LLM은 계산기가 아니다 — 숫자는 코드에게 맡긴다
한 줄 요약
LLM에게 데이터를 통째로 주고 계산시키면 틀립니다. 대신 "무엇을 계산할지"만 LLM이 정하고, 실제 계산은 pandas가 합니다. 이 역할 분담이 이번 장의 핵심입니다.
1. 왜 LLM에게 계산을 시키면 안 되나
LLM은 "다음에 올 말"을 예측하는 프로그램입니다. 2장에서 확인한 그대로입니다. 계산기가 아닙니다.
90,229,700 + 53,967,950 을 물으면 답은 나옵니다. 훈련 데이터에서 비슷한 계산을 많이 봤기 때문입니다. 그런데 틀릴 수 있고, 틀려도 그럴듯하게 나옵니다.
주문 2,400건을 카테고리별로 묶어 합계를 내는 일이라면 어떨까요?
① 2,400행을 전부 프롬프트에 넣어야 한다 → 토큰이 어마어마하다
② 모델이 머릿속으로 2,400번 더해야 한다 → 거의 확실히 틀린다
③ 틀려도 그럴듯한 숫자가 나온다 → 틀린 줄 모른다
③이 가장 위험합니다.
"돌아가는데 왜 알아야 하나" — ChatGPT에 CSV를 붙여 넣고 "합계를 내 줘"라고 하면 답은 나옵니다. 문제는 그 숫자가 맞는지 확인할 방법이 없다는 것입니다. 이 절은 그 확인 문제를 구조로 해결하는 이야기입니다.
2. 역할을 나눕니다
| 누가 | 무엇을 | 잘하는 일인가 |
|---|---|---|
| LLM | "카테고리별 매출 상위 3개"를 pandas 식으로 번역 | ✓ 언어 → 코드 변환은 잘한다 |
| pandas | 2,400행을 실제로 집계 | ✓ 계산은 정확하다 |
| LLM | 나온 숫자를 사람이 읽을 문장으로 | ✓ 언어 표현은 잘한다 |
각자 잘하는 것을 시킵니다. 그리고 숫자 자체는 절대 LLM이 만들지 않습니다.
3. 실제로 만들어지는 식
모델이 만든 것을 그대로 옮긴 것입니다.
질문: "카테고리별 매출 상위 3개를 알려주세요."
모델이 만든 식:
orders[~orders['status'].isin(['취소','환불'])].groupby('category')['amount'].sum().nlargest(3)
pandas 실행 결과:
category
가전 90229700
전자기기 53967950
스포츠레저 53259600
모델의 최종 답변:
"가전제품 90,229,700원, 전자기기 53,967,950원, 스포츠/레저 53,259,600원으로 집계되었습니다."
세 단계를 하나씩 보세요.
- 식에
~orders['status'].isin(['취소','환불'])이 들어 있습니다 → 독스트링의 규칙을 지켰습니다 - 숫자
90229700은 pandas가 계산한 것입니다. 모델이 만든 게 아닙니다 - 최종 답변에서 천단위 쉼표를 붙였습니다 → 시스템 지시를 지켰습니다
4. 시스템 지시로 못 박기
아래는 6절에서 만들 code/ch05_csv_agent.py 의 일부를 미리 보는 것입니다 — 지금 붙여 넣지 않아도 됩니다.
SYSTEM = (
"너는 승승장구몰의 데이터 분석가다. "
"숫자는 반드시 run_pandas 도구로 계산하고, 머릿속으로 계산하지 않는다. "
"매출 집계에서는 취소·환불 건을 제외한다. "
"결과는 한국어로, 숫자에는 천단위 쉼표를 붙여 간결하게 설명한다."
)
"머릿속으로 계산하지 않는다" — 2장 2절에서 미리 보여 준 그 문장입니다. 왜 필요한지 이제 알겠죠.
이 문장이 없으면 모델이 간단한 계산은 직접 해 버릴 수 있습니다.
Q: 재고가 3개인데 재주문 기준이 30개면 몇 개를 발주해야 하나요?
A: 27개를 발주하셔야 합니다. ← 도구를 안 쓰고 직접 뺐다
이 정도는 맞습니다. 그런데 어디까지 직접 하고 어디부터 도구를 쓸지의 경계가 흐려지면 언제 틀릴지 알 수 없습니다. 일관되게 도구를 쓰게 만드는 편이 안전합니다.
5. 이 원칙이 적용되는 범위
계산만이 아닙니다. "정확해야 하는 것"은 전부 코드나 문서에 맡깁니다.
| 종류 | LLM에게 맡기면 | 어떻게 해야 하나 | 장 |
|---|---|---|---|
| 숫자 계산 | 틀린다 | pandas로 계산 | 5장 |
| 사내 규정 | 지어낸다 | 문서에서 찾아 근거로 | 6장 |
| 주문 상태 | 모르거나 지어낸다 | CSV 조회 | 3장 |
| 최신 정보 | 옛날 것을 말한다 | 웹검색 | 4장 |
LLM에게 맡기는 것은 "판단"과 "표현" 입니다.
LLM이 잘하는 것 : 질문 이해 · 도구 선택 · 코드 생성 · 결과를 문장으로
LLM에게 맡기면 안 되는 것 : 사실 · 숫자 · 규정
이 표의 구분을 8장까지 기억해 두세요. 멀티에이전트를 설계할 때, "이 정보는 어디서 오는가" 를 담당자별로 나누는 것이 그대로 이 원칙의 적용입니다.
6. 그런데 코드 생성도 틀릴 수 있습니다
솔직히 말하면, 이 방식에도 빈틈이 있습니다.
모델이 만든 식이 틀리면?
→ 열 이름을 잘못 쓰면 오류가 난다 (다행히 티가 난다)
→ 조건을 잘못 걸면 오류 없이 틀린 답이 나온다 (티가 안 난다)
예를 들어 취소 만 제외하고 환불 을 빼먹으면, 오류 없이 매출이 조금 많게 나옵니다.
그래서 두 가지를 합니다.
- 독스트링과 시스템 지시에 규칙을 명시한다 (앞 절에서 한 것)
- 결과를 검증한다 — 나온 숫자가 말이 되는지 사람이 본다
두 번째는 자동화하기 어렵습니다. 그래서 사람의 일로 남습니다.
실습에서 확인하는 법 — 8절에서 나온 답을 직접 pandas로 계산해 대조해 보는 연습을 합니다. 에이전트가 낸 숫자를 믿지 않고 확인하는 습관이 이 장에서 익힐 가장 실용적인 내용입니다.
예측해 보기
다음 절로 넘어가기 전에 적어 보세요.
run_pandas도구는 모델이 만든 파이썬 식을 그대로 실행합니다. 여기서 무엇이 위험할까요? 모델이 이런 식을 만들면 어떻게 될까요?
python "__import__('os').system('rm -rf /')"
- 위험 요소: ______
- 어떻게 막을 수 있을까: ______
7절이 이 문제를 다룹니다.
핵심 정리
- LLM은 계산기가 아닙니다. 데이터를 통째로 주고 집계시키면 틀립니다. 틀려도 그럴듯하게 나옵니다.
- 역할을 나눕니다 — LLM은 계산식을 만들고, pandas가 계산하고, LLM이 문장으로 설명합니다.
- 숫자 자체는 절대 LLM이 만들지 않습니다.
- 시스템 지시에 "머릿속으로 계산하지 않는다" 를 못 박습니다.
- 이 원칙은 계산만이 아니라 정확해야 하는 것 전부에 적용됩니다 — 숫자는 코드로, 규정은 문서로.
- LLM에게 맡기는 것은 판단과 표현입니다. 사실·숫자·규정은 맡기지 않습니다.
- 코드 생성도 틀릴 수 있습니다. 결과를 검증하는 것은 사람의 일로 남습니다.