Terraform 면접은 state에 집중합니다. 실제 문제 대부분이 state에서 비롯되기 때문입니다. 누가 state를 보유하는지, 누가 동시에 변경할 수 있는지, 그리고 실제 인프라가 state와 어긋나면 무슨 일이 벌어지는지가 핵심입니다. 그다음으로는 모듈, 환경, 안전한 변경, 그리고 팀에서 Terraform을 어떻게 운영할지가 이어집니다.
아래는 답변과 함께 정리한 25개의 질문입니다. HashiCorp이 2023년에 Terraform 라이선스를 변경했고 커뮤니티 포크인 OpenTofu가 존재하므로, 관련话题가 나오면 팀이 어느 쪽을 쓰는지 언급하세요. 핵심 개념과 명령은 둘 다 동일합니다.
기초
1. Terraform이란 무엇이고, Infrastructure as Code란 무엇인가요?
Terraform은 구성 파일로 인프라를 정의하고 provider API를 통해 적용하는 도구입니다. Infrastructure as Code란 콘솔에서 클릭으로 구성하는 대신, 설정을 문서로 작성하고 버전 관리하며 리뷰하고 반복 가능하게 만드는 것을 뜻합니다.
2. 선언형과 명령형의 차이는 무엇인가요?
Terraform은 선언형입니다. 원하는 최종 상태를 기술하면 Terraform이 단계를 알아서 계산합니다. 명령형 스크립트는 단계를 직접 작성하며, 두 번 실행하면 문제가 생길 수 있습니다.
3. Terraform의 주요 명령은 무엇인가요?
| 명령 | 하는 일 |
|---|---|
| terraform init | provider와 모듈을 다운로드하고 backend를 설정합니다 |
| terraform validate | 구성이 유효한지 검사합니다 |
| terraform fmt | 파일을 포맷합니다 |
| terraform plan | 무엇이 변경될지 보여줍니다 |
| terraform apply | 변경을 적용합니다 |
| terraform destroy | 관리 중인 리소스를 제거합니다 |
| terraform import | 기존 리소스를 관리 대상으로 가져옵니다 |
| terraform state | state를 조회하고 편집합니다 |
4. provider, resource, data source란 무엇인가요?
provider는 AWS, Azure, Kubernetes 같은 API와 통신하는 플러그인입니다. resource는 Terraform이 생성하고 관리하는 대상입니다. data source는 이미 존재하는 것(예: 기존 VPC나 최신 AMI)에 대한 정보를 읽어옵니다.
5. variable, output, local이란 무엇인가요?
입력 variable은 구성을 매개변수화합니다. output은 값을 노출하여 명령줄이나 다른 모듈에서 사용할 수 있게 합니다. local은 모듈 내부의 이름 있는 표현식으로, 반복을 피하기 위해 사용합니다.
State
6. Terraform state 파일이란 무엇이고 왜 중요한가요?
state는 구성을 실제 리소스에 매핑하고 그 속성을 저장합니다. Terraform은 구성, state, 실제 인프라를 비교하여 변경을 계획합니다. state를 잃으면 이미 존재하는 것을 다시 생성하려 할 수 있습니다. 또한 secret을 포함할 수 있으므로 민감 정보로 취급해야 합니다.
7. state는 어디에 저장해야 하나요?
개인 노트북이 아니라 원격 backend에 저장하세요. 예를 들어 S3와 DynamoDB 테이블 또는 최신 네이티브 S3 잠금, Azure Storage, Google Cloud Storage, Terraform Cloud 등이 있습니다. 버킷에 버전 관리를 켜고 암호화하고 접근을 제한하세요.
8. state locking이란 무엇인가요?
두 사람이나 파이프라인이 동시에 apply하여 state를 손상시키는 것을 막습니다. 대부분의 원격 backend가 이를 지원합니다. 실행이 중단되면 아무도 apply 중이 아닌지 확인한 후 terraform force-unlock으로 오래된 잠금을 해제해야 할 수 있습니다.
9. drift란 무엇이고 어떻게 처리하나요?
drift는 실제 인프라가 state와 다른 상태로, 보통 누군가 수동으로 변경했을 때 발생합니다. terraform plan(또는 plan -refresh-only)으로 확인합니다. apply로 변경을 되돌릴지, 코드를 실제에 맞게 수정할지 결정하세요.
10. 기존 리소스를 Terraform 관리로 가져오려면 어떻게 하나요?
resource 블록을 작성한 뒤 terraform import <address> <id>를 실행하거나, 최신 버전에서는 import 블록을 사용합니다. 이후 plan을 실행하고 변경이 없을 때까지 코드를 조정하세요.
11. 환경이나 팀별로 state를 어떻게 분리하나요?
환경과 컴포넌트별로 별도의 state를 사용하세요. 예를 들어 네트워킹용, 각 앱용, 환경별로 하나씩 두는 식입니다. 이렇게 하면 영향 범위를 제한하고 plan 속도를 높일 수 있습니다. output과 data source 또는 원격 state로 값을 공유하세요.
모듈과 구조
12. 모듈이란 무엇이며, 언제 작성하나요?
모듈은 입력과 출력을 가진 재사용 가능한 리소스 그룹입니다. VPC나 서비스처럼 동일한 패턴을 반복하고, 한 번 검토된 버전을 사용하고 싶을 때 작성합니다. 모듈은 작고 집중적으로 유지하고, 합리적인 기본값을 제공하며, 버전을 관리하세요.
13. dev, staging, production은 어떻게 관리하나요?
일반적인 방법은 자체 상태와 변수 파일을 가진 별도의 디렉터리나 리포지토리를 사용하거나, 워크스페이스를 사용하는 것입니다. 많은 팀이 환경별로 별도의 상태를 선호하는데, 워크스페이스는 동일한 코드를 공유하기 때문에 잘못된 환경에 적용하기 쉽기 때문입니다. 동일한 모듈을 서로 다른 변수 값으로 사용하세요.
14. 워크스페이스란 무엇인가요?
하나의 백엔드와 구성 내에 있는 이름이 지정된 상태입니다. 브랜치별 테스트 환경처럼 동일한 설정의 임시 복사본에는 유용하지만, 프로덕션을 위한 강력한 분리는 아닙니다.
15. count와 for_each의 차이는 무엇인가요?
count는 위치로 인덱싱된 여러 복사본을 생성합니다. for_each는 맵이나 집합의 항목마다 이름을 키로 하여 하나씩 생성합니다. for_each를 선호하세요. count 목록 중간에서 항목을 제거하면 인덱스가 밀려 리소스가 삭제되고 다시 생성될 수 있기 때문입니다.
16. depends_on은 무엇을 하나요?
Terraform이 참조로는 파악할 수 없는 의존성을 명시적으로 추가합니다. 대부분의 의존성은 다른 리소스의 속성을 참조하면서 생기므로, 꼭 필요할 때만 사용하세요.
안전한 변경과 운영
17. lifecycle 규칙이란 무엇인가요?
create_before_destroy는 교체 리소스를 먼저 만들고, prevent_destroy는 삭제를 차단하며, ignore_changes는 Terraform 외부에서 변경된 속성을 건너뛰고, replace_triggered_by는 다른 리소스가 변경될 때 교체를 강제합니다.
18. Terraform에서 시크릿은 어떻게 처리하나요?
하드코딩하지 마세요. 시크릿 관리자나 환경 변수를 사용하고, 변수와 출력을 sensitive로 표시하세요. 값이 여전히 상태에 남을 수 있으므로 상태를 보호해야 합니다. 버전 관리에 포함된 일반 변수 파일을 통해 시크릿을 전달하지 마세요.
19. 변경 사항을 안전하게 검토하고 적용하려면 어떻게 하나요?
풀 리퀘스트에서 plan을 실행하고, plan 출력을 검토하고, 승인을 요구하며, 저장된 plan을 사용해 파이프라인에서 적용하여 검토된 내용이 그대로 실행되도록 하세요. plan에서 destroy나 replace 줄을 주의 깊게 확인하세요.
20. plan에서 데이터베이스를 삭제하고 다시 생성한다고 나옵니다. 어떻게 하나요?
멈추고 이유를 파악하세요. 흔한 원인은 변경 불가능한 속성의 변경, 리소스 이름 변경, 모듈 이동입니다. moved 블록이나 terraform state mv로 주소 변경을 수정하고, 필요하다면 ignore_changes나 prevent_destroy를 사용하며, 위험한 apply 전에는 반드시 백업하세요.
21. 리소스를 삭제하지 않고 이름을 바꾸거나 이동하려면 어떻게 하나요?
코드에서 moved 블록을 사용하거나 terraform state mv로 상태에서 주소를 변경하세요. 그런 다음 plan을 실행하여 destroy가 없는지 확인하세요.
22. 버전은 어떻게 고정하나요?
Terraform에는 required_version을, 프로바이더에는 버전 제약과 함께 required_providers를 사용하고, .terraform.lock.hcl 파일을 커밋하여 모든 사람이 동일한 프로바이더 빌드를 사용하도록 하세요. 신중하게 업그레이드하고 변경 로그를 읽으세요.
실무 및 시나리오 질문
23. 프로비저너란 무엇이며, 사용해야 하나요?
프로비저너는 생성 후 리소스에서 스크립트를 실행합니다. 상태에 추적되지 않고 실패 처리가 어렵기 때문에 최후의 수단입니다. cloud-init, Packer 같은 도구로 빌드한 이미지, 또는 구성 관리를 선호하세요.
24. 여러 환경을 가진 팀을 위해 Terraform을 어떻게 구성하시겠어요?
"버전이 지정된 릴리스가 있는 공유 모듈용 리포지토리와, 환경 및 컴포넌트별 디렉터리를 가진 라이브 리포지토리를 둡니다. 각각 잠금 기능이 있는 자체 원격 상태를 가집니다. 파이프라인은 풀 리퀘스트에서 fmt, validate, plan을 실행하고, 승인을 요구하며, 머지 시 적용합니다. 접근은 단기 자격 증명을 통해 이루어지고, 정책 검사가 위험한 변경을 잡아냅니다."
25. 누군가 콘솔에서 리소스를 변경해서 이제 Terraform이 되돌리려고 합니다. 어떻게 하나요?
왜 변경했는지 파악하세요. 긴급 수정이었다면 코드를 변경에 맞게 업데이트하고 적용하여 변경을 유지하세요. 실수였다면 적용하여 되돌리세요. 그런 다음 콘솔 쓰기 접근을 제한하는 등의 통제를 추가하여 다시 발생하지 않도록 하세요.
준비 방법
원격 백엔드, 모듈, 두 개의 환경이 있는 작은 프로젝트를 만드세요. moved 블록을 사용한 이름 변경, import, 드리프트 수정을 연습하세요. plan이 예상 밖이었던 때와 어떻게 대처했는지 설명할 준비를 하세요. 관련 클라우드 주제는 AWS 면접 가이드와 Kubernetes 가이드를 참고하세요.
특히 상태 관련 질문은 설명이 엉키기 쉬우므로 답변을 소리 내어 말해보세요. 모의 면접 기록을 보면 어디서 망설였는지 알 수 있습니다. 실제 면접에서 AI 도구 사용에 관한 고용주의 규칙을 따르세요.
YesToTheOffer와 함께 Terraform 면접 답변을 연습하세요
모의 기술 면접을 진행하고, 상태와 모듈을 소리 내어 설명한 후 녹취록을 검토하세요. 30분 무료, 구독 없음.
