2026년 9월 4주차 그래프 오마카세
[GUG 9th interview AD]
/
지난 7월 예정되었던 GUG 아홉 번째 인터뷰, Graph Research Labs의 Dougal Watt 님과의 만남을 다시 진행합니다. 당시에는 행사 직전 발생한 갑작스러운 사고로 아쉽게 일정을 연기해야 했습니다. 다행히 Dougal 님께서 잘 회복하셨고, 다시 세미나를 진행할 수 있다는 반가운 소식을 전해주셨습니다. 기다려주신 분들께도 감사드립니다.
“에이전트가 이해해야 할 업무의 개념과 관계는 어떻게 정의하고, 그 결과와 행동은 어떤 기준으로 검증할 수 있을까요?” 이번 세미나에서는 이 질문을 온톨로지 엔지니어링 관점에서 살펴봅니다.
주제는 ‘AI-Assisted Ontology Engineering: Guardrails and Workflows for Using LLMs Safely’입니다. 다음 3가지 콘텐츠들을 중점으로 세미나가 진행될 예정입니다.
① LLM은 온톨로지를 만들 때 어떤 실수를 할까요?
지나치게 복잡한 계층, 일관성 없는 분류, 중복된 속성 등 실제 모델링에서 발생하는 문제를 살펴봅니다.
② AI와 사람은 어떻게 함께 설계하고 검증할까요?
온톨로지가 답해야 하는 질문인 Competency Question을 정의하고, 사람이 변경 사항을 검토하며, SHACL과 추론기 등으로 반복 검증하는 과정을 다룹니다.
③ 온톨로지는 에이전트 운영에 어떻게 연결될까요?
Dougal 님이 제시하는 Skill → Plugin → Harness의 관점을 따라, 온톨로지와 제약 조건을 에이전트의 행동을 검증하고 통제하는 기준으로 활용하는 접근을 살펴봅니다.
온톨로지 관리부터 API·애플리케이션 생성, Semantic Agent Harness를 활용한 에이전트 제어까지 이어지는 GRL 도구 데모도 소개될 예정입니다. 저는 특히 “AI가 만든 온톨로지를 어떻게 신뢰할 수 있을까?”와 “검증한 온톨로지를 에이전트 운영에 어떻게 활용할까?”를 함께 이야기해보고 싶습니다.
최근 링크드인에서도 온톨로지 개념을 자사의 데이터 체계와 관리 방식에 접목하려는 시도들이 이전대비 많이 보이곤 하는데요. 이번 세미나가 이러한 고민을 구체적인 설계와 구현으로 이어가는 데 도움이 되었으면 합니다.
또한, 취업을 준비하며 포트폴리오를 만드는 분들께도 좋은 참고가 될 것 같습니다. 특히 고객의 업무와 문제를 이해하고 이를 실제 작동하는 시스템으로 구현하는 FDE(Forward Deployed Engineer) 역할에 관심이 있다면, 도메인 지식을 어떻게 데이터 구조로 표현하고 AI의 결과를 어떤 기준으로 검증할지 살펴보는 시간이 될 것입니다. 자신의 포트폴리오에 ‘왜 이렇게 설계했고, 어떻게 검증했는가’를 담고 싶은 분들도 함께해주시면 좋을거 같네요.
일시: 26년09월22일
장소 및 참여 방식: 온라인 구글밋
참가 신청: https://luma.com/vc71wrra
다시 마련한 자리에서 반갑게 뵙겠습니다. 감사합니다!
TypeSafe AI - Jev가 뜨는 이유는?
- 다음 주가 추석인 만큼 이번 주도 지루한(?) 논문 리뷰 대신 최근 많이 언급되고 있는, 9월 중순 TypeSafe AI가 공개한 Jev 모델에 대한 관련 영상과 데모 몇 가지를 함께 구경하는 시간으로 준비해봤습니다.
- Jev는 등장한 지 며칠밖에 되지 않았지만 꽤 빠르게 개발자들의 관심을 받고 있습니다. Vercel에 따르면 AI Gateway에 추가된 뒤 24시간 안에 유료 팀의 약 13%가 Jev를 사용했고, 이를 자사 Gateway 역사상 가장 빠르게 채택된 신규 모델이라고 소개했습니다. 물론 Vercel이라는 하나의 플랫폼 안에서 관찰된 초기 사용량이므로 전체 AI 시장의 점유율을 의미하는 것은 아니지만, 출시 직후의 관심도를 보여주는 사례로는 꽤 흥미롭습니다.
- 이것을 둘러싼 여러 분석자료들이 나오고 있는데 대체로 단순히 좋은 새 LLM 모델이 나왔다는 것 이상으로 LLM이 지금까지 해오던 일 중 일부를 굳이 언어 생성으로 풀 필요가 있느냐는 색다른 질문에서 시작되었다고 합니다.
JEV Breakdown: The First AI Model Built For Code
- 보통 AI 모델을 사용한다고 하면, 사용자가 무언가를 입력하고 모델이 토큰을 하나씩 생성해 문장 형태의 답을 반환하는 모습을 먼저 떠올립니다. 하지만 실제 소프트웨어 안의 모든 문제에 긴 문장 형태의 출력이 필요한 것은 아닙니다. 때로 우리에게 필요한 것은 설명문이 아니라 짧고 명확한 결정일 수도 있습니다. TypeSafe의 Jev는 바로 이런 종류의 문제를 겨냥합니다.
- TypeSafe는 Jev를 첫 번째 System One Model이라고 소개합니다. 자연어 문장을 생성하는 대신, 주어진 상태에 대해 미리 정의된 질문을 평가하고 typed decision과 probability를 반환하도록 설계했습니다. 공식적으로는 Choice, Score, Noul이라는 세 가지 질문 형태를 지원하며, 하나의 입력에 대해 여러 질문을 동시에 평가할 수도 있습니다.
- 아주 단순화해서 비교하면 기존 LLM 기반 workflow가
입력 → 추론 → 문장 생성 → JSON 파싱 → 프로그램 사용
에 가까웠다면, Jev는 입력 → 선택 / 점수 / 확률 → 프로그램 사용
으로 한 단계를 압축하는 접근에 가깝습니다. TypeSafe가 Jev를 frontier-intelligence function call이라고 표현하는 이유도 여기에 있습니다. - Choice, Score, Noul이 실제 Playground에서 어떻게 동작하는지 빠르게 보고 싶다면 해당 영상이 가장 이해하기 쉽습니다. 10분 정도만 보셔도 Jev가 일반적인 Chat LLM과 무엇이 다른지는 금방 감을 잡으실 수 있을 것 같습니다.
Meet Jev: The AI Built to Make Decisions
- Jev와 관련해 가장 많이 언급되는 부분은 역시 속도와 비용입니다. TypeSafe는 자체 workflow evaluation에서 기존 LLM 대비 최대 193.6배 빠르고 444.6배 저렴한 결과를 보고했습니다. 다만 이 수치는 모든 AI 작업에 그대로 적용되는 결과라기보다, 답의 범위가 미리 정해진 classification·routing·scoring 등의 문제를 대상으로 한 TypeSafe 측 평가라는 점은 함께 볼 필요가 있습니다.
- 그래도 왜 이런 속도 차이가 발생할 수 있는지에 대한 아이디어 자체는 꽤 직관적입니다. 긴 문장을 토큰 단위로 생성한 뒤 다시 필요한 정보를 추출하는 대신, 처음부터 필요한 선택이나 점수만 반환한다면 그만큼 생성 과정의 비용을 줄일 수 있기 때문입니다.
- 위 영상에서는 이를 이메일 분류 예제로 보여줍니다. 다양한 이메일을 Jev로 처리하면서 카테고리, 우선순위, 스팸 여부, 답장이 필요한지 여부 등을 동시에 판단합니다. 영상에서 평균 응답 시간은 약 200ms 수준으로 관찰되며, 마지막에는 실제 API 비용까지 확인할 수 있습니다.
Browser Use - Jev-ultrafast Github
browser-use
Gregor Zunic
- Jev를 실제 브라우저 Agent에 적용한 Jev-ultrafast 저장소도 흥미로운 사례입니다. 개인적으로는 여기에서 Jev가 앞으로 어떤 방식으로 활용될 수 있을지가 가장 잘 드러난다고 생각합니다.
- 에이전트가 하나의 작업을 수행하는 과정을 생각해보면 실제로는 수많은 작은 결정을 반복합니다. 사용자의 요청을 어느 Agent에게 넘길지, 어떤 Tool을 호출할지, 화면에서 어떤 element를 선택할지, 계속 진행할지 혹은 작업을 종료할지 등을 매 단계 판단합니다. 상당수는 대체로 현재 상태에서 주어진 후보 하나를 고르는 문제에 가깝습니다.
- Jev-ultrafast에서는 브라우저의 현재 상태를 보고 Jev가 다음 action과 대상 element를 선택하고, 실제 텍스트 생성이 필요한 순간에만 별도의 생성 모델을 사용합니다. 즉 하나의 LLM에 모든 역할을 맡기기보다 결정과 생성을 서로 다른 모델에 나누어 맡기는 구조입니다.
- README 상단의 영상만 보셔도 꽤 재미있습니다. 화면을 확인한 뒤 긴 reasoning을 생성하는 방식보다는, 매 순간 가능한 action 가운데 하나를 빠르게 선택하며 브라우저를 이동합니다.
- 실제로 Google Flights에서 London 항공편을 찾는 공개 데모는 약 7.1초에 완료됐고, 저장소에 공개된 작은 비교 실험에서는 동일한 하나의 항공편 검색 작업을 각각 세 차례 수행했을 때 median runtime이 9.450초에서 7.092초로 줄었습니다. 다만 개발자들도 명시하듯 하나의 task, 하나의 browser profile에서 수행한 소규모 실험이기에 일반적인 벤치마크 결과로 바라보긴 어렵습니다. 가볍게 데모 정도로 보는 편이 적절할 것 같습니다
- 여기까지 보면 LLM 대신 뜨겁게 떠오르는 Jev를 쓰면 되나? 라는 생각이 들 수 있을 것 같습니다. 하지만 아직 그렇게 보기에 이르다는 자료들도 존재합니다.
- Jev가 이제 막 공개된 모델이기도 하고, TypeSafe가 공개한 자료에서도 arithmetic, counting, date reasoning, multi-hop reasoning처럼 잘하지 못하는 영역이 명시되어 있습니다. 또한 입력에 관련 없는 정보가 많아질수록 정확도가 떨어지거나, 질문의 표현 방식에 따라 결과가 달라질 수 있다는 한계도 있습니다.
- Jev 1.13 공식 limitations 문서는 Jev가 잘하는 영역을 System One task, 즉 빠른 semantic judgment로 한정합니다. 반대로 숫자 계산, 날짜 비교, multi-hop indirection, 불필요하게 긴 context 등에 약점이 있다고 직접 밝히며, 가장 마지막 failure mode인 Generation에서는 아예 텍스트 생성이 필요하면 generative model을 사용하라고 안내합니다.
- 또한 TypeSafe의 출시 글에서도 Jev는 classify, route, score, extract, branch 같은 AI-powered workflow의 decision rule에 초점을 둔다고 구분합니다. 즉 공식 포지셔닝부터 기존 LLM을 모두 Jev로 갈아끼운다가 아니라 역할이 다른 모델을 조합한다에 가깝습니다.
- 최근 Agent 시스템이 커지면서 하나의 거대한 모델에 모든 판단을 맡기기보다는 routing, memory, planning, generation, verification을 각각 다른 구성 요소로 분리하려는 흐름이 계속 등장하고 있습니다. 그런 관점에서 보면 Jev도 단순히 빠른 새로운 AI 모델이라기보다, Agent 안에서 결정과 생성을 어디까지 분리할 수 있을까? 라는 관점으로 바라보는 편이 더 흥미롭지 않을까 싶습니다.
[Contact Info]
Gmail: jhbae1184@akane.waseda.jp
Twitter (X): @jhbae1184