이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

10년간 코딩을 못 했던 YC 대표 Gary Tan이, 9일 만에 다시 개발자가 됐어요.

본인 말로는 "무릎 부상으로 못 뛰다가 바이오닉 무릎을 달아서 5배 빠르게 뛰게 된 느낌"이래요.

그런 Gary가 직접 인터뷰한 사람이 Calvin French-Owen. 수십억 달러에 인수된 Segment의 공동 창업자이자, OpenAI에서 Codex(코딩 에이전트)를 직접 설계한 사람이에요.

코딩 에이전트를 '쓰는 사람'이 아니라 '만든 사람'한테 물어본 이야기라, 깊이가 다릅니다.

1인 창업가에게 도움이 될 내용 위주로 정리했어요.

Q. Claude Code를 직접 써보니까 어땠나요? 전에는 Cursor도 쓰고, Codex도 만들었잖아요.

Claude Code가 지금 제 메인 도구예요. 한동안 Cursor에 깊이 빠져있었어요. Cursor의 새 모델이 정말 빠르고 좋거든요. 그러다가 Claude Code로 넘어왔는데, 특히 Opus 모델이 나오면서요.

Claude Code는 제품과 모델이 같이 잘 작동하는 정도가 과소평가되고 있다고 봐요. 사람들이 잘 모르는 부분이 하나 있는데, Claude Code가 컨텍스트를 분할하는 방식이 정말 뛰어나요.

구체적으로 말하면 이래요.

Claude Code에 뭔가를 시키면, 보통 '탐색 서브 에이전트'를 여러 개 띄워요. 각각의 서브 에이전트가 Haiku 같은 가벼운 모델을 돌려서 파일 시스템을 탐색하고, 뭐가 있는지 파악해요. 중요한 건 각각이 자기만의 컨텍스트 윈도우(대화 기억 공간)에서 작동한다는 거예요. 서로 간섭하지 않아요.

Anthropic이 여기서 뭔가를 알아낸 것 같아요.

'이 작업이 하나의 컨텍스트 윈도우에 들어갈 수 있는가, 아니면 여러 개로 쪼개야 하는가'를 판단하는 부분이요.

모델이 이 판단을 정말 잘 해요. 그래서 결과물의 품질이 좋은 거예요.

Q. 근데 왜 하필 CLI(커맨드라인)인가요? IDE가 더 발전된 도구 아니에요?

이게 정말 이상한 레트로 퓨처 같은 거예요.

CLI는 20년 전 기술이잖아요. 그런데 그게 지금 실제로 모든 IDE를 이기고 있어요.

더 발전된 기술이 더 원시적인 기술에 진 거예요.

이유가 있어요.

Claude Code가 IDE가 '아닌' 것이 사실 중요해요. IDE는 파일을 탐색하는 도구예요. 사용자가 직접 모든 상태를 머릿속에 담아두고 이해하려고 해야 해요. 코드의 흐름을 따라가면서 "이 함수가 저 함수를 호출하고, 저기서 에러가 나면 여기로 돌아오고" 이런 걸 다 파악해야 하거든요. 그런데 CLI는 완전히 다른 물건이에요. 코드 자체를 보는 게 중심이 아니에요. 그래서 사용 경험을 설계할 자유가 훨씬 많아요.

제가 Claude Code를 쓸 때 느끼는 건, 코드 위를 날아다니는 느낌이에요. 여러 가지가 동시에 돌아가고, 작은 진행 표시기들이 나타나고, 상태 업데이트를 해주는데, 작성되는 코드 자체가 중심에 있지 않아요. 그게 포인트예요.

터미널이라서 가능한 것도 있어요. 개발 환경은 원래 지저분하잖아요. 샌드박스가 개념적으로는 깔끔한데, 실제로 쓰면 온갖 문제가 생겨요. Postgres에 접근해야 하는데 안 되고, codex.md 파일을 20줄이나 써도 제대로 안 되고.

CLI에서는 그냥 개발 데이터베이스에 바로 접근할 수 있어요. 사실 프로덕션 데이터베이스에도 접근시켰어요. 그랬더니 "아, 여기 봤는데 이런 일이 있었던 것 같고, 이 동시성 문제를 디버깅하겠습니다"라고 하더라고요. 5단계 깊이로 중첩된 지연 작업(delayed job)을 디버깅해서 버그를 찾아내고, 그 버그가 다시는 안 생기도록 테스트까지 작성하는 걸 봤어요.

