Node.js 리드·아키텍트 테스트 전략 및 코드품질 면접

마이크로서비스로 전환 시 테스트 피라미드는 단위:통합:계약:E2E = 50:30:15:5 비율로 조정하는 것이 적합합니다. 단위 테스트는 각 서비스 내부 비즈니스 로직에 집중하고, 통합 테스트는 단일 서비스 내 컴포넌트 간 상호작용과 데이터베이스 연동을 검증합니다. 계약 테스트(Pact, Spring Cloud Contract)는 서비스 간 API 스펙 준수를 보장하며, 프로바이더와 컨슈머 양측에서 실행됩니다. E2E 테스트는 핵심 비즈니스 플로우만 선별하여 최소화하고, 테스트 환경 구성 비용을 줄이기 위해 서비스 가상화(Mock Server, Testcontainers)를 활용합니다. 각 서비스는 독립적으로 배포 가능해야 하므로 외부 의존성은 모두 stub/mock으로 격리하며, CI/CD 파이프라인에서 병렬 실행이 가능하도록 설계합니다.

TDD는 초기 개발 속도는 10-20% 느리지만, 버그 밀도를 40-80% 감소시키고 리팩토링 안정성을 확보하여 장기적으로 총 개발 비용을 절감합니다. 레거시 코드베이스에서는 Characterization Test(기존 동작 보존 테스트)를 먼저 작성하여 안전망을 구축하고, 새로운 기능부터 TDD를 적용합니다. TDD가 효과적인 영역은 복잡한 비즈니스 규칙, 알고리즘, 상태 전이 로직이며, 단순 CRUD, 외부 API 연동, UI 레이어는 통합 테스트나 E2E 테스트로 커버하는 것이 효율적입니다. 조직 도입 시에는 핵심 도메인 모듈부터 시작하여 성공 사례를 만들고, 페어 프로그래밍과 코드 리뷰를 통해 TDD 사이클(Red-Green-Refactor)을 학습하도록 합니다. 테스트 커버리지보다 테스트 품질과 유지보수성에 집중하며, 과도한 목(mock) 사용을 지양하고 실제 협력 객체를 사용하는 통합 테스트를 병행합니다.

Stub은 미리 정의된 응답을 반환하는 객체로 외부 API나 DB 응답을 단순화할 때 사용하고, Mock은 호출 여부와 인자를 검증하는 객체로 특정 메서드가 올바르게 호출되었는지 확인할 때 사용합니다. Spy는 실제 객체를 감싸서 호출을 기록하며 부분적인 검증에 적합하고, Fake는 실제와 유사하게 동작하는 경량 구현체로 인메모리 DB나 테스트용 서버를 구축할 때 사용합니다. 외부 API는 Stub으로 응답을 고정하고, DB는 Fake(인메모리 DB)나 Testcontainers로 실제 환경을 구성하며, 시간 의존 로직은 Sinon의 useFakeTimers로 시간을 제어합니다. 과도한 mocking은 테스트가 구현에 강하게 결합되어 리팩토링 시 테스트가 깨지고, 실제 통합 오류를 발견하지 못하는 문제를 야기합니다. 따라서 핵심 비즈니스 로직은 mock 없이 테스트하고, 외부 의존성만 선택적으로 대체하는 것이 바람직합니다.

커버리지 목표치를 강제하면 테스트 품질보다 숫자 채우기에 집중하여 의미 없는 테스트가 증가하고, 중요한 엣지 케이스는 놓치는 문제가 발생합니다. 라인 커버리지는 코드 줄 실행 여부만 측정하고, 브랜치 커버리지는 if-else 분기를 모두 테스트했는지, 조건 커버리지는 복합 조건의 true/false 조합을 검증했는지 측정합니다. 커버리지 외에 뮤테이션 테스트(Stryker) 스코어, 테스트 실행 시간, 플래키 테스트 비율, 평균 수정 시간(MTTR)을 함께 추적해야 합니다. Istanbul 사용 시 node_modules는 제외하고, 테스트 파일 자체는 커버리지에서 제외하며, 트랜스파일된 코드가 아닌 원본 소스 기준으로 측정하도록 source-map 설정이 필요합니다. 핵심 비즈니스 로직은 높은 커버리지를 유지하되, 단순 getter/setter, 설정 파일, 외부 라이브러리 래퍼는 낮은 커버리지를 허용하는 차별화된 기준을 적용합니다.

