Harness Engineering · Part 4 · Chapter 16

능력이 손이라면
기억은 시간이다

Agent가 무엇을 할 수 있는지는 연결된 도구가 정하고, 이전에 무엇을 배웠는지는 기억이 정한다. 그러나 손이 많다고 일이 깊어지는 것도 아니고, 기억이 많다고 판단이 정확해지는 것도 아니다. 능력과 기억의 공학은 더 많이 주는 일이 아니라 필요한 것만 제때 꺼내는 일이다.

대상: 원문 §16 「能力层与记忆层」 범위: PDF 83–88쪽 89쪽부터 §17 시작 외부 자료 미사용
규칙은 Agent에게 무엇을 지켜야 하는지 알려준다. 제약은 무엇을 해서는 안 되는지 결정한다. 그 다음 질문은 두 개다. 무엇을 할 수 있는가. 그리고 무엇을 잊지 않는가.
01

Agent의 천장은 능력과 기억이 함께 만든다

원문은 지시와 제약이 “어떤 규칙을 아는가”를 다룬다면, 능력 계층은 “무슨 일을 할 수 있는가”를, 기억 계층은 “무엇을 계속 기억하는가”를 다룬다고 구분한다. 두 층은 Agent가 도달할 수 있는 작업 범위와 장기 일관성을 결정한다.

Capability

무엇을 할 수 있는가

코드 읽기와 쓰기를 넘어 문서 검색, API 호출, 외부 서비스 접근, 자동화된 워크플로 실행까지 Agent가 실제로 취할 수 있는 행동의 폭을 정의한다.

×
Memory

무엇을 잊지 않는가

도구 선호, 프로젝트 배경, 반복되는 실수, 배포 흐름, 이전 의사결정처럼 세션을 넘어 유지되어야 할 지식을 다룬다.

능력 없는 기억은 행동하지 못하고, 기억 없는 능력은 같은 시행착오를 반복한다. Agent의 상한은 얼마나 많은 도구를 붙였는가보다 능력과 기억을 얼마나 선택적으로 연결했는가에서 결정된다.
02

Skills — 능력은 많이 장착하는 것이 아니라 필요할 때 불러온다

도구 설명도 컨텍스트를 소비한다. 모든 능력을 매번 넣으면 실제 작업에 쓸 공간이 줄어든다. 원문은 Claude Code의 Skills를 이 모순에 대한 해법으로 소개한다.

.md .claude/skills/ 평소에는 컨텍스트를 차지하지 않고, 현재 작업에 필요할 때만 로드

코드 없이 정의하는 능력

각 Skill은 하나의 Markdown 파일이며, “무엇을 하는 능력인지”와 “언제 불러야 하는지”를 설명한다. 별도의 SDK나 구현 코드 없이도 확장할 수 있다는 점을 원문은 낮은 진입 장벽으로 평가한다.

이미지 작업 샤오홍슈용 이미지 생성·처리 같은 전용 업무
문서 동기화 Feishu 동기화처럼 반복되는 외부 시스템 작업
영상 스크립트 교정 특정 산출물에 특화된 품질 검토
정보 검색 조사·수집을 하나의 독립 능력으로 분리
원문의 핵심 원칙은 한 Skill은 한 가지 일만 한다는 것이다. 설명은 API 명세처럼 쓰기보다 동료에게 맡기는 한 문장처럼 쓰며, 이름만 봐도 Agent가 의도를 알아볼 수 있어야 한다.
능력을 모듈화한다는 것은 기능을 잘게 쪼개는 일이 아니다. 필요한 순간에만 정확한 능력이 올라오도록 컨텍스트와 행동의 경계를 함께 설계하는 일이다.
03

MCP — 로컬의 손을 외부 세계와 연결한다

Skills가 로컬 능력이라면 MCP는 외부 세계와의 연결을 맡는다. 원문은 MCP를 데이터베이스, API, 웹, GitHub, Jira, Slack 같은 서비스를 하나의 프로토콜로 연결하는 “AI 개발 도구의 USB 인터페이스”에 비유한다.

