Node.js 리드·아키텍트 프레임워크 심층 면접

Event Loop는 6개 phase로 구성되며 timers(setTimeout/setInterval), pending callbacks(시스템 콜백), poll(I/O 이벤트), check(setImmediate), close callbacks 순으로 실행됩니다. process.nextTick()과 Promise는 microtask queue에 들어가 각 phase 전환 시점마다 우선 실행되며, nextTick이 Promise보다 높은 우선순위를 가집니다. CPU 집약적 작업이 poll phase에서 발생하면 다른 I/O 이벤트 처리가 지연되어 전체 시스템 응답성이 저하됩니다. 해결 방안으로는 Worker Threads를 활용한 병렬 처리, 작업을 chunk 단위로 분할하여 setImmediate로 다음 tick에 위임, 또는 별도 마이크로서비스로 분리하는 아키텍처 전환을 고려할 수 있습니다. 특히 이미지 처리, 암호화, 대용량 데이터 파싱 등은 Worker Threads pool로 격리하는 것이 권장됩니다.

Readable은 데이터 소스, Writable은 데이터 목적지, Duplex는 양방향 독립 스트림, Transform은 데이터 변환 스트림입니다. 각 스트림은 highWaterMark 기준으로 내부 버퍼를 관리하며, Readable이 Writable보다 빠르게 데이터를 생성할 때 backpressure가 발생합니다. write() 메서드가 false를 반환하면 버퍼가 가득 찬 것이며, 이를 무시하고 계속 쓰면 메모리 누수가 발생합니다. pipe() 메서드는 자동으로 backpressure를 처리하므로 대용량 파일 처리 시 권장됩니다. 아키텍처 패턴으로는 multipart upload를 Stream으로 받아 chunk 단위로 S3에 직접 전송하거나, Transform Stream으로 암호화/압축을 파이프라인화하여 메모리 사용을 일정하게 유지하는 방식을 사용합니다. 또한 Stream pool을 구성해 동시 처리 수를 제한하고 시스템 리소스를 보호합니다.

CommonJS는 동기적으로 런타임에 모듈을 로드하며 require()가 실행되는 시점에 파일을 읽고 캐싱합니다. ES Modules는 비동기적이며 파싱 단계에서 정적 분석을 통해 의존성 그래프를 먼저 구성합니다. 순환 참조 시 CommonJS는 부분적으로 초기화된 exports 객체를 반환하지만, ESM은 TDZ(Temporal Dead Zone)로 인해 ReferenceError가 발생할 수 있습니다. 모노레포에서 혼용 시 .mjs/.cjs 확장자 관리, package.json의 type 필드 설정, 그리고 interop 레이어에서의 default export 처리 문제가 발생합니다. 마이그레이션 전략으로는 먼저 leaf 모듈부터 ESM으로 전환하고, 점진적으로 상위 레이어로 확장하며, 과도기에는 dual package 방식으로 양쪽 모두 지원하는 번들을 제공하는 방법을 사용합니다.

Cluster 모듈은 마스터 프로세스가 소켓을 listen하고 워커에게 연결을 분배하며, IPC 채널을 통해 메시지를 주고받습니다. Round-robin 방식은 Node.js가 직접 분배를 제어하고, OS scheduling은 커널 레벨에서 처리하는데 Windows와 일부 Unix에서는 OS 방식이 기본입니다. 세션 관리는 Redis 같은 외부 저장소를 사용하거나, sticky session을 구현해 같은 클라이언트를 동일 워커로 라우팅해야 합니다. PM2는 Cluster 모듈을 wrapping하여 무중단 재시작과 모니터링을 제공하므로 단일 서버 환경에서 유용하고, Docker Swarm이나 Kubernetes는 컨테이너 레벨 스케일링으로 여러 노드에 분산 가능하므로 대규모 환경에 적합합니다. Cluster 모듈은 CPU 코어 활용이 주 목적이고 단일 서버 최적화가 필요할 때 선택하며, 다중 서버 환경에서는 컨테이너 오케스트레이션이 더 적합합니다.

Callback 패턴에서는 error-first 규칙으로 첫 번째 인자에 에러를 전달하며, 에러 처리를 누락하면 조용히 실패합니다. Promise는 reject를 통해 에러를 전파하고 .catch()로 처리하며, catch되지 않으면 unhandledRejection 이벤트가 발생합니다. async/await는 동기 코드처럼 try-catch를 사용하지만, catch 없이 reject된 Promise는 여전히 unhandledRejection을 발생시킵니다. uncaughtException은 동기 코드나 callback에서 throw된 에러가 catch되지 않을 때 발생하며, 프로세스가 불안정한 상태가 됩니다. 프로덕션에서는 unhandledRejection 발생 시 로깅 후 graceful shutdown을 수행하고, uncaughtException은 즉시 프로세스를 종료하며 PM2나 Kubernetes가 재시작하도록 합니다. 전역 에러 핸들러는 마지막 안전망 역할이지만, 근본적으로는 모든 비동기 코드에 명시적 에러 처리를 하는 것이 원칙입니다.

V8은 Generational GC를 사용하며 New Space는 단명 객체를 빠르게 수집하는 Scavenger 알고리즘을, Old Space는 장수 객체를 Mark-Sweep-Compact로 처리합니다. 메모리 누수는 클로저가 외부 스코프를 계속 참조하거나, 전역 변수에 대량 데이터를 누적하거나, 이벤트 리스너를 removeListener하지 않을 때 발생합니다. 진단은 Chrome DevTools의 힙 스냅샷으로 retained size가 큰 객체를 찾거나, --inspect 플래그로 프로파일링하며, clinic.js나 heapdump 모듈을 사용합니다. --max-old-space-size는 Old Space 크기를 조정하는 플래그로 기본 1.4GB를 늘릴 수 있지만, 근본적으로는 Stream을 사용한 chunk 처리, Worker Threads로 메모리 격리, 또는 데이터를 외부 저장소(Redis, DB)에 오프로드하는 아키텍처로 메모리 한계를 우회해야 합니다.

N-API는 ABI(Application Binary Interface) 안정성을 제공하여 Node.js 버전이 바뀌어도 재컴파일 없이 바이너리를 재사용할 수 있습니다. NAN은 각 Node.js 버전마다 재컴파일이 필요하고 V8 API 변경에 취약하지만, N-API는 V8에서 추상화되어 있어 안정적입니다. 배포 시 node-gyp로 소스를 빌드하거나 prebuild를 사용해 플랫폼별 바이너리를 미리 준비해야 하며, Windows/Linux/macOS 각각에서 빌드 환경 구성이 필요합니다. 성능 트레이드오프로는 JavaScript-C++ 컨텍스트 전환 오버헤드가 있어 호출 빈도가 높으면 오히려 느릴 수 있습니다. WASM은 샌드박스 환경에서 안전하고 브라우저와 코드 공유가 가능하며 빌드가 단순하므로, 시스템 리소스 접근이 불필요하고 크로스 플랫폼 배포가 중요한 경우 선택합니다. 네이티브 애드온은 하드웨어 직접 제어나 기존 C/C++ 라이브러리 통합이 필수적일 때 선택합니다.