IaC를 사용한 인프라 관리 측면에서 인프라 상태 정보를 어떻게 공유하는 게 맞을까?

[Hexeong]

논의 제안 배경

우리 SolidConnection 프로젝트의 인프라를 Terraform(IaC)으로 관리하기 시작하면서, 협업 시 인프라의 '상태(State)'를 어떻게 동기화할지에 대한 고민이 생겼습니다.

일반적인 애플리케이션 개발은 각자 로컬에서 코드를 짜고 Git으로 합치면 되지만, IaC는 '실제 클라우드 리소스'라는 단 하나의 실체를 두고 여러 명이 수정하는 구조입니다. 이 과정에서 다음과 같은 위험 요소들이 우려됩니다.

1. 상태 덮어쓰기(Race Condition): 두 명의 작업자가 동시에 apply를 실행할 경우, 나중에 완료된 사람의 데이터가 이전 작업자의 상태를 덮어씌워 인프라 구성이 꼬일 수 있습니다.

2. 코드와 실체의 불일치: 누군가 로컬에서 인프라를 변경하고 상태 파일(tfstate)을 공유하지 않으면, 다른 팀원이 plan을 수행할 때 의도치 않게 기존 리소스를 삭제하거나 변경하려는 시도가 발생합니다.

3. 작업 내용의 혼선: 내가 작업 중인데 다른 사람의 작업 결과가 S3에 반영되어 내 로컬 실행 결과에 영향을 주는 상황이 발생하며, 이는 개발 안정성을 해칠 수 있습니다.

---

저의 제안

단순히 파일을 S3에 올려 공유하는 수준을 넘어, 'Locking 메커니즘' 과 '중앙 집중형 배포 절차' 를 통해 협업 구조를 안정화할 것을 제안합니다.

1. AWS S3 + DynamoDB 기반의 Remote Backend 구축

   • S3 (Storage): 모든 팀원이 항상 최신 상태 파일을 참조하도록 원격 저장소로 사용합니다.
   • DynamoDB (Locking): 누군가 인프라를 변경 중일 때 다른 사람의 접근을 원천 차단하는 'Lock' 기능을 활성화하여 작업 꼬임을 방지합니다.

2. State 격리 구조 도입

   • 전체 인프라를 하나의 상태 파일로 관리하지 않고, 네트워크(VPC), 데이터베이스(DB), 애플리케이션(App) 등으로 디렉토리를 분리하여 작업 영향 범위를 최소화합니다.

3. CI/CD 파이프라인(GitHub Actions) 연동

   • 로컬 PC에서의 직접적인 apply를 지양하고, Pull Request를 통해 변경 사항을 검토한 뒤 Merge 시점에만 자동 배포되도록 순서를 직렬화합니다.

---

논의 포인트

우리 팀의 현재 개발 속도와 편의성을 고려하여 아래 사항들에 대해 의견을 나누고 싶습니다.

• Locking 도입의 시급성: 현재 우리 프로젝트 규모에서 DynamoDB를 통한 엄격한 Lock 관리를 바로 도입하는 것에 대해 어떻게 생각하시나요?

  • DynamoDB에 대해서 AWS pricing caculator로 대강 계산해보았는데 서울 리전 2GB 스토리지 + 평균 512 바이트 + 쓰기 설정(매월 1백만) + 읽기 설정(강력한 일관성 100퍼센트) 기준으로 월별 총비용 0.54 USD로 나옵니다..

• 인프라 분리 기준: 기존 상태 파일을 ec2, s3 등 자원 또는 환경 기준으로 분리 관리하는 방식에서 문제점은 없을까요?

• 배포 권한 및 절차: 개별 팀원의 로컬 배포를 어디까지 허용할 것인지, 혹은 반드시 GitHub Actions 같은 공통 CI 도구를 통해서만 인프라를 변경할 것인지에 대한 의견이 궁금합니다.

---

참고자료

[whqtker]

