Google ADK Go 2.0 정식 출시 단일 에이전트를 넘어 그래프 기반 워크플로우로 진화하다

왜 ADK Go 2.0인가? — 에이전트 오케스트레이션의 새로운 패러다임

실전에서 돌아가는 에이전트 애플리케이션은 단일 프롬프트로 끝나는 경우가 거의 없습니다. 사용자 요청을 분류(Classify)하고, 조건에 따라 분기(Branch)하며, 여러 전문 에이전트로 작업을 분산(Fan-out)시키고, 결과를 다시 모아(Fan-in)야 합니다. 때로는 사람의 승인(Human-in-the-Loop)을 받아야 하고, 실패 시 재시도(Retry)와 반복(Loop)도 필요하죠.

이런 복잡한 오케스트레이션을 임시방편(ad-hoc)으로 제어 흐름을 짜면 유지보수가 급격히 어려워집니다. ADK Go 2.0은 이런 문제를 그래프(Graph)라는 개념으로 깔끔하게 해결합니다. 노드(Node)와 엣지(Edge)로 에이전트의 행동 흐름을 선언적으로 기술하고, 스케줄러가 동시성 실행, 상태 저장, 일시 중지 및 재개를 처리합니다.

📌 핵심 철학: "그래프 자체가 하나의 에이전트다." — ADK 2.0에서 워크플로우는 agent.Agent 인터페이스를 구현하므로, 기존 싱글 에이전트를 실행하던 러너, 론처, 콘솔을 그대로 사용할 수 있습니다.

이 글에서는 ADK Go 2.0의 주요 기능을 살펴보고, 한국 개발자 생태계에서 어떻게 활용할 수 있을지 실무 관점에서 분석해보겠습니다.

(근거자료: Google 공식 블로그)

그래프 기반 워크플로우: 코드로 보는 핵심

가장 기본적인 순차(sequential) 워크플로우부터 시작해보죠. 두 개의 함수 노드를 체인으로 연결하는 예제입니다.

import "google.golang.org/adk/v2/workflow"

// 노드 생성: 각각 문자열을 처리하는 함수
upper := workflow.NewFunctionNode("upper", upperFn, cfg)
suffix := workflow.NewFunctionNode("suffix", suffixFn, cfg)

// 엣지 연결: Start -> upper -> suffix
edges := workflow.Chain(workflow.Start, upper, suffix)

// 워크플로우 에이전트 생성
wf, _ := workflowagent.New(workflowagent.Config{
    Name: "simple_sequence_workflow",
    Edges: edges,
})

// wf는 agent.Agent 인터페이스를 구현하므로 기존 러너로 실행 가능

라우팅(Routing) — 조건부 분기

엣지에 라우팅 조건을 추가하면, 노드의 출력값에 따라 다음 실행 노드가 결정됩니다.

b := workflow.NewEdgeBuilder()
b.AddRoutes(router, map[string]workflow.Node{
    "question":    answerNode,
    "statement":   commentNode,
    "exclamation": reactNode,
})
b.AddFanOut(planner, researchA, researchB, researchC) // 병렬 분기
b.AddFanIn(join, researchA, researchB, researchC)      // 결과 취합

동적 노드(Dynamic Node) — 런타임 오케스트레이션

실행 순서를 런타임에 결정해야 한다면 동적 노드를 사용합니다. 일반 Go 코드로 자식 노드를 직접 호출합니다.

greeter := workflow.NewDynamicNode("greeter_workflow",
    func(nc agent.Context, in string, emit func(*session.Event) error) (string, error) {
        // 일반 Go 코드로 자식 노드 실행
        return workflow.RunNode[string](nc, greeterNode, in)
    },
    workflow.NodeConfig{},
)

휴먼 인 더 루프(HITL) — 사람 개입

event := workflow.NewRequestInputEvent(ctx, session.RequestInput{
    InterruptID: "approve_refund",
    Message:     "환불 $200을 승인하시겠습니까? (yes/no)",
    ResponseSchema: schema,
})
// 이벤트를 발생시키면 노드는 'waiting' 상태로 전환
// 사용자가 응답하면 ctx.ResumedInput(...)으로 재개

