How Jev Turns AI Into Software That Gets Things Done

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jev는 AI를 프로그램의 상태와 행동에 연결해, 소프트웨어가 사용자의 의도대로 실제 업무를 신뢰성 있게 수행하도록 만들려는 구성요소다.

📌 핵심 요점

1. 목표는 소프트웨어가 수행할 수 있는 일의 확장이다. Type Safe는 Jev를 코드 안에 넣는 지능형 구성요소로 제시한다. 자연어로 표현된 의도를 프로그램에서 다뤄 기존에 자동화하기 어려웠던 작업을 처리하려는 접근이다.
2. 상태 머신과 AI의 연결이 핵심 작동 구상이다. 원하는 일을 자연어로 설명하고 상태 머신을 제공하면 신뢰도에 따라 행동을 선택한다. 디오구는 Jev가 분류기라는 설명을 받아들이며, 개발자가 이런 기능을 쉽게 프로그래밍할 수 있다는 점에 가치를 둔다.
3. 신뢰성은 상황이 달라져도 판단 능력을 유지하는 것이다. 같은 입력에 같은 출력을 내는 결정성이나 서비스 가동률만으로는 충분하지 않다. 작업과 무관한 UUID가 프롬프트에 추가돼도 기능적인 판단은 유지돼야 한다는 설명이다.
4. 평가 기준은 실제 업무의 자동화 성과여야 한다. 사람에게 좋아 보이는 답변과 반복 업무를 맡길 수 있는 능력에는 차이가 있다. 헬프데스크 문의의 95%를 처리했다는 과거 사례도 비밀번호 재설정에 편중됐으며, 문의 유형 기준으로는 약 50%였다는 경험이 소개된다.
5. 확산의 관건은 비용·속도·기존 시스템과의 통합이다. 현재는 달러당 지능을 우선하지만, 초당 지능이 더 중요할 가능성도 인정한다. 기존 SaaS 기업은 고객의 문제와 업무 흐름을 알고 고객 기반을 확보했다는 점에서 적용 기회를 가질 수 있다.

🧩 배경과 문제 정의

• AI의 높은 지능이 실제 업무 자동화로 충분히 이어지지 않는다는 문제의식이 출발점이다. 챗봇과 코딩 도구의 유용성에 비해, 소프트웨어 자체가 수행할 수 있는 일의 범위는 크게 달라지지 않았다는 비판이다.
• Type Safe의 Jev는 개발자의 코드 작성을 돕는 데서 더 나아가, 소프트웨어 안에 지능을 넣어 기존에 자동화하기 어려웠던 일을 처리하도록 만드는 것을 지향한다.
• 핵심 과제는 인상적인 개별 답변보다 신뢰할 수 있는 반복 실행이다. 백그라운드에서 데이터와 자원에 접근하는 자동화에는 조합 가능성, 안전성, 일관된 판단 능력이 필요하다.

🕒 시간순 섹션별 상세정리

1. 높은 AI 지능과 부족한 자동화 사이의 간극

• 디오구는 챗봇과 코딩 도구를 좋아하고 직접 사용하지만, 그 밖의 영역에서는 AI의 잠재력이 충분히 활용되지 못한다고 평가한다. 뛰어난 원재료가 실제로 유용한 소프트웨어로 전환되지 못한다는 문제다. [01:50]
• Type Safe는 개발 과정에서 사람을 보조하는 것뿐 아니라 실제 소프트웨어를 구성하는 AI를 개발하며, Jev를 자동화를 크게 개선하기 위한 첫 모델로 제시한다. [02:11]

2. 코드를 빨리 만드는 도구에서 소프트웨어의 능력을 넓히는 구성요소로

• Codex 같은 코딩 도구는 자연어로 즉석에서 프로그램을 만들지만, 결과물의 표현력은 기존 소프트웨어의 범위에 머문다는 구분이다. Jev의 목표는 의도 같은 개념을 프로그램에서 다루게 해 자동화 가능한 작업의 범위를 넓히는 것이다. [03:07]
• Jev는 사람이나 코딩 도구가 작성하는 코드 안에 넣는 새로운 구성요소다. 코드 작성 주체를 바꾸기보다 코드가 수행할 수 있는 일을 확장한다. [04:38]

3. 분류기를 개발자가 쉽게 프로그래밍할 수 있게 만드는 가치

