Software 3.0 시대, 어떤 소프트웨어가 살아남는가

핵심 요약

AI가 대부분의 코드를 쓰는 Software 3.0 시대에는 "얼마나 많은 인지(토큰)를 절약해 주는가"가 소프트웨어 생존의 핵심 기준이 된다.

저자는 이를 위해 여섯 가지 레버(레버리지: 통제할 수 있는 요소) — 통찰 압축, 더 싼 연산 기판, 폭넓은 유용성, 인지도, 낮은 마찰, 인간 계수 — 를 제시하며, 이 레버를 잘 활용한 소프트웨어만이 재합성(re-synthesis)을 피하고 살아남는다고 본다.

Software 3.0과 생존 문제

Software 3.0은 "AI가 대부분의 소프트웨어를 설계·구현·운영하는 시대"를 뜻한다.

이 시기에는 기업이 SaaS를 구매하기보다, AI를 이용해 필요한 도구를 직접 만들어 쓰는 것이 점점 더 싸지고 쉬워진다.
고객지원, 콘텐츠 생성, 생산성 도구, 저차원 코딩 도구 등 많은 카테고리가 이미 AI에 잠식되고 있으며, IDE도 예외가 아니다.

이 환경에서 모든 소프트웨어는 질문을 받는다. "AI가 즉석에서 비슷한 것을 합성하는 대신, 너를 계속 써야 할 이유가 있는가?"

이 질문에 대한 체계적인 답이 바로 '생존 비율(Survival Ratio)' 모델이다.

생존 비율(Survival Ratio) 모델

저자는 소프트웨어의 생존 가능성을 다음과 같은 비율로 설명한다.

Survival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)

여기서 중심 개념은 "토큰 = 에너지 = 돈"이다. LLM 추론에는 토큰이 필요하고, 토큰은 전기와 비용으로 직결되므로, 토큰 절약은 곧 비용·에너지 절약이다.

생존 비율이 1을 넘으면 "알고 쓰는 편이, 매번 새로 합성하는 것보다 싸다"가 되고, 1 밑이면 "차라리 AI가 그때그때 만들어 쓰는 게 낫다"가 된다. 경쟁이 심한 영역일수록 단순히 1을 넘는 것만으로는 부족하고, 더 높은 비율이 필요해진다.

이 비율을 구성하는 항목들은 다음 여섯 레버로 설명된다.

레버 1: 통찰 압축(Insight Compression)

통찰 압축은 "오랜 시행착오와 집단 지성이 응축된 설계/구조를 재사용하게 해주는 것"이다.

Git이 대표적인 예다. Git은 분산 버전 관리, 브랜치, 머지, 되돌리기, 협업 패턴 등에 대한 수십 년의 통찰을 DAG, ref, index 같은 개념으로 응축해 놓았다.
AI가 버전 관리 시스템을 새로 만들 수는 있지만, Git이 쌓아 온 역사 전체를 다시 탐색하는 것은 엄청난 토큰 낭비다. 경제적으로도 비합리적이다.

데이터베이스, 컴파일러, 운영체제, 워크플로 엔진(예: Temporal), 분산 시스템 프레임워크도 비슷하다. 이런 시스템은 "문제의 난이도 × 통찰 밀도"가 높아, 재합성보다 재사용이 훨씬 싸다.

또한 통찰 압축은 꼭 거대한 인프라가 아니어도 된다. 좋은 추상화, 잘 설계된 도메인 모델, 기억하기 쉬운 개념과 명령(예: Gas Town의 캐릭터 역할과 명령어)도 AI에게는 "생각을 덜 하게 해주는 압축된 지식"으로 작동한다.

레버 2: 더 싼 연산 기판(Substrate Efficiency)

두 번째 레버는 "같은 일을 더 싼 연산 기판에서 처리하게 해 주는 것"이다.

