AI를 실제로 일하는 소프트웨어로 바꾸는 Jev

URL: https://www.youtube.com/watch?v=Ut3LOjKNJaE 날짜: 2026-09-29 채널: a16z 원제: How Jev Turns AI Into Software That Gets Things Done 재생시간: 42분 24초 출연: Ben Horowitz, Martin Casado, Diogo Almeida 조직: TypeSafe

---

📌 핵심 질문 / 이 대화가 다루는 핵심 논점

==AI가 이미 놀라운 지능을 보여주는데도 왜 현실의 단순하고 반복적인 업무를 안정적으로 자동화하지 못하는가?==

Jev는 코딩 에이전트처럼 기존 소프트웨어를 더 빨리 작성하는 도구가 아니라, 자연어로 표현한 의도와 프로그램의 상태(state)를 결합해 신뢰도와 함께 결정을 반환하는 새로운 소프트웨어 프리미티브(primitive)를 지향한다. 목표는 챗봇을 애플리케이션 옆에 붙이는 데서 멈추지 않고, 소프트웨어 내부에 지능을 심어 기존 코드가 표현하지 못했던 자동화를 가능하게 만드는 것이다.

• Claude Code, Codex, Cursor는 사람이 작성하던 코드와 같은 종류의 코드를 더 빠르게 만든다.
• Jev는 자연어 질문, 애플리케이션 상태, 상태 머신(state machine)을 결합해 코드 안에서 지능적인 분기와 결정을 담당한다.
• 핵심 성능 기준은 모델의 벤치마크 점수나 동일한 출력이 아니라, 매번 지능적인 결과를 내놓아 개발자가 실제 코드에 안전하게 반영할 수 있는 신뢰성이다.
• 장기적으로 SaaS, 로그·이메일 분석, UI, 인간-컴퓨터 상호작용, 스마트 데이터베이스, 확률적 프로그래밍의 구조 자체가 바뀔 수 있다.

---

1. “대체 자동화는 어디에 있는가?”라는 출발점

AI의 지능과 현실 소프트웨어의 자동화 사이에는 커다란 간극이 있다. Diogo Almeida가 Jev를 설명할 때 가장 좋아하는 한 문장은 “대체 자동화는 어디에 있는가?”다.

1.1. 똑똑하지만 일하지 못하는 AI

1. AI의 현재 성과와 한계

   1. 압도적인 지능: AI는 매우 어려운 질문에 답하고 대화를 자연스럽게 이어가지만, 챗봇과 코딩 에이전트 바깥의 일은 여전히 거의 자동화하지 못한다.
   2. 현실의 역설: OpenAI가 2020년부터 고객 지원 자동화를 시도했는데도, 기업 현장에서 기본적인 업무가 광범위하게 자동화되지 않았다.
   3. 소프트웨어의 정체: AI 기반 코딩 에이전트를 몇 개 더 사용해도 소프트웨어 자체의 능력이 좋아지는 것은 아니다. 기존 소프트웨어를 더 빠르게 만들 뿐이며, 감독이 줄어들면 오히려 안전성이 떨어질 수도 있다.

2. TypeSafe와 Jev의 목표

   1. AI for software: TypeSafe는 사람을 위한 AI뿐 아니라 실제 소프트웨어를 만드는 AI를 개발한다.
   2. 첫 모델의 역할: Jev는 이 방향에서 자동화를 크게 개선할 첫 모델이다.
   3. 다이아몬드 원석: 현재 AI는 엄청난 지능을 가진 다이아몬드 원석이지만, 아직 일(work)에 투입할 만큼 준비되지 않았다.
   4. 자동화의 북극성: 특정 데모나 한두 개의 사용 사례가 아니라, 사람이 확인하지 않아도 백그라운드에서 계속 실행되고 그 위에 새로운 소프트웨어를 쌓을 수 있는 자동화를 지향한다.

1.2. “제품을 만들지 신을 만들지는 않는다”

1. TypeSafe의 태도

   1. 슬로건: “우리는 신(god)이 아니라 제품(product)을 만든다(We build a product, not a god).”
   2. 긍정적 미래관: Diogo Almeida는 AI가 일자리를 줄이는 대신 더 많은, 더 나은 일자리를 만들 수 있다고 믿는다.
   3. 종말론과 거리 두기: 현재의 AI가 곧 자기 개선형 초지능으로 이어진다고 보지 않으며, 현실에서 아직 자동화하지 못한 단순한 일들을 먼저 해결해야 한다고 본다.
   4. 개발자 관점의 차이: AI를 하나의 거대한 단일 두뇌로 보는 관점보다, 소프트웨어 안에 여러 종류의 작고 유용한 지능을 심는 관점을 택한다.

2. 불일치가 만드는 답답함

   1. 경제적 유인: 자동화하면 비용과 시간이 줄어들기 때문에, 현실에는 자동화를 추진할 재정적 유인이 충분하다.
   2. 현실과 기대의 간극: AI가 이토록 영리한데도 사람이 해서는 안 될 기본 작업을 계속 직접 해야 하는 상황이 Diogo에게 가장 고통스럽다.
   3. 두 종류의 AI 분위기: Jev를 사용하는 사람들은 가능성을 즐기는 “행복한 AI” 쪽에 있고, 그렇지 않은 사람들은 AI의 비관적 미래만 그리는 “우울한 AI” 쪽에 있다는 농담이 나온다.

