왜 Jev를 만들었나: 프로그래머블 AI와 기계 네이티브 지능

메타데이터

• 원문 제목: Why We Made Jev — Diogo Almeida, TypeSafe Co-founder & CEO
• URL: https://www.youtube.com/watch?v=cFx9Z3ZXca0
• 날짜: 2026-09-21
• 처리일: 2026-09-22
• 채널: Latent Space
• 출연자: Diogo Almeida, TypeSafe 공동창업자 겸 CEO
• 주제: Jev, System 1 모델, 프로그래머블 AI, RLCD, 신뢰성, AI API

---

📌 핵심 질문 / 논점

==AI가 수학의 난제를 풀 정도로 똑똑한데도 기본적인 경제 활동을 자동화하지 못하는 이유는 지능이 부족해서가 아니라, 소프트웨어가 직접 사용할 수 있는 형태의 신뢰할 수 있는 지능이 없기 때문이다. TypeSafe은 이를 해결하기 위해 인간과 대화하는 챗봇이 아니라 코드가 소비하는 프로그래머블 System 1 모델 Jev를 만든다.==

• 기존 LLM은 채팅·문자열·인간 피드백에 과도하게 최적화되어 소프트웨어가 요구하는 예측 가능성, 확률, 선택, 구조화된 상태를 제공하지 못한다.
• Jev는 intelligence per dollar를 북극성으로 삼고, 복잡한 시스템 프롬프트 하나 대신 작은 결정과 구조화된 질문을 프로그램 안에서 조합하도록 설계한다.
• RLHF가 “인간이 좋아하는 답”을, RLVR이 “검증 가능한 벤치마크 점수”를 북극성으로 삼았다면 RLCD는 “프로그램 안에서 신뢰성 있게 사용되는 지능”을 목표로 한다.
• TypeSafe은 공개 벤치마크를 게임하는 대신 실제 워크플로에 넣어 신뢰성과 여러 개의 9(nines)을 측정해야 한다고 주장한다.

1. Jev 출시와 AI 경제 혁명의 재개

1.1. 새로운 모델 계열

1. Jev는 TypeSafe이 “System 1 모델” 또는 “machine-native system 1 large programmable model”이라고 부르는 계열의 첫 모델이다.
2. 자연어를 자동완성하거나 인간에게 답하는 모델이 아니라, 코드가 직접 소비하고 조합하는 지능을 제공한다.
3. 모델 내부뿐 아니라 API, 타입, 출력 구조, 비용, 속도까지 소프트웨어 통합을 기준으로 최적화한다.
4. Jev라는 이름은 Jevons paradox에서 왔으며, 핵심 기준은 intelligence per dollar다.
5. 비용·속도·신뢰성·보정(calibration)은 중요하지만, 비용과 속도는 지능을 얻기 위한 값이고 실제로 중요한 것은 지능 그 자체다.

1.2. 출시 직후의 개발자 커뮤니티

1. 출시 직후 Diogo는 자신을 “너덜너덜한 시체 같은 사람”이라고 표현할 정도로 지쳐 있었지만, AI 경제 혁명이 다시 가능하다는 사실을 개발자들이 알아보기 시작했다는 점에서 강한 흥분을 느꼈다.
2. TypeSafe은 투자자나 VIP보다 개발자·엔지니어를 위한 타운홀을 우선했다.
3. Discord 커뮤니티는 10만 명 규모로 성장했고, 공개 영상은 수천만 조회를 기록했다.
4. 단순 가입자 수보다 기계가 밤에도 계속 호출하고 실제 작업을 수행하는지가 개발자 플랫폼의 핵심 신호다.

2. RLHF의 모드 붕괴와 보정

2.1. 문자열 모델이 인간 취향으로 수렴하는 방식

1. 잘 보정된 분포는 희귀한 결과와 이상치를 허용하지만, 모드가 붕괴하면 흔한 답만 남는다.
2. 긴 문자열에서 한 번의 명백한 오류는 쉽게 발견되지만 미묘한 오류는 놓치기 쉽다.
3. RLHF 보상은 명백한 오류를 강하게 벌하므로 모델은 긴 출력을 만들수록 지나치게 보수적으로 변한다.
4. 과도한 확신, 아첨, 장황한 설명, 이모지와 후속 질문 같은 채팅 특성은 인간에게 자연스럽지만 소프트웨어의 안정적인 계약과는 충돌한다.

2.2. Yann LeCun과 세계 모델

