Spring 리드·아키텍트 배포·운영 기술면접

금융 플랫폼에서는 Blue-Green 배포를 기본으로 하되, Canary 배포를 결합한 하이브리드 전략을 권장합니다. Blue-Green은 인프라 비용이 2배이지만 즉각적인 롤백(DNS 전환)이 가능하고 트랜잭션 일관성을 보장하기 쉽습니다. Canary는 5-10%의 트래픽으로 신규 버전을 검증한 후 Blue-Green으로 전환하여 리스크를 최소화합니다. 데이터베이스 스키마 변경은 Backward Compatible 방식으로 3단계(확장-배포-정리)로 진행하며, 각 단계마다 롤백 포인트를 설정합니다. 금융 규제 준수를 위해 모든 배포 단계는 감사 로그에 기록되고, 배포 승인 프로세스는 4-eyes 원칙을 적용합니다. 트랜잭션 중간 상태 처리를 위해 배포 전 진행 중인 트랜잭션을 드레이닝하고, 새 요청은 신규 버전으로 라우팅하는 Connection Draining 전략을 구현합니다.

컨테이너 메모리는 JVM 힙 + 메타스페이스 + 다이렉트 메모리 + 스레드 스택 + 네이티브 메모리를 모두 포함해야 합니다. 일반적으로 resources.limits.memory를 100%로 볼 때, -Xmx는 50-60%, 메타스페이스 10-15%, 다이렉트 메모리 10%, 나머지 20-25%는 오버헤드로 할당합니다. 예를 들어 2GB 컨테이너에서는 -Xmx1200m, -XX:MaxMetaspaceSize=256m, -XX:MaxDirectMemorySize=200m으로 설정하고 약 400MB의 버퍼를 둡니다. resources.requests는 limits의 80-90% 수준으로 설정하여 QoS를 Burstable로 유지하면서도 안정성을 확보합니다. 모니터링은 Prometheus + Grafana로 JVM 메트릭(heap, non-heap, GC)과 컨테이너 메트릭(RSS, cache)을 동시에 수집하고, OOM 발생 시 Heap Dump를 자동으로 저장하도록 -XX:+HeapDumpOnOutOfMemoryError 옵션을 설정합니다. JVM 11 이상에서는 -XX:+UseContainerSupport로 컨테이너 인식을 활성화하고, -XX:InitialRAMPercentage와 -XX:MaxRAMPercentage로 동적 할당을 고려할 수 있습니다.

팀 자율성이 중요하고 서비스 간 결합도가 낮다면 멀티레포를, 공통 라이브러리가 많고 일관된 표준이 필요하면 모노레포를 선택합니다. 멀티레포는 각 서비스가 독립적인 CI/CD 파이프라인을 가져 배포 독립성이 높지만, 공통 라이브러리 버전 관리가 복잡하고 중복 코드가 발생할 수 있습니다. 모노레포는 Gradle Build Cache와 Bazel 같은 도구로 변경된 서비스만 선택적으로 빌드하여 효율성을 높이고, 공통 코드 리팩토링이 용이하지만 파이프라인 복잡도가 증가합니다. 하이브리드 접근으로 공통 라이브러리는 별도 레포지토리로 관리하고 Artifact Repository(Nexus, Artifactory)에 배포하여 버전 관리하는 방식도 고려할 수 있습니다. 조직적으로는 멀티레포가 팀 자율성과 코드 소유권을 명확히 하지만, 모노레포는 크로스팀 협업과 표준화에 유리합니다. 기술 부채 관리는 모노레포에서 공통 라이브러리 업그레이드를 한 번에 처리할 수 있어 효율적입니다.

