예시 답변 1
약 120초
이미지 사이즈를 측정 기반으로 줄인 결
사이드 프로젝트에서 배포 이미지가 1.2GB까지 커진 자리가 있었습니다. 배포가 느려 원인을 봐야 했습니다.
막연히 손대지 않고 이미지 레이어별 크기를 먼저 확인했더니, 대부분이 빌드 도구와 개발 의존성이 최종 이미지에 그대로 남은 자리였습니다.
그 자리에서 빌드 단계와 실행 단계를 분리해, 실행 이미지에는 빌드 산출물과 런타임만 남겼습니다. 베이스도 필요한 최소 구성으로 바꿨습니다. 결과적으로 1.2GB에서 180MB 정도로 줄었고, 배포 시간도 눈에 띄게 짧아졌습니다.
다만 빌드 단계가 늘면서 Dockerfile이 더 복잡해진 자리는 비용이었습니다. 이 자리에서 배운 건 이미지 최적화는 기법보다 어디가 무거운지 먼저 보는 일이 핵심이라는 부분이었습니다.
이 결의 특징
*측정 → 원인 → 분리 → 결과*의 흐름이 가장 안전합니다. 수치(1.2GB→180MB)와 *복잡도라는 비용*까지 들어가 균형이 좋습니다.
면접관이 다음에 할 행동
*"베이스를 더 줄였을 때 문제는 없었나요?"* 같은 추궁이 따라오는 경우가 많습니다. 더 줄였을 때의 트레이드오프를 인지하고 있어야 답이 끊기지 않습니다.