Prompt → Context → Harness

FREEDOBY — 2026 · Deck 03 / 06

Prompt → Context → Harness.
진화의 방향.

AI Agent의 진화 — 대체가 아니라 겹겹이 잡는 통제.

"어떻게 말할까"에서 "무엇을 넣을까"로, 다시 "어떤 구조로 실행할까"로.
Better prompts don't scale. Better systems do.

Opening

#stacked #not-replacement

02 / 13

왜 진화했나

대체가 아니라
겹겹이 잡는 통제.

새 단계가 등장했다고 이전 단계가 사라진 게 아닙니다.
그 위에 한 층씩 쌓였습니다.

하네스 ⊃ 컨텍스트 ⊃ 프롬프트.
지금 우리가 쓰는 모든 셋업은 — 세 층의 합산.

왜 쌓였나? AI는 발산한다 — 잡고, 잡고, 또 잡고.
매 층은 제품 코드의 신뢰성을 지키는 engineering의 반복.

Opening · 적층의 구조02 / 13 · → Primer

Primer · User 하네스

#user-harness #7-units

03 / 13

여기서부터 — 우리가 짜는 층

User 하네스의 첫 layer.

에이전트에게 우리 프로젝트를 가르치는 자리 — .claude/.
항상 깔리는 것부터 필요할 때 부르는 것까지 — 7단위.
여기서부터가 우리 일.

CLAUDE.md매 호출 자동 깔리는 시스템 지침I

rules/CLAUDE.md가 @-참조하는 룰 분리I

skills/load-on-demand 지침 모듈II

agents/격리 컨텍스트 sub-agent 정의II

commands/명명된 워크플로우 진입점III

hooks/이벤트 트리거 스크립트III

settings.json권한 · 환경 · 구성III

Activation Timeline — 언제 깔리나

항상

CLAUDE.md rules/ settings.json

모델 판단

skills/ agents/

이벤트

hooks/

사람 · 예약 실행

commands/

← 자동 명시 호출 →

비유 — Inside the AI Workshop

AI의 작업실 — .claude/
User 하네스 — 우리가 짠다.

Primer · User 하네스 — 전환03 / 13 · → Stage I

Stage I · Prompt

#how-to-say #system-instruction

04 / 13

Prompt Engineering.

"어떻게 말할까." — 지침으로 모델의 행동을 규제하는 일.
시스템 프롬프트 · 역할 · 포맷 · 예시 제시 · 단계별 사고.

.claude/CLAUDE.md

# CLAUDE.md — Project Rules ## 참조 룰 @.claude/rules/architecture.md @.claude/rules/design-principles.md @.claude/rules/extension-rules.md ## 아키텍처 - 공통 모듈: src/common/ - 확장 모듈: src/extensions/[name]/ - 의존 방향: extensions → common - 외부 IO는 adapter layer에서만 ## 설계 원칙 - 함수는 단일 책임 - 부수효과는 boundary에서만 - 상태는 명시적 — 숨은 글로벌 금지 ## 톤 · 포맷 - 한국어, 능동태 - 모호한 부사 금지 - 마크다운 헤더 H3까지 ## 코딩 컨벤션 - C++ · Hungarian notation - 정수: iCount, fRatio, bValid - 포인터: pBuffer, pszName - 멤버: m_iData, m_pHandle - 클래스: CMyClass / IFoo - 한 함수 50줄 이하 ## 적용 지점 모든 1 호출의 베이스라인이 된다.

.claude/ 단면 — Stage I이 다루는 자리

.claude/ ├─ CLAUDE.md ← Stage I 루트 지침 (rules/ 참조) │ ├─ rules/ ← Stage I 룰 분리 │ ├─ architecture.md 아키텍처 룰 │ ├─ design-principles.md 설계 원칙 │ └─ extension-rules.md 공통·확장 규칙 │ ├─ skills/ ← Stage II Context — phase별 동적 모듈 │ ├─ requirements-analysis/ P1 요구사항 분석 │ ├─ dld-design/ P3 DLD 설계 │ ├─ unit-test-tdd/ P4 Unit (TDD RED) │ ├─ integration-test/ P6 Integration · E2E 실장 │ └─ regression-test/ P7 회귀 수행 │ ├─ agents/ ← Stage II Context — 분리 워커 │ ├─ code-reviewer.md P8 리뷰 (×3 병렬) │ └─ judge.md JUDGE — RTM 판별 (×1) │ ├─ commands/ ← Stage III Harness — 워크플로우 │ ├─ halo-workflow.md P1~P9 + LOOPBACK │ └─ doc-drift-sync.md 매일 자정 · 문서·코드 모순 동기화 │ ├─ hooks/ ← Stage III Harness — 트리거 │ ├─ post-edit-lint.sh 편집 후 린트 자동 수정 │ └─ post-edit-unit-test.sh 편집 후 영향받은 Unit 자동 실행 │ └─ settings.json ← Stage III Harness — 권한·구성

