멀티 에이전트 시스템(multi-agent systems)을 구축하는 사람이라면 누구나 이제 시작 패턴을 알고 있습니다. 라우터(router)가 요청을 읽고, 실제로 무엇을 묻고 있는지 파악한 뒤, 문제를 설정하는 에이전트, 실행하는 에이전트, 설명하는 에이전트, 범위를 좁히는 에이전트와 같이 전문화된 에이전트들에게 작업을 배분합니다. 오케스트레이션 그래프(Orchestration graph), 전문화된 노드(specialized nodes). 좋습니다. 모두가 이렇게 만듭니다. 이는 기본 중의 기본입니다.

아무도 가르쳐주지 않는 부분 — 당신의 시스템이 1년 동안 살아남을 수 있을지를 실제로 결정하는 부분 — 은 훨씬 조용합니다:

적절한 추상화 수준(level of abstraction)을 선택하는 것.

에이전트의 수가 아닙니다. 오케스트레이션(orchestration)의 영리함도 아닙니다. 바로 '수준'입니다. 그리고 이를 잘못 설정하는 데에는 두 가지 대칭적인 방법이 있습니다.

함정 1: 너무 거친(too coarse) — 그래프 안의 그래프

에이전트가 성장합니다. 이제 다섯 개의 분기, 세 개의 도구(tools), 루프(loop), 하위 결정(sub-decisions)을 갖게 됩니다. 모든 프레임워크가 유도하는 당연한 조치는 에이전트에게 자체적인 내부 그래프를 부여하는 것입니다. 그러고 나서 나중에는, 그 내부의 그래프 안에 또 다른 그래프를 넣게 됩니다.

