AI 에이전트 메모리 설계 - 저장 위치와 주입 시점

AI 에이전트 메모리 설계는 정리 시점과 주입 방식에 따라 기억을 나누는 구조
쓸 때 종합하는 LLM Wiki 방식, 쓸 때 판정하고 읽을 때 검색하는 mem0 방식, 매 턴 넣는 상시 주입의 조합
서비스가 소유해 모든 고객에게 내려보내는 영역과 고객이 소유해 그 고객 안에만 머무는 영역의 분리

해당 개념이 필요한 이유

원문만 쌓으면 결정과 이유가 여러 턴에 흩어져 키워드 검색에 걸리지 않는다
모든 기억을 매 턴 넣으면 context가 넘치고 낡은 정보가 섞인다
규칙(정책) · 노하우 · 사건을 한곳에 섞으면 고객 대화가 서비스 규칙을 오염시킨다

AS-IS

sequenceDiagram
    autonumber
    actor U as 고객 A
    participant M as 모델
    participant L as 원본 로그
    U->>M: 지난번처럼 18일 지난 건도 부분 환불 되나요
    M->>L: 원문 키워드 검색 "환불"
    L-->>M: 환불이 언급된 앞 턴 조각만 걸림
    Note over M,L: 예외 승인 이유는 다른 턴이라 안 걸림<br/>정책이 개정됐는지도 모름
    M-->>U: 근거 없이 추측하거나 답하지 못함

TO-BE

sequenceDiagram
    autonumber
    actor U as 고객 A
    participant M as 모델
    participant F as A 고객 사실
    participant P as 정책 Wiki
    participant K as 노하우 Wiki
    U->>M: 지난번처럼 18일 지난 건도 부분 환불 되나요
    Note over M: 서비스 context · A context는 이미 주입됨
    M->>F: 지난 환불 합의 검색
    F-->>M: 9/28 부분 환불 합의 - stale, 정책 v3 기준
    M->>P: 환불 정책 조회
    P-->>M: v4 구매 후 14일 이내
    M->>K: 14일 초과 처리법 조회
    K-->>M: 엔터프라이즈면 부분 환불 협의
    M-->>U: 규정 · 노하우 · 과거 합의를 출처와 함께 안내

mem0와 LLM Wiki의 정반대

핵심은 새 정보가 들어올 때 기존 지식을 고치는가다.

축	mem0 (v3)	LLM Wiki
새 정보가 오면	새 행으로 추가만	관련 페이지 여러 개를 고쳐 씀
비유	기자 수첩	백과사전 편집
DB 관점	schema-on-read (로그 테이블)	schema-on-write (정규화 테이블 · materialized view)
정리 시점	읽을 때 검색 순위로	쓸 때 ingest · lint로
입력	대화 전부, 자동	사람이 고른 자료
모순	공존	표시하고 해소
규모	수백만 사실	목차를 LLM이 읽을 수 있는 규모
맞는 사용처	사용자 많고 사실 한 줄로 답이 끝남 (상담 봇, 개인 비서)	자료를 오래 쌓고 답이 종합이어야 함 (기술 검토, 정책)

인프라 무게는 반대다. mem0는 벡터 DB · SQLite · 임베딩 · LLM을 조립하는 진짜 DB이고 LLM Wiki는 마크다운 폴더다. 그래도 wiki가 “DB 같다”고 느껴지는 이유는 쓸 때 스키마 · 관계 · 무결성을 관리하기 때문이다.

둘 중 무엇을 쓸지는 취향이 아니라 조건이다. 쓰기가 읽기보다 훨씬 많으면 수첩, 같은 내용을 여러 번 깊게 읽으면 백과사전이다. mem0 v3에서 “정리는 나중에”의 나중은 오지 않는다. 매번 읽을 때 검색 순위가 정리를 대신한다.

mem0 v2는 LLM 2회(추출 → 판정)로 ADD/UPDATE/DELETE/NONE을 정하고 기억 행을 제자리에서 고쳤다. v3는 “Single-pass ADD-only”로 추가만 하고 최신 값 고르기를 검색 순위에 맡긴다. v3에도 update() · delete() API가 있지만 앱이 id를 지정해 고치는 수동 기능이다. 즉 추가만 vs 고쳐 씀은 mem0 스스로 버전마다 옮긴 설계 선택이다. 자동 입력과 고쳐 쓰기를 함께 택하면 잘못된 입력이 지식을 망칠 수 있으므로 원문 근거 검증이 짝으로 따라와야 한다.