• 기존 소프트웨어에 행동 가능한 챗봇을 붙여도, 신뢰성 때문에 모든 행동을 맡기기는 어렵다. Jev는 AI가 잘하는 일과 코드가 제공하는 가치를 결합하는 지점을 겨냥한다. [05:57]
• 디오구는 Jev가 분류기라는 설명을 받아들인다. 분류기는 실용적인 시스템을 만들기 위한 도구이며, 확률을 다룬다는 점 자체도 새로운 것은 아니다. [06:49]

4. 비용 효율과 프로그램 내부 통합을 우선하는 설계

• 자연어 입출력과 절차적 프로그램 사이에는 연속적인 설계 선택지가 있다는 입장이다. 현재 우선순위는 달러당 지능이지만, 단기적으로는 초당 지능이 더 중요할 수도 있어 자신의 선택이 틀릴 가능성을 인정한다. [08:05]
• 입력을 ‘상태’로 다루는 인터페이스는 AI를 프로그램의 일부로 넣기 위한 의도적인 선택이다. 더 복잡한 내부 상태에도 AI를 적용하려 하지만, 당분간은 표준 라이브러리보다 데이터베이스에 가까운 형태가 될 것으로 예상한다. [08:24]

5. 수학보다 유용한 시스템 구축에 끌린 창업자의 경력

• 디오구는 수학에 재능이 있었지만 경쟁에서 이기는 데 집중된 활동은 좋아하지 않았고, 수학적이면서도 유용하고 재미있는 컴퓨터과학에 더 끌렸다. 자신도 AI 연구자보다는 컴퓨터과학자로 여긴다. [10:09]
• AI 분야로 들어온 계기는 Kaggle 대회 우승이었다. 승리의 핵심은 복잡한 수학보다 작업 자동화와 시스템 문제 해결이었으며, 이후 NeurIPS 발표와 이자벨 기용의 도움을 통해 연구자들과 연결됐다. [10:50]

6. 하나의 거대 지능보다 실용적인 제품에 거는 낙관

• 진행자들은 Type Safe의 관점을 ‘신이 아니라 제품을 만든다’는 말로 요약한다. AI가 더 많고 더 나은 일자리를 만들 수 있다는 낙관적인 미래상으로 해석하지만, 이는 실현된 결과가 아니라 전망이다. [12:37]
• 디오구는 AI에 대한 부정적인 세계관이 모든 것을 지배하는 하나의 모델이라는 발상과 연결돼 있다고 본다. 정작 사람들이 맡지 않아도 될 기초적인 일조차 자동화하지 못한 현실과 거대한 미래 서사 사이의 괴리를 지적한다. [13:46]

7. 호출할 필요 없이 믿고 맡기는 백그라운드 자동화

• Muse로 뉴욕타임스 구독을 취소했다는 사례는 번거로운 일상 업무에도 자동화 수요가 있음을 보여준다. 다만 디오구는 눈에 띄는 특이 사례나 예상 밖의 결과에만 집중해서는 자동화의 목표에 도달하기 어렵다고 본다. [15:23]
• 목표는 사용자가 매번 호출하지 않아도 믿고 실행해 둘 수 있고, 개발자가 그 위에 다른 기능을 쌓을 수 있는 시스템이다. 이를 위해 구성요소를 조합할 수 있어야 한다. [16:09]

8. RLHF의 일반화 능력과 AGI 기대가 남긴 실망

• 디오구는 2017년에도 AI를 소프트웨어 시스템으로 보는 비슷한 생각을 갖고 있었다고 회고한다. 다만 당시 발표 제목과 이후 생각이 구체화된 시점은 확신하지 않는다. [17:28]
• 2021년 말 무렵에는 RLHF의 일반화가 단순한 데이터 재현인지 검증하려 했다. 인터넷에 없음을 미리 확인한 ‘명상 전에 양말을 먹는 것이 왜 중요한가’ 같은 질문에도 사람다운 설득력 있는 답변이 나왔고, 이를 단순한 속임수가 아니라는 근거로 받아들였다. [18:02]

9. 사람에게 좋아 보이는 답변과 실제 자동화 성과의 차이

