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

먼저 Go 모듈 캐싱과 Docker 멀티 스테이지 빌드를 활용해 빌드 시간을 단축합니다. 각 서비스의 go.mod 파일을 기반으로 의존성 그래프를 생성하고, Directed Acyclic Graph(DAG)를 구성하여 배포 순서를 자동 결정합니다. GitHub Actions나 GitLab CI의 matrix 전략으로 독립적인 서비스들을 병렬 빌드하고, 공통 라이브러리는 별도 artifact registry에서 관리합니다. 변경 감지는 Git diff를 분석해 영향받는 서비스만 선택적으로 빌드하며, Bazel이나 Nx 같은 모노레포 도구를 활용해 증분 빌드를 구현합니다. Argo Workflows나 Tekton으로 복잡한 배포 오케스트레이션을 선언적으로 관리하고, 각 단계별 게이트웨이를 두어 품질 검증을 자동화합니다.

gRPC는 HTTP/2 기반 long-lived connection을 사용하므로 Pod 종료 시 기존 연결이 즉시 끊기지 않는 문제가 있습니다. preStop hook에서 단순 sleep만 두는 것이 아니라, /healthz 엔드포인트를 비활성화하고 충분한 시간(15-30초)을 두어 로드밸런서가 트래픽을 중단하도록 합니다. Kubernetes의 iptables 규칙 업데이트와 실제 트래픽 차단 사이에 시간차가 있으므로, terminationGracePeriodSeconds를 60초 이상으로 설정합니다. 서버 측에서는 grpc.Server의 GracefulStop()을 호출하여 새 요청은 거부하고 기존 스트림은 완료될 때까지 대기하도록 구현합니다. 클라이언트 측에서는 gRPC의 client-side load balancing을 활성화하고, keepalive 설정으로 죽은 연결을 감지하며, retry policy를 구성해 일시적 오류를 처리합니다. 추가로 Pod Disruption Budget(PDB)을 설정해 동시에 종료되는 Pod 수를 제한합니다.

먼저 멀티 스테이지 빌드를 적용해 빌드 스테이지는 golang:1.21 이미지를 사용하고, 최종 런타임은 distroless나 scratch 이미지를 사용합니다. CGO를 사용하지 않는다면 CGO_ENABLED=0으로 정적 링크 바이너리를 생성해 scratch 이미지에서 실행 가능하게 합니다. 디버깅이 필요한 경우 distroless/base-debian11을 사용하거나, 프로덕션용과 디버그용 이미지를 별도로 빌드합니다. 레이어 캐싱 최적화를 위해 go.mod와 go.sum을 먼저 COPY하고 go mod download를 실행한 후 소스코드를 복사합니다. .dockerignore 파일로 불필요한 파일을 제외하고, 빌드 시 -ldflags='-s -w'로 디버그 심볼을 제거해 바이너리 크기를 줄입니다. 최종적으로 10-50MB 수준의 이미지를 달성할 수 있으며, Trivy 같은 도구로 취약점 스캔을 CI에 통합합니다.

먼저 OpenTelemetry SDK를 도입해 trace ID, span ID를 생성하고 이를 모든 로그와 메트릭에 컨텍스트로 포함시킵니다. Go의 context.Context를 통해 trace ID를 전파하고, structured logging(zerolog, zap)으로 모든 로그에 trace_id, span_id 필드를 자동 추가합니다. Prometheus 메트릭에는 exemplar를 활용해 특정 메트릭 포인트에 trace ID를 연결하여 메트릭 이상치를 클릭하면 해당 트레이스로 이동 가능하게 합니다. Grafana를 단일 진입점으로 사용하여 Tempo(분산 트레이싱), Loki(로그), Prometheus(메트릭)를 통합 쿼리하고, trace ID 기반 correlation을 구성합니다. 서비스 메시(Istio)를 사용한다면 자동으로 분산 트레이싱 헤더를 전파하고, 커스텀 미들웨어로 HTTP/gRPC 요청마다 컨텍스트를 주입합니다. SLO 기반 알림을 설정하고, 알림에 관련 대시보드와 런북 링크를 포함시켜 MTTD와 MTTR을 단축합니다.

즉시 롤백은 위험하므로 먼저 데이터 영향도를 분석합니다. 가능하다면 hotfix로 새 버전이 구 스키마도 읽을 수 있도록 긴급 패치를 배포하고, 데이터 정합성을 복구하는 백그라운드 작업을 실행합니다. 근본적으로는 Expand-Contract 패턴을 도입해 스키마 변경을 3단계로 진행합니다: 1) 새 컬럼/테이블 추가(애플리케이션은 아직 사용 안 함), 2) 애플리케이션 배포하여 새 스키마 사용, 3) 구 컬럼/테이블 제거. 각 단계는 별도 배포로 진행하고 충분한 검증 시간을 둡니다. 데이터베이스 마이그레이션은 golang-migrate나 Atlas를 사용해 버전 관리하고, dry-run 모드로 먼저 검증합니다. 카나리 배포 시 데이터베이스 쿼리 에러율을 모니터링하고, 자동 롤백 조건에 포함시킵니다. Blue-Green 배포 시에도 두 버전 모두 동일 스키마에서 동작하도록 하위 호환성을 보장합니다.

먼저 Kustomize overlays나 Helm values 파일로 환경별 설정을 계층화하여 관리하고, base 설정은 공통으로 두고 환경별 차이만 오버라이드합니다. 시크릿은 Sealed Secrets나 External Secrets Operator를 사용해 Git에 암호화된 형태로 저장하거나, AWS Secrets Manager/Vault와 연동합니다. ArgoCD ApplicationSet을 활용해 여러 클러스터와 환경을 선언적으로 정의하고, Git 디렉토리 구조나 클러스터 라벨 기반으로 자동 생성합니다. 프로덕션 배포는 ArgoCD의 Sync Windows와 manual sync 옵션으로 승인 프로세스를 구현하거나, GitHub Actions에서 PR 승인 후 manifest를 업데이트하는 방식을 사용합니다. 드리프트 감지는 ArgoCD가 자동으로 수행하며, auto-sync와 self-heal을 활성화해 수동 변경사항을 자동 복구합니다. 멀티 클러스터는 ArgoCD의 cluster credential을 등록하고, ApplicationSet의 cluster generator로 관리하며, 각 클러스터별 health 상태를 모니터링합니다.

먼저 Prometheus와 Grafana로 각 서비스의 실제 CPU/메모리 사용량을 수집하고, 90-95 percentile 값을 분석하여 적정 request/limit을 산출합니다. Goldilocks나 robusta 같은 도구로 자동으로 권장 리소스를 분석합니다. VPA(Vertical Pod Autoscaler)를 recommendation 모드로 먼저 실행해 제안값을 검토하고, 트래픽이 적은 서비스부터 점진적으로 적용합니다. HPA는 CPU 기반 스케일링에서 커스텀 메트릭(요청 큐 길이, 응답 시간) 기반으로 전환해 더 정확한 스케일링을 구현합니다. Go 애플리케이션의 경우 GOMAXPROCS를 컨테이너 CPU limit에 맞춰 설정하고, 메모리는 GC 튜닝(GOGC, GOMEMLIMIT)으로 최적화합니다. 리소스 쿼터와 LimitRange로 네임스페이스별 리소스 사용을 제한하고, PodDisruptionBudget으로 가용성을 보장합니다. 비용 절감을 위해 Karpenter나 Cluster Autoscaler로 노드 스케일링을 자동화하고, spot 인스턴스를 활용합니다.