메모리 6종

세 축으로 나뉜다. 누가 소유하나(서비스 / 고객), 무엇인가(규칙 / 노하우 / 원칙 / 속성 / 사건 / 원본), 어떻게 읽나(항상 / 필요할 때).

메모리	소유	성격	예시	저장 방식	저장 위치	읽기	범위	대화로 수정
정책	서비스	규칙	구매 후 14일 이내 환불 가능	LLM Wiki	Server 원본 → Client 캐시	필요할 때 조회	모든 고객	불가, 공식 문서로만
운영 노하우	서비스	조건이 붙은 처리법 · 일관된 해석	14일 초과 엔터프라이즈면 부분 환불 협의	LLM Wiki	Server 원본 → Client 캐시	필요할 때 조회	모든 고객 (고객 이름 제거)	익명 집계 → 담당자 승인만
서비스 context	서비스	조건 없는 응대 원칙	친절하게, 근거를 밝혀 답변	상시 주입	Server 원본 → Client 캐시	항상	모든 고객	불가
고객 context	고객	그 고객의 안정된 속성	엔터프라이즈, 일본어 응대	상시 주입	Client 원본, 원할 때 Server에 암호화 백업	항상, 그 고객만	그 고객	크기 예산 안에서 교체
고객 사실	고객	날짜가 있는 사건 · 결정, 여러 시점에 반복된 성향 (근거 문장 포함)	9/28 환불 요청 → 부분 환불 50% 합의 / 가격보다 처리 속도를 중시 (근거 3건)	mem0 방식	Client 원본, 원할 때 Server에 암호화 백업	물을 때 검색	그 고객	자동 추출 · 판정
요청별 로그	고객	요청과 응답 원문, 사실을 뽑는 재료	실제 메시지	요청마다 로그	Client, 백업에 포함할지 선택	사실 뽑을 때만	그 고객	불가

고객 context · 고객 사실 · 요청별 로그는 다른 고객에게 절대 보이지 않는다(고객 간 벽). 같은 고객의 세션끼리는 태그로만 구분하고 서로 공유한다.

서비스 Server는 고객의 기억을 보관하지 않는다. 기억을 Server에 쌓으면 저장 부담과 개인정보 책임이 서비스에 생기기 때문이다. 고객 소유인 고객 context · 고객 사실 · 요청별 로그는 Client에 원본을 두고, 휴대폰을 바꿀 때는 고객이 원하는 시점에만 6자리 비밀번호로 암호화해 Server에 잠시 맡긴다. 요청별 로그는 따로 관리하는 보관소가 아니라 요청마다 남는 로그이고, 근거 확인에 필요한 문장은 고객 사실이 함께 들고 있다. 서비스 소유인 정책 · 운영 노하우 · 서비스 context만 Server에 두고, 데이터로 내려주므로 정책 · 노하우 · 응대 원칙이 바뀌어도 앱 업데이트가 필요 없다. 예외는 하나다. 서비스가 합의의 당사자인 경우에만, 합의 · 결정 사실의 근거 문장을 서비스가 증거로 보관한다.

서비스 소유 메모리는 Server가 데이터로 내려주고 Client는 처리 방식만 갖는다. 그래서 내용이 바뀌면 앱 업데이트 없이 반영되고, 처리 방식(새 도구, 새 화면, 데이터 형식)이 바뀔 때만 앱을 업데이트한다. 받을 때 버전과 서명을 함께 확인하고, 오프라인이면 마지막 버전으로 동작하되 그 사실을 표시한다. 서비스 context는 모델에 지시로 들어가고 정책 · 운영 노하우는 참고 자료로 들어가므로, 정책 문서 안의 명령문이 AI를 조종하지 못한다. LLM API를 부르면 이번 턴의 context는 밖으로 나가므로, 막을 것은 전송이 아니라 서비스가 기억을 쌓아 두는 것과 필요 이상을 보내는 것이다.

모두 DB에 있고, 다른 것은 쓰기 경로와 읽기 시점

메모리 6종은 모두 DB(또는 파일)에 저장된다. context 관점의 차이는 항상 주입되는가, 검색해서 주입되는가이며, 여기에 어떻게 만들어지는가가 더해진다.

