10. 인프라 및 IaC 가이드

0. 먼저 알고 가기 (30초 요약)

• 인프라는 코드처럼 버전 관리하고 PR로 변경하세요.
• 실제 환경 상태와 코드에 선언된 상태가 다르지 않게 드리프트를 점검하세요.
• 민감 정보는 코드 밖으로 분리해 승인·감사 흐름을 명확히 하세요.

초심자용 한눈에 보기

인프라는 코드처럼 다뤄야 합니다. 문서화되지 않은 규칙이 가장 위험합니다.

비유로 이해하기: 인프라를 "콘솔에서 클릭"으로 만드는 것은 종이 메모로 요리하는 것과 같습니다. 누구도 같은 요리를 재현할 수 없고, 잘못된 양념을 누가 넣었는지 추적할 수도 없습니다. IaC는 레시피를 코드 파일로 적어 두어, 같은 결과를 누구나 다시 만들 수 있게 합니다.

핵심 용어 빠르게 정리

환경별 분리 한눈에 보기

왜 중요한가: 환경별 권한과 데이터를 분리하지 않으면 검증 중인 코드 한 줄이 실제 사용자 데이터를 변경할 수 있습니다.

flowchart LR
  subgraph LOCAL["local"]
    L1["fixture/mock 데이터"]
    L2["개인 권한"]
  end
  subgraph PREVIEW["preview"]
    P1["익명화/샘플 데이터"]
    P2["PR 참여자 권한"]
    P3["TTL 자동 소멸"]
  end
  subgraph STAGING["staging"]
    S1["production 유사 데이터"]
    S2["팀 제한 권한"]
  end
  subgraph PROD["production"]
    R1["실제 사용자 데이터"]
    R2["승인된 운영자만"]
  end
  LOCAL --> PREVIEW --> STAGING --> PROD

---

프론트엔드 인프라 표준은 특정 클라우드 템플릿이 아니라 재현 가능성, 최소 권한, 비용 가시성, 빠른 검증 환경, 안전한 변경 절차를 보장하는 운영 규칙입니다.

---

추천 항목 (실무 우선순위)

• 시작 추천: 환경별 state 파일과 권한/리소스 규칙을 코드로 먼저 정의하세요.
• 안정 추천: 변경 시마다 drift check를 돌리고 누락 항목을 PR 설명에 포함합니다.
• 운영 추천: 비용 태그/TTL/만료 정책을 표준 템플릿으로 고정해 청구 이슈를 미리 줄입니다.

추천 항목 고도화 체크

• 첫 적용 — plan, drift, least privilege, cost guard 중 하나를 실제 PR이나 운영 이슈에 붙이고, 변경 전 기준을 먼저 적는다.
• 증거 정리 — plan output, drift report, policy check, cost diff를 같은 작업 기록에 남긴다.
• 재점검 — drift 수, 권한 wildcard 수, 월 비용 변화가 나아졌는지 30일 안에 확인하고 기준을 유지, 수정, 폐기 중 하나로 판정한다.

추천 항목 실행 기록 템플릿

• 작업 : plan, drift, least privilege, cost guard 적용 범위를 어느 화면, 패키지, 문서에 둘지 적는다.
• 증거 : plan output, drift report, policy check, cost diff 중 실제로 남긴 항목만 링크한다.
• 판정 : 유지/수정/폐기 중 하나와 이유를 한 문장으로 남긴다.
• 다음 점검 : drift 수, 권한 wildcard 수, 월 비용 변화를 다시 볼 날짜와 담당자를 지정한다.

문서 책임 범위

---

0. 모든 프론트엔드 그룹 공통 Baseline

0.0 인프라 변경 파이프라인

왜 중요한가: 변경 흐름이 한 줄로 보이지 않으면 어디서 위험을 차단해야 할지 합의가 어렵습니다.

flowchart TD
  A[요청/이슈] --> B[IaC 코드 작성]
  B --> C[plan 생성]
  C --> D{정책/보안 게이트}
  D -->|통과| E[apply]
  D -->|차단| F[ADR 보완 또는 수정]
  E --> G[리소스 적용]
  G --> H[drift check + 검증]
  H --> I{drift 존재}
  I -->|있음| J[재조정 PR]
  I -->|없음| K[운영 + 비용 모니터링]
  J --> C

0.0.1 drift 발생 시 협업 시퀀스

