오늘날 LLM은 꽤 똑똑합니다. 하지만 기업의 자동화 시스템이 원하는 결과가 언제나 잘 쓴 문장은 아닙니다.
어떤 요청을 어느 팀으로 보내야 하는지, 이 거래를 사람이 확인해야 하는지, 에이전트가 수행한 작업을 승인해도 되는지 판단해야 할 때가 있습니다. 이때 필요한 것은 긴 설명보다 명확한 결정과 그 확률입니다.
지금까지는 이런 결정을 얻기 위해서도 거대한 LLM이 문장을 만들게 하고, JSON으로 바꾸고, 다시 프로그램이 해석하는 과정을 거쳤습니다. TypeSafe AI의 Jev는 여기에서 다른 질문을 던집니다.
사람에게 답하는 모델과 소프트웨어가 판단할 때 사용하는 모델은 다르게 만들어도 되지 않을까.
Jev는 문장을 생성하는 대신 미리 정의된 선택지와 확률을 반환합니다. 자세한 구조와 학습 방식은 아직 모두 공개되지 않았습니다. 그런데 Jev가 등장한 뒤 비슷한 문제를 풀려는 제품과 구현이 시장에 빠르게 늘어났습니다.
정확한 내부 구조를 알지 못해도 Jev가 무엇을 해결하려는지는 이해할 수 있었기 때문입니다. 중요한 것은 같은 모델을 복제하는 일이 아니라, 필요한 능력을 정의하고 이미 있는 기술로 그것을 구현하는 일이었습니다.
이 관점은 기업의 데이터와 온톨로지를 다루는 방식에도 그대로 적용할 수 있습니다.
기업에 들어가 모든 데이터를 먼저 연결하고, 모든 엔티티를 정의하고, 완전한 온톨로지를 만들기 시작하면 몇 달 뒤 이런 질문을 받기 쉽습니다.
그래서 이것으로 무엇을 할 수 있는가.
온톨로지가 필요하지 않다는 뜻은 아닙니다. 만드는 순서가 중요하다는 뜻입니다.
예를 들어 장애가 발생했을 때 영향을 받는 고객을 찾고, 원인을 추적하고, 담당자에게 대응을 요청하는 에이전트를 만든다고 해보겠습니다. 그러면 에이전트가 해야 할 일이 먼저 보입니다. 장애와 서비스의 관계를 확인하고, 영향을 받는 고객과 최근 배포 내역을 찾고, 서비스 담당자를 알아내야 합니다.
그다음에야 필요한 엔티티와 관계가 나타납니다. Incident, Service, Customer, Deployment, Team과 같은 정보가 필요한 이유가 생깁니다. 온톨로지는 전사 데이터를 설명하는 거대한 사전이 아니라, 에이전트가 일을 하기 위해 세상을 이해하는 방법이 됩니다.
데이터도 마찬가지입니다. 모든 데이터가 준비되었는지부터 확인할 필요는 없습니다. 에이전트가 특정 결정을 내리기 위해 어떤 정보가 필요한지를 먼저 물어야 합니다. 이미 있는 데이터는 연결하고, 없는 데이터는 외부에서 가져오거나 기존 기록에서 추출할 수 있습니다. 실제 사용 과정에서 새롭게 축적할 수도 있습니다.
좋은 데이터가 반드시 시스템을 만들기 전에 완성되어 있어야 하는 것은 아닙니다. 좋은 시스템을 만들고 사람들이 사용하면서 더 좋은 데이터가 생기기도 합니다.
Jev가 보여주는 것은 특정한 모델 구조보다 이런 문제 해결의 순서입니다. 원하는 결과를 먼저 정하고, 그 결과에 필요한 판단과 행동을 나눈 뒤, 필요한 모델과 데이터와 의미체계를 역으로 정의합니다.
모델과 데이터, 온톨로지는 목표가 아니라 문제를 풀기 위한 재료가 됩니다.
AI 시대에 더 중요해지는 능력도 여기에 있다고 생각합니다. 모든 것을 처음부터 만드는 능력보다, 원하는 상태를 정확히 정의하고 이미 존재하는 기술을 조합해 실제 업무 결과까지 도달하는 능력입니다.