(Ycombinator) Claude Code AI: How Garry Tan Built the...

핵심 요약

• 브라우저 자동화 및 적대적 검토는 중요한 문제를 조기에 포착하여 품질을 6/10에서 8/10으로 자동으로 향상시킵니다.
• Claude Code AI: 개리 탄이 궁극의 에이전트 소프트웨어 스택을 구축한 방법
  주요 내용

G 스택은 AI 기반 코딩을 혁신합니다.

• 병렬 처리는 10-15개의 동시 프로젝트를 가능하게 합니다.
• 원시적인 코딩보다는 계획 및 검토에 80-90%의 시간을 할애합니다.

주요 내용

• G 스택은 AI 기반 코딩을 혁신합니다. 실제 개발 팀을 모방하여 전문화된 기술과 역할을 가진 팀 기반 접근 방식을 구현함으로써
• 에이전트 시대는 원시적인 모델 지능이 아닌 적절한 스캐폴딩을 요구합니다. 얇은 하네스, 풍부한 기술이 승리 전략입니다. - ** Office Hours 스킬은 YC의 검증된 방법론을 재현합니다.** 강제 질문을 사용하여 구축 전에 아이디어를 검증합니다. - ** 브라우저 자동화 및 적대적 검토는 중요한 문제를 조기에 포착하여 품질을 6/10에서 8/10으로 자동으로 향상시킵니다. - ** 병렬 처리는 10-15개의 동시 프로젝트를 가능하게 합니다. 원시적인 코딩보다는 계획 및 검토에 80-90%의 시간을 할애합니다. - ** 소프트웨어 구축 장벽이 무너졌습니다.** 남은 유일한 질문은 무엇을 만들 것인가입니다.

에이전트 시대: 왜 전통적인 코딩은 구식인가

우리는 완전히 새로운 소프트웨어 개발 시대에 진입했습니다. Y Combinator의 사장 겸 CEO인 개리 탄은 Palantir에서 10년간 풀타임 엔지니어로 일했으며, Posterous를 공동 설립(트위터에 인수)하고 YC의 내부 지식 플랫폼인 Bookface를 구축했습니다. 그의 경력은 의심할 여지가 없습니다. 그리고 그의 주장은 급진적입니다. AI 에이전트로 구축하는 방식은 인간이 항상 구축해 온 방식, 즉 팀으로, 역할과 프로세스를 가지고, 검토를 통해 구축하는 방식과 동일합니다.

탄이 안드레이 카르파티(Andrej Karpathy)와 보리스 체르니(Boris Cherny)와 같은 전설적인 인물들이 수동으로 코드를 작성하는 것을 멈췄다고 인정하는 것을 들었을 때 촉매제가 작용했습니다. 그는 1월에 Claude Code를 실험하기 시작했고 "완전히 매료"되었습니다. 단 두 달 만에 그는 엔지니어로 집중적으로 일했던 마지막 해인 2013년 전체보다 더 많은 코드를 작성했습니다. 그는 본질적으로 Posterous를 재구축했습니다. 이 플랫폼은 원래 2년, 공동 창업자 한 명, 10명의 엔지니어가 필요했지만, 대부분 Claude Code 세션을 통해 이루어졌습니다. 하지만 여기에 중요한 통찰이 있습니다.

G 스택: 얇은 하네스, 풍부한 기술 프레임워크

문제를 파악한 지 3주 후, 탄은 Claude Code를 합법적인 AI 엔지니어링 팀으로 변모시키는 오픈소스 저장소인 G 스택을 구축했습니다. 그 결과는 모두를 놀라게 했습니다. 몇 주 만에 Ruby on Rails보다 더 많은 GitHub 스타를 얻었습니다. 이것은 G 스택이 화려해서가 아닙니다. 작동하기 때문입니다. 철학적 접근 방식은 우아합니다. 얇은 하네스, 풍부한 기술. 하나의 모델에게 모든 것을 어설프게 하도록 요청하는 대신, G 스택은 특정 전문 지식을 가진 팀원처럼 작동하는 전문화된 기술을 만듭니다. 각 기술은 하나의 작업을 탁월하게 처리합니다. 프레임워크는 오케스트레이션, 컨텍스트 전달 및 품질 게이트를 관리합니다. 모델은 자신의 영역에 집중합니다.시그니처 스킬은 "오피스 아워"입니다. 이는 YC 파트너들이 창업가들과 협력하는 방식을 직접적으로 본뜬 것입니다. YC의 16명 파트너들이 수천 시간을 들여 방법론을 완벽하게 다듬은 결과물의 정수입니다. 하지만 이것이 강력한 이유는 일반적인 기능 브레인스토밍이 아니라는 점입니다. 단 한 줄의 코드를 작성하기 전에 문제를 재구성하도록 강제하는 기능입니다.

