AI 드리븐

지도 위치 : 2일차 · 구현과 검증 · 인프라 | 이전: 14차시 검증 ② 보안 점검과 차단 | 다음: 16차시 결제 연동 키워드 : 설정을 코드로 관리, 코드 저장소 준비, 배포 설정 개요

이 차시를 다 읽으면

1. IaC(설정을 코드로) 를 유와 종차로 정의하고, 콘솔 클릭 설정과 비교해 얻는 세 가지(기록 · 재현 · 리뷰)를 말할 수 있다.
2. IaC의 원칙 세 가지와, 코드와 실제가 어긋나는 상태 가 어떻게 생기는지 설명할 수 있다.
3. 환경 분리 (로컬 · 스테이징 · 운영)를 정의하고, 환경마다 무엇이 달라지는지 표로 말할 수 있다.
4. "설정 파일 수정"과 "클라우드에 적용" 을 되돌릴 수 있는가 축으로 가르고, 적용을 사람이 승인하는 이유를 설명할 수 있다.
5. 적용 전 계획 출력의 마지막 한 줄 을 읽고, 멈춰야 할 때를 판단할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 "서버 · DB · 배포 설정을 어떻게 AI에게 맡기면서도 사고를 막는가" 입니다. 답은 두 겹입니다. 설정을 코드로 만들어 AI가 읽고 고치고 리뷰할 수 있게 하고(축 2), 그 코드를 실제 클라우드에 적용하는 순간 에만 사람이 손을 댑니다(축 1 · 4). 3일차의 자동화와 배포가 모두 이 원칙 위에 섭니다.

---

1. ⭐ 설정을 코드로 — IaC

1.1 정의

IaC (Infrastructure as Code, 설정을 코드로) — [인프라 관리 방식]인데, [ 서버 · DB · 네트워크 · 배포 설정을 파일로 적어 두고 도구가 그 파일대로 만들게 한다 ]는 점에서 클라우드 콘솔 화면을 클릭해서 만드는 방식과 구별된다.

1.2 경계 — 콘솔 클릭과 무엇이 다른가

마지막 줄이 이 과정에서 특히 중요합니다. 에이전트는 콘솔 화면을 클릭하는 것보다 파일을 읽고 쓰는 일 을 훨씬 잘합니다. 설정이 코드면 에이전트가 읽고, 고치고, 리뷰할 수 있습니다.

1.3 반례 — 이건 IaC가 아닙니다

1.4 원칙 세 가지와 어긋남

어긋남 (Drift) — 콘솔에서 바꾼 것이 설정 코드에 반영되지 않아 코드와 실제가 달라진 상태 입니다. 다음에 에이전트가 설정 코드를 적용하면 콘솔에서 바꾼 것을 덮어씁니다.

⚠️ 콘솔 클릭의 유혹을 가장 크게 받는 사람이 코드를 읽지 않는 사람입니다. 콘솔이 코드보다 친숙해 보이기 때문입니다. 콘솔에서 바꿨다면 반드시 "콘솔에서 이걸 바꿨으니 설정 코드에도 반영해줘" 라고 알려 주세요.

💡 비유는 마지막에 — 콘솔 클릭은 손으로 끓인 찌개 , IaC는 레시피 입니다. 찌개는 맛있어도 다음에 똑같이 끓일 수 없고, 레시피는 누가 끓여도 같은 맛이 납니다. 레시피를 고치지 않고 냄비에 소금만 더 넣으면, 다음번엔 다시 싱거워집니다(어긋남).

---

2. 코드 저장소 준비

GitHub 같은 원격 저장소는 코드 보관소이자 자동화의 출발점 입니다.

앞으로 다시 만납니다 — 이 표의 아래 세 줄이 18 · 19 · 21차시에서 하나씩 실제로 설치됩니다. 지금은 "저장소가 단순한 보관소가 아니라 관문이 될 자리"라는 것만 잡아 두면 됩니다.

---

3. ⭐ 환경 분리

3.1 정의

환경 (Environment) — [서비스 실행 단위]인데, [ 같은 코드를 서로 다른 설정값(DB, 키, 주소)으로 독립적으로 실행한다 ]는 점에서 코드 자체가 다른 별개의 프로그램과 구별된다.

로컬 (local)       개인 개발. docker compose로 내 컴퓨터에서
     │
스테이징 (staging)  운영과 같은 구성의 시험장. 결제는 테스트 모드
     │
운영 (production)   실제 사용자. 결제는 실 모드 (사람 승인 후 전환)

