# 도구 사용

> **이 장에서 배우는 것**
> 도구 사용이 정확히 어떤 구조인지, 그리고 이것이 왜 앞 장들의 한계를 대부분
> 해결하는지.

## 한계를 다시 정리하면

[언어 모델](/guide/ai-language-model)이 못 하는 것으로 넷을 꼽았습니다.

```
정확한 계산 · 최신 사실 · 내 회사 정보 · 되풀이되는 정확성
```

넷 다 같은 뿌리입니다. **모델은 자기가 본 것만 압니다.** 바깥에 닿을 방법이
없습니다.

**도구 사용은 그 통로를 만드는 것**입니다.

## 구조

모델에게 **호출할 수 있는 함수 목록**을 함께 알려줍니다.

```
사용할 수 있는 도구:
  - 재고조회(제품코드)  : 현재 재고 수량을 반환
  - 주문조회(주문번호)  : 주문 상태와 배송 정보를 반환
  - 계산(수식)          : 수식을 계산해 결과를 반환
```

그러면 모델은 **답을 쓰는 대신 도구를 부르겠다고 요청**할 수 있습니다.

```mermaid
graph TD
  A["사람: A-1023 재고 얼마나 남았어?"] --> B["모델"]
  B -->|"재고조회('A-1023')"| C["실제 시스템"]
  C -->|"결과: 47개"| B
  B --> D["답: 현재 47개 남아 있습니다"]
```

### 흐름을 자세히 보면

1. 사람이 묻습니다
2. 모델이 판단합니다 — "이건 내가 모르는 값이다. 재고조회 도구를 써야겠다"
3. 모델이 **도구 호출 요청**을 냅니다: `재고조회("A-1023")`
4. **실제 실행은 시스템이 합니다** (모델이 하는 게 아닙니다)
5. 결과가 모델에게 돌아갑니다
6. 모델이 그 결과를 반영해 답을 만듭니다

> **4번을 기억해두세요.** 모델은 "이걸 불러주세요"라고 요청할 뿐, 직접 실행하지
> 않습니다. 그래서 **실행 전에 사람 승인을 끼워 넣을 수 있습니다.** 가드레일이
> 성립하는 지점이 여기입니다.

## 무엇이 달라지나

| | 도구 없이 | 도구 있음 |
|---|---|---|
| "재고 얼마나 남았어?" | 모름 (또는 지어냄) | 실제 값 |
| "237 × 481은?" | 그럴듯한 숫자 | 정확한 계산 |
| "오늘 환율은?" | 모름 | 검색 결과 |
| "이 주문 언제 도착해?" | 모름 | 주문 시스템 조회 |
| 답의 근거 | 없음 | **어느 도구에서 왔는지 보임** |

마지막 줄이 실무에서 가장 큽니다. **답에 근거가 생기면 검증할 수 있습니다.**
[환각](/guide/ai-hallucination)이 크게 줄어드는 이유도 이것입니다 — 지어낼 필요가
없어집니다.

## 도구는 읽기만 하는 게 아닙니다

여기서 성격이 갈립니다.

| 종류 | 예 | 위험도 |
|---|---|---|
| **읽기** | 재고 조회, 문서 검색, 계산 | 낮음. 틀려도 되돌릴 것 없음 |
| **쓰기** | 메일 발송, 주문 생성, 파일 저장 | **높음. 되돌리기 어려움** |
| **삭제·결제** | 데이터 삭제, 환불 처리 | **매우 높음** |

읽기 도구를 붙이는 것과 쓰기 도구를 붙이는 것은 **완전히 다른 결정**입니다.
읽기는 대체로 안전하게 시작할 수 있고, 쓰기부터는 승인 설계가 함께 가야 합니다.

> **처음에는 읽기 도구부터 붙이세요.** 그것만으로도 환각이 크게 줄고 답의 품질이
> 올라갑니다. 쓰기는 그 다음입니다.

## 어떤 도구가 필요한지 정하는 법

업무 흐름을 적고 **각 단계에서 무엇을 봐야 하는지**를 표시하면 도구 목록이
나옵니다.

```
청구서 처리:
  1. 메일에서 첨부 받기        → 메일 도구 (읽기)
  2. 청구서 내용 읽기          → 문서 읽기 (읽기)
  3. 거래처 정보 확인          → ERP 조회 (읽기)
  4. 계정 코드 판단            → (모델이 판단)
  5. 회계 시스템 입력          → ERP 입력 (쓰기) ← 승인 지점
```

4번만 모델이 하고 나머지는 도구입니다. **AI 과제의 대부분은 "판단 한 조각"이고
나머지는 연결**입니다.

## 자주 하는 오해

### "도구를 붙이면 AI가 알아서 다 하나?"

도구는 **닿을 수 있게** 해줄 뿐입니다. 무엇을 언제 부를지는 여전히 모델의
판단이고, 그 판단이 틀릴 수 있습니다. 엉뚱한 도구를 부르거나, 부를 것을 안 부를
수 있습니다.

도구가 많아질수록 이 문제가 커지는데, 그건 [도구와 MCP](/guide/mcp-why-standard)에서
다룹니다.

### "그럼 도구를 많이 붙일수록 좋은가?"

아닙니다. 반대인 경우가 많습니다. 도구가 200개면 모델이 **맞는 걸 고르기 어려워
집니다.** 사람도 공구가 200개 놓인 작업대에서 더 자주 틀리게 집습니다.

### "쓰기 도구는 위험하니 안 쓰는 게 낫나?"

쓰기 없이는 자동화가 안 됩니다. 다만 **승인 지점을 설계하고** 붙이는 것입니다.
"금액 100만원 초과는 승인", "외부 발송은 승인"처럼 **되돌리기 어려운 것에만**
사람을 끼웁니다.

---

## 확인

**1. 도구 호출에서 실제 실행은 누가 합니까? 왜 중요합니까?**

<details>
<summary>답</summary>

**시스템이 실행합니다.** 모델은 "이걸 불러주세요"라고 요청할 뿐입니다. 그래서
**실행 전에 사람 승인을 끼워 넣을 수 있고**, 이것이 가드레일이 성립하는 지점
입니다.
</details>

**2. 읽기 도구와 쓰기 도구를 나눠서 봐야 하는 이유는?**

<details>
<summary>답</summary>

**되돌릴 수 있는지가 다르기 때문**입니다. 읽기는 틀려도 되돌릴 게 없어 안전하게
시작할 수 있지만, 쓰기(메일 발송, 주문 생성)와 삭제·결제는 되돌리기 어려워 승인
설계가 함께 가야 합니다.
</details>

**3. 도구를 많이 붙일수록 좋지 않은 이유는?**

<details>
<summary>답</summary>

도구가 많아지면 모델이 **맞는 도구를 고르기 어려워집니다.** 비슷한 도구가 여럿
있으면 엉뚱한 걸 부를 확률이 올라갑니다.
</details>

---

도구가 생겼으니 이제 자료를 찾아올 수 있습니다 →
[자료를 찾아 붙이기](/guide/ai-grounding)