멀티 에이전트

지도 위치 : 2일차 · README 4장의 ④ 기억 층 — 기억 층의 첫 칸, 한 대화 안의 앞말을 이어받는 자리 | 이전: 15차시 검색 품질 개선 | 다음: 17차시 장기 기억 관리 키워드 : 대화 이력, 세션, 컨텍스트 윈도우

이 차시를 다 읽으면

1. ⭐ "API는 무상태이고, 기억은 앱이 이력을 들고 매번 다시 보내는 것"을 축 ⑦로 설명할 수 있다.
2. 세션을 유와 종차로 정의하고, 루프의 messages(9차시) · 장기 기억(17차시)과 구별할 수 있다.
3. 세션 저장소를 메모리 ↔ Redis/DB로 비교하고, 서버가 여러 대일 때 무엇이 달라지는지 말할 수 있다.
4. 컨텍스트 윈도우를 정의하고, 이력이 길어질 때의 문제와 세 가지 전략(슬라이딩 윈도 · 요약 · 핵심 사실 고정)을 비교할 수 있다.
5. ⚠️ 이력을 자를 때 tool_use / tool_result 짝을 깨지 않는 법과, 세션 분리 실패가 왜 개인정보 사고인지 설명할 수 있다.

---

0. 이 차시의 판별 축

이 차시의 질문 — 직원이 "경조휴가 며칠이야?"라고 묻고, 이어서 "그거 반차로 나눠 써도 돼?"라고 묻습니다. 사람에게는 당연한 "그거"가, 무상태 API에게는 아무것도 가리키지 않습니다. 9차시에서는 루프 한 번 안에서 messages가 쌓였습니다. 이 차시는 그 쌓임을 요청과 요청 사이로 넓힙니다. README가 축 ⑦의 정점으로 꼽은 자리입니다.

---

1. ⭐ 축 ⑦의 정점 — API는 기억하지 않는다

1.1 멀티턴은 "다시 보내기"다

앞에서 배운 대로(2차시) LLM API는 무상태입니다. 두 번째 질문을 보낼 때 첫 번째 질문과 답을 함께 보내지 않으면 , 모델은 첫 번째를 모릅니다.

1턴 보냄: [user "경조휴가 며칠이야?"]
    받음: assistant "본인 결혼 5일, ... [취업규칙 제24조, p.13]"
2턴 보냄: [user "경조휴가 며칠이야?", assistant "본인 결혼 5일 ...", user "그거 반차로 나눠 써도 돼?"]
    받음: assistant "경조휴가는 ... "          ← "그거" = 경조휴가임을 앎

history = []                                   # ⚠️ 이 줄이 이 절의 함정 (2절)

def chat(user_text: str) -> str:
    history.append({"role": "user", "content": user_text})
    response = client.messages.create(model=MODEL, max_tokens=16000,
                                      system=SYSTEM, messages=history)
    history.append({"role": "assistant", "content": response.content})
    return "".join(b.text for b in response.content if b.type == "text")

🔍 읽는 포인트 : messages=history — 매번 이력 전체 를 보냅니다. 기억은 모델 안이 아니라 history라는 앱의 변수 안 에 있습니다.

1.2 반례 — 이건 API가 기억하는 것이 아닙니다

---

2. 세션 — 누구의 이력인가

2.1 정의와 경계

1.1의 코드에는 큰 함정이 있습니다. history가 하나 뿐이라, 직원 A와 직원 B가 동시에 쓰면 같은 이력에 섞입니다.

세션 (Session) — [앱의 상태 관리 단위]인데, [ 한 사용자의 한 대화를 세션 ID로 묶어, 그 대화의 이력을 요청 사이에 보관한다 ]는 점에서 요청 하나가 끝나면 사라지는 루프의 messages와, 세션을 넘어 남는 장기 기억과 구별된다.

2.2 세션 ID와 주인 확인

sessions: dict[str, dict] = {}                     # 세션 ID → {"owner": 사번, "history": [...]}

