gstack 완전 가이드 4부: AI 시대의 개발 철학과 미래

“60일 만에 60만 라인” — Garry Tan의 도전

#

2026년 초, Y Combinator 대표 Garry Tan이 한 가지 놀라운 사실을 공개했다. YC를 풀타임으로 운영하면서도 단 60일 만에 60만 라인 이상의 프로덕션 코드를 작성했다는 것이다. 이는 단순한 자랑이 아니었다. gstack이라는 도구와 그 뒤에 담긴 철학이 무엇을 가능하게 하는지에 대한 증언이었다.

하루 10,000~20,000 라인. 파트타임으로. 혼자서.

이 숫자를 보고 처음에는 믿기 어려울 수 있다. 전통적인 개발 환경에서라면 불가능에 가까운 수치다. 하지만 gstack의 철학을 이해하면, 이 숫자가 어떻게 가능한지가 자연스럽게 이해된다.

4부이자 마지막 편인 이번 시리즈에서는 gstack이 단순한 도구를 넘어 하나의 개발 철학으로 기능하는 이유를 살펴본다. 세 가지 핵심 원칙, 오류 철학, 의도적 단순함, 테스팅 전략, 그리고 솔로 빌더의 미래까지.

철학 1: Boil the Lake — AI 시대에 완결성은 저렴하다

#

gstack ETHOS의 첫 번째 원칙은 Boil the Lake다. 직역하면 “호수를 끓여라"인데, 실제 의미는 이렇다: 완전한 구현을 선택하라.

전통적인 개발 관행에서는 “일단 작동하면 충분하다"는 사고방식이 지배한다. 엣지 케이스는 나중에, 테스트 커버리지는 시간이 나면, 에러 처리는 버그가 나면 고치면 된다는 식이다. 이 접근법에는 이유가 있었다 — 완전한 구현에는 시간이 많이 걸렸기 때문이다.

AI 시대에는 이 전제가 무너진다.

Lakes와 Oceans의 구분

#

gstack은 두 가지 범주를 구분한다:

• Lakes (호수): 완전한 구현이 현실적으로 가능한 것들. 100% 테스트 커버리지, 모든 엣지 케이스 처리, 완전한 에러 핸들링이 몇 분의 추가 비용으로 가능하다.
• Oceans (바다): 완전한 구현이 비현실적인 것들. 완벽한 보안, 무한한 확장성, 모든 브라우저 지원 같은 것들.

AI 에이전트를 활용하면 “Lakes"에 해당하는 것들의 비용이 극적으로 낮아진다. 100% 테스트 커버리지 작성에 AI가 투입되면 추가 시간은 몇 분에 불과하다. 그렇다면 왜 50%에서 멈추는가?

작업 미루기 거부

#

Boil the Lake의 핵심 태도는 “나중에"를 거부하는 것이다.

1
2
3
4
5
6
7
8

# 나쁜 패턴: 작업 미루기
# "TODO: 나중에 에러 처리 추가"
# "나중에 테스트 작성"
# "MVP 이후에 엣지 케이스 처리"

# gstack 방식: 지금 완결
/skill add-tests --coverage 100
/skill handle-errors --complete

AI 에이전트가 테스트를 작성하는 시대에, “나중에 테스트를 작성하겠다"는 말은 “절대 작성하지 않겠다"와 같다. gstack은 이 인식에서 출발해 처음부터 완전한 구현을 기본값으로 설정한다.

철학 2: Search Before Building — 3개 지식 레이어와 유레카 순간

#

두 번째 원칙은 Search Before Building이다. 바퀴를 재발명하지 말라는 단순한 충고처럼 들리지만, gstack은 이를 훨씬 정교하게 체계화했다.

세 가지 지식 레이어

#

모든 기술적 결정에는 세 가지 지식 레이어가 존재한다:

Layer 1 — Tried & True (검증된 방식)

수년간 전투를 거친 패턴들이다. REST API, SQL 데이터베이스, HTTP 캐싱 헤더 같은 것들. 이것들은 검증되었고 문서화도 잘 되어 있다. 하지만 AI 시대에는 가끔 “왜 이게 최선인가?“를 다시 물어볼 필요가 있다. AI 에이전트에게는 완전히 다른 트레이드오프가 적용될 수 있기 때문이다.

Layer 2 — New & Popular (새롭고 유행하는 것)

