다중 에이전트 시스템을 위한 그래프 엔지니어링: 에이전트 작업 관리

다중 에이전트 시스템은 단순한 챗봇처럼 실패하지 않습니다. 이들은 핸드오프를 통해 실패합니다: 계획자가 잘못된 전문가를 호출하거나, 검색 단계에서 제약 조건을 건너뛰거나, 도구 노드가 과도하게 비용을 사용하거나, 장기 실행 작업이 비싼 작업을 동일한 프런티어 모델로 계속 라우팅하는 경우입니다.

그래서 그래프 엔지니어링이 프로덕션에서 에이전트를 구축하는 팀에게 실용적인 분야로 자리 잡고 있습니다. 그래프는 에이전트 작업을 위한 운영 지도입니다. 이는 어떤 노드가 작동할 수 있는지, 어떤 엣지를 사용할 수 있는지, 상태가 어디에서 유지되는지, 언제 사람이 다음 단계를 승인해야 하는지, 모델 호출이 제어된 API 계층을 통해 라우팅되어야 하는지를 정의합니다.

그래프 엔지니어링이 지금 중요한 이유

초기 에이전트 시스템은 종종 루프처럼 보였습니다: 목표를 수신하고, 모델을 호출하고, 도구를 사용하고, 결과를 검사하고, 반복하는 방식이었습니다. 현대 에이전트 시스템은 점점 더 구조화되고 있습니다. LangGraph와 같은 프레임워크는 상태, 노드 및 엣지를 통해 그래프를 설명합니다.. Google은 에이전트 간 상호 운용성(Agent2Agent interoperability)을 에이전트 핸드오프를 위해 홍보했습니다. MCP는 AI 애플리케이션이 도구, 데이터 및 워크플로.

와 연결되는 표준 방법을 제공합니다. 이러한 요소들은 에이전트 시스템을 더 강력하게 만들지만, 실행 경로를 이해하기 더 어렵게 만들기도 합니다. 에이전트가 위임, 분기, 재시도 및 외부 도구 호출을 할 수 있게 되면 시스템의 비용과 위험은 더 이상 단일 프롬프트에 국한되지 않습니다. 이는 그래프 전체에 분산됩니다.

그래프를 프로덕션 아키텍처로 취급하십시오.

프로덕션 에이전트 그래프는 엔지니어가 모든 프롬프트를 읽지 않고도 여섯 가지 질문에 답할 수 있을 만큼 명확해야 합니다:

• 어떤 노드가 모델을 호출할 수 있습니까?
• 어떤 노드가 도구 또는 외부 시스템을 사용할 수 있습니까?
• 어떤 전환이 인간의 검토를 필요로 합니까?
• 각 단계에 적합한 모델 또는 모델 클래스는 무엇인가요?
• 재시도, 대체, 예산 제한은 어디에서 적용되나요?
• 팀은 잘못된 실행 후에 무슨 일이 있었는지 어떻게 재구성할 것인가요?

이것은 단순히 관찰 가능성 연습이 아닙니다. 또한 제품 및 마진 연습이기도 합니다. 낮은 위험 분류 노드, 검색 노드, 코드 생성 노드, 최종 검토 노드는 반드시 동일한 모델을 사용할 필요가 없습니다. 모든 노드가 기본적으로 가장 비싼 모델을 사용할 경우, 그래프는 비용 증폭기가 됩니다.

그래프에서 ShareAI의 역할

ShareAI는 팀에게 150개 이상의 AI 모델에 액세스할 수 있는 단일 API를 제공하며, 스마트 라우팅, 대체, 마켓플레이스 신호, 토큰당 결제 가격을 지원합니다. 그래프 기반 에이전트 시스템에서 이는 그래프 자체를 다시 작성하지 않고도 모델 호출 계층을 더 쉽게 변경할 수 있게 합니다.

빌더는 ShareAI 외부에서 오케스트레이터, 앱 프레임워크, 데이터베이스, 큐, 에이전트 런타임을 유지한 다음, ShareAI API 추론이 필요한 노드에서 모델 액세스를 사용할 수 있습니다. 그래프는 여전히 워크플로를 제어합니다. ShareAI는 모델 액세스, 라우팅 유연성, 사용량에 따른 상업적 경로를 제어합니다.

이 구분은 중요합니다. ShareAI는 그래프 엔진이 아닙니다. 이는 에이전트 시스템이 발전함에 따라 팀이 모델 선택을 열어둘 수 있도록 돕는 모델 마켓플레이스 및 API 계층입니다.

