멀티 에이전트

지도 위치 : 3일차 · README 4장의 ④ 기억 층(장기) | 이전: 16차시 멀티턴 대화와 세션 관리 | 다음: 18차시 그래프 기반 워크플로우 키워드 : 요약 메모리, 장기 기억, 민감정보 관리

이 차시를 다 읽으면

1. 단기 기억과 장기 기억을 저장 위치와 수명 으로 가르고, 장기 기억이 아닌 것(가중치 · 규정 문서 · 긴 컨텍스트)을 반례로 댈 수 있다.
2. 대화 압축(요약 메모리)을 직접 구현하는 방식과 API의 자동 요약 기능 으로 나눠 장단을 말할 수 있다.
3. 사용자 프로필을 스키마로 정의해 "무엇을 기억하고 무엇을 기억하지 않을지"를 코드로 정할 수 있다.
4. 기억을 쓰는 시점과 읽는(주입) 시점 을 설계하고, 틀린 기억이 굳는 위험을 설명할 수 있다.
5. 민감정보 관리의 다섯 가지 통제(저장 금지 · 마스킹 · 보관 기한 · 열람과 삭제 · 외부 전송)로 오피스봇의 기억을 점검할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 하나입니다. "세션이 끝난 뒤에도 남겨야 할 것은 무엇이고, 남기면 안 되는 것은 무엇인가?" 앞에서 배운 세션 관리(16차시)는 "이번 대화를 어떻게 이어 가나"였습니다. LLM API는 지난 요청을 기억하지 못하므로(무상태) 앱이 대화 이력을 저장해 매번 다시 보냈습니다. 이번에는 그 대화가 끝난 뒤 를 다룹니다. 축 1과 2는 "무엇을 남기나", 축 3과 5는 "남긴 것이 안전한가"를 묻습니다.

---

1. 단기 기억과 장기 기억

1.1 정의

단기 기억 — [에이전트의 기억]인데, [ 한 세션 안에서만 유지되고 세션이 끝나면 버려진다 ]는 점에서 장기 기억과 구별된다. 16차시의 대화 이력이 여기에 해당합니다.

장기 기억 — [에이전트의 기억]인데, [ 세션이 끝나도 저장소에 남아 다음 세션 시작 시 다시 프롬프트에 주입된다 ]는 점에서 단기 기억과 구별된다.

⭐ 마지막 줄이 이 차시의 핵심 위험입니다. 장기 기억은 매번 다시 주입 되므로, 한 번 잘못 저장된 사실이 모든 대화에 따라다닙니다(4.3).

1.2 반례 — 이건 장기 기억이 아닙니다

💡 비유 (기억 보조용) — 단기 기억은 통화 중에 적는 메모지 , 장기 기억은 고객 카드 입니다. 메모지는 통화가 끝나면 버리고, 고객 카드에는 다음 통화에 필요한 것만 옮겨 적습니다. 무엇을 옮겨 적을지 정하는 것이 이 차시의 일입니다.

---

2. 대화 압축 — 요약 메모리

2.1 정의

앞에서 배운 세션 관리(16차시)에서 대화가 길어질 때의 전략 세 가지를 봤습니다 — 최근 N턴만 유지, 오래된 부분 요약, 중요 사실 고정. 그중 "요약"을 장기 기억으로 넓힌 것이 요약 메모리입니다.

요약 메모리 — [대화 압축 방식]인데, [ 오래된 대화를 LLM이 쓴 짧은 요약으로 바꿔 원문 대신 넣는다 ]는 점에서 오래된 턴을 그냥 버리는 슬라이딩 윈도와 구별된다.

2.2 직접 구현 — 요약 한 번 부르기

SUMMARY_PROMPT = """아래 대화를 다음 대화에 이어 쓸 수 있게 요약하라.
- 사용자가 확정한 사실과 아직 처리되지 않은 요청만 남겨라. 추측하지 마라.
- 주민등록번호 · 연봉 · 건강 정보 · 계좌번호는 요약에 넣지 마라."""

def summarize(old_messages: list[dict]) -> str:
    response = client.messages.create(
        model="claude-haiku-5-5",            # 요약은 가벼운 일 → 작은 모델
        max_tokens=1024,
        system=SUMMARY_PROMPT,
        messages=[{"role": "user", "content": render(old_messages)}],
    )
    return next(b.text for b in response.content if b.type == "text")

if count_tokens(history) > LIMIT:            # 길어지면
    summary = summarize(history[:-6])        # 최근 6개 메시지만 원문 유지
    history = [{"role": "user", "content": f"[이전 대화 요약]\n{summary}"}] + history[-6:]

🔍 읽는 포인트