Metrics(Micrometer + Prometheus)는 시스템 전반의 성능 지표와 비즈니스 메트릭을 시계열로 수집하여 이상 징후를 빠르게 탐지하고, Logging(ELK)은 상세한 이벤트와 에러 스택 트레이스를 저장하여 문제의 컨텍스트를 파악하며, Tracing(Zipkin/Jaeger)은 분산 요청의 전체 흐름과 병목 구간을 시각화합니다. 장애 분석 시 먼저 Metrics 대시보드에서 이상 지표(응답 시간 증가, 에러율 상승)를 발견하고, 해당 시간대의 Trace ID로 분산 추적을 조회하여 느린 서비스를 특정한 후, 해당 서비스의 로그를 Trace ID로 필터링하여 근본 원인을 파악합니다. 데이터 수집 오버헤드 관리를 위해 Metrics는 전수 수집하되 집계 주기를 조정하고, Logging은 ERROR/WARN은 전수, INFO는 샘플링하며, Tracing은 1-10% 샘플링을 적용합니다. 모든 관측성 데이터는 Trace ID, Span ID, 타임스탬프로 상호 연관되도록 Spring Cloud Sleuth로 자동 계측하고, Grafana에서 통합 대시보드를 구성하여 한 화면에서 3가지 데이터를 연계 조회할 수 있도록 합니다.

즉시 Circuit Breaker를 OPEN 상태로 전환하여 신규 트래픽을 차단하고, 진행 중인 트랜잭션은 Graceful Shutdown으로 완료되도록 최대 30초 대기합니다. 애플리케이션은 Blue-Green 방식으로 이전 버전으로 즉시 전환하되, 데이터베이스 스키마는 Backward Compatible 설계 원칙에 따라 롤백하지 않고 유지합니다. 신규 버전에서 생성된 데이터는 버전 플래그 컬럼으로 식별하고, 이전 버전 애플리케이션이 해당 데이터를 읽을 때 호환 로직으로 처리하거나 별도 배치로 보정합니다. 외부 시스템 연동 데이터는 Saga 패턴의 보상 트랜잭션으로 처리하며, 이벤트 소싱 패턴을 적용한 경우 보상 이벤트를 발행하여 정합성을 맞춥니다. 롤백 후 모니터링 대시보드에서 에러율, 응답 시간, 비즈니스 메트릭을 실시간으로 확인하고, 데이터 정합성 검증 쿼리를 실행하여 이상 데이터를 식별합니다. 향후 예방을 위해 Feature Toggle을 도입하여 신규 기능을 런타임에 비활성화할 수 있도록 하고, Canary 배포로 소량 트래픽 검증 단계를 추가합니다.

Multi-stage 빌드로 빌드 도구와 소스 코드는 최종 이미지에서 제외하고 실행 가능한 JAR만 포함시킵니다. Spring Boot 2.3 이상의 Layered JAR 기능으로 dependencies, spring-boot-loader, snapshot-dependencies, application 레이어를 분리하여, 자주 변경되지 않는 dependencies 레이어는 Docker 캐시를 활용합니다. Base 이미지는 eclipse-temurin:17-jre-alpine처럼 JRE 기반 Alpine Linux를 사용하여 크기를 줄이고, JLink로 필요한 JVM 모듈만 포함한 커스텀 런타임을 생성하면 200MB 이하로 줄일 수 있습니다. 보안 취약점 최소화를 위해 Distroless 이미지나 최신 패치가 적용된 베이스 이미지를 사용하고, Trivy나 Snyk로 이미지 스캔을 CI 파이프라인에 통합합니다. .dockerignore로 불필요한 파일을 제외하고, 빌드 캐시 효율을 높이기 위해 변경 빈도가 낮은 명령어를 먼저 배치합니다. 최종적으로 이미지 크기는 200-300MB, 빌드 시간은 캐시 활용 시 1-2분 이내로 최적화할 수 있습니다.

Liveness Probe는 애플리케이션의 데드락이나 무한 루프 같은 복구 불가능한 상태를 감지하여 Pod를 재시작시키므로, 가벼운 검사(예: /actuator/health/liveness)만 수행해야 합니다. Readiness Probe는 트래픽을 받을 준비가 되었는지 확인하여 Service의 엔드포인트에서 제외/포함시키므로, 데이터베이스 연결, 필수 외부 API, 캐시 워밍업 상태를 포함할 수 있습니다. 그러나 외부 의존성을 Readiness에 포함하면 일시적인 네트워크 장애로 모든 Pod가 Not Ready 상태가 되어 전체 서비스 장애로 확대될 수 있으므로, Circuit Breaker 상태나 타임아웃을 짧게 설정하여 영향을 제한해야 합니다. 데이터베이스는 Connection Pool의 Active Connection 수를 확인하는 정도로 가볍게 검사하고, 외부 API는 헬스체크 전용 경량 엔드포인트를 사용합니다. Spring Boot Actuator의 Health Indicator를 커스터마이징하여 비즈니스 크리티컬한 의존성만 포함시키고, initialDelaySeconds, periodSeconds, failureThreshold를 적절히 조정하여 false positive를 방지합니다.