최근 6-18개월 사이에 떠오른 접근법들이다. GraphQL, Edge Functions, WebAssembly 같은 것들. 유행하고 있다는 것은 가치가 있다는 신호지만, 검증 기간이 짧다. 회의적 평가가 필요하다.

Layer 3 — First Principles (제1 원칙)

이것이 가장 가치 있는 레이어다. 당신의 구체적인 문제에 대한 독창적인 관찰. 기존 어떤 접근법도 고려하지 않은 제약 조건이나 기회를 발견했을 때 등장한다.

유레카 순간

#

gstack이 가장 중요하게 여기는 것은 유레카 순간이다. 이는 세 단계로 구성된다:

1. 기존 접근법들을 충분히 이해한다 (Layer 1 + 2 탐구)
2. 자신의 상황에 그것들을 적용해 추론한다
3. 왜 그것들이 자신의 상황에서는 최적이 아닌지 발견한다

gstack의 브라우저 자동화가 좋은 예다. CSS 셀렉터 기반의 접근법(Layer 1)이 있었다. Playwright의 테스트 레코더(Layer 2)가 있었다. 그런데 gstack 팀은 AI 에이전트에게는 ARIA 접근성 트리가 훨씬 안정적이고 프레임워크 독립적이라는 사실을 발견했다 — Layer 3 통찰이다.

철학 3: User Sovereignty — AI는 추천하고 인간이 결정한다

#

세 번째 원칙은 가장 철학적이면서도 가장 실용적이다. User Sovereignty — 사용자 주권.

핵심 명제: “AI 모델은 추천한다. 사용자가 결정한다.”

두 모델의 동의 ≠ 명령

#

흔한 오해가 있다. “Claude도 그렇게 말하고 GPT도 그렇게 말하니까 맞는 거다"는 논리. gstack은 이를 명시적으로 거부한다.

두 모델이 동의한다는 것은 그 견해가 훈련 데이터에서 일반적이었다는 뜻일 뿐이다. 당신의 구체적인 컨텍스트 — 팀 크기, 기술 부채, 비즈니스 제약, 레거시 시스템 — 에 대한 정보는 어떤 모델도 완전히 파악할 수 없다.

Generation-Verification 루프

#

gstack의 실제 워크플로우는 이 원칙을 코드로 구현한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# AI가 추천 생성
/skill suggest-architecture

# 이유와 함께 제시 (단순 결론 아님)
# "이 접근법을 추천하는 이유:"
# "1. 현재 코드베이스 패턴과 일치"
# "2. 기존 의존성 활용"
# "3. 팀 크기에 적합"
# "대안: X (장점/단점 포함)"

# 사용자가 검토 후 결정
/skill implement-architecture --approach chosen-option

AI가 추천을 이유와 함께 제시하고, 사용자가 그 이유를 평가해 최종 결정을 내린다. 이것이 “묻고 행동하는” 원칙이다.

Iron Man Suit 철학

#

gstack이 자주 인용하는 비유가 있다: AI는 Iron Man Suit다.

토니 스타크가 아이언맨 슈트를 입었을 때, 슈트는 엄청난 능력을 부여하지만 토니가 결정권자다. 슈트가 “저기에 폭탄을 던져야 합니다"라고 제안할 수 있지만, 최종 결정은 토니가 한다. 슈트가 토니를 대체하는 것이 아니라 증강(augment)한다.

gstack의 AI 에이전트들도 마찬가지다. 엄청난 속도로 코드를 생성하고, 테스트를 작성하고, 브라우저를 자동화하지만 — 아키텍처 방향, 비즈니스 우선순위, 기술 트레이드오프는 인간이 결정한다.

오류 철학: 에이전트를 위한 에러 메시지

#

gstack의 오류 처리 철학은 파격적이다: 에러 메시지는 인간이 아닌 AI 에이전트를 위한 것이다.

나쁜 에러 vs 좋은 에러

#

전통적인 에러 메시지:

1
2
3
4

Error: Element not found
  at findElement (browser.js:142)
  at navigate (browser.js:89)
  at main (index.js:23)

이 스택 트레이스는 인간 개발자가 디버깅할 때는 유용하다. 하지만 AI 에이전트에게는 쓸모없다. 에이전트는 “그래서 내가 뭘 해야 하지?“를 모른다.

gstack의 에러 메시지:

1
2
3

Error: Element not found — ref 'btn-submit' is no longer in the DOM
Action: Run /browse snapshot -i to see currently available elements
Available refs in last snapshot: [ref-1, ref-2, ref-3]

