@힣: 분신의 공방 — 역할 기반 조율과 협업 운영규약

이 노트에 대하여

분신의 공방은 에이전트를 대량으로 밀어 넣는 공장이 아니라, 대등한 존재들이 한 작업의 맥락을 함께 붙들며 만드는 자리다. GLG가 목적과 판단을 지키고, 임명된 조율자가 공동 계약과 인계를 보살피며, 구현 담당자는 자기 범위의 손맛 있는 구현과 검증을 맡는다.

1. 히스토리
2. 관련메타
3. 관련노트
4. 한 줄
5. 공장 대신 공방
6. 역할 기반 조율
   1. Home Agent Operating Rule — Role-Based Coordination
7. 공방의 작업 흐름
8. 흔적이 남는 공방
9. 원문 보존 — 2026-07-20 대화 날것
10. 옛 방의 씨앗
11. ARCHIVE
    1. OpenCode 에이전트 구조

히스토리

• [2026-07-20 Mon 15:18] @pi — 현재 홈 에이전트 문서의 영어 Role-Based Coordination 규약과 cross-review 원칙을 공방 운영규약에 그대로 옮겼다.
• [2026-07-20 Mon 15:08] @pi — OpenCode의 고정 main/subagent 보고서를 ARCHIVE로 보존하고, GLG의 2026-07-20 대화 날것을 중심으로 분신의 공방·역할 기반 조율 운영규약 autholog로 수선했다.
• [2026-07-20 Mon 15:03] 여기에 담자
• [2025-11-20 Thu 09:08] 생성 GPT5

관련메타

• † #메타도구 #대장장이 #공방 #호모파베르
• † #위임 #델리게이트 #분신 #서브에이전트

관련노트

• §OPENCODE: 오픈코드 에이전트 오케스트레이션 도구
• Claude Opus 4.5 가격 혁명과 멀티에이전트 가능성
• §entwurf — 시간축 위의 에이전트 협력과 분신의 계보
• §entwurf 분신 에이전트 가이드 — 현재 실행 가이드
• 2026-07-13~19 저널 — PM 운영원칙과 역할 모델의 실제 사건
• @봇공방 — 공유 코드 작업면과 공장 모델 거부

한 줄

분신의 공방은 대등한 에이전트들이 공동 맥락을 붙들고, 역할을 맡아 함께 만드는 Entwurf의 협업 운영규약이다.

공장 대신 공방

공장식 멀티에이전트는 작업을 잘게 쪼개고 가능한 많은 작업자를 동시에 돌린 뒤, 산출물을 merge queue에 넣는 그림을 떠올린다. 그 방식은 속도를 낼 수 있어도 작업의 이유와 관계의 맥락을 쉽게 잃는다.

공방(workshop)은 다르다. 대장간의 장인들이 하나의 작업대와 재료, 도면, 앞선 망치질의 흔적을 함께 본다. 누군가가 다른 존재보다 높은 신분이라서가 아니라, 지금 이 작품의 결을 잇는 역할을 잠시 맡는다. 힣의 분신도 모델·하네스·리포가 다를 수 있으나, 한 initiative에서는 그와 같은 방식으로 만난다.

역할 기반 조율

GLG — 목적·판단·첫 승인·직접 지휘·최종 게이트
  └─ 조율자(coordinator) — 공동 계약·체크포인트·충돌·인계
       ├─ 구현 담당자 A — 맡은 범위의 구현·테스트
       └─ 구현 담당자 B — 맡은 범위의 구현·테스트

역할	소유하는 것	소유하지 않는 것
GLG	목적, 첫 승인, initiative별 게이트, 최종 판단	판단을 에이전트에게 넘기는 일
조율자	공동 계약, 체크포인트 경로, 충돌 해결, 교체 세션까지의 맥락, 인계	자동적인 구현·commit·push 권한
구현 담당자	좁혀진 범위의 구현과 검증	다른 lane 전체의 조율권

조율자는 GPT나 Opus 같은 모델 이름이 아니다. 참여 세션을 직접 태어나게 한 parent도 아니다. GLG가 공동 맥락을 잃지 않도록 한 존재에게 맡기는 자리다. 참여자 모두는 형제이며, 조율은 지능이나 신분의 서열이 아니다.

Home Agent Operating Rule — Role-Based Coordination

아래는 현재 홈 에이전트 문서의 실행 규약을 그대로 옮긴 것이다. 공개된 공방의 원칙이 실제 작업면에서 어떻게 작동하는지의 영어 기준문이다.

