코틀린 오류 처리의 새로운 진화: Rich Errors 제안서

코틀린은 개발자가 일상적으로 마주하는 프로그래밍 문제를 실용적으로 해결하는 언어로 오랫동안 사랑받아 왔습니다. 특히 null 안전성(null-safety) 시스템은 코틀린의 대표적인 강점 중 하나입니다. 하지만 복구 가능하고 예측 가능한 오류를 다루는 영역에서는 일급 언어 기능(first-class language feature)이 부재한 채, 개발자들이 여러 패턴을 조합하여 대응해 왔습니다. Rich Errors 제안서, 즉 에러 유니온 타입(Error Union Types)은 바로 이 공백을 해소하기 위한 의미 있는 설계 이니셔티브입니다.

이번 글에서는 해당 제안서의 동기와 설계 철학을 깊이 있게 살펴봅니다. 코틀린의 기존 오류 처리 패턴이 지닌 한계를 분석하고, Rich Errors 기능이 이를 어떻게 하나의 표현력 있고 타입 안전하며 편리한 시스템으로 통합하고자 하는지 살펴보겠습니다. 오류 처리에 관심이 있는 코틀린 개발자라면, 이 제안서가 앞으로의 코틀린 생태계에 어떤 변화를 가져올 수 있는지 주목할 필요가 있습니다.

코틀린 오류 처리의 현주소: 패턴별 장단점 분석

이 제안서는 코틀린이 JVM 생태계를 물려받으면서 예외(exception) 기반으로 출발했다는 점을 먼저 짚고 있습니다. 다만 코틀린은 의도적으로 Java의 논란이 많은 checked exception을 도입하지 않았으며, 그 결과 개발자들은 주로 세 가지 패턴으로 오류를 처리해 왔습니다. 각 패턴에는 고유한 트레이드오프가 존재합니다.

1. 복구 불가능한 오류를 위한 예외(Exception)

코틀린의 철학에서 예외는 복구 불가능한 오류, 즉 프로그래머의 버그나 사전 조건 위반에 사용하도록 설계되었습니다. 프레임워크 수준의 비로컬(non-local) 제어 흐름에도 예외가 활용됩니다. 가령 require(userName.isNotBlank())는 사용자 이름이 빈 문자열인 경우 예외를 던지는데, 빈 사용자 이름 자체가 함수 계약(contract)의 위반이기 때문입니다. 호출자가 이 오류로부터 "복구"할 필요는 없으며, 단순히 코드 버그를 수정해야 합니다. 이러한 사용 사례는 현재의 예외 시스템으로 충분히 잘 동작하고 있으므로, 이번 제안서의 대상이 아닙니다.

2. 단순한 실패를 위한 nullable 타입(T?)

단순하고 복구 가능한 실패를 처리하는 가장 보편적이고 관용적인 방법은 null을 반환하는 것입니다. String.toIntOrNull()이나 List<T>.firstOrNull() 같은 함수가 대표적인 예시이며, 코틀린의 null 안전성 연산자(?., ?:)와 자연스럽게 조합할 수 있다는 장점이 있습니다.