TypeScript 리드·아키텍트 기술면접

공유 타입은 독립적인 npm 패키지로 관리하며 Semantic Versioning을 엄격히 적용합니다. Breaking change는 메이저 버전 업데이트로 표시하고, 최소 2개 버전 동안 deprecated 필드를 유지하는 점진적 마이그레이션 전략을 사용합니다. 타입 정의와 함께 런타임 검증 스키마(Zod, io-ts 등)를 함께 배포하여, 각 서비스의 경계에서 실제 데이터를 검증합니다. API Gateway나 서비스 진입점에서 스키마 검증을 수행하고, 검증 실패 시 상세한 로그와 함께 요청을 거부합니다. 타입 변경 시 Consumer-Driven Contract Testing을 도입하여 의존하는 모든 서비스의 호환성을 사전 검증하고, 모노레포 환경이라면 의존성 그래프 분석을 통해 영향 범위를 자동으로 파악합니다.

데이터베이스 암호화(TDE)는 물리적 저장소 탈취를 방어하지만 애플리케이션 레벨 침해에는 무력하므로, 민감 필드는 애플리케이션 레벨에서 추가 암호화합니다. TypeScript에서는 crypto 모듈로 AES-256-GCM을 사용하며, 암호화 키는 AWS KMS나 HashiCorp Vault 같은 전용 키 관리 서비스에서 관리합니다. 검색이 필요한 필드는 HMAC 기반 토큰화나 Format-Preserving Encryption을 적용하고, 완전 동형 암호화는 성능 오버헤드가 크므로 제한적으로 사용합니다. 개인정보는 목적별로 암호화 키를 분리하고, 데이터 주체의 삭제 요구 시 해당 키만 폐기하는 crypto-shredding 전략을 구현합니다. 암호화/복호화 작업은 성능 병목이 될 수 있으므로 Redis 같은 인메모리 캐시에 복호화된 데이터를 단기 보관하되, 캐시 레이어에도 접근 제어와 감사 로그를 적용합니다.

B-Tree는 제자리 업데이트(in-place update) 방식으로 데이터를 수정하며, 균형 잡힌 트리 구조로 읽기 성능이 일관되게 우수합니다. 반면 LSM-Tree는 쓰기를 메모리에 버퍼링했다가 순차적으로 디스크에 기록하는 append-only 방식으로, 쓰기 처리량이 매우 높지만 읽기 시 여러 레벨을 탐색해야 하므로 읽기 성능은 상대적으로 낮습니다. B-Tree는 읽기 중심 워크로드(OLTP, 트랜잭션 처리)에 적합하고, LSM-Tree는 쓰기 중심 워크로드(로그 수집, 시계열 데이터, 분석)에 유리합니다. TypeScript 애플리케이션에서 실시간 분석 플랫폼을 구축한다면 Cassandra나 ScyllaDB(LSM-Tree 기반)를, 전통적인 트랜잭션 시스템이라면 PostgreSQL(B-Tree 기반)을 선택하는 것이 일반적입니다. 하이브리드 워크로드라면 RocksDB 같은 임베디드 LSM-Tree를 쓰기 버퍼로 사용하고 주기적으로 B-Tree 기반 DB로 동기화하는 Lambda Architecture를 고려할 수 있습니다.

트래픽 라우팅은 Istio나 AWS App Mesh 같은 서비스 메시를 활용하여 5% → 25% → 50% → 100% 단계로 점진적으로 증가시킵니다. 각 단계에서 에러율, 응답 시간(P95, P99), 비즈니스 메트릭(전환율, 주문 성공률 등)을 Prometheus로 수집하고, 임계값 초과 시 자동 롤백하는 규칙을 정의합니다. OpenTelemetry를 사용해 요청마다 배포 버전을 태그로 추가하여, Jaeger나 Zipkin에서 버전별 트레이스를 비교 분석합니다. 카나리 버전의 오류 전파를 막기 위해 Circuit Breaker 패턴을 적용하고, 하위 서비스 호출 시 타임아웃을 짧게 설정합니다. 조직 차원에서는 배포 파이프라인 템플릿을 표준화하고, 모든 서비스가 공통 메트릭(Golden Signals: latency, traffic, errors, saturation)을 노출하도록 강제하며, 배포 전 자동화된 스모크 테스트와 합성 트랜잭션을 실행하는 프레임워크를 구축합니다.

먼저 이벤트 이름을 키로, 페이로드 타입을 값으로 하는 이벤트 맵 인터페이스를 정의합니다. 조건부 타입을 사용해 특정 이벤트 이름에 대응하는 페이로드 타입을 추출하는 유틸리티 타입을 만들고, emit 함수는 이벤트 이름을 제네릭으로 받아 해당 페이로드 타입만 허용하도록 제약합니다. 템플릿 리터럴 타입으로 이벤트 이름 패턴을 검증하여, 예를 들어 'user:created', 'order:updated' 같은 네이밍 컨벤션을 타입 레벨에서 강제할 수 있습니다. on 함수도 동일하게 타입 안전성을 보장하여, 잘못된 페이로드 타입을 받는 핸들러는 컴파일 오류를 발생시킵니다. 실무적으로는 이벤트 이름 오타로 인한 런타임 버그를 완전히 제거하고, 리팩토링 시 IDE의 자동 완성과 타입 체크로 안전하게 이벤트 시스템을 변경할 수 있으며, 새 개발자도 타입 정의만 보고 사용 가능한 이벤트와 페이로드 구조를 즉시 파악할 수 있습니다.

효과적인 답변은 (1) Situation: 기술 전환이 필요했던 구체적 배경과 팀 상황, (2) Task: 리더로서 해결해야 했던 과제와 목표, (3) Action: 반대 의견을 경청하고 데이터 기반으로 의사결정한 과정, POC나 스파이크를 통한 검증, 점진적 도입 계획, 학습 지원 방안 등 구체적 행동, (4) Result: 최종 결과와 팀의 변화, 그리고 개인적으로 배운 리더십 교훈을 포함해야 합니다. 특히 기술적 우수성만이 아니라 팀의 역량, 비즈니스 일정, 리스크 허용도를 종합적으로 고려한 의사결정 과정을 보여주고, 반대 의견을 존중하면서도 명확한 근거로 방향을 제시한 경험이 중요합니다. 결과적으로 팀원들이 변화를 수용하고 성장했다는 점, 그리고 의사결정 과정에서 투명성과 참여를 보장했다는 점을 강조하면 좋습니다.

중앙값 추적을 위해 최대 힙과 최소 힙 두 개를 사용하여, 작은 절반은 최대 힙에, 큰 절반은 최소 힙에 저장합니다. 새 값이 추가될 때마다 두 힙의 크기 균형을 맞추면 중앙값은 O(1)에 조회 가능하고, 삽입은 O(log n)입니다. 슬라이딩 윈도우 구현을 위해서는 타임스탬프와 값을 함께 저장하는 큐를 유지하고, 만료된 이벤트를 제거할 때 해당 값을 힙에서도 삭제해야 하는데, 이는 O(n) 비용이 듭니다. 이를 최적화하기 위해 lazy deletion을 사용하여, 힙의 top에서 값을 꺼낼 때만 만료 여부를 확인하고 제거합니다. TypeScript 구현 시 JavaScript에는 내장 힙이 없으므로 직접 구현하거나 라이브러리를 사용하며, 대용량 처리를 위해서는 근사 알고리즘(t-digest, quantile sketch)을 고려할 수 있습니다. 공간 복잡도는 윈도우 크기에 비례하는 O(w)이며, 메모리 제약이 있다면 샘플링이나 reservoir sampling을 적용합니다.