Jev 이후의 다음 단계? Metacache: 구성(Construction)을 통한 추론

Jev는 AI 산업에 깊은 흔적을 남겼습니다. 이 글은 앞으로 무엇이 올지 엿볼 수 있게 해줍니다. Jev는 업계가 어느 방향으로 나아가고 있는지 보여줍니다. 즉, 거대한 단일 모델(monolithic models)에서 벗어나, 작고 개별적인 AI 에이전트들이 각각 좁은 작업을 수행하고 오케스트레이션 레이어(orchestration layer)가 이들이 어떻게 함께 작동할지 결정하는 복합 시스템(compound systems)으로 나아가고 있다는 것입니다. 이 글은 왜 그러한 변화가 일어나고 있는지 설명하고, 이후 AI 추론을 위한 다음 단계를 제안합니다.

요약하자면, 단일 모델은 예측하기 어렵고 변경하기 힘들지만, 훈련 과정에서 스스로 프로그래밍됩니다. 코드는 그 반대입니다. 예측 가능하고 변경하기 쉽지만, 명시적으로 작성되어야 합니다. 복합 시스템은 이 둘을 결합합니다. AI 에이전트가 작업을 수행하고 오케스트레이션 레이어가 코드를 통해 이를 제어합니다. 이것이 Jev가 대표하는 방향입니다.

다음 단계는 다음과 같습니다. 모델이 직접 답을 내놓는 대신, 복합 시스템을 구성하고(builds), 이를 실행한 다음, 답변과 함께 그 시스템 자체를 반환하는 것입니다. 이렇게 반환된 시스템을 reasonlet이라고 부릅니다. 반환된 reasonlet은 로컬에 보관될 수 있기 때문에, 모델에게 다시 요청하지 않고도 새로운 입력으로 또는 코드를 편집하여 반복적으로 실행할 수 있습니다. 저장되고 재사용 가능한 reasonlet이 바로 metacache입니다. 모델 제공자(provider)는 또한 compute를 절약하기 위해 여러 사용자로부터 온 유사한 요청에 대해 reasonlet을 캐시하고 재사용할 수도 있습니다.

왜 단일 모델만으로는 충분하지 않은가

단일 모델은 두 가지 실질적인 약점을 가지고 있습니다. 첫째, 예측 불가능합니다. 같은 질문이라도 어느 날은 정확한 답변을 내놓고 다음 날은 잘못된 답변을 내놓을 수 있어, 그 동작을 완전히 통제할 수 없습니다. 둘째, 변경하기 어렵습니다. 그 동작이 훈련 가중치(trained weights)에 고정되어 있어 직접 편집할 수 없습니다. 모델의 행동은 프롬프트, 추가 데이터(RAG), 또는 파인튜닝(fine-tuning)으로 유도할 수 있지만, '유도하는 것'과 '행동을 설정하는 것'은 같지 않으며, 파인튜닝은 이미 작동하던 것을 망가뜨릴 수도 있습니다. 새로운 데이터로 처음부터 재훈련하는 것이 유일하게 안전한 해결책이지만, 시간 소모적이고 비용이 많이 듭니다.

코드는 정반대의 특성을 가집니다. 코드가 작성된 대로 정확히 동작하며, 코드 편집을 통해 쉽게 변경될 수 있습니다.