def chat(session_id: str, user, text: str) -> str:
    s = sessions.get(session_id)
    if s is None or s["owner"] != user.employee_id:   # ⭐ 이 세션의 주인인가
        raise PermissionError("세션 접근 권한 없음")
    s["history"].append({"role": "user", "content": text})
    ...

🔍 읽는 포인트 : 세션 ID만 맞으면 통과시키지 않고, 로그인한 사용자 = 세션 주인 인지 확인합니다. 앞에서 배운 권한 경계(8차시: 신원은 로그인 세션에서, 요청자 = 대상인지 코드가 검사)가 이력에도 그대로 적용됩니다. 세션 ID는 서버가 추측할 수 없는 무작위 값 으로 발급합니다.

---

3. 세션 저장소 — 메모리 ↔ Redis/DB (축 ①)

Redis — [데이터 저장소]인데, [ 별도 서버의 메모리에 키-값을 두고 여러 앱 서버가 함께 읽고 쓰며, 항목마다 만료 시간을 줄 수 있다 ]는 점에서 앱 프로세스 안에만 있는 dict와 구별된다.

⚠️ 서버가 두 대가 되는 순간 dict 방식은 조용히 망가집니다. 첫 질문은 1번 서버로, 둘째 질문은 2번 서버로 가면 "그거"를 모릅니다. 에러는 나지 않고 답만 엉뚱해집니다.

⚠️ 저장소에 남는 이력에는 직원의 질문 · 조회 결과가 담깁니다. 보관 기한 · 마스킹 (8차시)을 저장 단계에도 적용하고, 무엇을 얼마나 남길지는 17차시에서 장기 기억과 함께 정합니다.

---

4. 컨텍스트 윈도우 — 이력이 길어지면

4.1 정의

컨텍스트 윈도우 (Context Window) — [모델의 입력 한도]인데, [ 한 번의 호출에서 다룰 수 있는 토큰(시스템 프롬프트 · 이력 · 도구 · 답)의 상한 ]이라는 점에서 대화를 저장해 두는 세션 저장소의 크기와 구별된다. 최신 Claude 모델은 100만 토큰입니다.

4.2 한도 안이어도 문제다

💡 현재 이력의 크기는 client.messages.count_tokens(model=..., system=..., messages=history)로 미리 셉니다. 다른 회사의 토크나이저로 세면 맞지 않습니다.

4.3 세 가지 전략

⭐ 실무에서는 섞어 씁니다 — 최근 N턴 + 오래된 부분 요약 + 핵심 사실 고정. 그리고 어느 전략이든 이력을 바꾸면 앞부분이 달라져 프롬프트 캐시가 깨진다 (10차시 6절)는 점을 비용 계산에 넣습니다. 서버 측에서 긴 대화를 자동 요약해 주는 기능(compaction, 베타)도 있습니다. 직접 요약과의 비교는 17차시에서 다룹니다.

---

5. ⚠️ 도구 호출 기록까지 담은 이력 자르기

오피스봇의 이력에는 사용자 · 답 텍스트만 있는 게 아닙니다. 9차시 루프의 tool_use · tool_result도 들어 있습니다.

[0] user       "다음 주 휴가 쓸 수 있어?"              ← 턴 1 시작
[1] assistant  tool_use(get_leave_balance)  id=t1
[2] user       tool_result(t1) "5일"
[3] assistant  "네, 5일 남아 ..."
[4] user       "경조휴가는 며칠이야?"                   ← 턴 2 시작
[5] assistant  tool_use(search_policy)      id=t2
[6] user       tool_result(t2) "제24조 ..."
[7] assistant  "본인 결혼 5일 ..."

def trim(history: list, max_turns: int) -> list:
    starts = [i for i, m in enumerate(history)
              if m["role"] == "user" and isinstance(m["content"], str)]   # 사람이 쓴 메시지 = 턴 시작
    return history if len(starts) <= max_turns else history[starts[-max_turns]:]

