안녕하세요, 요즘은 WebRTC를 이용한 Peer to Peer(P2P)를 공부하고 있습니다. 회사에서는 TypeScript를 사용을 권장하고 있어서 “왜 TypeScript를 사용해야할까?”라는 궁금증에서 시작되어서 “TypeScript를 사용하는 이유”에 대해서 작성해 볼까 합니다!
참고로 WebRTC와 Peer to Peer(P2P)와 React, TypeScript를 통해서 개발할 때에만 사용하는 경우에 대해서 작성 되었습니다.
🤔 TypeScript의 사용에 대한 의문
회사에서 TypeScript에 사용하여서 개발해 보면 좋을 것 같다는 의견이 나오기 전에 React.js(JavaScript)를 통해서 개발할 때에는 항상 가지고 있는 의문점이었습니다. “왜 현직에서는 TypeScript를 많이 요구하고 TypeScript를 사용할까?”라는 의문점이 항상 있었습니다.
회사 채용 중 📜
kakao 프론트엔드 개발자 채용 모집 내용 중에서 찾아던 내용입니다.
배달의 민족 B마트 프론트엔드 개발자 채용 모집 내용 중에서 찾아던 내용입니다.
많은 회사들 중에서 프론트엔드 개발 분야에서 TypeScript을 사용하는 기술을사용하고 관련된 개발자 분들을 채용하고 있다는 점을 알 수 있습니다.
그 만큼 실제 서비스를 제공하고 있는 IT 회사에서도 많은 개발자들은 TypeScript를 통해서 개발하고 있다는 점이 보입니다.
🧐 TypeScript의 안정성
항상 실제로 서비스를 제공해 보면 “안정성”이라는 관점에서 개발에서 안정성이 가장 중요하다고 생각합니다.
정적 타이핑과 안정성 애기하면 항상 나오는 글이 있습니다.
The broken promise of static typing 이라는 상당히 자극적인 제목의 글이 있습니다. 링크에 있는 글은 정적/동적 타이핑 여부와 버그의 발생 빈도 사이에는 큰 관계가 없다는 결론을 엄청나게 설득력이 있는 근거와 함께 설명하고 있습니다.
TypeScript를 별로 사용하지 않았지만 결론이 제 생각과 별로 맞지 않지만 근거가 분명하게 있기 때문에 충분히 동의할 수 있습니다.
타입은 런타임에서의 에러 발생 확률을 줄여주지만, 그것이 반드시 버그 감소로 귀결되지는 않습니다.
애플리케이션의 안정성으로 이어지진 않습니다. 물론 여전히 안정성을 이유로 TypeScript를 선택하는 사람이 있지만, 제 생각은 다릅니다.
정말로 버그를 감소 시키고 줄이고 싶다면 타이핑에 만족하지 않고 테스트를 더 잘 짜는데 주력해야 한다고 생각합니다. TypeScript를 사용한다고 해서 테스를 안짜도 되는 것은 아닙니다.
리팩토링의 영향이 닿는 모든 기능을 확인하기 전에는 확신하기 어려운 JavaScript와는 달리, (타이핑을 문제없이 했다는 가정 하) TypeScript는 컴파일 타임에 어느 부분이 깨지는지 빠짐없이 알려주기 때문에 리팩토링하기 편해지고, 리팩토링에 대해서 열린 마음을 갖고 개발 하게 됩니다.
결론적으로 타입 에러를 컴파일 타임에 발견해서 얻는 이득은 런타임에서의 안정성보다는 더 좋은 개발 경험과 생산성, 그로 인해 얻게 되는 더 좋은 코드에 가깝습니다 😍
🗃 TypeScript의 생산성
정적 타이핑과 동적 타이핑의 생산성에 관한 논쟁은 옛날부터 오래된 떡밥이고 아직도 진행 중인 논쟁입니다. “타이핑 하는 게 우위이다.” 또는 “타이핑을 안 하는 게 우위다.”라고 절대적인 결론이 나지는 않았습니다.
단순히 더 많은 코들르 작성해야하니 생산성을 떨어지게 된다는 주장은 일차원적인 의견입니다, 상황과 사용자에 따라서 보다 적절한 선택이 있습니다.
본 주제에 일반적인 의견은, 동적 타이핑은 단기적으로 사용할 경우에는 큰 생산성을 보여주고 있지만 다수의 사람들이 장기적으로 유지보수 하는 경우 어려움을 느낄 가능성이 높습니다. 물론 정적 타이핑은 이 반대의 우위를 가지고 있습니다. JavaScript와 TypeScript의 관계도 마찬가지입니다. TypeScript는 장기적으로 생산성에 나은 선택이 될 가능성에 사용하는 게 좋습니다.
최근에는 JavaScript가 활용되는 영역에는 한계가 거의 없다시피 사용되고 있지만 여전히 가장 많이 사용되는 곳은 Front End 프로젝트에 사용되고 있습니다. 과거에는 웹이 Multi Page Application(MPA) 기반으로 작성되었던 것과 달리 요즘 웹 페이지는 프론트엔드 프레임워크(React, Vue, Angular) 등을 사용하는 Single Page Application(SPA)으로 작성되고 있습니다.
두 가지 타입의 웹에서는 프론트엔드에 기대하는 바도 다릅니다. 과거 MPA의 프론트엔드에서는 HTML 렌더링을 백엔드에서 했기 때문에, 단순히 AJAX 처리 후 DOM 조작을 이용한 극히 부분적 렌더링 정도만을 JavaScript로 처리했었습니다. 하지만 요즘은 SPA에서는 대부분의 HTML 렌더링을 프론트엔드에서 처리하고 있습니다. 프론트엔드가 백엔드의 역할 상당히 많이 흡수 되었습니다. HTML 렌더링, 페이지 라우팅, 일부 비즈니스 로직, 어플리케이션 상태 저장 등과 더불어 예전에는 프론트엔드를 굳이 알 필요 없었던 DB 모델링 스키마도 이제는 프론트엔드에서 당연히 알아야 하는 부분이 되어 버렸습니다.
따라서 요즘 SPA 프론트엔드 프로젝트는 과거 MPA 프로젝트보다 규모가 훨씬 커졌습니다. 더 많은 사람들이 더 오랜기간(시간) 만들고 유지보수 해야할 가능성이 아주아주 높아졌습니다. 최근의 타입스크립트의 엄청난 성장과 SPA 프로젝트가 점점 많아지고 있는 현재 트렌드와 무관하지 않다는 것이 제 생각입니다.
생산성 부분에 있어서 결론은 SPA의 코드 규모에 따라서 TypeScript 는 도움이 될 수도 있고 안 될 수도 있다는 점입니다. 하지만 프로젝트가 대규모이고 장기간 서비스를 유지보수할 가능성이 높다면 TypeScript의 장점을 이용하는 것도 좋은 방법이라고 생각합니다.
🌈 커뮤니티
타입스크립트를 사용하고 있는 사용자는 해마다 많아 지고 있습니다.
StackOverflow에서는 해마다 실시하는 Devloper Survey의 결과를 보게 되면 TypeScript는 순위권에 랭크 되어 있었습니다. 또한 GitHub에서 진행되는 Octoverse에서도 순위권에 올라있을 정도로 사용자가 많고 커뮤니티 규모가 큽니다. 항상 소프트웨어와 관련된 커뮤니티가 크다는 점은 당연하고 잘 알고 있겠지만, 참고할 자료가 많고 디테일한 부분에서 언어 자체에 대한 지원이 잘 되어 있는 점을 알 수 있는 부분입니다.
🔥 결론
기존에 JavaScript를 사용하여서 코딩을 한 경험이 많았고 개인 프로젝트도 SPA를 사용한 개발을 많이 했었는데, 단지 개인 프로젝트였기 때문에 장기간 유지보수를 한 적이 없었는데 이번 포스팅을 통해서 TypeScript의 장기간 유지보수에 대한 인식과 장점을 알게 되었습니다.
TypeScript에 대한 안 좋은 선입견이 조금 있었는데 없어진 것 같고 다른 사람들에게 좋은 언어라고 추천할 수 있는 정도의 언어인 것 같습니다.
참고했고 읽었던 좋은 글 📁
