Chapter 15 · Agent Frameworks — ADK, CrewAI, and LangGraph

세 개의 사고방식

『Agentic Architectural Patterns for Building Multi-Agent Systems』 15장 — Ali Arsanjani, Juan Pablo Bustos, Thomas Kurian

이론적 구성물을 기능하는 운영 준비 애플리케이션으로 옮기려면 에이전트 생성·실행·통신의 밑바닥 복잡성을 다뤄 줄 실무 도구가 필요하다. 바닥부터 짓는다면 역할 정의, 상태와 기억, 워크플로 조율, LLM 통합, 도구 사용, 에이전트 간 통신까지 수많은 움직이는 부품을 관리해야 한다. 프레임워크는 그 기초 배관을 다시 발명하지 않아도 되게 해 준다. 다만 프레임워크마다 세계를 보는 방식이 다르다.

01

Three frameworks · core abstractions

세 프레임워크 — 저마다의 핵심 추상

빠르게 진화하는 에이전틱 AI 지형에서 여러 프레임워크가 등장했고, 저마다 고유한 철학과 강점과 대상 용례를 갖는다. 여기서 다루는 셋은 망라적인 목록이 아니라 예시다. 이 책이 논한 설계 패턴은 보편적이며 다른 프레임워크에도 일반화된다.

ADK 운영 서비스 에이전트 서비스 콜백 · 미들웨어 가드레일 에이전트 런타임 · 관리 상태 배포 가능한 부품 CREWAI 역할 기반 팀 매니저 에이전트 역할 A 역할 B 역할 C 맥락으로 암묵 전달 협업하는 크루 LANGGRAPH 상태 기계 노드 1 노드 2 노드 3 순환 State — 모든 노드에 명시적으로 전달 순환하는 그래프

〈세 추상〉 통제 흐름의 모양이 곧 그 프레임워크의 세계관이다.

Google ADK

에이전트 개발 키트

Google · 2024 시제품 / 2025 공개

AI 에이전트를 짓고 배포하는 구조화된 환경을 제공한다. 운영 준비를 염두에 두고 설계됐으며, 특히 멀티 에이전트 시나리오에서 에이전트 정의·생애주기 관리·도구 통합·통신을 위한 부품을 갖춘다.

Agent지시·도구·과업 처리를 포함한 핵심 로직의 기반 구조
Tools외부 세계와 상호작용할 함수·API의 정의와 등록
PlannerGemini 등 LLM과 통합한 추론 루프. 내장 플래너 또는 맞춤 로직
State상호작용을 가로지르는 상태와 기억의 유지
A2AAgent-to-Agent 상호운용 프로토콜의 네이티브 지원
Runtime배포·과업 분배·병렬 실행·재시도를 관리하는 실행 환경

CrewAI

역할 연기하는 크루

CrewAI (João Moura 창립) · 2023 오픈소스

역할 연기 에이전트를 통한 협업 지능에 명시적으로 초점을 둔다. 복잡한 과업은 흔히 쪼개어 구체적 역할과 책임, 심지어 “배경 이야기”를 가진 에이전트에게 배정할 수 있다는 철학이다.

Agent역할·목표·배경 이야기, 쓰는 LLM, 접근 가능한 도구로 정의
Task설명과 기대 출력을 갖고 특정 에이전트에 배정되는 과업. 연쇄 가능
ToolBaseTool을 상속하는 경우가 많다
Crew에이전트와 과업의 집합. 협업 방식을 정의한다
Process순차(sequential) 또는 위계(hierarchical) — 매니저 에이전트가 위임

LangGraph

상태를 가진 그래프

LangChain · 2024

LangChain을 확장해 상태를 가진 다중 행위자 애플리케이션을 그래프로 짓는다. LangChain이 선형 연쇄에 초점을 둔다면, LangGraph는 순환(cycle)을 허용한다. 에이전트는 흔히 루프하고 재시도하고 현재 상태에 근거해 다음 단계를 동적으로 결정해야 하기 때문이다.