LLM은 곱셈·파싱·검색 같은 일을 할 수 있지만, 이 모든 것을 GPU 위의 거대한 행렬 연산으로 처리한다. 이는 말 그대로 "닭만 가지고 긴 곱셈하는 사람"에 가깝다. 동작은 하지만 효율이 끔찍하다.

grep은 "누구도 대체하려 하지 않을 도구"의 고전적 예다.
정규식 기반 텍스트 검색이라는 일을 CPU에서, 효율적인 알고리즘으로, 거의 0에 가까운 비용으로 처리하니, 이 일을 위해 GPU 추론을 돌리는 건 미친 짓이 된다.

계산기, 파서, 이미지 변환 도구(ImageMagick류), 각종 Unix CLI 도구처럼 "CPU + 좋은 알고리즘"으로 싸고 빠르게 해결할 수 있는 일을 담당해 주면, AI는 비싼 토큰을 쓰지 않고 그 도구를 호출하기만 하면 된다.

요지는 간단하다.
"LLM이 직접 생각하는 것보다, 너를 호출하는 편이 토큰/에너지 측면에서 언제나 싸게 만들어라."
이 조건이 만족되면, 재합성할 유인이 거의 없어진다.

레버 3: 폭넓은 유용성(Broad Utility)

Usage 항은 "얼마나 많은 상황에서, 얼마나 자주 쓸 수 있는가"를 나타낸다.

같은 양의 통찰 압축, 같은 기판 효율성을 가진 도구라도 쓰임새가 넓으면 인지도 비용을 여러 곳에 나눠 상쇄할 수 있다.
Git과 grep이 생존력이 강한 이유 중 하나는 너무 다양한 맥락에서 반복적으로 쓰인다는 점이다.

Temporal은 비교적 신생 도구지만, "지속성 있는 워크플로 실행"이라는 매우 일반적인 문제를 풀어준다.
에이전트 기반 시스템이 보편화될수록, 복잡한 사가(saga) 패턴, 재시도, 보상 트랜잭션 처리가 필요한 워크플로는 폭발적으로 늘어난다. Temporal은 여기서 ① 난이도 높은 문제(분산 워크플로)를 ② 효율적인 기판 위에서 ③ 다양한 도메인에 공통으로 적용 가능한 방식으로 풀어 통찰 압축과 폭넓은 유용성을 동시에 가진다.

Dolt(버전 관리 가능한 DB) 역시 에이전트가 실수하더라도 Git처럼 되돌릴 수 있게 해주어, "에이전트가 프로덕션 DB를 건드려도 되는 세계"라는 새로운 넓은 용도를 연다.

또 하나의 예는 "대규모 코드 검색"이다.
LLM들이 코드를 10~100배 더 많이 생성하면, 코드베이스가 커지고 복잡해져 grep만으로는 검색이 버거워진다. 여기서 코드 검색 엔진은 ① 어려운 문제(정확한 검색·순위·리팩터링 인식)를 ② GPU보다 훨씬 싼 기판에서 ③ 거의 모든 코드베이스에 적용 가능한 일반 도구로 제공해 생존성이 올라간다.

결론적으로, "많은 에이전트가 많은 상황에서 반복적으로 쓸 수 있게 설계된 도구"는 인지 비용을 쉽게 상쇄하며, 생존 비율을 크게 끌어올린다.

레버 4: 인지도(공개·홍보, Awareness)

좋은 도구라도, 에이전트가 "존재 자체를 모르면" 쓸 수 없다. Awareness_cost는 이 문제를 정량화한 것이다.

인지 비용은 크게 두 가지로 발생한다.
하나는 사전 학습 단계에서, 모델이 당신의 도구를 "이미 알고 있게" 만드는 비용이고, 다른 하나는 추론 시점에 프롬프트·문서를 통해 도구를 가르치는 비용이다.

첫 번째는 전통적인 의미의 "브랜드·커뮤니티·콘텐츠"를 키워 인터넷에 흔적을 남기는 방식으로도 해결되지만, 점점 더 직접적인 루트가 생기고 있다.

