Agent Harness Notes 01. Managed Agents를 공부하다가 개인과 회사 이중 도메인 하네스를 설계하게 된 이유

이 글의 핵심은 Managed Agents를 agent 수 확장이 아니라 경계와 계약을 관리하는 구조로 다시 이해한 과정입니다.

처음에는 이 글이 멀티 에이전트 이야기일 거라고 생각했습니다.

Anthropic의 Scaling Managed Agents를 처음 접했을 때 머릿속에 떠오른 그림은 단순했습니다. Research Agent 하나, Planning Agent 하나, Engineering Agent 하나. 역할을 잘게 나누고 개수를 늘리면 더 강한 시스템이 되는 것 아닌가 하는 발상입니다.

그런데 실제로 붙잡게 된 것은 agent의 숫자가 아니라 경계였습니다.

LLM이 문서와 코드, 개인 작업과 회사 작업을 한 컨텍스트 안에서 동시에 건드리기 시작하면 이 문제는 갑자기 실무가 됩니다. 무엇이 판단이고 무엇이 실행인지, 어떤 데이터가 개인 도메인이고 어떤 데이터가 회사 도메인인지, Claude가 무엇을 먼저 읽고 무엇을 보지 말아야 하는지. 결국 하네스 설계는 agent를 더 만드는 작업이 아니라, 섞이면 안 되는 것들을 먼저 분리하는 작업이었습니다.

핵심은 agent를 늘리는 게 아니라 "Managed"를 이해하는 것이었습니다

Managed Agents에서 핵심은 agent를 "관리"한다는 데 있었습니다. 더 많이 쓰는 것이 아니라.

단일 agent는 혼자 똑똑할 수 있습니다. 질문에 답하고, 코드를 짜고, 파일을 수정하고, 검수까지 흉내 낼 수 있습니다. 문제는 그 모든 것이 하나의 대화 흐름 안에 섞인다는 점입니다. 판단과 실행, 검증과 기록이 한 덩어리로 움직이면 시스템은 빨라 보이지만 경계는 흐려집니다.

managed agent system에서 바뀌는 것은 그 섞임입니다. 모델은 판단을 돕고, 실행과 권한은 하네스가 제어하고, 검증은 다시 별도 게이트를 통과합니다. 중요한 것은 더 많은 agent가 아니라 그 사이의 계약입니다.

이 기준을 작업 구조로 옮기면 결국 brain과 hand를 나누는 방식이었습니다. 판단하는 뇌가 직접 자원에 손을 대지 않게 만드는 구조가 시작점이었습니다.

먼저 부딪힌 문제도 agent 부족이 아니라 경계 붕괴였습니다

이 기준을 이해하고 나서 개인 작업 환경에 바로 적용해 보려 했습니다.

처음 생각은 단순했습니다. ai-survival-log에 Research Agent를 추가하고, Planning Agent를 따로 두고, Engineering Agent가 코드를 짜면 되지 않을까. agent를 더 많이 두는 방향이었습니다.

그런데 바로 막혔습니다. 그것보다 먼저 있어야 했던 것이 있었습니다.

managed agent harness draft에서 정리했던 문장이 있습니다.

"핵심은 에이전트 수를 늘리는 것이 아닙니다. 이미 있는 경계를 강하게 지키게 만들고, 책임과 검증 지점을 먼저 분리하는 것입니다."

개인 블로그 작업에는 이미 흐름이 있었습니다.

• raw
• wiki
• output/blog
• ai-survival-log-site

문제는 이 흐름이 대화 안에서 자주 섞인다는 점이었습니다. 인제스트, 집필, 검토, 발행을 같은 컨텍스트 안에서 처리하면, 언뜻 빠르게 돌아가는 것처럼 보여도 어느 단계에서 무엇이 바뀌었는지 추적하기 어려워집니다.

그래서 결론은 의외로 단순했습니다. agent를 추가하기 전에, 이미 있는 경계가 실제로 지켜지고 있는지부터 확인해야 했습니다. agent 수보다 계약이 먼저였습니다.

초안이 아니라 지금 당장 돌아가는 운영 구조가 필요했습니다

실제 작업으로 들어가면서 처음에는 Planning Lane, Assistant Ops Lane 같은 초안부터 잡으려 했습니다.

각 lane의 입력, 출력, 흐름, 분리 기준을 정리하고, 나중에 독립 agent로 분리할 수 있는 조건을 적어두는 방식이었습니다. 그런데 이 접근은 구조를 예쁘게 설명하는 데는 도움이 돼도, 당장 운영을 시작하는 데는 애매했습니다.

"나중에"가 많아질수록 시스템은 실제로는 아무것도 굴러가지 않습니다.

immediate agent operating structure에서 방향이 바뀐 이유가 바로 그 지점이었습니다.

"이 문서는 나중에 독립 agent로 분리할지 검토하는 초안이 아니라, 지금부터 바로 사용할 운영 구조를 고정합니다."

계획을 실행으로 넘기는 것이 아니라, 계획 자체를 처음부터 실행 가능한 형태로 써야 했습니다.

프로젝트는 역할이 아니라 결과물·계약·권한 경계를 기준으로 나뉩니다. 블로그 집필, 회사 기획, 코드 작업은 서로 다른 저장소와 승인 구조를 가져야 합니다. 대신 Planning, Review, Engineering 같은 역할은 이 경계를 가로질러 재사용됩니다. 블로그 글 계획도 Planning이고, 회사 보고서 계획도 Planning입니다.