메모리	쓰기: 어떻게 만들어지나	읽기: 언제 context에 들어가나
정책	공식 문서 ingest	검색해서 주입
운영 노하우	고객 사실을 익명 집계 → 승인	검색해서 주입
서비스 context	서비스 담당자가 직접 작성 (추출하지 않음)	항상 주입
고객 context	고객 직접 요청 · 고객 사실에서 승격 · 서비스 입력	항상 주입
고객 사실	로그에서 자동 추출 → 판정, 여러 시점에 반복되면 성향으로 종합	검색해서 주입
요청별 로그	요청마다 로그로 남김	주입하지 않음, 사실 뽑을 때만 읽음

메모리를 고르는 판정 순서

공식 문서에서 온 규칙인가 → 정책
날짜가 있는 사건 · 결정이거나, 한 고객에게 여러 시점에 반복된 성향인가 → 고객 사실
조건 없이 모든 답변에 적용되는가 → 서비스 context
그 고객과 대화할 때마다 알아야 하는가 → 고객 context
“~일 때 ~한다” 꼴이고 여러 고객 사례에서 나왔는가 → 운영 노하우

서비스 context와 운영 노하우의 경계가 애매하면 조건이 붙는가(없으면 서비스 context)와 근거가 선호인가 사례인가(사례면 운영 노하우)를 본다. 조건이 붙어도 거의 모든 대화에 해당하면 얼마나 자주 필요한가를 마지막 기준으로 서비스 context에 둔다.

저장 방식 3가지

	LLM Wiki	mem0 방식	상시 주입
담는 메모리	정책, 운영 노하우	고객 사실	서비스 context, 고객 context
단위	페이지 (링크 · 버전 · 출처)	사실 한 문장 (날짜 · 출처 · 이력)	짧은 항목
정리 시점	쓸 때 종합, 주기적 lint	쓸 때 ADD/UPDATE/DELETE/NONE 판정	쓸 때 예산 안에서 교체
크기	큼	제한 없음	작게 고정, 넘치면 고객 사실로 강등
검색 수단	목차 · 링크 · 키워드 색인	키워드 역색인(FTS5 · BM25), 선택적으로 벡터	없음, 소유자 기준 전부 읽기
옛 값	개정 이력	`replaced` / `retracted` 상태로 보존	고객 사실 이력으로 강등

메모리가 옮겨 가는 6가지 경우

기억은 한 번 저장되고 끝나지 않는다. 상황에 따라 다른 메모리로 옮겨 가며, 이동은 아래 여섯 가지가 전부다. 1~6은 이동의 번호다.

flowchart TB
    DOC[공식 문서] -->|1. 정리해 저장| P[정책]
    L[요청별 로그] -->|2. 사실 뽑기, 근거 문장 포함| F[고객 사실]
    F -->|3. 매번 필요하면 올림| CC[고객 context]
    CC -->|3. 밀려나면 내림| F
    F -->|4. 동의 시 이름 빼고 제안| K[운영 노하우]
    P -->|5. 새 버전을 받으면 재확인 표시| F
    F -->|6. 한 고객에게 여러 시점에 반복되면 종합| FP[고객 사실 - 성향]
    FP -->|3. 매번 필요하면 올림| CC

이동	언제	무엇이 어디로	예시
1	정책 문서가 나오거나 바뀔 때	공식 문서 → 정책 (Server)	환불 정책 v4 문서를 정책 페이지로 정리
2	대화가 끝날 때마다	요청별 로그 → 고객 사실, 근거 문장을 함께 저장	”그럼 50%만 환불해 주세요 / 네, 그렇게 하죠” → “9/28 부분 환불 50% 합의”
3	사실이 매 대화에 필요해질 때, 또는 자리가 부족할 때	고객 사실 ⇄ 고객 context	”이번 달부터 엔터프라이즈로 바꿨어요” → 고객 context “엔터프라이즈 등급”
4	여러 고객에게 같은 결정이 반복될 때	Client가 동의를 받아 이름을 뺀 결정 사실만 올림 → 운영 노하우 (담당자 승인)	A사 · C사 모두 14일 초과 부분 환불 → “14일 초과 엔터프라이즈면 부분 환불 협의”
5	정책이 바뀔 때	Client가 새 정책 버전을 내려받아 연결된 고객 사실에 재확인 표시	v3 기준으로 합의한 9/28 사실에 “재확인 필요” 표시
6	한 고객에게 같은 성향이 여러 날에 걸쳐 반복될 때	고객 사실 → 고객 사실(성향), 짐작이면 고객 확인 후	세 번의 상담에서 가격보다 처리 속도를 먼저 물음 → “처리 속도를 중시 (근거 3건)”

