이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Docker의 가장 큰 장점은 환경 일관성이었습니다. 개발 환경과 배포 환경이 달라 생기는 문제를 Dockerfile 하나로 해결할 수 있었고, 팀원마다 로컬 셋업에 시간을 쓰는 문제가 사라졌습니다.
반면 단점은 이미지 레이어가 쌓이면 빌드 시간이 길어지는 것이었습니다. 최적화하지 않으면 수백 MB짜리 이미지가 쌓여 레지스트리 저장 비용도 올라갔습니다. 멀티 스테이지 빌드로 개선했지만 초기에는 이 부분이 불편했습니다.
Kubernetes는 자동 복구와 무중단 배포가 가장 큰 장점이었습니다. 파드가 죽으면 자동으로 재시작되고, 롤링 업데이트로 서비스를 중단 없이 교체하는 경험이 인상적이었습니다. 다만 초기 학습 곡선이 가파르고, YAML 설정 파일이 많아지면서 관리 복잡성도 올라갔습니다.
졸업 프로젝트에서 Docker로 컨테이너화는 하루 만에 해결됐는데, 여러 컨테이너를 묶어 운영하려고 Kubernetes를 처음 도입하면서 이틀을 설정 파일만 붙잡았습니다. Pod, Service, Deployment 개념을 한꺼번에 이해해야 했고, YAML 설정 오류가 어디서 났는지 찾는 것도 어려웠습니다. 결국 팀 프로젝트 일정이 촉박해 Kubernetes를 포기하고 docker compose로 대체했습니다. 팀 규모와 서비스 복잡도 대비 오버엔지니어링이었다는 걸 돌아봤습니다. 지금 기준으로는 작은 팀의 단순 서비스에 Kubernetes는 관리 부담 대비 얻는 게 적고, 서비스 수가 늘어날 때 도입을 검토하는 편이 낫다는 생각을 갖게 됐습니다.
인턴 기간에 Docker 이미지가 1.2GB로 커서 배포할 때마다 시간이 오래 걸린다는 문제가 있었습니다. 처음에는 이미지 크기가 왜 중요한지 몰랐는데, CI 빌드 시간의 절반이 이미지 push/pull에서 나온다는 걸 알게 됐습니다. Dockerfile을 들여다보니 node_modules가 통째로 들어가 있었고, 빌드 캐시도 활용되지 않는 구조였습니다.
multi-stage 빌드를 도입해 빌드 환경과 실행 환경을 분리했고, 실행에 필요 없는 dev 의존성을 제외했습니다. 이미지 크기가 180MB로 줄었고 배포 시간도 절반이 됐습니다. 컨테이너 이미지는 작을수록 배포 속도와 보안 면에서 유리하다는 걸 이 경험으로 처음 직접 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부동산플래닛 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.