🔍 읽는 포인트 : ⭐ 자르는 자리는 턴의 시작 (사람이 직접 쓴 user 메시지)뿐입니다. tool_result도 role은 user이지만 내용이 블록 목록이라 턴 시작으로 치지 않습니다. 이렇게 하면 짝이 항상 함께 남거나 함께 잘립니다.

---

6. ⚠️ 세션 분리 실패 = 개인정보 사고

이력에는 직원의 잔여 연차 · 질문 내용 · 조회 결과가 들어 있습니다. 세션이 섞이면 다른 직원에게 그 내용이 답으로 나갑니다. 모델의 실수가 아니라 앱의 사고 입니다.

⭐ 세션 분리는 부탁이 아니라 강제 의 영역입니다. "이전 사용자의 대화는 언급하지 마"라는 프롬프트는 아무것도 막지 못합니다 — 이력이 섞인 순간 이미 모델 입력에 들어가 있기 때문입니다.

---

7. 오피스봇 적용 — 세 턴의 대화

턴 3에서 "신청 대상: 경조휴가, 날짜: 다음 주 월요일"은 핵심 사실 고정 (4.3) 칸에 올려 둡니다. 이력이 잘려도 진행 중인 신청 내용은 잊지 않게 합니다.

---

8. 2일차 정리와 3일차 예고

2일차가 끝나면 오피스봇은 스스로 반복하고(행동), 근거를 찾고(지식), 한 대화를 이어 갑니다(기억). 하지만 세션이 끝나면 이력은 사라집니다. 내일 다시 오면 오피스봇은 이 직원이 개발팀이라는 것도, 어제 경조휴가를 물었다는 것도 모릅니다.

앞으로 다시 만납니다 — 17차시에서 세션을 넘어 남는 장기 기억 (요약 메모리 · 사용자 프로필)과 그 민감정보 관리를, 18차시에서 이 차시의 이력과 같은 생각을 그래프의 State · 체크포인트 (세션별 상태 저장 · 재개)로, 23차시에서 턴 3의 승인 대기를 다룹니다.

---

9. 실습 — 맡기고 검수하기

지시

오피스봇에 세션별 멀티턴 대화를 붙여줘.
- 참고: Claude API 공식 문서(messages, token counting). 확인한 주소를 보고에 적을 것
- 세션: 서버가 무작위 세션 ID 발급, {owner: 로그인 사번, history} 저장. 요청마다 owner == 로그인 사번 검사
- 저장소: 개발은 dict, 설정 하나로 Redis로 바꿀 수 있게. 30분 무응답 시 만료
- 이력 자르기: 최근 10턴 슬라이딩 윈도. 반드시 "사람이 쓴 user 메시지" 위치에서만 자를 것
- 핵심 사실 칸: 진행 중인 신청(휴가 종류·날짜)을 따로 저장해 매 요청 앞에 넣을 것
- 매 요청 전에 count_tokens로 입력 토큰을 재서 로그에 남길 것
- 저장 전 마스킹 적용 (주민번호·전화번호)
테스트: ① 3턴 대화(경조휴가 → 그거 반차로? → 다음 주 월요일 신청)
 ② 15턴 대화로 자르기 동작, 도구 호출이 섞인 턴에서 잘릴 때 400 에러가 없는지
 ③ 직원 A 세션 ID로 직원 B 로그인 상태에서 요청
 ④ 서버 재시작 후 같은 세션 이어 묻기 (dict / Redis 각각)
추측하지 말고 실행 출력 원문을 붙여.
보고 형식: [테스트 | 턴 | 보낸 메시지 수 | 입력 토큰 | 결과 | 에러 여부] 표

받을 증거

• 테스트 ①~④의 표와 요청별 로그 원문
• ②에서 자르기 직전 · 직후의 이력 구조(역할과 블록 종류만)
• ③의 거부 응답 원문

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 16차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"API는 무상태, 앱이 이력을 다시 보낸다(축 ⑦)", "세션과 주인 확인", "컨텍스트 윈도우와 세 가지 줄이기 전략", "tool_use/tool_result 짝을 깨지 않고 자르기"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.