AI 드리븐

이 문서는 본문이 아닙니다. 지도 입니다.

처음 읽는다면 2장(정의하는 법) , 4장(전체 구조) , 5장(판별 축 지도) 만 먼저 읽고 1차시로 넘어가세요. 나머지는 필요할 때 돌아와 찾아 읽으면 됩니다.

이 노트는 이 폴더만으로 완결 되도록 썼습니다. 다른 교재나 자료를 찾아보지 않아도 되며, 처음 나오는 개념은 그 자리에서 설명합니다.

---

이 문서를 다 읽으면

1. 이 과정이 무엇을 만들고, 진짜 학습 목표가 무엇인지 말할 수 있다.
2. 새 용어를 만났을 때 던질 네 개의 질문 을 순서대로 댈 수 있다.
3. 과정 전체를 세 단계(결정 → 구현과 검증 → 신뢰와 운영) 로 나누고, 3일이 각각 어느 단계를 맡는지 말할 수 있다.
4. 이 노트 전체를 관통하는 여덟 개의 판별 축 을 대고, 각 축이 이 과정에서 어디에 나오는지 찾아갈 수 있다.
5. 과정 전체를 닫는 세 문장 을 말할 수 있다.
6. 각 차시 노트에서 "AI에게 맡기는 자리"와 "내가 검수하는 자리" 를 구분해 읽을 수 있다.

---

1. 이 과정은 무엇인가

1.1 한 문장

사람 한 명이 AI 에이전트들을 하나의 개발팀처럼 꾸려서, 기획부터 운영까지 실제로 돌아가는 웹 서비스를 끝까지 만들어 인터넷에 내보낸다.

과정이 끝나면 두 가지가 남습니다.

⭐ 두 번째가 진짜 학습 목표입니다. 서비스는 연습 대상이고, AI에게 일을 맡기고 그 결과를 믿을 수 있게 만드는 체계 를 익히는 것이 핵심입니다.

1.2 일정

---

2. 이 노트의 사고방식 — 정의하는 법

2.1 비유보다 범주를 먼저

"하위 에이전트는 팀원 같은 거예요", "훅은 경비원 같은 거예요" 같은 비유는 기억에는 좋지만 서로 겹칩니다. 겹치면 경계가 흐려지고, 둘이 무엇이 다른지 말할 수 없게 됩니다.

그래서 이 노트는 항상 이 순서 로 씁니다.

2.2 정의는 이 형식으로 씁니다

X — [상위 범주]인데, [ 종차 ]는 점에서 [형제 개념]과 구별된다.

상위 범주 는 "무엇의 한 종류인가"이고, 종차(種差) 는 "같은 종류 안의 형제들과 무엇이 다른가"입니다.

2.3 새 용어를 만났을 때 던질 네 개의 질문 ⭐

1. 이것은 무엇의 한 종류인가? (상위 범주)
2. 형제 개념과 무엇으로 갈리는가? (5장의 여덟 축 중 어디에 꽂히는가 )
3. 이건 아니다 — 반례는 무엇인가?
4. 그다음에야 비유를 찾는다. (기억 보조용으로만)

---

3. 각 차시 노트의 구조

모든 차시가 같은 자리 로 되어 있습니다.

┌──────────────────────────────────────────────────┐
│ 지도 위치          ← 몇 일차, 어느 단계, 앞뒤 차시       │
│ 이 차시를 다 읽으면  ← 학습 목표                       │
│ 0. 이 차시의 판별 축 ← 0/1 축 표, 5장의 어느 큰 축인가   │
│ 1~N. 본문          ← 정의 → 경계 → 반례 → 비유         │
│ N. 실습 — 맡기고 검수하기 ← AI에게 줄 지시, 받을 증거,    │
│                         내가 직접 확인할 것            │
├──────────────────────────────────────────────────┤
│ 부록 A. 스스로 확인하기  (질문 + 답이 있는 절)            │
│ 부록 B. 자주 하는 실수  (❌ / ⭕)                      │
│ 부록 C. NotebookLM 복습 프롬프트                      │
└──────────────────────────────────────────────────┘

기호 약속

---

4. 전체 구조 — 세 단계

[1일차: 결정 — 무엇을, 누가, 어떤 구조로]
 환경 준비 ─▶ AI 팀 기능 이해 ─▶ 요구사항→완료 기준 ─▶ 범위·API 설계
     ─▶ 역할 정의 원리 ─▶ 화면 설계 ─▶ 화면 검증 분리 ─▶ 아키텍처 결정 기록
                                                          │
[2일차: 구현과 검증 — 만들고, 제대로 만들었나]                  ▼
 뼈대 세우기 ─▶ 백엔드 ─▶ 프론트엔드 ─▶ 데이터 ─▶ 코드·동작 검증 ─▶ 보안 점검
     ─▶ 인프라 설정 ─▶ 결제 연동
                                                          │
[3일차: 신뢰와 운영 — 믿고 내보내고, 계속 돌리기]                ▼
 자동 테스트 ─▶ 버전 관리·커밋 검사 ─▶ 자동화 파이프라인 ①② ─▶ 서버 배포 ─▶ 화면 배포·끝까지 검증
     ─▶ 운영·장애 대응 ─▶ 데모·회고

순서에도 이유가 있습니다. 결정(1일차)이 구현(2일차)보다 먼저 오고, 구현은 다시 자동 검증(3일차)으로 둘러싸입니다. AI는 코드를 매우 빨리 만들기 때문에 병목은 "무엇을 만들지 정하는 것"과 "만든 것을 믿는 것" 쪽에 생깁니다. 이 과정은 그 두 지점에 시간을 씁니다.

---

5. ⭐ 판별 축 지도

