AI 소프트웨어 팩토리: 혼자서 20명의 엔지니어링 팀을 운영하는 법

코딩 에이전트를 쓰는 인디 파운더가 늘고 있습니다. Claude Code를 열고, 프롬프트를 던지고, 코드를 생성합니다. 하지만 대부분 여기서 멈춥니다. AI가 코드를 짜주는 건 좋은데, 누가 그 코드를 리뷰하고, 테스트하고, 배포 전에 점검합니까?

혼자 일하는 파운더의 진짜 병목은 코딩 속도가 아닙니다. 코드를 짠 사람이 직접 리뷰하고, 직접 테스트하고, 직접 배포하는 역할의 부재입니다. 대기업에는 PM, 디자이너, QA 엔지니어, 릴리즈 매니저가 있습니다. 솔로 파운더에게는 자기 자신뿐입니다.

YC CEO Garry Tan이 이 문제를 정면으로 해결하려 했습니다. 그가 오픈소스로 공개한 gstack은 단순한 프롬프트 모음이 아닙니다. AI 에이전트에게 역할을 부여하고, 소프트웨어 개발의 전체 사이클을 구조화한 "소프트웨어 팩토리"입니다.

코딩 에이전트의 진짜 문제: 코드는 나오는데 제품이 안 나옵니다

AI 코딩 도구의 발전 속도는 놀랍습니다. 프롬프트 한 줄로 수백 줄의 코드가 나옵니다. 하지만 코드와 제품 사이에는 거대한 간극이 있습니다.

코드를 짜는 건 소프트웨어 개발의 20%에 불과합니다. 나머지 80%는 이런 질문에 답하는 과정입니다:

• 이 기능이 정말 필요한가? — 제품 검증 없이 만들면 쓰레기가 됩니다
• 아키텍처는 괜찮은가? — 지금 빠르게 짤 수 있어도 3개월 뒤 무너질 수 있습니다
• 엣지 케이스는 커버되는가? — 개발자가 놓치는 것을 QA가 잡아줍니다
• 프로덕션에 내보내도 되는가? — 보안, 성능, 호환성을 누가 최종 점검합니까

혼자 일하면 이 질문들이 전부 생략됩니다. 급하니까 리뷰 없이 머지하고, 테스트 없이 배포합니다. 그리고 주말에 장애가 터집니다.

gstack의 핵심 아이디어: AI에게 직급을 주세요

gstack의 접근법은 단순하지만 강력합니다. AI를 "똑똑한 코딩 도우미"가 아니라 "특정 역할을 수행하는 팀원"으로 사용하는 것입니다.

슬래시 커맨드 하나로 AI의 페르소나가 바뀝니다:

• /office-hours — YC 오피스아워 형식으로 6가지 질문을 던져 제품을 검증합니다
• /plan-ceo-review — CEO 관점에서 "10성급 제품"인지 탐색합니다
• /plan-eng-review — 엔지니어링 매니저가 아키텍처와 보안을 정의합니다
• /review — 시니어 엔지니어가 프로덕션 버그를 탐지하고 자동 수정합니다
• /qa — QA 리드가 실제 브라우저로 테스트하고 회귀 테스트를 생성합니다
• /ship — 릴리즈 엔지니어가 PR을 만들고 테스트 프레임워크를 부트스트랩합니다

핵심은 각 단계에서 컨텍스트가 자동으로 전달된다는 점입니다. CEO 리뷰에서 나온 요구사항이 엔지니어링 설계로, 설계가 코드로, 코드가 QA로 자연스럽게 흐릅니다.

AI를 쓸 때 가장 큰 실수는 모든 걸 하나의 프롬프트에 우겨넣는 것입니다. 역할을 분리하면 각 단계의 품질이 올라갑니다.

Think → Plan → Build → Review → Test → Ship: 스프린트의 재발명

gstack은 소프트웨어 개발을 6단계 스프린트로 구조화합니다. 이건 애자일 스크럼의 AI 버전입니다.

Think 단계에서는 무엇을 만들지 정합니다. /office-hours가 YC 파트너처럼 날카로운 질문을 던집니다. "이 기능의 고객이 누구입니까?" "경쟁 제품과 뭐가 다릅니까?"

Plan 단계에서는 어떻게 만들지 설계합니다. CEO 리뷰와 엔지니어링 리뷰가 순차적으로 진행됩니다. 제품 방향성과 기술적 타당성을 동시에 검증합니다.

Build 단계에서는 실제로 코드를 작성합니다. 이 단계에서야 비로소 코딩이 시작됩니다. 앞의 두 단계가 있기 때문에 "뭘 만들어야 하지?"라는 모호함이 사라집니다.