---

2. 코딩 에이전트와 Jev의 차이

핵심 차이는 소프트웨어 개발을 자동화하는가, 아니면 소프트웨어가 할 수 있는 일 자체를 확장하는가에 있다.

2.1. “just-in-time software”와 “smart software”

1. 코딩 에이전트가 제공하는 것

   1. 자연어 프로그래밍: Claude Code, Codex, Cursor 같은 도구는 자연어로 지시하면 프로그램을 즉석에서 만들어 준다.
   2. 기존 표현력의 유지: Garry Tanenbaum이 말한 “just-in-time software”처럼 필요할 때 소프트웨어를 만들지만, 그 소프트웨어가 가진 표현력은 일반 코드와 본질적으로 같다.
   3. 인간 코드의 가속: 생성된 코드는 사람이 10년 전 작성했을 법한 코드와 같은 종류다. 더 좋거나 나쁠 수는 있어도, 새로운 종류의 코드가 되는 것은 아니다.

2. Jev가 제공하려는 것

   1. smart software: 소프트웨어 개발 속도가 아니라 소프트웨어의 능력을 확장한다.
   2. 의도 표현: 사람이 원하는 결과를 자연어로 설명하고, 기존 코드가 표현하기 어려운 의도(intent)를 프로그램 안에 넣는다.
   3. 새로운 프리미티브: 인간 개발자든 코딩 에이전트든, 코드에 추가해 소프트웨어의 능력을 확장하는 구성요소를 얻는다.
   4. 프로그래밍의 목적: 프로그래밍은 가치 있는 것을 극도로 구체화하고 반복 재생산하는 일이다. Jev는 그 구체화할 수 있는 가치의 범위를 넓힌다.

2.2. Jev의 기본 구조

1. 자연어와 상태 머신의 결합

   1. 입력: 애플리케이션의 상태(state)와 자연어로 쓴 질문 또는 원하는 동작을 제공한다.
   2. 판단: Jev가 선택 가능한 동작이나 상태 전이 중 무엇을 할지 판단한다.
   3. 출력: 결정과 함께 일정 수준의 확신(confidence)을 반환한다.
   4. 내부 위치: 대화창의 최상위 인터페이스가 아니라 프로그램 내부에 들어가는 라이브러리 또는 프리미티브다.

2. 분류기라는 단순한 설명의 가치

   1. “Jev는 분류기다”: Diogo는 이 설명을 부정하지 않는다. 분류기는 애초에 유용하도록 만들어진 도구이기 때문이다.
   2. 자연어 처리의 계보: 실무자가 시스템을 작동시키기 위해 만든 자연어 처리 인터페이스와 같은 계보에 있다.
   3. 2019년 ML 팀과의 비교: 2019년에 좁은 업무를 자동화하려면 머신러닝 팀이 데이터를 수집하고, 모델을 훈련하고, 평가 체계를 만들고, 전용 인프라를 구축해야 했다. Jev는 필요한 질문을 즉석에서 프로그래밍할 수 있어 그런 팀보다 이미 나은 결과를 낼 가능성이 있다.
   4. 출발점: 이는 끝난 기술이 아니라 이제 시작된 영역이며, 앞으로 어떤 좁은 업무가 만들어질지는 아직 알 수 없다.

2.3. 자연어 출력과 명령형 프로그램 사이의 슬라이더

1. 설계 공간

   1. 한쪽 끝: 자연어를 입력하고 자연어를 출력하는 현재의 언어 모델이 있다.
   2. 다른 쪽 끝: 전통적인 명령형(imperative) 프로그램이 있다.
   3. 중간 지점: 자연어를 입력하되 기계가 다루는 상태(machine state)를 출력하는 Jev의 방식이 있다.
   4. 슬라이더라는 관점: Diogo는 이것이 고정된 하나의 점이라기보다 양극단 사이를 움직이는 슬라이더에 가깝다고 본다.

2. 비용과 속도의 설계 기준

   1. 지능/달러(intelligence per dollar): 현재 주된 최적화 기준은 지능을 달러당 얼마나 제공하느냐이다.
   2. 지능/초(intelligence per second): 단기적으로는 지능을 초당 얼마나 빨리 제공하느냐가 더 중요할 수도 있으며, 현재 기준이 틀릴 가능성도 인정한다.
   3. 상태라는 인터페이스: Jev가 입력을 “state”라고 부르는 것은 우연이 아니다. 코드 패치처럼 프로그램의 내부 상태에 자연스럽게 들어가도록 의도한 설계다.
   4. 복잡한 내부 상태: 핵심 연구 과제는 프로그램 안의 더 복잡한 내부 상태 구조에 지능을 추가할 수 있는지다.

3. 데이터베이스에서 표준 라이브러리로

   1. 초기 형태: 밀리초 단위로 작동하는 AI를 만드는 일이 쉬우므로, Jev는 한동안 표준 라이브러리보다는 데이터베이스에 가까운 형태가 될 수 있다.
   2. 장기 목표: 궁극적으로는 일반적인 표준 라이브러리처럼 프로그램 어디에서나 호출되는 구성요소가 되기를 원한다.
   3. 설계의 긴장: 어떤 기능을 자연어로 남기고 어떤 기능을 전통 코드로 확정할지는 지속적인 설계 문제다.

---

3. Diogo Almeida의 경로와 TypeSafe의 세계관

