더 좁은 타입의 유효성에 대하여

사람이 무언가를 집중해서 바라보다 보면, 어느샌가 주변부가 흐려지고 가끔은 집중하고 있던 그 대상조차 보이지 않게 된다. 처음엔 분명하게 인식되던 경계가 서서히 사라지고, 오히려 애써 무시했던 주변이 본질을 가릴 때도 있다. 잘 보려 애쓰는 행위가, 역설적으로 시야를 좁히는 순간이다.

개발에서도 비슷한 순간이 찾아온다. 타입을 정교하게 다듬고, 설계를 촘촘하게 만드는 데 집중하다 보면 어느새 전체 맥락을 잃어버린다. 엄밀함이라는 이름 아래, 타입 그 자체에 집착하게 되고, 그 타입이 놓인 현실적인 맥락은 시야에서 밀려난다. 나는 그 맹목의 순간을 몇 번이나 지나왔다.

타입스크립트를 사용하다 보면 “더 정확한 타입”, “더 안전한 설계”라는 목표는 언제나 옳아 보인다. 실제로 많은 버그를 사전에 차단해주고, 코드의 의도를 명확히 드러내는 데에도 큰 도움이 된다. 문제는 그 정확함이 목적이 되는 순간부터 시작된다.

타입을 정교하게 만들기 위해 복잡한 제네릭을 쌓고, 모든 경우의 수를 타입 레벨에서 봉쇄하려고 하다 보면, 어느새 질문이 바뀐다.

“이 코드는 현실에서 어떻게 쓰일까?”가 아니라
“이 타입은 논리적으로 완벽한가?”가 중심이 된다.

그 순간부터 설계는 점점 현실과 멀어진다.

개발에서의 엄밀함은 분명 중요하다. 하지만 그 엄밀함은 언제나 맥락 위에 놓여야 한다. 타입은 코드를 설명하는 수단이지, 그 자체로 완결된 세계가 아니다. 타입이 현실을 설명하지 못하는 순간, 타입을 잘못 설계한 것이 아니라 타입을 바라보는 시야를 잘못 설정한 것일지도 모른다.

이후 설계를 수정하면서 나는 한 가지 원칙을 다시 세웠다. 설계는 “완벽하게 막는 것”보다, “잘못되었을 때 드러나는 것”이 더 중요하다는 점이다. 모든 경우를 사전에 봉쇄하려 하기보다는, 현실적인 사용을 자연스럽게 수용하고, 잘못된 조합이 명확하게 실패하도록 만드는 쪽이 더 건강한 구조일 수 있다.

아이러니하게도, 그렇게 한 발 물러서서 설계를 다시 보니 이전보다 타입은 더 단순해졌고, 구조는 오히려 더 단단해졌다. 시야를 넓히자, 그제야 정말로 잘 보이기 시작했다.

개발자는 종종 “더 잘 보기 위해” 눈을 좁힌다. 하지만 집중이 맹목이 되는 순간, 우리는 중요한 것을 놓친다. 타입이든, 아키텍처든, 추상화든 마찬가지다. 잘 만든다는 명분 아래, 우리가 보고 있는 것이 무엇인지 스스로에게 묻지 않으면, 설계는 쉽게 현실과 어긋난다.

요즘 나는 코드보다도, 내가 어디를 보고 있는지를 더 자주 점검하려 한다. 엄밀함에 취해 시야를 좁히고 있지는 않은지, 논리적으로 완벽하다는 이유로 현실을 외면하고 있지는 않은지. 그 질문을 던지는 것만으로도, 설계는 조금 더 사람을 닮아간다.