Worker를 사람 역할이 아니라 계약으로 봐야 하는 이유

OkayJing Local을 pixel office나 worker 화면으로 만들다 보면 자연스럽게 "누가 일하는가"가 먼저 보인다. 연구 worker, 구현 worker, 리뷰 worker처럼 이름을 붙이면 화면은 이해하기 쉬워진다. 그런데 이 방식은 금방 역할극으로 흐를 수 있다.

실제 운영에서 중요한 질문은 "이 worker가 어떤 성격인가"가 아니다. 어떤 capability를 갖고 있는지, 어떤 입력을 받아도 되는지, 어떤 artifact를 남기는지, 실패하면 누가 어떻게 회수하는지가 더 중요하다. 그래서 worker는 사람 역할보다 계약으로 보는 편이 맞다.

"리뷰어"라는 이름을 붙였다고 해서 그 worker가 항상 좋은 리뷰를 하지는 않는다. "구현자"라고 해서 파일을 안전하게 고치는 것도 아니다. 이름은 사용자가 대략 이해하기 쉽게 돕지만, 운영 시스템의 보증이 되지는 못한다.

보증에 가까운 것은 계약이다. 이 worker가 읽을 수 있는 범위, 쓸 수 있는 범위, 필요한 evidence, 완료 조건, 남겨야 할 report, Hub가 흡수하거나 버릴 기준이 명시되어야 한다. 그래야 다음 세션이나 다른 profile이 봐도 같은 작업을 이어갈 수 있다.

capability는 worker의 능력 목록이다. 예를 들면 "SEOJing 글을 build 검증까지 한다", "OkayJing Local 화면을 read-only로 QA한다", "Discord gateway 설정을 안전하게 점검한다"처럼 적을 수 있다. 여기에는 반드시 경계가 붙어야 한다.

같은 worker라도 읽기 전용 점검은 허용될 수 있고, push나 gateway restart는 막혀야 할 수 있다. 그래서 capability는 단순한 장점 목록이 아니라 권한과 검증을 포함한 실행 범위다.

여러 worker가 같이 움직일 때 대화 로그 전체를 넘기면 처음에는 편하다. 하지만 시간이 지나면 Hub가 무엇을 믿어도 되는지 알기 어렵다. 반대로 handoff contract는 넘겨야 할 것만 남긴다.

최소한 intent, acceptance criteria, source paths, allowed actions, produced artifacts, verification result, disposition이 있어야 한다. 여기서 disposition은 특히 중요하다. 이 작업을 Hub가 흡수할지, archive할지, discard할지 정해야 다음 작업에서 context가 오염되지 않는다.