지난 편에서 /triage 스킬을 만든 이야기를 했다. Todoist 관리함에 던져둔 할일을 카테고리로 분류하고, 애매한 태스크는 무엇을 어떻게 할지 한 번에 물어 구체화하는 단계(Step 4)까지 붙였다. 그때는 그걸로 됐다고 생각했다.
안 됐다.
다 자동으로 밀어붙이고 싶었다
만들고 나니 욕심이 났다. 분류만 하는 게 아니라, 분류가 끝난 태스크를 CLI가 곧장 실행할 수 있는 상태까지 만들고 싶었다. 그래서 계속 붙였다.
6월 27일에는 태스크마다 어떤 모델로 돌릴지(model:sonnet·opus), 워크플로우로 병렬 처리할지(workflow:yes)까지 triage가 판단해서 달게 했다. triage가 판단한 걸 각 프로젝트의 docs/todo.md에 그대로 적어두면, /dispatch가 그 파일을 읽어 무인으로 실행한다. 흐름은 이렇게 이어졌다.
triage → auto 확정 + 모델/워크플로우 결정
→ docs/todo.md에 태그 포함해서 기입
→ dispatch가 읽어서 실제 실행목표는 명확했다. 관리함에 할일 하나 던져두면 분류부터 실행까지 사람 손 안 타고 굴러가는 것. 분류라는 판단을 통째로 자동화 파이프에 밀어넣는 거였다.
밀어붙이면 엉뚱한 게 나온다
문제는 분류가 끝났다고 다 같은 태스크가 아니라는 데 있었다.
“권한추가” 같은 할일을 생각해보자. 명사 하나. 무슨 권한을, 어디에, 왜 추가하는지 이 세 글자만 봐서는 모른다. triage가 이런 걸 그냥 auto로 찍어 넘기면, /dispatch는 그 모호한 설명을 받아 뭔가를 만들긴 만든다. 대개 내가 원한 게 아닌 걸.
이건 나중에 dispatch 스킬에 아예 못 박아둔 규칙이 됐다. 실행 전 품질 게이트를 하나 세웠다.
요구사항이 불충분한 채로 실행하면 엉뚱한 결과물이 나온다. “기능 추가”, “UI 개선”, “정리해줘” 같은 모호한 설명은 실행 금지.
무인 실행 파이프라인 한복판에 “이건 돌리지 마”라는 브레이크를 스스로 달아둔 거다. 자동화를 밀어붙이려고 만든 시스템인데, 그 안에 “여기서 멈춰”가 필요했다는 뜻이다.
처음엔 이걸 로직 문제로 봤다. triage의 구체화 단계를 더 똑똑하게 다듬으면, 애매한 것도 알아서 잘 채워넣게 만들면 되지 않나. Step 4를 더 정교하게.
”discuss 스킬도 좀 만들어줄래”
방향을 튼 건 그 날 오후였다. 나는 이렇게 말했다.
discuss 스킬도 좀 만들어줄래 todo discuss 할일들 하나씩가져와서 처리하게
구체화 로직을 정교하게 만드는 대신, 구체화가 필요한 태스크에 discuss라는 라벨을 하나 붙이기로 했다. 아이디어가 덜 여물었거나, 방향이 안 정해졌거나, 티키타카가 필요한 것. triage가 자신 있게 auto로 못 찍는 건 전부 여기로 뺀다.
그리고 /discuss는 그 라벨 붙은 할일을 한 번에 하나씩 꺼낸다. 한꺼번에 몰아 묻지 않고, 태스크 하나를 열어 가장 불확실한 것부터 묻고, 답을 받아 방향이 서면 그제서야 auto나 manual로 확정한다. dispatch 쪽에서 discuss는 “결정 대기 → 보류”. 사람이 정하기 전엔 자동 실행 큐에 아예 안 올라간다.
로직을 자동화한 게 아니었다. 자동화를 멈출 자리를 만든 거였다.
이 자리는 원래 자동화할 곳이 아니었다
discuss를 굴려보고 나서야 보였다. 내가 붙잡고 있던 문제 설정 자체가 틀렸다는 게.
나는 “분류를 어떻게 하면 더 잘 자동화할까”를 풀고 있었다. 그런데 애초에 이 자리는 자동화 대상이 아니었다. 할일 하나가 무슨 뜻인지 정하는 건, 그러니까 “권한추가”가 실은 무슨 작업인지 확정하는 건 내 머릿속에만 있는 맥락이다. 로직을 아무리 다듬어도 없는 정보를 만들어낼 수는 없다. 여기서 필요한 건 더 똑똑한 분류기가 아니라, 사람한테 물어보는 한 줄이었다.
discuss는 그래서 라벨 이상이었다. “확신 없으면 discuss”는 결국 “이 판단은 사람 몫”이라는 선언이다. 자동화 시스템 안에 사람의 자리를 명시적으로 그어둔 경계.
분류도 예외가 아니었다
“무엇을 할지”가 애매한 자리는 discuss로 뺐다. 그런데 별개로 “어디로 갈지”에서도 같은 문제가 있었다. triage가 프로젝트·섹션을 판단해서 자동으로 옮기게 했는데, 생각보다 삑사리가 많이 났다. Second Brain(위키 시스템 자체를 운영하는 일)과 마이위키(별도 앱을 만드는 일)를 헷갈리거나, 태스크명에 “블로그”만 들어가면 실제로는 시스템 개선 작업인데도 컨텐츠 쪽으로 잘못 보내는 식. 이름만 보고 자동으로 확정 짓기엔 프로젝트 경계가 미묘한 경우가 많았다.
그래서 지금 triage는 섹션 이동도 자동으로 확정하지 않는다. Claude가 판단한 분류를 먼저 제시하고(”→ 컨텐츠 > OO 시리즈. 맞아?”), 사용자가 확인해줘야 실제로 옮긴다. 실행 여부만이 아니라 어디로 갈지, 그 분류 자체도 사람 확인이 필요한 자리였던 거다.
안전한 자동화는 어디를 남길지 아는 것
한동안 나한테 자동화란 “얼마나 더 사람 손을 뺄 수 있나”였다. triage에 계속 기능을 붙인 것도 그 힘으로였다. 그런데 정작 시스템을 쓸 만하게 만든 건 반대쪽 결정이었다. 어디를 자동화하지 않을지 정한 것.
밀어붙이는 걸로 안전이 나오지 않는다. 애매한 걸 억지로 auto로 넘기면 엉뚱한 결과가 쌓이고, 그걸 되돌리는 게 애초에 사람이 한 줄 물어보는 것보다 훨씬 비싸다. 안전한 자동화는 밀어붙이는 힘이 아니라, 어디를 사람 몫으로 남길지 아는 데서 나왔다.
triage는 지금도 계속 바뀐다. 다만 이제는 기능을 하나 붙일 때마다 같은 걸 묻는다. 이건 정말 자동화할 자리인가, 아니면 discuss로 남겨야 하는 자리인가.