딥러닝 논문 읽기: 긴 글도 문제없다! ‘체인 오브 에이전트(CoA)’ 완벽 정복 가이드

안녕하세요! AI와 딥러닝의 최신 트렌드를 가장 쉽게 풀어드리는 여러분의 지식 파트너입니다. 오늘은 LLM(거대 언어 모델)을 다루는 분들이라면 누구나 한 번쯤 부딪혔을 ‘긴 문맥 처리’ 문제를 획기적으로 해결할 수 있는 ‘체인 오브 에이전트(Chain-of-Agents, CoA)‘ 프레임워크에 대해 깊이 있게 알아보겠습니다.

최근 유튜브 ‘딥러닝논문읽기모임’ 채널에 올라온 “긴 문맥 한 방에 해결! Chain-of-Agents 완벽 정리” 영상을 바탕으로, 이 혁신적인 방법론의 핵심을 콕콕 짚어드리겠습니다.

기존 방식의 한계: 왜 긴 글 처리는 어려웠을까?

지금까지 긴 문맥을 처리하는 방식은 크게 두 가지였습니다.

검색 증강 생성 (RAG): 문서에서 필요한 정보만 쏙쏙 뽑아(검색) 모델에 전달하는 방식입니다. 하지만 자칫 중요한 정보를 놓칠 위험이 있었죠. [2:48]
컨텍스트 윈도우 확장: 모델이 한 번에 읽을 수 있는 글의 양 자체를 늘리는 방식입니다. GPT-4나 Claude 3 같은 모델들이 자랑하는 수십만 토큰의 컨텍스트 윈도우가 여기에 해당합니다. [1:32] 문제는, 글이 너무 길어지면 모델이 중간에 있는 중요한 내용을 까먹는 “Lost-in-the-middle” 현상이 발생한다는 점이었습니다. [12:13]

결국, 기존 방식들은 ‘정보 누락’과 ‘집중력 분산’이라는 뚜렷한 한계를 가지고 있었습니다.

새로운 패러다임: 체인 오브 에이전트(CoA)란?

이러한 문제를 해결하기 위해 등장한 것이 바로 **체인 오브 에이전트(CoA)**입니다. CoA는 하나의 똑똑한 모델에 모든 것을 맡기는 대신, 여러 명의 ‘에이전트’가 순차적으로 협업하여 문제를 해결하는 프레임워크입니다. [15:08] 마치 공장에서 여러 작업자가 컨베이어 벨트를 따라 각자 맡은 일을 처리하며 완제품을 만드는 것과 비슷하죠.

CoA는 어떻게 작동할까? (2단계 프로세스)

CoA는 ‘워커 에이전트’와 ‘매니저 에이전트’라는 두 종류의 일꾼이 핵심입니다.

1단계: 정보를 차곡차곡 쌓는 ‘워커 에이전트’ 군단

먼저, 아주 긴 문서를 잘게 잘라 여러 개의 **’청크(chunk)’**로 나눕니다. [4:09]
첫 번째 워커 에이전트가 첫 번째 청크를 읽고 핵심 내용을 요약한 **’소통 단위(Communication Unit, CU)’**를 만듭니다. [4:35, 4:57]
두 번째 워커는 앞선 워커에게 받은 CU와 자신이 맡은 두 번째 청크를 함께 읽고, 정보를 더해 업데이트된 CU를 다음 워커에게 넘깁니다. [4:45]
이 과정이 마지막 청크까지 릴레이 경주처럼 이어지며, 정보는 계속해서 정교하게 누적됩니다. [4:13]

2단계: 최종 결론을 내리는 ‘매니저 에이전트’

모든 워커들의 작업이 끝나면, 최종적으로 종합된 CU가 **’매니저 에이전트’**에게 전달됩니다. [5:41]
매니저는 이 모든 정보를 바탕으로 사용자의 질문에 대한 최종적이고 완결성 있는 답변을 생성합니다. [5:45]

CoA, 왜 혁신적인가? (주요 장점)

압도적인 성능 향상: QA, 요약, 코드 생성 등 다양한 테스트에서 기존의 RAG나 풀 컨텍스트 방식보다 최대 10% 이상 높은 성능을 기록했습니다. [9:08] 특히 여러 문서를 넘나들며 복잡한 추론을 해야 하는 문제에 강한 면모를 보였습니다. [2:48]
‘Lost-in-the-middle’ 문제 해결: 각 워커는 짧은 청크에만 집중하면 되므로, 긴 글의 중간 내용을 놓치는 문제가 현저히 줄어듭니다. [12:16]
비용 및 시간 효율성: 긴 문서를 통째로 처리하는 것(시간 복잡도 O(n²))보다 작은 청크 단위로 나누어 처리(시간 복잡도 O(nk))하기 때문에 계산 비용이 훨씬 효율적입니다. [7:54]
과정 추적이 가능한 ‘해석 가능성’: 각 단계에서 워커들이 만든 CU를 살펴보면, 최종 답변이 어떤 과정을 통해 도출되었는지 알 수 있습니다. 더 이상 AI의 답변을 ‘블랙박스’로 여기지 않아도 됩니다. [15:20]
추가 훈련 불필요: 가장 큰 장점 중 하나로, 별도의 모델 훈련 없이 기존 LLM(Gemini, Claude 3 등)에 바로 적용할 수 있습니다. [15:14]