판별 축 — 두 개념을 0과 1로 가르는 하나의 질문 입니다.

축은 비유와 다릅니다. 비유는 개념마다 새로 만들어야 하고 서로 겹치지만, 축은 여덟 개로 이 과정 전체를 덮고 서로 겹치지 않습니다. 새 용어가 나오면 어느 축의 어느 쪽에 꽂히는지만 정하면 됩니다.

5.1 여덟 개의 큰 축 — 정의

⚠️ ⑤의 어느 쪽도 "발전된 형태"가 아닙니다. 규모와 실패 비용에 따라 답이 정해집니다. 에이전트를 열 개로 쪼개는 것이 한 개보다 늘 나은 것이 아닙니다(5차시).

5.2 여덟 축이 이 과정에서 나오는 자리

5.3 이 과정에서 자주 쓰는 파생 축

큰 축에서 갈라져 나온 축들입니다. 이 과정의 핵심 원리 대부분이 여기 있습니다.

---

6. 과정 전체를 관통하는 세 문장

문장 1. 모호함을 측정 가능한 것으로 바꾼다 (모호함 ↔ 측정 가능)

"빠르게", "깔끔하게", "안전하게"는 AI가 판정할 수 없습니다. 완료 기준(3차시), API 명세(4차시), 디자인 토큰(6차시), 테스트(17차시)는 모두 말을 확인 가능한 기준으로 바꾸는 작업 입니다.

문장 2. 만드는 자와 검증하는 자를 분리한다 (만드는 자 ↔ 검증하는 자)

자기가 만든 결과를 자기가 검토하면 같은 맹점을 공유합니다. 그래서 디자인 검증(7차시), 코드 리뷰와 동작 검증(13차시), 자동 코드 리뷰(20차시)는 다른 역할, 다른 권한 으로 수행합니다.

문장 3. 부탁하지 말고 강제한다 (부탁 ↔ 강제)

AI는 지시를 "대체로" 지킵니다. 대체로는 충분하지 않은 영역(데이터 삭제, 비밀값, 결제, 배포)에는 시스템이 막는 장치 를 둡니다.

약함 ◀──────────────────────────────────────────────▶ 강함
 프롬프트로 부탁  →  지침 파일(기억)  →  권한 제한  →  훅 · 커밋 검사  →  자동 검사 관문

파괴 방지 장치(12차시), 위반 차단(14차시), 커밋 자동 검사(18차시), 통과 관문(19차시)이 이 사다리의 각 칸입니다.

---

7. 이 과정에서 꾸리는 AI 팀

사람(나)의 역할 은 팀장입니다. 목표를 정하고, 역할 사이를 조율하고, 돈 · 데이터 · 보안이 걸린 결정을 최종 승인합니다.

---

8. 노트 전체에서 쓰는 예제 서비스

클래스온 — 동네 공방(도자기, 가죽, 향수 등)의 원데이 클래스를 검색하고, 예약하고, 결제하는 서비스

• 사용자: 클래스 목록 보기 → 상세 보기 → 날짜 선택 → 예약 → 결제 → 내 예약 확인/취소
• 공방 운영자: 클래스 등록, 정원 설정, 예약자 확인
• 일부러 고른 까다로운 지점: 정원이 1자리 남았을 때 두 명이 동시에 예약 (13차시), 결제 금액 위변조 (16차시), 수강생 연락처 같은 개인정보 (14차시)

(실제 수업 예제와 다를 수 있습니다. 개념을 붙잡을 고리로만 쓰세요.)

예시 도구는 대부분 Claude Code (터미널에서 동작하는 코딩 에이전트) 기준으로 적었습니다. 다른 에이전트 도구도 이름만 다를 뿐 같은 개념(규칙 파일, 하위 에이전트, 훅, 외부 연결)을 갖고 있습니다.

---

9. AI에게 맡기는 방식으로 읽기

이 노트는 코드를 한 줄씩 읽지 않고, 큰 그림과 판단은 내가 쥐고 구현은 AI에게 맡기는 방식 을 기준으로 썼습니다. 그런데 이 방식에는 빈자리가 하나 있습니다. 많은 안전장치가 마지막에 "사람이 코드를 읽고 확인한다" 를 전제하기 때문입니다. 이 노트는 그 자리를 아래 네 가지로 채웁니다.

9.1 신뢰의 네 가지 근거 ⭐

코드를 읽는 능력이 부족한 만큼 ①과 ②에 더 많이 투자 해야 합니다. 그래서 강제 장치 차시(12, 14, 18, 19, 20)는 이 방식에서 선택이 아니라 필수 입니다. 반대로 AI의 말("구현했습니다", "안전합니다")은 신뢰의 근거가 아닙니다. 근거가 붙어 있을 때만 받아들입니다.

9.2 내가 쥐는 것과 맡기는 것

왼쪽 열은 코드를 몰라도 할 수 있는 일 입니다. 이 방식의 핵심 역량이 여기에 있습니다.

9.3 실습의 세 자리

각 차시의 실습은 이렇게 생겼습니다.

9.4 AI 보고에서 보이는 위험 신호

9.5 코드 블록 읽는 법

9.6 이 방식의 한계

학습용 · 개인 프로젝트 · 사내 도구라면 이 노트의 방식으로 충분히 운영할 수 있습니다. 실제 고객의 돈과 개인정보를 다루는 순간 에는 한 번은 사람의 눈을 거치세요.

---

10. 전체 목차

1일차 · 무엇을, 누가, 어떤 구조로

2일차 · 만들고, 제대로 만들었는지 확인

3일차 · 믿고 내보내고, 계속 돌리기

부록

• 용어 사전 — 상위 범주 열 포함, 헷갈리는 짝 모음