최근 Google DeepMind가 Gemini API에 "멀티툴 체이닝(툴 조합)"과 "컨텍스트 순환"을 더해, 복잡한 에이전트 워크플로우의 오케스트레이션 부담을 크게 낮췄다는 소식이 나왔습니다1. 한마디로, 모델이 여러 도구를 엮어 쓰고 그 결과를 자연스럽게 이어받게 되면서 "대화형 앱"이 "일하는 에이전트"로 넘어가는 문턱이 낮아졌습니다.
멀티툴 체이닝: 내 함수 + 구글 기본 도구를 한 번에
예전에는 "먼저 검색 → 결과 요약 → 그다음 우리 서버 함수 호출"처럼 단계를 사람이(혹은 오케스트레이터가) 나눠 설계하는 경우가 많았습니다. 이제는 Google Search나 Google Maps 같은 기본 도구와, 여러분이 선언한 커스텀 함수(tool)를 한 요청 안에 같이 넣을 수 있어요2.
체감 포인트는 지연 시간과 설계 복잡도입니다. 모델이 상황에 따라 "공개 데이터는 검색으로", "사내 데이터는 백엔드 함수로" 자연스럽게 갈아타니, 프롬프트/상태/라우팅 코드를 덜 짜도 됩니다. 예를 들어 '주말 모임 장소 추천'을 만들 때 검색으로 후보를 모으고, 곧바로 사내 예약 API를 호출하는 흐름이 더 매끄러워지는 식이죠.
컨텍스트 순환: 툴 결과가 다음 툴의 연료가 된다
에이전트가 멀티스텝으로 일할 때 자주 터지는 문제가 "앞에서 얻은 툴 결과를 다음 단계가 까먹는 것"입니다. 이번 업데이트의 핵심인 컨텍스트 순환은, 툴 호출과 응답을 모델 컨텍스트에 보존해 다음 툴/다음 턴에서 그대로 참고하게 합니다2.
이게 왜 중요하냐면, 개발자가 중간 결과를 요약해서 다시 넣거나(토큰 비용), 별도 상태 저장소에 적재하고 다시 꺼내오는(구현 비용) 일을 줄여주기 때문입니다. 예시로, 날씨 도구로 실시간 정보를 가져온 뒤 그 데이터를 그대로 이어받아 '장소 예약' 같은 커스텀 도구를 호출하는 흐름이 더 자연스러워집니다2.
디버깅이 쉬워진 이유: Tool response ID의 등장
툴을 병렬로 호출하기 시작하면 디버깅이 급격히 어려워집니다. "어느 호출의 응답이 어느 결과로 이어졌지?"가 꼬이거든요. Gemini API는 각 툴 호출에 고유 식별자(id)를 붙여, 비동기/병렬 실행에서도 요청-응답 매핑을 정확히 하도록 했습니다2.
개발자 입장에선 운영 단계에서 로그 추적이 쉬워지고, 에이전트가 실수했을 때 "모델이 틀린 게 아니라 특정 툴 응답이 늦게/다르게 들어온 것" 같은 원인 분석도 빨라집니다.
시사점: 에이전트는 쉬워지고, 비용·접근 전략이 중요해진다
툴 체이닝과 컨텍스트 순환이 편해질수록, 오히려 중요한 건 "어떤 모델/요금/접근 방식으로 실험→운영까지 가져가느냐"입니다. 운영비 폭주를 막으려면 프로젝트 단위 월 지출 상한(Project Spend Caps) 같은 안전장치가 실무에서 꽤 유용합니다3.
시작은 가볍게 해도 됩니다. 빠른 프로토타입은 AI Studio에서 API 키를 발급받아 간단히 호출해보면 감이 오고4, 프론트엔드 데모 수준이면 Puter.js처럼 키 없이도 브라우저에서 테스트 가능한 경로도 있습니다(서비스 구조는 다르니 목적에 맞게 선택하세요)5. 중요한 건 "툴을 많이 붙일수록 설계가 쉬워진다"가 아니라, "툴을 많이 붙이기 쉬워졌으니 관측(로그/ID)과 비용 통제가 더 중요해졌다"는 점입니다.
참고
1Google Deepmind upgrades Gemini API with multi-tool chaining and context circulation
2Gemini API tooling updates: context circulation, tool combos and Maps grounding for Gemini 3
3Giving you more transparency and control over your Gemini API costs
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.