트레이드오프는 코드가 저절로 발생하는 것이 아니라 명시적으로 작성되어야 한다는 점입니다. 반면, 모델은 훈련 과정에서 스스로 프로그래밍됩니다. 해결책: 복합 시스템(compound system)이 이 두 가지를 결합합니다. 작업은 여러 AI 에이전트들에게 분배되며, 각 에이전트는 하나의 좁은 작업을 처리하고, 오케스트레이션 레이어의 코드가 어떤 에이전트를 실행할지, 어떤 순서로 실행할지, 그리고 그 결과들을 어떻게 조합할지를 결정합니다. 이를 통해 맞춤화(customization)와 예측 가능성(predictability)이라는 두 가지 특성을 동시에 얻을 수 있습니다. 맞춤화 측면에서, 시스템의 동작은 모델을 재훈련하는 것이 아니라 오케스트레이션 레이어의 코드를 편집함으로써 변경될 수 있습니다. 예측 가능성 측면에서는, 각 에이전트가 작은 작업을 수행하기 때문에 거대한 단일 모델(monolithic model)보다 더 예측 가능합니다. Jev는 이러한 시스템을 위한 한 종류의 에이전트입니다. 이는 자유 텍스트 대신 유형화된 결정(typed decision)—예/아니오, 카테고리, 또는 숫자—을 반환합니다. 그러한 좁은 결정에 거대한 단일 모델은 비효율적이지만, Jev와 같은 작은 모델이 더 적합합니다. 다음 단계: 구성(construction)을 통한 추론 오늘날의 복합 시스템은 미리 수동으로 구축됩니다. 다음 단계는 모델이 추론 과정 중에 스스로 하나를 구축하도록 하는 것입니다. 연구자들은 모델이 추론할 수 있도록 만드는 여러 방법을 탐구하고 있습니다. 그중 하나는 '월드 모델(World model)' 접근 방식인데, 이 경우 모델이 문제에 대한 내부 표현을 구축하고 그 위에서 추론합니다. 이 작업은 아직 대부분 연구 단계에 머물러 있습니다. 구성적 추론(Reasoning by construction)은 오늘날 존재하는 방법들을 사용하여—검사 가능한 추론(reasoning you can inspect)—동일한 목표를 추구합니다. 작동 방식은 다음과 같습니다. 모델에게 질문을 하면, 모델은 직접적으로 답변하지 않습니다. 대신, 복합 시스템을 구축하고 그것을 실행하여 답을 계산하며, 그 답과 함께 자신이 구축한 시스템도 반환합니다. 모델이 추론을 위해 구축하는 이 복합 시스템을 '리즌렛(reasonlet)'이라고 부르고, 이런 방식으로 작동하는 모델을 '구성적 추론 모델(Reasoning-by-Construction Model)', 또는 'RCM'이라고 합니다. 간단한 질문은 오직 오케스트레이션 레이어만 있고 에이전트는 없는 리즌렛을 생성할 수도 있습니다. 답에 도달하기 위해 코드를 구축하고 실행하는 것은 새로운 일이 아닙니다. 코드 인터프리터(code-interpreter) 도구들이 이미 이를 수행하고 있습니다.

여기서 새로운 두 가지가 있습니다. 모델이 구축한 시스템을 버리지 않고 유지한다는 점입니다. 즉, 재사용 가능한 reasonlet(추론 과정)이 됩니다. 이 reasonlet은 답변과 함께 사용자에게 반환됩니다. 이것이 왜 중요하냐면, 답변이 어떻게 도출되었는지 확인할 수 있기 때문입니다. reasonlet은 모델이 사용한 정확한 절차이므로, 답변을 무조건 신뢰할 필요가 없습니다. 로컬에서 실행해 볼 수 있습니다. reasonlet에는 오케스트레이션 레이어(orchestration layer)와 호출하는 모든 에이전트(agent)가 포함됩니다. 이 에이전트들이 직접 연결되어 있든 네트워크를 통해 호출되든 상관없습니다. 따라서 모델에게 다시 요청할 필요 없이, 동일하거나 다른 입력을 사용하여 로컬 머신에서 실행할 수 있습니다. 이렇게 저장된 reasonlet은 metacache(메타캐시)입니다. 사용자가 이것을 변경할 수 있습니다. 오케스트레이션 레이어는 코드이므로, 입력뿐만 아니라 그 논리 자체를 편집할 수 있습니다. 수정된 논리로 재사용되는 reasonlet은 higher-order metacache(고차원 메타캐시)가 됩니다.

