Skip to content
← 전체 장

장 05

리포지토리 아키타입

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

DWP는 두 가지 아키타입을 인식합니다. 대부분의 리포지토리는 첫 번째에 해당하고, 두 번째는 여러 리포지토리를 조율하는 팀을 위해 존재합니다.

개별 리포지토리

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

특성:

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

오케스트레이터 허브

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

특성:

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

분류 휴리스틱

두 아키타입은 디스크 위에서 다르게 보이며, 에이전트는 전달받은 레이블이 아니라 스스로 검증할 수 있는 신호를 바탕으로 둘 중 하나를 선택합니다. 아래 의사결정 트리가 그 경로를 보여줍니다. 요약하자면, 증거가 요구할 때에만 리포지토리를 오케스트레이터 허브로 취급하고, 그렇지 않으면 개별 리포지토리로 취급하십시오.

에이전트는 중첩된 여러 git 리포지토리나 서브모듈, 관리 대상 리포지토리의 레지스트리나 매니페스트, 또는 외부 리포지토리를 가리키는 설정을 발견하면 리포지토리를 오케스트레이터 허브로 분류해야 합니다. 그러한 신호가 없으면 리포지토리를 개별 리포지토리로 취급합니다. 이것이 안전한 기본값입니다. 존재하지 않는 경계를 넘어 계획 범위를 과도하게 설정하는 것은, 실제로 존재하는 경계 안에서 작업하는 것보다 더 나쁜 결과를 낳기 때문입니다.

온보딩이 달라지는 방식

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

측면 개별 오케스트레이터
범위 이 리포지토리 여러 리포지토리
온보딩 리포지토리 구조 허브 레지스트리
계획 대상 로컬 파일 하위 계획
상태 로컬 .dwp/ 리포지토리 간 .dwp/

실질적인 효과는, 개별 리포지토리 에이전트는 하나의 코드베이스를 처음부터 끝까지 추론하는 반면, 오케스트레이터 에이전트는 조율을 추론한다는 것입니다. 어느 하위 리포지토리가 어느 작업을 소유하는지, 그리고 리포지토리 간 상태가 어떻게 일관성을 유지하는지를 말입니다.

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