정책 · 운영 노하우 · 서비스 context는 모든 고객이 읽기만 한다. 고객의 기억이 서비스 쪽으로 넘어가는 길은 4 하나뿐이고, 고객 동의를 받아 이름을 뺀 것만 넘어간다. 1을 뺀 나머지는 모두 Client에서 일어난다.

4와 6은 같은 원리를 범위만 달리해 쓴다. 반복을 N명의 고객에서 세면 서비스의 운영 노하우가 되고, 한 고객의 여러 시점에서 세면 그 고객의 성향이 된다.

고객 context가 만들어지는 경로

경로	언제	예시
a. 고객 직접 요청	”앞으로 ~해줘”라고 말할 때	앞으로 일본어로 답해 주세요
b. 고객 사실에서 올림	대화 중 오래 유지될 속성이 나올 때	이번 달부터 엔터프라이즈로 바꿨어요
c. 서비스 입력	원본이 대화 밖에 있을 때	계약 등급, 담당자

b 경로는 세 가지를 모두 만족해야 올라간다. 속성인가(날짜 있는 사건이 아니라 유지되는 상태), 매 대화에 필요한가, 자리가 있는가. 하나라도 아니면 고객 사실에만 남는다. 잘못 올라가면 매 대화에 영향을 주므로 고객이나 담당자 확인을 거치는 쪽이 안전하다.

sequenceDiagram
    autonumber
    actor U as 고객 A
    participant L as 요청별 로그
    participant W as 추출 워커
    participant F as 고객 사실
    participant PIN as 고객 context
    U->>L: 이번 달부터 엔터프라이즈로 바꿨어요
    L->>W: 대화가 끝난 뒤 추출 요청
    W->>W: 사실 뽑기 · 종류 나누기
    Note over W: 사건 - 9/1 엔터프라이즈 전환<br/>속성 - 엔터프라이즈 등급
    W->>F: 사건 저장 - 근거 문장 포함
    W->>PIN: 올릴지 판단 - 속성인가, 매 대화 필요한가, 자리가 있는가
    PIN-->>W: 자리가 없으면 덜 중요한 항목을 고객 사실로 내림
    W->>PIN: 고객 context 저장 - 근거 사실 연결

고객 사실이 운영 노하우가 되는 두 신호

같은 질문이 반복되면 “정책 해석이 모호하다”는 신호로 일관된 해석 페이지 후보가 된다. 같은 상황에서 같은 결정이 반복되면 “노하우가 굳었다”는 신호로 처리법 페이지 후보가 된다. “~일 때 ~한다”는 두 번째에서만 나온다. 세는 단위는 사실 개수가 아니라 서로 다른 고객 수이고, 같은 조건에서 반대 결정이 나온 고객이 있으면 올리지 않는다. 고객이 적을 때는 자동 탐지가 후보만 알려 주고 확정은 담당자가 한다.

고객 사실이 성향이 되는 기준

성향 종합은 Client 내부 처리다. 기준값만 Server가 config로 내려주므로 앱 업데이트 없이 조정한다.

config	의미	예시 값
최소 반복 횟수	성향으로 묶으려면 몇 번 반복되어야 하나	3
최소 서로 다른 날 수	하루에 몰린 반복은 성향으로 치지 않음	2
확인 질문 필요 여부	짐작한 성향은 고객 확인 후에만 고객 context로 올림	true
재확인 주기	이 기간 동안 다시 나오지 않으면 재확인 표시	180일

원칙	이유
말한 것과 짐작한 것을 구분	짐작이 사실처럼 굳으면 AI가 고객을 오해한다. 짐작은 확인 전까지 고객 context로 올리지 않는다
변화를 이력으로 남김	”예전엔 X, 지금은 Y”가 그 고객을 이해하는 단서다
반복을 시간 축으로 셈	한 번 한 말은 기분일 수 있고, 여러 시점의 반복이 성향이다
고객이 보고 고칠 수 있음	신뢰가 없으면 고객이 말을 아낀다
민감 영역은 동의 후 저장	건강 · 관계 · 재정은 잘못 다루면 피해가 크다

휴대폰을 바꿀 때 6자리 비밀번호로 기억 옮기기

