왜 당신의 AI 에이전트들은 계속 서로의 발을 밟는가

AIdeazz에 처음 게시되었습니다 — 정식 링크와 함께 이곳에 교차 게시되었습니다.

두 명의 에이전트가 40분 동안 내내 서로의 작업을 망치는 것을 처음 목격했을 때, 나는 노트북을 태평양에 던져버리고 싶었습니다. 저는 파나마에서 실제 운영 제약 조건(production constraints)이 있고 낭비되는 사이클의 여유가 거의 없는 멀티 에이전트 시스템(multi-agent systems)을 구축하고 있는 1인 창업자 Elena Vakeva입니다. 서류상으로 제 설정은 지능적으로 보입니다. 에이전트 하나는 새로운 논문을 읽고, 하나는 코드를 작성하며, 하나는 풀 리퀘스트(pull requests)를 검토하고, 하나는 사용자와 대화하며, 하나는 저의 개인 지식 베이스(knowledge base)를 유지합니다. 하지만 실제로 작동할 때는 공통된 메모리(memory)를 공유하기를 거부하는, 아주 자신만만한 고양이들을 몰고 다니는 기분입니다.

실패는 컨텍스트(context)에서 시작됩니다. 각 에이전트에게는 세상의 좁은 조각만이 주어집니다. 연구 에이전트는 최신 arXiv 논문들은 알고 있지만, 이번 주의 제품 로드맵(product roadmap)은 본 적이 없습니다. 코드 작성 에이전트는 코드베이스(codebase)를 이해하고 있지만, 지난달 사용자 인터뷰에서 얻은 고통스러운 교훈에 대해서는 기억이 없습니다. 제가 그들에게 협업하라고 말할 때 그들은 서로의 발을 밟게 되는데, 왜냐하면 그들은 말 그대로 동일한 메모리를 공유하지 않기 때문입니다.

저는 뻔한 해결책을 시도했습니다. 모든 에이전트가 공유 작업 공간(shared workspace)에 읽고 쓸 수 있도록 중앙 벡터 데이터베이스(vector database)를 구축했습니다. 이론적으로는 우아하게 들렸습니다. 하지만 현실은 노이즈(noise)가 모든 것을 집어삼키는 상황이었습니다. 한 에이전트가 새로운 트랜스포머(transformer) 논문에 대한 20페이지 분량의 요약본을 떨어뜨려 놓습니다. 나중에 다른 에이전트가 UI 변경을 결정하기 위해 그 텍스트 더미를 사용하려다 완전히 혼란에 빠집니다. 신호(signal)가 이전 대화의 층 아래로 사라져 버립니다. 이는 마치 모든 직원이 자신의 하루에 대해 500단어 분량의 메모를 작성하고, 다른 모든 사람이 결정을 내리기 전에 그 내용을 전부 읽기를 기대하는 회사를 운영하는 것과 정확히 같습니다.

조율 (Coordination)은 훨씬 더 심각합니다. 인간은 분위기를 파악하는 법을 배웁니다. 에이전트는 그렇지 못합니다. 그들은 두 가지 실패 모드 사이를 오갑니다. 명령을 영원히 기다리거나, 묻지도 않고 서로의 출력을 지나치게 의욕적으로 다시 쓰는 것입니다. 저는 제가 개입할 때까지 멈추지 않는 무한 루프에 빠진 에이전트들을 목격했습니다. 더 깊은 문제는 대부분의 멀티 에이전트 (multi-agent) 연구가 명확한 보상 함수 (reward functions)가 있는 시뮬레이션 환경 내의 수십 또는 수백 명의 에이전트를 가정한다는 점입니다. 그것은 제가 처한 세상이 아닙니다. 저는 제한된 컴퓨팅 자원 (compute), 제한된 시간, 그리고 매주 변하는 목표를 가진 한 사람일 뿐입니다. 제 에이전트들은 교체 가능한 연산 단위 (compute units)가 아니라, 사려 깊은 동료처럼 행동해야 합니다.