모든 파일 = 마크다운 형태의 자연어 지침.
사람이 읽고 — 모델이 읽는 — 같은 substrate.

Stage I · Prompt — substrate vs concern04 / 13 · → Stage II

Stage II · Context

#what-when-how #skill-agent

05 / 13

Context Engineering.

"무엇을, 어떤 순서로." — 필요할 때 필요한 모듈을 동적으로 주입한다.
MCP · RAG · Skills · Agents · Serena.

Context Stacking — load-on-demand + sub-agent isolation

.claude/ 단면 — Stage II가 다루는 자리

.claude/ ├─ CLAUDE.md ← Stage I 루트 지침 (rules/ 참조) │ ├─ rules/ ← Stage I 룰 분리 │ ├─ architecture.md 아키텍처 룰 │ ├─ design-principles.md 설계 원칙 │ └─ extension-rules.md 공통·확장 규칙 │ ├─ skills/ ← Stage II Context — phase별 동적 모듈 │ ├─ requirements-analysis/ P1 요구사항 분석 │ ├─ dld-design/ P3 DLD 설계 │ ├─ unit-test-tdd/ P4 Unit (TDD RED) │ ├─ integration-test/ P6 Integration · E2E 실장 │ └─ regression-test/ P7 회귀 수행 │ ├─ agents/ ← Stage II Context — 분리 워커 │ ├─ code-reviewer.md P8 리뷰 (×3 병렬) │ └─ judge.md JUDGE — RTM 판별 (×1) │ ├─ commands/ ← Stage III Harness — 워크플로우 │ ├─ halo-workflow.md P1~P9 + LOOPBACK │ └─ doc-drift-sync.md 매일 자정 · 문서·코드 모순 동기화 │ ├─ hooks/ ← Stage III Harness — 트리거 │ ├─ post-edit-lint.sh 편집 후 린트 자동 수정 │ └─ post-edit-unit-test.sh 편집 후 영향받은 Unit 자동 실행 │ └─ settings.json ← Stage III Harness — 권한·구성

모든 파일 = 마크다운 형태의 자연어 지침.
사람이 읽고 — 모델이 읽는 — 같은 substrate.

Stage II · Context — substrate vs concern05 / 13 · → Stage III

Stage III · Harness

#how-to-execute #halo-workflow

06 / 13

Harness Engineering.

"어떤 구조로 실행할까." — 발산을 잡는 LOOPBACK sensor.
프로젝트 단위로 실행 흐름 자체를 구조화한다.

HALO Workflow — Phase 진행 + JUDGE 게이트 + LOOPBACK

.claude/ 전체 — Harness가 모두 오케스트레이션

.claude/ ├─ CLAUDE.md ← Stage I 루트 지침 (rules/ 참조) │ ├─ rules/ ← Stage I 룰 분리 │ ├─ architecture.md 아키텍처 룰 │ ├─ design-principles.md 설계 원칙 │ └─ extension-rules.md 공통·확장 규칙 │ ├─ skills/ ← Stage II Context — phase별 동적 모듈 │ ├─ requirements-analysis/ P1 요구사항 분석 │ ├─ dld-design/ P3 DLD 설계 │ ├─ unit-test-tdd/ P4 Unit (TDD RED) │ ├─ integration-test/ P6 Integration · E2E 실장 │ └─ regression-test/ P7 회귀 수행 │ ├─ agents/ ← Stage II Context — 분리 워커 │ ├─ code-reviewer.md P8 리뷰 (×3 병렬) │ └─ judge.md JUDGE — RTM 판별 (×1) │ ├─ commands/ ← Stage III Harness — 워크플로우 │ ├─ halo-workflow.md P1~P9 + LOOPBACK │ └─ doc-drift-sync.md 매일 자정 · 문서·코드 모순 동기화 │ ├─ hooks/ ← Stage III Harness — 트리거 │ ├─ post-edit-lint.sh 편집 후 린트 자동 수정 │ └─ post-edit-unit-test.sh 편집 후 영향받은 Unit 자동 실행 │ └─ settings.json ← Stage III Harness — 권한·구성

모든 파일 = 마크다운 형태의 자연어 지침.
사람이 읽고 — 모델이 읽는 — 같은 substrate.

Stage III · Harness — substrate vs concern06 / 13 · → 적층의 단면

Synthesis · Layered

#claude-folder #stratigraphy

07 / 13

한 폴더가

진화의 지층 단면.

한 폴더가 곧 제품 코드 신뢰성을 지키는 통제의 누적.

.claude/ 디렉토리 — AI Agent 기반 제품 개발의 단면