Locking 도입의 시급성: 현재 우리 프로젝트 규모에서 DynamoDB를 통한 엄격한 Lock 관리를 바로 도입하는 것에 대해 어떻게 생각하시나요?

당장 충돌 상황은 거의 발생하지 않을 것 같지만 그럼에도 도입하는 것이 좋아 보입니다. 사전에 차단해야 한다고 생각해요. 최신 terraform 버전에서는 S3로만 락킹을 하더라고요 ! 이전 버전에는 다이나모디비 방식도 있는 것 보면 해당 방식은 deprecated될 예정인 것 같습니다.

인프라 분리 기준: 기존 상태 파일을 ec2, s3 등 자원 또는 환경 기준으로 분리 관리하는 방식에서 문제점은 없을까요?

이 점에 대해서는 뭐가 나을지 잘 모르겠네요 ... 하나의 리소스에 하나의 파일을 매핑하면 직관적이다는 생각이 들면서도 파일이 너무 많아지는 건가 싶기도 하네요 .. 그렇다고 환경 별로 구분하자니 중복 코드가 생기고 ..

배포 권한 및 절차: 개별 팀원의 로컬 배포를 어디까지 허용할 것인지, 혹은 반드시 GitHub Actions 같은 공통 CI 도구를 통해서만 인프라를 변경할 것인지에 대한 의견이 궁금합니다.

PR을 올리면 github actions를 통해 terraform plan을 수행하고, 머지 시 terraform apply하는 구조가 되면 뭔가 직관적인 흐름이 될 것 같습니다. 개인이 apply하면 협업 시 혼란이 생길 것 같고, 동시에 같은 리소스에 대해 apply해서 의도치 않은 동작도 발생할 것 같습니다. 다만 개발자는 로컬에서 plan으로만 잘 작성되었는지 확인할 수 있을텐데, plan이 성공적으로 된다 해도 apply가 반드시 성공하지는 않더라고요 ..

[Hexeong]

당장 충돌 상황은 거의 발생하지 않을 것 같지만 그럼에도 도입하는 것이 좋아 보입니다. 사전에 차단해야 한다고 생각해요. 최신 terraform 버전에서는 S3로만 락킹을 하더라고요 ! 이전 버전에는 다이나모디비 방식도 있는 것 보면 해당 방식은 deprecated될 예정인 것 같습니다.

이런 방법이 있었군요! 그럼 DynamoDB도 사용하지 않아도 될 것 같네요! 이 방법으로 찾아보겠습니다!

이 점에 대해서는 뭐가 나을지 잘 모르겠네요 ... 하나의 리소스에 하나의 파일을 매핑하면 직관적이다는 생각이 들면서도 파일이 너무 많아지는 건가 싶기도 하네요 .. 그렇다고 환경 별로 구분하자니 중복 코드가 생기고 ..

흠. 그럼 일단은 현재 체제를 유지하고 변경 필요성이 생기면 바꾸도록 하겠습니다~

PR을 올리면 github actions를 통해 terraform plan을 수행하고, 머지 시 terraform apply하는 구조가 되면 뭔가 직관적인 흐름이 될 것 같습니다. 개인이 apply하면 협업 시 혼란이 생길 것 같고, 동시에 같은 리소스에 대해 apply해서 의도치 않은 동작도 발생할 것 같습니다. 다만 개발자는 로컬에서 plan으로만 잘 작성되었는지 확인할 수 있을텐데, plan이 성공적으로 된다 해도 apply가 반드시 성공하지는 않더라고요 ..

음.. 이부분에 대해서는 조금더 고민이 필요할 것 같네요 ㅠㅜ

[Hexeong]

03.26) 현재까지의 논의 내용 + 제시 의견 정리

협업 워크플로우 정리

단계	트리거	명령어	목적
Plan	PR 생성 시	terraform plan -out=tfplan	변경사항 미리보기, 리뷰어가 승인 전 확인
Apply	PR 머지 후 (수동 승인)	terraform apply tfplan	실제 인프라 적용

