타입스크립트의 유니온 타입을 하스켈에서 구현하려다 겪은 멘붕기

요약 타입스크립트(TypeScript)의 유니온 타입(Union Types)과 리터럴 타입(Literal Types, 싱글톤 타입)을 하스켈(Haskell)에서 어떻게 구현할 수 있는지 비교한 개발 블로그 글입니다. 타입스크립트에서는 'ok: false'와 에러 문자열, 혹은 'ok: true'와 특정 허용 크기(96 | 128 | 512) 및 유저 역할("ADMIN" | "GUEST")을 간결하고 직관적인 유니온 타입으로 깔끔하게 묶어 표현할 수 있습니다. 반면 기본 하스켈에서는 이러한 값들을 정의하기 위해 UserRole이나 AvatarSize 같은 별도의 대수적 데이터 타입(ADT)을 선언해야 하며, 실제 값(96, 128 등)이 태그 뒤로 숨겨져 가독성과 간결함이 떨어지는 단점이 있습니다. 작성자는 이를 극복하기 위해 하스켈의 GHC 언어 확장 기능들을 탐색했습니다. 첫 번째 대안으로는 DataKinds와 GADTs를 활용해 타입 레벨 자연수 리스트([Nat])를 처리하는 OneOfNat(Here, There 구조) 방식을 시도했으나, 패턴 매칭 시 Here와 There가 중첩되어 코드가 복잡해졌습니다. 두 번째 대안으로 언박스드 섬(UnboxedSums) 문법((# SNat 96 | SNat 128 | SNat 512 #))을 사용해 평탄한 문법을 구성했으나, 언박스드 섬은 일반 타입과 다르게 동작해 아리티(항수)에 따라 카인드(Kind)가 달라지면서 타입 패밀리를 통한 일반화 과정에서 에러가 발생했습니다. 결국 두 방식 모두 중복을 알아서 정규화해주는 집합(Set) 형태의 유니온 시맨틱을 완벽히 제공하지 못하며, 이를 타입 레벨 Set으로 해결하려 해도 표현만 지나치게 복잡해진다는 한계를 지적하며 글을 마무리했습니다. 하스켈 같은 순수 함수형 언어보다 오히려 타입스크립트의 유연한 타입 시스템이 실무 API 모델링에서 얼마나 편리한지 보여주는 기술 분석입니다.