[SK네트웍스 Family 엔코아 AI캠퍼스] AI 오케스트레이션 캠프 1기_9월 5주차 회고

Об этом предложении

13주차 1. 배움 정리 Multi-Agent Orchestration 지난주에는 하나의 큰 작업을 여러 작업으로 나누고 각각을 적절한 Agent에게 맡기는 멀티에이전트 구조를 살펴봤다. 이번 주에는 여기에서 더 나아가 여러 Agent가 실제로 하나의 시스템처럼 동작하려면 어떻게 관리해야 하는지를 생각해봤다. 여러 Agent를 사용하는 것 자체가 Multi-Agent System 이라면, 이 Agent들이 어떤 순서로 작업하고 서로 어떤 정보를 주고받으며 결과를 어떻게 합칠지를 관리하는 것이 Multi-Agent Orchestration 에 가깝다. Goal ↓ Task Decomposition ↓ Agent 선택 ↓ Execution ↓ Communication ↓ Result Merge ↓ Evaluation 결국 핵심은 Agent의 숫자가 아니라 작업과 Agent 사이의 관계를 어떻게 정의하는가 인 것 같다. Supervisor, Router와 Handoff 여러 Agent 중 어떤 Agent가 작업해야 하는지를 정하는 방법도 여러 가지가 있다. Router 는 입력이나 현재 상태를 보고 적절한 Agent 또는 경로를 선택하는 역할로 볼 수 있다. → Research Agent Input → Router → Coding Agent → Review Agent Supervisor 는 조금 더 넓게 전체 목표와 진행 상태를 보고 하위 Agent들에게 작업을 배분하거나 다음 작업을 결정하는 역할을 할 수 있다. ┌→ Agent A Goal → Supervisor → Agent B └→ Agent C ↓ Result 반면 Handoff 는 한 Agent가 자신의 작업을 처리하다가 다른 Agent가 더 적합하다고 판단했을 때 작업의 제어권이나 필요한 Context를 넘기는 방식으로 볼 수 있다. Agent A ↓ 현재 작업 수행 ↓ Agent B가 더 적절함 ↓ Handoff ↓ Agent B 세 가지 모두 Agent를 연결하지만 역할이 조금 다르다. Router → 어디로 보낼 것인가 Supervisor → 전체 작업을 어떻게 조율할 것인가 Handoff → 현재 작업을 누구에게 넘길 것인가 이렇게 구분하니 멀티에이전트 오케스트레이션에서 "Agent를 연결한다"는 말 안에도 여러 종류의 관계가 있다는 것을 이해하기 쉬웠다. Workflow와 Task Graph 멀티에이전트의 실행 구조는 Graph 형태로 표현할 수 있다. Node → Agent / Tool / Task Edge → 작업 사이의 관계 예를 들어 순차 작업은 A → B → C 이고 독립적인 작업은 → B → A → → E → C → → D → 처럼 Fan-out / Fan-in 구조로 표현할 수 있다. 작업 간 선후 관계만 있고 순환이 없다면 DAG(Directed Acyclic Graph) 형태로 생각할 수도 있다. 이때 중요한 것은 Agent보다 먼저 Task Dependency 를 보는 것이다. Task A ↓ Task B는 A가 필요한가? ↓ YES → Dependency NO ↓ 병렬 실행 가능 여부 확인 작업의 Dependency가 강하면 순차 실행이 필요하고, 서로 독립적이면 병렬 처리가 가능하다. 그래서 멀티에이전트의 병렬성도 Agent를 많이 만든다고 생기는 것이 아니라 작업 자체에 존재하는 독립성을 발견했을 때 활용할 수 있는 것 이라고 이해하는 편이 맞는 것 같다. State와 Context 여러 Agent가 작업하려면 현재 작업이 어떤 상태인지 공유할 필요도 있다. Context 는 현재 Agent가 판단하는 데 필요한 정보에 가깝고, State 는 Workflow 전체에서 현재 어떤 일이 진행되고 있는지를 표현하는 정보에 더 가깝게 볼 수 있다. State 현재 Task 완료된 Task 각 Agent의 결과 오류 여부 다음 실행 대상 각 Agent에게 전체 State를 모두 전달할 필요는 없다. 예를 들어 Research Agent에게 Coding Agent 내부의 모든 실행 기록까지 전달하는 것은 불필요할 수 있다. Global State ↓ 현재 Agent에게 필요한 정보 선택 ↓ Local Context ↓ Agent 이전에 Context를 공부하면서 생각했던 것처럼 필요한 정보만 적절한 시점에 전달하는 것 이 여러 Agent가 존재할 때 더 중요해지는 것 같다. A2A와 MCP Agent를 연결하는 방법을 살펴보면서 A2A 와 MCP 도 다시 구분해서 생각할 수 있었다. 둘 다 시스템 사이를 연결하기 위한 방법이지만 연결하려는 대상이 다르다. MCP Agent ↓ Tool / Resource / External System A2A Agent ↓ Agent MCP는 Agent가 외부 Tool이나 데이터에 접근할 수 있는 인터페이스를 제공하는 데 가깝고, A2A는 서로 독립적으로 동작하는 Agent가 작업을 요청하거나 결과를 주고받기 위한 통신에 초점이 있다. 따라서 하나의 멀티에이전트 시스템에서도 둘을 같이 사용할 수 있다. Agent A │ │ A2A ↓ Agent B │ │ MCP ↓ Tool / DB / API 이렇게 보면 A2A와 MCP는 경쟁 관계라기보다 서로 다른 연결 계층을 해결하는 기술 로 보는 것이 자연스러운 것 같다. 여러 Agent를 연결할수록 Interface가 중요해진다 Agent A가 Agent B에게 결과를 넘긴다고 해서 문자열 하나만 전달하면 항상 제대로 협업할 수 있는 것은 아니다. { task, input, constraints, result, status, metadata } 처럼 서로 약속된 형태가 필요할 수 있다. 결국 Agent 사이에서도 기존 소프트웨어에서 사용하던 Interface 또는 Contract 개념이 중요해진다. Agent A ↓ Contract ↓ Agent B 내부 구현이 바뀌어도 Contract가 유지된다면 다른 구성요소에 미치는 영향을 줄일 수 있다. 이것은 Agent를 독립적인 모듈로 교체하기 위해서도 중요하다. Agent v1 ↓ 같은 Interface ↓ Agent v2로 교체 가능 그래서 모듈화에서 중요한 것은 단순히 파일이나 서비스를 분리하는 것이 아니라 분리된 요소 사이에 안정적인 경계를 만드는 것 이라고 생각한다. Trace와 Observability Agent가 하나일 때도 Trace가 필요하지만 여러 Agent가 존재하면 실행 경로가 훨씬 복잡해진다. → Agent A → Tool A User → Router → Agent B → Tool B → Agent C → Tool C ↓ Merge 최종 결과만 보면 어떤 Agent가 선택됐고 어디에서 문제가 생겼는지 알기 어렵다. 그래서 멀티에이전트에서는 Trace , Logs , Metrics 같은 정보를 통해 실행을 관찰할 필요가 있다. Trace → 어떤 실행 경로를 거쳤는가 Logs → 어떤 이벤트와 오류가 발생했는가 Metrics → 얼마나 오래 걸렸고 얼마나 많은 자원을 사용했는가 이를 합쳐서 보면 Observability는 단순히 시스템이 실행됐는지를 보는 것이 아니라 시스템 내부에서 어떤 일이 일어났는지를 외부에서 판단할 수 있게 만드는 것 에 가깝다. 멀티에이전트에서는 Agent마다 모델 호출과 Tool 사용이 추가될 수 있기 때문에 Latency나 Token Cost 같은 값도 관찰할 필요가 있다. Evaluation도 여러 단계가 필요하다 멀티에이전트의 결과가 좋다고 해서 반드시 좋은 시스템이라고 할 수는 없다. 예를 들어 System A Agent A → Agent B → Result 와 System B Agent A → Agent C → Agent D → Agent B → Result 가 같은 결과를 만들었다면 최종 결과만으로는 두 시스템의 차이를 확인하기 어렵다. 그래서 평가도 여러 수준으로 볼 필요가 있다. Result Quality → 최종 결과가 좋은가 Task Quality → 각 Agent가 맡은 작업을 잘했는가 Trajectory → 적절한 실행 경로를 사용했는가 Latency → 실행 시간이 적절한가 Cost → 필요 이상의 자원을 사용하지 않았는가 Reliability → 반복해도 안정적으로 동작하는가 이전에 생각했던 Prediction → Action → Observation → Delta 구조도 여기에서 사용할 수 있을 것 같다. Expected Result vs Actual Result Expected Process vs Actual Process 결과의 차이와 과정의 차이를 따로 관찰할 수 있다. 핵심 개념들을 하나의 구조로 연결해보기 이번 주의 개념들을 다시 연결해보면 다음과 같이 볼 수 있을 것 같다. [Goal] ↓ Task Decomposition ↓ Task Graph / | \ Dependency Parallel Sequence ↓ Multi-Agent Orchestration ↓ ┌─────────────┼─────────────┐ Router Supervisor Handoff └─────────────┼─────────────┘ ↓ Agent ↓ ┌─────────┴─────────┐ A2A MCP ↓ ↓ Agent Tool / Data └─────────┬─────────┘ ↓ State Update ↓ Trace / Metrics / Logs ↓ Evaluation ↓ Feedback 각 개념을 이렇게 놓으면 서로의 역할이 조금 더 명확해진다. Task Decomposition → 무엇으로 나눌 것인가 Task Graph → 나눈 작업은 어떤 관계인가 Orchestration → 전체 실행을 어떻게 조율할 것인가 Router / Supervisor / Handoff → 실행 주체를 어떻게 선택하고 전환할 것인가 State → 현재 시스템은 어떤 상태인가 Context → 현재 Agent에게 어떤 정보가 필요한가 A2A → Agent와 Agent를 어떻게 연결할 것인가 MCP → Agent와 Tool을 어떻게 연결할 것인가 Trace / Observability → 무엇이 일어났는지 어떻게 알 것인가 Evaluation → 잘했는지 어떻게 판단할 것인가 여기까지 정리하고 나면 그 위에서 조금 더 추상적인 구조도 보인다. Goal ↓ Decompose ↓ Coordinate ↓ Execute ↓ Observe ↓ Evaluate ↓ Update ↺ 지난주에는 하나의 작업을 적절하게 나누고 여러 실행 주체에게 위임하는 것 이 중요하다고 생각했다. 이번 주에는 거기에서 더 나아가 나눈 작업과 실행 주체 사이의 관계, 상태, 인터페이스, 관찰과 평가까지 있어야 하나의 시스템이 된다 는 생각을 하게 되었다. 즉 멀티에이전트의 핵심은 Agent가 많다는 것이 아니라 독립적인 여러 실행 주체를 하나의 목적 아래 안정적으로 조율할 수 있는 구조 에 있는 것 같다. 2. 문제 및 개선 문제 구성요소를 많이 추가하면 시스템이 좋아질 것이라는 생각을 하기 쉽다. Multi-Agent, A2A, MCP, Supervisor, Observability처럼 적용할 수 있는 기술과 개념이 많아지면서 모두 사용해보고 싶어진다. 하지만 각각을 추가할 때마다 상태 관리, 통신, 오류 처리와 평가해야 할 범위도 같이 증가한다. 오케스트레이션 구조를 먼저 만들고 실제 작업의 특성을 나중에 맞추기 쉽다. 병렬 처리나 Supervisor 구조가 좋아 보여도 실제 Task의 Dependency가 강하다면 그 구조를 사용할 이유가 적을 수 있다. Agent 사이에 전달할 Context의 범위를 정하기 어렵다. 정보가 부족하면 다음 Agent가 제대로 판단하지 못하지만 너무 많은 정보를 넘기면 Context가 커지고 불필요한 정보까지 영향을 줄 수 있다. 결과와 과정 중 어디까지 평가해야 하는지 기준이 아직 명확하지 않다. 모든 Trace를 상세하게 평가하면 비용이 커지고, 최종 결과만 보면 실행 과정의 문제를 놓칠 수 있다. 개선 기술을 추가하기 전에 해결하려는 문제를 먼저 적는다. Problem ↓ 필요한 역할 ↓ 가장 단순한 구조 ↓ 필요한 기술 A2A를 사용한다 보다 독립적인 Agent 사이에서 표준화된 통신이 필요하다 가 먼저 와야 한다. Agent보다 Task Graph를 먼저 만든다. Goal ↓ Tasks ↓ Dependency ↓ Workflow ↓ Agent Assignment 어떤 Agent를 쓸지보다 어떤 작업이 있고 서로 어떤 관계인지부터 정하는 것이 좋을 것 같다. Global State와 Local Context를 구분한다. 전체 시스템에서는 필요한 정보를 유지하되 각 Agent에게는 현재 작업에 필요한 정보만 전달하는 방향을 실험해보고 싶다. 평가도 목적에 따라 필요한 수준만 선택한다. 결과가 중요한 작업 → Result 중심 비용이 중요한 작업 → Cost / Latency 추가 안정성이 중요한 작업 → Trace / Reliability 추가 모든 평가를 항상 하는 것보다 작업의 목적에 따라 필요한 평가 항목을 선택하는 것이 좋을 것 같다. 3. 소감 이번 주에는 멀티에이전트를 여러 AI가 협력하는 기능으로 보는 것에서 조금 더 벗어나 실제 시스템의 관점에서 생각해볼 수 있었다. Router , Supervisor , Handoff , State , A2A , MCP , Trace , Evaluation 같은 용어를 하나씩 보면 서로 다른 기술처럼 보이지만 다시 연결해보면 결국 하나의 질문으로 모인다. 여러 개의 독립적인 실행 주체를 어떻게 하나의 목표를 향해 움직이게 할 것인가? Agent를 여러 개 만드는 것 자체는 생각보다 어려운 문제가 아닐 수도 있다. 오히려 어떤 작업을 나눌지, 어떤 Agent가 맡을지, 어떤 정보를 전달할지, 실패하면 어떻게 처리할지, 마지막에 무엇을 기준으로 잘했다고 판단할지가 더 어려운 문제인 것 같다. 이런 구조를 공부하면서 기존 소프트웨어 시스템과 비슷한 부분도 많이 보였다. 함수나 서비스 사이에는 Interface가 있고, 분산 시스템에는 통신과 상태 관리가 필요하며, 복잡한 시스템에서는 Observability가 필요하다. Agent가 새로운 실행 주체로 추가됐다고 해서 기존 소프트웨어의 원리가 사라지는 것이 아니라 오히려 기존에 사용하던 개념들을 Agent에 맞게 다시 적용하는 부분도 많은 것 같다. 지난주에는 모든 일을 하나의 주체가 잘하는 것보다 일을 적절하게 나누고 연결하는 것이 중요하다. 고 생각했다. 이번 주에는 여기에서 한 단계 더 나아가 잘 나누는 것만으로는 부족하고, 나뉜 것들이 어떤 규칙으로 상호작용하고 전체 상태를 어떻게 관찰할 것인지까지 정의해야 시스템이 된다. 는 생각을 하게 되었다. 그리고 그 구조를 만들 때도 처음부터 복잡한 멀티에이전트 시스템을 만드는 것보다 Single Agent ↓ Task 분리 ↓ 작은 Workflow ↓ 필요한 Agent 추가 ↓ 관찰 ↓ 실제로 필요한 관리 구조 추가 처럼 복잡도가 필요한 만큼만 확장하는 것이 더 좋은 방법일 것 같다. 결국 새로운 용어와 기술을 많이 아는 것도 중요하지만, 각 개념이 어떤 문제를 해결하고 전체 시스템의 어디에 위치하는지를 이해하는 것 이 더 중요하다고 생각한다.