https://medium.com/daangn/typescript를-활용한-서비스개발-73877a741dbc

당근마켓은 중고거래 서비스를 넘어선 동네 기반의 하이퍼 로컬 플랫폼으로 도약하기 위해 다양한 서비스를 준비하고 있어요. 그리고 다양한 서비스들을 TypeScript를 활용하여 만들고 있어요. TypeScript는 JavaScript의 **동적 타입(Dynamic Typing)**을 **정적 타입(Static Typing)**으로 활용할 수 있는 superset이에요. TypeScript는 정적 타입을 통해 컴파일 타임에 타입 검사를 해서 코드의 안정성을 향상시켜요.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/80e0aa01-db71-4bd4-9034-81fb236012cd/1I9YGTIMQAhhTdNG3FiLjoA.jpeg

PHP, Python, JavaScript와 같은 동적 타입의 언어들은 코드를 빠르게 작성할 수 있게 도와주지만 규모가 크거나 기능이 많은 서비스를 개발하기 시작하면 항상 버그의 위험에 노출되어 있어요. 예를 들어 동료가 개발해서 넘겨준 함수의 return값이 string이라고 생각해서 split 메서드를 사용했으나 number타입인 경우 서비스가 동작하는 런타임에 에러가 발생하고 만약 프로덕션에 배포된 서비스라면 서비스 장애로 이어질 가능성이 높아져요.

타입스크립트 코드(컴파일에러)

//index.ts 
const getMessageByKey = (userKey: string) => {
   const [userId, tag] = userKey.split(':');
   const message = messageRepo.findOne({ where: {userId, tag} });
   //....
};//컴파일 에러
getMessageByKey(3927);

자바스크립트 코드(런타임 에러)

//index.js
const getMessageByKey = (userKey) => {
   const [userId, tag] = userKey.split(':');
   const message = messageRepo.findOne({ where: {userId, tag} });
   //....
};//런타임 에러 
getMessageByKey(3927);

TypeScript의 정적 타입을 사용하게 되는 경우 컴파일 단계에서 타입체크가 되어서 바로 버그가 있는 것을 인지하고 코드를 수정하여 코드의 안정성이 높아지게 되어요.

당근마켓에서는 많은 신규 프로젝트들이 생겨나고 서비스의 규모도 트래픽에 맞게 커지고 있는 만큼 많은 코드를 좀 더 안정적으로 관리할 필요가 있어서 TypeScript를 적극적으로 활용하고 있어요.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/04dfba05-5d02-44a7-a127-1846099adf5b/17lIHCo8RPZg1Mph21Yr82Q.png

NestJS

당근마켓은 TypeScript와 함께 NestJS 프레임워크를 사용해요. NestJS는 TypeScript를 완벽하게 지원하는 서버-사이드 프레임워크에요. NestJS를 이용하면 확장 가능하며 유지 관리가 쉬운 서버 애플리케이션을 쉽게 개발할 수 있어요.

NestJS와 다른 프레임워크와의 큰 차이점은 아키텍처 구조를 프레임워크에서 제공해요. 그렇다면 왜 아키텍처를 프레임워크에서 정의를 할까요? 쉽게 예를 들어볼게요. NestJS를 사용하지 않고 순수 express를 사용하는 프로젝트에 여러명의 팀원들이 같이 개발을 하고 있을 때 한 팀원 A가 B에게 이렇게 말을 해요.

A: “B, 이 코드는 언제 호출하는 코드에요?”B: “그 코드는 제가 개발하지 않아서 C한테 물어보셔야 해요”

A는 다시 C에게 가서 이렇게 말해요.

B: “C, 이 코드는 언제 호출하는 코드에요?”C: “아 그 코드는 사용자를 인증할 때 호출되는 코드에요. 저는 이런 코드는 미들웨어에 넣고 비즈니스 로직 관련 코드는 클래스를 따로 정의하고 컨트룰러에서 그걸 호출하고…”

A가 B에게 물어봤지만 B도 다른 사람이 작성한 코드가 쉽게 눈에 들어오지 않아요. 그리고 C의 아키텍처 디자인 스타일을 한참을 설명 받고 나서야 C가 개발한 코드가 이해가 되요. 사람마다 아키텍처 디자인 스타일이 다르거나 팀마다 스타일이 다르면 이처럼 커뮤니케이션 하는데 비용이 증가해요.

당근마켓 팀 또한 규모도 점점 커지고 많은 신규 프로젝트들을 개발하고 있기 때문에 개발자마다, 프로젝트마다 구조가 달라질 가능성이 있어요. NestJS는 이런 아키텍처의 정의도 프레임워크에서 제공하기 때문에 각 개발자들의 아키텍처가 통일되고 개발자들이 서로가 작성한 코드의 구조를 쉽게 파악할 수 있어요.