StateGraph워크플로 그래프를 나타내는 핵심 객체. 상태를 보유한다
StateTypedDict 등으로 정의된 데이터 구조. 진행에 관련된 모든 정보
Node단계나 행위자. 현재 상태를 받아 행동하고 상태 갱신을 반환
Edge노드 사이의 전이를 정의
Conditional분기 로직. 상태나 출력에 따라 다른 노드로 라우팅

Enterprise caution · CrewAI

기업 아키텍트에게 중요한 고려사항이 하나 있다. 이 “페르소나 주도” 스타일은 모델 출력에 변이를 들여올 수 있다. 대출 심사처럼 규제받거나 판돈 큰 워크플로에 CrewAI를 적용할 때는, 엄격한 도구 계약과 엄정한 테스트로 그 유연성을 상쇄해 결정론적이고 준수하는 결과를 보장하는 것이 결정적이다.

LangGraph는 특히 다음이 해당할 때 잘 맞는다.

  • 명시적 상태 관리가 결정적일 때
  • 순환 절차가 필요할 때 — 에이전트가 자기 출력을 성찰하고 재시도하거나, 사람 개입(HITL) 상호작용이 있을 때
  • 분기와 동적 라우팅을 포함한 복잡한 통제 흐름이 요구될 때
  • 여러 에이전트나 행위자(사람 포함) 사이의 상호작용을 모델링해야 할 때
02

Similarities and differences

같은 점과 다른 점 — 차이는 “핵심 추상”에 있다

공통의 개념적 토대

Common 01

추론 엔진으로서의 LLM

셋 모두 핵심에서 LLM을 에이전트의 “뇌”로 쓴다. 프롬프트와 현재 상태와 가용 도구에 근거해 추론하고 계획하고 다음에 무엇을 할지 결정하는 책임을 진다.

Common 02

도구 통합

셋 모두 함수 호출 또는 도구 사용 패턴 위에 세워졌다. DB 검색, 파일 읽기, API 호출 같은 세상에 행동하는 능력은 도구를 쥐어 줌으로써 생긴다.

Common 03

목표 지향

단순한 일회성 질의응답 도구가 아니다. 개발자가 정의한 구체적 목표를 이루기 위해 복잡한 다단계 과업을 실행하는 애플리케이션을 짓도록 설계됐다.

The real difference

핵심 추상 — 워크플로를 표상하는 심적 모형

일차적 차이는 핵심 추상에 있다. 곧 에이전틱 워크플로를 표상하는 데 쓰는 심적 모형이다. 이 근본적 차이가 통제 흐름부터 상태 관리까지 모든 것에 영향을 미친다.

핵심 철학과 추상

CrewAI

역할 기반 협업

추상은 전문가 팀이다. 에이전트를 역할(예: “선임 대출 심사역”), 목표(예: “대출 신청을 분석하라”), 배경 이야기(예: “당신은 꼼꼼한 분석가다…”)로 정의한다. 사람 팀을 모사하는 워크플로에 대단히 직관적이며, 협업 자체가 중심 기능이다.

LangGraph

상태를 가진 그래프

추상은 순서도 또는 상태 기계다. 노드(에이전트나 함수)와 엣지(그 사이의 경로)를 정의한다. 초점이 에이전트에서 절차로 옮겨간다. 그 힘은 애플리케이션의 상태를 명시적으로, 통제 흐름을 결정론적으로 만드는 데 있다.

Google ADK

운영 준비된 에이전트

추상은 에이전트 자신이며, 모듈적이고 테스트 가능하고 배포 가능한 소프트웨어 부품으로 다뤄진다. 소프트웨어 엔지니어에게 익숙한 코드 우선 접근이다. 기업 등급 견고성을 위해 두 기제에 기댄다 — 콜백(능동 필터링·PII 탐지·HITL 통제를 위한 미들웨어)과 워크플로 에이전트(순차·반복·병렬 과업의 골격).