애플리케이션 코드 레포와 배포 매니페스트(Helm Chart, Kustomize) 레포를 분리하여 개발 주기와 배포 주기를 독립적으로 관리합니다. 배포 레포는 환경별 디렉토리(environments/dev, staging, prod)로 구성하고, Kustomize의 overlay 구조로 공통 베이스와 환경별 차이를 관리합니다. ArgoCD Application을 환경별로 생성하고, Auto-Sync 정책으로 Git 커밋 시 자동 배포되도록 설정하되, Production은 Manual Sync로 승인 프로세스를 추가합니다. 시크릿은 Sealed Secrets나 External Secrets Operator로 암호화하여 Git에 안전하게 저장하거나, Vault와 연동하여 런타임에 주입합니다. CI 파이프라인에서 이미지 빌드 후 배포 레포의 이미지 태그를 업데이트하는 커밋을 자동 생성하고, ArgoCD가 이를 감지하여 배포합니다. 롤백은 Git revert 커밋으로 이전 매니페스트 상태로 되돌리면 ArgoCD가 자동으로 반영하며, 모든 배포 이력이 Git 커밋으로 추적되어 감사 추적과 재현이 용이합니다. 배포 상태 모니터링은 ArgoCD UI와 Prometheus 메트릭으로 실시간 확인하고, Slack 알림을 통합합니다.

부하 테스트는 Smoke Test(최소 부하), Load Test(예상 부하), Stress Test(한계 부하), Soak Test(장시간 부하) 4단계로 설계합니다. 목표 지표는 프로덕션 트래픽 분석 결과를 기반으로 설정하되, 평균 TPS의 2배를 처리할 수 있는 여유를 두고, 95 percentile 응답 시간이 SLA(예: 500ms) 이내, 에러율 0.1% 미만을 목표로 합니다. 시나리오는 실제 사용자 행동 패턴(로그인, 조회, 등록 등)을 반영하고, Think Time을 포함하여 현실적인 부하를 생성합니다. Gatling으로 테스트 스크립트를 코드로 관리하고, CI 파이프라인에서 Staging 환경에 배포 후 자동 실행하도록 통합합니다. 성능 기준선(baseline)을 설정하고, 테스트 결과가 기준선 대비 10% 이상 저하되면 파이프라인을 실패시켜 배포를 차단합니다. 결과는 Grafana 대시보드로 시각화하고, InfluxDB에 저장하여 시간에 따른 성능 트렌드를 추적합니다. APM 도구(Pinpoint, New Relic)와 연계하여 성능 저하 구간의 상세 프로파일링을 자동으로 수집합니다.

장애 감지는 Prometheus Alertmanager와 PagerDuty를 통합하여 Critical 알람 발생 시 온콜 엔지니어에게 자동으로 전화/SMS를 발송합니다. 온콜 체계는 Primary와 Secondary 담당자를 지정하고, 15분 내 응답 없으면 에스컬레이션합니다. 장애 대응 단계는 1) 감지 및 초기 대응(5분 이내), 2) 영향 범위 파악 및 임시 조치(Circuit Breaker, 트래픽 차단), 3) 근본 원인 분석 및 수정, 4) 배포 및 검증, 5) 복구 확인으로 구성됩니다. 커뮤니케이션은 Slack Incident 채널을 생성하여 모든 대응 과정을 기록하고, 30분마다 상태 업데이트를 공유하며, 이해관계자에게는 별도 요약 메시지를 전달합니다. 장애 복구 후 48시간 이내에 Blameless Postmortem을 작성하여 타임라인, 근본 원인, 영향 범위, 액션 아이템을 문서화하고, 액션 아이템은 Jira 티켓으로 생성하여 추적합니다. 조직 차원에서는 분기별 Chaos Engineering 훈련으로 장애 대응 역량을 강화하고, Postmortem 리뷰 미팅에서 패턴을 분석하여 공통 개선 사항을 도출합니다. SLO/SLI를 정의하고 Error Budget을 관리하여 안정성과 개발 속도의 균형을 맞춥니다.