게리 탄은 13년 동안 코드를 거의 쓰지 않았어요. 마지막으로 본격적으로 개발했던 게 2013년인데, 올해 다시 키보드 앞에 앉았더니 그때보다 400배 많은 코드를 쓰고 있다고 합니다. 세계 최대 액셀러레이터 YC를 풀타임으로 운영하면서, 한 번 만드는 데 400만 달러·1년 반이 들었던 블로그 서비스를 이번엔 200달러로 5일 만에 다시 만들어버렸고요.
그가 정리한 비결은 단 하나, "토큰을 마음껏 태워라"였습니다. 1인 창업가가 진짜 팀 규모로 일할 수 있느냐는 논쟁 한가운데, 게리 탄은 가장 극단적인 증거를 들고 나타났어요. 이번 라이트콘 에피소드에서 그가 직접 풀어놓은 작업 방식을 그대로 옮겼습니다.
13년 만의 코딩 복귀와 Garry's List
Q. 13년 만에 다시 코딩을 시작하게 된 계기가 뭐였나요?
저 자신도 놀라고 있어요. 직접적인 계기는 라이트콘 에피소드 중 하나였어요. 그 에피소드를 끝내고 나서, 캘리포니아, 특히 샌프란시스코에 대해 같은 생각을 가진 사람들을 한데 모으고 싶다는 생각이 들었거든요. 그래서 정책 활동을 할 수 있는 비영리 단체를 만들었고, 지금은 후원금을 받는 재단과 직접 선거 운동까지 할 수 있는 정치 모금 조직도 만들었어요. 정치 단체들이 흔히 쓰는 구조예요. 다들 돈에만 초점을 맞추는데, 사실 핵심은 똑똑한 사람들을 모으는 거거든요.
이미지 출처 : garryslist.org
샌프란시스코 정치에서 일하면서 배운 게 하나 있다면, 사람을 한데 모으는 일이 얼마나 강력한지예요. 그게 곧 대중 사회 운동이잖아요. 그래서 생각했죠. "그럼 그걸 시작할 웹사이트를 그냥 내가 만들어버리자."
Q. 첫 번째로 만든 게 Garry's List(게리 탄이 운영하는 캘리포니아 정치·정책 미디어 사이트)였잖아요. 어떻게 시작했나요?
처음엔 그냥 제가 걱정하는 이슈들에 대해 글을 쓰는 것부터 시작했어요. 예를 들어 저는 아이들이 학교에서 제대로 배우길 원하거든요. 전 세계에서 이 영상을 보는 분들은 좀 이상하게 느끼실 텐데, 샌프란시스코 공립학교에서는 중학교 1, 2학년이 대수학(algebra)을 듣는 게 거의 불가능에 가까웠어요. 지금도 아주 어려워요.
이미지 출처 : @garrytan, X
이게 저한테는 정말 가슴 아픈 일이었어요. 저는 베이 에어리어 동쪽의 공립학교에서 그 수업을 들을 수 있었기 때문에 스탠퍼드에서 공학을 공부할 수 있었고, 코드를 쓸 수 있었고, 이 모든 일을 할 수 있었거든요. 만약 그때 대수학을 못 배웠다면 지금 여기 있지도 못했을 거예요. 그래서 "이제 코드를 쓸 때가 됐다"고 결심했죠.
결과적으로 제가 2008년 YC에서 했던 첫 스타트업인 Posterous(포스터러스)를 다시 만들게 됐어요. 그게 지금의 Garry's List의 출발점이에요.
Q. Posterous는 어떤 서비스였죠?
이메일로 글을 쓰면 그게 곧 블로그가 되는, 정말 단순한 블로그 서비스였어요. 인터넷 상위 200대 사이트까지 성장했고, 결국 트위터가 약 2천만 달러에 인수했어요. 사실상 제 첫 큰 성공이었죠.
트위터가 인수한 뒤에 서비스를 종료해버려서, 제가 Post Haven이라는 이름으로 한 번 더 만들었어요. 트위터한테서 서비스를 다시 사오려면 200~300만 달러가 들었는데, 당시엔 그만한 돈이 없었거든요. 그래서 차라리 다시 만들었죠.
이미지 출처 : 나노바나나 제작
그리고 올해 1월에 세 번째로 다시 만들었어요. 비교해보면 흥미로워요. 첫 번째는 약 400만 달러, 6~7명, 1년 반이 걸렸어요. 두 번째는 약 10만 달러, 두 사람(저와 공동창업자 브렛 깁슨, 지금은 Initialized 대표), 약 3개월이 걸렸고요. 세 번째는 약 200달러, 그것도 클로드 코드 맥스 계정 비용이었고, 시간은 5일밖에 안 걸렸어요. 그 세 번째 버전이 바로 지금의 Garry's List예요.
Q. 5일이라니, 단순한 블로그 클론은 아니었을 텐데요.
정말 모든 기능이 다 들어간 블로그 플랫폼이었어요. 그 위에 풀 RAG(검색으로 가져온 자료를 LLM이 참고해서 답하는 방식), 풀 에이전틱 검색(여러 AI 에이전트가 능동적으로 자료를 찾아오는 방식)까지 다 얹었어요. 인터넷 전체를 읽어들이고, 제 트윗을 전부 수집하고, 어떤 주제든 재귀적으로 크롤링하고 딥리서치를 할 수 있어요.
대수학 이야기는 제가 정말 신경 쓰는 여러 이슈 중 하나일 뿐이거든요. 그래서 인터넷에 있는 자료를 다 가져와서 찬반 양쪽 주장을 모두 보고, 백엔드에서 매우 상세한 보고서를 만들 수 있게 했어요. 라이트콘 초기 에피소드 중 제이크 헬러(Jake Heller) 편 기억하시는 분 있을 거예요. 제이크가 Casetext(AI 법률 리서치 서비스)를 만들었는데, 그가 설명한 방식을 거의 그대로 가져와서 저널리스틱한 장문의 기사를 쓰는 시스템을 만든 거예요.
이미지 출처 : garryslist.org
그래서 누구나 Garry's List 사이트에 들어가 보면, 캘리포니아·샌프란시스코·LA에서 무슨 일이 벌어지고 있는지, 어떻게 더 나은 정부를 만들 수 있는지에 대한 잘 정리된, 출처가 다 표시된 기사 2~3편을 매일 볼 수 있어요.
Q. 그러니까 Garry's List는 블로그 플랫폼이면서 동시에 기자의 일까지 하는 거네요.
맞아요. 사람들이 Garry's List를 잘 이해 못 하는 게 그 점이에요. 보통 소프트웨어는 사람이 쓰라고 만드는 거잖아요. 블로그 플랫폼을 만들면 누군가 그 위에서 글을 쓰고요. 그런데 Garry's List는 블로그 플랫폼이면서, 동시에 고품질 탐사 보도를 하는 기자의 일도 해요. 기자가 도구로 쓰는 게 아니라, 기자 자체가 시스템 안에 들어가 있는 거죠.
이미지 출처 : garryslist.org
5~10달러어치 Opus API 호출만 있으면, 실제 사람이라면 수십 편의 기사를 꼼꼼히 읽고 책 몇 권을 통째로 읽고 주석을 다는 그 작업을 다 해내요. Casetext에서 제이크가 가르쳐준 핵심이 그거였어요. 사람이 주어진 맥락에서 뭘 할지를 생각하라는 거예요. 도서관에 가면 어떤 책을 찾을지, 웹에서 어떻게 검색할지, 그런 걸 다 시뮬레이션하는 거죠.
Q. 자료는 어디서 가져오나요?
이제는 그것도 직접 안 해도 돼요. 퍼플렉시티 API로 딥리서치를 할 수 있고, X API와 그록 API로도 할 수 있어요. 그록 API는 X 데이터를 리서치할 때 정말 좋고요. 모든 맥락을 다 끌어올 수 있어요.
토큰 맥싱과 "보일 더 오션" 철학
Q. "보일 더 오션(가능한 모든 자료를 다 끌어다 쓰는 접근)" 이야기를 하셨는데, 이게 어떤 개념인가요?
제가 쓴 에세이 중에 「Boil the Ocean」이라는 글이 있어요. 특히 지금처럼 에이전틱 소프트웨어를 만들 때는, 우리가 인간으로서 코드를 짤 때 했던 타협을 받아들일 필요가 없다는 이야기예요.
리서치도 마찬가지예요. 인간이라면 한 달 걸릴 완전판 리서치, 즉 "완벽주의자의 리서치"를 그냥 시켜버리는 거죠. 돈을 좀 더 쓰고, 토큰을 좀 더 태우는 거예요. 이걸 "토큰 맥싱(토큰 사용을 최대치로 끌어올리기)"이라고 하는데, 토큰 맥스를 해야 해요. 어떤 작업이든 더 완전하고 더 멋지게, 또 글쓰기의 경우엔 현실을 더 잘 반영하게 만들 수 있다면 그렇게 해야 하거든요.
예를 들어 글을 쓸 때 출처 하나로 만족하지 말고 20개를 가져와요. 그러면 교차 검증을 할 수 있어요. "이 13개 출처는 이걸 말하고, 7개 출처는 반대 의견이네"라고 정리한 뒤에, 그 맥락을 전부 핵심 프롬프트에 넣는 거예요. 그러면 사람이 링크 하나 클릭해서 헤드라인 읽고 끝내는 것보다 훨씬 나은 판단을 할 수 있어요. 토큰 맥싱은 기사 생성에만 적용되는 게 아니에요. 코드 짤 때도 그렇고, 우리가 "지식 노동"이라고 부르는 거의 모든 일에 적용돼요.
Q. 토큰 맥싱이 결국 사람을 대체한다는 의미는 아니죠?
아니에요. 사람들이 여전히 에이전시(어떤 일을 의도적으로 일으키는 주체로서의 의지)를 공급해야 해요. 저는 여기 앉아서 대수학에 대해 신경 쓰고 있잖아요. 이런 거대한 기술 변화가 일어나고 있는데, 저한테는 갈증과 욕구, 그리고 뜨거운 욕망이 있었어요. 그 욕망이 없으면 토큰 맥싱은 아무 의미도 없어요.
Q. 그 경험에서 얻은 패턴들이 다음 프로젝트인 GStack으로 이어진 거죠?
사실 GStack을 만들 계획은 전혀 없었어요. 그냥 같은 일을 계속 반복하고 있다는 걸 깨달았거든요. 똑같은 걸 또 타이핑하기 싫어서, 클로드 코드에 자주 입력하던 문장들을 애플 노트에 정리해뒀어요. 정말 단순한 내용이었어요.
이미지 출처: thenewstack.io
예를 들어 "여기 플랜 리뷰가 있어"부터 시작해서요. 제가 발견한 트릭 중 하나는, 클로드한테 아스키 아트(ASCII art, 문자로 그리는 그림이나 도식)로 다이어그램을 만들어달라고 하는 거였어요. 그냥 코드를 쓰라고 하면 가끔 헷갈려서 버그를 만들거나 빠뜨리는데, "작업 시작 전에 데이터 흐름·입력·출력·사용자 플로우·에러 메시지를 전부 아스키로 그려봐"라고 하면 달라지더라고요. 데이터 플로우, 상태 머신, 의존성 그래프, 처리 파이프라인, 의사결정 트리를 다 그려본 뒤에 작업을 시작하면, 모든 맥락이 머릿속에 로드되고 훨씬 완전하게 일을 해냈어요. 보일 더 오션을 더 잘 하게 된 거죠.
그 뒤에 작업이 자연스럽게 섹션별로 나뉘었어요. 아키텍처 리뷰, 코드 품질, 테스트 같은 식으로요.
Q. 테스트 이야기가 나왔는데, 직접 코딩하실 때와 차이가 있나요?
엄청 달라요. Garry's List를 직접 손으로 코딩할 때 저는 항상 테스트를 최소한만 했어요. 재미가 없거든요. 필요한 건 알지만, "나는 재미있는 새 코드를 쓰러 온 거지 테스트 쓰러 온 게 아니야" 같은 마음이었어요. 그러다가 다들 바이브 코딩을 시작할 때 부딪히는 벽에 똑같이 부딪혔어요. 슬롭(저품질 결과물)이 나오는 거예요. 80% 케이스에선 잘 굴러가는데, 진짜 사용자가 손대기 시작하면 무너져요.
이미지 출처: Reddit r/vibecoding
그때 깨달았어요. 100% 테스트 커버리지까지 갈 수 있구나. 지금은 100%가 과하다는 걸 배워서, 80~90% 정도가 적정선이라는 게 모범 사례 같아요. 기계는 신경 안 써요. 그냥 90% 커버리지를 채워줘요. 사람이 직접 짤 때는 절대 못 할 일이거든요.
Q. 그래서 GStack의 첫 번째 스킬이 만들어진 거군요.
맞아요. 이게 plan-eng-review(플랜 엔지니어링 리뷰)라는 스킬의 첫 버전이에요. 다들 아는 office-hours 스킬은 새 제품이나 새 기능을 만들 때 제가 지금도 쓰는 거예요. 우리가 회사 창업자랑 일할 때 하는 걸 그대로 시뮬레이션해요. "이걸 사람들이 원하는 걸 어떻게 아세요? 누구를 위한 거예요? 뭘 해요? 임팩트는 뭐예요?" 같은 질문들이요. 이게 원형 스킬이에요. 그땐 스킬이라는 개념이 있는 줄도 몰랐어요.
이미지 출처 : @garrytan, X
이걸 X에 올렸는데 갑자기 입소문이 났어요. 20만 명 정도가 봤죠. 그래서 더 확장한 버전도 만들었어요. 처음엔 "메가 플랜"이라고 부르다가 "CEO 플랜"으로 이름을 바꿨고요.
Q. CEO 플랜 스킬은 어떻게 만드신 건가요?
메타프롬프팅(프롬프트를 만드는 프롬프트를 LLM에게 짜게 하는 방식)을 썼어요. 기존 plan-eng-review 스킬을 가져다가 클로드에게 말했어요. "이걸 한 번 더 만들어보자. 그런데 이번엔 브라이언 체스키(Airbnb CEO)가 너 옆에 앉아 있다고 상상해 봐."
이미지 출처 : @garrytan, X
브라이언 체스키가 자주 하는 이야기가 "10성급 경험이 뭐냐"는 거예요. 보통 호텔을 3성, 4성, 5성으로 구분하잖아요. 거기서 그가 묻는 거예요. "그럼 6성은 뭐고, 7성, 8성, 9성, 10성은 뭐냐?" 끝까지 다 가보는 거죠. 제가 가장 좋아하는 제품·디자인 사고 훈련이에요. 그런데 이제는 매번 그걸 할 수 있어요.
Q. 그래서 이 프롬프트의 핵심이 뭐예요?
이 CEO 플랜 프롬프트는 결국 "이걸 가장 이상적인 형태로 만들면 뭐가 될까"를 찾아내요. 핵심은 두 가지인데, 그중 하나가 "10x 체크"예요. 노력은 2배만 들이면서 10배 더 큰 가치를 주는 더 야심찬 버전이 뭔지를 묻는 거예요.
이미지 출처 : gstack github
이 두 문장이 모델이 잠재 공간(latent space, 모델이 학습하면서 만든 의미의 좌표 공간)에서 진짜 잠재력을 시각화하도록 만들어주거든요. 저는 ADHD CEO인데, 순수한 잠재력에 매혹되거든요. 짧은 두 문장이 엄청난 걸 풀어내요.
Q. 그렇게 GStack이 본격적인 도구 모음이 된 거네요.
맨 처음엔 그것도 의도한 게 아니었어요. 그냥 제가 스킬 몇 개를 만들어야 했고, 사람들이 스킬 저장소를 만들고 있다는 얘기를 들었거든요.
이미지 출처: Youtube '토큰맥싱: 최고의 개발자들이 AI를 활용하여 400명의 엔지니어가 할 일을 처리하는 방법', Y Combinator 채널
그러다가 세 번째로 한 게, 이 두 스킬을 너무 많이 쓰다 보니 Conductor(여러 클로드 코드 인스턴스를 동시에 돌리는 맥용 앱) 인스턴스가 막 밀리기 시작한 거예요. 이게 제 실제 작업 환경이에요. 지난 48시간 동안 PR 13개를 머지했어요. 새 아이디어가 떠오를 때마다 그냥 큐에 넣어요. CEO 스킬로 정말 잘 테스트된 형태로 만들고, 플랜 모드에서 다 한 다음 "승인"을 누르면 클로드가 가서 작업을 다 해요.
Q. 그러다가 QA 문제에 부딪힌 거잖아요. 어떻게 푸셨어요?
큐에 15개 기능이 쌓이니까 결국 제가 손수 클릭해서 테스트해야 하는 상황이 됐어요. 그게 너무 지겨워서 그냥 클로드한테 던졌어요. "이거 너무 느려. 마이크로소프트 Playwright(브라우저 자동화 도구)로 감싸줄 수 있어?" 엔터 눌렀더니, 그게 결국 GStack의 새 기능이 됐어요. 지금은 새 기능이 필요할 때마다 이렇게 만들어요. 가끔 클로드가 "야, 너 이미 만들었잖아" 하고 답할 정도예요.
이미지 출처: playwright.dev
ADHD CEO와 IQ 200의 CTO
Q. GStack은 여러 역할의 스킬들로 구성돼 있는데, 흐름이 어떻게 되나요?
CEO가 있고, 디자이너가 있고, 개발자 경험(DevEx) 담당자도 있어요. 디자인 툴도 여러 개고요. plan-eng-review가 마지막에 들어가요. 그리고 보통 마지막에 /codex 명령을 실행해요. 최근엔 코덱스에서도 /claude 명령을 추가했어요.
Q. /codex 스킬은 어떻게 시작됐어요?
YC 동문 행사에서 나온 이야기예요. 머리가 완전히 지친 상태로 배치 이벤트에 갔다가, 사람들이랑 클로드 코드와 코덱스 비교하는 이야기를 나눴어요. 그때 저는 100% 클로드 코드 파였거든요. 그런데 많은 사람들이 코덱스를 더 좋아한다는 걸 알게 됐어요. "왜지?" 했죠.
이미지 출처 : 나노바나나 제작
알고 보니, 클로드 코드는 ADHD CEO를 위한 도구라면, 코덱스는 다른 종류의 도구였어요. 클로드 코드는 가끔 헛소리를 만들어내요. 클로드 모델은 정말 좋지만, 가장 똑똑한 모델은 아닌 게 사실이에요. 그래서 사람들이 설명해주길, 훨씬 더 미친 문제가 있을 땐 "거의 말 못 하는 IQ 200 CTO"가 필요하다는 거예요. 친구를 한 명 불러오는 셈인데, 그게 바로 /codex예요.
Q. 실제로는 어떻게 작동하나요?
작동 방식은 이래요. GStack 스킬이 현재 플랜이나 이미 구현된 결과를 가져가서, 커맨드라인에서 코덱스를 실행시켜요. 프롬프트는 "모든 문제와 버그를 찾아라"고요. 코덱스가 결과를 보고하면 클로드 코드한테 다시 피드백을 줘요. 그러면 클로드 코드랑 둘이 그 피드백을 같이 작업하는 거죠. 코덱스를 메인 에이전트로 쓰는 분이라면 반대로 /claude를 호출해서 잠깐 클로드를 CEO 역할로 부를 수도 있어요.
이미지 출처 : @garrytan, X
Q. 전체적인 작업 흐름은 어떻게 되나요?
GStack을 풀로 돌릴 때는 항상 office-hours, CEO 리뷰부터 시작해요. UI가 있으면 design 스킬을 돌리고요. 개발자가 쓰게 될 게 분명하면(GStack과 GBrain 같은 건 거의 다 해당해요) developer review를 돌려요. 그 다음에 review, 그리고 codex.
이 플랜이 다 끝나고 모든 이슈를 다 통과한 뒤에야 본격적으로 만들어요. GStack은 ask_user_question에 매우 많이 의존해요. 거기가 바로 인간이, 그러니까 바이브 코더, 오퍼레이터, 에이전틱 엔지니어가 자기의 이해를 공급해야 하는 지점이거든요. 무엇을 만들고 있는지에 대한 이해 말이에요. 그걸 대체할 수 있는 건 없어요.
진짜로 인간이 루프 밖에 있는데도 그냥 소프트웨어를 만들어내는 도구를 누군가 만든다면 저는 정말 놀랄 거예요. 좀 논쟁적인 입장이긴 한데, 저는 절대로 루프 밖에 있고 싶지 않아요. 기계가 제가 하기 싫은 일을 대신해주는 정도가 좋아요. QA가 좋은 예예요.
Q. QA 자동화는 어떻게 만드신 건가요?
지금 GStack의 최신 버전에 뭔가를 입력하면 "야, 우리 이미 만들었잖아. browse 있잖아"라고 답해요. browse는 70개 명령을 가진 장기 실행 HTTP 데몬으로, CLI 형태예요. QA는 그냥 browse를 호출하는 거예요.
QA 프롬프트는 이렇게 되어 있어요. "네 컨텍스트를 봐. 이 브랜치에서 뭘 했지? UI나 데이터 변경이 있으면 브라우저를 써서 그걸 테스트해." 이게 멋진 게, 블랙박스 브라우저를 갖고 있는 것 같거든요. 처음 작동했을 때 머리가 띵했어요. "미니 AGI(범용 인공지능)가 이미 여기 와있구나" 싶었죠.
진짜 AGI는 제가 여기 있을 필요도 없을 거예요. 그런데 사실 그래도 괜찮아요. 빌더로서 좀 이기적으로 말하자면, 저는 그게 영영 안 일어나길 바라거든요. 기계가 끝까지 그걸 못 풀어내길 바라요. 그러면 디자인 감각과 제품 감각, 진짜 고객을 머리에 그릴 줄 아는 인간 엔지니어가 계속 중요할 테니까요. 우리는 사실상 날개를 단 거나 마찬가지예요. 이 상태가 유지되는 한은요.
마크다운은 곧 코드다 'Thin Harness, Fat Skills'
Q. X에 올리신 "Thin Harness, Fat Skills(얇은 하네스, 두꺼운 스킬)" 글이 토큰 맥싱 철학을 한 번에 정리한다는 평이 많아요.
일부는 마크다운 가지고 인터넷에서 끊임없이 놀림당하면서 나온 글이에요. "쟤는 그냥 마크다운 팔이짓을 하네" 같은 비아냥요. 그런데 제 경험상 마크다운은 그냥 코드예요. 다른 방식으로 컴파일되는 코드일 뿐이고, 컴퓨터한테 정말 놀라운 일들을 시킬 수 있어요.
예를 들어 저는 비주얼 스튜디오를 거의 안 써요. 쓸 이유가 없어요. 에이전트한테 말로 시키면 에이전트가 다 해주거든요.
Q. 그런 글이 나오게 된 배경은 뭔가요?
클로드 코드를 매일 종일 쓰다가 어느 순간 깨달았어요. "잠깐, 클로드 코드 자체가 이미 엄청 잘 만든 하네스잖아? 근데 우리가 왜 내부에서 또 같은 걸 만들고 있지?" 참고로 "하네스"라는 표현은 YC 파트너 피트 쿠민(Pete Koomen)이랑 같이 에이전트 작업을 하면서 굳어진 말이에요.
이미지 출처 : @garrytan, X
그때부터 생각이 바뀌었어요. 저희가 시간을 써야 할 곳은 하네스를 또 만드는 게 아니라, "어떤 마크다운을 쓸 것이냐"라는 걸요. 마크다운을 이렇게 생각해 보세요. 당신이 결혼식 플래너인데, 다음에 결혼식을 맡을 사람에게 넘겨주려고 체크리스트를 쓴다고요. 평범한 말로 "결혼식 진행하는 법"을 적는 거죠. 그게 다 마크다운에 들어가요.
반면 결정론적으로(deterministic, 같은 입력에 늘 같은 결과가 나오게) 처리해야 할 일이나 실제 액션은 달라요. 결혼식 플래너가 장소 20곳에 전화를 돌려야 한다면? 그건 마크다운이 아니라 Twilio(통화·문자 API 서비스) API 호출이 해야 할 일이에요.
Q. 그럼 무엇을 마크다운에 넣고, 무엇을 코드에 넣을지를 어떻게 정하나요?
이게 지금 에이전틱 엔지니어링에서 가장 어려운 지점이에요. 사람들이 마크다운에 넣어야 할 걸 코드에 넣으려고 하다가 실패해요. 코드는 부서지기 쉽거든요. 특수한 경우를 이해 못 해요. 코드는 글자 그대로 당신이 원하는 게 뭔지, 당신이 누구인지 몰라요. 결정론적인 0과 1을 튜링 완전 루프 안에서 실행할 뿐이에요.
이미지 출처 : @garrytan, X
그런데 이제 LLM이 잠재 공간을 갖고 있어요. 당신이 누군지, 당신의 동기가 뭔지 알아요. 일반적인 경우들도 다 다룰 수 있고요. 지금 엔지니어로서의 마법은, "이건 LLM 영역이고 저건 코드 영역"을 잘 가르는 데 있어요.
거기에 제가 배운 또 하나, 테스트 80~90%를 더해야 해요. 테스트가 없는데 그냥 사용자를 던져 넣으면 슬롭이 돼요. 사람이 짠 코드보다 10배 나빠요. 무슨 일이 일어날지 모르거든요. 결정론 공간에서 뭐가 돌아가고 LLM 공간에서 뭐가 돌아가는지를 알아야 하고, 각각이 유닛 테스트, 통합 테스트로 검증돼야 해요. 보일 더 오션으로 돌아가면, 기계는 신경 안 써요. 그냥 해줘요. 90% 테스트 커버리지를 그냥 달성해줘요.
Q. 오픈클로를 쓰면 어떤 느낌이에요?
요즘 OpenClaw를 쓰는 건 마치 페라리를 모는 느낌이에요. 짜릿하고, 미친 짓이에요. 기계가 절대 알아낼 수 없을 거라고 생각했던 걸 알아내고, 그것도 정말 빠르게 해내요. 그런데 동시에 페라리이기도 해요. 가장 필요한 순간에 길가에서 고장 나는 페라리요. 본넷 열고 렌치 들고 직접 고쳐야 하는, 결국 본인이 정비공이 되어야 하는 페라리예요.
지금이 컴퓨터 과학과 기술에서 정말 흥분되는 시점인 게, 이게 홈브루 컴퓨터 클럽(1970년대 실리콘밸리의 전설적인 PC 동호회)이거든요. Apple I이 나왔던 그 순간 말이에요. 스티브 잡스와 스티브 워즈니악이 만든 Apple I은 사실 나무 케이스 안에 못과 청테이프로 붙인 브레드보드(회로 시제품용 기판)였어요. 개인 컴퓨터를 갖고 싶으면 그렇게 해야 했던 시대였어요.
지금이 딱 그래요. 기술적으로 어느 정도 트레이닝이 된 사람이 2~3시간 작업하고, 토큰과 클라우드 비용으로 500달러에서 1000달러 정도 쓰면 그런 시스템을 돌릴 수 있어요. 일단 굴러가기 시작하면 키트카 페라리 단계예요. 어디든 갈 수 있고, "나 페라리 있다!"고 산봉우리에서 외치고 싶어지죠.
Q. 이 "직접 고친다"는 부분을 사람들이 잘 못 받아들이는 것 같아요.
그게 한번 뚫고 나가보지 않으면 이해 안 되는 부분이에요. 줌아웃해서 보면, 이 모든 게 빠르게 진행됐어요. 옛날에는 Stack Overflow라는 게 있어서 프로그래밍 막혔을 때 거기 가서 답을 찾는 것만 해도 놀라웠잖아요. 그러다 ChatGPT가 나와서 "오, 스택 오버플로우보다 훨씬 좋은 인터랙티브 도구가 생겼네" 했고요.
그런데 그때도 같은 행동이었어요. 질문하고, 코드 복사 붙여넣기 하고, 실행해서 결과 보고, 다시 복사해서 넣고… 클로드 코드로 오면서 이 복사 붙여넣기를 안 해도 된다는 걸 깨달았어요. 그냥 실행하고 돌리거든요.
이미지 출처 : 나노바나나 제작
OpenClaw도 처음 셋업할 때 짜증 났어요. 스스로 망가지기도 하고 귀찮은 짓도 많이 해요. 그런데 클로드 코드를 같이 띄워놓으면 클로드 코드가 그걸 고쳐줘요. 분명 이게 장기적인 모습은 아니겠지만, 마인드셋이 바뀌어요. "취약하고 자주 고쳐야 한다"는 게 더 이상 문제가 아니에요. 옆에 다른 에이전트가 항상 고쳐주고 있으니까요.
Q. 한때 클로드 코드만 쓰셨다고 들었는데, 지금은 어떠세요?
전 완전 클로드 코드 파였고 지금도 그래요. 그런데 작업 시간의 50~60%만 클로드 코드에서 일해요. 나머지 절반 가까이는 OpenClaw로 옮겨갔어요. 흥미롭죠. 사실 요즘은 GBrain 작업에 시간을 더 많이 쓰고 있어요.
이미지 출처 : @garrytan, X
Q. GBrain은 어떻게 탄생했나요?
피터 스타인버거를 만나고, 라이트콘에서도 다루고 나서 결국 한 주말에 결심했어요. "이거 도대체 뭔지 한번 봐야겠다. OpenClaw 돌려보자."
그때가 카파시(전 OpenAI·테슬라 AI 디렉터)가 "LLM이 참고할 지식 위키를 직접 만들어 두면 좋다"는 글을 쓴 직후였어요. 그래서 생각했죠. "나는 마크다운 파일이 잔뜩 쌓인 폴더가 있는데, 내 모든 맥락을 거기 다 넣어버려야겠다."
그러다가 어느 순간 깨달았어요. "잠깐, 이거 그냥 키워드 검색 쓰고 있잖아." 키워드 검색은 그렇게 좋지 않아요. 필요한 것보다 훨씬 많은 내용을 AI한테 들이밀거든요. 그렇게 제대로 파고들기 시작했죠.
Q. 그렇게 RAG 시스템을 직접 만드신 건가요?
처음부터 만든 게 아니에요. 코드 베이스가 커지면 머릿속에 그게 다 들어 있다는 게 큰 이점이거든요. Garry's List에서 AI 기자를 만들 때, 자료를 잘 찾아오게 하는 기술들을 이미 다 배워뒀어요. 긴 글을 적당한 크기로 잘라서 검색하기 좋게 만드는 법, 여러 검색 결과를 똑똑하게 합치는 법 같은 것들요. 결과물 품질에 집착하면서 만들었기 때문에 검증도 끝난 상태였고요.
그래서 Conductor를 열고 첫 줄에 이렇게 썼어요. "Garry's List 가서 우리가 검색 시스템 어떻게 만들었는지 봐. 그걸 그대로 가져와서 내 OpenClaw용으로 똑같이 만들어 줘." 그렇게 한 단계가 또 다른 단계로 이어졌어요.
Q. 그러니까 이미 만들어놓은 코드를 자산처럼 활용해서 다음 걸 만든다는 거네요.
맞아요. 이게 제가 "오픈소스의 황금기"라고 부르는 이유예요. 누구나 할 수 있어요. 1월 23일에 제가 트윗을 올렸어요. "이번 주 클로드 코드가 25살이던 시절의 나를 깨웠다. 새벽까지 레드불 마시며 코딩하던 그 자아. 우리는 돌아왔다."
지금 저는 하루에 4시간 자고 20시간 코딩하는 모드로 다시 들어왔어요.
라인 수 400배가 의미하는 것
Q. 라인 수가 100배라는 말로 인터넷에서 곤욕을 치르셨잖아요.
지금도 그 입장이 맞다고 생각해요. 라인 수 이야기가 인터넷에서 굉장히 논쟁적이었어요. 반론은 익숙해요. "라인 수는 개발자 생산성을 측정 못 한다"는 거잖아요. 일견 그래요. 그런데 사실 측정하기도 해요.
이미지 출처 : @garrytan, X
물리적 라인 수(physical lines, 빈 줄과 주석 포함 전체 줄 수)랑 논리적 라인 수(logical lines, 실제 의미 있는 코드 줄)는 다른데, 잘 알려진 깃 레포가 있어요. 거기 도구를 돌리면 실제 논리적 라인 수만 뽑아낼 수 있거든요. 제가 그걸 돌렸어요.
원래 "2013년에 비해 100배 코드를 짠다"고 트윗했다가 곤욕을 치렀는데, 논리적 라인 수로 환산해서 다시 비교했더니 오히려 숫자가 올라갔어요. 결과적으로 400배였어요.
Q. 왜 논리적으로 환산했더니 더 늘어났을까요?
물론 그걸 제가 직접 타이핑한 건 아니에요. 한 번에 에이전트 15개 정도를 동시에 돌리고 있었어요. 숫자만 보면, 클로드 코드의 라인 수는 환산 후에 조금 줄었어요. 그런데 놀라웠던 건, 2013년에 제가 쓴 라인 수가 환산 후에 70%나 줄었다는 거예요.
이미지 출처: @Gregorein, X
이게 미스매치의 핵심이에요. 사람들이 화가 나는 이유는, 사람이 코드를 짤 때는 라인 수 부풀리기가 쉽거든요. 반면 클로드 코드는 일부러 라인 수를 부풀리라고 시키지 않는 한 그렇게 안 해요. 잘못된 걸 만들 수는 있어요. 잘 끌어주지 못하면 엉뚱한 일을 할 수도 있고요. 그런데 인간 직장인처럼 라인 수를 최적화하려고 하지는 않아요.
Q. 정말 의외인 결과네요.
진짜 놀라운 건 따로 있어요. 1990~2000년대 소프트웨어 엔지니어링 문헌을 보면, 테스트되고 프로덕션 준비된 코드 기준으로 평균적인 프로 엔지니어가 하루에 짜는 양이 100줄도 안 돼요. 50줄, 30줄 수준이에요. 저는 14줄이었어요. 다만 그때 저는 파트타임이었어요.
그래서 400배라는 숫자가 나온 거예요. 라인 수 가지고 더 트롤링당하지 말고 이걸 먼저 말했어야 했는데, 인터넷에서 시비를 걸어드렸다면 죄송해요. 이 주제에 대해 훨씬 깊은 이해가 있고, 결국 블로그 글로 자세히 정리했어요.
이미지 출처 : @steipete, X
이건 별일 아닌 게 아니에요. 기술적인 사람들에게는 엄청나게 중요한 사실이에요. 본인이 할 수 있는 일의 천장 자체가 올라갔다는 뜻이거든요. 라인 수로 저를 공격하던 사람들이야말로 토큰을 풀로 태웠을 때 가장 큰 날개를 달 사람들이에요. 이게 클래식한 문제예요. 감각이 있고 기술을 이해하는 사람일수록 이걸 받아들였을 때 얻을 게 가장 많거든요. 그냥 믿기만 하면 돼요. 싸우지 말고 클로드 코드를 열어서 해보세요.
Q. 모델이나 하네스에 따라 경험 차이가 크지 않나요?
저도 그렇게 느껴요. 약간 복잡한 프로그래밍 작업을 OpenClaw 에이전트로 돌려보면 그냥 실패해요. Opus 4.7 같은 동일한 모델을 클로드 코드에서 돌릴 때랑 비교하면 분명히 차이가 나거든요. 단순한 스크립트 이상은 OpenClaw에서는 잘 안 되더라고요. 그래서 클로드 코드로 돌아와요.
이미지 출처: mini-swe-agent.com, swebench.com
그게 저한테는 묘한 순간이었어요. "아, 옛날에 이렇게 느꼈었지." 6개월 전만 해도 다 그랬어요. "이거 아직 좀 멀었네"가 일반적인 반응이었죠. 그러다 클로드 코드 + Opus 4.5에서 "어, 진짜 됐네" 하는 순간이 왔고요.
같은 변화가 곧 반복될 거예요. 지금 사람들이 OpenClaw나 Hermes 에이전트 같은 게 "아직 멀었다, 손이 너무 간다"고 느끼는데, 1년 안에 모두가 이렇게 말하게 될 거예요. 지구상의 모든 사람이 자기만의 개인 AI를 갖게 될 거라고요.
'누가 통제할 것인가' 개인 AI 혁명
Q. 개인 AI라는 표현이 흥미로워요. 어떤 의미인가요?
두 가지 세계 중 하나에서 살게 될 거예요. 우리가 자기 AI를 갖고, 자기 데이터를 갖고, 자기 통합 도구를 갖고, 무슨 일이 일어나는지 보고, 자기 프롬프트를 직접 쓰고, 자기가 보는 것에 통제권을 갖는 세계.
아니면 기업이 통제하는 세계. 호스트에 접속하는 형태로, 페이스북 피드 같은 거예요. 그 알고리즘을 누가 썼는지, 누구의 이익을 위한 건지, 뒤에 어떤 비즈니스 모델이 있는지 아무도 몰라요.
이미지 출처 : 위키피디아
선물 같았던 가장 강력한 아이디어가 개인용 컴퓨터 혁명이었어요. 우리는 지금 그것과 정확히 같은 전환을 개인 AI로 겪으려 하고 있어요. 그리고 그건 선택의 문제예요. 본인이 자기 프롬프트를 쓸 의지가 있느냐는 거죠.
피트 쿠민이 여기 없는 게 아쉽네요. 그한테 배운 것 중 하나가 있는데, 자기 프롬프트를 직접 못 쓰면 당신은 어떤 PM이나 개발자가 API 가이드라인 아래에 정한 한계 안에서 살게 된다는 거예요. 그 PM이나 개발자는 당신이 아니에요. 당신의 필요를 이해 못 하고, 당신이 무엇에 진심인지 몰라요.
그래서 이게 정의적인 질문이에요. 당신이 자기 도구를 통제할 거냐, 아니면 도구가 당신을 통제할 거냐.
Q. 그런데 이게 가능하려면 비용이 만만치 않잖아요. 일반인들에게는 진입장벽이 있지 않을까요?
대중이 못 보는 단절이 거기 있어요. 이런 능력들은 최신 모델에서만 제대로 작동하거든요. 그리고 토큰을 마음껏 태우는 게 지금은 꽤 비싸요. 물론 가격은 내려오고 있어요. 그런데 사람들 대부분이 무료 모델이나 기본 클로드 프로 구독만 써본 상태예요. 이 새로운 빌딩 방식, ASI/AGI 모먼트는 토큰을 많이 태워야 도달할 수 있어요. 그게 토큰 맥싱 패러다임 전체예요.
이미지 출처 : @garrytan, X
Q. 그 비싼 비용을 정당화할 방법이 있을까요?
샌프란시스코 임대료가 떠오르는 비유예요. YC 창업자들한테 항상 해주는 이야기가 있어요. 누군가 와서 "샌프란시스코는 너무 비싸서 이사 가기 싫어요"라고 하면 저는 답해요. "거기 안 사는 게 더 비싸요."
그게 핵심이에요. YC 배치 초반에 창업자들이 와서 "이 아파트는 월세가 몇천 달러나 해요. 말도 안 되는데, 내야 할까요?"라고 물어요. 저는 답해요. "당연히 내야죠. 오히려 더 내서 그냥 샌프란시스코가 아니라 Dogpatch(샌프란시스코의 스타트업 밀집 동네) 같은 동네에 살아서 우연한 만남을 만드세요."
토큰 맥싱도 똑같아요. 창업자들이 받아들이도록 가르쳐야 하는 일이에요. 직관적으로 안 와요. 이건 임대료와 같은 거예요. 사무실 책상 같은 데서 아끼는 건 괜찮아요. 비싼 소파 같은 거 필요 없어요. 그런데 실제 모델 사용과 토큰 지출에 대해서는 꽤 세게 밀어붙여야 해요.
이미지 출처 : @garrytan, X
YC의 핵심 격언 중 하나가 "좋은 스타트업 아이디어는 어떻게 찾는가? 미래에 살고, 빠진 걸 만들어라"잖아요. 이게 그 격언의 심화 버전이에요. 머리를 헌신하기만 하면 돼요. 하루에 500달러를 토큰에 쓰는 걸 보면서 "내가 진짜 가치를 만들고 있고 옳은 걸 만들고 있다면 그 정도는 쓸 수 있다"고 받아들이는 거예요.
시간 억만장자가 되는 법
Q. YC CEO를 풀타임으로 하면서 이걸 다 해내신다는 게, 시간이 부족하지 않으세요?
솔직히 시간이 부족하죠. 저는 시간 억만장자(살아갈 시간이 어마어마하게 남아 있는 사람)들이 부러워요. 가끔 제 아이들을 보면서 생각해요. "쟤네는 시간 억만장자구나." 스타트업 스쿨에 가면 만나는 친구들이 그래요. "당신은 지금 시간 억만장자예요. 멋진 거예요. 뭐든 배울 수 있고, 뭐든 할 수 있어요."
개인적으로 저는 머릿속이 미친 듯이 급해요. 이 한 몸으로 100억 인생을 살아야 할 것 같은 기분이고, 모든 순간이 의미를 가져야 해요. 그런데 토큰 맥싱을 할 수 있으면 이야기가 달라져요. 수백만 년 분량의 기계 의식을 살 수 있는 거예요. 그제야 시간 억만장자가 될 수 있어요. 제 시간이 아니라 기계의 시간이지만, 그 기계가 저를 위해 일하고, 제가 아끼는 사람들과 제가 아끼는 대의를 위해 일하는 거예요.
Q. 그럼 이 모든 걸 시작하게 만든 결정적 계기가 있었나요?
대단한 마스터플랜이었다고 말하긴 어려워요. 그런데 잠재의식 속에서는 그게 작동하고 있었던 것 같아요.
저는 YC에 진심이고, 빌더들이 빌드할 수 있게 되는 데도 진심이거든요. 작년 내부 오프사이트에서도 "이 새로운 도구들을 어떻게 우리 일에 도입할 것인가"를 자주 이야기했어요.
결정적이었던 건 라이트콘을 하면서, 옆에 보리스 체르니(클로드 코드 책임자)와 직접 앉아 이야기하던 순간이에요. 그가 "우리 팀은 코드를 한 줄도 안 쓴다"고 말했을 때, 저는 "오, 나도 저거 할 수 있겠는데"라고 생각했거든요. 그 한 마디가 결국 이 모든 걸 시작하게 만든 셈이에요.
Q. 마지막으로, 이 글을 보고 계신 분들에게 한 마디 해주신다면요?
지금 이걸 보고 계신 분들도 저랑 다르지 않아요. 우리는 같은 출발점에 있었어요.
저는 스스로를 무슨 하늘에 있는 존재처럼 생각하지 않아요. 사람들이 그렇게 말하는 것 같긴 한데, 저는 그냥 뭔가를 해보려는 한 사람일 뿐이에요. 보리스 옆에 앉으면 그가 제가 만나본 최고의 엔지니어 중 한 명이라는 걸 알 수 있어요. 동시에, 제가 프롬프트를 열면 우리는 같은 프롬프트를 갖고 있어요. 같은 맥북 프로를 갖고 있고요.
당신과 저, 그리고 우리 모두 사이에는 인류를 섬길 수십 만년의 토큰을 끌어다 쓰는 일을 가로막는 게 아무것도 없어요.
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요