AI 연구자, 시스템 엔지니어, 컴퓨터 과학자의 관점이 한 사람 안에서 만난 경로가 Jev의 설계에 영향을 주었다.

3.1. 수학 경시에서 컴퓨터 과학으로

1. 수학 경시 경험

   1. Mathlete: Diogo는 수학 경시 참가자였고 수학을 꽤 잘했다.
   2. 자기희화화: 수학 실력이 여자아이들의 관심을 끌 정도였다는 농담을 했다가, 젊은 사람들에게는 그렇게 살지 말고 차분하고 흥미로운 사람이 되라는 조언으로 수습한다.
   3. 수학에 대한 양가감정: 수학 자체를 좋아했다기보다 작은 연못의 큰 물고기였고, 경쟁에서 이기는 일이 중심인 수학에는 흥미를 잃었다.

2. 컴퓨터 과학의 매력

   1. “멋지고 유용한 수학”: 컴퓨터 과학은 수학과 비슷하지만 더 멋지고 유용하며 재미있다고 본다.
   2. 알고리즘 인터뷰: 지금도 알고리즘 면접을 진행하는 일을 좋아한다.
   3. 판단 능력: 무엇을 잘하는지는 모르지만 좋아하는 일이고, 사람을 잘 평가하는 데 도움이 된다고 말한다.
   4. 정체성: AI 연구자라는 배경보다 컴퓨터 과학자라는 정체성을 더 강하게 느낀다.

3.2. Kaggle과 시스템적 사고

1. Kaggle 대회

   1. 우승 방식: 복잡한 수학을 사용하기보다 점점 더 많은 중첩 루프(nested loops)로 모든 것을 자동화해 우승했다.
   2. 핵심 교훈: 성과의 중심은 이론적 수식이 아니라 시스템을 구성하고 자동화하는 방식이었다.
   3. NeurIPS 발표: 우승 때문에 NeurIPS에서 발표해야 했지만 연구 커뮤니티의 주목보다 실제 문제의 한가운데 있는 일을 더 좋아해 그 경험을 달가워하지 않았다.

2. AI 업계로 들어간 계기

   1. Isabelle Guillon: Kaggle 발표자는 SVM 공동 저자인 Isabelle Guillon이었다. Diogo는 그녀가 SVM 논문의 제1저자였는지는 확실하지 않다고 덧붙였다.
   2. 멘토링: Guillon은 Diogo가 기존 연구 커뮤니티에 잘 맞지 않는다는 점을 알아보고 그를 여러 AI 전문가에게 소개했다.
   3. 경력 이동: Jeremy Howard와 함께한 스타트업, Google Brain을 거쳐 OpenAI로 이동했다.
   4. AI의 즐거움: 아무것도 하지 않는 느낌에 지쳐 “AI는 정말 재미있다”고 생각했고, 그 이유로 OpenAI에 합류했다.

3.3. 거대한 단일 모델에 대한 거리 두기

1. 개발자가 보지 못하는 변화

   1. 분류기 논쟁: 개발자가 아니면 분류기 수준의 변화가 왜 중요한지 이해하기 어렵고, AI 업계가 즐기는 큰 변화의 속을 보기 힘들다.
   2. 단일 모델 숭배: 모든 것을 하나의 거대한 모델이 해결해야 한다는 믿음이 AI에 대한 어두운 전망을 만든다.
   3. 모듈화: 지능을 하나의 단일 두뇌로 묶기보다 목적별 모듈과 프리미티브로 소프트웨어에 배치하는 편이 현실적이다.

2. “신이 아니라 제품”이라는 태도

   1. 비관론의 원인: 하나의 거대한 두뇌가 세상을 지배한다는 서사가 실제 개발 현장의 상황을 과장한다.
   2. 현재의 증거: 인류는 아직 비밀번호 재설정 같은 기본 업무조차 완전히 자동화하지 못했다.
   3. 긍정적 방향: 거대한 선언보다 실제로 책임질 수 있는 작은 자동화를 하나씩 소프트웨어에 넣는 것이 TypeSafe의 방향이다.

---

4. 왜 높은 지능이 자동화로 이어지지 않았는가

AI의 벤치마크 성적과 생산적 업무의 자동화 사이에는 측정 목표와 데이터의 차이가 있다.

4.1. 2021년의 놀라운 일반화와 무너진 기대

1. RLHF의 일반화

   1. 시점: ChatGPT가 나오기 직전, 2021년 4분기 무렵 Diogo는 인간 피드백 기반 강화학습(Reinforcement Learning from Human Feedback, RLHF)의 일반화 능력에 크게 놀랐다.
   2. 검증 태도: 팀은 자신들이 맞다는 것을 증명하려 하지 않고 과학적 방식으로 결과를 반증하려 했다.
   3. 양말과 명상 질문: 인터넷에 이미 존재하지 않는 “명상 전에 양말을 먹는 것이 왜 중요한가?”라는 질문을 던졌는데, 모델이 그럴듯하고 인간적인 답을 만들었다.
   4. 결론: 이 현상이 사기가 아니라는 확신을 얻었고, 머신러닝에서는 언제나 사기 가능성을 경계해야 한다는 태도를 유지했다.

