이 함수, 실패하면 어떻게 되나요? null부터 Rich Errors까지, Kotlin 에러 처리 15년

Kotlin이 15년간 시도해온 에러 처리 방식들을 짚고, JetBrains가 만들고 있는 Rich Errors가 실제 앱 코드를 어떻게 바꾸는지 본 뒤, 나아가 AI가 코드를 쓰는 시대에 실패를 언제 정의해야 하는지까지 다룹니다.

https://ticketa.co/event/ic97nj1c

Transcript

1. Kotlin User Groups Seoul COMMUNITY EVENT 2026 KotlinConf Extended 2026 KOTLIN 이 함수, 실패하면 어떻게 되나요? null부터 Rich Errors까지, Kotlin 에러 처리 15년 이태희 / Mobile Engineer KOTLINUSERGROUPSEOUL
2. UserRepository.kt
3. UserRepository.kt null 무슨 일이 있었을까요?
4. null이 나온 이유 1 사용자가 존재하지 않는다 2 요청이 1초 안에 끝나지 않았다 둘 다 같은 null 입니다
5. 그런데 대응은 Mobile Server
6. AI 에게 요청해서 받은 함수 AI 생성 코드 여기서 null 을 받는다면?
7. Kotlin은 15년째 실패를 말하는 문법이 없습니다
8. 발표자 소개 이태희 Mobile Engineer 2년 차지만, 벌써 3번 째 회사 입사 직전인.. 1 GDG Korea Android super.init(ver=6) 발표 경험 2 안드로이드 개발 공부 5년차 3 IT 동아리 회장 경험 haeti-dev haeti
9. 오늘의 순서 01 15년 에러 처리 변천사 예외 / null / sealed / Result / Arrow 가 각자 남긴 문제 02 Rich Errors 실패를 반환 타입에 적는 문법과 설계 원칙, 그리고 못 하는 것 03 그래서 어떻게 쓰나 4일 전 공개된 따끈따끈한 공식 예제 04 AI 시대의 에러 처리 절차는 자유롭게, 도메인 계약은 명확하게
10. KEEP Kotlin Evolution and Enhancement Process github.com/Kotlin/KEEP
11. KEEP-0441 / 2025 / 왜 필요한가 KEEP-0462 / 2026 / 어떻게 만든 것인가
12. 15년 타임라인 2011 2016 2017 2018 2021 2025 2026 공개 1.0 Arrow kotlin.Result sealed interface Rich Errors 공개 설계 명세
13. checked exception을 버리게 된 계기 UserRepository.java 결정은 옳았지만 대가가 있었다
14. 11년 동안 살아있는 이슈 youtrack.jetbrains.com/issue/KT-7128
15. null 관용구와 균열 null.kt
16. sealed class / interface 프로젝트마다 반복되는 이름들 UserResult.kt UserResult LoginResult PaymentResult ProfileResult ...
17. kotlin.Result의 탄생 UserRepository.kt kotlin/coroutines/Continuation.kt
18. Arrow 2017년, 커뮤니티가 만든 Kotlin 함수형 라이브러리 UserRepository.kt
19. Either 가 좋은 건 알겠어요. 그런데 제네릭도 낯설어하는 팀원들에게 써드 파티 기술을 6개월 가르칠 수는 없어요. 이건 Arrow 잘못이 아니에요. reddit.
20. Boolean? 하나에 세 가지 의미
21. 정리 방식 풀었던 것 남긴 것 예외 복구 불가 상황 처리 실패 가능성을 적을 곳이 없다 null 간결한 관용구와 체인 이유와 위치가 사라진다 sealed Exhaustive 검사 성공까지 감싸야, API 마다 반복 Result 표준 래퍼 에러 타입 표현 불가 Arrow 타입 있는 에러 팀의 학습 비용 전부 언어가 준 범용 재료로 각자 조합한 방식, 복구 가능한 실패를 위한 전용 문법은 한 번도 없었습니다
22. In KotlinConf 2025 Michail Zarečenskij / KotlinConf 2025
23. 문법 UserRepository.kt
24. UserRepository.kt
25. 소비하는 쪽 UserRepository.kt
26. 아무 타입이나 묶이는 건 아니다 RichErrors.kt
27. 왜 제한했나 진짜 유니온 타입이라면 Rich Errors는
28. 설계 원칙 1 값처럼 다룬다 2 복구 가능한 실패에만 쓴다 3 when이 exhaustive해야 한다 4 컴파일이 느려지지 않게 한다
29. 예외와의 경계 예외 / 복구 불가 에러 / 호출자가 판단 Validator.kt 사용자가 없다 네트워크가 끓어졌다 github.com/Kotlin/KEEP/discussions/447 / e2e4b6b7
30. 새로운 문법 . UserRepository.kt
31. ?. → !. → |. github.com/Kotlin/KEEP/discussions/447 / e2e4b6b7
32. traceability 규칙 UserRepository.kt
33. 최다 표를 받은 반론
34. 언어팀의 답
35. 두 가지가 안 됩니다 ErrorTypes.kt NetworkErrors.kt
36. Error types cannot have superclasses, superinterfaces, or generic parameters. ... It s needed to form only DISJOINT UNIONS. KEEP-0462 / Error types 에러와 값이 절대 격치지 않는 구조 평범한 타입 검사로 구분된다 Due to the disjointness ... it will always be possible to distinguish between them using ORDINARY RUNTIME TYPE 도 도 박싱 래퍼OF CHECKS . This representation AVOIDS THE OVERHEAD BOXING AND UNBOXING , making error handling almost overhead free. KEEP-0462 / Compilation scheme for JVM 필요 없다
37. KEEP-0462 / 타입 계층
38. 정리 UserRepository.kt
39. notes/0009 / Design Notes: Evaluating Rich Errors in the Wild
40. 실패 하나를 적으려고 성공까지 감쌌다 허용 여부와, 허용일 때 쓸 설정값을 함께 돌려줘야 한다 BEFORE CustomHeaderAllowedChecker.kt AFTER CustomHeaderAllowedChecker.kt
41. 에러가 반환 타입 밖으로 나가는 경우 BEFORE MediaRegistration.kt AFTER MediaRegistration.kt
42. 이름만 같고 다른 타입 CreateSessionError.kt UpdateSessionError.kt 두 RateLimited 의 공통 타입이 없다
43. 그래서 호출부가 어떻게 되나 PinEntryForRegistrationLockViewModel.kt
44. Signal이 직접 만든 범용 래퍼 NetworkResult.kt / 469줄 / 함수 29개 “ 복잡한 요청이라면, 이건 당신을 위한 게 아닙니다. 직접 sealed class를 만드는 편이 나을 겁니다. ” NetworkResult.kt 의 KDoc / Signal-Android
45. AI가 sealed class를 다 만들어주는데, Rich Errors가 아직 필요한가요?
46. 비용은 사라진 게 아니라 옮겨갔다 만드는 비용 → 거의 0 읽는 비용 → 그대로 이해하는 비용 → 그대로 중복이 늘어나는 속도 → 더 빨라진다 만드는 비용은 사라졌지만, 의미의 비용은 사라지지 않았습니다
47. 명세를 먼저. 실행은 맡긴다. Opus 5 performs best when given the complete task specification up front and left to run . 완전한 작업 명세를 먼저 주고, 그다음은 맡겨둘 때 가장 잘한다. Anthropic / Prompting Claude Opus 5
48. 실패는 원인이 아니라 다음 행동으로 나뉘다 다음 행동 표현 예상된 실패 복구 / 안내 / 재시도 값으로 반환 깨진 전제 중단하고 알린다 예외로 던진다 취소 즉시 위로 전달 절대 삼키지 않는다 실패는 기술적 사건이 아니라 도메인 판단입니다
49. 잡기 전에 정의한다 기존 AI가 구현 새로 도메인 분석 테스트 리뷰 성공과 실패 정의 빠진 실패 발견 타입에 기록 재작업 ↻ 다시 처음으로 AI가 그 안에서 구현 에러 처리를 잘한다는 건, 구현 전에 어떤 실패가 존재하는지 정의하는 겁니다 컴파일러가 즉시 지적
50. 문서는 지도, 타입은 계약 규칙 문서 찾을 수 있게 한다 AGENTS.md / CLAUDE.md 타입 시그니쳐 방향을 제한한다 User | NotFound 컴파일러 즉시 알려준다 exhaustive / must-use
51. 좋은 타입은 압축된 도메인 지식 UserRepository.kt 성공 타입 가능한 실패의 유한한 목록 새 실패가 생기면 고쳐야 할 호출부 재시도에 필요한 데이터
52. UserRepository.kt
53. 개발자의 역할은 구현에서 정의로 옮겨갑니다 도메인을 이해하고, 그 이해를 명료한 계약으로 바꾸는 일 KEEP-0462 토론 #487 notes/0009 github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0462-rich-errors.md github.com/Kotlin/KEEP/discussions/487 github.com/Kotlin/KEEP/blob/main/notes/0009-rich-errors-use-cases.md
54. 실패를 정의할 수 있어야, AI가 성공을 구현할 수 있습니다 Rich Errors는 그 정의를 사람과 AI와 컴파일러가 함께 읽게 합니다
55. Kotlin User Groups Seoul COMMUNITY EVENT 2026 감사합니다 haeti-dev haeti pakengo@gmail.com KOTLINUSERGROUPSEOUL