실제 DB를 사용하면 프로덕션 환경과 동일한 동작을 보장하지만 테스트 속도가 느리고 환경 구성이 복잡하며, 인메모리 DB는 빠르지만 DB 고유 기능(트리거, 프로시저, 특정 데이터 타입)을 테스트할 수 없습니다. Testcontainers는 Docker 컨테이너로 실제 DB를 격리 실행하여 두 장점을 결합하며, 테스트 종료 시 자동으로 정리됩니다. 트랜잭션 롤백 방식은 빠르지만 커밋 후 동작(예: DB 트리거)을 테스트할 수 없고, 직접 정리 방식은 느리지만 완전한 통합을 검증합니다. 테스트 간 데이터 격리 실패 시 이전 테스트의 데이터가 다음 테스트에 영향을 주어 플래키 테스트가 발생하고, 테스트 순서에 따라 결과가 달라지는 비결정적 동작이 나타납니다. 따라서 각 테스트는 독립적으로 실행 가능해야 하며, DB 시드 데이터를 명시적으로 관리하고, 테스트별 네임스페이스나 UUID를 사용하여 데이터 충돌을 방지합니다.

첫 단계는 Characterization Test(승인 테스트)를 작성하여 현재 동작을 캡처하고, 리팩토링 중 회귀를 감지할 안전망을 구축합니다. God Object는 Extract Method로 작은 함수를 분리하고, Extract Class로 책임을 나누며, 각 단계마다 테스트를 실행하여 동작 보존을 확인합니다. 콜백 헬은 Promise로 변환한 후 async/await로 평탄화하되, 한 번에 하나씩 점진적으로 변환합니다. Strangler Fig 패턴은 새로운 코드로 기능을 재작성하고 라우팅 레이어에서 점진적으로 트래픽을 이동시켜 레거시를 단계적으로 대체하며, Branch by Abstraction은 인터페이스 레이어를 도입하여 구현을 교체할 수 있게 합니다. 각 리팩토링은 작은 커밋으로 나누어 진행하고, 기능 플래그를 사용하여 언제든 롤백 가능하도록 하며, 모니터링을 강화하여 성능 저하나 오류를 즉시 감지합니다. 비즈니스 가치가 높은 핫스팟부터 우선순위를 두어 리팩토링합니다.

효과적인 코드 리뷰는 자동화 가능한 항목(포맷팅, 린트, 타입 체크)은 ESLint, Prettier, TypeScript로 CI에서 처리하고, 리뷰어는 비즈니스 로직 정합성, 보안 취약점, 성능 이슈, 테스트 충분성, API 설계에 집중합니다. 우선순위는 1) 보안과 데이터 무결성, 2) 아키텍처 일관성과 설계 원칙, 3) 성능과 확장성, 4) 테스트 품질, 5) 가독성 순입니다. PR 크기는 400줄 이하로 제한하여 리뷰 부담을 줄이고, 기능별로 작게 나누어 제출합니다. 리뷰 병목 해소를 위해 팀 내 코드 오너십을 분산하고, 페어 프로그래밍으로 리뷰 부담을 사전에 줄이며, 리뷰 응답 SLA(예: 4시간 이내)를 설정합니다. 건설적인 피드백 문화를 위해 질문 형태로 의견을 제시하고, 대안을 함께 제안하며, 칭찬도 포함하여 심리적 안전성을 높입니다. 정기적인 코드 리뷰 회고를 통해 프로세스를 개선합니다.

