개리 탄: AI를 채팅창 대신 운영체제로 만드는 법
9분

개리 탄: AI를 채팅창 대신 운영체제로 만드는 법

X (개리 탄, @garrytan) 원문 보기 ↗

YC CEO 개리 탄은 AI를 채팅창이 아닌 운영체제로 직접 구축했습니다.

100개 스킬 파일과 10만 페이지 지식 베이스가 그 핵심 구조입니다.

개인이 구축한 복리 AI 시스템이 기업용 AI 도구를 앞서는 시대가 열렸습니다.

AI를 채팅창으로만 쓰고 계십니까?
YC CEO는 AI에게 100가지 스킬을 가르쳐 조직을 운영합니다.

오늘 AI를 몇 번 쓰셨습니까? 대부분의 경우, 질문 하나를 던지고 답을 받고 끝납니다. 내일도 같은 질문을 다시 합니다. 어제 했던 대화는 사라졌습니다.

Y Combinator CEO 개리 탄은 다르게 씁니다. 그는 100개 스킬 파일과 10만 페이지 지식 베이스로 구성된 개인 AI 운영체제를 직접 설계했습니다. 매일 밤 2시까지 코딩하며 이 시스템을 공개했습니다. 채팅창과 운영체제의 차이가 무엇인지, 이 글이 설명합니다.

2026년 AI 활용의 격차는 '쓰느냐, 안 쓰느냐'가 아닙니다. 채팅창에서 질문 하나 던지고 끝내는 AI와 다릅니다. 내 업무·인맥·독서를 매일 축적하는 AI 시스템이 다른 결과를 만듭니다. 개리 탄의 시스템은 하루가 지날수록 더 유용해집니다. 이 격차가 5년 후 조직 역량을 결정합니다.

100,000
지식 베이스 페이지 수
(인물·회의·책·아티클 포함)
100+
운용 중인 스킬 파일 수
(각각 1개 업무에 집중)
40분
162페이지 책을 개인화하는
AI 처리 시간

첫째, 얇은 하네스와 두꺼운 스킬이 핵심 구조입니다. 하네스는 수천 줄의 라우팅 코드입니다. 요청을 받아 어떤 스킬을 쓸지 결정하는 역할만 합니다. 스킬은 하나의 업무에 집중한 상세 지시 마크다운 파일입니다. 스킬 파일 안에 모든 운영 지식이 담겨 있습니다. 스킬 하나를 개선하면 그 스킬을 쓰는 모든 업무가 자동으로 개선됩니다.

둘째, 10만 페이지 지식 베이스가 복리 기반을 만듭니다. 개리 탄의 시스템은 만나는 모든 인물, 모든 회의, 읽는 모든 책을 자동으로 기록합니다. 각 페이지는 현재 상태, 타임라인, 원본 데이터로 구조화됩니다. 회의가 끝나면 AI가 언급된 모든 인물과 기업 페이지를 자동 업데이트합니다. 이것은 파일 캐비닛이 아닙니다. 변화를 감지하고 지금 필요한 것을 꺼내주는 신경망입니다.

셋째, 스킬파이(Skillify)가 메타-메타-프롬프팅의 핵심입니다. 예를 들어, 고객 미팅 전 준비 과정을 처음 AI와 함께 수행했다고 합니다. 그 과정을 Skillify에 맡기면 "매번 이 순서로 하라"는 스킬 파일이 자동 생성됩니다. 다음부터는 같은 준비가 자동으로 실행됩니다. 개리 탄은 이 방식으로 '책 미러' 스킬을 만들었습니다. 162페이지 책 22개 챕터를 개인 맥락으로 변환하는 데 40분이 걸렸습니다.

넷째, 모델은 엔진에 불과합니다. 스킬과 지식이 자동차입니다. 개리 탄은 Opus 4.7, GPT-5.5, DeepSeek V4-Pro를 스킬 성격에 따라 선택합니다. 어느 AI 모델이 최고냐는 질문은 틀린 질문입니다. 같은 엔진을 얹어도 어떤 차를 설계했느냐가 성능을 결정합니다. "미래는 복리 AI 시스템을 구축하는 개인에게 있다"고 탄은 말합니다.

용어 설명

하네스(Harness): AI에게 사용자의 요청을 받아 어떤 스킬을 실행할지 결정하는 라우팅 미들웨어입니다.

스킬 파일(Skill File): 하나의 업무에 집중한 상세 지시 마크다운 파일입니다. 재사용 가능한 AI 프롬프트 인프라입니다.

스킬파이(Skillify): 반복 업무의 패턴을 분석해 새 스킬 파일을 자동 생성하는 메타-스킬입니다. 스킬을 만드는 스킬입니다.

엔티티 전파(Entity Propagation): 회의 후 언급된 모든 인물·기업 페이지를 AI가 자동으로 업데이트하는 프로세스입니다.

