AI Agent

프롬프트, 컨텍스트, 그리고 하네스 — AI 개발의 무게중심은 어디로 이동했나

프롬프트만으로는 부족했고, 컨텍스트만으로도 안전하지 않다. AI가 일하는 시스템 전체 — 컨텍스트 큐레이션, 검증 루프, 권한 경계 — 가 어떻게 진화해 왔는지, 그리고 지금 우리가 무엇을 먼저 짜야 하는지를 정리한다.

한 사람이 IDE에서 자동완성을 켠다. 코드가 빨리 나온다.

같은 회사의 다른 자리에서는 PR이 더 자주, 더 크게 올라오는데 머지 직전에서 멈춰 있다. 또 다른 자리에서는 에이전트가 자기 멋대로 권한을 휘둘러 하룻밤 사이에 데이터가 사라진다. 코드는 분명히 빨라졌는데, 시스템은 더 복잡해졌다.

이 엇갈림은 AI가 도구만 바꾼 게 아니기 때문이다. 소프트웨어를 정의·구현·검증·운영하는 시스템 전체가 같이 움직이고 있다. 그래서 일의 무게중심도 따라 이동했다. 한때는 키보드 앞에서 코드를 입력하는 시간이 병목이었고, 그다음엔 아키텍처와 통합이 병목이었다. 지금은 문제 정의, 컨텍스트 구성, 검증 체계, 그리고 인간의 판단이 새 병목이다.

이 글은 그 이동을 따라가는 글이다. 본문에서는 세 질문을 차례로 본다.

무엇이 진짜로 변했는가 (Software 3.0)
왜 프롬프트만으로는 안 됐고, 왜 컨텍스트만으로도 안전하지 않은가
그래서 우리가 다음에 짜야 할 것은 무엇인가 (하네스와 그 위의 운영 패턴)

1. Software 3.0 — 산출물의 정의가 넓어졌다

2022년 11월 ChatGPT 공개 이후 자연어가 사실상 새로운 프로그래밍 인터페이스가 됐다. Karpathy는 이 변화를 Software 1.0 → 2.0 → 3.0이라는 세 단계로 정리한다.¹

구분	핵심 산출물	개발 방식	대표 예
Software 1.0	사람이 작성한 코드	규칙과 로직을 직접 구현	웹 서버, 업무 시스템
Software 2.0	데이터·모델 가중치	데이터로 동작 학습, 가중치가 로직	분류·추천·음성 인식
Software 3.0	프롬프트·컨텍스트·도구·평가	자연어와 도구로 런타임에 행동 구성	코딩·업무 자동화 에이전트

여기서 중요한 건 분류 자체가 아니다. "코드"의 정의가 넓어졌다는 점이다. 3.0 시대에는 사람이 직접 쓴 코드만 산출물이 아니라, 문제 정의 문서, 컨텍스트 큐레이션, 에이전트 지침, 평가 세트, 도구 설명, 작업 로그까지 전부 산출물이다. 그리고 이것들 모두가 코드처럼 버전 관리·테스트·운영의 대상이 된다.

같은 이야기를 2023년부터 Karpathy가 LLM-OS라는 비유로 정리해 왔다. 모델 한 덩어리만 보지 말고 그 주변을 운영체제처럼 보자는 제안이다.²

전통 컴퓨터	LLM 시스템
CPU	LLM
RAM	컨텍스트 윈도우
디스크	RAG·DB·장기 메모리
주변기기	검색·셸·브라우저·코드 실행
운영체제	에이전트 런타임·오케스트레이션·정책

비유는 비유일 뿐이지만 한 가지 시사점은 분명하다. 모델이 좋아진다고 시스템이 저절로 좋아지지 않는다. 좋은 시스템은 RAM(컨텍스트)·디스크(메모리·문서)·주변기기(도구)·OS(런타임·정책)를 어떻게 짜는가에 달렸고, 이건 모델 벤치마크가 알려 주지 않는다.

2. 프롬프트만으로는 풀리지 않은 자리

초기에는 "어떻게 말해야 좋은 답이 나오는가"가 중심 질문이었다. 그래서 등장한 게 추론 구조다.

