ADK 스터디를 마무리하면서

스터디 참여 배경

저는 LangChain으로 LLM 애플리케이션 개발을 시작했고, 이후 LangGraph로 개발을 이어왔습니다. Google I/O에서 ADK를 처음 접했을 때는 LangChain이나 LangGraph와 비교하는 관점으로 접근했습니다. 당시 일부 기능이 아직 제대로 동작하지 않는 것을 보고 실망해서 ADK 문서를 점차 찾아보지 않게 되었습니다. 그러던 중 최근 태우님의 ADK 스터디 모집을 보고 “왜 LangGraph보다 부족하다고 느꼈는지”를 구체적으로 확인해보고 싶어 참여하게 되었습니다.

Agent Development Kit

ADK와 LangGraph: 제어와 자유도

스터디를 진행하면서도 “LangGraph가 더 편하다”는 초기 판단은 쉽게 바뀌지 않았습니다. ADK에서는 LLM을 세밀하게 제어하기가 상대적으로 어렵게 느껴졌기 때문입니다. LangGraph는 코드 레벨에서 입력 생성, 후처리, 상태 전환을 명시적으로 다룰 수 있어 LLM의 불확실성을 보완하기 쉽습니다. 물론 ADK에서도 콜백 등의 메커니즘을 통해 비슷한 구조를 만들 수는 있습니다.

  • ADK: 사용자의 발화와 문맥에 맞는 에이전트를 선택해 턴을 넘기며 상호작용하는 구조입니다. 라우팅과 에이전트 조합에 초점이 맞춰져 있습니다. 참고: ADK 공식 문서
  • LangGraph: 노드(LLM/함수) 간의 명시적인 그래프/상태 머신 기반으로 실행되어 흐름을 고정하고 제어하기 쉽습니다. 참고: LangGraph 문서

LangGraph

스터디에는 LLM 애플리케이션 개발이 처음인 분들도 있었는데, 공통적으로 “전통적인 if/for 중심의 프로그래밍”과 “텍스트 입출력 중심의 LLM 환경” 사이의 간극에서 어려움을 겪었습니다. 이는 ADK만의 문제가 아니라 LLM 애플리케이션 개발 전반의 학습 곡선으로 보는 것이 맞습니다.

Workflow vs Agentic 디자인 패턴

“그렇다면 ADK는 불필요한가?” 그렇지 않습니다. LLM 애플리케이션은 크게 Workflow와 Agentic 디자인 패턴으로 나눌 수 있습니다.

  • Workflow 지향 프레임워크: LangGraph, n8n 등. 정해진 규칙과 순서대로 노드를 실행해 결과를 도출합니다. 참고: n8n Docs, LangGraph Docs
  • Agentic 지향 프레임워크: ADK, CrewAI 등. 에이전트 간 협업과 동적 의사결정으로 문제를 해결합니다. 참고: ADK Docs, CrewAI Docs

핵심 차이는 LLM의 자유도입니다. Agentic 시스템은 실행 순서를 미리 정하지 않고, 상황에 맞는 에이전트와 도구를 동적으로 선택해 더 넓은 문제를 다룰 수 있습니다. 반면 Workflow 시스템은 절차가 명확해서 재현성과 예측 가능성이 높습니다.

Agentic의 숨은 비용

Agentic 시스템은 계획(Plan)-행동(Act)-반성(Reflect) 루프를 반복하고 도구를 자주 호출하기 때문에, 단순 대화나 고정 워크플로보다 토큰 비용이 급격히 증가할 수 있습니다. 이런 비용 증가와 운영 복잡도는 미리 고려해야 합니다. 참고: Anthropic – Building effective agents, Anthropic – Multi-agent research system

디버깅도 쉽지 않습니다. 전통적인 스택 트레이스 대신 모델의 추론 로그와 실행 체인을 분석해야 해서 원인을 찾기 어렵습니다. 초기에 잘못된 판단이 발생하면 연쇄적으로 오류가 확산되기 쉬워, 모니터링과 안전장치가 매우 중요합니다.

또한 Agent Injection, Multi-Agent Jailbreaks, Memory Poisoning 같은 에이전트 특유의 보안 위협이 존재합니다. 기존 시스템에서는 드문 위협이므로, 보안과 거버넌스를 처음부터 고려해 설계해야 합니다. 참고: Microsoft – Taxonomy of failure modes in AI agents

