AI 세미나 추가자료
260315 AI 세미나 준비.md는 freeze. 이후 추가/변경 내용은 여기에 기록.
각 항목은 세미나 본편의 연결 포인트를 명시.
현대 AI의 3가지 키워드
본편 전체를 관통하는 프레임. Part 1 → Context, Part 2 → Agent, Part 3 → Short Loop.
1. Context (컨텍스트)
프롬프트 엔지니어링은 죽었다. 남은 건 "무엇을 알려줄 것인가" — 목표, 제약, 배경, 평가 기준. chub, Rules, Skills 전부 이 이야기. MCP보다 CLI가 이기는 것도 토큰(=컨텍스트) 효율 문제.
2. Agent (에이전트)
대화형에서 "시도 → 실패 → 수정을 AI가 혼자 돌리는" 구조로 전환. autoresearch, 멀티에이전트, Skill 자기 개선 전부 에이전트 루프. 사람은 실행자에서 감독자로 역할이 바뀌고 있다.
3. Short Loop (짧은 루프)
길게 쓰면 망한다. Context Rot, Lost in the Middle, METR Time Horizons — 전부 같은 결론. 짧게, 자주, 나눠서. Karpathy의 5분 사이클, 골빈해커의 짧은 반복, "새 세션으로 끊어라"가 전부 이것.
셋의 관계
Context → 좋은 맥락을 주고
Agent → 에이전트가 알아서 돌리되
Short Loop → 짧게 끊어서 검증한다세미나 본편이 정확히 이 구조다:
| 키워드 | 본편 파트 | 핵심 |
|---|---|---|
| Context | Part 1 (공급자) | 프롬프트 → 컨텍스트 엔지니어링 |
| Agent | Part 2 (시장) | autoresearch, 멀티에이전트, 소수 정예 |
| Short Loop | Part 3 (실천) | 컨텍스트 윈도우 한계, 피드백 루프 |
컨텍스트 품질이 곧 모델 성능인가?
본편 Part 1 "컨텍스트 엔지니어링" + Part 3 전체 — 3가지 키워드의 관계 심화
거의 맞지만, 정확히는 "컨텍스트 품질이 모델 성능의 상한선을 결정한다."
근거: 대부분의 에이전트 실패는 컨텍스트 실패다
"에이전트가 성공하느냐 실패하느냐를 결정하는 것은 모델이 아니라, 주어진 컨텍스트의 품질이다. 대부분의 에이전트 실패는 모델 실패가 아니라 컨텍스트 실패다."
— Philipp Schmid (Hugging Face)
세미나에서 직접 실험한 chub 테스트가 이걸 증명한다:
| 같은 모델, 컨텍스트 없이 | 같은 모델, chub 컨텍스트 있을 때 | |
|---|---|---|
| Supabase RLS 함정 | 모름 | 핵심 주의사항으로 강조 |
| yanked 버전 경고 | 모름 | 피하라고 경고 |
| 1000행 제한 | 모름 | pagination 필요 명시 |
모델은 동일한데, 컨텍스트가 달라지니 출력이 완전히 달라졌다.
하지만 "="는 아니다
| 요소 | 비유 | 설명 |
|---|---|---|
| 모델 능력 | 요리사의 실력 | 추론, 코드 생성, 논리적 일관성 — 컨텍스트를 잘 줘도 모델이 못하면 못함 |
| 컨텍스트 품질 | 식재료의 품질 | 목표, 제약, 배경, 평가 기준 — 모델이 잘해도 컨텍스트가 나쁘면 엉뚱한 결과 |
| 활용 구조 | 주방 환경 | 피드백 루프, 세션 길이 — 둘 다 갖춰도 긴 세션이면 성능 하락 |
최고의 요리사도 썩은 재료로는 좋은 요리를 못 만든다. 반대로 최고의 재료를 줘도 실력 없는 요리사는 망친다. 그리고 둘 다 갖춰도 주방이 난장판이면 결과가 나쁘다.
3가지 키워드와의 연결
Context → 재료의 품질 (상한선 결정)
Agent → 요리사의 실력 (기본 능력)
Short Loop → 주방 환경 (실행 조건)셋 중 하나만 좋아서는 안 된다. 하지만 지금 시점에서 가장 개선 여지가 큰 것이 컨텍스트다. 모델은 이미 충분히 좋아졌고(Part 1), 남은 차이는 컨텍스트와 활용 방식에서 나온다.
참고 링크:
- Philipp Schmid — Context Engineering
- Context Discipline and Performance Correlation (arxiv)
컨텍스트 품질을 높이는 4가지 전략
본편 Part 3 전체 — "컨텍스트 품질 = 모델 성능의 상한선"의 실천편
Philipp Schmid의 정의:
"컨텍스트 엔지니어링은 적절한 정보와 도구를, 적절한 형식으로, 적절한 시점에 제공하는 동적 시스템을 설계하는 것."
프롬프트를 잘 쓰는 게 아니라, LLM 호출 전에 실행되는 시스템을 만드는 것.
1. 쓰기 (Write) — 필요한 맥락을 미리 적어두기
| 방법 | 예시 | 본편 연결 |
|---|---|---|
| Rules | .cursor/rules/에 코딩 컨벤션, 네이밍 규칙 | 3-4 Rules |
| Skills | 반복 작업을 SKILL.md로 패키징 | 3-4 Skills |
| 시스템 프롬프트 | 목표, 제약, 평가 기준을 명시 | 1-1 컨텍스트 엔지니어링 |
2. 가져오기 (Retrieve) — 필요할 때 관련 정보를 주입
| 방법 | 예시 | 본편 연결 |
|---|---|---|
| chub | API 문서를 실시간으로 fetch | 3-4 chub |
| RAG | 코드베이스에서 관련 파일 검색해서 주입 | — |
| 파일 참조 | @파일명으로 특정 파일을 컨텍스트에 추가 | — |
3. 줄이기 (Compress) — 불필요한 것을 제거
| 방법 | 예시 | 본편 연결 |
|---|---|---|
| 새 세션 | 길어지면 끊고 새로 시작 | 3-3 컨텍스트 윈도우 한계 |
| 요약 | 긴 대화를 요약해서 다음 세션에 전달 | Short Loop |
| 불필요 정보 제거 | 관련 없는 파일, 이전 에러 로그 등 빼기 | Context Rot 방지 |
4. 나누기 (Isolate) — 작업별로 컨텍스트를 분리
| 방법 | 예시 | 본편 연결 |
|---|---|---|
| 멀티에이전트 | 분석/코딩/테스트를 별도 에이전트로 | 2-2 McKinsey 스쿼드 |
| 도구 분리 | MCP/CLI로 외부 작업을 별도 실행 | MCP보다 CLI |
| 작업 분해 | 큰 작업을 독립적인 작은 단위로 나눔 | 3-2 덧셈형/뺄셈형 |
→ Write로 기반을 깔고, Retrieve로 적시에 보강하고, Compress로 노이즈를 줄이고, Isolate로 간섭을 차단. 이 4가지가 세미나 본편에서 다룬 Rules, Skills, chub, 새 세션, 멀티에이전트를 하나의 프레임으로 묶는다.
참고 링크:
- Philipp Schmid — Context Engineering
- Philipp Schmid — Context Engineering Part 2
- A Survey of Context Engineering (arxiv)
- Redis — Context Engineering Best Practices
Claude Code vs Cursor — 컨텍스트 관리 차이
본편 3-3 "컨텍스트 윈도우의 한계" + 3-4 "도구가 바뀌어도 가져갈 수 있는 것" — 실천적 비교
Claude Code: 자동 관리
| 기능 | 작동 방식 |
|---|---|
| Auto-compaction | 컨텍스트가 ~95% 차면 자동으로 요약 후 압축 |
/compact | 수동으로 대화를 요약, 핵심만 남기고 새 컨텍스트로 |
/clear | 완전히 새 세션 |
| 도구 출력 정리 | 오래된 도구 출력부터 먼저 제거 |
→ 사용자가 신경 안 써도 알아서 관리된다.
Cursor: 수동 + 하네스 설계
Cursor는 자동 compaction이 없다. 사용자가 하네스(harness)를 설계해서 관리해야 한다.
| 요소 | 역할 | Claude Code 대응 |
|---|---|---|
Rules (.cursor/rules/*.mdc) | 선언적 규칙, 조건부 활성화 | 시스템 프롬프트 |
| Skills | 절차적 지시, 필요 시만 로드 | Skills (동일 표준) |
| Memories | 세션 간 기억 유지 | memory 시스템 |
| Dynamic Context Discovery | 에이전트가 필요한 파일을 스스로 찾아서 로드 | Claude Code도 자동으로 함 |
Cursor에서 Claude Code처럼 하려면
핵심: Rules를 "토큰 예산"으로 관리. Rules가 컨텍스트의 25%를 차지하면, 실제 코드를 볼 수 있는 공간이 25% 줄어든다.
1. Rules는 조건부 활성화 (Always-on 최소화)
# .cursor/rules/python-testing.mdc
---
description: Python 테스트 작성 시 적용
globs: ["*_test.py", "test_*.py"]
---
테스트 규칙 내용...→ 테스트 파일을 다룰 때만 로드. 항상 켜져 있는 Rules는 최소한으로.
2. 계층적 Rules 구조
.cursor/rules/
├── 00-foundation.mdc # 항상 ON — 핵심만 (최소 토큰)
├── 10-architecture.mdc # 구조 관련 파일에서만
├── 30-python.mdc # .py에서만
└── 30-typescript.mdc # .ts에서만3. Skills로 큰 컨텍스트를 지연 로딩
Skills의 이름/설명만 시스템 프롬프트에 올리고, 본문은 필요할 때만 로드 — auto-compaction 대신 처음부터 적게 넣는 전략.
4. 수동 compact 습관
Cursor에는 auto-compact가 없으니, 대화가 길어지면 새 세션으로 끊는 습관이 필요. 또는 커뮤니티 skill(cursor-context-management)을 설치해서 수동 compact 사용.
한 줄 요약
| Claude Code | Cursor | |
|---|---|---|
| 컨텍스트 관리 | 자동 (시스템이 해줌) | 수동 (하네스를 설계해야 함) |
| 전략 | 많이 넣고 → 알아서 압축 | 처음부터 적게 넣고 → 필요할 때만 로드 |
→ 두 전략 모두 본편 3-3 "긴 대화보다 짧은 세션 여러 번"과 같은 결론에 도달한다. 차이는 자동이냐 수동이냐.
참고 링크:
- Claude Code 작동 방식
- Claude Code Compaction
- Cursor Dynamic Context Discovery
- Cursor Rules — Token Tax
긴 세션에서의 성능 변화 — Claude Code vs Cursor
본편 3-3 "컨텍스트 윈도우의 한계" — 세션 길이에 따른 실제 성능 패턴
세션이 길어지면 둘 다 성능이 떨어진다. 하지만 떨어지는 패턴이 다르다.
왜 떨어지나 (공통)
| 원인 | 설명 |
|---|---|
| Lost in the Middle | LLM은 컨텍스트의 앞과 끝에 주의를 집중, 중간은 놓침. 세션이 길어질수록 중요한 정보가 "중간"으로 밀림 |
| 신호 대 잡음비 하락 | 실패한 시도, 이전 버전 코드, 탐색용 질문 등 "잡음"이 쌓임 |
| 물리적 한계 | 컨텍스트 윈도우가 가득 차면 뭔가를 버려야 함 |
Claude Code: 톱니 패턴 (Sawtooth)
성능 ↑
█▄
█ ▀▄ █▄
█ ▀▄ █ ▀▄
█ ▀▄▄▄ █ ▀▄
┼─────압축①──압축②──→ 시간- 컨텍스트가 ~95% 차면 자동 압축(auto-compaction) 실행
- 이전 대화를 요약하고 새 세션처럼 시작 → 성능 회복
- 대가: 압축 시 세부사항 유실 (정확한 코드 스니펫, 에러 메시지 등)
Cursor: 선형 하락 (Linear Decay)
성능 ↑
█
█▀▄
█ ▀▄
█ ▀▄
█ ▀▄▄▄▄ ← 바닥
┼──────────→ 시간
(수동 개입 없으면 계속 하락)- 자동 압축 없음 — 컨텍스트가 계속 쌓임
- 사용자가 의식적으로 새 세션을 열어야 리셋
- 숙련자는 "작업 단위로 세션을 끊는" 습관이 있음
비교
| 항목 | Claude Code | Cursor |
|---|---|---|
| 성능 하락 시작 | 느림 (200K 토큰 윈도우) | 빠름 (상대적으로 작은 윈도우) |
| 자동 복구 | 있음 (auto-compaction) | 없음 |
| 복구 비용 | 세부사항 유실 가능 | 없음 (새 세션 = 완전 리셋) |
| 최적 전략 | 길게 가되 압축에 맡김 | 작업 단위로 세션 끊기 |
컨텍스트 사용량 확인 방법
두 도구 모두 "지금 컨텍스트 70% 찼습니다" 같은 게이지는 없다. 2026년 현재 대부분의 AI 코딩 도구의 공통 한계.
| 도구 | 확인 방법 |
|---|---|
| Claude Code | /cost 명령으로 누적 토큰 확인. 압축 시 [auto-compact] 메시지로 간접 감지 |
| Cursor | 우측 하단 토큰 수 표시. 정확한 % 게이지는 없음 |
실무에서는 이런 신호로 판단:
| 신호 | 의미 |
|---|---|
| 응답이 느려짐 | 컨텍스트가 많아서 처리 시간 증가 |
| 이전에 한 이야기를 반복 질문 | 중간 내용을 놓치기 시작 |
| 지시를 안 따름 | 초반 지시가 "중간"으로 밀려서 무시됨 |
Claude Code에서 [auto-compact] 발생 | 95% 도달 → 압축 실행 |
실전 팁
- Claude Code: 압축 후에도 필요한 정보는
CLAUDE.md나 메모리에 써두는 게 안전. 압축은 "똑똑한 요약"이지 "완벽한 보존"이 아님 - Cursor: 하나의 기능 구현이 끝나면 새 세션. Rules 파일에 프로젝트 상태를 잘 적어두면 세션 전환 비용이 거의 없음
→ 이전 섹션(Claude Code vs Cursor — 컨텍스트 관리 차이)이 "어떻게 관리하느냐"라면, 이 섹션은 "관리를 안 하면 어떻게 되느냐"에 대한 답.
서브에이전트로 컨텍스트 격리 — Isolate 전략의 실제 구현
본편 3-3 "컨텍스트 윈도우의 한계" + 4가지 전략의 "Isolate" — 컨텍스트가 차는 속도를 줄이는 방법
서브에이전트(멀티에이전트)를 쓰면 메인 세션의 컨텍스트가 차는 속도를 크게 줄일 수 있다. 핵심 원리: 서브에이전트는 자기만의 컨텍스트 윈도우에서 작업하고, 메인에는 결과 요약만 돌려준다.
토큰 절약 효과
직접 작업: 파일 읽기 50K + 검색 30K + 시행착오 20K = 100K 토큰 (메인에 쌓임)
서브에이전트: 결과 요약 2K 토큰만 메인에 반환 ← 나머지 98K는 서브에이전트에서 소멸실제 패턴
1. 리서치 격리 — 탐색은 서브에이전트, 판단은 메인
메인: "McKinsey 은행 사례 찾아봐"
└→ 서브에이전트: 웹 검색 5회 + 문서 10개 읽기 (자체 컨텍스트)
└→ 메인에 반환: 핵심 3줄 요약만2. 코딩과 검증 분리 — McKinsey 스쿼드 패턴의 소규모 버전
메인 (감독): 방향만 결정
├→ 에이전트A: 코드 작성 (자체 컨텍스트)
├→ 에이전트B: 테스트 실행 (자체 컨텍스트)
└→ 메인에 반환: "테스트 3/5 통과, 실패 원인은 X"3. Claude Code의 Agent 도구 — 이미 이 방식으로 작동
| 서브에이전트 타입 | 역할 | 메인에 반환하는 것 |
|---|---|---|
Explore | 코드베이스 탐색 | 찾은 파일/패턴 요약 |
Plan | 구현 설계 | 단계별 계획 |
general-purpose | 범용 리서치 | 조사 결과 요약 |
4가지 전략과의 연결
서브에이전트는 Isolate + Compress를 동시에 실현한다:
| 전략 | 서브에이전트에서의 적용 |
|---|---|
| Isolate | 무거운 작업을 별도 컨텍스트로 분리 |
| Compress | 서브에이전트가 알아서 요약해서 반환 |
| Retrieve | 필요한 정보만 골라서 가져오기 |
한계 — 감독자의 딜레마
| 장점 | 한계 |
|---|---|
| 메인 컨텍스트가 깨끗하게 유지 | 서브에이전트 결과도 결국 메인에 쌓임 |
| 무거운 탐색을 격리 | 서브에이전트 간 컨텍스트 공유 안 됨 |
| 병렬 처리 가능 | 오버헤드 (실행 시간, 비용) |
| 실패해도 메인에 영향 없음 | 요약 과정에서 세부사항 유실 가능 |
핵심 트레이드오프: 위임할수록 메인 컨텍스트는 깨끗하지만, 감독자(메인)가 디테일을 모를 수 있다. 이건 McKinsey 스쿼드에서 사람 감독자가 겪는 문제와 동일 — 결국 "얼마나 위임할 것인가"가 설계 판단이다.
→ 긴 세션 성능 하락의 해법: 압축(Compress)은 사후 대응이고, 격리(Isolate)는 사전 예방이다. 둘을 함께 쓰면 세션 수명이 크게 늘어난다.
실제 반응: 하네스를 잘 짜면 어떻게 되나
본편 3-1 "피드백 루프가 짧을수록 AI가 잘한다" + 3-4 "Rules/Skills" — 컨텍스트 투자의 실제 효과
하네스(Rules/Skills)를 잘 구성한 뒤의 실제 반응:
"그동안 개삽질을 직접 다 한 다음 그 내용 정리해서 떠먹이는데만 2주 이상 쓰긴 했는데, 이거까지 하고 나니까 뭔가 말귀 잘 알아먹어서 시키는거 빠딱빠딱 잘 해오는 주니어한테 디렉션 줘서 일 진행시키는 거처럼 되네...와"
이 반응이 증명하는 것
| 세미나 포인트 | 이 반응에서 확인 |
|---|---|
| Context = 상한선 | 2주간 삽질한 내용을 정리해서 "떠먹였더니" 잘한다 |
| Write 전략 | 삽질 → 정리 → Rules/Skills로 패키징 |
| 사람의 역할 전환 | 직접 코딩 → 디렉션만 주는 감독자 |
| 초기 투자 비용 | 2주라는 시간이 필요했다 — 하네스는 공짜가 아님 |
세미나에서 쓸 수 있는 포인트
- 하네스 구성은 초기 투자다 — 2주간의 삽질과 정리가 선행
- 하지만 한번 만들면 이후에는 "디렉션만 주면 된다"
- 본편 3-1 골빈해커의 패턴("코드를 쓰는 게 아니라, 검토하고 방향을 잡는 것이 사람의 역할")과 정확히 일치
- "말귀를 잘 알아먹는 주니어"라는 체감이 컨텍스트 엔지니어링의 실제 효과
이 세미나가 필요한 이유
본편 전체 — 세미나의 존재 의미
청중은 이미 도구를 쓸 줄 아는 사람들이다. 그러면 이 세미나는 뭘 하는 건가?
도구를 쓰는 것과, 도구를 잘 쓰고 있는지 판단하는 것은 다르다.
이 세미나가 제공하는 것은 도구 바깥의 것들:
- 판단 기준 — AI에게 뭘 시키고 뭘 시키지 말아야 하는지 (3-2 작업의 조건, 2-4 만들수있다≠잘만든다)
- 경계심 — "잘 되고 있다"는 체감이 틀릴 수 있다는 것 (METR 연구: 19% 느렸지만 20% 빨라졌다고 믿음), 길어지면 AI가 잊는다는 것 (컨텍스트 윈도우 한계)
- 시야 — 세상이 어디까지 가고 있는지 (autoresearch 333개 실험, 5명이 100개 에이전트)
- 방향 합의 — 각자 따로 쓰고 있던 걸 모아서, 어디까지 함께 할지 정하는 것 (투표 A~D)
Cursor를 매일 쓰면서도, 컨텍스트 윈도우 한계를 모르면 긴 세션에서 왜 품질이 떨어지는지 모른다. 혼자 일하면서는 잘 안 보이는 것들이 있다.
이걸 먼저 정리해서 꺼내놓는 사람이 있어야 대화가 시작된다. 그게 이 세미나의 역할.
정정: McKinsey 은행 사례 (본편 2-2)
본편 2-2 "소수 정예와 대규모 운영" — 인용 수치 정정 및 상세화
세미나 본편에서 "5명이 100+ AI 에이전트 감독, $250M 절감, 엔지니어링 시간 60% 감소"로 인용했으나, McKinsey 원문과 대조하면 수정이 필요하다.
실제 프로젝트
대상: 다국적 은행의 레거시 리스크 모델 100개+를 SAS → Python으로 전환하는 프로젝트. 에이전트가 상시 운영되는 게 아니라 일회성 대규모 전환(migration) 작업이다.
에이전트 구성: 5단계 파이프라인 × 25개 병렬
McKinsey가 말하는 "스쿼드"는 사람 팀이 아니라, 같은 역할을 하는 에이전트 25개의 묶음이다. 5개 스쿼드 = 5단계 파이프라인이고, 각 단계에서 25개 에이전트가 서로 다른 모듈을 병렬 처리한다.
스쿼드1 (분석 ×25) → 스쿼드2 (설계 ×25) → 스쿼드3 (코딩 ×25) → 스쿼드4 (테스트 ×25) → 스쿼드5 (수정 ×25)| 스쿼드 (단계) | 역할 | 25개 에이전트가 하는 일 |
|---|---|---|
| 1. 분석 | 데이터 엔지니어 | 레거시 코드 25개 모듈을 동시에 분석, 비즈니스 로직 해독 |
| 2. 설계 | 아키텍트 | 분석 결과를 받아 현대적 모듈 구조로 재설계 |
| 3. 코딩 | 코더 | 설계를 코드로 구현 (SAS → Python) |
| 4. 테스트 | 테스터 | 구현된 코드를 샌드박스에서 자동 검증, 에러 탐지 |
| 5. 수정 | Fixer | 테스트 실패한 코드를 자동 수정 후 재테스트 |
25개인 이유 — 리스크 모델이 100개+이니까, 한 스쿼드 안에서 에이전트 여러 개가 각각 다른 모듈을 병렬로 처리. 사람은 이 파이프라인 전체를 감독하는 역할.
별도 사례: COBOL → Java
같은 LegacyX 플랫폼으로 공공기관 프로젝트도 수행:
- COBOL 15,000줄 → Java 1,000줄 미만으로 재설계
- 정확도 90%+ (10% 미만만 사람이 수정)
- 수동 전환 대비 2배 빠름
- 6주 PoC로 25만 줄 코드 분석, 3,000개 비즈니스 규칙 중 전체 식별을 2년 → 6~8개월로 단축 전망
정정 사항
| 세미나 인용 | 실제 McKinsey 발표 | 비고 |
|---|---|---|
| 5명이 100+ 에이전트 | 5단계 파이프라인 × 25개 병렬 (=125개) | "5명"이 아니라 "5개 스쿼드". 감독 인원수는 미공개 |
| $250M 절감 | 구체 금액 미공개. 비용 40% 절감 | $250M은 출처 불명확 |
| 엔지니어링 시간 60% 감소 | 40~50% 가속화 | 60%는 과장 |
전환하고 끝인가?
이 프로젝트는 전환이 목표다. 레거시 코드 현대화가 끝나면 에이전트의 임무도 끝난다. 다만 McKinsey는 지속적 기술 부채 상환 모델로 확장을 제안 — 전환이 끝나면 같은 스쿼드를 다른 영역에 재배치해서 현대화를 계속 진행하는 방식.
→ 발표 시 "5단계 AI 파이프라인(125개 에이전트)이 역할별로 분업하여 레거시 전환을 수행. 사람은 감독자 역할"로 설명하는 것이 정확.
참고 링크:
- McKinsey LegacyX 소개
- QuantumBlack — Overcoming legacy tech
- McKinsey — AI for IT modernization
해커톤 심사 기준 상세 (본편 2-3)
본편 2-3 "도메인 전문가와 해커톤" — 변호사가 1위를 한 이유
공개된 심사 기준 (3가지)
| 기준 | 설명 |
|---|---|
| Technical Innovation | Claude의 능력을 얼마나 창의적으로 활용했는가 |
| Implementation Quality | 실제로 동작하는 프로토타입인가 (문서만 많은 것보다 작동하는 것 우대) |
| Potential Impact | 실제 문제를 해결하는가, 영향력이 있는가 |
심사위원 6명(Boris Cherny, Cat Wu, Thariq Shihpar, Lydia Hallie, Ado Kukic, Jason Bigman)은 모두 Anthropic 팀 소속. 항목별 가중치나 점수 배분은 비공개. "심사위원의 결정은 최종적이고 구속력이 있다"는 규정만 있음.
변호사(Mike Brown)가 1위를 한 이유 — 추론
심사위원 코멘트는 공개되지 않았다. 심사 기준에 대입한 추론:
- Potential Impact가 결정적이었을 가능성 — 캘리포니아 건축 허가는 수개월 걸리는 실제 고통점. 친구가 뒤뜰 별채를 짓다가 허가 거부를 반복 경험한 실제 문제를 풀었다
- Implementation Quality — 코딩 경험 없이 6일 만에 동작하는 앱(CrossBeam)을 완성
- Technical Innovation — Claude Code만으로 구현했다는 것 자체가 Claude의 능력 시연
→ "코드를 잘 짰느냐"가 아니라 "실제 문제를 풀었느냐"에 가중치가 높았던 것으로 보인다. 본편 2-3의 메시지("코딩을 잘하는 사람이 아니라, 문제를 잘 아는 사람이 이기고 있다")와 일치.
주의사항
- 심사 기준의 세부 배점은 비공개다. 위 분석은 공개된 3가지 기준에 대입한 추론이지 공식 발표가 아님
- 심사위원 전원이 Anthropic 소속이다. 자사 도구(Claude Code)의 가능성을 보여주는 결과가 선호되었을 수 있음 (이해충돌)
- 해커톤 자체가 Claude Code 한정이다. 다른 AI 도구와의 비교가 아님
- 본편에서도 이미
⚠️ 해커톤도 Claude Code 한정으로 주의를 달아뒀으나, 발표 시 이 맥락을 함께 전달해야 "변호사가 개발자를 이겼다"가 과대해석되지 않는다
참고 링크:
- 해커톤 공식 페이지
- Anthropic 공식 결과 발표
- 해커톤 결과 분석
METR 연구 후속 업데이트 (2026.02)
본편 2-4 "만들 수 있다 ≠ 잘 만든다" — METR 연구 인용 부분의 보강
세미나 본편에서 인용한 METR 연구(2025.07)의 후속 결과가 나왔다.
결과 비교
| 원래 연구 (2025.07) | 후속 연구 (2026.02) | |
|---|---|---|
| 효과 | +19% 느려짐 | -18% 빨라짐 |
| 신뢰구간 | +2% ~ +39% | -38% ~ +9% |
| AI 도구 | Cursor Pro + Claude 3.5/3.7 | 에이전틱 도구 (Claude Code 등) |
→ 도구가 발전하고, 개발자가 숙련되면서 결과가 뒤집혔다.
하지만 연구 설계 자체에 문제가 생김
METR가 스스로 실험 설계를 바꾸겠다고 선언한 이유:
- 모집이 어려워졌다 — "작업의 50%를 AI 없이 하라"는 조건을 거부하는 개발자가 늘어남
- 선택 편향 — AI에 긍정적인 개발자일수록 참여를 거부 (AI 없이 일하기 싫으니까)
- 결과적으로 AI에 회의적인 사람만 남는 구조적 문제
벤더 연구와의 차이
| 출처 | 결과 | 비고 |
|---|---|---|
| METR (원래) | 19% 느려짐 | 독립 비영리, RCT |
| METR (후속) | 18% 빨라짐 | 같은 방법론, 최신 도구 |
| GitHub/Google/MS | 20~55% 빨라짐 | AI 도구 벤더가 한 연구 (이해충돌) |
| 업계 자가보고 | 10~30% 빨라짐 | 설문 기반 (체감) |
세미나에서 쓸 수 있는 포인트
- 체감과 실측의 괴리는 여전히 유효 — 원래 연구의 핵심 발견은 변하지 않음
- 도구 발전 속도가 빠르다 — 6개월 만에 결과가 뒤집힐 정도
- "누가 한 연구인가"가 중요하다 — 벤더 연구는 이해충돌이 있다는 시각을 알려줄 것
참고 링크:
- METR 원래 연구
- METR 후속 업데이트
- arxiv 논문
"짧게 쓰는 게 낫다" — 그래프로 보는 근거
본편 3-3 "컨텍스트 윈도우의 한계" + 3-1 "피드백 루프가 짧을수록 AI가 잘한다" — 시각적 근거 보강
세미나에서 "왜 짧게 써야 하는가"를 그래프 3개로 연속 제시할 수 있다.
1. Context Rot — 길어질수록 잊는다
Chroma (2025.07). 18개 프론티어 모델 전부, 토큰이 늘어날수록 성능 하락. 예외 없음.
- 10K → 100K+ 토큰 구간에서 정확도 20~50% 하락
- 의미 이해(semantic matching) 작업에서 더 심하게 하락
- Claude는 비교적 선방하지만 8,000단어 이후부터 감소
그래프: research.trychroma.com/context-rot — 인터랙티브 차트, 모델별 토큰 수 vs 정확도
2. Lost in the Middle — 중간에 넣은 건 못 찾는다
Stanford/Meta (2024 TACL). 정보가 입력의 어디에 위치하느냐에 따라 정확도가 U자 곡선.
- 앞부분: 높은 정확도 (primacy bias)
- 중간: 30%+ 정확도 하락 — 문서 안 준 것보다 못한 경우도
- 끝부분: 약간 회복 (recency bias)
- GPT-3.5, GPT-4, Claude, LLaMA 등 모든 모델에서 동일
그래프: Stanford 논문 PDF Figure 1, 2의 U자 곡선 / MIT Press 정식 게재본
3. METR Time Horizons — 짧은 작업에서만 잘한다
METR (2025~2026). AI가 처리할 수 있는 작업 시간이 7개월마다 2배씩 성장하지만, 현재는 짧은 작업에서만 신뢰도 높음.
- 50% 성공 기준: 수분~수십분 수준의 작업
- 작업이 길어질수록 성공률 급감 (로지스틱 곡선)
- MIT Technology Review가 "AI에서 가장 오해받는 그래프"로 선정
그래프: metr.org/time-horizons — 인터랙티브 차트 / 해설: MIT Tech Review
세미나에서 제시 순서
| 순서 | 그래프 | 메시지 |
|---|---|---|
| 1 | Context Rot (토큰 vs 정확도) | "길어질수록 잊는다" |
| 2 | Lost in the Middle (위치 vs 정확도) | "중간에 넣은 건 못 찾는다" |
| 3 | METR Time Horizons (작업 시간 vs 성공률) | "짧은 작업에서만 잘한다" |
→ 세 그래프를 연속으로 보여주면 "짧게, 자주, 나눠서"가 시각적으로 증명된다. 본편 3-3의 "긴 대화보다 짧은 세션 여러 번이 정확도가 높다"를 데이터로 뒷받침.
Autoresearch 패턴으로 Skill 자기 개선
본편 2-1 "autoresearch와 자율 실험" + 3-4 "Skills" — autoresearch 패턴의 skill 확장
세미나 본편의 "시야" 파트에서 언급한 autoresearch(Karpathy, 333개 실험)를 skill 개선에 적용하는 방법.
autoresearch 핵심 루프
수정 → 검증 → 유지/폐기 → 반복 (사람 개입 없이)원래는 ML 모델 학습에 적용했지만, 같은 루프를 skill 파일 개선에도 적용할 수 있다.
3가지 필수 요소
| 요소 | 설명 | skill 적용 예시 |
|---|---|---|
| 수정 가능한 단일 파일 | 에이전트가 수정할 대상 | SKILL.md 파일 1개 |
| 스칼라 메트릭 | 개선 여부를 판단하는 숫자 | 바이너리 테스트 통과율 |
| 고정 시간 사이클 | 매 실험 동일 시간 | 5분 실행 → 결과 비교 |
skill 자기 개선 작동 방식
- Skill 파일에 바이너리 테스트 3~5개 정의 (예: "생성된 코드가 lint 통과하는가?", "API 호출 성공하는가?")
- 에이전트가 skill 내용을 수정
- 수정된 skill로 테스트 실행
- 통과율이 올랐으면 유지, 떨어졌으면 폐기
- 밤새 반복 — 사람은 자고, 아침에 개선된 skill을 확인
왜 이게 가능한가
- 사람이 병목 — 실험 설계·결과 확인·다음 실험 결정을 사람이 하면 하루 몇 개가 한계
- 제약이 곧 힘 — 파일 1개, 메트릭 1개로 범위를 좁히면 밤새 100개 실험 가능
- 평가가 자동화되면 개선도 자동화된다 — "좋은 결과"를 숫자로 정의할 수 있으면 나머지는 루프가 해결
세미나와의 연결
"5명이 100개 에이전트를 돌린다"는 것은 이 패턴의 확장판이다. 그리고 이걸 skill에 적용하면 AI가 자기가 쓸 skill을 스스로 개선하는 구조가 된다 — 재귀적 자기 개선(recursive self-improvement)의 실용적 형태.
참고 링크:
- Claude Code + AutoResearch 자기 개선 skill
- AutoResearch eval loop — 바이너리 테스트
- uditgoenka/autoresearch — Claude용 구현체
- Karpathy autoresearch 패턴 해설
Skill 간 참조와 조합 (Composition)
본편 3-4 "Skills — 다음 단계" — 단일 skill을 넘어 생태계로
하나의 skill이 다른 skill을 참조하거나, 여러 skill을 체인으로 엮어 복합 워크플로우를 구성할 수 있다.
조합 방식
1. 참조 파일 공유 — 여러 skill이 같은 참조 파일을 사용
skill-a/SKILL.md → references/coding-standards.md
skill-b/SKILL.md → references/coding-standards.md (같은 기준 공유)2. Skill 체이닝 — 순차 실행으로 워크플로우 구성
브레인스토밍 → 구현 계획 → 코딩 → 테스트 → 코드리뷰각 skill이 이전 skill의 출력을 입력으로 받는 구조.
3. Meta-Skill — 대화에서 학습한 내용을 자동으로 새 skill 파일로 저장하는 "스킬을 만드는 스킬".
4. Skill Discovery — 에이전트가 list_skills로 사용 가능한 skill 목록을 조회하고, 작업에 맞는 것을 골라서 invoke_skill로 실행. 사람이 지정하지 않아도 에이전트가 알아서 적절한 skill을 선택.
아키텍처 원칙
| 원칙 | 설명 |
|---|---|
| 프로세스는 SKILL.md에 | 절차/단계만 기술 |
| 컨텍스트는 references/에 | 긴 참고자료는 별도 파일로 분리 |
| progressive disclosure | 필요할 때만 참조 로드 |
| 독립 실행 가능 | 각 skill은 다른 skill 없이도 단독 동작해야 함 |
세미나와의 연결
단일 skill을 넘어 skill 생태계로 발전하는 흐름. autoresearch로 개별 skill을 개선하고, composition으로 skill끼리 엮으면 — 에이전트가 스스로 능력을 확장하는 구조가 된다.
참고 링크:
- Claude Code 공식 Skill 문서
- Skill 아키텍처 설계
- levnikolaevich/claude-code-skills — 전체 워크플로우 skill 체인 예시
- Meta-Skill 만들기
MCP보다 CLI — 2026년 도구 연결 트렌드
본편 3-4 "MCP — 개인에서 팀으로" + "알아는 두되, 지금은 못 쓰는 것들" — MCP의 위상 변화
AI 에이전트가 외부 도구를 사용하는 방식에서, MCP(Model Context Protocol)보다 CLI가 더 효율적이라는 흐름이 2026년 초부터 뚜렷하다.
토큰 효율 차이
| 항목 | MCP | CLI |
|---|---|---|
| 비용 | 10~32배 비쌈 | 기준 |
| 신뢰성 | 72% | 100% |
| 토큰 소모 | 스키마 정의만 수만 토큰 | 모델이 이미 알고 있음 |
예: GitHub MCP 서버는 93개 도구를 노출하는데, 연결만 해도 스키마 정의에 ~55,000 토큰 소모. 사용자가 질문하기도 전에.
왜 CLI가 자연스러운가
AI 모델은 수십억 줄의 터미널 상호작용(Stack Overflow, GitHub, 문서)으로 학습됐다. git, docker, kubectl 같은 CLI를 쓸 때 모델의 기존 지식을 그대로 활용. MCP는 별도 스키마를 런타임에 읽어야 하지만, CLI는 "스키마가 이미 모델 파라미터 안에 있다."
실제 움직임
- Perplexity — MCP 지원 공개 제거. 내부 벤치마크에서 CLI 대비 15~20배 토큰 소모, 품질 개선 없음
- Anthropic 자체 연구 — MCP 대신 Python/shell 스크립트 직접 실행으로 토큰 98.7% 절감
- 2026년 2~3월 "MCP is Dead" 류 포스트 대량 등장
그래도 MCP가 필요한 곳
| CLI가 맞는 경우 | MCP가 맞는 경우 |
|---|---|
| git, docker, npm 등 CLI가 있는 도구 | CLI가 없는 SaaS 서비스 |
| 개발 워크플로우 | 엔터프라이즈 감사/보안 요구 |
| 비용 민감한 환경 | 멀티테넌트 권한 분리 |
| 빠른 프로토타이핑 | 타입 안전한 스키마 검증 필요 |
→ 기본은 CLI, MCP는 보조. chub도 CLI, autoresearch도 CLI 기반 — 이 흐름과 일치.
참고 링크:
- MCP vs CLI 비교 (비용, 속도, 보안)
- Why CLI Tools Are Beating MCP
- MCP is Dead; Long Live MCP!
- MCP vs CLI 벤치마크
chub (Context Hub) 테스트 결과
본편 3-4 "스킬 맛보기 — Context Hub (chub)" — 실제 효과 검증
AI가 잘 아는 API vs 덜 아는 API에서 chub 효과 비교.
Anthropic Claude API — 차이 미미
| 항목 | chub 없이 | chub 있을 때 |
|---|---|---|
| 기본 코드 | 정확 | 동일 |
| 모델명 | 맞음 (최신 4.6 모델은 누락) | 최신 모델 + deprecated 목록 |
| thinking, token counting | 누락 | 있음 |
→ AI가 이미 잘 아는 API라 큰 차이 없음
Supabase Python (v2.28.0) — 차이 큼
| 항목 | chub 없이 | chub 있을 때 |
|---|---|---|
| 기본 CRUD | 맞음 | 동일 |
| RLS 함정 | 언급 없음 | 핵심 주의사항으로 강조 |
.execute() 누락 | 언급 없음 | 흔한 실수로 명시 |
get_user() vs get_session() | 몰랐음 | 보안상 get_user() 권장 |
| Storage/Edge Functions/Realtime | 없음 | 전부 있음 |
| 1000행 기본 제한 | 몰랐음 | pagination 필요 명시 |
| yanked 버전 (v2.19~2.23) | 몰랐음 | 피하라고 경고 |
→ AI가 잘 모르는 API일수록 효과가 크다
Member discussion: