타입스크립트에서 '검증하지 말고 파싱하라'를 굳이 적용하는 방법

요약 타입스크립트(TypeScript) 개발자라면 누구나 코드베이스 곳곳에 따개비처럼 덕지덕지 붙어 있는 방어적 if 검사 코드에 지쳐본 경험이 있을 것입니다. 저자는 알렉시스 킹(Alexis King)의 유명한 2019년 글인 '검증하지 말고 파싱하라(Parse, don't validate)'를 다시금 돌아보며, 타입스크립트 환경에서 왜 여전히 많은 개발자들이 파싱 대신 단순 유효성 검증(Validation)에 머무르고 있는지 짚었습니다. 단순 유효성 검증기는 조건이 맞으면 boolean 값을 반환하며 '통과'라고 외치지만, 함수가 종료되는 즉시 그 검증 결과를 잊어버립니다. 예를 들어 `isValidUser(user)`로 이메일과 나이를 검사해도 타입 시스템상 `user.email`은 여전히 일반 문자열(`string`), `user.age`는 단순 숫자(`number`)로 남습니다. 따라서 몇 단계 깊은 호출 스택에서 이메일을 다룰 때도 컴파일러는 검증 여부를 전혀 알지 못하며, 결국 개발자들은 곳곳에 중복된 if 검사를 추가하는 이른바 '산탄총 파싱(shotgun parsing)'의 함정에 빠지게 됩니다. 반면 파서는 모호한 원시 데이터를 받아 검증된 더 정밀한 타입을 반환하거나 실패 이유를 알립니다. 이를 통해 한 번 `EmailAddress` 타입으로 파싱되면 프로그램 전체에서 다시는 유효성을 의심할 필요가 없어집니다. 하스켈(Haskell)이나 엘름(Elm), F# 같은 언어에서는 불투명 타입(opaque type)과 스마트 생성자(smart constructor)를 통해 이를 손쉽게 강제할 수 있지만, 타입의 구조만 같으면 같은 타입으로 취급하는 구조적 타이핑(structural typing)을 채택한 타입스크립트는 이를 기본적으로 지원하지 않습니다. 글에서는 타입스크립트에서 이를 우회하기 위해 널리 쓰이는 기법인 '브랜디드 타입(Branded types, phantom types)'을 소개합니다. `unique symbol` 등을 활용해 컴파일 시점에만 존재하는 가상의 브랜드를 결합함으로써 `Email` 타입을 일반 `string`과 호환되지 않도록 분리하는 방식입니다. 이를 통해 전용 파서 함수(`parseEmail`)를 거쳐야만 올바른 타입을 획득할 수 있도록 강제하여, 타입스크립트의 구조적 한계 속에서도 불가능한 상태를 표현할 수 없도록(make illegal states unrepresentable) 만드는 접근법을 보여줍니다.