• 디오구는 AGI라는 개념이 여러 사람이 서로 다른 기대를 담을 만큼 넓고 모호했다고 본다. 자신은 AGI로 향하고 있다는 주장에 동의하지 않지만, 경제적 가치가 있는 업무 대부분을 자동화한다는 목표 자체는 충분히 실행 가능하다고 판단한다. [19:35]
• 많은 업무는 반복적이고 단순하며, 외주화할 수 있을 만큼 명확한 지시로 드러난다. 이런 일을 수행할 지능은 모델에 오래전부터 있었다는 것이 그의 판단이고, 의문은 왜 실제 기능으로 제공되지 않느냐는 데 있다. [20:19]

10. 생산 업무의 자동화 가능성을 성과 기준으로 삼기

• 진행자는 생산적인 실제 업무를 얼마나 자동화할 수 있는지가 평가 기준이어야 하는지 묻는다. 디오구는 어려운 수학 문제를 해결한다는 주장과 드라이브스루 주문조차 처리하지 못하는 현실의 간극을 점검 기준으로 제시한다. [21:10]
• 이에 현실의 데이터 분포는 예외가 많고 꼬리가 두꺼우며, 학습에 필요한 데이터도 부족하다는 반론이 나온다. 수학이나 코딩의 성과가 현실 업무로 바로 이전되지 않는 이유가 데이터 차이일 수 있다는 가설이다. [21:53]

11. 모든 예외를 해결하기보다 투자 가치가 있는 자동화부터 구축하기

• 디오구는 현실에 많은 예외가 있다는 점은 인정하지만, 데이터 부족만으로 자동화 부진을 설명하는 데는 동의하지 않는다. 모든 예외를 자동화해야만 성과를 인정할 필요는 없으며, 신뢰할 수 있는 소프트웨어 구축에는 원래 투자가 필요하다는 입장이다. [22:28]
• 짧은 반복 작업을 없애기 위해 긴 시간을 들이는 일은 투자수익의 문제다. 자동화가 가능해지면 새로운 종류의 일도 생겨날 것으로 예상하며, 이를 제번스의 관점과 연결한다. [23:09]

12. 고객 지원의 높은 처리율이 가릴 수 있는 업무 편중

• 생성형 AI 유행 이전에도 헬프데스크 문의의 95%를 처리한다는 기업 사례가 있었지만, 데이터를 살펴보면 비밀번호 재설정이 대부분이었다는 경험이 나온다. 처리 건수의 비율만으로 다양한 업무를 해결한다고 판단하기는 어렵다. [24:14]
• 같은 사례를 문의 유형의 고유성을 기준으로 보면 비율이 약 50%에 그쳤다는 설명이다. 반복 문의의 높은 처리율과 다양한 예외를 다루는 능력을 구분해야 한다. [24:31]

13. 예상 밖의 관심 확산과 제품의 중심에 둔 신뢰성

• 디오구는 출시 이후 나타난 활용 범위와 반응을 예상하지 못했다고 드러낸다. 개발자가 아닌 지인들까지 온라인에서 관심을 보였지만, 비개발자가 제품을 어떻게 사용할지는 자신도 명확히 알지 못한다. [24:55]
• Jev의 핵심은 수년간 공들인 신뢰성이며, 이 목표를 이해하지 못하면 겉모습이 비슷해도 신뢰할 수 있는 제품을 만들기 어렵다는 입장이다. 신뢰성 향상은 새로운 응용을 가능하게 하므로, 매우 높은 수준을 추구한다. [25:45]

14. 같은 출력보다 매번 유지되는 판단 능력으로서의 신뢰성

• 디오구가 말하는 신뢰성은 서비스 가동률이나 같은 입력에 같은 답을 내는 결정성과 다르다. 핵심은 매번 비슷한 수준의 지능을 유지하는 견고성이다. [26:35]
• 결정성은 단위 테스트에는 유용하지만 실제 시스템의 요구를 충분히 설명하지 못한다. 프롬프트에 UUID를 추가해도 본래 작업이 같다면 기능적인 판단은 유지돼야 한다는 예를 든다. [27:09]

15. 코딩 에이전트의 문법 능력과 소프트웨어 설계의 절충