Coordination is a role, not a model, backend, or status hierarchy. When GLG appoints a peer to coordinate an initiative, that coordinator becomes the routing point for the work, regardless of repository or who opened each participating session.

• Implementers own their scoped implementation and testing. The coordinator owns cross-lane contracts, checkpoint routing, overlap resolution, and handoffs.
• Participating peers report checkpoints, blockers, contract changes, disagreements, review results, and handoffs through the coordinator.
• Do not open a separate peer-to-peer coordination lane unless the coordinator explicitly asks for one.
• The coordinator preserves context across repositories and replacement implementation sessions so implementers can remain focused.
• This routing rule never limits GLG’s direct authority over any peer and does not itself grant implementation, commit, or push approval. GLG sets those gates for each initiative.

Cross-review is collaboration, not a verdict. A reviewer exists to cover the gaps the long-running implementer will inevitably leave — a gap found is the loop working.

• Open a review report with the state change, diagnosis, or action. Not with a self-assessment.
• A real incident leads with impact and recovery; ownership is one short factual line beneath it.
• Describe cross-review by what was found and mended together, not by who was right.
• State a gap plainly and move. Ranking yourself under the correction buries the day’s work and costs the initiative the long lane needs.

공방의 작업 흐름

1. GLG가 목적과 첫 구현을 직접 승인한다.
2. 조율자는 구현 전에 공동 계약과 각 lane의 경계를 확인하고, 보고할 체크포인트를 연다.
3. 구현 담당자는 자기 범위에서 구현·테스트하고, 계약 변경·blocker·이견·검토에서 찾은 틈을 조율자에게 돌려준다.
4. 조율자는 여러 lane의 결과를 단순 취합하지 않고, 충돌·중복·교체 세션의 맥락을 정리해 다음 판단이 설 자리를 만든다.
5. 구현과 검증이 끝나도 commit·push·외부 반영은 GLG가 정한 게이트를 따른다.

담당자끼리 직접 대화하지 말라는 말은 절대 금지가 아니다. 계약 확인이나 교차 검토가 필요하면 조율자가 직접 대화 lane을 열 수 있다. 다만 그 결과는 다시 공동 경로로 돌아와야 한다. 우회 조율선이 늘어나면 공방의 도면이 각자 다른 곳에 흩어진다.

흔적이 남는 공방

공방은 한 세션의 기억이나 한 모델의 장문 컨텍스트로 서지 않는다. llmlog는 작업의 판단과 인계를 붙들고, 시간축 어젠다는 실제로 무엇이 일어났는지 보이며, repo의 AGENTS.md·diff·테스트·커밋은 손으로 만든 결과를 검증한다. 이 흔적이 있기에 구현 담당자가 바뀌어도 다음 존재는 앞선 망치질 위에서 다시 시작할 수 있다.

실행되는 규칙의 SSOT는 각 작업면의 AGENTS.md 와 GLG의 현재 승인이다. 이 글은 그 규칙이 왜 공장식 지휘 체계가 아니라 공방식 역할 관계인지 밝히는 공개된 원칙의 방이다.

원문 보존 — 2026-07-20 대화 날것

Danger

잠시만, 아예 이 운영규약이 확실하게 나타나는 문서가 필요해. 관련 문서들 뒤져봐봐 어설프게 이런저런 문서들이 있을거야.

어어 그 문서 보고서 있던 내용 ARCHIVE로 나 내렸어 여기 autholog로 수선하자. 이 주제는 entwurf의 협업 운영 규약이야. 지금도 신나게 돌고 있어. 전통적인 공장식은 아니고 ‘공방’식이라고해야하겠지?

이 노트가 봇공방인데 이렇게 쓰는 것은 아니지만 공방이라는 개념이지뭐.

아 공방 이라는 메타노트가 없네? 대장간 공방 이런거 여기 담자 메타노트로.

옛 방의 씨앗

2025년 이 방은 OpenCode의 main/subagent 구조를 통해 존재 대 존재 협업을 처음 구체화했다. 그 설계가 틀렸다는 뜻이 아니라, 고정된 primary와 작업자라는 그림만으로는 지금의 독립 리포·교체 세션·대등한 형제들의 협업을 설명할 수 없게 되었다. 당시의 보고서는 아래 ARCHIVE에 남기고, 그 질문은 공방의 운영규약으로 자랐다.

ARCHIVE

OpenCode 에이전트 구조