이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 Docker를 처음 써봤습니다. 이전에는 팀원마다 개발 환경이 달라서 '내 환경에서는 됐는데'라는 상황이 반복됐는데, Dockerfile로 환경을 정의하고 나서 환경 불일치 문제가 사라졌습니다. docker-compose로 앱·DB·캐시를 한 번에 띄우는 구성을 만들었고, 새 팀원이 명령어 한 줄로 로컬 환경을 세팅할 수 있게 됐습니다. 이후 쿠버네티스 실습에서 파드 자동 복구가 동작하는 걸 직접 확인했는데, 서비스를 수동으로 재시작하는 작업이 자동으로 이뤄지는 걸 보고 오케스트레이션이 운영에서 만드는 가치를 실감했습니다. 컨테이너가 서버에서 직접 돌리는 것과 달리 자원을 격리하고 필요한 만큼만 할당하는 구조도 배포 예측 가능성을 높여줬습니다.
환경을 코드로 정의하는 것이 배포 시스템 전체를 안정적으로 만드는 출발이라는 걸 배웠습니다.
도커·오케스트레이션에서 트레이드오프를 의식하게 된 경험은 소규모 프로젝트에서 쿠버네티스 학습 비용이 더 컸던 케이스였습니다. 오케스트레이션의 자동 복구 기능을 경험하고 나서 모든 프로젝트에 적용하고 싶었는데, 실제 소규모 프로젝트에서 쿠버네티스를 설정하는 데 드는 시간이 서비스 자체보다 많은 상황이 됐습니다.
Docker Compose로도 충분한 규모에서 쿠버네티스를 쓰는 것은 과한 선택이 될 수 있다는 것을 이해했습니다. 오케스트레이션 도구는 서비스 규모와 팀 운영 역량에 맞는 것을 선택하는 것이 맞고, 기술 자체가 항상 최선인 것은 아니다라는 결이 생겼습니다.
도커·오케스트레이션에서 운영을 의식하게 된 경험은 컨테이너 이미지 버전 관리가 안 됐을 때 어느 버전이 배포됐는지 알 수 없었던 케이스였습니다. 처음에 이미지 태그를 latest로만 관리하다 보니 어느 버전이 실제로 실행 중인지 파악하기 어려운 상황이 생겼습니다.
커밋 해시나 버전을 이미지 태그에 포함하는 방식으로 바꾼 뒤 어떤 코드가 실행 중인지 추적이 가능해졌습니다. 컨테이너 환경에서 이미지 버전 관리는 배포 추적과 롤백의 기반이고, 명확한 태그 전략이 없으면 운영에서 혼란이 생긴다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.