• Jev를 사용하는 코딩 에이전트와 사람이 직접 Jev를 활용하는 개발 방식의 관계가 쟁점이 된다. 디오구는 자신의 경험상 코딩 에이전트가 문법에는 강하지만 소프트웨어 설계에는 매우 약하며, 설계가 개발의 창의적이고 인간적인 부분이라고 본다. [28:06]
• Jev 활용이 현재 코딩 모델의 학습 분포 안에 충분히 포함돼 있는지는 불확실하다. 익숙한 영역이 되면 문법적인 코드 작성에 활용하는 데는 문제가 없을 것으로 예상하지만, 설계 능력에 대해서는 모델이 하위 50% 수준일 수도 있다는 개인적 평가를 내놓는다. [29:16]

16. SaaS의 고객 지식과 유통 기반이 AI 시대에도 가치를 갖는다

• 소프트웨어가 저렴하고 복제하기 쉽다는 이유만으로 SaaS의 가치가 사라진다고 보기는 어렵다. 내부에는 복잡한 처리와 기존 시스템이 있으며, SaaS가 제공하는 가치는 이전과 같다는 견해다. 시장의 반응에는 두려움이 반영됐을 가능성도 있다 [31:05]
• 기존 SaaS 기업은 사용자의 문제와 자동화할 업무 흐름을 잘 알기 때문에 AI의 큰 수혜자가 될 수 있다. 다만 이는 제품의 잠재력에 관한 전망이며, 금융시장에 대한 예측은 유보한다 [31:49]

17. 자연어와 음성 인터페이스가 기존 입력 방식을 바꿀 가능성

• 선택형 입력 폼은 사람의 자연어 의도를 프로그램이 처리할 형식으로 바꾸는 중간 장치에 가깝다. 이런 폼이 사라지는 미래를 상상하지만, 실제로 실현 가능한지는 확신하지 않는다 [32:47]
• 음성으로 컴퓨터를 조작하면서 발화가 명령인지 입력할 텍스트인지, 텍스트를 어디에 넣을지 계속 판단하는 사례가 있다. 신뢰성을 보장할 수는 없지만, 비용과 속도를 개선하면 사용자 인터페이스가 크게 바뀔 가능성을 보여준다 [33:32]

18. 코드 작성 자동화에서 소프트웨어의 새 기능으로

• 대기업의 평균 PR이 약 10줄이라는 연구 경험을 근거로, 코딩 자동화가 기존의 작은 변경 작업을 빠르게 처리하는 데 머물 수 있다는 지적이 나온다. 작성 속도가 빨라져도 새로운 기능이나 품질 향상이 자동으로 따라오지는 않으며, 감독이 줄면 보안이 약해질 수 있다는 우려도 있다 [34:39]
• 자연어 이해와 추론을 상태 머신에 연결하면 애플리케이션에 새로운 기능을 부여할 수 있다. Jev의 비전은 타입 안전성의 성과를 확장하는 데 있지만, 그 성취를 미리 보장하지는 않는다 [35:29]

19. 쉬운 업무부터 자동화하며 시스템 설계를 다시 생각한다

• 항공 관제 같은 영역까지 가능성을 넓힐 수 있다는 생각과 함께, 어려운 일보다 쉬운 일을 먼저 자동화해야 한다는 원칙이 드러난다. 확률적 프로그래밍이나 신경·기호 결합 AI와 닮은 새 시대가 열릴 수 있다는 전망도 있다 [36:25]
• 생물학적 영감 자체보다는 실제 작동하는 공학적 구현을 중시한다. 지능의 수준마다 비용과 속도가 달라지면, 고도화된 시스템은 대략적인 추정으로 데이터의 처리 경로를 정하는 등 새로운 절충을 설계해야 할 것으로 본다 [37:44]

20. AI를 소프트웨어 전반에 연결하려면 자연어 출력의 한계를 넘어야 한다

• Jev의 적용 범위는 개별 앱이나 SaaS에 한정되지 않고 TCP 같은 기반 계층까지 염두에 둔다. 거의 모든 소프트웨어에 AI가 들어가는 미래를 출발점으로 삼기 때문에, 비용 대비 지능과 상위 계층으로의 확장을 중요하게 본다 [39:44]
• 기존 소프트웨어는 자연어를 직접 이해하지 못하며, JSON 출력과 스키마를 요구하는 방식만으로도 통합 문제가 해결되지 않는다는 지적이 나온다. 결국 출력을 사람에게 넘기거나 다른 언어 모델에 다시 전달하면서, 대화 또는 에이전트 반복 루프에 의존하게 된다 [40:19]

