TypeScript 리드/아키텍트 트러블슈팅 면접

먼저 프로덕션 환경에서 힙 메모리 사용량과 GC 패턴을 모니터링하여 메모리 누수 여부를 확인합니다. Node.js의 --inspect 플래그와 Chrome DevTools를 활용해 힙 스냅샷을 주기적으로 수집하고, 두 스냅샷 간 비교를 통해 증가하는 객체를 식별합니다. TypeScript에서 흔한 패턴으로는 이벤트 리스너 해제 누락, RxJS 구독 해제 누락, 클로저에서 대용량 객체 참조 유지, WeakMap 대신 Map 사용으로 인한 참조 유지 등이 있습니다. clinic.js나 0x 같은 프로파일링 도구로 메모리 할당 핫스팟을 찾고, 의심되는 코드 경로에 대해 격리된 테스트 환경에서 재현합니다. 근본 원인 수정 후에는 메모리 사용량 알림 임계값 설정, 주기적인 힙 덤프 자동화, 그리고 CI/CD에 메모리 프로파일링 테스트를 추가하여 재발을 방지합니다.

먼저 영향받는 서비스들의 node_modules와 빌드 아티팩트를 완전히 제거하고 재빌드하여 캐시 문제를 배제합니다. 각 서비스의 tsconfig.json 설정, 특히 strict 옵션, skipLibCheck, typeRoots 등의 차이를 비교합니다. 공통 라이브러리의 타입 선언 파일과 실제 JavaScript 구현이 일치하는지 확인하고, 타입 가드나 런타임 검증 로직이 누락되지 않았는지 점검합니다. TypeScript의 구조적 타이핑 특성상 명목적 타입이 필요한 경우 브랜드 타입 패턴이 적절히 사용되었는지 확인합니다. 문제의 근본 원인은 대부분 타입 선언만 변경하고 런타임 구현을 함께 변경하지 않았거나, 타입 단언(as)의 과도한 사용으로 타입 체크를 우회한 경우입니다. 재발 방지를 위해서는 공통 라이브러리에 대한 통합 테스트 강화, Zod나 io-ts 같은 런타임 타입 검증 라이브러리 도입, 그리고 타입 변경 시 Breaking Change로 분류하는 버전 관리 정책이 필요합니다.

먼저 APM 도구나 OpenTelemetry로 요청의 전체 트레이스를 수집하여 어느 구간에서 시간이 소요되는지 파악합니다. GraphQL에서 흔한 N+1 문제를 의심하여 DataLoader가 올바르게 구성되었는지, 특히 요청별로 새 인스턴스가 생성되는지 확인합니다. Node.js의 --prof 플래그나 0x 도구로 CPU 프로파일을 생성하여 핫스팟을 찾고, async_hooks를 활용해 비동기 작업의 체인과 대기 시간을 분석합니다. TypeScript의 복잡한 타입 연산이나 데코레이터가 런타임에 과도한 오버헤드를 발생시키는지 확인하고, 특히 리플렉션 메타데이터 사용 여부를 점검합니다. 캐시가 작동하지 않는 원인으로는 캐시 키 생성 로직의 변경, 객체 참조 비교 문제, 또는 TTL 설정 오류를 확인합니다. 문제 해결 후에는 성능 회귀를 방지하기 위해 주요 쿼리에 대한 성능 벤치마크 테스트를 CI에 추가하고, 응답 시간 P95/P99 메트릭에 대한 알림을 설정합니다.

먼저 CI 환경과 로컬 환경의 Node.js 버전, TypeScript 버전, 그리고 package.json의 의존성 버전이 정확히 일치하는지 확인합니다. package-lock.json이나 yarn.lock 파일이 커밋되어 있고 CI에서 이를 사용하는지 검증합니다. 간헐적 실패는 대부분 병렬 빌드나 타입 체크 과정에서의 race condition, 또는 incremental 빌드 설정으로 인한 캐시 오염이 원인입니다. tsconfig.json의 incremental 옵션을 비활성화하거나, CI에서 tsbuildinfo 파일을 매번 삭제하는 것으로 해결할 수 있습니다. 또한 모노레포 환경에서는 프로젝트 간 의존성 빌드 순서가 보장되지 않아 발생할 수 있으므로 Turborepo나 Nx 같은 빌드 오케스트레이션 도구를 도입합니다. 파일 시스템의 대소문자 구분 차이(macOS vs Linux)도 확인이 필요하며, CI 로그를 상세 모드로 수집하여 실패 패턴을 분석합니다.

