자바 sealed 클래스, 컴파일 시점의 한계와 위험
원제 Java sealed classes and exhaustive pattern matching
110 포인트댓글 82
Key Point
sealed 클래스의 exhaustive pattern matching이 모든 문제를 해결하지 못하며, 특히 공개 API에 사용될 때 예상 밖의 런타임 에러를 초래할 수 있다는 실제 위험을 설명한다.
핵심 요약
- Java 17의 sealed 클래스는 인터페이스나 기본 클래스의 하위 타입을 명시적으로 제한하여, 패턴 매칭 시 모든 경우를 다뤘는지 컴파일러가 검증할 수 있게 해준다.
- sealed 인터페이스/클래스에 switch 식을 사용하면 컴파일러가 모든 경우를 확인했는지 판단하여, 누락된 경우가 없다면 default 절을 생략해도 되므로 코드 안전성이 높아진다.
- 하지만 새로운 하위 타입을 sealed 클래스에 추가하는 것은 기존 코드의 switch 문을 깨뜨리므로 주요 버전 업그레이드가 필요한 breaking change가 된다.
- 컴파일러는 컴파일 시점에만 전수성을 보장할 수 있으며, 소비자 코드를 재컴파일하지 않으면 런타임에 MatchException이 발생한다.
- sealed 타입을 추가해도 기존 바이너리는 새로운 경우를 처리하지 않으므로, 모든 코드를 함께 재컴파일하지 않으면 정적 검증의 이점이 사라진다.
- 저자는 sealed 클래스가 컴포넌트 내부 구현에서는 유용하지만, 공개 API로 노출될 경우 모듈 경계를 넘나들며 런타임 에러를 야기할 수 있다고 지적한다.