1. Diogo는 Yann LeCun의 문제 제기 중 상당 부분이 현실에 가깝다고 평가한다.
2. 시퀀스가 길어질수록 오류가 증가한다는 직관이 실제 모델 행동과 항상 일치하지 않는 이유는 문자열 모델이 드문 모드를 버리기 때문이다.
3. JEPA 같은 공동 임베딩 예측(joint embedding prediction)과 세계 모델은 흥미로운 연구 방향이지만, Diogo는 당장 무엇을 만들 수 있는지를 더 중요하게 본다.
4. 스케일링 법칙은 투입량보다 체감 수익이 작을 수 있으나, 그 개선이 큰 가치를 만들 때는 의미가 있다.

3. 안전 정렬과 범용 API의 경계

3.1. 거부는 API에서 타입 오류가 될 수 있다

1. 사람이 모델과 대화하다가 파일을 읽을 수 없다는 거부를 받는 것은 불편하지만 우회할 수 있다.
2. 다른 프로그램이 의존하는 백그라운드 컴포넌트가 특정 입력에서 거부하면 전체 소프트웨어가 확률적으로 깨진다.
3. ChatGPT나 Claude 같은 1차 제품은 일반 사용자와 가족을 위해 안전 정책을 둘 수 있지만, 개발자용 API는 사용자가 애플리케이션의 정책을 직접 구성해야 한다.
4. 범용 지능 계층에 downstream 목적별 금지 규칙을 계속 넣으면 지능이 파편화되고 일반적인 사용성이 떨어진다.

3.2. 책임은 제품과 조직 계층에 둔다

1. 모델이 전쟁이나 폭력에 사용될 가능성은 현실적인 우려지만, 기술 계층 자체에 모든 downstream 목적을 심는 것은 다른 문제다.
2. 일반 지능 API는 작은 결정으로 분해된 호출을 수행하고, 최종 정책과 책임은 제품과 조직이 가져야 한다.
3. 데이터베이스가 사용 목적을 판단하지 않는 것처럼, 기반 지능도 호출자의 전체 목적을 알 수 없어야 소프트웨어 엔지니어에게 최대한의 능력을 제공할 수 있다.

4. 공개 벤치마크 대신 실제 워크플로

4.1. 공개 점수의 한계

1. 공개 문항은 학습 데이터에 들어가거나 유사 데이터 수집으로 최적화될 수 있다.
2. MMLU와 비슷한 데이터를 만들어 성능을 높이는 것은 벤치마킹에 벤치마킹을 더한 것일 뿐이다.
3. 실제 지능은 공개 점수보다 사용자가 “이것을 실제로 쓸 수 있다”고 느끼는 순간 드러난다.

4.2. 출시 후 실제 신호

1. Jev는 밤에도 계속 호출되며 하루 1조 토큰을 넘는 사용량에 도달했다.
2. 대기자 명단의 가입자 수보다 사용자가 가치를 발견한 뒤 더 많은 rate limit을 요구하는지가 중요하다.
3. 한 명의 파워 유저가 백그라운드 루프를 만들어 창출하는 가치는 모든 사람이 테스트 질의를 몇 번 작성하는 것보다 클 수 있다.
4. TypeSafe은 내부에서 비용·속도·지능을 비교하지만, 최종 평가는 모델을 실제 워크플로에 넣고 정확도·지연·실패·운영 비용을 측정하는 방식이어야 한다.

5. 가장 쓰라린 교훈: 올바른 과업이 데이터·컴퓨트를 이긴다

5.1. 세 가지 북극성

1. RLHF는 인간이 원하는 지시 따르기(instruction following)를 중요한 과업으로 만들었다.
2. RLVR는 검증 가능한 보상과 추론을 중심에 놓았지만, 검증 가능한 벤치마크에 모델을 날카롭게 과적합시킬 수 있다.
3. RLCD는 프로그램 안에서 직접 소비되고 신뢰성 있게 동작하는 지능을 북극성으로 삼는다.
4. 알고리즘이 무엇인지보다 어떤 방향을 가치 있는 목표로 삼는지가 모델의 행동과 실패 양식을 결정한다.

5.2. 데이터가 곧 모델 역량이다

