Train·Test 분할과 클라우드의 관리 범위

11. Train / Test 4분할 — 시험지와 정답지를 나누는 법

11.1 왜 나누는가

머신러닝에서는 일반화 성능을 확보하고 과적합(Overfitting) 을 방지하기 위해 전체 데이터를 학습용(Training) 과 시험용(Test) 으로 철저히 분리합니다.

과적합(Overfitting) — [학습 실패의 한 종류]인데, [학습 데이터는 잘 맞히지만 새 데이터는 못 맞히는 상태]라는 점에서 다른 실패와 구별된다.

기출문제만 통째로 외운 학생과 같습니다. 기출은 100점인데 실제 시험은 60점입니다. 그래서 한 번도 안 본 문제로 시험을 봐야 진짜 실력을 알 수 있습니다.

11.2 4분할 매트릭스 ⭐

전체 데이터를 문제(Feature)와 정답(Label) 관점으로 쪼개면 4단 분할 구조가 나옵니다.

       ┌──────────────────────────────────────┬──────────────────────────┐
       │               Features               │          Label           │
       │            (문제 / X 변수)            │    (정답 / y 변수 / GT)   │
┌──────┼──────────────────────────────────────┼──────────────────────────┤
│ Train│  X_train                             │  y_train                 │
│ Set  │  (학습용 문제집)                       │  (학습용 정답지)          │
├──────┼──────────────────────────────────────┼──────────────────────────┤
│ Test │  X_test                              │  y_test                  │
│ Set  │  (실전 시험지)                        │  (채점용 정답지)          │
└──────┴──────────────────────────────────────┴──────────────────────────┘

가로 축은 "문제냐 정답이냐", 세로 축은 "공부용이냐 시험용이냐" 입니다. 2×2 이므로 넷이 나옵니다. 3주차 1.2절의 좌표평면과 같은 사고법입니다.

11.3 각 영역의 역할과 통제 메커니즘

① Training Set (전체 데이터의 약 70~80%)

• X_train — 모델에게 보여주는 학습용 입력 데이터(특성)입니다.
• y_train — X_train 에 대응하는 정답(라벨)입니다. 모델은 이 둘을 교과서와 해설지처럼 함께 보며 가중치를 업데이트합니다.

② Test Set (전체 데이터의 약 20~30%)

• X_test — 학습이 끝난 모델의 실력을 검증하기 위해 던져주는 실전 시험 문제입니다.
• y_test — ⭐ 모델에게 절대 보여주지 않고 사람이 따로 쥐고 있는 채점용 정답지입니다. 모델이 X_test 를 풀어 예측값을 내놓으면, 그 결과를 y_test 와 비교해 최종 점수를 도출합니다.

from sklearn.model_selection import train_test_split

X = df.drop(columns=["Survived"])     # 문제  (Features)
y = df["Survived"]                    # 정답  (Label = Ground Truth)

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42
)

model.fit(X_train, y_train)           # ✅ 학습에는 train 만 쓴다
pred = model.predict(X_test)          # ✅ 시험은 X_test 로만
score = accuracy_score(y_test, pred)  # ✅ y_test 는 채점할 때 딱 한 번

💡 random_state=42 는 난수 시드입니다. 같은 숫자를 주면 항상 같은 방식으로 쪼개집니다. 재현 가능성(Reproducibility) 을 위한 장치이고, 값 자체에 의미는 없습니다.

11.4 ⚠️ 데이터 누수 (Data Leakage)

만약 X_test 나 y_test 가 학습 과정(X_train, y_train)에 조금이라도 섞여 들어가면 시험 문제가 유출된 것과 같으므로, 실제 현장에서는 무용지물이 되는 부실한 모델이 생성됩니다.

데이터 누수(Data Leakage) — [모델 평가의 오류]인데, [평가에 쓰여야 할 정보가 학습 과정에 흘러들어간 상태]라는 점에서 다른 오류와 구별된다.

무서운 점은 누수가 있으면 점수가 올라간다는 것입니다. 그래서 알아채기 어렵습니다.

⭐ 모든 전처리는 "나눈 다음에" 합니다. 순서 하나가 실험 전체를 무의미하게 만듭니다.

11.5 캐글 타이타닉의 train.csv 와 test.csv

1주차에서 타이타닉 데이터를 내려받았습니다. 이번 주에는 경진대회 페이지에서 다시 받았습니다. 파일이 두 개인 이유가 지금 설명됩니다.

