Function Calling과 Grounding으로 외부 세계와 연결하기
AI가 모르는 것을 처리하게 하는 방법
앞 장까지는 모델이 입력을 이해하고, 정해진 형식의 결과를 내보내는 방법을 배웠다. 이제 한 단계 더 나아가야 한다. 실제 업무에서는 모델의 기억만으로 답할 수 없는 질문이 많다. "오늘 서울 날씨는?", "이 상품 재고가 남았나?", "고객 A의 최근 주문은?", "이 공지 페이지의 핵심 변경점은?" 같은 질문은 최신 정보나 내부 시스템 상태가 필요하다.
이때 사용하는 대표 기능이 Function Calling, Grounding with Google Search, URL Context다. 셋의 역할은 다르다. Function Calling은 내 시스템의 함수나 API로 연결하는 방식이고, Google Search Grounding은 공개 웹의 최신 정보로 답변을 보강하는 방식이며, URL Context는 사용자가 지정한 페이지를 읽고 그 범위 안에서 답하게 하는 방식이다.

Function Calling은 '실행'이 아니라 '호출 제안'이다
Function Calling을 처음 볼 때 가장 많이 하는 오해는 "모델이 함수를 직접 실행한다"는 생각이다. 정확히는 그렇지 않다. 개발자가 함수의 이름, 설명, 입력 파라미터 스키마를 모델에게 알려주면, 모델은 사용자 요청을 보고 어떤 함수를 어떤 인수로 호출해야 하는지 JSON 형태로 제안한다. 실제 API 호출, 데이터베이스 조회, 예약 처리, 결제 실행은 개발자의 애플리케이션 코드가 담당한다.1
예를 들어 사용자가 "내일 부산 날씨에 맞춰 출장 복장을 추천해줘"라고 묻는다고 하자. 모델은 get_weather 함수를 선택하고, city: 부산, date: 내일 같은 인수를 만든다. 애플리케이션은 이 값을 받아 실제 날씨 API를 호출한다. 그 결과를 다시 모델에 전달하면, 모델은 "비 예보가 있으니 방수 신발과 얇은 외투를 준비하세요"처럼 자연어 답변을 만든다.
함수 설계는 이름보다 스키마가 중요하다
좋은 함수 호출은 좋은 함수 선언에서 시작한다. 함수 이름은 짧고 동작이 분명해야 한다. 설명에는 "언제 이 함수를 써야 하는지"를 적는다. 파라미터에는 타입, 필수값, 허용 형식, 예외 조건을 넣는다.
예를 들어 재고 확인 함수라면 이렇게 설계할 수 있다.
함수 이름:
check_inventory설명: 특정 상품의 현재 판매 가능 재고를 확인한다.
필수 파라미터:
product_id문자열,store_id문자열선택 파라미터:
size,color반환 형식: 재고 수량, 품절 여부, 입고 예정일
테스트할 때는 정상 질문만 넣지 말아야 한다. "검은색 M 사이즈 있어?", "강남점에 남았어?", "상품명은 모르고 사진만 있어"처럼 정보가 부족한 요청도 넣어본다. 모델이 함수를 성급히 호출하는지, 추가 질문을 하는지, 잘못된 인수를 만들지는 않는지 확인해야 한다.
여러 도구를 조합하는 워크플로
Gemini API의 함수 호출은 한 번에 여러 함수를 호출하는 병렬 호출, 첫 결과를 바탕으로 다음 함수를 고르는 순차·합성 호출, 내장 도구와 사용자 정의 함수를 함께 쓰는 멀티툴 사용을 지원한다.2
실무에서는 이 조합이 중요하다. "다음 주 화요일 오후에 고객 미팅 가능한 시간을 잡고, 이동 시간을 고려해 가장 가까운 지점을 추천해줘"라는 요청은 한 함수로 끝나지 않는다. 일정 조회, 고객 위치 확인, 지점 검색, 이동 시간 계산이 이어진다. 서로 독립적인 정보는 병렬로 조회하고, 앞 단계 결과가 필요한 작업은 순차로 처리한다.
단, 자동화 범위는 명확히 제한해야 한다. 조회는 자동으로 해도 되지만, 예약 확정·결제·삭제처럼 되돌리기 어려운 작업은 사용자의 확인을 한 번 더 받게 설계하는 편이 안전하다.
최신 공개 정보에는 Google Search Grounding
모델은 학습 시점 이후의 정보를 기본적으로 알 수 없다. 최신 뉴스, 시장 동향, 최근 수상자, 현재 제품 가격처럼 공개 웹의 최신성이 중요한 질문에는 Grounding with Google Search를 켠다. 이 기능은 Gemini가 실시간 웹 콘텐츠를 활용해 더 정확한 답을 만들고, 검증 가능한 출처를 함께 제시하도록 돕는다.3
하지만 모든 질문에 검색이 필요한 것은 아니다. "회의록을 요약해줘", "문장을 더 공손하게 바꿔줘", "이 JSON을 표로 바꿔줘" 같은 작업은 검색 없이도 충분하다. 반대로 "2026년 현재", "최근", "오늘", "공식 발표에 따르면" 같은 표현이 들어가면 검색 사용을 우선 고려한다.
특정 페이지를 읽게 할 때는 URL Context
URL Context는 사용자가 제공한 URL의 내용을 모델 컨텍스트로 가져와 답변에 활용하는 도구다. 제품 페이지 비교, 공지사항 요약, 문서 검토, 채용공고 분석처럼 "이 페이지 안에서만 답하라"는 작업에 적합하다.4
프롬프트는 범위를 분명히 해야 한다.
아래 URL의 내용만 근거로 삼아 변경 사항을 요약해줘. 페이지에 없는 내용은 추측하지 말고 "확인 불가"라고 표시해줘. 마지막에는 사용자가 확인해야 할 체크리스트를 만들어줘.
이렇게 쓰면 모델이 일반 지식으로 빈칸을 채우는 일을 줄일 수 있다. 여러 URL을 비교할 때도 "공통점", "차이점", "각 페이지에서 확인된 근거"처럼 출력 항목을 정해두면 결과를 업무 문서로 옮기기 쉽다.
신뢰도는 실패 규칙에서 나온다
외부 도구를 붙이면 답변이 강해지지만, 실패 가능성도 늘어난다. API가 느릴 수 있고, 검색 결과가 없을 수 있으며, URL 접근이 막힐 수 있다. 그래서 도구 설계에는 성공 흐름만이 아니라 실패 규칙도 포함해야 한다.
규칙은 간단할수록 좋다. 도구가 필요한 이유를 먼저 판단한다. 호출 결과가 있으면 답변에 어떻게 반영할지 정한다. 빈 결과면 "찾을 수 없음"이라고 말한다. 권한 제한이면 사용자에게 필요한 접근 권한을 안내한다. 출처가 필요한 답변이면 근거를 함께 보여준다.
Function Calling은 AI를 업무 시스템에 연결한다. Grounding은 최신 공개 정보에 연결한다. URL Context는 지정한 문서와 페이지에 연결한다. 세 기능을 함께 쓰면 AI Studio의 실험은 단순한 대화에서 실제 업무 흐름으로 확장된다.
참고
1Function calling with the Gemini API - Google AI for Developers
2Function calling with the Gemini API - Google AI for Developers
3Grounding with Google Search - generateContent API | Google AI for Developers
4URL context - generateContent API | Google AI for Developers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.