왜?
아임웹 엔지니어링에서는 기술 부채를 없애고 모던 스택을 도입 하기 위해 아임웹 서비스 전체를 점진적으로 MSA (Micro Service Architecture)로 재개발을 하고 있습니다.
MSA에 사용할 백엔드 언어를 선택 할 때 오직 성능만 본다면 단연코 go 를 선택 했을 것입니다. 그러나, 우리는 Backend 언어로 node.js 를 선택하였습니다.
아임웹 서비스는 성능도 중요하지만, 지금 단계에서 가장 중요한 가치는 높은 생산성과 기술부채의 해결 입니다.
우리는 성장하고 있고, 빠른 확장도 필요 합니다. 그런데 기술부채가 발목을 잡고 있거든요.
이 글은, 아래의 이유를 분석합니다.
- go를 쓸 때 일반적인 장점을 알아보고
- node.js 로 어떻게 go 의 장점을 가져오거나 대체할 수 있는지
- 왜 nest.js 를 사용하는지
자- 알아 봅시다.
go를 쓰면 무엇이 좋은데요?
일단 만들면, 같은 일을 해도 빠릅니다.
Memory-Leak(메모리-릭)이 거의 없습니다.
병렬 CPU를 최대한 활용 할 수 있습니다.
모든 것은 인터페이스, 정적 타입 선언을 하기 때문에 유형 검증에 오히려 안정적 입니다.
Exception 이 없기 때문에, 코드 흐름의 가독성이 매우 좋습니다.
go는 정말 좋지만, 생산성이 문제입니다.
표준 라이브러리는 잘 지원 됩니다. (누구나 사용하는 기능 같은 것들, 예를 들면 websocket)
그러나, 타사 라이브러리는 잘 지원되지 않습니다. (예를 들면, passport 같은 oauth2 타사 인증 모듈들)
npm의 수백만개의 찾기만 하면 바로 사용할 수 있는 수준과는 비교하기가 어렵습니다.
또한, 언어의 극단적인 미니멀리즘 때문에, 간단한 일도 돌아가야 하는 경우가 종종 있습니다.
하지만,
이런 장점의 일부를 node.js 를 사용하면서 일부 대체할 수 있죠.
node.js 의 대체 처리 방법
메모리-릭이 거의 없습니다.
→ 메모리 릭이 나와도 상관없게 인스턴스를 매일 교체 합니다.
→ 이 방법은 기술부채를 남기지만 컨테이너와 결합하여 훌륭한 방법이 될 수 있습니다.
병렬 CPU를 최대한 활용 할 수 있습니다.
→ 싱글 CPU를 사용하는 컨테이너를 수십개 띄우면 됩니다.
→ 이제는, node.js의 Worker Thread, Cluster 도 있죠.
모든 것은 인터페이스, 정적 타입 선언을 하기 때문에 유형 검증에 오히려 안정적 입니다.
→ Typescript 를 쓰면 됩니다.
Exception 이 없기 때문에, 코드 흐름의 가독성이 매우 좋습니다.
→ 코딩 컨벤션을 강제 하며, 예외를 매우 보수적으로 사용 하는 전략을 취합니다.
Why node.js
node.js 로 만들 때 장점은 단연코 생산성 입니다
그리고, Backend 와 Frontend 의 언어가 같다는 장점도 매우 귀한 장점 입니다.
이로 인해, 수많은 개발자 Pool 이 있고, 채용에 높은 점수를 받습니다.
개발자 구하기가 비교적 쉽고, 그러므로 제때 우리 목표를 이룰 수 있을테니까요.
하지만, 그냥 생각없이 개발 하기도 쉽습니다.
JS는 Vanilla JS (외부 라이브러리 없는 순수한 JS)로 개발이 가능한 언어 이고, 스파게티가 되기 매우 쉽고, 콜백 지옥이 있습니다.
하지만, 현재 이런 일반적인 문제는 문법과 Framework 의 힘으로 다 해결이 됐습니다.
그냥, Typescript 를 쓰면 됩니다.
JS를 C# 처럼 사용할 수 있게 해주는 마법의 언어 입니다.
굳이 Java도 아닌, C# 을 말하는 이유는…
C# 과 TS의 창시자가 같은 사람이기 때문 입니다.
TS는 JS의 스파게티 코드를 싸그리 없애주는 최고의 슈퍼셋 입니다.
무조건 써야 합니다.
요즘은 TS를 기본으로 장착하는 Framework 가 아주 많습니다.
Nest.js, React.js, Vue.js…
Nest.js
node.js의 범용 백엔드 프레임워크인 Express.js 는 자유도가 엄청 납니다.
그만큼 쉽게 사용할수 있고 직관적이죠. 그러나, 협업할땐 정말 꽝 입니다.
너무 쉽게 만들다 보니 자기 마음대로 만들기 때문이죠.
이런 Express의 너무 심각한 자유도를 적당히 제한 하면서
Typescript 를 도입하고, 협업에 필요한 많은 개념을 차용하여
차기 Express 라고 말하는 프레임워크 입니다.
상당 부분의 개념을 Java의 Spring 에서 따왔습니다.
DI, AOP, CQRS…
이미 node.js 를 사용하여 생산성이 보장된 상태에서, Java Spring으로 프로덕션에서 검증된 방법론을 재해석하여 차용 하고, 이렇게 많은 사용자 풀을 가지면서, 좋은 결과물을 낼 수 있는 프레임워크가 또 있었나 싶습니다.
결론
최고의 생산성을 위해 node.js 를 선택하지만,
검증된 아키텍처를 잘 사용하기 위해 nest.js 프레임워크를 차용 하며,
모든 Backend Engineer 가 이 기술을 잘 습득 하여,
아임웹의 기술 부채를 깨부셔 나가면,
안정적이면서 시장과 고객의 요구를 빠르게 해소해 줄 수 있게 되고,
이로 인해 고객은 더 큰 만족과 매출을,
이것은 결국, 우리에게 풍요로운 미래를 보장해 줄 것입니다.
오늘도 긴 글 읽어주셔서 감사합니다.
ps.
이 글은 내부에 MSA 재개발 작업을 시작하기 전에 공유했었는데,
약 6개월 만에, 지금은 대부분의 BE 엔지니어가 Nest.js에 능숙하고 AOP를 철저히 지키면서 코드리뷰와 함께 즐겁게 일하고 있습니다.