먼저 문제가 발생한 API 핸들러의 요청 처리 코드를 추적하여 타입 단언(as), any 타입 사용, 또는 non-null assertion(!.) 연산자가 사용된 부분을 찾습니다. 외부에서 들어오는 요청 데이터는 TypeScript 타입 시스템의 보호를 받지 못하므로, 런타임에 실제로 타입을 검증하는 로직이 필요합니다. class-validator나 Zod 같은 스키마 검증 라이브러리를 사용하여 요청 DTO를 검증하고, 검증 실패 시 명확한 에러 응답을 반환하도록 수정합니다. 또한 API 클라이언트 측에서 선택적 필드를 보내지 않았거나, 직렬화/역직렬화 과정에서 필드가 누락되는 경우도 확인합니다. 재발 방지를 위해서는 모든 외부 입력에 대해 런타임 검증을 필수화하고, strict 모드를 활성화하며, ESLint 규칙으로 타입 단언과 any 사용을 제한합니다. 통합 테스트에서 다양한 엣지 케이스(누락된 필드, 잘못된 타입 등)를 명시적으로 테스트합니다.

먼저 이벤트 핸들러들이 비동기로 실행되면서 서로의 완료를 기다리지 않고 동시에 같은 엔티티를 조회-수정하는 race condition을 의심합니다. 낙관적 잠금이 제대로 작동하려면 버전 체크와 업데이트가 원자적으로 실행되어야 하는데, 트랜잭션 범위가 이벤트 핸들러 전체를 포괄하지 못하면 효과가 없습니다. 각 이벤트 핸들러의 실행 컨텍스트와 트랜잭션 경계를 명확히 하고, 필요시 비관적 잠금(SELECT FOR UPDATE)을 고려합니다. Node.js의 단일 스레드 특성에도 불구하고 비동기 작업 사이의 인터리빙으로 인한 동시성 문제가 발생할 수 있으므로, 엔티티별로 작업 큐를 두어 순차 처리를 보장하거나, Redis를 활용한 분산 락을 구현합니다. 또한 이벤트 소싱 패턴을 도입하여 상태 변경을 이벤트 스트림으로 관리하면 동시성 문제를 근본적으로 해결할 수 있습니다. 문제 재현을 위해 부하 테스트 도구로 동시 요청을 시뮬레이션하고, 데이터베이스 격리 수준과 트랜잭션 로그를 분석합니다.

먼저 package.json의 의존성 버전 범위 표기(^, ~)로 인해 마이너나 패치 버전이 자동으로 업데이트되었는지 확인합니다. package-lock.json이나 yarn.lock 파일이 커밋되어 있지 않거나, CI/CD에서 이를 무시하도록 설정된 경우 매번 최신 버전이 설치될 수 있습니다. 또한 직접 의존성이 아닌 전이 의존성(transitive dependency)의 업데이트로 인한 문제일 수도 있으므로, npm ls나 yarn why 명령으로 의존성 트리를 분석합니다. 문제가 된 패키지 버전을 특정한 후, 해당 버전의 변경 사항과 Breaking Change를 확인합니다. 해결 방법으로는 lock 파일을 반드시 버전 관리에 포함하고, 의존성 업데이트는 명시적으로 관리하며, Renovate나 Dependabot으로 자동 PR을 생성하되 자동 머지는 하지 않습니다. 중요한 프로젝트에서는 npm shrinkwrap을 사용하거나, private registry를 구축하여 의존성을 직접 관리하는 것도 고려합니다. 또한 CI/CD에서 의존성 설치 시 --frozen-lockfile 옵션을 사용하여 lock 파일과 불일치 시 빌드를 실패시킵니다.