AI 에이전트와 Langchain

위 글은 SEQUOIA의 "LangChain’s Harrison Chase on Building the Orchestration Layer for AI Agents"를 번역 및 정리한 글입니다.

LangChain

해리슨은 Agent 생태계에서 전설적인 인물로, LLM(대형 언어 모델)을 도구와 행동에 연결하는 제품 비전을 제시한 첫 번째 사람입니다. LangChain은 AI 공간에서 가장 인기 있는 에이전트 구축 프레임워크입니다. Agent의 상태, 미래 가능성, 앞으로의 경로에 대해 이야기 해보겠습니다.

 

Agent란 무엇인가?

Agent를 정의하는 것은 까다롭습니다. 아직 LLM과 Agent 모두 초기 단계이기 때문이죠. 에이전트는 LLM(Large Language Model)이 애플리케이션의 제어 흐름을 결정하는 것과 비슷하다고 볼 수 있습니다. 전통적인 RAG Chain(검색 증강 생성 체인, Retrieval-Augmented Generation Chain)이나 검색 기반 생성 체인(Retrieval-Augmented Generation Chain)을 생각해 보세요. 이런 시스템에서는 일반적으로 단계들이 미리 정해져 있습니다.

예를 들면 이런 순서로 진행됩니다:

1. 검색 쿼리를 생성한다.
2. 관련 문서들을 검색해 가져온다.
3. 답변을 생성한다.
4. 그 답변을 사용자에게 전달한다.

이처럼 매우 고정된 순서로 사건들이 발생하게 됩니다.

제가 생각할 때, Agent적인 특성을 갖기 시작할 때는 LLM을 중심에 두고 그것이 무엇을 할지 정확히 결정하도록 하는 것입니다. 때로는 검색 쿼리를 실행할 수도 있고, 다른 때는 그냥 사용자에게 직접 응답할 수도 있습니다. 어떤 경우에는 검색 쿼리를 실행하고 결과를 얻은 다음, 또 다른 검색 쿼리를 실행하고, 두 가지 검색 쿼리를 더 실행한 후에 응답할 수도 있습니다. 즉, LLM이 제어 흐름을 결정하게 되는 것입니다.

Agent와 관련된 또 다른 흥미로운 요소로는 도구(Tools) 사용이 있습니다. LLM이 무엇을 할지 결정할 때 주된 방식이 도구 사용을 통해 이루어집니니다. 그래서 도구와 Agent는 밀접하게 연관되어 있습니다. 또한 메모리(기억) 기능도 Agent와 흔히 관련되어 있습니다. LLM이 무엇을 할지 결정할 때 과거에 했던 일을 기억해야 하기 때문입니다. 따라서 도구 사용과 메모리는 어느 정도 연관이 있습니다. 하지만 제 생각에 에이전트란 결국 LLM이 애플리케이션의 제어 흐름을 결정하는 것입니다.

 

Agent의 행동과 의사결정

Agent에서 행동과 의사결정은 밀접하게 관련이 있다고 생각합니다. Agent가 수행하는 많은 작업은 어떤 행동을 취할지 결정하는 것입니다. 행동을 취하는 데 가장 큰 어려움은 올바른 행동을 결정하는 것입니다. 따라서 하나를 해결하면 자연스럽게 다른 하나도 해결됩니다. 행동을 결정한 후에는 LLM 주변의 시스템이 그 행동을 실행하고 이를 다시 Agent에 피드백하는 과정이 있습니다. 그래서 두 가지는 밀접하게 관련되어 있다고 생각합니다.

즉, Agent는 Chain과 달리 다음 어떤 행동을 할지 결정하는 것입니다. 그 결정은 규칙 기반의 하드코딩된 것이 아니죠.

다음 행동을 결정하는 방식은 다양합니다. 예를들어, 어느 경로를 선택할지 결정하는 라우터가 있을 수 있습니다. 이는 체인에서 분류 단계를 수행하는 것과 같습니다. LLM이 여전히 무엇을 할지 결정하지만, 매우 단순한 방식입니다. 반대로 자율 Agent 유형도 있고, 그 중간에는 다양한 스펙트럼이 있습니다. 대부분 맞지만, 요즘 LLM 공간에는 많은 미세한 차이와 회색 영역이 있습니다.

 