.claude/ ├─ CLAUDE.md ← Stage I 루트 지침 (rules/ 참조) │ ├─ rules/ ← Stage I 룰 분리 │ ├─ architecture.md 아키텍처 룰 │ ├─ design-principles.md 설계 원칙 │ └─ extension-rules.md 공통·확장 규칙 │ ├─ skills/ ← Stage II Context — phase별 동적 모듈 │ ├─ requirements-analysis/ P1 요구사항 분석 │ ├─ dld-design/ P3 DLD 설계 │ ├─ unit-test-tdd/ P4 Unit (TDD RED) │ ├─ integration-test/ P6 Integration · E2E 실장 │ └─ regression-test/ P7 회귀 수행 │ ├─ agents/ ← Stage II Context — 분리 워커 │ ├─ code-reviewer.md P8 리뷰 (×3 병렬) │ └─ judge.md JUDGE — RTM 판별 (×1) │ ├─ commands/ ← Stage III Harness — 워크플로우 │ ├─ halo-workflow.md P1~P9 + LOOPBACK │ └─ doc-drift-sync.md 매일 자정 · 문서·코드 모순 동기화 │ ├─ hooks/ ← Stage III Harness — 트리거 │ ├─ post-edit-lint.sh 편집 후 린트 자동 수정 │ └─ post-edit-unit-test.sh 편집 후 영향받은 Unit 자동 실행 │ └─ settings.json ← Stage III Harness — 권한·구성

잡고, 잡고, 또 잡고 — 한 폴더가 곧 그 반복의 누적된 형태.

Synthesis · 적층의 단면07 / 13 · → Vendor 기반

Stack · Vendor 기반

#two-harnesses #layer-zero

08 / 13

그런데 — 이 적층의 맨 아래엔

하네스가 — 모델을 '에이전트'로 만든다.

파일을 읽고·고치고, 명령을 돌리고, 폭주를 멈추는 능력 — 모델엔 없다. 누가 그걸 깔아 주느냐로 — 하네스는 두 층으로 갈린다.

0번 층 — Vendor Harness

raw 모델 → 범용 에이전트.

도구 · 에이전트 루프 · 권한 게이트 · 컨텍스트 관리

목적 — 어디서든 돌아가게. 도구 쓰고·파일 고치고·폭주 안 하는 에이전트를 만든다. 단, User의 프로젝트는 모른다.

그 위 — User Harness

범용 → User 제품 전용.

.claude/ · 프롬프트 · 컨텍스트 · 프로세스

목적 — User 제품을 성공시키게. 컨벤션·도메인·완료 기준을 가르쳐, 범용 에이전트가 User 제품을 제대로 뽑게 만든다.

벤더는 범용 에이전트까지 — 거기서 멈춘다. 그 위를 User 도메인에 맞추는 건, User만 안다. 그래서 User 하네스는 — User의 몫.

Stack · Vendor 기반 — 주장08 / 13 · → 측정

Stack · /context

#context-window #vendor-vs-user

09 / 13

Vendor 하네스는 추상이 아니다

/context의 단면 — Vendor Harness, 그 위에 User Harness.

▶/context Claude Sonnet · 200K

/context 항목

토큰

%

누구 것

연결

System prompt

4K

2.0%

Vendor 하네스

행동 baseline — 손댈 수 없음

System tools

21K

10.5%

Vendor 하네스

27 도구 + MCP — 25K의 대부분

Custom agents

2K

1.0%

User 하네스

.claude/agents/

Memory files

1K

0.5%

User 하네스

.claude/CLAUDE.md

Skills

2K

1.0%

User 하네스

.claude/skills/

Messages

100K

50.0%

대화 · 런타임

입력 · 코드 · 출력 — 당신 몫

Vendor — 사용자가 손대기 전부터 깔리는 층 (System prompt + tools) · default
User — .claude/로 우리가 얹는 층 (agents · memory · skills)
대화 — 런타임에 채워지는 가변 영역

Vendor Harness 고정 — 우리가 만질 곳은 User Harness = .claude/로 설정.

Stack · /context — 측정 + 매핑09 / 13 · → 지침

Stack · Vendor 지침

#system-prompt #guardrails

10 / 13

그 Vendor 하네스 안을 열어보면

Vendor Harness 안 — 안전·컨텍스트·해석을 박은 지침.

raw 모델을 어디서든·폭주 없이 굴리는 규칙 — Vendor의 System prompt에, 사용자가 한 줄 쓰기 전부터 박혀 있다. Claude Code 실제 발췌 넷.

안전 · 폭주 차단

system-prompt-action-safety-and-truthful-reporting

"For actions that are hard to reverse or outward-facing, confirm first — approval in one context doesn't extend to the next."

되돌리기 힘든·외부로 나가는 행동은 먼저 확인. 한 번 승인이 다음까지 가지 않는다 — 폭주를 막는 가드레일.

배선 · 권한 게이트

system-prompt-harness-instructions

