리포지토리 아키타입

에이전트는 단 한 줄의 코드를 변경하기 전에, 이후의 모든 것을 결정짓는 하나의 판단을 내립니다. 이것은 어떤 종류의 리포지토리인가? 에이전트가 추론하는 아키타입이 나머지 작업 전반에 걸쳐 추론할 경계를 설정합니다. 어떻게 온보딩할지, 계획이 어디까지 미칠지, 그리고 상태가 어디에 기록될지를 결정합니다. 잘못 판단하면 에이전트는 작업 범위를 잘못된 대상에 맞추게 되는데, 이것이 장기 작업에서 드리프트가 발생하는 가장 흔한 원인입니다. 올바르게 판단하면 계획, 온보딩, 상태가 모두 코드의 실제 형태와 일치하기 때문에 수 시간 동안 자율적으로 실행할 수 있습니다.

DWP는 세 가지 아키타입을 인식합니다. 대부분의 리포지토리는 첫 번째에 해당하고, 두 번째는 여러 리포지토리를 조율하는 팀을 위해 존재하며, 세 번째는 자율 에이전트의 장기 실행 작업 공간을 다룹니다.

개별 저장소

자족적인 단일 코드베이스

오케스트레이터 허브

하위 저장소를 조정해요

개별 리포지토리

일반적인 경우: 자기 완결적 코드베이스 — 애플리케이션, 라이브러리, 또는 서비스. 추론할 하나의 일관된 대상이 있으므로 계획은 리포지토리의 코드에 직접 작용하고, 온보딩은 리포지토리 자체의 구조와 관례를 읽습니다. 에이전트는 전체 코드베이스를 컨텍스트로 보유하고 처음부터 끝까지 작업합니다.

특성:

• 하나의 일관된 코드베이스.
• 계획이 이 리포지토리의 파일을 수정합니다.
• .dwp/ 작업 공간이 리포지토리 루트에 있습니다.

오케스트레이터 허브

조율 역할을 하는 경우: 다른 리포지토리를 관리하는 것이 역할인 리포지토리. 여기서 작업 단위는 파일이 아니라 하위 리포지토리이므로, 계획이 하위 리포지토리에서 하위 계획을 생성할 수 있고, 온보딩은 단일 코드베이스가 아니라 허브의 관리 대상 리포지토리 레지스트리를 읽습니다. 에이전트는 경계와 인계를 추론합니다. 어느 리포지토리가 어느 작업을 소유하는지, 그리고 그 상태가 어떻게 일관성을 유지하는지를 판단합니다.

특성:

• 여러 하위 리포지토리를 조율합니다.
• 계획이 하위 계획에 위임할 수 있습니다.
• 관리 대상 리포지토리의 레지스트리를 유지합니다.
• 허브 루트의 .dwp/ 작업 공간이 리포지토리 간 상태를 추적합니다.

에이전트 작업 공간

v2.2에서 추가된 세 번째 아키타입은 리포지토리이기 전에 작업 공간인 것을 설명합니다: 자율 에이전트의 장기 실행 홈. OpenClaw 작업 공간, Hermes 서비스 디렉터리, 개인 비서 데몬의 데이터 디렉터리, 클라우드 에이전트의 영속 볼륨 — 각각 실행할 계획, 사용할 도구, 유지할 메모리가 있지만, 출시할 코드베이스는 없을 수 있습니다.

핵심 통찰은 하니스가 리포지토리가 아닌 작업 공간이라는 것입니다. DWP가 리포지토리에 설치하는 모든 요소 — AGENTS.md, docs/, .agents/, .dwp/ — 에는 직접 작업 공간 등가물이 있습니다. 방법론의 표면이 깔끔하게 매핑됩니다: 상시 컨텍스트 파일이 루트 AGENTS.md를 대체하고, 플랫폼 스킬 디렉터리가 .agents/를 대체하며, 작업 공간 루트의 .dwp/ 폴더는 변경이 없습니다. 변경되는 것은 git의 역할입니다. 리포지토리에서는 git 로그가 상태를 담고 계획을 세션 간에 재개 가능하게 합니다. git이 없는 작업 공간에서는 state.json이 그 역할을 합니다 — 이것이 기계 가독 상태 레이어가 에이전트 작업 공간에 필수인 이유입니다.

