> *"오늘 우리가 자연어로 AI에게 일을 시키는 것은, 1947 년 종이에 플로차트를 그리던 그 행위의 최신 형태일 뿐이다."* ---

본 lesson 카드는 VCH 트랙 의 강의 활용 자리. 95 entity (언어 38 + OS 25 + 도구 32) + 18 synthesis (그룹) 의 진입점. 이 카드 하나만 읽으면 강의 도입 5 분이 완성되도록 구성. 다른 113 카드는 깊이 들어갈 때 펼침. ---

- 95 SNLR 기록 (group-g1 ~ group-se_g6) - 강사 직접 경험 (FORTRAN 펀치카드) - Karpathy LLM Wiki + Claude Code · Cursor 동시대 자료 - 기록 메모리: feedback_inference-bottleneck-is-memory.md 기록 ---

> 에이전트의 시간은 쿼리 루프의 시간이다. 한 턴이 한입(One Bite) 이어야 수렴한다. 한입이 아니면 시간은 빙빙 돈다.

LLM 한 번 호출은 함수 다. 들여보내는 프롬프트가 있고 받아 보는 텍스트가 있다. 변수가 둘. 두 개로 사고하면 충분했다 — 그게 prompt-engineering 함수 시대 의 사고방식.

에이전트는 다르다. 함수가 아니라 루프. 프롬프트가 들어가면 모델이 도구를 부르고, 도구가 결과를 돌려주고, 그 결과가 다시 모델 입력에 합쳐지고, 모델이 또 도구를 부르고. 그렇게 도구 호출 없는 응답이 나올 때까지 돈다. 한 번 도는 것을 한 턴 이라 부른다.

이게 시간 요소 의 본질. 그리고 흥미로운 건 — 종래의 SE 에서는 이런 루프가 사실상 불가능했다. 사람이 한 사이클을 돌리는 비용이 너무 컸다. AI 가 한 사이클을 분 단위로 돌려 주는 시대 가 되어서야 — 이 루프가 처음으로 가능해졌다.

쿼리 루프가 수렴하려면 — 한 턴에 처리하는 작업이 한입 크기 여야 한…

> 공간은 유한하다. 한도 안에서도 길어지면 썩는다. 부패는 토큰 한도의 문제가 아니라 attention 분산의 문제다.

에이전트의 공간은 컨텍스트 윈도우. 그리고 그것은 유한하다.

→ 어느 모델이든 무한한 메모리가 아니다. 모든 에이전트 설계는 결국 — 유한한 버퍼 안에서 무엇을 살리고 무엇을 버릴지의 문제.

컨텍스트 부패는 토큰 한도 초과가 아니다. 한도 안에서도 — 모델 성능이 점진적으로 떨어지는 현상.

왜 부패하는가: LLM 은 attention 메커니즘. 컨텍스트가 길어질수록 같은 토큰에 분산되는 attention 의 질이 떨어짐.

> 200K 윈도우에 50K 만 차 있을 때와 180K 차 있을 때의 모델은 같은 모델이 아니다. 후자는 부패한 모델.

여기서 시간 요소 (3 장) 와 공간 요소가 만난다. 한입이 부패를 막는다.

큰 덩어리를 한 턴에 처리하려고 하면 — 도구 결과가 컨텍스트를 부풀린다. 한 파일을 통째로 read 하면 그 결과가 KB 단위로 기록됨. 10 번 read 하면 …

> 모델 + 도구 = 에이전트. 도구는 모델의 손과 발이다. 도구가 늘어도 무너지지 않게 호환성과 확장성을 기록하는 일이 연결 요소다.

여기서 모델이 에이전트가 된다. 가장 결정적인 구분.

모델 자체는 토큰 인 → 토큰 아웃 함수 일 뿐. 텍스트 생성기다. 에이전트가 아니다. 두뇌만으로는 세상에 아무 영향을 못 준다 — 파일 하나 못 읽고, 명령 하나 못 실행하고, API 하나 못 부른다.

모델이 에이전트가 되는 순간은 — 외부 도구가 연결되는 순간. 도구는 모델의 손과 발:

> 모델 + 도구 = 에이전트. 이게 공식이다.

도구 없이는 그냥 챗봇이고, 도구가 붙는 순간부터 에이전트 라 부른다. 그래서 연결 요소가 단순 옵션이 아니라 에이전트의 정체성.

Claude Code 도구 약 40 개:

여기에 MCP (Model Context Protocol) — Anthropic 표준화 외부 도구 통합 프로토콜. JSON-RPC 기반, 사용자가 만든 MCP 서버를 Claude Code 에 붙이면 그 서버…

> 검증은 가소성의 전제이고, 가소성은 지식 성장의 조건이다. 좋은 시스템은 시간이 지날수록 좋아진다 — 검증이 그 효과를 만든다.

검증은 에이전트의 건강검진. 자기 자신과 자기가 만든 결과물을 점검하는 메커니즘.

