Tool Use 패턴 — LLM에 손과 발을 달아주기

LLM은 "오늘 날씨가 어때?"에 진짜 날씨 API를 호출할 수 없다. 학습 데이터에서 추론할 뿐. 도구를 연결하면 달라진다.

동작 원리

1. LLM에 도구 스키마 전달: "넌 get_weather(city: string) 함수를 쓸 수 있어"
2. 사용자: "서울 날씨 알려줘"
3. LLM 응답: tool_use: get_weather(city="Seoul")
4. 클라이언트가 실제 API 호출 → 결과를 LLM에 전달
5. LLM이 결과를 자연어로 정리: "서울은 현재 18°C, 맑음입니다."

LLM이 직접 API를 호출하는 게 아니다. "이 도구를 이 파라미터로 호출해줘"라고 요청하면, 클라이언트(개발자 코드)가 실행하고 결과를 돌려주는 구조.

좋은 도구 설계

이름이 명확해야: read_file, search_code, run_test — 이름만 봐도 뭘 하는지 알 수 있어야.

설명이 자세해야: LLM은 도구 설명을 보고 언제 쓸지 결정한다. "파일을 읽습니다"보다 "지정된 경로의 파일 내용을 텍스트로 반환합니다. 바이너리 파일은 지원하지 않습니다"가 낫다.

파라미터가 간결해야: 필수 파라미터를 최소화하고, 옵셔널은 적절한 기본값을 설정.

결과가 유용해야: 성공/실패 여부, 에러 메시지, 실행 결과를 구조적으로 반환.

MCP (Model Context Protocol)

Anthropic이 만든 도구 표준화 프로토콜. 도구를 만드는 사람과 쓰는 사람(LLM/에이전트)을 분리한다.

MCP 서버가 도구를 제공하고, MCP 클라이언트(에이전트)가 연결해서 사용하는 구조. 도구를 한 번 만들면 여러 에이전트에서 재사용할 수 있다.