2-The Foundation

Andrew한테 23단계 파이프라인을 안 준 이유 — 맥락은 잘라낼수록 강해진다

Raon

2026년 4월 18일2달 전

카테고리

how-it-works

더 많이 줄수록 더 강해질 것이라는 생각이 있었다. 그 생각을 한 번 끝까지 따라가 봤다.

OpenClaw 에이전트 Andrew를 세팅하던 날, 지식 라이브러리 두 개가 있었다.

market-research-1.0.1/ — 경쟁사 분석 방법론과 증거 등급 체계가 담긴 패키지.
playwright-1.0.3/ — 브라우저 자동화 7원칙이 담긴 패키지.

처음 드는 생각은 단순했다. 다 주면 더 강해지지 않을까?

두 패키지를 통째로 Andrew 컨텍스트에 붙이면 그만이었다. 그런데 그 전에 내용을 한 번 훑어봤다. 그리고 결국 다 주지 않기로 했다. 이유를 정리하다 보니 지식 이식에서만 쓰이는 원칙이 아니었다.

23단계를 4단계로 줄인 이유

market-research-1.0.1/ 안에는 AutoResearchClaw라는 파이프라인이 있었다. 리서치를 23단계로 나눈 구조다. 문헌 검색부터 통계 보정, 동료 검토까지 — 학술 논문 수준의 흐름이었다.

"이걸 Andrew한테 다 넣으면 어떻게 될까"를 시뮬레이션해봤다.

비즈니스 리서치 질문이 하나 들어온다 — "경쟁사 A의 최근 전략 변화를 정리해줘." 그러면 Andrew는 23단계를 밟으려 할 것이다. 질문 정의 → 탐색 범위 설정 → 자료 수집 → 1차 검토 → 교차 검증 → 통계 보정 → … 간단한 경쟁사 조사에 논문급 절차가 실행된다.

이건 강함이 아니라 과부하다.

비즈니스 리서치에 필요한 건 4단계였다.

1. 질문 정의 — 무엇을 알아야 하는가
2. 자료 수집 — 증거 등급 기준으로
3. 교차 검증 — 상충되는 자료 처리
4. 구조화 보고 — 결론 + 근거 등급 명시

23단계를 쓰지 않은 게 아니라, 23단계 중에서 이 4개를 골랐다. 나머지 19단계는 Andrew의 도메인 밖이었다.

7원칙을 3원칙으로 줄인 이유

playwright-1.0.3/에는 브라우저 자동화 7원칙이 있었다. 여기서도 같은 질문이 생겼다 — 7개 전부를 줘야 하는가.

7원칙을 읽다 보니 뒤쪽 4개가 보였다. 테스트 재현성 유지, 오류 스크린샷 자동 저장, 리포트 포맷 표준화, CI 환경 대응.

이건 QA 엔지니어 원칙이다. Andrew는 리서치 에이전트지 테스터가 아니다. 이 4개를 Andrew가 알면, "지금 이 작업이 재현 가능한 테스트인가?"를 매번 고려하게 된다. 불필요한 맥락이 실행을 방해한다.

그래서 앞쪽 3원칙만 가져왔다 — 자료 탐색, 페이지 스크롤, 텍스트 추출. Andrew가 실제로 쓰는 것들.

역할과 무관한 맥락은 빼야 한다

이 두 번의 판단에서 공통점이 보였다. 역할과 무관한 맥락은 빼야 한다. 모른다고 약해지는 게 아니다. 필요 없는 걸 알면 흐릿해진다.

증거 등급만은 통째로 가져온 이유

그런데 한 가지는 자르지 않았다.

market-research-1.0.1/에 있던 증거 등급 체계다.

A등급: 공식 IR·정부 통계
B등급: 주요 언론·업계 리포트
C등급: 커뮤니티 반응·비공식 인터뷰
D등급: 추측·익명 제보

이건 4단계 전부를 다 줬다. 이유는 하나다 — 리서치의 공용 언어이기 때문이다.

Andrew가 보고서를 쓸 때 "A등급 자료 2건 기반"이라고 명시하거나 "C등급 자료만 존재 — 신뢰도 낮음"이라고 쓰면, 그 보고서를 읽는 사람도 등급을 알아야 한다. 절반만 이식하면 언어가 깨진다.

뺄 것과 남길 것을 구분하는 기준이 여기서 드러났다. "역할에서 쓰이는가"가 아니라 "공유 언어인가"도 기준이 된다. 쓰는 곳이 한 명이 아니라면, 공용 문법은 지워서는 안 된다.

서브에이전트 위임도 같은 원칙으로 실패한다

지식을 골라내는 원칙은 생각보다 더 넓게 쓰인다는 걸 뒤에 알았다.

OpenClaw를 먼저 운영해온 다른 팀 에피소드에서 들은 이야기가 있다. 서브에이전트에게 이미지 카드 제작을 위임했는데 전량 재작업이 필요했던 사건이다. 에이전트가 흰색 배경 카드 100장을 만들어야 했는데 보라색으로 나왔다.

처음엔 "더 비싼 모델을 쓰면 해결된다"고 생각했다고 한다. 바꿔봤는데 여전히 보라색이었다.

이유는 모델이 아니었다. 서브에이전트는 메인 에이전트의 기억을 가져가지 않는다. SOUL.md도, MEMORY.md도, 지금까지 쌓인 디자인 맥락도 — 전부 가져가지 않는다. 모델이 아무리 좋아도 맥락이 없으면 처음 만난 사람으로 일한다.

맥락의 밀도가 역할과 맞지 않았다

이게 지식 이식과 정확히 같은 구조다. 지식 라이브러리를 통째로 주면 에이전트의 맥락이 과부하된다. 서브에이전트에게 판단을 맡기면 서브에이전트의 맥락이 비어있다. 방향이 반대인 것 같지만 실패 이유는 하나다 — 맥락의 밀도가 역할과 맞지 않았다.

그래서 서브에이전트에게는 판단이 개입되지 않는 작업만 위임하는 게 맞다. 코드 수정, API 호출, 데이터 조회처럼 맥락 없이도 실행할 수 있는 것들.

넣을지보다 빼낼지가 더 중요하다

Andrew에게 주지 않은 것들의 목록이 준 것들의 목록보다 길다.

23단계 중 19단계, 7원칙 중 4원칙. 숫자만 보면 뺀 게 훨씬 많다.

그런데 결과는 더 정확한 리서치가 나온다. 더 빠르게. 역할에 맞는 맥락만 가진 에이전트는 자기 일에 집중할 수 있다. 잘라낸 맥락은 약점이 아니라 경계선이다.

지식 이식의 난이도는 "무엇을 넣을지" 결정하는 것보다 "무엇을 넣지 않을지" 판단하는 것에 있다. 넣는 건 추가다. 빼는 건 책임이다.

컨텍스트는 항상 제한되어 있다. 무엇을 넣을지보다, 무엇을 빼낼지가 더 중요한 판단이다. 맥락은 잘라낼수록 강해진다.

'The Architect of AI Workforce' 구독하기

사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'The Architect of AI Workforce'을 구독하세요!