예를 들어, OpenAI·Anthropic·Google 등과 직접 협업하여, 도구 사용법과 평가 셋(eval)을 제공하고, 모델이 당신의 도구를 잘 쓰도록 파인튜닝하거나 툴링 통합을 돕는 서비스가 등장하고 있다.
이는 말 그대로 "에이전트용 SEO"에 가까우며, 충분한 예산이 있다면 Awareness_cost를 한 번에 크게 낮출 수 있는 방법이다.

둘째 방법은 그럴 여력이 없을 때 쓰는 "런타임 교육" 전략이다.
프롬프트에 "이 도구는 이런 상황에서 유용하다, 이렇게 호출하면 된다"와 같은 정보를 꾸준히 넣어 주는 방식이다. 이것은 Awareness_cost를 inference 단계로 미루는 것이며, 그만큼 토큰 비용을 직접 떠안는 셈이다.

요약하면, 인지도는 "에이전트가 너를 떠올릴 확률"이며, 이 확률을 높이는 전략을 제품 설계와 별개의 축으로 따로 고민해야 한다.

레버 5: 낮은 마찰과 에이전트 UX(Friction 최소화)

Friction_cost는 "도구를 실제로 사용할 때 생기는 모든 귀찮음"이다.

에이전트는 항상 급한 사람처럼 행동한다.
API가 조금만 애매하거나, 에러가 자주 나거나, 매번 세세한 설정을 요구하면, "이 도구를 고집하는 것보다 그냥 다른 방식(또는 재합성)을 택하는 것이 더 싸겠다"는 쪽으로 판단을 바꾼다.

여기서 중요한 개념이 "에이전트 UX"와 "욕망의 길(Desire Paths)"이다.
Beads의 CLI가 좋은 예인데, 이 도구는 인간을 위해서가 아니라 에이전트를 위해 설계되었다.
에이전트가 자주 '헛갈려서' 시도해보는 명령, 옵션, 형식들을 계속 관찰한 뒤, 그 헛된 시도를 실제로 동작하는 기능으로 구현해 나가면, 어느 순간부터 에이전트가 "지레 짐작으로" 시도한 거의 모든 호출이 성공하게 된다.

이것은 일종의 "환각 스쿼팅(hallucination squatting)"과도 닮았다.
모델이 잘못 상상하는 도메인·엔드포인트·명령어를 실제로 점유해 버리면, 에이전트의 입장에서는 "아무 생각 없이 쳤는데도 잘 작동하는 직관적인 도구"가 된다.

따라서 문서만 잘 쓰는 것은 충분 조건이 아니다.
이상적인 상태는, 에이전트가 다른 도구 경험을 바탕으로 예상하는 방식 그대로가 실제 사용법과 거의 일치하는 것이다.
이때 문서는 "자신이 기대한 대로 작동함을 확인하는 참고 자료" 정도의 역할만 하면 된다.

정리하자면, Friction을 줄이는 방법은 다음과 같다.
에이전트가 자연스럽게 예상할 법한 인터페이스·명령 패턴을 채택하고, 그들의 잘못된 시도까지 포용해 성공 사례로 바꿔 주는 것.
이렇게 하면 도구 사용 시 발생하는 재시도·실패·학습 비용이 줄어들어, 생존 비율의 분모가 작아진다.

레버 6: 인간 계수(Human Coefficient, H)

H는 효율성만으로 설명할 수 없는 "인간성 프리미엄"을 의미한다.

어떤 도구나 서비스는, 인지 비용·토큰 비용 측면에서 비합리적이어도 "인간이 개입했다"는 사실 때문에 선택된다.
인간이 선별한 플레이리스트, 인간이 진행하는 수업, 실제 사람이 참여하는 게임·커뮤니티는, 에이전트가 동일하거나 심지어 더 나은 품질을 제공할 수 있어도 여전히 선호될 수 있다.