플래키 테스트를 줄이기 위해 고정된 타임아웃 대신 Playwright의 auto-waiting이나 Cypress의 retry-ability를 활용하여 요소가 실제로 상호작용 가능할 때까지 대기합니다. 네트워크 요청은 cy.intercept()나 page.route()로 모킹하여 외부 의존성을 제거하고 응답 시간을 제어합니다. 애니메이션은 CSS 설정으로 비활성화하거나 테스트 환경에서 duration을 0으로 설정합니다. 테스트 데이터는 각 테스트마다 독립적으로 생성하고, 테스트 종료 후 정리하여 데이터 의존성을 제거합니다. 실행 시간 단축을 위해 병렬 실행(Playwright의 workers, Cypress의 parallelization)을 활용하고, 스모크 테스트와 풀 테스트를 분리하여 커밋마다는 핵심 플로우만, 배포 전에는 전체를 실행합니다. 헤드리스 모드로 실행하고, 실패 시에만 스크린샷과 비디오를 저장하여 스토리지 비용을 절감합니다. Page Object Model 패턴으로 UI 변경에 대한 테스트 유지보수성을 높입니다.

부하 테스트는 예상 트래픽에서 정상 동작을 확인하고, 스트레스 테스트는 시스템 한계를 찾아 장애 지점을 파악하며, 스파이크 테스트는 급격한 트래픽 증가 시 시스템 반응을 검증하고, 내구성 테스트는 장시간 운영 시 메모리 누수나 성능 저하를 확인합니다. k6는 JavaScript로 시나리오를 작성하고 대규모 부하 생성이 가능하며, Artillery는 YAML 설정으로 간단히 구성하고 CI 통합이 쉽습니다. 실제 트래픽 패턴 시뮬레이션을 위해 프로덕션 로그를 분석하여 API 호출 비율, 피크 시간대, 사용자 세션 패턴을 반영하고, ramping-up 시나리오로 점진적 부하 증가를 구현합니다. 성능 병목 식별을 위해 응답 시간 백분위수(p95, p99), 처리량(TPS), 에러율을 측정하고, Node.js 프로파일러(clinic.js, 0x)로 CPU 핫스팟을 찾으며, 데이터베이스 슬로우 쿼리 로그와 APM 도구(New Relic, Datadog)로 전체 트랜잭션을 추적합니다. 개선 후 A/B 테스트로 성능 향상을 검증하고, 성능 회귀를 방지하기 위해 CI에서 지속적으로 실행합니다.

변경 영향 분석을 위해 Git diff를 기반으로 수정된 파일과 의존성 그래프를 분석하여 영향받는 테스트만 실행하며, Nx나 Turborepo 같은 빌드 시스템의 affected 명령을 활용합니다. 테스트 결과는 해시 기반 캐싱으로 동일한 코드에 대해 재실행을 방지하고, 원격 캐시를 공유하여 팀 전체가 이점을 누립니다. 병렬 실행 최적화를 위해 테스트를 실행 시간 기준으로 샤딩하여 각 워커에 균등하게 분배하고, Jest의 --maxWorkers나 Playwright의 sharding을 활용합니다. 플래키 테스트는 자동 재실행 결과를 추적하여 재실행 빈도가 높은 테스트를 quarantine 스위트로 분리하고, 주기적으로 수정합니다. 빠른 피드백을 위해 유닛 테스트는 pre-commit hook에서, 통합 테스트는 PR 생성 시, E2E 테스트는 머지 후 실행하는 계층화된 전략을 사용합니다. 비용 최적화를 위해 스팟 인스턴스나 자동 스케일링을 활용하고, 테스트 실행 통계를 분석하여 불필요한 테스트를 제거하며, 컨테이너 이미지 캐싱으로 시작 시간을 단축합니다.