모든 에러는 actionable해야 한다. 에러가 발생했을 때 다음 행동이 명확해야 한다.

충돌 복구: 재시작으로 해결

#

gstack의 또 다른 독특한 선택: 복잡한 재연결 로직 대신 재시작을 기본 복구 전략으로 선택했다.

WebSocket 연결이 끊어졌을 때 재연결하는 복잡한 로직을 구현하는 대신, 브라우저 데몬을 재시작한다. 이것이 더 단순하고, 상태 불일치 버그가 없으며, AI 에이전트가 이해하기도 쉽다.

의도적으로 구현하지 않은 것들 — 단순함의 가치

#

gstack에서 가장 흥미로운 설계 결정 중 일부는 무엇을 구현하지 않았느냐다.

WebSocket 스트리밍 — 필요 없다

#

많은 AI 도구들이 실시간 스트리밍을 위해 WebSocket을 사용한다. gstack은 HTTP 폴링으로 충분하다고 판단했다. 이유:

• AI 에이전트는 사람처럼 실시간 스트리밍 UI가 필요 없다
• HTTP는 더 단순하고, 캐싱이 가능하며, 디버깅이 쉽다
• 결과를 받는 것과 진행 상황을 보는 것은 다른 문제다

MCP 프로토콜 — JSON 스키마 오버헤드

#

Model Context Protocol은 훌륭한 표준이지만, gstack은 자체 스킬 시스템을 선택했다. MCP의 JSON 스키마 직렬화/역직렬화 오버헤드가 gstack의 사용 패턴에서는 이점보다 비용이 컸기 때문이다.

멀티유저 지원 — 범위 외

#

gstack은 단일 개발자 또는 단일 팀의 로컬 개발 도구다. 멀티유저 SaaS를 목표로 하지 않는다. 이 범위 제한이 코드베이스를 극적으로 단순하게 유지한다.

Linux/Windows 쿠키 복호화 — 지원 안 함

#

macOS의 Keychain 쿠키 복호화는 지원하지만, Linux의 gnome-keyring이나 Windows의 DPAPI는 지원하지 않는다. 복잡성 대비 가치가 낮다고 판단했기 때문이다. 이 결정에 동의하지 않는 사용자들도 있지만, gstack 팀은 이 트레이드오프를 명시적으로 선택했다.

단순함은 기능이다. 구현하지 않은 것들이 gstack을 이해하기 쉽고, 유지보수하기 쉽고, 신뢰할 수 있게 만든다.

테스팅 철학: Tier 1/2/3 비용 대비 효과

#

gstack의 테스트 전략은 비용과 커버리지를 동시에 최적화한다. 세 가지 티어로 구성된다.

Tier 1: 정적 검증 (무료, 5초 이내)

#

1
2
3
4

# 명령어 파싱 검증
# 스킬 레지스트리 유효성 확인
# 타입 체크
# 린팅

• 비용: 무료 (로컬 실행)
• 시간: 5초 미만
• 커버리지: 모든 커밋에서 실행
• 목적: 명백한 오류 즉시 차단

이 레이어는 항상 실행된다. CI/CD 파이프라인의 첫 번째 단계이며, 실패하면 다음 단계로 가지 않는다.

Tier 2: E2E 테스트 (약 $3.85, 20분)

#

1
2
3

# 실제 Claude 세션으로 각 스킬 테스트
# 실제 브라우저 자동화 검증
# 실제 API 호출

• 비용: 스킬당 약 $3.85 (Claude API 비용)
• 시간: 전체 약 20분
• 커버리지: PR 또는 릴리스 전
• 목적: 실제 환경에서의 동작 검증

이 레이어는 비용이 있지만 허용 가능한 수준이다. $3.85로 전체 스킬 스위트의 E2E 커버리지를 얻는다면 합리적인 투자다.

Tier 3: LLM-as-Judge (약 $0.15, 30초)

#

1
2
3

# Sonnet이 문서 명확성 평가
# 스킬 설명의 AI 가독성 점수
# 에러 메시지 actionability 평가

• 비용: 약 $0.15
• 시간: 30초
• 커버리지: 문서 및 프롬프트 품질
• 목적: AI 에이전트가 올바르게 이해하는지 검증

