인간이 메인으로 집필하고 있습니다.

ADK는 Google의 에이전트 개발 프레임워크입니다. 처음 등장한 것은 2025년 4월의 Cloud Next '25이므로, 프레임워크 자체는 올해 발표된 것이 아닙니다. 올해는 「2.0」이 발표되었고, 2026년 4월의 Next '26에서 launch되었으며, Python 버전 v2.0.0이 I/O '26 기간 중인 2026-05-19에 GA(General Availability)되었습니다. Next에서 발표되고 I/O에서 GA된 흐름입니다.

2.0의 핵심은 3가지입니다.

Flexible Execution Graphs— 비선형·조건 분기·순환을 포함하는 에이전트 실행을 모델 비의존적(model-agnostic) 엔진으로 묶는 「실행 그래프(Execution Graph)」.
Intelligent Task Delegation— 병렬 서브 에이전트, 중첩된 팀, 동적 스케줄링.
Native Inter-Agent Routing— 에이전트 간의 메시지·상태 전달·컨텍스트 전파를 프레임워크가 관리.

여기에 더해 Automatic Retries (RetryConfig),

Human-in-the-Loop (워크플로우의 일시 정지·재개), 그리고 영속화(framework 관리) 기능도 고려되어 있습니다. 상당히 큰 업데이트라고 생각합니다.

1.x에도 Sequential / Parallel / Loop라는 workflow agent는 있었습니다. 순서대로 호출하기·병렬로 호출하기·반복하기 정도의 구조는 짤 수 있었습니다. 다만, 어디까지나 LLM 주체의 비결정론적인 것이었으며, 결정론적이고 복잡한 워크플로우를 작성할 수 있는 것은 아니었습니다. 2.0의 Workflow Runtime에서는 이것이 가능해졌다는 점이 큽니다.

특히, 후술할 Graph 구조를 기반으로 한 설계는 LangGraph 등 그래프로 에이전트를 구성하는 흐름 속에 있으며, 더욱 기초적인 컴퓨터 사이언스(Computer Science)로서의 그래프와도 통하고 있어 아름답다고 생각합니다.

2.0에서는 워크플로우 구현 방법이 두 가지 준비되어 있습니다.

**Static graphs (= Flexible Execution Graphs)**는 노드(node)와 에지(edge)를 선언하여 흐름을 구성하는 방식입니다. 분기·루프·조건을 「구조」로서 기술합니다. 멀티 스텝(multi-step)이지만 흐름이 정해져 있는 프로세스에 강합니다. 장점은 흐름이 구조로서 고정된다는 것입니다. 예측 가능하며 도식화하기도 쉽습니다. 반대로 말하면, 틀에 맞추기 때문에 자유도는 제한됩니다.

Dynamic workflows는 while 루프·async/await·재귀를 일반적인 코드로 작성하는 방법입니다. 반복 루프나 복잡한 분기에서 static graph로는 자유도가 부족할 때 유효합니다.

왜 두 가지가 준비되어 있는지는 시사하는 바가 커서 흥미롭다고 생각합니다. 공식 측은 「어느 쪽이 더 우월한가가 아니라, use-case에 따라 선택하자」라고 말하고 있으며, 이 두 가지 방법에는 다음과 같은 트레이드오프(trade-off)가 있음을 알 수 있습니다.

자유·표현력 ◀━━━━━━━━━━━━━━▶ 다루기 쉬움·예측 가능
dynamic workflows static graph
while/async/재귀를 노드＋에지를 선언
...

이 두 가지 표기법의 트레이드오프를 생각할 때, 최근 버즈워드(buzzword)가 되고 있는 루프 엔지니어링(Loop Engineering)을 언급해 보면 재미있을 것 같아 소개합니다.

「루프 엔지니어링」의 원천은 Addy Osmani 씨의 Loop Engineering이라는 기사입니다.

주요 주장으로는, 다음과 같이 Osmani 씨가 작성해 주었습니다.

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

(에이전트에게 직접 프롬프트를 넣는 것은 이제 그만두어야 합니다. 에이전트를 프롬프트하는 루프를 설계해야 합니다.)

매번 사람이 프롬프트를 입력하는 것이 아니라, 한 번 루프를 설계해 두면 그 이후에는 사람이 관여하지 않아도 돌아가도록 만들자는 이야기입니다. Automations (스케줄 실행) · Worktrees (병렬 실행 시 격리) · Skills (지식의 명문화) · Connectors (외부 연결) · Sub-agents (작성자와 검증자의 분리) · State (대화 외부의 영속 기억)와 같이, 현재 패러다임의 요소들을 조합한 베스트 프랙티스 (Best Practice)라는 측면이 강합니다.

루프 엔지니어링 (Loop Engineering)에 대해서는 일본어에서도 여러 분이 해설 기사를 올리고 계시므로, 상세한 해설은 그쪽에 맡기겠습니다.