Q. 코딩 에이전트의 배포 방식이 왜 중요한가요?

다운로드해서 바로 쓸 수 있다는 게 핵심이에요. Cursor든 Claude Code든 Codex CLI든, 아무한테 허가를 받을 필요가 없어요.

최근에 재미있는 제품을 써봤는데, 데스크톱 앱을 다운로드하면 그 앱이 내 노트북에서 돌아가는 Claude Code를 실행하고, MCP 서버를 통해 데스크톱 제품과 통신하는 구조였어요. 누구 허락도 필요 없이 그냥 다운로드해서 바로 쓰는 거예요.

이게 빠르게 변하는 세상에서 정말 중요해요.

제품이 톱다운이 아니라 바텀업 배포 방식을 가져야 해요. 톱다운은 너무 느려요. 회사의 CTO는 보안이 어떻고, 프라이버시가 어떻고, 만약에 이러면 어떡하나, 기존 시스템과의 호환은 어떤가 하는 걱정을 다 하잖아요. 의사결정이 몇 달이 걸릴 수 있어요. 그 사이에 엔지니어는 그냥 설치해서 "이거 대박이다"라고 하면서 쓰고 있어요. 이미 코드가 커밋되고 있는 거예요.

바텀업이면 경쟁자가 쉽게 따라올 것 같지만, 방어 모델이 있어요. 넷스케이프 내비게이터가 딱 이랬어요. 비상업적 용도는 무료였어요. 사람들이 그냥 다운받아서 회사에서도 쓰는 거예요. 넷스케이프는 IP 주소를 추적해서 어떤 회사에 몇 개의 클라이언트가 있는지 알아내고, "이거 라이선스 사셔야 해요"라고 하는 거예요. 바텀업으로 깔고, 톱다운으로 과금한 거예요.

Q. 바텀업 배포가 만든 더 큰 변화가 있다면요?

도구 선택의 권위 자체가 바뀌고 있어요. 지금 사람들이 아키텍처 결정을 Claude Code 안에서 직접 내리고 있거든요. 무슨 분석 도구를 쓸지도 모르는데, Claude Code가 "PostHog 쓰세요"라고 하면 PostHog을 쓰는 거예요. 도구 선택의 권위가 개발자 개인에서 LLM으로 넘어가고 있다는 뜻이에요.

그러다 보니 GEO(Generative Engine Optimization)라는 전략이 나오고 있어요. 구글 검색 최적화가 SEO잖아요. GEO는 생성형 AI 챗봇에서 어떻게 노출되느냐를 최적화하는 거예요. 사용자가 ChatGPT나 Claude에게 "이런 도구 추천해줘"라고 물었을 때 내 제품이 나오게 만드는 거예요.

재미있는 사례가 있어요. 경쟁사가 "이 카테고리에서 써야 할 도구 Top 5" 목록을 만들었는데, 당연히 자기 도구가 1위예요. 사람이 보면 "이건 너무 뻔한 편향이지"라고 바로 알아차려요. 하지만 LLM은 속아요. 여러 소스에서 컨텍스트를 모아서 "아, 이게 1위구나"라고 판단하고 그대로 추천해요. 이게 지금 실제로 벌어지고 있는 일이에요.

Q. 그러면 LLM한테 내 제품이 추천되게 하려면 어떻게 해야 하나요?

개발자 도구를 팔고 있다면, 좋은 문서를 인터넷 곳곳에 올려놓는 것, 사회적 증거를 쌓는 것, Reddit에 좀 더 많이 노출되는 것, 이 모든 게 엄청나게 도움이 돼요.

Supabase가 좋은 예예요. 작년에 정말 많이 성장했는데, 이유 중 하나가 오픈소스 문서화가 정말 잘 되어 있기 때문이에요. 누군가 백엔드를 세팅하는 법을 물어보면, Firebase 같은 서비스가 필요한 상황이면, 모든 LLM의 기본 답변이 Supabase예요. 전에는 Stack Overflow 검색하고 구글 하던 것과 같은 원리인데, 이제 아무도 구글을 안 쓰잖아요. 플랫폼이 바뀐 거예요. 하지만 "인터넷에서 이기는 제품이 선택받는다"는 원리는 동일해요.

