들어가며
벌써 9월이 다가오고 삼성의 공채가 열리며 하반기의 시작을 알렸다. 나도 꾸준히 공부하던 도중.. 문득 이런 의문이 들었다.
스타트업에서는 왜 Node 기반을 많이 쓸까?
한국 기준으로 자바가 많이 활성화 되어있고, 이에 따라 인재풀 또한 자바가 많을 거라 생각해서 기업 입장에서도 당연히 자바를 많이 쓸 거라 생각했다.
하지만 실상은 달랐고 오늘은 그 이유를 알아보기 위해 두 기술을 비교해보았다.
일단 예시를 위해 실제 어느 한 기업의 기술스택을 가져왔다.
🛠️ 기술 스택
Frontend
- Typescript
- React Native (Expo)
- NextJS
Backend
- Typescript
- NodeJS
- tRPC (Express)
- Prisma
1. 생각의 틀을 바꾸다: 멀티 스레드 vs 이벤트 루프
가장 먼저 마주한 차이는 바로 동시성 모델의 차이였다. 이것은 단순히 언어 문법의 차이가 아닌, 서버가 요청을 처리하는 방식에 대한 근본적인 차이점이였다.
Java/Spring의 세계 (멀티 스레드)
요청이 들어올 때마다 새로운 스레드를 할당하거나(혹은 스레드 풀에서 꺼내) 처리하는 방식에 익숙했다. 한 스레드가 DB 조회나 API 호출로 잠시 멈춰(Blocking) 있더라도, 다른 스레드가 다른 요청을 처리하기에 전체 서버가 멈추는 일은 없었다.
마치 손님마다 전담 웨이터가 한 명씩 붙는 레스토랑과 같았다.
Node.js의 세계 (싱글 스레드 이벤트 루프)
Node.js는 단 하나의 메인 스레드로 모든 요청을 받는다. 그리고 오래 걸리는 I/O 작업(DB 조회, 파일 읽기 등)은 운영체제(libuv)에게 위임하고, 자신은 바로 다음 요청을 받으러 간다.
위임했던 작업이 끝나면 그 결과(콜백 함수)는 이벤트 큐에 등록되고, 메인 스레드는 순서대로 큐의 작업들을 처리한다.
엄청나게 손이 빠른 웨이터 한 명이 모든 테이블의 주문을 받고, 주방에 던져놓고, 요리가 완성되면 서빙하는 방식이었다.
⚠️ 중요한 차이점
Node.js에서는 모든 I/O가 'Non-Blocking'으로 동작해야만 했다. 만약 단 하나라도 Blocking 작업이 메인 스레드를 차지하면, 서버 전체가 멈춰버리는 끔찍한 재앙이 발생한다.
2. 기술 스택 파헤치기: tRPC와 Prisma, 그리고 Next.js
이 기술 스택은 단순히 Node.js를 사용하는 것을 넘어, 그 생태계의 장점을 극대화하는 조합으로 구성되어 있었다.
End-to-End 타입 안정성의 충격: tRPC
가장 충격적이었던 기술은 tRPC였다. Spring Boot 환경에서는
1. Controller에 API를 만들고
2. Swagger 같은 도구로 API 문서를 생성하고
3. 프론트엔드 개발자는 그 문서를 보며 요청/응답 타입을 수동으로 만들어야 했다
tRPC는 이 모든 과정을 없애버렸다.
- 백엔드에서 TypeScript로 API 함수를 정의하면, 프론트엔드에서 그 함수의 타입을 그대로 'import'해서 사용할 수 있었다
- 백엔드 API의 응답 객체 필드명이 바뀌면, 프론트엔드 코드에서 즉시 컴파일 에러가 발생했다
- API 명세서가 사라지고, 코드가 곧 문서가 되는 세상이었다
개발 속도와 안정성을 동시에 잡는 이 방식은 혁신적으로 느껴졌다.
현대적인 ORM, Prisma
Prisma는 JPA/Hibernate와는 또 다른 경험을 제공했다:
- 스키마 파일을 먼저 정의하면, 데이터베이스 마이그레이션과 타입 세이프한 클라이언트를 자동으로 생성
- Prisma가 생성한 타입을
tRPC가 그대로 프론트엔드까지 전달해 주는 End-to-End 타입 안정성 아키텍처는 매우 견고하고 좋아보였다.
풀스택 프레임워크, Next.js
Next.js는 백엔드와 프론트엔드를 하나의 프로젝트, 하나의 언어(TypeScript)로 개발하게 해주었다
/pages/api폴더에는 백엔드 API 코드를- 그 외
/pages폴더에는 사용자에게 보여줄 React 컴포넌트를 작성
이는 마치 Spring Boot 프로젝트 안에 React 프로젝트가 완벽하게 통합된 것과 같은 경험을 제공하며, 엄청난 개발 생산성을 가져다줄 것 같았다.
3. 모든 기술에는 트레이드오프가 있다
이 새로운 세계는 장점만 가득한 유토피아처럼 보였다. 하지만 모든 기술 선택에는 반드시 트레이드오프가 존재한다. Java/Spring 생태계가 수십 년간 엔터프라이즈 시장을 지배해 온 데에는 그만한 이유가 있었다.
⚡ CPU 집약적 작업
- Node.js의 약점: 싱글 스레드인 Node.js는 복잡한 연산, 대용량 데이터 처리 등 CPU를 많이 사용하는 작업에 명백한 약점을 가졌다
- Java의 강점: 멀티스레딩을 완벽하게 지원하는 Java와 JVM이 압도적인 성능을 보여준다
🌐 생태계의 안정성
- npm 생태계: 거대하고 활기차지만, 그만큼 변화가 빠르고 파편화되어 있다
- Java 생태계: 변화는 느릴지언정, 오랜 기간 검증된 라이브러리들이 주는 안정감과 신뢰도가 있다
🔋 'Batteries-Included' 철학
- Spring Boot:
@Transactional어노테이션 하나로 해결되는 정교한 트랜잭션 관리, 강력한 Spring Security 등 엔터프라이즈급 기능들이 프레임워크 자체에 단단하게 통합되어 있다 - Node.js: 이런 기능들을 수많은 라이브러리들을 직접 조합하여 구현해야 했다. 이는 유연성을 주지만, 동시에 아키텍처에 대한 더 깊은 고민을 요구했다. 특히나 안전성을 요구하는 큰 프로젝트라면... 더욱 기피할 것 같았다.
🎯 결론: 더 넓은 시야를 갖게 되다
이번 조사를 통해 Java/Kotlin의 세계와 Node.js/TypeScript의 세계를 깊이 있게 비교하며 탐험할 수 있었다.
결론적으로 어떤 기술 스택이 절대적으로 '더 좋다'고 말할 수는 없었다.
Node.js 기반 풀스택 TypeScript 스택이 적합한 환경
- 빠른 개발 속도와 반복이 중요한 경우 (스타트업이 많이 선택하는 주요 이유)
- 대부분의 작업이 I/O 통신으로 이루어지는 웹/앱 서비스 환경
Java/Spring 생태계가 적합한 환경
- 극강의 안정성이 필요한 경우
- 무거운 연산 처리가 필요한 대규모 엔터프라이즈 환경
핵심 인사이트
결국 중요한 것은 해결하려는 문제의 본질을 이해하고, 각 기술의 철학과 트레이드오프를 고려하여 가장 적합한 도구를 선택하는 능력이었다.
특히 AI가 발전하고 다양한 MCP 및 에이전트가 등장함에 따라 언어의 장벽이 더 낮아졌다고 생각한다. 결국은 어떤 기준으로 선택하고 어떻게 빨리 학습해 구현할 것인지가 더 중요하지 않을까....
언젠가는 Node로 한번 프로젝트를 해봐야겠다는 생각이 든다.