HITL은 프로세스 재시작 후에도 지속(durable)됩니다. 세션 히스토리를 스캔하여 중단된 워크플로우를 복원할 수 있습니다.

주요 기능 비교 및 주의사항

ADK Go 2.0 vs 1.0 핵심 변화

⚠️ 주의사항 및 한계

1. 러닝 커브: 그래프 기반 사고 방식에 익숙해져야 합니다. 단순한 요청-응답 패턴에 과하게 적용하면 오히려 복잡도가 증가할 수 있어요.
2. 디버깅 복잡성: 여러 노드가 동시에 실행되거나 상태가 전이되는 과정을 추적하는 것이 까다로울 수 있습니다. ADK의 통합 텔레메트리(span tree)를 적극 활용하세요.
3. 세션 상태 크기: durable HITL을 위해 세션에 모든 이벤트가 저장됩니다. 장기 실행 워크플로우의 경우 세션 크기가 커질 수 있으므로 주기적인 정리(cleanup) 전략이 필요합니다.
4. Go 버전 의존성: ADK 2.0은 Go 1.22 이상을 권장합니다. iter.Seq2 등 최신 기능을 사용하므로, 레거시 프로젝트에서는 업그레이드가 필요할 수 있습니다.

한국 개발 생태계에서의 적용 맥락

• 금융/핀테크: 고객 상담 챗봇에서 환불, 대출 승인 등 사람의 승인이 필요한 단계를 HITL로 안전하게 처리할 수 있습니다.
• 전자상거래: 주문 처리 파이프라인(재고 확인 → 결제 → 배송)을 그래프로 모델링하여 각 단계별 실패 시 재시도 및 예외 처리를 명확하게 설계할 수 있습니다.
• SI 프로젝트: 복잡한 업무 로직(예: 보험 청구 처리)을 노드 단위로 분할하면, 각 노드를 독립적으로 개발/테스트할 수 있어 유지보수성이 크게 향상됩니다.

💡 실무 팁: 처음 도입할 때는 전체를 그래프로 바꾸기보다, 가장 복잡한 단일 업무(예: "주문 취소 워크플로우")부터 그래프로 리팩토링해보세요. ADK 1.0과 2.0이 동일한 런타임에서 동작하므로 점진적 전환이 가능합니다.

결론: Go 에이전트 개발의 새로운 기준

ADK Go 2.0은 단순한 업데이트가 아닙니다. Go 생태계에서 에이전트 애플리케이션을 구축하는 방식 자체를 바꾸는 중요한 릴리스입니다. 그래프 기반 워크플로우는 복잡한 오케스트레이션을 선언적이고 유지보수 가능하게 만들어주며, HITL, 재시도, 병렬 처리 같은 실전 요구사항을 프레임워크 수준에서 지원합니다.

특히 인상적인 점은 '그래프 자체가 에이전트'라는 설계 철학입니다. 이 덕분에 기존 싱글 에이전트 코드와 완벽하게 호환되며, 점진적인 도입이 가능합니다. Python ADK 2.0과도 중단점(interrupt) 포맷을 공유하므로, 멀티 언어 환경에서도 일관된 워크플로우를 구성할 수 있습니다.

다음 단계 학습 방향

1. 공식 예제 실행: go run ./examples/workflow/basic/부터 시작해서 라우팅, HITL, 복합 그래프 예제를 순서대로 실행해보세요.
2. 마이그레이션 가이드 숙지: ADK 1.0 사용자라면 공식 마이그레이션 가이드에서 InvocationContext → agent.Context 변경 등 주요 변경 사항을 확인하세요.
3. 나만의 워크플로우 설계: 현재 운영 중인 서비스에서 가장 복잡한 프로세스 하나를 골라 그래프로 모델링해보는 것을 추천합니다.

함께 보면 좋은 글

• LLM 추론 비용 폭탄? NVIDIA Runai와 NIM으로 GPU 활용률 2배 높이는 법
• React 동적 폼, 컴포넌트 vs 스키마 실무에서 고민해야 할 선택지