🔗 https://www.kaggle.com/competitions/titanic/data

⭐ 캐글이 y_test 를 안 줍니다. 그게 경진대회의 규칙입니다. 참가자는 예측 결과만 제출하고, 캐글이 자기가 가진 정답으로 채점해 순위를 매깁니다. 즉 캐글 대회의 구조 자체가 11.3절의 통제 메커니즘을 그대로 구현한 것입니다.

💡 그래서 실무에서는 train.csv 를 또 한 번 쪼갭니다.

---

12. IaaS / PaaS / SaaS — 어디까지 내가 관리하는가

12.1 세 모델의 정의

클라우드 서비스는 제공업체가 어디까지 관리하고, 사용자가 어디부터 제어하느냐에 따라 세 가지로 분류됩니다. 셋 다 ~ as a Service 로 끝납니다. "~를 서비스로 빌려 쓴다" 는 뜻입니다.

12.2 책임 공유 모델 — 9층 표 ⭐

이 표 하나가 세 모델의 정의를 전부 대신합니다. 위에서 아래로 갈수록 하드웨어에 가깝습니다.

⭐ 표를 읽는 법: 경계선이 위로 올라갈수록 내가 할 일이 줄어듭니다. On-Premise ── IaaS ── PaaS ── SaaS 순으로 자유도와 관리 부담이 함께 낮아집니다.

⚠️ 이건 발전 단계가 아닙니다. SaaS가 IaaS보다 진화한 것이 아닙니다. 3주차의 모놀리식/MSA 논의와 같습니다. 필요에 따라 고르는 것입니다.

12.3 "피자 만들기" 비유 네 가지

💡 비유에서 '오븐'이 OS, '음료와 식기'가 데이터, '설거지'가 유지보수입니다. IaaS는 내 오븐을 쓰므로 OS를 내가 관리하고, PaaS는 배달되므로 OS를 안 건드립니다. 9층 표와 정확히 맞습니다.

12.4 선택 가이드

12.5 우리가 쓰는 것들을 분류해 보기

이 교재에서 지금까지 쓴 도구들을 이 축에 얹으면 이렇게 됩니다.

⭐ 이 주에 Ollama를 로컬에 설치한 것은 의도적으로 On-Premise로 내려간 것입니다. 데이터가 밖으로 안 나가고, 토큰 비용이 0이며, 오프라인에서 돌아갑니다. 대신 성능과 관리 부담을 대가로 치릅니다.

앞으로 다시 만납니다 — Docker(14.5절)는 이 표의 가상화(Virtualization) 층을 다루는 기술입니다. "내 컴퓨터에서는 되는데 서버에서는 안 된다"는 문제가 이 층에서 생기고, 이 층에서 해결됩니다.

---

13. 프롬프트 · 커맨드 · 서치

13.1 세 개의 정의

같은 입력창처럼 보이지만 셋은 완전히 다른 것입니다.

① 프롬프트 (Prompt) — 컴퓨터가 입력을 받을 준비가 되었다는 '대기 신호', 또는 생성형 AI에게 내리는 '지시문'. 전통적 의미는 CLI(터미널)에서 입력을 기다리며 깜빡이는 C:\> 또는 $ 같은 기호이고, 현대적 의미는 생성형 AI로부터 원하는 답변을 얻기 위해 입력하는 자연어 질문이나 명령문입니다. 정해진 문법 없이 일상 언어로 자유롭게 지시할 수 있어 자유도가 매우 높습니다.

⚠️ 한 단어가 두 뜻을 가진 이유 — 어원이 같습니다. 라틴어 promptus = "준비된, 즉시 내놓는". 연극에서 배우에게 대사를 일러주는 사람이 프롬프터(prompter) 입니다. "다음 말을 하도록 유도하는 신호" 가 핵심 의미입니다. 터미널의 $ 는 사람에게, AI 프롬프트는 AI에게 다음 말을 하라는 신호입니다. 방향만 반대일 뿐 같은 단어입니다.

② 커맨드 (Command) — 시스템이나 소프트웨어에 특정 동작을 수행하도록 내리는 직접적인 '명령어'. 미리 정의된 엄격한 규칙과 문법(Syntax) 을 따라야 하고, 철자나 공백이 틀리면 에러가 나므로 자유도가 가장 낮습니다. 파일 목록 ls / dir, 폴더 생성 mkdir, 시스템 종료 shutdown 등이 여기 속합니다.