검증 없이 도는 에이전트 — 잘못된 코드 위에 잘못된 코드를 쌓는다. 한 번 만든 코드는 틀린 채로 굳고, 한 번 내린 결정은 잘못된 채로 누적. 검증 메커니즘이 작동해야 비로소 잘못 됐다가 발견 되고, 발견되어야 갱신 된다.

검증의 본질 = 가소성. 신경망에서 빌려온 용어. 에이전트 맥락에서는 — 기존 지식·결정·산출물이 새 정보에 의해 갱신될 수 있는 능력. 검증 없이는 가소성도 없다. 가소성 없이는 지식이 자라지 않는다.

> 검증은 가소성의 전제이고, 가소성은 지식 성장의 조건이다.

*가드레일은 막는 일. 건강검진은 점검하는 일. 둘 다 검증.*

그리고 한 가지 더 — 검증 자체도 계층적·구조화 되었는지를 검증. 검증의 메타 차원. 검증 시스템이 잘 짜였는가를 검증. 이게 시간…

Claude Code 가 매 요청 에 자동 병합 하는 8 레이어 컨텍스트 스택 — 실벨 개발자 YouTube 강의 출처. 아래로 갈수록 강력 (헌법 메타포의 반대 방향 — 강의 핵심 주의).

→ 두 비유 방향 반대 — Ch2 에서 명확 분리.

> *Vibe Coding 을 처음 명명한 거인 이 1 년 후 자기 부정. 같은 시기 4 거인 (Karpathy / Lütke / Cherny / GitHub) 이 서로 다른 자리에서 같은 결론 으로 수렴 — Plan Mode + 하네스 + 4 엔지니어링.* ---

본 단원은 4 거인이 각각 다른 분야 를 박은 합. → 4-engineering-disciplines 의 4 분야가 4 거인의 결론 으로 기록됨: - 프롬프트 엔지니어링: Karpathy 가 시작점 으로 기록 - 컨텍스트 엔지니어링: Lütke 가 bottleneck moved 로 기록 - 하네스 엔지니어링: Cherny 가 에이전트 팀 으로 기록 - 에이전틱 엔지니어링: 4 거인 수렴이 Plan Mode + 자율 에이전트 로 기록 ---

int-ai-native-mindset (3 장 — AI 네이티브 4 단계). ---

60_service/booklet/part-1-int/ch02-giants-w…

> *설계의 필요도는 프로젝트의 규모 와 시간 축 에 따라 비선형으로 증가한다. 어느 임계점을 넘는 순간 급격히 필요해진다.*

> "여러분의 과제는 곡선 왼쪽. 졸업하면 오른쪽으로 갑니다. > 이 책은 그 오른쪽으로 갈 때를 대비하라는 책입니다."

이 책 한 권 전체를 반박 하는 단 하나의 질문 — 우수한 학생일수록 더 자주 던진다.

> "교수님, 제 과제는 100 줄 / 3 일짜리인데 — 설계 안 해도 잘 돌아갔는데요?"

이 질문이 틀린 질문이 아니다. 맞는 관찰이다. 다만 위치를 바꿔서 본다.

→ 임계점은 약 10,000~100,000 줄 사이. 이 구간에서 설계 비율이 25% → 50% 로 점프.

100 줄에서 조금 늘면 설계가 조금 필요해지는 게 아니다. 어느 임계점 을 넘는 순간 급격히 필요해진다.

> 여러분의 지금 = 0% 설계 / 100 줄 / 1 일. > 여러분의 6 개월 후 = 80% 설계 / 100 만 줄 / 6 개월.

가장 중요한 한 줄: 과제에서 안 했던 일이 입사하면 전부 …

> *무설계 Vibe Coding 의 청구서는 5 곳에서 동시에 도착 한다 — 기술 부채 / 보안 / 데이터 모델 / 운영 / 인간 역량. 모두의 단일 원인 = 컨텍스트 부패 + 요구사항 표류.* ---

- 프롬프트 엔지니어링: 한 줄 위임의 모호함 → 5 청구서의 시작점 - 컨텍스트 엔지니어링: CLAUDE.md ❌ → 청구서 ①·② (부패·보안) - 하네스 엔지니어링: 검증 ❌ → 청구서 ③·④ (데이터·운영) - 에이전틱 엔지니어링: Subagent 격리 ❌ → 청구서 ⑤ (인간 역량) → 4 분야 모두 깨졌을 때 5 청구서가 기록됨. 역으로 — 4 분야가 박히면 5 청구서가 막힘. ---

본 단원이 진단의 정점. 다음 — 처방 — Part 3 의 hrn-4layer-architecture (하네스 4 계층) 와 hrn-superpowers-framework (Superpowers). ---

60_service/book-vbc-no-design-no-cod…

> *AI 산출물은 사람이 볼 수 있게 박혀야 한다 — 개입·정체성·경계가 가능해지는 자리. 이게 능력 vs 책임 의 갈림길.*

→ 본 단원의 핵심 = 중간 결과물을 사람이 볼 수 있게 기록.

상세: hitl (Human-in-the-Loop)

> 능력은 AI 가 한다. 책임은 사람이 진다.

이 갈림에서 중간 결과물의 가시성 이 기록된다. AI 가 능력 100% 라도 인간이 못 보는 작업 은 책임 박을 자리 ❌.