Chain-of-Thought는 모델이 답을 곧장 내놓는 대신 중간 추론을 거치게 만든다.³ 그러나 외부 세계를 직접 확인하지 못하면 그럴듯한 거짓을 낳는다. ReAct가 그 한계를 보완한다. 검색하고, 파일을 읽고, 명령을 실행하면서 관찰값으로 다음 추론을 갱신하는 루프다.⁴

   Thought       지금 무엇을 할까
       │
       ▼
   Action        도구 호출 (검색·파일 읽기·셸 실행 등)
       │
       ▼
   Observation   결과 관찰
       │
       └──────► 다시 Thought 로

오늘날 코딩 에이전트가 rg로 코드를 찾고, 파일을 열고, 패치를 적용하고, 테스트를 돌리고, 실패 로그를 보고 다시 고치는 흐름이 바로 이 골격이다.

여기서 한 단계 더 나아간 게 Andrew Ng이 정리한 4가지 에이전트 패턴이다.⁵ 한 줄로 정리하면 다음과 같다. 흔한 실패도 같이 적었다.

패턴	핵심	흔한 실패
Reflection	작성과 비판 분리	평가 기준이 없으면 자기비판이 주관에 빠짐
Tool Use	외부 도구 호출	권한·실패 처리 경계가 흐릿
Planning	검증 가능한 중간 목표	중단 조건·롤백 단위 누락
Multi-Agent	역할 분담	공유 컨텍스트가 흐트러져 전제가 충돌

Anthropic은 한 단계 더 들어가 Workflow와 Agent를 구분한다.⁶ 같은 단어로 묶이지만 운영 성격이 다르다.

구분	Workflow	Agent
실행 경로	사람이 정한 경로	모델이 동적으로 결정
장점	예측 가능, 비용 통제	유연, 탐색 가능
단점	예외에 약함	비용·오류가 누적되기 쉬움
적합한 곳	정형 업무, 분류	코드 수정, 리서치, 장애 분석

자율성도 일률적으로 주는 게 아니라 위험도에 맞춰 단계화하는 흐름이 자리잡는 중이다. 초안과 제안 같은 낮은 자율성, 파일 수정과 PR처럼 사람 검토가 붙는 중간 자율성, 운영과 배포처럼 강한 가드레일과 감사 로그가 필수인 높은 자율성으로 나눈다.

문제는 이 모든 기법이 컨텍스트 없이는 무너진다는 점이다. 코드베이스를 보여주지 않고 "이 버그를 고쳐줘"라고 던지는 식의 사용은 데모에서는 그럴듯해 보이지만, 요구사항 흔들림·테스트 부재·보안 누락·기존 계약 충돌·팀 이해 불가가 누적된다. 결국 엄밀함은 사라지지 않고 이동한다 — 코드 한 줄에서 아키텍처로, 그리고 이제는 문제 정의와 검증으로.

3. 컨텍스트 엔지니어링이 등장한 이유

질문이 "어떻게 말할까"에서 "무엇을 보여줘야 모델이 올바르게 판단하는가"로 옮겨가면, 자연스럽게 §1의 LLM-OS 비유에서 RAM에 무엇을 어떻게 채울지를 다루는 영역으로 넘어간다. 핵심은 단순하다. 컨텍스트 윈도우는 작업 기억이다. 디스크(저장된 문서)와 주변기기(검색·도구)에 정보가 아무리 많아도, 작업 기억으로 끌어오지 않으면 모델은 모른다.

LangChain은 컨텍스트 운영을 네 가지 동작으로 정리한다.⁷

동작	의미	개발 예시
Write	컨텍스트 밖에 기록	`AGENTS.md`, ADR, 작업 노트
Select	필요한 것만 가져옴	관련 함수·테스트·로그만
Compress	핵심으로 줄임	긴 로그 → 실패 테스트명·에러·스택 위치
Isolate	작업·역할별 분리	보안 리뷰와 UI 문구를 같은 컨텍스트에 섞지 않음

여기서 직관에 반하는 사실이 두 가지 등장한다.