1. TypeSafe은 데이터 랩에 가깝다. 좋은 데이터는 합성인지 아닌지가 아니라 과업의 모양과 필요한 행동을 정확히 표현하는지로 평가한다.
2. 좋은 데이터 담당자는 생성 결과를 읽고 무엇이 잘못됐는지 표현하고, 다시 생성하고, 일반적인 결함을 외과적으로 고친다.
3. 사용자 데이터를 그대로 학습하면 사람들이 자주 묻는 요청에 과적합될 수 있다.
4. 현재의 사용 패턴만 데이터로 삼으면 미래의 인프라 계층이 되어야 할 모델이 현재의 관습에 갇힌다.
5. Diogo는 10억 달러가 주어져도 처음부터 사전학습하지 않겠다고 말한다. 기존 모델 조합과 정밀한 후처리가 비용과 속도 면에서 더 실용적일 수 있다.

6. RLCD와 프로그래머블 AI

6.1. 코드가 소비하는 새로운 학습 과업

1. RLCD는 특정 알고리즘의 이름보다 새로운 북극성 과업을 설명하는 용어다.
2. 핵심은 human-in-the-loop를 제거하고 프로그램 루프 안에서 안정적으로 사용할 수 있는 판단과 출력이다.
3. 프로그래머블 AI는 소프트웨어 엔지니어가 지능을 호출·검증·조합하는 방식을 바꾼다.

6.2. 긴 문자열 대신 작은 결정

1. 하나의 거대한 시스템 메시지에 모든 조건을 넣으면 어떤 규칙이 실행됐는지 검증하기 어렵다.
2. 모델이 해야 할 일을 가장 작은 의미 단위로 분해하면 각 질문과 결과를 독립적으로 평가할 수 있다.
3. 파일을 읽었는지, 특정 키를 외부 모델에 넘기지 않았는지처럼 프로그램적으로 보장해야 하는 정책은 별도 결정으로 만든다.
4. 작은 결정은 어느 단계에서 틀렸는지 보이고, threshold·재시도·사람에게 escalation 같은 운영 정책을 붙이기 쉽다.

7. Jev API의 설계

7.1. 문자열 대신 구조화된 상태

1. 상태·지시·기준·입력을 JSON 객체로 전달한다.
2. 중첩 구조는 모델이 처리할 난도를 높이지만 프로그램에는 더 명료하고 구현 세부사항과 독립적이다.
3. 시스템 메시지는 모든 변수를 전역 변수처럼 쌓는 방식이므로 테스트와 조합이 어렵다.
4. 함수 상태의 일부만 다음 결정에 넘기면 상태를 명시적으로 관리할 수 있다.

7.2. 프로그래밍 프리미티브

1. Choice는 enum이나 switch문에 가까운 선택 프리미티브다.
2. Boolish는 참·거짓에 가까운 연속값으로 조건문에 연결할 수 있다.
3. Score는 정수나 실수와 동일하지 않은 평가값으로, 정렬하거나 threshold를 적용할 수 있다.
4. 이 타입들은 기존 프로그래밍 타입과 닮았지만 같은 것은 아니며, 명료성을 위해 새로운 개념으로 설계했다.
5. 앞으로도 모델 출력을 switch, if, sorting, thresholding 같은 프로그래밍 프리미티브에 연결할 타입이 추가될 수 있다.

7.3. API 사용 팁

1. 큰 질문을 하나 던지지 말고 가장 작은 의미 단위로 쪼갠다.
2. 질의의 참조 대상을 백틱과 명시적인 구조로 고정해 모델이 문자 그대로 이해하게 한다.
3. 한 상태를 한 번 가져온 뒤 여러 개의 병렬 질문을 던지면 비용을 줄일 수 있다.
4. 메시지와 상태에 ID를 붙여 긴 상태의 각 요소에 별도 질문을 보낸다.
5. 거부 정책처럼 복잡한 판단은 상황별 조건을 독립적으로 묻고, 실패가 발견되면 새로운 질문·threshold·테스트 케이스를 추가한다.

8. 신뢰성·견고성·결정성

8.1. 결정성보다 견고성

1. 결정성(determinism)은 같은 입력에 같은 출력을 내는 속성으로 단위 테스트에는 유용하다.
2. 견고성(robustness)은 비슷한 의미의 입력에 비슷한 결과가 나오는 속성이다.
3. 무의미한 UUID나 nonsense를 바꿔 넣어도 의미가 같다면 결과가 비슷해야 한다.
4. 결정성은 비용·지능과 교환될 수 있지만, 실제 의사결정에서 사용자를 태우는 문제는 표면 표현 변화에 결과가 흔들리는 것이다.

8.2. 모델 버전과 LTS

