이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Docker를 처음 도입하면서 환경 일관성 문제를 처음으로 해결했습니다. 팀원 간 OS가 달라서 로컬에서는 동작하지만 다른 환경에서 오류가 나는 경우가 반복됐고, Dockerfile로 실행 환경을 코드화하자 이 문제가 사라졌습니다.
docker-compose로 앱 서버, DB, Redis를 한 번에 띄우는 구조를 만들었고, 개발 환경 세팅 시간이 크게 줄었습니다. 멀티 스테이지 빌드를 적용해 최종 이미지에서 빌드 도구를 제외하니 이미지 크기가 절반 이하로 줄었습니다. Azure는 팀 프로젝트에서 Azure Container Registry와 App Service를 연동해 컨테이너 이미지를 배포하는 파이프라인을 구성했고, 코드 머지 후 자동으로 배포되는 구조를 만들었습니다. 컨테이너 기반 배포는 환경 차이를 코드로 관리하는 것이 가장 큰 가치라는 결을 얻었습니다.
Docker를 도입하기 전과 후의 차이를 가장 명확하게 느낀 것은 개발 환경 세팅 시간이었습니다. 이전에는 새 팀원이 합류하면 환경 세팅에 반나절에서 하루가 걸리는 경우가 있었고, OS 버전이나 패키지 버전 차이로 오류가 생기면 그 원인을 찾는 데 추가 시간이 걸렸습니다.
docker-compose로 개발 환경을 정의하고 나서 새 팀원이 명령어 하나로 앱 서버와 DB를 함께 띄울 수 있었고, 세팅 시간이 30분 이내로 줄었습니다. 환경 차이로 인한 오류도 사라졌습니다. '내 로컬에서는 되는데' 유형의 문제를 해결하는 시간이 없어지니 실제 개발에 집중하는 시간이 늘었습니다.
Azure 배포 파이프라인을 연결했을 때도 유사한 측정 기준이 생겼습니다. 코드 머지 후 배포까지 걸리는 시간이 수동 배포 대비 크게 줄었고, 배포 실패 시 이전 이미지로 롤백하는 것이 가능해졌습니다. 컨테이너와 자동화 파이프라인의 조합은 개발-배포 속도를 측정 가능한 수치로 바꿔주는 자리라는 생각이 남아 있습니다.
Azure를 처음 독립적으로 사용해본 것은 사이드 프로젝트에서 파일 저장소가 필요했을 때였습니다. 서버에 직접 파일을 저장하면 서버가 재시작될 때 파일이 사라지는 문제가 있었고, Azure Blob Storage를 연동해 파일을 외부에 저장하는 방식으로 해결했습니다.
SDK를 통해 업로드와 다운로드를 구현했는데, 처음에는 파일 접근 권한 설정이 복잡하게 느껴졌습니다. 공개 파일은 URL만으로 접근 가능하게 하고, 사용자별 파일은 SAS 토큰으로 시간 제한 접근을 허용하는 방식을 이해하고 나서 설계가 깔끔해졌습니다.
Docker로 컨테이너화한 앱과 Azure Blob Storage를 조합하니 서버를 재시작하거나 스케일 아웃해도 파일 접근에 영향이 없는 구조가 됐습니다. 상태를 서버에 두지 않고 외부에 분리하는 원칙이 Stateless 서버 설계와 자연스럽게 연결된다는 것을 이 경험에서 처음 직접 느꼈습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.