③ 서치 (Search) — 방대한 데이터나 시스템 내부에서 조건·키워드에 맞는 정보를 찾아내는 '탐색 행위(검색)'. 실행하거나 설정을 바꾸는 것이 아니라 이미 존재하는 데이터를 필터링해 보여달라고 요청하는 것이며, 대략 입력해도 연관 결과를 찾아줍니다. 구글/네이버 검색, 파일 탐색기 검색, 문서 내 단어 찾기(Ctrl + F)가 예입니다.

13.2 핵심 차이점 비교표 ⭐

⭐ 가장 중요한 줄은 마지막 줄입니다. 커맨드는 틀리면 멈춥니다. 그래서 안전합니다. 서치는 틀리면 빈손이라 손해가 없습니다. 그런데 프롬프트는 틀려도 뭔가를 만들어냅니다. 그게 위험합니다. "답이 나왔다"가 "맞았다"를 뜻하지 않습니다. 할루시네이션 문제의 뿌리가 여기 있습니다.

13.3 작동 흐름과 비유

사용자가 컴퓨터를 조작할 때 세 개념은 이렇게 연결됩니다. ① 반짝이는 프롬프트(입력창) 가 활성화되어 명령을 기다리고 → ② 시스템을 제어하려면 정확한 커맨드를 입력하거나 → ③ 정보를 얻으려면 키워드로 서치를 수행합니다.

13.4 같은 구글인데 왜 하나는 서치, 하나는 프롬프트인가

이 주에 나온 질문입니다. 구글 검색과 제미나이(Gemini)는 같은 회사 제품이고 둘 다 입력창이 하나 있습니다. 그런데 하나는 '검색엔진'이라 부르고 하나는 '언어모델'이라 부릅니다. 차이는 입력창이 아니라 뒤에 있는 것입니다.

⭐ 판별 축: "찾는가, 만드는가." 찾는 것은 서치이고, 만드는 것은 프롬프트입니다. 입력창의 생김새는 같아도 하는 일이 근본적으로 다릅니다. 이것이 이 주 마지막 날의 주제(할루시네이션 대응, 14.13절)로 이어집니다.

---

14. 실습 — 이번 주에 손으로 한 것

14.1 프랙탈 구조 완성 — 파일명 일괄 정리 프롬프트

6주차에서 빈 파일들을 만들어 뒀습니다. 이번 주에는 열 개 폴더의 이름 규칙을 한 번에 통일했습니다.

api/schemas 폴더의 파일명을 기준으로

  api/v1
  adapter/outbound/orm
  adapter/outbound/pg
  app/dtos
  app/ports/input
  app/ports/output
  app/use_cases
  dependencies
  domain/entities
  domain/value_objects

위 폴더들의 접두사·접미사를 서로 일치시키고,
그 과정에서 발생하는 import 에러까지 전부 수정해줘.

결과 형태는 james_schema.py(api/schemas) · james_router.py(api/v1) · james_orm.py(orm) · james_pg_repository.py(pg) · james_dto.py(dtos) · james_use_case.py(ports/input) · james_repository.py(ports/output) · james_interactor.py(use_cases) · james_dependency.py(dependencies) · james.py(domain/entities) 처럼 접두사 하나로 열 개가 묶입니다.

💡 왜 이 작업이 중요한가 — 3주차의 프랙탈 구조를 파일명 레벨까지 밀어붙인 것입니다. 이름이 규칙적이면 파일 하나만 보고 나머지 아홉 개의 위치를 추론할 수 있습니다. 사람에게도 그렇지만 AI에게 특히 그렇습니다. 6주차 11.4절의 "좋은 아키텍처는 토큰을 아낀다"의 실천입니다.

⚠️ 이런 대규모 리네이밍은 import 에러를 반드시 동반합니다. 그래서 프롬프트에 그 수정까지 명시적으로 넣습니다. "파일명만 바꿔줘"라고 하면 프로젝트가 안 켜지는 상태로 끝납니다.

14.2 CLAUDE.md 최상위 규칙 만들기

프로젝트 루트에 AI가 항상 지켜야 할 규칙을 문서로 못 박습니다.

CLAUDE.md 최상위 규칙을 만들어줘.

- 카파시의 하네스 엔지니어링 위에 Wiki + LLM 의 PKS 를 구현한다
- 반드시 SOLID 를 준수한다
- 헥사고날 + 클린 아키텍처 + DDD 를 적용한다
- 내부 경로 표기에서 tailor / apps 는 생략한다
- core 경로는 tailor.core. 로 시작한다
- ⚠️ 규칙 본문은 영어로 작성한다

