진정한 타입스크립트 개발자라면 이런 경험쯤은 해봤을 겁니다 (feat. 애증의 TS)

몇 달 전, 개발자 커뮤니티를 뜨겁게 달궜던 포스팅 당신이 진짜 자바스크립트 개발자라면 이런 경험쯤은...을 기억하시나요? 솔직히 그냥 재미 삼아 올렸던 글인데, 그렇게 많은 개발자분들이 공감해 주실 줄은 저도 예상하지 못했습니다 😅.

댓글들을 보면, 우리 모두 비슷한 혼돈의 카오스를 겪어왔다는 걸 알 수 있죠.

정체불명의 버그
뜬금없는 npm 대참사
console.log 신공 디버깅
어떻게든 돌아가는데 아무도 원리를 모르는 코드

그러다 최근, @sylwia-lask 님의 진정한 소프트웨어 개발자라면 이런 경험쯤은...이라는 재미있는 글을 접하게 되었습니다. 읽는 내내 고개를 끄덕일 수밖에 없었죠.

단순히 웃겨서 좋았던 게 아닙니다. 이 글이 개발자 커뮤니티에 대해 제가 가장 좋아하는 점 중 하나를 떠올리게 해줬거든요. 우리는 저마다 다른 기술 스택을 사용하고, 다른 업무를 하며, 각기 다른 수준의 경험을 가지고 있죠. 그런데도 어찌 된 일인지, 똑같은 이야기들을 계속해서 수집하게 됩니다 😄. 제가 실무에서 헤매던 시절, '아니 이 혼란이 나만의 것이 아니었구나!' 하며 안도했던 기억이 선명합니다.

그래서 자바스크립트와 실비아의 소프트웨어 개발자 에디션에 이어, 이 유쾌한 전통을 이어가는 것이 마땅하다고 생각했습니다.

이번에는 우리 스스로의 실수로부터 우리를 보호하는 데 절반의 시간을 보내는 언어, 바로 타입스크립트에 대해 이야기해볼까요?

TypeScript developer girl image

자, 당신이 진정한 타입스크립트 개발자라면 이런 경험쯤은 해봤을 겁니다...

🔷 타입스크립트와 첫 대면, 그 현실 체크

JavaScript 프로젝트를 TypeScript로 전환하며 "한 시간이면 충분하겠지!" 생각했던 당신, 3일 뒤에도 타입 에러와 씨름하고 있을 겁니다.

에러를 없애기 위해 any를 추가했죠.

그리고는 "나중에 꼭 돌아와서 수정해야지!"라고 스스로에게 약속했지만... 당신은 절대 돌아오지 않았습니다.

타입스크립트 에러 하나를 고쳤는데...

새로운 에러 12개가 뿅 하고 나타나는 마법을 경험했죠. 마치 어떤 달성 시스템처럼요.

타입 에러를 20분 동안 노려보며 생각했습니다.

"나는 내가 뭘 의미하는지 아는데. 왜 타입스크립트는 내가 뭘 의미하는지 모를까?"

결국 이렇게 작성하고 말았습니다.

as any

그리고는 약간의 부끄러움을 느꼈죠.

🤝🏻 이 미묘한 애증의 관계

하루 종일 타입스크립트를 향해 불평을 쏟아냈지만...

막상 순수 JavaScript 프로젝트를 만나면 길 잃은 어린 양처럼 헤매게 되죠.

"간단하게 만들자"며 타입 어노테이션을 제거했습니다.

타입스크립트는 강력하게 반대했고요.

실제 비즈니스 로직을 작성하는 시간보다 타입을 설계하는 데 더 많은 시간을 보냈습니다.

어떤 제네릭 타입을 보고는 생각했습니다.

"와, 이 명작은 누가 만들었지?"

그러다 6개월 전의 내가 작성한 코드임을 깨달았죠. 이 묘한 기분이란... 아마 저뿐만은 아닐 겁니다.

다른 제네릭 타입을 보고는 또 생각했습니다.

"젠장, 이 악몽은 또 누가 만들었지?"

이 또한 당신이었습니다.

인생이 복잡한 만큼, 타입도 복잡하게 선언했습니다.

string | number | null | undefined

🧠 이제는 베테랑 개발자의 순간들