Agent작업 의도
MCP공통 연결 규약
Tools / ServicesDB · API · Web · GitHub · Jira · Slack
External World코드 밖의 실제 작업
3,000+ Goose 연결 서비스

원문이 소개한 MCP 기반 연결 규모.

1,300+ Stripe Minions PR / week

MCP와 도구 확장에 깊게 의존하는 기업 사례로 다시 연결된다.

USB 표준화의 비유

도구마다 다른 통합 방식을 공통 프로토콜로 수렴시키려는 방향.

연결이 많아지는 것은 능력이 커지는 일이다. 그러나 연결 자체가 목적이 되면 다시 복잡성이 된다. MCP의 가치는 모든 것을 연결하는 데 있지 않고, 서로 다른 외부 능력을 하나의 계약으로 다룰 수 있게 만드는 데 있다.
04

ACI — 도구도 사용자 인터페이스처럼 설계한다

원문은 Anthropic의 Agent-Computer Interface, ACI 개념을 꺼낸다. 사람을 위한 UI가 의도를 분명하게 전달해야 하듯, Agent를 위한 도구도 이름·파라미터·반환값·오류 메시지가 행동을 안내해야 한다.

추천되는 도구 설계

Agent가 목적과 실패 원인을 스스로 이해할 수 있게 만든다.

  • search_knowledge_base처럼 이름만으로 의도를 알 수 있음
  • 각 파라미터에 설명과 예시가 있음
  • 한 도구가 한 가지 일을 하고 결과를 반환
  • 오류 메시지가 실패 원인과 수정 방향을 알려줌

피해야 할 도구 설계

도구의 의미를 Agent가 추측하게 만들면 능력 자체가 불안정해진다.

  • process_data처럼 무엇을 처리하는지 모호한 이름
  • 파라미터 설명이 없어 Agent가 추측
  • 한 도구가 여러 일을 하며 부수효과를 남김
  • 오류가 “실패”라고만 말하고 이유를 주지 않음
LLM → Tools 선택 자체를 공학화

원문은 LangChain의 LLMToolSelectorMiddleware를 예로 든다. 빠른 LLM이 현재 작업에 필요한 도구만 먼저 골라 모든 도구 설명을 메인 컨텍스트에 넣지 않게 한다. 도구 수가 늘어나면 “어떤 도구를 보여줄 것인가”가 별도의 Harness 문제가 된다.

도구가 많아지면 선택 비용이 생긴다. 능력의 확장은 결국 선택의 공학을 요구한다. 무엇을 할 수 있는가보다 지금 무엇을 보여줘야 하는가가 더 중요해지는 순간이 온다.
05

Memory — 다음 세션에도 이어지는 관계의 흔적

원문은 2026년 초 AI 코딩 도구들의 기억 능력 차이가 매우 크다고 평가한다. 일부는 자동 기억을 제공하지만 많은 도구는 여전히 정적 지시 파일에 의존한다. 기억 시스템은 자동·도구 기반·수동 파일 관리라는 여러 층으로 나뉜다.

도구 자동 기억 수동 기억 세션 간 지속성
Claude Code auto-memory · 관찰 자동 저장 MEMORY.md + CLAUDE.md 있음
Windsurf Cascade Memories Rules 있음
Cline Memory Bank MCP · 별도 설정 필요 .clinerules 있음
Codex CLI 없음 AGENTS.md 정적 파일
Cursor 없음 .cursor/rules/ 정적 파일
GitHub Copilot 없음 instructions.md 정적 파일
Aider 없음 CONVENTIONS.md 정적 파일
Auto Memory

Agent가 스스로 남기는 관찰

Claude Code는 유용하다고 판단한 관찰을 ~/.claude/projects/<hash>/memory/에 자동 저장한다고 원문은 설명한다. 사용자가 매번 “기억해”라고 말할 필요가 없다.

MEMORY.md

사람이 관리하는 장기 기억