⚠️ 왜 규칙 본문을 영어로 쓰는가 — 모델이 학습한 기술 문서 대부분이 영어이기 때문입니다. 같은 지시라도 영어 쪽이 토큰 수가 적고 해석이 안정적입니다. 반면 설명과 대화는 한국어로 합니다. 규칙(기계가 읽는 것)과 설명(사람이 읽는 것)의 언어를 분리하는 것입니다.

💡 이 파일이 6주차 11.1절 하네스의 가이드(Guide, 피드포워드) 에 해당합니다. 행동하기 전에 방향을 잡아주는 장치입니다.

14.3 CLAUDE.md 4개 구조 — 시블링 확장을 전제로

주 후반에는 CLAUDE.md를 하나에서 넷으로 쪼갰습니다.

프로젝트 루트/
├── CLAUDE.md                 ① 루트 — 공통 원칙 (SOLID, 아키텍처, 경로 규칙)
├── tailor/
│   └── CLAUDE.md             ② 백엔드 — FastAPI, SQLAlchemy, 포트/어댑터 규칙
│       └── apps/titanic/
│           └── CLAUDE.md     ④ 타이타닉 앱 — 이 앱에만 해당하는 것
└── taylor/
    └── CLAUDE.md             ③ 프론트엔드 — Next.js, 컴포넌트 규칙

타이타닉의 CLAUDE.md는 루트 내용을 복사하지 않고 링크로 참조합니다. 3주차에서 배운 시블링(Sibling) 구조 — 앱이 titanic, walter, rose 처럼 옆으로 늘어날 것을 전제하기 때문입니다.

⭐ 이 작업 자체가 이 장의 OCP입니다. 앱이 하나 늘 때 루트 CLAUDE.md를 여는가(변경), 앱 폴더에 하나 더 만드는가(확장)? 답은 후자여야 합니다. 3.2절의 include_router 와 완전히 같은 구조입니다.

14.4 __abstract__ = True — 테이블 없이 설계만

실제 DB 테이블을 만들지 않고 설계만 유지하려면 ORM 클래스 안에 한 줄이면 됩니다.

class TimeStampedORM(Base):
    __abstract__ = True     # 이 클래스는 테이블로 만들지 않는다

자세한 설명은 2.8절에 있습니다.

14.5 Docker 설치와 도커허브

Docker란 무엇인가 — 애플리케이션과 그것이 돌아가는 데 필요한 환경 전체를 하나의 상자(컨테이너)에 담는 기술입니다. 4주차 격리 3단계에서 예고했던 그 컨테이너입니다.

가상환경 (venv/conda)   →   컨테이너 (Docker)   →   가상 머신 (VM)
   패키지만 격리            OS 라이브러리까지 격리      OS 통째로 격리

설치 — 관리자 권한 PowerShell에서 wsl --install. WSL(Windows Subsystem for Linux)은 윈도우 안에서 리눅스를 돌리는 장치입니다. Docker Desktop이 리눅스 컨테이너를 실행하려면 이게 먼저 필요합니다. 설치 후 재부팅합니다.

도커허브(Docker Hub) 🔗 https://hub.docker.com/ — 이미지를 올리고 내려받는 공용 저장소입니다. 1주차 축 2(로컬 ↔ 원격)의 한 쌍이고, 구조가 전부 같습니다.

⭐ "내 것을 만든다 → 공용 저장소에 올린다 → 남이 받아 쓴다." 이름만 다를 뿐 하나의 패턴입니다.

14.6 캐글 타이타닉 — 피처 확인과 재다운로드

🔗 https://www.kaggle.com/competitions/titanic/data — train.csv 와 test.csv 를 받습니다. 두 파일의 차이는 11.5절에 있습니다.

받은 뒤 가장 먼저 할 일 — 피처 확인

import pandas as pd

train = pd.read_csv("train.csv")

print(train.shape)          # (891, 12) — 행/열 개수
print(train.columns)        # 피처 목록
print(train.info())         # 타입과 결측치 개수
print(train.isnull().sum()) # 컬럼별 빈칸 개수
print(train.describe())     # 숫자 컬럼의 기초 통계

⭐ isnull().sum() 이 곧 6.3절 결측치 처리의 시작점입니다. 타이타닉에서는 Age 와 Cabin 에 빈칸이 많습니다.