첫째, Lost in the Middle. 긴 컨텍스트에서 관련 정보가 가운데 묻혀 있을 때보다 앞이나 뒤에 있을 때 모델이 훨씬 잘 활용한다.⁸ 정보의 양보다 위치와 구조가 결정적이라는 뜻이다. 핵심 제약은 짧고 명확하게 두고, 작업 전·검증 전·최종 리뷰 전 시점마다 다시 노출해 잊히지 않게 만드는 패턴이 자리잡는 이유다.

둘째, Context Rot. Chroma의 18개 LLM 실험에서, 입력 토큰이 늘어날수록 모델 성능이 비균일하게 저하됐다.⁹ 같은 정보를 더 길게 보여 주면 더 잘 이해할 거라는 직관과 정반대로, 길어질수록 관련 없는 정보가 판단을 오염시킨다는 관찰이다. 그래서 실무에서 자리잡은 한 가지 패턴은 계층화다 — 항상 들어가는 짧고 강한 규칙 위에 자주 참조되는 도메인 사실을 두고, 실시간 데이터는 필요할 때만 끌어온다. LangChain의 4 동작으로 보면 Write·Select 가 어디에 무엇을 둘지를 정하는 자리, Compress·Isolate 가 길이와 영향 범위를 관리하는 자리다.

비용 관점에서는 Anthropic의 Prompt Caching이 긴 시스템 지시·문서·도구 컨텍스트가 반복될 때 이를 재사용해 부담을 크게 줄인다 — Anthropic은 비용 최대 90% 절감, 지연 최대 85% 단축을 발표했다.¹⁰ 캐시에 쓰는 비용은 base 입력의 +25%, 캐시에서 읽는 비용은 base의 10%다. 다만 cache hit rate를 단독 지표로 보면 함정이다. 같은 prefix만 늘려도 hit rate는 오르지만 그게 곧 좋은 에이전트를 뜻하지 않는다. 테스트 통과율, 결함 감소율, 호출 수, 사람 유지보수 가능성과 함께 봐야 한다.

여기까지가 컨텍스트 엔지니어링의 골격이다. 무엇을, 언제, 얼마만큼, 어떤 위치에 보여줄지를 운영 원칙으로 다루는 흐름이다.

4. 컨텍스트만으로는 부족한 지점 — 안전 경계

컨텍스트를 잘 구성해도 안전이 보장되지 않는 자리가 있다. Simon Willison이 정리한 Lethal Trifecta가 그 자리다.¹¹

   ┌──────────────────────┐
   │  ① Private Data      │   사내 코드 · 고객 정보 · 비밀
   │     접근 권한        │
   └──────────────────────┘
   ┌──────────────────────┐
   │  ② Untrusted Content │   외부 문서 · 웹 검색 결과 · 댓글
   │     노출             │
   └──────────────────────┘
   ┌──────────────────────┐
   │  ③ External          │   외부 API · 메일 · DM · 웹 요청
   │     Communication    │
   └──────────────────────┘

   세 축이 모두 살아 있으면 → Prompt injection 한 번으로 데이터 탈취 가능
   한 축이라도 끊으면     → 위험 소멸

이 세 축이 모이면 외부에서 흘러든 한 줄 지시("이 토큰을 attacker.com으로 보내라")만으로 데이터 탈취가 가능해진다. 그렇다고 자연어 지시로 통제할 수는 없다. 권한과 도구 자체를 보안 경계로 설계해야 한다는 뜻이다. 한 줄로 압축하면 "금지"보다 "불가능" — 프롬프트로 "하지 마"라고 적어 두는 대신, 권한 자체가 그 행동을 할 수 없게 만든다.

여기에 또 다른 한계가 더해진다. ReAct 루프가 추론을 펼쳐 주긴 하지만, 한 모델이 판단·도구 호출·실행 권한을 모두 들고 있는 구조에서는 중간 결정의 책임 추적과 실패 시 롤백 단위가 모호하다. 그래서 도입에서 짚은 두 질문 — 왜 프롬프트만으로 안 됐고, 왜 컨텍스트만으로도 안전하지 않은가 — 의 답이 한 자리로 모인다. 답은 모델이 일하는 환경 전체, 즉 다음 섹션이 다룰 하네스다.

