이 글은 SI(System Integration) 프로젝트에서 기업형 애플리케이션(Enterprise Application)을 목표 시스템으로 프로젝트를 진행하는 프로젝트 팀 개발자를 독자로 가정하고 작성하였습니다. 서비스 개발 회사의 경우, 기술 선택의 폭이 넓고 다양하여 일관된 흐름과 구조를 특정하기 어렵기 때문입니다.
소프트웨어 아키텍트는 목표 시스템의 아키텍처를 설계할 때, 다양한 의사결정과정을 거칩니다. 그 과정에서 기업이나 프로젝트 팀의 기술 아키텍처(Technology architecture) 내부에 정의해 둔 기술 인벤토리를 참조하여 대상 기술을 결정합니다. 기술 인벤토리는 기업의 과거, 현재, 미래의 기술에 대해 각 모듈이나 영역 별로 조사, 검토하여 시스템 설계에 사용할 기술을 미리 정하여 둔 문서입니다.
2018년 이후 모던 웹 애플리케이션을 설계할 때, 주로 SPA 스타일을 적용합니다. 이 때, 만나는 여러 의사결정 중에 우선 순위가 높은 다섯 가지를 정해 보았습니다. 당연히 개발 언어 선택이 가장 중요합니다. 그 이후의 결정은 프로그래밍 언어에 의존적입니다.
아키텍트는 위와 같은 결정을 할 때, 기술 자체의 우수성 보다는 운영 조직과 개발 조직의 역량과 수용성, 시장 기술의 흐름과 방향, 해당 기술의 생명주기 등을 고려하여 결정합니다. 따라서 아키텍트 관점에서 개발 언어 선택을 할 때, 언어 자체의 특성과 우수성을 깊이 살펴보기 보다는 시장과 팀의 상황, 그리고 기술 트랜드, 등을 중심으로 생각합니다.
프로그래밍 언어 관점에서 TypeScript의 자세한 특징이 궁금하신 분들은 Medium의 Jack Tomaszewski 님의 블로그 글을 참조하세요.
Jack Tomaszewski
JavaScript는 1995년 웹 페이지의 요소들에 움직임을 부여하는 매우 한정적인 용도로 개발하였습니다. 따라서 엄격한 엄격한 규칙없이 편하게 사용할 수 있도록 동적 타입(Dynamic typed)을 사용합니다. 이러한 특성은 간단한 프로그램에서는 장점이 되었지만, 규모가 큰 프로그램에서는 디버깅과 테스트를 어렵게하였습니다. JavaScript 언어의 특성을 간단하게 표로 살펴봅니다.
이러한 문제를 해결함과 동시에 객체지향 언어 특성을 강조하여 나온 언어가 TypeScript 입니다. 우선 간단하게 특성을 표로 살펴 봅니다.
TypeScript는 JavaScript의 수퍼셋으로 ES8 스펙을 포함하여 ECMA 새표준을 지속적으로 반영하고 있습니다. Interface, Generic 등과 같은 객체지향 프로그래밍 지원으로 크고 복잡한 대규모 시스템을 지원할 뿐만 아니라 정적 타입 지원으로 IDE의 Code Assist, 타입 체크, 리팩토링 기능을 사용할 수 있습니다. JavaScript ES6에 익숙한 개발자 뿐만 아니라 Java 개발자도 TypeScript 프로그램을 쉽게 다가갈 수 있습니다.
TypeScript는 JavaScript의 수퍼셋이므로 TypeScript는 JavaScript를 이해합니다. 최소한의 확장 세트를 사용할 경우, 타입(데이터, 객체, 인터페이스)을 미리 정의하는 것을 제외하면 거의 같은 수준입니다. JavaScript의 확장자는 *.js 이고, TypeScript의 확장자는 *.ts입니다. React에서 사용하는 JavaScript를 확장한 *.jsx가 TypeScript에서는 *tsx입니다. TypeScript가 프로젝트 구성정보 설정방법이 약간 다른 것을 제외하면, TypeScript는 엄격한 타입을 적용한 JavaScript라고 할 수 있습니다.
위의 예제 코드를 보면, 타입을 미리 정의하는 부분, 매개변수의 타입을 지정하는 부분 등을 빼고 나면 JavaScript 코드와 동일합니다.
아키텍트 입장에서 언어를 결정할 때 참조하는 가장 중요한 정보는 기술 흐름입니다. 다른 프로젝트, 다른 개발자 들은 어떤 선택을 하는 지를 알아보아야 합니다. TypeScript와 JavaScript 사용에 대한 다양한 정보들을 찾을 수 있지만, 둘 중에 하나를 선택해야 하는 상황에서 가장 유용한 정보는 stateofjs.com 사이트입니다.
이 사이트에서 보여주는 그래프는 JavaScript를 사용하는 개발팀이 TypeScript를 채택하는 추세를 볼 수 있습니다. 2019년 기준으로 이미 58.5%가 프로젝트에서 TypeScript를 사용하고 있다고 하였고, 22.3%의 개발자는 긍정적으로 받아들이고 있는 것을 볼 수 있습니다.
이 정보는 JavaScript 개발팀에서 TypeScript를 채택하여 어떤 프로젝트에서 사용하고 있음을 보여주고 있습니다. 시장 점유율 관점에서 참조할 만한 정보인 githut은 github의 pull 요청을 기준으로 언어별 비율을 보여주는 사이트입니다. 아래 데이터는 2020년 3월 기준 데이터를 검색한 결과입니다. JavaScript가 가장 인기가 많은 언어임을 알 수 있습니다. 아래 쪽에서 6위 자리에서 꾸준히 상승하고 있는 TypeScrpt를 볼 수 있습니다.
SI 프로젝트의 기업형 애플리케이션은 대체로 규모가 크고 복잡합니다. 애자일 프로세스, 마이크로서비스 아키텍처, 등이 자리 잡은 기업이 많지 않습니다. 따라서 많은 수의 프로젝트가 워터폴 프로세스를 따릅니다. 그 결과 모노리스 스타일 프론트 개발이 이루어지고 있습니다. 그 결과 개발팀은 크고 복잡한 프론트-엔드 모듈을 상대해야 합니다. 디버깅과 테스트가 어려울 수 밖에 없습니다.
SI 프로젝트에서 프론트-엔드 모듈 개발 언어로 TypeScript 언어를 추천합니다. 다음 여섯 가지를 이유로 들어봅니다.
- JavaScript의 수퍼셋으로 JavaScript의 미래 모습이다.
- JavaScript 개발자가 쉽게 배울 수 있다.
- 풀스택을 지향하는 Java 개발자에게 배우기 쉬운 언어이다.
- 객체지향 특성을 사용할 수 있다.
- REST API를 타고 오는 백엔드의 객체모델(서비스 데이터 객체) 변환이 쉽다.
- 디버깅과 테스트가 용이하다. 따라서 개발생산성과 품질이 상대적으로 높다.
긴 고민 끝에 언어를 결정하고 나면, SPA용 UI 라이브러리, State 관리를 위한 컨테이너 선택, 등이 기다리고 있습니다. 넥스트리는 TypeScript, React, MobX를 기준으로 애플리케이션 프론트를 설계하고 있습니다. 2000년 10월에 성공적으로 오픈한 철강회사의 대규모 MES 프로젝트도 세 가지 조합으로 구성하여 잘 끝낸 경험을 갖고 있습니다.
왜 Vue 대신에 React를 선택했으며, Redux 대신에 MobX를 선택했는가는 또 다른 글로 공유하겠습니다.
선택은 조직과 팀, 특히 소프트웨어 아키텍트의 몫입니다. 여전히 많은 프로젝트에서 JavaScript를 프론트-엔드의 기준 언어로 사용하고 있습니다. 하지만, 백엔드의 Java와 보조를 맞춰야 할 프론트 언어의 자격으로 객체지향 특성은 매우 중요합니다. 개발 조직이 풀스택 개발자를 지향하거나, 코드 자동화 도구를 만들 거나 할 때, 프론트 언어와 백엔드 언어 모두 객체지향 특성을 지원하면 학습 기간, 모델 변환, 코드 재사용 등에 유리합니다.
JavaScript 개발팀이 TypeScript로 전환을 고민해야 할 때가 왔습니다.
참조자료
- TypeScript 홈: https://www.typescriptlang.org
- TypeScript 이전 사례: https://slack.engineering/typescript-at-slack/