2. AGI 기대의 붕괴

   1. 초기 기대: Diogo는 RLHF 모델이 SHGI에 가까워질 가능성이 있다고 진지하게 생각했다.
   2. 좌절: 실제 공개 이후 그런 일이 일어나지 않자 세계관이 무너지는 경험을 했다.
   3. RLHF와 RLVR의 차이: 인간 피드백 기반 강화학습은 꽤 잘 일반화했지만, 검증 가능한 보상 기반 강화학습(Reinforcement Learning from Verifiable Rewards, RLVR)은 자신이 관찰한 범위에서 그렇게 잘 일반화하지 않았다.
   4. AGI 정의의 모호함: OpenAI에서 AGI를 논의할 때 정의를 넓고 의도적으로 모호하게 두어 여러 사람이 안에 들어오게 했지만, Diogo는 현재 모델이 곧 자기 개선형 AI로 향한다고 보지 않는다.

4.2. 인간 평가에 최적화된 모델

1. 잘 답하는 것과 일을 끝내는 것

   1. 현재 모델의 능력: 경제적으로 가치 있는 노동 대부분을 자동화하는 데 필요한 지능은 이미 모델 안에 상당 부분 들어 있다고 본다.
   2. 업무의 성격: 세계의 일은 매우 다양해 보여도 양적으로는 누구나 따를 수 있는 단순한 지시로 표현되는 반복 업무가 많다.
   3. 산업의 실패: RLHF 이후 업계는 거대한 약속과 약한 결과 사이로 갈라졌다.
   4. GPT-3의 균형: GPT-3는 당시 기준에서 능력과 기대의 균형이 비교적 좋았다고 평가한다.

2. 평가 함수의 문제

   1. 인간이 심사자: 인간이 모델 출력을 평가하면 모델은 인간 심사자의 선호에 맞춰 최적화된다.
   2. 자동화는 뒷전: 사람이 보기에 그럴듯하고 정확한 답을 만드는 능력은 좋아졌지만, 실제 업무를 안정적으로 끝내는 능력은 충분히 최적화되지 않았다.
   3. 핵심 질문: “이것이 왜 더 유용하지 않은가?”라는 의문이 Jev를 향한 방향 전환의 출발점이 됐다.

4.3. GPQA와 자율주행 차량 호출의 역설

1. 벤치마크와 현실의 불일치

   1. GPQA: Google조차 답을 모른다고 설명되는 어려운 질문을 2년 전부터 해결했다는 주장을 하면서, 자율주행 차량을 주문하는 단순한 업무는 여전히 제대로 처리하지 못한다.
   2. 현실의 경고등: “멋진 공상과학”처럼 들리는 주장과 일상 업무의 실패가 동시에 존재하는 것은 첫 번째 경고 신호다.
   3. 측정 기준: 모델이 얼마나 어려운 문제를 풀었는지보다 실제 생산적 작업을 얼마나 자동화했는지를 측정해야 한다.

2. 데이터 부족 가설에 대한 반론

   1. Martin의 질문: 디지털 세계와 현실 세계는 분포가 다르고, 현실에는 긴 꼬리(long tail)와 많은 이상치가 있으며, 충분한 데이터가 없어 생산 업무를 자동화하지 못하는 것 아니냐고 묻는다.
   2. Diogo의 답: 긴 꼬리가 존재한다는 사실은 인정하지만, 자동화의 첫 단계에서 그 긴 꼬리 전체를 처리할 필요는 없다고 본다.
   3. 실용주의: 신뢰할 수 있는 소프트웨어를 만드는 일에는 항상 투자비가 들므로, 자동화는 투자수익률(ROI)을 기준으로 선택해야 한다.
   4. 프로그래머의 미덕: 5분 걸리는 일을 다시 하지 않으려고 10시간을 들여 한 번 자동화하는 “게으름”이 프로그래머의 미덕으로 언급된다. 나머지 두 미덕은 대화 중 정확히 떠올리지 못하는 농담으로 남는다.

4.4. 지원 업무의 95%라는 착시

1. 총량과 고유성의 차이

   1. 기업의 주장: 한 회사가 전체 지원 문의의 95%에 답한다고 말했다.
   2. 실제 구성: 데이터를 자세히 보니 대부분 비밀번호 재설정처럼 반복적인 요청이었다.
   3. 고유성 기준: 문의의 고유성으로 계산하면 자동화 비율은 약 50% 수준으로 낮아졌다.
   4. 긴 꼬리: 사람과 자연 시스템을 상대하면 예외가 긴 꼬리를 이루므로, 단순한 총량 비율만으로 자동화 난도를 판단할 수 없다.

2. 작은 자동화부터 시작하는 이유

   1. ROI의 현실성: 모든 예외를 해결하려 하기보다 높은 빈도와 명확한 가치가 있는 업무를 먼저 자동화해야 한다.
   2. Jevons paradox: 자동화가 가능해지면 기존 일을 없애는 데서 끝나지 않고 새로운 종류의 일이 생길 수 있다.
   3. 기준점의 역할: 완전한 현실 자동화가 아니더라도, AI가 “할 수 있어야 한다”고 보이는 일부터 실제로 자동화하는지 확인하는 벤치마크가 필요하다.

---

5. 신뢰성은 가동 시간이 아니라 “매번 지능적인 결과”다

Jev의 경제적 가치는 원시 지능이나 공개 벤치마크보다, 프로그램 안에서 반복해서 사용할 수 있는 신뢰성에 달려 있다.

5.1. 신뢰성의 세 가지 층위

