이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
테라폼을 처음 써본 건 클라우드 스터디에서였습니다. AWS 리소스를 콘솔에서 수동으로 만들다가 실수로 지우는 일이 반복돼서, 코드로 관리하면 재현이 쉽겠다는 생각에 테라폼을 시도했습니다. 처음에 상태 파일을 로컬에만 두다가 팀원이 다른 컴퓨터에서 apply를 실행해 상태가 꼬이는 문제가 생겼습니다. S3를 백엔드로 설정해서 해결했지만, 설정 방법을 찾는 데 반나절이 걸렸습니다. Heat는 이론으로만 알고 있고 직접 써본 경험은 없습니다. 소규모 실습이었지만 인프라를 코드로 관리할 때 상태 관리가 핵심이라는 걸 배웠습니다.
캡스톤에서 팀원마다 AWS 설정이 달라 환경 불일치가 자주 생겼습니다. 제가 테라폼으로 공통 인프라를 코드화하자고 제안했고, 처음 코드를 작성해서 공유했습니다. 처음에는 팀원들이 테라폼을 몰라서 직접 실행하기를 꺼려했고, 제가 사용 방법을 문서로 정리해서 공유했습니다. 그래도 한 팀원이 destroy를 잘못 실행해서 리소스가 날아가는 사고가 한 번 있었습니다. 이후 권한을 분리하는 방향으로 개선했습니다. 도전과제는 도구 도입보다 팀원들이 쓸 수 있게 만드는 것이었다는 걸 그때 배웠습니다.
테라폼을 실제 팀 프로젝트에 도입해본 경험은 없습니다. 개인적으로 공식 튜토리얼을 따라 AWS에 VPC와 EC2를 코드로 만들어보는 실습을 했습니다. 코드를 수정하면 plan에서 변경 내용을 미리 확인하고 apply로 적용하는 흐름을 처음 경험했습니다. 한번은 plan 없이 바로 apply를 했다가 의도하지 않은 리소스가 삭제됐고, 그 이후로 반드시 plan 확인을 먼저 하는 습관이 생겼습니다. Heat는 OpenStack의 오케스트레이션 서비스라는 개념만 알고 실습은 못 했습니다. 실무 도입 경험이 없어 부족하지만, 기초는 쌓았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.