'한 명이 20명처럼 일한다.' YC CEO 개리 탄이 직접 만들어 쓰는 오픈소스 워크플로우 툴킷 gstack이 내건 약속이다. Think → Plan → Build → Review → Test → Ship → Reflect로 이어지는 스프린트 전 단계를 슬래시 커맨드로 커버하고, 각 명령이 CEO 리뷰어·아키텍트·디자이너·QA 리드·릴리즈 엔지니어처럼 동작한다. OWASP Top 10 보안 감사부터 Core Web Vitals 벤치마크, 배포 후 카나리 모니터링까지—사람이 하던 역할 대부분이 /cso, /benchmark, /canary 한 줄로 대체된다.
숫자만 보면 압도적이다. /autoplan 하나로 CEO·디자인·엔지니어링 리뷰가 자동 순차 실행되고, Conductor를 통해 여러 Claude Code 세션이 격리된 워크스페이스에서 병렬로 돌아간다. 한 세션은 오피스아워, 다른 세션은 코드 리뷰, 세 번째는 기능 구현, 네 번째는 QA—동시에. MIT 라이선스로 포크해서 팀 색깔에 맞게 확장까지 가능하다. 창업자·테크 리드·PM이 타깃이라고 명시했지만, 솔직히 말하면 이 구조가 정말 돌아가면 그 사람들이 할 일이 극단적으로 줄어든다.
그런데 실제 현장에서 이 공장을 돌려보면 즉시 벽에 부딪히는 지점이 있다. 세션 단절이다. AI 코딩 에이전트는 근본적으로 무상태(stateless)다. 터미널을 닫는 순간, 컨텍스트 윈도우가 꽉 차는 순간, 에이전트가 지금까지 쌓아온 모든 작업 맥락이 사라진다. dev.to에 공개된 체크포인트 시스템 구현 사례는 이 문제를 정면으로 다룬다. 지라 티켓 읽기 → 설계 문서 작성 → 리뷰 → 다중 모듈 구현 → PR 생성으로 이어지는 멀티 아워 워크플로우를 끊김 없이 이어가려면, 프롬프트 엔지니어링이 아니라 상태 관리 인프라가 필요하다.
이 체크포인트 아키텍처의 핵심 원칙은 명쾌하다. 첫째, 모든 메시지가 아니라 페이즈 경계에서만 저장한다. 설계 완료, 모듈별 구현 완료처럼 의미 있는 단위로만 체크포인트를 찍어야 데이터가 작고 신뢰할 수 있다. 둘째, 디스크가 데이터베이스보다 신뢰할 수 있는 소스다. "설계 단계 완료"라는 메타데이터 레코드보다 실제 설계 문서 파일이 존재하는지가 진실이다. 세션이 죽고 재개할 때, 에이전트는 메타데이터가 아니라 디스크 아티팩트를 기준으로 어디서부터 시작할지 결정한다.
그리고 세 번째, 가장 중요한 원칙이 있다. 휴먼 게이트다. 설계 리뷰 후, 코드 리뷰 후—두 지점에서 에이전트는 멈추고 사람의 승인을 기다린다. 이 게이트는 자동화 실패에 대한 보험이 아니다. 자동화해서는 안 되는 결정이 존재한다는 구조적 선언이다. "AI가 하루 종일 코드를 쓸 수 있지만, 이 설계가 말이 되는지는 내가 판단한다"는 것. gstack의 /careful, /guard 같은 안전 커맨드도 같은 맥락이다. rm -rf나 강제 푸시 같은 파괴적 명령 앞에 경고를 삽입하고, 디버깅 중 범위 외 파일 수정을 차단한다. 공장 자동화에는 반드시 비상정지 버튼이 있어야 한다.
성능 측정과 품질 관리도 빠질 수 없다. dev.to의 Hosaka Studio 사례는 AI 주도 개발에서 측정이 선행되어야 한다는 점을 잘 보여준다. 첫 프레임 렌더 시간, 프레임 캡처 지연, 에디터 프리뷰 FPS처럼 팀이 실제로 신경 쓰는 지표를 먼저 정의하고, 그 숫자를 AI에게 보여준 다음 개선 실험과 벤치마크를 맡기는 방식이다. 단위 테스트는 CLAUDE.md에 두 줄 지시만 있어도 AI가 알아서 돌린다. 스모크 테스트를 위한 CLI 모드를 앱에 추가해서 AI가 비대화형으로 기능을 직접 검증하게 만드는 것도 실용적인 접근이다. 측정할 수 없으면 개선할 수 없고, AI도 예외가 아니다.
이 세 가지 흐름을 종합하면 'AI 소프트웨어 팩토리'의 실제 구조가 윤곽을 드러낸다. 워크플로우 자동화(gstack) + 상태 지속성(체크포인트) + 측정 기반 품질 관리(벤치마크)—이 세 레이어가 동시에 작동할 때 비로소 '혼자서 팀처럼' 돌아가는 공장에 근접한다. 어느 하나만 있으면 구멍이 생긴다. 슬래시 커맨드만 있고 세션 복구가 없으면 멀티 아워 작업이 언제 터질지 모르는 시한폭탄이 된다. 체크포인트가 있어도 측정 기준이 없으면 공장이 나쁜 제품을 빠르게 찍어낸다.
솔직하게 짚자. 이 구조가 실제 팀 전체를 대체할 수 있느냐는 질문에 대한 답은 아직은 아니다다. gstack이 강력한 건 맞지만, 현재로서는 구조화된 작업, 명확한 스펙, 기존 코드베이스 이해가 전제된 환경에서 가장 잘 작동한다. 애매한 요구사항, 레거시 의존성, 팀 간 정치적 의사결정—이런 영역에서 AI는 여전히 사람의 판단을 필요로 한다. 체크포인트 아키텍처를 만든 개발자가 직접 쓴 것처럼, "AI 에이전트에게 좋은 코드를 쓰게 만드는 게 어려운 게 아니다. 어려운 건 이미 결정된 것을 기억하게 하고, 맥락을 잃지 않고 이어가게 만드는 것"이다. 이 문제는 아직 완전히 풀리지 않았다.
그럼에도 방향은 분명하다. AI-First 팀을 리빌딩하고 있다면, 지금 당장 도입할 수 있는 실행 순서는 이렇다. 먼저 측정부터—팀이 진짜 신경 쓰는 지표를 CLAUDE.md에 박아놓는다. 그다음 체크포인트 구조—멀티 스텝 작업이 세션을 넘어서도 이어지게 페이즈 경계를 설계한다. 마지막으로 휴먼 게이트를 명시적으로 정의한다—어디서 사람이 개입해야 하는지를 워크플로우 설계 단계에서 미리 박아넣는다. gstack은 그 세 가지를 하나의 오픈소스 패키지로 묶어서 실험해볼 수 있게 해준다. 포크해서 돌려보는 데 하루도 안 걸린다. AI 공장의 청사진이 이미 오픈소스로 공개됐다—남은 건 감독자 역할을 어떻게 설계하느냐다.