이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 Terraform을 처음 사용해 네트워크 인프라를 코드로 관리하는 경험을 했습니다. 처음에는 수동으로 설정하던 보안 그룹 규칙을 코드화하면서, 변경 이력이 Git에 남는다는 점이 가장 큰 이점임을 실감했습니다. 팀원과 공유하면서 코드 리뷰를 통해 실수를 미리 잡을 수 있다는 것도 경험했습니다.
terraform plan으로 실제 적용 전 변경 사항을 미리 확인하는 방식이 처음에는 번거롭게 느껴졌지만, 예상치 못한 리소스 삭제를 한 번 경험하고 나서부터 드라이런을 어김없이 거치는 방식으로 바뀌었습니다. 롤백 측면에서는 상태 파일이 손상됐을 때 어떻게 복구하는지 직접 겪어봐야 안다는 게 한계로 남아 있습니다.
인프라 코드화가 운영 안정성보다 협업 속도에 더 즉각적인 효과를 준다는 걸 이 경험에서 배웠습니다.
IaC로 관리하던 인프라가 수동 변경으로 인해 코드와 달라진 경험이 있습니다. Terraform으로 구성한 네트워크 인프라를 운영 중 긴급 조치로 콘솔에서 직접 규칙을 추가했습니다. 이후 terraform plan을 실행했을 때 예상치 못한 변경 항목이 나타났고, 어떤 것이 의도된 상태인지 불명확해졌습니다. 코드와 실제 인프라의 간극이 생기자 IaC의 가장 큰 장점인 재현 가능성이 무너졌습니다. 수동 변경이 누적되면 코드가 진실의 원본이 아닌 참고 문서로 전락한다는 것을 배웠습니다. 이후로는 긴급 조치도 즉시 코드에 반영하고 PR로 추적하는 원칙을 팀과 합의했습니다.
이 실패가 이후 IaC 운영 시 콘솔 직접 변경을 즉시 코드화하는 원칙을 규칙으로 정착시키는 기준이 됐습니다. IaC의 가치는 코드가 항상 실제 인프라의 유일한 진실 원본일 때 유지됩니다.
IaC 기반 인프라를 신규 팀원 입장에서 바라본 경험이 있습니다. 새 환경에 합류했을 때 Terraform 코드만 보고 전체 인프라 구조를 파악하려 했는데, 모듈 간 의존 관계와 변수 흐름을 따라가기가 어려웠습니다. 코드가 잘 작성돼 있어도 구조를 설명하는 다이어그램이나 README가 없으면 온보딩 시간이 배로 걸립니다. 이 경험으로, IaC 자동화는 코드 작성만큼 코드를 읽을 사람을 위한 구조 설명 문서가 함께 있어야 효과가 완성된다는 것을 배웠습니다. 이를 반영해 Terraform 모듈 디렉터리에 모듈 역할·입력·출력·의존 관계를 한 페이지로 요약한 README를 추가하는 방식을 채택했습니다.
이 관점이 이후 IaC 코드를 작성할 때 코드 완성과 온보딩 가이드 작성을 함께 산출물로 두는 습관을 만들었습니다. IaC 자동화의 완성은 코드 실행 가능성만큼 팀 가독성에 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 휴젤 시스템 운영 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.