TypeScript의 승리. 그 결과 우리가 얻은 것들.
논쟁은 끝났습니다. 대부분의 새로운 프론트엔드 프로젝트는 기본적으로 TypeScript를 사용합니다. 이제 사람들은 TypeScript를 도입할지 말지를 두고 더 이상 다투지 않습니다.
진정한 가치는 단순히 오타를 잡아내는 데 있지 않습니다. 그 가치는 처음 제시되었던 명분보다 훨씬 더 깊습니다.
타입은 결코 낡지 않는 문서를 제공합니다. 함수 시그니처는 코드 조각이 무엇을 필요로 하고 무엇을 반환하는지 정확히 알려줍니다. 개발자가 유니온 타입(union type)에 새로운 옵션을 추가하면, 컴파일러는 코드의 모든 부분을 업데이트하도록 강제합니다. 주석은 낡아버리지만, 타입은 그렇지 않습니다.
리팩터링은 두려운 작업에서 안전한 작업으로 변합니다. 타입이 없는 코드에서 필드 이름을 바꾸는 것은 도박처럼 느껴집니다. TypeScript에서는 타입을 변경하기만 하면 컴파일러가 오류가 발생한 모든 줄의 목록을 보여줍니다. 덕분에 오래된 코드를 건드리는 것에 대한 두려움이 사라집니다.
타입은 AI와의 협업 능력도 향상시킵니다.
AI에게 타입이 없는 JavaScript를 수정해 달라고 요청하면, AI는 구조를 추측합니다. 이 과정에서 발생하는 실수는 운영 환경의 오류로 이어집니다. TypeScript에서 타입은 명세(specification) 역할을 합니다. AI는 규칙을 알게 됩니다. AI가 실수를 하더라도 컴파일러가 즉시 잡아냅니다. 타입은 "그럴듯한 코드"를 "검증된 코드"로 바꿔줍니다.
타입은 작업 속도를 늦추지 않습니다. 오히려 AI 워크플로우에서는 속도를 높여줍니다. 타입은 가드레일 역할을 하여, 모든 줄을 일일이 수동으로 확인하지 않고도 생성된 코드를 신뢰할 수 있게 해줍니다.
의도를 가지고 타입을 작성하세요:
• 여러 개의 불리언(boolean) 대신 유니온(union)을 사용하세요. "loading" | "error" | "ready"와 같은 상태 값은 불가능한 상태를 방지합니다.
• 도메인 타입을 명명하세요. "type Cents = number"와 같이 작성하면 의도가 명확해집니다.
• "any"를 피하세요. 대신 "unknown"을 사용하고 타입을 좁혀(narrowing) 나가세요. "any"는 안전망을 파괴합니다.
• 타입 추론(inference)을 활용하세요. 모든 것에 타입을 붙일 필요는 없습니다. 함수의 시그니처와 내보낸(exported) API에만 타입을 지정하고, 나머지는 추론에 맡기세요.
TypeScript는 코드베이스를 강제된 계약(contract)의 집합으로 바꾸어 놓았습니다. 이러한 계약 덕분에 두려움 없는 리팩터링과 신뢰할 수 있는 AI 지원이 가능해졌습니다.
우리는 버그를 막기 위해 타입을 사용하기 시작했습니다. 그리고 그 타입이 다른 모든 것의 토대가 되기 때문에 계속해서 사용하고 있습니다.
출처: https://dev.to/parsajiravand/typescript-won-heres-what-that-actually-bought-us-12m8