통제 흐름과 순환 행동

  • CrewAI는 통제 흐름을 상위 수준에서 관리한다. 프로세스를 순차(과업 1 → 2 → 3) 또는 위계(매니저 에이전트가 위임)로 정의한다. 선형이거나 단순한 위임 과업에 단순하고 효과적이다.
  • LangGraph완전하고 세밀한 통제를 준다. 워크플로가 그래프이므로 순환·분기·루프를 쉽게 만든다. “검증이 실패하면 거절 노드로, 아니면 신용 조회 노드로” 같은 조건부 엣지를 정의할 수 있다. 오류를 관리하고 루프하는 이 능력이 많은 고급 패턴의 핵심 요구사항이다.
  • ADK는 둘의 균형을 잡는다. SequentialAgent 같은 결정론적 워크플로를 돌릴 수도, 에이전트 자신이 다음 단계를 정하는 동적·LLM 주도 계획을 허용할 수도 있다. 후자는 에이전트 런타임이 관리한다.

상태 관리 — 명시 · 암묵 · 관리

Explicit

LangGraph의 초능력

명시적 상태 관리가 초능력이다. 모든 정보를 담는 State 객체를 정의하고, 이 전체 상태가 모든 노드에 전달된다. 각 노드가 작업하고 갱신을 반환한다. 디버깅이 훨씬 쉬워진다. 매 단계마다 상태를 들여다볼 수 있기 때문이다.

Implicit

CrewAI의 암묵 전달

한 과업의 출력이 자동으로 형식이 맞춰져 그것에 의존하는 다음 과업의 맥락으로 전달된다. 단순한 연쇄에는 빠르지만, LangGraph의 명시적 상태보다 직접적 통제와 검사가 덜하다.

Managed

ADK의 관리 상태

에이전트 런타임과 세션 서비스가 상호작용을 가로질러 상태와 기억을 영속화할 책임을 진다. 이 복잡성을 개발자에게서 추상화하고, 장기 실행 에이전트도 멈춘 자리에서 이어가게 보장한다.

03

Comparative analysis

비교 분석 — 생태계와 기술의 두 층

구분Google ADKCrewAILangGraph
주 후원 Google CrewAI (João Moura 창립) LangChain
공개 시점 2024 시제품 / 2025 공개 2023 오픈소스 출시 2024
핵심 철학과 초점 운영 등급의 견고한 에이전트를 짓고 평가하고 배포하는 포괄적 오픈소스 툴킷. Google 생태계(Gemini·Vertex AI)에 최적화됐으나 모델 불가지론으로 설계됐다. 역할 연기하는 자율 에이전트를 조율하는 프레임워크. 에이전트들이 “크루”로 함께 목표를 이루는 협업 지능을 강조한다. LangChain의 확장. 상태를 가진 다중 행위자 애플리케이션에 강하다. 순환 절차와 복잡한 통제 흐름을 그래프(상태 기계)로 모델링하는 데 탁월하다.

〈표 15.1〉 에이전틱 프레임워크 비교 — 생태계와 철학

기능Google ADKCrewAILangGraph
핵심 추상 운영 등급 에이전트와 런타임 역할 연기 팀(“크루”) 상태를 가진 그래프(“상태 기계”)
통제 흐름 플래너 주도. 에이전트 런타임이 관리. 순차 또는 병렬 가능 상위 수준 프로세스(순차 또는 위계) 세밀함. 그래프 엣지로 정의. 순환과 분기에 탁월
상태 관리 관리형 — 에이전트의 세션과 런타임이 처리 암묵 — 맥락을 통해 과업 사이로 자동 전달 명시 — 중앙 State 객체가 각 노드에 전달되고 갱신됨
콜백과 훅 미들웨어·인터셉터 패턴. 콜백이 LLM 호출 전후로 입출력을 가로채는 “가드레일” 노릇을 한다.

