LangTailor페이지 목차
이 페이지에서 검색
멀티 에이전트
이 페이지에 묻기
멀티 에이전트 · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
MULTI · AGENT
멀티 에이전트
생성 수정
도구 실행·검색·기억·그래프 흐름·전문 에이전트의 협업을 구성하고 권한·평가·사람의 확인으로 통제합니다.
26개 문서 · 길잡이·부록 · 1 / 26
00 · 이 노트를 읽는 법 + 전체 목차
이 문서는 본문이 아닙니다. 지도 입니다.
처음 읽는다면 2장(정의하는 법) , 4장(전체 구조) , 5장(판별 축 지도) 만 먼저 읽고 1차시로 넘어가세요. 나머지는 필요할 때 돌아와 찾아 읽으면 됩니다.
이 노트는 이 폴더만으로 완결 되도록 썼습니다. 다른 교재나 자료를 찾아보지 않아도 되며, 처음 나오는 개념은 그 자리에서 설명합니다.
이 문서를 다 읽으면
- 이 과정이 무엇을 만들고, 왜 "LLM 한 번 호출"에서 "여러 에이전트의 협업"까지 단계를 밟는지 말할 수 있다.
- 새 용어를 만났을 때 던질 네 개의 질문 을 순서대로 댈 수 있다.
- 과정 전체를 여섯 개의 층 으로 나누고, 3일이 각각 어느 층을 맡는지 말할 수 있다.
- 이 노트 전체를 관통하는 여덟 개의 판별 축 과, 이 과정의 중심 축인 "누가 흐름을 정하는가" 를 설명할 수 있다.
- 과정 전체를 닫는 세 문장 을 말할 수 있다.
- 각 차시 노트에서 "AI에게 맡기는 자리"와 "내가 검수하는 자리" 를 구분해 읽을 수 있다.
1. 이 과정은 무엇인가
1.1 한 문장
LLM 한 번 호출에서 출발해, 도구를 쓰고 · 문서를 찾고 · 기억하고 · 역할을 나눠 협업하는 에이전트 서비스를 직접 만든다.
과정이 끝나면 세 가지가 남습니다.
| 산출물 | 내용 | 주로 만드는 날 |
|---|---|---|
| 도구를 쓰는 단일 에이전트 | 의도 분류 → 도구 선택 → 실행 → 답변, 권한과 개인정보 보호를 갖춘 것 | 1일차 |
| 기억하고 근거를 대는 에이전트 | 스스로 반복하는 루프 + 문서 검색(RAG) + 대화 세션 | 2일차 |
| 여러 에이전트가 협업하는 서비스 | 그래프 워크플로우 + 전문 에이전트 + 관리 에이전트 + 사람의 승인 + API 서버 | 3일차 |
1.2 왜 이 순서인가 ⭐
에이전트는 한 번에 만드는 것이 아니라 층을 쌓는 것 입니다. 아래 층이 부실하면 위층은 그 부실을 반복해서 증폭 합니다. 프롬프트가 모호하면 도구 선택이 틀리고, 도구 선택이 틀리면 루프가 헛돌고, 루프가 헛돌면 멀티에이전트는 그 헛돎을 여러 배로 만듭니다.
그래서 이 과정은 가장 단순한 것부터 쌓습니다. 그리고 각 단계에서 "이 단계로 충분하면 위로 올라가지 않는다"를 원칙으로 삼습니다(1차시).
1.3 일정
| 일차 | 주제 | 차시 |
|---|---|---|
| 1일차 | LLM 호출 · 프롬프트 · 구조화 출력 · 도구 호출 · 안전한 도구 실행 | 1~8 |
| 2일차 | 에이전트 루프 · 가드레일 · 프레임워크 · 문서 검색(RAG) · 대화 세션 | 9~16 |
| 3일차 | 장기 기억 · 그래프 워크플로우 · 멀티에이전트 · 사람의 개입 · 서비스 통합 | 17~24 |
2. 이 노트의 사고방식 — 정의하는 법
2.1 비유보다 범주를 먼저
"에이전트는 비서 같은 거예요", "멀티에이전트는 회사 조직 같은 거예요" 같은 비유는 기억에는 좋지만 서로 겹칩니다. 겹치면 경계가 흐려지고, 둘이 무엇이 다른지 말할 수 없게 됩니다.
그래서 이 노트는 항상 이 순서 로 씁니다.
| 순서 | 무엇을 하는가 | 예 |
|---|---|---|
| ① | 소속 범주부터 — "이것은 ~의 한 종류다" | 에이전트는 LLM 응용 시스템 의 한 종류다 |
| ② | 형제 개념과의 경계선 — 0/1로 갈리는 축 | 워크플로우는 코드가 흐름을 정하고, 에이전트는 모델이 흐름을 정한다 |
| ③ | 반례 — "이건 아니다" | 도구 목록을 준 한 번의 호출은 아직 에이전트가 아니다 (반복이 없다) |
| ④ | 그 다음에야 비유 — 기억 보조용으로만 | 정해진 조립 라인 ↔ 재량을 가진 직원 |
2.2 정의는 이 형식으로 씁니다
X — [상위 범주]인데, [ 종차 ]는 점에서 [형제 개념]과 구별된다.
상위 범주 는 "무엇의 한 종류인가"이고, 종차(種差) 는 "같은 종류 안의 형제들과 무엇이 다른가"입니다.
| 용어 | 정의 |
|---|---|
| 에이전트 | [LLM 응용 시스템]인데, [ 모델이 도구 사용과 다음 행동을 스스로 정하며 목표까지 반복한다 ]는 점에서 코드가 순서를 정한 워크플로우와 구별된다. |
| RAG | [LLM 응용 기법]인데, [ 질문과 관련된 문서를 찾아 프롬프트에 함께 넣어 근거로 답하게 한다 ]는 점에서 모델의 가중치를 고치는 파인튜닝과 구별된다. |
2.3 새 용어를 만났을 때 던질 네 개의 질문 ⭐
- 이것은 무엇의 한 종류인가? (상위 범주)
- 형제 개념과 무엇으로 갈리는가? (5장의 여덟 축 중 어디에 꽂히는가 )
- 이건 아니다 — 반례는 무엇인가?
- 그다음에야 비유를 찾는다. (기억 보조용으로만)
3. 각 차시 노트의 구조
모든 차시가 같은 자리 로 되어 있습니다.
┌──────────────────────────────────────────────────┐
│ 지도 위치 ← 몇 일차, 어느 층, 앞뒤 차시 │
│ 이 차시를 다 읽으면 ← 학습 목표 │
│ 0. 이 차시의 판별 축 ← 0/1 축 표, 5장의 어느 큰 축인가 │
│ 1~N. 본문 ← 정의 → 경계 → 반례 → 비유 │
│ N. 실습 — 맡기고 검수하기 ← AI에게 줄 지시, 받을 증거, │
│ 내가 직접 확인할 것 │
├──────────────────────────────────────────────────┤
│ 부록 A. 스스로 확인하기 (질문 + 답이 있는 절) │
│ 부록 B. 자주 하는 실수 (❌ / ⭕) │
│ 부록 C. NotebookLM 복습 프롬프트 │
└──────────────────────────────────────────────────┘
| 자리 | 어떻게 쓰는가 |
|---|---|
| 이 차시를 다 읽으면 | 읽기 전에 한 번, 읽고 나서 한 번 봅니다. 두 번째에 못 하겠는 항목이 다시 볼 곳입니다 |
| 0. 판별 축 | 본문보다 먼저 봅니다. 그 차시의 뼈대입니다 |
| 본문 | 순서대로 읽습니다. ⭐가 붙은 절이 중심입니다 |
| 실습 — 맡기고 검수하기 | 코드를 직접 짜지 않고 AI(코딩 에이전트)에게 맡기는 방식입니다. 9장 참고 |
| 부록 A | 답을 먼저 보지 말고 절 번호로 되돌아가세요 |
| 부록 B | 막혔을 때 가장 먼저 볼 곳입니다 |
기호 약속
| 기호 | 뜻 |
|---|---|
| ⭐ | 그 차시의 핵심 |
| ⚠️ | 주의. 여기서 대부분 틀립니다 |
| 💡 | 팁 |
| ❌ / ⭕ | 잘못된 것 / 올바른 것 |
| 🔍 읽는 포인트 | 코드 블록에서 이 줄만 알아보면 되는 곳 |
> 앞으로 다시 만납니다 | 뒤 차시에 대한 예고. 그 자리에서 반드시 회수됩니다 |
| "앞에서 배운 ~ (N차시)" | 이 노트의 앞 차시에서 이어지는 자리 |
4. 전체 구조 — 여섯 개의 층
에이전트 서비스는 아래 여섯 층으로 쌓입니다. 이 그림이 과정 전체의 지도입니다. 위층은 아래층을 부품으로 씁니다.
┌────────────────────────────────────────────────────────────┐
│ ⑥ 서비스 API 서버 · 스트리밍 · 사람의 승인(HITL) │ ← 23~24차시
├────────────────────────────────────────────────────────────┤
│ ⑤ 협업 그래프 워크플로우 · 분기 · 작업 분해 · 전문/관리 에이전트 │ ← 18~22차시
├────────────────────────────────────────────────────────────┤
│ ④ 기억 대화 세션(단기) · 요약 · 사용자 프로필(장기) │ ← 16~17차시
├────────────────────────────────────────────────────────────┤
│ ③ 지식 문서 로딩 · 청킹 · 임베딩 · 벡터 DB · 근거 기반 답변 │ ← 12~15차시
├────────────────────────────────────────────────────────────┤
│ ② 행동 도구 호출 · 다중 도구 라우팅 · 에이전트 루프 · 가드레일 │ ← 5~11차시
├────────────────────────────────────────────────────────────┤
│ ① 호출 LLM API · 프롬프트 · 구조화 출력 │ ← 1~4차시
└────────────────────────────────────────────────────────────┘
| 일차 | 이 날 답하는 질문 | 주로 다루는 층 | 주요 산출물 |
|---|---|---|---|
| 1일차 | LLM을 어떻게 부르고, 어떻게 바깥 기능을 쓰게 하나? | ① ② | 의도 분류기, 데이터 조회 도구, 안전한 도구 계층 |
| 2일차 | 스스로 반복하고, 근거를 찾고, 대화를 이어 가려면? | ② ③ ④ | 에이전트 루프 + 가드레일, RAG 파이프라인, 세션 관리 |
| 3일차 | 오래 기억하고, 역할을 나눠 협업하고, 서비스로 내보내려면? | ④ ⑤ ⑥ | 그래프 기반 멀티에이전트, HITL, API 서버 |
5. ⭐ 판별 축 지도
판별 축 — 두 개념을 0과 1로 가르는 하나의 질문 입니다.
축은 비유와 다릅니다. 비유는 개념마다 새로 만들어야 하고 서로 겹치지만, 축은 여덟 개로 이 과정 전체를 덮고 서로 겹치지 않습니다. 새 용어가 나오면 어느 축의 어느 쪽에 꽂히는지만 정하면 됩니다.
5.1 여덟 개의 큰 축 — 정의
| 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축이 묻는 질문 | 일반적인 예 |
|---|---|---|---|---|
| ① 디스크 ↔ 메모리 | 디스크 — 영구 · 꺼도 남음 | 메모리 — 휘발 · 실행 중에만 있음 | 이것은 저장된 것인가, 지금만 살아 있는 것인가? | 저장된 문서 파일 ↔ 열려 있는 편집 창 |
| ② 추상 ↔ 구상 | 추상 — 무엇을 해야 하는가 (계약 · 약속) | 구상 — 어떻게 하는가 (구현 · 기술) | 이것은 약속인가, 그 약속을 지키는 실제 부품인가? | 콘센트 규격 ↔ 그 규격에 맞춘 각 회사의 플러그 |
| ③ 속성 ↔ 기능 | 속성 — 값 · 데이터 · 설명 | 기능 — 동작 · 실행 | 이것은 가지고 있는 값인가, 수행하는 동작인가? | 주문 정보 ↔ 주문 조회하기 |
| ④ 로컬 ↔ 원격 | 로컬 — 내 서버 · 내 컴퓨터 | 원격 — 남의 서버 · 인터넷 너머 | 이것은 내 손 안에 있는가, 밖으로 나가는가? | 사내 DB ↔ 외부 API |
| ⑤ 하나 ↔ 여럿 | 하나로 뭉침 — 단순 · 빠름, 대신 같이 멈추고 한계가 있음 | 여럿으로 나눔 — 전문화 · 확장, 대신 조율 비용 | 한 덩어리로 둘 것인가, 나눌 것인가? | 한 사람이 다 하는 가게 ↔ 역할을 나눈 팀 |
| ⑥ 동기 ↔ 비동기 | 동기 — 끝날 때까지 기다린다 | 비동기 — 기다리지 않고 다른 일을 한다 | 결과를 기다리는 동안 멈춰 있는가? | 전화 통화 ↔ 문자 메시지 |
| ⑦ 무상태 ↔ 상태 | 무상태 — 이전 일을 기억하지 않는다 | 상태 — 이전 일을 기억한다 | 이것은 지난번을 기억하는가? | 자판기 ↔ 단골 손님을 기억하는 직원 |
| ⑧ 구문론 ↔ 의미론 | 구문 — 형식 이 맞는가 | 의미 — 뜻 이 맞는가 | 겉모양을 검사하는가, 내용을 검사하는가? | 맞춤법 검사 ↔ 내용이 맞는지 검토 |
⚠️ 두 개를 미리 짚어 둡니다.
- ⑤의 오른쪽(멀티에이전트)은 "발전된 형태"가 아닙니다. 에이전트를 나누면 전문화되는 대신 넘겨주는 비용(토큰 · 지연 · 정보 손실) 이 생깁니다. 규모와 실패 비용이 답을 정합니다(21차시).
- ⑥ 비동기는 "더 빠른 것"이 아닙니다. 일 하나에 걸리는 시간은 같고, 기다리는 시간에 다른 일을 하므로 같은 시간에 처리하는 양 이 늘어날 뿐입니다.
5.2 ⭐ 이 과정의 중심 축 — 누가 흐름을 정하는가
여덟 축 외에, 이 과정 전체를 꿰는 파생 축이 하나 있습니다.
| 코드가 흐름을 정한다 (0) | 모델이 흐름을 정한다 (1) | |
|---|---|---|
| 이름 | 워크플로우 (Workflow) | 에이전트 (Agent) |
| 다음에 할 일 | 개발자가 미리 짠 순서 · 분기 | 모델이 결과를 보고 스스로 결정 |
| 장점 | 예측 가능 · 시험하기 쉬움 · 싸다 | 유연 · 미리 다 정할 수 없는 일에 대응 |
| 단점 | 예상 밖 상황에 약함 | 예측 어려움 · 비싸다 · 헛돌 수 있음 |
| 이 과정의 자리 | 의도 분류 후 분기(4, 7, 19차시), 그래프(18차시) | 에이전트 루프(9차시), 관리 에이전트(22차시) |
부모 축은 ⑦ 무상태 ↔ 상태와 결정론 ↔ 확률론입니다. ⭐ 이 과정의 3일은 이 축 위를 오가는 여정 입니다. 1일차는 대부분 왼쪽, 2일차 루프는 오른쪽, 3일차 그래프는 둘을 섞는 법 (큰 흐름은 코드가, 각 칸 안의 판단은 모델이)입니다.
5.3 여덟 축이 이 과정에서 나오는 자리
| 큰 축 | 이 과정에서의 모습 | 주로 나오는 차시 |
|---|---|---|
| ① 디스크 ↔ 메모리 | ⭐ 컨텍스트(이번 호출에만 존재) ↔ 세션 저장 · 장기 기억 · 벡터 DB(영구) | ⭐ 12, 13, 16, 17 |
| ② 추상 ↔ 구상 | 도구 선언(이름 · 설명 · 인자 형식) ↔ 실제 함수 / 에이전트의 입출력 약속 ↔ 내부 구현 / 프레임워크 ↔ 모델 제공자 | ⭐ 5, 11, 21 |
| ③ 속성 ↔ 기능 | 그래프의 State(값) ↔ Node(동작) / 도구 결과(데이터) ↔ 도구 실행 | 6, 18 |
| ④ 로컬 ↔ 원격 | ⭐ 내 서버의 데이터 ↔ 외부 LLM API로 보내지는 프롬프트 — 무엇이 밖으로 나가는가 | ⭐ 2, 8, 17 |
| ⑤ 하나 ↔ 여럿 | 도구 하나 ↔ 여러 도구 / 에이전트 하나 ↔ 멀티에이전트 / 문서 통째 ↔ 청크 | ⭐ 7, 12, 20, 21, 22 |
| ⑥ 동기 ↔ 비동기 | 한 번에 받기 ↔ 스트리밍 / 순서대로 ↔ 병렬 도구 · 병렬 워커 | 20, 24 |
| ⑦ 무상태 ↔ 상태 | ⭐ LLM API는 무상태 → 대화 이력을 매번 다시 보낸다 / 그래프 State · 체크포인트 / 승인 대기 후 재개 | ⭐ 9, 16, 18, 23 |
| ⑧ 구문론 ↔ 의미론 | ⭐ 스키마 검증(형식) ↔ 분류 정확도 · 답의 근거(의미) / 키워드 검색 ↔ 의미 검색 | ⭐ 4, 13, 15 |
5.4 이 과정에서 자주 쓰는 파생 축
| 파생 축 | 왼쪽 (0) | 오른쪽 (1) | 부모 축 | 나오는 차시 |
|---|---|---|---|---|
| 누가 흐름을 정하는가 ⭐ | 코드 (워크플로우) | 모델 (에이전트) | ⑦ | 1, 9, 18, 22 |
| 결정론 ↔ 확률론 | 같은 입력 → 같은 출력 | 같은 입력 → 다른 출력 가능 | ⑧ | 3, 4, 10 |
| 부탁 ↔ 강제 | 프롬프트로 "하지 마" | 코드 · 스키마 · 권한으로 막음 | ② | ⭐ 4, 8, 10 |
| 읽기 ↔ 쓰기 | 조회 도구 (상태를 안 바꿈, 재시도 안전) | 변경 도구 (상태를 바꿈, 재시도 위험) | ⑦ | 6, 8, 23 |
| 사람이 손을 대는가 | 사람 승인 후 실행 | 자동 실행 | ⑦ | 8, 23 |
| 밖에서 찾는가 ↔ 안을 고치는가 | RAG (문서를 찾아 넣음) | 파인튜닝 (가중치를 고침) | ⑧ | 12, 14 |
| 단기 ↔ 장기 기억 | 이번 세션의 대화 | 세션을 넘어 남는 사용자 정보 | ① | 16, 17 |
| 선형 ↔ 그래프 | 체인 (A → B → C) | 그래프 (분기 · 되돌아감 · 병렬) | ⑤ | 11, 18, 19 |
| 증거 ↔ 주장 | 출처 · 실행 결과가 붙은 답 | 근거 없는 답 | ⑧ | ⭐ 14, 9장 전체 |
| 한 건의 비용 ↔ 전체 비용 | 호출 한 번의 토큰 | 루프 · 멀티에이전트 전체의 토큰 | ⑤ | 2, 7, 10, 21 |
6. 과정 전체를 관통하는 세 문장
문장 1. 가장 단순한 것부터, 충분하면 멈춘다 (누가 흐름을 정하는가)
한 번의 호출로 되면 워크플로우를 만들지 않고, 워크플로우로 되면 에이전트를 만들지 않고, 에이전트 하나로 되면 멀티에이전트를 만들지 않습니다. 위로 올라갈수록 유연해지는 대신 비싸고 예측하기 어렵습니다. → 1, 9, 21차시
문장 2. 모델은 판단하고, 코드는 지킨다 (부탁 ↔ 강제)
모델은 무엇을 할지 판단 합니다. 하지만 형식 · 권한 · 개인정보 · 비용 · 반복 횟수처럼 어기면 안 되는 선 은 프롬프트로 부탁하지 않고 코드로 강제 합니다. 도구는 모델이 "요청"할 뿐 실행은 코드가 합니다. → 4, 5, 8, 10, 23차시
문장 3. 근거와 측정이 없으면 믿지 않는다 (증거 ↔ 주장)
답에는 출처 가 붙어야 하고(14차시), 도구 선택 · 검색 품질 · 분류 정확도는 평가셋으로 측정 해야 하며(4, 7, 15차시), 에이전트의 행동은 추적(트레이싱)으로 기록 되어야 합니다(11차시). → 4, 7, 11, 14, 15, 24차시
7. 노트 전체에서 쓰는 예제 서비스
오피스봇 — 회사 직원이 사내 메신저로 묻는 인사 · IT · 규정 질문을 처리하는 사내 도우미
| 기능 | 예 | 관련 차시 |
|---|---|---|
| 의도 분류 | "휴가 며칠 남았어?" → 휴가조회 / "노트북이 안 켜져요" → IT장애 | 4 |
| 데이터 조회 도구 | 휴가 잔여 조회, IT 티켓 상태 조회 | 6 |
| 변경 도구 (승인 필요) | 장비 신청, 휴가 신청 | 8, 23 |
| 규정 문서 검색 | 취업규칙 · 복리후생 · 보안 규정 PDF에서 근거를 찾아 답하고 출처 표기 | 12~15 |
| 대화와 기억 | 앞 질문을 이어받기, 부서 · 선호 언어 기억 | 16, 17 |
| 멀티에이전트 | 인사 에이전트 · IT 에이전트 · 규정 에이전트 + 관리 에이전트 | 20~22 |
일부러 고른 까다로운 지점
| 지점 | 왜 까다로운가 | 관련 축 · 차시 |
|---|---|---|
| 본인 데이터만 | 직원 A가 직원 B의 휴가 · 연봉을 물으면? 모델이 아니라 코드가 막아야 함 | 부탁 ↔ 강제, 8차시 |
| 개인정보가 외부 API로 | 사번 · 연락처 · 연봉이 프롬프트에 실려 외부 LLM으로 나감 | ④, 8 · 17차시 |
| 복합 요청 | "다음 주 월요일 휴가 쓰려는데 잔여 확인하고, 노트북 반납 절차도 알려줘" | ⑤, 20차시 |
| 되돌릴 수 없는 작업 | 장비 신청 · 휴가 신청은 실행하면 기록이 남음 | 읽기 ↔ 쓰기, 23차시 |
(실제 수업 예제와 다를 수 있습니다. 개념을 붙잡을 고리로만 쓰세요.)
8. 실습 기준 환경
| 항목 | 기준 | 비고 |
|---|---|---|
| 언어 | Python 3.11+ | 가상환경 사용 (2차시) |
| LLM | Claude API (anthropic Python SDK) | 다른 제공자(OpenAI 등)도 개념은 같습니다. 이름과 파라미터만 다릅니다 |
| 예시 모델 | claude-opus-5-5 (기본), 가볍고 많은 작업에는 claude-haiku-5-5 · claude-sonnet-5-5 | 모델 이름 · 가격은 자주 바뀝니다. 공식 문서 확인 (2차시) |
| 프레임워크 | LangChain, LangGraph | 버전에 따라 API 이름이 바뀝니다 (11, 18차시) |
| 임베딩 · 벡터 DB | 오픈소스 임베딩 모델 + Chroma (예시) | pgvector, Qdrant 등으로 바꿀 수 있습니다 (13차시) |
| 서버 | FastAPI | 24차시 |
⚠️ 이 분야는 라이브러리 이름 · 함수 이름 · 모델 이름이 몇 달 단위로 바뀝니다. 노트의 코드는 구조를 보여 주기 위한 예시 이고, 실제로 실행할 때는 공식 문서 기준으로 AI에게 맞춰 쓰게 하세요(9장).
9. AI에게 맡기는 방식으로 읽기
이 노트는 코드를 한 줄씩 읽지 않고, 큰 그림과 판단은 내가 쥐고 구현은 AI(코딩 에이전트)에게 맡기는 방식 을 기준으로 썼습니다.
이 과정에는 재미있는 겹침이 있습니다. 에이전트를 만드는 일을 에이전트에게 맡깁니다. 그래서 이 과정에서 배우는 원칙(도구 권한, 가드레일, 사람의 승인, 근거 요구)은 내가 코딩 에이전트를 다룰 때도 그대로 적용됩니다.
9.1 내가 쥐는 것
| 내가 쥐는 것 | 왜 | 어디서 배우나 |
|---|---|---|
| 설계 결정 | 워크플로우냐 에이전트냐, 도구를 몇 개로 나눌지, 에이전트를 나눌지 | 1, 7, 18, 21차시 |
| 권한과 경계 | 어떤 도구가 쓰기를 하는지, 누구의 데이터를 볼 수 있는지, 무엇이 밖으로 나가는지 | 8, 17, 23차시 |
| 평가셋 | 실제 질문 수십 개와 기대 결과. AI의 "잘 동작합니다"를 직접 채점 | 4, 7, 15차시 |
| 비용 한도 | 에이전트 · 멀티에이전트는 토큰을 많이 씀. 상한을 정하는 것은 사람 | 2, 10, 21차시 |
9.2 실습의 세 자리
| 실습의 자리 | 하는 일 |
|---|---|
| 지시 | 목표 · 참고할 공식 문서 · 하지 말 것 · 보고 형식(표) 을 정해 AI에게 맡김 |
| 받을 증거 | "완료했습니다" 대신 실행 명령과 출력 원문, 평가 결과표, 실행 추적 기록 을 받음 |
| 내가 직접 확인할 것 | 화면 · 숫자 · 행동 시험(다른 사람 사번으로 물어보기 등)처럼 코드 없이 확인할 수 있는 것 |
9.3 이 분야에서 AI에게 맡길 때 특히 조심할 점 ⚠️
| 위험 | 왜 | 대응 |
|---|---|---|
| AI의 기억이 오래됨 | SDK · LangChain · LangGraph의 함수 이름이 자주 바뀜. 사라진 함수를 자신 있게 씀 | 공식 문서 주소를 함께 주고 , 실행 결과로 확인 |
| "잘 동작합니다" | 예시 질문 한두 개만 돌려 봤을 수 있음 | 평가셋 결과표 를 요구 |
| 권한 검사를 프롬프트에만 둠 | "다른 사람 정보는 알려 주지 마"는 부탁일 뿐 | 도구 코드 안에서 막았는지 행동 시험으로 확인 (8차시) |
| API 키 노출 | 키를 코드나 대화에 붙여 넣음 | 환경변수로만. AI에게 키 값을 보여 주지 않음 (2차시) |
| 비용 폭주 | 루프가 멈추지 않거나 에이전트가 서로 계속 호출 | 반복 횟수 · 토큰 상한을 코드로 걸었는지 확인 (10차시) |
9.4 코드 블록 읽는 법
| 코드 종류 | 알아볼 것 | 몰라도 되는 것 |
|---|---|---|
| LLM 호출 | model=, system=, messages=, max_tokens= 네 줄 | 나머지 옵션 |
| 도구 정의 | "name", "description", "input_schema"의 required | JSON 문법 |
| 에이전트 루프 | while 반복과 멈추는 조건 (stop_reason, 최대 횟수) | 리스트 처리 |
| 스키마 (Pydantic) | 필드 이름과 허용 값 목록(Literal, enum) | 타입 문법 |
| 그래프 (LangGraph) | add_node(무엇을 하는 칸), add_edge(어디로 가는 선), add_conditional_edges(갈림길) | 나머지 |
| 응답의 usage | input_tokens, output_tokens — 비용 | — |
10. 전체 목차
1일차 · LLM 호출에서 안전한 도구 실행까지
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 1 | 에이전트 요구사항과 아키텍처 설계 | ⭐ 누가 흐름을 정하는가 |
| 2 | 개발 환경 구성과 LLM API 호출 | ④ 로컬 ↔ 원격, ⑦ 무상태 ↔ 상태 |
| 3 | 프롬프트 설계 | 결정론 ↔ 확률론 |
| 4 | 의도 분류기 — 구조화 출력 | ⭐ ⑧ 구문론 ↔ 의미론, 부탁 ↔ 강제 |
| 5 | Function Calling 원리 | ② 추상 ↔ 구상, ③ 속성 ↔ 기능 |
| 6 | 데이터 조회 도구 구현 | 읽기 ↔ 쓰기, ③ |
| 7 | 다중 도구 라우팅 | ⑤ 하나 ↔ 여럿, 한 건의 비용 ↔ 전체 비용 |
| 8 | 보안 — 안전한 도구 실행 | ⭐ 부탁 ↔ 강제, ④ |
2일차 · 스스로 반복하고, 근거를 찾고, 대화를 잇기
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 9 | 에이전트 루프 직접 구현 | ⭐ 누가 흐름을 정하는가, ⑦ |
| 10 | 루프 제어와 가드레일 | 부탁 ↔ 강제, 한 건의 비용 ↔ 전체 비용 |
| 11 | 프레임워크 기반 에이전트 구성 | ② 추상 ↔ 구상, 증거 ↔ 주장 |
| 12 | 문서 로딩과 청킹 | 밖에서 찾는가 ↔ 안을 고치는가, ⑤ |
| 13 | 임베딩과 벡터 DB | ⑧ 구문론 ↔ 의미론, ① |
| 14 | 근거 기반 답변 | ⭐ 증거 ↔ 주장 |
| 15 | 검색 품질 개선 | ⑧, ⑤ |
| 16 | 멀티턴 대화와 세션 관리 | ⭐ ⑦ 무상태 ↔ 상태 |
3일차 · 기억하고, 협업하고, 서비스로
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 17 | 장기 기억 관리 | 단기 ↔ 장기 기억, ④ |
| 18 | 그래프 기반 워크플로우 | ⭐ 선형 ↔ 그래프, ③ |
| 19 | 조건 분기와 라우팅 | 누가 흐름을 정하는가 |
| 20 | 복합 요청 분해 처리 | ⑤ 하나 ↔ 여럿, ⑥ |
| 21 | 전문 에이전트 구현 | ⭐ ⑤ 하나 ↔ 여럿, ② |
| 22 | 오케스트레이션 | 누가 흐름을 정하는가 |
| 23 | Human-in-the-Loop | ⭐ 사람이 손을 대는가, 읽기 ↔ 쓰기 |
| 24 | 서비스 통합과 실행 | ⑥, 전체 정산 |
부록
- 용어 사전 — 상위 범주 열 포함, 헷갈리는 짝 모음