🏗️ 테라폼 코드, 누가 짜야 하나? — 인프라팀 vs 개발팀 논쟁 종결

"우리 팀이 짜면 되잖아요"
— 이 한마디가 조직의 3개월을 잡아먹는다.

🎯 이 글에서 다루는 것

• Terraform 코드 소유권 논쟁이 생기는 진짜 이유
• 인프라팀이 담당할 때의 장점과 한계
• 개발팀(DevOps 포함)이 담당할 때의 장점과 한계
• 실제 현장에서 통하는 3가지 모델
• 조직 규모별 최적 구조 제안

---

📌 도입 / 배경

클라우드 도입이 가속화되면서 Terraform은 어느 순간 "인프라 팀의 전유물"에서 "모두가 건드려야 하는 공유 자원"이 되어버렸습니다.

 

문제는 여기서 시작됩니다.

"ECS 클러스터 하나 만들어달라고 티켓 올렸는데 2주가 걸렸어요."
"개발팀이 직접 짠 Terraform 코드가 프로덕션 VPC를 날렸어요."

 

두 이야기 모두 실제로 발생하는 일입니다. 전자는 인프라팀이 병목이 된 경우고, 후자는 소유권 없이 누구나 건드리다 벌어진 참사입니다.

 

Terraform 코드의 소유권 문제는 단순히 "누가 코드 짜느냐"의 문제가 아닙니다. 조직 구조, 책임 소재, 변경 속도 세 가지가 맞물린 복잡한 문제입니다.

---

🔍 먼저 Terraform이 다루는 영역을 구분하자

Terraform 코드는 크게 두 레이어로 나눌 수 있습니다.

레이어 1 — 플랫폼 인프라 (Foundation Layer)

• VPC, 서브넷, 라우팅, TGW
• IAM 정책, Security Group 기본 템플릿
• EKS/ECS 클러스터 자체
• S3 버킷 정책, KMS 키
• DNS (Route 53 호스티드 존)

이 영역은 변경 빈도가 낮고, 잘못 건드리면 전사 장애로 이어집니다. 신중함이 필요합니다.

레이어 2 — 애플리케이션 인프라 (App Layer)

• ECS 서비스, Task Definition
• Lambda 함수, API Gateway
• RDS 인스턴스 (앱 전용)
• CloudFront 배포 설정
• 환경별 변수, 서비스별 S3 버킷

이 영역은 변경 빈도가 높고, 배포 사이클과 직결됩니다. 속도가 중요합니다.

이 두 레이어를 같은 팀이 같은 방식으로 관리하려다가 충돌이 발생합니다.

---

⚙️ 모델 1 — 인프라팀 집중 소유 (Centralized)

인프라팀(또는 SRE팀)이 모든 Terraform 코드를 소유하고 관리하는 방식입니다.

 

장점

• 표준화 용이: 네이밍 컨벤션, 태깅 정책, 모듈 구조가 일관됩니다
• 보안 통제: 누가 무엇을 만드는지 반드시 리뷰를 거칩니다
• 전문성 집중: Terraform Provider 버전 관리, state 파일 관리 등 숙련도가 쌓입니다

단점

• 병목 발생: 개발팀 요청이 쌓이면 티켓 큐가 폭발합니다
• 컨텍스트 부재: 인프라팀이 앱의 요구사항을 완전히 이해하지 못한 채 코드를 짭니다
• 배포 속도 저하: 민첩한 CI/CD 파이프라인과 충돌합니다

적합한 조직

• 금융, 공공, 의료 등 보안·컴플라이언스 요구가 강한 곳
• 인프라 변경이 드문 온프레미스 + 클라우드 하이브리드 환경
• 클라우드 전환 초기 단계 (아직 표준화가 안 된 시점)

---

⚙️ 모델 2 — 개발팀 자율 소유 (Decentralized / "You Build It, You Run It")

각 개발팀(서비스팀)이 자신의 서비스에 필요한 인프라를 직접 Terraform으로 정의하는 방식입니다. Netflix, Spotify 같은 대형 테크 기업이 채택한 모델입니다.

 

장점

• 배포 속도: PR 올리면 바로 반영 가능. 인프라 팀 대기 없음
• 컨텍스트 일치: 앱을 가장 잘 아는 팀이 인프라도 결정
• 책임 명확화: "내가 짠 인프라는 내가 책임진다"

단점