핵심 역량 — 전송 중 데이터 수정(PII 마스킹) 또는 LLM 자체를 우회(캐싱)
이벤트 기반 훅. on_task_start, on_task_end 등 특정 생애주기 이벤트에서 발동한다.

핵심 역량 — 핵심 에이전트 로직을 바꾸지 않고 관찰 가능성과 부수 효과(로깅, UI 갱신, 웹훅 트리거)
상태 리스너와 인터럽트. 추적(LangSmith)에는 콜백을 쓰되 통제에는 “인터럽트”에 기댄다.

핵심 역량 — 특정 노드에서 그래프를 일시 정지(체크포인팅)해 재개 전 HITL 입력을 기다림
가장 잘 맞는 곳 운영 시스템, 기업 통합(특히 Google Cloud), 견고하고 테스트 가능한 에이전트 협업 과업의 빠른 시제품, 역할이 정의된 워크플로(예: “연구자”, “작성자”) 복잡하고 동적인 워크플로, 명시적 오류 처리, 루프, HITL

〈표 15.2〉 ADK · CrewAI · LangGraph의 기술적 비교

04

Re-implementing the loan agent

같은 문제, 두 구현 — 차이가 드러나는 자리

차이를 구체적으로 드러내기 위해, 13장의 대출 처리 시스템을 CrewAI와 LangGraph로 각각 다시 구현한다. 목표는 그대로다. applicant_iddocument_id를 받아 문서 내용을 가져오고 최종적이고 감사 가능한 대출 결정을 낸다.

13~14장에서 ADK로 기준 아키텍처를 충분히 다뤘으므로 여기서 반복하지 않는다. 대신 같은 문제를 서로 다른 프레임워크 패러다임으로 어떻게 접근하는지에 집중한다.

CrewAI · 역할과 과업

매니저가 위임하고, 맥락이 흐른다

도구는 BaseTool을 상속하는 파이썬 클래스로 정의된다. 그다음 역할·목표·배경 이야기를 가진 에이전트를 만들고, 과업을 정의해 context 매개변수로 의존 관계를 잇는다.

  • task_validate — 설명에 {document_content} 자리표시자를 두어 가져온 JSON을 받는다
  • task_creditcontext=[task_validate]
  • task_riskcontext=[task_validate, task_credit]
  • task_compliancecontext=[task_validate, task_risk]

매니저 에이전트allow_delegation=True로 팀을 조율하고 최종 보고서를 작성한다. 과업에 에이전트를 직접 배정하지 않는다. 매니저가 위임한다.

LangGraph · 노드와 엣지

상태가 흐르고, 조건이 갈린다

먼저 LoanGraphState를 정의한다. 문서 내용, 검증 상태, 신용점수, 위험 점수와 등급, 준수 상태, 최종 결정, 그리고 오류를 명시적으로 추적하는 error 필드까지.

  • node_fetch_document — 문서를 가져온다. 절차가 깔끔하게 시작된다
  • node_validate_document — 검증 도구를 부르고 추출 데이터나 오류로 상태를 갱신한다
  • node_check_credit · node_assess_risk — 이후 노드는 진행 전에 오류를 확인한다
  • node_compile_report / node_compile_rejection — 성공과 실패의 두 종점

node_assess_riskLLM을 직접 써서 위험 평가를 생성한다. 결정론적 도구 호출 옆에 생성적 단계를 나란히 통합할 수 있음을 보여준다.

구현 예시 · LangGraph 그래프와 조건부 엣지
from langgraph.graph import StateGraph, END

workflow = StateGraph(LoanGraphState)

# 노드 추가
workflow.add_node("fetch_doc",         node_fetch_document)
workflow.add_node("validate_doc",      node_validate_document)
workflow.add_node("check_credit",      node_check_credit)
workflow.add_node("assess_risk",       node_assess_risk)
workflow.add_node("check_compliance",  node_check_compliance)
workflow.add_node("compile_report",    node_compile_report)     # 성공 종점
workflow.add_node("compile_rejection", node_compile_rejection)  # 실패 종점