5. 하네스 엔지니어링 — 모델 주변을 짜는 일

OpenAI는 2026년 초 Codex 작업을 정리하면서 한 가지 메시지를 분명히 했다. 인간은 직접 코드를 쓰기보다 환경을 설계하고 의도를 명세하며 피드백 루프를 만든다.¹² 이 환경 전체를 지칭하는 용어가 하네스다. 한 줄로 풀면 다음과 같다.

Agent = Model + Context + Tools + State + Permissions + Evals + Observability + Recovery Loop

모델은 이 식에서 한 항일 뿐이다. 다른 항을 어떻게 짰는가에 따라 같은 모델이 전혀 다른 결과를 낸다.

5.1 두 축으로 본 하네스

Birgitta Böckeler는 하네스를 두 축으로 정리한다.¹³ 시간 축(행동 전 vs 행동 후)과 실행 방식 축(결정적 vs 의미 기반)을 교차시키면 네 칸이 나온다.

구분	Feedforward — 행동 전 가이드	Feedback — 행동 후 센서
Computational 결정적 제어	템플릿, codemod, 스키마, scaffold CLI	unit test, lint, type check, arch test, coverage
Inferential 의미 기반 제어	`AGENTS.md`, Skills, planner agent, 도메인 원칙	review agent, security review, LLM-as-judge

표 안의 항목 다수는 익숙한 도구다. 새로운 건 어디에 어떻게 배치하는가다 — 같은 unit test도 우상단에 배치되면 회복 신호로, 좌상단의 scaffold가 깔리면 실수 발생 자체를 줄이는 가드로 작동한다.

실무에서 깔리는 순서도 정해진다. 먼저 빠르고 결정적인 검증(우상단의 lint·type·test)을 빈틈없이 깐다. 그 위에 결정적 가이드(좌상단의 템플릿·codemod)로 실수의 발생 자체를 줄이고, 의미 기반 가이드(좌하단의 AGENTS.md·Skills)로 도메인 판단 기준을 구조화한 뒤, 마지막에 의미 검토(우하단의 review agent·LLM-as-judge)를 일부 자동화한다. 사람 검토를 없애는 게 아니라 가장 중요한 지점에 사람이 집중되도록 만드는 것이 목표다.

5.2 사례 둘

이 골격이 실제로 어떻게 작동하는지를 보여주는 사례 둘이 있다. 하나는 멀티 에이전트로 분업화한 구조, 다른 하나는 한 프롬프트를 끝없이 돌리는 단순 루프다.

Anthropic의 3-Agent 하네스는 만든 사람과 검사하는 사람을 분리해 자기평가의 관대함을 깨는 구조다.¹⁴

   사용자 요청
       │
       ▼
   Planner       제품/기술 명세 (요청을 시스템 설명으로 확장)
       │
       ▼
   Generator     명세 기반 구현 + 자체 점검
       │
       ▼
   Evaluator     Playwright MCP로 실제 앱을 클릭하며 점수·피드백
       │
       ├── 기준 미달 ──► Generator 로 되돌림
       │
       └── 통과 ──► 다음 작업으로

Planner는 짧은 요청을 명세로 확장하고, Generator는 명세 기반으로 구현하며, Evaluator는 Playwright MCP로 실제 앱을 클릭하면서 점수와 수정 피드백을 돌려준다. 흐름을 잃지 않게 만들고(명세), 자기평가의 관대함을 깨고(분리), 테스트가 놓치는 UX 문제를 잡는다. 출처는 사람의 최종 검토를 필수 단계로 명시하지 않는다 — 운영자가 PR을 함께 보거나 비활성으로 둘 수는 있지만, 다이어그램 단계에서는 자율적으로 다음 작업으로 넘어가는 구조다.