1. 서로 다른 개념

   1. 가동 시간(uptime/SLA): 서비스를 호출할 수 있는가를 나타내는 운영 지표다.
   2. 결정성(determinism): 같은 입력에 같은 결과를 반환하는 성질이며, 단위 테스트에는 유용하지만 현실 시스템 전체의 목표는 아니다.
   3. Jev의 신뢰성: 출력이 글자 그대로 같지 않더라도 매번 지능적인 결과가 나와야 한다.

2. UUID 예시

   1. 기능적으로 같은 질의: 질의에 UUID를 하나 추가해도 본질적으로 같은 질문이라면 같은 수준의 판단을 해야 한다.
   2. 완전한 결정성은 아님: 결과가 바이트 단위로 똑같을 필요는 없지만, 쓸모없는 변화에 의해 지능이 흔들려서는 안 된다.
   3. 코드에 반영 가능한 판단: 결과가 사람에게 이해 가능한 방식으로 지능적이면 개발자가 그 판단을 코드의 다음 단계에 사용할 수 있다.

5.2. “같은 지능”과 개발자의 몰입

1. 신뢰성의 정의

   1. 같은 지능(same intelligence every time): Diogo가 제시한 가장 간결한 정의다.
   2. 예시 질의의 필요성 제거: 매번 샘플 질의를 만들어 모델이 어떻게 반응하는지 확인하지 않아도 프로그램을 작성할 수 있어야 한다.
   3. 흐름(flow): 개발자가 Jev를 믿고 계속 설계하며, 끊김 없이 훌륭한 소프트웨어를 만드는 상태가 궁극적 목표다.

2. 신뢰성의 경제적 효과

   1. 1%의 가치: 신뢰성이 1% 높아질 때마다 시장 규모와 별개로 새로운 사용 사례가 열릴 수 있다.
   2. 업무에 넣는 전기 모터: Jev는 지능이라는 “전기 모터”를 사람들의 업무 안에 넣는 역할을 한다.
   3. 사용자가 결정: TypeSafe가 모든 최종 업무를 결정하는 것이 아니라, 신뢰할 수 있는 프리미티브를 제공하면 각 조직이 그 위에 무엇을 만들지 결정한다.
   4. 늦은 출시의 이유: 더 일찍 출시할 수 있었지만 신뢰성을 위해 수년간 피와 땀을 들였다. 기술적으로 이해하지 못하더라도 사용자가 “이제 믿어도 된다”는 감각을 얻는 것이 중요하다.

5.3. 코딩 에이전트와의 결합

1. 에이전트의 강점과 약점

   1. 강점: 코딩 에이전트는 문법(syntax)에 매우 강하다.
   2. 약점: 의미론(semantics)과 특히 아키텍처(architecture)에 매우 약하다.
   3. 아키텍처의 인간성: 아키텍처는 소프트웨어 개발에서 가장 인간적이고 창의적인 부분이므로, Diogo는 AI 에이전트를 코딩에 사용하는 일을 좋아한다.
   4. 학습 분포의 한계: 실제 사용자 데이터에서 아키텍처를 학습하고 있다면 불쾌할 수 있지만, 문법처럼 학습 분포 안에 있는 지시를 따르게 하는 것은 문제없다고 본다.

2. 속도와 품질 사이의 선택

   1. 50번째 백분위: 코딩 모델의 아키텍처가 50번째 백분위 수준일 수 있다.
   2. 팀의 선택: 조직이 아키텍처를 잘 모른다면 그 수준도 충분할 수 있다.
   3. 속도의 레버리지: 어떤 프로젝트에서는 60번째 백분위의 아키텍처보다 50번째 백분위의 결과를 택하고 Codex를 밤새 실행하는 편이 더 큰 레버리지가 된다.
   4. 미래 결합: 코딩 에이전트가 Jev를 사용해 기존 코드에 지능적인 프리미티브를 넣고, 인간이 에이전트를 관리하는 구조가 자연스럽게 가능하다.

---

6. SaaS의 종말이 아니라 “역(逆) SaaS 아포칼립스”

AI가 SaaS를 파괴할 것이라는 시장 서사와 달리, Jev는 기존 SaaS가 보유한 고객·워크플로·도메인 지식을 활용해 더 큰 승자가 될 수 있다고 본다.

6.1. SaaS가 복제하기 어려운 이유

1. 시장 서사의 변화

   1. 초기 공포: AI 에이전트가 등장했을 때 SaaS 기업의 가치가 급락하는 “SaaS apocalypse”가 거론됐다.
   2. 이후의 환영: Claude가 등장하자 SaaS 기업들은 AI를 최고의 기회로 받아들였다.
   3. 소프트웨어의 복제성: 소프트웨어는 싸고 복사하기 쉽다는 주장이 있었지만, Diogo는 표면적인 코드는 복사할 수 있어도 내부에서 일어나는 많은 일은 쉽게 복제할 수 없다고 반박한다.
   4. 기존 가치: 시장이 두려워 반응했을 수는 있어도 SaaS가 제공하는 가치는 이전과 동일하게 남아 있다.

2. 기존 SaaS의 강점

   1. 고객 이해: 크고 지루해 보이는 SaaS 기업은 어떤 워크플로가 자동화할 가치가 있는지 가장 잘 안다.
   2. 도메인 투자: SaaS는 자본을 먼저 투자해 전체 사용자 기반에 더 나은 경험을 확산시키는 사업이다.
   3. 분포와 유통: 이미 고객을 확보한 SaaS 기업은 새로운 AI 기능을 고객 전체에게 배포할 수 있다.
   4. 결론: SaaS는 AI 시대의 가장 큰 승자 중 하나가 될 가능성이 있다.

