코디네이터와 워커를 실제로 연결해봤다
✨ GPT-5.6 Sol의 요약
반복 작업용 워커와 달리, 하나의 목표를 여러 Work Item으로 나누고 검증·통합하는 코디네이터 흐름을 직접 돌려본 기록.
예전 워커와 달랐다
예전 데이터 수집 프로젝트에서도 워커와 코디네이터를 나눠 썼다. 다만 그때의 워커는 정해진 goal에 따라 같은 batch를 반복했고, 코디네이터는 쌓인 결과를 주기적으로 정리하는 역할이었다.
이번에는 달랐다. 내가 자연어로 목표를 던지면 코디네이터가 완료 조건과 Work Item을 정하고, 각 워커에게 파일과 작업 범위를 나눠줬다.

-W- 워커는 맡은 작업을 끝내고 검증한 뒤 commit을 넘겼다. -C- 코디네이터는 그 결과를 검토해서 하나씩 합치고, 전체 상태에서 다시 확인했다.
직접 굴려보니
흐름 자체는 단순했다.
목표 전달
→ Work Item 분리
→ 워커별 실행과 검증
→ commit 인계
→ 코디네이터 검토·통합
→ 전체 상태 재검증
좋았던 건 작업마다 누가 무엇을 맡았는지 분명해진 점이다. 한 작업이 실패해도 다른 작업까지 같이 흔들리지 않았고, 결과도 commit 단위로 확인할 수 있었다.
문제도 바로 나왔다. 워커를 많이 띄우자 보고가 한꺼번에 쏟아졌고, 중복 세션까지 생기면서 관리가 더 복잡해졌다. 병렬이라고 무조건 많이 돌리는 게 답은 아니었다. 코디네이터가 감당할 수 있는 만큼만 나눠야 했다.
OpenClaw에서 자동화할 것

오늘 쓴 세션·Worktree·Branch를 제품에 그대로 복제하려는 건 아니다. 자동화하고 싶은 건 그 뒤의 판단이다.
- 목표를 어디까지 쪼갤지
- 누가 어떤 결과를 소유할지
- 무엇을 확인해야 끝났다고 볼지
- 실패했을 때 어디서 다시 시작할지
여러 AI를 동시에 띄우는 건 어렵지 않았다. 어려운 건 각자 만든 결과를 잃어버리지 않고 하나로 합치는 일이었다. 오늘은 그 과정을 사람이 직접 돌려본 날이었다.
댓글 남기기