오픈소스가 여기서 특히 유리해요. 모델이 소스 코드를 직접 보고 어떻게 작동하는지 이해할 수 있으니까요. 클로즈드 소스 제품은 이게 안 돼요. 모델이 내부 동작을 모르니까 추측해야 하는 거예요.

그런데 이건 '도구를 파는 쪽' 이야기고, '도구를 쓰는 쪽'에서도 알아야 할 게 있어요.

Q. 에이전트를 더 잘 쓰려면 뭘 알아야 하나요?

핵심은 컨텍스트 관리예요. 코딩 에이전트의 성능은 모델의 지능만으로 결정되지 않아요.

모델에게 '어떤 정보를, 어떤 형태로 주느냐'가 결과를 크게 좌우해요.

OpenAI에서 Codex를 만들 때 했던 걸 말씀드릴게요. OpenAI의 고성능 모델(O3)을 기반으로 잡고, 코딩 작업에 특화되도록 추가 학습을 많이 시켰어요. "이 코딩 문제를 풀어라, 이 테스트를 고쳐라, 이 기능을 구현해라"라는 질문들을 주고 모델이 거기에 답하도록 반복 훈련을 시킨 거예요.

대부분의 사람이 직접 이런 훈련을 하지는 않겠지만, 할 수 있는 건 있어요.

'이 에이전트에게 최상의 결과를 얻으려면 어떤 컨텍스트를 줘야 하는가'를 파악하는 거예요.

앞서 말한 서브 에이전트 방식처럼, Claude Code가 작동하는 걸 보면 파일 시스템의 다른 패턴들을 검색하고, 돌아와서 컨텍스트를 요약해주고, 거기서부터 출발해요.

재미있는 건 코딩 에이전트마다 이 컨텍스트를 구조화하는 방식이 달라요.

Cursor는 의미 기반 검색을 써요. 코드의 의미를 수치로 변환해서 "어떤 쿼리가 이 코드와 가장 비슷한가"를 찾는 방식이에요.

Codex나 Claude Code는 그냥 grep을 써요. ripgrep 같은 도구로 검색해요.

이게 잘 작동하는 이유가 있어요. 코드는 한 줄에 정보가 꽉 차 있어요. 코드 한 줄이 보통 80자 이하잖아요. git ignore를 활용해서 관련 없는 파일을 걸러낼 수 있고, grep과 ripgrep으로 코드 주변의 맥락을 찾을 수 있어요. 그리고 LLM은 사람한테는 고문 같은 복잡한 grep 표현식을 아주 잘 만들어내요.

한 가지 더 알아두면 좋은 건, 에이전트마다 잘하는 프로젝트가 다르다는 거예요.

Codex는 Python 모노레포(회사의 모든 코드를 하나의 저장소에 모아놓은 것)에서 아주 잘 작동하고, Anthropic은 프론트엔드 쪽에 좀 더 강해요.

학습 데이터뿐만 아니라 제품 환경도 변수예요. 모델은 Ruby를 잘 하는데, 제품의 샌드박스 환경이 Rails의 Postgres 접근 방식과 안 맞는 경우도 있거든요.

결국 모델이 탐색하기 쉬운 구조로 데이터를 정리하면 성능이 좋아져요. 이건 코딩이 아닌 업무에도 그대로 적용돼요.

Q. 코딩 에이전트의 상위 1% 사용자가 되려면 어떻게 해야 하나요? 본인은 어떤 스택을 쓰나요?

첫 번째로, 코드와 설정의 양 자체를 줄이는 거예요. 저는 배포 스택을 Vercel, Next.js, Cloudflare Workers 같은 곳에 올려요. 이런 플랫폼들은 기본 설정이 이미 다 잡혀있어서, 인프라 세팅에 드는 시간이 거의 없어요. 거의 100~200줄 코드 안에 다 정의돼요.

두 번째로, LLM의 초능력이 뭔지 아는 게 중요해요. 코딩 에이전트는 안드레이 카파시가 최근에 트윗한 것처럼 엄청나게 끈질겨요. 맞는 방향으로 가면 엄청난 생산성이 되지만, 잘못된 방향으로 빠지면 멈추지 않고 계속 삽질해요. 그래서 에이전트를 올바른 방향으로 유도하는 게 핵심이고, 기존 코드의 품질이 여기서 매우 중요해요.

