• 목록

LLM이 일정 조회나 데이터 검색을 위해 도구를 호출한다는 설명을 들으면 모델이 직접 프로그램을 실행한다고 생각하기 쉽습니다. 그러나 사용자 정의 함수 호출의 기본 흐름에서는 모델이 함수 이름과 인수를 제안하고 애플리케이션이 실제 실행을 맡습니다.

실행 결과를 다시 모델에 전달해야 사용자가 이해할 답변으로 이어질 수 있습니다. 호출 요청과 실행, 성공 확인을 나누어 이해하는 방법을 정리합니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
사용자 정의 도구 호출은 함수 이름과 인수를 담은 요청이며 실행 완료의 증거가 아닙니다. 애플리케이션이 인수와 권한을 확인해 실행하고 실제 결과를 연결해야 합니다.

---

1. 모델이 받는 함수 설명과 실행 코드를 구분합니다

애플리케이션은 모델에게 사용할 수 있는 함수의 이름과 목적, 인수 형식을 설명할 수 있습니다. 모델은 이를 바탕으로 적절한 호출을 생성합니다.

설명을 전달했다고 실제 함수 구현이 모델 내부로 옮겨지는 것은 아닙니다. Google의 함수 호출 문서는 사용자 정의 함수의 이름과 인수를 추출해 애플리케이션에서 실행하는 기본 흐름을 설명합니다.

가상의 날씨 조회 도구라면 모델은 지역 인수를 담은 요청을 만들고 서버의 코드가 조회를 수행합니다. 내장 도구나 SDK가 일부 과정을 대신하는 경우에도 호출 생성과 실제 실행의 역할을 구분해 보면 시스템 동작을 이해하기 쉽습니다.

이 글은 특정 SDK의 자동 실행 설정을 그대로 안내하는 글은 아닙니다.

---

2. 호출 요청은 해야 할 일과 입력값을 표현합니다

가상의 도구 get_order_status에 주문 식별자를 전달한다고 생각해 봅니다. 모델이 함수 이름과 인수를 올바른 구조로 만들었어도 해당 주문이 존재하거나 조회 권한이 있다는 뜻은 아닙니다.

날짜와 범위, 단위처럼 형식은 맞아도 의미가 잘못된 값이 들어올 수 있습니다. 애플리케이션은 허용된 함수인지와 필요한 인수의 형식·범위를 확인해야 합니다.

모델 출력 문자열을 임의 코드로 실행하는 방식과 미리 정의한 함수를 선택하는 방식은 구분합니다. 호출 요청을 받았다는 상태를 기록하고 아직 실행하지 않았다면 완료 상태로 표시하지 않습니다.

입력 검증의 결과도 이후 흐름을 결정하는 별도 단계입니다.

---

3. 사용자의 권한은 서버에서 확인합니다

모델이 특정 사용자나 자원 식별자를 인수에 넣었다는 이유로 접근을 허용하면 안 됩니다. 실제 로그인한 사용자의 권한과 서비스 정책은 애플리케이션이 확인해야 합니다.

가상의 주문 조회에서는 요청한 주문이 해당 사용자가 볼 수 있는 대상인지 검증합니다. 모델이 잘못된 인수를 만들지 않도록 설명하는 것과 서버가 권한을 강제하는 것은 다른 방어입니다.

상태를 바꾸는 작업이라면 사용자의 실제 요청 범위와 필요한 승인 조건도 시스템에서 다뤄야 합니다. 도구 설명에 주의 문구를 넣었다는 사실만으로 권한 검사가 구현되는 것은 아닙니다.

개발 문서에는 모델 판단과 애플리케이션 검증의 경계를 명시하는 편이 좋습니다.

---

4. 실행 결과는 성공과 실패를 구분해 돌려줍니다

함수가 실행되면 반환값을 도구 호출과 연결해 모델에 전달할 수 있습니다. 가상의 조회 결과가 없음인지, 접근이 거절되었는지, 외부 서비스가 실패했는지는 서로 다른 상태입니다.

빈 문자열 하나로 모두 표현하면 모델이 상황을 구분하기 어려울 수 있습니다. 결과 형식에는 필요한 상태와 데이터, 사용자가 이해하는 데 필요한 제한을 담는 설계를 생각할 수 있습니다.

내부 비밀정보나 불필요한 원문을 결과에 넣을 이유는 없습니다. 실행이 실패했는데 성공했다는 텍스트를 결과로 보내면 최종 답변도 잘못될 수 있습니다.

반환값이 어떤 사실을 확인했는지와 아직 확인되지 않은 부분이 무엇인지 분명하게 표현해야 합니다.

---

5. 조회와 변경 작업은 실패 후 대응이 다를 수 있습니다

읽기 전용 조회와 예약 생성 같은 상태 변경은 같은 방식으로 재시도하기 어려울 수 있습니다. 가상의 예약 요청이 서버에서 처리되었지만 응답만 유실되면 다시 실행할 때 중복이 생길 수 있습니다.

