아, 이거 나잖아? 당신이 '찐' 타입스크립트 개발자라면 겪었을 공감 백서
2026. 6. 9.
아, 이거 나잖아? 당신이 '찐' 타입스크립트 개발자라면 겪었을 공감 백서
몇 달 전, 제가 작성했던 '당신이 '진짜' 자바스크립트 개발자라면...' 포스트가 생각보다 많은 분의 공감을 얻었어요. 그저 재미로 쓴 글이었는데, 댓글들을 보니 역시 개발자라면 누구나 겪는 고난과 역경이 있더라고요.
알 수 없는 버그, 툭하면 터지는 npm 오류, console.log로 점철된 디버깅, 왜 돌아가는지 아무도 모르는 코드 같은 것들 말이죠.
최근에는 @sylwia-lask 님의 '당신이 '진짜' 소프트웨어 개발자라면...'이라는 글을 봤는데, 정말이지 폭풍 공감했습니다.
그 글이 단순히 웃겨서가 아니었어요. 개발자 커뮤니티의 가장 멋진 점을 다시 한번 깨닫게 해주었거든요. 우리는 각기 다른 기술 스택을 쓰고, 다른 일을 하며, 경험치도 천차만별인데, 신기하게도 같은 이야기들을 공유하고 있단 말이죠.
자바스크립트에 이어, 실비아 님의 소프트웨어 개발자 에디션까지 나왔으니, 저도 이 즐거운 전통을 이어가지 않을 수 없겠죠?
이번에는 우리 자신으로부터 우리를 보호하는 데 절반의 시간을 쓰는 언어, 바로 타입스크립트에 대해 이야기해볼까 합니다.
그럼, 당신이 '진짜' 타입스크립트 개발자라면...
🔷 첫 번째 타입스크립트 현실 점검
자바스크립트 프로젝트를 타입스크립트로 전환하면서 "이거 한 시간이면 충분하겠지?"라고 생각했습니다. 하지만 사흘이 지나도 타입 에러와 씨름하고 있는 자신을 발견하죠.
any를 추가해서 에러를 일단 잠재운 뒤, '나중에 꼭 고치러 돌아올 거야!'라고 굳게 다짐했지만, 그 약속은 지켜진 적이 없습니다. 제가 실무에서 레거시 프로젝트에 처음 타입스크립트를 적용했을 때 딱 이랬죠. any가 마법처럼 에러를 없애주었지만, 결국 그 대가는 미래의 제가 치렀습니다.
타입스크립트 에러 하나를 고쳤는데, 새로운 에러 열두 개가 우르르 쏟아져 나오는 경험은 마치 어떤 업적 달성 시스템 같습니다.
타입 에러를 20분 동안 노려보며, "난 내 의도를 아는데, 왜 타입스크립트는 내 의도를 모르는 거지?"라고 중얼거린 적이 있습니다.
as any를 작성하고 미묘한 수치심을 느꼈다면, 당신은 이미 찐입니다.
🤝🏻 애증의 관계
하루 종일 타입스크립트를 욕하다가도, 막상 순수 자바스크립트로 작업하려니 완전히 길을 잃은 듯한 기분을 느껴보셨나요?
"좀 더 간단하게 만들자"고 타입 어노테이션을 지웠다가, 타입스크립트의 강력한 반대에 부딪힌 적이 있을 겁니다.
실제 비즈니스 로직을 작성하는 시간보다 타입을 설계하는 데 더 많은 시간을 쏟았습니다.
어떤 제네릭 타입을 보고 "세상에, 이 멋진 코드는 누가 짠 거지?"라고 감탄하다가, 6개월 전의 나 자신이라는 사실을 깨닫고 살짝 부끄러워진 적도 있죠.
그리고 또 다른 제네릭 타입을 보고 "이 악몽 같은 코드는 도대체 누가 만든 거야?"라고 분노하다가, 역시나 나 자신이라는 것을 알게 됩니다.
인생이 복잡하니까, 어떤 값을 string | number | null | undefined로 타입 지정해버렸을 때, 당신은 이미 타입스크립트를 제대로 다루고 있는 겁니다.
🧠 진정한 고수의 순간
파일을 열었는데 다음과 같은 코드를 발견합니다:
type Result<T extends keyof U, U extends object>
그리고 즉시 파일을 닫아버리죠. 저는 이런 복잡한 제네릭 타입을 처음 마주쳤을 때, '내가 타입스크립트를 너무 쉽게 봤나?' 하는 좌절감에 잠시 다른 일로 도피했던 경험이 있어요. 하지만 결국 하나씩 뜯어보며 이해했을 때의 쾌감은 또 남다르죠.
한 시간 동안 타입스크립트와 치열하게 싸우다가, 결국 타입스크립트가 옳았다는 사실을 깨닫고 겸허해졌습니다.
IDE에서 빨간 밑줄이 드디어 사라졌을 때, 작지만 진심 어린 축배를 들었습니다.
한 곳에서 속성 이름을 변경했는데, 타입스크립트 덕분에 20개가 넘는 파일이 깨지는 걸 막아주는 기적을 목격하고는 잠시나마 진정한 감사를 느꼈을 겁니다.
프로젝트에 strict mode를 추가하고, 차라리 발견하지 않았으면 좋았을 법한 코드들을 발견했습니다.
자동 완성 기능을 너무 많이 써서, 이제는 속성 이름을 전부 다 입력하는 것이 어색하게 느껴진다면, 당신은 이미 타입스크립트와 한 몸이 된 것입니다.
🚨 비상 해결책
// @ts-ignore를 작성하고 아무도 눈치채지 못하길 바랐던 적이 있습니다.
미래의 나 자신도 이해하려면 문서가 필요할 정도로 복잡한 타입을 작성했습니다.
타입스크립트 에러를 구글에 복사해서 붙여넣었더니, 답변에는 원래 에러보다 더 많은 타입스크립트 코드가 담겨 있었습니다.
같은 디버깅 세션 동안 "타입이 맞고, 코드가 틀렸다"고 말하다가, 이내 "코드가 맞고, 타입이 틀렸다"고 말을 바꿨습니다.
마침내 버그를 고쳤는데, 타입스크립트가 이틀 전에 이미 그 버그를 경고했다는 사실을 깨닫고 망연자실했던 순간도 있겠죠.
🎯 그래서, 당신은 '공식적인' 타입스크립트 개발자인가요?
이 리스트를 읽으면서 몇 줄마다 고개를 끄덕였다면? 축하드립니다! 🥳
당신은 '공식적인' 타입스크립트 개발자입니다.
아마 이런 경험들을 하셨겠죠:
- 아무도 안 볼 때
any를 추가했습니다. - 결국 타입스크립트가 옳았음에도 불구하고 한참을 싸웠습니다.
- 새로운 기능을 개발하는 것보다 타입을 고치는 데 더 많은 시간을 보냈습니다.
- 빨간 밑줄이 드디어 사라졌을 때 환호성을 질렀습니다.
그리고 이 모든 불평불만에도 불구하고...
당신은 사실 타입스크립트를 몰래 사랑하고 있습니다.
충분한 프로젝트를 경험하다 보면 깨닫게 되거든요.
타입스크립트는 우리의 하루를 망치려 하는 게 아닙니다.
미래의 우리 자신이 하루를 망치는 것을 막아주려 하는 거죠! 😄
💬 당신의 차례입니다!
당신이 겪었던 가장 '타입스크립트 개발자스러운' 순간은 무엇이었나요?
저의 경험을 하나 꼽자면, 속성이 딱 두 개인 객체를 위해 30분 동안 아름다운 타입을 만들었던 때입니다 😅 (결국 interface로 간단히 할 수 있었는데 말이죠!)
이 글이 도움이 되셨기를 바랍니다! ❤️ 더 많은 콘텐츠를 원하시면 팔로우해주세요. Hadil Ben Abdallah 님이 💙를 담아 작성했습니다.
{% embed https://dev.to/hadil %}
원문: https://dev.to/hadil/youre-a-real-typescript-developer-only-if-1d9o 수집일: 2026-06-09 01:52:04