gstack, Claude Code 하나로 꾸리는 가상 엔지니어링 팀

PM·아키텍트·구현·리뷰어·테스터 역할을 나눠 맡는 Claude Code 기반 AI 에이전트들이 협업하는 오픈소스 프로젝트 gstack의 구조와 동작 방식, 현실적 제약을 정리한다

2026-08-14 · 최초 발행 2026-03-23

YC(Y Combinator) CEO 출신 개발자가 공개한 오픈소스 프로젝트 gstack은 단일 개발자가 Claude Code를 활용해 복수의 AI 에이전트로 구성된 가상 엔지니어링 팀을 운영하는 소프트웨어 개발 모델을 제시한다. 기획자, 설계자, 구현자, 리뷰어, 테스터 역할을 각각 담당하는 AI 에이전트들이 협력해 복잡한 소프트웨어를 개발하는 이 접근법은, 1인 개발자가 소규모 팀 수준의 개발 역량을 갖출 수 있다는 가능성을 실증적으로 보여준다.

Claude Code 위에 얹은 소프트웨어 팩토리

gstack은 GitHub에 공개된 오픈소스 프로젝트로, Claude Code를 핵심 AI 엔진으로 삼아 여러 전문화된 AI 에이전트가 소프트웨어 개발 생명주기 전반을 협력적으로 수행하는 "AI 소프트웨어 팩토리"를 구현한다. 프로젝트명의 'g'는 개발자 Garry Tan(개리 탄)의 이니셜로, 그가 YC CEO 재임 시절부터 탐구해온 개발자 생산성 극대화 비전의 산물이다.

gstack의 핵심 철학은 역할 분리(role separation)다. 단일 LLM 인스턴스에 모든 작업을 맡기는 대신, 소프트웨어 팀의 다양한 역할을 모방한 전문화된 에이전트들이 각자의 책임 영역에서 작업하고 결과를 공유한다. 인간 팀의 협업 구조를 AI 에이전트 시스템으로 번역한 시도인 셈이다.

에이전트마다 다른 책임, PM에서 테스터까지

아니오아니오개발자: 요구사항 정의PM 에이전트기획서 스펙 작성아키텍트 에이전트시스템 설계 문서구현 에이전트 (복수)코드 구현리뷰어 에이전트코드 품질 통과?테스터 에이전트테스트 통과?개발자: 최종 검토 승인

gstack의 에이전트 구성은 실제 소프트웨어 개발 팀 구조를 반영한다. PM 에이전트는 사용자 요구사항을 분석해 기능 명세서(PRD)와 작업 우선순위를 작성하고, 모호한 요구사항을 구체적인 수용 기준(acceptance criteria)으로 변환한다. 아키텍트 에이전트는 이 명세를 바탕으로 컴포넌트 분해, 데이터 모델 설계, API 인터페이스 정의, 기술 스택 선택을 담당하며 설계 결정의 근거를 문서화한다. 구현 에이전트(들)는 아키텍트의 설계를 기반으로 실제 코드를 작성하는데, 복잡한 기능은 여러 구현 에이전트가 병렬로 작업해 개발 속도를 높인다. 리뷰어 에이전트는 구현된 코드를 코딩 표준, 보안 취약점, 성능 문제, 설계 일관성 측면에서 검토하고 개선 사항을 피드백하며, 테스터 에이전트는 유닛·통합·엣지 케이스 테스트를 작성·실행하고 실패 시 구현 에이전트에게 상세한 실패 컨텍스트를 전달한다.

에이전트 간 협업은 공유 작업 큐와 컨텍스트 저장소를 통해 이루어진다. 각 에이전트는 완료한 작업의 결과물과 결정 사항을 컨텍스트 저장소에 기록하며, 후속 에이전트는 이 정보를 읽어 작업을 이어받는다. 이 설계는 에이전트 간 컨텍스트 손실을 최소화하고 작업의 연속성을 보장한다.

Claude Code가 이 구조를 가능하게 하는 이유

gstack이 Claude Code를 핵심 엔진으로 선택한 이유는 Claude Code가 제공하는 고급 파일 시스템 조작, 터미널 명령 실행, 멀티파일 편집 역량 때문이다. 단순한 코드 생성을 넘어 프로젝트 전체 구조를 이해하고 일관된 변경을 가할 수 있는 능력이 에이전트 기반 소프트웨어 팩토리를 가능하게 하는 기술적 토대다.

gstack에서 Claude Code 활용의 핵심 패턴은 셋이다. 각 에이전트 실행 전 역할 정의, 현재 프로젝트 상태, 이전 에이전트의 결과물을 CLAUDE.md 및 컨텍스트 파일로 주입하는 컨텍스트 주입, 각 에이전트에게 역할에 필요한 도구만 허용해 예기치 않은 부작용을 방지하는 도구 범위 제한, 에이전트 간 인터페이스를 구조화된 마크다운 문서로 표준화해 파싱과 재사용을 용이하게 하는 결과물 표준화다.