Agent가 다음 큰 물결인가?

현재 코파일럿에서 Agent로 이동하고 있다고 생각합니다. 코파일럿은 여전히 인간이 개입해야 하기 때문에 제한적입니다. Agent는 인간의 개입 없이 더 많은 작업을 수행할 수 있습니다. 그러나 더 많은 작업을 수행하게 되면 실수하거나 잘못된 방향으로 갈 위험이 커집니다. 이 균형을 맞추는 것이 매우 흥미로울 것입니다.

 

첫 번째 자율 에이전트의 실패

2023년 3월경 몇몇 자율 에이전트가 많은 관심을 받았지만, 기대에 미치지 못했습니다. AutoGPT는 매우 일반적이고 비제한적이었습니다. 하지만 실제로 비즈니스 가치를 제공하려면 더 구체적이고 많은 규칙이 필요합니다. 대부분의 에이전트와 어시스턴트는 특정 방식으로 일을 수행합니다. 그것은 더 많은 엔지니어링 작업이 필요하고, 더 오래 걸립니다. 이것이 AutoGPT 스타일 아키텍처가 잘 작동하지 않은 이유입니다.

 

인지 아키텍처란?

인지 아키텍처는 기본적으로 LLM 애플리케이션의 시스템 아키텍처입니다. 애플리케이션을 구축할 때 알고리즘을 사용하는 몇 가지 단계가 있습니다. 이 알고리즘을 무엇에 사용하는지, 최종 답변을 생성하는 데만 사용하는지, 아니면 두 가지 다른 것들 사이를 라우팅하는 데 사용하는지, 다양한 가지와 반복되는 사이클이 있는 복잡한 구조를 가지고 있는지, 아니면 LLM을 반복적으로 실행하는 단순한 루프 구조를 가지고 있는지 등의 질문 모두 인지 아키텍처의 다양한 변형이며, 인지 아키텍처는 사용자 입력에서 사용자 출력까지 데이터와 정보의 흐름, 그리고 LLM 호출이 일어나는 과정을 나타내는 멋진 표현입니다.

그리고 사람들이 에이전트를 실제로 프로덕션에 투입하려고 할 때, 그 흐름이 애플리케이션의 도메인에 특정된다는 것입니다. 처음부터 특정한 체크를 하고 싶어 할 수도 있고, 그 다음에는 세 가지 특정 단계를 거칠 수도 있습니다. 그리고 각 단계는 다시 루프로 돌아가거나 두 가지 별도의 하위 단계를 가질 수 있습니다.

이렇게 그래프를 그리듯이 더 많은 맞춤형 그래프를 보게 됩니다. 사람들이 에이전트를 애플리케이션에 따라 제어하고 안내하려고 하기 때문입니다. 제가 이것을 인지 아키텍처라고 부르는 이유는 LLM의 강점이 무엇을 해야 할지 추론하고 생각하는 데 있기 때문입니다. 저는 과제를 수행하는 인지적 모델을 소프트웨어 시스템, 즉 아키텍처로 인코딩하는 것입니다.

그렇다면, 맞춤형 및 하드코딩된 방식이 우리가 가고 있는 방향일까요? 극단적인 예로, 모델이 계획을 정말 잘하고 신뢰할 수 있게 된다면, for-loop이 최선의 방법일 수 있습니다. LLM을 호출하고 무엇을 할지 결정하고, 행동을 취하고 다시 루프를 도는 방식이죠. 모델이 계획과 추론에서 더 나아질 것이라고 확신하지만, 그것이 최선의 방법이 될 것이라고는 생각하지 않습니다. 이유는 첫째, 효율성 때문입니다. 항상 A 단계를 B 단계 이후에 수행하려면, 그 순서를 유지하는 것이 낫습니다. 둘째, 신뢰성 때문입니다. 특히 기업 환경에서는 항상 A 단계를 B 단계 이후에 수행해야 한다면, 실제로 그렇게 될 것이라는 확신이 필요합니다.

