TypeScript 주니어 배포·운영 기술면접

CI/CD 파이프라인은 크게 빌드, 테스트, 배포 단계로 구성됩니다. 먼저 빌드 단계에서는 npm install로 의존성을 설치하고, npm run build로 TypeScript를 JavaScript로 컴파일합니다. 테스트 단계에서는 npm test로 유닛 테스트를 실행하고, npm run lint로 코드 품질을 검사합니다. 배포 단계에서는 빌드된 결과물을 서버나 클라우드 플랫폼에 업로드합니다. TypeScript 프로젝트에서는 타입 체크를 위해 tsc --noEmit 명령어를 추가로 실행하여 컴파일 오류를 사전에 확인하는 것이 중요합니다.

Dockerfile은 기본 이미지 선택, 의존성 설치, 소스 복사, 빌드, 실행 단계로 구성됩니다. Multi-stage build를 사용하면 빌드 단계에서만 필요한 devDependencies와 TypeScript 컴파일러를 최종 이미지에서 제외할 수 있어 이미지 크기를 크게 줄일 수 있습니다. 첫 번째 스테이지에서 npm install과 npm run build를 실행하고, 두 번째 스테이지에서는 빌드된 JavaScript 파일과 production 의존성만 복사합니다. node_modules는 .dockerignore에 추가하여 로컬 파일이 복사되지 않도록 하고, 컨테이너 내부에서 npm ci --only=production으로 설치합니다. 또한 Alpine 기반 Node.js 이미지를 사용하면 기본 이미지 크기를 줄일 수 있습니다.

Blue-Green 배포는 기존 버전(Blue)과 새 버전(Green)을 동시에 실행하고, 로드밸런서를 통해 트래픽을 한 번에 전환하는 방식입니다. 문제 발생 시 즉시 롤백이 가능하지만, 두 배의 리소스가 필요합니다. Rolling 배포는 여러 인스턴스 중 일부를 순차적으로 새 버전으로 교체하는 방식으로, 리소스 효율적이지만 배포 중 두 버전이 공존하므로 하위 호환성이 필요합니다. Blue-Green은 중요한 서비스나 데이터베이스 스키마 변경이 있을 때 적합하고, Rolling은 리소스가 제한적이거나 빈번한 배포가 필요한 경우에 적합합니다. TypeScript API 서버에서는 데이터베이스 마이그레이션 전략과 함께 배포 방식을 결정해야 합니다.

헬스체크 엔드포인트는 서버의 기본 동작 여부, 데이터베이스 연결 상태, 외부 의존성 연결 상태 등을 확인합니다. Liveness Probe는 애플리케이션이 살아있는지 확인하여 실패 시 컨테이너를 재시작하고, Readiness Probe는 트래픽을 받을 준비가 되었는지 확인하여 실패 시 로드밸런서에서 제외합니다. Liveness는 간단한 응답만 확인하고, Readiness는 데이터베이스 등 의존성까지 확인하는 것이 일반적입니다. 데이터베이스 연결 확인 시 타임아웃을 짧게 설정하여 헬스체크 자체가 병목이 되지 않도록 해야 하며, 연결 풀의 일부만 사용하여 실제 트래픽에 영향을 주지 않아야 합니다. TypeScript에서는 각 의존성의 상태를 타입 안전하게 반환하도록 구현합니다.

롤백 시 먼저 현재 발생하는 에러의 범위와 영향도를 파악하고, 로그와 모니터링 도구로 근본 원인을 확인해야 합니다. 코드 롤백은 이전 버전의 Docker 이미지를 재배포하거나 Git 태그를 이용해 이전 커밋으로 되돌립니다. 데이터베이스 마이그레이션이 포함된 경우, 새 버전에서 추가된 컬럼이나 테이블이 있다면 이전 코드가 정상 동작하는지 확인해야 합니다. 마이그레이션을 롤백하면 새 버전 배포 중 생성된 데이터가 손실될 수 있으므로, 가능하면 스키마 변경은 하위 호환성을 유지하도록 설계하고, 데이터 마이그레이션과 코드 배포를 분리하는 것이 안전합니다. 롤백 후에는 반드시 헬스체크와 주요 기능 테스트를 수행하여 정상 동작을 확인해야 합니다.