'Type is possibly undefined'의 악몽에서 벗어나는 법
안녕하세요, 여러분. 15년 차 풀스택 개발자로서 솔직히 고백하자면, 저도 주니어 시절에는 빨간 줄이 뜨는 에러 메시지가 무서웠습니다. 특히 자바스크립트에서 타입스크립트(TypeScript)로 기술 스택을 전환하던 과도기에 가장 많이 마주쳤고, 가장 저를 괴롭혔던 에러가 바로 'Object is possibly undefined' 혹은 'Type is possibly null'이었습니다. 금요일 오후 5시, 퇴근을 앞두고 긴급 배포를 진행하는데 터미널에 이 에러가 수십 개씩 뜬다면 어떨까요? 아마 등줄기에 식은땀이 흐르고, 주말 약속은 취소해야 할지도 모른다는 공포감이 엄습할 것입니다. ☕
사실 이 에러는 타입스크립트가 우리를 괴롭히려는 것이 아닙니다. 오히려 "이봐, 지금 네가 접근하려는 데이터가 실제로는 없을 수도 있어! 이대로 배포하면 사용자가 버튼을 누르는 순간 앱이 펑 하고 터질 거야!"라고 미리 경고해 주는 아주 고마운 수호천사입니다. 자바스크립트 역사상 가장 악명 높은 'Uncaught TypeError: Cannot read property of undefined' 에러를 사전에 방지해 주는 강력한 수문장 역할을 하죠. 하지만 고마운 마음과는 별개로, 코드를 작성할 때마다 if (data && data.user && data.user.profile) 처럼 끝도 없이 이어지는 방어 코드를 작성하는 건 생산성을 갉아먹는 주범입니다.
제가 과거 대형 금융권 차세대 프로젝트를 진행할 때였습니다. API 응답 데이터의 깊이가 7단계 이상 되는 복잡한 JSON 구조를 다뤄야 했는데, 백엔드에서 특정 필드 하나가 누락되어 프론트엔드 전체 화면이 하얗게 변하는 '화이트 스크린(White Screen of Death)' 현상이 발생했습니다. 당시 팀원 4명이 이 문제를 해결하기 위해 방어 로직을 짜느라 꼬박 3일 밤을 샜던 기억이 납니다. 만약 그때 오늘 소개할 옵셔널 체이닝(Optional Chaining) 문법이 표준화되어 있었다면, 그 3일의 고통스러운 시간은 단 30분으로 줄어들었을 것입니다.
오늘 이 가이드에서는 단순히 문법 하나를 배우는 것을 넘어, 왜 우리가 undefined를 철저히 관리해야 하는지, 그리고 옵셔널 체이닝(?.)이 어떻게 우리의 코드를 우아하고 안전하게 혁신하는지 깊이 있게 파헤쳐 보려 합니다. 내부 동작 원리부터 성능 이슈, 흔히 저지르는 실수, 그리고 프로들만 아는 실전 팁까지 꽉 채웠으니 끝까지 정독해 주세요. 이 글을 읽고 난 후, 여러분의 코드는 더 이상 undefined를 두려워하지 않게 될 것입니다. 🚀
왜 'undefined'는 발생하며, 왜 위험한가?
엄격한 문지기: strictNullChecks의 세계
타입스크립트 설정 파일(tsconfig.json)에는 strictNullChecks라는 매우 중요한 옵션이 있습니다. 15년 전 자바스크립트 개발 환경과 비교하면 이 옵션은 가히 혁명과도 같습니다. 과거에는 모든 변수에 null이나 undefined가 들어갈 수 있다고 암묵적으로 가정하고 코딩했습니다. 이는 마치 지뢰밭을 눈을 가리고 걷는 것과 같았죠. 언제 어디서 터질지 모르니까요. 하지만 이 옵션을 켜는 순간, 타입스크립트는 변수가 '확실히 값이 있는 상태(T)'인지 '없을 수도 있는 상태(T | undefined)'인지를 매우 엄격하게 구분하기 시작합니다.
쉬운 예로 택배 상자를 생각해 봅시다. 여러분이 택배를 주문했는데, 상자 안에 물건이 있을 수도 있고(Value), 상자가 비어있을 수도 있고(Null), 아예 상자조차 배달되지 않았을 수도 있습니다(Undefined). 기존 자바스크립트는 상자가 도착하지도 않았는데 "상자를 열어서 물건을 꺼내!"라고 명령하면 프로그램이 즉시 멈춰버렸습니다. 이것이 바로 런타임 에러입니다. 타입스크립트는 컴파일 단계에서 "잠깐, 상자가 도착했는지 확인부터 해야지! 안 그러면 난 이 코드를 통과시켜 줄 수 없어."라고 막아섭니다. 이것이 우리가 보는 빨간 줄의 정체입니다.
많은 주니어 개발자들이 이 엄격함을 귀찮아하며 any 타입을 남발하거나 ! (Non-null assertion) 연산자로 컴파일러의 입을 강제로 막아버리곤 합니다. 하지만 이건 시한폭탄을 안고 가는 것과 같습니다. 실제 운영 환경(Production)에서 데이터는 언제나 우리의 예상과 다르게 들어옵니다. 네트워크 지연으로 데이터가 늦게 오거나, 백엔드 로직 변경으로 특정 필드가 삭제될 수도 있죠. 이때 strictNullChecks를 무시했다면, 사용자는 텅 빈 화면이나 멈춘 앱을 보게 될 것입니다.
통계적으로 보면, 프론트엔드 애플리케이션에서 발생하는 버그의 약 20% 이상이 null 또는 undefined 참조 오류에서 기인한다고 합니다. 프로그래밍 언어의 창시자 토니 호어(Tony Hoare)가 "10억 달러짜리 실수(The Billion Dollar Mistake)"라고 불렀던 null 참조 오류를 막기 위해, 우리는 이 '귀찮음'을 기꺼이 받아들여야 합니다. 그리고 그 귀찮음을 해결해 줄 구세주가 바로 뒤에 나올 옵셔널 체이닝입니다.
과거의 고통: && 연산자의 지옥과 Falsy의 함정
옵셔널 체이닝이 등장하기 전(TypeScript 3.7 이전), 우리는 중첩된 객체의 속성에 접근하기 위해 소위 '피라미드'를 쌓아야 했습니다. 예를 들어 user.address.street에 접근하고 싶은데 user가 없을 수도 있고, address가 없을 수도 있는 상황을 가정해 봅시다. 우리는 울며 겨자 먹기로 다음과 같이 코드를 작성했습니다.
const street = user && user.address && user.address.street;
이 코드는 안전해 보이지만 치명적인 단점이 있습니다. 첫째, 가독성이 매우 떨어집니다. 속성의 깊이가 깊어질수록 코드는 옆으로 길어지고, 내가 지금 무엇을 확인하려는지 한눈에 들어오지 않습니다. 개발자들 사이에서는 이를 '가드 코드(Guard Code)의 늪'이라고 불렀죠. 코드 리뷰를 할 때마다 이런 중복 코드를 보는
댓글
댓글 쓰기