이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Docker와 Kubernetes를 처음 써본 경험이 있습니다. 팀원 4명이 각자 개발 환경이 달라 로컬에서 잘 되는 코드가 다른 환경에서 오류가 나는 일이 반복됐습니다. Docker로 컨테이너 이미지를 통일해 이 문제를 먼저 해결했고, 이후 테스트 환경을 여러 개 띄워야 할 때 Kubernetes로 파드를 관리했습니다. 처음에는 kubectl 명령어와 yaml 파일 구조에 익숙해지는 데 시간이 걸렸는데, 배포 설정을 팀 공유 레포에 버전 관리하면서 팀원들과 이해를 함께 맞춰나갔습니다. 배포 중 파드가 계속 재시작되는 문제가 생겼을 때는 로그와 이벤트를 먼저 확인해 메모리 제한이 너무 낮았던 것이 원인임을 찾아냈고, 리소스 limit과 request 값을 조정해 해결했습니다. 이 경험 이후 인프라 설정은 문서화와 팀 공유가 같이 가야 한다는 감각이 생겼습니다.
클라우드 컴퓨팅 수업에서 GKE 위에 3-tier 웹앱을 배포하는 실습을 진행했습니다. 처음에는 도커 이미지를 빌드해서 컨테이너 레지스트리에 올리는 흐름 자체가 낯설었는데, Dockerfile을 직접 작성하면서 어떤 의존성이 이미지에 포함되어야 하는지를 명확하게 이해할 수 있었습니다. Kubernetes 쪽에서는 Deployment와 Service 리소스를 분리해서 관리하는 구조가 처음에 헷갈렸습니다. Pod에 직접 접근하는 게 아니라 Service를 통해 트래픽을 라우팅하는 이유를 실습하면서 비로소 이해했습니다. 실습 중에 Rolling Update를 설정했을 때 배포 중 다운타임 없이 교체되는 장면이 인상적이었고, 이 구조가 실서비스에서 왜 중요한지 체감했습니다. 팀원 한 명이 yaml 설정 오류로 Deployment가 계속 pending 상태에 빠졌을 때, `kubectl describe pod` 로그를 같이 들여다보며 원인을 찾아낸 경험이 디버깅 감각을 키우는 데 도움이 됐습니다. 인프라 구성에서 yaml 관리와 로그 해석이 핵심 역량이라는 것을 그 수업에서 확인했습니다.
졸업 프로젝트에서 초반에는 Docker Compose로 멀티 컨테이너를 구성했다가, 후반에 K8s로 전환하는 경험을 했습니다. Compose는 개발 환경에서 빠르게 세팅할 수 있어서 편했는데, 서비스를 늘리면서 컨테이너 간 의존 순서와 헬스체크 관리가 점점 복잡해졌습니다. K8s로 이전하면서는 readinessProbe와 livenessProbe를 처음으로 설정했고, 이 두 가지가 트래픽 분기와 자동 재시작에 직접 연결된다는 걸 실제 장애를 겪으며 배웠습니다. DB 컨테이너가 준비되기 전에 API 서버가 먼저 뜨면서 연결 오류가 반복됐는데, initContainer로 의존 순서를 강제하는 방식으로 해결했습니다. 팀원들과 yaml 파일을 공유하면서 리소스 이름 충돌이 생기기도 했고, 이후에는 네임스페이스를 역할별로 나눠서 관리하는 규칙을 도입했습니다. 이 프로젝트를 통해 K8s의 강점은 선언적 설정에 있지만, 그만큼 설정 오류가 예기치 않은 방식으로 발현된다는 점도 함께 배웠고, 선언한 상태와 실제 상태를 항상 비교하는 습관이 이때부터 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크래프톤 게임 서버 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.