🔍 읽는 포인트 : 위에서 아래로 갈수록 실제 사용자와 돈에 가까워집니다. 그만큼 사람의 손이 더 들어갑니다.

3.2 환경마다 무엇이 다른가

이 차이는 모두 환경변수 (9차시)로 표현합니다. 원칙 ③ — 같은 코드에 다른 값을 넣을 뿐, 환경마다 코드를 복사하지 않습니다.

3.3 스테이징이 필요한 이유

"로컬에서 되면 운영에서도 되겠지"가 깨지는 지점이 있습니다. 실제 도메인의 CORS, 실제 클라우드 DB의 접속, 그리고 결제 입니다. 결제 대행사와의 연동(16차시)은 실제 인터넷 주소로 통지를 받아야 하는 부분이 있어 로컬만으로 다 시험하기 어렵습니다. 스테이징은 운영과 같은 구성인데 돈이 오가지 않는 곳 이라서, 운영으로 가기 전 마지막 시험장이 됩니다.

---

4. ⭐ 되돌릴 수 있는가 — 파일 수정 ↔ 적용

4.1 두 동작을 가른다

4.2 적용 전 계획 — 마지막 한 줄만 본다

Terraform 같은 도구는 적용 전에 무엇이 바뀌는지 계획(plan) 을 먼저 보여 줍니다(9차시의 plan mode와 같은 생각입니다). 전체를 읽을 필요는 없습니다.

Plan: 2 to add, 1 to change, 0 to destroy.

🔍 읽는 포인트 : destroy 앞의 숫자 만 봅니다. 0이 아니면 멈추고 "무엇이 삭제되는지, 그 안에 데이터가 있는지" 묻습니다.

4.3 인프라 역할 정의

# .claude/agents/infra.md
## 책임
- Dockerfile, compose, 배포 설정, 자동화 파이프라인 설정 파일 작성 · 관리
## 하지 않는 일
- 앱 기능 코드 수정, 운영 환경 직접 변경
## 권한
- 인프라 설정 파일만 수정
- 클라우드에 실제로 적용하는 명령(apply, deploy)은 사람의 승인을 받는다
## 완료 조건
- 로컬에서 docker compose up으로 전체가 뜬다 (출력 원문)
- 설정 파일에 비밀값이 없다
- 바뀐 설정과 그 영향을 보고한다

🔍 읽는 포인트 : "권한"의 둘째 줄이 0절 축 1 · 4입니다. 그리고 에이전트에게 클라우드 관리자 권한을 통째로 주지 않습니다.

4.4 비용 알림 — 코드로는 안 보이는 위험

AI가 만든 설정이 의도보다 큰 서버나 비싼 서비스를 띄울 수 있고, 설정 코드만 보고 그걸 알아채기는 어렵습니다. 클라우드 콘솔의 예산(Budget) 알림 으로 "월 3만 원을 넘으면 이메일" 같은 알림을 걸어 둡니다. 이것은 콘솔에서 한 번 설정해도 되는 안전망 이지만, 가능하면 이것도 설정 코드에 넣어 둡니다.

---

5. 클래스온에 적용하면 — 배포 설정 개요

3일차 배포(21 · 22차시)를 내다보고 지금 정해 둘 것들입니다.

---

6. 실습 — 맡기고 검수하기

지시

infra 역할로 진행해줘. 클라우드에 적용하는 명령은 실행하지 마.
1. 서버용 Dockerfile과, 서버 + DB를 함께 띄우는 docker-compose.yml을 만들어줘.
2. docker compose up을 실행하고, /health 호출 결과까지 출력 원문을 붙여줘.
3. 환경변수 목록을 [이름 | 로컬 값의 종류 | 스테이징 | 운영 | 비밀값인가] 표로 정리하고 .env.example을 갱신해줘.
   비밀값은 값 대신 "비밀"이라고만 써.
4. 만든 설정 파일 전체에서 비밀번호·키 모양의 문자열을 검색한 명령과 출력 원문을 붙여줘.
5. 바뀐 파일 목록과 각 파일이 하는 일을 한 줄씩 보고해줘.

받을 증거

• docker compose up과 /health 출력 원문
• 환경별 환경변수 표, 비밀값 검색 명령과 출력
• 바뀐 파일 목록

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 15차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"IaC와 콘솔 클릭의 차이", "환경 분리와 스테이징의 이유", "파일 수정과 적용의 차이(되돌릴 수 있는가)"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.