실용적인 그래프 엔지니어링 체크리스트

다중 에이전트 시스템이 고객에게 도달하기 전에, 운영적 관점에서 그래프를 매핑하세요:

1. 모든 노드를 나열하세요. 에이전트, 결정론적 함수, 도구 호출, 승인 게이트, 라우터, 평가자, 백그라운드 작업을 포함하세요.
2. 모든 모델 호출에 라벨을 붙이세요. 프롬프트 목적, 예상 입력 크기, 예상 출력 크기, 허용 가능한 모델 클래스를 추적하세요.
3. 라우팅을 오케스트레이션과 분리하십시오. 그래프가 다음에 무엇을 해야 할지 결정하게 하고, 모델 계층이 특정 호출을 처리할 적합한 모델을 결정하게 하십시오.
4. 그래프 및 노드 수준에서 예산을 설정하십시오. 가능한 경우 실행당, 사용자당, 테넌트당, 노드당 제한을 설정하십시오.
5. 좁은 작업에는 저렴한 모델을 사용하십시오. 분류, 추출, 형식화 및 1차 검토는 종종 개방형 추론과 동일한 모델을 필요로 하지 않습니다.
6. 대체 동작을 정의하십시오. 재시도할 시점, 다른 모델로 라우팅할 시점, 실패로 종료할 시점을 결정하십시오.
7. 되돌릴 수 없는 작업에 대한 승인을 요구하십시오. 메시지 전송, 구매, 기록 삭제 또는 고객 데이터 변경과 같은 외부 부작용 전에 인간 체크포인트를 배치하십시오.
8. 그래프 ID를 기록하십시오. 그래프 버전, 실행 ID, 노드 ID, 모델 ID, 도구 ID, 테넌트 및 사용자 컨텍스트를 캡처하십시오.
9. 프롬프트와 도구를 버전 관리하십시오. 팀이 런타임에 사용된 정확한 지침과 도구 스키마를 재현할 수 있을 때만 그래프를 디버깅할 수 있습니다.
10. 출시 전에 마진을 검토하십시오. 에이전트가 고객 대상 제품의 일부인 경우, 모델 비용은 가격이 확정되기 전에 표시되어야 합니다.

빌더 관점: 그래프 비용이 제품 마진이 된다

빌더에게 그래프 엔지니어링은 신뢰성만이 아니라, AI 사용을 제품 비즈니스 모델과 일치시키는 것입니다.

앱이 고객에게 연구 에이전트, 지원 에이전트, 코딩 에이전트 또는 워크플로우 에이전트를 실행하도록 허용하는 경우, 각 그래프 경로는 다른 비용 프로파일을 생성할 수 있습니다. 짧은 요약 흐름은 기본 계획에 쉽게 포함될 수 있습니다. 깊은 다중 에이전트 조사는 사용 제한, 유료 추가 충전 또는 추가 요금이 필요할 수 있습니다.

모델이 ShareAI 빌더 콘솔 앱 소유자가 외부 애플리케이션을 ShareAI에 연결하고, AI 마진 또는 추가 요금을 설정하며, 고객이 ShareAI에 직접 사용료를 지불하도록 돕습니다. 이는 빌더에게 에이전트 그래프 내부의 모델 호출에서 지속 가능한 고객 가격 책정으로 가는 더 명확한 경로를 제공합니다.

비용 구조를 설계하기 전에 그래프를 설계하십시오.

에이전트 그래프는 조용히 성장하는 경향이 있습니다. 계획자는 또 다른 전문가를 얻습니다. 전문가는 또 다른 도구를 얻습니다. 지원 워크플로우는 인간 검토 경로를 얻습니다. 폴백은 두 번째 모델 호출이 됩니다. 이러한 선택 중 어느 것도 반드시 잘못된 것은 아니지만, 각각은 비용과 제어 표면을 변경합니다.

유용한 움직임은 그래프를 초기 단계에서 가시적으로 만드는 것입니다. 오케스트레이션을 명시적으로 유지하고, 모델 호출을 모델이 변경될 때 변경될 수 있는 레이어를 통해 라우팅하며, 에이전트 작업이 이해하기 어려울 정도로 비싸지기 전에 고객 대상 사용을 가격 책정하십시오.

탐색을 시작하십시오. ShareAI 모델 마켓플레이스에서 및 ShareAI 문서.

자주 묻는 질문

다중 에이전트 시스템을 위한 그래프 엔지니어링이란 무엇입니까?