workflow.set_entry_point("fetch_doc")

# 조건부 엣지 로직 — 상태의 error 필드를 본다
def decide_after_fetch(state: LoanGraphState):
    return "reject" if state.get("error") else "continue"

def decide_after_validation(state: LoanGraphState):
    return "reject" if state.get("error") else "continue"

def decide_after_compliance(state: LoanGraphState):
    # 준수 노드가 오류를 설정했다면(비준수) 거절한다
    return "reject" if state.get("error") else "continue"

# 엣지 연결 — 실패하면 즉시 거절 노드로
workflow.add_conditional_edges("fetch_doc", decide_after_fetch,
    {"continue": "validate_doc", "reject": "compile_rejection"})
workflow.add_conditional_edges("validate_doc", decide_after_validation,
    {"continue": "check_credit", "reject": "compile_rejection"})

The decisive difference

실패했을 때 무엇이 달라지는가

상태의 error 키에 근거한 조건부 엣지 덕에, 가져오기나 검증이 실패하면 그래프가 즉시 거절 노드로 라우팅한다. 유효하지 않은 데이터에 대해 신용 조회나 위험 평가 같은 불필요한 도구 호출을 막는다.

이 명시적 라우팅은 손에 잡히는 효율 이득이다. 실패 즉시 실행을 중단해 불필요한 API 비용과 지연을 없앤다. 최초 검증 오류에도 중간 에이전트들이 계속 작동했던 CrewAI 예제와 직접적으로 대비된다.

Tip · temperature=0.0

이 에이전트에는 의도적으로 temperature=0.0을 설정한다. 정밀한 도구 사용과 구조화된 출력(JSON 등)에 기대는 에이전틱 워크플로에서는 무작위성 최소화가 결정적이다. 다만 temperature=0.0이 변이를 크게 줄이지만 100% 결정론적 행동을 보장하지는 않는다. GPU 부동소수점 연산의 내재적 비결정성 때문이다. 그럼에도 논리와 조율 과업에 가능한 최대의 안정성을 제공한다.

Tip · 구조화 출력

Pydantic 스키마를 모델에 넘기면 유효한 JSON 객체를 반환하도록 강제할 수 있다(예: {"risk_level": "LOW"}). 깨지기 쉬운 문자열 파싱 로직 없이 출력이 하류 요구사항과 일치함을 보장한다.

그래프 기반 접근은 이 특정 워크플로에서, 특히 오류 처리에 관해 더 단순한 CrewAI 프로세스보다 우월한 견고성과 추적 가능성을 제공한다.

05

Observability & responsible AI

관찰 가능성 — 왜 그랬는지 모르면 공정도 안전도 없다

프레임워크를 고르는 일은 개발 경험만의 문제가 아니다. 결과물을 관리하고 감시하고 통치하는 능력의 문제다. 비결정성이 상수인 에이전틱 AI에서 관찰 가능성은 책임 있는 AI의 주춧돌이다.

The premise

추적할 수 없으면 보장할 수 없다

에이전트가 왜 그런 결정을 내렸는지 추적할 수 없다면, 그것이 공정한지 안전한지 준수하는지 보장할 수 없다.

LangSmith

LangGraph와 CrewAI

LangChain 생태계는 LangSmith와 네이티브로 통합되도록 지어졌다. 복잡한 LLM 애플리케이션 추적에 특화된 관찰 가능성 플랫폼이다. LangGraph의 상태가 명시적이기 때문에 그 추적이 특히 선명하다.

Cloud Trace · OpenTelemetry

Google ADK

