“컨텍스트 대화를 위한 런타임” 시멘틱 커널을 사용한 AI 에이전트 만들기

1990년대 초 필자는 한 대형 통신사 연구실에서 고급 가입자망 그룹에 속해 일했다. 당시 그룹이 맡은 문제는 가입자 집까지 서비스가 들어가는 구간, 즉 '라스트 마일(last mile)'이었다. 필자의 연구 분야는 아날로그에서 디지털 서비스로 네트워크 전환이 이뤄질 때 일어날 일에 대해 생각하는 것이었다.  
 

오랜 시간 동안 연구실에서 보편적 대역폭의 미래에 컴퓨팅이 어떤 형태가 될지를 상상했다. 그러다가 필자는 컴퓨터가 백그라운드로 사라지고 소프트웨어 에이전트가 인간의 대리자가 되어 네트워크 서비스와 상호작용하는 유비쿼터스 컴퓨팅 개념에 매료됐다. 유비쿼터스 컴퓨팅은 애플과 IBM, 제너럴 매직(General Magic)을 비롯한 많은 기업에 영향을 미쳤다. 

소프트웨어 에이전트 개념의 대표적인 개척자는 MIT 교수 패티 매스다. 매스는 네트워킹, 프로그래밍, AI의 경계를 넘나들며 연구했는데, 주로 지능적 에이전트와 자율적 에이전트라는 두 가지 상호 관련된 개념에 집중했다. 이 둘은 사용자를 위해 정보를 찾아서 추출하고, 그 과정에서 행동을 바꿀 수 있는 적응형 프로그램이었다. 

이후 소프트웨어 업계가 이 선구적인 연구를 따라잡기까지는 30년이 걸렸고, 마침내 트랜스포머 기반의 LLM(Large Language Model)과 적응형 오케스트레이션 파이프라인의 조합을 통해 최초의 원대한 개념을 실현할 수 있게 됐다. 

에이전트 프레임워크로서의 시맨틱 커널 

마이크로소프트의 시맨틱 커널(Semantic Kernel) 팀은 오픈 AI의 어시스턴트(Assistant) 모델을 기반으로 일종의 지능형 에이전트와 여러 함수 호출을 관리하기 위한 일련의 툴을 함께 제공한다. 또한 마이크로소프트는 오픈AI API에서 보내고 받는 메시지를 관리하고 플러그인을 사용해서 범용 채팅과 RAG를 사용한 근거 있는 데이터 기반 통합을 위한 수단도 제공한다. 

팀은 최근 1.01 릴리스에서 원래의 랭체인(LangChain)과 비슷한 오케스트레이션 모델을 넘어, 이제 시맨틱 커널을 컨텍스트 대화를 위한 런타임으로 여기고 있다. 이를 위해서는 대화 및 사용된 프롬프트 기록을 훨씬 더 많이 관리해야 한다. 시맨틱 커널이 모든 입출력을 관리하면서 모든 상호작용은 채팅 기능을 통해 이뤄진다. 

현재 이 분야에서는 많은 일이 일어나고 있다. 첫째, AI 스택을 향한 움직임이다. 마이크로소프트 코파일럿 모델은 AI 지원 인프라(추론 및 학습용)에 대한 마이크로소프트의 투자, 기반 모델 라이브러리, 그리고 마이크로소프트 및 오픈AI 플랫폼 전반에서 작동하는 플러그인을 기반으로 하는 최신 에이전트 스택 구현이라고 할 수 있다. 

시맨틱 커널 플러그인의 역할 

시맨틱 커널의 최근 업데이트에서 중요한 부분은 더 이상 사용자가 명시적으로 기록을 관리할 필요가 없게 되어 LLM 사용자 인터페이스와의 채팅이 간소화됐다는 점이다. 이제 애플리케이션에 사용할 AI 서비스를 정의하는 즉시 시맨틱 커널이 기록을 관리해준다. 결과적으로 기반 모델에서 추상화된, 훨씬 더 이해하기 쉬운 코드를 얻게 된다. 

