구글: 에이전트(Agents) 백서

• 구글이 낸 백서는 생성형 AI 에이전트를 모델, 툴, 오케스트레이션 레이어 세 요소의 조합으로 정의하고 이 조합을 인지 아키텍처라 부름
• 모델은 학습 데이터 안에 갇혀 단일 추론만 내놓지만, 에이전트는 세션 기록을 관리하며 다중 턴으로 툴을 골라 쓰고 외부 시스템까지 건드림
• 툴은 확장 기능, 함수, 데이터 저장소 세 갈래다. 확장 기능은 에이전트 측에서 API를 직접 호출하고, 함수는 호출할 이름과 인자만 출력해 실행은 클라이언트가 맡음
• 응답 품질은 모델이 적절한 툴을 고르는 능력과 툴 정의의 완성도에 직결되며, 문맥 내 학습과 검색 기반 학습, 미세 조정 세 가지로 그 선택 능력을 끌어올림

에이전트를 이루는 세 축

• 모델은 에이전트 프로세스의 의사결정자 역할을 맡는 언어 모델로, 크기와 무관하게 하나 또는 여러 개를 쓰며 범용과 멀티모달, 미세 조정본 어느 쪽도 가능
• 모델은 보통 특정 툴 선택이나 오케스트레이션 설정까지 학습하지 않으며, 다양한 맥락에서 툴을 쓰는 예시를 붙여주는 쪽이 성능 개선에 효과적
• 툴은 GET, POST, PATCH, DELETE 같은 웹 API 메소드와 닮은 형태로, 파운데이션 모델 단독으로는 불가능하던 외부 데이터 접근과 실행을 열어줌
• 오케스트레이션 레이어는 정보 입력, 내부 추론, 다음 행동 결정을 반복하는 순환 구조이며 목표 달성이나 중단점에 닿을 때까지 돌아감
• 순환의 복잡도는 작업마다 달라서 단순한 결정 규칙 계산부터 연쇄 논리, 별도 머신러닝 알고리즘이나 확률적 추론 기법 결합까지 폭이 넓음

모델과 에이전트가 갈리는 지점

• 모델은 세션 기록 관리가 기본으로 없어 채팅 이력 같은 연속 맥락을 스스로 붙들지 못하고, 쿼리 하나에 예측 하나로 끝남
• 에이전트는 오케스트레이션 계층이 턴 단위로 쿼리와 결정을 쌓아 다중 턴 추론을 이어감. 여기서 턴은 수신 이벤트 하나와 에이전트 응답 하나를 뜻함
• 모델에는 기본 툴 구현도 로직 계층도 없어, 사용자가 프롬프트를 복잡하게 짜서 추론 프레임워크를 흉내 내야 함
• 에이전트는 툴과 인지 아키텍처를 아키텍처 차원에서 내장하고, 사전 구축된 에이전트 프레임워크를 그대로 얹을 수 있음
• 백서는 이 차이를 주방 셰프에 빗대 주문 확인과 구상, 조리, 피드백 반영이 도는 순환 자체가 인지 아키텍처라고 설명

추론 프레임워크와 ReAct 루프

• ReAct는 모델이 질의를 두고 추론과 행동을 번갈아 내놓게 하는 프롬프트 프레임워크로, 맥락 내 예시 유무와 무관하게 작동하며 여러 SOTA 기준을 넘어섬
• Chain-of-Thought는 중간 단계를 거쳐 추론하게 하는 방식이며 자기 일관성, 능동 프롬프트, 멀티모달 변형으로 갈라져 각각 장단이 다름
• Tree-of-Thoughts는 CoT를 일반화해 여러 사고 갈래를 동시에 탐색하게 하므로 탐색이나 전략적 예측 성격의 작업에 유리
• ReAct 루프는 질문, 사고, 행동, 행동 입력, 관찰을 순서대로 밟고 필요한 만큼 반복한 뒤 최종 답변으로 닫힘
• 행동 단계에서 Flights, Search, Code, None처럼 주어진 후보 중 하나를 고르며 None은 툴을 쓰지 않겠다는 선택
• 백서 예시의 모델은 항공편 질문을 기존 지식으로 추측해 환각을 내는 대신 Flights 툴로 실시간 정보를 끌어와 답을 구성

확장 기능과 함수, 실행 주체가 다르다

