대화 세션에서 돌리던 slash skill을 배치 자동화로 옮긴 이야기

요즘 같은 slash skill을 하루에도 몇 번씩 수동으로 돌리고 있는 저를 발견했습니다. 처음에는 "이게 가능하다니"라는 감탄으로 시작했는데, 어느 순간부터는 손가락이 먼저 움직이는 반복 작업이 되어 있었습니다. 이 글은 그 반복을 세션 밖의 배치 자동화로 옮기면서 느낀 것들에 대한 기록입니다. 기술 이야기이긴 하지만, 제게는 "사람이 어디까지 개입해야 하는가"라는 질문이 더 컸습니다.

같은 스킬을 매일 손으로 돌린다는 자각

자동화할 때가 되었다는 신호는 언제나 피로감으로 먼저 옵니다. 새로운 일이 들어오면 정해진 slash skill을 실행하고, 결과물을 훑어보고, 판단해서 다음 단계로 넘기는 루틴이었습니다. 처음 며칠은 "이게 되네" 싶어서 재미있었는데, 2주쯤 지나자 같은 동작을 똑같이 반복하고 있는 제 모습이 보였습니다.

돌이켜 생각해보면, 자동화 후보를 고르는 가장 정직한 기준은 "이 루틴을 내가 매일 같은 방식으로 반복하고 있는가" 하나뿐이었습니다. 아무리 정교한 스킬이라도, 결국 같은 조건에서 같은 결과를 만드는 일이라면 사람 손을 거칠 이유가 점점 줄어듭니다. 그 자각이 먼저 와야 이후의 설계가 의미가 있다는 생각이 들었습니다.

대화 세션과 세션 밖 실행의 경계

대화 세션 안에서 스킬을 실행하는 건 편합니다. 지금까지의 맥락, MCP로 연결된 도구들, 중간에 끼어들 수 있는 제 판단이 모두 살아 있습니다. 애매한 건 물어보고, 빗나간 결과는 바로 교정하면 됩니다. 이 "풍부함"이 대화형 작업의 가장 큰 자산입니다.

반면 세션 밖의 배치 실행은 그 풍부함을 얼마나 가져갈지 선택해야 하는 일입니다. 맥락을 다 포기하면 너무 단조로운 결과가 나오고, 전부 가져가려 하면 배치가 아니라 반자동 대화가 됩니다. 결국 "수동 대화의 똑똑함을 어디까지 포기할 것인가"가 설계의 출발점이 되었습니다. 저는 데이터 수집과 일차 분류까지는 자동으로 밀고, 마지막 판단만 사람이 잡는 선에서 경계를 그었습니다.

자동화 실행 환경, 세 가지를 비교해본 뒤

실행 환경을 고를 때 세 가지 후보가 남았습니다. GitHub Actions, 크론(cron), LaunchAgent. 겉보기에는 다 비슷해 보이지만, 개인 자동화 관점에서 보면 결이 꽤 달랐습니다.

개인 MacBook 위에서 돌리는 배치라면 저는 LaunchAgent가 거의 정답이라는 결론에 이르렀습니다. 로그인 세션의 Keychain에 붙을 수 있고, plist로 선언적으로 정의할 수 있고, 자원은 무료입니다. 원격 러너로 밀었을 때 인증을 우회하려고 설계가 복잡해지던 것들이, 로컬에서는 그냥 "자연스럽게" 풀렸습니다. 개인 자동화의 "집"이라는 표현이 과하지 않다는 생각이 들었습니다.

LLM을 어떻게 부를 것인가 — Direct API와 claude -p

실행 환경이 정해진 다음에는 LLM 호출 경로가 남습니다. 처음에는 "API 키 발급받아서 fetch로 붙이면 끝"이라 생각했는데, 막상 들여다보니 그렇게 간단하지 않았습니다.

제가 이미 Max 플랜을 쓰고 있다는 사실이 결정적이었습니다. 월 정액 쿼터라는 정산 축이 이미 있는데, Direct API를 따로 붙이면 별도 콘솔에 per-token 과금이 붙습니다. 청구선이 두 개가 되는 구조입니다. 반면 claude -p CLI로 호출하면 이미 내고 있는 쿼터에서 소진되기 때문에 청구선이 하나로 유지됩니다. 결제 구조가 단순해진다는 것 자체가 예상보다 큰 가치였습니다.

