Report · 산업 · AI 엔지니어링
"토큰을 낭비하고 시간을 벌어라." 프런티어 창업자 네 명이 말하는, 코드를 직접 쓰지 않는 시대의 엔지니어링.
2026년 6월, 투자자 나발 라비칸트(Naval Ravikant)가 진행하는 팟캐스트의 한 회차에 프런티어 창업자 세 명이 모였다. 클라우드 플랫폼 회사 버셀(Vercel)의 기예르모 라우흐(Guillermo Rauch), 초음속 여객기를 만드는 붐 슈퍼소닉(Boom Supersonic)의 블레이크 숄(Blake Scholl), 그리고 실리콘 위에 살아 있는 신경세포를 키워 뇌-기계 인터페이스를 만드는 사이언스(Science)의 맥스 호닥(Max Hodak)이다.
진행자가 던진 틀은 분명했다. 이들이 무엇을 만드는지가 아니라, 어떻게 만드는지에서 무엇이 달라지고 있는가. 세 사람 모두 기성 부품을 조립하는 대신 자기 공장을 직접 짓는 사람들이다. 첫 번째 대화의 주제는 소프트웨어 엔지니어링이었고, 도달한 결론은 도발적이었다. 코드를 손으로 쓰는 일은 이미 끝나가고 있다는 것이다.
라우흐가 꺼낸 개념은 "소프트웨어 공장(software factory)"이다. 과거 엔지니어를 평가하는 기준은 단순했다. 그가 맡은 결과물 하나를 얼마나 잘 만들어 내느냐. 사람 A가 산출물 B를 얼마나 잘 뽑느냐가 곧 그의 값어치였다.
이제 라우흐가 묻는 질문은 다르다. 당신은 산출물 하나를 만드는 사람인가, 아니면 산출물을 줄줄이 찍어 내는 공장을 만드는 사람인가. 한 개의 결과물 B가 아니라, B부터 Z까지를 곱셈처럼 쏟아 내는 생산 라인을 설계할 수 있느냐가 새로운 기준이 된다.
가구 장인은 의자를 직접 깎는다. 솜씨가 좋으면 더 좋은 의자가 나오지만, 하루에 만들 수 있는 양은 손의 속도에 묶인다. 공장 설계자는 의자를 깎지 않는다. 의자를 찍어 내는 기계를 설계한다. 기계가 한 번 돌기 시작하면 의자 한 개가 아니라 수백 개가 나온다.
AI(인공지능, Artificial Intelligence) 에이전트 시대의 엔지니어는 점점 후자에 가까워진다. 직접 코드를 치는 대신, 코드를 대신 써 줄 에이전트의 작업 흐름을 설계한다.
라우흐와 라비칸트는 한때 논쟁적이던 '10배 엔지니어' 가설을 끌어온다. 같은 직군 안에서도 어떤 사람은 다른 사람보다 열 배의 결과를 낸다는 주장이다. 두 사람이 보기에 이 숫자는 너무 작다. 아이디어와 지적 영역, 가상·디지털 영역에서는 격차가 10배가 아니라 100배, 1000배이며, 사실 늘 그래 왔다는 것이다.
라비칸트는 이런 주장이 "모두가 평등하다"는 통념과 충돌해 과거 비판을 받았다고 회고한다. 그는 1000배 프로그래머의 예로 자바스크립트(JavaScript)를 만든 브렌던 아이크(Brendan Eich), 게임 엔진의 전설로 불리는 존 카맥(John Carmack), 비트코인(Bitcoin)을 설계한 익명의 사토시 나카모토(Satoshi Nakamoto), 마인크래프트를 만든 노치(Notch)를 든다.
그리고 한 가지를 덧붙인다. 더 큰 변수는 '무엇을 만들기로 선택하느냐'다. 옳은 문제를 고른 사람과 그른 문제를 고른 사람의 차이는 배수가 아니라 무한대일 수 있다. 더 나은 프로그래머가 아니라, 그저 무엇에 매달릴지에 대한 판단이 좋았던 사람이 앞선다. 그가 보기에 AI라는 지렛대 덕에 이 생산성 격차 주장은 이제 덜 논쟁적이 되었다.
새로운 생산성에는 새로운 측정 문제가 따라온다. 라우흐는 "토큰 리더보드(token leaderboard)"의 혼란을 짚는다. 100배 엔지니어들을 데리고 있다고 자부하는데, 정작 눈에 보이는 건 그들이 태운 막대한 토큰 청구서뿐인 상황이다. 그렇다면 투자 대비 수익(ROI, Return on Investment)은 어떻게 재야 하는가.
숄은 이를 과거의 '코드 라인 수' 측정에 빗댄다. 코드를 많이 짰다고 일을 잘한 게 아니듯, 토큰을 많이 썼다고 가치를 많이 만든 것은 아니다. 둘 다 결과를 직접 가리키는 지표가 아니다.
라비칸트의 처방은 단순하다. 토큰을 입력으로도 출력으로도 보지 말라. 당신의 시간과 최종 결과물만 보라. 그는 같은 문제를 코덱스(Codex), 클로드(Claude), 제미나이(Gemini)에 동시에 던지고, 쓸 만한 답이 나올 때까지 토큰을 거리낌 없이 낭비한다고 말한다. 모델이 아무리 비싸 보여도 사람 인건비보다는 훨씬 싸기 때문이다.
토큰을 낭비하고 시간을 벌어라.— Naval Ravikant
설령 모델이 저품질 코드를 쏟아 내더라도, 운영에 올릴 때가 되면 토큰을 더 부어 다시 쓰게 시키면 된다. 검증 가능하고 이미 풀린 문제의 영역이라면, 모델은 세대가 바뀔수록 그 문제를 더 잘 해결할 것이다. 다만 라비칸트도 단서를 단다. 아직 풀리지 않은 창의의 최전선 — 이를테면 수학자 테런스 타오(Terence Tao)가 서 있는 자리 — 에서는 모델과 훨씬 긴밀하게 협업해야 하지만, 자신의 소프트웨어 작업은 그 수준이 아니라는 것이다.
번역가에게 통째로 일을 맡기면 시간당 비용이 든다. 반면 자동 번역기는 같은 문단을 열 번, 스무 번 돌려도 사람 한 시간 값에 못 미친다. 결과가 마음에 안 들면 다시 돌리면 그만이다.
모델의 토큰도 비슷하다. 낭비처럼 보이는 재시도가, 사람의 시간을 아끼는 가장 싼 방법이 된다. 그래서 토큰의 절대량이 아니라 아낀 시간으로 셈하라는 것이다.
호닥의 관찰은 불편하지만 정확하다. 모델은 그 분야에서 대체로 사용자만큼 똑똑하다. 유능한 개발자가 쓰면 강력한 도구가 되고, 초급 개발자가 쓰면 초급 개발자처럼 군다. 사용자가 띄엄띄엄 던지는 피드백이 결과의 수준을 좌우한다.
그래서 라우흐에게는 새로운 종류의 도움이 생겼다. 모델에서 좋은 결과를 못 얻은 동료에게, 모델에 무엇을 어떻게 다시 물을지 알려 주는 일이다. '다시 묻는 법(reprompting)'의 품질이 결과를 가른다. 다만 호닥은 이것을 한시적 현상으로 본다. 모델이 더 똑똑해질수록 적게 넣고 많이 얻게 될 것이다. 적어도 지금 단계에서는, 모델이 사용자의 판단을 그대로 되비춘다.
모델은 거울에 가깝다. 거울 앞에 선 사람이 또렷하면 또렷한 상이 맺히고, 흐릿하면 흐릿한 상이 맺힌다. 같은 모델이라도 누가, 어떻게 묻느냐에 따라 전혀 다른 수준의 답이 돌아온다.
지금 단계에서 도구의 성능은 사용자의 판단력을 비추는 면이 크다. 도구를 탓하기 전에 '내가 무엇을 어떻게 물었는가'를 먼저 보게 되는 이유다.
라우흐는 최근 모델에서 일어난 변화를 짚는다. 예전 모델은 지시를 받으면 곧장 다음 단어를 이어 붙이듯 일을 시작해, 사용자의 아이디어를 제멋대로 끌고 갔다. 요즘 모델은 시키지 않아도 먼저 계획을 세운다. "당신이 원하는 걸 하려면 세 가지 경로가 있고, 각각 이런 절충점이 있다"며 되묻는다. 한때 주니어 엔지니어 같던 모델이, 이제 트레이드오프를 들고 오는 수석(principal) 엔지니어처럼 군다는 것이다. 물론 허세도 있다. "이건 3주 걸립니다" 같은 엉터리 추정을 천연덕스럽게 내놓는다.
판단이 빛나는 지점은 기술 선택이다. 호닥은 팀의 주니어 엔지니어가 다음 단계로 올라설 때, 일이 '기능 구현'에서 '기술 선택'으로 옮겨 간다고 말한다. 데이터베이스로 포스트그레스(Postgres, 범용 관계형 데이터베이스)를 쓸지 다른 것을 쓸지, 메시지 큐로 제로엠큐(ZeroMQ)를 쓸지 다른 것을 쓸지. 모델이 후보를 제시할 수는 있지만, "아니, 나는 이걸 쓰겠다"고 결정하는 작은 피드백이 결과를 좌우한다. 라비칸트는 이를 취향과 판단(taste and judgment)이라 부른다.
흥미로운 건, 그 취향의 근거조차 모델에게 물으면 꽤 괜찮은 절충표를 내놓는다는 점이다. 라우흐가 직접 겪은 일이 있다. 값의 종류가 매우 많은(high-cardinality) 원격 측정 데이터를 포스트그레스에 넣으라고 했더니, 모델이 그런 데이터는 포스트그레스에 넣지 않는다며 클릭하우스(ClickHouse, 대용량 로그·시계열 분석에 강한 열 기반 데이터베이스) 같은 것을 고려하라고 받아쳤다는 것이다. 시키는 대로 받아 적던 도구가, 이제 설계를 두고 이의를 제기한다.
이 대목에서 라비칸트는 더 큰 질문을 던진다. 순수 소프트웨어는 죽었는가. 과거에는 모델과 대화하려면 코드라는 언어를 배워야 했다. 이제 모델이 사람의 어설프고 두루뭉술한 영어를 알아듣고 되받는다. 코드가 모델과의 유일한 통로이던 시절이 끝났다면, 소프트웨어 회사의 해자(moat, 경쟁 우위를 지키는 방어선)는 어디에 남는가.
그는 하드웨어 창업자에게는 반사이익이라고 본다. 예전엔 하드웨어를 만들면서 좋은 소프트웨어까지 갖추기가 어려웠는데, 이제 소프트웨어를 빠르게 붙일 수 있기 때문이다. 그는 스트라이프(Stripe) 창업자 패트릭 콜리슨(Patrick Collison)의 말을 빌린다. 소프트웨어는 예술이고, 예술가를 고용하기는 어렵다는 것이다.
라우흐의 답은 '빌딩 블록 경제(building block economy)'다. 터미널 프로그램 고스티(Ghostty)와 인프라 도구 테라폼(Terraform)을 만든 미첼 하시모토(Mitchell Hashimoto)가 2026년 4월에 쓴 글에서 나온 개념이다. 핵심은 이렇다. 이제 가장 쓸모 있는 것은 완성된 거대 애플리케이션이 아니라, 남들이 가져다 조립할 수 있는 견고하고 잘 문서화된 '블록'이다. AI 에이전트는 매번 바닥부터 새로 짜기보다, 잘 만들어진 부품을 가져다 붙이기를 선호하기 때문이다. 하시모토 자신의 사례에 따르면, 완성된 앱 고스티가 한참에 걸쳐 도달한 사용자 규모를, 그 핵심을 떼어 낸 라이브러리가 훨씬 짧은 기간에 넘어섰다(정확한 집계는 어렵다는 단서를 그도 달았다).
라우흐는 에이전트가 이메일 한 통 보내려고 큐 시스템을 통째로 다시 발명하길 원하지 않는다고 말한다. 그 일에는 불엠큐(BullMQ) 같은, 작업에 꼭 맞는 블록을 끌어오면 된다. 그는 한 발 더 나간다. 에이전트가 세상의 모든 것을 자기 식대로 처음부터 다시 만든다면, 그것은 나만을 위한 고속도로와 법과 정책을 새로 까는 것과 같다. 최적화의 여지가 조금 있더라도, "우리 둘 다 포스트그레스 13.2에 의존한다"는 사실에서 오는 대규모 협업의 가치가 더 크다. 그는 또 하나의 비유를 보탠다. 이미 만들어진 것은 모델에게 '토큰 캐시(token cache)'와 같다. 이미 존재하는 것을 재현하려고 1조 개의 토큰을 태울 이유가 없다. 라비칸트가 정리한다. 결국 이것들은 모델을 위한 라이브러리이자 의존성이다.
집을 지을 때 벽돌과 배관, 전선 규격을 매번 새로 발명하지 않는다. 표준 부품을 가져다 쌓는다. 그래야 빠르고, 남의 집과도 호환된다.
AI 에이전트도 마찬가지다. 검증된 부품(블록)을 조립하는 편이, 매번 1조 개의 토큰을 태워 바닥부터 만드는 것보다 싸고 안전하다. 이미 존재하는 것은 다시 계산할 필요가 없는 '캐시'인 셈이다.
마지막으로 호닥은 코딩 경험의 질적 변화를 이야기한다. 그는 어릴 때부터 프로그래밍에 빠져 한 번에 스무 시간씩 코드를 짜던 사람이지만, 한동안 코드를 한 줄도 쓰지 않았다고 말한다. 그런데도 지난 몇 달 사이, 오래 상상만 하던 프로그램들을 직접 만들어 매일 쓰고 있다. 단 한 줄도 손으로 쓰지 않았다. 이제 손으로 코드를 짜는 시절로 돌아가는 것은 상상하기 어렵다는 것이다.
라우흐는 그 비결이 '부품이 어떻게 맞물리는지'를 이해하는 데 있다고 본다. API(응용 프로그램 인터페이스, Application Programming Interface)가 무엇인지, 데이터가 어떻게 흐르는지, 성능의 기댓값이 어느 정도인지 아는 사람은 모델에게 올바른 기준을 줄 수 있다. 그는 유능한 엔지니어링 리더가 늘 해 오던 일이 사실은 일종의 '바이브 코딩(vibe coding)'이었다고 말한다. 슬랙(Slack) 메시지나 일대일 면담으로 자신의 의도와 경험을 전달하고, 남이 그것을 받아 실행하게 하는 일. 이제 그 대상이 사람에서 에이전트로 바뀌었을 뿐이다.
라비칸트의 경험이 이를 뒷받침한다. 그는 20년간 코드를 안 쓰다가, 이제 에이전트를 통해 늘 코딩한다. 소프트웨어 공학과 알고리즘의 기본 원리만 알아도 멀리 갈 수 있더라는 것이다. 그가 코딩을 그만뒀던 이유는 최신 언어와 인프라를 따라잡을 시간이 없어서였는데, 그 시작의 번거로움이 사라졌다.
호닥이 핵심을 짚는다. 예전에는 일이 술술 풀리다가도 어느 순간 사소한 문제에 걸려 끝없이 디버깅에 시간을 쏟곤 했다. 프로그래밍은 본질적으로 답답한 것이고 그렇게 배우는 것이라던 통념. 그것이 더 이상 사실이 아니다. 에이전트와 함께라면, 이제 막히지 않는다.
대화는 한 가지 그림으로 수렴한다. 엔지니어의 가치가 코드를 치는 손끝에서, 무엇을 만들지 정하고 결과를 검증하는 판단으로 옮겨 가고 있다는 것이다. 코드를 직접 쓰는 능력이 사라지는 게 아니라, 그 능력의 희소성이 빠르게 줄어드는 중이다. 네 사람이 공유한 전제는 단순하다. 도구는 계속 좋아질 것이고, 지금 해야 할 일은 그 도구의 경계가 어디까지인지 늘 가늠하는 것이다. 그리고 그 경계는 고정돼 있지 않다.