1. 개발자는 API 모델이 배포 후 몰래 바뀌어 종속성을 깨는 것을 싫어한다.
2. TypeSafe은 배포한 모델을 바꾸지 않겠다고 말하지만, 새 모델은 훨씬 빠르게 출시할 계획이다.
3. 사용자가 많은 Jev 1.13.0 같은 버전을 임시 LTS로 유지하는 방식을 고려한다.
4. 모든 버전을 장기 지원하면 모델 fleet이 수백 개로 쪼개지므로, 빠른 개선과 호환성 사이의 균형이 필요하다.

9. Intelligence per dollar와 실제 경제 혁명

9.1. 속도·비용·지능

1. Jev는 “빠르고 싼데 지능도 유지하는” 비어 있는 사분면을 노린다.
2. 사용자 대면 시스템에서는 100~1,000밀리초 구간의 차이가 경험을 바꾼다.
3. 백그라운드 배치 작업에서는 latency보다 총 비용이 중요할 수 있다.
4. AI가 화면의 주인공이 아니라 기존 소프트웨어 속으로 사라지는 것이 TypeSafe이 말하는 역 SaaS 종말(inverse SaaS-pocalypse)이다.

9.2. System 1과 System 2

1. 사전학습된 지능의 응축물은 빠른 직관·패턴·단일 단계 결정에 강하다.
2. Jev는 단일 단계 작업에서 강하고, 멀티홉 reasoning이 늘어날수록 성능이 떨어질 수 있다.
3. RLVR은 수학·추론 벤치마크에서 놀라운 성능을 만들었지만, 특정 과업에 날카롭게 과적합된 jagged한 능력을 보인다.
4. System 2 작업을 버리는 것이 아니라 confidence와 uncertainty를 사용해 큰 모델·사람·다른 경로로 escalation한다.

10. 안전과 프런티어 속도에 대한 비판

1. “더 많은 RLVR”이 유일한 연구 경로라는 전제를 받아들이지 않는다.
2. TypeSafe은 자신들의 목적에 필요한 RLVR 양이 0에 가깝다고 판단한다.
3. 다른 연구소가 모델에 무엇이든 시도할 권한을 주면서 발생하는 위험은 그 학습 방향의 결과이며, 다른 목적의 회사가 같은 위험을 감수할 이유는 없다.
4. 목표는 연구소를 설득하는 것이 아니라 소프트웨어 엔지니어에게 새 자동화 선택지를 주는 것이다.
5. 정책·안전 논쟁에서 과도한 확신과 권위에 기대어 사람을 움직이면 장기적인 신뢰를 잃을 수 있으므로, 기술자는 가능한 한 투명해야 한다.

11. AI가 사라지는 주요 사용 사례

1. Dark data: 기업이 보유하고도 비용 때문에 분석하지 못한 데이터 더미를 저렴한 지능으로 반복 분석한다.
2. Coding agents: Jev로만 가능한 결정 프리미티브를 붙여 단일 모델 중심의 코딩 에이전트 경쟁을 바꾼다.
3. Real-time intelligence: 전자상거래, 개인 비서, 게임처럼 10밀리초의 개선도 가치가 있는 루프에 지능을 넣는다.
4. Verify everything: 모든 LLM 호출에 ID를 부여하고 상태별로 병렬 질문을 던져 결과를 관찰·검증한다.
5. Smart software: Jev를 프로그래밍 언어 구성 요소처럼 사용해 과거에는 불가능했던 조합형 소프트웨어를 만든다.
6. Computer use: 브라우저·음성·운영체제 상호작용을 결정 모델로 연결하고, 화려한 데모보다 반복 가능한 안정성을 검증한다.

12. KV cache의 폭정에서 벗어난 코딩 에이전트

1. 현재 코딩 에이전트는 효율적인 KV cache를 위해 한 모델의 긴 대화 상태를 계속 append하는 구조에 묶여 있다.
2. 이 구조는 상태 관리·추상화·작업 분해보다 긴 컨텍스트를 그대로 전달하는 방식을 유도한다.
3. 계층형 서브태스크 트리와 명시적 상태를 만들고, 필요한 부분만 검색하면 더 작은 모델로도 서브 에이전트를 운영할 수 있다.
4. 역사적 컨텍스트를 저렴하게 조회하면 매번 처음부터 시작하지 않는 메모리 관리가 가능하다.
5. 병렬 에이전트가 서로의 상태를 읽고 쓰며, 단순한 잠금이 아니라 지능적인 조정으로 충돌을 해결할 수 있다.

13. TypeSafe의 창업 배경과 미래

13.1. OpenAI에서 출발한 문제의식