물론 공짜 점심은 없었습니다. claude -p는 매 호출마다 기본 시스템 프롬프트와 도구 스키마가 함께 주입되어, 같은 작업을 Direct API로 처리할 때보다 대략 열 배쯤 되는 토큰을 씁니다. 실행 속도도 더 느립니다. 이 비용을 "정산 단순성"이라는 가치로 수용할지가 판단 포인트였습니다.

저는 두 번째에 해당했기 때문에 claude -p로 갔습니다. 다만 본업 세션과 5시간 쿼터를 공유하는 리스크는 염두에 두고 있어야 합니다. 구체적인 플래그 설정이나 타임아웃 같은 실무 디테일은 정리할 게 많아, 다음 편에서 따로 다루려 합니다.

집행자에서 큐레이터로

사실 이 글에서 가장 말하고 싶은 부분은 여기입니다. 자동화를 붙이고 나서 가장 크게 달라진 것은 속도가 아니라 제 역할이었습니다.

이전의 저는 "집행자"였습니다. 새로운 입력이 들어오면 확인하고, 스킬을 실행하고, 결과를 붙여넣고, 다시 사람에게 전달하는 모든 단계에 제가 있었습니다. 스킬이 얼마나 정교하든, 결국 모든 건을 제가 한 번씩 돌리는 구조였습니다.

자동화를 붙인 뒤의 저는 "큐레이터"에 가까워졌습니다. 수집과 일차 판단, 초안 생성은 배치가 처리하고, 저는 쌓인 결과를 훑으면서 "승인할지, 스킵할지"만 선택합니다. 매 건을 처리하던 노동이 하루 한두 번 큐를 둘러보는 큐레이션으로 바뀌었습니다. 처리할 수 있는 건수는 오히려 늘어났고, 의사결정 피로는 줄었습니다. 같은 시간을 더 밀도 있게 쓸 수 있게 되었다는 생각이 들었습니다.

감사 가능한 배치 파이프라인이라는 부수 효과

예상하지 못한 장점도 있었습니다. 수동 루프 시절에는 "내가 오늘 몇 건을 어떻게 처리했는지"가 제 기억에만 남았습니다. 주간 회고를 하려 해도 근거로 삼을 자료가 거의 없었습니다.

배치로 옮기고 나니 이벤트 로그가 자동으로 쌓이기 시작했습니다. 시작 시각, 종료 시각, 처리 건수, 스킵 사유 같은 것들이 기록되니 주간·월간 단위로 "내 룰이 얼마나 잘 작동하고 있는가"를 돌아볼 수 있게 되었습니다. 한때 머리에만 있던 판단 기준이 정규식과 분류 프롬프트로 부호화되는 순간, 그 정책 자체가 하나의 자산이 된다는 생각이 들었습니다.

이 인프라가 자리 잡고 나면 다음 자동화를 붙이는 비용도 줄어듭니다. 로깅, 실행 가드, 누적 저장 같은 공통 부품이 이미 준비되어 있기 때문입니다. 저는 이 지점에서 배치 자동화의 진짜 가치를 체감했습니다. 당장의 시간 절약이 아니라, 판단 기준을 코드로 남기고 그 위에 층을 쌓아 갈 수 있다는 점이 제일 귀한 부분이었습니다.

정리하며

대화 세션 안에서 돌리던 slash skill을 배치로 옮기는 일은 기술적으로 그렇게 어려운 작업은 아니었습니다. 오히려 어려웠던 것은 "내가 어디까지 개입할 것인가"를 다시 정의하는 쪽이었습니다. 집행자로 남아 있을지, 큐레이터로 올라갈지를 결정하는 일. 이 결정이 선행되지 않으면 자동화는 그저 반복 횟수만 늘린 더 피곤한 장치가 됩니다.

다음 글에서는 claude -p를 LaunchAgent에 물려 안정적으로 돌리는 실무 체크리스트를 정리해볼 생각입니다. 인증, 타임아웃, 도구 억제, 에러 매핑처럼 개념만으로는 잡히지 않고 실제로 한 번 부딪쳐야 보이는 부분들입니다. 오늘의 글은 그 이전 단계 — 손에서 기계로 일을 넘기기로 결심하는 순간의 기록으로 남기고 싶었습니다.