6.2. “SaaS-appaloosa”와 사라지는 폼

1. 역 SaaS 아포칼립스

   1. 기회에 대한 이름: Diogo는 SaaS가 붕괴하는 대신 모든 애플리케이션이 훨씬 유용해지는 상황을 “reverse SaaS apocalypse”라고 부르고, 농담으로 “SaaS-appaloosa”라는 이름을 제안한다.
   2. 챗봇 이상의 변화: 고객 옆에 챗봇을 하나 붙이는 것이 아니라 제품 내부의 실제 기능을 크게 개선해야 한다.
   3. 자본 효율: SaaS 기업이 이미 고객에게 도달하는 데 쓴 자본 투자를 활용해, 같은 사용자 기반에 자동화된 기능을 확산시킬 수 있다.

2. 폼에서 자연어로

   1. 폼의 소멸: 사용자가 선택지를 고르는 폼이 사라지고, 소프트웨어가 이미 이해할 수 있는 자연어를 Java와 비슷한 출력으로 매핑할 수 있다.
   2. 4GL의 재등장: Ben은 이런 생각이 1980년대의 4GL(fourth-generation language)과 비슷하다고 지적한다.
   3. “Do what I mean”: 사용자가 정확한 명령이나 입력 위치를 고민하지 않고 의도만 표현하면 소프트웨어가 알아서 실행하는 수준을 지향한다.
   4. 음성 인터페이스 사례: 한 개발자 앱에서는 사용자가 음성으로 컴퓨터를 조작하면서, 시스템이 각 발화를 명령인지 텍스트 입력인지, 텍스트를 어디에 넣을지 계속 판단했다. Diogo는 이 경험이 매우 인상적이지만 해당 앱의 신뢰성은 보증하지 않는다고 선을 긋는다.

---

7. 새 코드를 더 많이 쓰는 것이 아니라 새 능력을 부여하기

Jev의 가장 큰 야심은 논리 게이트와 타입 시스템에 작은 두뇌를 붙여 소프트웨어가 기존에는 표현하지 못했던 판단을 수행하게 만드는 것이다.

7.1. 평균 pull request 10줄의 함정

1. 코드 생성의 한계

   1. 대규모 기업의 평균 PR: Google에서 수행한 조사에 따르면 대기업의 평균 pull request는 약 10줄이다.
   2. 자동화의 규모: 코딩 에이전트는 그 10줄을 자동으로 작성할 수 있지만, 이는 고객에게서 얻은 학습이나 작은 기능 조정에 해당할 수 있다.
   3. 능력 확장의 부재: 10줄을 빨리 쓰는 일은 소프트웨어가 할 수 있는 일을 새로 만들지 않는다.
   4. 안전성 우려: 감독이 줄어든 상태에서 속도만 높이면 결과가 덜 안전해질 수 있다.

2. 새 프리미티브의 의미

   1. 자연어와 추론: Jev는 자연어를 이해하고 어느 정도 추론한다.
   2. 상태 머신과 결합: 자유로운 언어 능력을 상태 머신의 제어 구조와 결합해 다음 동작을 선택한다.
   3. 새 기능: 애플리케이션이 단순히 더 많은 코드를 갖는 것이 아니라 새로운 기능을 얻게 된다.
   4. 개발자와 에이전트 모두의 도구: 인간이 직접 작성해도 되고, 코딩 에이전트가 기존 코드에 삽입해도 된다.

7.2. 지능을 가진 타입과 논리 게이트

1. 타입 안전성의 확장

   1. 기존 논리 게이트: 전통적인 소프트웨어는 몇 가지 기본 논리 게이트와 타입으로 구성된다.
   2. 작은 두뇌: Jev는 그 논리 게이트와 타입에 작은 두뇌를 넣는 것과 같은 비전을 제시한다.
   3. 과대한 목표의 인정: Diogo는 이것이 TypeSafe의 유산과도 연결되는 거대한 비전이며, 실제로 전달할 수 있는 것 이상을 약속하지 않겠다고 말한다.
   4. 싸울 가치: 실현하기 어렵더라도 그 방향을 위해 싸우겠다고 한다.

2. 남은 시스템 질문

   1. 상태 일관성(state consistency): 확률적 판단이 시스템의 상태와 충돌하지 않도록 보장할 수 있는가가 남아 있다.
   2. 강한 보장(strong guarantees): 중요 시스템이 요구하는 수준의 신뢰성과 시스템 전체 보장을 제공할 수 있는지 아직 알 수 없다.
   3. 영향받을 영역: 로그 분석, 이메일 분석, 사용자 인터페이스 설계, 인간-컴퓨터 상호작용은 확실히 바뀔 가능성이 높다.
   4. 고위험 영역: 항공 교통 관제 같은 시스템까지 확장하려면 “조금 무서울” 정도로 높은 보장 수준이 필요하다.

7.3. 확률적 프로그래밍과 뉴로심볼릭 논의