어떤 파일을 열었는데, 이런 코드를 발견했습니다.

type Result<T extends keyof U, U extends object>

그리고는 즉시 파일을 닫아버렸죠.

한 시간을 타입스크립트와 싸웠지만...

결국 타입스크립트가 옳았다는 사실을 깨달았습니다.

드디어 IDE에서 빨간 밑줄들이 사라졌을 때, 당신은 환호성을 질렀을 겁니다.

한 곳에서 속성 이름을 변경했는데...

타입스크립트 덕분에 20개의 파일이 박살 나는 것을 막았습니다. 그 짧은 순간만큼은 진심으로 감사함을 느꼈을 거예요.

프로젝트에 strict mode를 추가했습니다.

그리고는 발견하지 말았어야 할 것들을 발견했죠. 저도 strict mode를 도입하며 '클린 코드'를 외쳤던 적이 있는데, 마치 판도라의 상자를 연 듯 숨겨진 문제점들이 쏟아져 나와 한동안 밤샘 작업을 했던 기억이 나네요.

자동 완성 기능을 너무 많이 사용해서, 이제는 속성 이름을 전부 입력하는 것이 어색하게 느껴집니다.

🚨 위기의 순간, 비상 해결책

이렇게 작성하고 '아무도 못 보겠지?'라며 슬며시 커밋한 당신.

// @ts-ignore

미래의 자신조차 이해하려면 문서가 필요할 정도로 복잡한 타입을 작성했습니다.

타입스크립트 에러를 구글에 복사해서 붙여 넣었습니다.

그런데 그 답변에는 원래 에러보다 더 많은 타입스크립트 내용이 담겨있어 더 혼란스러웠죠. 이건 정말 국룰이죠!

같은 디버깅 세션 중에 이렇게 말했습니다.

"타입은 맞아. 코드가 틀렸어."

그리고 또 이렇게 말했죠.

"코드는 맞아. 타입이 틀렸어."

마침내 버그를 고쳤는데...

타입스크립트가 이틀 전에 그 버그에 대해 경고했다는 사실을 깨달았습니다.

🎯 그래서, 당신은 공식적인 타입스크립트 개발자?

이 목록을 읽으면서 연신 고개를 끄덕였다면, 축하합니다! 🥳 당신은 진정한 타입스크립트 개발자입니다.

아마 당신은 다음과 같은 경험들을 해봤을 겁니다.

아무도 보지 않을 때 any를 추가했습니다.
결국 타입스크립트가 옳았다는 걸 깨달으며 타입과 논쟁했습니다.
기능을 작성하는 시간보다 타입을 고치는 데 더 많은 시간을 보냈습니다.
빨간 밑줄이 드디어 사라졌을 때 환호했습니다.

그리고 모든 불평에도 불구하고...

우리는 타입스크립트를 은밀하게 사랑하고 있습니다.

충분한 프로젝트를 경험하다 보면 깨닫게 되죠.

타입스크립트는 우리를 괴롭히려는 게 아닙니다.

미래의 우리 자신으로부터 우리를 지켜주려는 든든한 방패 역할을 하는 거죠 😄. 제가 실무에서 겪어보니, 타입스크립트 덕분에 대규모 리팩토링이나 팀원 간 협업 시 생길 수 있는 치명적인 오류를 사전에 막았던 경험이 한두 번이 아니거든요. 그 순간만큼은 진심으로 고맙게 느껴집니다.

💬 여러분은 어떠신가요?

당신이 경험한 가장 "타입스크립트 개발자"스러운 순간은 무엇이었나요?

저는 딱 두 개의 속성만 가진 객체를 위해 30분 동안 아름다운 타입을 만들었던 경험에 한 표 던지겠습니다 😅.

| 읽어주셔서 감사합니다! 🙏🏻 <br/> 도움이 되셨기를 바랍니다 ✅ <br/> 더 많은 글을 위해 반응과 팔로우 부탁드립니다 😍 <br/> Hadil Ben Abdallah 님이 💙로 만들었습니다 | | |---------|----------|---------|

{% embed https://dev.to/hadil %}

원문: https://dev.to/hadil/youre-a-real-typescript-developer-only-if-1d9o 수집일: 2026-06-10 02:03:03