이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
DevOps 공부를 하면서 GitOps 개념을 처음 접했을 때, 인프라 상태를 코드로 선언하고 Git을 기준으로 동기화한다는 방식이 흥미로웠습니다. 개인 프로젝트에서 Argo CD를 가상 환경에 설치하여 간단한 배포 파이프라인을 구성해보았습니다. 처음에는 Kubernetes 매니페스트를 저장소에 올리고 자동 동기화가 될 것이라고 기대했으나, 헬스체크 설정이 맞지 않아 Argo CD가 계속 동기화 실패로 표시되었습니다. 설정 파일을 수정하면서 어떤 값이 실제 배포 상태와 연결되는지를 하나씩 맞춰나갔습니다. 2주짜리 실습이었는데 절반은 환경 설정에 소요되었습니다.
선언형 구성의 장점은 이해했지만, 실제 운영 환경에서 사용하려면 구성 관리 원칙을 먼저 정해야 한다는 것을 배웠습니다. 선언형 구성 파일 자체가 문서 역할을 한다는 점도 장점이라는 것을 실습하면서 느꼈습니다.
팀 프로젝트에서 Terraform을 써서 클라우드 자원을 코드로 관리하는 방식을 처음 도입해봤습니다. 팀원 각자가 콘솔에서 직접 자원을 만들었더니 누가 뭘 만들었는지 파악이 안 되는 문제가 있었는데, Terraform state 파일로 현재 상태를 한 곳에서 볼 수 있다는 게 편했어요.
state 파일을 로컬에서만 관리하다가 팀원이 동시에 apply를 실행해서 충돌이 생겼습니다. 원격 backend 설정이 필요하다는 걸 그때 알았어요. 이후에 GitLab CI와 연결해서 merge 후에만 apply되도록 했는데, Git이 인프라 변경의 승인 채널이 된다는 게 GitOps의 핵심이라는 걸 직접 느꼈습니다.
Git 이력이 인프라 변경 이력이 되는 구조가 협업에서 왜 유용한지 직접 느낀 경험이었습니다.
클라우드 네이티브 강의에서 GitOps 워크플로우 전체 흐름을 배우면서 자원 라이프사이클 관리가 어떻게 달라지는지 이해했습니다. 기존에는 사람이 직접 명령을 실행해서 자원을 만들거나 삭제하는데, GitOps에서는 변경 사항을 PR로 올리고 merge 이후에 자동으로 적용되는 방식으로 바뀐다는 게 핵심이었어요. 강의 실습에서 Flux를 써서 저장소 변경이 클러스터에 자동 반영되는 걸 확인했는데, 연결이 끊겼을 때 동기화 상태를 어떻게 확인하는지가 생각보다 헷갈렸습니다.
자원 상태의 단일 출처를 Git으로 유지한다는 원칙은 이해했고, 실제 운영 환경에서 어떻게 예외 상황을 다루는지 더 배우고 싶습니다. 동기화 오류 메시지를 해석하는 것부터 연습이 필요하다는 걸 실습에서 배웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.