IaC 설계·운영 역량 확인
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
부트캠프 프로젝트에서 AWS VPC, EC2, RDS, S3, IAM Role을 Terraform으로 IaC화했습니다. 애플리케이션 코드와 인프라 코드를 같은 Git 저장소에서 관리해 변경 이력을 추적했습니다. 변경 관리는 terraform plan으로 예상 변경 사항을 사전 확인한 뒤, 팀원 PR 리뷰를 거친 후에만 apply를 실행하는 규칙을 지켰습니다. 롤백 전략으로는 상태 파일을 S3 + DynamoDB 잠금으로 원격 관리하면서 이전 상태를 보존했고, 문제가 생기면 직전 커밋으로 apply를 재실행하는 방식을 썼습니다. 완전한 자동화 롤백은 구현하지 못했지만 단계별 검증과 상태 잠금이 실수를 막는 데 가장 효과적이었습니다. 이 경험에서 인프라도 코드처럼 리뷰와 버전 관리를 거쳐야 안정성을 높일 수 있다는 걸 체감했습니다.
Terraform으로 인프라를 IaC화할 때 단순히 리소스를 코드로 옮기는 것보다 모듈 구조로 재사용성을 확보하는 것이 장기 유지보수에 더 중요합니다. 초기에는 환경별(dev/staging/prod)로 거의 동일한 코드가 반복됐는데, 공통 인프라 패턴을 모듈로 추출해서 환경 변수만 다르게 주입하는 방식으로 중복을 제거했습니다.
Terraform 모듈이 인프라 코드의 DRY(Don't Repeat Yourself) 원칙을 실현하는 핵심 구조입니다. 모듈화 이후에는 새 환경을 추가할 때 기존 모듈을 재사용하면 되기 때문에, 온보딩 비용과 설정 불일치 위험이 크게 줄었습니다. 모듈 버전 관리를 함께 적용하면 변경 사항이 모든 환경에 일관되게 전파됩니다.
인프라 코드도 소프트웨어처럼 설계되어야 관리가 가능합니다. Terraform 모듈 구조가 IaC의 확장성을 결정하는 기반입니다.
Terraform을 도입한 이후에도 콘솔에서 수동으로 변경된 리소스가 코드와 달라지는 드리프트(drift) 문제가 생겼습니다. 이를 탐지하기 위해 주기적으로 terraform plan을 실행해서 실제 인프라와 코드 상태의 차이를 자동으로 알림으로 받는 파이프라인을 구성했습니다.
드리프트 감지(Drift Detection) 자동화가 "코드가 진실의 원천"이라는 원칙을 유지하는 운영 메커니즘입니다. 정책 검사는 OPA(Open Policy Agent)를 통해 보안 그룹 오픈 포트나 퍼블릭 버킷 생성을 사전에 차단하는 방식으로 구성했습니다. 이 두 가지 자동화가 없으면 IaC를 도입해도 실제로는 수동 변경이 축적되면서 코드 신뢰성이 떨어집니다.
IaC는 도구가 아니라 규율이고, 자동화가 그 규율을 지킵니다. 드리프트 감지 파이프라인이 Terraform 운영의 신뢰성을 보장하는 핵심 장치입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.