TypeScript의 승리. 그 결과 우리가 얻은 것들.
논쟁은 끝났습니다. 개발자들은 더 이상 TypeScript 사용 여부를 두고 다투지 않습니다. 새로운 프론트엔드 프로젝트들은 기본적으로 TypeScript를 사용합니다.
원래의 주장은 앱이 충돌하기 전에 오타를 잡아내는 것이었습니다. 하지만 그것이 진짜 이점은 아닙니다. 진짜 가치는 훨씬 더 깊은 곳에 있습니다.
TypeScript는 결코 낡지 않는 문서를 만들어냅니다. 함수 시그니처는 함수에 무엇이 필요하고 무엇을 반환하는지 정확히 알려줍니다. 타입에 새로운 옵션을 추가하면, 컴파일러는 코드를 업데이트해야 하는 모든 위치를 보여줍니다. 주석은 그저 그 자리에 남아 당신에게 거짓말을 할 뿐입니다.
리팩터링이 안전해집니다. 타입이 없는 코드에서 필드 이름을 바꾸는 것은 도박처럼 느껴집니다. 문자열을 검색하며 운에 맡겨야 하죠. TypeScript에서는 타입을 변경하기만 하면 컴파일러가 깨진 모든 줄을 할 일 목록으로 제공합니다. 이제 코드베이스를 두려워할 필요가 없습니다.
타입은 AI를 활용하는 데에도 도움이 됩니다.
JavaScript에서 코드를 추측하는 AI 도구는 위험합니다. 프로덕션 에러를 유발하는 실수를 저지를 수 있기 때문입니다. TypeScript에서 타입은 명세(spec) 역할을 합니다. AI는 무엇이 허용되는지 알게 됩니다. AI가 실수를 하더라도 컴파일러가 즉시 잡아냅니다. 타입은 "그럴듯한 코드"를 "정확한 코드"로 바꿔줍니다.
사람들은 타입이 작업 속도를 늦춘다고 말하곤 했습니다. 하지만 AI 시대에는 타입이 속도를 높여줍니다. 타입은 가드레일 역할을 합니다. 모든 줄을 일일이 손으로 확인할 필요 없이, 생성된 코드를 확신을 가지고 받아들일 수 있습니다.
더 나은 타입을 작성하기 위한 규칙:
- 여러 개의 불리언(boolean) 대신 유니온(union)을 사용하세요.
"loading" | "error" | "ready"와 같은 상태는 불가능한 상태를 방지합니다. - 도메인 타입을 명명하세요.
"type Cents = number"를 사용하면 의도가 명확해집니다. "any"를 피하세요. 대신"unknown"을 사용하고 타입을 좁혀나가세요(narrow down)."any"는 안전망을 무너뜨립니다.- 타입 추론(inference)을 활용하세요. 모든 것에 타입을 명시할 필요는 없습니다. 함수 시그니처와 내보낸(exported) API에만 타입을 명시하고, 나머지는 흐름에 맡기세요.
TypeScript는 단순히 오타를 잡아내는 것에 그치지 않았습니다. 코드베이스를 강제된 계약(enforced contracts)의 시스템으로 탈바꿈시켰습니다. 이러한 계약 덕분에 두려움 없는 리팩터링과 신뢰할 수 있는 AI 도구가 가능해졌습니다.
우리는 버그를 막기 위해 타입을 사용하기 시작했습니다. 하지만 우리가 타입을 계속 사용하는 이유는 그것이 다른 모든 것의 토대이기 때문입니다.
출처: https://dev.to/parsajiravand/typescript-won-heres-what-that-actually-bought-us-53lo