세 번째로, 모델이 자기 작업을 검증할 수 있게 해주면 성능이 극적으로 좋아져요. 테스트를 돌리고, 린트를 실행하고, CI를 걸어주는 거예요. 저는 코드 리뷰 봇도 적극적으로 사용해요. Reptile이라는 YC 회사가 정말 좋고, Codex도 코드 리뷰에 아주 좋아요.

네 번째로, 에이전트가 못하는 걸 아는 것도 중요해요. 에이전트의 기본 성향이 '추가 생산'이다 보니, 줄이거나 단순화해야 할 때는 오히려 방해가 돼요. 코드를 자주 복제하고 이미 있는 것을 다시 구현하는 데 시간을 낭비하곤 해요.

다섯 번째로, 컨텍스트 오염을 조심해야 해요. 이전 대화가 쌓이면서 에이전트의 판단이 흐려지는 현상인데, 사람은 중간에 "잠깐, 이거 아닌 것 같은데?"라고 멈추지만 에이전트는 안 멈춰요. 이건 다음 질문에서 더 자세히 다룰게요.

Q. 말씀하신 것처럼 대화하다가 에이전트가 삽질을 하기 시작하면 어떻게 하나요?

컨텍스트를 지우는 게 가장 효과적이에요. 저는 보통 토큰이 50%를 넘으면 새로 시작해요.

이 개념을 잘 설명한 사람이 있어요. Dex라는 사람인데, Human Layer라는 회사를 만든 YC 출신이에요. 이 사람이 'LLM의 바보 존(dumb zone)'이라는 개념을 말해요. 일정량의 토큰을 넘으면 품질이 떨어지기 시작한다는 거예요.

이게 왜 그런지 생각해보면, 대학생이 시험을 보고 있어요. 시험 시작 후 5분에는 "시간 많으니까 하나하나 잘 생각해서 풀자" 이러거든요. 그런데 5분 남았는데 아직 절반이 남았어요. "아 그냥 뭐라도 쓰자" 이렇게 되잖아요. LLM의 컨텍스트 윈도우가 정확히 이거예요.

재미있는 트릭이 하나 있어요.

컨텍스트 윈도우의 시작 부분에 감시용 문장을 넣는 거예요. "내 이름은 캘빈이고, 아침 8시에 차를 마셨다" 이런 식으로 아무 관련 없는 사실을요. 그러고 나서 계속 작업하다가 중간중간에 "내 이름이 뭐야?"라고 물어보는 거예요. 그걸 잊어버리기 시작하면, 컨텍스트가 오염되었다는 신호예요.

Q. 도구가 알아서 컨텍스트를 관리할 수는 없나요? Claude Code와 Codex는 이 문제를 어떻게 풀고 있어요?

기술적으로는 가능해요.

주기적으로 자기 상태를 점검해서 기억이 흐려지는지 확인하는 거죠. 하지만 아직 거기까지는 안 왔어요.

Claude Code가 이걸 우회하는 방식은 앞서 말한 컨텍스트 분할이에요. 작업을 여러 서브 에이전트로 쪼개서 처리하는 거죠. 하지만 세션 끝에 컨텍스트에 들어있는 것은 고정되어 있어요.

Codex의 접근법은 정반대예요. Codex는 매 턴마다 대화 내용을 요약·압축하는 과정(컴팩션)을 실행해요. 그래서 Codex는 아주 오래 돌릴 수 있어요. CLI에서 퍼센트를 보면, 컴팩션이 실행되면서 올라갔다 내려갔다 하는 걸 볼 수 있어요.

근본적으로 두 도구는 철학이 달라요.

Claude Code는 사람과 같이 일하는 도구에 가깝고, Codex는 혼자서 몇 시간에 걸쳐 긴 작업을 수행하는 자율 에이전트에 가까워요. 둘 다 코딩 에이전트라고 불리지만, 근본 철학이 다른 거예요.

궁극적으로 백만 토큰 컨텍스트를 매번 쓸 수 있으면 좋겠지만, 더 중요한 건 긴 작업 흐름에서의 학습이에요. 

한참 전에 했던 작업을 나중에 참조해서 다음에 뭘 해야 할지 이해하는 건 아직 훨씬 어려운 문제예요.