1. 새로운 프로그래밍 시대

   1. 확률적 프로그래밍(probabilistic programming): 다양한 비용·속도·지능의 모델을 프로그램 구조 안에서 선택하는 시대가 열릴 수 있다.
   2. 역사적 뿌리: 확률적 프로그래밍은 1970년대에 이미 큰 역사를 가졌지만 한때 사라졌다.
   3. 뉴로심볼릭 AI: Martin은 Jev의 방향이 뉴로심볼릭(neurosymbolic) AI와 닮았다고 말하며, TypeSafe 공동 창업자 Eric이 그 분야에서 왔다고 언급한다.
   4. 극단적 실용주의: Ben은 생물학적 영감의 설명을 좋아하지 않으며, 결국 작동하는 시스템은 공학적으로 다듬어진다고 주장한다.

2. 시스템 전문가의 역할

   1. 다양한 trade-off: 미래에는 비용과 속도가 서로 다른 수많은 지능을 선택할 수 있다.
   2. 시스템 재설계: 시스템 전문가는 상황에 맞는 모델을 고르고, 개발자는 대략적인 기준만 제시해도 된다.
   3. 1,000배의 지능: 개발자는 시스템 전문가보다 1,000배 더 똑똑한 판단을 내릴 수 있고, 전문가는 거친 추정을 바탕으로 데이터를 적절한 곳에 배치할 수 있다.
   4. 극한 시스템: 이런 조합이 극단적으로 복잡한 시스템에서도 사용할 수 있는 능력을 만들어 낼 수 있다.

---

8. 애플리케이션에서 시스템의 내부까지

Jev는 단순한 애플리케이션 플러그인이 아니라, 신뢰할 수 없는 지능을 신뢰 가능한 프로그램 구성요소로 바꾸는 계층을 지향한다.

8.1. TCP 비유

1. 신뢰성 계층으로서의 Jev

   1. TCP의 역할: TCP가 신뢰할 수 없는 네트워크를 신뢰할 수 있는 통신으로 바꾸는 전환 계층인 것처럼, Jev는 불안정한 AI 호출을 소프트웨어가 사용할 수 있는 판단으로 바꾸려 한다.
   2. AI의 내부화: 공상과학의 미래처럼 모든 소프트웨어가 AI를 호출하는 상황을 생각하면, 사람에게 직접 보여 주는 호출은 전체의 일부에 불과하다.
   3. “많은 9”: AI 호출의 대부분은 사용자 화면의 최상위에서 스타일을 갖춰 사람에게 보여 주는 용도가 아니라, 시스템 내부 깊은 곳에서 발생할 것이다.
   4. 첫 단계부터 깊은 곳으로: 시작부터 내부 계층을 목표로 하지 않으면 나중에 그 깊이까지 도달하는 데 오래 걸린다.

2. 기존의 실패 패턴

   1. AI를 소프트웨어에 몰래 넣기: 실제로 많은 소프트웨어가 이미 비공개로 AI를 내장하려 시도했지만 예측 불가능하게 동작했다.
   2. JSON 스키마 실패: 프롬프트에 “필요한 JSON 출력과 스키마는 이것”이라고 명시해도 모델이 따르지 않는 경우가 있었다.
   3. 사람에게 넘기기: 출력이 불안정하면 사람이 직접 검토하도록 전달했다. 이것이 human-in-the-loop 챗봇이다.
   4. 다른 모델에 넘기기: 또는 출력물을 다른 언어 모델에 다시 전달했다. 이것이 에이전트의 “while loop”다.

8.2. 다섯 단계의 애도와 상태 머신

1. AI 통합의 반복

   1. 부정(denial): 개발자는 AI를 소프트웨어에 넣으면 곧 작동할 것이라고 생각한다.
   2. 분노(anger): 실제 결과가 불안정해지면 프롬프트와 스키마를 고치며 씨름한다.
   3. 타협과 혼란: 출력물을 사람이 확인할지, 다른 모델로 보낼지 여러 겹의 우회로를 만든다.
   4. 수용(acceptance): 결국 사람에게 넘기거나 다른 언어 모델에 넘기는 방식을 받아들인다.
   5. Jev의 제안: 언어 모델을 상태 머신으로 바꾸고, 자연어 판단을 생산적인 분기 안에 배치한다.

2. human-in-the-loop에서 software-in-the-loop로

   1. 챗봇의 구조: 자연어 결과를 사람이 다음 단계로 라우팅하면 사람이 루프 안에 들어간다.
   2. 에이전트의 구조: 자연어 결과를 다음 모델 호출로 라우팅하면 while loop가 생긴다.
   3. Jev의 구조: 자연어 판단을 프로그램의 상태 전이와 결합해 코드가 직접 다음 행동을 선택한다.
   4. 새로운 계층: 핵심은 언어 모델을 더 큰 챗봇으로 포장하는 것이 아니라, 소프트웨어 내부의 신뢰 가능한 결정 계층을 만드는 것이다.

8.3. “do as I mean”이라는 최종 비전

1. 반복되지 않는 명령 해석

   1. 의도와 실행의 연결: 사람은 정확한 UI 필드나 명령 문법을 기억하지 않고 원하는 결과를 말한다.
   2. 유체적인 세계: 각 도구와 시스템이 톱니바퀴처럼 매끄럽게 연결되어 사람이 의도한 일을 수행한다.
   3. 과학소설의 현실화: 모든 기술이 사용자의 뜻대로 작동하는 것은 공상과학처럼 들리지만, 현재 AI의 지능으로 충분히 현실적인 목표가 될 수 있다.
   4. 스타트렉 농담: Ben은 이런 경험을 두고 이미 Star Trek에 들어간 셈이라고 농담한다.