1. GPT-3.5와 instruction following은 큰 가능성을 보여 주었지만 실제 활용은 카피라이팅과 웹의 새로운 슬롭에 치우쳤다.
2. 모델이 똑똑한데 경제적 가치를 만들지 못하는 이유를 거꾸로 추적한 결과, AI API의 주 사용자는 사람이 아니라 코드라는 결론에 도달했다.
3. 몇 주 안에 끝날 줄 알았던 연구가 수년이 되었고, 가능성의 신호가 보이자 TypeSafe을 창업했다.

13.2. 다음에 탐구할 것

1. 지능적인 NPC와 상태 머신으로 게임을 더 풍부하게 만드는 일은 아직 큰 기회다.
2. KV cache 제약이 사라진 코딩 에이전트, 계층형 메모리, 병렬 에이전트 협업은 탐구할 가치가 크다.
3. TypeSafe은 Jev 하나에 머무르지 않고 여러 형태의 지능을 제공하는 “지능의 AWS” 방향을 상상한다.
4. 중요한 것은 새 모델을 무작정 늘리는 것이 아니라, 하나의 통합된 비전 아래 소프트웨어가 사용할 수 있는 지능의 형태를 확장하는 것이다.

주요 발언 모음

“AI가 수학의 밀레니엄 문제를 풀 수 있는데도 기본적인 경제적 일을 자동화하지 못하는 이유는, 능력과 실제 소프트웨어 사이에 올바른 플러그가 없기 때문이다.”

“우리는 인간이 아니라 코드가 소비하는 모델을 만들고 있다.”

“RLCD의 북극성은 프로그램 안에서 신뢰성 있게 사용되는 지능이다.”

“공개 벤치마크가 아니라 실제 워크플로에 넣고, 그 워크플로가 어떻게 작동하는지 측정해야 한다.”

“게이트를 건너뛸 수 있다면 모델은 건너뛴다.”

“AI는 소프트웨어의 주인공으로 남는 것이 아니라 더 나은 소프트웨어 속으로 사라져야 한다.”

“KV cache의 폭정에서 벗어난 코딩 에이전트에는 아직 탐구되지 않은 공간이 많다.”

핵심 데이터 & 수치

• 출시 후 사용량: Jev는 밤에도 계속 호출되며 하루 1조 토큰을 넘는 사용량에 도달했다.
• 커뮤니티: TypeSafe Discord는 약 10만 명 규모로 성장했다.
• 속도 예산: 사용자 대면 시스템에서는 100~1,000밀리초의 지연 예산이 경험을 좌우한다.
• 생산성 전망: Diogo는 AI 경제 혁명이 통계상 5년 내 TFP 3% 성장으로 나타날 수 있다고 언급한다.
• 모델 선택: 한 번의 큰 reasoning 호출 대신 여러 개의 값싼 System 1 결정을 조합한다.
• 확장 방향: TypeSafe은 여러 형태의 지능을 제공하는 ‘지능의 AWS’를 지향한다.

결론 및 시사점

1. AI의 병목은 모델의 IQ가 아니라 소프트웨어 연결부다: 실제 가치가 있는 업무를 자동화하려면 모델을 코드가 직접 호출하고 검증할 수 있어야 한다.
2. System 1 지능을 과소평가하지 말라: 빠른 단일 결정을 작은 프리미티브로 조합하면 거대한 reasoning 호출보다 값싸고 안정적인 시스템을 만들 수 있다.
3. 북극성 과업이 모델을 만든다: RLHF·RLVR·RLCD는 알고리즘보다 무엇을 가치 있는 목표로 삼는지의 차이다.
4. 작은 질문과 구조화된 상태가 운영 가능성을 만든다: 긴 시스템 프롬프트 대신 choice·score·threshold를 코드로 분해하면 각 단계를 평가할 수 있다.
5. 공개 점수와 실제 품질을 구분하라: 실제 워크플로의 신뢰성·비용·속도·nines가 더 중요한 평가다.
6. AI는 제품 전면보다 내부 인프라가 될 수 있다: dark data, 코딩 에이전트, 실시간 시스템, 검증 가능한 스마트 소프트웨어에서 큰 가치가 발생한다.
7. KV cache는 임시 제약일 수 있다: 계층형 상태·선택적 메모리·병렬 에이전트 협업을 통해 코딩 에이전트를 다시 설계할 여지가 크다.
8. 신뢰성이 지능을 경제적 가치로 바꾼다: 충분히 똑똑해도 반복적으로 믿을 수 없다면 실제 경제 활동을 자동화할 수 없다.