AI가 소프트웨어를 다 짜버리는 시대에, 우리는 무엇을 만들어야 살아남을 수 있을까 하는 질문은 이미 현실이 되었습니다. 이 글은 스티브 예기(Steve Yegge)의 「소프트웨어 서바이벌 3.0 – 무엇을 만들어야 살아남는가」를 바탕으로, 개발자·기획자·창업자 관점에서 핵심을 정리해봅니다.

AI가 바꿔버린 소프트웨어 생존 규칙

스티브 예기는 2023년 코드 자동완성, 2024년 대화형 인터페이스, 2025년 에이전트, 2026년 오케스트레이션이라는 흐름을 비교적 정확히 예측해 온 인물입니다. 그의 전제는 단순합니다. “AI 발전 곡선은 지수적이며, 그 위에서 소프트웨어의 운명을 다시 계산해야 한다”는 것입니다.

그가 말하는 핵심은 한 줄로 요약됩니다. AI가 대부분의 코드를 작성하는 시대에는 “AI가 처음부터 합성하는 것보다 토큰(추론 비용)을 확실히 절약해 주는 소프트웨어만이 진화론적 선택 압력 속에서 살아남는다”는 것입니다.

생존 비율 공식: 내 제품이 버틸 수 있을까?

예기는 소프트웨어의 생존 가능성을 하나의 비율로 설명합니다.

Survival(T) 비율은 대략 다음과 같은 요소들로 구성됩니다.

• Savings: 그 도구를 사용했을 때 AI가 처음부터 만들어 쓰는 것에 비해 절약되는 인지 비용(토큰 절감량)

• Usage: 얼마나 자주, 얼마나 다양한 상황에서 사용되는지(범용성과 반복 사용성)

• H(Human Coefficient): 인간이 개입했다는 사실에서 오는 가치, 취향, 사회적 증거, 창의성 등의 계수

• Awareness_cost: 사용자·에이전트가 이 도구의 존재와 사용 타이밍을 이해하는 데 드는 비용

• Friction_cost: 온보딩, 에러, 재시도, 인터페이스 오해 등 실제 사용 과정에서 생기는 마찰 비용

생존을 위해서는 이 비율이 최소 1을 넘어야 하지만, 경쟁이 붙으면 훨씬 높은 값을 요구받습니다. 즉 “간신히 쓸 만한 도구”는 곧 “조금 더 효율적인 경쟁자”에게 자리를 빼앗기게 된다는 뜻입니다.

레버 1: 통찰 압축 – 다시 만들기엔 너무 비싼 도구

첫 번째 생존 레버는 통찰 압축(Insight Compression)입니다.

오랜 시간 축적된 도메인 지식을 “다시 발견하기에는 너무 비쌀 정도로” 촘촘하게 압축해 둔 소프트웨어는 AI 시대에도 강력한 위상을 유지합니다. 대표적인 사례는 다음과 같습니다.

• Git: 커밋 DAG, 참조(ref), 인덱스, reflog 등 수십 년의 버전 관리 시행착오가 응축된 시스템

• 데이터베이스, 컴파일러, 운영체제, 워크플로우 엔진, 모니터링 시스템 같은 인프라 레이어

• Kubernetes: 복잡한 분산 시스템 특성을 받아들이고 설계한, 필연적 복잡성을 가진 오케스트레이션 시스템

• Temporal: 직접 구현하면 연구 프로젝트 급 난이도가 되는 내구성 워크플로우를 제공하는 실행 플랫폼

이런 도구들의 공통점은 “AI가 처음부터 다시 합성하는 것이 경제적으로 전혀 말이 안 되는 수준의 통찰 밀도”를 갖고 있다는 점입니다. 다시 말해, “이걸 새로 만들겠다는 시도 자체가 미친 짓처럼 느껴지게 만들면” 살아남을 확률이 높아진다는 것입니다.

레버 2: 기판 효율성 – GPU를 덜 쓰게 만드는 설계

두 번째 레버는 기판 효율성(Substrate Efficiency)입니다.