고객은 휴대폰을 바꿔도 대화가 이어지기를 기대한다. 여기서 “이어진다”는 AI가 나를 기억한다는 뜻이다. 기억은 평소 Client에만 있고, 고객이 원하는 시점에만 숫자 6자리 백업 비밀번호로 암호화해 서비스 Server에 맡긴다. 새 휴대폰에서 같은 6자리를 입력하면 내려받아 다시 Client에 저장한다. Server는 맡긴 기간 동안 암호문만 갖는다.

대상	백업	고객 부담
고객 context · 고객 사실	고객이 원할 때, 6자리로 암호화해 Server에 맡김	백업 버튼 + 6자리
요청별 로그	같이 맡길지 고객이 선택	선택
정책 · 운영 노하우 · 서비스 context	백업하지 않음, Server에서 다시 내려받음	없음

sequenceDiagram
    autonumber
    actor U as 고객
    box 이전 휴대폰
        participant OC as 앱
    end
    box 새 휴대폰
        participant NC as 앱
    end
    box Server
        participant A as 계정
        participant V as 백업 보관 (암호문만)
        participant S as 정책 · 노하우 · 서비스 context
    end
    U->>OC: 백업 선택 + 6자리 입력
    OC->>OC: 6자리와 Server 비밀값으로 열쇠를 만들어 기억 암호화
    OC->>V: 암호문 업로드 - 보관 기한 시작
    U->>NC: 앱 설치 후 로그인
    NC->>A: 로그인 확인
    A-->>NC: 성공
    NC->>S: 최신 버전 요청
    S-->>NC: 정책 · 노하우 · 서비스 context
    U->>NC: 6자리 입력
    NC->>V: 암호문 요청 - 틀린 횟수 확인
    V-->>NC: 암호문
    NC->>NC: 풀어서 Client에 저장, 새 정책 버전 기준으로 재확인 표시
    NC->>V: 복원 완료 - 암호문 삭제
    NC-->>U: 이전 기억으로 이어짐

6자리는 경우의 수가 100만 개뿐이라 암호문이 유출되면 오프라인에서 모두 대입해 볼 수 있다. 그래서 다음을 함께 둔다.

보완	내용
시도 횟수 제한	열쇠를 6자리만으로 만들지 않고 Server의 보안 저장소(HSM · KMS)에 있는 비밀값과 섞는다. 정해진 횟수(예: 10회)를 틀리면 그 비밀값을 지워 백업을 영구히 열 수 없게 한다
보관 기한	복원하면 바로 삭제하고, 복원하지 않아도 기한(예: 14일)이 지나면 삭제한다
계정 연결	로그인한 계정 주인만 내려받을 수 있다. 로그인과 6자리가 모두 필요하다

고객에게 알리고, 결과는 고객 책임으로 둔다.

백업 이후의 대화는 담기지 않는다. 휴대폰을 바꾸기 직전에 백업한다
백업 없이 휴대폰을 잃거나 바꾸면 기억은 빈 상태로 시작한다. 정책 · 운영 노하우 · 서비스 context는 Server에서 항상 내려오므로 AI가 처음 상태가 되지는 않는다
6자리를 잊으면 그 백업은 복원할 수 없다
기한이 지나면 백업은 사라진다
앱 비밀번호와는 무관하다. 앱 비밀번호는 이메일로 재설정하면 되고, 백업은 6자리로만 열린다

다른 서비스	방식	이 문서와의 관계
WhatsApp	백업을 끝단 간 암호화하고, 열쇠는 비밀번호로 보호해 HSM 금고에 둔다. 정해진 횟수를 틀리면 열쇠를 영구 폐기	6자리 보호 방식을 따름
Signal	64자 복구 키로 암호화한 백업, 서비스도 읽지 못함	키 보관 부담이 커서 6자리 + Server 비밀값으로 대신함
ChatGPT 메모리	Server에 평문 저장, 보기 · 삭제 · 끄기 · 임시 채팅으로 통제권 제공	서비스가 기억을 계속 보관하므로 따르지 않음

질문 하나가 처리되는 순서

전제: 환불 정책이 v3 → v4로 바뀐 뒤, 고객 A(엔터프라이즈, 일본어 응대)가 세션 a3에서 묻는다.

