gstack을 Antigravity로 포팅

AI 코딩 도구를 쓰다 보면 비슷한 순간이 온다.

1. 처음에는 “정말 똑똑하네”에서 시작한다.
2. 그다음에는 “이걸 어떻게 더 잘 시킬까?”로 넘어간다.
3. 그리고 조금 더 쓰다 보면 결국 이런 고민을 하게 된다.

이걸 팀처럼 일하게 만들 수는 없을까?

내가 gstack에 관심을 가진 이유도 여기에 있었다.

gstack은 스스로를 단순한 스킬 모음이 아니라, Claude Code를 하나의 가상 엔지니어링 팀처럼 움직이게 만드는 방식으로 설명한다. 

CEO, 엔지니어링 매니저, 디자이너, 리뷰어, QA 리드, 보안 담당, 릴리즈 엔지니어 같은 역할이 나뉘어 있고, 전체 흐름이 Think → Plan → Build → Review → Test → Ship → Reflect로 설계되어 있다. 

즉, 핵심은 프롬프트 몇 개가 아니라 역할 분리와 작업 순서에 있다.

요즘 AI 도구들은 대부분 “잘 대답하는가?”에 초점이 맞춰져 있다. 그런데 gstack은 한 걸음 더 들어가서 “어떤 순서로 일하게 만들 것인가”를 다룬다. 

1. `/office-hours`로 문제를 다시 정의하고, 
2. `/plan-ceo-review`와 `/plan-eng-review`로 범위와 구조를 다듬고, 
3. `/review`, `/qa`, `/ship`으로 마무리하는 흐름은 실제 팀이 일하는 방식과 꽤 닮아 있다. 

그래서 gstack을 처음 봤을 때 든 생각은 신기하다보다 이건 실무에 더 가깝다는 쪽이었다.

그런데 여기서 다음 질문이 생겼다.

좋은 건 Claude Code 자체일까, 아니면 gstack의 워크플로우일까?

gstack은 Claude Code 중심으로 설계돼 있다. 

설치 구조도 Claude 체계를 전제로 하고 있고, 브라우저 자동화 역시 자체 browse 흐름을 기준으로 설명한다. 

ARCHITECTURE 문서에서는 persistent browser와 long-lived Chromium daemon을 유지해서 첫 호출 이후에는 빠르게 재사용하고, 세션과 탭 상태도 이어가는 방식이라고 설명한다. 

즉, 원본 gstack은 단순한 명령어 모음이 아니라 브라우저 기반 검증과 리뷰까지 포함한 일종의 소프트웨어 팩토리에 가깝다.

그래서 Antigravity로의 포팅은 이름만 바꾸는 작업이 될 수 없었다. 그냥 복사해서 붙여넣는다고 되는 구조가 아니었기 때문이다.

gstack의 핵심은 명령어 목록 그 자체가 아니라, 그 명령들이 어던 런타임 위에서 어떤 철학으로 연결되는가에 있다.

결국 이 작업은 포팅이라기보다 번역에 가까웠다. 원본의 철학과 흐름을 이해한 뒤, 그것을 Antigravity의 문법으로 다시 써야 했기 때문이다.

gstack-antigravity는 바로 이 관점에서 시작되었다. 물론 내가 antigravity를 자주 사용하는 이유도 있었다.

내가 사용하기 위해서는 Antigravity 환경에 맞춘 네이티브 포팅이 필요했고, 그 과정에서 Thin Router Architecture, Native Browser Integration, Cross-Platform Parity를 고민하게 됐다. 

즉, 원본을 그대로 흉내 내는 포크가 아니라, 원본 워크플로우를 Antigravity 쪽에서 오래 버틸 수 있게 다시 설계한 포팅이라고 보는 편이 맞다.

또 하나는 토큰 문제였다.

AI 워크플로우를 오래 쓰다 보면 언젠가는 비슷한 문제를 겪게 된다.

처음에는 잘 되는데, 문맥이 길어질수록 점점 느려지고, 작업이 커질수록 흐름이 흐트러진다. 특히 역할과 규칙이 많아질수록, 매번 모든 설명을 통째로 들고 다니는 방식은 금방 무거워진다. 