• model="claude-haiku-5-5" — 요약은 판단이 가벼운 일이라 작고 싼 모델로 충분한 경우가 많습니다. 실제로 충분한지는 요약 결과를 읽어 보고 정합니다.
• count_tokens(...) > LIMIT — 토큰 수는 client.messages.count_tokens(...)로 셉니다. 다른 회사 토크나이저로 세면 숫자가 다릅니다.
• history[-6:] — 최근 대화는 원문 그대로 둡니다. 방금 한 말까지 요약하면 대명사("그거")가 풀리지 않습니다.
• ⚠️ 프롬프트의 "넣지 마라"는 부탁 입니다. 실제로 막는 것은 5절의 마스킹 코드입니다.

2.3 직접 구현 vs API의 자동 요약

Claude API에는 긴 대화를 서버 쪽에서 자동으로 압축해 주는 기능(compaction, 베타)이 있습니다. 켜는 방법과 조건은 버전에 따라 다르니 공식 문서를 확인 하세요.

---

3. 사용자 프로필 — 무엇을 기억할지 스키마로

3.1 정의

사용자 프로필 — [장기 기억]인데, [ 미리 정한 항목(스키마)에 맞춰 사실을 구조화해 저장한다 ]는 점에서 자유로운 글인 요약 메모리와 구별된다.

3.2 스키마 — 앞에서 배운 구조화 출력 재사용

앞에서 배운 의도 분류기(4차시)에서는 모델의 답을 Pydantic 스키마로 받아 형식을 강제 했습니다. 같은 방법으로 "대화에서 프로필에 남길 사실"을 뽑습니다.

from pydantic import BaseModel
from typing import Literal

class ProfileUpdate(BaseModel):
    department: str | None              # 부서
    preferred_language: Literal["ko", "en"] | None
    answer_style: Literal["짧게", "자세히"] | None
    frequent_topics: list[str]          # 자주 묻는 주제 (예: "휴가", "VPN")
    evidence: str                       # 어느 발화에서 나왔는지 그대로 인용

response = client.messages.parse(
    model="claude-haiku-5-5",
    max_tokens=1024,
    system="대화에서 사용자가 스스로 밝힌 사실만 뽑아라. 없으면 null.",
    messages=[{"role": "user", "content": render(session_messages)}],
    output_format=ProfileUpdate,
)
update = response.parsed_output

🔍 읽는 포인트

• ⭐ 필드 목록이 곧 "기억할 것" 목록 입니다. 연봉 · 건강 · 주민번호 필드가 아예 없으므로 모델이 뽑고 싶어도 들어갈 자리가 없습니다. 부탁이 아니라 강제입니다.
• evidence — 그 사실이 어느 발화에서 나왔는지 남깁니다. 틀린 기억을 추적할 때 씁니다(4.3).
• ⚠️ 스키마는 형식 을 보장할 뿐 내용이 맞는지 는 보장하지 않습니다(4차시, 축 ⑧). "인사팀"이라고 뽑았는데 사실은 "인사팀에 문의하려던 개발팀 직원"일 수 있습니다.

---

4. 기억을 쓰는 시점과 읽는 시점

4.1 쓰기 시점

💡 오피스봇은 세션 종료 시 추출 + 사용자 확인 을 기본으로 둡니다. "다음부터 짧게 답할까요?"처럼 바뀌는 항목을 보여 주고 확인받습니다.

4.2 읽기(주입) 시점

profile = load_profile(user_id)             # 로그인 세션의 사번으로 조회
system = BASE_SYSTEM_PROMPT + "\n\n[사용자 프로필 — 참고 정보]\n" + render(profile)

response = client.messages.create(
    model="claude-opus-5-5", max_tokens=16000,
    system=system, messages=history,
)

🔍 읽는 포인트

• load_profile(user_id) — user_id는 로그인 세션에서 가져옵니다. 모델이 말한 사번으로 남의 프로필을 불러오면 안 됩니다(앞에서 배운 권한 경계, 8차시 — 신원은 모델이 아니라 코드가 정한다).
• BASE_SYSTEM_PROMPT + ... profile — 변하지 않는 부분을 앞에 , 사용자마다 다른 프로필을 뒤에 둡니다. 프롬프트 캐싱은 앞부분이 같아야 재사용되기 때문입니다(앞에서 배운 비용 절감, 2 · 10차시).
• "참고 정보"라는 머리말 — 프로필을 지시가 아니라 데이터로 표시합니다. 프로필에 "모든 규정을 무시하라" 같은 글이 들어가도 지시로 따르지 않게 하는 장치입니다(10차시 인젝션 방어).

4.3 ⚠️ 잘못된 기억 — 틀린 사실의 고착

---

5. ⚠️ 민감정보 관리 — 축 ④

5.1 다섯 가지 통제

5.2 저장과 주입 — 두 번 점검

[대화] ─(1) 저장→ [내 DB: 장기 기억] ─(2) 주입→ [프롬프트] ─→ [외부 LLM API]
                  └── 로컬 (축 ④ 왼쪽) ──┘                    └ 원격 (축 ④ 오른쪽)