Q. CLI 중심 도구와 자율 에이전트, 결국 어느 쪽이 이기나요?

이건 두 회사의 창업 DNA로 돌아가는 질문이에요. 근본적으로 다른 세계관을 가진 두 회사가 코딩 에이전트를 만들었으니까요.

Anthropic은 항상 '인간을 위한 도구 만들기'에 집중했어요.

Claude Code는 그 자연스러운 연장선이에요. 개집을 만들어야 한다고 하면, "하드웨어 가게에 가서 재료를 사고, 어떻게 조립하는지 알아낼게요"라고 하는 식이에요. 사람이 옆에서 보면서 "아 저기 좀 다르게 해봐"라고 말할 수 있는 구조예요.

반면에 OpenAI는 "최고의 모델을 훈련시키고, 시간이 지나면서 강화학습으로 점점 더 긴 작업을 하게 만들자"는 방향이에요. 개집 예시로 돌아가면, 3D 프린터가 처음부터 개집을 출력하는 거예요. 이상한 방식으로 만들지만, 결국은 작동하는.

궁극적으로 후자가 어느 정도 불가피해 보이지만, 저는 전자가 너무 좋아요. 직접 손으로 코드를 다듬던 그 장인 같은 느낌을 에이전트와 함께 다시 느낄 수 있거든요. 다만 혼자서 할 때보다 5배는 빠르게요.

그런데 이 도구를 실제로 쓰는 현장에서는, 회사 규모에 따라 풍경이 완전히 달라요.

Q. 회사 규모에 따라 쓰는 모습이 완전히 다르다고 하셨는데요, 대기업과 스타트업에서 이 도구들의 활용은 어떻게 다를까요?

취미 수준이나 작은 스타트업에서 실험하는 사람들은 코딩 에이전트를 끝까지 밀어붙이고 있어요. 다른 걸 파악할 시간이 없으니까요. 스타트업은 런웨이가 한정돼 있으니까 속도에 올인하는 거예요.

"제대로 된 아키텍처를 고민하는 것보다, 일단 되게 만드는 게 낫다"는 거예요.

큰 회사는 잃을 게 더 많아요. 코드 리뷰 같은 내부 프로세스가 있고, 이미 큰 엔지니어링 팀을 고용했잖아요. 모든 변경 사항이 여러 단계의 승인 과정을 거쳐야 하고, 보안 검토도 있고. 코딩 에이전트를 도입한다고 해도 기존 프로세스와 어떻게 맞추느냐가 문제예요.

그런데 이상한 일이 생길 거예요. 혼자 일하는 개별 팀이 "저 팀이 제대로 안 하고 있으니까 내가 프로토타입을 만들어볼게"라고 하는 거예요.

코딩 에이전트 덕분에 한 사람이 만든 프로토타입이 10명 팀이 만든 것보다 더 빠르게, 때로는 더 잘 돌아가는 상황이 올 수 있어요. 

Q. 그러면 어떤 유형의 사람이 가장 큰 혜택을 받을까요?

일반적으로 시니어일수록 더 많은 혜택을 받아요. 이건 직감에 반하는 이야기일 수 있어요. AI가 코딩을 대신 해주니까 경험 적은 사람이 유리할 것 같은데 실제로는 시니어가 더 큰 레버리지를 얻어요.

에이전트가 아이디어를 실행에 옮기는 데 정말 뛰어나거든요. 시니어 엔지니어는 뭘 만들어야 하는지, 어떤 아키텍처가 맞는지를 이미 알아요. 그 아이디어를 몇 마디로 프롬프트할 수 있으면, "갑자기 이 아이디어가 있었는데 바로 실현됐어"라는 경험을 하게 돼요.

체계적인(매니저 성향의) 엔지니어도 유리해요. 여러 세션에 걸쳐서 "이 작업 끝났어, 여기 당신의 입력이 필요해"라고 알려주는 제품이 나오면, 매일 아침 "밤새 이런 일이 됐어, 세 가지 결정을 내려야 해"라고 안내받는 방식으로 일하게 돼요.