LLM의 추론은 GPU라는 매우 비싼 기판 위에서 돌아가며, 패턴 매칭과 룩업을 섞은 방식으로 계산을 수행합니다. 반면 전통적인 도구들, 예를 들어 grep은 CPU에 최적화된 간단한 구조로 텍스트 검색을 수행하면서 특정 작업에서는 GPU 기반 모델보다 여러 자릿수 이상 효율적입니다.

여기에 계산기, 파서, ImageMagick 같은 유틸리티, 다양한 Unix CLI 도구들이 포함됩니다. 이들은 “좋은 알고리즘 + 더 싼 기판(CPU나 인간)을 활용해 토큰과 에너지를 크게 절약하는 소프트웨어”입니다. AI 시대에 강한 제품은 결국 “정말로 GPU가 필요한 부분은 최소화하고, 나머지를 더 저렴한 기판으로 옮기는 설계”를 택하게 됩니다.

레버 3: 광범위한 유용성 – 어디서나 쓰이는 도구

세 번째 레버는 광범위한 유용성(Broad Utility)입니다.

Usage가 넓어질수록, 즉 여러 팀과 도메인에서 반복 사용될수록 Awareness 비용이 전체 사용자·에이전트 집단에 분산됩니다. 그 결과 개별 사용 시 필요한 토큰 절감량이 낮더라도 충분한 생존 가능성을 확보할 수 있습니다.

예기가 주목하는 도구들은 다음과 같습니다.

• Temporal: PostgreSQL처럼 범용적 워크플로우 모델을 노리는 플랫폼으로, 통찰 압축·기판 효율성·범용성을 모두 지향

• Dolt: Git 스타일 버전 관리가 가능한 데이터베이스로, 장기간의 투자 끝에 에이전트 기반 프로덕션·DevOps에서 킬러 앱을 찾은 사례

• 코드 검색 엔진: “LLM이 뿜어낸 방대한 코드베이스”를 다루기 위해 새롭게 중요해진 영역으로, 전통적인 grep으로는 감당하기 어려운 규모와 복잡도에 대응

특히 코드 검색 엔진은 “비자명한 문제를 다루고, 싼 기판을 활용하며, 거의 모든 개발 조직이 필요로 하는 범용 도구”라는 점에서 세 가지 레버를 동시에 충족하는 예로 소개됩니다.

레버 4: 홍보 – 이제는 에이전트까지 상대로 하는 SEO

네 번째 레버는 홍보(Publicity), 즉 인지도입니다.

아무리 인지 비용을 잘 줄여주는 도구도, 존재 자체를 모르면 사용될 수 없습니다. Dolt 역시 통찰 압축과 기판 효율성, 범용성을 갖추고도 한동안 큰 주목을 받지 못한 이유가 인지도 부족이었기 때문이라고 분석됩니다.

여기서 등장하는 개념이 ‘에이전트를 위한 SEO’입니다.

• 커뮤니티를 키워 도구 사용 사례와 문서가 자연스럽게 훈련 데이터에 포함되게 만들기

• 에이전트용 문서와 예제, 오용 사례까지 포함한 평가 세트를 제공해 사용 방법을 학습시키기

• 필요 시 모델 제공 기업과 직접 협력하거나 비용을 지불해 노출과 학습을 유도하는 전략

앞으로는 “사람이 검색하고 찾는 SEO + 에이전트가 학습하고 선택하는 SEO”를 동시에 고려해야 하는 시대가 오고 있다는 메시지입니다.

레버 5: 마찰 최소화 – Agent UX라는 새로운 설계 축

다섯 번째 레버는 마찰 최소화(Minimizing Friction)입니다.

인지도는 선택 이전의 문제라면, 마찰은 실제 사용 과정에서의 문제입니다. 에이전트는 제한된 컨텍스트와 시간 안에서 움직이기 때문에, 조금만 막히거나 에러가 나도 즉시 다른 경로로 우회하는 경향을 보입니다. 사람에게 익숙한 UX가 아니라, 에이전트가 빠르게 이해하고 신뢰할 수 있는 UX가 필요합니다.

예기가 제시하는 전략은 두 가지입니다.

• 문서 중심 전략: 도구의 역할, 강점, 사용 타이밍, 빠른 시작 가이드와 후속 문서를 컨텍스트에 직접 주입해 에이전트의 이해를 돕는 방식