하지만 흥미로운 점은, 단순히 루프에서 실행하는 아키텍처는 매우 단순하지만 일반적인 인지 아키텍처라고 생각할 수 있습니다. 실제로는 맞춤형이고 복잡한 인지 아키텍처가 많이 사용되고 있습니다. 복잡하지만 일반적인 인지 아키텍처와 맞춤형 복잡한 인지 아키텍처가 있습니다. 예를 들어, 복잡한 계획 단계와 반영 루프 또는 생각의 나무 구조 같은 것입니다. 이러한 일반적인 계획과 반영은 모델 자체에 점점 더 많이 훈련될 것입니다. 하지만 일반적이지 않은 계획, 반영, 제어 루프는 모델에 포함되지 않을 것입니다. 저는 이 두 가지 스펙트럼의 끝부분이 계속 중요할 것이라고 생각합니다.

결국 LLM이 일반적인 에이전트 추론을 담당하고, 도메인별 추론이 필요합니다. 하나의 일반 모델로 구축할 수 없는 부분이죠. 맞춤형 인지 아키텍처를 생각하는 한 가지 방법은 계획 책임을 LLM에서 인간으로 이전하는 것입니다. 일부 계획은 점점 더 모델과 프롬프트로 이동하겠지만, 많은 작업은 여전히 복잡한 계획이 필요합니다. 그래서 완벽하게 신뢰할 수 있는 시스템을 구축하기까지는 시간이 걸릴 것입니다.

 

당신의 맥주 맛을 더 좋게 하는 것에 집중하세요

제프 베조스는 "당신의 맥주 맛을 더 좋게 하는 것에 집중하라"는 말을 했습니다. 일반적인 인지 아키텍처를 구축하는 경우, 맥주 맛을 더 좋게 만들지는 않습니다. 모델 제공자가 이러한 일반적인 계획을 작업할 것입니다. 반면에, 인지 아키텍처가 지원 팀의 사고 방식이나 내부 비즈니스 프로세스 또는 특정 유형의 코드를 개발하는 최선의 방법을 인코딩하는 것이라면, 이는 맥주 맛을 더 좋게 만듭니다. 사용자 경험, UI 및 배포도 중요한 역할을 하지만, 일반과 맞춤형의 구분이 중요하다고 생각합니다.

팻 그레이디: 해리슨, 본론에 들어가기 전에 잠시 상위 레벨에서 생각해보겠습니다. 저희 창립자인 돈 발렌타인은 항상 "그래서 뭐?"라는 질문을 했습니다. 자율 에이전트가 완벽하게 작동한다고 가정했을 때, 그것이 세상에 어떤 의미가 있을까요? 삶은 어떻게 달라질까요?

해리슨 체이스: 높은 수준에서 보면, 인간으로서 우리가 집중하는 것들이 달라질 것입니다. 많은 산업에서 반복적인 작업이 많습니다. 에이전트의 아이디어는 이러한 작업을 자동화하여 우리가 더 높은 수준의 작업에 집중할 수 있도록 하는 것입니다. 에이전트가 어떤 일을 해야 할지 생각하고, 그 결과를 활용하여 더 창의적인 일을 하거나 더 높은 레버리지 작업을 수행하는 것이죠.

그리고 에이전트를 통해 많은 기능을 아웃소싱하여 회사를 시작하는 것도 상상할 수 있습니다. 마케팅 에이전트, 영업 에이전트 등을 두어 많은 일을 에이전트에 맡기고, 자신은 전략적 사고나 제품 개발에 집중할 수 있게 되는 것입니다. 이렇게 하면 우리가 하고 싶은 일과 잘하는 일에 집중하고, 하고 싶지 않은 많은 일들을 자동화할 수 있습니다.

 

에이전트가 실질적으로 적용되는 곳