멀티태스킹하는 사람도 유리해요. 항상 좋은 프로젝트를 여러 개 동시에 진행하는데, 하나도 끝내지 못하는 유형 있잖아요. Claude Code가 이걸 바꿔요. 모든 걸 끝까지 가져가줘요. 다른 아이디어가 떠올라서 그쪽으로 가고 싶을 때, 이제 진짜 그렇게 해도 돼요. 보통이라면 이쪽저쪽 왔다갔다 하면서 모든 게 반만 되어있잖아요. 이제는 전부 다 완성돼요.

심지어 미팅이 많은 사람도 코딩할 수 있게 됐어요. PG(폴 그레이엄)의 유명한 글처럼 메이커 스케줄과 매니저 스케줄은 원래 양립하기 어려웠어요. 예전에는 최소 4시간 빈 시간이 있어야 코딩을 시작할 가치가 있었거든요. 머릿속에 모든 클래스 이름, 함수, 코드가 건드리는 부분에 대한 데이터를 채워야 했으니까요. 이제는 에이전트가 알아서 쌓으니까, 10분이든 30분이든 빈 시간이 생기면 바로 의미 있는 작업을 시작할 수 있어요. YC 파트너들도 미팅 중에 에이전트를 돌려놓고 나중에 확인해요.

1인 창업가에게 특히 큰 변화예요. 미팅과 미팅 사이, 아이를 재우고 난 뒤에도 실질적인 개발을 진행할 수 있다는 뜻이니까요.

Q. 다음 세대는 어떻게 복잡한 시스템 관리를 배울 수 있을까요? 대학교에 다시 간다면 뭘 공부하겠어요?

AI가 대신해주는 세상에서 '진짜 실력'을 어떻게 키우느냐는 문제예요. 제 10살 아이가 매일 글쓰기 과제를 하는데, 어제 처음으로 AI를 썼어요. 보니까 10살이 쓸 수 있는 표현이 아닌 거예요.

이걸 우리 맥락에 적용해보면, 18~22세 인턴들이 아직 매니저 업무를 해본 적이 없잖아요. 수십만 개의 에러를 일일이 살펴보면서 모든 사용자를 위해 시스템이 잘 돌아가는지 확인하는 정말 화려하지 않은 일이요. 다음 세대가 이걸 어떻게 배울까요?

개인적으로는 시스템을 이해하는 게 여전히 중요하다고 봐요. Git이 어떻게 작동하는지, HTTP, 데이터베이스 등이요. 에이전트가 코드를 대신 짜주더라도, 그 코드가 돌아가는 인프라를 이해하지 못하면 문제가 생겼을 때 대응할 수 없으니까요.

또 하나는 한 학기 동안 매주 뭔가를 만들면서 모델을 끝까지 밀어보는 거예요. 모델이 어디까지 할 수 있고 어디서부터 못하는지를 아는 건 계속 움직이는 목표라서, 그냥 많이 만져보는 게 가장 좋아요.

Q. 제품을 만들 때 가장 중요한 건 뭔가요?

제가 제품을 만들 때 가장 시간을 많이 쓰는 건, '사용자가 이 제품을 머릿속에서 어떻게 이해하게 할 것인가'를 설계하는 거예요. 기능 목록이 아니라, 사용자가 직관적으로 파악할 수 있는 기본 개념 구조를 정하는 거예요.

Slack이 그런 제품이라고 볼 수 있죠. Slack은 사실 새로운 개념이 아니었어요. 전에도 채팅 앱은 많았거든요. 하지만 채널, 메시지, 리액션을 단순한 방식으로 구성했고, 사람들이 "아, 이거 어떻게 쓰는지 알겠다"라고 바로 이해할 수 있었어요.

그런데 사용자가 그 이해 방식에 익숙해지면, 나중에 바꾸기가 정말 어려워요.

에이전트 시대에는 이 초기 설계가 과거보다 훨씬 더 중요해졌어요. 그 기본 틀을 코딩 에이전트에 넘기면, 에이전트가 거기서 시작해서 영원히 만들어나가거든요.

첫 번째 100줄의 코드가 나중에 10만 줄의 코드의 방향을 정하는 거예요.

Q. 미래의 SaaS는 어떻게 달라지나요?

이건 당장의 이야기는 아니지만, 훨씬 먼 미래를 상상해보면 소프트웨어는 완전히 개인화돼요. 지금처럼 모든 사람이 똑같은 SaaS를 쓰는 게 아니라, 각자 자기만의 버전을 갖게 돼요.

