12월 21, 2025
44 분 읽기

시니어 DevOps 엔지니어 면접 질문: 프로덕션 시스템 중심

interview
career-advice
job-search
시니어 DevOps 엔지니어 면접 질문: 프로덕션 시스템 중심
Milad Bonakdar

Milad Bonakdar

작성자

Kubernetes, Terraform 상태, GitOps, 보안, 관측성, 장애 대응, 프로덕션 운영 의사결정을 실무형 질문으로 준비하세요.

시니어 DevOps 면접의 핵심

시니어 DevOps 면접은 도구 이름을 아는지보다 프로덕션 시스템을 운영할 수 있는지를 봅니다. Kubernetes 장애, Terraform 상태 보호, GitOps 배포, 클라우드 복원력, 보안 통제, 관측성, 인시던트 대응을 시나리오로 묻는 경우가 많습니다.

이 가이드를 활용해 무엇을 먼저 확인할지, 어떤 위험을 줄일지, 수정이 효과적인지 어떻게 검증할지, 그리고 engineering, security, product 이해관계자에게 어떤 트레이드오프를 설명할지 연습하세요.

고급 Kubernetes

1. Kubernetes 아키텍처와 핵심 구성 요소의 역할을 설명하세요.

답변: Kubernetes는 컨트롤 플레인과 워커 노드로 구성된 아키텍처를 사용합니다. 좋은 시니어 답변은 구성 요소뿐 아니라 원하는 상태가 시스템에서 어떻게 조정되는지까지 설명합니다.

컨트롤 플레인 구성 요소:

  • API 서버: Kubernetes 컨트롤 플레인의 프런트엔드이며, 모든 REST 요청을 처리합니다.
  • etcd: 클러스터 상태를 위한 분산 키-값 저장소입니다.
  • 스케줄러: 리소스 요구 사항에 따라 파드를 노드에 할당합니다.
  • 컨트롤러 관리자: 컨트롤러 프로세스(복제, 엔드포인트 등)를 실행합니다.
  • 클라우드 컨트롤러 관리자: 클라우드 공급자 API와 통합됩니다.

노드 구성 요소:

  • kubelet: 파드에서 컨테이너가 실행되도록 보장하는 에이전트입니다.
  • kube-proxy: 파드 통신을 위한 네트워크 규칙을 유지합니다.
  • 컨테이너 런타임: 컨테이너를 실행합니다(Docker, containerd, CRI-O).
Loading diagram...

작동 방식:

  1. 사용자가 kubectl을 통해 배포를 제출합니다.
  2. API 서버가 유효성을 검사하고 etcd에 저장합니다.
  3. 스케줄러가 파드를 노드에 할당합니다.
  4. 노드의 kubelet이 컨테이너를 만듭니다.
  5. kube-proxy가 네트워킹을 구성합니다.

희소성: 매우 흔함 난이도: 어려움

2. CrashLoopBackOff 상태에서 멈춘 파드를 어떻게 해결하나요?

답변: 체계적인 디버깅 접근 방식:

# 1. 파드 상태 및 이벤트 확인
kubectl describe pod <파드 이름>
# 이미지 풀 오류, 리소스 제한, 실패한 상태 검사 등을 확인하세요.

# 2. 로그 확인
kubectl logs <파드 이름>
kubectl logs <파드 이름> --previous  # 이전 컨테이너 로그

# 3. 리소스 제약 조건 확인
kubectl top pod <파드 이름>
kubectl describe node <노드 이름>

# 4. 활성/준비 프로브 확인
kubectl get pod <파드 이름> -o yaml | grep -A 10 livenessProbe

# 5. 컨테이너에 접속 (잠시라도 살아있다면)
kubectl exec -it <파드 이름> -- /bin/sh

# 6. 이미지 확인
kubectl get pod <파드 이름> -o jsonpath='{.spec.containers[*].image}'
docker pull <이미지>  # 로컬에서 테스트

# 7. ConfigMap/Secret 확인
kubectl get configmap
kubectl get secret

# 8. 배포/파드 사양 검토
kubectl get deployment <배포 이름> -o yaml

일반적인 원인:

  • 애플리케이션이 시작 시 충돌
  • 누락된 환경 변수
  • 잘못된 활성 프로브 구성
  • 불충분한 리소스 (OOMKilled)
  • 이미지 풀 오류
  • 누락된 종속성

수정 예시:

# 리소스 제한 증가
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# 프로브 타이밍 조정
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # 앱이 시작될 시간을 줍니다.
  periodSeconds: 10
  failureThreshold: 3

희소성: 매우 흔함 난이도: 중간

3. Kubernetes 네트워킹: 서비스, Ingress 및 네트워크 정책을 설명하세요.

답변: Kubernetes 네트워킹 계층:

서비스: 서비스 노출 유형:

# ClusterIP (내부 전용)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (노드 IP를 통한 외부 액세스)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (클라우드 로드 밸런서)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: HTTP/HTTPS 라우팅:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

네트워크 정책: 파드 간 통신 제어:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

희소성: 매우 흔함 난이도: 어려움

4. Kubernetes에서 자동 스케일링을 어떻게 구현하나요?

답변: 다양한 자동 스케일링 전략:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # 또는 "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: 보류 중인 파드를 기반으로 클러스터 크기를 자동으로 조정합니다.

# AWS 예시
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

희소성: 흔함 난이도: 중간

고급 Terraform

5. Terraform 상태 관리와 모범 사례를 설명하세요.

답변: Terraform 상태는 인프라를 추적하며 운영에 매우 중요합니다.

원격 상태 구성:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

상태 잠금:

# 상태 잠금을 위한 DynamoDB 테이블
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

모범 사례:

1. 상태 파일을 Git에 커밋하지 마세요.

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. 환경에 따라 작업 공간을 사용하세요.

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. 기존 리소스를 가져오세요.

# 기존 EC2 인스턴스 가져오기
terraform import aws_instance.web i-1234567890abcdef0

# 확인
terraform plan

4. 상태 조작 (주의해서 사용하세요)

# 상태의 리소스 나열
terraform state list

# 특정 리소스 표시
terraform state show aws_instance.web

# 상태에서 리소스 이동
terraform state mv aws_instance.old aws_instance.new

# 상태에서 리소스 제거 (삭제하지 않음)
terraform state rm aws_instance.web

5. 주요 변경 전에 상태를 백업하세요.

terraform state pull > backup.tfstate

희소성: 매우 흔함 난이도: 어려움

6. 대규모 프로젝트를 위해 Terraform 코드를 어떻게 구성하나요?

답변: 유지 관리를 위한 모듈식 구조:

디렉터리 구조:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

모듈 예시:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "VPC CIDR 블록"
  type        = string
}

variable "environment" {
  description = "환경 이름"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "프라이빗 서브넷 CIDR 블록"
  type        = list(string)
}

variable "availability_zones" {
  description = "가용 영역"
  type        = list(string)
}

variable "tags" {
  description = "공통 태그"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

모듈 사용:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

희소성: 흔함 난이도: 어려움

클라우드 아키텍처

7. AWS에서 고가용성 다중 지역 아키텍처를 설계하세요.

답변: 고가용성을 위한 다중 지역 아키텍처:

Loading diagram...

주요 구성 요소:

1. DNS 및 트래픽 관리:

# 상태 검사를 사용하는 Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. 데이터베이스 복제:

# 리전 간 읽기 복제본이 있는 RDS
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. 데이터 복제:

# S3 리전 간 복제
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

설계 원칙:

  • 활성-활성 또는 활성-수동 설정
  • 상태 검사를 통한 자동 장애 조치
  • 최소 지연 시간으로 데이터 복제
  • 리전 간 일관된 배포
  • 두 리전에 대한 모니터링 및 경고

희소성: 흔함 난이도: 어려움

GitOps 및 CI/CD

8. GitOps와 ArgoCD를 사용하여 이를 구현하는 방법을 설명하세요.

답변: GitOps는 Git을 선언적 인프라 및 애플리케이션을 위한 단일 소스 저장소로 사용합니다.

원칙:

  1. Git의 선언적 구성
  2. 자동 동기화
  3. 모든 변경 사항에 대한 버전 제어
  4. 지속적인 조정

ArgoCD 구현:

# 애플리케이션 매니페스트
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

디렉터리 구조:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

장점:

  • 감사 추적으로서의 Git
  • 간편한 롤백 (git revert)
  • 선언적 원하는 상태
  • 자동 드리프트 감지
  • 다중 클러스터 관리

희소성: 흔함 난이도: 중간

보안 및 규정 준수

9. Kubernetes에서 보안 모범 사례를 어떻게 구현하나요?

답변: 다계층 보안 접근 방식:

1. 파드 보안 표준:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (역할 기반 액세스 제어):

# 개발자를 위한 역할
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. 네트워크 정책:

# 모든 Ingress 거부 기본값
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. 비밀 관리:

# 외부 비밀 운영자
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. 보안 컨텍스트:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. 이미지 스캔:

# OPA가 있는 어드미션 컨트롤러
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v is not from approved registry", [image])
    }

희소성: 매우 흔함 난이도: 어려움

관찰 가능성 및 SRE

10. 포괄적인 관찰 가능성 스택을 설계하세요.

답변: 관찰 가능성의 세 가지 핵심 요소: 메트릭, 로그, 추적

아키텍처:

Loading diagram...

1. 메트릭 (Prometheus + Grafana):

# 앱 메트릭을 위한 ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. 로깅 (Loki):

# 로그 수집을 위한 Promtail 구성
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. 추적 (Jaeger):