2. 신중한 약속

   1. 과대 약속 거부: Diogo는 Jev가 광고된 모든 용도에 이미 준비됐다고 말하지 않는다.
   2. 신뢰성 우선: 팀이 싸우는 핵심은 신기한 데모가 아니라 실제 업무에 넣을 수 있는 신뢰성이다.
   3. 사용자의 체감: 사람들은 이 기술을 논리적으로 완전히 이해하지 못하더라도 “이제 믿을 수 있다”는 감각을 얻어야 한다.
   4. 최종 문장: 기술의 궁극적인 목표는 “do as I mean”, 즉 사람이 의도한 대로 실행하는 세계다.

---

주요 발언 모음

“대체 자동화는 어디에 있는가?”

“우리는 신이 아니라 제품을 만든다.”

“AI를 사용해 소프트웨어를 만들고 있어도, 여전히 예전과 같은 소프트웨어를 만들고 있다.”

“Jev는 분명히 분류기다. 분류기는 유용하도록 만들어졌다.”

“신뢰성이란 매번 같은 지능을 얻는 것이다.”

“결과가 똑같을 필요는 없지만, 매번 지능적이어야 한다.”

“코딩 에이전트는 문법에는 매우 강하고 의미론에는 매우 약하다.”

“폼의 선택지가 사라지고 자연어가 소프트웨어가 이미 이해하는 출력으로 매핑되는 세상이 있을 수 있다.”

“타입이 작은 두뇌를 가진 논리 게이트처럼 될 수 있다.”

“프로그래머는 어려운 일보다 쉬운 일을 먼저 자동화해야 한다.”

“Jev는 AI의 불안정성을 신뢰할 수 있는 소프트웨어 계층으로 바꾸는 TCP와 같다.”

“모든 기술이 사람이 의도한 대로 작동한다면 어떨까? 그것은 공상과학이 아니다.”

---

핵심 데이터 & 수치

• 42분 24초: 대화의 재생시간이다.
• 2020년: OpenAI가 고객 지원 자동화를 시도하기 시작한 시점으로 언급된다.
• 2017년: Diogo가 “AI: 이론적으로 모듈식이고 실제로 유연한 AI”와 비슷한 주제로 발표하며 데이터와 과업 중심의 관점을 갖고 있던 시점이다.
• 2021년 4분기: RLHF의 일반화 능력이 실제라고 확신한 시점으로 언급된다.
• 95% 대 약 50%: 한 기업이 전체 지원 문의의 95%에 답한다고 주장했지만, 문의의 고유성 기준으로는 약 50% 수준이었다.
• 10시간 대 5분: 5분짜리 반복 작업을 다시 하지 않기 위해 10시간을 들여 자동화하는 프로그래머의 실용주의를 설명하는 예시다.
• 약 10줄: 대기업에서 조사한 평균 pull request 규모다.
• 50번째 대 60번째 백분위: 더 빠른 개발을 위해 아키텍처 품질을 일부 양보할 수 있다는 비교다.
• 1980년대: 자연어로 의도를 표현하는 아이디어가 4GL(fourth-generation language) 논의와 연결된다.
• 3개의 논리 게이트: 기존 타입·논리 게이트에 작은 두뇌를 붙이겠다는 비유의 출발점이다.
• 1,000배: 미래의 시스템 전문가보다 개발자의 판단이 훨씬 더 똑똑해질 수 있다는 비유적 수치다.
• 5단계의 애도: AI를 소프트웨어에 넣으려다 부정, 분노, 혼란과 타협, 수용으로 넘어가는 통합 과정을 설명하는 비유다.

---

결론 및 시사점

1. AI의 다음 진전은 더 큰 챗봇이나 더 빠른 코드 생성이 아니라, 지능을 소프트웨어 내부의 작은 결정 계층으로 내리는 데서 나올 수 있다.
2. 자연어 입력, 프로그램 상태, 상태 머신, 확률과 신뢰도를 묶으면 기존 명령형 코드가 다루기 어려웠던 의도를 표현할 수 있다.
3. 제품에 AI를 넣으려면 “모델이 얼마나 똑똑한가”보다 “매번 코드가 사용할 수 있을 만큼 지능적인 결과를 내놓는가”를 먼저 측정해야 한다.
4. 반복 빈도가 높고 ROI가 분명한 쉬운 업무부터 자동화하면 현실의 긴 꼬리와 예외를 한 번에 해결하지 않고도 생산적 전환을 시작할 수 있다.
5. 기존 SaaS 기업은 고객 분포, 도메인 지식, 워크플로 데이터를 이미 가지고 있으므로 AI 시대에 오히려 강력한 유통·자동화 주체가 될 수 있다.
6. 코딩 에이전트는 문법과 반복 구현을 맡고, 인간과 Jev 같은 프리미티브는 의미론·아키텍처·의도 표현을 담당하는 분업이 가능하다.
7. 장기적으로 소프트웨어 타입과 논리 게이트는 확률적 판단 능력을 가진 구성요소가 될 수 있지만, 상태 일관성·보안·비용·속도·강한 보장은 여전히 해결해야 한다.
8. 최종 지향점은 사람이 시스템의 문법과 폼을 배우는 것이 아니라, 시스템이 사람의 의도를 이해해 “내가 뜻한 대로(do as I mean)” 실행하는 세계다.