누군가 Segment(Calvin이 만들었던, 고객 데이터를 여러 분석 도구에 연결해주는 서비스)에 가입할 때마다 코드베이스를 포크(복제)해서 자기만의 Segment를 갖는 거예요. 뭔가를 바꾸고 싶으면 그냥 채팅창에 말하면 되고, 그 뒤에서 에이전트 코딩 루프가 돌면서 자기 버전을 수정해요. 본사가 새 기능을 내보내면, 에이전트가 자동으로 합치는 방법을 알아내요.

결국 일하는 모든 사람이 자기만의 클라우드 에이전트 세트를 갖게 돼요. 슈퍼 EA(Executive Assistant)를 가진 것과 비슷해요. 사람들이 직접 만나서 아이디어를 교환하는 공간은 여전히 있고, 별도로 에이전트 군단이 당신을 대신해서 일하고 있는 거예요.

평균적인 회사는 조금 더 작아지고, 대신 더 많은 회사가 더 많은 일을 할 거예요.

Q. 그러면 Segment를 다시 만든다면 뭘 바꾸겠어요?

먼저 큰 그림을 말씀드리면, 데이터 모델은 여전히 일관성이 있어야 하고, 원본 데이터를 관리하는 중심 시스템이 필요해요.

Segment가 처음에 시작한 건 통합(integration)을 만드는 거였어요. 같은 데이터를 Mixpanel, Kissmetrics, Google Analytics 등에 연결하는 거예요. 예전에는 각각의 분석 도구에 맞게 데이터를 보내는 코드를 직접 짜야 했어요. 그게 귀찮은 일이었어서 Segment처럼 한 곳에서 다 처리해주는 서비스에 돈을 낼 만했어요. 지금은 그 가치가 0으로 떨어졌어요. "이 데이터를 이렇게 매핑해줘"라고 Claude나 Codex에 말하면, 정확히 원하는 대로 해주니까요.

하지만 데이터 파이프라인을 계속 돌리고, 비즈니스의 일부를 자동화하는 것. 그 가치는 아직 있어요. 이건 코드 몇 줄 짜는 문제가 아니라, 지속적으로 안정적으로 돌아가야 하는 인프라니까요.

제가 다시 만든다면 스택을 위로 올라가겠어요. 아래쪽의 저수준 연결 작업은 이제 LLM이 해주니까 필요 없어졌고, 고객 한 명 한 명에 맞춰서 제품 경험을 실시간으로 바꾸는 것, 캠페인 단위의 비즈니스 임팩트가 큰 일을 하는 거예요.

이건 SaaS를 만드는 사람이라면 꼭 생각해볼 포인트예요. 

내 제품이 해주는 일 중에서 LLM이 대체할 수 있는 부분이 어디인지, 그 위에서 새로 만들어야 할 가치가 뭔지를요. 물론 이렇게 빠르게 만들 수 있게 되면, 당연히 따라오는 질문이 있어요. LLM이 만든 코드를 바로 믿을 수 있을 것인가?

Q. 에이전트가 만든 코드, 품질은 어떻게 보장하나요?

테스팅이 결정적이에요. 처음 9일 중 2~3일은 테스트 없이 작업했어요. 그러다 하루를 잡아서 "오늘은 리팩토링 데이. 100% 테스트 커버리지까지 가겠어"라고 했어요.

그러고 나니까 속도가 미친 듯이 빨라졌어요. 테스트 커버리지가 너무 좋으니까 아무것도 안 깨져요. 에이전트가 새 기능을 추가하면 테스트가 바로 잡아주고, 에이전트가 그걸 보고 고치고. 이 사이클이 돌아가기 시작하면 사람이 직접 개입할 일이 거의 없어져요.

아직 부족한 부분도 있어요.

여러 작업을 합치고 순서를 정하는 과정은 아직 병목이에요. 코드를 합치면 누가 봐야 하는지, 변경 사항을 어떻게 검증하는지. 이런 자동화는 아직 구축해야 해요.

하지만 코딩에서든 프롬프트에서든, 검증 루프가 있느냐 없느냐가 결과 품질의 분기점이에요.

Q. 테스트로 많이 좋아졌다고 했는데, 그래도 완전히 해결할 수는 없지 않나요?

맞아요. Claude Code용 Stack Overflow 같은 게 필요할 것 같아요.