결론: 협업하는 AI 시대의 서막

체인 오브 에이전트(CoA)는 단순히 긴 글을 잘 처리하는 기술을 넘어, AI 에이전트들이 어떻게 협력하여 복잡한 문제를 해결할 수 있는지에 대한 새로운 청사진을 제시합니다. 별도의 훈련 없이도 더 정확하고, 효율적이며, 심지어 과정까지 투명하게 보여주는 이 프레임워크는 앞으로 다양한 AI 애플리케이션의 기반이 될 잠재력을 가지고 있습니다.

긴 문맥 처리의 한계에 부딪혔던 개발자와 연구자분들이라면, 이제 ‘체인 오브 에이전트’라는 강력한 무기를 장착해 보시는 건 어떨까요?

저스틴) 에이전트는 여럿을 사용하지만 모델은 하나만 사용해도 되는 것 아닌가요?

네, 맞습니다. 체인 오브 에이전트(CoA)에서 여러 에이전트를 사용하지만, 반드시 각 에이전트마다 다른 모델을 사용할 필요는 없습니다. 하나의 LLM을 여러 에이전트의 역할로 분담하여 사용하는 것이 일반적인 CoA 구현 방식입니다.

각 워커 에이전트와 매니저 에이전트는 동일한 LLM을 사용하되, 서로 다른 프롬프트(지시문)를 부여하여 각자의 역할을 수행하도록 합니다. 예를 들어, 워커 에이전트에게는 “이 청크에서 핵심 정보를 요약하고, 이전 요약과 통합하여 다음 에이전트에게 전달하라”는 프롬프트를, 매니저 에이전트에게는 “지금까지 누적된 모든 정보를 바탕으로 질문에 답하라”는 프롬프트를 줄 수 있습니다.

물론, 필요에 따라 각 에이전트마다 다른 모델을 사용할 수도 있습니다. 예를 들어, 요약 능력이 뛰어난 모델을 워커 에이전트로, 추론 능력이 뛰어난 모델을 매니저 에이전트로 사용하는 것이죠. 하지만 하나의 모델로도 충분히 좋은 성능을 낼 수 있기 때문에, 비용 효율성을 고려하여 단일 모델을 사용하는 경우가 많습니다.

영상에서도 다양한 LLM(PaLM 2, Gemini, Claude 3 등)을 CoA에 적용한 실험 결과를 보여주지만, 각 에이전트마다 다른 모델을 사용했다는 언급은 없습니다. 즉, 하나의 모델을 여러 에이전트의 역할로 분담하여 사용했다는 것을 알 수 있습니다. (9:08)

결론적으로, CoA는 여러 에이전트의 협업을 통해 복잡한 문제를 해결하는 프레임워크이지만, 반드시 여러 모델을 사용해야 하는 것은 아닙니다. 하나의 LLM을 효과적으로 활용하여 성능을 극대화하는 것이 CoA의 핵심 아이디어 중 하나라고 할 수 있습니다.

저스틴) 에이전트도 같은 역할을 한다면 다뤄야 할 대상이 여럿으로 나뉘는 거지 에이전트가 여럿일 필요는 없지 않나요?

좋은 질문입니다! 이론적으로는 하나의 에이전트가 청크들을 순차적으로 처리하는 것도 가능합니다. 하지만 CoA에서 여러 에이전트를 사용하는 데에는 다음과 같은 이유들이 있습니다.