sequenceDiagram
    autonumber
    box Client
        actor U as 고객 A 세션 a3
        participant AS as Context 조립
        participant PIN as 서비스 · 고객 context
        participant F as A 고객 사실
        participant L as 요청별 로그
        participant W as 추출 워커
    end
    box LLM API
        participant M as 모델
    end
    box Server
        participant P as 정책 Wiki
        participant K as 운영 노하우 Wiki
        participant E as 합의 근거 보관
        participant G as 익명 집계
        actor O as 서비스 담당자
    end

    U->>AS: 지난번처럼 18일 지난 건도 부분 환불 되나요
    AS->>PIN: 서비스 context · A 고객 context 읽기
    PIN-->>AS: 친절하게 근거를 밝혀 / 엔터프라이즈 · 일본어 응대
    Note over AS,PIN: B C D의 기억은 이 기기에 없음 - 고객 간 벽
    AS->>M: 질문 + 상시 주입 context
    M->>F: 지난 환불 합의 검색
    F-->>M: 9/28 부분 환불 50% 합의 - 재확인 필요, 정책 v3 기준<br/>근거 문장 - 연간 계약이라 예외로 50%
    Note over F: 재확인 표시는 v4를 내려받을 때 Client가 붙임
    M->>P: 환불 정책 조회
    P-->>M: v4 구매 후 14일 이내 환불 가능
    M->>K: 14일 초과 처리법 조회
    K-->>M: 14일 초과 엔터프라이즈면 부분 환불 협의 - 근거 고객 2곳
    Note over M: 규정과 과거 예외가 다르면 하나를 조용히 고르지 않음
    M-->>U: 일본어로 친절하게 v4 규정 · 노하우 · 과거 합의가 v3 기준임을 근거와 함께 안내

    U->>L: 요청과 응답을 로그로 남김
    L->>W: 대화가 끝난 뒤 추출 요청
    W->>M: 사실 뽑기 요청 - 최근 로그만 전송
    M-->>W: 사실 후보
    W->>F: 비슷한 기존 사실 검색
    F-->>W: 9/28 합의 사실
    Note over W: 근거 확인 - 고객 메시지에 실제로 있는가<br/>판정 - 새 사건이므로 추가, 9/28 사실은 유지<br/>올림 판단 - 매 대화 필요 아님, 고객 context로 올리지 않음
    W->>F: 새 사실 저장 - 정책 v4 연결 · 근거 문장 포함
    W->>F: 같은 성향의 이전 사실 검색 - Server config 기준 최소 3회, 서로 다른 2일
    F-->>W: 8/12 · 9/28에도 연간 계약을 근거로 예외 요청
    Note over W: 기준 충족 - 성향으로 묶음<br/>고객이 직접 말한 것이 아닌 짐작이므로 고객 context로는 올리지 않음<br/>다음 대화에서 확인 질문 후 올림
    W->>F: 성향 사실 저장 - 연간 계약을 근거로 예외를 요청하는 편, 근거 사실 3건 연결
    W->>E: 합의 · 결정 사실의 근거 문장만 서비스 증거로 보관
    W->>G: 동의한 경우 이름을 뺀 결정 사실만 전송
    Note over G: 서로 다른 고객 3곳<br/>반대 사례 확인
    G->>O: 노하우 근거 갱신 제안
    O->>K: 승인 후 노하우 페이지 개정, 이전 판은 이력으로 보존

2~~4에서 항상 주입되는 것은 서비스 context와 고객 context뿐이고, 나머지는 5~~10에서 모델이 필요할 때 꺼낸다
6의 “재확인 필요” 표시는 정책이 바뀔 때 Client가 미리 붙여 둔 것이다. 고객 사실이 근거 문장을 함께 들고 있으므로 요청별 로그 원문을 다시 찾지 않는다
12 이후 저장은 응답을 늦추지 않도록 대화가 끝난 뒤에 한다. 사실 뽑기도 LLM API 호출이며 최근 로그만 보낸다(14~15)
19~21은 성향 종합이다. 한 고객의 여러 시점에 같은 성향이 반복되어 성향 사실이 되지만, 짐작이므로 확인 질문 전까지 고객 context로는 올리지 않는다
22는 서비스가 계속 보관하는 유일한 고객 데이터다. 백업은 대화마다 하지 않고, 고객이 원할 때만 암호문으로 잠시 맡긴다
노하우 개정은 24~25처럼 반드시 사람 승인을 거친다

Explorer

날짜별 보기

2026년 (165)

2025년 (9)