• 확장 기능은 API와 에이전트 사이를 표준화된 방식으로 잇고, 사용 예시와 필수 인자를 학습시켜 에이전트가 엔드포인트를 직접 호출하게 만듦
• 커스텀 코드로 쿼리에서 출발지와 도착지를 뽑아 API를 부르는 방식은 출발 도시가 빠진 문장 하나에도 실패하고 예외 처리 코드가 계속 불어남
• 에이전트는 실행 시점에 내장 예시를 근거로 어떤 확장 기능이 이 쿼리에 맞는지 동적으로 고르며, 에이전트와 확장 기능은 1대다로 붙음
• 구글은 프로젝트에 바로 가져다 쓰는 기본 확장 기능을 제공하고, 코드 인터프리터는 자연어 설명을 파이썬 코드로 바꿔 실행까지 해줌
• 제미나이 앱 설정의 확장 기능 메뉴에서 원하는 항목을 켜면 항공편 조회 같은 요청을 바로 시험해볼 수 있음
• 함수는 모델이 호출할 함수 이름과 인자만 출력하고 실제 API 호출은 클라이언트 애플리케이션이 수행하는 구조

함수 호출이 실제로 쓰이는 방식

• 함수를 고르는 이유는 인증 제약으로 에이전트가 API에 닿지 못하거나, 배치나 사람 검토처럼 실시간 호출이 불가능하거나, 응답에 추가 변환이 필요할 때
• 스키 여행 추천 사례에서 일반 프롬프트는 도시 목록을 산문으로 뱉지만, 함수 호출은 cities와 preferences 키를 가진 JSON 페이로드로 정형화
• 클라이언트 서버는 그 페이로드를 받아 구글 플레이스 API로 도시 이미지를 가져오고 사용자에게 서식이 적용된 화면으로 돌려줌
• 함수 호출은 함수를 실행하지 않으므로 인증 정보를 코드에 심을 필요가 없고, 수 초 이상 걸리는 비동기 작업이나 다른 기기에서의 실행에도 맞음
• 외부 API 결과를 에이전트에 되돌릴지는 개발자 판단이며, 이후 추론에 쓸 일이 없으면 반환을 생략해 에이전트를 루프 밖에 둬도 됨

데이터 저장소와 목표 학습

• 데이터 저장소는 정적인 학습 데이터의 한계를 메우려고 스프레드시트나 PDF 같은 자료를 원본 형식 그대로 붙이는 통로
• 문서는 벡터 임베딩으로 변환돼 벡터 데이터베이스에 적재되며, 데이터 변환이나 재학습, 미세 조정 없이 최신 정보를 끌어 쓸 수 있음
• RAG 루프는 쿼리 임베딩 생성, 스캔(SCaNN) 같은 알고리즘으로 매칭, 원문 텍스트 회수, 에이전트의 응답 구성 순으로 돌아감
• 문맥 내 학습은 프롬프트와 소수 예시만으로 추론 시점에 툴 사용법을 즉석에서 익히게 하는 방식이고 ReAct가 그 사례
• 검색 기반 문맥 내 학습은 외부 메모리에서 관련 예시와 툴을 끌어와 프롬프트를 동적으로 채우며, 버텍스 AI 확장의 예시 저장소가 이 부류
• 미세 조정 기반 학습은 추론 전에 대규모 예시로 모델을 미리 훈련시키는 쪽이다. 세 방식은 속도와 비용, 지연에서 서로 상충하므로 섞어 쓰는 편이 유리

프로토타입에서 프로덕션까지

• 백서는 랭체인과 랭그래프로 gemini-1.5-flash-001에 서프API 검색과 구글 플레이스 툴을 물린 프로토타입을 예시로 제시
• 이 에이전트는 텍사스 롱혼스의 지난주 상대를 검색으로 찾은 뒤, 이어서 그 팀 경기장 주소를 장소 API로 조회하는 2단 질문을 처리
• 실제 서비스에는 사용자 인터페이스, 평가 프레임워크, 지속적 개선 장치가 더 필요하며 버텍스 AI가 이를 관리형 환경으로 묶어 제공
• 개발자는 목표와 작업 지침, 툴, 위임할 하위 에이전트를 자연어로 정의하고 인프라와 배포, 유지보수는 플랫폼에 넘길 수 있음
• 백서는 도메인별로 강한 에이전트를 이어 붙이는 에이전트 체이닝을 다음 흐름으로 꼽으며, 아키텍처 설계는 반복 실험이 전제라고 못 박음