‘빈 문자열은 절대 못 들어와’ — 검증을 반복하지 말고 타입으로 못 박는 법

무슨 일이냐면요

Haskell(하스켈)이라는 함수형 언어 커뮤니티에서 ‘타입으로 검증된 비어있지 않은 문자열(non-empty string)’이라는 주제의 글이 올라왔어요. 하스켈을 안 써도 괜찮아요. 여기 담긴 아이디어는 모든 언어 개발자에게 통하는 보석 같은 개념이거든요.

흔한 상황을 떠올려볼게요. 회원가입에서 ‘이름’을 받는다고 쳐요. 이름은 당연히 빈 값이면 안 되겠죠. 그래서 우리는 보통 함수 안에서 if name == "" then 에러 같은 검사를 넣어요. 그런데 문제는, 이 함수를 호출하는 곳이 열 군데, 백 군데로 늘어나면 그중 한 곳에서 검사를 깜빡할 수 있다는 거예요. 그러면 빈 이름이 슬그머니 시스템 깊숙이 들어와서 한참 뒤 엉뚱한 곳에서 터져요.

핵심 아이디어: “검증하지 말고, 파싱해라”

이 글이 말하는 해법은 발상의 전환이에요. “빈 문자열일 수도 있는 값과, 절대 빈 문자열일 수 없는 값을 아예 다른 타입으로 구분하자”는 거예요.

이게 뭐냐면요. 보통 문자열은 그냥 String 타입 하나잖아요. 그런데 여기에 NonEmptyString(비어있지 않은 문자열)이라는 새로운 타입을 하나 더 만드는 거예요. 그리고 이 타입은 오직 ‘검증을 통과한 경우에만’ 만들어질 수 있게 막아둬요. 이걸 ‘스마트 생성자(smart constructor)’라고 불러요. 빈 문자열을 넣으면 NonEmptyString을 못 만들고 실패하는 거죠.

핵심은 그다음이에요. 일단 NonEmptyString 타입의 값을 손에 쥐었다면, 그 값은 이미 비어있지 않다는 게 타입 차원에서 보장돼요. 그래서 이 값을 받는 함수들은 더 이상 “혹시 비어있나?” 검사를 할 필요가 없어요. 컴파일러가 “이건 절대 안 비어있어”라고 보증서를 끊어준 셈이니까요.

어떻게 동작하냐면

흐름을 정리하면 이래요. 데이터가 시스템에 들어오는 ‘입구’(예: API 요청, 폼 입력)에서 딱 한 번 검증해서 NonEmptyString으로 바꿔요. 검증에 실패하면 거기서 바로 막고요. 일단 통과하면 그 안쪽 코드들은 전부 ‘이미 검증된 값’만 다루게 돼요.

이렇게 하면 검증 로직이 시스템 곳곳에 흩어지지 않고 입구 한 곳에 모여요. 그리고 ‘검사를 깜빡했다’는 실수 자체가 불가능해져요. 왜냐하면 검사 안 한 일반 String을 검증된 값 자리에 넣으려고 하면 컴파일이 안 되니까요. 버그를 런타임이 아니라 컴파일 단계에서 잡는 거예요.

업계 맥락

이 철학을 한 문장으로 “Parse, don’t validate(검증하지 말고 파싱하라)”라고 불러요. 함수형 진영에서 유명한 격언인데요. 점점 다른 언어로도 퍼지고 있어요. TypeScript에서는 브랜디드 타입(branded type), Rust에서는 newtype 패턴으로 똑같은 걸 구현해요. 자바나 코틀린에서도 작은 값 객체(value object)로 비슷하게 흉내 낼 수 있고요.