시맨틱 커널은 대화 상태를 관리함으로써 에이전트를 위한 컨텍스트 에이전트가 된다. 그 다음으로 시맨틱 커널에 필요한 것은 외부 툴과 상호작용하기 위한 수단이다. 여기서 플러그인이 LLM 친화적인 설명을 메서드에 추가한다. 코드에 이 메타데이터를 추가하기만 하면 더 이상의 다른 작업은 필요하지 않다. 그러면 채팅에서 API를 통해 홈 어시스턴트(Home Assistant)와 같은 스마트 홈 플랫폼을 사용해서 난방을 켜는 등의 동작을 트리거할 수 있다.  

시맨틱 커널 kernel 객체에 플러그인을 추가하면 채팅 기반 오케스트레이션에서 플러그인을 사용할 수 있게 된다. 기반 LLM은 가장 그럴듯한 플러그인 설명과 연결된 동작을 실행하는 데 필요한 언어적 이해를 제공한다. 이렇게 하면 에이전트를 실행하는 사용자가 정확성에 지나치게 얽매이지 않아도 된다. 즉, "방을 더 따뜻하게 해" 또는 "방 온도를 17C로 설정해"와 같은 말로 "방 온도 설정"을 트리거할 수 있다. 이 두 가지 지시의 의도는 동일하며 시맨틱 커널은 그에 따라 적절한 메서드를 호출하게 된다. 

또는 현재 실험적으로 지원되는 오픈AI 플러그인을 사용하는 방법도 있다. 이런 플러그인은 오픈API 사양을 사용해서 외부 API에 액세스하며, 호출은 시맨틱 설명에 연결된다. API 호출의 시맨틱 설명은 오픈AI의 LLM이 프롬프트의 내용을 기반으로 적절한 호출을 수행할 수 있게 해준다. 시맨틱 커널은 자체 플러그인 및 오픈AI 플러그인을 사용해서 전체적인 컨텍스트를 관리하고 일련의 API에 대한 호출을 체인으로 연결할 수 있다. 시맨틱 커널은 모델을 혼합해서 자체 시맨틱 메모리와 함께 사용할 수도 있으며, 이 경우 벡터 검색을 사용해 실제 데이터에서 LLM의 근거를 마련할 수 있다. 

여기서 마이크로소프트가 하는 일은 LLM의 언어 역량을 가져와 사용자, 데이터, API 컨텍스트로 래핑하는 것이다. 이 부분부터 시맨틱 커널을 지능형 에이전트 구축을 위한 툴로 지칭할 수 있다. 프롬프트와 사용자 채팅을 사용해서 데이터 소스와 인터넷에 호스팅된 리소스를 기준으로 동적으로 쿼리를 오케스트레이션하기 때문이다. 

LLM 기반 에이전트는 자율적인 동작이 가능한가? 

일종의 자율성을 구현하기 시작한 일련의 시맨틱 커널 함수도 있다. 진짜 흥미로운 부분은 여기서부터 시작한다. 시맨틱 커널 에이전트는 컨텍스트를 관리함으로써 현재 라이브러리에서 적절한 플러그인을 선택해 답변을 제공할 수 있다. 

여기서 시맨틱 커널의 플래너를 활용해서 워크플로우를 만들 수 있다. 최근 출시된 핸들바(Handlebars) 플래너는 루프와 조건문이 포함된 오케스트레이션을 동적으로 생성할 수 있다. 사용자가 채팅에서 작업을 생성하면 플래너는 해당 지침에 따라 오케스트레이션을 생성하고 작업을 완료하는 데 필요한 플러그인을 호출한다. 시맨틱 커널은 커널 코드에 정의된 플러그인만 사용한다(해당 플러그인만 사용하도록 하는 프롬프트 사용). 

자율적으로 작동하는 코드에는 몇 가지 이슈가 있다. 코드의 근거를 유지하고 부정확성과 오류를 방지하려면 어떻게 해야 할까? 한 가지 방법은 애저 AI 스튜디오(Azure AI Studio)의 프롬프트 플로우(Prompt Flow) 툴을 통해 플래너와 플러그인의 정확성을 평가하는 테스트 프레임워크를 만드는 것이다. 이 툴은 방대한 벤치마크 데이터를 사용하여 에이전트가 다양한 사용자 입력에 대해 어떻게 작동하는지 판단할 수 있다. 충분한 데이터를 얻기 위해서는 LLM을 사용하여 초기 요청을 생성하고 합성 쿼리를 생성해야 할 수 있다. 

