LLM 도구 사용 원리 총정리 - 함수 호출, MCP, 코드 샌드박스까지 CMU 강의 해설

핵심 메시지

• 언어모델이 쓰는 도구는 크게 정보를 모으는 '지각', 환경을 바꾸는 '행동', 모델이 직접 하기 어려운 '계산' 세 갈래로 나뉜다.
• 지금의 표준은 JSON 스키마로 함수의 이름·설명·인자를 적어 주면 모델이 그 형식에 맞는 호출문을 생성하고, 실제 실행은 애플리케이션이 책임지는 방식이다.
• MCP는 원래 에이전트에게 API 키를 그대로 넘기지 않으려고 만든 중간 계층이었지만, 지금은 도구 연결의 사실상 업계 표준이 됐다.
• 모델이 만든 코드를 그대로 실행하는 순간 보안 문제가 생기므로, 위험한 모듈을 걸러내는 래퍼부터 컨테이너 격리까지 샌드박스가 필수다.
• 도구가 고장 났을 때 모델이 그 사실을 알아채는 능력은 여전히 약하고, 알아챈다고 해서 과제를 성공시키는 것도 아니다.

쉽게 이해하기

카네기멜런대 그레이엄 뉴빅 교수의 대학원 강의는 '도구'를 언어모델 바깥에 있으면서 입력과 출력이 정해진 함수형 인터페이스로 정의한다. 그리고 도구를 세 갈래로 나눈다. 모델 파라미터 안에 없는 정보를 가져오는 지각, 환경에 실제 변화를 일으키는 행동, 그리고 모델이 직접 하기엔 오류가 잦은 계산이다. 웹 검색과 데이터베이스 조회, 계산기와 파이썬 인터프리터, 날씨나 일정 조회, 이미지 질의응답이나 영상 자막 변환 같은 것들이 모두 여기에 들어간다.

호출 방식 자체는 단순하다. 모델이 답을 내놓기 전에 도구 호출 시작을 알리는 태그를 만들고, 호출문을 쓰고, 시스템이 그 호출을 실행해 결과를 되돌려 준다. 강의는 이 흐름이 결코 새롭지 않다고 짚는다. 시리나 알렉사 같은 예전 비서들도 같은 일을 했지만, 그때는 어떤 API를 부를지 분류기가 고르고 인자는 별도 모델이 채우는 구조였다. 지금은 모델이 호출 코드를 직접 생성한다는 점이 다르다.

현대적 사례의 출발점으로는 웹GPT가 꼽힌다. 검색·클릭·스크롤·인용이 가능한 텍스트 기반 브라우징 인터페이스를 주고, 사람이 실제로 정보를 찾는 과정을 기록해 따라 하게 한 뒤 사람 선호 데이터로 보상 모델을 학습시켰다. 여기서 흥미로운 지점은 검색 자체가 도구 호출이 됐다는 것이다. 질의를 받아 문서를 찾아 붙이고 답을 생성하는 전형적인 RAG와 달리, 모델이 언제 검색할지를 스스로 정한다. 툴포머는 한 걸음 더 나아가 사람 주석 없이 학습했다. 문장 곳곳에 API 호출 후보를 뿌려 보고, 그 호출 결과를 붙였을 때 정답의 확률이 올라간 경우만 남겨 학습 데이터로 삼는 방식이다.

2024년 이후의 실무 표준은 JSON 스키마 기반 함수 호출이다. 함수 이름과 설명, 인자의 타입과 필수 여부를 적어 주면 모델이 그 규격에 맞는 호출을 생성한다. 뉴빅 교수는 읽기 편한 파이썬 문법을 더 선호한다고 농담하면서도, 모든 모델이 이 형식으로 방대하게 학습돼 있어 실질적으로 잘 동작한다고 말한다. 다만 코드처럼 따옴표가 많은 값을 JSON에 넣으면 이스케이프가 폭발하는데, 초기 코딩 에이전트가 자주 깨진 이유가 바로 이것이었다. 한 번에 여러 도구를 동시에 부르는 병렬 호출도 이제 기본에 가깝다.

MCP에 대한 설명은 흔한 오해를 정리해 준다. 도구 목록을 알려 주는 엔드포인트와 실제 호출을 처리하는 엔드포인트를 가진 서버일 뿐이며, 그런 기능은 기존 API 서버로도 가능하다. 그럼에도 이 규격이 퍼진 결정적 이유는 인증이었다. API 키를 에이전트에게 직접 노출하지 않고 서버 뒤에 숨기려는 설계였는데, '에이전트용 API'에 대한 수요가 워낙 커서 그대로 표준이 됐다는 것이다. 강의 시점에 이미 서버가 1만 7천 개를 넘었고 중앙 레지스트리도 생겼다. 에이전트끼리 대화하는 A2A와는 목적이 다르다는 구분도 함께 짚는다.

강의 후반부는 실행과 안전, 그리고 도구를 만드는 문제로 넘어간다. 개별 함수 호출 대신 파이썬 코드를 짜서 실행하게 하면 조건 분기와 조합이 가능해지는데, 대신 모델이 실수로 파일을 지우거나 오염된 라이브러리를 설치할 위험이 생긴다. 그래서 위험한 모듈 임포트를 막는 로컬 래퍼, 도커 같은 컨테이너 격리, 웹어셈블리 실행 같은 선택지를 비교한다. 마지막으로는 모델이 원시 함수들을 조합해 새 도구를 만들고, 자주 쓰이지 않는 도구는 도구함에서 솎아 내는 접근을 소개한다.

주요 인사이트

• 검색을 '도구 호출'로 다루면 파이프라인이 뒤집힌다. 질의가 들어오면 무조건 검색부터 하는 고정형 RAG와 달리, 모델이 검색이 필요한 순간을 스스로 판단하고 필요하면 여러 번 나눠 찾는다.
• 툴포머의 필터 기준은 '정답이 맞았는가'가 아니라 '그 도구 결과를 붙였더니 정답의 확률이 올라갔는가'다. 강의 중 학생이 지적했듯 확률이 올라갔다고 답이 맞다는 보장은 없지만, 사람 주석 없이 도구 사용을 가르칠 수 있게 해 준 지점이 핵심이다.
• 도구 사용 강화학습에서 보상은 두 겹으로 설계된다. 형식 보상은 JSON 스키마 검증으로 간단히 확인되지만, 정답 보상은 도구 이름과 인자 이름·값의 겹침을 각각 재서 부분 점수를 준다. 호출을 너무 많이 만들면 감점되고, 완전 정답을 받으려면 모든 항목이 맞아야 한다.
• 고장 난 도구에 대한 벤치마크 결과가 특히 뼈아프다. 일부러 API를 망가뜨렸을 때 '이 도구가 안 된다'고 인지한 모델이 놀랄 만큼 적었고, 인지한 경우에도 다른 도구로 우회해 과제를 끝내는 데까지 이어지지는 않았다.
• 도구는 많을수록 좋은 게 아니다. 비슷한 도구를 잔뜩 붙이면 컨텍스트만 잡아먹고 모델을 헷갈리게 한다. 여러 도구 중 최적을 고르는 능력은 아직 뛰어나지 않아서, 어떤 상황에 무엇을 쓸지 명시적으로 지시하거나 학습시켜야 한다는 것이 강연자의 진단이다.

자주 묻는 질문

관련 AI 소식