1
GBrain으로 핵심 인물 페이지 1개를 만듭니다.
github.com/garrytan/gbrain에서 설치합니다. 주요 협력사 대표나 핵심 고객 1명을 선택합니다. 이름, 최근 동향, 우리 회사와의 접점을 한 파일에 정리합니다. Claude에 "이 사람과의 다음 미팅 전에 알아야 할 핵심 3가지를 뽑아줘"라고 요청합니다. (설치 30분, 페이지 작성 30분)
2
이번 주 반복 업무 1개를 스킬 파일로 정의합니다.
매주 작성하는 보고서, 또는 고객 미팅 전 준비 과정을 고릅니다. 완료 직후 Claude에 요청합니다. "내가 방금 한 작업의 단계를 분석하고 재사용 가능한 지시 파일로 정리해줘." 저장된 파일을 팀 폴더에 넣으면 팀 전체가 동일 품질을 낼 수 있습니다. (2시간)
3
다음 외부 미팅 전에 AI 컨텍스트 팩을 준비합니다.
상대방 이름과 소속을 Claude에 입력합니다. "공개 정보를 바탕으로 이 사람의 관심사와 우리 회사의 접점 3개를 찾아줘. 각 접점에 대화를 시작할 질문을 달아줘"라고 요청합니다. (30분)

생산량이 품질을 보장하지 않습니다. 개리 탄이 하루 37,000줄의 AI 생성 코드를 공개한 직후, 한 개발자가 그의 사이트를 감사했습니다. 78,400줄 AI 코드가 홈페이지 1회 로드에 6.42MB, 169개 요청을 발생시켰습니다. (출처: gregorein, X, 2026) AI가 생성한 코드는 반드시 별도 검증 단계가 필요합니다. 빠른 생산과 신뢰할 수 있는 품질은 다른 문제입니다.

시스템 구축 초기 비용이 상당합니다. 개리 탄 본인도 "첫 번째로 만든 것은 형편없었다"고 말합니다. 100번째 스킬에 이르러서야 신뢰할 수 있는 수준이 됩니다. 처음 3개월은 결과물보다 시스템 구축에 시간을 써야 합니다. 복리 효과는 초기에 보이지 않습니다. 팀에게 이 현실을 미리 설명해야 합니다.

특정 모델과 플랫폼 의존성이 생깁니다. 이 시스템은 Opus 4.7, GPT-5.5 등 최신 모델에 최적화됩니다. 모델 버전이 바뀌거나 API 가격이 변경되면 기존 스킬 파일을 수정해야 합니다. 오픈소스 기반이지만 인프라 유지 비용이 지속적으로 발생합니다. 도입 전에 유지 담당자를 지정해야 합니다.

AI를 채팅창이 아닌 복리 시스템으로 구축하는 것이 다음 5년의 핵심 경쟁력입니다. 지금 시작하지 않으면 격차는 매일 벌어집니다.

창업자/CEO AI 활용 전략을 '도구 도입'에서 '시스템 구축'으로 재정의합니다. GBrain 구조를 참고해 조직 AI 아키텍처를 설계합니다.
팀장 팀에서 반복되는 업무 3가지를 스킬 파일로 정의합니다. 한 번 만든 스킬은 팀 전체가 재사용합니다.
임원 지식 베이스 구축을 조직 투자 항목으로 승인합니다. 첫 분기는 시스템 구축에, 두 번째 분기부터 복리가 작동합니다.
  • Tan, G. (2026, May). Meta-Meta-Prompting: The Secret to Making AI Agents Work [Article]. X. (원문 보기 ↗)
  • gregorein. (2026, April). I audited Garry's website after he bragged about 37K LOC/day [Article]. X. (원문 보기 ↗)
라운드테이블
B
블랙 · 중견기업 임원
솔직히 이거 보고 충격받았어요. 저는 AI를 매일 쓰는 줄 알았는데, 채팅창에서 질문 하나 던지고 끝냈던 거잖아요. 스킬 파일 개념 자체가 완전히 달라요.
R
레드 · 저널리스트
근데 이분 YC CEO잖아요. 하루에 밤 2시까지 코딩할 수 있는 사람이 얼마나 있어요? 시스템 구축 자체가 전업 수준의 시간 투자인데, 일반 조직에서 따라 할 수 있는 구조인가요?
B
블랙 · 중견기업 임원
전체를 따라 하라는 게 아니죠. 스킬 파일 3개만 만들어도 팀 반복 업무 30%가 표준화돼요. 처음부터 100개를 목표로 안 하면 됩니다.
N
네이비 · 시니어 엔지니어
37K LOC 얘기는 빠져 있는데, 본문 리스크에 제대로 짚었어요. 감사 결과가 정직하게 인용됐고요. 생산량이 품질이 아니라는 게 핵심인데, 이건 AI 코딩 전반에 해당하는 경고예요.
G
골드 · 창업자
저는 다르게 봐요. 6.42MB 로딩이 문제가 되는 건 코드 품질 이슈고, 시스템 구조 자체는 별개예요. 지식 베이스와 스킬 파일 개념은 코드 품질 논란과 분리해서 봐야 합니다.
W
화이트 · 조직장
스킬 파일 개념을 팀에 적용하면 가장 먼저 막히는 게 뭔지 아세요? "그거 누가 관리해요?"예요. 개인 시스템이라면 괜찮은데, 조직 단위로 가면 소유권이 불분명해집니다.
P
퍼플 · 마케터
그래서 팀 단위로 가기 전에 개인 실험이 먼저라고 봐요. 나 혼자 쓸 스킬 파일 5개 만들어서 6개월 써보고, 그게 팀에 공유할 만하면 그때 확장하는 거죠. 조직 도입 전에 개인 검증 단계가 있어야 해요.
W
화이트 · 조직장
그 말이 맞아요. 조직 단위로 갔다가 관리 주체 없이 스킬 파일만 쌓이면 두 번째 서랍이 생기는 거니까요. 개인 검증 후 팀 표준화, 이 순서가 현실적입니다.
_posts/2026-05-10-garry-tan-meta-meta-prompting-personal-ai.md