DevOps 면접에서 탁월한 성과를 거두는 데 필요한 지식과 자신감을 갖추도록 설계된 이 포괄적인 가이드에 오신 것을 환영합니다. 이 문서는 DevOps 전반에 걸쳐 자주 묻는 질문과 상세한 답변을 꼼꼼하게 정리했습니다. 기본 개념 및 CI/CD 파이프라인부터 Infrastructure as Code, 컨테이너화, 보안과 같은 고급 주제까지 모두 다룹니다. 이해도를 높이고자 하는 숙련된 전문가이든, 첫 면접을 준비하는 지망 DevOps 엔지니어이든, 이 자료는 성공을 향한 여정에 귀중한 도구가 될 것입니다. 뛰어들어 모든 DevOps 면접 과제를 정복할 수 있는 통찰력으로 자신을 강화하세요!
답변:
DevOps 는 소프트웨어 개발 (Dev) 과 IT 운영 (Ops) 을 결합한 일련의 관행입니다. 시스템 개발 수명 주기를 단축하고 높은 소프트웨어 품질로 지속적인 제공을 목표로 합니다. 개발팀과 운영팀 간의 협업과 소통을 촉진하여 더 빠른 릴리스와 더 안정적인 환경을 제공합니다.
답변:
지속적 통합 (CI) 은 개발자가 코드 변경 사항을 중앙 저장소에 자주 병합하는 개발 관행입니다. 그런 다음 자동화된 빌드 및 테스트를 실행하여 통합 오류를 조기에 감지합니다. 이 관행은 버그를 신속하게 식별하고 수정하여 코드 품질을 개선하고 통합 문제를 줄이는 데 도움이 됩니다.
답변:
지속적 전달 (CD) 은 모든 변경 사항이 자동화된 테스트 파이프라인을 거치도록 하여 언제든지 소프트웨어를 프로덕션에 릴리스할 수 있도록 보장합니다. 지속적 배포는 파이프라인의 모든 단계를 통과하는 모든 변경 사항을 사람의 개입 없이 자동으로 프로덕션에 배포함으로써 이를 한 단계 더 발전시킵니다. 주요 차이점은 지속적 배포에서 프로덕션으로의 자동화된 배포입니다.
답변:
코드형 인프라 (IaC) 는 개발팀이 소스 코드에 사용하는 것과 동일한 버전 관리를 사용하여 설명적인 모델로 인프라 (네트워크, 가상 머신, 로드 밸런서 등) 를 관리하는 것입니다. 이점으로는 일관성, 반복성, 더 빠른 프로비저닝, 사람의 오류 감소, 재해 복구 개선 등이 있습니다. Terraform 및 Ansible 과 같은 도구가 IaC 에 일반적으로 사용됩니다.
답변:
버전 관리 시스템 (Git 등) 은 코드, 구성 및 인프라 정의의 변경 사항을 추적하는 데 중요합니다. 여러 개발자 간의 협업을 가능하게 하고, 모든 변경 사항에 대한 기록을 제공하며, 브랜칭 및 병합을 용이하게 하고, 이전 상태로 쉽게 롤백할 수 있도록 합니다. 이는 개발 프로세스의 추적성과 안정성을 보장합니다.
답변:
불변 인프라 (Immutable infrastructure) 는 서버 또는 구성 요소가 배포되면 수정되지 않음을 의미합니다. 변경이 필요한 경우 (예: 업데이트 또는 구성 변경), 원하는 변경 사항이 적용된 새 서버를 빌드하여 이전 서버를 교체합니다. 이 접근 방식은 구성 드리프트를 줄이고, 롤백을 단순화하며, 일관성과 안정성을 향상시킵니다.
답변:
마이크로서비스는 애플리케이션이 작고 독립적인 서비스 모음으로 구축되는 아키텍처 스타일로, 각 서비스는 자체 프로세스에서 실행되고 경량 메커니즘을 통해 통신합니다. 서비스의 독립적인 개발, 배포 및 확장을 가능하게 하고, 팀 자율성을 촉진하며, 개별 구성 요소에 대한 더 빠른 릴리스 주기를 용이하게 함으로써 DevOps 와 잘 맞습니다.
답변:
모니터링 및 로깅은 애플리케이션 및 인프라 성능에 대한 가시성을 확보하고, 문제를 사전에 식별하며, 시스템 동작을 이해하는 데 필수적입니다. 문제 해결, 성능 최적화 및 시스템 상태 및 확장성에 대한 정보에 입각한 결정을 내리는 데 중요한 데이터를 제공합니다. 효과적인 모니터링 및 로깅은 신속한 인시던트 대응 및 지속적인 개선을 가능하게 합니다.
답변:
'시프트 레프트' 원칙은 품질 보증, 보안 및 테스트 활동을 소프트웨어 개발 수명 주기 초기로 이동하도록 권장합니다. 프로세스 후반에 버그나 보안 취약점을 찾는 대신, 이러한 문제는 설계 및 개발 단계에서 해결됩니다. 이는 문제 수정 비용을 줄이고 전반적인 소프트웨어 품질 및 보안을 향상시킵니다.
답변:
DevOps 파이프라인은 버전 관리에서 빌드, 테스트 및 배포와 같은 다양한 단계를 거쳐 코드를 가져오는 자동화된 워크플로입니다. 모든 변경 사항이 일관되고 반복 가능한 프로세스를 거치도록 하여 코드 품질 및 배포 가능성에 대한 빠른 피드백을 제공합니다. 이러한 자동화는 CI/CD 달성의 핵심입니다.
답변:
CI/CD는 지속적 통합/지속적 전달 (또는 배포) 을 의미합니다. 소프트웨어 릴리스 프로세스를 자동화하여 더 빠르고 빈번하며 안정적인 배포를 가능하게 하기 때문에 중요합니다. 이는 수동 오류를 줄이고 코드 품질을 개선하며 시장 출시 시간을 단축합니다.
답변:
지속적 전달은 소프트웨어가 항상 배포 가능한 상태를 유지하도록 하며, 프로덕션 배포에는 수동 승인이 필요합니다. 지속적 배포는 전체 프로세스를 자동화하여 모든 단계를 통과하는 모든 변경 사항을 사람의 개입 없이 자동으로 프로덕션에 배포합니다.
답변:
일반적인 도구로는 오케스트레이션을 위한 Jenkins, GitLab CI, GitHub Actions 또는 Azure DevOps 가 있습니다. 버전 관리를 위한 Git, 빌드 자동화를 위한 Maven/Gradle, 코드 품질을 위한 SonarQube, 컨테이너화를 위한 Docker, 오케스트레이션을 위한 Kubernetes 가 있습니다. 자동화된 테스트를 위한 Selenium 도 있습니다.
답변:
보안은 정적 애플리케이션 보안 테스트 (SAST), 동적 애플리케이션 보안 테스트 (DAST) 및 소프트웨어 구성 분석 (SCA) 도구를 통합하여 보장됩니다. 또한 안전한 자격 증명 관리, 이미지 취약점 스캔 및 파이프라인 단계 전반에 걸쳐 최소 권한 원칙을 적용하여 보장됩니다.
답변:
일반적인 단계에는 소스 (코드 커밋), 빌드 (컴파일, 패키징), 테스트 (단위, 통합, 기능 테스트), 스테이징/UAT 배포, 그리고 최종적으로 프로덕션 배포가 포함됩니다. 각 단계는 다음 단계로 진행하기 전에 품질을 보장하는 게이트 역할을 합니다.
답변:
아티팩트는 JAR 파일, Docker 이미지 또는 컴파일된 바이너리와 같이 빌드 단계의 불변 출력입니다. 이는 테스트된 정확히 동일한 패키지가 모든 환경에 배포되도록 보장하여 '내 컴퓨터에서는 작동하는데'와 같은 문제를 방지하고 일관성을 보장하기 때문에 중요합니다.
답변:
실패한 빌드는 개발팀에 즉시 알림 (예: Slack, 이메일) 을 트리거합니다. 파이프라인은 실패한 단계에서 중지되어야 합니다. 배포의 경우, 마지막 안정 버전으로의 롤백 또는 빠른 수정 전략이 사용되며, 종종 자동화된 경고 및 모니터링과 함께 사용됩니다.
답변:
IaC 는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것입니다. CI/CD에서 Terraform 또는 CloudFormation 과 같은 IaC 도구를 사용하면 인프라를 버전 관리하고, 테스트하고, 애플리케이션 코드와 함께 자동으로 배포할 수 있어 일관되고 반복 가능한 환경을 보장합니다.
답변:
블루/그린 배포는 두 개의 동일한 프로덕션 환경 (Blue 및 Green) 을 실행하는 것을 포함합니다. 새로운 릴리스는 비활성 환경 (Green) 으로 이동하며, 테스트가 완료되면 트래픽이 전환됩니다. 이점으로는 다운타임 없는 배포, 쉬운 롤백, 릴리스 중 위험 감소 등이 있습니다.
답변:
모니터링에는 파이프라인 실행 상태, 빌드 시간, 테스트 통과율, 배포 빈도 및 변경에 대한 리드 타임 추적이 포함됩니다. Prometheus, Grafana 또는 내장된 CI/CD 대시보드와 같은 도구가 가시성을 제공합니다. 중요한 지표에는 DORA 지표 (리드 타임, 배포 빈도, 변경 실패율, 복구 평균 시간) 가 포함됩니다.
답변:
IaC 는 소스 코드와 동일한 버전 관리를 사용하여 설명적인 모델로 인프라 (네트워크, 가상 머신, 로드 밸런서 등) 를 관리하는 것입니다. 자동화, 일관성, 반복성 및 더 빠른 배포를 가능하게 하여 수동 오류와 드리프트를 줄이기 때문에 DevOps 에서 중요합니다.
답변:
Terraform 은 여러 제공업체에 걸쳐 인프라를 프로비저닝하기 위한 클라우드에 구애받지 않는 도구입니다. Ansible 은 구성 관리, 자동화 및 오케스트레이션으로, 종종 서버 설정에 사용됩니다. CloudFormation(AWS) 및 ARM 템플릿 (Azure) 은 해당 플랫폼에 대한 클라우드별 IaC 도구입니다.
답변:
명령형 IaC 는 원하는 상태를 달성하기 위한 단계를 정의합니다 (예: 'VM 을 생성하고 소프트웨어를 설치합니다'). 선언형 IaC 는 원하는 최종 상태를 설명하고 도구가 단계를 파악합니다 (예: 'VM 에는 X 소프트웨어가 설치되어 있어야 합니다'). 선언형은 멱등성 (idempotency) 과 더 쉬운 관리로 인해 일반적으로 선호됩니다.
답변:
멱등성은 동일한 IaC 구성을 여러 번 적용해도 의도하지 않은 부작용 없이 항상 동일한 시스템 상태가 된다는 것을 의미합니다. 이는 일관성과 예측 가능성을 보장하여 자동화 스크립트의 안전한 재실행을 가능하게 합니다.
답변:
비밀 정보는 IaC 파일에 하드코딩해서는 안 됩니다. 대신 AWS Secrets Manager, Azure Key Vault, HashiCorp Vault 와 같은 전용 비밀 정보 관리 서비스 또는 환경 변수를 사용하고 IaC 템플릿 내에서 안전하게 참조해야 합니다.
답변:
인프라 드리프트는 IaC 외부에서 수동으로 인프라 변경이 이루어져 정의된 코드와 실제 환경 간의 불일치가 발생하는 경우 발생합니다. IaC 는 코드를 단일 진실 공급원 (single source of truth) 으로 만들어 정기적인 조정 또는 자동화된 롤백을 통해 드리프트를 감지하고 수정함으로써 이를 완화합니다.
답변:
이점으로는 공급업체 종속성 회피, 복원력 향상, 최고의 서비스를 활용하는 것이 있습니다. IaC 의 과제는 다양한 API 및 리소스 모델을 관리해야 하며, Terraform 과 같은 클라우드에 구애받지 않는 도구가 필요하거나 각 클라우드에 대한 별도의 IaC 를 유지해야 하므로 복잡성이 증가합니다.
답변:
IaC 는 일반적으로 인프라 코드를 애플리케이션 코드처럼 취급하여 CI/CD에 통합됩니다. 변경 사항은 린팅 (linting), 유효성 검사 (예: terraform plan) 및 자동화된 배포 (예: terraform apply) 를 위한 파이프라인 단계를 트리거하여 모든 코드 변경과 함께 인프라가 일관되게 프로비저닝되고 업데이트되도록 합니다.
답변:
Terraform 상태 파일은 실제 리소스를 구성에 매핑하고 메타데이터 및 종속성을 추적합니다. Terraform 이 관리하는 리소스를 이해하고, 변경 사항을 감지하고, 업데이트를 계획하는 데 중요합니다. 팀 협업을 위해 원격으로 안전하게 (예: S3, Azure Blob Storage) 저장하고 잠금 (locking) 기능을 사용해야 합니다.
답변:
불변 인프라는 서버 또는 구성 요소가 배포되면 수정되지 않음을 의미합니다. 모든 변경 사항에는 새롭고 업데이트된 인스턴스를 빌드하고 배포한 다음 이전 인스턴스를 교체하는 것이 필요합니다. IaC 는 새롭고 동일한 환경 또는 구성 요소의 일관되고 자동화된 프로비저닝을 가능하게 함으로써 이를 촉진합니다.
답변:
주요 이점은 환경 일관성으로, 애플리케이션이 개발부터 프로덕션까지 동일하게 실행되도록 보장합니다. 컨테이너는 애플리케이션과 해당 종속성을 패키징하여 호스트 시스템과 격리하고 '내 컴퓨터에서는 작동하는데'와 같은 문제를 제거합니다.
답변:
Docker 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정을 포함하여 소프트웨어 조각을 실행하는 데 필요한 모든 것을 포함하는 가볍고 독립적이며 실행 가능한 패키지입니다. Docker 컨테이너는 이미지의 실행 가능한 인스턴스입니다. 컨테이너를 생성, 시작, 중지, 이동 또는 삭제할 수 있습니다.
답변:
컨테이너 오케스트레이션은 컨테이너의 배포, 관리, 확장 및 네트워킹을 자동화합니다. 이는 많은 마이크로서비스를 가진 복잡한 분산 애플리케이션을 관리하고, 고가용성, 로드 밸런싱 및 머신 클러스터 전반에 걸친 효율적인 리소스 활용을 보장하는 데 필요합니다.
답변:
Kubernetes 는 가장 인기 있으며 다양한 환경에 걸쳐 대규모의 복잡한 배포에 사용됩니다. Docker Swarm 은 더 간단하고 Docker 와 통합되어 소규모 설정에 적합합니다. Amazon ECS 및 Azure AKS 는 컨테이너 실행을 위한 클라우드별 관리 서비스입니다.
답변:
Kubernetes 는 Pod 집합에 대한 네트워크 액세스를 추상화하기 위해 Service 를 사용합니다. Service 는 안정적인 IP 주소와 DNS 이름을 제공합니다. Kube-proxy 는 Service 와 관련된 Pod 간에 트래픽을 분산하여 로드 밸런싱을 처리하며, 종종 라운드 로빈 또는 IPVS 를 사용합니다.
답변:
Pod 는 Kubernetes 에서 가장 작은 배포 단위로, 클러스터 내에서 실행 중인 프로세스의 단일 인스턴스를 나타냅니다. 네트워크 네임스페이스, 스토리지 볼륨 및 IPC 와 같은 리소스를 공유하는 밀접하게 결합된 하나 이상의 컨테이너를 포함할 수 있습니다. 이들은 함께 배치되고 함께 스케줄링됩니다.
답변:
Dockerfile 은 이미지를 조립하기 위해 사용자가 명령줄에서 호출할 수 있는 모든 명령을 포함하는 텍스트 문서입니다. 기본 이미지, 종속성, 애플리케이션 코드 및 구성 단계를 정의하여 Docker 이미지를 빌드하는 재현 가능한 방법을 제공합니다.
답변:
Kubernetes 의 영구 스토리지는 PersistentVolumes(PV) 및 PersistentVolumeClaims(PVC) 를 사용하여 달성됩니다. PV 는 클러스터 내의 스토리지 조각이고, PVC 는 사용자가 스토리지에 대한 요청입니다. 그런 다음 Pod 는 PVC 를 마운트하여 Pod 가 다시 시작되거나 이동하더라도 데이터가 지속되도록 보장합니다.
답변:
불변 인프라는 서버 또는 컨테이너가 배포되면 수정되지 않음을 의미합니다. 변경이 필요한 경우 원하는 변경 사항이 포함된 새 이미지 또는 컨테이너를 빌드한 다음 배포하여 이전 것을 대체합니다. 이는 구성 드리프트를 줄이고 일관성 및 안정성을 향상시킵니다.
답변:
Kubernetes Deployment 는 동일한 Pod 집합을 관리하여 원하는 수의 복제본이 실행되도록 보장하고 선언적 업데이트를 제공합니다. Pod 는 단일 인스턴스인 반면, Deployment 는 여러 Pod 의 수명 주기를 관리하여 롤링 업데이트, 롤백 및 자체 복구 기능을 가능하게 합니다.
답변:
모니터링은 문제를 사전에 감지하기 위해 실시간 시스템 상태 및 성능 메트릭에 중점을 둡니다. 로깅은 사후 분석, 디버깅 및 감사를 위해 시간이 지남에 따라 이벤트 및 데이터를 기록하는 것을 포함합니다. 모니터링은 '지금 무슨 일이 일어나고 있는지'를 알려주고, 로깅은 '무슨 일이 일어났는지'를 알려줍니다.
답변:
관찰 가능성의 세 가지 기둥은 로그 (Logs), 메트릭 (Metrics), 추적 (Traces) 입니다. 로그는 개별 이벤트 기록을 제공하고, 메트릭은 시간이 지남에 따른 집계된 숫자 데이터를 제공하며, 추적은 분산 시스템 전반에 걸친 요청의 엔드투엔드 흐름을 보여줍니다. 이 세 가지를 함께 사용하면 시스템 동작에 대한 포괄적인 보기를 얻을 수 있습니다.
답변:
모니터링을 위한 인기 있는 도구로는 Prometheus, Grafana, Datadog, New Relic 이 있습니다. 로깅을 위한 일반적인 선택으로는 ELK Stack(Elasticsearch, Logstash, Kibana), Splunk, Loki, Sumo Logic 이 있습니다. 클라우드 제공업체는 AWS CloudWatch 또는 Azure Monitor 와 같은 자체 네이티브 서비스도 제공합니다.
답변:
알림은 일반적으로 주요 메트릭 (예: CPU 사용률 > 80%, 오류율 > 5%) 에 대한 임계값을 정의하여 설정됩니다. 임계값이 초과되면 알림이 트리거되어 PagerDuty, Slack, 이메일 또는 SMS 와 같은 채널을 통해 담당자에게 전송됩니다. 의미 있는 임계값을 설정하여 알림 피로 (alert fatigue) 를 피해야 합니다.
답변:
런북은 특정 알림 또는 인시던트를 진단하고 해결하기 위한 단계를 설명하는 상세한 가이드입니다. 엔지니어에게 사전 정의된 절차, 명령 및 컨텍스트를 제공하여 문제를 신속하게 해결하고, 평균 해결 시간 (MTTR) 을 줄이며, 일관된 응답을 보장합니다.
답변:
서비스 수준 지표 (SLI, Service Level Indicators) 는 지연 시간 또는 오류율과 같이 서비스 성능의 특정 측면에 대한 정량적 측정입니다. 서비스 수준 목표 (SLO, Service Level Objectives) 는 이러한 SLI 에 대한 목표 값으로, 원하는 서비스 신뢰 수준을 정의합니다. 이는 '좋은' 상태가 무엇인지 정의하고 모니터링 및 알림 전략을 안내하는 데 도움이 됩니다.
답변:
마이크로서비스를 모니터링하려면 서비스 간 요청을 추적하기 위한 분산 추적 (distributed tracing), 중앙 집중식 분석을 위한 집계된 로깅, 각 구성 요소에 대한 서비스별 메트릭이 필요합니다. 추적을 위한 Jaeger/Zipkin, 메트릭을 위한 Prometheus, 중앙 집중식 로깅 솔루션과 같은 도구는 복잡한 상호 작용에 대한 가시성을 확보하는 데 중요합니다.
답변:
로그 집계는 다양한 소스 (애플리케이션, 서버, 네트워크 장치) 의 로그를 중앙 집중식 위치로 수집하는 프로세스입니다. 효율적인 검색, 분석, 시스템 간 이벤트 상관 관계 및 장기 보관에 중요하며, 디버깅 및 감사를 훨씬 쉽게 만듭니다.
답변:
알림 피로는 엔지니어가 너무 많은 중요하지 않거나 중복된 알림을 받아 중요한 알림을 무시하게 되는 현상입니다. 완화 전략에는 실행 가능하고 의미 있는 임계값 설정, 에스컬레이션 정책 사용, 관련 알림 그룹화, 알림 중복 제거 및 억제 구현이 포함됩니다.
답변:
대시보드는 주요 메트릭 및 로그의 시각적 표현을 제공하여 시스템 상태 및 성능에 대한 빠른 개요를 제공합니다. 추세를 식별하고, 이상 징후를 감지하며, 다양한 이해 관계자에게 운영 상태를 전달하여 더 빠른 의사 결정 및 문제 해결을 가능하게 합니다.
답변:
제 접근 방식은 다음과 같습니다. 1. 증상과 범위를 이해합니다. 2. 최근 변경 사항을 확인합니다. 3. 문제를 격리합니다 (예: 네트워크, 애플리케이션, 데이터베이스). 4. 데이터를 수집합니다 (로그, 메트릭). 5. 가설을 세우고 테스트합니다. 6. 수정을 구현하고 검증합니다. 7. 문제와 해결 방법을 문서화합니다.
답변:
top 또는 htop으로 CPU 를 소비하는 프로세스를 식별하는 것부터 시작합니다. 그런 다음 ps aux --sort=-%cpu를 사용하여 더 자세한 정보를 확인합니다. 특정 애플리케이션인 경우 해당 로그와 구성을 확인합니다. 시스템 전체 문제의 경우 커널 오류에 대해 dmesg 또는 기록 데이터에 대해 sar를 확인합니다.
답변:
vmstat, iostat, netstat과 같은 도구를 사용하여 시스템 리소스 (CPU, 메모리, 디스크 I/O, 네트워크 지연 시간) 를 확인합니다. 그런 다음 오류 또는 느린 쿼리에 대해 애플리케이션 로그를 검토합니다. 데이터베이스 성능 메트릭 및 네트워크 패킷 캡처 (예: tcpdump) 도 병목 현상을 파악하는 데 유용합니다.
답변:
먼저 파이프라인 로그에서 특정 오류 메시지 또는 스택 추적을 검토합니다. 실패한 정확한 단계를 확인합니다. 일반적인 원인으로는 종속성 문제, 잘못된 환경 변수, 실패한 테스트 또는 권한 문제가 있습니다. 가능한 경우 로컬에서 실패를 재현해 보겠습니다.
답변:
일반적으로 서비스가 예상 포트 또는 IP 에서 수신 대기하지 않거나 방화벽이 연결을 차단하고 있음을 나타냅니다. 서비스 프로세스가 실행 중인지 (systemctl status 또는 ps aux), 수신 대기 포트 (netstat -tulnp) 를 확인하고 방화벽 규칙 (iptables -L 또는 firewall-cmd --list-all) 을 검사합니다. 네트워크 연결 (ping, telnet) 도 요인입니다.
답변:
제 우선 순위는 복구입니다. 안전하고 빠른 경우 서비스 또는 호스트를 다시 시작해 보겠습니다. 동시에 즉시 데이터를 수집하고 (로그, 메트릭) 필요한 경우 관련 팀에 에스컬레이션합니다. 복구되면 재발을 방지하기 위해 근본 원인 분석을 수행합니다.
답변:
로그, 메트릭 및 경고를 위해 AWS CloudWatch, Azure Monitor 또는 Google Cloud Monitoring 과 같은 클라우드 네이티브 모니터링 서비스를 활용합니다. 더 깊은 통찰력을 얻기 위해 분산 추적 도구 (예: Jaeger, Zipkin) 및 APM 솔루션 (예: Datadog, New Relic) 을 사용하여 마이크로서비스 간의 요청을 추적합니다.
답변:
kubectl describe pod <pod-name>을 사용하여 이벤트 및 조건을 확인합니다. 일반적인 이유로는 리소스 부족 (CPU/메모리), 노드 타인트/허용 (taints/tolerations), 노드 친화도 규칙 또는 영구 볼륨 클레임 문제가 있습니다. 또한 클러스터 전체 문제에 대해 kubectl get events를 확인합니다.
답변:
이미지 이름과 태그가 올바른지 확인합니다. 그런 다음 이미지가 레지스트리에 있는지, 레지스트리에 액세스할 수 있는지 확인합니다. 인증 문제 (예: 잘못된 imagePullSecrets) 가 일반적입니다. 레지스트리에 대한 네트워크 연결도 확인해야 합니다.
답변:
스테이징 또는 사전 프로덕션 환경에서 수정 사항을 철저히 테스트하도록 합니다. 여기에는 단위, 통합 및 회귀 테스트가 포함됩니다. 또한 프로덕션에 배포한 후 주요 메트릭과 로그를 면밀히 모니터링하고 예상치 못한 문제가 발생할 경우 롤백 계획을 준비합니다.
답변:
Shift Left 는 소프트웨어 개발 수명 주기 초기에 보안 관행 및 테스트를 통합하는 것을 의미하며, 마지막에만 적용하는 것이 아닙니다. 이는 취약점을 수정하는 데 비용이 적게 들고 쉬울 때 식별하고 수정하는 데 도움이 되어 전반적인 보안 태세를 개선하고 위험을 줄이기 때문에 중요합니다.
답변:
비밀 관리는 HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault 와 같은 전용 도구를 사용하여 민감한 정보 (API 키, 비밀번호) 를 안전하게 저장하고 검색하는 것을 포함합니다. 이러한 도구는 CI/CD 파이프라인과 통합되어 비밀을 하드코딩하지 않고 런타임에 주입하여 암호화되고 액세스가 제어되도록 합니다.
답변:
IaC 보안은 Terraform, CloudFormation 과 같은 인프라 정의 자체에 보안 모범 사례를 적용하는 것을 포함합니다. 여기에는 잘못된 구성에 대한 IaC 템플릿의 정적 분석, 보안 정책 적용 및 무단 변경을 방지하기 위한 불변성 보장이 포함되어 처음부터 기본 인프라를 보호합니다.
답변:
SAST(정적 애플리케이션 보안 테스팅) 는 소스 코드를 실행하지 않고 취약점을 분석하며, 일반적으로 빌드 단계에서 수행됩니다. DAST(동적 애플리케이션 보안 테스팅) 는 공격을 시뮬레이션하여 실행 중인 애플리케이션의 취약점을 테스트하며, 일반적으로 스테이징 또는 프로덕션 환경에서 수행됩니다. 둘 다 CI/CD에 통합되어 지속적인 보안 피드백을 제공합니다.
답변:
컨테이너 보안은 빌드 시점에 컨테이너 이미지의 취약점을 스캔하고, 신뢰할 수 있는 기본 이미지를 사용하며, 런타임 보안 모니터링을 구현하고, 네트워크 정책을 적용하는 것을 포함합니다. Clair, Trivy 또는 상용 솔루션과 같은 도구는 CI/CD 파이프라인 내에서 이러한 검사를 자동화하는 데 도움이 됩니다.
답변:
최소 권한 원칙은 사용자, 시스템 또는 프로세스가 의도된 기능을 수행하는 데 필요한 최소한의 권한만 부여되어야 함을 규정합니다. DevOps 에서는 IAM 역할, 서비스 계정 및 파이프라인 권한에 적용되어 공격 표면을 줄이고 침해로 인한 잠재적 피해를 제한합니다.
답변:
규정 준수는 시스템 및 프로세스가 GDPR, HIPAA, PCI DSS 와 같은 규제 표준을 준수하도록 보장합니다. DevOps 에서는 자동화가 규정 준수 검사를 파이프라인에 코딩하고, 정책 코드 (policy-as-code) 도구 (예: Open Policy Agent) 를 사용하며, 지속적으로 준수를 입증하기 위한 감사 추적을 생성하여 이를 지원합니다.
답변:
보안 패치 및 취약점 관리는 종속성 및 인프라의 알려진 취약점을 지속적으로 모니터링하는 것을 포함합니다. 자동화 도구는 새로운 CVE 를 스캔하고, 자동화된 패치 프로세스를 트리거하며, 심각도 및 영향에 따라 수정 작업을 우선 순위 지정하며, 종종 CI/CD 파이프라인에 통합하여 수정을 신속하게 배포합니다.
답변:
보안 게이트는 CI/CD 파이프라인 내에서 정의된 검증 지점으로, 파이프라인이 다음 단계로 진행하기 전에 특정 보안 테스트 또는 정책 검사를 통과해야 합니다. 예로는 취약점 스캔 임계값, 코드 품질 메트릭 또는 규정 준수 검사가 있으며, 안전하지 않은 코드가 프로덕션에 도달하는 것을 방지합니다.
답변:
불변 인프라는 서버 또는 구성 요소가 배포되면 절대 수정되지 않음을 의미합니다. 대신 변경 또는 업데이트가 필요한 경우 새롭고 업데이트된 인스턴스를 빌드하고 배포해야 합니다. 이는 일관성을 보장하고 구성 드리프트를 줄이며 문제 발생 시 롤백을 단순화하여 보안을 강화합니다.
답변:
코드형 인프라 (IaC) 는 수동 프로세스 대신 코드를 통해 인프라를 관리하고 프로비저닝하는 관행입니다. 이는 DevOps 에서 자동화, 일관성, 버전 관리 및 인프라 배포의 반복성을 가능하게 하여 오류를 줄이고 전달 속도를 높이는 데 중요합니다.
답변:
지속적 통합 (CI) 은 개발자가 코드 변경 사항을 중앙 리포지토리에 자주 병합한 다음 자동화된 빌드 및 테스트를 실행하는 개발 관행입니다. 그 이점으로는 통합 문제의 조기 감지, 코드 품질 향상, 더 빠른 피드백 루프 및 릴리스 중 위험 감소가 있습니다.
답변:
지속적 전달 (CD) 은 소프트웨어가 항상 릴리스 가능한 상태를 유지하도록 보장합니다. 즉, 모든 변경 사항이 빌드, 테스트되어 언제든지 프로덕션 배포 준비가 완료됩니다. 지속적 배포는 파이프라인의 모든 단계를 통과하는 모든 변경 사항을 사람의 개입 없이 자동으로 프로덕션에 배포함으로써 이를 한 단계 더 발전시킵니다.
답변:
모니터링 및 로깅은 애플리케이션 및 인프라 성능에 대한 가시성을 확보하고, 문제를 사전에 식별하며, 시스템 동작을 이해하는 데 중요합니다. 이를 통해 신속한 문제 해결, 성능 최적화, 용량 계획이 가능하며 시스템 안정성과 가용성을 보장합니다.
답변:
'Shift Left' 원칙은 품질 보증, 보안 및 테스트 활동을 소프트웨어 개발 수명 주기 초기로 이동할 것을 옹호합니다. 잠재적 문제를 더 빨리 해결함으로써 결함 수정 비용을 줄이고 전반적인 소프트웨어 품질을 개선하며 전달 속도를 높입니다.
답변:
마이크로서비스는 작고 느슨하게 결합된 서비스의 독립적인 개발, 배포 및 확장을 촉진함으로써 DevOps 와 잘 일치합니다. 이를 통해 팀은 자율적으로 작업하고, 더 자주, 더 적은 위험으로 변경 사항을 배포하며, 각 서비스에 가장 적합한 기술을 선택하여 민첩성과 지속적 전달을 촉진할 수 있습니다.
답변:
불변 인프라는 서버 또는 구성 요소가 배포되면 절대 수정되지 않음을 의미합니다. 대신 변경이 필요한 경우 업데이트된 구성으로 새 서버를 프로비저닝하고 이전 서버는 사용 중단합니다. 이는 일관성을 보장하고 구성 드리프트를 단순화하며 롤백을 용이하게 합니다.
답변:
버전 관리, 일반적으로 Git 은 모든 코드, 구성 및 인프라 정의를 관리하는 데 있어 DevOps 의 기본입니다. 협업을 가능하게 하고, 변경 사항을 추적하며, 브랜칭 및 병합을 용이하게 하고, CI/CD 파이프라인 및 추적성에 필수적인 완전한 기록을 제공합니다.
답변:
자동화는 코드 커밋부터 배포 및 운영에 이르기까지 전체 수명 주기에 걸쳐 수동적이고 반복적인 작업을 제거하는 DevOps 의 핵심입니다. 속도를 높이고, 사람의 오류를 줄이며, 일관성을 개선하고, 엔지니어가 더 복잡하고 부가 가치가 높은 활동에 집중할 수 있도록 합니다.
답변:
일반적인 어려움으로는 문화적 저항, 자동화 기술 부족, 레거시 시스템 및 보안 문제 등이 있습니다. 이는 강력한 리더십, 교차 기능 교육, 점진적 채택, 최신 도구 투자 및 보안 조기 통합 ('SecOps') 을 통해 해결할 수 있습니다.
답변:
Terraform 또는 Ansible 과 같은 도구를 사용하여 인프라를 정의하고 관리하는 코드형 인프라 (IaC) 를 구현하겠습니다. 이는 일관되고 반복 가능한 배포를 보장하고 인적 오류를 줄입니다. IaC 에 대한 버전 관리 또한 롤백 및 감사를 가능하게 합니다.
답변:
팀 규모가 작고 확장 요구 사항이 불확실한 소규모 신규 애플리케이션의 경우, 모놀리식 아키텍처가 초기 개발에 더 간단하고 빠를 수 있습니다. 독립적인 확장, 기술 다양성 및 복원력이 필요한 크고 복잡한 애플리케이션의 경우, 운영 오버헤드가 있음에도 불구하고 마이크로서비스가 더 선호됩니다.
답변:
모니터링/경고를 통한 탐지, 이해 관계자에게 즉시 알림, 사고 책임자 지정. 문제 격리, 가능한 경우 롤백 또는 핫픽스 적용. 해결되면 비난 없는 사후 분석을 수행하여 근본 원인을 파악하고, 교훈을 문서화하며, 예방 조치를 구현합니다.
답변:
파이프라인은 코드 커밋 시 트리거되고, 단위/통합 테스트를 실행하며, 각 서비스에 대한 Docker 이미지를 빌드하고 컨테이너 레지스트리로 푸시합니다. 그런 다음 새 이미지 태그로 Kubernetes 매니페스트 (예: Helm 차트) 를 업데이트하고 E2E 테스트를 위해 스테이징에 배포한 후 프로덕션으로 배포합니다.
답변:
초기에는 비용 효율적이라면 수직적 확장 (CPU/RAM 증가) 을 고려할 것입니다. 장기적인 확장을 위해서는 샤딩, 복제 (읽기 복제본) 또는 Cassandra 와 같은 분산 데이터베이스 솔루션이나 관리형 NoSQL 서비스로 마이그레이션하는 것과 같은 기술을 사용하는 수평적 확장이 중요합니다.
답변:
메인 브랜치로 병합하기 전에 필수적인 풀 리퀘스트 (PR) 검토를 구현하겠습니다. 그런 다음 CI 파이프라인은 PR 시 자동으로 트리거되어 모든 테스트를 실행합니다. 프로덕션 배포는 성공적인 CI 실행 후에만 메인 브랜치에서 허용됩니다.
답변:
별도의 환경에 이전 버전 (파랑) 과 함께 새 버전 (초록) 을 배포합니다. 초록 환경이 완전히 테스트되면 로드 밸런서를 전환하여 트래픽을 초록으로 보냅니다. 문제가 발생하면 트래픽을 즉시 파랑으로 되돌려 다운타임을 최소화할 수 있습니다.
답변:
HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault 와 같은 전용 비밀 정보 관리 솔루션을 구현하겠습니다. 이러한 도구는 비밀 정보 저장을 중앙 집중화하고, 액세스 제어 및 감사를 제공하며, 애플리케이션이 런타임에 동적으로 비밀 정보를 검색할 수 있도록 합니다.
답변:
IaC 를 사용하여 변경하고, 스테이징 환경에서 철저히 테스트하고, 단계적 배포 전략 (예: 카나리 배포 또는 기능 플래그) 을 구현하겠습니다. 모니터링 및 롤백 계획을 마련하고 이해 관계자와의 지속적인 소통을 유지하겠습니다.
답변:
메트릭 (Prometheus/Grafana), 로그 (ELK/Loki) 및 분산 추적 (Jaeger/OpenTelemetry) 을 포함하는 포괄적인 모니터링 스택을 구현하겠습니다. 이를 통해 서비스 상태, 요청 흐름에 대한 가시성을 확보하고 서비스 전반의 성능 병목 현상을 파악하는 데 도움이 됩니다.
답변:
주요 고려 사항에는 애플리케이션 리팩토링 요구 사항, 데이터 마이그레이션 전략, 보안, 비용 최적화 및 네트워크 연결이 포함됩니다. 단계에는 평가, 파일럿 마이그레이션, 데이터 전송, 애플리케이션 배포, 테스트 및 전환이 포함되며 이후 최적화가 이어집니다.
답변:
정보 (로그, 메트릭, 최근 변경 사항) 를 수집하는 것부터 시작합니다. 그런 다음 문제 영역을 격리하고 가설을 세웁니다. 이러한 가설을 체계적으로 테스트하고 필요한 경우 변경 사항을 롤백하며 이해 관계자에게 상태 업데이트를 자주 전달합니다.
답변:
공유 목표, 공통 도구 및 교차 기능 교육을 옹호합니다. '빌드한 사람이 운영한다'와 같은 관행과 비난 없는 사후 분석을 구현하면 공유 책임 및 지속적인 개선 문화가 조성됩니다.
답변:
IaC 는 수동 프로세스 대신 코드를 사용하여 인프라를 관리하고 프로비저닝합니다. 이점으로는 일관성, 반복성, 버전 관리, 더 빠른 프로비저닝 및 인적 오류 감소가 있어 더 안정적인 환경을 제공합니다.
답변:
즉시 해당 개발자와 관련 팀에 알릴 것입니다. 제 우선순위는 중단된 변경 사항을 되돌리거나 신속하게 수정하여 파이프라인 기능을 복원한 다음, 개발자와 협력하여 근본 원인을 파악하고 재발을 방지하는 것입니다.
답변:
Prometheus, Grafana 및 Datadog 을 사용했습니다. 주요 메트릭에는 CPU/메모리 사용량, 네트워크 I/O, 요청 지연 시간, 오류율 (예: 5xx 오류), 처리량 및 애플리케이션별 비즈니스 메트릭이 포함됩니다.
답변:
Docker 로 애플리케이션을 컨테이너화하고, Dockerfile 을 작성하고, 이미지를 관리한 경험이 있습니다. Kubernetes 를 사용해서는 YAML 매니페스트를 사용하여 애플리케이션을 배포, 확장 및 관리했으며 Pod, Deployment, Service 및 Ingress 와 같은 개념을 이해하고 있습니다.
답변:
수동적이고 빈번하며 오류가 발생하기 쉬운 작업을 식별합니다. 그런 다음 적절한 도구 (예: Python/Bash 스크립팅, Ansible, Terraform) 를 선택하여 자동화하고, 작고 관리 가능한 부분부터 시작하여 반복합니다.
답변:
배포 중에 중요한 구성 단계를 놓쳐 중단이 발생했습니다. 철저한 배포 전 체크리스트, 동료 검토 및 CI/CD 파이프라인에 자동화된 검증 단계를 구현하여 이러한 오류를 포착하는 것의 중요성을 배웠습니다.
답변:
업계 블로그를 정기적으로 읽고, 웨비나에 참석하고, 오픈 소스 프로젝트를 팔로우하고, 온라인 커뮤니티에 참여합니다. 또한 개인 또는 샌드박스 환경에서 새로운 도구를 직접 실험하는 데 시간을 할애합니다.
답변:
AWS, 특히 EC2, S3, RDS, VPC, IAM 및 CloudWatch 에 대한 실무 경험이 있습니다. 애플리케이션을 배포 및 관리하고, 네트워킹을 구성하고, AWS 생태계 내에서 보안 모범 사례를 구현했습니다.
DevOps 면접을 효과적으로 준비하는 것은 철저한 준비에 달려 있습니다. 이 문서는 CI/CD, 자동화, 클라우드 플랫폼 및 협업 관행에 대한 이해를 명확하게 설명하는 데 필요한 기초 지식을 제공하는 일반적인 질문과 통찰력 있는 답변에 대한 포괄적인 개요를 제공했습니다. 이러한 개념을 숙달하고 실무 경험을 보여주는 것은 모든 면접 환경에서 자신감과 성과를 크게 향상시킬 것입니다.
DevOps 환경은 끊임없이 진화하고 있다는 점을 기억하십시오. 이 가이드는 강력한 시작점을 제공하지만, 지속적인 학습과 실무 경험은 지속적인 성공을 위해 가장 중요합니다. 새로운 기술을 수용하고, 문제 해결 기술을 연마하고, 호기심을 유지하십시오. 성장에 대한 헌신은 올바른 역할을 확보하는 데 도움이 될 뿐만 아니라 역동적인 DevOps 세계에서 번영할 수 있도록 힘을 실어줄 것입니다.