Google Cloud 콘솔의 Trace 뷰가 에이전트의 내부 “생각–행동–관찰” 루프를 노출한다. 최종 답만 보는 것이 아니라, getLoanStatus 대신 getUserBalance를 불렀는지까지 정확히 볼 수 있다.

세 가지 축 — 공정성 · 안전 · 책임성

Fairness

공정성 검증

인구통계학적 동등성 테스트 — CI/CD 파이프라인에 공정성 평가 단계를 넣는다. 다양한 인구집단의 질의로 구성한 “골든 데이터셋”에 에이전트를 돌려, 버전 승격 전에 응답 품질이 집단을 가로질러 일관된지 수학적으로 측정한다.

이질적 영향 점검 — 배포 전에 다양한 신청인 프로필의 골든 데이터셋으로 돌려, 우편번호나 성별 같은 보호 속성이 명시적 특성으로 쓰이지 않더라도 승인 로직이 이질적 영향을 보이지 않는지 확인한다.

Safety

안전과 견고성

LangGraph의 조건부 엣지가 “빠른 실패” 로직을 강제하는 프로그램적 안전 패턴 노릇을 한다. 불완전하거나 오염된 데이터 위에서 LLM이 계속 추론하도록 두는 대신, 그래프가 상태의 error 키를 감시한다. 검증 중 소득 필드 누락 같은 오류가 감지되면 즉시 종단 거절 노드로 재라우팅한다.

모델이 결정을 환각하거나 잘못된 정보에 근거해 인가되지 않은 API를 호출할 위험을 유의미하게 줄인다. ADK 쪽에서는 safety_settingsBLOCK_LOW_AND_ABOVE 임계로 설정하고, PII 탐지 같은 입력 가드레일로 민감 데이터가 컨텍스트 창에 닿기 전에 가로채 마스킹한다.

Accountability

책임성과 거버넌스

추적 가능하고 관찰 가능한 워크플로가 책임성의 전제조건이다. 감사자가 “왜 이 대출이 거절됐는가”를 물으면, LangSmith나 Google Cloud Trace의 완전한 추적을 제시해 각 단계의 정확한 데이터·도구 출력·LLM 추론을 보일 수 있다.

불변 감사 추적 — 데이터 접근 로그를 활성화하고 모든 상호작용 로그를 BigQuery로 내보낸다. 에이전트의 모든 API 호출에 타임스탬프와 특정 서비스 계정 신원이 연결된 불변 기록이 생겨, 준수 팀이 언제 누가 그 거래를 인가했는지 정확히 질의할 수 있다.

이것이 에이전트를 “블랙박스”에서 투명하고 감사 가능한 업무 프로세스의 부품으로 바꾼다.

06

Choosing a framework

무엇을 언제 고를 것인가

단 하나의 “최선의” 에이전트 프레임워크는 없다. 올바른 선택은 프로젝트의 복잡도, 팀의 개념 친숙도, 그리고 운영 요구사항에 달렸다. 요컨대 풀려는 문제에 맞는 심적 모형을 고르는 일이다.

CrewAI를 고려하라 — 팀의 은유

  • 빠르게 시제품을 만들며 멀티 에이전트 시스템을 신속히 돌려 보고 싶을 때
  • 워크플로가 전문가 협업 팀에 자연스럽게 대응될 때(예: “연구자”, “작성자”, “편집자”)
  • 절차가 위계 구조(매니저·작업자)에서 이득을 보고 위임이 핵심일 때
  • 맥락을 통한 암묵적 상태 전달로 충분할 때

LangGraph를 고려하라 — 상태 기계

  • 복잡하고 비선형인 통제 흐름이 필요할 때(루프, 분기, 상태 기반 동적 라우팅)
  • 각 단계에서 명시적 상태 관리와 검사가 로직이나 디버깅에 결정적일 때
  • 실패에 따라 특정 경로로 라우팅하는 견고한 오류 처리가 요구될 때
  • 고충실도 디버깅과 추적 가능성이 필요할 때(매 단계의 전체 상태를 봄)
  • 정밀한 상태 통제가 필요한 장기 실행 에이전트를 지을 때
  • 입력을 기다리는 노드를 더해 HITL 패턴을 쉽게 구현해야 할 때

