[🛠] 코디네이터와 워커를 실제로 연결해봤다

✨ GPT-5.6 Sol의 요약 　

반복 작업용 워커와 달리, 하나의 목표를 여러 Work Item으로 나누고 검증·통합하는 코디네이터 흐름을 직접 돌려본 기록.

반복형 워커에서 Work Item 기반 워커로

예전 데이터 수집 프로젝트에서도 워커와 코디네이터를 나눠 썼다. 다만 그때의 워커는 정해진 goal에 따라 같은 batch를 반복했고, 코디네이터는 쌓인 결과를 주기적으로 정리하는 역할이었다.

이번에는 달랐다. 내가 자연어로 목표를 던지면 코디네이터가 완료 조건과 Work Item을 정하고, 각 워커에게 파일과 작업 범위를 나눠줬다.

-W- 워커는 맡은 작업을 끝내고 검증한 뒤 commit을 넘겼다. -C- 코디네이터는 그 결과를 검토해서 하나씩 합치고, 전체 상태에서 다시 확인했다.

워커 수가 늘자 통합 비용도 늘었다

흐름 자체는 단순했다.

목표 전달
→ Work Item 분리
→ 워커별 실행과 검증
→ commit 인계
→ 코디네이터 검토·통합
→ 전체 상태 재검증

좋았던 건 작업마다 누가 무엇을 맡았는지 분명해진 점이다. 한 작업이 실패해도 다른 작업까지 같이 흔들리지 않았고, 결과도 commit 단위로 확인할 수 있었다.

문제도 바로 나왔다. 워커를 많이 띄우자 보고가 한꺼번에 쏟아졌고, 중복 세션까지 생기면서 관리가 더 복잡해졌다. 병렬이라고 무조건 많이 돌리는 게 답은 아니었다. 코디네이터가 감당할 수 있는 만큼만 나눠야 했다.

이날은 Orchestrator·Acceptance 기준선, 공통 Workflow·Skill, 워커·코디네이터 세션 운영 규칙까지 함께 정비했다.

OpenClaw에서 자동화할 것

오늘 쓴 세션·Worktree·Branch를 제품에 그대로 복제하려는 건 아니다. 자동화하고 싶은 건 그 뒤의 판단이다.

• 목표를 어디까지 쪼갤지
• 누가 어떤 결과를 소유할지
• 무엇을 확인해야 끝났다고 볼지
• 실패했을 때 어디서 다시 시작할지

OpenClaw에는 워커 수보다 결과 소유권, 검증, 재시작 지점을 관리하는 코디네이터가 필요했다.