역할을 나눈 에이전트에게 일을 넘기기 전에 판단 모델을 붙였습니다

일이 진행되는 건 이제 LLM이 훌륭히 합니다. 하지만 해도 되는지, 부족한 게 있는지, 그 판단 자체는 여전히 중요한 요소입니다.

PM 혼자 내리던 위임 판단

에이전트를 역할별로 나눈 뒤로 저는 PM 에이전트하고만 이야기합니다. PM은 제 요청을 직접 처리하거나, 설계는 archie에게, 구현은 build에게, 기록과 발행은 scribe에게 넘깁니다. 넘길 때는 칸반 카드에 배경과 완료 조건을 적고, 받은 에이전트는 제 대화를 보지 못한 채 그 카드만 읽고 일을 시작합니다.

카드를 받은 에이전트는 코드를 쓰고 테스트를 돌리고 문서를 고쳐 커밋까지 합니다. 일을 해내는 쪽은 크게 걱정하지 않게 됐습니다. 남는 것은 카드를 만드는 순간의 판단입니다. 이 일을 넘겨도 되는지, 누구에게 넘겨야 하는지, 카드에 빠진 것은 없는지를 PM 혼자 정합니다. 그 판단이 카드 한 장으로 굳어 다른 프로세스로 넘어가면, 받은 쪽은 틀린 판단이라도 카드에 적힌 대로 일합니다.

그래서 PM 옆에 판단만 하는 모델을 하나 두기로 했습니다. 앞으로 이런 판단 모델이 더 중요해질 거라고 생각했습니다.

Laya 대신 Clef

처음 떠올린 것은 메일 분류에 쓰고 있는 Laya였습니다. 가중치가 무료로 공개되어 있어 맥미니에서 직접 돌리는 결정 모델입니다. 글을 생성하지 않고 정해 둔 선택지마다 확률을 돌려주니, PM이 카드를 만들 때 build, archie, scribe 가운데 누구의 일인지 고르게 하면 될 것 같았습니다.

PM에게 물었더니 맞지 않는다고 했습니다. Laya가 읽는 양이 문제였습니다. 제가 쓰는 Laya는 파라미터 3억 2천만 개짜리 모델이고 한 번에 1,024토큰까지만 읽습니다. 넘길지 말지는 앞선 대화에서 답이 나왔는지에 따라 달라지는데, 그 대화가 들어가지 않습니다. 카드 본문만 넣어도 셋 중 둘은 잘립니다. 학습시킬 정답도 없었습니다. 메일은 3,597통으로 학습했지만, 칸반 카드는 PM이 넘긴 기록일 뿐 넘기는 게 옳았다는 기록이 아닙니다.

저는 이것이 무료 모델의 한계인지 물었습니다. 같은 방식의 결정 모델인 TypeSafe AI의 Jev는 유료 API로만 쓸 수 있고 훨씬 길게 읽기 때문입니다. 그러다 Cloudflare Workers AI에도 같은 방식의 모델이 있는 것을 봤습니다. Clef입니다. Clef도 Laya처럼 가중치가 Apache 2.0으로 공개되어 있습니다. 무료로 풀린 모델이라서 모자란 것이 아니라 Laya가 작아서 모자랐던 것입니다. Clef는 파라미터가 270억 개이고 한 번에 65,536토큰을 읽으며, 학습 없이 질문 문장만 주면 답합니다.

더 작고 빠른 clef-flash도 있지만 정확한 쪽을 쓰기로 했습니다. Clef는 맥미니의 48GB 메모리에 들어가지 않아 Cloudflare에서 부릅니다.

처음 정한 세 가지 질문

질문은 제가 처음 떠올린 세 가지로 시작했습니다. build로 가야 하는 일인가, archie에게 던질 일인가, scribe에게 넘기기에 재료가 충분한가. 지난 카드에 돌려 보니 Clef는 대부분 실제 배정과 같은 역할을 골랐고, PM이 일부러 재료를 빼고 써 본 카드도 가려냈습니다.

그런데 결과를 보면서 헷갈렸습니다. 이 질문들이 PM이 실제로 결정을 못 하거나 잘못하던 곳을 겨누고 있는지 알 수 없었습니다. 판단 모델은 잘못하던 곳에 쓰여야 쓸모가 있는데, 저는 잘못하던 곳을 확인하기 전에 질문부터 정했습니다.

막힌 카드에 남은 이유

PM에게 기록을 다시 보게 했습니다. 한 달 남짓 동안 PM이 세 에이전트에게 넘긴 카드 170여 장 가운데 40장 남짓이 한 번 이상 막히거나 멈췄습니다. 막힌 이유는 카드에 남아 있었고, 세 에이전트가 쓴 한 달 회고에도 PM의 실수가 적혀 있었습니다.