구체적인 타이밍

1. terraform plan

• 시점: Pull Request 생성 시 (GitHub Actions 자동 실행)
• 목적: 코드를 머지하기 전에 어떤 변경이 일어날지 팀원들이 리뷰
• Plan 결과는 PR 코멘트로 자동 첨부되어 팀원들이 확인

2. terraform apply

• 시점: PR 이 승인되고 main 브랜치에 머지된 후
• 방식:
  • 자동 실행 방식: 머지되면 바로 apply 실행 (개발 환경 등)

주요 원칙

PR 생성 → Plan 자동 실행 → 팀 리뷰 → PR 승인/머지 → Apply 실행

• S3 백엔드는 상태 파일을 공유하고, S3 네이티브 상태 파일 락 기능으로 동시 실행을 방지합니다.
  • 해당 방식은 Terraform 1.10 이상부터 가능하기에 모든 개발자는 해당 버전으로 설치해야 합니다!
• PR 에서 검토한 변경과 실제 적용 대상이 일치해야 하므로, 저장된 plan artifact 를 apply 하거나 merge 후 최신 기준으로 다시 plan/apply 를 수행합니다.

git branch 전략 요약

• main 브랜치 : 해당 브랜치에 머지가 될 경우, 변경된 폴더가 타겟팅하는 환경에 대해서 plan -> apply를 진행한다.
• feature/refactor/fix 등 작업 브랜치 : main 브랜치에서 생성하여 작업한 이후, 작업이 완료되었을 때 main 브랜치로 pr을 생성한다.
  • 로컬에서 작업시 terraform plan만 가능하도록 한다. (로컬에서 terraform apply 불가)
  • 생성된 pr에 대해서는 github action으로 terraform plan 실행한 결과를 pr의 comment로 생성한다.
  • 리뷰어들은 코드와 해당 내용을 확인하여, 리뷰를 수행한다.

terraform apply에서 실패했을 때, 대처 방식

Apply 실패 
    ↓
1. GitHub Actions 로그 확인 (어떤 오류인지 식별)
    ↓
2. 오류 유형 분류
    ├─ 일시적 오류 → 재실행 버튼 클릭
    ├─ 코드 오류 → 수정 커밋 푸시 → 자동 재실행
    ├─ 권한/쿼터 오류 → IAM/쿼터 수정 후 재실행
    └─ 상태 락 오류 → force-unlock (신중하게)
    ↓
3. 재실행 후 성공 확인
    ↓
4. 반복 실패 시 PR 로 복구 또는 수동 개입

요약

• 일시적 오류: GitHub Actions 재실행 [web:6]
• 코드 오류: 수정 커밋 반영 후 재실행
• 권한/쿼터 오류: IAM 또는 한도 수정 후 재실행
• 상태 락 오류: 실제 실행 중 작업이 없는지 확인 후 unlock 검토 [web:71]

S3 기반 tfstate 상태 관리 방법

• 별도의 S3 버킷을 생성하여 관리.
• 버킷 이름은 solid-connection-tfstate로 사용한다.
• 해당 버킷에 대해 버전 관리 활성화를 설정한다.
• 버킷은 퍼블릭 접근 차단과 함께 S3 암호화를 설정한다.
• 경로별로 상태 파일의 s3 키는 다음과 같이 분리
  • env/prod/terraform.tfstate
  • env/stage/terraform.tfstate
  • env/load_test/terraform.tfstate
  • env/monitoring/terraform.tfstate
  • env/global/terraform.tfstate

[whqtker]

전반적으로 위 내용 동의합니다.

추가로 로컬에서 terraform apply 불가능하도록 강제가 가능한가요 ?

[Hexeong]

해당 내용은 IAM 선에서 액세스 키 발행을 못하도록 강제하면 가능할 것 같습ㄴ다!
OIDC는 IAM Role 기반으로 동작하기에 cli에서 terraform이 동작하기 위한 액세스 키 발행을 취소해도 영향이 없을 것 같네요 :)