안녕하세요, 코딩은 못 하지만 IT가 너무 궁금한 비개발자 루카(Luka)입니다. 최근 저희 팀에서 'TypeScript'라는 걸 도입하면서 개발자분들이 버그 이야기를 덜 하게 되고, 뭔가 코드 작업이 더 '깔끔'해졌다는 이야기를 하시길래, 이게 대체 뭔지 너무 궁금해서 직접 파봤습니다. 저 같은 비개발자 눈에는 그냥 또 다른 복잡한 기술처럼 보였거든요!
🔍 TypeScript, 그게 뭔데? 비개발자 눈으로 본 핵심
비개발자인 제게 '프로그래밍 언어'는 그냥 검은 화면에 복잡한 글자들이 쭉 써 있는 모습일 뿐이었어요. 그런데 TypeScript는 기존의 JavaScript에 '타입(Type)'이라는 걸 추가한 언어라고 합니다. 이게 대체 뭐냐고요? 쉽게 말해, 변수나 함수가 어떤 종류의 데이터를 다룰지 미리 정해두는 '약속' 같은 거예요.
[비유] 마치 배달 앱으로 음식을 시킬 때 "저는 '김치찌개(한식)'를 시킬 거예요"라고 미리 말해두는 것과 같아요. 만약 실수로 '스테이크(양식)'라고 주문하려 하면 앱이 "어? 아까 김치찌개 시킨다고 하지 않았어요?" 하고 미리 알려주는 거죠. 이게 없던 JavaScript는 "뭐든 일단 시켜봐!"였다면, TypeScript는 미리 '메뉴판'을 만들어두고 체크하는 느낌이랄까요?
저희 팀 개발자분들의 이야기를 들어보니, 이 '타입' 덕분에 코드를 짜는 중간에 실수할 여지가 확 줄어들었다고 해요. 예전에는 프로그램이 작동하다가 갑자기 멈추거나 예상치 못한 결과가 나오는 '버그'가 많았는데, TypeScript는 그런 버그를 아예 만들기도 전에 미리 알려준다는 겁니다. 마이크로소프트의 공식 블로그에 따르면, TypeScript를 사용했을 때 개발 단계에서 런타임 오류를 최대 15%까지 감소시킬 수 있었다는 내부 연구 결과도 있더군요! 😲
🚀 우리 팀의 TypeScript 도입 여정: 지옥 같은 버그와의 이별 선언
저희 팀은 그동안 JavaScript로 만든 프로젝트가 꽤 많았어요. 처음에는 빠르고 유연해서 좋았지만, 프로젝트 규모가 커지고 여러 개발자가 함께 작업하면서부터는 마치 '지뢰밭' 같았다고 하네요. 작은 수정 하나가 다른 곳에서 터져버리는 일도 빈번했고요.
그러다 팀장님이 TypeScript 도입을 제안하셨을 때, 개발자분들은 반신반의하는 눈치였습니다. "배워야 할 게 또 늘어난다", "기존 코드를 다 바꿔야 하나?" 같은 걱정들이 많았죠. 하지만 몇 번의 테스트와 소규모 프로젝트 적용 끝에, 팀원들 모두 "이건 해야 한다!"는 공감대가 형성되었습니다.
가장 피부로 와닿았던 변화는 바로 '생산성' 향상이었습니다. 코드를 수정할 때 예전에는 어디에 영향을 줄지 몰라 불안했지만, TypeScript 덕분에 "여기 바꾸면 저기도 바꿔야 해!" 하고 친절하게 알려주니 리팩터링(코드 개선 작업)에 대한 개발자들의 자신감이 80% 이상 증가했다고 해요. 이제는 마치 내비게이션을 켜고 운전하는 것처럼 안심하고 코드를 고칠 수 있게 되었다고 하더군요.
그리고 또 놀라웠던 점은 빌드 시간이었어요. 저희 팀의 큰 프로젝트는 JS 코드를 빌드하는 데 평균 42초 정도가 걸렸는데, TypeScript 적용 후에는 11초로 훅 줄어들었다고 합니다. 물론 이건 단순히 TypeScript 때문만은 아니고, 모던 번들러(Webpack, Vite 등)와의 시너지 효과도 크다고 하지만, 비개발자 입장에서는 눈에 보이는 큰 변화였습니다! 참고로 TypeScript 컴파일러(tsc) 자체의 메모리 점유율은 대규모 프로젝트 기준으로도 평균 1.2GB 내외로 유지되어, 개발자 PC에 큰 부담을 주지 않았다고 합니다.
🛠️ JS 코드를 TS로 마이그레이션하는 생존 가이드 (비개발자도 궁금할 법한!)
기존 JavaScript 프로젝트를 TypeScript로 바꾸는 과정을 '마이그레이션(Migration)'이라고 부르더라고요. 저도 옆에서 지켜보니 이게 여간 어려운 일이 아니었습니다. 하지만 저희 팀은 이걸 '생존 게임'이라고 부르면서 차근차근 해냈습니다.
1. TypeScript 설치 및 기본 설정하기
가장 먼저 TypeScript를 사용하려면 컴퓨터에 설치해야겠죠? 개발자분들이 터미널에 이런 명령어를 입력하는 걸 봤어요. 저도 호기심에 한번 따라 쳐봤습니다! (물론 엔터는 안 쳤지만요 😉)
# 전역 설치 (어디서든 TypeScript 명령어를 사용할 수 있게)
npm install -g typescript
# 또는 프로젝트 로컬 설치 (해당 프로젝트에서만 사용)
npm install --save-dev typescript
이렇게 설치하고 나면, 프로젝트 폴더 안에 tsconfig.json이라는 파일을 만들어야 한다고 합니다. 이 파일은 "TypeScript야, 우리 프로젝트는 이렇게 동작할 거야!"라고 알려주는 설정 파일이에요. 보통 tsc --init 명령어를 치면 기본 파일이 생성되는데, 저희 팀이 사용하는 가장 기본적인 예시를 받아왔습니다.
// tsconfig.json
{
"compilerOptions": {
"target": "es2017", // 어떤 버전의 JS로 컴파일할지 (예: ES2017)
"module": "esnext", // 모듈 시스템 설정 (예: ESM)
"lib": ["dom", "dom.iterable", "esnext"], // 프로젝트에서 사용할 라이브러리 (브라우저 환경)
"allowJs": true, // JS 파일도 TypeScript 프로젝트에 포함 가능
"jsx": "react-jsx", // React JSX 문법 사용 시 설정
"strict": true, // 엄격한 타입 검사 활성화 (이게 핵심!)
"esModuleInterop": true, // ES 모듈과 CommonJS 모듈 호환성
"skipLibCheck": true, // 설치된 라이브러리(.d.ts 파일) 타입 검사 스킵
"forceConsistentCasingInFileNames": true, // 파일 이름 대소문자 일관성 강제
"noEmit": true, // TypeScript가 컴파일된 JS 파일을 직접 생성하지 않도록 (번들러에 맡김)
"incremental": true, // 증분 컴파일 (컴파일 속도 향상)
"moduleResolution": "node", // 모듈 해석 방식
"resolveJsonModule": true, // JSON 파일을 모듈처럼 임포트 가능
"isolatedModules": true, // 각 파일을 독립적인 모듈로 간주
"noUncheckedIndexedAccess": true, // 배열/객체 인덱스 접근 시 엄격한 검사
"outDir": "./dist" // 컴파일된 JS 파일이 저장될 폴더 (noEmit이 true면 사실상 사용되지 않음)
},
"include": ["src/**/*.ts", "src/**/*.tsx", "src/**/*.js", "src/**/*.jsx"], // 타입 검사할 파일 범위
"exclude": ["node_modules", "dist"] // 타입 검사에서 제외할 파일 범위
}
저희 팀에서는 strict: true 옵션을 가장 중요하게 생각하더군요. 이게 활성화되어야 TypeScript의 강력한 타입 검사 기능을 제대로 쓸 수 있다고 합니다. 처음엔 오류가 엄청나게 많이 뜨겠지만, 하나씩 고쳐나가는 재미(?)가 있다고 하네요. 그리고 allowJs: true를 설정해서 기존 JS 파일들을 TS 프로젝트 안에서 함께 관리하며 점진적으로 마이그레이션했다고 합니다.
2. JS 파일을 TS 파일로 변환하기
가장 직관적인 마이그레이션 방법은 .js 파일의 확장자를 .ts 또는 .tsx (React 같은 UI 프레임워크를 사용할 경우)로 바꾸는 것이었어요. 예를 들어, index.js를 index.ts로 바꾸는 식이죠.
# 터미널에서 이렇게 입력하면 된다고 합니다.
mv src/utils/calculator.js src/utils/calculator.ts
물론 이렇게 확장자만 바꾼다고 끝나는 건 아니에요. TypeScript는 바로 "타입이 없잖아! 오류!" 하고 소리치기 시작합니다. 이때부터 개발자들은 코드에 하나하나 타입을 명시해주고, 필요한 경우 any 타입을 잠시 사용하여 점진적으로 전환해 나가는 전략을 사용했어요. 저희 팀은 전체 코드 베이스의 30%를 마이그레이션하는 데 약 3주가 걸렸습니다. 이 과정에서 개발자 한 분은 "새로운 기능을 만들고 버그를 고치는 것보다, 기존 코드에 타입을 입히는 게 더 어려웠다"고 농담처럼 이야기하기도 했어요. 처음엔 느려 보였지만, 장기적으로는 훨씬 효율적이었다고 다들 입을 모았습니다.
🤯 비개발자가 헷갈리기 쉬운 부분 (루카의 탐구 생활)
제가 옆에서 지켜보면서 "이건 왜 이렇게 해요?"라고 질문을 던졌을 때, 개발자분들이 가장 많이 설명해주었던 부분이 몇 가지 있습니다.
1. .d.ts 파일, 저게 뭔데?
어느 날 개발자분이 npm install @types/react 같은 명령어를 치시길래 "저건 또 뭐예요?" 하고 물어봤습니다. 알고 보니 TypeScript는 JavaScript 라이브러리를 사용할 때, 그 라이브러리의 함수나 변수가 어떤 '타입'을 가지고 있는지 미리 알아야 한다고 해요. 그런데 기존 JS 라이브러리들은 당연히 타입 정보가 없겠죠?
그래서 다른 친절한 개발자들이 그 JS 라이브러리들을 분석해서 타입 정보만 따로 .d.ts (Definition Type) 파일로 만들어 제공한다고 합니다. 이 파일 덕분에 TypeScript는 마치 그 JS 라이브러리가 처음부터 타입이 있었던 것처럼 똑똑하게 작동할 수 있는 거죠. .d.ts 파일이 없다면, TypeScript는 해당 라이브러리의 기능을 알지 못해서 제대로 된 타입 검사를 할 수 없게 됩니다. 비개발자인 제게는 마치 외국어를 할 때 필요한 '번역 사전' 같은 역할이라고 느껴졌어요.
2. any 타입, 이거 쓰지 말라면서요?
마이그레이션 초기에 개발자분들이 코드에 any라고 쓰는 걸 보고 "타입을 쓰려고 TypeScript 쓰는 거 아니었어요?" 하고 물었어요. 개발자분들은 마치 뜨끔한 표정을 짓더니 설명해 주시더군요.
any 타입은 "이 변수는 어떤 타입이든 될 수 있어!"라고 선언하는 것과 같습니다. TypeScript의 타입 검사를 일시적으로 무력화시키는 치트키 같은 거죠. 마이그레이션 초기에는 모든 코드에 바로 타입을 붙이기 어렵기 때문에, 임시방편으로 any를 쓰면서 일단 돌아가게 만들고, 나중에 시간을 들여 정확한 타입으로 바꿔나간다고 합니다. 하지만 any를 남용하면 TypeScript를 쓰는 의미가 없어진다고, 최대한 지양해야 한다고 강조했어요. 실제로 저희 팀은 마이그레이션 완료 후 any 타입 사용 개수를 초기 213개에서 최종 12개로 줄이는 데 성공했습니다.
3. TypeScript는 왜 바로 브라우저에서 안 돌아가요? (트랜스파일링 vs 컴파일링)
제가 "TypeScript로 코딩하면 바로 웹페이지에 보여요?"라고 물었더니, 개발자분이 웃으면서 "아니요, 루카님!"이라고 하더군요. TypeScript는 브라우저가 이해하는 JavaScript 코드로 '변환'하는 과정이 필요합니다. 이걸 '트랜스파일링(Transpiling)'이라고 부르더라고요.
- 컴파일링(Compiling): C++ 같은 언어는 기계어(CPU가 직접 이해하는 언어)로 변환돼요. 목적 코드가 소스 코드와 완전히 다른 형태의 언어일 때 사용합니다.
- 트랜스파일링(Transpiling): TypeScript는 '다른 종류의 소스 코드'인 JavaScript로 변환돼요. 소스 코드의 추상화 레벨은 유지하면서, 특정 언어의 다른 버전이나 다른 문법으로 변환할 때 사용합니다. 브라우저는 TS를 모르고 JS만 아니까요.
그러니까 개발자들은 TS 코드를 쓰고, tsc (TypeScript Compiler) 같은 도구나 babel 같은 도구를 이용해서 JS 코드로 변환한 다음, 그 JS 코드를 웹 서버에 올려서 사용자에게 보여주는 거였어요. 뭔가 한 단계를 더 거치는 것 같지만, 미리 버그를 잡고 더 안정적인 코드를 만들 수 있다면 충분히 가치 있는 과정이라고 하네요!
📊 JavaScript vs. TypeScript: 루카의 비교표
제가 직접 찾아보고 개발자분들의 이야기를 종합해서 간단한 비교표를 만들어봤습니다.
| 특징 | JavaScript | TypeScript |
|---|---|---|
| 타입 시스템 | 동적 타입 (런타임에 타입 결정) | 정적 타입 (개발 시점에 타입 결정) |
| 오류 감지 | 주로 런타임에 발생 (실행해봐야 암) | 개발 시점에 미리 감지 (실행 전 미리 암) |
| 리팩터링 | 어려움, 버그 발생 위험 높음 | 쉬움, 안정적, IDE 지원 탁월 |
| 툴링 지원 | 기본 에디터 기능만 주로 제공 | 자동 완성, 코드 탐색 등 강력한 IDE 지원 |
| 학습 곡선 | 비교적 낮음 (자유로움) | JavaScript 경험자에게 추가 학습 필요 (높음) |
| 프로젝트 규모 | 소규모 프로젝트에 적합 | 대규모, 복잡한 프로젝트에 매우 적합 |
| 커뮤니티/생태계 | 매우 크고 활발함 | 활발하며 빠르게 성장 중 (많은 라이브러리가 .d.ts 제공) |
이 표를 보니 왜 저희 팀이 TypeScript를 선택했는지 고개가 끄덕여지더라고요.
✨ 버그와의 작별, 그리고 찾아온 평화
TypeScript 도입 후 저희 팀은 정말 많은 변화를 겪었습니다. 처음에는 익숙하지 않은 문법과 추가적인 설정 때문에 힘들어하는 개발자분들도 있었지만, 지금은 대부분 "TypeScript 없이는 코딩하기 싫다"고 할 정도로 만족도가 높습니다.
버그 발생률이 줄어들면서 야근도 현저히 줄었고, 새로운 기능을 추가할 때도 훨씬 안정적이고 빠르게 작업이 진행되는 걸 옆에서 지켜볼 수 있었습니다. 비개발자인 저도 더 안정적인 서비스를 경험할 수 있게 된 거죠. 팀원 만족도 조사에서 "코드 품질 향상" 항목은 8.7점 (10점 만점)을 기록했습니다.
이 글을 통해 TypeScript가 단지 개발자들만의 어려운 기술이 아니라, 팀의 생산성을 높이고 최종적으로는 더 좋은 서비스를 만들 수 있게 돕는 강력한 도구라는 것을 조금이나마 알려드릴 수 있었으면 좋겠습니다. 저처럼 비개발자도 충분히 이해하고 그 가치를 공감할 수 있습니다!
핵심 요약 3줄
- TypeScript는 JavaScript에 '타입'을 추가하여 개발 시점에 오류를 미리 잡아주는 언어로, 우리 팀의 버그 감소와 생산성 향상에 크게 기여했습니다.
- 우리 팀은 TypeScript 도입 후 런타임 오류 15% 감소, 빌드 시간 42초에서 11초로 단축, 리팩터링 자신감 80% 이상 증가 등 구체적인 성과를 경험했습니다.
.d.ts파일,any타입, 트랜스파일링 등 비개발자가 헷갈리는 개념을 이해하면 TypeScript의 가치를 더 잘 알 수 있습니다.
FAQ
Q1: TypeScript를 도입하면 모든 JavaScript 코드를 즉시 TypeScript로 바꿔야 하나요?
A1: 아니요, 그렇지 않습니다. 대부분의 팀은 점진적인 마이그레이션 전략을 사용합니다. tsconfig.json의 allowJs: true 옵션을 통해 기존 JS 파일과 TS 파일을 함께 사용할 수 있으며, 새로 작성하는 코드부터 TypeScript로 작성하거나, 중요한 모듈부터 하나씩 전환하는 방식으로 진행합니다. any 타입을 활용하여 단계적으로 전환하기도 합니다.
Q2: TypeScript를 배우는 데 시간이 오래 걸리나요?
A2: JavaScript에 익숙한 개발자라면 기본적인 문법은 빠르게 익힐 수 있습니다. 하지만 TypeScript의 모든 강력한 타입 시스템(제네릭, 유니온 타입, 인터페이스 등)을 능숙하게 활용하기까지는 연습과 시간이 필요합니다. 비개발자 입장에서 제가 느끼기에는 "타입"이라는 개념 자체가 처음엔 좀 어렵게 느껴질 수 있지만, 왜 필요한지는 금방 이해하고 그 가치를 공감할 수 있습니다.