언제 Agentic이 적합한가

  • 사용자 응답에 따라 다음 질문과 행동이 달라지는 동적 대화
  • 설계, 법률, 장기 계획 같은 고가치 의사결정
  • 사전에 절차를 정의하기 어려운 개방형 탐색과 리서치
  • 분기가 많은 복잡한 작업처럼 규칙 기반으로 모두 코딩하기 어려운 문제

언제 Workflow가 유리한가

  • 명확한 단계가 고정된 반복 업무
  • 금융, 의료, 법무, 공공 분야처럼 추적과 근거가 필요한 규제 환경
  • 비용과 성능 예측이 중요한 대량 처리 시나리오
  • 모니터링과 안전장치가 아직 갖춰지지 않은 초기 제품 단계

운영 관점: 비용과 관측성의 한계

Agentic 시스템은 요청 복잡도와 에이전트 전환 횟수에 따라 토큰 소비가 달라져서 비용 예측이 어렵습니다. 반면 Workflow는 경로가 고정되어 있어 비용을 쉽게 추정할 수 있습니다.

운영 단계에서는 관측성(Observability) 도구로 실행 경로, 토큰 사용량, 응답 시간을 추적해 이상 징후를 조기에 발견할 수 있습니다. 하지만 이것만으로는 한계가 있습니다. 아무리 정교한 모니터링을 구축해도 LLM이 왜 그런 결정을 내렸는지, 다음에 무엇을 할지 완벽하게 예측하기는 어렵습니다. 참고: Langfuse Observability

인터페이스와 Human-in-the-Loop: 운영 문제의 실질적 해결책

관측성의 한계를 극복하는 실용적인 방법이 바로 적절한 인터페이스 설계와 Human-in-the-Loop(HITL)입니다. 단순히 모니터링하는 것을 넘어, 사용자가 직접 시스템의 의사결정 과정에 개입할 수 있게 만드는 것입니다.

채팅을 넘어선 구조화된 인터페이스

많은 사람이 AI 시스템을 ‘채팅’으로만 생각하지만, 인터페이스를 잘 설계하면 비용과 품질 문제를 동시에 해결할 수 있습니다. 채팅 UI는 자유도가 높지만 사용자 요구사항이 모호해져 불필요한 토큰 소비와 잘못된 결과로 이어질 수 있습니다.

Cursor는 이 문제를 훌륭하게 해결한 사례입니다. 단순 채팅이 아니라 Diff 표시와 파일 참조 기능으로 사용자 의도를 명확하게 전달합니다. 이렇게 구조화된 입력은 LLM의 탐색 공간을 줄여 토큰 비용을 절감하고 정확도를 높입니다.

Free Chatbot Templates You Can Edit & Download | Figma Cursor interface

HITL: 비용 절감과 품질 보증의 균형점

HITL(Human-in-the-Loop)은 단순한 안전장치가 아니라 운영 효율성을 높이는 핵심 전략입니다. LLM이 불확실한 지점에서 사용자 확인을 받도록 하면, 잘못된 경로로 진행되어 낭비되는 토큰과 시간을 대폭 줄일 수 있습니다.

예를 들어, 복잡한 데이터 분석 작업에서 LLM이 초기 분석 방향을 제시하고 사용자 승인을 받은 후 진행하면, 전체 분석을 다시 하는 비용을 방지할 수 있습니다. 이는 특히 Agentic 시스템에서 계획-실행-반성 루프가 반복될 때 효과적입니다. 참고: Human-in-the-loop (위키백과)

동적 UI 생성: 맥락에 맞는 개입 지점

최근에는 “LLM이 필요하다고 판단하면 UI를 자동으로 생성”하는 도구까지 나오고 있습니다. 이는 모니터링으로 발견한 문제를 사후에 수정하는 것이 아니라, 실시간으로 사용자 개입이 필요한 지점을 파악하고 적절한 인터페이스를 제공합니다.

UI-MCP

테슬라 오토파일럿 비유: 지속적인 감독과 선택적 개입

테슬라 오토파일럿은 HITL의 이상적인 모델입니다. 시스템이 대부분의 운전을 처리하지만, 운전자는 계속 도로를 주시하고 필요시 개입합니다. LLM 애플리케이션도 마찬가지로, 기본적으로는 자동화하되 중요한 순간에 사용자가 개입할 수 있는 인터페이스를 제공해야 합니다.

AutoPilot

이런 접근은 완전 자동화보다 토큰 비용을 줄이면서도 더 높은 품질을 보장합니다. 사용자는 시스템이 올바른 방향으로 가고 있는지 확인하고, 필요시 경로를 수정해 불필요한 재작업을 방지합니다.

References