이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Terraform을 써본 건 개인 프로젝트에서 클라우드 인프라를 코드로 관리하려고 시도했을 때입니다. 처음엔 콘솔에서 직접 설정했다가, 같은 환경을 다시 만들어야 할 때 어떤 설정을 했었는지 정확히 기억이 안 되는 문제가 생겼습니다. Terraform으로 바꾸고 나서 설정이 코드로 남아있어서 재현이 쉬워졌습니다. 처음엔 state 파일 관리가 낯설어서 로컬 파일이 실제 인프라와 어긋나는 문제를 겪었는데, 원격 상태 저장소를 쓰는 방식으로 해결했습니다. 인프라를 코드로 다루면 변경 내역이 남고 팀이 함께 관리할 수 있다는 게 가장 큰 장점이라고 느꼈습니다.
변경 추적이 가능한 인프라 관리가 팀 협업에서 얼마나 중요한지를 느꼈습니다.
IaC 도구를 쓰면서 가장 크게 느낀 점은 인프라 변경도 코드 리뷰를 받을 수 있다는 것입니다. 콘솔에서 직접 바꾸면 누가 언제 무엇을 바꿨는지 추적하기 어렵습니다. Terraform으로 변경 사항을 커밋하면 `git` 히스토리로 변경 이유와 시점이 남습니다. 팀 프로젝트에서 인프라 구성을 코드로 관리하면서 한 팀원이 실수로 설정을 잘못 바꿨을 때 이전 상태로 되돌리는 것이 빠르게 가능했습니다. 인프라 관리에서 재현 가능성과 추적 가능성이 얼마나 중요한지를 직접 체감했습니다.
재현 가능성과 추적 가능성이 인프라 관리의 핵심이라는 걸 직접 배웠습니다. 인프라 변경도 코드처럼 검토받을 수 있다는 것이 가장 큰 장점이었습니다.
Terraform을 처음 쓸 때 어려웠던 건 `plan`과 `apply` 단계의 차이를 제대로 이해하지 못했던 것입니다. plan에서 예상한 것과 apply 결과가 다르게 나오는 경우가 있었는데, 의존성 순서를 잘못 잡은 게 원인이었습니다. 그 경험 덕에 `plan` 결과를 꼼꼼하게 읽는 습관이 생겼습니다. 또 모듈화를 일찍 하지 않고 코드를 길게 쓰다가 나중에 재사용이 어려워지는 문제도 겪었습니다.
IaC도 소프트웨어 개발처럼 처음부터 구조를 잘 잡는 것이 나중에 드는 비용을 줄인다는 걸 느꼈습니다. 인프라도 코드처럼 처음부터 구조를 잡는 것이 나중 비용을 줄입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.