gstack-antigravity는 이 문제를 해결하기 위해, 가벼운 규칙 파일이 먼저 라우터처럼 동작하고 실제 워크플로우가 호출될 때만 필요한 내용을 읽어오는 방향을 택했다.

모든 걸 항상 들고 있는 구조가 아니라, 필요한 순간에 필요한 것만 가져오는 구조를 지향하는 셈이다.

이런 종류의 포팅이 실패하는 가장 흔한 이유는 원본 시스템의 방식을 너무 고집해서, 새 환경이 이미 잘하는 것을 못 쓰는 경우다. 

그래서 gstack-antigravity는 원본처럼 별도의 브라우저 체계를 억지로 유지하기보다 Antigravity가 제공하는 네이티브 브라우저 도구를 우선 활용하는 방식으로 정리했다.

나는 이 방향이 꽤 중요하다고 생각한다. 좋은 포팅은 원본을 똑같이 복제하는 것이 아니라, 원본의 철학을 유지한 채 새 환경이 잘하는 방식을 받아들이는 일에 더 가깝기 때문이다.

그리고 이 포팅은 antigravity-skills와 함께 쓰면 더 효율적이다. 실제 작업할 때는 큰 흐름을 잡아주는 운영체계와 세부 작업을 도와주는 스킬셋을 나눠 쓰는 편이 훨씬 효율적이다.

gstack-antigravity가 생각-계획-구현-리뷰-QA-배포 같은 전체 흐름을 잡아주는 쪽이라면, antigravity-skills는 브레인스토밍이나 계획 작성 같은 작업 단위 스킬을 보강하는 쪽에 가깝다.

개인적으로 이 조합이 괜찮다고 느껴지는 이유는 현실의 작업 방식과도 잘 맞기 때문이다.

실제 일은 처음부터 끝까지 한 가지 모드로만 흐르지 않는다. 

• 어떤 날은 아이디어를 넓게 보는 시간이 필요하고, 
• 어떤 날은 빠르게 계획을 해야 하며, 
• 어떤 날은 리뷰와 QA가 더 중요하다. 

이럴 때 gstack-antigravity가 전체 뼈대를 잡아주고, antigravity-skills가 필요한 순간에 세부 스킬을 보강해주면 흐름이 훨씬 부드러워진다. 

예를 들어 새로운 기능을 시작할 때는 먼저 @brainstorming으로 문제를 살펴보고, 그다음 gstack 스타일의 계획 흐름으로 구조를 잡고, 구현 이후에는 리뷰와 QA로 마무리하는 식이다. 

즉, 이 둘은 경쟁 관계라기보다 운영체계와 도구 상자라고 표현하는 편이 더 맞다.

AI 도구를 오래 써보면 결국 필요한 건 “더 똑똑한 답변”만이 아니다. 오히려 더 절실한 건 흐트러지지 않는 작업 흐름, 길어져도 무너지지 않는 문맥 관리, 실제로 계속 쓸 수 있는 운영 방식이다. 

gstack-antigravity는 원본 gstack의 핵심인 역할 분리, 스프린트형 흐름, 작업 철학을 유지하면서, 그것을 Antigravity 환경에 맞게 다시 설계한 포팅이다. 

이 과정에서 얇은 라우팅 구조를 통한 문맥 경량화, Antigravity 네이티브 브라우저 도구 활용, 크로스 플랫폼 대응을 함께 고민했다. 

여기에 antigravity-skills 같은 실전 스킬 저장소를 함께 붙이면, 전체 흐름과 세부 작업을 나눠서 다루는 좀 더 현실적인 작업 방식이 만들어진다.

혹시, 써보고 싶은신 분들은 아래를 참고하세요.

https://www.npmjs.com/package/@runchr/gstack-antigravity

다음 글에서는 paperclipai + opencode 같은 조합으로 여러 Agent를 회사 조직처럼 묶어서 운영하는 방법에 대해 정리해보려고 합니다.