이 세 번째 레이어가 특히 흥미롭다. AI가 도구를 올바르게 사용하려면 문서와 에러 메시지가 AI에게 명확해야 한다. 인간이 읽기 좋은 것과 AI가 파싱하기 좋은 것은 다를 수 있다. LLM-as-Judge는 이 갭을 측정한다.

솔로 빌더의 시대: 미래 개발자의 역할 변화

#

gstack이 그리는 미래는 개발자의 역할이 근본적으로 변화하는 세계다.

코더에서 오케스트레이터로

#

과거의 개발자는 코드를 직접 작성하는 사람이었다. IDE를 열고, 함수를 타이핑하고, 버그를 추적하는 것이 일상이었다. 하루에 수백 라인을 작성하는 것도 훌륭한 생산성이었다.

gstack 시대의 개발자는 오케스트레이터다. 10-15개의 AI 에이전트를 동시에 조율하고, 아키텍처 결정을 내리고, 방향을 설정하고, 결과를 검증한다. 타이핑 속도가 아닌 판단력이 병목이 된다.

이 변화는 어떤 기술이 중요해지는지를 바꾼다:

줄어드는 중요성:

• 특정 언어/프레임워크 암기
• 타이핑 속도
• 저수준 구현 세부사항

커지는 중요성:

• 시스템 사고와 아키텍처 감각
• AI 에이전트 지시 및 평가 능력
• 비즈니스 요구사항을 기술 명세로 번역
• 결과물의 품질 판단

1인 팀의 가능성

#

Garry Tan의 사례는 극단적인 예시지만, 방향을 보여준다. 과거에는 10명이 필요했던 프로젝트를 혼자 해낼 수 있는 가능성. 단, 이를 위해서는 올바른 도구와 올바른 철학이 필요하다.

gstack은 그 철학을 코드로 구현한 것이다.

gstack 시리즈 총정리 + 시작하는 방법

#

4개의 포스트에 걸쳐 gstack의 전체 모습을 살펴봤다.

1부: 소개와 개요

• gstack이 무엇인지, 왜 만들어졌는지
• 핵심 구성요소: Skills, Browser Automation, Conductor
• 62,600+ GitHub stars의 오픈소스 생태계

2부: 설치와 워크플로우

• macOS 설치 (5분 이내)
• Claude Desktop 연동
• 기본 스킬 실행과 커스텀 스킬 작성
• .gstack/ 프로젝트 설정

3부: 브라우저 자동화와 멀티에이전트

• ARIA 기반 Ref 시스템
• 3계층 브라우저 데몬 아키텍처
• Conductor를 통한 10-15 에이전트 병렬 실행
• 실전 사용 패턴

4부: 철학과 미래 (이번 포스트)

• Boil the Lake, Search Before Building, User Sovereignty
• 에이전트를 위한 에러 철학
• 의도적 단순함
• 솔로 빌더의 미래

지금 시작하기

#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. 설치
brew install gstack

# 2. 프로젝트 초기화
cd your-project
gstack init

# 3. Claude에게 gstack 사용 권한 부여
# Claude Desktop Settings → MCP → gstack 활성화

# 4. 첫 번째 스킬 실행
/list-skills
/run-tests

gstack GitHub: github.com/gstack/gstack

마무리: “AI 시대의 Iron Man Suit”

#

gstack을 처음 접하면 도구처럼 보인다. 스킬을 실행하고, 브라우저를 자동화하고, 에이전트를 병렬로 돌리는 유틸리티.

하지만 더 깊이 들여다보면 이것은 개발 철학의 구현이다.

• 완전성은 비싸지 않다 — AI 시대에는. (Boil the Lake)
• 먼저 찾아보라, 그다음 만들어라. (Search Before Building)
• AI는 슈트다, 드라이버가 아니다. (User Sovereignty)

Garry Tan이 60일 만에 60만 라인을 작성할 수 있었던 것은 단지 좋은 도구가 있었기 때문이 아니다. AI 에이전트를 어떻게 활용해야 하는지에 대한 명확한 철학이 있었기 때문이다.

솔로 빌더의 시대는 이미 시작되었다. gstack은 그 시대를 위한 Iron Man Suit다.

gstack 완전 가이드 시리즈

• 1부: gstack 소개 — AI 에이전트 시대의 개발 도구
• 2부: 설치와 핵심 워크플로우
• 3부: 브라우저 자동화와 멀티에이전트
• 4부: AI 시대의 개발 철학과 미래 ← 현재 포스트