DevOps 면접은 소프트웨어를 안정적으로 배포할 수 있는지를 봅니다. 코드가 노트북에서 프로덕션까지 어떻게 가는지, 잘 돌아가는지 어떻게 아는지, 그리고 문제가 생겼을 때 무엇을 하는지를 확인하죠. 아래에는 기본 개념부터 대부분의 면접을 좌우하는 시나리오 질문까지, 답변과 함께 20개의 질문을 정리했습니다. 명령어가 나오는 곳에는 도구 자체 문서에서 확인할 수 있는 표준 명령어를 사용했습니다.
기초
1. DevOps란 무엇인가요?
개발과 운영을 하나로 묶어, 소프트웨어를 만들고 테스트하고 릴리스하고 운영하는 전 과정을 하나의 공유된 프로세스로 처리하는 방식입니다. 목표는 더 빠르고 안전한 릴리스, 그리고 문제가 생겼을 때 더 빠른 복구입니다. 문화이자 일련의 관행이며, 도구는 이를 뒷받침하는 수단일 뿐입니다. 직함 하나로 정의되는 것이 아닙니다.
2. 지속적 통합, 지속적 전달, 지속적 배포의 차이는 무엇인가요?
| 관행 | 의미 |
|---|---|
| 지속적 통합 | 개발자가 작은 변경을 자주 병합하고, 병합할 때마다 자동 빌드와 테스트가 실행됨 |
| 지속적 전달 | 파이프라인을 통과한 모든 변경이 릴리스 가능한 상태가 되고, 사람이 릴리스 시점을 결정함 |
| 지속적 배포 | 파이프라인을 통과한 모든 변경이 자동으로 프로덕션에 릴리스됨 |
3. 소프트웨어 전달의 핵심 지표는 무엇인가요?
DORA 연구 프로그램에서 널리 쓰이는 네 가지가 있습니다. 배포 빈도, 변경 리드 타임, 변경 실패율, 서비스 복구 시간입니다. 앞의 두 가지는 속도를, 뒤의 두 가지는 안정성을 측정합니다. 좋은 답변은 속도를 높이기 위해 안정성을 희생하지 않도록 네 가지를 모두 추적한다는 점을 설명합니다.
4. 좋은 CI 파이프라인은 어떤 모습인가요?
- 코드를 체크아웃하고 캐시된 의존성을 복원합니다.
- 빌드합니다.
- 빠른 테스트(단위 테스트)를 먼저 실행하고, 그다음 느린 테스트를 실행합니다.
- 린팅, 의존성 취약점 스캔 같은 정적 검사를 실행합니다.
- 아티팩트(컨테이너 이미지 또는 패키지)를 한 번만 빌드하고 커밋으로 태그합니다.
- 이를 게시하고, 동일한 아티팩트를 모든 환경에 배포합니다.
핵심은 한 번 빌드하고 동일한 아티팩트를 승격시키는 것입니다. 그래야 테스트한 것이 곧 배포하는 것이 됩니다.
버전 관리와 릴리스
5. 브랜치와 릴리스는 어떻게 관리하나요?
두 가지 접근이 일반적입니다. 트렁크 기반 개발은 작은 변경을 메인 브랜치에 자주 병합하고, 기능 플래그로 미완성 작업을 숨깁니다. GitFlow 같은 브랜치 기반 워크플로는 릴리스를 위해 오래 유지되는 브랜치를 사용합니다. 트렁크 기반 개발이 보통 지속적 전달과 더 잘 맞습니다. 병합이 작고 자주 일어나기 때문입니다.
6. 블루-그린 배포와 카나리 배포란 무엇인가요?
| 전략 | 작동 방식 | 롤백 |
|---|---|---|
| 블루-그린 | 동일한 환경 두 개. 유휴 환경에 배포하고 테스트한 뒤 트래픽을 전환 | 트래픽을 다시 전환 |
| 카나리 | 새 버전으로 트래픽의 일부를 보내고 지표를 관찰한 뒤 점진적으로 늘림 | 해당 트래픽 비중을 0으로 되돌림 |
| 롤링 | 인스턴스를 몇 개씩 교체 | 앞으로 진행하거나 롤을 되돌림 |
블루-그린은 추가 용량이 필요합니다. 카나리는 데이터를 보고 결정하기 때문에 좋은 지표가 필요합니다.
7. 기능 플래그란 무엇이고, 왜 사용하나요?
배포 없이 기능을 켜고 끌 수 있는 설정상의 스위치입니다. 코드 배포와 기능 릴리스를 분리해 주고, 소규모 그룹과 테스트할 수 있게 해주며, 문제가 생겼을 때 빠르게 끌 수 있는 수단을 제공합니다. 단점은 오래된 플래그가 쌓인다는 것이므로, 기능이 안정되면 제거해야 합니다.
8. 안전하게 롤백하려면 어떻게 해야 하나요?
이전 아티팩트를 사용 가능한 상태로 유지하고, 배포를 반복 가능하게 만들고, 데이터베이스 변경을 하위 호환되게 만들어야 합니다. 그래야 이전 버전이 새 스키마에서도 여전히 작동합니다. 데이터베이스를 고려하지 않은 롤백 계획은 계획이 아닙니다. 위험한 변경의 경우, 롤백으로 데이터가 유실될 수 있다면 수정 사항을 적용해 앞으로 나아가는 편이 낫습니다.
인프라와 컨테이너
9. Infrastructure as Code란 무엇인가요?
콘솔에서 클릭하는 대신 서버, 네트워크, 권한을 버전 관리되는 파일로 정의하는 것입니다. 이를 통해 환경을 반복 가능하고 검토 가능하며 쉽게 재구축할 수 있습니다. 일반적인 도구로는 Terraform, Pulumi, 그리고 클라우드 제공업체 자체 템플릿이 있습니다. Terraform 면접 질문을 참고하세요.
10. 컨테이너와 가상 머신의 차이는 무엇인가요?
가상 머신은 가상화된 하드웨어 위에 완전한 게스트 운영체제를 포함합니다. 컨테이너는 호스트의 커널을 공유하고 애플리케이션과 그 의존성만 패키징하므로 더 빠르게 시작되고 메모리를 덜 사용합니다. 컨테이너는 가상 머신보다 격리 수준이 낮습니다.
11. 좋은 Dockerfile에는 무엇이 들어가야 하나요?
작고 특정한 베이스 이미지를 사용하고, 변경이 가장 적은 레이어가 먼저 오도록 순서를 정하고(빌드 캐시를 활용하기 위해), 소스 코드를 복사하기 전에 의존성 파일을 복사하고 설치하며, 비루트 사용자로 실행하고, 이미지에 시크릿을 넣지 않습니다. 멀티 스테이지 빌드는 최종 이미지에서 빌드 도구를 제외시킵니다.
12. 왜 Kubernetes인가요?
여러 머신에 걸쳐 컨테이너를 스케줄링하고, 실패한 컨테이너를 재시작하며, 확장하고, 롤링 업데이트와 서비스 디스커버리를 처리합니다. 또한 복잡성을 크게 증가시키므로, 좋은 답변은 언제 사용하지 않을지도 말합니다. 예를 들어 몇 대의 서버에 맞는 작은 앱이나 관리형 플랫폼의 경우입니다. Kubernetes 면접 질문을 참고하세요.
13. 시크릿은 어떻게 관리하나요?
소스 관리나 이미지에 절대 넣지 않습니다. 시크릿 관리자나 플랫폼의 시크릿 저장소를 사용하고, 각 서비스에 필요한 최소한의 접근 권한만 부여하며, 시크릿을 교체하고, 로그에 출력하지 않습니다. 유출되었을 때 무엇을 할지도 말하세요: 폐기하고, 교체하고, 사용 여부를 로그에서 확인합니다.
안정성과 운영
14. 모니터링, 로깅, 트레이싱이란 무엇인가요?
| 신호 | 알려주는 것 |
|---|---|
| 메트릭 | 시간에 따른 시스템 상태, 예를 들어 오류율과 지연 시간 |
| 로그 | 특정 이벤트에서 무슨 일이 있었는지 |
| 트레이스 | 하나의 요청이 여러 서비스를 거쳐 어떻게 이동했는지 |
사용자가 느끼는 증상(오류, 느린 응답)에 대해 알림을 설정하고, 원인(한 머신의 높은 CPU 등)보다는 증상에 더 중점을 둡니다.
15. SLI, SLO, SLA란 무엇인가요?
서비스 수준 지표(SLI)는 측정값입니다. 예를 들어 성공한 요청의 비율입니다. 서비스 수준 목표(SLO)는 그에 대한 목표입니다. 예를 들어 30일 동안 99.9퍼센트입니다. 서비스 수준 협약(SLA)은 고객과의 약속이며, 종종 미달 시 결과가 따릅니다. 100퍼센트와 SLO 사이의 간극은 오류 예산입니다: 위험과 변경을 감수할 수 있는 여유입니다.
16. 프로덕션 서비스가 느립니다. 어떻게 하나요?
- 대시보드와 오류율을 사용해 실제 문제인지, 누가 영향을 받는지 확인합니다.
- 최근에 무엇이 변경되었는지 확인합니다: 배포, 구성 변경, 트래픽 급증.
- 범위를 좁힙니다: 특정 엔드포인트, 리전, 의존성.
- 리소스(CPU, 메모리, 연결)와 다운스트림 서비스를 살펴봅니다.
- 최근 변경이 유력한 원인이라면 먼저 롤백하고 나중에 조사합니다.
- 작업하는 동안 상태를 공유합니다.
면접관은 침착하고 질서 있는 접근 방식과 근본 원인을 찾기 전에 완화하는 태도를 듣고 있습니다.
17. 비난 없는 포스트모템이란 무엇인가요?
장애 후 작성하는 검토 문서로, 누가 실수했는지가 아니라 시스템과 프로세스가 어떻게 실패를 허용했는지에 초점을 맞춥니다. 타임라인, 영향, 원인, 담당자가 있는 구체적인 후속 조치를 다룹니다. 핵심은 배우고 같은 실패가 반복되기 어렵게 만드는 것입니다.
18. 수평 확장과 수직 확장의 차이는 무엇인가요?
수직 확장은 머신에 더 많은 리소스를 제공합니다. 수평 확장은 더 많은 머신을 추가합니다. 수직은 간단하지만 한계가 있고 단일 장애점이 있습니다. 수평은 더 많이 확장할 수 있고 한 머신의 손실을 견디지만, 상태 비저장 서비스나 공유 상태가 필요합니다.
실전
19. 파이프라인을 어떻게 보호하나요?
파이프라인을 변경할 수 있는 사람과 프로덕션에 배포할 수 있는 사람을 제한합니다. 의존성과 이미지에서 알려진 취약점을 스캔하고, 아티팩트에 서명하고 검증하며, 자격 증명을 단기간으로 제한하고 범위를 좁히며, 파이프라인 파일 변경을 코드처럼 검토합니다. 광범위한 권한을 가진 빌드 에이전트는 주요 공격 대상입니다.
20. 잘못된 배포에 대해 말씀해 주세요.
기술 면접 안의 행동 질문입니다. 짧은 이야기로 답하세요: 무엇이 변경되었는지, 어떻게 알아차렸는지, 먼저 무엇을 했는지(보통 완화, 종종 롤백), 무엇을 발견했는지, 이후 반복되지 않도록 무엇을 변경했는지. 면접관이 찾는 것은 비난 없는 표현과 구체적인 후속 조치입니다.
준비 방법
- 저장소, 빌드, 테스트 실행, 컨테이너, 그리고 접근 가능한 환경으로의 배포까지 아우르는 작은 파이프라인을 처음부터 끝까지 구축해 보세요.
- 본인이 겪은 장애나 실패한 릴리스 하나를 설명할 준비를 하세요.
- "서비스가 느리다"는 질문에 대한 답변을 차분하고 정돈된 목록이 될 때까지 소리 내어 연습하세요.
- CI, 컨테이너, 코드형 인프라, 모니터링 등 각 영역에서 도구 이름을 길게 나열하기보다는 하나씩 제대로 아는 도구를 갖추세요.
관련 연습 자료로는 AWS 면접 질문, Terraform 면접 질문, Kubernetes 면접 질문, 컴퓨터 네트워킹 면접 질문 가이드를 참고하세요.
소리 내어 자신의 말로 연습하세요. 이후 녹취록을 확인하면 어디서 말이 길어졌는지, 핵심을 놓쳤는지 파악할 수 있습니다. 실시간 면접이나 평가에서 AI 도구 사용에 관한 고용주의 규칙을 따르세요.
YesToTheOffer로 답변을 연습하세요
소리 내어 리허설하고, 자신의 이력서를 기반으로 한 답변을 받고, 이후 녹취록을 검토하세요. 30분 무료, 구독 없음.