→ AI-native 의 정의 = AI 가 일하는 환경을 사람이 보고 통제하는 자세.

→ 5 원칙 모두 사람이 키보드 앞을 떠나도 다시 돌아와 읽을 수 있는 자세.

→ 4 분야 모두 본 단원 정합. ---

본 단원이 박은 중간 결과물 가시성 은 4 요소를 처음 본 순간으로 회귀시킨다. 시간이 지나며 부패한 시스템 을 사람이 다시 한 번 본다 — 그게 가소성 (plasticity) 의 활성화. 결국 4 요소 균형 = 사람이 보면서 기록하는 4 자리.

본 책 마치며 — 4 바퀴가 굴러가게 하라…

> *이 강의는 AI 시대 일반론이 아니다. 졸업 직전 여러분의 이력서가 지금 어떻게 변하고 있는지 의 강의다.* ---

본 단원은 4 엔지니어링이 모두 등장하는 첫 자리: - 프롬프트 엔지니어링: 2020 채용 공고 → 2026 채용 공고로 프롬프트만으로는 부족해진 변화 - 컨텍스트 엔지니어링: 요구사항 정의·분해 능력 = 컨텍스트 기록 - 하네스 엔지니어링: 프로덕션 환경에서의 검증 루프 설계 = 하네스의 검증 차원 - 에이전틱 엔지니어링: 에이전트 오케스트레이션 경험 = 에이전틱의 본질 → 기초 자료에서 4 분야 모두 기록 (사용자 명시 규칙 정합). ---

int-software-evolution (1 장 — 소프트웨어 1.0 → 3.0). ---

60_service/booklet/00_preface.md (서문 — Hook).

> *AI 의 자율 작업 시간이 6 개월마다 2 배 로 증가하면서 인간 개발자의 역할이 코드 저자 에서 아키텍트이자 리뷰어 로 강제 전환되었다. 이 전환을 인지·실행·운용하는 자세가 에이전틱 엔지니어링이다.*

본 단원은 4 요소 시간 + 검증 의 풀버전 + AGENT 축 ★ 핵심 보강 — book-vbc ch07 (31 KB) 의 깊이 흡수.

> 2 년 전: 3 시 카카오페이 추가 의뢰 → 6 시까지 키보드 앞에. > > 2026 년: 3 시 5 분 한 줄 위임 → 3 시 30 분 회의 → 4 시 PR 머지 버튼.

같은 작업, 다른 일과(日課). *AI 에게 한 번에 맡길 수 있는 일의 크기 가 커졌다. 함수 한 개 (손가락 도우미) → 기능 한 묶음 (별도 책상의 신입 동료*).

→ 한 번 위임 받고 인간이 돌아올 때까지의 시간 = 2 분 → 2 시간. 시간이 길어진 게 아니라 그만큼 큰 일을 맡긴다는 뜻.

한 줄 정의: AI 에이전트 팀을 편성·조율하고 그 결과를 검토하는 인간 자세. 비…

> *컨텍스트 부패는 오염 이 아니라 부패 다 — 처음엔 멀쩡하다가 시간이 지나며 망가진다. AI 가 망각하는 게 잘못이 아니라, 우리가 영구 지시어를 박지 않은 게 잘못이다.* 본 단원은 4 요소 공간 의 풀버전 — book-vbc ch02 (29 KB) 의 깊이 흡수. ---

- 컨텍스트 엔지니어링: 본 단원의 주 무대. 영구 지시어 / 정적 7 + 동적 13 / Compaction 5 층 - 하네스 엔지니어링: Worktree 격리 / Subagent = 모델 바깥 인프라 - 에이전틱 엔지니어링: Subagent 격리 = 에이전트 위임 결정 흐름 - 프롬프트 엔지니어링: 영구 지시어 = 응축된 프롬프트. 4 슬롯의 시간 확장 → 4 분야 모두 본 단원에서 기록됨. ---

본 단원은 진단. 처방의 자세한 설계 — hrn-context-engineering-deep (다음) 와 3 부 — 자율형 에이전트 하네스 엔지니어링 (Chapter 7~9) 으로. …

> *한 번의 질문 최적화 (프롬프트 엔지니어링) → 시스템 단위 정보 통제 (컨텍스트 엔지니어링). 부패의 처방이 한 번의 자세 가 아니라 시스템의 자세 로 기록된 자리.*

hrn-context-rotting-deep 가 부패는 한 번의 질문 으로 못 막는다 는 진단을 박았다. 그 진단에 답해 등장한 새 자세 — 컨텍스트 엔지니어링.

> 프롬프트 엔지니어링 = 한 번의 질문을 잘 짜는 자세. > 컨텍스트 엔지니어링 = 시스템 전체의 정보를 통제하는 자세.

한 번의 자세 → 시스템의 자세 로의 강제 이동.

시스템 입력 파이프라인 = 영구 지시어 + 동적 컨텍스트 + 도구 결과 + RAG + Compaction. 이 5 층 파이프라인 의 정밀한 통제가 컨텍스트 엔지니어링.