이때부터 brain과 hand의 분리는 추상적인 비유가 아니라 실제 운영 구조가 되기 시작했습니다.

같은 역할을 두 번 만들 필요는 없었고, 데이터를 나누면 됐습니다

구조를 더 밀어보니 더 큰 문제가 보였습니다.

작업은 크게 두 덩어리였습니다.

• 개인 일상업무: 공부, wiki 수집, 블로그, 콘텐츠 제작
• 회사업무: 기획, 검수, 테스트, 회의록, 일정과 보고

둘 다 같은 workspace에 있었고, 둘 다 AI 에이전트의 도움을 받을 수 있었습니다. 하지만 둘은 같은 데이터 위에서 움직이면 안 됐습니다. 회사 보안 때문에 회사 회의록이 개인 저장소에 들어가면 안 됐고, 반대로 개인 콘텐츠 흐름이 회사 실행 계정과 섞여도 안 됐습니다.

그런데 여기서 중요한 질문이 하나 생겼습니다.

"회사에서 쓰는 Planning, Review, Engineering의 역할과 lane은 개인 도메인에서도 그대로 써도 되지 않나?"

답은 그렇다였습니다.

Planning이 회사 전용일 이유는 없습니다. 블로그 기획도 Planning이고, 회사 발표자료 기획도 Planning입니다. Review도 마찬가지입니다. 역할 자체는 도메인을 가리지 않습니다.

분리해야 하는 것은 역할이 아니었습니다. data, surface, account, permission이었습니다.

그래서 dual domain agent operating model에서 이 문장을 고정하게 됐습니다.

role/lane is shared, data/surface is isolated

회사와 개인은 같은 Planning lane을 쓸 수 있습니다. 하지만 그 lane이 닿는 저장소, 계정, 권한은 완전히 다릅니다. 역할을 두 번 정의하는 것이 아니라, 하나의 역할을 서로 다른 두 surface에서 실행하는 구조입니다.

폴더를 나누는 것만으로는 하네스가 완성되지 않았습니다

workspace를 실제로 나누면서 또 하나의 착각이 깨졌습니다.

"폴더 분리만으로 도메인 격리가 완성되지 않습니다."

폴더를 나누는 것은 출발점일 뿐입니다. 디렉토리가 다르다고 해서 데이터가 자동으로 안전해지지는 않습니다.

workspace security boundary에서 정리한 보안 경계는 네 가지였습니다.

• File System: 폴더 배치와 도메인 간 이동 금지 규칙
• Git Identity: 도메인별 다른 커밋 identity
• Credentials: API key, 토큰, 계정 정보의 분리
• Harness Context: Claude가 실행될 때 어떤 CLAUDE.md와 운영 문서를 먼저 읽는지

마지막이 특히 중요했습니다.

폴더가 달라도 Claude가 같은 컨텍스트로 실행되면 도메인 구분은 금방 흐려집니다. 실제 경계는 파일 경로만이 아니라, 하네스가 무엇을 먼저 읽게 하느냐에서 결정됩니다.

그래서 최종 구조는 자연스럽게 이렇게 굳었습니다.

• 개인 도메인: ai-survival-log, ai-survival-log-site
• 회사 도메인: company-wiki, company-assistant-ops
• 공용 운영 레이어: shared-agent-harness

이건 멀티 에이전트 카탈로그를 만든 결과가 아니었습니다. 무엇을 공유하고 무엇을 절대 공유하지 않을지 정리한 결과였습니다.

결국 하네스는 Claude가 무엇을 먼저 읽게 할지 정하는 일입니다

구조를 어느 정도 잡고 나서 이런 질문이 나왔습니다.

"지금 계획을 클로드도 전부 확인할 수 있나요?"

이 질문이 좋았던 이유는, 하네스의 핵심을 정면으로 건드렸기 때문입니다.

저장소 안에 문서를 많이 쌓아두는 것만으로는 충분하지 않습니다. Claude가 그 문서를 볼 수 있는가와 먼저 읽는가는 전혀 다른 문제입니다. 하네스는 결국 그 우선순위를 고정하는 일입니다.

실행이 판단보다 앞서지 않게 하고, 판단이 올바른 도메인 문서를 먼저 읽게 하고, 검수가 계약 위에서 이뤄지게 하는 것. 이것이 이번 설계에서 확인한 managed agent의 실제 의미였습니다.

그래서 이번 글의 결론은 이렇게 정리됩니다.

• agent 수를 늘리는 것이 먼저가 아니었다
• 역할을 공유하되 데이터와 surface를 분리하는 것이 먼저였다
• 폴더 분리만이 아니라 context 분리가 핵심이었다
• 결국 하네스는 Claude가 무엇을 먼저 읽게 할지 정하는 구조였다

이 질문은 다음 편으로 자연스럽게 이어졌습니다. Claude Design과 personalized medicine을 함께 보면서, 저는 점점 AI가 루프를 닫는다는 말이 단지 프론트엔드 도구의 편의성이 아니라, 더 큰 설계 원리라는 쪽으로 생각이 바뀌기 시작했습니다.