# 애플리케이션 계측
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# 추적 설정
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# 코드에서 사용
with tracer.start_as_current_span("process_request"):
    # 코드를 여기에 넣으세요
    pass

4. 경고 규칙:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "높은 오류율 감지"
        description: "오류율은 {{ $value | humanizePercentage }}입니다."
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "높은 지연 시간 감지"

5. SLO 모니터링:

# SLO 정의
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "API 요청이 성공해야 합니다."
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

희소성: 흔함 난이도: 어려움

재해 복구

11. Kubernetes 클러스터에 대한 재해 복구를 어떻게 구현하나요?

답변: 포괄적인 DR 전략:

1. 백업 전략:

# Velero 백업 예약
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 매일 오전 2시
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30일

2. etcd 백업:

#!/bin/bash
# 자동화된 etcd 백업 스크립트

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# S3에 업로드
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# 오래된 백업 정리
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. 복원 절차:

# 스냅샷에서 etcd 복원
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Velero를 사용하여 애플리케이션 복원
velero restore create --from-backup daily-backup-20231125
velero restore describe <복원 이름>

4. 다중 지역 장애 조치:

# 다중 지역 설정을 위한 Terraform
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... 구성
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... 구성
}

# Route 53 상태 검사 및 장애 조치
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. RTO/RPO 목표:

  • RTO (복구 시간 목표): < 1시간
  • RPO (복구 시점 목표): < 15분
  • 정기적인 DR 훈련 (매월)
  • 문서화된 런북
  • 가능한 경우 자동 장애 조치

희소성: 흔함 난이도: 어려움

서비스 메시

12. 서비스 메시 아키텍처와 사용 시기를 설명하세요.

답변: 서비스 메시지는 서비스 간 통신을 위한 인프라 계층을 제공합니다.

핵심 구성 요소:

Loading diagram...

Istio 구현:

# 트래픽 라우팅을 위한 가상 서비스
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# 대상 규칙
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews

사용할 때:

  • 마이크로서비스 간 통신이 복잡한 경우
  • mTLS, 권한 부여, 트래픽 규칙을 일관되게 적용해야 하는 경우
  • 카나리 배포와 트래픽 분할이 필요한 경우
  • 서비스 간 호출의 관측성을 통합해야 하는 경우

주의할 점: 서비스 메시에는 복잡성, 지연 시간, 운영 부담이 추가됩니다. 시니어 면접에서는 해당 시스템에서 이 비용을 감수할 만큼 가치가 있는 이유를 설명해야 합니다.

결론

도구 정의만 외우지 마세요. 각 답변에서 프로덕션 문제를 어떻게 분리하고, 어떤 위험을 우선순위에 두며, 수정 결과를 어떻게 검증하고, 장기 개선으로 어떻게 연결할지 보여주는 것이 중요합니다.

Newsletter subscription

실제로 효과가 있는 주간 커리어 팁

최신 인사이트를 받은 편지함으로 직접 받아보세요

관련 게시물

시니어 네트워크 엔지니어 면접 질문과 답변
12월 21, 2025
35 분 읽기

시니어 네트워크 엔지니어 면접 질문과 답변

OSPF, BGP, SD-WAN, 고가용성, 보안, QoS, 자동화, 문제 해결을 중심으로 시니어 네트워크 엔지니어 면접을 준비하세요.

Milad BonakdarMilad Bonakdar
시니어 GCP 클라우드 엔지니어 면접 질문과 답변
12월 21, 2025
34 분 읽기

시니어 GCP 클라우드 엔지니어 면접 질문과 답변

아키텍처, GKE, Cloud Run, IAM, 비용, BigQuery, 안정성 트레이드오프를 중심으로 시니어 GCP 면접을 준비하세요.

Milad BonakdarMilad Bonakdar
시니어 머신러닝 엔지니어 면접 질문: 프로덕션 ML 대비
12월 21, 2025
48 분 읽기

시니어 머신러닝 엔지니어 면접 질문: 프로덕션 ML 대비

시니어 ML 엔지니어 면접은 시스템 설계, MLOps, 분산 학습, 지연 시간, 모니터링, 트레이드오프 같은 프로덕션 판단력을 평가합니다. 실무형 답변을 연습하세요.

Milad BonakdarMilad Bonakdar

다음 면접은 이력서 하나로 결정됩니다

몇 분 만에 전문적이고 최적화된 이력서를 만드세요. 디자인 기술은 필요 없습니다—입증된 결과만 있으면 됩니다.

내 이력서 만들기

이 게시물 공유

이력서 작성 시간을 90% 단축하세요

평균적인 구직자는 이력서 서식을 작성하는 데 3시간 이상을 소비합니다. 우리 AI는 15분 이내에 완성하여 지원 단계에 12배 더 빠르게 도달할 수 있습니다.

15분 만에 작성