상세: context-engineering · persistent-instructions

karpathy 와 tobias-lutke (Shopify CEO) 의 두 트윗 이 패러다임 전환의 공식 분기점:

> Karpathy (2…

실벨 개발자 YouTube 강의의 한 페이지 체크리스트 — CLAUDE.md 자가 점검 6 항목. 본 강의 Ch9 마치며 의 직접 부착 자료 (포스터 면).

isabella-he (Anthropic) 작성 — anthropics/claude-plugins-official/plugins/claude-md-management 공식 플러그인. claude-md-improver 스킬 (5 단계 감사) + /revise-claude-md 명령 (6 단계 학습 캡처) 의 상호 보완 으로 CLAUDE.md 자가 진화 루프 구현.

Phase 1 — Discovery: 저장소 모든 CLAUDE.md 탐색 (루트·local·전역·모노레포·중첩) 최대 50 개.

Phase 2 — Assessment: 6 기준 가중 평가 1. 빌드·테스트·배포 명령 2. 아키텍처 명확성 3. 숨겨진 패턴 4. 간결성 (200 줄) 5. 현행성 6. 실행 가능성

등급: A 90~100 / B 70~89 / C 50~69 / D 30~49 / F 0~29.

Phase 3 — Report: 점수 전에 보고서 출력 (평균·업데이트 필요 수·기준별 점수·문제점·권장). 승인 없이 변경 ❌.

> *2026-03-31 .npmignore 누락 사고가 박은 측정 가능성 — 1.6% AI / 98.4% Infrastructure. brain 이 아니라 skeleton 이 노출됐다.*

상세는 npmignore-leak-claude-code. 핵심: 2026-03-31 Claude Code v2.1.88 npm 배포에서 .map 누락 → source map 59.8 MB 누출. 같은 실수가 두 번* (2025·2026).

상세는 50-vs-512k-leak. 외부 분석가의 한 줄 요약:

> 1.6% AI / 98.4% Infrastructure.

512,000 줄 中 AI 쿼리 루프 = 50 줄. 나머지 511,950 줄 = Product Engineering.

→ Claude Code 는 AI 도구가 아니라 AI 가 일하는 제품 시스템.

본 누출이 본 강의에 준 가장 큰 선물 — 측정 가능성. 전에는 사용 후기로만 짐작. 이제는 코드 수준 측정:

→ 측정 안 되는 것은 가르칠 수 없다. 본…

Anthropic 공식 — CLAUDE.md 는 4 위치 에 둘 수 있고, 더 구체적인 위치가 더 광범위한 위치보다 우선. 헌법 메타포: 헌법 > 법률 > 시행령 > 시행규칙.

→ 상위법 우선 원칙 ↔ CLAUDE.md 우선순위 정확 일치.

Anthropic 공식 — CLAUDE.md 의 3 가지 로드 규칙: ① 트리 위로 올라가며 수집, ② 하위 디렉토리는 lazy load, ③ HTML 주석은 컨텍스트 주입 전 제거.

*모두 컨텍스트에 연결 (재정의 ❌). 정렬: 루트 → 작업 디렉토리 순서. → 시작 위치에 더 가까운 지침이 마지막* 에 읽힘.

각 디렉토리 내: CLAUDE.local.md 가 CLAUDE.md 후에 추가 → 그 수준의 마지막.

> "Claude 가 현재 작업 디렉토리 아래 하위 디렉토리 에서도 CLAUDE.md 를 발견 + 시작 시 로드 ❌ + Claude 가 해당 하위 디렉토리 파일을 읽을 때 포함."

→ **컨텍스트 토큰 소비 없이 인간 유지보수자 노트 남기는 공식 트릭**.

Anthropic 공식 — CLAUDE.md 작성 4 원칙: ① 크기 (200 줄 이하), ② 구조 (헤더·글머리), ③ 구체성 (검증 가능), ④ 일관성 (충돌 ❌).

> "Adding emphasis (e.g., 'IMPORTANT' or 'YOU MUST') can tune your instructions to improve compliance."

→ instructional-overrides 참조. 남발 ❌ (희소성이 효과).

> *HIAO 1-N-N + 한입 + 가드레일 — 4 요소를 한 손에 쥐는 실무 균형. 셋이 묶여서 박혀야 4 요소가 동시에 굴러간다.*

4 요소를 한 장씩 박았다. 그러나 실무에서는 동시에 균형 잡아야 한다. 시간을 짧게 박으면 공간이 넓어지고, 공간을 작게 박으면 연결이 좁아지고, 연결을 늘리면 검증이 약해진다. 4 요소는 트레이드오프.

→ 이 트레이드오프를 동시에 푸는 패턴 이 본 단원의 주제.

→ 본 패턴이 4 요소를 동시에 기록:

상세는 subagent-mailbox-isolation. Claude Code 안에서 동작하는 HIAO 의 동형 패턴 — 우리가 외부적으로 의식해서 박은 패턴이 역으로 Claude Code 안에서도 기록되어 있음.

one-bite-task 가 시간 차원 의 핵심. HIAO 가 공간·연결·검증 차원에서 한입을 N 개로 만드는 구조.

4 요소 균형은 자동이 아님. guardrail-context 가 균형이 깨졌을 때 막는 장치:

→ 4 요소가 균형 잃으려 할 때 …

karpathy 의 2026-01-26 viral thread 를 forrest-chang 가 65 줄 CLAUDE.md 로 정립. 4 원칙 = LLM 코딩 실수 방지 매니페스토. karpathy-109k-stars 의 지적 본체.

표어: "Don't assume. Don't hide confusion. Surface tradeoffs."

표어: "Minimum code that solves the problem. Nothing speculative."

표어: "Touch only what you must. Clean up only your own mess."

표어: "Define success criteria. Loop until verified."

Karpathy 핵심: "Don't tell it what to do, give it success criteria and let them work."

> "These guidelines bias toward caution over speed. …

boris-cherny (Anthropic, claude-code 책임자) 의 핵심 명제 — *"Claude Code 를 잘 쓰는 사람은 AI 한테 일을 잘 시키는 사람 이 아닙니다. AI 가 자기 작업을 스스로 검증 하게 만드는 사람 입니다."* 이것이 harness-engineering 의 정수.

핵심 명제 > "Claude Code 를 잘 쓰는 사람은 AI 한테 일을 잘 시키는 사람이 아닙니다. > AI 가 자기 작업을 스스로 검증하게 만드는 사람 입니다." > — Boris Cherny (Anthropic / Claude Code 책임자) 검증 루프 설계 — 좋은 지시 vs 나쁜 지시 ❌ 검증 없는 지시: > "이 기능 만들어 줘." ✅ 검증 루프 포함 지시: > "이 기능을 구현해 줘. > 작동 확인용 테스트 코드 도 같이 작성해 줘. > 마지막으로 테스트를 실행 해서 통과 여부를 확인해 줘." → 이 차이 하나가 Claude 를 코드 생…

jaesang-ha (메타 시니어 / 알렉스) 의 진단 — "시니어 전문가는 자신의 숙련된 경험 을 바탕으로 AI 가 생성한 결과물을 검증하는 하네스를 직접 설계 한다." 즉 경험 = 하네스의 원천. CLAUDE.md = 경험의 외재화 도구. 알텐바흐 사례 — 비개발자 1명이 시니어 7명분 효과를 낸 이유는 현장 경험 이 있었기 때문.

핵심 명제 > "시니어 전문가는 숙련된 경험 을 바탕으로 AI 결과물을 검증하는 하네스를 직접 설계 한다. > 이는 AI 오류(Hallucination)를 시니어의 직관과 논리 로 제어하는 고도의 기술적 협업 모델이다." 경험 자본 ↔ 하네스 강도 | 경험 수준 | 하네스 설계 능력 | AI 통제력 | |:---|:---|:---| | 신입 (0~3년) | 기준 불명확 | 낮음 — AI 출력 맹신 위험 | | 중급 (5~10년) | 부분 보유 | 중간 — 특정 영역만 검증 | | 시니어 (10년+) | 비즈니스 + 예외 패턴 축…

본 단원은 설계 우선과 하네스 엔지니어링이 정말 효과가 있는가 라는 학생의 의심을 6 개 산업 출처의 수치로 정면 반박한다. 핵심 메시지는 — *AI 모델 자체는 그대로 두고 주변 시스템 (하네스) 만 바꾸어도 성능이 극적으로 상승한다 는 것이다. 구체 수치를 보면, LangChain 의 Terminal Bench 점수가 52.8 에서 66.5 로 (+13.7) 올랐고, Microsoft Azure SRE 팀의 에이전트 의도 충족률이 45% 에서 75% 로 상승했으며, 학계의 SWE-bench 점수는 12.5% 에서 53% 로 4 배 뛰었다. 산업 적용 사례에서는 Klarna 의 고객 응대 자동화율 80%, Podium 의 의도 분류 정확도 90%, C.H. Robinson 의 일일 600 시간 노동력 절감 같은 결과가 모두 모델 교체 없이 달성되었다. 본 단원은 이 수치들을 종합해 하네스 엔지니어링이 추측이 아닌 측정 가능한 실증 영역* 임을 학생에게 기록한다.

보조 정량 지표 (책…

컴퓨터공학과 학생들이 학교에서 배운 객체지향분석설계 (OOASD) 가 AI 시대에는 필요 없는 옛 지식이 아닌가 하는 의문을 흔히 갖는다. 본 단원은 그 의문을 정면으로 다루고, 결론적으로 *OOASD 의 uml 3 대 다이어그램이 AI 에이전트 설계와 1:1 동형 사상 (Isomorphism) 관계 라는 점을 보여 준다. 즉 Usecase Diagram 의 Goal 이 AI 에이전트의 목표 와 같고, Class Diagram 의 Role + Tool 이 에이전트의 역할 + 사용 도구 와 같으며, Sequence Diagram 의 객체 간 메시지 흐름 이 에이전트들의 orchestration (오케스트레이션) 그 자체다. 더 나아가 OOP 의 5 핵심 원칙 (캡슐화·상속·인터페이스·다형성·결합도) 이 그대로 hiao (계층적 AI 에이전트 오케스트레이션) 의 설계 원칙으로 매핑된다. 학생이 이미 알고 있는 OOP 가 버려지는 게 아니라 그대로 쓰임* 을 확인하는 단원.

UML 3대 ↔…

학생이 흔히 claude-md 를 단순한 설정 파일 정도로 오해하는데, 본 단원은 그 오해를 정면으로 깬다. CLAUDE.md 는 사실상 AI 에이전트의 UML Class Diagram 에 해당하는 압축형 설계 문서 로, 역할 (Role) + 제약 (Constraints) + 목표 (Goal) + 컨텍스트 (Context) 네 요소를 한 파일에 박아 두는 형태다. 다시 말해 객체지향 설계의 Usecase + Class + Sequence Diagram 세 가지를 하나의 마크다운으로 통합한 형태 다. 이 모델의 정점 사례가 바로 karpathy-claudemd-65lines — Karpathy 가 GitHub 에 공개한 65 줄짜리 CLAUDE.md 가 10 만 스타를 받은 사건이다. 본 단원의 결론은 — Karpathy 의 CLAUDE.md 4 원칙이 단순한 글쓰기 가이드가 아니라 OOP 핵심 원칙의 AI 시대 재번역 이라는 점이다.

CLAUDE.md 가 정의하는 4 요소 | 요…

본 단원은 강의 전체에서 유일한 라이브 시연 단원 으로, 강사가 학생들 앞에서 직접 claude-code 를 구동해 약국 마케팅 에이전트 시뮬레이션을 15 분 안에 처음부터 끝까지 만들어내는 모습을 보여준다. 시연은 4 단계로 진행된다 — 먼저 CLAUDE.md 에 약국 도메인 + 금지 사항 + 검증 기준을 박아 두고, 다음으로 Plan Mode 로 작업 계획을 먼저 세운 뒤, 여러 서브에이전트 (가격 분석 / 광고 카피 / 일정 관리 등) 를 병렬로 파견 하고, 마지막으로 각 에이전트의 산출물을 검증 루프로 통과시켜 최종 보고서를 만드는 흐름이다. 본 단원의 목적은 추상적 설명 듣기 가 아니라 *학생이 직접 목격 함으로써 강의 03 HRN 단원에서 박은 4 계층 하네스가 실제로 동작한다 는 점을 행동 동기로 전환* 하는 것이다.

시연 시나리오 > 동네 약국 4 곳의 위치 / 매출 / 고객 데이터 를 받아, 방문 순서 최적화 + 마케팅 메시지 자동 생성 + 결과 보고 를 수행하는…

본 강의의 압축 결론. 핵심 명제 — *"바이브 코딩이 실패하는 이유는 AI 가 코드를 못 써서가 아니라, 설계되지 않은 빈칸 을 AI 가 대신 결정하게 만들기 때문입니다." + 5종 체크리스트 (Goal/Non-goals/Acceptance/Verification/Memory Rules). 학생이 현장에서 3 줄 적기* 의 행동 트리거.

> "바이브 코딩이 실패하는 이유는 AI 가 코드를 못 써서가 아니라, > 설계되지 않은 빈칸 을 AI 가 대신 결정하게 만들기 때문입니다."

> "좋은 팀은 코드를 먼저 쓰지 않고, > 성공 조건을 먼저 쓴 뒤 AI 에게 구현을 맡깁니다."

five-checklist — 즉시 적용 가능 5종

> "이 강의에서 말하는 설계는 두꺼운 워터폴 문서가 아닙니다."

설계 = 실행 가능한 설계 팩: - 목표 + 비목표 - 아키텍처 제약 - 완료 조건 - 검증 방법 - 권한 경계 - 저장소 규칙 파일

> "*설계 = AI 에게 의사결정을 맡기는 영역과 내가 통제하는 영…

학생들이 졸업 후 마주칠 미래 — 자율 소프트웨어 팩토리 (Autonomous Software Factory). 에이전트 생성 코드베이스 + 시스템 엔지니어 = 조율자 + 감사관. AI = 도구 시대가 끝나고 AI = 팀원 시대 시작. 핵심 메시지: "하네스 환경 지배력을 확보한 조직이 다음 시대의 기술적 패권을 쥔다."

에이전트 생성 코드베이스의 범위 확장 | 과거 인식 | 현재 실제 | |:---|:---| | 비즈니스 로직 코드만 | 비즈니스 로직 + | | | 유닛·통합 테스트 | | | CI/CD 구성 스크립트 | | | 내부 개발자 도구 | | | 설계 문서·아키텍처 히스토리 | | | 코드 리뷰 코멘트 | | | 저장소 관리 스크립트 | → *소프트웨어 생명 주기 전체* 가 에이전트 산출물. 시스템 엔지니어의 역할 변화 autonomous-software-factory — 미래 방향** 에이전트가 MCP 를 통해 다양한 모달…

vibe-coding 의 환상과 청구서 를 정면 진단. three-month-wall — 1~3개월 유포리아 후 혼돈과 붕괴 가 도착한다. 7건의 실제 프로덕션 사고 (Lemkin·PocketOS·Anthropic·curl·Moltbook·Lovable·Dog Tracker) 가 모두 동일 원인 으로 수렴 — 목표·제약·검증 기준의 시스템적 부재. AI 약함이 아니라 우리가 구조를 안 줘서 망한다.

3개월의 벽 — 3단계 붕괴 패턴 | 단계 | 기간 | 양상 | 위험 | |:---|:---|:---|:---| | 유포리아 | 1~3개월 | 폭발적 속도, 시각적 결과물 | 설계 누락·보안 무시·기술 부채 누적 | | 혼돈 | 3~5개월 | 버그 수정이 다른 버그 유발 | context-rot (문맥 부패), 일관성 상실 | | 붕괴 | 6개월+ | 유지보수 불가능, 전체 재작성 | 운영 효율성 상실, 번아웃 | context-rot 메커니즘: 대화 이력에만 의존 → A…

alex-an (메타 수석 개발자) 의 진단 — *"AI 시대에 살아남는 핵심 역량은 코딩 실력 이 아닌 문제를 잘 정의하는 능력 이다." 이 메시지는 sanger-architect-quote (Cursor 공동창업자) 의 코더 → 아키텍트 진단과 한 흐름으로 수렴. 핵심 변화: 주니어의 집중점 코드 줄(Line of Code) → 아키텍트의 집중점 시스템 구조 + 에이전트 간 상호작용 설계*.

전통적 개발 vs 바이브 코딩 — 5축 비교 | 축 | 전통적 (Legacy) | 바이브 코딩 (VBC) | |:---|:---|:---| | 주요 도구 | 언어 (C++/Java) + 컴파일러 | 자연어 (Prompt) + AI 에이전트 | | 진입 장벽 | 수년 학습 (높음) | 일상 언어 (낮음) | | 핵심 역량 | 문법·알고리즘 구현 | 문제 정의 + 맥락 설계 | | 생산 주기 | 주~월 단위 | 시간~일 단위 | | 개발자 역할 | 코더 | 아키텍트 (orchest…

본 단원은 바이브 코딩 (VBC) 과 명세 주도 개발 (SDD) 이 서로 대립하는 두 진영이 아니라 영역별로 다르게 적용해야 하는 두 도구 라는 점을 학생에게 박아준다. 즉 vibe-coding 와 spec-driven-development 사이에서 하나만 선택 하는 것이 아니라, 속도가 우선인 영역에서는 VBC 의 자연어 즉시 실행을 사용하고, 통제와 신뢰성이 우선인 영역에서는 SDD 의 명세 우선 워크플로우를 사용한다. 구체적으로 프로토타입 검증·UI 탐색·일회성 스크립트 같은 실패 비용이 낮은 영역은 VBC 가 적합하고, 반대로 프로덕션 코어·데이터베이스 트랜잭션·인증·결제 같이 실패가 즉시 비용이 되는 영역은 SDD 가 필요하다. 본 단원의 핵심 명제는 한 줄로 압축된다 — "20 분을 투자해 견고한 스펙을 작성하면, 2 시간의 디버깅 지옥을 차단할 수 있다".

VBC 의 정의 (Karpathy 2025) > 자연어로 AI와 대화하며 애플리케이션을 생성·디버깅. 코드의 존…

메타 인스타그램 광고 팀의 수석 개발자 alex-an 은 자신이 바이브 코딩으로 실전에서 살아남는 4 가지 전략 을 정리해 발표했고, 본 단원은 그 4 전략을 학생이 오늘 저녁부터 본인 코드에 적용할 수 있는 형태 로 재구성한다. 첫째는 기획서를 먼저 쓰고 코드를 짜는 것, 둘째는 한 번에 큰 작업을 시키지 않고 작은 단위로 분해해 요청하는 것, 셋째는 AI 를 단순한 코드 생성기가 아니라 협업자로 두고 함께 수정·리팩토링하는 것, 넷째는 안정 버전마다 체크포인트를 박아 실험적 시도가 실패해도 되돌릴 수 있게 하는 것 이다. 알렉스는 이 4 전략을 오케스트레이션 (orchestration) 의 출발점 이라고 표현했는데, 이는 단일 AI 도구의 숙련도 가 아니라 여러 AI 에이전트를 조율하는 총괄 관리자 역량 이 핵심이라는 뜻이다.

알렉스의 VBC 정의 > "전통적인 구문 기반 코딩에서 벗어나, 인간의 언어와 논리적 의도 를 중심으로 소프트웨어를 구축하는 방식." 역량 이동:…

에이전트 시스템을 4계층 으로 분리: (1) SDK & 프레임워크 → (2) 스캐폴딩 → (3) 하네스 → (4) 에이전트. *3계층 하네스가 전체 수명 주기를 제어 해 에이전트가 추론에만 집중 할 수 있게 한다. Martin Fowler 의 표현 — "에이전트를 프로덕션에서 작동하게 하는 숨겨진 아키텍처 계층."*

4계층 아키텍처 | 계층 | 이름 | 역할 | 기술 예시 | |:---|:---|:---|:---| | 1 | SDK & 프레임워크 | How to build — 기본 조립 도구 | LangChain, Claude Agent SDK | | 2 | 스캐폴딩 | 프로젝트 초기 구조 생성 | 폴더 트리, 보일러플레이트 | | 3 | 하네스 (Harness) | **How to run — 에이전트 운영 체제 | 도구 연동, 메모리, 재시도, 인간 승인 루프 | | 4 | 에이전트 | 비즈니스 로직 수행 | 제한된 컨텍스트 윈도우 내 추론 | feedforwar…

본 단원은 Superpowers 라는 SDD 기반 지능형 스킬 프레임워크 를 소개한다. 이 프레임워크는 harness-engineering 의 가장 대표적인 구현체 로, 개발자가 매번 수동으로 박아야 했던 하네스 패턴을 재사용 가능한 스킬 패키지로 묶어 제공한다. Superpowers 의 핵심은 3 가지 개념으로 구성된다 — 첫째 visual-companion (시각적 컴패니언) 은 작업 진행 상황을 AI 가 자체적으로 시각화 하는 기법이고, 둘째 subagent-driven-development (서브에이전트 주도 개발) 은 복잡한 작업을 여러 서브에이전트로 분해해 병렬 실행 하는 패턴이며, 셋째 two-stage-review (2 단계 리뷰) 는 AI 가 자기 코드를 다른 AI 의 시각으로 다시 검토 하는 GAN 형 자기 검열 메커니즘이다. 이 셋이 결합되어 기획 → 계획 → 실행 의 3 단계 파이프라인을 시스템 레벨에서 강제 — 즉 사용자가 매번 명령하지 않아도 자동으로 강제되…

바이브 코딩 도구를 직접 만든 사람들이 모두 "설계가 먼저"라고 말한다. Karpathy ("plan mode가 더 좋다"), Truell(Cursor CEO, "start with a plan"), GitHub ("missing structure가 실패 원인"), Altman ("타이핑이 아니라 판단"). 네 발언은 같은 결론을 가리킨다 — 도구가 진화할수록 가치는 얼마나 빨리 코딩하느냐 가 아니라 얼마나 정확한 사양 위에서 움직이게 하느냐 로 옮겨갔다.

4대 인용 (출처·날짜 명시 필수): | 발언자 | 인용 | 출처 | |:---|:---|:---| | Andrej karpathy | "Things get better in plan mode." | X 포스트, 2026-04-24 | | Michael Truell (cursor CEO) | "Start with a plan." | X 팁 스레드, 2026-03-18 (첫 번째 항목) | | GitHub 공식 블로그 |…

karpathy 의 3단계 진화론으로 강의를 연다 — 1.0 명시 코드 → 2.0 신경망/데이터셋 → 3.0 자연어 프롬프트. 핵심 메시지: 개발자의 레버리지가 타이핑 속도에서 컨텍스트 윈도우 통제 능력으로 이동했다. 일차 산출물도 소스 코드 → 명세서·테스트로 옮겨갔다.

강의 진행 시퀀스 (10분): 1. ★ Hook — 개인화된 긴급감 (90초): 슬라이드 "채용 공고 2020 vs 2026" - 2020: "C++/Java 5년 경력, 알고리즘 능숙" - 2026: "AI 협업 설계 능력, 요구사항 정의 경험, 에이전트 오케스트레이션" - 구체적 통증: "여러분이 매일 쓰는 Cursor·Copilot — 그 자동완성을 그냥 받아들이면 어떻게 되는지 본 사람?" - 청중 손 들기 → AI slop 1 컷 (괄호 깨진 코드 / 누락 import / 무한 루프) → "이게 오늘 여러분의 과제 입니다" - 메시지: "이 강의는 AI 시대 일반론 …

메타(Meta) 인스타그램 광고 팀 수석 개발자 안상현(커리어해커 알렉스)의 4단계 모델 — 믿음 → 목격 → 활용 → 행동. 청중이 3·4학년이라는 점은 전문가 편향 역설 때문에 오히려 유리하다 (수년간 쌓은 전문성이 단시간에 대체될 수 있다는 심리적 저항이 베테랑일수록 크다). 강의의 라이브 시연이 목격 단계, 실습이 행동 단계를 채운다.

강의 진행 시퀀스 (8분): 1. 인물 소개 (1분): 메타 인스타그램 광고 팀 수석 개발자 — 권위 확보. 2. 4단계 표 제시 (3분): 한 단계씩 짚으며, 각각 오늘 강의의 어느 시점에 매칭되는지 지목 (믿음 = 지금, 목격 = 라이브 시연, 활용 = HRN/DSL 단원, 행동 = 실습). 3. 전문가 편향 역설 (2분): "지금 전문가가 아니라서 오히려 유리하다" — 청중을 안심시키는 동시에 즉시 행동 동기를 부여. 4. 양이 질을 만든다 (1분): 알렉스 발언 인용 + "오늘 시연을 본 뒤 한 번이라도 직접 돌려보라." 5.…