Review → Test → Ship은 품질 게이트입니다. 코드 리뷰, QA 테스트, 배포까지 각각 전담 역할이 수행합니다.

솔로 파운더가 이 과정을 혼자 하면 반나절이 걸리던 일을 AI가 역할별로 나눠서 처리하면 1시간이면 한 사이클을 돌립니다.

왜 "역할 분리"가 프롬프트 엔지니어링보다 강력한가

많은 파운더가 더 좋은 프롬프트를 쓰려고 합니다. 프롬프트를 길게 쓰고, 예시를 넣고, 체인 오브 씽킹을 요청합니다. 하지만 하나의 프롬프트로 PM, 디자이너, 개발자, QA를 동시에 시키는 건 한 사람에게 네 가지 일을 동시에 시키는 것과 같습니다.

역할을 분리하면 세 가지가 달라집니다:

• 깊이가 생깁니다. QA 역할만 맡은 AI는 "이 입력값이 null이면 어떻게 됩니까?"를 놓치지 않습니다
• 견제가 생깁니다. 개발자 AI가 짠 코드를 리뷰어 AI가 검토합니다. 같은 맥락에서 벗어나 객관적으로 봅니다
• 프로세스가 생깁니다. "그냥 코드 짜줘"에서 "기획 → 설계 → 구현 → 검증"으로 체계가 잡힙니다

좋은 팀의 비밀은 뛰어난 개인이 아니라 역할 간의 견제와 균형입니다. AI 팀도 마찬가지입니다.

인디 파운더를 위한 실전 적용법

gstack을 그대로 쓸 필요는 없습니다. 핵심 원리를 가져와서 당신의 워크플로우에 적용하면 됩니다.

첫째, 코딩 전에 반드시 "기획 에이전트"를 거치세요. Claude Code에 "이 기능을 구현해줘" 대신 "이 기능이 필요한 이유를 YC 파트너처럼 검증해줘"라고 먼저 요청합니다. 만들지 말아야 할 기능을 걸러내는 것이 만드는 것보다 중요합니다.

둘째, 코드를 짠 후 반드시 "리뷰 에이전트"를 거치세요. 같은 대화에서 "이 코드를 시니어 엔지니어 관점에서 리뷰해줘. 보안 취약점, 성능 이슈, 엣지 케이스를 찾아줘"라고 요청합니다. 자기가 짠 코드를 자기가 리뷰하면 100% 통과시킵니다.

셋째, 배포 전에 "QA 에이전트"를 거치세요. "이 변경사항으로 발생할 수 있는 회귀 테스트 시나리오 5개를 만들어줘"라고 요청합니다. 프로덕션에서 터지는 버그의 80%는 이 단계에서 잡을 수 있습니다.

병렬 스프린트: AI의 진짜 강점은 동시성입니다

사람은 한 번에 하나의 일만 할 수 있습니다. 하지만 AI 에이전트는 동시에 여러 개의 작업을 병렬로 처리할 수 있습니다.

gstack의 Conductor 기능은 여러 스프린트를 동시에 실행합니다. 결제 모듈을 개발하면서 동시에 사용자 인증 모듈을 설계하고, 기존 코드의 리팩토링까지 병렬로 진행합니다.

이건 20명의 팀이 하는 일과 같습니다. 하지만 실제로는 혼자입니다. 매니저가 팀원들에게 작업을 배분하듯, 파운더가 AI 에이전트들에게 역할과 작업을 배분합니다.

물론 모든 작업을 병렬로 돌리면 컨텍스트를 놓칠 수 있습니다. 핵심 아키텍처 결정은 순차적으로, 독립적인 기능 구현은 병렬로 — 이 원칙만 지키면 됩니다.

도구는 변해도 원리는 남습니다

gstack이 내일 사라져도 상관없습니다. 중요한 건 도구가 아니라 "AI를 역할 기반으로 활용한다"는 원리입니다.

Claude Code, Cursor, Codex — 어떤 도구를 쓰든 적용할 수 있는 세 가지 원칙이 있습니다:

• 역할을 명시하세요. "너는 시니어 백엔드 엔지니어야"라고 선언하면 AI의 출력 품질이 달라집니다
• 단계를 나누세요. 기획, 설계, 구현, 리뷰, 테스트를 한 프롬프트에 몰아넣지 마세요
• 견제 구조를 만드세요. 만든 사람(AI)과 검토하는 사람(AI)은 반드시 분리하세요

2026년에 소프트웨어를 만든다는 것은 코드를 짜는 것이 아닙니다. AI 팀을 조직하고 운영하는 것입니다. 인디 파운더에게 이보다 강력한 레버리지는 없습니다.