이 과정에서 만들 것 — 8장까지 마친 뒤의 화면 미리 보기
한 줄 요약
"우리 회사 데이터로 이런 질문에 답하는 프로그램" 을 만드는 과정입니다. 연결 방식이 서로 다른 에이전트 네 종류를 하나씩 만들고, 마지막에 하나의 팀으로 묶습니다.
1. 무엇을 만드는가 — 이런 질문에 답합니다
말로 설명하기 전에, 여러분이 만들 프로그램에 실제로 던지게 될 질문 다섯 개를 보겠습니다.
무대는 가상의 온라인 쇼핑몰 승승장구몰입니다. 상품 40개를 팔고, 주문이 2,400건 쌓여 있고, 리뷰가 650건 달려 있고, 사내 규정 문서가 PDF로 있습니다. 여느 회사와 같습니다.
여기서 일하는 사람들이 매일 부딪히는 상황을 다섯 개 골랐습니다. 답이 안 나오면 일이 안 되는 질문들입니다.
아래 답은 전부 실제로 돌려서 받은 것입니다.
Q1 · 발주 담당자 — 월요일 아침
상황 — 이번 주 발주서를 넣어야 합니다. 상품이 40개인데, 엑셀을 열어 재고와 재주문 기준을 하나씩 눈으로 비교하고 있습니다. 매주 반복하는 일이고, 바쁘면 빠뜨립니다.
"지금 발주해야 할 상품이 있나요?"
상품 40개를 일일이 안 봐도 됩니다. 재고와 기준을 비교해 걸러내는 일을 시킨 것이죠.
Q2 · 상품기획(MD) — 분기 리뷰 회의를 앞두고
상황 — "평점 낮은 상품 정리해서 가져오세요"라는 요청을 받았습니다. 평점 평균은 엑셀로 금방 뽑는데, "왜 낮은지" 는 리뷰 650건을 직접 읽어야 알 수 있습니다. 회의는 내일입니다.
"평점이 낮은 상품이 있나요? 고객들이 뭐라고 하는지도 알려주세요."
"평점이 낮다"에서 멈추지 않습니다. 리뷰 650건을 직접 읽어 왜 낮은지까지 정리합니다. 에어프라이어는 용량 표기 문제, 소설 세트는 배송 포장 문제 — 대응이 완전히 다르죠.
Q3 · CS 상담원 — 항의 전화를 받는 중
상황 — 고객이 화가 나 있습니다. 환불해 줘야 할지, 정상이라고 설명해야 할지 지금 정해야 합니다. 제품 매뉴얼을 뒤지는 동안 고객은 기다리고 있고, 다른 고객도 같은 항의를 했던 것 같은데 확실하지 않습니다.
"고객이 '배터리가 일주일 간다더니 하루도 안 간다'고 항의합니다. 우리 잘못인가요?"
CS 담당자가 매일 마주치는 질문입니다. "우리 잘못인가"에 답하려면 고객이 겪은 일(리뷰) 과 제품의 공식 사양(매뉴얼) 을 나란히 놓아야 합니다. 한쪽만 봐서는 판단이 안 섭니다.
Q4 · 신입 상담원 — 반품 접수를 받으며
상황 — 들어온 지 일주일 됐습니다. 규정 문서는 받았는데 어디에 뭐가 있는지 모릅니다. 틀리게 안내하면 사고라서 매번 선배에게 물어보는데, 선배도 바쁩니다.
"불량 반품은 며칠까지 받아줘야 하나요? 배송비는 누가 냅니까?"
답에 출처가 붙습니다. 어느 문서 몇 쪽인지 밝히므로, 의심스러우면 열어서 확인할 수 있습니다. 그리고 문서에 없는 것은 "찾을 수 없습니다" 라고 합니다 — 지어내지 않습니다.
Q5 · 팀장 — 주간 회의에서
상황 — "스마트워치 요즘 왜 이래요?"라는 질문이 나왔습니다. 재고가 적다는 것도 알고, 평점이 떨어진 것도 아는데, 그래서 무엇부터 해야 하는지가 안 잡힙니다. 재고 담당·CS·MD에게 각각 물어보고 취합하려면 하루가 갑니다.
"승승 스마트워치 Fit 5, 지금 어떻게 대응해야 할까요?"
막연한 질문입니다. 그런데 실제로 던지는 건 이런 질문이죠.
여기가 이 과정의 결승선입니다. 위 Q1~Q4가 전부 필요한 질문이거든요 — 재고와 리뷰는 사내 CSV에, 제품 사양과 환불 규정은 사내 문서에, 시장 반응은 인터넷에 있습니다. 세 곳을 따로 뒤진 뒤 하나로 합쳐야 나오는 답입니다.
여기까지가 이 과정의 산출물입니다. 나머지는 "이걸 어떻게 만드는가"입니다.
Q1·Q2는 표 데이터를 계산해서, Q4는 사내 문서를 검색해서, Q3·Q5는 여러 곳을 뒤져 합쳐서 나온 답입니다. 이 연결 방식의 차이가 이 과정의 뼈대입니다.
2. 에이전트 네 종류는 무엇이 다른가
이 과정에서 만들 네 종류는 전부 같은 LLM(Gemini) 을 씁니다. 다른 것은 딱 하나, 바깥세상과 연결되는 방식입니다.
| 에이전트 | 무엇에 연결되나 | 핵심 기술 | 대표 질문 | 장 |
|---|---|---|---|---|
| ① 사내 데이터 조회 | 우리 CSV의 정해진 값 | 함수 도구(Function Calling) | "주문 O001203 어디까지 왔어요?" | 3장 |
| ② 웹검색 | 인터넷 (실시간·외부) | 외부 API 도구 | "요즘 스마트워치 시장 어때요?" | 4장 |
| ③ CSV 데이터분석 | 표 데이터 (자유로운 집계) | 코드 생성·실행 | "카테고리별 매출 상위 3개는?" | 5장 |
| ④ RAG(문서검색) | 사내 문서 PDF (긴 글) | 임베딩·벡터검색 | "불량 상품 반품 기간이 며칠이죠?" | 6장 |
표에 나온 낯선 말 세 개를 여기서 풀어 둡니다. 지금 외울 필요는 없고, "아, 그런 뜻이구나" 정도면 됩니다.
- RAG(Retrieval-Augmented Generation, 검색증강생성) — 답하기 전에 먼저 사내 문서에서 관련 대목을 찾아 오고, 찾아온 그 대목만 근거로 답하게 하는 방식입니다. 6장에서 만듭니다. 앞으로 표기는 RAG(문서검색) 하나로 씁니다.
- 임베딩 · 벡터 검색 — 문장을 숫자 목록으로 바꿔 두고(임베딩), 뜻이 가까운 것끼리 찾는(벡터 검색) 방식입니다. RAG가 "관련 대목을 찾아 오는" 데 쓰는 기술입니다. 역시 6장입니다.
- 함수 도구(Function Calling) — 우리가 만든 평범한 파이썬 함수를 모델에게 쥐여 주고, 모델이 "이 함수를 이렇게 불러 달라"고 요청하게 하는 방식입니다. 3장에서 만듭니다. 3장에서는 이것을 Function Calling 이라는 이름으로 부릅니다 — 같은 것입니다.
①과 ③이 어떻게 다른가 — ①은 "주문번호를 넣으면 그 주문 정보를 돌려주는" 정해진 조회입니다. 질문이 바뀌어도 하는 일은 같습니다. ③은 "카테고리별로 묶어서 합계를 내라" 처럼 매번 다른 계산을 합니다. 그래서 ③은 계산식 자체를 LLM이 만들어 냅니다.
③과 ④가 어떻게 다른가 — 이게 가장 헷갈리는 지점입니다. 표에 든 숫자는 코드로 계산하고, 문서에 쓰인 문장은 검색해서 근거로 씁니다. "평균 평점"은 계산이고 "반품 기간"은 문장입니다. 6장에서 이 구분을 다시 짚습니다.
3. 8장 전체 흐름
| 장 | 무엇을 하나 | 끝나면 |
|---|---|---|
| 1 | 실습 환경 준비 · 첫 LLM 호출 | 내 PC에서 python code/ch01_hello.py 가 돌아간다 |
| 2 | LLM API 기초 — 시스템 지시·멀티턴 | 말투를 고정한 상담 봇과 대화를 이어 갈 수 있다 |
| 3 | 에이전트 ① 사내 데이터 조회 | 1장에서 답하지 못했던 주문 질문에 답한다 |
| 4 | 에이전트 ② 웹검색 | LLM이 모르는 최신 정보를 스스로 찾아 답한다 |
| 5 | 에이전트 ③ CSV 데이터분석 | 한국어 질문으로 매출을 집계한다 |
| 6 | 에이전트 ④ RAG 문서검색 | 사내 PDF를 근거로 답하고 출처를 밝힌다 |
| 7 | 기억하는 에이전트 | "아까 그 상품" 이 통한다 |
| 8 | 멀티에이전트 아키텍처 | 질문 하나에 여러 에이전트가 붙어 하나의 판단을 낸다 |
만드는 파일은 딱 8개입니다. code/ch01_hello.py 부터 code/ch08_multi_agent.py 까지, 장마다 한 개씩 늘어납니다. 앞 장에서 만든 파일은 뒤에서 그대로 가져다 씁니다 — 8장은 3~7장 결과물을 재료로 씁니다.
8장에서 넷이 어떤 모양으로 합쳐지나
앞의 Q5("스마트워치, 지금 어떻게 대응해야 할까요?")가 8장의 모습입니다. 회사 조직처럼 생겼습니다.
질문이 들어오면 팀장이 "이건 재고 담당, 이건 문서 담당" 하고 할 일을 쪼개 나눠 줍니다. 담당자들이 각자 자기 도구로 조사해서 결과를 올리고, 팀장이 그것들을 하나로 묶어 최종 답을 냅니다.
담당자 넷이 각자 조사한 것을 팀장이 하나로 묶습니다 — 그렇게 만든 것이 Q5의 답입니다. 2절 표의 네 종류가 그대로 담당자 네 명이 됩니다 — ①사내 데이터 조회 → 주문담당 · ②웹검색 → 시장조사원 · ③CSV 데이터분석 → 데이터분석가 · ④RAG(문서검색) → 규정담당. 8장 코드에서도 이 네 이름을 그대로 씁니다.
용어를 여기서 하나로 고정합니다.
이 교재의 말 라이브러리·문서에서 부르는 이름 팀장 플래너(planner) 담당자 워커(worker) 앞으로 이 교재는 팀장 · 담당자로 쓰고, 괄호로 원어를 한 번씩 달아 둡니다. 검색할 때는 planner · worker 로 찾으면 됩니다.
4. 무대는 승승장구몰
1절에서 본 승승장구몰의 데이터는 전부 data/ 폴더에 들어 있습니다 — 주문 2,400건, 고객 200명, 상품 40개, 리뷰 650건, 사내 문서 PDF 5종.
특히 상품 하나를 기억해 두세요.
P0003 · 승승 스마트워치 Fit 5 — 이 과정의 주인공입니다.
3장에서는 "주문 O001203이 이 상품이구나" 로, 5장에서는 "재고가 3개밖에 없네" 로, 6장에서는 "배터리 사양이 이렇구나" 로 만나고, 8장에서 전부 합쳐집니다. 같은 상품을 매 장 다른 각도로 보게 되어, 마지막에 세 관점이 합쳐질 때 "아, 그래서 그랬구나" 하고 이해하게 됩니다.
5. 무엇을 알고 있어야 하나
파이썬 문법을 조금만 알면 충분합니다. 구체적으로는 이 정도입니다.
- 함수를 정의하고 부를 줄 안다 (
def f(x): ...) - 리스트와 딕셔너리를 안다 (
[1,2,3],{"a": 1}) for문과if문을 읽을 줄 안다
몰라도 되는 것 — 머신러닝, 딥러닝, 수학, 클래스 설계, 비동기 프로그래밍. 하나도 안 나옵니다.
pandas도 몰라도 됩니다
이 과정의 코드에는 pandas(표 데이터를 다루는 라이브러리)가 자주 나옵니다. 처음 보는 문법일 수 있습니다.
괜찮습니다. 읽고 넘어가세요.
# 3장 도구 함수의 일부 — 지금 이해 못 해도 괜찮습니다
hit = orders[orders["order_id"] == oid]
r = hit.iloc[0]
이 줄들은 AI에게 짜 달라고 해서 받은 것입니다. 여러분도 그렇게 하면 됩니다. "orders 라는 표에서 order_id 가 이것과 같은 행을 찾아 줘" 라고 부탁하면 AI가 위 코드를 써 줍니다.
이 과정이 가르치는 것은 pandas가 아닙니다.
"AI가 짜 준 코드를 함수로 묶어, 그 함수를 에이전트에게 도구로 쥐여 주는 법" 입니다.도구 안이 pandas든, SQL이든, 사내 API 호출이든 — 에이전트 구조는 한 글자도 안 바뀝니다. 그래서 이 과정을 마치면 여러분 회사의 데이터에도 그대로 적용할 수 있습니다.
그럼 사람은 무엇을 하나요? 이 과정에서 반복해 나오는 답입니다.
| AI가 하는 일 | 사람이 하는 일 |
|---|---|
| 도구 함수 안의 코드를 짜 준다 | 무엇을 도구로 만들지 정한다 |
| 질문에 맞는 도구를 고른다 | 도구 설명(독스트링)을 쓴다 |
| 결과를 문장으로 정리한다 | 나온 답이 맞는지 검증한다 |
오른쪽은 AI가 대신 못 합니다. 우리 회사 데이터가 어떻게 생겼는지, 어떤 규칙이 있는지 아는 사람만 쓸 수 있으니까요.
핵심 정리
- 1절의 질문 다섯 개가 이 과정의 산출물입니다. 장마다 답할 수 있는 질문이 늘어납니다.
- 이 과정은 연결 방식이 다른 에이전트 네 종류를 하나씩 만들고, 마지막에 하나의 팀으로 묶습니다.
- 네 종류의 차이는 LLM이 아니라 무엇에 연결되는가 입니다 — 사내 CSV / 인터넷 / 표 계산 / 사내 문서.
- 결승선은 질문 하나에 여러 에이전트가 붙어 하나의 판단을 내는 것입니다. 네 종류가 전부 8장 팀에 들어갑니다.
- 한 곳만 봐서는 답이 안 나오는 질문 — 그것이 멀티에이전트가 필요한 이유입니다.
- 다음 절에서는 LLM 혼자서는 답하지 못하는 질문 세 개를 직접 눈으로 확인합니다.