비유: 도서관에서 누군가 책 위치를 마음대로 바꾸면, 카탈로그가 더 이상 사실을 말하지 않습니다. drift는 카탈로그(코드)와 실제 책장(콘솔)의 차이가 벌어진 상태입니다.

sequenceDiagram
  participant Console as 운영 콘솔
  participant Scanner as drift 감지
  participant Owner as Infra Owner
  participant PR as 재조정 PR
  participant CI as Policy CI
  Console->>Scanner: 수동 리소스 변경 발생
  Scanner->>Owner: drift 리포트 발송
  Owner->>Owner: 변경 의도/긴급도 확인
  alt 의도된 변경
    Owner->>PR: IaC에 반영하는 PR 작성
  else 의도되지 않은 변경
    Owner->>Console: 콘솔 수정 revert
  end
  PR->>CI: plan + policy 검증 요청
  CI-->>PR: 통과/차단 결과
  CI->>Console: apply로 상태 동기화
  Console-->>Scanner: 재검사 결과 클린

0.0.2 상태 기반 IaC 라이프사이클

일상 비유: 인프라 리소스는 호텔 객실과 같습니다. 비어 있다가 예약(plan)되고, 손님이 들어와 사용(apply, 운영)하고, 청소(drift 재조정)와 체크아웃(폐기)을 거칩니다.

stateDiagram-v2
  [*] --> Planned: PR + plan 생성
  Planned --> PolicyChecked: policy-as-code 통과
  Planned --> Rejected: 정책 위반
  PolicyChecked --> Applied: apply 실행
  Applied --> Operational: 운영 + 비용 추적
  Operational --> Drifted: 콘솔 수동 변경
  Drifted --> Reconciled: 재조정 PR + apply
  Reconciled --> Operational
  Operational --> Retired: TTL 만료/폐기 결정
  Retired --> [*]
  Rejected --> Planned: ADR 보완 후 재제출

0.1 교차 검증 매트릭스

0.2 운영 게이트

---

1. 인프라 설계 원칙

왜 중요한가: 다섯 가지 원칙은 "한 번 만들고 끝"이 아니라 "반복 변경에도 안전한 인프라"의 최소 토대입니다.

1. 코드가 단일 진실 공급원이어야 합니다. 운영 콘솔에서 만든 리소스는 재현할 수 없고 리뷰도 어렵습니다.
2. 변경 전 plan, 변경 후 drift check를 둡니다. 인프라 변경은 코드 변경과 같은 리뷰 과정을 거칩니다.
3. 권한은 배포 단위로 최소화합니다. CI가 production 전체 권한을 갖지 않도록 환경별 역할을 분리합니다.
4. preview는 자동 소멸해야 합니다. 검증 환경은 오래 남을수록 비용과 보안 리스크가 됩니다.
5. 런타임 설정과 빌드 산출물을 분리합니다. 동일한 artifact를 환경별 설정으로 승격할 수 있어야 합니다.

flowchart LR
  P1["원칙 1\n단일 진실 공급원"] --> R1["콘솔 변경 차단"]
  P2["원칙 2\nplan + drift check"] --> R2["변경 리뷰 흐름"]
  P3["원칙 3\n최소 권한"] --> R3["환경별 역할 분리"]
  P4["원칙 4\npreview 자동 소멸"] --> R4["TTL + 자동 cleanup"]
  P5["원칙 5\nartifact-config 분리"] --> R5["build once, deploy many"]

---

2. 환경 모델

왜 중요한가: 환경을 섞으면 "테스트가 통과한 코드"와 "사용자가 받는 코드"가 일치한다는 보장이 깨집니다.

preview 환경은 production 데이터를 복제하지 않는 것이 기본입니다. 불가피한 경우 익명화, 최소 범위, 시간 제한, 접근 감사가 필요합니다.

flowchart LR
  Code["같은 artifact"] --> L["local\nfixture"]
  Code --> P["preview\n익명/샘플"]
  Code --> S["staging\nprod 유사"]
  Code --> R["production\n실데이터"]
  L -.->|승격| P -.->|승격| S -.->|승격| R

---

3. Workload Identity

일상 비유: 호텔 직원이 매일 같은 마스터키를 들고 다니는 것과, 필요한 객실 카드를 그때그때 발급받는 것의 차이입니다. workload identity는 후자에 가깝습니다.

CI/CD는 장기 비밀키를 저장하지 않는 구조가 기본입니다.

권한 정책은 "누가 어느 환경에서 어떤 artifact를 어디에 배포할 수 있는지"를 문장으로 먼저 정의한 뒤 코드로 옮깁니다.