오피스 아워: 아이디어를 먼저 검증하는 강제 기능

Tan과 함께 실제 사례를 살펴보겠습니다. 그는 Conductor(G Stack 인터페이스)를 열고 Gmail 및 금융 기관에서 1099-INT 세금 서류를 추출하는 도구라는 스타트업 아이디어를 구상합니다. 대부분의 개발자들은 바로 개발에 착수하겠지만, 오피스 아워는 이를 허용하지 않습니다. 이 스킬은 여섯 가지 강제 질문을 던집니다. 첫 번째 질문은 모든 것의 핵심을 꿰뚫습니다: "누군가가 이 제품을 실제로 원한다는 가장 강력한 증거는 무엇입니까? '관심 있다'거나 '대기자 명단에 등록했다'는 것이 아니라, 만약 내일 이 제품이 사라진다면 진정으로 실망할 것이라는 증거 말입니다."

후속 질문은 구체성을 요구합니다: "개인적으로 1099-INT를 놓쳐본 적이 있습니까? 아는 사람 중에 1099-INT를 놓쳐서 IRS로부터 벌금을 받은 사람이 있습니까? '이것이 필요하다'고 생각하게 만든 특정 인물이나 순간이 있었습니까? 권장 사항: 최대한 구체적으로 설명하세요. 이름, 금액, 결과 등을요. '세금 시즌은 스트레스받는다'는 수요가 아닙니다. 'Ally Bank가 보낸 1099-INT를 보지 못해서 IRS에 847달러의 벌금을 냈습니다'—이것이 바로 수요입니다."

Tan은 개인적인 경험이 있다고 확인합니다. 모델은 더 깊이 파고듭니다: 계좌는 몇 개였습니까? 어떤 은행이었습니까? 결과는 무엇이었습니까?

브라우저 자동화: 예상치 못한 강력한 한 수

대화는 브라우저 자동화로 흘러갑니다. 이는 계획 세션의 핵심이 된 비전통적인 솔루션입니다. 그 이유는 다음과 같습니다: 임의의 은행에서 세금 서류를 안정적으로 파싱할 수 없기 때문입니다. 하지만 AI 에이전트에게 브라우저를 탐색하고, Gmail을 검색하고, 문서 알림을 식별하고, 사용자가 유지하는 다른 계정에 대해 질문하고, 다단계 인증을 처리하고, PDF를 다운로드하고, 요약본을 CPA에게 보내도록 가르칠 수 있습니다. 이 모든 과정은 사용자가 클라우드가 아닌 실제 자신의 기기에서 지켜보는 가운데 이루어집니다. 이것이 두 번째 중요한 통찰력입니다: ** 신뢰. 사용자들은 AI가 무엇을 하는지 보고 싶어 합니다.** 자동화를 클라우드에 두는 것은 다른 사람의 컴퓨터에 두는 것이며 위험하게 느껴집니다. 로컬에서 실행하여 눈에 보이고 감사할 수 있게 하는 것은 완전히 다른 경험입니다. G Stack의 브라우저 기능은 AI 지원 워크플로우에서 주요 신뢰 마찰을 제거합니다.

적대적 검토: 자동화된 품질 게이트

계획 단계에서 접근 방식이 확고해진 후, 다음 기술은 "적대적 검토"를 실행합니다. 이는 문제를 자동으로 찾아내는 다단계 품질 게이트입니다. 모델에게 완벽한 코드를 만들라고 요구하지 않습니다. 모델에게 코드를 만들라고 한 다음, 그 코드를 공격합니다.첫 번째 검토에서 네트워크 오류에 대한 누락된 오류 처리, 불완전한 개인정보 공개, 2단계 인증 핸드오프 계획 부재, 병렬 은행 로그인 시도에서의 경쟁 조건 등 16가지 문제가 발견되었습니다. 시스템은 문제를 표시하고 중단하는 대신 자동 수정을 시도했습니다. 품질 점수는 10점 만점에 6점에서 8점으로 향상되었습니다. 사소한 문제들만 남았습니다. 이는 과거에 QA에 몇 주를 보냈던 팀들에게는 판도를 바꾸는 일입니다. 적대적 검토(adversarial review) 기술은 기능이 고장나는 모든 방식을 경험하고 이를 테스트하는 방법을 아는 선임 엔지니어처럼 작동합니다. 이 기술은 사람이 코드를 건드리기도 전에 실행됩니다.

