빌드가 멈추는 이유의 절반은 심각한 버그가 아니에요. 밀가루 컵에 소금을 붓는 것과 같은 실수예요.
코드 안의 모든 데이터에는 타입이 있어요. 그 데이터가 어떤 종류인지를 나타내는 라벨이에요. 텍스트는 하나의 타입이에요(개발자들은 이를 "string"이라 불러요). 정수는 또 다른 타입이고요. 목록도, 참·거짓도 각각 타입이에요. 이 라벨은 장식이 아니에요. 그 데이터로 무엇을 할 수 있는지를 결정해요.
라벨이 붙은 계량컵을 떠올려 보세요. 조리대 위에 밀가루, 소금, 달걀이라고 적힌 컵이 줄지어 있어요. 라벨이 있는 이유는 소금을 밀가루 자리에 쏟아 반죽을 망치지 않기 위해서예요. 타입은 데이터의 그 라벨이에요. "아이템 수량" 칸은 실제 숫자를 기대해요. 12(숫자) 대신 "twelve"(텍스트)를 넣으려 하면 주방이 바로 막아서요. 잘못된 재료가 잘못된 컵에 들어가는 거예요.
타입 에러는 컴퓨터가 정확히 그 불일치를 잡아내고 실행을 거부하는 거예요. "숫자가 필요한데 텍스트를 넘겼습니다." 대표적인 사례들이 있어요.
- 텍스트로 저장된 전화번호에 수학 연산을 시도하는 것 (
"555-1234" + 1은 말이 안 돼요). - 목록이 아닌 것에서 세 번째 항목을 꺼내려는 것.
- 이름을 기다리는 함수에 날짜를 넘기는 것.
바이브 코딩을 하는 분들이 가장 많이 부딪히는 벽이 바로 이거예요. AI가 코드를 잔뜩 작성해줬고, 기대를 품고 실행하면 작동 대신 TypeError: expected string, got undefined 같은 메시지가 튀어나와요. 충돌처럼 느껴지고 실패처럼 느껴지는데, 사실은 정반대예요. 안전망이 제 역할을 하는 거예요. 잘못된 재료가 완성된 요리에 섞여 고객에게 전달되기 전에 미리 잡아내는 거니까요.
다음 개념으로 이어지는 좋은 소식도 있어요. 이런 오류의 상당수는 코드가 실행되기도 전에, 빌드하는 즉시 잡혀요. 라벨을 미리 전부 검사하는 언어들이 있거든요. TypeScript 같은 "타입 언어"라고 부를 때 그 이름 자체가 타입에서 온 거예요. 빌드 시점에 불일치를 잡는다는 건, 라이브 환경에서 누군가 앞에 드러나기 전에 내 기기에서 조용히 해결한다는 뜻이에요.
타입 에러를 만나면 코드를 눈으로 훑으며 짐작하지 말고, 에러 메시지 전체를 AI에게 붙여 넣으세요. 그 긴 텍스트가 스택 트레이스이고, 잘못된 재료가 잘못된 컵에 들어간 정확한 지점을 알려줘요. 열에 아홉은 한 줄로 해결돼요. 텍스트를 숫자로 변환하거나, 값이 실제로 존재하는지 먼저 확인하거나, 올바른 종류의 값을 넘기면 되거든요.
타입 에러는 프로젝트가 망가지는 신호가 아니에요. 밀가루 컵에 소금이 들어가기 전에, 라벨이 제 역할을 다하고 있는 거예요.