TL;DR

  • Jev를 계기로 기업 안에서 AI를 실제로 운영하는 AI Ops Engineering은 모든 일을 대형 언어 모델(LLM)에 맡기는 대신, 결정의 종류와 규모에 따라 지능을 배치하는 시스템 설계임.
  • Jev는 텍스트를 생성하지 않고 상태를 바탕으로 구조화된 판단을 내리는 모델로, 생성보다 판단이 중요한 업무에 적합함.
  • 결정적 소프트웨어, 가벼운 판단 모델, LLM, 에이전트, 사람을 각자의 역할에 맞춰 조합하는 아키텍처가 필요함.
  • 기업의 작은 결정이 대규모로 쌓이면 지연 시간, 비용, 관측 가능성, 신뢰성, 평가와 실패 대응이 핵심 엔지니어링 과제가 됨.
  • AI를 제대로 운영하는 기업은 가장 큰 프롬프트나 가장 많은 에이전트가 아니라 여러 지능 요소를 신뢰할 수 있는 시스템으로 결합하는 기업임.

AI Ops는 에이전트만의 문제가 아님

  • 최근 AI Ops Engineering을 많이 생각하고 있음. 이는 MLOps나 모델 호스팅 관점의 ‘AI 인프라’, 또는 에이전트 구축만을 뜻하지 않음.
  • 모델을 비즈니스 시스템에 연결하고, 적절한 맥락을 제공하며, 허용할 작업을 정하고, 사람·에이전트·소프트웨어 사이에서 작업을 라우팅하고, 결과를 측정하며, 실패를 처리하고, 결정마다 어떤 지능을 사용할지 정하는 기업 내 AI 운영 엔지니어링을 의미함.
  • 지금의 한 가지 실수는 모든 AI 시스템의 중심에 LLM을 두는 것임. Claude나 GPT에 여러 도구를 연결하고 맥락을 넣은 뒤 모든 일을 해결하도록 맡기는 방식은 작동하지만, 가장 비싸고 유연한 구성 요소가 분류, 라우팅, 점수화, 우선순위 지정, 위험 감지, 에스컬레이션, 작성, 추론, 계획, 도구 사용까지 전부 처리하게 됨.
  • AI Ops의 목표는 모든 곳에 LLM을 두는 것이 아니라 올바른 시스템을 구축하는 것임.

Jev는 역할 분리를 요구하는 점에서 흥미로움

  • Jev를 처음 살펴봤을 때 눈에 띈 점은 텍스트를 생성하지 않는다는 것임. 상태를 제공하고 초점을 좁힌 질문을 하면 소프트웨어가 사용할 수 있는 구조화된 결정을 내림.
  • 이는 LLM보다 훨씬 작은 역량이며, 바로 그 점이 흥미로움. 조직 안의 많은 업무는 생성 문제가 아니라 판단 문제임.
  • 티켓을 에스컬레이션할지, 고객이 이탈 조짐을 보이는지, 잠재 고객을 영업팀에 전달할 가치가 있는지, 중요한 변화가 있었는지, 사람의 승인이 필요한지 등을 판단하는 일이 이에 해당함.
  • 이런 일에 LLM을 쓰는 이유는 LLM이 충분히 잘하기 때문이지만, ‘모델이 할 수 있음’과 ‘그것이 올바른 아키텍처임’은 서로 다른 질문임.

자체 시스템의 사례

  • 업무에서 티켓 분류 워크플로를 운영함. Claude가 티켓을 받고 맥락을 모아 상황을 파악하며, 문제 분류, 에스컬레이션 여부 결정, 에스컬레이션 메모 작성, 추론 설명, 답변 초안 작성까지 수행함.
  • 이 가운데 일부 작업에는 생성형 모델이 분명히 필요하지만, 분류는 그렇지 않은 대표 사례임.
  • 필요한 결과가 문제 유형, 긴급도, 제품 영역, 에스컬레이션 여부, 신뢰도라면 Claude가 무언가를 생성할 필요가 없음. 필요한 것은 판단을 내리는 소프트웨어임.
  • 이 차이는 작아 보이지만 AI Ops Engineering의 근본적인 구분임.

달라지는 아키텍처

  • 기존의 ‘LLM이 모든 것을 처리’하는 구조에서 다음과 같은 구성으로 옮겨갈 수 있음.
  • 데이터 → 결정 모델 → 결정적 워크플로 → 필요할 때 LLM → 필요할 때 사람
  • 각 구성 요소는 서로 다른 일을 맡음. 명확하게 정의할 수 있는 일은 결정적 소프트웨어가 처리하고, Jev 같은 모델은 빠른 확률적 판단을 맡으며, LLM은 개방형 추론·생성·상호작용을 담당함.
  • 에이전트는 도구와 워크플로 사이의 조정을 맡고, 판단·책임·모호성 때문에 필요한 경우 사람을 절차에 포함함.
  • AI Ops Engineering의 핵심 질문은 ‘가장 똑똑한 에이전트를 어떻게 만들까?’가 아니라 ‘지능을 둘러싼 운영체제를 어떻게 설계할까?’임.