그래프 엔지니어링은 다중 에이전트 워크플로우를 구성하는 노드, 엣지, 상태, 승인, 도구 호출 및 모델 호출을 설계하는 실천입니다. 이는 작업이 시스템을 통해 이동하는 방식에 초점을 맞추며, 각 프롬프트가 작성되는 방식에만 초점을 맞추지 않습니다.

그래프 엔지니어링은 프롬프트 엔지니어링과 어떻게 다릅니까?

프롬프트 엔지니어링은 모델에 제공되는 지침을 개선합니다. 그래프 엔지니어링은 다음에 실행될 에이전트 또는 기능, 사용 가능한 도구, 호출할 모델, 실행이 중지, 분기, 재시도 또는 승인을 요청해야 할 시점을 정의합니다.

그래프 엔지니어링 아이디어를 사용하려면 LangGraph가 필요합니까?

아닙니다. LangGraph는 그래프 기반 에이전트 오케스트레이션의 유용한 예이지만, 핵심 아이디어는 다중 에이전트, 도구, 모델 호출 및 결정 지점이 워크플로우에서 연결된 모든 시스템에 적용됩니다.

모델 라우팅은 에이전트 그래프에서 어디에 위치합니까?

모델 라우팅은 추론이 필요한 모든 노드에 속합니다. 그래프는 모델 호출이 필요하다고 결정하며, 라우팅 레이어는 비용, 지연 시간, 가용성 및 작업 적합성을 기반으로 해당 호출을 처리할 적합한 모델을 결정합니다.

ShareAI가 내 에이전트 오케스트레이터를 대체할 수 있습니까?

아니요. ShareAI는 오케스트레이터나 앱 프레임워크가 아닙니다. 이는 사람들이 주도하는 AI 마켓플레이스 및 API로, 빌더들이 자신이 소유하고 다른 곳에서 운영하는 애플리케이션에서 모델 호출을 액세스하고 라우팅할 수 있도록 돕습니다.

그래프 엔지니어링이 AI 비용을 어떻게 줄일 수 있습니까?

비용이 많이 드는 경로를 가시적으로 만듭니다. 팀이 어떤 노드가 모델을 호출하는지, 해당 노드가 얼마나 자주 실행되는지, 각 노드가 어떤 모델 클래스를 요구하는지 알게 되면, 더 간단한 작업을 저비용 모델로 이동시키고 고가치 단계에 최첨단 모델을 예약할 수 있습니다.

고객 대면 에이전트 그래프에서 빌더들이 무엇을 추적해야 합니까?

빌더들은 테넌트, 사용자, 그래프 버전, 노드, 모델, 토큰, 지연 시간, 비용, 폴백 이벤트 및 청구 가능한 사용 상태를 추적해야 합니다. 이러한 필드는 고객 지원을 더 쉽게 하고 AI 마진을 보호하는 데 도움이 됩니다.

그래프 엔지니어링이 프라이버시 우선 또는 자체 호스팅 앱에 관련이 있습니까?

네. 프라이버시 우선 및 자체 호스팅 앱은 데이터 흐름 위치, 사용되는 모델 엔드포인트 및 고객 행동이 승인되어야 하는지에 대한 명확한 제어가 여전히 필요합니다. 그래프는 이러한 경계를 문서화하는 데 도움을 줍니다.

MCP가 그래프 설계를 어떻게 변경합니까?

MCP는 에이전트에게 도구와 데이터 소스를 더 쉽게 노출할 수 있게 하지만, 액세스 제어, 도구 경계, 스키마 검토 및 노드별 권한에 대한 필요성을 증가시킵니다. 도구 액세스는 그래프 설계의 일부가 되어야 하며, 사후 고려 사항이 되어서는 안 됩니다.

그래프에 인간 승인이 포함되어야 할 때는 언제입니까?

인간 승인은 메시지를 외부로 보내거나, 청구 상태를 변경하거나, 데이터를 삭제하거나, 지원 사례를 확대하거나, 고객 계정에 영향을 미치는 결정을 내리는 등 되돌릴 수 없거나 고위험 행동 전에 필요합니다.

관리되는 에이전트 그래프를 향한 첫 번째 단계는 무엇입니까?

현재 워크플로를 노드와 전환으로 그린 다음, 모든 모델 호출, 도구 호출, 승인 지점, 재시도, 폴백, 예산 한도를 표시하세요. 이 맵은 일반적으로 첫 번째 비용 및 신뢰성 수정을 드러냅니다.