현재 에이전트가 더 많이 적용되는 두 가지 주요 영역이 있습니다. 하나는 고객 지원(Customer Support)이고, 다른 하나는 코딩입니다. 많은 사람들이 고객 지원을 필요로 하고, LangChain에서도 고객 지원이 필요합니다. 그래서 에이전트를 통해 이 일을 할 수 있다면 정말 강력할 것입니다.

코딩은 흥미로운 부분입니다. 코딩에는 창의성이 요구되고 제품 사고나 포지셔닝이 많이 필요한 측면이 있습니다. 하지만 많은 사람들이 가지고 있는 창의성을 방해하는 코딩의 측면도 있습니다. 예를 들어, 제 어머니가 웹사이트에 대한 아이디어가 있지만 코딩을 할 줄 모른다면, 에이전트가 그 일을 대신할 수 있다면 어머니는 웹사이트의 아이디어와 범위에 집중할 수 있을 것입니다. 고객 지원은 현재 많은 영향을 미치고 있고, 코딩도 많은 관심을 받고 있지만 아직 고객 지원만큼 성숙하지는 않았습니다.

아이디어에서 현실로의 격차를 줄이는 것은 방해 요소를 자동화하는 것입니다. AI 시대의 빌더가 된다는 것은 이전에는 엔지니어가 필요했지만, 이제는 다양한 지식과 빌더들을 저렴한 비용으로 사용할 수 있다는 의미입니다. 이는 새로운 빌더들이 등장하는 것을 가능하게 합니다.

 

반영, 생각의 연쇄 및 기타 기법

AutoGPT가 작동하지 않았던 이유를 조금 이야기할 필요가 있습니다. 많은 인지 아키텍처가 그것을 해결하기 위해 등장했습니다. 처음에는 LLM이 첫 번째 단계에서 무엇을 해야 할지 잘 추론하지 못했습니다. 그래서 생각의 연쇄와 같은 프롬프트 기술이 유용했습니다. 이는 LLM이 특정 단계에 대해 단계별로 생각할 수 있는 공간을 제공했습니다. 이것이 점점 더 모델에 훈련되기 시작했습니다.

그런 다음, Shunyu Yao의 ReAct라는 훌륭한 논문이 있었습니다. 이는 에이전트용 첫 번째 인지 아키텍처였습니다. 이 논문은 LLM에게 행동을 예측하도록 하고, 추론 구성 요소를 추가했습니다. 생각의 연쇄와 비슷하게 단계마다 추론을 추가하고 루프에 넣어 실행했습니다. 모델이 훈련되면서 이러한 명시적인 추론 단계는 점점 덜 필요해졌습니다. 그래서 요즘 ReAct 스타일의 에이전트를 사용하는 사람들은 명시적인 생각 과정 없이 함수 호출을 사용하는 경우가 많습니다. 그러나 루프는 여전히 ReAct 논문과 연관되어 있습니다.

지금 작동하는 상태에서는 계획 수립과 완료 여부가 주요 문제입니다. 계획 수립이란 내가 해야 할 일의 순서를 계획하는 것입니다. 모델은 장기 계획 수립에 어려움을 겪습니다. 그래서 계획을 생성하고 단계별로 실행하는 명시적인 단계를 추가하는 것이 유용합니다.

그리고 반영은 모델이 실제로 일을 잘했는지 확인하는 것입니다. 인터넷에서 답을 얻었지만 잘못된 답일 수 있습니다. 이를 반영하여 올바른 답을 얻었는지, 다시 시도해야 하는지를 판단하는 명시적인 단계를 추가하는 것이 유용합니다.

계획 수립과 추론은 인기 있는 일반 인지 아키텍처입니다. 많은 맞춤형 인지 아키텍처가 있지만, 이는 모두 비즈니스 논리와 관련이 있습니다. 그러나 계획 수립과 추론은 일반적인 것이며, 이는 점점 더 모델에 훈련될 것입니다. 얼마나 잘 될지는 더 길게 논의해야 할 주제입니다.

 

UX는 아키텍처의 효율성에 영향을 줄 수 있다

