인공지능이라는 오케스트라 이끄는 지휘자는? [인공지능 오디세이]
거대 언어모델(Large-scale Language Model·LLM)이 빠르게 발전하면서 단순히 문장을 생성하거나 질문에 답하는 데 그치지 않고 더 복잡한 작업을 맡길 수 있는 ‘에이전트(agent)’가 주목받고 있다. 여기에서 에이전트란 LLM 혼자서는 풀기 어려운 문제들을 외부 도구(검색, 데이터베이스, API 등)와 연동해 스스로 해결하는, 일종의 “자율 실행 AI 시스템”을 의미한다. 이번 글에서는 에이전트의 구성 요소를 중심으로 어떻게 동작하는지 살펴보겠다.
최근 널리 사용되고 있는 에이전트 시스템은 크게 모델(LLM), 도구(tool), 메모리(memory), 그리고 이들을 총괄하는 오케스트레이션 레이어(orchestration layer)로 구성된다(〈그림 1〉 참조). ‘모델(LLM)‘은 텍스트 이해와 생성을 담당한다. ‘도구‘는 검색 API, 데이터베이스 질의, 날씨 조회, 결제 시스템 호출 등 모델이 스스로 얻기 힘든 정보를 확보하는 역할을 맡는다. ’메모리’는 현재 대화 맥락(단기)과 과거 대화 이력, 사용자 선호·취향(장기) 등을 저장해두는 영역이다. ’오케스트레이션 레이어’는 마치 오케스트라의 지휘자처럼 “언제, 어떤 도구·메모리를 사용하고, 그 결과를 어떻게 LLM에 반영해 답변을 완성할지”를 결정하고 지휘한다.
LLM은 사전·사후 학습과 운영 과정에서 각각 문맥 이해(In-Context Learning)와 지시 수행(Instruction Following), 단계적 사고(Chain-of-Thought) 능력을 획득한다. 이전 회에서 언급했듯 모델은 이런 역량을 바탕으로 검색 결과나 함수 호출 결과 같은 정보를 추가로 프롬프트에 주입받으면 훨씬 정확하고 풍부한 답변이 가능해진다(〈시사IN〉 제909호 ‘현직 개발자가 알려주는 LLM 제대로 사용하기’ 기사 참조). 이 과정을 증강(augmentation)이라고 하며, 에이전트 시스템에서는 오케스트레이션 레이어가 “어떤 도구·메모리로부터 언제 정보를 받아 모델에 전달할지”를 제어하면서 구현된다.
내 취향 어떻게 알았지?
이전 회에서는 이해를 돕기 위해 외부 정보(예: 주말 서울 실내 체험공간 검색 결과, 날씨 API 호출 결과)가 이미 확보된 상태에서, LLM이 이를 활용해 답변하는 과정을 살펴봤다. 이번에는 ‘식당 예약’이라는 상황에서, 오케스트레이션 레이어가 어떻게 외부 정보를 확보하고 이를 LLM에 전달하는지 구체적으로 알아보겠다. 예컨대 사용자가 “다음 주 금요일 저녁 7시에 한식당을 예약하고 싶은데, 주차가 편한 곳을 찾아줘”라고 요청했다고 가정해보자.
오케스트레이션 레이어는 여러 방식으로 구현할 수 있다. 최근 각광받는 접근법 중 하나는 리액트(ReAct, Reasoning+Action)다. 리액트는 “생각(추론)→행동(검색, 함수 호출 등)→관찰(결과 확인)” 과정을 반복하며 에이전트가 의사결정을 차근차근 수행하도록 유도한다. 식당 예약 상황이라면 먼저 한식당을 검색한 다음, 그 결과를 보고 주차 가능 여부나 예약 상태를 다시 한번 확인하고, 최종적으로 예약 가능한 식당을 골라 예약 API를 호출하는 식이다(〈그림 2〉 참조).
복잡한 과제의 경우 고도의 추론·계획 능력이 필요하기 때문에 오케스트레이션 레이어 역시 LLM을 중심으로 구성하는 경우가 일반적이다. 오케스트레이션 레이어가 최종적으로 확보한 예약 정보는 모델에 넘겨서 답변하도록 한다.
이런 방식으로 추론 단계가 명시적으로 드러나면 모델이 언제 어떻게 의사결정을 했는지 추적하기 수월하다. 게다가 중간 과정에서 ‘메모리’를 활용해 사용자 취향이나 과거 이력을 참조하면 “사용자가 이전에 선호했던 매운 음식”이나 “회사 근처 식당을 선호한다” 같은 정보를 놓치지 않을 수 있다. 오케스트레이션 레이어가 수집한 예약 완료 정보 등은 최종적으로 모델(LLM)에 전달되고, 모델은 이 같은 내용을 바탕으로 예약 성공 여부와 세부 내용을 사용자에게 답변한다.
최근에는 한 개의 LLM에만 의존하지 않고 여러 모델을 조합해 사용하는 ‘멀티 LLM’ 방식도 늘고 있다. 예컨대 대형 모델에 더해 요약·번역·분석 같은 특정 분야에 특화된 소형 모델들을 함께 운용한다. 멀티 LLM 접근은 각 모델이 지닌 장점을 극대화하고 약점을 상호 보완해 더욱 정밀하고 풍부한 에이전트 시스템을 구현하는 데 도움이 된다. 다만 모델이 여러 개일수록 “어떤 모델에 어떤 작업을 맡길지”를 결정하는 선택 로직이 복잡해지는데, 이 또한 오케스트레이션 레이어가 맡아, 모델별 특성과 메모리 정보를 종합적으로 고려해 최적의 모델을 할당한다.
2024년 말부터는 에이전트형 서비스들이 급속도로 보급되면서, 일반 사용자들도 다양한 형태의 ‘에이전트’를 손쉽게 활용할 수 있게 되었다. 예컨대 오픈AI의 딥리서치(Deep Research)나 퍼플렉시티(Perplexity)는 검색 엔진을 활용해 사용자가 제시한 주제에 대해 비교적 짧은 시간 안에 깊이 있는 연구 보고서나 통찰을 제공하도록 설계되어 있다. 앤스로픽의 컴퓨터 유즈(Computer Use)와 오픈AI의 오퍼레이터(Operator)는 사용자의 컴퓨터 환경(파일 시스템, 프로그램 등)이나 웹 브라우저와 단계적으로 상호작용함으로써 필요한 정보를 찾고 후속 작업까지 수행한다. 각 회사에서 내부 구현 상세를 공개하지는 않았지만, 대체로 ‘모델(LLM)+도구(검색, API, 시스템 액세스 등)+메모리(대화 맥락 및 사용자 이력)+오케스트레이션 레이어(작업 흐름 제어)’라는 구조를 갖추고 있을 것으로 보인다.
특히 중국의 AI 스타트업 모니카는 자사 에이전트 시스템 ‘마누스(manus)’가 에이전트 성능을 측정하는 ‘GAIA 벤치마크 테스트’에서 최고 기록을 세워 오픈AI의 딥리서치를 앞섰다고 이달 초 주장해 눈길을 끈다. 마누스 역시 ‘모델+도구+메모리+오케스트레이션 레이어’ 구성인 것으로 보인다. 업계에서는 모니카가 오픈AI, 앤스로픽 등 다양한 회사의 여러 최신 모델들을 ‘멀티 LLM’ 방식으로 마누스에 활용하고 있는 것으로 보고 있다.
요컨대 에이전트는 LLM의 한계를 보완하고 외부 세계와 능동적으로 상호작용할 수 있는 강력한 시스템이다. 사용자가 간단한 자연어 지시(식당 예약)를 내리면, 에이전트는 도구(검색, 예약 API 등)를 자유롭게 활용하여, 필요하면 추가 정보(주차 여부 등)를 가져오고, 메모리(사용자 취향)에 기반해 맞춤형 제안을 제시한 뒤 최종적으로 목표(예약)를 달성한다.
이 과정에서 가장 중요한 역할을 하는 것이 오케스트레이션 레이어다. 검색이나 API 호출이 단순히 나열만 되어서는 효율적인 실행 흐름이 만들어지지 않는다. 오케스트레이션 레이어가 필요 시점마다 도구 호출을 지시하고, 그 결과를 검토해 추론 과정에 반영해야 에이전트가 진정한 의미의 ‘자율 실행 AI’가 될 수 있다. 앞으로 업무 자동화나 개인 맞춤형 비서 등 다양한 영역에서 에이전트가 활약할 것으로 기대된다. 오케스트레이션 레이어를 얼마나 정교하게 설계·구현하느냐가 에이전트 시스템의 활용 범위와 사용자 경험을 좌우하게 될 것이다.
개발자 M (필명·AI 개발자) editor@sisain.co.kr
▶좋은 뉴스는 독자가 만듭니다 [시사IN 후원]
©시사IN, 무단전재 및 재배포 금지
Copyright © 시사IN. 무단전재 및 재배포 금지.