처음 정한 질문은 실제 실패와 거의 겹치지 않았습니다. 쓸 재료가 없어 막힌 scribe 카드는 한 장도 없었습니다. 실제로 반복된 실패는 이랬습니다.

• 지침 파일을 고치라는 지시. Hermes는 AGENTS.md, SOUL.md, CLAUDE.md를 고칠 때 사람의 승인을 받게 합니다. 카드를 받아 혼자 도는 워커에게는 승인을 누를 사람이 없어서 그 자리에서 멈춥니다.
• 워커 혼자 끝낼 수 없는 단계. origin push, 공개 저장소에 PR이나 이슈 올리기, 사람의 확인, 실제 통화로 하는 측정이 완료 조건에 들어 있었습니다.
• 한 카드에 너무 많은 일. archie는 회고에서 다음 달에 바꿀 한 가지로 구현 카드를 중간 완료점마다 나누는 것을 꼽았습니다.
• 대화에서 생긴 실수. 제가 “다크 시네마틱 톤이 중요하진 않아”라고 한 말을 PM이 발표 덱의 시각 언어 전체를 빼라는 뜻으로 넓혀 카드에 적었습니다. 제 승인 없이 카드를 만든 적도 있고, PM이 직접 답할 수 있던 일을 archie에게 넘긴 적도 두 번 있습니다.

누구에게 넘길지 고르는 질문도 마찬가지였습니다. 기록에 남은 배정 실수는 그 두 번뿐이었고, 역할을 잘못 고른 것이 아니라 넘기지 말았어야 할 일이었습니다.

카드 본문까지만 읽는 모델

Clef에게는 카드 본문만 줍니다. 카드를 받은 에이전트가 제 대화를 모른 채 읽는 바로 그 글입니다. 그렇다면 본문에 드러난 실패는 Clef도 볼 수 있고, 대화에만 남은 실패는 볼 수 없을 것이었습니다.

실제로 그랬습니다. 지침 파일을 고치라는 지시가 본문에 적힌 카드는 대부분 짚었고, 그 파일을 읽으라거나 인용만 한 카드는 걸지 않았습니다. 파일 이름만 찾는 규칙으로는 그런 카드까지 함께 걸립니다. 설계 문서를 따르라는 한 줄뿐인 카드는 짚을 수 없었습니다. 워커 혼자 끝낼 수 없는 단계는 이 때문에 막힌 카드를 셋 중 둘꼴로 짚었지만, 문제없이 끝난 카드도 일부 걸렸습니다. PM이 직접 답할 수 있던 위임이나 작업 중에 사용자에게 물어야 하는 카드는 본문만으로 가려내지 못했습니다.

kanban_create 직전의 검사

본문에 드러나는 이 두 가지만 Hermes 플러그인으로 붙였습니다. PM이 kanban_create로 카드를 만들려고 하면, 그 직전에 플러그인이 카드 제목과 본문을 Clef에 보냅니다. 지침 파일 수정 지시로 판정되면 카드를 만들지 않고 이유를 PM에게 돌려줍니다. 워커 혼자 끝낼 수 없는 단계는 문제없던 카드도 걸리므로 막지 않고 경고만 붙입니다. Clef를 부르지 못하면 검사를 건너뛰고 카드를 그대로 만듭니다.

카드 한 장을 보는 데 0.0004달러쯤 들어서, 평소에는 Workers AI가 매일 주는 무료 사용량 안에서 끝납니다. 시험하던 날에는 지난 카드를 여러 번 돌리느라 무료 사용량을 넘겼는데, 넘겨도 요청이 막히지 않았습니다. 그래서 하루 상한을 플러그인에 넣었습니다.

남은 것

지난 카드에 돌려 보면, 막히거나 멈춘 40여 장 가운데 이 검사가 짚는 카드는 열 장 남짓입니다. 나머지는 대화에서 생긴 실패입니다. 제 말을 넓게 읽은 것, 넘기지 않아도 될 일을 넘긴 것, 저만 아는 기준이 빠진 것은 카드 본문에 흔적이 남지 않습니다. 그래서 이 판단은 여전히 카드를 만들기 전에 PM이 결정 문장과 제약을 제게 보여 주고, 제가 읽고 확인하는 절차에 맡겨 둡니다.

판단 모델이 할 수 있는 일은 카드에 적힌 판단을 한 번 더 보는 데까지입니다. 그 판단이 처음 생기는 대화는 아직 제가 직접 봐야 합니다.

플러그인을 붙인 뒤 새로 만든 카드 네 장은 모두 그대로 통과했고, 막힘 없이 끝났습니다. 막거나 경고를 붙인 카드는 아직 없습니다.