디자인 샷건: 몇 분 만에 여러 변형 생성

(표준 스크럼에서 보통 한 사람의 의견에 불과한) 전통적인 CEO 검토 대신, G 스택은 여러 AI 디자인 변형을 동시에 생성하는 도구인 "디자인 샷건"을 제공합니다. 세금 앱의 주요 대시보드에 대해 세 가지 뚜렷한 옵션이 나왔습니다. 옵션 A: 커맨드 센터 는 기술적인 레이아웃으로 상세한 은행 및 문서 상태를 제시했습니다. 이는 엔지니어에게는 강력하지만, 세금을 관리하는 일반 사용자에게는 잠재적으로 부담스러울 수 있습니다. 옵션 B: 카드 기반 인터페이스 는 사용자 친화적인 형식으로 진행 상황과 누락된 문서를 보여주었습니다. 이는 즉시 공감을 얻었고, Tan은 이를 높이 평가했습니다. 옵션 C: 복잡한 다중 패널 은 너무 많은 것을 보여주려 했습니다. 직관성이 떨어졌습니다. 팀은 옵션 B를 디자인 방향으로 선택했습니다. 이는 몇 주간의 디자인 주기 대신 몇 분 만에 이루어졌습니다. 병렬 에이전트 접근 방식은 후보를 생성하고, 인간의 판단이 승자를 선택합니다.

스프린트 프로세스: 계획, 구축, 검토, 출시

G 스택은 전체 개발 수명 주기를 스프린트 프로세스인 구상 → 계획 → 디자인 → 구축 → 검토 → QA → 출시 로 체계화합니다. 각 단계에는 다음 단계로 이어지는 전담 기술이 있습니다. 직접적인 개입을 덜 원하는 사용자를 위해 "자동 계획(autoplan)"은 기본 권장 사항에 따라 CEO, 엔지니어링, 디자인 및 개발자 검토를 자동으로 실행합니다. 코드가 구축된 후, "검토(review)" 기술은 스태프 수준의 버그 검사를 수행합니다. 그런 다음 "QA"는 스크린샷 촬영, 복잡한 상호 작용 수행, 양식 작성, 미디어 다운로드, 전체 회귀 테스트 실행, JavaScript 및 CSS 문제 확인 등 브라우저 기반 테스트를 실행합니다. 마지막으로 "출시(ship)"는 통합을 위한 풀 리퀘스트를 준비합니다. 전체 워크플로는 G 스택 내 28가지 다양한 명령을 통해 사용할 수 있습니다. 이 방식은 광범위하게 채택되었으며, 사용자들은 코딩 자체보다는 계획 및 검토 단계에서 시간의 80-90%를 보낸다고 보고합니다. 이는 근본적인 변화를 나타냅니다. 즉, 품질은 생산 실패를 디버깅하는 하류 단계가 아니라 계획 및 검토와 같은 상류 단계에서 구축됩니다.

병렬 처리: 10-15개의 동시 프로젝트 관리여기서 G Stack은 단순한 도구에서 곱셈 기술로 변모합니다. Tan은 10-15개의 Claude Code 세션을 여러 프로젝트에서 동시에 실행합니다. 때로는 동일한 프로젝트에서 여러 세션을 실행하기도 합니다. 각 워크트리는 새로운 작업 항목을 나타냅니다. 아이디어가 떠오르거나, 버그 보고서가 도착하거나, X(이전 트위터)에서 G Stack에 대한 불만을 발견하면 그는 새로운 워크트리를 생성하고 '오피스 아워'를 실행하여 아이디어를 구체화합니다.

그가 처음 직면했던 병목 현상은 QA였습니다. 기획과 설계는 엄청나게 가속화되었지만, 그는 개발에서 가장 즐겁지 않은 부분인 QA를 수동으로 수행하고 있음을 발견했습니다. CLI 수준에서 Playwright를 래핑함으로써 G Stack은 이제 전체 브라우저를 사용하여 포괄적인 테스트를 수행할 수 있습니다. 이는 G Stack을 Tan이 '레벨 7 효율성'이라고 부르는 것으로 변화시켰습니다. 즉, 전체 개발 워크플로우를 통해 여러 동시 작업을 효율적으로 처리하는 것입니다. 그는 더 이상 전통적인 할 일 목록을 사용하지 않습니다. 대신, 각 아이디어나 버그는 워크트리가 됩니다. 그는 회의 일정에 따라 매일 10개, 15개, 20개, 심지어 50개의 풀 리퀘스트를 처리할 수 있습니다. 이는 그가 초인적이어서가 아닙니다.

