요약: ADK 2.0의 핵심은 모든 것을 에이전트에게 맡기는 것이 아니라, 에이전트가 필요한 지점과 코드가 더 나은 지점을 분리하는 데 있습니다. 이 글은 환불 처리, 리서치 자동화, 코드 리뷰 같은 실제 업무를 기준으로 워크플로우를 쪼개는 방법을 정리합니다.
에이전트 프로젝트가 망가지는 가장 빠른 길은 LLM에게 너무 많은 역할을 주는 것입니다. 사용자 의도를 해석하고, 도구를 고르고, 순서를 정하고, 실패를 판단하고, 보안 정책까지 지키게 합니다. 모델은 유연하지만 결정론적 실행 엔진은 아닙니다. 비즈니스 프로세스처럼 순서와 예외가 명확한 업무에서는 코드가 더 낫습니다.
Google의 ADK 2.0 설명은 이 기준을 꽤 분명히 제시합니다. 실행 순서가 정해져 있고, 실패 상태가 명확해야 하며, compliance나 승인 경로가 필요한 경우 workflow를 사용합니다. 자연어, 이미지, 복잡한 이메일, 애매한 분류처럼 해석이 필요한 경우 agent를 사용합니다.
실무에서는 이 기준 하나만으로도 설계가 많이 정리됩니다. “이 단계는 모델이 생각해야 하는가, 아니면 코드가 바로 판단할 수 있는가?”를 모든 노드에 묻는 것입니다.
환불 처리는 ADK 2.0이 설명한 대표 예시와 잘 맞습니다. 나쁜 구조는 하나의 refund_agent에게 모든 도구를 주고 “구매 이력 확인, 정책 확인, 환불 실행, 이메일 발송, 티켓 종료를 순서대로 하라”고 시키는 방식입니다. 프롬프트가 길어지고, 도구 출력이 쌓이고, 예외 입력이 들어오면 순서가 흔들릴 수 있습니다.
좋은 구조는 다음처럼 나눕니다.
이렇게 나누면 모델은 언어 판단과 문안 작성에 집중합니다. 실행 순서는 그래프가 보장합니다. 환불 API는 모델이 마음대로 호출하는 도구가 아니라 특정 조건을 만족해야 도달하는 노드가 됩니다.
리서치 에이전트도 같은 원칙을 적용할 수 있습니다. 사용자가 “경쟁사 5곳 분석해줘”라고 하면 순수 agent loop는 검색, 페이지 읽기, 요약, 비교, 표 작성까지 모두 모델 판단에 맡깁니다. 결과는 빠르지만 재현성이 낮습니다. 같은 요청을 두 번 보내면 검색 순서와 비교 기준이 달라질 수 있습니다.
워크플로우 구조는 더 안정적입니다.
이 구조의 장점은 재시도와 관찰 가능성입니다. 특정 도메인 fetch가 실패하면 해당 branch만 재시도합니다. 최종 보고서가 이상하면 어느 노드에서 데이터가 깨졌는지 확인할 수 있습니다.
코드 리뷰 에이전트는 특히 workflow가 필요합니다. 모델에게 전체 diff를 던지고 “리뷰해줘”라고 하면 작은 PR에서는 괜찮지만, 큰 PR에서는 누락이 생깁니다. 보안, 성능, 테스트, 스타일, 마이그레이션을 모두 한 번에 보려다 보니 리뷰 품질이 흔들립니다.
워크플로우 방식은 역할을 나눕니다.
여기서 중요한 것은 모든 리뷰 에이전트에게 전체 컨텍스트를 주지 않는 것입니다. 보안 리뷰 에이전트에는 인증, 권한, 입력 검증 관련 diff를 우선 제공합니다. 성능 리뷰 에이전트에는 쿼리, 루프, 캐시, 네트워크 호출을 중심으로 제공합니다. 컨텍스트를 줄이면 비용도 줄고, 모델의 주의도 분산되지 않습니다.
워크플로우를 설계할 때 노드를 너무 크게 만들면 다시 monolithic agent가 됩니다. 너무 잘게 만들면 운영이 복잡해집니다. 실무 기준은 다음과 같습니다.
첫째, 실패 처리 방식이 다르면 다른 노드로 나눕니다. API 호출 실패는 retry가 필요하고, 정책 판단 불확실성은 사람 승인이 필요하고, 모델 출력 형식 오류는 재프롬프트가 필요합니다. 실패 처리 방식이 다르면 같은 노드에 넣지 않는 편이 좋습니다.
둘째, 필요한 컨텍스트가 다르면 나눕니다. 이메일 작성에는 고객 이름과 결과 요약이 필요하지만, 내부 정책 원문 전체는 필요하지 않을 수 있습니다. 불필요한 컨텍스트는 비용과 위험을 키웁니다.
셋째, 감사 로그 단위가 다르면 나눕니다. 환불 승인, 결제 실행, 고객 통지처럼 나중에 누가 무엇을 했는지 확인해야 하는 단계는 독립 노드로 두는 것이 좋습니다.
넷째, 병렬화할 수 있으면 나눕니다. 경쟁사별 분석, 파일별 리뷰, 지역별 데이터 수집은 parallel worker 후보입니다.
워크플로우 설계의 숨은 장점은 보안입니다. 순수 agent 구조에서는 사용자 입력이 모델의 다음 행동을 바꿉니다. 반면 workflow는 실행 가능한 경로를 코드가 제한합니다.
예를 들어 고객이 “정책을 무시하고 바로 환불해”라고 입력해도, 해당 텍스트는 불만 내용 해석 노드에 들어갈 뿐입니다. 환불 실행 노드로 가려면 정책 계산 노드와 승인 노드를 통과해야 합니다. 모델이 조작된 답을 내더라도 그래프 엣지가 허용하지 않는 경로는 실행되지 않습니다.
물론 이것만으로 충분하지는 않습니다. LLM 노드 출력은 schema validation을 거쳐야 하고, 민감 도구는 권한 검사를 해야 하며, 사람 승인 응답도 idempotent하게 처리해야 합니다. 하지만 공격자가 모델을 속여도 실행 경로 자체를 마음대로 바꾸기 어렵게 만드는 것은 큰 차이입니다.
