복붙한 코드를 모듈로 접기

한 줄 요약

같은 코드를 세 번 복사했다면 그건 모듈이 되어야 한다는 신호입니다.
다만 너무 일찍 모듈로 만들면 복붙보다 나쁩니다.

왜 이게 필요했나

환경이 셋이면 디렉터리가 셋이 됩니다.

dev/main.tf     (300줄)stage/main.tf   (300줄, dev 와 거의 같음)prod/main.tf    (300줄, 인스턴스 크기만 다름)

보안 그룹 규칙 하나를 고치려면 세 곳을 고쳐야 하고, 반드시 한 곳을
빼먹습니다. 그리고 그 빠진 한 곳이 대개 prod 입니다.

모듈이 하는 일

모듈은 입력을 받아 자원 묶음을 만드는 함수입니다.

module "web" {  source        = "../modules/web-service"  name          = "api"  instance_size = "large"     # 환경마다 다른 것만 인자로  replicas      = 6}

세 환경이 같은 모듈을 쓰고, 다른 값만 인자로 넘깁니다. 규칙을 고칠 때는
모듈 한 곳만 고칩니다.

좋은 모듈의 조건

1. 경계가 자연스럽다
"웹 서비스 하나에 필요한 것 전부" 는 좋은 경계입니다. "우리 회사의 모든
인프라" 는 나쁜 경계입니다. 모듈은 재사용 단위이지 포장 단위가 아닙니다.

2. 입력이 적다
인자가 30개인 모듈은 모듈이 아니라 설정 파일입니다. 인자가 늘어난다는 건
경계가 잘못됐다는 신호입니다.

3. 출력이 명확하다
다른 모듈이 참조할 값(ID, 엔드포인트)을 출력으로 노출합니다. 내부 구현을
바깥에서 알아야 한다면 캡슐화가 실패한 것입니다.

4. 버전이 있다
모듈을 고치면 그걸 쓰는 모든 곳이 영향을 받습니다. 버전을 붙여
환경별로 다른 시점의 모듈을 쓸 수 있게 합니다 — dev 에서 먼저 새 버전을
써 보고 prod 는 나중에 올립니다.

너무 이른 추상화

세 곳에서 쓰는 코드를 모듈로 만들었는데, 곧 네 번째 사용처가 나타나면서
"이 경우만 다르게" 가 시작됩니다. 인자가 하나씩 늘고, 조건문이 들어가고,
결국 아무도 이해할 수 없는 모듈이 됩니다.

경험칙은 이렇습니다.

• 2번 반복: 그냥 둡니다. 아직 패턴을 모릅니다.
• 3번 반복: 공통점이 뚜렷하면 모듈로.
• 조건이 늘어남: 모듈을 쪼개거나, 그 사용처는 모듈을 안 쓰게 합니다.

중복은 눈에 보이고 고칠 수 있지만, 잘못된 추상화는 보이지 않고 고치기도
어렵습니다. 확신이 없으면 중복인 채로 두는 편이 낫습니다.

현장에서 만나는 모습

• 모듈 인자가 40개 → 경계가 틀렸다. 쪼개야 한다.
• 모듈 안에 count = var.is_prod ? 3 : 1 같은 환경 분기가 쌓임 → 인자로

받아야 할 값을 모듈이 스스로 판단하고 있다.

• 모듈을 고쳤더니 관계없는 환경이 깨짐 → 버전 고정이 없다.

다음 확인에서 볼 것

이어지는 퀴즈에서는 중복 제거 자체보다 안정된 경계와 버전 고정, 호출자 책임을
판단합니다. 환경 분기가 계속 늘거나 관계없는 호출자가 함께 깨지는 사례에서
모듈을 확장할지 분리할지 선택해 보세요.