Node.js 미드레벨 기술면접
새 면접Q. Node.js 애플리케이션에서 CPU 집약적인 작업(예: 이미지 처리, 대용량 데이터 변환)을 처리할 때 발생할 수 있는 문제점과 이를 해결하기 위한 방법들을 비교 설명해주세요. 각 방법의 장단점도 함께 말씀해주세요.
Node.js는 싱글 스레드 기반이므로 CPU 집약적 작업이 Event Loop을 블로킹하여 다른 요청 처리가 지연됩니다. 해결 방법으로는 1) Worker Threads를 사용한 멀티스레딩, 2) Child Process로 별도 프로세스 생성, 3) 외부 마이크로서비스로 분리, 4) Bull/Bee-Queue 같은 작업 큐 활용이 있습니다. Worker Threads는 메모리 공유가 가능하지만 복잡도가 높고, Child Process는 격리성이 좋지만 IPC 오버헤드가 있으며, 마이크로서비스는 확장성이 뛰어나지만 네트워크 레이턴시가 발생합니다. 실무에서는 작업의 특성과 빈도에 따라 적절한 방법을 선택해야 합니다.
- • Event Loop 블로킹 문제 이해
- • Worker Threads, Child Process, 마이크로서비스 등 다양한 해결책
- • 각 방법의 트레이드오프 분석
- • 작업 큐를 활용한 비동기 처리
실제 프로젝트에서 이미지 리사이징 작업을 처리해야 한다면, 동시에 100개의 요청이 들어올 때 어떤 아키텍처를 설계하시겠습니까? 리소스 제한과 응답 시간을 고려해서 설명해주세요.
Q. Node.js에서 Singleton 패턴을 구현할 때 require 캐싱을 활용하는 방법과 주의사항을 설명하고, ES6 Module(import/export)에서는 어떻게 다르게 동작하는지 비교해주세요.
Node.js의 CommonJS(require)는 모듈을 처음 로드할 때 캐싱하므로 같은 모듈을 여러 번 require해도 동일한 인스턴스를 반환합니다. 따라서 module.exports로 객체를 내보내면 자연스럽게 Singleton이 됩니다. 주의사항으로는 require.cache를 직접 조작하거나 삭제하면 캐싱이 무효화되고, 심볼릭 링크나 상대경로 차이로 다른 모듈로 인식될 수 있습니다. ES6 Module은 정적 분석과 Live Binding을 지원하며, 모듈 인스턴스가 한 번만 생성되는 것은 동일하지만 export한 값의 변경이 실시간으로 반영됩니다. 두 방식 모두 기본적으로 Singleton을 보장하지만, ES6 Module이 더 명확한 스코프와 정적 분석 이점을 제공합니다.
- • require 캐싱 메커니즘 이해
- • require.cache 조작 시 주의사항
- • ES6 Module의 Live Binding 특성
- • 두 모듈 시스템의 Singleton 동작 차이
데이터베이스 커넥션 풀을 Singleton으로 관리할 때, 테스트 환경에서는 매 테스트마다 새로운 인스턴스가 필요합니다. 이런 경우 어떻게 설계하시겠습니까?
Q. 프로덕션 환경에서 Node.js 애플리케이션의 응답 시간이 간헐적으로 급증하는 문제가 발생했습니다. 가능한 원인들을 체계적으로 분석하는 방법과 각 원인을 진단하기 위해 사용할 수 있는 도구나 메트릭을 설명해주세요.
응답 시간 급증의 원인은 크게 1) Event Loop 지연(CPU 집약 작업, 동기 코드), 2) I/O 병목(DB 쿼리, 외부 API 호출), 3) 가비지 컬렉션 일시정지, 4) 메모리 부족, 5) 네트워크 이슈로 나눌 수 있습니다. 진단 방법으로는 clinic.js로 Event Loop 지연 분석, APM 도구(New Relic, Datadog)로 트랜잭션 추적, --inspect 플래그와 Chrome DevTools로 CPU 프로파일링, process.memoryUsage()와 heapdump로 메모리 분석, prom-client로 커스텀 메트릭 수집이 있습니다. 실무에서는 로그에 타임스탬프를 찍어 각 구간별 소요시간을 측정하고, 느린 쿼리 로그와 외부 API 응답시간을 모니터링하며, percentile 기반 메트릭(p95, p99)으로 이상치를 감지합니다.
- • Event Loop, I/O, GC 등 다양한 원인 분석
- • clinic.js, APM, profiling 도구 활용
- • percentile 메트릭을 통한 이상치 감지
- • 구간별 타이밍 측정으로 병목 구간 특정
clinic.js로 분석한 결과 특정 미들웨어에서 Event Loop 지연이 발생한다는 것을 확인했습니다. 해당 미들웨어는 JWT 토큰 검증을 수행하는데, 어떻게 최적화하시겠습니까?
Q. Node.js에서 Promise를 사용할 때 흔히 발생하는 안티패턴들과 그 문제점을 설명하고, 올바른 코드 작성 방법을 제시해주세요. 특히 Promise 체이닝, 에러 처리, async/await 혼용 시 주의사항을 중심으로 설명해주세요.
주요 안티패턴으로는 1) Promise 생성자 안에서 불필요하게 다른 Promise를 래핑하는 Promise Constructor Anti-pattern, 2) then 안에서 return을 빠뜨려 체이닝이 끊기는 경우, 3) catch를 빠뜨려 unhandled rejection이 발생하는 경우, 4) async 함수에서 await 없이 Promise를 반환만 하는 경우가 있습니다. then 체이닝보다는 async/await을 사용하되 반드시 try-catch로 감싸야 하며, Promise.all 사용 시 하나라도 실패하면 전체가 실패하므로 Promise.allSettled를 고려해야 합니다. 또한 루프 안에서 await을 사용하면 순차 실행되므로 병렬 처리가 필요하면 Promise.all과 map을 조합해야 합니다.
- • Promise Constructor Anti-pattern 회피
- • then 체이닝에서 return 누락 방지
- • unhandled rejection 처리
- • async/await과 Promise.all을 활용한 병렬 처리
여러 개의 비동기 작업을 수행하는데, 일부는 실패해도 되고 일부는 반드시 성공해야 하는 요구사항이 있습니다. 이런 경우 어떻게 에러 처리를 설계하시겠습니까?
Q. 대용량 트래픽을 처리하는 Node.js API 서버에서 Rate Limiting을 구현해야 합니다. 단일 서버와 다중 서버 환경에서 각각 어떻게 구현할 수 있는지 설명하고, Redis를 활용한 분산 Rate Limiting의 구현 전략과 주의사항을 설명해주세요.
단일 서버에서는 메모리 기반으로 Map이나 express-rate-limit 라이브러리를 사용하여 IP별 요청 횟수를 추적할 수 있습니다. 다중 서버 환경에서는 각 서버가 독립적인 메모리를 가지므로 Redis 같은 중앙 저장소가 필요합니다. Redis 기반 구현은 1) Fixed Window(고정 시간창), 2) Sliding Window(슬라이딩 윈도우), 3) Token Bucket, 4) Leaky Bucket 알고리즘을 사용할 수 있습니다. Sliding Window는 Sorted Set을 활용해 타임스탬프를 저장하고, Token Bucket은 INCR과 EXPIRE를 조합합니다. 주의사항으로는 Redis 장애 시 Fallback 전략, Race Condition 방지를 위한 Lua Script 사용, TTL 설정으로 메모리 관리, 그리고 Rate Limit 초과 시 적절한 HTTP 429 응답과 Retry-After 헤더 제공이 필요합니다.
- • 단일 vs 다중 서버 환경의 Rate Limiting 차이
- • Redis 기반 다양한 알고리즘(Fixed/Sliding Window, Token Bucket)
- • Lua Script를 통한 원자성 보장
- • 장애 대응과 적절한 HTTP 응답 설계
API 사용자별로 다른 Rate Limit을 적용해야 하고(무료/프리미엄 등급), 특정 엔드포인트는 더 엄격한 제한이 필요합니다. 이런 복잡한 요구사항을 어떻게 설계하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!