⚠️ 11.4절을 잊지 마세요. 채우기는 나눈 뒤에 합니다.

14.7 Ollama 설치와 로컬 한국어 모델

Ollama 🔗 https://ollama.com/download/windows — 설치 후 명령 프롬프트(cmd)에서:

ollama run anpigon/eeve-korean-10.8b

>>> 프롬프트가 뜨면 한국어로 테스트해 보고, /exit 로 종료합니다.

⚠️ 여기서 나오는 >>> 가 13.1절의 전통적 의미의 프롬프트입니다. "입력을 기다리고 있다"는 신호입니다. 그 뒤에 자연어를 치면 현대적 의미의 프롬프트가 됩니다. 같은 화면 안에서 한 단어의 두 뜻이 동시에 보이는 드문 장면입니다.

왜 EEVE-Korean인가 — 야놀자가 공개한 한국어 특화 모델로, 기본 Llama3보다 한국어 속도와 문맥 이해가 우수합니다. 로컬 모델은 크기가 곧 요구 메모리이므로, 한국어를 잘하는 작은 모델을 고르는 것이 관건입니다.

14.8 kiwipiepy + Ollama — 경쟁이 아니라 상호보완

# requirements.txt 에 최신 버전으로 추가
kiwipiepy
ollama

로컬 한국어 조합의 결론 — ⭐ 둘은 경쟁 관계가 아니라 상호보완입니다.

원문 ──▶ [ kiwipiepy ] ──▶ 정제된 토큰 ──▶ [ EEVE on Ollama ] ──▶ 답변
          전처리기                              모델

⚠️ 자주 하는 혼동: "Ollama가 AI 모델인가요?" — 아닙니다. Ollama는 모델을 실행하는 런타임(플랫폼) 이고, 모델은 그 위에 올라가는 내용물입니다. 유튜브와 유튜브 영상의 관계와 같습니다.

14.9 더 가벼운 모델로 교체

10.8B 모델은 개인 PC에서 무겁습니다. 더 작은 모델로 바꾸고, 도커가 아니라 낱개 파일로 실행해 확인합니다.

ollama pull qwen2.5:3b
python test.py

💡 왜 도커가 아니라 낱개 파일인가 — 문제를 좁히기 위해서입니다. 컨테이너 안에서 실행하면 실패했을 때 모델 문제인지 컨테이너 설정 문제인지 구별이 안 됩니다. 먼저 가장 단순한 형태로 되는 것을 확인하고, 그다음 감쌉니다. 6주차 10.5절의 "먼저 동작하는 것을 만든다"와 같은 순서입니다.

⭐ 8장의 CPU/GPU 이야기가 여기서 체감됩니다. GPU가 없으면 CPU로 돌아가는데, 큰 모델일수록 그 차이가 견딜 수 없어집니다.

14.10 TDD 실습 — pytest 세 가지 실행

cd tailor

# ① 전체 단위 테스트 (82개, test_korean_ai 제외)
python -m pytest

# ② Ollama 연동 테스트 — Ollama 서버가 켜져 있어야 함
python -m pytest apps/titanic/tests/test_korean_ai.py -m ollama -v -s

# ③ 테스트 파일을 그냥 파이썬으로 실행
python apps/titanic/tests/test_korean_ai.py

옵션 읽는 법

⚠️ 왜 Ollama 테스트를 따로 떼어놓는가 — 외부 서버가 필요한 테스트이기 때문입니다. Ollama가 꺼져 있으면 실패하는데, 그건 코드가 틀린 게 아니라 환경이 없는 것입니다. "코드의 문제"와 "환경의 문제"를 섞으면 테스트를 믿을 수 없게 됩니다. 그래서 마커로 분리합니다.

💡 이게 하네스의 센서(Sensor)입니다. 가이드(CLAUDE.md)가 행동 전 방향을 잡고, 센서(테스트)가 행동 후 결과를 확인합니다.

14.11 프론트 채팅창 → 백엔드 라우터 연결

① 프론트 — captain-smith/page.tsx

const res = await fetch("/api/titanic/smith/chat", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ messages }),      // ⭐ 키값은 messages
});

② 백엔드 — crew_smith_captain_router.py

from fastapi import APIRouter, Body

crew_smith_captain_router = APIRouter()

@crew_smith_captain_router.post("/smith/chat")
async def chat(messages = Body(...)):
    print(f"[Router] {messages}")          # ⭐ 먼저 로그부터
    return {"ok": True}