H가 높은 소프트웨어는 "비효율적이지만, 사람들은 그걸 원한다"는 이유로 살아남는다.
이는 특히 소셜, 교육, 예술, 라이브 이벤트, 창작·후기·평가가 중심이 되는 서비스에서 더 중요해진다.

다만 H만 믿고 나머지 레버를 버리는 것은 위험하다.
AI가 무한대에 가까운 개인화·맞춤형 경험을 제공하는 세계에서, 인간성만으로 버티려면 상당히 강력한 브랜드·커뮤니티·문화가 필요하다.
그래서 가장 현실적인 전략은 "효율성 레버(1~5)를 잘 당기되, 동시에 인간이 개입하는 지점을 의도적으로 마련해 H를 끌어올리는 것"이다.

여섯 레버를 활용한 생존 전략 정리

Software 3.0 시대에 소프트웨어를 설계·운영하는 사람에게 여섯 레버는 매우 실용적인 체크리스트가 된다.

먼저, "우리 도구는 AI가 직접 생각하는 것보다 토큰을 확실히 절약해 주는가?"를 묻는다.
그렇다면 그 이유가 통찰 압축(레버 1)인지, 더 싼 연산 기판(레버 2)인지, 아니면 둘 다인지 점검한다.
이어 "이 도구가 쓸 수 있는 상황이 얼마나 넓은가?"를 따져, 가능한 한 범용적인 형태로 추상화할 수 있는지 고민한다(레버 3).

그 다음은 "에이전트가 우리를 알 수 있게 만드는 전략"이다.
모델 제공자와의 직접적인 통합, 문서·예제·튜토리얼의 대량 생산, 생태계·커뮤니티 구축 등으로 Awareness_cost를 줄여야 한다(레버 4).

그리고 실제 사용 시의 마찰을 없애는 "에이전트 UX"에 투자한다.
에이전트의 잘못된 추측까지도 포용하는 인터페이스, 일관된 API 설계, 오류 메시지와 피드백 설계, 최소한의 설정으로 바로 쓸 수 있는 기본값 등으로 Friction_cost를 공격적으로 낮춘다(레버 5).

마지막으로, 이 모든 것과 별개로 "인간이 굳이 사람을 찾을 만한 요소"를 의식적으로 설계한다.
사람이 큐레이션하거나, 리뷰를 남기거나, 직접 개입하는 지점을 만들어 H를 올리면, 순수 효율성 경쟁에서 벗어날 방어막을 하나 더 갖게 된다(레버 6).

인사이트

Software 3.0 시대의 핵심 기준은 "기능이 있느냐 없느냐"가 아니라 "AI가 재합성하지 않고 굳이 이 소프트웨어를 써야 할 만큼, 토큰과 주의를 절약해 주는가"이다.

따라서 앞으로 소프트웨어를 만들 때는 다음 세 가지 질문을 계속 던지는 것이 좋다.
첫째, "이걸 처음부터 다시 만드는 건 말이 안 될 정도로 통찰과 효율이 응축되어 있는가?"
둘째, "에이전트 입장에서, 나를 찾고 이해하고 쓰는 게 얼마나 자연스럽고 싸게 느껴지는가?"
셋째, "인간은 이 소프트웨어에서 어떤 '인간적인 가치'를 느끼는가?"

이 세 질문에 "그렇다"고 답할 수 있는 제품을 만든다면, AI가 코드를 도배하는 Software 3.0 이후에도 충분히 살아남을 가능성이 크다.
요약하면, "다시 만들기엔 미친 짓인 수준으로 잘 만들고, 에이전트와 인간이 모두 쓰기 쉽게 만들어라." 이게 저자가 말하는 생존 전략의 핵심이다.

출처 및 참고 : Software Survival 3.0. I spent a lot of time writing software… | by Steve Yegge | Jan, 2026 | Medium