이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 사이드 프로젝트에서 쿠버네티스 클러스터를 로컬에 구성해 고가용성을 테스트해봤습니다. 처음엔 파드 1개로 서비스를 배포했는데, 파드를 강제로 삭제하면 서비스가 중단되는 상황이 그대로 생겼습니다. 레플리카 수를 3으로 늘리니 하나가 죽어도 나머지 파드가 요청을 이어받아 서비스가 유지됐습니다. 이후 노드 하나를 꺼보는 실험을 했더니, 그 노드에 있던 파드가 다른 노드로 재스케줄됐습니다. 생각보다 빠르게 복구됐는데, 파드 재시작 시간을 줄이는 설정을 찾아보다가 readinessProbe와 livenessProbe 설정이 복구 속도에 영향을 준다는 걸 배웠습니다. 처음엔 이 설정의 차이를 몰라서 둘 다 같은 엔드포인트로 설정했다가 파드가 계속 재시작되는 문제를 겪었습니다. 직접 실험하면서 헬스체크 설정이 왜 중요한지 몸으로 배웠습니다.
졸업 프로젝트에서 팀이 컨테이너 기반 배포를 처음 도입하는 과정에서 파이프라인 설정을 맡았습니다. 이미지를 빌드하고 레지스트리에 올리는 과정은 빠르게 됐는데, 운영 환경과 개발 환경의 설정이 달라서 개발에서 잘 되던 게 운영에서 동작하지 않는 문제가 생겼습니다. 원인은 환경 변수가 이미지에 하드코딩되어 있었던 것이었습니다. 설정을 이미지 밖에서 주입하도록 바꿨고, 환경마다 다른 값을 설정 파일로 관리하는 구조를 만들었습니다. 이후 배포 환경이 추가됐을 때 이미지는 그대로 쓰고 설정만 바꾸는 방식이 됐습니다. 처음엔 빠르게 돌리는 것만 생각하다가 환경 분리를 나중에 해결해야 하는 상황을 만들었는데, 설계 단계에서 환경 분리를 먼저 고려해야 한다는 걸 배웠습니다.
취업 준비 중 클라우드 기반 컨테이너 오케스트레이션 공부를 하면서 관리형 쿠버네티스 서비스가 왜 필요한지를 먼저 이해하려 했습니다. 직접 클러스터를 구성할 때와 비교해보니 노드 업그레이드, 컨트롤 플레인 관리 같은 운영 부담을 줄여주는 것이 핵심이라는 걸 파악했습니다. 실습 환경에서 자동 스케일링 설정을 해보다가 노드가 예상보다 많이 늘어나는 상황이 생겼습니다. 스케일 조건을 너무 민감하게 잡았던 것이 원인이었습니다. 임계값을 조정하며 트래픽 패턴에 맞는 스케일 범위를 찾는 과정을 경험했습니다. 아직 운영 규모 경험은 없지만, 설정 하나가 리소스 사용 전체에 영향을 줄 수 있다는 감각을 실습으로 익혔습니다. 실무에서는 더 복잡한 상황을 만나겠지만, 이 경험이 기반이 될 것 같습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 Tmap Mobility 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.