⭐ 성공 판정 기준은 "답변이 나오는 것"이 아니라 "로그가 찍히는 것"입니다. 6주차 10.4절과 같은 원칙입니다. 흐름이 여러 조각으로 나뉘면 로그가 유일한 눈입니다.

연결이 안 될 때 확인 순서 — ① 브라우저 개발자도구 Network 탭(요청이 아예 안 나갔는가) → ② 요청 URL이 라우터 경로와 같은가(prefix 중복 /api/titanic 두 번) → ③ Body의 키 이름이 같은가(message vs messages) → ④ 백엔드 콘솔에 로그가 찍히는가(여기까지 오면 절반은 성공) → ⑤ CORS 에러(3주차 설정 확인).

⚠️ 3번이 가장 자주 나오는 실수입니다. 키 하나가 다르면 FastAPI는 422 Unprocessable Entity 를 돌려줍니다. "서버는 켜졌는데 422가 뜬다"면 경로가 아니라 몸통(Body)을 의심하세요.

14.12 옵시디언 정리 — 개발 파일 숨기기

코드 폴더를 옵시디언 vault로 열면 .py, node_modules 같은 게 전부 보여서 노트가 묻힙니다. 기획 노트만 보이게 만드는 설정입니다.

① vault 전환 — 좌측 하단 vault 이름 → Manage vaults... → Open folder as vault

② 제외 파일 설정 — 좌측 하단 톱니바퀴 → 파일 및 링크(Files and links) → 고급 설정 > 제외하는 파일(Excluded files) 의 관리 버튼

설정에 보관함 캐시 다시 빌드하기 가 있습니다. vault 크기에 따라 몇 초에서 몇 분 걸립니다.

③ CSS 스니펫 추가 — 설정 > 외형(Appearance) → 하단 CSS snippets 의 폴더 열기(vault/.obsidian/snippets) → 새 텍스트 문서를 hide-cache.css 로 이름 변경 후:

div[data-path$="alembic"],
div[data-path*="__pycache__/"] {
    display: none !important;
}

④ 커뮤니티 플러그인 — 설정 > Community plugins → Browse → Show Hidden Files 설치 → 이어서 File Hider (by eldritch-oliver) 설치 후 토글 활성화 → 톱니바퀴에서 Show all file types 와 Show hidden files 를 둘 다 비활성화

⑤ 그래도 보이면 — 해당 폴더를 우클릭 후 Hide Folder. 마지막으로 옵시디언을 껐다 켭니다.

💡 이 작업도 이 장의 주제와 이어집니다. 노트(사람이 읽는 것)와 코드(기계가 읽는 것)의 경계를 긋는 일입니다. 14.2절에서 규칙은 영어, 설명은 한국어로 나눈 것과 같은 종류의 분리입니다.

14.13 할루시네이션을 극복하는 두 가지 방법

주 마지막 날의 주제입니다. 13.2절의 "프롬프트는 틀려도 뭔가를 만들어낸다" 에 대한 대응책입니다.

①은 입력 쪽을 고치고, ②는 출력 쪽을 검사합니다. 6주차 11.1절의 하네스 두 축 — 가이드(피드포워드)와 센서(피드백) — 와 같은 쌍입니다.

이 주에 LLM에게 실제로 던진 검증 질문이 이것입니다.

하네스 엔지니어링에서 머신러닝 단계의 할루시네이션 감소를 위해 RAG를 구성할 때,
켄트 벡의 TDD를 도입하는 것이 철학적으로 맞는가?

⭐ 이 질문 자체가 훈련입니다. 답을 얻으려는 질문이 아니라 모델이 개념을 제대로 연결하는지 보려는 질문입니다. TDD는 "먼저 실패하는 테스트를 쓰고, 그걸 통과시키는 코드를 쓴다"입니다. RAG에 적용하면 "먼저 기대하는 답의 기준을 정하고, 그 기준을 통과하는 검색·생성을 만든다" 가 됩니다. 즉 위 표의 ②를 ①보다 먼저 놓는 순서입니다.

💡 AI 답변을 검증하는 실전 요령: 내가 이미 아는 주제로 물어보세요. 모르는 주제로 물으면 답이 맞는지 알 수 없습니다. 아는 것으로 모델을 재고, 그다음 모르는 것을 묻습니다.

---

15. 이 주의 읽을거리와 그 맥락