제가 겪은 사례가 있어요. 작업 큐의 우선순위에서 콤마가 들어간 문자열을 넣었는데, 그 시스템은 JSON 배열을 기대하고 있었어요. 그러니까 아무 작업도 안 돌아가는 거예요. 30분 동안 Rails의 Active Job 내부를 수천 줄이나 탐색하면서 디버깅하는 걸 지켜봤어요. 실제로 버그를 찾긴 했어요.

10년 전이었으면 Stack Overflow에서 "콤마 구분 문자열 넣으면 안 되고 배열로 넣어야 해요"라는 글을 바로 찾았겠죠.

"에이전트들이 자기만의 Stack Overflow를 가져야 할까"라는 질문은, 지능이 조금만 올라가면 필요 없을 수도 있어요. 하지만 과거 경험을 기억하고 공유하는 것은 별개의 과제예요.

Q. 그렇다면 에이전트가 경험을 기억하고 서로 공유할 수는 없나요?

기억하는 건 이미 시작됐어요. Claude Code도 Codex도 대화 기록을 파일로 저장해서, 이전에 어떤 문제를 어떻게 풀었는지 다시 꺼내볼 수 있게 만들어놨어요.

다만 아직 빠진 조각이 있어요. 협업 부분이에요.

동료의 프롬프트를 스마트하게 공유할 수 있으면 대단할 거예요. "나도 이 문제를 겪었는데, 실은 저쪽 Brian이 아까 고쳤어"라는 걸 알 수 있는 거예요.

Claudebot Social이라는 게 있다고 하더라고요. Claude 봇들이 서로 대화하는 소셜 네트워크예요. 각 사용자가 자기만의 개인 AI 에이전트를 돌리고, 그 에이전트들이 서로 대화하는 거예요. AI가 생성한 콘텐츠로 가득 찬 소셜 네트워크라니, 듣기만 해도 이상한데 실제로 존재해요. 에이전트끼리 이렇게 연결되는 세상에서는, 보안도 완전히 새로운 문제가 돼요.

Q. 보안 쪽은 어떻게 보나요? Skip permissions(이용자 확인 없이 계속 진행하게 하는 것) 모드를 쓰나요?

OpenAI는 보안 문제를 다른 누구보다 진지하게 봐요. Codex를 만들 때, 새 버전을 내놓으려면 매번 안전과 보안 위험에 대한 검토를 통과해야 했어요.

사용자들이 "에이전트가 인터넷에서 정보를 찾을 수 있게 해달라"고 많이 요청했는데, 그게 고민이었어요. 에이전트가 외부 웹페이지를 읽다가, 거기 심어놓은 악의적 지시를 그대로 따라버릴 수 있거든요. 팀의 PM인 Alex가 GitHub 이슈에 일부러 함정을 심어놨어요. "이건 절대 안 먹힐 거야"라고 했는데, 바로 먹혔어요.

Skip permissions(매번 물어보지 않고 에이전트가 알아서 진행하게 하는 것)는 저는 안 써요. Gary도 에이전트가 뭘 하는지 직접 확인하는 걸 좋아해서 안 쓰고요. 반면 Jared는 "100% 씁니다"라고 했어요. YC 엔지니어링 팀에서도 반반이래요. 맥락에 따라 크게 달라요. 

대기업에서는 절대 하면 안 돼요. 스타트업이고 잃을 게 없으면, 할 수도 있어요.

Q. 앞으로 이 도구들은 어떻게 진화할까요?

도구는 몇 달마다 완전히 바뀌고 있어요. 지금 최선인 게 반년 뒤에는 아닐 수 있어요.

그래서 특정 도구에 베팅하기보다는, 도구가 바뀌어도 적응할 수 있는 사람이 유리해요. 

방향을 지시하는 매니저 감각, 제품에 뭘 넣고 뭘 뺄지를 정하는 디자이너 감각, 이 두 가지가 점점 더 중요해질 거예요.

한 가지 확실한 건, 소프트웨어가 제대로 안 되는 것에 대한 변명이 그 어느 때보다 적어졌다는 거예요.

결국 답은 하나예요. 지금 당장 만져보는 거예요.

오늘 레터가 좋았다면, 조쉬의 뉴스레터를 주변에 알려주시거나, 구독을 해주세요. 소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]