LLM이 완벽하지 않고 신뢰할 수 없기 때문에 UX가 중요합니다. 그래서 초기 상호작용과 애플리케이션에서 채팅이 강력한 UX로 자리 잡았습니다. 쉽게 무엇을 하는지 볼 수 있고, 반응을 스트리밍하고, 응답으로 쉽게 수정할 수 있습니다. 그래서 채팅이 현재 지배적인 UX입니다. 그러나 채팅에는 단점이 있습니다. AI 메시지와 인간 메시지가 번갈아가며, 인간이 많이 개입해야 합니다. 인간을 루프에서 제거할수록 더 많은 일을 할 수 있게 되어 매우 강력해집니다.

하지만 LLM이 완벽하지 않기 때문에 이 두 가지를 어떻게 균형을 맞출지 고민해야 합니다. Devin에 대해 이야기하면, 에이전트가 수행한 모든 작업을 투명하게 보여주는 것이 흥미롭습니다. 두 번째 단계는 수행한 작업을 수정할 수 있는 것입니다. 잘못된 결정을 수정하고 새로운 지시를 주거나 수동으로 수정할 수 있습니다.

저는 이 되감기 및 편집 외에도 흥미로운 UX 패턴이 몇 가지 더 있다고 생각합니다. 하나는 에이전트가 필요에 따라 인간에게 연락할 수 있는 일종의 받은 편지함 개념입니다. 그래서 백그라운드에서 10개의 에이전트가 병렬로 실행되고 있다고 가정했을 때, 가끔씩 인간에게 명확히 해달라고 요청할 필요가 있을 때가 있습니다. 그래서 당신은 에이전트가 '도와줘, 여기서 도움 필요해'와 같은 메시지를 보내는 이메일 받은 편지함을 갖게 됩니다. 그리고 당신은 그 시점에서 에이전트를 도와줍니다.

비슷한 패턴으로는 에이전트의 작업을 검토하는 방식이 있습니다. 이것은 매우 강력합니다. 우리는 연구 스타일 에이전트와 같은 다양한 종류의 글쓰기 에이전트를 많이 보았고, 그 중 하나는 매우 흥미로운 아키텍처를 가진 GPT Researcher입니다. 이와 같은 리뷰 유형에 적합합니다. 예를 들어, 에이전트가 초안을 작성하면 제가 이를 검토하고 의견을 남길 수 있습니다. 이는 여러 가지 방식으로 이루어질 수 있습니다. 가장 덜 수고스러운 방법은 제가 한 번에 여러 의견을 남기고 이를 에이전트에게 보내면 에이전트가 모두 수정하는 것입니다. 또 다른 흥미로운 UX는 협력적인 실시간 작업입니다. 예를 들어, 구글 문서처럼 인간과 에이전트가 동시에 작업하는 것인데, 제가 의견을 남기면 에이전트가 이를 수정하는 동안 저는 다른 의견을 남기는 방식입니다. 이것은 설정하고 작동시키는 것이 다소 복잡하지만 매우 흥미로운 UX입니다.

또 다른 흥미로운 UX는 에이전트가 이러한 상호작용에서 배우는 방법입니다. 우리는 인간이 에이전트를 수정하거나 피드백을 주는 것에 대해 이야기하고 있습니다. 동일한 피드백을 100번 반복해야 한다면 매우 좌절감을 느낄 것입니다. 그래서 시스템이 이를 학습할 수 있게 하는 아키텍처가 무엇인지가 흥미롭습니다. 이러한 것들은 아직 초기 단계이지만, 우리는 이와 관련된 많은 것들을 고민하고 있습니다.

 

범위 밖의 문제는 무엇입니까?

