이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 인프라 코드화(IaC)를 처음 도입한 경험이 있습니다. 이전에는 클라우드 콘솔에서 수동으로 리소스를 만들다 보니, 개발·운영 환경 설정이 달라 예상치 못한 동작 차이가 생겼습니다. Terraform으로 전환한 뒤 인프라 설정이 코드 저장소로 들어오면서 환경별 차이를 변수 파일로 명시적으로 관리할 수 있게 됐습니다. 코드 리뷰 프로세스에 인프라 변경이 포함되니 실수가 줄었고, 새 팀원도 저장소를 클론해서 동일 환경을 재현할 수 있었습니다.
인프라를 코드화하면 설정 자체가 문서가 된다는 점이 가장 큰 장점이었는데, 나중에 이유가 기억나지 않는 설정의 맥락을 git log로 확인할 수 있었습니다. 지금도 인프라 변경은 코드 변경과 동일한 리뷰 기준을 적용하는 방향을 선호합니다.
처음 IaC를 도입하면서 Terraform 코드 구조를 혼자 짰는데, 모듈 분리 기준을 잘못 잡아서 환경별로 코드를 복사하는 방식이 됐습니다. 환경이 늘어나면서 동일한 변경을 여러 곳에 반복 적용해야 하는 불편함이 생겼고, 결국 선임 개발자에게 코드 리뷰를 요청했습니다.
워크스페이스나 변수 파일로 환경을 분기하면 코드 중복 없이 환경을 분리할 수 있다는 것을 그때 배웠습니다. 혼자 오래 파고드는 것보다 경험 있는 사람에게 초기에 리뷰를 받는 것이 더 빠른 경우가 있다는 걸 이 경험이 확인시켜줬습니다. 코드를 설명하는 과정에서 내가 놓쳤던 가정이 드러나기도 했고, 리뷰를 받은 뒤에야 왜 이렇게 짜면 안 되는가가 이해됐습니다. IaC는 설계 초기에 구조를 검토받는 비용이 나중에 구조를 뜯는 비용보다 압도적으로 낮다는 것을 이때 배웠습니다.
인프라를 Terraform으로 코드화한 이후에도 콘솔에서 누군가 임시로 수정한 설정이 코드와 달라지는 드리프트(Drift) 문제를 겪었습니다. terraform plan을 실행했을 때 예상치 못한 리소스 변경이 감지됐다는 결과가 나와, 어느 팀원이 언제 왜 바꿨는지를 파악하는 데 시간이 걸렸습니다.
드리프트 자체보다 발견이 늦었다는 것이 더 큰 문제라고 판단해, 주기적으로 terraform plan을 CI에서 돌려 드리프트를 자동 감지하는 파이프라인을 추가했습니다. 감지되면 Slack으로 알림이 가도록 설정했고, 이후에는 콘솔 직접 수정이 불가피할 때 반드시 코드도 함께 업데이트하는 프로세스를 팀 내 규칙으로 정했습니다.
코드화 자체가 끝이 아니라 코드와 실제 인프라의 정합성을 지속적으로 유지하는 것이 IaC 도입의 진짜 목표임을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.