Google ADK를 고려하라 — 운영 서비스

  • 운영 기업 환경, 특히 Google Cloud 생태계 안에서 지을 때
  • 에이전트를 모듈적이고 테스트 가능하고 배포 가능한 부품으로 다루는 소프트웨어 공학 중심 접근이 필요할 때
  • OpenTelemetry 같은 표준 기업 관찰 가능성과 거버넌스 시스템과의 통합이 일차 요구사항일 때
  • 개발·평가에서 배포·모니터링까지 에이전트의 전체 생애주기를 관리해야 할 때
  • 도구·에이전트·모델로 들어가는 페이로드를 검사하고, 그 출력을 검사하거나 조치해야 할 때
  • 순차 같은 복잡한 멀티 에이전트 패턴을 조율해야 할 때

프레임워크는 성숙도의 조력자다

성숙도 단계프레임워크 접근과 조력 도구
1 · 프롬프팅 단순한 단일 턴 프롬프팅. 직접 LLM API 호출(Gemini, OpenAI 등). 프레임워크는 대체로 필요 없다.
2 · RAG 맥락으로 증강된 생성. LangChain(RAG 파이프라인용) 또는 벡터 DB를 호출해 맥락을 프롬프트에 넣는 맞춤 코드.
3 · 튜닝 에이전틱 프레임워크와 무관한 단계.
4 · 접지와 평가 CrewAI는 상위 수준의 역할 기반 조율에, LangGraph는 저수준의 상태 주도 프레임워크에 초점을 둔다. 접지와 평가에 대한 접근도 이 분기를 반영한다.

CrewAI — 통합적이고 기업 지향적. 환각 가드레일 같은 네이티브 기능으로 맞춤 로직 없이 “턴키”에 가깝게 만든다.
LangGraph자기수정 루프(조건부 엣지로 나쁜 출력을 감지해 “정련” 노드로 상태를 되돌림), 상태 체크포인트(“버전 관리된” 이력에 접지, 알려진 좋은 상태로 롤백), HITL 인터럽트(판돈 큰 도구 호출 전 사람 검증을 위해 실행을 명시적으로 중단). 평가는 LangSmith 통합(모든 노드 전이의 지연·비용·정확도를 “LLM-as-a-judge”로 측정)과 단위 테스트 가능한 노드(노드가 고립된 파이썬 함수이므로 결정론적 단위 테스트 가능).
5 · 단일 에이전트 시스템 ADK — 일차 용례. 도구를 가진 단일 Agent 클래스를 정의해 에이전트 런타임에서 실행 CrewAI — 크루 하나로도 쓸 수 있으나 덜 일반적 LangGraph — 명시적 상태에 근거해 여러 도구를 부를 수 있는 하나 이상의 에이전트 노드를 가진 그래프. 성찰하며 루프 가능
6 · 멀티 에이전트 시스템 ADK — 독립 배포된 여러 ADK 에이전트 서비스가 메시징이나 A2A 프로토콜로 통신 CrewAI일차 설계 철학. 뚜렷한 역할과 프로세스(순차·위계)를 가진 크루를 정의 LangGraph — 복잡한 상호작용에 이상적. 각 에이전트·함수가 노드, 엣지가 통신·인계·통제 흐름을 정의. 명시적 상태가 공유된 이해를 돕는다

〈표 15.3〉 조직의 성숙도 단계에 따른 프레임워크 접근

이 표가 보여주듯, 프레임워크는 “에이전트 준비된” 모델(3단계)에서 기능하는 에이전틱 시스템(4·5단계)으로 건너가는 다리다. 우리가 설계한 정교한 애플리케이션을 실제로 구성하는 방법(how)을 제공한다.