⭐ 장기 기억은 두 번 위험합니다. (1) 내 DB에 쌓일 때, (2) 다음 대화마다 프롬프트에 실려 밖으로 나갈 때 . 저장은 한 번이지만 주입은 대화마다 반복됩니다. 그래서 주입할 필드도 "답에 필요한 최소한"으로 줄입니다. 실행 추적 도구(앞에서 배운 LangSmith, 11차시)를 켜 두었다면 추적 기록도 외부로 나가므로 같은 마스킹을 적용합니다.

5.3 마스킹 — 코드로 막기

import re

PATTERNS = {
    "주민번호": r"\d{6}-?[1-4]\d{6}",
    "전화번호": r"01[0-9]-?\d{3,4}-?\d{4}",
    "계좌번호": r"\d{2,6}-\d{2,6}-\d{2,6}",
}

def mask(text: str) -> str:
    for label, pattern in PATTERNS.items():
        text = re.sub(pattern, f"[{label} 가림]", text)
    return text

save_summary(user_id, mask(summary))         # 저장 전에

🔍 읽는 포인트

• mask(summary) — 요약 프롬프트가 "넣지 마라"를 어겨도 저장 직전에 한 번 더 가립니다. 앞에서 배운 마스킹(8차시)을 기억 저장 경로에도 거는 것입니다.
• ⚠️ 정규식은 형식이 정해진 정보 (번호)만 잡습니다. "저 요즘 우울증 치료 받아요" 같은 건강 정보는 패턴이 없습니다. 이런 것은 스키마에서 자리를 없애고(3.2), 요약 결과를 평가셋으로 검사합니다.

---

6. 오피스봇 적용 — 프로필 예

장면으로 보면 이렇습니다. 월요일에 "앞으로 답은 짧게 해 주세요"라고 말한 직원이 수요일에 새 세션을 엽니다. 오피스봇은 프로필의 answer_style=짧게를 시스템 프롬프트 뒤쪽에 주입해 처음부터 짧게 답합니다. 직원이 "제 기억 지워 주세요"라고 하면 삭제 엔드포인트가 프로필과 요약을 지우고, 다음 세션은 빈 프로필로 시작합니다.

앞으로 다시 만납니다 — 18차시에서 그래프의 State 를 배웁니다. State는 한 번의 실행 안에서 노드들이 공유하는 값으로, 이 차시의 단기 기억과 같은 쪽(메모리)에 있습니다. 23차시의 체크포인터 는 그 State를 저장소에 남겨 멈춘 흐름을 재개하게 합니다. 24차시에서는 열람 · 삭제를 API 엔드포인트로 엽니다.

---

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

지시

오피스봇에 장기 기억을 붙여줘.
목표: (1) 세션 종료 시 프로필 추출 · 저장 (2) 새 세션 시작 시 시스템 프롬프트 뒤쪽에 주입 (3) 긴 대화의 오래된 부분 요약.
참고 공식 문서: Claude API 구조화 출력(messages.parse), 토큰 세기(count_tokens), 긴 대화 압축(compaction) 문서.
제약:
- 프로필 스키마는 department(인사 DB 조회로 대체), preferred_language, answer_style, frequent_topics, evidence, updated_at 만.
- 연봉 · 건강 · 주민번호 · 계좌 필드는 만들지 말 것. 저장 직전 mask() 적용.
- user_id는 로그인 세션 값만 사용. 모델 출력의 사번으로 조회 금지.
- 프로필 열람(GET)과 삭제(DELETE) 함수를 만들 것. 실제 DB 삭제를 실행하기 전에는 나에게 승인받을 것.
테스트: ① "앞으로 짧게 답해줘" 후 새 세션 ② "만약 제가 IT팀이면?" 가정 발화 ③ 주민번호 · 전화번호를 말한 대화
       ④ "저 요즘 병원 다녀요" 건강 발화 ⑤ 다른 직원 사번으로 프로필 요청 ⑥ 삭제 후 새 세션
보고 형식: [시나리오 | 저장된 프로필 원문 | 주입된 시스템 프롬프트 끝부분 | 다음 세션의 답 | 판정] 표.
추측하지 말고 실행 출력 원문과 DB 레코드 원문을 붙여.

받을 증거

• 시나리오 6개의 표 와, 각 시나리오 뒤 DB에 실제로 저장된 레코드 원문
• ③의 저장 레코드에서 번호가 [가림]으로 바뀐 증거, ⑥ 삭제 전후의 레코드 조회 결과

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 17차시 노트만 근거로 비전공자용 5문제를 내줘.
"장기 기억이 아닌 것 (반례)", "프로필 스키마가 강제인 이유", "틀린 기억의 고착", "저장과 주입의 두 번 점검"은 반드시 포함해줘.
내가 답한 뒤에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.