많은 고통스러운 실험 끝에, 저는 실제로 도움이 되는 두 가지 투박한 관행에 도달했습니다. 첫째는 메모리 핸드오프 (memory handoffs)입니다. 모든 에이전트가 모든 것을 보게 하는 대신, 저는 그들이 작업을 마칠 때 매우 간결한 한 문장을 작성하도록 강제합니다. 다음 에이전트는 작업을 시작하기 전에 반드시 그 한 문장을 읽어야 합니다. 예를 들어, 리서치 에이전트가 다음과 같이 실행을 마칩니다: "핵심 통찰: 새로운 어텐션 메커니즘 (attention mechanism)은 추론 비용 (inference costs)을 줄여주지만, 우리의 모바일 배포 계획에 중요한 긴 컨텍스트 (long context)에서는 작동하지 않음." 이 한 줄은 엔지니어링 에이전트에게 순수한 신호 (signal)가 됩니다. 노이즈 (noise)가 극적으로 줄어듭니다.

둘째로, 저는 에이전트들이 스스로 조직화될 것이라고 가정하는 것을 그만두었습니다. 저는 명시적인 체크포인트 (checkpoints)에서 조정자 (coordinator)로서 직접 개입했습니다. 저는 제안된 계획들을 한곳에서 함께 검토하고 어려운 결정을 내립니다. 여전히 제가 대부분의 생각을 하고 있는 것처럼 느껴지지만, 적어도 이제 에이전트들이 리서치, 초안 작성, 그리고 탐색과 같은 힘든 작업들을 수행합니다.

솔직한 진실은 우리가 아주 초기 단계에 있다는 것입니다. 자원이 제한된 창업자 주도 환경 내에서 진정한 협업을 위한 도구는 기본적으로 존재하지 않습니다. 대부분의 프레임워크는 당신이 MLOps 팀을 보유한 대기업이거나, 아니면 장난감 예제 (toy examples)를 가지고 놀고 있다고 가정합니다. 지친 창업자 한 명이 번아웃 없이 산출량을 늘리려고 노력하는 그 혼란스러운 중간 단계 (messy middle)를 겨냥한 것은 거의 없습니다.

그것이 제가 이 문제로 계속 되돌아오는 이유입니다. 보상은 엄청납니다. 에이전트들이 협업하는 방식이 조금이라도 개선된다면, 한 사람이 만들어낼 수 있는 결과물의 양이 달라집니다. 미래는 가장 많은 에이전트를 보유한 창업자의 것이 아닙니다. 인간을 미치게 만들지 않으면서 에이전트들이 협업하게 만들 수 있는 사람의 것입니다.

저는 실패를 통해 얻은 많은 흉터와, 도움이 되기 시작한 몇 가지 작은 관행들을 가지고 있습니다: 가차 없는 요약 (ruthless summarization)을 동반한 공유 메모리 (shared memory), 명확한 인수인계 프로토콜 (handoff protocols), 창업자의 주의력 (attention)을 진정한 병목 현상 (bottleneck)으로 취급하는 것, 그리고 아주 많은 인내심입니다. 만약 여러분도 자신만의 작은 환경에서 에이전트들과 씨름하고 있다면, 여러분에게는 무엇이 효과가 있는지 듣고 싶습니다.

FAQ

왜 공유 벡터 데이터베이스 (shared vector database)가 노이즈 문제를 악화시키나요?
에이전트들이 큐레이션 (curation) 없이 긴 문서들을 쏟아붓기 때문입니다. 20페이지 분량의 논문 요약본은 그 모든 세부 사항이 필요하지 않은 후속 에이전트 (downstream agent)에게는 컨텍스트 오염 (context pollution)이 됩니다.

메모리 인수인계 (memory handoff)란 무엇이며 왜 도움이 되나요?
메모리 인수인계란 모든 작업의 끝에 작성되는 단 하나의 간결한 문장으로, 다음 에이전트가 작업을 시작하기 전에 반드시 읽어야 하는 것입니다. 이는 무분별한 컨텍스트 (context)를 가차 없는 신호 (signal)로 대체합니다.

1인 창업자도 여전히 코디네이터 (coordinator) 역할을 해야 하나요?
네. 자원이 제한된 창업자 주도 환경에서는 인간의 주의력 (attention)이 진정한 병목 현상 (bottleneck)입니다. 명시적인 체크포인트 (checkpoints)에 자신을 개입시키는 것은, 에이전트들이 스스로 조직화하기를 바라는 것보다 무한 루프 (infinite loops)와 어긋난 작업을 방지하는 데 훨씬 효과적입니다.