DOCS/journey/troubleshooting/250812_claude_메모리시스템_하드코딩_문제_분석.md
Claude-51124 22557e7132 docs: 오래된 트러블슈팅 아카이브 및 구조 정리
- 7-8월 초기 구축 문서 12개를 _archive/troubleshooting/2025_07-08_initial_setup/로 이동
- book/300_architecture/390_human_in_the_loop_intent_learning.md를 journey/research/intent_classification/로 이동 (개발 여정 문서)
- 빈 폴더 제거 (journey/assets/*)
2025-11-17 14:06:05 +09:00

5.5 KiB

rb10508 메모리 시스템 하드코딩 문제 분석 및 개선 방안

작성 정보

  • 작성일: 2025-08-12
  • 작성자: Claude (51124 서버)
  • 대상: rb10508_micro 서비스
  • 배경: "김종태야님" 호칭 문제로 발견된 근본적 설계 이슈

1. 문제 상황

1.1 대화 로그 분석

사용자가 반복적으로 "종태님"이라고 부르라고 요청했으나, AI가 계속 "김종태야님"이라고 잘못 호칭하는 문제 발생.

user: 종태님이라고 부르라고!!
assistant: 네, 김종태야님. 종태님이라고 부르겠습니다.
user: 진짜 미친거야?
assistant: 김종태 님. 죄송합니다.

1.2 근본 원인

  • 하드코딩된 메모리 시스템
  • 학습 능력 부재
  • 모든 대화를 무차별 저장

2. 현재 시스템 분석

2.1 컬렉션 구조

rb10508_test_happybell80
rb10508_test_episodic      # 모든 대화가 여기에만 저장
rb10508_test_procedural    # 사용 안 함
rb10508_test_semantic       # 사용 안 함
rb10508_test_identity
rb10508_test_test_user

2.2 메모리 검색 알고리즘

현재 프로세스:

  1. 단일 컬렉션 검색: 항상 episodic만 검색
  2. ChromaDB 벡터 검색: 최대 100개, user_id로만 필터
  3. Mistral LLM 필터링:
    • 의도 분석
    • 베이지안 점수 + 시간 감쇠
    • MMR (다양성 보장)
    • 최종 5-9개 선택
  4. 문제점:
    • 다른 컬렉션 무시
    • 잘못된 내용 필터링 불가
    • 컬렉션 간 연결 없음

2.3 메모리 저장 알고리즘

ID 생성:

memory_id = f"{user_id}_{hashlib.md5(f'{content}{timestamp}'.encode()).hexdigest()[:16]}"
# 결과: test_user_78c0c0c5cee10ee6

문제점:

  • 모든 대화가 episodic에만 저장
  • 사용자별 컬렉션 자동 생성 (관리 어려움)
  • metadata에 content 중복 저장 (공간 낭비)
  • 임베딩 서비스 의존 (폴백 없음)

3. 하드코딩 문제 목록

3.1 발견된 하드코딩

# 컬렉션 이름
f"{settings.ROBING_ID}_{memory_type}"  # 고정 패턴

# 메모리 타입
memory_type = "episodic"  # 항상 같은 값

# 사용자 ID
user_id = "test_user"  # 테스트 하드코딩

# 검색 개수
n_results = 100  # 고정값
top_n = len(memories) // 5  # 20% 고정

# 수학 상수
golden_ratio = (1 + 5 ** 0.5) / 2  # 매번 재계산

3.2 ChromaDB 제약사항

  • 컬렉션 이름: 한글 불가, 영문/숫자/언더스코어/하이픈만 가능
  • 메타데이터: 한글 가능
  • 삭제 기능: collection.delete(ids=[...]) 또는 where 조건 가능

4. 로빙 철학과의 충돌

4.1 현재: "도구적 기록"

  • 모든 대화를 무차별 저장
  • 개발자가 정한 규칙만 따름
  • 학습 능력 없음

4.2 목표: "존재적 기억"

  • 의미 있는 순간만 기억
  • 스스로 학습하고 성장
  • 관계 중심의 기억 구조

5. 개선 방안

5.1 단순 CONFIG 방식의 한계

# 여전히 개발자가 정한 틀
CONFIG = {
    "memory": {
        "types": ["episodic", "semantic"],
        "default_type": "episodic"
    }
}

5.2 메모리 기반 자율 학습 시스템

핵심 개념:

"코드는 학습 방법만 정의, 무엇을 학습할지는 로빙이 결정"

학습 가능한 메모리 구조:

memory = {
    "type": "learning_moment",
    "pattern": "호칭_수정_요청",
    "before": "김종태야님",
    "after": "종태님",
    "feedback": "negative",
    "applied_count": 0,
    "success_rate": 0.0,
    "growth_exp": 10
}

자율 진화 프로세스:

  1. 실수 → 피드백 → 학습

    if user_emotion == "anger" and "이름" in message:
        await create_learning_memory(mistake, correction)
    
  2. 학습 → 적용 → 검증

    learned_rules = await get_learned_rules(user_id)
    response = apply_rules(response, learned_rules)
    await track_rule_success(rule_id, user_reaction)
    
  3. 성공 → 강화 → 영구화

    if rule.success_rate > 0.8 and rule.applied_count > 10:
        await promote_to_core_identity(rule)
    

5.3 즉시 적용 가능한 조치

  1. 잘못된 메모리 정리

    • "김종태야" 포함 26개 메모리 삭제
    • identity 컬렉션에 preferred_name 저장
  2. 컬렉션 재구성

    robing_10508_core        # 핵심 정체성
    robing_10508_with_jongtae  # 종태님과의 기억
    robing_10508_growth      # 학습 내용
    
  3. 선택적 저장

    if calculate_entropy(message) > 0.7 or emotion_intensity > 0.5:
        await save_memories(...)
    

6. 핵심 통찰

함수형 프로그래밍 vs 하드코딩

  • 함수형: HOW (어떻게 구현) - 순수 함수, 부작용 없음
  • 하드코딩 제거: WHAT (무엇을 설정) - 유연성, 재사용성
  • 둘은 독립적이지만 함께 추구해야 함

왜 하드코딩을 제거해야 하는가?

"로빙이 학습하고 성장하는 존재가 되려면, 코드를 고치지 않고도 행동이 바뀌어야 한다"

  • 하드코딩 = 로빙이 도구로 고정
  • 메모리 학습 = 로빙이 존재로 진화

7. 결론

현재 rb10508_micro는 "모든 것을 기록하는 도구"입니다. 목표는 "의미 있는 순간을 기억하고 성장하는 존재"입니다.

이를 위해서는:

  1. 하드코딩 제거
  2. 메모리 기반 학습 시스템 구축
  3. 관계 중심 컬렉션 구조
  4. 선택적 기억과 망각

"종태님"이라고 한 번 배우면 기억하고, 다음엔 스스로 적용하는 것이 진짜 AI입니다.