이것은 자연스럽게 느껴집니다. 하지만 이는 멀티 에이전트 시스템이 조용히 모놀리스(monolith)로 변해가는 방식이기도 합니다. 모든 것이 부모의 상태(state)를 공유합니다. 하위 그래프(sub-graph) 깊은 곳에서의 변경은 당신이 볼 수 없는 폭발 반경(blast radius)을 가집니다. 내부 조각을 격리하여 테스트할 수 없습니다. 왜냐하면 그것은 부모 내부에서만 존재하기 때문입니다. 확장할 수도, 넘겨줄 수도, 별도로 추론할 수도 없습니다. 경계(seam)가 없기 때문입니다. 그것은 오직 작성자만이 이해할 수 있는, 그리고 단 몇 주 동안만 유지되는 하나의 단단히 결합된(tightly-coupled) 유기체가 됩니다. (저는 임베디드 시스템에서

그렇지 않습니다. 오히려 의견이 불일치할 수 있는 경로가 더 많아질 뿐입니다. 오작동할 수 있는 핸드오프(hand-off)가 더 많아집니다. 끝에서 끝으로 쌓이는 지연 시간(latency)이 더 많아집니다. "이 40개의 에이전트 중 어떤 것이, 어느 단계에서 틀렸는가?"라는 질문이 더 많아집니다. 당신은 모놀리스(monolith)를 설계하지도 않았고 관찰할 수도 없는 분산 시스템(distributed system)과 맞바꾼 것입니다. 에이전트의 비용은 결코 그것을 생성하는 코드가 아닙니다. 그것은 에이전트가 뒤에 끌고 오는 조정(coordination) 비용입니다. 에이전트를 만드는 비용이 저렴해지면, 바로 그 비용이야말로 당신이 인지하지 못하게 되는 바로 그 요소가 됩니다.

실제 기술: 가치를 증명하는 경계선을 긋는 것

두 가지 함정은 모두 동일한 실패, 즉 판단(judgment call)을 회피하는 것입니다. 기술이란 그 중간에 앉아 의도적으로 경계선이 어디에 위치해야 하는지 결정하는 것입니다.

저의 규칙은 다음과 같습니다: 단순할 때는 노드(node)로 유지하십시오. 그러다 스스로 그 노드에 별도의 그래프(graph)를 부여하고 있다는 사실을 깨닫는 바로 그날, 프로토콜(A2A, Agent-to-Agent) 뒤에 있는 독립적인 에이전트로 승격시키십시오. 그 전에는 절대 안 됩니다. 그 순간은 코딩 결정이 아닙니다. 해당 구성 요소가 부모 내부에서 살아남기에는 너무 커졌음을 설계가 당신에게 알려주는 것입니다.

이를 프로토콜 기반의 에이전트로 승격시키면, 중첩된(nested) 버전이 당신을 괴롭혔던 모든 것들이 쉬워집니다. 그것은 계약(contract)을 가지며, 독립적으로 테스트할 수 있고, 독립적으로 확장 및 버전 관리를 할 수 있으며, 다른 사람이 관리할 수 있습니다. 그리고 프로토콜을 통해 통신하기 때문에 고객의 에이전트를 포함한 누구나 호출할 수 있습니다. 반면 중첩된 서브 그래프(sub-graph)는 오직 부모에 의해서만 통신될 수 있습니다.

절제의 조항 (이것이 기술의 핵심입니다)

이것을 "모든 것을 에이전트로 분해하라"는 뜻으로 읽지 마십시오. 그것은 단지 중첩된 그래프(nested-graph)의 실수가 다른 옷을 입고 나타난 것일 뿐입니다. 즉, 가치를 증명하기도 전에 유지 관리해야 하는 성급한 경계(premature boundaries)를 만드는 것입니다.

판단은 타이밍에 달려 있습니다. 단순할 때는 단순한 노드로 유지하십시오. 승격의 신호는 구체적입니다: 노드에 별도의 그래프를 부여하고 있다는 사실을 스스로 깨닫는 바로 그날입니다. 그때 추출하십시오. 그 전에도 안 되고, 다섯 단계나 늦게 하는 것도 안 됩니다. 적절한 추상화 수준이란 가능한 한 경계선을 최소화하되, 결코 그보다 적게 만들지 않는 것을 의미합니다.

그리고 이 중 어느 것도 그것이 언제 깨질지는 알려주지 않습니다

이것을 실제로 배포하기 전에 한 가지 주의할 점이 있습니다. 적절한 추상화 (Abstraction)는 시스템을 '유지보수 가능하게 (maintainable)' 만들 뿐, '정확하게 (correct)' 만들지는 않습니다. 아름답게 팩터링 (factoring)된 멀티 에이전트 시스템 (Multi-agent system)이라 할지라도 여전히 확신을 가지고 틀릴 수 있습니다. 시스템이 '언제' 실패할지를 알려주는 유일한 방법은 경계면 (seams)에서의 의도적인 계획과 테스트이지, 직관 (vibes)이 아닙니다. 이는 그 자체로 하나의 독립된 분야이며, 관련 포스트를 곧 올릴 예정입니다. 지금 당장 기억하세요. 경계 (boundaries)를 테스트하고 있지 않다면, 당신은 추측하고 있는 것입니다.

요점 (The takeaway)

멀티 에이전트 (Multi-agent)에 관한 논의는 오케스트레이션 (orchestration)과 에이전트 수에 집착합니다. 시스템을 오래 지속시키는 엔지니어들은 그보다 덜 화려한 것, 즉 **추상화 수준 (the level of abstraction)**에 집착합니다. 너무 거칠면 (too coarse) 모놀리스 (monolith)가 되고, 너무 세밀하면 (too fine) 스웜 (swarm)이 됩니다. 전체 업무의 핵심은 경계가 어디에 위치해야 하는지를 아는 것, 그리고 그 이상을 긋지 않는 절제력을 갖는 것입니다.

에이전트는 쉬운 부분입니다. 추상화 수준이 바로 엔지니어링입니다.

멀티 에이전트 시스템을 구축하고 있다면: "별도의 에이전트로 만들 것인가"와 "노드 (node)로 유지할 것인가"를 결정하는 당신만의 신호는 무엇인가요? 다른 분들은 어떻게 선을 긋는지 듣고 싶습니다.

원문은 제 블로그에 게시되었습니다.