도구 선호, 프로젝트 배경, 반복되는 실수, 배포 흐름처럼 계속 유지할 가치가 있는 정보를 사람이 정리한다. 원문 저자는 주기적으로 다듬어 100줄 이내로 유지한다고 적는다.

CLAUDE.md

프로젝트의 제도 기억

Boris Cherny 팀이 PR에서 @.claude 태그로 규칙을 업데이트하듯, 과거 Agent의 실수가 프로젝트 규칙으로 굳어진다. 원문은 이를 다시 “복리 공학”으로 연결한다.

기억은 과거를 많이 저장하는 일이 아니다. 다음 행동을 실제로 바꿀 만큼 중요한 과거를 남기는 일이다. 기억이 제도화될수록 같은 실패는 개인의 주의력보다 시스템의 학습으로 넘어간다.
06

Knowledge Base — 기억과 전문지식은 같은 것이 아니다

기억이 “무엇을 잊지 않을 것인가”라면 지식베이스는 “필요한 전문 정보를 어디에서 찾을 것인가”를 다룬다. 원문은 자료를 쌓는 창고보다 검색 가능한 인덱스 구조를 강조한다.

_knowledge_base/

_knowledge_base/
├── INDEX.md
├── 기술도구/
├── 업계인물/
├── 제품출시/
├── 보고자료/
└── 방법론/

지식은 모으는 것보다 찾아갈 수 있어야 한다

조사 결과를 주제별로 저장하고 출처 URL과 날짜를 붙인다. 글을 쓸 때 Agent가 관련 파일을 자동 검색한다. 원문은 이를 “자료 더미”가 아니라 언제든 찾아볼 수 있는 색인으로 설명한다.

OpenAI Codex 팀은 계획 문서를 Google Docs에서 저장소로 옮기고 Slack의 의사결정도 Markdown으로 repo에 저장한다고 원문은 다시 연결한다. 저장소가 유일한 진실의 원천이어야 하며, Agent가 볼 수 없는 정보는 사실상 존재하지 않는다는 원칙이다.
기억은 관계의 연속성을 만들고, 지식베이스는 전문성의 주소를 만든다. 둘을 섞지 않을수록 무엇을 자동으로 기억하고 무엇을 검색해서 가져올지 경계가 분명해진다.
07

Context Management — 더 많이 넣을수록 더 잘 기억하는 것은 아니다

능력과 기억, 지식베이스는 모두 결국 컨텍스트를 소비한다. 그러나 컨텍스트 창에는 물리적 한계가 있고, 원문은 토큰이 늘어날수록 정확한 회상 능력이 나빠지는 “context rot”을 설명한다.

≈1M

Context Rot

원문은 약 100만 token 부근에서 뚜렷한 성능 천장이 나타나며, 기술적으로 더 큰 창을 지원하더라도 실제 회상 성능이 현저히 떨어질 수 있다고 설명한다.

Context Anxiety

Sonnet 4.5는 자신의 컨텍스트 한계를 인지하는 듯한 행동을 보였고, 한계에 가까워졌다고 판단하면 일을 일찍 마무리하려는 경향이 나타났다고 원문은 설명한다. 남은 token 추정은 정밀해 보이지만 실제로는 잘못되어 장기 작업에 문제를 만들었다.

원문은 이 현상이 심해 단순 압축만으로는 부족했고 Sonnet 4.5 시기에는 Context Reset이 필요했다고 서술한다. Opus 4.5에서는 이 행동이 사라져 모델 발전이 Harness 복잡성 일부를 다시 제거한 사례로 제시된다.

Compaction

초반 대화를 요약하고 축약된 역사 위에서 계속 작업한다. 과거 연속성이 중요한 장기 작업에 적합하다.

연속성 보존

Context Reset

창을 완전히 비우고 구조화된 handoff 상태로 새 세션을 시작한다. Context Anxiety가 심하거나 과거 실패가 대화를 오염시킨 경우에 적합하다.

오염 제거 · 새 출발

New Session