Ralph Pattern은 정반대 방향에서 같은 결론에 닿는다.¹⁵ 하나의 프롬프트를 무한 루프로 돌리고 마크다운 파일을 상태 저장소로 쓴다. 핵심 코드는 한 줄이다 — while :; do cat PROMPT.md | claude-code; done. 종료 조건은 별도 코드가 아니라 마크다운 안의 체크리스트다. 모든 항목이 체크되면 멈추고, 중간에 끊겨도 다음 실행이 같은 마크다운을 읽고 이어간다. 단순해 보이지만 상태 외부화·결정적 재현성·돌발 종료 후 재개 가능성이라는 속성이 따라온다. 화려한 멀티 에이전트가 아니어도 잘 짠 루프 하나가 큰 작업을 묵묵히 끝내는 모습을 보여 준다.

두 사례가 가리키는 결론은 같다. 하네스의 핵심은 모델 자체가 아니라, 모델이 일하는 환경을 어떻게 짰는가다.

6. 자율화 5단계와 운영 패턴

하네스가 잘 짜이면 자연스럽게 다음 질문이 따라온다. 어디까지 자율적으로 맡길 것인가. §2 끝에서 한 번 짚었듯 자율성은 한 번에 주는 게 아니라 단계로 본다. 아래 다섯 단계는 단일 권위 표준이라기보다, 코딩 보조 → 어시스턴트 → 작업 단위 에이전트 → 장기 실행 → 자율 시스템 순으로 자리잡는 업계 흐름을 저자가 일반화한 정리에 가깝다.

단계	주도권	모습	필요한 엔지니어링
1. 코드 완성	사람 + AI 보조	다음 줄 자동완성	좋은 로컬 컨텍스트, naming
2. 코딩 어시스턴트	사람 주도, AI 대화	설명·리팩터·테스트	컨텍스트 선별
3. 작업 단위 에이전트	AI가 작업 단위 실행	이슈 받아 PR 제출	도구·검토·테스트·리뷰
4. 장기 실행 에이전트	AI가 다단계 자율	며칠짜리 마이그레이션	상태·복구·평가 인프라
5. 자율 시스템	AI가 배포·운영까지	24/7 운영 자율화	강한 가드레일·감사·정책·관측

각 단계는 이전을 포함한다. 단계가 올라갈수록 모델보다 하네스의 비중이 커진다는 것이 일관된 관찰이다.

이 단계 위에서 자주 보이는 두 가지 운영 패턴이 있다.

첫째, 검증 단계화. 같은 결함을 어느 단계에서 잡느냐에 따라 비용이 한 자릿수 단위로 달라진다.

단계	검증 종류	비용
L1	type check, syntax, lint	가장 낮음
L2	unit test	낮음
L3	integration · contract test	중간
L4	e2e · 시각 회귀	높음
L5	사람 검토 · 비즈니스 검증	가장 높음

L1에서 잡힐 문제가 L5까지 가면 비용이 폭증한다. §5의 하네스 두 축에서 결정적 사후(우상단)부터 빠르게 깔고 그 위에 의미 검토(우하단)를 얹는 순서와 같은 결이다.

둘째, 피드백 인코딩. 같은 지적이 두 번 나오면 다음 단계로 승격시킨다.

   즉흥 코멘트 ──► 체크리스트 ──► lint 규칙 ──► 테스트 ──► 자동 수정 · codemod
   (사람이      (문서로            (도구로            (자동 실행)    (자동 적용)
    한 번 말함)   기록)              강제)

이렇게 인코딩된 피드백만 시스템에 남는다. 사람의 시간은 새로운 종류의 판단에 쓰이고, 같은 실수가 두 번 반복되면 자동으로 잡힌다. 이 과정이 작동하면 에이전트의 평가 기준이 시간이 갈수록 강해지는 복리 효과가 생긴다.

§4의 Trifecta가 가리킨 결론은 운영 단계에서 더 구체화된다. 모델이 판단하는 자리와 도구가 행동하는 자리를 다른 컨테이너·다른 NetworkPolicy·다른 계정으로 두면, Trifecta의 한 축이 인프라 단계에서 자동으로 끊긴다. 단일 권위 명칭으로 정착된 구조는 아직 없다.