"Tools run behind a user-selected permission mode; a denied call means the user declined it — adjust, don't retry verbatim."

도구는 권한 모드 뒤에서 실행 — 거부당하면 똑같이 재시도 말고 조정. 모델을 터미널에 묶는 배선.

컨텍스트 · 윈도우 관리

system-prompt-context-compaction-summary

"Write a continuation summary that will allow you to resume work in a future context window where the conversation history will be replaced with this summary."

대화가 길어지면 — 히스토리를 요약으로 갈아끼워 다음 윈도우로 잇는다. 200K를 넘지 않게 관리.

해석 · SE 기본값

system-prompt-doing-tasks-software-engineering-focus

"…change methodName to snake case — do not reply with just 'method_name'; find the method in the code and modify it."

모호한 지시도 '코드를 고치라'로 해석 — 텍스트가 아니라 작업으로. 범용 에이전트의 기본 자세.

출처 — Claude Code v2.1 system prompts · Piebald-AI 추출 (github.com/Piebald-AI/claude-code-system-prompts)

Stack · Vendor 지침 — 4선10 / 13 · → 4대장

Stage III · Frameworks

#superpowers #gstack #bmad #omc

11 / 13

한 도구 위에 다시 한 층

하네스의 4대장.

Cursor·Claude Code 위에 사람들이 또 하네스를 쌓고 있다.
Stage III는 추측이 아니라 이미 일어나고 있는 일.
아래는 커뮤니티에서 주목받은 케이스 4가지.

Framework — Author

superpowers

Jesse Vincent · obra

plan-first methodology로 시작해 작은 task로 분해, TDD·리뷰가 사이클에 박힘. agentic skills 프레임워크 + 부분-에이전트 협업.

Framework — Author

gstack

Garry Tan · Y Combinator

YC CEO의 23-tool 셋업: CEO · Designer · Eng Manager · Release Manager · Doc Engineer · QA. 한 명의 개인이 가상 팀을 끼고 일한다.

Framework — Author

BMAD-METHOD

BMad Code · Agile AI

"Breakthrough Method for Agile AI Driven Dev". 12+ 도메인 페르소나(PM·Architect·Dev·UX·QA), 34+ 워크플로우, Party Mode 멀티-에이전트 협업.

Framework — Author

🇰🇷 oh-my-claudecode

Yeachan-Heo · 한국

한국 개발자가 만든 multi-agent orchestration. 19 specialized agents, tmux fan-out으로 task를 동시에 분산. "Zero learning curve. Maximum power."

공통점 — 모두 역할을 쪼개고 멀티 에이전트로 분담한다.
차이는 분해 단위뿐 — task · role · persona · agent.

Stage III · 4 Frameworks11 / 13 · → vendor 흐름

Stage III · Vendor Flows

#devin #kiro #closing-the-loop

12 / 13

vendor가 그리는 두 흐름

업계의 두 답 — 자율 vs 게이트.

Closing the Agent Loop · 자율

Devin. Cognition Labs.

코드리뷰 코멘트를 자율로 fix

PR이 올라오면 리뷰어 코멘트를 읽고 스스로 수정 커밋을 푸시한다. 개발자가 매번 babysit하지 않아도 — sensor가 작동하면 loop이 닫힌다.

"Long-running Agents" — Addy Osmani.

Spec-Driven Development · 게이트

Kiro. Amazon Web Services.

Requirements → Design → Tasks 3-phase

요구사항을 EARS 노테이션 (모호함 없는 요구사항 문법: When/While/If/Where + shall)으로 강제, 다음 phase로 넘어가기 전 게이트. AI가 코드 쓰기 전에 사람이 spec을 검증한다.

phase 자체가 traceability — spec.md가 약속이 된다.

공통점: 둘 다 model 위에 실행 구조를 한 층 더 깐다 — Hooks · Subagents · Worktree 같은 Claude Code 메커니즘이 이 위에서 게이트·격리·자동화를 떠받친다. 차이: Devin은 자율 closure로 사람의 부담을 뺀다 Kiro는 phase + gate로 사람의 판단을 박는다 — 트레이드오프는 결국 "어디까지 사람이 들어갈 것인가" 결국: 둘 다 — 발산을 잡는 두 방법. 한쪽은 자율, 한쪽은 게이트.

Stage III · Vendor Flows12 / 13 · → Fin

Fin

#bridge-to-deck-4

13 / 13

Fin.

Better prompts
don't scale.

Better systems do.

말하는 방식을 다듬는 시대는 끝났다.
지금은 실행 구조를 짜는 시대다.
그러면 — 그 구조는 어디서 왔나?

Phase · 검증 · 확장 — 우리가 지금 새로 만들고 있다 믿는 것들.
50년 전에 다른 이름으로 같은 답이 있었다.

Fin · Bridge to Deck 413 / 13 · END