PRD 생성부터 배포 승인까지, 실제 파이프라인

개발자는 자연어로 프로젝트 목표와 핵심 제약 조건을 기술한다. gstack의 PM 에이전트가 이를 분석해 기능 목록, 기술 요구사항, 단계별 마일스톤을 포함한 PRD를 자동 생성하고, 개발자가 검토·수정한 뒤 승인하면 개발 파이프라인이 시작된다.

테스터 에이전트리뷰어 에이전트구현 에이전트아키텍트 에이전트PM 에이전트개발자테스터 에이전트리뷰어 에이전트구현 에이전트아키텍트 에이전트PM 에이전트개발자요구사항 기술PRD 초안PRD 승인설계 요청설계 문서 전달코드 구현 완료리뷰 피드백수정 코드 전달테스트 결과 보고최종 검토 및 배포

실제 개발 사이클에서 에이전트들은 비동기적으로 작동한다. 구현 에이전트가 한 모듈을 작업하는 동안 리뷰어 에이전트는 이미 완료된 다른 모듈을 검토할 수 있고, 테스터 에이전트는 검토 완료된 코드에 대한 테스트를 병렬로 작성한다.

코드 작성자에서 팀을 이끄는 사람으로

gstack 모델에서 인간 개발자의 역할은 "코드를 작성하는 사람"에서 "엔지니어링 팀을 이끄는 사람"으로 전환된다. 요구사항을 명확하게 정의하는 제품 관리자 역할, 에이전트 작업 결과를 평가하는 품질 게이트키퍼 역할, 중요한 기술적 결정을 내리는 수석 엔지니어 역할, 개발 파이프라인 전체를 최적화하는 엔지니어링 매니저 역할로 무게 중심이 옮겨간다.

반면 인간 고유의 영역으로 남는 것도 있다. 비즈니스 컨텍스트와 사용자 공감에 기반한 우선순위 결정, 새로운 요구사항 발굴과 제품 방향성 설정, 법적·윤리적 판단이 필요한 결정, 외부 이해관계자와의 소통과 협상은 여전히 인간이 맡는다.

gstack이 던지는 질문들

gstack의 등장은 소프트웨어 개발 업계에 근본적인 질문을 던진다. 소프트웨어 개발에서 "팀"은 더 이상 반드시 인간들의 집합을 의미하지 않는다. AI 에이전트와 인간의 하이브리드 팀이 표준이 될 때 팀 구성, 역할, 보상, 책임의 개념은 어떻게 재정의되는가. AI 에이전트가 코드 작성의 많은 부분을 담당할 때 인간 개발자의 핵심 가치는 어디에 있는가 — 기술적 구현 능력보다 시스템 사고, 도메인 이해, 에이전트 감독 역량이 더 중요해지는가. 에이전트 생성 코드의 장기적 유지보수성·일관성·이해 가능성은 인간 작성 코드와 어떻게 다르며, 에이전트 기반 개발의 기술 부채는 어떤 형태로 나타나는가.

컨텍스트 한계와 비용이라는 현실

gstack은 유망한 실험이지만 현재 단계에서 여러 현실적 제약이 존재한다. 대형 프로젝트에서는 각 에이전트가 전체 코드베이스의 컨텍스트를 유지하기 어려워 일관성 문제로 이어질 수 있고, 에이전트들이 공유 컨텍스트를 다르게 해석하거나 설계 의도를 잘못 이해했을 때 오류가 파이프라인 전반에 전파되는 위험이 있다. 복수의 Claude Code 에이전트를 지속적으로 실행하는 비용은 상당해 복잡한 프로젝트일수록 경제성 분석이 필요하며, 의료·금융·보안 같은 특수 도메인의 암묵적 지식과 규정 준수 요구사항은 에이전트가 충분히 습득하기 어려운 영역으로 남아 있다.

gstack은 "1인 개발자가 팀을 이길 수 있는가"라는 질문에 대한 실험적이고 도전적인 대답이다. Claude Code를 활용한 다중 에이전트 협업 구조는 소프트웨어 개발의 병목을 상당 부분 해소하고, 단일 개발자가 다루기 어려웠던 규모의 프로젝트를 가능하게 하는 잠재력을 보인다. 그러나 진정한 팀이 제공하는 다양한 관점, 도메인 전문성, 창의적 충돌의 가치는 에이전트 시스템이 아직 완전히 대체하기 어려우며, 인간과 AI 에이전트의 최적 협업 모델을 찾는 탐구는 계속될 것이다.

Sources

gstackClaude Code멀티에이전트 개발AI 소프트웨어 팩토리에이전틱 코딩