공급망 보안: 커지는 우려

이 낙관적인 비전에 한 가지 우려가 드리워져 있습니다. 바로 공급망 공격 입니다. 코드가 대규모로 생성될 때, 어떻게 보안을 검증할 수 있을까요? Tan은 이에 대해 '상당히 편집증적'이라고 인정합니다. 다행히 G Stack은 프레임워크에 보안 도구를 내장하고 있습니다. 하지만 AI 생성 코드가 확장됨에 따라 이 부분은 여전히 경계를 늦추지 않아야 할 영역입니다.

구축 장벽의 붕괴

Tan의 더 넓은 주장은 놀랍도록 간단합니다. 바로 소프트웨어 구축의 장벽이 무너졌다는 것 입니다. 1년 전, Posterous를 구축하려면 2년, 공동 창업자, 그리고 10명의 엔지니어가 필요했습니다. 오늘날, G Stack과 Claude Code를 사용하는 한 사람이 몇 달 만에 비슷한 규모를 달성할 수 있습니다. 그 영향력은 엄청납니다. 이는 기술이 '단지 몇 퍼센트 더 좋아서'가 아닙니다. 스캐폴딩, 워크플로우, 팀 역학이 순수한 지능보다 더 중요하기 때문입니다. 컨텍스트 전환의 마찰을 제거하고, 아이디어를 검증 단계를 거치게 하며, 자동화된 품질 검사를 실행하고, 병렬 작업을 가능하게 할 때, 인간의 효율성은 기하급수적으로 증가합니다. 따라서 Tan이 던지는 질문은 실존적입니다. "남은 유일한 질문은 무엇을 만들 것인가?" 입니다. 기술적 장벽은 사라졌습니다. 지금이 행동할 때입니다.

G Stack 액세스: 당신의 길

G Stack은 github.com/garrytan/gstack 에서 오픈 소스 저장소로 제공됩니다. 실행할 첫 번째 명령어는 '/office-hours'입니다. 이는 YC에 지원하거나 투자자에게 피칭하기 전에, YC가 창업자들과 함께하는 제품 사고방식의 한 버전을 말 그대로 경험하게 해줍니다. 여기에는 유사한 반대 의견과 재구성 과정도 포함됩니다.G 스택의 배경에는 심오한 진실이 담겨 있습니다. 훌륭한 팀은 한 명의 천재 때문에 작동하는 것이 아닙니다. 프로세스, 역할, 그리고 검토가 더 나은 사고를 강제하기 때문에 작동합니다. AI 지원 개발은 이 원칙을 확장합니다. 모델은 주니어 개발자가 됩니다. 스킬은 시니어 엔지니어가 됩니다. 인간은 의사 결정자이자 전략가가 됩니다.

결론

우리는 소프트웨어 개발 방식의 근본적인 변화를 목격하고 있습니다. 개리 탄의 G 스택은 AI 지원 개발의 제한 요소가 모델 지능이 아니라 스캐폴딩, 워크플로, 그리고 프로세스임을 보여줍니다. G 스택은 모듈형 스킬을 통해 팀 역학(오피스 아워, 적대적 검토, 디자인 샷건, QA 자동화)을 구현함으로써, 클로드 코드를 코드 완성 도구에서 복잡하고 프로덕션 수준의 프로젝트를 처리할 수 있는 합법적인 AI 엔지니어링 팀으로 변화시킵니다. 수동 코딩의 시대가 끝난 것이 아니라, 변화했습니다. 성공하는 개발자는 워크플로를 설계하고, 아이디어를 엄격하게 검증하며, 에이전트가 실행을 처리하는 동안 전략적 결정을 내리는 사람들일 것입니다. 오늘날 소프트웨어를 구축하는 사람이라면 G 스택을 탐색하는 것은 선택 사항이 아닙니다. 이것이 다음 세대 제품이 구축될 방식입니다. github.com/garrytan/gstack을 방문하여 첫 오피스 아워 세션을 시작하세요. 구축의 장벽이 무너졌습니다. 이제 질문은 이것입니다: 무엇을 만들 것인가요? > 원본 출처: 개리 탄의 클로드 코드 설정 내부

제공: osmu.app