21. 신뢰성을 바탕으로 사용자가 의도한 대로 작동하는 기술

• 팀은 신뢰성을 중요하게 여겨 더 일찍 출시할 수 있었던 시점에도 출시를 서두르지 않았다. 사용자가 구현 세부를 이해하지 못하더라도 제품을 사용하며 믿을 수 있다고 느끼게 하는 것이 목표다 [41:25]
• 최종 지향점은 기술과 시스템이 서로 매끄럽게 연결되고 사용자의 의도대로 움직이는 것이다. “내가 뜻한 대로 해줘”라는 요구를 충족하는 기술이 원하는 AI 미래의 핵심으로 남는다 [42:02]

🧾 결론

• Jev의 제안은 자연어 이해와 추론을 프로그램의 상태 및 행동 선택에 연결해 자동화 범위를 넓히는 것이다.
• 사용자가 매번 호출하지 않아도 실행되는 시스템을 만들려면 일관된 판단, 구성요소 간 조합, 데이터와 자원 접근에 대한 안전 보장이 필요하다.
• 실용화는 투자 가치가 있는 쉬운 업무부터 시작할 수 있다. 모든 예외를 해결해야만 자동화의 성과를 인정할 수 있다는 입장은 아니다.
• 소개된 비전과 실제로 검증된 제품 역량은 구분해야 한다. 모든 응용에 적용할 준비가 됐는지, 강한 상태 일관성과 내구성까지 보장할 수 있는지는 열린 문제다.

📈 투자·시사 포인트

• SaaS 기업을 평가할 때는 코드 작성 비용과 함께 고객에 대한 지식, 기존 시스템과의 연결, 고객 확보 기반을 살펴볼 필요가 있다. 디오구는 이들이 AI의 수혜자가 될 가능성을 제시하지만 금융시장 예측은 유보한다.
• 자동화 제품의 처리율은 업무 구성과 함께 해석해야 한다. 반복되는 단일 문의의 처리량과 서로 다른 업무 유형을 해결하는 범위는 별도의 경쟁력이다.
• 자동화의 경제성은 절약하는 반복 작업과 구축에 투입하는 시간의 관계에 달려 있다. 비용 대비 지능과 처리 속도 중 무엇이 중요한지도 적용 업무에 따라 점검해야 한다.
• 신뢰성 향상은 로그·이메일 분석과 사용자 인터페이스 등 새로운 응용을 가능하게 할 수 있다. 다만 기대되는 활용 범위를 이미 달성한 성과로 평가해서는 안 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제공된 자료에는 Jev의 신뢰성을 정량적으로 검증할 벤치마크, 실패율, 반복 실행 결과가 제시되지 않는다. 높은 신뢰성은 제품의 핵심 지향점으로 설명된다.
• 상태 일관성·내구성처럼 강한 보장이 필요한 시스템에 적용할 수 있는지, 기대된 모든 애플리케이션을 지원할 준비가 됐는지는 확정되지 않았다.
• 헬프데스크의 95%와 약 50%는 과거 기업 사례에 대한 경험담이며 Jev의 성능 수치가 아니다. 코딩 모델의 설계 능력에 관한 비율도 개인적 평가다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복적이고 지시가 명확한 업무 하나를 선정하고, 현재 소요 시간과 자동화 구축에 필요한 시간을 비교한다.
• 처리 건수 기준 성공률과 업무 유형별 해결 범위를 나눠 기록해 단순 반복 업무의 편중을 확인한다.
• 동일한 작업에 무관한 정보나 표현 변화를 추가했을 때 기능적인 판단이 유지되는지 반복 검증한다.
• 자연어 의도를 어떤 상태와 행동에 연결할지 정의하고, 데이터·자원 접근에 필요한 안전 보장을 점검한다.

❓ 열린 질문

• Jev가 목표로 하는 일관된 판단 능력은 어떤 지표와 반복 실험으로 입증할 수 있을까?
• 현실의 드문 예외에 대응할 때 AI의 판단과 소프트웨어의 안전 보장을 어떻게 결합해야 할까?
• 기존 SaaS 기업의 고객 지식과 유통 기반은 실제 제품 개선과 경제적 성과로 얼마나 이어질까?