AI가 도구를 호출하면 업무도 끝난 걸까요?

오늘의 인사이트 요약

• 도구 호출은 AI가 사용할 기능과 입력값을 정해 전달하는 방식입니다.

• 직접 만든 도구는 애플리케이션이 실행하고 결과를 AI에 돌려줍니다.

• 호출 요청, 실행 성공, 업무 완료를 구분하고 권한은 서버에서 확인합니다.

AI가 주문을 조회하거나 업무 시스템의 정보를 바꾼다고 하면, 답변을 쓰는 모델이 어디까지 처리하는지 궁금하실 텐데요. 도구 호출은 AI가 외부 기능을 사용하도록 연결하는 방법입니다. 다만 기능을 호출하겠다는 응답이 나왔다고 실제 업무까지 끝난 것은 아닙니다. 오늘은 도구 호출의 원리와 실행 과정, 서비스를 만들 때 구분할 권한과 완료 상태를 알아보겠습니다.

1. 도구 호출은 어떤 기능일까?

도구 호출은 모델이 사용할 수 있는 기능의 설명과 입력 규칙을 보고, 필요한 기능과 전달할 값을 고르는 방식입니다. 함수 호출이라고도 부릅니다. 개발자는 주문 조회, 일정 검색처럼 허용할 기능을 등록하고, 모델은 사용자의 요청을 처리하는 데 그 기능이 필요한지 판단합니다.

가상의 주문 상담 서비스를 예로 들겠습니다. 사용자가 주문 상태를 물으면 AI는 주문 조회 기능에 주문 번호를 전달하도록 요청할 수 있습니다. 이때 AI가 돌려준 것은 조회 요청입니다. 실제 주문 데이터베이스를 읽는 일은 연결된 프로그램이 맡습니다. 외부 도구가 없다면 모델이 최신 주문 상태를 알고 있다고 전제해서는 안 됩니다.

직접 만든 도구와 제공자 도구의 차이

도구의 실행 위치는 제품 구성에 따라 다릅니다. Claude의 직접 정의한 도구는 애플리케이션에서 실행하고, 웹 검색 같은 서버 도구는 제공자 인프라에서 실행합니다. 따라서 모든 도구를 우리 서버가 실행한다고 일반화하기보다 실행 주체를 확인하는 편이 정확합니다. 두 방식의 차이와 호출 흐름은 Claude의 도구 사용 안내에서 더 자세히 보실 수 있습니다.

2. 호출 요청은 어떻게 실행 결과가 될까?

직접 만든 도구를 연결할 때는 모델 응답에서 도구 이름과 입력값을 읽고 해당 기능을 실행합니다. 주문 조회라면 서버가 주문 번호를 받아 기존 시스템에 조회한 뒤 결과를 돌려주는 식입니다. AI는 그 결과를 바탕으로 사용자가 이해할 답변을 작성할 수 있습니다. 모델 응답과 실제 시스템 동작 사이에 애플리케이션의 처리가 있는 셈입니다.

도구 결과는 어떤 호출의 응답인지 연결해 전달합니다. Claude에서는 호출의 식별자와 결과를 짝지어 보내며, 실행 오류도 결과에 표시할 수 있습니다. 여러 도구를 썼다면 어떤 결과가 어떤 호출에 대한 것인지 짝을 맞춰 전달합니다. 오류를 결과로 전달하는 형식까지 살펴보고 싶다면 도구 호출 처리 문서를 참고해 보세요.

입력 규칙과 업무 조건은 다릅니다

입력 규칙에는 주문 번호가 문자열인지, 어떤 항목이 필요한지 등을 정의합니다. 기능 이름과 설명도 모델이 도구를 고르는 근거가 됩니다. 설명을 구체적으로 쓰고 입력값을 정의하는 방법은 도구 정의 문서에서 예시와 함께 볼 수 있습니다. 입력 형식이 맞아도 그 주문이 실제로 존재하는지까지 확인된 것은 아닙니다.

같은 주문 번호라도 로그인한 사용자가 볼 수 있는 주문인지는 별도 문제입니다. 모델이 제시한 고객 번호를 그대로 받아들이면 다른 사람의 자료에 접근할 수 있습니다. 조회 권한과 데이터 소유 관계는 애플리케이션이 현재 사용자 정보를 기준으로 검사합니다. 이는 특정 모델의 기능 설명이 아니라 서비스에 적용할 설계 기준입니다.

3. 업무 완료는 어떤 결과로 판단할까?

화면에는 AI의 도구 요청과 실제 업무 처리 상태를 구분해 보여주는 것이 좋습니다. 조회를 시작했는지, 데이터를 받았는지, 조회에 실패했는지에 따라 안내가 달라집니다. 요청이 만들어졌다는 이유만으로 성공 문구를 먼저 보여주면 사용자는 아직 처리되지 않은 일을 끝난 것으로 받아들일 수 있습니다.

가상의 일정 변경 도구라면 조회와 저장은 서로 다른 동작입니다. 가능한 시간을 찾은 뒤에도 사용자가 고른 일정이 확정됐는지, 저장 시점에 다른 사람이 먼저 예약하지 않았는지 확인할 일이 남습니다. AI가 변경하겠다고 답한 문장보다 시스템에 반영된 결과를 완료 판단의 근거로 삼습니다.

결과를 알 수 없을 때의 처리

통신이 끊겨 응답을 받지 못했다면 실제 반영 여부도 모를 수 있습니다. 변경 요청을 무조건 다시 보내기보다 기존 시스템에서 반영 여부를 조회할 수 있는지 살펴봅니다. 재시도 규칙은 연결한 기능의 특성에 맞춰 정하며, 같은 요청을 다시 보내도 중복 처리되지 않는지 확인합니다.

조회 도구부터 연결할지, 데이터 변경까지 허용할지도 업무별로 정합니다. 중요한 변경에는 적용할 대상과 값을 보여주고 사용자 확인을 거치도록 설계할 수 있습니다. 확인할 정보가 없거나 권한이 부족한 요청은 추가 질문이나 담당자 검토로 넘깁니다. 자동 처리 범위를 넓힐 때는 도구 수를 늘릴 때와 별도로 검토합니다.

업무 맥락과 시스템 연결을 함께 설계합니다

똑똑한개발자는 사내 시스템 똑빌더를 구축해 프로젝트 맥락과 담당자·에이전트의 실행을 연결하는 업무 방식을 운영하고 있습니다. 아래 소개서 장표는 원문과 결정, 기한, 상태를 프로젝트 단위로 잇는 구성을 보여줍니다. 특정 고객사의 주문 조회 기능을 구축했다는 사례로 소개하는 자료는 아닙니다.

AI가 사용할 도구와 기존 시스템의 실행 범위를 함께 설계하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요. 업무 분석부터 시스템 구축과 운영 개선까지 연결해 살펴보겠습니다. 감사합니다.