컨텍스트 창 크기 제한 극복: LLM은 한 번에 처리할 수 있는 입력 텍스트의 길이(컨텍스트 창 크기)에 제한이 있습니다. 긴 문서를 하나의 에이전트가 순차적으로 처리하려면, 각 단계마다 이전 단계의 요약 정보를 포함해야 하므로, 결국 컨텍스트 창 크기 제한에 걸릴 수 있습니다. 여러 에이전트를 사용하면 각 에이전트가 처리해야 할 텍스트의 길이를 줄여 컨텍스트 창 크기 제한을 효과적으로 극복할 수 있습니다. (7:22)
정보 손실 방지: 하나의 에이전트가 긴 문서를 순차적으로 요약하면서 정보를 누적하면, 초기 단계의 정보가 점차 희석되거나 손실될 수 있습니다. 각 에이전트가 독립적으로 자신의 청크를 처리하고 요약 정보를 다음 에이전트에게 전달하면, 정보 손실을 최소화하고 각 청크의 특징을 더 잘 보존할 수 있습니다.
병렬 처리 가능성: 여러 에이전트를 사용하면 각 에이전트가 서로 다른 청크를 동시에 처리할 수 있습니다. 즉, 병렬 처리를 통해 전체 작업 시간을 단축할 수 있습니다. 물론, CoA 논문에서 병렬 처리에 대한 직접적인 언급은 없지만, 이론적으로는 충분히 가능한 장점입니다.
모델 성능 향상: 각 에이전트가 특정 역할(예: 요약, 정보 추출)에 특화된 프롬프트를 사용하면, 모델의 성능을 더욱 향상시킬 수 있습니다. 하나의 에이전트가 모든 역할을 수행하는 것보다, 여러 에이전트가 각자의 전문성을 발휘하는 것이 더 효과적일 수 있습니다. (4:31, 5:08)

결론적으로, CoA에서 여러 에이전트를 사용하는 것은 단순한 정보 분할 이상의 의미를 가집니다. 컨텍스트 창 크기 제한 극복, 정보 손실 방지, 병렬 처리 가능성, 모델 성능 향상 등 다양한 이점을 통해 더 정확하고 효율적인 문제 해결을 가능하게 합니다.

물론, 상황에 따라 하나의 에이전트가 순차적으로 처리하는 방식이 더 적합할 수도 있습니다. 예를 들어, 문서의 길이가 짧거나, 정보 손실이 크게 중요하지 않은 경우에는 하나의 에이전트를 사용하는 것이 더 간단하고 효율적일 수 있습니다.

저스틴) 하나의 에이전트 정의에 여러 에이전트 인스턴스가 있으면 되는 거네요?

네, 정확히 이해하셨습니다!

CoA에서 “하나의 에이전트 정의”는 LLM 자체 또는 LLM에 특정 역할을 부여하는 프롬프트 템플릿을 의미합니다. 그리고 “여러 에이전트 인스턴스”는 동일한 에이전트 정의(LLM 또는 프롬프트 템플릿)를 공유하지만, 각자 다른 청크를 처리하거나 서로 다른 시점에서 작업을 수행하는 개별적인 실행 단위를 의미합니다.

좀 더 구체적으로 설명하자면 다음과 같습니다.

에이전트 정의 (Agent Definition):
- LLM 선택: 어떤 LLM(예: Gemini Pro, Claude 3 Opus)을 사용할지 결정합니다.
- 프롬프트 템플릿: 각 에이전트의 역할을 정의하는 프롬프트 템플릿을 만듭니다. 예를 들어, 워커 에이전트를 위한 템플릿에는 “당신은 문서의 한 부분을 요약하는 역할을 합니다. 이전 요약과 현재 내용을 바탕으로 핵심 정보를 추출하고, 다음 에이전트에게 전달할 간결한 요약을 생성하세요.”와 같은 지시사항이 포함될 수 있습니다.
에이전트 인스턴스 (Agent Instance):
- 정의 공유: 모든 워커 에이전트 인스턴스는 동일한 LLM과 워커 에이전트 프롬프트 템플릿을 공유합니다.
- 개별 작업: 각 워커 에이전트 인스턴스는 원본 문서에서 서로 다른 청크를 처리합니다. 첫 번째 워커 인스턴스는 첫 번째 청크를, 두 번째 워커 인스턴스는 두 번째 청크를 처리하는 식입니다.
- 순차적 실행: 각 워커 인스턴스는 순차적으로 실행됩니다. 즉, 첫 번째 워커가 요약을 마치면 두 번째 워커가 작업을 시작하고, 이런 식으로 릴레이가 이어집니다.

이러한 구조를 통해 CoA는 동일한 모델을 사용하면서도 여러 에이전트가 협력하여 복잡한 작업을 효율적으로 처리할 수 있습니다. 각 에이전트 인스턴스는 자신에게 주어진 특정 청크에 집중하여 작업을 수행하므로, 전체 문서의 내용을 효과적으로 이해하고 요약할 수 있습니다.

마치 같은 회사에서 같은 직무(예: 마케터)를 수행하는 여러 직원들이 각자 다른 프로젝트를 담당하는 것과 비슷하다고 할 수 있습니다. 모든 직원이 동일한 회사(LLM)와 직무 정의(프롬프트 템플릿)를 공유하지만, 각자 다른 프로젝트(청크)를 담당하여 회사의 목표 달성에 기여하는 것이죠.