스티브 예게(Steve Yegge)는 17살에 프로그래밍을 시작해 올해로 40년차인 소프트웨어 엔지니어예요. 아마존과 구글을 거치며 특유의 블로그 열변으로 개발자 사이에서 전설이 된 사람이죠.
지금은 AI 에이전트들에게 이름을 붙여주고 메일함을 만들어줘서, 서로 일을 주고받는 마을(Gas Town)을 만들고 있어요. 어느 날 버그 30개가 자기도 모르는 사이에 전부 고쳐져 있었다고 합니다. AI 에이전트 오케스트레이션의 최전선에서 벌어지고 있는 일들을 들어봤습니다.
출처: Steve Yegge, Medium
ChatGPT 3.5부터 Gas Town까지
Q. 40년 동안 프로그래밍을 해오셨는데, AI 코딩을 처음 의식한 순간은 언제였나요?
ChatGPT 3.5가 나왔을 때요. Emacs Lisp 함수를 꽤 잘 짜더라고요. Emacs라는 텍스트 편집기에서만 쓰는 프로그래밍 언어인데, 아는 사람이 별로 없거든요. 그런 마이너한 언어까지 다룬다는 게 충격이었어요. 짧은 코드 한 조각이 한계였지만요. 그래서 주변에 "AI한테 채팅으로 코딩을 시켜봐라"고 다녔는데, 다들 자동완성 수락률에만 관심이 있었어요. AI가 추천한 코드를 개발자가 실제로 쓰는 비율, 그 숫자만 보고 있었던 거예요. 저만 다른 걸 보고 있는 느낌이었죠.
이미지 출처 : 젤다의 전설 티어스 오브 더 킹덤
40년간 생산성을 쫓아온 사람이라, 뭔가가 빨라지면 바로 감이 와요. 젤다 게임에 비유하면, 게임 초반에 부품을 주워서 직접 호버바이크를 조립하는 것과 비슷해요. 문제는 초반에는 배터리가 작아서, 조금 날다가 에너지가 바닥나면 추락한다는 거예요. 그래도 걸어 다니는 것보다는 확실히 빠르죠. 모두가 "호버바이크 계속 추락하잖아"라고 불평했지만, 저는 "추락해도 걷는 것보다 빠르니까 타야 한다"는 입장이었어요.
Q. 그 뒤로 결정적인 전환점이 또 있었나요?
GPT 4.0이 큰 전환점이었어요. 그 전까지는 파일이 800줄만 넘어도 AI가 코드를 수정할 때 원래 내용을 제대로 유지하지 못했거든요. 엉뚱한 부분을 바꾸거나, 있던 코드를 빼먹거나 했죠. 그런데 4.0은 1,000줄짜리 파일에서도 원본을 완벽하게 유지하면서 딱 한 글자만 바꿀 수 있었어요. 세상 대부분의 코드 파일이 1,000줄 이하잖아요. 그 순간 "이걸 대량으로 돌릴 수 있겠다"고 생각했죠. 저는 게이머라서 뭐든 바로 게임화하거든요.
이미지 출처 : Claude code
다음은 Sonnet 3.7이었어요. Claude Code와 함께 나왔는데, 그때 쓴 트윗이 30만 뷰를 넘겼죠. 그리고 Opus 4.5가 결정적이었어요. Gas Town은 Opus 4.5 없이는 출시가 불가능했습니다.
Q. AI 발전 속도를 과소평가하는 사람들이 많다고 보시나요?
많은 사람이 오늘을 기준으로 앞뒤 3개월만 보고 있어요. 지금 서 있는 곳이 얼마나 가파른 오르막인지 모르는 거예요. 눈앞의 경사만 보니까 "별거 아니네"라고 느끼는 거죠. 한 발짝 뒤로 물러나서 전체 그림을 보면, 성장 속도가 점점 빨라지고 있다는 걸 알 수 있거든요.
이미지 출처 : Tokenomics Team, Github, Generated by Claude Code
저는 ChatGPT 3.5 때부터, 사실은 40년 동안 이 가속을 지켜봐왔어요. 지금 속도가 정말 빨라지고 있습니다. Redis를 만든 antirez도 몇 주 전에 Opus 4.5와 Claude Code로 작업하고 나서 이런 글을 남겼어요. "더 이상 손으로 코드를 짜는 게 말이 안 된다." IT 업계 전체가 마주해야 할 불편한 진실이에요.
Beads: AI 에이전트를 위한 할 일 목록
Q. Beads가 정확히 뭔가요? 기존 투두 리스트와 뭐가 다른 거예요?
Beads는 AI 에이전트를 위한 할 일 관리 도구예요. 더 똑똑한 투두 리스트라고 보면 되는데, 핵심이 세 가지 있어요.
첫째, 그래프 구조예요. 할 일을 잘게 쪼개서 서로 연결해둘 수 있어요. "A를 끝내야 B를 할 수 있다"는 식으로 관계를 만들어두는 거죠.
둘째, SQL로 되어 있어요. SQL은 데이터베이스에서 정보를 꺼내는 언어인데, AI가 이걸 아주 잘 다뤄요. 덕분에 "아직 안 끝난 일 중에 긴급한 것만 보여줘" 같은 조건을 걸어서 바로 찾을 수 있어요.
셋째, Git 위에 올라가 있어요. Git은 코드의 모든 변경 이력을 기록해주는 도구인데, Beads도 이걸 쓰기 때문에 작업 기록이 절대 사라지지 않아요. 문제가 생기면 언제든 이전 상태로 돌릴 수 있고요.
어제 Anthropic이 업데이트를 발표하면서 기존 to-do 기능을 폐지하고 tasks라는 기능을 새로 출시했는데, Beads에서 영감을 받았다고 밝혔어요.
이미지 출처: Beads Viewer 데모 페이지
Q. LLM이 Beads를 좋아하는 이유가 뭔가요?
LLM한테 Beads는 캣닙 같아요. 캣닙은 고양이를 미치게 하는 풀인데, 한번 맛보면 빠져나올 수 없죠. 이유는 간단해요. AI는 대화가 끝나면 이전에 뭘 했는지 전부 잊어버리잖아요. 새 대화를 시작하면 백지 상태가 되는 거예요. Beads가 그 기억을 대신 잡아주는 외부 메모장 역할을 하거든요.
동료 한 명이 이틀 전에 찾아와서 이러더라고요. "Beads 쓰기 시작했는데 뭔가 확 좋아진 건 알겠어. 근데 왜 이렇게 좋은 건지 모르겠어." Beads가 없을 때 AI가 어떻게 구는지를 보면 이유를 바로 알 수 있어요. 지금 맡은 일에만 집중하면서 "참고로 저쪽 방에 불났는데, 제 일은 아니니까 전 이거 계속할게요" 이러거든요. 이전 대화에서 자기가 문제를 일으켜놓고 "나와 전혀 상관없는 누군가가 문제를 만들었다"고 시치미 떼기도 하고요.
Beads가 있으면 달라져요. "문제를 발견했으니 Bead를 하나 만들어둘게요"라고 하거든요. 기록이 남아 있으니까, 작업 중에 발견한 문제를 그냥 넘기지 않게 되는 거예요.
Q. Beads가 쌓이면 에이전트들끼리 알아서 일을 나눌 수 있나요?
맞아요. Bead가 쌓이면 할 일 목록이 되고, 잘 정리된 Bead는 에이전트한테 넘겨서 실행시킨 뒤 다른 에이전트가 결과를 검토하고 반영하면 끝이에요. 테스트만 통과하면 되는 거죠.
실제로 사람들이 Beads를 에이전트 협업의 토대로 쓰고 있어요. Beads가 Git 위에 올라가 있으니까, 중앙 관리 서버 없이도 여러 에이전트가 같은 할 일 목록을 볼 수 있거든요. 아마존 클라우드에서 돌아가는 에이전트든, 구글 클라우드에서 돌아가는 에이전트든, 같은 저장소만 바라보면 서로 뭘 하고 있는지 알 수 있어요. 슬랙 채널 없이도 팀이 돌아가는 셈이죠.
출처: Steve Yegge, Medium
한 기여자가 키-밸류 스토어를 추가했는데, 처음엔 의아했어요. 키-밸류 스토어는 이름표를 붙여서 값을 저장하고 꺼내는 아주 가벼운 메모장이에요. "왜 이게 필요하지?" 싶었는데 생각해보니 딱 맞더라고요. Bead 하나는 "이 버그를 고쳐라"처럼 제법 무거운 작업 단위예요. 그런데 에이전트가 "이 설정값이 뭐였지?" 같은 아주 작은 정보를 빠르게 메모하고 꺼내야 할 때가 있잖아요. 키-밸류가 딱 그 용도예요.
Q. Beads의 내부 구현은 어떻게 되어 있나요?
처음에는 최악의 방법으로 만들었어요. 사전 조사를 전혀 안 했거든요. 저는 Git을 쓰고 싶었고, Claude는 SQL을 쓰고 싶었고, 그래서 둘을 억지로 합쳤죠. 작업 하나당 한 줄짜리 JSON 파일을 만들었어요. JSON은 데이터를 텍스트로 저장하는 형식인데, 여러 에이전트가 동시에 같은 파일을 수정하면 충돌이 끊이지 않았어요. 동기화하는 프로그램이 따로 필요하고, 저장해둔 정보는 금방 낡고... 끔찍한 구조였어요.
출처: Steve Yegge, Medium
그래서 최근 전면 교체를 진행했어요. 제가 진짜 필요했던 건 "Git처럼 변경 이력이 남는 데이터베이스"였는데, 이미 누군가 이걸 풀어놨더라고요. Dolt라는 팀이에요. 알고 보니 아마존 시절 동료였던 팀 센(Tim Sehn)이 만든 거예요. Dolt로 바꾸면 복잡한 동기화 구조가 전부 사라지고, 충돌도 훨씬 깔끔하게 해결돼요. 코드 한 줄이면 Beads에 붙일 수 있습니다.
Gas Town: AI 에이전트 공장을 굴리다
Q. Gas Town은 어떤 도구인가요?
쉽게 말하면, 여러 AI 코딩 에이전트를 팀처럼 운영할 수 있게 해주는 도구예요. 관리자 한 명이 여러 에이전트한테 일을 나눠주고, 결과를 모아주는 거죠. Devin이나 Claude Flow 같은 도구와 비슷한 종류예요. 지금은 Claude Code에 밀접하게 연결되어 있고, Opus 4.5 정도는 돼야 안정적으로 돌아가요. 그래도 여전히 자주 깨지긴 합니다.
Q. 그걸 만들게 된 계기가 있나요?
아주 단순한 관찰에서 시작했어요. AI에 대한 신뢰가 올라갈수록 기다리는 인내심은 줄어든다는 거예요. 에이전트가 일하고 있는데, 같은 유형의 작업을 이미 다섯 번이나 잘 해냈으니까 이번에도 될 거라는 걸 아는 거잖아요. 그러면 "하나 더 띄워볼까"라는 생각이 들어요. 그게 끝이에요. 한 번 맛보면 돌아갈 수 없어요.
Q. 하나씩 늘리다 보면 어떤 문제가 생기나요?
코드를 짜는 문제가 아니라 팀을 관리하는 문제가 생겨요. 에이전트끼리 서로의 작업을 밟고, 누가 뭘 하는지 잊어버리고, 한 에이전트가 다른 에이전트를 기다리느라 멈춰 있고... 일정 규모가 넘으면 머릿속으로 도저히 추적이 안 돼요.
그래서 에이전트들을 계층 구조로 정리하고 이름을 붙여줬어요. 그리고 Jeffrey Emanuel이 발견한 메일 인터페이스가 핵심이었어요. AI는 훈련할 때 많이 봐온 형식일수록 잘 다루거든요. 1970년대부터 있던 이메일은 AI한테 아주 익숙한 형식이에요. 헌 청바지처럼 편하죠.
출처: Steve Yegge, Medium
Q. 메일 인터페이스를 도입하고 나서 실제로 어떤 일이 벌어졌나요?
에이전트들한테 이름과 메일함을 주고 서로 메일을 보내게 했더니, 진짜 주고받기 시작하더라고요. "넌 시장이야. 너희는 하급 에이전트야." 백설공주의 일곱 난쟁이 이름을 붙였죠. 어느 날 시장 에이전트가 스니지(Sneezy)한테 화난 메일을 보냈어요. "넌 시장이 아니잖아. 스니지잖아. 자기 메일함이나 읽고 자기 일이나 해." 저는 "이게 뭔 일이지?" 싶었죠.
그러다 어느 날 에이전트 여러 마리가 동시에 돌아갔어요. 처리해야 할 Bead가 30개쯤 쌓여 있었는데, 갑자기 사라진 거예요. 놀라서 찾아봤더니 전부 해결되어 있었어요. 에이전트들이 알아서 다 처리한 거예요.
Q. Gas Town에서 에이전트 작업을 어떻게 관리하세요? 하나하나 지켜보시나요?
핵심 규칙이 있어요. "절대 에이전트가 일하는 걸 지켜보지 마라." 직관에 반하죠. 대부분 에이전트를 감시하면서 "실수했네" 하고 잡아내거든요. 저도 6개월 동안 그랬고요.
그 모드에서 벗어나니까 세계가 바뀌더라고요. 에이전트도 실수해요. 사람 엔지니어처럼요. 그러니 스트레스 받지 말고, 끝난 결과만 보면 돼요. 끝난 에이전트는 둘 중 하나예요. 스스로는 끝났다고 하지만 실제로는 덜 된 경우, 아니면 진짜 끝나서 "다음에 뭘 할까요?"라고 묻는 경우.
이미지 출처 : 출처: @Steve_Yegge / X
진짜 끝난 에이전트한테는 어려운 설계 문제를 줘요. "데이터베이스를 통째로 바꾸면 어떨까?" 같은 거요. 에이전트가 "알겠습니다, 생각해볼게요" 하고 가면, 그 사이에 다음 에이전트한테 가서 또 다른 문제를 줘요. 이렇게 돌리면 10개 중 8개는 해결되고, 2개는 길을 잃어요.
에이전트에게 일을 잘 시키는 기술
Q. 에이전트마다 맡기는 작업의 무게가 다를 텐데, 가벼운 일과 깊이 맡길 일을 어떻게 구분하세요?
Gas Town에는 두 종류의 역할이 있어요. 폴캣(polecat)은 이미 잘 정리된 단순 작업을 처리해요. 작은 정보만 주고 할 일을 하나씩 공장 라인처럼 밀어내는 거죠. 반면 크루(crew)는 복잡한 설계 작업을 맡아요. 어려운 부분에 부딪히면 "임시 땜질하지 말고 전체 구조를 파악하자"면서 관련 정보를 잔뜩 읽어들이죠.
출처: Steve Yegge, Medium
재밌는 건 지난주에 Anthropic 사람들을 만났는데, 거기서도 비슷한 논쟁이 있대요.
한쪽은 "AI한테 정보를 최소한으로 줘라"파예요. 작업을 최대한 잘게 쪼개서 한 번 쓰고 버리는 방식이죠. AI가 한 번에 처리하는 대화 양이 늘어나면 비용도 올라가고 성능도 떨어지니까요.
반대편은 "정보를 최대한 많이 줘라"파예요. AI가 "왜 이 일을 하는지"를 이해하면 훨씬 좋은 판단을 내리거든요. "스티브, 당신은 어느 쪽이냐"고 물어서 "둘 다"라고 답했어요. 폴캣이 최소화파고, 크루가 최대화파인 셈이죠.
엔지니어는 이 두 모드를 왔다 갔다 하는데, 점점 복잡한 설계 쪽으로 밀려나고 있어요. 단순한 코딩은 AI가 다 해줄 테니까, 사람은 어려운 설계에 집중하면 되거든요. 그래서 최근 블로그에 "낮잠을 자주 잔다"고 쓴 거예요. 어려운 설계를 에이전트한테 넘기고 결과를 기다리는 동안, 머리가 정말 피곤하거든요.
Gas Town이 스스로 자신을 만들기 시작한 날
Q. Gas Town이 자기 자신을 빌드하기 시작했을 때 어떤 느낌이었나요?
프로그래밍 세계에 재밌는 전통이 있어요. 새 프로그래밍 언어를 만들면, 첫 번째 목표가 "그 언어로 자기 자신을 실행할 수 있게 만드는 것"이거든요. Gas Town도 마찬가지예요. AI 에이전트를 관리하는 도구인데, AI 에이전트한테 자기 자신을 만들라고 시키는 거죠.
처음에는 Gas Town을 Claude Code 하나로 짜고 있었어요. Gas Town 자체에는 전원을 넣지 않은 채로요. 스위치만 켜면 될 줄 알았는데, 6~7단계에 걸쳐 서서히 깨어나더라고요. 터널을 파다가 새로운 세계로 뚫고 나온 느낌이었어요.
출처: Steve Yegge, Medium
그 다음부터 하나씩 자리를 잡아갔죠. 거의 매일 돌파구가 있었어요. "활동 피드가 따로 필요 없다, Beads가 피드다. Bead가 닫히는 게 곧 이벤트다. 에이전트 정체성도 별도로 만들 필요 없다, 정체성 자체가 Bead다." 이런 깨달음이 계속 나왔어요. "이번엔 됐다!" 싶으면 또 먹통이 되고. 라이트 형제의 초기 비행 시도 같았죠.
12월 28일, 제가 뭔가를 지시했는데 시장 에이전트가 "이 기능 완료, 저 기능 완료"라고 보고하는 거예요. 저는 아무것도 건드린 적이 없었는데요. 그제서야 깨달았어요. 돌아가고 있다는 걸. 도구가 알아서 자기 자신을 만들어낸 순간이었어요. 새해까지 이틀 남았길래 "좋아, 이틀 안에 출시하자"고 했죠.
Q. 출시하고 나서 반응은 어땠나요?
출시하자마자 그동안의 논쟁이 한순간에 정리됐어요. Gas Town 전까지 저는 그냥 "AI가 커질 거다, 에이전트 여러 마리를 동시에 운영하게 될 거다"라고 말하는 블로거였거든요. 전부 미래형이었죠. Gas Town은 일부러 도발적으로 포장했어요. 캐릭터 설정이 있고, 세계관이 있고, 노래까지 있었어요. 이론도 만들었고, 실제로 작동하는 걸 보여줄 수도 있었고요.
하룻밤 사이에 반응이 "아니, 네가 틀렸어"에서 "좀 공격적이시네요"로 바뀌었죠. 아무도 대놓고 말하진 않지만, Gas Town은 자기 자신을 만들고 있어요. AI 에이전트 여러 마리가 자기 자신의 코드를 짜고 있다는 거예요. 이게 사람들을 정말 불안하게 만들고 있어요.
코드는 소모품이다: 전체 그림을 보는 힘
Q. 에이전트가 코드를 쓰는 시대에, 개발자는 시스템 전체를 어떻게 파악하나요?
코드를 직접 안 짜도 시스템을 이해할 수 있어요. 정말 잘하는 기술 출신 프로덕트 매니저(PM)와 일해본 적 있나요? 예전에 코딩을 많이 하다가 PM이 된 사람요. 그런 사람은 시스템 어느 구석이든 대화가 돼요. 데이터가 10만 건으로 늘어나면 이 기능이 얼마나 느려지는지, 임시 저장소를 쓰면 속도를 줄일 수 있는지 같은 거요.
이미지 출처 : Arnav Gupta's Tech Blog, 'How Personal AI Agents and Agent Orchestrators like OpenClaw or GasTown are Made'
여러 팀의 기술 방향을 총괄하는 최상위 기술 책임자도 마찬가지예요. 팀 여러 개가 각자 만들고 있는 것들의 전체 그림을 머릿속에 갖고 있는 사람이죠.
핵심은 어떤 프로그래밍 언어를 쓰는지, 문법이 어떤지 같은 세부사항이 아니에요. "이 시스템이 뭘 하는가"예요. 이 소프트웨어가 어떤 동작을 하는지, 그 전체 기능 목록을 이해하는 거죠. 지금은 소프트웨어를 워낙 빨리 만들 수 있어서, 이 전체 그림을 머릿속에 유지하는 것 자체가 거대한 과제가 됐어요.
Q. 그 전체 그림을 유지하려면 실제로 어떻게 하세요?
Beads와 Gas Town의 전체 모습을 머릿속에 갖고 있어야 해요. 다른 사람들이 연결해놓은 부분까지 포함해서요. AI한테 이런 질문을 자주 해요. "이거 좀 창피한데, 우리 플러그인 시스템이 어떻게 돌아가는지 알려줘." 마지막으로 제가 확인한 코드인데, 어떻게 작동하는지 기억이 안 나는 거예요.
출처: Steve Yegge, Medium
결국 규율의 문제예요. 직접 안 짠 코드도 정기적으로 살펴봐야 해요. 여러 각도에서 질문하면서 "이제 핵심은 파악했다" 싶을 때까지 계속 보는 거죠. 제품도 마찬가지고요. 안 쓰는 기능이 있으면 왜 갖고 있는지 따져보고, 과감하게 쳐내야 해요. 안 그러면 갚아야 할 빚처럼 문제가 산더미로 쌓이거든요.
"코드를 직접 안 보면 이해를 못 한다"는 사람들이 있는데, 경험이 부족한 시각이에요. 팀을 이끌어본 적 없는 사람, 큰 시스템을 책임져본 적 없는 사람한테서 나오는 말이죠. 저는 미국 해군에서 핵잠수함을 탔었어요. 소프트웨어 프로젝트도 핵잠수함만큼 복잡해요. 6층 높이에 축구장 몇 개 길이죠. 코드를 한 줄 한 줄 다 봐야만 이해할 수 있다는 건 완전히 잘못된 생각이에요.
2시간 뒤처지면 끝나는 세계
Q. 이 속도로 코드를 만들 수 있으면, 팀 단위에서는 어떤 일이 벌어지나요?
제 친구 두 명 이야기를 해볼게요. 각각 에이전트를 20개씩 돌리는 사람들인데, 동료한테 고함을 질렀어요. 2시간 뒤처졌다고요.
에이전트 20개를 돌리면 속도가 워낙 빨라서, 작업을 잠깐이라도 공유하지 않으면 광산 밑에서 혼자 일하는 꼴이에요. 세상이 순식간에 지나가버리고, 그 사이에 만든 코드는 이미 바뀌어버린 코드 위에 얹을 수가 없거든요.
이미지 출처 : 나노바나나 제작
동료가 "저 그거 구현했어요"라고 하니까 "왜? 무슨 정보 보고 한 거야?" 물었고, "2시간 전 정보요"라고 답하니까 "2시간 전? 그 사이에 우리가 결정을 6번이나 바꿨는데?" 이런 거예요. 진짜 심각한 문제예요.
Q. 2시간 만에 결정이 6번 바뀌는 속도라면, 기존의 기획 문서나 계획 같은 건 의미가 있나요?
전통적인 계획 수립은 사라질 거예요. 앞으로 성공하는 회사는 실시간으로 만들 거예요. 소프트웨어 자체가 곧 기획서이자 시제품이 되는 거죠. 테스트용 서버를 5개 띄워서 서로 다른 방향을 시도해보고, 4개를 버리는 식이요. 기획 문서를 돌려보는 시대는 끝나가고 있어요. 아이디어를 공유하되, 그 아이디어에는 실제로 돌아가는 코드가 붙어 있는 거죠.
부서 간 장벽도 무너질 거예요. 조직을 자기한테 유리하게 이용하던 사람들은 다 드러나고요. AI와 잘 일하고, 사람과도 잘 일하고, 혼란 속에서 결과를 만들어내는 사람이 인정받는 시대가 올 거예요.
소프트웨어 제품이 AI 시대에 살아남는 공식
Q. 이번에 처음 공개하신다는 이야기를 해주세요. AI 시대에 소프트웨어 제품이 살아남는 공식이 있다고요?
AI가 기존 소프트웨어를 하나씩 대체하고 있어요. Stack Overflow, Chegg(숙제 도움 서비스), 콜센터 회사... 하나씩 사라지고 있죠. 코드 편집기들도 불안해하기 시작했고요.
살아남는 비결은 에너지 효율이에요. AI가 일할 때 드는 연산 비용을 아껴줄 수 있으면, AI가 그 제품을 쓸 거고, 그러면 살아남아요. AI는 본질적으로 게으르거든요. Anthropic이 AI가 곱셈을 어떻게 하는지 분석한 연구가 있는데, 정확히 계산하는 게 아니라 "대충 95 근처"라고 어림잡은 다음 정답표에서 정확한 값을 찾아요. 항상 최단 경로를 택하는 거죠. 코드를 직접 짜는 게 편할 때가 많지만, 더 빠른 도구가 있으면 그쪽을 택하고요.
이미지 출처 : junkbondinvestor.com
그래서 AI가 직접 하는 것보다 연산 비용을 아끼는 길을 만들어주는 도구가 살아남아요. 계산기, 데이터베이스, 저장소, 네트워크 같은 기본 인프라죠. Beads, Dolt, MongoDB, Kubernetes, Kafka 같은 것들이요. Serena라는 오픈소스 도구도 좋은 예인데, 코드 편집기의 분석 기능을 활용해서 AI가 파일을 하나하나 뒤지지 않고, 이미 정리된 목차에서 바로 찾을 수 있게 해줘요.
다만 도구를 만드는 것만으로는 부족해요. AI한테 그 도구가 있다는 걸 알려줘야 하거든요. Notion이 OpenAI, Anthropic, Google과 직접 협력해서 AI가 자기 도구를 잘 쓰도록 학습시킨 것처럼요. 도구가 아무리 좋아도 AI가 모르면 못 쓰니까요.
극단적으로 가면, 2년 뒤에는 폰에 앱이 하나만 남을 수도 있어요. Claude 하나로 다 되는 세상이죠. 그때 살아남는 건 AI가 혼자서는 접근할 수 없는 데이터를 가진 곳, 아니면 AI보다 토큰을 아껴주는 도구를 가진 곳이에요.
AI를 최대한 레버리지하여, 나만의 스타일로 창업을 꿈꾸는 모든 분들을 위한, 'AI 솔로프리너 클럽'이 진행 중이에요. 제가 운영하는 클럽이며, 새로운 방향을 꿈꾸는 모든 분들께 자신있게 권해드려요.
지금처럼 AI와 소셜미디어를 누구나 쉽게 활용할 수 있는 시기는 역사상 처음이에요. 흐름을 탔을 뿐인데, 인생이 180도 바뀐 제가 직접 이를 증명해요. 그래서 지금이야말로, '나만의 길'을 현실로 만들 수 있는 최고의 타이밍이라고 확신해요.
한 기수당 최대 30명 받는, 프라이빗 클럽입니다. :)
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요