코드와 LLM 사이의 빠진 계층

  • 전통적인 소프트웨어는 ‘조건이 x면 y’와 같은 결정적 규칙을 제공하고, LLM은 ‘복잡한 상황을 보고 무엇을 할지 판단’하는 전혀 다른 능력을 제공함.
  • 두 방식 사이에는 큰 영역이 있음. 예를 들어 제품 사용량이 줄고, 고객이 지원 티켓을 여러 건 열고, 갱신 시점이 다가오며, 통화에서 가격 우려가 언급된 계정은 사람이 ‘위험에 처했을 수 있다’는 감을 형성할 수 있음.
  • 이를 결정적 규칙으로 작성하면 복잡해지지만, 변화가 생길 때마다 대형 LLM을 호출하는 방식도 과도해 보임.
  • Jev를 통해 분명해진 중간 계층은 기계 추론까지는 필요하지 않더라도 기계 판단이 필요한 기업 내 수많은 지점임.

AI Ops가 대규모로 작동할 때의 중요성

  • 분류 호출 하나나 이탈 위험 확인 하나는 큰 문제가 아닐 수 있지만, 조직에는 고객, 티켓, 잠재 고객, 통화, 제품 이벤트, 청구서, 워크플로, 에이전트 작업마다 작은 결정이 가득함.
  • AI가 이 모든 시스템에서 작동하기 시작하면 결정의 수가 막대해지며, 지연 시간·비용·관측 가능성·신뢰성이 훨씬 중요해짐.
  • 이 지점에서 AI Ops는 프롬프트 작성 문제가 아니라 엔지니어링 문제가 됨. 어떤 결정에 LLM이 필요한지, 더 작은 결정 모델로 처리할 수 있는지, 코드만으로 충분한지, 언제 사람에게 에스컬레이션할지, 결정 품질을 어떻게 측정할지, 신뢰도가 낮을 때 어떻게 대응할지, 워크플로 실행 이유를 어떻게 추적할지, 시간이 지나며 시스템을 어떻게 개선할지 물어야 함.
  • 모델은 시스템의 한 구성 요소일 뿐임.

에이전트는 역할 분리를 더 중요하게 만듦

  • 에이전트는 기계의 결정을 줄이는 것이 아니라 늘릴 것임. 기업 안에서 HubSpot, PostHog, 지원 티켓, 통화, 내부 문서, 제품 데이터에 접근하는 에이전트는 의미 있는 작업 하나를 수행하기 전에 수십 가지 작은 결정을 내릴 수 있음.
  • 관련성이 있는지, 변화가 있었는지, 정보를 더 가져와야 하는지, 이례적인 상황인지, 위험한지, 작업을 자동으로 실행할 수 있는지, 승인이 필요한지, 어떤 워크플로를 호출할지 등을 판단해야 함.
  • 현재는 이런 판단을 모두 주 LLM에 맡기는 경우가 많지만, 최종 아키텍처가 그렇게 되지는 않을 것이라고 점점 확신함.
  • 주 추론 모델이 시스템 안의 모든 작은 판단을 수행해서는 안 되며, AI Ops Engineering의 일부는 결정을 분해해 적절한 위치에 배치하는 일임.

흥미로운 문제는 오케스트레이션임

  • 핵심 엔지니어링 과제는 Claude와 GPT와 Gemini 중 하나를 고르거나 모든 일을 해낼 단일 모델을 찾는 것이 아니라, 서로 다른 유형의 지능을 조율하는 일임.
  • 구성 요소는 SQL과 일반 코드의 결정적 논리, Jev와 같은 모델의 가벼운 판단, LLM의 추론과 생성, 다단계 실행을 맡는 에이전트, 영향력이 큰 결정의 사람 검토로 나뉠 수 있음.
  • 이를 연결하는 인프라에는 맥락, 권한, 관측 가능성, 평가, 대체 경로, 승인, 상태, 트리거, 피드백 루프가 필요함.
  • 이 계층이 AI Ops Engineering의 의미임.

Jev는 더 큰 변화의 한 사례임

  • Jev 자체가 얼마나 중요해질지는 아직 알 수 없음. 아직 초기 단계이며, 데모만 보고 결론을 내리기보다 실제 워크플로에서 시험하고자 함.
  • 모델 자체보다 더 흥미로운 것은 그 뒤의 아키텍처 아이디어임. 지난 몇 년간 소프트웨어에 지능이 필요할 때 주로 ‘LLM을 추가하자’고 답했지만, AI Ops Engineering에는 ‘시스템의 이 부분에 실제로 어떤 종류의 지능이 필요한가?’라는 더 성숙한 답이 필요함.
  • 어떤 경우에는 Claude가, 어떤 경우에는 에이전트가, 또 어떤 경우에는 Jev 같은 모델이 적합하며, 상당수 경우에는 여전히 코드가 적합함.
  • AI를 제대로 구현하는 기업은 가장 큰 프롬프트나 가장 많은 에이전트를 보유한 기업이 아니라, 이 모든 요소를 신뢰할 수 있는 시스템으로 결합하는 방법을 익히는 기업일 가능성이 큼.