애플리케이션은 요청 식별자와 실제 저장 상태를 확인하는 등 업무에 맞는 중복 방지와 복구를 설계해야 합니다. 모델에게 다시 시도하라고 말하는 것만으로 이 문제가 해결되지는 않습니다.

호출이 실패했다고 보이는 상황과 실제 작업이 수행되지 않은 상황을 구분합니다. 실행 결과가 불명확하면 완료 여부를 확인할 경로를 마련하고 확인 전에는 성공이나 미실행을 단정하지 않는 것이 중요합니다.

---

6. 여러 호출은 관계와 결과 연결이 필요합니다

모델이 여러 도구 요청을 생성하거나 한 결과를 보고 다음 호출을 만드는 흐름이 있을 수 있습니다. 서로 독립적인 조회와 앞선 결과가 필요한 작업은 구분해야 합니다.

가상의 예에서 상품 목록 조회와 사용자 선호 조회는 독립적일 수 있지만 선택한 상품을 예약하는 작업은 확인된 대상과 권한이 필요합니다. 병렬 실행 가능 여부를 함수 이름만 보고 결정하지 말고 실제 의존 관계와 서비스 조건을 살펴봅니다.

결과를 돌려줄 때는 어떤 호출의 결과인지 식별할 수 있어야 합니다. 호출 순서와 결과 연결이 어긋나면 데이터가 맞아도 최종 답변이 다른 대상을 설명할 수 있으므로 기록과 검증이 필요합니다.

---

7. 최종 답변은 실제 확인한 결과를 기준으로 만듭니다

모델이 사용자에게 예약이 완료되었다고 말하려면 실제 실행 결과에서 완료가 확인되어야 합니다. 호출을 생성했다거나 실행을 시작했다는 사실만으로 같은 표현을 쓰면 안 됩니다.

가상의 상태표에는 요청 생성, 검증 통과, 실행 중, 결과 확인, 사용자 안내를 나눌 수 있습니다. 처리 시간이 길어 중간 상태를 제공한다면 현재 어디까지 진행됐는지 설명합니다.

결과가 부분적으로만 확인되었을 때도 성공한 범위와 남은 범위를 구분합니다. 도구를 쓰는 목적은 답변에 기술적인 장식을 더하는 것이 아니라 외부의 실제 데이터와 작업 결과를 연결하는 데 있습니다.

사용자 안내가 실행 기록과 맞는지 확인하는 단계가 중요합니다.

---

8. 작은 모의 도구로 전체 흐름을 검증합니다

처음에는 실제 외부 상태를 바꾸지 않는 가짜 조회 함수를 만들어 정상 결과와 입력 오류, 권한 거절, 시간 초과를 반환해 볼 수 있습니다. 각 상황에서 모델이 어떤 호출을 만들고 애플리케이션이 무엇을 실행하며 최종 답변이 어떻게 달라지는지 기록합니다.

이 실습은 실제 운영의 모든 보안과 신뢰성 요구를 검증하는 것은 아니지만 단계 구분을 익히는 데 유용합니다. 로그에는 호출 식별자와 상태를 남기고 민감한 인수나 결과를 불필요하게 출력하지 않습니다.

이후 실제 기능을 연결할 때도 같은 상태 구분을 유지하면 불명확한 성공 안내를 줄이고 오류가 생긴 단계를 찾기 쉽습니다.

---

9. 자주 묻는 질문

Q1. 모델이 함수 호출을 만들면 이미 실행된 건가요?

사용자 정의 함수 호출의 기본 흐름에서는 요청을 만든 단계입니다. 실제 실행은 애플리케이션이나 이를 담당하는 실행 계층이 맡습니다.

SDK가 자동화하더라도 결과 확인은 구분해야 합니다.

Q2. 인수 형식이 맞으면 그대로 실행해도 되나요?

형식 외에 값의 범위와 의미, 사용자 권한을 확인해야 합니다. 모델이 준 자원 식별자가 허용된 대상이라는 보장은 없습니다.

서버의 검증과 정책이 필요합니다.

Q3. 실패하면 모델에게 다시 호출하게 하면 되나요?

작업 종류와 실제 처리 상태를 확인해야 합니다. 상태 변경 작업은 응답만 유실된 경우 재시도로 중복이 생길 수 있습니다.

요청 식별과 결과 확인 절차를 업무에 맞춰 설계합니다.

Q4. 도구 결과를 전부 모델에 보내는 것이 좋나요?

답변에 필요한 정보와 상태만 전달하는 설계를 검토합니다. 비밀정보나 불필요한 원문을 포함할 필요는 없습니다.

데이터의 권한과 로그 노출 범위도 함께 확인해야 합니다.

---

참고 자료

• Google: 사용자 정의 함수 호출의 실행 흐름