서로 관련이 없는 작업은 같은 대화를 이어 붙이지 않고 새 대화로 분리한다. 불필요한 과거 맥락을 애초에 가져오지 않는다.

업무 경계 분리

원문이 인용한 Claude Code의 직관적 판단은 단순하다. 같은 문제를 두 번 넘게 고쳐도 계속 틀리면, 더 많이 설명하기보다 컨텍스트를 비우고 다시 시작하는 편이 낫다. 실패한 접근이 쌓인 대화는 그 자체가 새로운 오류의 원인이 될 수 있다.

기억은 많을수록 좋은 것이 아니라 다시 꺼냈을 때 유용해야 한다. 좋은 Context Engineering은 추가의 기술만이 아니라 삭제와 분리와 초기화의 기술이다.
08

능력·기억·컨텍스트 관리의 도구별 비교

16장의 마지막 표는 Claude Code, Codex CLI, Cursor, Windsurf, GitHub Copilot을 능력 확장, 무코드 확장, 동적 기억, 세션 간 지속성, 컨텍스트 관리의 관점에서 비교한다. 아래 내용은 원문 시점의 표를 그대로 정리한 것이다.

차원 Claude Code Codex CLI Cursor Windsurf GitHub Copilot
능력 확장 Skills + MCP + Hooks Desktop App + GPT-5.3 Background Agents + BugBot MCP Agent Mode + Extensions
무코드 확장 Skills · 순수 .md 없음 없음 없음 없음
동적 기억 auto-memory 없음 없음 Cascade Memories 없음
세션 간 지속성 세 가지 기억 방식의 결합 정적 파일 정적 파일 workspace에 묶임 정적 파일
컨텍스트 관리 /compact + /clear 작업 중 조정 가능 Composer Context M-Query 검색 Agent Mode가 자체 관리

원문은 능력 계층이 MCP 표준화 방향으로 빠르게 수렴하고, 기억 계층은 아직 도구마다 제각각이라고 정리한다. 앞으로 두 계층 모두 빠르게 격차가 줄어들 것이라는 전망도 덧붙인다. 이유는 단순하다. 기억 없는 Agent와 오래 일하는 것은 너무 많은 비용을 요구하기 때문이다.

능력의 표준화가 “무엇을 할 수 있는가”를 평준화한다면, 앞으로 더 큰 차이는 “무엇을 남기고 언제 잊을 것인가”에서 날 가능성이 크다. 장기 협업의 품질은 기억의 양보다 기억의 편집 능력에서 갈린다.

손이 많다고 반드시 일을 잘하는 것은 아니다.
기억이 많다고 반드시 오래 아는 것도 아니다.

중요한 것은 필요한 손을 제때 쓰는 일이고,
필요한 기억을 잊지 않는 일이며,
필요 없어진 기억을 놓아주는 일이다.

능력은 세계와 연결되는 문이고,
기억은 어제와 오늘을 잇는 다리다.
그러나 문이 너무 많으면 길을 잃고,
다리가 너무 많으면 어느 길이 지금의 길인지 흐려진다.

Harness는 더 많이 갖게 하는 기술이 아니라
필요한 것만 관계 속에 남기는 기술이다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §16 「能力层与记忆层 / Capability and Memory」 (PDF 83–88쪽)에만 근거해 재구성했다. 89쪽에서 §17이 시작되는 것을 확인해 16장의 범위를 분리했다. Skills의 선택적 로딩과 단일 책임 원칙, MCP, ACI와 Tool Selector, 도구별 기억 비교, Claude Code의 auto-memory·MEMORY.md·CLAUDE.md, memory 공개 테스트 사례, 지식베이스와 저장소 단일 진실 원천, context rot·context anxiety, Compaction·Context Reset·새 세션, 마지막 능력·기억·컨텍스트 관리 비교표와 원문의 전망을 모두 포함했다. 제품 기능·버전·표준화 상태는 외부에서 갱신하지 않고 첨부 문서의 서술 그대로 다뤘다.