마지막으로 외부 시스템과의 연결이다. MCP(Model Context Protocol)는 파일·DB·SaaS·검색·브라우저·사내 API를 표준 인터페이스로 묶는 프로토콜이다.¹⁶ 능력 확장은 곧 공격 표면 확장이라는 점만 같이 본다. 데이터 접근 범위, 읽기와 쓰기 분리, 승인이 필수인 액션, 감사 로그가 같이 설계되지 않으면 Trifecta의 세 축이 한꺼번에 활성화된 시스템을 만들기 쉽다.

7. 그래서 무엇을 먼저 깔아야 하는가

진화 서사가 일관되게 가리키는 자리를 추리면 네 가지 첫걸음이 남는다. 도구 비교나 모델 선택은 그다음이다.

   ┌─ 1. 컨텍스트 자산을 코드처럼 관리                       (§1 · §3)
   │     AGENTS.md · repo instructions · Skills · 도메인 용어집
   │     → 작업 기억(컨텍스트 윈도우)에 끌어오지 않으면 모델은 모른다
   │
   ├─ 2. 결정적 검증부터 빈틈없이                            (§5 · §6)
   │     lint · type · unit · integration → L1·L2를 먼저
   │     → 같은 결함은 일찍 잡을수록 비용이 작다
   │
   ├─ 3. 권한을 인프라 경계로                                (§4 · §6)
   │     IAM · sandbox · NetworkPolicy로 Trifecta 한 축 끊기
   │     → "금지"보다 "불가능"
   │
   └─ 4. 학습 루프                                            (§6)
         같은 지적 두 번 = 다음 단계로 승격, 실패는 평가 세트로
         → 평가 기준이 시간이 갈수록 강해지는 복리 효과

리더 입장에서는 한 가지가 더 따라온다. 어느 항목이든 누가 운영하는가가 정해지지 않으면 모두 일회성 시도로 흩어진다. 이름이 AI enablement든 engineering productivity든 SDLC platform이든 AIOps platform이든 상관없다. 컨텍스트 자산을 큐레이션하고, 검증 하네스를 굴리고, 권한 정책을 갱신하고, 학습 루프를 닫는 역할이 어딘가에 명시적으로 있어야 한다. 이 자리가 비어 있으면 도구는 늘어도 조직의 학습은 쌓이지 않는다.

결론

진화 단계 — 프롬프트, 컨텍스트, 안전 경계, 하네스, 그리고 운영 주체 — 가 가리키는 자리는 일관되다.

모델은 실행력을 제공하고
하네스는 제어와 검증을 제공하며
조직은 컨텍스트 자산을 큐레이션하고, 검증 하네스를 굴리고, 실패를 평가 세트로 인코딩하는 운영 주체를 명시적으로 둔다

각 자리가 따로 움직이면 어느 한쪽만 잘해도 전체는 늘 부족해 보인다. 그래서 결론은 처음의 한 줄로 돌아간다.

경쟁력은 어떤 모델을 쓰는가가 아니라, 그 모델이 일하는 환경을 어떻게 짰는가에서 갈린다.

벤더 발표나 모델 벤치 점수를 따라다니다 보면 이 자리를 자주 놓친다. 다음 분기에 어떤 모델이 더 똑똑해지든, 컨텍스트를 코드처럼 관리하고, 결정적 검증을 먼저 깔고, 권한을 인프라로 끊고, 학습 루프를 돌리는 자리가 비어 있으면 같은 자리를 한 번 더 맴돈다. 반대로 이 자리가 채워지면, 같은 모델로도 결과가 달라진다.

부록 A. 용어 지도

본문에 등장한 프레임과 용어의 1차 출처를 한 표로 모았다. 표준 분류라기보다 빠른 오리엔테이션을 위한 개념 지도다.

