구글 ADK 시퀀셜 에이전트 사용법: 코드 작성·검토·리팩터링 3단계 파이프라인 실습 정리

핵심 메시지

• 워크플로우 에이전트는 사전에 정의된 절차대로 움직이며, 순차·반복·병렬 세 가지 흐름을 구성할 수 있다.
• LLM 에이전트가 상황에 따라 동적으로 판단하는 비결정론적 방식이라면, 워크플로우 에이전트는 오케스트레이션 단계에 LLM이 개입하지 않는 결정론적 방식이다.
• 구글 ADK는 시퀀셜(순차)·루프(반복)·패러럴(병렬) 세 종류의 워크플로우 에이전트를 제공한다.
• 시퀀셜 에이전트는 하위 에이전트를 등록된 순서대로 실행하며, 각 단계의 결과는 output_key에 저장돼 다음 에이전트로 전달된다.
• 실습에서는 코드 작성자·코드 검토자·코드 리팩터 세 하위 에이전트를 묶어 코드 생성 파이프라인을 만든다.

쉽게 이해하기

모든 업무에는 순서가 있다. 정해진 차례대로 처리해야 하는 일이 있고, 품질이 만족스러워질 때까지 반복해야 하는 일이 있으며, 시간을 줄이려고 여러 작업을 동시에 돌려야 하는 일도 있다. 강의는 이런 다양한 작업 흐름을 손쉽게 구성하고 제어하도록 돕는 것이 워크플로우 에이전트라고 설명한다.

일반적인 LLM 에이전트와 워크플로우 에이전트의 결정적 차이는 판단 주체다. LLM 에이전트는 상황에 맞춰 언어 모델이 동적으로 추론하고 결정하지만, 워크플로우 에이전트는 고정된 로직을 따르며 오케스트레이션 단계에서는 LLM이 끼어들지 않는다. 실행 순서 자체를 코드로 못 박아 두는 결정론적 구조인 셈이다.

구글 ADK가 제공하는 워크플로우 에이전트는 세 가지다. 하위 에이전트를 차례로 하나씩 실행하는 시퀀셜 에이전트, 반복 실행하는 루프 에이전트, 동시에 병렬로 실행하는 패러럴 에이전트다. 강의는 이 중 첫 번째인 시퀀셜 에이전트를 이론과 실습으로 다룬다.

실습 예제는 코드를 만들어 주는 AI 에이전트다. 사용자의 요구에 맞춰 초기 파이썬 코드를 쓰는 코드 작성자 에이전트, 그 코드의 오류·스타일·문법과 모범 사례 준수 여부를 검토하는 코드 검토자 에이전트, 검토 피드백을 반영해 코드를 다듬는 코드 리팩터 에이전트를 각각 LLM 에이전트로 만들고 시퀀셜 에이전트의 하위 에이전트로 순서대로 등록한다.

연결 고리는 output_key다. 코드 작성자가 만든 코드는 지정한 키에 저장되고, 검토자 에이전트는 인스트럭션에서 그 키를 참조해 대상 코드를 읽는다. 리팩터 에이전트는 원본 코드와 리뷰 코멘트를 함께 참조하되, 리뷰에 "큰 문제 없음"이라고 적혀 있으면 원본을 그대로 돌려주도록 지시받는다. 마지막으로 ADK 웹 UI에서 "계산기 코드를 작성해 주세요"라고 요청하면 파이프라인 에이전트가 먼저 호출되고 작성자·검토자·리팩터가 차례로 실행되는 과정을 이벤트 화면에서 확인할 수 있다.

주요 인사이트

• 에이전트 설계에서 "언제 LLM에게 판단을 맡기고 언제 맡기지 않을 것인가"는 별개의 결정이다. 순서가 이미 정해진 작업이라면 매번 모델에게 다음 단계를 묻는 것보다 워크플로우로 고정하는 편이 안정적이다.
• 하위 에이전트끼리 데이터를 주고받는 방식이 output_key라는 상태 저장소라는 점이 중요하다. 다음 에이전트의 인스트럭션이 그 키를 명시적으로 참조하도록 써야 파이프라인이 실제로 이어진다.
• 시퀀셜 에이전트 자체에는 모델과 인스트럭션 설정이 없다. 대신 이름과 설명은 반드시 적어야 하는데, 복잡한 시스템에서 다른 에이전트가 이 에이전트를 식별하고 참조하기 위한 정보이기 때문이다.
• ADK는 시작점을 변수명으로 인식한다. 루트가 되는 에이전트의 변수명을 root_agent로 두지 않으면 실행 자체가 되지 않으므로, 파이프라인을 만든 뒤 루트에 할당하는 단계를 빠뜨리면 안 된다.
• 환경 변수 파일은 루트 에이전트 폴더에만 두면 되고 하위 에이전트마다 만들 필요가 없다. 폴더 규칙을 이해하면 하위 에이전트를 늘릴 때 반복 작업이 줄어든다.

자주 묻는 질문

관련 AI 소식