마이크로소프트의 코파일럿은 실제 작동하는 지능형 에이전트의 예다. 반갑게도 시맨틱 커널 팀에서도 이 용어를 사용한다. 소프트웨어 에이전트에 대한 30년 이상의 연구가 축적된 만큼, 이 같은 풍부한 경험에 기대 시맨틱 커널 오케스트레이션의 결과를 평가 및 개선하고 에이전트가 제공할 수 있는 사용자 경험과 프레임을 구축하도록 개발자를 이끌 수 있다. 

30년 동안 이어진 지능형 에이전트 

시맨틱 커널의 에이전트 모델은 한 가지 중요한 측면에서 원래의 에이전트 개념과 다르다. 바로 원격 플랫폼에서 쿼리를 실행하기 위해 지능형 코드를 전송하지 않는다는 점이다. 지난 30여 년 동안 분산 애플리케이션 개발 분야에서 큰 혁신이 일어나면서 에이전트 기술을 지원하는 데 필요한 많은 부분이 바뀌었다. 

이런 새로운 개발 접근 방식에 따른 결과는 더 이상 원격 서버에서 신뢰할 수 없는 임의의 코드를 실행할 필요가 없다는 것이다. 대신 API와 클라우드 리소스를 활용해서 에이전트를 분산 시스템 전반에 걸친 오케스트레이션된 워크플로우로 취급할 수 있다. 또한 이 에이전트는 이전 작업과 현재 작업을 기반으로 오케스트레이션을 지능적으로 재구성할 수 있다. 현대의 마이크로서비스는 이를 위한 이상적인 플랫폼으로, 서비스 지향 아키텍처 개념을 기반으로 하며 자체 문서화 오픈API 및 그래프QL 설명을 사용한다. 

이것이 시맨틱 커널이 채택 중인 모델로 보인다. 즉, 이런 동적 워크플로를 호스팅할 수 있는 프레임워크를 제공하는 것이다. API 호출, 벡터 검색, 오픈AI 플러그인을 비교적 간단한 프로그래밍적 스캐폴딩과 결합하면 원래의 에이전트 전제에 대한 현대적 대안을 구축할 수 있다. 결국 관건은 무해한 에이전트를 맬웨어와 어떻게 구분하느냐는 것이다. 1994년에는 컴퓨터 바이러스가 드물었고 네트워크 공격은 공상 과학 영화에나 나올법한 이야기였다. 

지금은 오픈API 정의를 사용해서 신뢰할 수 있는 API에서 데이터를 쿼리하고 추출하는 방법을 LLM에게 학습시킬 수 있다. 이러한 연결을 위해 필요한 모든 코드는 기반 AI가 제공하므로 프롬프트와 사용자 질문만 있으면 된다. 시맨틱 커널은 이 프롬프트를 제공하고, 원래 질문의 맥락에 맞게 자연어로 답변을 제공한다. 

초기 에이전트 개념을 현대적으로 실현하는 방식이라고 생각할 수 있다. 다수의 시스템이 아닌 클라우드의 한 지점에서 코드를 실행한다. API를 사용하면 에이전트에 정보를 제공하는 시스템이 감당해야 하는 부하가 줄어들고 프로세스의 보안이 더 강화된다.  

이와 같은 기술이 발전함에 따라 중요한 점은 이를 완전히 새로운 기술로 취급하지 않는 것이다. 수십 년에 걸친 연구의 결과가 마침내 처음 의도한 사용자를 만나는 중이다. 이 연구에는 1990년대 연구자들이 원래 의도했던, 차세대 네트워크에서 우리의 대리자 역할을 할 안정적이고 사용자 친화적인 지능형 에이전트를 제공하는 데 도움이 될 수 있는 많은 내용이 담겨 있다.
editor@itworld.co.kr