• 파편화 위험: 팀마다 다른 방식으로 리소스를 만들어 일관성이 깨집니다
• 보안 사고 위험: Terraform 지식이 부족한 개발자가 퍼블릭 S3 버킷을 만들 수 있습니다
• state 파일 충돌: 여러 팀이 겹치는 리소스를 건드릴 때 상태 파일이 꼬입니다

적합한 조직

• DevOps 성숙도가 높은 스타트업이나 테크 기업
• MSA(마이크로서비스)로 팀 단위가 명확히 분리된 조직
• 개발자가 클라우드에 익숙한 환경 (AWS 자격증 수준 이상)

---

⚙️ 모델 3 — 플랫폼 팀 + Golden Path 모델 (Platform Engineering)

현재 가장 주목받는 모델입니다. 인프라팀은 "플랫폼"을 만들고, 개발팀은 "서비스"를 올린다는 개념입니다.

핵심 아이디어: 인프라팀이 검증된 Terraform 모듈을 만들어 제공하고, 개발팀은 그 모듈을 가져다 쓴다.

# 인프라팀이 만든 검증된 모듈 (예시)
module "my_ecs_service" {
  source  = "git::https://github.com/company/terraform-modules//ecs-service?ref=v2.1.0"

  # 개발팀이 채우는 값
  service_name   = "payment-api"
  container_port = 8080
  desired_count  = 2
  cpu            = 512
  memory         = 1024

  # 보안 관련은 모듈 내부에서 강제 적용됨
  environment = "prod"
  vpc_id      = var.vpc_id
}

 

개발팀은 source 모듈을 바꿀 수 없고, 허용된 변수만 입력합니다. 보안 그룹 규칙, IAM 정책, 태깅 표준은 모듈 내부에 이미 구워져 있습니다.

 

장점

• 속도 + 표준화 동시에 달성
• 개발팀은 Terraform 전문가가 안 되어도 됨
• 인프라팀은 모듈 품질에만 집중

단점

• 모듈 설계 초기 비용이 큼
• 모듈이 너무 제한적이면 개발팀 불만 발생
• 모듈 버전 관리가 필요 (?ref=v2.1.0 형태로 태깅 필수)

적합한 조직

• 중견~대기업, 팀 수가 5개 이상 되는 스케일
• Platform Engineering 또는 DevEx(Developer Experience) 팀을 별도로 운영하는 곳
• 내부 개발자 포털(IDP, Internal Developer Portal)을 구축하려는 조직

---

💡 현실에서 자주 보이는 잘못된 패턴

❌ 패턴 1 — "그냥 다 같이 써요"

별도의 소유권 구분 없이 누구나 main 브랜치에 PR을 날립니다. 리뷰 기준도 없고, state 락 충돌이 주기적으로 발생합니다. 소규모 팀에서 시작해 흔히 굳어버리는 패턴입니다.

 

❌ 패턴 2 — 인프라팀이 모든 것을 짜지만 리뷰는 없다

중앙화는 됐지만 코드 품질 관리가 없습니다. 수년 된 Terraform 코드에 아무도 손대지 못하는 "레거시 IaC"가 됩니다.

 

❌ 패턴 3 — 개발팀이 짜되 인프라팀에 공유 안 함

"우리 서비스 인프라는 우리가 안다"며 독립적으로 운영하다가, 보안 감사에서 대량의 미승인 리소스가 터집니다.

---

✅ 정리 / 마무리

"Terraform은 누가 짜야 하나"의 정답은 조직 규모와 성숙도에 따라 다릅니다.

조직 상황	추천 모델
클라우드 전환 초기, 5인 이하 팀	인프라팀 집중 소유
DevOps 성숙, MSA, 소규모 스타트업	개발팀 자율 소유
팀 5개 이상, 표준화 필요	플랫폼팀 + Golden Path 모듈
금융/공공 등 컴플라이언스 강한 환경	인프라팀 소유 + 필수 리뷰 게이트

 

가장 중요한 원칙은 이것입니다.

플랫폼 인프라(VPC, IAM, 클러스터)는 인프라팀이, 앱 레이어(서비스, 함수)는 개발팀이
— 단, 모듈과 표준은 인프라팀이 제공한다.

 

 

소유권이 명확해야 장애 시 누가 대응하는지도 명확해집니다. 코드의 소유권은 곧 운영의 책임입니다.