제대로 된 Kanban board라면 결정 사항을 다음 작업자에게 넘겨야 합니다. 하위 worker는 상위 작업의 결과를 받아야 하고, 재시도에는 이전 실패가 남아야 합니다. 검토 과정도 막연한 comment가 아니라 추적 가능한 run으로 기록되어야 하죠.
- Hermes Kanban은 task와 run을 SQLite에 영속적으로 저장합니다.
- Parent task가 끝나기 전에는 child task를 실행하지 않습니다.
- 같은 카드의 검토는 review와 change-request 전이를 사용합니다. 외부 개입이 필요할 때만 block합니다.
- Dispatcher worker는
kanban_*도구를 호출합니다. CLI는 사람과 모델 실행 밖의 자동화가 사용합니다.
1. 오래 이어지는 작업에 Kanban 선택하기
delegate_task는 짧은 parent-child 호출에 맞습니다. 여러 profile을 거치거나 재시작 뒤에도 남아야 하는 작업, 검토가 필요하거나 사람의 판단을 기다릴 수 있는 작업에는 Kanban이 맞습니다. Task는 todo, ready, running, review, blocked, done을 거치며, 각 시도는 run history에 남습니다.
Board 자체도 격리 경계입니다. 이름을 붙인 board마다 SQLite 파일, workspace, log가 나뉩니다. 이 편의 fixture도 호출자가 지정한 경로에 독립 데이터베이스 하나를 만듭니다.
2. 의존성과 handoff 모델링하기
끝나지 않은 parent가 있는 child는 todo에 머뭅니다. 모든 parent가 완료되면 ready로 승격됩니다. 완료 summary와 metadata는 child의 구조화된 context가 됩니다. 다음 agent가 긴 대화 기록에서 결정을 다시 추측하게 하는 것보다 안전한 전달 방식입니다.
막힌 task를 풀기 위해 만든 지원 task를 그 task의 child로 연결하면 안 됩니다. 의존성 방향이 뒤집혀 두 카드가 함께 멈출 수 있습니다.
3. Review와 block 구분하기
같은 카드의 review 흐름은 구현, 검토 요청, 수정 요청, 재검토 요청, 승인 순서입니다. 구현과 검토 시도가 한 카드에 계속 쌓입니다. 일반적인 검토 의견에는 kanban_block을 쓰지 않습니다. 외부 결정, 접근 권한, 사용할 수 없는 인프라처럼 작업자가 해결할 수 없는 원인에 사용합니다.
별도 reviewer child 카드를 만드는 방식도 가능합니다. 한 검토 단계에는 한 모델만 선택하세요. 두 방식을 섞으면 같은 결과물에 review lane이 두 개 생깁니다.
4. 재시도 횟수 제한하기
일시적인 실패가 발생하면 task는 ready로 돌아갑니다. 재시도 한도에 도달하면 blocked가 되어 자동 반복을 멈춥니다. 원인을 해결한 뒤 사람이 unblock할 수 있습니다. 이전 오류는 다음 시도에도 남으므로 worker가 같은 동작을 반복하지 않고 전략을 바꿀 수 있습니다.
Hermes는 worker spawn이 연속으로 실패할 때 circuit breaker를 적용합니다. Fixture는 같은 제한 규칙을 결정적인 로컬 연산에 적용해 네트워크 없이 반복 실행할 수 있게 했습니다.
5. 격리된 board 실행하기
cd examples/chapter-11-kanban-collaboration
python3 board.py --db board.db --reset
python3 -m unittest discover -s tests -vJSON snapshot에는 의존성 승격, verifier의 실패와 성공 시도, writer와 reviewer의 순서가 들어 있습니다. 데이터베이스는 삭제 가능한 로컬 상태입니다. 테스트는 시작하지 않은 task를 완료하려 하면 거부되는지도 확인합니다.
6. Hermes 환경에 적용하기
운영자는 실제 board를 hermes kanban init, hermes kanban create, hermes kanban show, hermes kanban watch로 만들고 살펴봅니다. 할당된 worker는 이 명령을 shell에서 실행하지 않습니다. Dispatcher가 제공하는 kanban_show, kanban_heartbeat, kanban_request_review, kanban_request_changes, kanban_complete 같은 board 범위 도구를 사용합니다.
Summary에는 변경 파일, 테스트, 결정 사항, 남은 제약을 구체적으로 적습니다. Commit이 있다는 이유만으로 task가 완료되지는 않습니다. Task의 acceptance contract를 충족한 뒤 완료해야 합니다.
7. Fixture의 경계 이해하기
이 예제는 lifecycle 의미를 검사합니다. Hermes dispatcher process, profile 구성, messaging gateway는 실행하지 않습니다. 작은 schema는 Hermes 내부 데이터베이스 schema의 복사본도 아닙니다. 운영에서는 Hermes 명령과 도구를 사용하고, fixture가 Hermes board 파일을 열게 하지 마세요.
다음 편에서는 의존성, 재시도, 검토, 사람 승인, Git, 전송 경계를 자격 증명 없는 capstone 하나로 조립합니다.
답글 남기기