용어	주창자·1차 출처	성격
Software 3.0	Karpathy, YC AI Startup School 2025-06-17¹	패러다임 선언
LLM-OS	Karpathy, Intro to Large Language Models 2023-11-23 (42:15~)²	비유
Chain-of-Thought	Wei et al., NeurIPS 2022 (arXiv:2201.11903)³	추론 패턴
ReAct	Yao et al., ICLR 2023 (arXiv:2210.03629)⁴	추론·행동 루프
4 Agentic Patterns (Reflection / Tool Use / Planning / Multi-Agent Collaboration)	Ng, The Batch Issue 241, 2024-03-20⁵	설계 패턴
Workflow vs Agent	Anthropic, Building effective agents 2024-12-19⁶	운영 구분
Context Engineering (Write/Select/Compress/Isolate)	LangChain, 2025-07-02⁷	컨텍스트 운영
Lost in the Middle	Liu et al., TACL 2023 (arXiv:2307.03172)⁸	경험 관찰
Context Rot	Hong, Troynikov, Huber (Chroma), 2025-07-14⁹	경험 관찰
Prompt Caching	Anthropic, 2024-08-14¹⁰	비용·지연
Lethal Trifecta	Willison, 2025-06-16¹¹	보안 프레임
MCP (Model Context Protocol)	Anthropic, 2024-11-25¹⁶	도구 인터페이스
Harness Engineering	OpenAI (Lopopolo) 2026-02-11¹² · Böckeler 2026-04-02¹³	산업 프레임
3-Agent (Planner/Generator/Evaluator)	Rajasekaran (Anthropic Engineering), 2026-03-24¹⁴	산업 사례
Ralph Pattern	Huntley, 2025-07-14¹⁵	산업 사례

부록 B. 프레임 × 진화 단계 커버리지

각 프레임이 어느 단계를 중심으로 다루는지 (●=중심 · ○=부수 · 빈칸=거의 다루지 않음).

프레임	Prompt	Context	Harness	Operations
Software 3.0 (Karpathy)	○	○	○	○
Chain-of-Thought · ReAct	●	○
4 Agentic Patterns (Ng)	●	○	○
Workflow vs Agent (Anthropic)		○	●	○
Context Engineering (LangChain)		●	○
Lost in the Middle · Context Rot		●
Prompt Caching (Anthropic)		●		○
Lethal Trifecta (Willison)		○	●	●
MCP (Anthropic)		○	●	○
Harness Engineering (OpenAI · Böckeler)		○	●	●
3-Agent (Anthropic)		○	●
Ralph Pattern (Huntley)		○	●

References

1차 자료 (벤더·공식)

학술 논문

연구·블로그

Disclosures

저자 소속: 독립 분석자. Anthropic · OpenAI · LangChain · Chroma · Thoughtworks(Böckeler 소속)와 직접 이해관계(지분·유료 지원·파트너십) 없음.
스폰서·접대: 없음.
작성 도구: 본 글은 AI 보조 도구와 웹 검색을 함께 써 작성·팩트체크됐다. 다이어그램은 ASCII 텍스트만 사용했고 이미지는 사용하지 않았다.
팩트체크 방법: 본문 인용 17개 출처에 대해 1차 URL과 게시 날짜를 직접 검증했다. Accessed 기준일은 2026-05-04. 다음 네 항목은 검증 과정에서 흔한 오인용을 정정해 본문에 반영했다.
Context Rot의 1차 출처는 Apparate Labs/Daniel Brewer가 아닌 Chroma Research(Hong, Troynikov, Huber), 2025-07-14.
Karpathy LLM-OS의 1차 talk은 Microsoft Build 2023이 아닌 2023-11-23 [1hr Talk] Intro to Large Language Models (42:00~).
Andrew Ng 4 Agentic Patterns의 1차는 deeplearning.ai 단행 블로그가 아닌 The Batch Issue 241, 2024-03-20.
Anthropic Prompt Caching의 게시일은 2024-08-14 (일부 인용에서 2025로 잘못 표기되는 경우 있음).
표현 강도 조정: Böckeler의 두 축은 본문에서 처음부터 4사분면 격자로 제시되지 않으므로, "교차시키면 자연스럽게 네 칸이 나온다"는 표현으로 표기했다. 본문 §5.1의 4사분면 표는 Böckeler가 직접 매핑한 항목(codemod, AGENTS.md, Skills, tests, linters, type checkers, structural analysis, coverage, review agents, LLM-as-judge)을 기반으로 하되, 각 칸의 예시 일부(좌상단의 템플릿·스키마·scaffold CLI, 좌하단의 planner agent·도메인 원칙, 우하단의 security review)는 본문이 같은 결로 일반화·보강한 항목이다. 권한 격리 사례에 대해 단일 권위 1차 출처가 없는 명칭(예: 'Brain·Hands·Session 분리')은 사용하지 않고, 흐름이 가리키는 방향만 일반화해 표기했다. Swiss Cheese Model의 AI 보안 차용 또한 단일 1차 출처가 분산되어 있어 출처 표기 없이 본문에서 다루지 않았다.