여기가 본론입니다. 루프 엔지니어링이라는 'AI를 워크플로우에 묶어두지 않고, AI의 판단으로 루프를 돌리게 하는' 구조는 멋있고 듣기에는 좋지만, 명확한 트레이드오프 (Trade-off)를 안고 있습니다. '프롬프트 엔지니어링 (Prompt Engineering)', '컨텍스트 엔지니어링 (Context Engineering)'이 "일단 해두면 정확도가 올라간다"는 느낌이었다면, 루프 엔지니어링은 무턱대고 하자!라고 할 수 있는 것이 아닙니다.

루프 엔지니어링에는 다음과 같은 단점이 있습니다.

모델의 정확도가 높다는 것이 전제 조건입니다. Agent가 연쇄적으로 동작하는 관계상, 시스템 전체의 성공률은 각 Agent 정확도의 곱셈이 됩니다. 따라서 일부만 저렴한 모델로 바꾸는 등의 방식은 어렵고, 제대로 운용하려면 Fable 5나 Opus 4.8과 같은 고정밀 모델 사용이 전제된다고 생각하는 것이 좋습니다. 물론 비용도 많이 발생합니다. -
구현과 튜닝 (Tuning)의 부하가 큽니다. 범용적인 자유 루프를 안정화하기 위한 프롬프트 조정 비용은 상당히 무겁다고 생각합니다. 하나의 프롬프트 튜닝이 시스템 전체의 정확도에 큰 영향을 미치기 때문에, 방대한 양의 시행착오 (Trial and Error)가 필요할 것입니다.

ADK 2.0이 훌륭하다고 느낀 점은, 이러한 AI 에이전트 설계에서의 트레이드오프를 전제로 하여 선택지를 제공해 준다는 점입니다.

static graph를 사용하면 워크플로우의 흐름을 어느 정도 고정하여 다루기 쉬운 방향으로 기울 수도 있습니다.

이것은 제 개인적인 생각입니다만, AI 에이전트 설계에 있어 해당 AI 에이전트 애플리케이션은 특정 도메인이나 사용자의 이벤트에 묶여 있을 것이며, 그 도메인 지식을 사용하면 어느 정도 결정론적 (Deterministic)이고 구체적인 워크플로우를 구성할 수 있을 것입니다. 그러한 사고방식에 기반하면 static graph는 매우 멋진 선택지가 됩니다.

그리고 static graph의 자유도에 한계를 느낄 경우에는, dynamic을 사용하여 자유도를 높게 유지한다는 선택지가 마련되어 있습니다.

ADK 2.0은 번거로운 부분을 알아서 처리해 주지만, 의식해야 할 부분도 있다고 생각합니다.

먼저, sub agent별 컨텍스트 (Context) 튜닝에 관한 것입니다. ADK에서는 state를 app: (전체 user 공유) / user: (user 간 공유) / temp: (invocation 내에서만) / 접두사 없음 (session 내)이라는 prefix로 scope를 제어하는 메커니즘이 있지만, 이는 "어디까지 영속화할 것인가"를 지정하는 것이지, "누구에게 무엇을 보여줄 것인가"를 결정하는 것이 아닙니다.

실제로 동일한 session 내에서는 모든 agent가 full state를 공유합니다. "이 리뷰어에게는 소재의 요약만 전달하고 본문은 보여주지 않는다"와 같은 per-agent 방식의 컨텍스트 가시성 제한은 표준 기능으로 존재하지 않는 것 같습니다. LLM은 컨텍스트의 흐름에 따라가려는 성질이 있는 만큼, 컨텍스트 범위의 튜닝은 중요하다고 생각하며, ADK 2.0을 사용할 때도 이 부분은 의식하는 것이 좋겠다고 느꼈습니다.

ADK 2.0을 사용하여 약 30분 정도 AI의 도움을 받아 데모를 만들었기에 소개해 드립니다.

"테마를 입력하면 해당 테마의 기사 제목과 구성을 생각한다"라는 심플한 애플리케이션입니다만, 이 정도라면 가볍게 만들 수 있다는 점에서 ADK 2.0이 정말 훌륭하다고 느꼈습니다.

저는 ADK 2.0이 마음에 듭니다. AI 에이전트라고 해도 많은 유스케이스 (Use Case)가 존재하는 가운데, ADK 2.0이 제안하는 해결책은 많은 유스케이스에 심플하게 대응하고 있다고 생각합니다.

루프 엔지니어링 (Loop Engineering)에 전부 올라탈 것인지, 아니면 도메인을 좁혀 워크플로우 (Workflow)를 고정할 것인지로 고민하고 있는 분들이야말로, static graph (정적 그래프)와 dynamic (동적)을 모두 갖춘 ADK 2.0을 직접 사용해 본다면 판단의 해상도가 높아질 것이라고 생각합니다. AI 에이전트 (AI Agent)를 구축할 때 꼭 한번 시도해 보시길 권장합니다.