경쟁사 리뷰 수백 건을 읽어 로드맵으로 바꾸는 작업. 예전 같으면 주말 몇 번을 날려야 했을 일이다. dev.to에 공개된 GapHunter 사례는 이 작업을 Claude Code 슬래시 커맨드 하나로 압축했다. /gaphunter DBeaver TablePlus를 실행하면 G2, Capterra, Reddit, GitHub Issues 등 여러 소스를 병렬로 탐색하고, 의미론적 클러스터링으로 중복 불만을 하나로 묶은 뒤, 자신의 레포 구조까지 읽어 '이미 구현된 것'과 '아직 안 된 것'을 교차 분석한다. 결과물은 Summary·Quick Wins·Comparison·Plan 탭이 달린 HTML 리포트 하나.
이 사례가 흥미로운 이유는 Claude Code를 단순 코딩 도우미가 아니라 도메인 특화 파이프라인의 오케스트레이터로 쓴 데 있다. 스킬 파일, HTML 뷰어, CSS까지 모두 Claude Code 안에서 작성했다고 저자는 밝힌다. 실행 가능성 측면에서 보면 설득력 있는 접근이다. 반복 가능한 분석 작업을 슬래시 커맨드로 패키징하면, 팀 내 누구든 같은 품질의 인풋을 만들 수 있다. 문제는 그 다음부터다.
GapHunter가 작동하는 방식을 뜯어보면 '멀티 스텝 에이전트 루프'다. 소스 탐색 → 클러스터링 → 레포 분석 → 리포트 생성, 각 단계가 앞 단계의 출력을 받아 다음 단계로 넘긴다. 로컬 사이드 프로젝트 수준에서는 중간에 소스가 403을 뱉거나 클러스터링이 어긋나도 그냥 다시 돌리면 그만이다. 그런데 이 구조를 팀 단위 프로덕션 워크플로우에 올리는 순간, 전혀 다른 문제가 터진다.
dev.to의 또 다른 글, Gravtory 팀이 공개한 '에이전트에 메모리를 줬더니 깨진 것들' 포스트가 정확히 이 지점을 짚는다. 12단계짜리 에이전트 루프에서 4번째 스텝이 타임아웃으로 죽으면, 체크포인팅이 없는 한 처음부터 다시 시작이다. 토큰 비용, 실행 시간 전부 날아간다. 이건 개발 단계에서는 '짜증나는 일'이지만, 수백 개 유저 요청이 병렬로 돌아가는 프로덕션에서는 비용 사고다.
Gravtory가 내놓은 해법은 단순하다. 별도 브로커나 오케스트레이션 서버 없이, 이미 쓰고 있는 Postgres에 각 스텝의 출력을 원자적으로 기록한다. 워커가 죽었다 살아나면 완료된 스텝은 DB에서 불러오고 거기서부터 재개한다. 모델 폴백도 내장되어 있어, Claude Sonnet이 응답하지 않으면 GPT-4o로 자동 전환하고 그 결과도 체크포인트에 쌓인다. 코드로 보면 @grav.workflow 데코레이터 하나에 @step 순서를 붙이는 수준이다.
그런데 Gravtory 팀이 진짜로 팀의 사고방식을 바꿨다고 말하는 건 라이브러리 자체가 아니라 테스트 프레임워크다. runner.simulate_crash_after(step=1)로 특정 스텝 이후 크래시를 시뮬레이션하고, 재개 후 해당 스텝의 모델이 다시 호출되지 않았음을 단위 테스트로 assert할 수 있다. 인프라 없이, 인메모리로. 이 한 줄이 의미하는 건 '크래시 복구를 희망하는 것'에서 '크래시 복구를 검증하는 것'으로 팀의 기준이 이동했다는 뜻이다.
두 사례를 나란히 놓으면 팀에게 던져지는 설계 질문이 선명해진다. Claude Code 스킬 확장은 '어떤 업무를 에이전트로 패키징할 것인가'의 문제다. GapHunter처럼 반복 가능한 멀티스텝 분석을 슬래시 커맨드로 추상화하면 팀의 실행 속도는 분명히 올라간다. 하지만 그 스킬이 팀 워크플로우에 올라타는 순간, '중간에 깨지면 어떻게 할 것인가'라는 두 번째 질문이 반드시 따라온다. 이 질문에 설계로 답하지 않은 에이전트 파이프라인은 로컬에서만 작동하는 데모로 남는다.
실용적인 순서를 제안하자면 이렇다. 첫째, 팀이 반복하는 멀티스텝 작업을 먼저 목록화한다. 경쟁사 분석, 스펙 초안 생성, 테스트 케이스 작성 등 후보는 많다. 둘째, 각 스텝의 실패 시나리오를 미리 쓴다. 어느 스텝이 가장 비싸고, 어느 스텝이 가장 자주 실패하는가. 셋째, 체크포인팅 전략을 코드보다 먼저 결정한다. Gravtory 같은 라이브러리를 쓰든, 직접 구현하든, 상태 저장 위치와 재개 조건은 스킬 설계 단계에서 픽스되어야 한다. 에이전트에게 복잡한 업무를 위임하는 것과, 그 위임이 프로덕션에서 신뢰 가능하게 작동하도록 설계하는 것은 별개의 일이다. Claude Code가 전자를 쉽게 만들수록, 후자를 팀이 놓칠 위험도 커진다.