• 에이전트 친화적 도구 설계: 에이전트가 이미 익숙한 다른 도구와 비슷하게 만들거나, 에이전트가 사고하는 방식 그대로 문제를 정의할 수 있도록 인터페이스를 설계하는 방식

흥미로운 예로 Beads라는 도구는 수개월 동안 에이전트의 사용 패턴을 관찰하며 100개가 넘는 하위 명령과 별칭, 대체 문법을 추가해 왔습니다. LLM이 자주 잘못 추측하거나 환각하는 문법을 실제 기능으로 편입함으로써 “에이전트가 추측하는 거의 모든 명령이 실제로 동작하는 CLI”를 만들어낸 것입니다.

여기에 더해, LLM이 자주 환각하는 도메인을 추적해 실제로 등록하고 아티팩트를 올려두면 에이전트가 해당 리소스를 그대로 다운로드하게 만드는 ‘환각 스쿼팅’ 기법도 언급됩니다. 국가 단위의 해커 조직까지 이런 Agent UX를 활용하고 있다는 점에서, 이 영역의 중요성이 드러납니다.

레버 6: 인간 계수 – AI 냄새에 피로해진 사람들

여섯 번째 레버는 인간 계수(Human Coefficient, H)입니다.

AI 효율성과 별개로, “인간이 개입했다는 사실” 자체가 중요한 가치를 가지는 분야가 계속 존재할 것이라는 주장입니다. 예를 들어 다음과 같은 사례를 들 수 있습니다.

• 인간이 직접 고른 플레이리스트와 AI가 추천한 최적 플레이리스트

• 실제 사람이 존재하는 게임 환경과 AI만 상대하는 게임 환경

• 에이전트가 활동하지 못하도록 설계된 소셜 네트워크의 매력

• 최고의 튜터가 AI가 된다 해도, 일부는 의도적으로 인간 교사를 선택하는 상황

Karpathy가 그리는 미래처럼, 에이전트는 “누구에게나, 무엇이든” 되어줄 수 있는 존재가 될 가능성이 높습니다. 그럼에도 이미 많은 사람들이 에이전트 냄새가 강한 콘텐츠와 상호작용에 피로감을 느끼기 시작했고, 인간의 시간과 주의, 취향이 스며든 경험에 더 높은 가치를 부여하고 있습니다.

그래서 무엇을 만들어야 하는가?

예기의 결론은, “인간과 AI 사이를 가볍게 중개하는 레이어”나 “곧 AI가 스스로 해버릴 일을 대신하는 똑똑해 보이는 소프트웨어”는 구조적으로 불리하다는 것입니다. 대신 여섯 가지 레버를 기준으로, 다음과 같은 방향성이 제안됩니다.

• 다시 만들기엔 미친 짓처럼 느껴질 정도로 통찰이 압축된 도구를 만들 것(Insight Compression)

• GPU가 할 일을 최소화하고, 더 싼 기판으로 옮겨 토큰을 절약하는 구조를 설계할 것(Substrate Efficiency)

• 다양한 팀과 도메인에서 반복 사용되는 범용 유틸리티를 지향할 것(Broad Utility)

• 인간과 에이전트 모두를 대상으로 하는 인지도 전략을 세울 것(Publicity)

• 에이전트가 좋아하는 UX, 즉 낮은 마찰을 갖춘 인터페이스와 프로토콜을 설계할 것(Minimizing Friction)

• 인간 개입이 핵심 가치가 되는 부분에서는, H를 최대화하는 경험을 설계할 것(Human Coefficient)

토큰 비용이 내려갈수록, 사람들의 야망은 더 먼 프런티어를 향하게 되고, 작성해야 할 소프트웨어의 총량은 사실상 무한에 가깝습니다. 중요한 것은 “내가 만들고 있는 것이 이 여섯 가지 레버 중 어디에 힘을 주고 있는지”를 명확히 의식하는 것입니다.

마지막으로 예기가 던지는 문장은 이 시대 제품 전략의 방향을 잘 요약합니다. “다시 만들려는 시도 자체가 미친 짓처럼 느껴지는 것을 구축하고, 발견하기 쉽고 사용하기 쉽게 만든다면 충분히 견고한 가능성을 확보할 수 있다”는 것입니다.