실질적 이점은 야간 무인 계획입니다. OpenClaw 클래스 플랫폼에서는, 하트비트 또는 크론 턴이 에이전트를 깨우고, DWP 재개 프로토콜을 실행하고, 다음 원자적 작업을 실행하고, state.json을 갱신하고, 양보합니다. 계획이, 세션이 아니라, 연속성의 단위입니다. 다중 일 계획이 재시작, 모델 교체, 세션 경계에서 살아남습니다. 다음 턴이 필요한 모든 것이 계획 파일에 있기 때문입니다: 목표, 체크된 진행 상황, 게이트 기록, 현재 작업 내의 정확한 체크포인트.

특성:

• 자율 에이전트 플랫폼의 작업 디렉터리.
• 작업 공간 루트에 AGENTS.md, .agents/, .dwp/.
• Git은 필수가 아닌 권장.
• git이 없을 때, 그리고 모든 무인 실행에 state.json 필수.
• 계획은 일반적으로 예약된 하트비트 또는 크론으로 무인 실행됨.

분류 휴리스틱

세 아키타입은 디스크 위에서 다르게 보이며, 에이전트는 전달받은 레이블이 아니라 스스로 검증할 수 있는 신호를 바탕으로 결정합니다. 아래 의사결정 트리가 그 경로를 보여줍니다. 요약하자면, 플랫폼 식별 신호가 있을 때 에이전트 작업 공간으로 분류하고, 증거가 요구할 때에만 오케스트레이터 허브로 분류하며, 그렇지 않으면 개별 리포지토리로 분류하십시오.

저장소

? 중첩된 여러 저장소인가요, 아니면 허브 레지스트리인가요?

아니요

개별 저장소

• 단일 코드베이스
• 계획이 로컬 파일을 수정해요
• .dwp/ 가 저장소 루트에 있어요

예

오케스트레이터 허브

• 하위 저장소를 조율해요
• 계획이 하위 계획에 위임해요
• 저장소 간에 .dwp/ 상태를 공유해요

에이전트는 먼저 에이전트 작업 공간 신호를 찾아야 합니다: 플랫폼 식별 파일(OpenClaw의 SOUL.md 또는 HEARTBEAT.md 등), 주요 애플리케이션 스택 없음, 주로 에이전트 자체 상태인 콘텐츠. 그것이 없으면, 오케스트레이터 신호를 찾습니다: 여러 중첩된 git 리포지토리 또는 서브모듈, 관리 대상 리포지토리의 레지스트리 또는 매니페스트, 외부 리포지토리를 가리키는 설정. 둘 다 없으면, 대상을 개별 리포지토리로 취급합니다 — 안전한 기본값. 존재하지 않는 경계를 넘어 계획 범위를 과도하게 설정하는 것은, 실제로 존재하는 경계 안에서 작업하는 것보다 더 나쁜 결과를 낳기 때문입니다.

온보딩이 달라지는 방식

아키타입은 단순한 장식적 레이블이 아닙니다. 에이전트가 읽는 것, 계획이 건드릴 수 있는 것, 그리고 상태가 기록되는 위치를 바꿉니다.

실질적인 효과는, 개별 리포지토리 에이전트는 하나의 코드베이스를 처음부터 끝까지 추론하고, 오케스트레이터 에이전트는 리포지토리 간 조율을 추론하며, 에이전트 작업 공간 에이전트는 세션 간 연속성을 추론한다는 것입니다 — 무엇이 계획되었는지, 무엇이 실행되었는지, 무엇이 차단되었는지, 다음은 무엇인지를 말입니다.

이것이 에이전트가 감독 없이 여러 시간 동안 자율적으로 일할 수 있게 해주는 것입니다. 아키타입을 먼저 고정함으로써 계획, 온보딩, 상태를 올바른 경계로 한정하므로, 에이전트는 첫 작업부터 마지막 작업까지 올바른 표면에서 동작합니다.