sequenceDiagram
  participant CI as CI Runner
  participant IDP as OIDC Provider
  participant Cloud as Cloud IAM
  participant Env as Target Env
  CI->>IDP: workflow id, branch, env claim 요청
  IDP-->>CI: 서명된 ID 토큰 발급
  CI->>Cloud: AssumeRoleWithWebIdentity(claim 포함)
  Cloud->>Cloud: trust policy 검증\n(repo/branch/env 일치 확인)
  alt 허용
    Cloud-->>CI: 단기 자격 증명(예: 15분)
    CI->>Env: artifact 배포
  else 거부
    Cloud-->>CI: 권한 거부
    CI->>CI: 빌드 실패 + 감사 로그
  end

---

4. Preview 환경 표준

Preview 환경은 프론트엔드 팀의 품질 속도를 크게 높이지만, 자동 정리가 없으면 비용과 보안 부채가 됩니다.

---

5. IaC 리뷰 체크리스트

• [ ] public 접근이 필요한 리소스와 그렇지 않은 리소스가 분리되어 있는가
• [ ] 저장소, 캐시, 로그, 백업에 암호화가 적용되어 있는가
• [ ] secret이 코드, state 파일, build log에 노출되지 않는가
• [ ] production 권한이 preview/staging 배포 경로에 섞이지 않는가
• [ ] deletion protection, retention, lifecycle rule이 환경별로 다른가
• [ ] 비용 태그와 TTL 태그가 모든 임시 리소스에 강제되는가
• [ ] plan 결과가 PR에 첨부되고 reviewer가 변경 범위를 볼 수 있는가
• [ ] drift 감지 결과가 운영 채널과 backlog에 연결되는가

---

6. Policy-as-Code Gate

일상 비유: 공항 보안검색대와 같습니다. "위험물 반입 금지"라는 안내문(문서)만 있으면 누군가는 통과시키지만, 게이트(자동 검사)가 있으면 예외 없이 막을 수 있습니다.

인프라 정책은 문서에만 있으면 지켜지지 않습니다. CI에서 자동 차단해야 합니다.

flowchart TD
  Plan[plan 산출물] --> Check{Policy 검사}
  Check -->|공개 접근| F1[차단]
  Check -->|wildcard 권한| F2[차단]
  Check -->|암호화 누락| F3[차단]
  Check -->|태그 누락| F4[차단]
  Check -->|관리 포트 공개| F5[차단]
  Check -->|TTL 누락| F6[차단]
  Check -->|모두 통과| Apply[apply 허용]
  F1 --> Fix[수정 또는 만료 있는 ADR 예외]
  F2 --> Fix
  F3 --> Fix
  F4 --> Fix
  F5 --> Fix
  F6 --> Fix
  Fix --> Plan

정책 예외는 만료일과 owner가 있는 RFC/ADR로 관리합니다.

---

7. 비용 운영

프론트엔드 인프라 비용은 대부분 CDN 전송량, build minutes, preview 환경, 로그/trace 저장량에서 증가합니다.

비용 알림은 단순 월말 예산 초과가 아니라 "일일 증가율", "preview orphan", "로그 수집량 급증"처럼 조기 탐지 가능한 지표로 둡니다.

---

8. Drift와 변경 관리

왜 중요한가: drift는 단순 실수가 아니라 "정상 경로가 너무 불편하다"는 신호입니다. 반복 drift는 도구나 권한 모델을 고치라는 경고로 읽어야 합니다.

수동 수정 자체를 탓하기보다, 왜 코드 경로보다 수동 경로가 쉬웠는지 개선해야 합니다.

flowchart TD
  D[drift 감지] --> Q{변경 의도}
  Q -->|의도된 긴급 hotfix| H[24h 내 IaC에 반영]
  Q -->|의도되지 않은 변경| R[콘솔 변경 revert]
  Q -->|정책 위반 의심| S[보안 리뷰 + 자동 remediation 판단]
  H --> L[원인 회고: 왜 콘솔이 빨랐는가]
  R --> L
  S --> L
  L --> P{반복 drift 패턴}
  P -->|있음| I[권한/자동화 개선 backlog]
  P -->|없음| O[운영 지속]

---

9. AI 활용 기준

AI는 IaC 초안 작성, 정책 누락 점검, 비용 최적화 후보 도출에 유용하지만 다음 제약을 둡니다.