15.1 인간은 고리 밖에 있다 — Why loop vs How loop

🔗 https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html

AI 에이전트가 코드를 쓰는 시대에 사람의 자리가 어디인가를 다룬 글입니다. 핵심은 두 개의 고리(loop) 입니다.

전통적으로 개발자는 How loop 안에 있었습니다. 한 줄 쓰고, 돌려보고, 고치는 것을 직접 했습니다. 이제 그 안쪽 고리는 에이전트가 돕니다. 사람은 밖에서 방향을 정하고 결과를 받아들일지 판단합니다.

이게 왜 이 주의 자료인가 — 이 장의 OCP와 같은 그림이기 때문입니다.

     Why loop (사람)   ←── 안 바뀌는 쪽 = 변경에 닫힘
     ─────┼───────────── 인터페이스 = 명세·수용 기준·CLAUDE.md
     How loop (에이전트) ←── 갈아끼우는 쪽 = 확장에 열림

3.5절에서 pg_repository 를 mongo_repository 로 갈아끼워도 유스케이스가 안 바뀌었습니다. 같은 방식으로 How loop를 사람이 돌든 에이전트가 돌든 Why loop는 안 바뀝니다. 그래서 명세와 수용 기준을 문서로 못 박는 일(14.2절 CLAUDE.md) 이 그 인터페이스가 됩니다.

⭐ 경계를 명확히 그은 사람만 안쪽을 자동화할 수 있습니다. 이 장 전체의 메시지와 같습니다.

15.2 AI 코딩의 발전단계 — 하네스 엔지니어링과 완전 자율형 에이전트

🔗 https://bcho.tistory.com/m/1508

AI 코딩 도구가 어디까지 왔고 어디로 가는지를 단계로 정리한 글입니다.

이게 왜 이 주에 나왔는가 — 이 주의 작업이 정확히 ③단계이기 때문입니다. 파일명 규칙을 통일했고(14.1), CLAUDE.md로 규칙을 못 박았고(14.2, 14.3), 82개의 테스트를 돌렸습니다(14.10).

⭐ 셋 다 "코드를 쓴 일"이 아니라 "AI가 지킬 구조를 만든 일"입니다. 그리고 그 구조의 이름이 이 장에서 배운 LSP와 OCP 입니다. "AI가 아무 파일이나 열지 못하게" 만드는 것이 OCP이고, "AI가 만든 하위 타입이 기존 코드를 깨지 않게" 만드는 것이 LSP입니다.

15.3 스키마와 인스턴스

🔗 https://computer-science-student.tistory.com/478

이게 왜 이 주의 자료인가 — 이 주에 Schema 라는 단어를 세 가지 뜻으로 썼기 때문입니다(5.2절). Pydantic Schema, DB Schema, PostgreSQL의 네임스페이스 schema. 같은 단어가 층마다 다른 것을 가리킬 때, 원래 뜻(틀·형태)으로 돌아가면 길을 잃지 않습니다.

15.4 캐글 타이타닉 경진대회 데이터

🔗 https://www.kaggle.com/competitions/titanic/data

이게 왜 이 주의 자료인가 — 1주차에서는 "이진 분류 연습용 CSV"로 받았지만, 이번 주에는 11장의 4분할 구조를 실제로 확인하기 위해 다시 받았습니다. train.csv 에는 Survived 가 있고 test.csv 에는 없다는 사실 하나가, "y_test 는 모델에게 보여주지 않는다"는 원칙의 살아 있는 증거입니다.

15.5 도커허브

🔗 https://hub.docker.com/

이게 왜 이 주의 자료인가 — 12장의 IaaS/PaaS/SaaS 축과 짝을 이룹니다. 클라우드가 "어디까지 남이 관리하는가" 의 축이라면, 컨테이너는 "어디까지 내가 싸 들고 다니는가" 의 축입니다. Docker 이미지는 앱 + 런타임 + OS 라이브러리를 통째로 포장한 것이라 어느 클라우드에 올리든 같은 결과가 나옵니다. 12.2절 표에서 벤더 종속을 줄이는 장치입니다.

15.6 옵시디언 설정 정리 노트

🔗 https://share.evernote.com/note/674a0370-7bb1-40f3-ac6f-f412e74c05b2

이게 왜 이 주의 자료인가 — 14.12절의 절차 원본입니다. 노트와 코드가 같은 폴더에 있는 구조(모노레포)를 택했기 때문에 생긴 문제이고, 3주차에서 배운 모노레포의 대가(trade-off) 가 실제로 나타난 장면입니다.