서버에서 reasonlet 캐싱하기
같은 재사용이 서버 측에서도 일어날 수 있습니다. 제공업체는 자신이 구축한 reasonlet을 보관하고 재사용할 수 있습니다. 이미 처리했던 것과 일치하는 새로운 요청이 도착하면, 처음부터 추론하는 대신 저장된 reasonlet을 새로운 요청의 입력으로 다시 실행합니다. 모델은 적은 작업을 수행하게 되고, 답변은 더 빠르게 돌아옵니다. 이것이 바로 사용자의 기기가 아닌 서버에 보관된 metacache입니다. 하나의 reasonlet이 그 절차에 맞는 모든 요청을 처리할 수 있기 때문에, 단일 캐시 복사본이 여러 요청, 그리고 종종 다른 사용자들에게 공유됩니다. reasonlet이 일반적일수록 더 많은 요청을 포괄합니다.

reasonlet의 일반성 결정하기
모델은 대화 내용을 통해 reasonlet이 얼마나 일반적이어야 할지 스스로 결정해야 합니다. 만약 다양한 종류의 수학 문제를 풀다가 2 + 2를 요청한다면, 두 숫자만 더할 수 있는 reasonlet보다 모든 수학 표현식을 평가할 수 있는 reasonlet이 더 유용합니다. 만약 대화가 그러한 단서를 제공하지 않는다면, 사용자 스스로 직접 명시할 수 있습니다: “저는 다양한 종류의 수학을 할 것입니다. 지금은 2와 2를 더하는 것만 하세요.”

두 가지 예시
숫자 더하기. 2 + 2를 요청합니다.

모델은 두 숫자를 더하는 오케스트레이션 레이어를 가진 리즌릿(reasonlet)을 구축하고, 이를 실행한 후 그 결과와 함께 리즌릿을 반환합니다. 나중에 다른 숫자들로 리즌릿을 다시 실행하거나, 모델에게 요청하지 않고도 오케스트레이션 레이어를 곱셈으로 수정할 수 있습니다. 검색의 경우, 모델에게 무언가를 찾도록 요청합니다. 이때 리즌릿의 오케스트레이션 레이어는 일련의 외부 서비스들을 호출하고 사용자의 검색 용어를 입력값으로 받습니다. 나중에 다른 용어로 실행하거나, 모델에게 다시 요청하지 않고도 어떤 서비스를 호출할지 변경할 수 있습니다. 리즌릿을 읽기 쉽게 만드는 리즌릿의 오케스트레이션 레이어는 텍스트 코드로 작성됩니다. 이는 문제를 야기합니다: 추론 과정을 이해하려면 코드를 읽어야 하고, 수정하려면 코드를 작성해야 합니다. 리즌릿을 반환하는 가치는 사용자가 텍스트 코드를 쉽고 효율적으로 읽고 편집할 수 있는지에 달려 있으므로, 이 장벽이 중요합니다. 시각적 프로그래밍(Visual programming)은 텍스트 줄 대신 연결된 블록으로 로직을 구축함으로써 이러한 장벽을 낮출 수 있지만, 시각 언어 자체가 충분히 강력해야 합니다.

마무리하며 거대한 단일 모델에서 복합 시스템으로의 전환은 추론에 대한 명확한 다음 단계를 시사합니다: 모델이 복합 시스템, 즉 리즌릿을 구축하고, 이를 실행하여 답과 함께 리즌릿 자체를 반환하도록 하는 것입니다. 추론 과정은 읽고, 다시 실행하고, 수정할 수 있는 것이 됩니다: 메타캐시(metacache)이며, 논리가 편집된 후에는 상위 수준의 메타캐시(higher-order metacache)가 됩니다. 남아있는 문제는 리즌릿을 읽고 변경하기 쉽게 만드는 것인데, 이때 범용적이고 표현력이 풍부한 시각 언어가 가장 큰 도움이 될 것입니다.

IP에 대한 참고 사항 본 기사에서 설명된 일부 방법들은 출원 중인 특허의 대상입니다. /u/PurpleDragon99가 제출했습니다 [링크] [댓글]}**