• production credential, 계정 ID, 내부 도메인, state 파일 원문을 AI에 전달하지 않습니다.
• AI가 만든 IaC는 plan, policy-as-code, 최소 권한 리뷰를 통과해야 합니다.
• "최신 권장 설정"은 클라우드별 공식 문서로 재확인한 뒤 적용합니다.
• 인프라 변경 설명에는 blast radius, rollback, drift 가능성을 포함합니다.

---

10. 제외한 벤더 종속 항목

공통 개발 가이드에는 특정 클라우드의 리소스 이름, 전용 IaC construct, 특정 CDN 원본 접근 제어 방식, 특정 DNS/인증서 콘솔 절차, 특정 비용 콘솔 사용법을 표준으로 포함하지 않습니다. 이 문서는 어떤 클라우드와 IaC 도구를 쓰더라도 유지되어야 하는 재현성, 권한, 환경 분리, 비용, drift, 정책 검증 기준만 남깁니다.

---

실무 적용 가이드

언제 이 문서를 펼칠까

• preview 환경이 쌓여 비용과 보안 문제가 생길 때
• 수동 콘솔 변경 때문에 실제 상태와 코드가 달라질 때
• CI가 production 장기 키를 들고 배포할 때

적용 순서

1. 환경을 local, preview, staging, production으로 나누고 데이터/권한을 분리한다.
2. 배포 대상, CDN, 권한, 알림을 IaC로 선언한다.
3. CI에는 OIDC/workload identity 기반 임시 권한을 사용한다.
4. preview는 owner, environment, ttl 태그와 자동 삭제를 강제한다.
5. plan, policy-as-code, drift report를 PR 증거로 남긴다.

함께 두는 파일

• 앱별 IaC 모듈, 환경 변수 schema, preview 설정을 같은 service 폴더에 둔다.
• 공통 module은 여러 서비스에서 검증된 뒤 shared infra package로 승격한다.
• runbook과 rollback 절차는 배포 문서와 연결한다.

흔한 실수

• 콘솔에서 만든 리소스를 코드로 되돌리지 않는다.
• preview에 production 데이터를 복제한다.
• 장기 cloud key를 CI secret으로 저장한다.
• 비용 태그와 TTL 없이 임시 리소스를 만든다.

PR 완료 기준

• [ ] IaC plan과 policy report가 있다.
• [ ] 장기 키 없이 배포된다.
• [ ] preview cleanup이 자동화되어 있다.
• [ ] drift 감지와 복구 절차가 있다.

추천 항목 실행 우선순위 매핑

• P1(7일 내) — plan, drift, least privilege, cost guard 중 하나를 작은 변경 1건에 적용하고 증거(plan output)를 남긴다.
• P2(30일 내) — IaC 변경 기준을 팀 템플릿, 체크리스트, CI 중 한 곳에 고정한다.
• P3(90일 내) — drift 수, 권한 wildcard 수, 월 비용 변화 추이를 보고 기준을 유지할지 조정할지 결정한다.
• 완료 기준 — 인프라 오너가 증거와 철회 조건을 확인했다는 기록을 남긴다.

추천 항목 실행 체크리스트

• [ ] 1단계(7일) : plan, drift, least privilege, cost guard 적용 대상을 1개로 좁힌다.
• [ ] 2단계(30일) : 증거(plan output, drift report, policy check, cost diff)를 PR, ADR, 회고 중 한 곳에 연결한다.
• [ ] 3단계(60일) : drift 수, 권한 wildcard 수, 월 비용 변화가 기준 안에 들어왔는지 확인한다.
• [ ] 문제 대응 : 미달성 사유와 다음 조치, 중단 여부를 같은 기록에 남긴다.

추천 항목 실행 운영 규칙

• 실행 게이트 : 적용 전 plan과 rollback 경로가 같은 PR에 있어야 한다.
• 승인 체계 : 인프라 오너가 영향 범위와 rollback 담당자를 적용 전에 확인한다.
• 재개 조건 : plan과 policy check가 통과하고 drift가 설명되면 apply한다.
• 정지 조건 : 수동 콘솔 변경이나 wildcard 권한이 설명되지 않으면 중단한다.
• 리스크 점수 : 변경 리소스 수, 권한 범위, 비용 증가율로 산정한다.
• 리더 승인자 : 플랫폼 리드가 최종 승인 책임을 맡는다.
• 승인 역할 : IaC 변경 작성자, 검토자, 운영 확인자를 분리해 기록한다.
• 재평가 주기 : 월 1회 drift와 비용 report를 같이 본다.