Agent Harness Notes 03. Bounded Context로 본 프로젝트 운영 경계

지난 두 편에서 정리한 결론은 단순했습니다.

AI 에이전트 운영에서 먼저 늘려야 하는 것은 역할의 수가 아니었습니다. 먼저 닫아야 하는 것은 경계였습니다. 같은 Planning, Review, Engineering이라는 이름을 쓰더라도, 그 역할이 어떤 데이터와 어떤 실행 표면에 닿는지는 저장소마다 달라야 했습니다.

이번 글은 그 구조를 소프트웨어 설계의 Bounded Context 관점으로 다시 읽어보는 기록입니다. Martin Fowler는 Bounded Context를 DDD의 전략 설계에서 큰 모델을 여러 context로 나누고 관계를 명시하는 패턴으로 설명합니다. Eric Evans의 DDD Reference에서도 bounded context는 특정 모델이 정의되고 적용되는 경계로 설명됩니다.

이 글은 DDD 해설이 아닙니다. 그 관점을 빌려서, AI 에이전트가 여러 저장소를 오갈 때 왜 같은 역할이라도 다른 문맥으로 실행되어야 하는지 정리합니다.

5개 저장소는 폴더 분리가 아니었습니다

처음에는 저장소를 나눈다는 말이 폴더를 나눈다는 말처럼 보였습니다.

하지만 실제로 어려웠던 것은 폴더가 아니었습니다. 어떤 저장소가 무엇을 책임지고, 어떤 저장소가 무엇을 절대 소유하지 않아야 하는지 정하는 일이 더 중요했습니다.

개인 위키 저장소는 공부, 원본 수집, 글쓰기 source를 맡습니다. 사이트 저장소는 독자가 실제로 만나는 presentation layer를 맡습니다. 공용 하네스 저장소는 role, lane, template, validation 같은 운영 언어를 맡습니다. 회사 쪽 저장소들은 authoring, approval, audit, execution surface를 분리해서 다룹니다.

이 구조를 하나의 폴더 트리로만 보면 핵심이 흐려집니다.

중요한 것은 저장소의 개수가 아니라 각 저장소가 적용하는 모델입니다. 같은 "작업"이라는 단어도 개인 글쓰기 문맥에서는 source-of-truth와 publish contract를 뜻하고, 회사 실행 문맥에서는 승인, 감사, 외부 행동 위험을 뜻할 수 있습니다.

그래서 저장소를 나눈 것은 정리정돈이 아니라 문맥 분리였습니다.

같은 Planning이라도 닿는 데이터가 다르면 다른 문맥입니다

Agent Harness Notes 01에서 고정한 문장이 있습니다.

role/lane is shared, data/surface is isolated

역할과 lane은 공유할 수 있습니다. Planning은 개인 블로그 기획에도 필요하고, 회사 작업 정리에도 필요합니다. Review도 마찬가지입니다. Engineering도 마찬가지입니다.

하지만 같은 Planning이라는 이름을 쓴다고 해서 같은 context에서 실행되는 것은 아닙니다.

개인 글쓰기 Planning은 raw, wiki, output, site handoff를 봅니다. 제품 개발 Planning은 build, test, release gate, 사용자-facing claim을 봅니다. 회사 작업 Planning은 내부 원문과 실행 권한의 경계를 봐야 하지만, 그 원문이 개인 위키로 들어오면 안 됩니다.

즉 공유되는 것은 역할의 언어입니다. 분리되는 것은 데이터, 계정, 권한, 실행 표면입니다.

이 차이를 닫지 않으면 하네스는 금방 애매해집니다. 같은 agent가 같은 이름의 역할로 움직이더라도, 어느 문맥에서 무엇을 읽고 무엇을 쓰면 안 되는지가 고정되어 있지 않으면 경계는 대화 안에서 흐려집니다.

shared-agent-harness는 모든 실행의 중심이 아닙니다

공용 하네스 저장소를 만들 때 가장 조심해야 했던 점은 중앙집중화였습니다.

공용이라는 말은 모든 것을 한곳으로 모은다는 뜻이 아닙니다. 오히려 각 저장소가 자기 책임을 더 잘 지키도록 공통 언어만 제공한다는 뜻에 가깝습니다.

공용 하네스가 맡을 수 있는 것은 이런 것들입니다.

• 역할과 lane의 이름
• review와 validation의 기준
• decision-ready queue의 모양
• playbook과 template의 형식
• 실행 권한을 열기 전의 gate 언어

반대로 공용 하네스가 소유하면 안 되는 것도 있습니다.

• 개인 글의 source-of-truth
• 사이트 runtime artifact
• 회사 원문과 내부 evidence
• 저장소별 오류 기록의 실제 항목
• 외부 실행 승인과 감사 기록

