스킬을 필요할 때마다 하나씩 만들었다. 블로그 쓸 때 막혀서 하나, 앱 만들 때 답답해서 하나, 할일이 안 돌아가서 하나. 서로 상관없는 문제였고 만들 때도 서로 참고 안 했다. 블로그 스킬 짜면서 앱 스킬을 떠올린 적은 없다.
그런데 어느 시점에 각각을 다듬다가 갑자기 보였다. 백엔드는 docs-spec으로 설계 결정 박고 plan으로 쪼개서 실행했고, 프론트는 요구사항 받아서 시안 여러 개 뽑고 하나 골라서 확장한 다음 기능 개발로 넘겼고, 블로그는 seed에서 줄거리 잡고 초안 쓰고 배포했고, 할일은 todo에서 구체화하고 분류하고 실행했다. 이름도 다르고 도메인도 달랐는데, 다듬고 나란히 놓으니 다 똑같은 모양이었다.
따로 만든 세 개
세 파이프라인을 만든 이유가 전부 다르다.
블로그는 소재가 머릿속에서 휘발되는 게 싫어서 만들었다. 채팅 이력이랑 위키에서 소재를 긁어오는 blog-mine, 방향 잡고 사람이 승인하는 blog-brief, 본문 쓰는 blog-draft, 검수 끝나면 내보내는 blog-publish 순서로 흐른다.
앱은 “이거 만들어줘” 한 마디로 통째로 던졌다가 절반쯤 가서 컨텍스트 터지는 게 싫어서 만들었다. 이건 지난 편들에서 길게 다뤘으니 짧게만. 요구사항 뽑는 app-req, 설계 결정을 박는 docs-spec, 한 세션 단위로 쪼개는 plan, 그걸 무인으로 도는 /goal.
할일은 Todoist에 쌓이기만 하고 손이 안 가는 게 싫어서 만들었다. 분류하는 triage, 계획으로 묶는 plan-todo, auto로 표시된 항목을 실제로 실행하는 dispatch.
소재 휘발, 컨텍스트 터짐, 안 돌아가는 할일. 셋이 무슨 상관인가 싶었다.
펼쳐놓으니 다 똑같았다
나란히 표로 놓고서야 보였다.
| 파이프라인 | 요구사항·소재 | 구체화 | 사전 준비 | 에이전트 실행 | 사람이 멈추는 곳 |
|---|---|---|---|---|---|
| 블로그 | blog-mine / seed | blog-brief | raw 연결·골격 | blog-draft / publish | brief 승인, draft 검수 |
| 앱 | app-req | discuss · docs-spec | plan | /goal | 설계 결정, 게이트 항목 |
| 할일 | Todoist 수집 | triage 분류 | plan-todo | dispatch · /goal | 분류 확정 |
열을 보면 단어만 다르지 자리는 같다. 먼저 뭘 할지 정하고(요구사항·소재), 그걸 에이전트가 실행할 수 있을 만큼 구체화하고, 실행 직전까지 사전 준비를 깔고, 그다음에야 에이전트한테 넘긴다. 그리고 중간중간 사람이 멈춰서 보는 자리가 한두 군데 박혀 있다. 블로그면 brief를 사람이 승인해야 draft로 넘어가고, 앱이면 설계 결정과 게이트 항목에서 멈춰 묻고, 할일이면 분류가 맞는지 확정한다.
도메인이 블로그든 앱이든 할일이든 모양이 안 바뀐다. 사람이 앞에서 다 차려놓고, 에이전트가 뒤에서 실행한다. 가운데 게이트 몇 개.
왜 같은 모양이 됐나
처음엔 우연인 줄 알았는데, 생각해보니 그럴 수밖에 없었다.
에이전트는 컨텍스트를 줘야 움직이는 존재다. 뭘 만들지, 어떤 제약이 있는지, 뭐가 뭐에 의존하는지 안 주면 그냥 그럴듯한 걸 지어낸다. blog-draft한테 소재만 던지면 일반론을 쓰고, /goal한테 목표만 던지면 절반쯤 가서 방향이 샌다. 그래서 앞단에 요구사항이랑 구체화가 무조건 붙는다. 명세를 건너뛰면 나중에 갈아엎으니까, 앞에서 막는 거다.
그러니까 앞단(준비)은 사람이 못 피한다. 에이전트한테 일을 시킨다는 건, 시키기 전에 시킬 수 있는 상태로 만들어놓는다는 거다. 그 “만들어놓는” 부분이 사람 몫이고, 그게 매번 같은 모양으로 남는다. 크게 보면 계획하고 사전 준비를 다 해서 에이전트한테 구현을 시키는 거고, 도메인이 뭐든 이 골격은 안 변한다.
게이트도 같은 이유다. 무인으로 끝까지 밀고 싶은 욕심이 늘 있는데, 앞단 결정이 0.5%만 틀어진 채 자동으로 흐르면 뒤에 쌓인 게 전부 그 오류를 상속한다. 사람이 디버깅하는 비용이 자동화로 아낀 것보다 커진다. 그래서 중요하고 되돌리기 어려운 결정에는 사람 멈춤이 박힌다. 블로그 brief 승인이든 앱 설계 게이트든, 자리가 다를 뿐 역할은 같다.
어디서 나누느냐가 전부다
이제는 왜 이 모양이 됐는지 알 것 같다.
사람이 해야 할 자리에 에이전트를 들이면 제품이 망가진다. 방향 없이 소재만 던지면 일반론이 나오고, 명세 없이 목표만 주면 절반쯤 가서 방향이 샌다. 에이전트는 사람이 정해놓은 맥락 안에서만 똑똑하다.
반대도 마찬가지다. 에이전트가 해야 할 자리에 사람이 앉아 있으면 생산성이 떨어진다. 초안 한 편을 사람이 직접 쓰거나 plan의 항목을 사람이 하나씩 실행하면 자동화가 무슨 의미인가 싶어진다.
그래서 앞뒤가 나뉜다. 앞단은 사람 자리, 뒷단은 에이전트 자리. 이 경계를 잘못 그으면 어느 쪽이든 문제가 생긴다. 파이프라인마다 조금씩 다르게 그어봤는데, 공통점은 하나였다. 사람이 결정하고 에이전트가 실행한다. 그 순서가 바뀌면 안 된다.