두 가지 명확한 영역이 있다고 생각합니다. 하나는 모델 레벨이고, 다른 하나는 데이터베이스 레벨입니다. 우리는 벡터 데이터베이스를 구축하지 않고 있습니다. 우리는 적절한 저장소가 무엇인지 생각하는 것이 흥미롭다고 생각하지만, 우리는 그것을 하지 않고 있습니다. 우리는 또한 기초 모델을 구축하지 않습니다. 우리는 모델의 미세 조정(fine-tuning)을 하지 않습니다. 우리는 데이터 큐레이션에 도움을 주고 싶지만, 인프라를 구축하는 것은 하지 않습니다. Fireworks와 같은 다른 회사들이 이 분야에서 활동하고 있습니다. 이것들은 현재 사람들이 직면하고 있는 즉각적인 인프라 문제라고 생각합니다.

또 다른 질문은 에이전트가 미래가 된다면, 그로 인해 발생할 다른 인프라 문제가 존재합니다. 지금은 에이전트가 신뢰할 수 있을 만큼 충분히 발전하지 않았기 때문에 이러한 에이전트 경제가 출현할지는 알 수 없습니다. 하지만 에이전트를 위한 신원 확인, 권한 부여, 결제와 같은 문제가 흥미롭습니다. 실제로 에이전트가 인간에게 일을 맡길 수 있는 결제 스타트업도 있습니다. 에이전트가 보편화된다면 어떤 툴링과 인프라가 필요할지 생각하는 것이 흥미롭습니다. 이것은 LLM 애플리케이션을 구축하는 개발자 커뮤니티에서 필요한 것들과는 약간 다르다고 생각합니다. LLM 애플리케이션은 이미 존재하고 있으며, 에이전트는 이제 막 도입되고 있는 단계이기 때문입니다.

 

Fine Tuning vs 프롬프트?

미세 조정과 인지 아키텍처가 상호 대체재라고 생각하지 않습니다. 오히려 상호 보완적이라고 생각합니다. 더 맞춤형 인지 아키텍처가 있을 때 각 에이전트나 시스템의 각 구성 요소가 수행해야 하는 작업의 범위가 훨씬 제한됩니다. 이는 미세 조정에 매우 흥미로운 부분입니다.

 

LangSmith와 LangGraph?

LangChain이 처음 등장했을 때, 이 오픈 소스 프로젝트는 다양한 구성 요소의 인터페이스를 표준화하는 몇 가지 문제를 해결했습니다. 우리는 다양한 모델, 벡터 저장소, 도구, 데이터베이스와의 통합을 많이 갖추고 있습니다. 이는 LangChain의 큰 가치 제안 중 하나였습니다. LangChain에는 RAG나 SQL Q&A와 같은 오프더셸프 솔루션을 쉽게 시작할 수 있는 상위 수준의 인터페이스도 있습니다. 또한 체인을 동적으로 구성할 수 있는 하위 수준의 런타임도 있습니다. 체인과 LangGraph의 차이점은 반복적인 루프를 포함한 사용자 정의 가능한 것들입니다. LangGraph는 지속성 계층, 백그라운드에서 비동기적으로 실행되는 애플리케이션 배포에 중점을 둡니다.

LangSmith는 LLM 애플리케이션의 가시성과 테스트를 위한 도구입니다. 비결정론적인 LLM을 시스템의 중심에 둘 때 가시성과 테스트가 중요합니다. LangSmith는 프롬프트 관리, 인간 주석 큐를 포함하여 인간 검토를 허용합니다. 이것이 LLM의 비결정론적 특성 때문에 중요합니다.

 

기존의 관찰 도구와 새로운 접근 방식의 차이점?

관찰 도구의 경우 새로운 것이 필요하다는 것이 명확합니다. 예를 들어, 다단계 애플리케이션에서는 Datadog과 같은 도구가 특정 추적에 대한 모니터링을 제공하지만, LangSmith는 더 많은 인사이트를 제공합니다. 테스트의 경우, LLM 테스트에서는 페어와이즈 비교가 중요합니다. 소프트웨어 테스트와는 달리 페어와이즈 비교가 중요한 이유는 LLM 평가에서 중요한 역할을 하기 때문입니다. 또한, 테스트 결과의 추적과 인간의 검토가 필요합니다. 이러한 요소들이 기존 소프트웨어 테스트와는 다릅니다.