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 도구를 통해서만 인프라를 변경할 것인지에 대한 의견이 궁금합니다.

---

참고자료