답변하는 AI에서 실행하는 AI로
어떤 프롬프트는 대답을 아주 그럴듯하게 만들어 준다. 하지만 실무에서는 그 다음이 더 중요하다. 고객 정보를 조회해야 하고, 최신 문서를 검색해야 하고, 계산을 해야 하고, 때로는 티켓을 생성하거나 메시지를 보내야 한다. 이 지점에서 AI는 더 이상 "잘 말하는 모델"로는 부족하다. 실제 세계와 접속해 일을 처리하는 시스템이 되어야 한다.
답변은 결과가 아니라 시작일 때가 많다
입문 단계에서는 보통 프롬프트를 "좋은 문장을 얻는 기술"로 이해한다. 질문을 더 구체적으로 쓰고, 형식을 지정하고, 예시를 넣으면 답변 품질이 올라간다. 여기까지는 맞다. 그러나 운영 환경에서는 사용자의 목표가 대답 그 자체가 아닌 경우가 많다.
예를 들어 사용자가 "이번 주 미결제 주문을 찾아서 담당자에게 요약 메일 초안을 만들어 줘"라고 말한다고 해보자. 이 요청은 사실 여러 층으로 이루어져 있다. 미결제 주문을 조회해야 하고, 결과를 정리해야 하며, 메일 초안을 작성해야 한다. 모델이 이 중 하나라도 추측으로 메우면 그럴듯해 보여도 실무적으로는 실패다. 최신 주문 상태를 모른 채 답하면 틀릴 수 있고, 실제 고객 데이터가 없는 상태에서 메일을 쓰면 공허한 문장이 된다.
그래서 고급 프롬프트 엔지니어링은 질문을 잘 쓰는 법에서 한 걸음 더 나아간다. "무엇을 말하게 할까?"가 아니라 "무엇을 하게 만들까?"를 설계해야 한다. 이때 핵심 단위는 문장이 아니라 행동이다.
도구 사용은 모델이 바깥세계를 만나는 방식이다
도구 사용, 또는 함수 호출은 모델이 외부 시스템을 직접 실행하는 능력처럼 보이지만, 실제 구조는 더 단정하다. 모델은 스스로 함수를 실행하지 않는다. 대신 어떤 도구를 써야 하는지 결정하고, 그 도구에 넘길 인자를 구조화된 형태로 제안한다. 실제 실행은 애플리케이션이 담당한다. 그리고 애플리케이션은 결과를 다시 모델에 돌려주어 최종 응답을 만든다.1
이 단순한 구분이 매우 중요하다. 모델은 판단과 조합을 맡고, 시스템은 권한과 실행을 맡는다. 다시 말해 모델은 "무엇을 호출할지"를 제안하는 두뇌에 가깝고, 실제로 손을 움직이는 쪽은 애플리케이션이다.2
이 구조 덕분에 LLM은 세 가지 약점을 보완할 수 있다.
최신 정보에 약하다는 점
계산이나 조회처럼 정확한 절차 작업에 취약하다는 점
외부 시스템 상태를 바꿀 수 없다는 점
날씨 조회, 환율 계산, 사내 문서 검색, 데이터베이스 질의, 티켓 생성, 캘린더 등록 같은 작업은 모두 이 틀 안에서 다룰 수 있다. 중요한 것은 "모델이 모든 걸 안다"는 환상에서 벗어나는 것이다. 좋은 에이전트는 많이 아는 모델이 아니라, 필요한 순간에 적절한 도구를 부를 수 있는 모델이다.
함수 호출은 프롬프트의 경쟁자가 아니라 인터페이스다
초보자는 종종 이렇게 생각한다. "프롬프트를 아주 잘 쓰면 도구 없이도 해결되지 않을까?" 일부 작업은 그렇다. 하지만 외부 사실 확인, 실시간 조회, 정밀 계산, 상태 변경이 필요한 순간에는 프롬프트만으로 버티는 것이 아니라 프롬프트와 도구를 함께 설계해야 한다.
여기서 프롬프트의 역할은 사라지지 않는다. 오히려 더 중요해진다. 프롬프트는 모델에게 언제 텍스트로 바로 답하고, 언제 도구를 써야 하며, 어떤 경우에는 사용자 확인을 먼저 받아야 하는지를 가르치는 운영 규칙이 된다. 함수 호출은 그 규칙이 실제 시스템과 만나는 인터페이스다.
제공자마다 표현 방식은 조금 다르지만, 전체 흐름은 대체로 같다. 도구 정의를 함께 보내고, 모델이 필요하면 구조화된 호출을 반환하고, 애플리케이션이 실행한 뒤 결과를 다시 넣어 최종 응답을 받는다. 형식이 달라도 본질은 같은 두 단계 루프다.2
이 관점으로 보면 프롬프트와 함수 호출의 관계가 분명해진다.
프롬프트는 정책이다. 함수 호출은 계약이다. 실행 코드는 집행이다.
셋 중 하나라도 흐리면 시스템은 흔들린다. 정책이 약하면 모델이 도구를 써야 할 때 말로 때운다. 계약이 부실하면 잘못된 인자를 만든다. 집행이 느슨하면 위험한 요청이 그대로 실행된다.
좋은 도구 정의는 "설명"이 아니라 "계약"이다
도구를 붙였는데도 에이전트가 엉뚱한 행동을 하는 경우가 많다. 대부분은 모델이 멍청해서가 아니라 도구 정의가 흐리기 때문이다. 도구 이름이 모호하거나, 설명이 짧거나, 파라미터가 불분명하면 모델은 어떤 상황에서 그 도구를 써야 하는지 안정적으로 판단하기 어렵다.
좋은 도구 정의는 최소한 네 가지를 분명히 해야 한다.3
이 도구가 무엇을 하는가 검색 도구인지, 읽기 전용 조회인지, 실제 변경을 일으키는 실행 도구인지 드러나야 한다.
언제 사용해야 하는가 "사내 정책, 절차, 기술 문서를 찾을 때 사용"처럼 사용 조건이 설명에 들어가야 한다.
어떤 입력을 받아야 하는가 파라미터 이름은 구체적이어야 하고, 형식과 예시는 가능하면 명시해야 한다.
무엇을 절대 하면 안 되는가 삭제, 송금, 승인 같은 고위험 작업은 제한 조건이나 추가 승인 규칙이 따라야 한다.
예를 들어 search라는 이름보다 search_policy_documents가 낫다. email보다 draft_customer_email이 낫다. 이름만 바꿔도 모델의 선택 정확도가 올라간다. 설명란에는 "고객에게 실제 발송하지 않고 초안만 생성" 같은 제한을 넣을 수 있다. 파라미터에는 priority를 자유 문자열로 두기보다 low, medium, high 같은 제한값으로 두는 편이 안전하다.3
이 장에서 꼭 기억할 원칙이 하나 있다. 도구 스키마는 모델을 위한 문서이면서, 시스템을 위한 방화벽이기도 하다.
그리고 실제 실행 전에 함수 이름과 인자를 반드시 검증해야 한다. 모델이 그럴듯한 호출을 만들었다고 해서 그대로 실행하면 안 된다. 허용된 도구인지, 필수 인자가 있는지, 값의 범위가 맞는지, 실행 권한이 있는지 확인한 뒤에만 움직여야 한다.1
도구를 붙인다고 곧바로 에이전트가 되지는 않는다
도구 사용은 에이전트의 출발점이지 완성품이 아니다. 단일 도구 호출은 계산기 버튼을 한 번 누르는 것에 가깝다. 에이전트는 여러 단계를 이어서 목표를 달성하는 구조다. 그래서 중요한 질문은 "어떤 도구가 있나?"보다 "어떤 작업 단위로 쪼갤 것인가?"가 된다.
사용자가 "다음 주 고객 미팅 준비를 도와줘"라고 말하면, 이 요청은 너무 크고 모호하다. 이 상태로 바로 실행하면 모델은 보통 조언을 길게 늘어놓는다. 하지만 실무적으로 필요한 것은 조언이 아니라 작업 분해다.
좋은 실행 단위는 네 가지 성질을 가져야 한다.4
구체적이어야 한다. 무엇이 성공인지 한 문장으로 말할 수 있어야 한다.
실행 가능해야 한다. 한 번의 모델 호출이나 하나의 도구 호출로 끝낼 수 있어야 한다.
순서가 보여야 한다. 앞 단계 결과가 있어야 뒤 단계가 가능한지 드러나야 한다.
검증 가능해야 한다. 통과와 실패를 비교적 명확하게 판정할 수 있어야 한다.
예를 들어 "고객 미팅 준비"를 다음처럼 바꾸면 시스템이 움직이기 쉬워진다.
고객사명, 미팅 날짜, 발표 목적을 사용자 요청에서 추출한다.
부족한 정보가 있으면 질문한다.
고객 산업 동향을 검색 도구로 수집한다.
수집 결과를 발표 목적에 맞게 요약한다.
슬라이드 초안 개요를 작성한다.
팀 미팅 초대 문구를 만든다.
실제 발송이나 등록 전에는 사용자 승인을 요청한다.
이 목록이 중요한 이유는, 이제 각 단계가 "말"이 아니라 "행동 후보"가 되었기 때문이다. 어느 단계는 모델만으로 되고, 어느 단계는 검색 도구가 필요하며, 어느 단계는 절대 자동 실행하면 안 된다.
실행 단위는 작을수록 좋지만, 너무 잘게 쪼개면 오히려 망한다
작업 분해를 배우면 모든 것을 잘게 쪼개고 싶어진다. 그러나 지나친 분해는 또 다른 문제를 만든다. 단계 수가 늘수록 지연이 늘고, 도구 호출이 많아지고, 실패 지점도 많아진다. "메일 보내기"를 열다섯 단계로 나누면 정교해 보이지만 실제로는 과공학이 된다.
좋은 기준은 이렇다. 한 단계가 하나의 의사결정과 하나의 책임을 가지면 충분하다.
예를 들어 아래 세 단계는 적당하다.
고객 정보를 조회한다.
조회 결과를 바탕으로 회신 초안을 작성한다.
발송 전 승인 여부를 확인한다.
반면 아래처럼 지나치게 쪼개면 흐름이 무거워진다.
고객 ID의 첫 글자를 읽는다.
고객 ID의 나머지 글자를 읽는다.
주문 목록 API를 호출할지 생각한다.
주문 목록 API 인자를 다시 확인한다.
응답 JSON의 첫 항목을 해석한다.
작업 분해의 목적은 세밀함이 아니라 통제 가능성이다. 사람이 디버깅하고, 평가하고, 중단시키고, 재시도할 수 있을 만큼만 분해해야 한다.
순차 작업과 병렬 작업을 구분해야 비용이 줄어든다
모든 단계가 줄을 서서 실행될 필요는 없다. 어떤 단계는 앞선 결과를 기다려야 하지만, 어떤 단계는 동시에 처리해도 된다. 이 구분은 성능과 비용에 직접 연결된다.4
예를 들어 내부 지식 도우미가 다음 일을 한다고 해보자.
정책 문서를 검색한다.
사용자 계정 상태를 조회한다.
최근 공지사항을 확인한다.
세 결과를 합쳐 답변을 만든다.
앞의 세 단계는 서로 의존하지 않을 수 있다. 그렇다면 병렬화가 가능하다. 반대로 "환불 승인 여부 판단"은 정책 검색 결과와 계정 상태가 모두 있어야 하므로 뒤에서 해야 한다.
이런 구분을 하지 않으면 에이전트는 불필요하게 느려진다. 반대로 의존 관계를 무시하면 순서가 꼬인다. "티켓 생성"보다 "중복 티켓 검색"이 먼저여야 하는데, 이를 뒤집으면 같은 문제로 티켓을 두 번 만들 수 있다.
실행형 프롬프트는 '말투'보다 '전이 조건'을 많이 담는다
답변형 프롬프트가 어조, 형식, 길이에 집중한다면, 실행형 프롬프트는 상태 전이에 집중한다. 즉, 다음 질문에 답해야 한다.
언제 바로 답할 것인가
언제 도구를 호출할 것인가
언제 추가 정보를 요청할 것인가
언제 멈추고 사람 승인을 기다릴 것인가
이 차이는 꽤 크다. 예를 들어 "친절하고 정확하게 답하라"는 답변형 지시다. 하지만 "최신 정보가 필요하면 검색 도구를 먼저 사용하고, 계정 변경이나 발송 작업은 사용자 승인 없이는 실행하지 말라"는 실행형 지시다. 후자가 시스템을 만든다.
그래서 고급 프롬프트는 문장 미세 조정보다 흐름 제어에 가깝다. 어떤 조건에서 어떤 도구를 쓰는지, 실패하면 어떻게 되돌아가는지, 결과가 비어 있으면 무엇을 말하는지까지 정의해야 한다.
작은 예시: "출장 준비해 줘"를 실행으로 바꾸기
"다음 주 도쿄 출장 준비해 줘"라는 요청을 받았다고 하자. 답변형 AI는 준비물 목록과 일반 조언을 길게 줄 수 있다. 하지만 실행형 AI는 질문을 이렇게 바꿔 본다.
먼저 이 요청에서 정말 해야 할 일을 분해한다. 항공편 검색이 필요한지, 일정 정리가 필요한지, 호텔 예약은 이미 되었는지, 팀 공유용 일정 메일이 필요한지를 확인해야 한다. 그다음 가능한 도구를 붙인다. 캘린더 조회 도구, 항공편 검색 도구, 메일 초안 도구가 있다면 각각의 책임이 분명해진다.
실행 흐름은 대략 이렇다. 일정과 목적을 확인한다. 필요한 누락 정보를 묻는다. 항공편과 숙박 정보를 조회한다. 출장 일정표 초안을 만든다. 팀 공유 메일 초안을 작성한다. 실제 발송 전 승인을 요청한다.
이 예시의 핵심은, 시스템이 더 똑똑해진 것이 아니라 더 잘게 책임이 나뉘었다는 점이다. 덕분에 어디서 실패했는지 보이고, 어느 단계가 비쌌는지 보이고, 어떤 단계가 자동화되면 위험한지도 보인다.
실무에서 먼저 설계해야 할 것은 도구보다 경계다
도구를 많이 연결하면 에이전트가 강해진다고 생각하기 쉽다. 실제로는 반대인 경우가 많다. 도구 수가 늘수록 선택은 어려워지고, 잘못된 호출 가능성도 커진다. 읽기 전용 도구와 쓰기 도구를 구분하지 않으면 작은 오판이 큰 사고가 된다.
처음에는 가능한 한 적은 수의 도구로 시작하는 편이 좋다. 특히 실무에서는 읽기 전용 조회, 초안 생성, 승인 후 실행의 세 층으로 나누면 안전하다. 검색과 조회는 상대적으로 위험이 낮다. 초안 작성은 사용자가 검토할 수 있다. 실제 발송, 수정, 삭제는 마지막에 분리한다.
이렇게 해야 "답변하는 AI"에서 "실행하는 AI"로 넘어갈 때 가장 큰 함정을 피할 수 있다. 그 함정은 모델이 아니라 설계자가 만든다. 해야 할 일과 해도 되는 일을 구분하지 않은 채 자동화부터 시작하는 것이다.
기억할 문장
좋은 실행형 시스템은 모델에게 더 많은 말을 시키지 않는다. 더 좋은 단위로 행동하게 만든다.
도구 사용의 본질은 화려한 에이전트 프레임워크가 아니다. 최신 정보는 조회로, 정확한 연산은 도구로, 위험한 실행은 승인 흐름으로 보내는 일이다. 그리고 그 모든 것의 시작은 큰 목표를 실행 가능한 작은 단계로 바꾸는 설계다.
다음 단계에서는 이 행동 단위들을 어떻게 연결해 planner와 executor 구조로 만들고, 어디서 멈추고, 얼마나 행동하게 할지를 본격적으로 다루게 된다.
참고
1Function calling with Gemma 4
2Function Calling & Tool Use: The Complete Guide for GPT, Claude, and Gemini (2026)
3Chapter 4: Function Calling and Tool Use
4Task Decomposition for AI Agents: How to Break Down Work That Actually Gets Done
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.