[TypeScript] 타입 한 줄로 552개 파일을 2주 만에 안전하게 수정한 방법
"회원 구조가 바뀌어서 552개 파일을 수정해야 합니다."
보통이라면 야근과 버그, 회귀 테스트의 늪에 빠질 이 상황. 하지만 우리는 2주 만에, 사이드 이펙트 0건으로 끝냈습니다. 비결은
1년 전 작성해둔 type ProfileId = string; 이 한 줄 덕분이었습니다.
🔑 왜 가능했을까?
단순히 string을 쓰는 대신 도메인 의미를 담은 타입(Type Alias)을 사용했기 때문입니다.
-
변경 추적: ProfileId 타입을 ProfileId | undefined로 바꾸는 순간, 컴파일러가 수정이 필요한 552곳을 정확히 찾아냈습니다.
-
문서화: 변수명이나 주석 없이도 타입 자체가 코드의 의도를 설명해 주었습니다.
🛡️ 타입 시스템이 QA가 되다
단순한 에러 방지를 넘어, 코드에 의미를 부여하고 대규모 변경을 안전하게 가이드하는 설계 도구로서의 TypeScript 활용법을
공유합니다.👉 [전체 읽기: 타입 한 줄로 552개 파일을 2주 만에 안전하게 수정한 방법]
🔗 https://blog.sangwook.dev/posts/typescript-project-type-safe-refactor-with-typescript
(https://blog.sangwook.dev/posts/typescript-project-type-safe-refactor-with-typescript)
17개의 댓글
와 정말 멋진 경험인 것 같아요..! 다른 사람이 개발한 레거시 리팩토링을 앞두고 있는데, 도움이 많이 될 것 같습니다. 감사합니다 :)
TS 는 type ProfileId = string 과 string 을 구분하지 못합니다. 그래서 이 코드는 타입 안정성 보다는, 코드를 읽는 사람으로 하여금 명확하게 인지를 시켜주는 용도 정도의 의미를 가진다고 생각합니다. (물론 대규모 마이그레이션이 발생하는 경우에도 효과적인 방법입니다.)
만약 ProfileId 의 타입 시그니쳐가 string 에서 string | number 로 변경되는 상황이라면, string 으로 선언된 N개의 파일을 수정하는게 아닌, ProfileId 타입 정의 한 곳과 그 타입을 사용하는 부분만 수정하면 글에서 설명하는 의도대로 정리가 될겁니다.
이건 타입뿐 아니라 코드 레벨에서도 동일하게 적용이 되는데요, 예를 들어서 어떤 데이터를 조회하는 로직이 여러곳에 흩어져 있다면 모든 호출부를 수정해야 하지만, 한 곳에서만 관리되도록 잘 래핑되어 있다면 그 한곳만 수정하면 됩니다.
그래서 글에서 핵심은 타입 별칭의 효과보다는, 프로필 ID 조회 로직이 한 곳에서 잘 관리되어 있었기 때문에 마이그레이션이 안전하게 끝날 수 있었다가 아닐까.. 하는 의견을 남겨봅니다 ㅎㅎ 잘 읽었습니다.
Profile 타입을 따로 만들고 Profile['id']를 하던가 Pick<Profile,"id">가 더 좋아보이긴해요.
Profile이 id만 갖고 있지않으니까요
"코드에 의미 계층을 추가한 것" 이 TS 뿐 아니라 대부분의 규모있는 프로젝트에서 정말 큰 차이를 만든다고 생각되네요,, 마음이 편해지는 글 잘 읽었습니다 🙏🙇🏻♂️
어디를 수정해야 하는지 찾느라 1주
...
결국 한 달...
얼마전 저를 보는 것 같네요 ㅠㅠ 다음에 개선할 때는 한번 적용해봐야겠습니다 감사합니다..!
좋은 글 감사합니다!
이펙티브 타입스크립트라는 책을 읽으면서 보통 명확하게 타입이 추론가능한 원시타입은 굳이 타입을 설정하지 않아도 괜찮다는 의견?이 있었던 거로 기억하는데, (좀 오래되긴 해서 대충 저런 뉘앙스였던 것으로 기억합니다.. 잘못 기억하고 있었다면 죄송합니다)
이 글에서 소개해주신 ProfileId 케이스의 경우처럼 타입 정의가 필요한 경우도 있겠다는 걸 알게되었네요!
처음엔 552줄인 줄 알고 읽다가 552개 파일이라는 걸 보고 깜짝 놀랐네요. 저라면 벌써 어디서부터 손대야 할지 몰라 막막했을 것 같은데, 타입 설계 단계에서 이미 해결의 실마리를 만들어두셨던 거군요. 개발할 때 자주 하던 말이 '업보청산'이었는데, 이번 글은 과거의 누군가에게 고마워해야하는 경험인 것 같네요 ㅋㅋ 좋은 글 감사합니다!
코드 자체가 문서가 된다는 말에 공감했습니다. 보통 문서는 업데이트를 지속적으로 하지 않으면 결국 못쓰게 되는데 코드 자체가 문서 역할을 하도록 만들면 항상 유지될 수 밖에 없어서 좋은 것 같습니다.
좋은 글 감사합니다! 제 프로젝트에도 적용할 점이 있는지 확인해봐야 겠네요!