각주

Karpathy, "Software Is Changing (Again)", YC AI Startup School, 2025-06-17. https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again ; YouTube https://www.youtube.com/watch?v=LCEmiRjPEtQ (Accessed 2026-05-04) ↩↩
Karpathy, "[1hr Talk] Intro to Large Language Models", 2023-11-23, LLM OS section at 42:15. https://www.youtube.com/watch?v=zjkBMFhNj_g (Accessed 2026-05-04) ↩↩
Wei, Wang, Schuurmans, Bosma, Ichter, Xia, Chi, Le, Zhou, "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", arXiv:2201.11903, 2022-01-28; NeurIPS 2022. https://arxiv.org/abs/2201.11903 (Accessed 2026-05-04) ↩↩
Yao, Zhao, Yu, Du, Shafran, Narasimhan, Cao, "ReAct: Synergizing Reasoning and Acting in Language Models", arXiv:2210.03629, 2022-10-06; ICLR 2023. https://arxiv.org/abs/2210.03629 (Accessed 2026-05-04) ↩↩
Ng, "Agentic Design Patterns Part 1", The Batch Issue 241, 2024-03-20. https://www.deeplearning.ai/the-batch/issue-241/ (Accessed 2026-05-04) ↩↩
Anthropic, "Building effective agents", 2024-12-19. https://www.anthropic.com/research/building-effective-agents (Accessed 2026-05-04) ↩↩
LangChain, "Context Engineering for Agents", 2025-07-02. https://blog.langchain.com/context-engineering-for-agents/ (Accessed 2026-05-04) ↩↩
Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni, Liang, "Lost in the Middle: How Language Models Use Long Contexts", arXiv:2307.03172, 2023-07-06; TACL 2023. https://arxiv.org/abs/2307.03172 (Accessed 2026-05-04) ↩↩
Hong, Troynikov, Huber, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", Chroma Research, 2025-07-14. https://research.trychroma.com/context-rot (Accessed 2026-05-04) ↩↩
Anthropic, "Prompt caching with Claude", 2024-08-14. https://www.anthropic.com/news/prompt-caching ; 시스템 프롬프트·도구 정의·문서 등 블록 단위로 캐시되는 구조의 명세는 API docs https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching 참조. (Accessed 2026-05-04) ↩↩
Willison, "The lethal trifecta for AI agents: private data, untrusted content, and external communication", 2025-06-16. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ (Accessed 2026-05-04) ↩↩
Lopopolo (OpenAI), "Harness engineering: leveraging Codex in an agent-first world", 2026-02-11. https://openai.com/index/harness-engineering/ (Accessed 2026-05-04) ↩↩
Böckeler, "Harness engineering", martinfowler.com (Exploring Gen AI), 2026-04-02. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html (Accessed 2026-05-04) ↩↩
Rajasekaran, "Harness design for long-running application development", Anthropic Engineering, 2026-03-24. https://www.anthropic.com/engineering/harness-design-long-running-apps (Accessed 2026-05-04) ↩↩
Huntley, "Ralph Wiggum as a 'software engineer'", 2025-07-14. https://ghuntley.com/ralph/ (Accessed 2026-05-04) ↩↩
Anthropic, "Introducing the Model Context Protocol", 2024-11-25. https://www.anthropic.com/news/model-context-protocol (Accessed 2026-05-04) ↩↩