이 구분을 두면 shared-agent-harness는 중앙 오케스트레이터가 아니라 공통 언어가 됩니다. 각 저장소는 그 언어를 빌려 자기 문맥 안에서 실행합니다.

Bounded Context 관점으로 보면, 공용 하네스는 모든 context를 하나로 합치는 모델이 아닙니다. 여러 context가 서로 알아들을 수 있게 하는 published language에 더 가깝습니다.

Playbook은 owning repo에 남아야 했습니다

이번에 작은 사례가 하나 있었습니다.

공용 engineering error playbook skill은 이미 있었습니다. 그런데 이 저장소에는 실제로 scan하고 update할 repo-local docs/development-error-playbook.md가 없었습니다. 그래서 ERR-20260613-001로 repo-local error playbook adoption gap을 기록했습니다.

이 사례가 중요한 이유는 playbook의 위치를 보여주기 때문입니다.

공용 하네스는 playbook의 형식과 원칙을 줄 수 있습니다. 하지만 실제 오류 항목은 그 오류가 발생한 owning repo에 남아야 합니다. 그래야 다음에 같은 저장소에서 비슷한 문제가 생겼을 때, agent가 그 저장소 안에서 먼저 검색하고 같은 실수를 반복하지 않을 수 있습니다.

만약 모든 오류 기록을 공용 하네스에 모으면 겉으로는 깔끔해 보일 수 있습니다. 하지만 어떤 오류가 어느 문맥에서 의미 있는지 흐려집니다. 개인 위키 publish 오류와 사이트 build 오류와 회사 approval 오류는 같은 ERR-* 형식을 쓸 수 있지만, 같은 evidence surface에 놓이면 안 됩니다.

그래서 이번 playbook 사례는 단독 방법론 글로 키우지 않습니다. 더 큰 결론은 이것입니다.

형식은 공유하고, 실제 기록은 소유 저장소에 남깁니다.

회사 적용 내용은 구조만 남겨야 했습니다

여러 저장소 운영 구조를 공개 글로 기록할 때는 한 가지 경계가 더 필요했습니다.

개인 프로젝트 구조는 비교적 직접 설명할 수 있습니다. 하지만 회사 쪽 작업은 다릅니다. 내부 원문, source trace, review record, test evidence, credentials, issue key, screenshot은 공개 글이나 개인 위키에 들어오면 안 됩니다.

그래서 공개 글에서는 회사 쪽 저장소를 세부 이름과 실제 적용 내역으로 설명하지 않고, 구조로만 설명해야 합니다.

예를 들면 이렇게 바꿔야 합니다.

공개 글에서 다룰 수 있는 표현	공개 글에서 피해야 하는 표현
회사 authoring source	실제 업무 원문과 내부 요구사항
approval and audit surface	승인 기록 원문과 실행 로그
private analysis workspace	민감 분석 자료와 source trace
sanitized queue summary	내부 ticket, payload, screenshot

이렇게 추상화하면 글의 가치가 사라지는 것이 아닙니다. 오히려 더 보편적인 구조가 보입니다. 회사 작업의 디테일이 아니라, 여러 문맥을 섞지 않기 위한 운영 원칙을 설명할 수 있기 때문입니다.

경계가 닫혀야 queue도 의미가 있습니다

최근에는 Peter Steinberger식 maintainer loop를 보면서 decision-ready queue도 적용했습니다.

그 방식의 핵심은 AI worker를 많이 돌리는 것이 아니라, owner에게 올라오는 질문의 모양을 줄이는 데 있었습니다. raw status를 그대로 넘기는 대신, 쉬운 한글 설명, 근거, 위험, 다음 결정을 작은 queue로 압축하는 방식입니다.

하지만 queue는 경계가 닫힌 뒤에야 의미가 있습니다.

어떤 저장소가 어떤 문맥인지 모른다면, queue도 위험해집니다. 개인 블로그 publish queue와 사이트 deploy queue와 회사 approval queue가 같은 언어를 써도, 같은 evidence와 같은 권한으로 움직이면 안 됩니다.

그래서 이번 글의 결론은 queue가 아니라 그 앞의 경계입니다.

같은 역할을 공유할 수 있습니다. 하지만 같은 역할이 항상 같은 context에서 실행되는 것은 아닙니다. 하네스는 agent를 많이 만드는 장치가 아니라, 역할이 닿는 문맥을 닫는 장치입니다.

다음 글에서는 이 경계 위에서 owner가 덜 피곤하게 판단할 수 있는 queue 표면을 어떻게 보여줄지 다룹니다.