---

부록 A. 용어 사전

---

부록 B. 스스로 확인하기

먼저 답해보고, 막히면 옆의 절을 펼치세요.

---

부록 C. 자주 하는 실수

---

부록 D. 날짜별 색인

이 장의 내용이 실제 수업에서 어느 날 다뤄졌는지입니다.

---

부록 E. Gemini / NotebookLM 프롬프트

복습 문제 받기

이 7주차 교재만 근거로 8문제를 내줘. 비전공자 기준으로.
"LSP는 데이터 객체에, OCP는 제어 컴포넌트에"와
"Train/Test 4분할과 데이터 누수"는 반드시 포함해줘.
답은 바로 주지 말고, 내가 답한 다음에 채점하고
틀린 이유를 교재의 어느 절을 근거로 설명해줘. 교재에 없는 내용은 꺼내지 마.

인포그래픽 ① — 이 장의 중심 개념

「1.5 왜 데이터에는 LSP, 제어에는 OCP인가」와 「4.1 한 번의 요청, 두 개의 원칙」을 합쳐
인포그래픽 1장으로 만들어줘.
- 왼쪽에 LSP: 상위 타입 하나에서 Schema / DTO / VO / Entity / ORM 다섯 갈래가 뻗어나가는 그림
- 오른쪽에 OCP: Router → Use Case → Repository(IF) → pg_repository / mongo_repository 세로 흐름
- 가운데에 "상자에는 OCP, 화살표에는 LSP" 한 문장을 크게
- 전문용어는 한글(영문) 병기

인포그래픽 ② — 머신러닝과 딥러닝

「7.2 핵심 차이점」과 「7.3 특징 추출의 주체」와 「8.1 두 개의 비유」를 한 장으로 만들어줘.
- 위쪽 절반: 머신러닝 — 사람이 [SIZE][COLOR][WEIGHT]를 지정 → 알고리즘 → 규칙, 그리고 'CPU = 대학교수 1명'
- 아래쪽 절반: 딥러닝 — Raw 이미지 → 신경망 층(선 → 질감 → 물체 부위) → 규칙, 그리고 'GPU = 초등학생 3,000명'
- 하단 배너: "머신러닝은 인간의 특징 정의가 필요하지만, 딥러닝은 특징 추출까지 자동으로 수행합니다"

인포그래픽 ③ — 데이터 4분할과 클라우드 9층

두 장을 만들어줘.
(1) 「11.2 4분할 매트릭스」를 2×2 표로 — 가로축 Features(문제/X) ↔ Label(정답/y/Ground Truth),
    세로축 Train Set(70~80%) ↔ Test Set(20~30%). y_test 칸만 색을 다르게 하고
    "모델에게 절대 보여주지 않음"과 '데이터 누수(Data Leakage)' 경고 박스를 붙여줘.
(2) 「12.2 9층 표」와 「12.3 피자 비유」를 합쳐 — App/Data/Runtime/Middleware/OS/가상화/서버/스토리지/네트워크를
    세로로 쌓고 On-Premise / IaaS / PaaS / SaaS 네 열로 '사용자'와 '제공업체'를 색으로 구분,
    각 열 아래에 피자 비유(직접 만들기 / 밀키트 / 배달 / 외식) 한 줄 설명.

막힐 때

7주차에서 "___" 가 이해가 안 돼.
이 교재의 판별 축 5개(치환/확장, 정적/동적, 사람이 정의/기계가 발견, 순차/병렬,
어디까지 내가 관리하는가)만 써서 다시 설명해줘. 교재에 없는 새 비유는 만들지 마.

내 코드 진단시키기

아래 파이썬 코드를 붙여넣을게. 이 교재의 2.9절(LSP 자가 진단 5문항)과
3.6절(OCP 자가 진단 5문항) 체크리스트만 써서 진단해줘.
교재에 없는 원칙은 꺼내지 말고, 위반이 있으면 몇 번 문항에 걸리는지 번호로 알려줘.

앞뒤 장과의 연결 확인

이 7주차 교재에서 "3주차"~"6주차"라고 언급된 부분과 "앞으로 다시 만납니다"라고 표시된 부분을
전부 찾아서 표로 정리해줘. 컬럼은 "다른 장 / 그때의 이름 / 이번 장의 절 / 이번의 이름 / 무엇이 달라졌나".