챗봇에서 작업자로 넘어가기
Qwen을 단순 챗봇으로 쓰면 답변은 잘하지만 실제 업무 시스템을 움직이지는 못한다. 오늘 날씨를 묻는 질문에는 답할 수 있어도, 실제 기상 API를 호출하거나 사내 데이터베이스에서 매출을 조회하거나 캘린더에 일정을 등록하려면 외부 도구가 필요하다.
이때 사용하는 구조가 함수 호출이다. 핵심은 Qwen이 직접 네트워크에 접속하거나 데이터베이스를 실행하는 것이 아니라는 점이다. Qwen은 대화 맥락과 도구 정의를 보고 "어떤 함수를 어떤 인자로 호출해야 하는지"를 구조화해 제안한다. 실제 실행은 애플리케이션 서버가 맡는다. 실행 결과를 다시 Qwen에 전달하면, Qwen은 그 결과를 바탕으로 사용자에게 자연어 답변을 만든다.
AI 생성 이미지
기본 흐름 이해하기
Alibaba Cloud Model Studio의 function calling 흐름은 단순하다. 먼저 개발자가 도구 스키마를 정의한다. 예를 들어 날씨 조회 도구라면 get_current_weather라는 이름, "지정한 도시의 날씨를 조회한다"는 설명, 그리고 location 같은 입력값을 JSON Schema로 적는다. 그다음 사용자 메시지와 tools 정보를 함께 Qwen에 보낸다.
모델이 도구가 필요 없다고 판단하면 바로 답변한다. 도구가 필요하면 tool_calls에 함수 이름과 인자를 담아 반환한다. 애플리케이션은 이 인자를 파싱하고 검증한 뒤 실제 함수를 실행한다. 이후 실행 결과를 role: "tool" 메시지로 대화에 추가하고, 같은 대화 기록으로 Qwen을 다시 호출한다. 두 번째 호출에서 Qwen은 도구 결과를 사용해 최종 답변을 만든다.1
간단히 정리하면 다음과 같다.
사용자 질문 → Qwen이 도구 호출 결정 → 서버가 함수 실행
→ 실행 결과를 Qwen에 전달 → 최종 답변 생성도구 스키마는 명확해야 한다
도구 스키마는 모델에게 주는 사용 설명서다. 이름은 실제 서버 코드의 함수와 맞아야 하고, 설명은 언제 이 도구를 써야 하는지 알려줘야 한다. 파라미터는 가능한 좁게 정의하는 편이 좋다.
예를 들어 일정 등록 도구라면 title, date, start_time, end_time, attendees를 받을 수 있다. 여기서 날짜 형식은 YYYY-MM-DD, 시간대는 Asia/Seoul, 참석자는 회사 이메일만 허용한다고 명시해야 한다. "적당히 일정을 잡아줘" 같은 모호한 요청이 들어오더라도 서버는 비어 있는 값, 잘못된 날짜, 권한 없는 참석자를 거절해야 한다.
Qwen function calling을 지원하는 모델 범위도 확인해야 한다. Model Studio 문서 기준으로 Qwen-Max, Qwen-Plus, Qwen-Flash, Qwen-Turbo, Qwen3.5, Qwen3, Qwen2.5 계열이 포함되며, 일부 Qwen-VL과 Qwen-Omni 모델도 지원한다. 실습에서는 예제에 자주 쓰이는 qwen-plus를 기준으로 시작하면 무난하다.1
서버가 권한을 통제해야 한다
함수 호출에서 가장 중요한 원칙은 "모델은 제안하고, 서버가 결정한다"이다. Qwen이 delete_user, send_payment, update_contract 같은 위험한 도구 호출을 제안할 수 있다고 해서 그대로 실행하면 안 된다.
서버는 허용된 도구 목록만 노출해야 한다. 읽기 도구와 쓰기 도구를 분리하고, 쓰기 작업에는 사용자 확인 단계를 넣어야 한다. 예를 들어 "다음 주 회의를 잡아줘"라는 요청은 Qwen이 일정 후보를 만들고 캘린더 등록 인자를 생성할 수 있다. 그러나 실제 등록 전에는 사용자에게 "이 일정으로 등록할까요?"라고 확인해야 한다.
데이터베이스 검색도 마찬가지다. Qwen이 SQL을 직접 실행하게 두기보다, search_customer_orders(customer_id, start_date, end_date)처럼 제한된 도구를 제공하는 편이 안전하다. 사용자 권한, 조회 가능한 고객 범위, 날짜 제한은 서버 코드에서 검사한다.
에이전트는 함수 호출의 반복 구조다
단일 함수 호출은 한 번의 작업에 적합하다. 그러나 실제 업무는 여러 단계를 거친다. "지난달 매출을 요약하고 이상 거래를 찾아 슬랙에 보고해줘"라는 요청은 데이터 조회, 계산, 이상치 탐지, 보고문 작성, 전송이라는 단계로 나뉜다.
이런 구조를 에이전트라고 부른다. 에이전트는 목표를 이해하고, 필요한 도구를 고르고, 실행 결과를 관찰한 뒤 다음 행동을 결정한다. Qwen-Agent는 Qwen의 지시 따르기, 도구 사용, 계획, 메모리 능력을 바탕으로 이런 다단계 애플리케이션을 만들기 위한 프레임워크다. LLM, Tool, Agent가 핵심 구성요소이며, 사용자 정의 도구를 등록하고 Assistant나 FnCallAgent 같은 구조로 실행할 수 있다.2
Qwen-Agent를 쓰면 RAG 검색, 코드 실행, 파일 읽기, 브라우저 자동화, MCP 연동처럼 여러 도구를 묶어 더 복잡한 작업을 설계할 수 있다. 다만 복잡도가 올라갈수록 통제 장치도 함께 필요하다.
안전한 에이전트 설계 원칙
에이전트는 편리하지만 실패 방식도 다양하다. 잘못된 도구를 고를 수 있고, 필수 인자를 빠뜨릴 수 있으며, 같은 도구를 반복 호출해 비용을 늘릴 수도 있다. 권한이 큰 도구를 잘못 실행하면 실제 업무 피해로 이어진다.
따라서 운영 환경에서는 다음 원칙을 기본으로 삼는다.
도구 허용 목록을 정하고 요청별로 사용할 수 있는 도구를 제한한다.
모든 파라미터를 서버에서 검증한다.
최대 실행 횟수와 전체 실행 시간을 제한한다.
결제, 삭제, 발송, 등록 같은 변경 작업은 사용자 확인을 거친다.
도구 호출 입력, 결과, 최종 답변을 로그로 남긴다.
실패 시 재시도 횟수와 대체 흐름을 미리 정한다.
좋은 에이전트는 모델이 마음대로 행동하는 시스템이 아니다. Qwen의 판단 능력을 활용하되, 실행 권한은 애플리케이션이 통제하는 구조다. 이 경계를 분명히 해야 Qwen은 말만 하는 챗봇을 넘어 안전하게 업무를 수행하는 도구가 된다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.