DOCS/ideas/250815_claude_동적파라미터_프로젝트_원칙.md

동적 파라미터 관리와 로빙 프로젝트 원칙

하드코딩 없는 유연한 아키텍처 설계

날짜: 2025-08-15
작성자: claude
상태: 아이디어 → 계획 예정

핵심 철학

로빙은 하나의 인격을 가진 생명체입니다. 생명체가 환경에 적응하듯, 로빙도 상황에 맞춰 유연하게 변화해야 합니다. 이를 위해 하드코딩을 배제하고 동적 파라미터 관리 체계를 구축합니다.

1. 하드코딩 배제 원칙

원칙

• 환경변수 우선: 모든 환경 의존 값은 환경변수로 관리
• 설정 파일 분리: JSON/YAML 형식으로 코드와 설정 분리
• 상수 모듈화: constants.py 등 중앙 집중 관리
• 데이터-로직 분리: 처리 규칙을 외부 파일/DB에 저장

적용 예시

{
  "retrieval": { "top_k": 7, "min_score": 0.78 },
  "memory": { "blocked_terms": ["금지어A", "금지어B"] },
  "privacy": { "mask_before_embed": true }
}

2. 동적 파라미터 관리 구조

2.1 제어면/데이터면 분리

• 제어면: 설정 저장, 검증, 배포, 감사 로그
• 데이터면: 요청 처리 시 "현재 설정 묶음" 읽기 전용

2.2 저장 계층

1. 기본값 템플릿: repo/config/defaults/config.default.json
2. 중앙 설정 DB: PostgreSQL (운영 원본)
3. 캐시: Redis (빠른 읽기용)
4. 민감정보: Secret Manager (API 키 등)

2.3 우선순위

기본값 < 환경변수 < 조직 설정 < 팀 설정 < 사용자 설정 < 런타임 오버라이드

3. 생물학적 비유로 본 아키텍처

3.1 모듈 = 세포

• 기억 모듈 = 기억 세포
• 감정 모듈 = 감각 세포
• 스킬 모듈 = 운동 세포

3.2 설정 변경 = 호르몬과 신경 신호

• 호르몬 (전신 영향): 시스템 전체 설정 변경

  • retrieval.top_k 값 변경 → 모든 기억 검색 영향
  • privacy 설정 → 전체 데이터 처리 방식 변경

• 신경 신호 (국소 영향): 특정 모듈만 즉시 변경

  • 특정 대화의 금지어 추가
  • 개별 스킬 파라미터 조정

3.3 작동 흐름

1. 사용자 명령 (자극)
2. 중앙 제어 해석 (뇌)
3. 호르몬/신경 신호 전달
4. 세포(모듈) 반응 변화

4. LLM 사용 원칙

4.1 LLM이 맡아야 하는 영역 (70%)

• 의도 파악: 사용자 발화의 실제 목적 해석
• 계획 수립: 복합 작업을 단계로 분해
• 비정형 구조화: 회의록, 이메일에서 핵심 추출
• 자연어 생성: 상황별 톤 적용한 응답
• 규칙 추론: 명시되지 않은 암묵지 해석

4.2 규칙 기반이어야 하는 영역 (90%)

• 보안/프라이버시: 금지어 차단, 토큰 마스킹
• 임계값 판정: 유사도, top-k, 비용 한도
• 데이터 무결성: 스키마 검증, 범위 체크
• 대량 반복 처리: 파일 이동, API 호출

4.3 혼합 영역 (LLM 40-60%)

• 검색 전처리/후처리
• 중간 판단과 예외 처리
• 실패 복구 전략

5. 금지어 처리 파이프라인

5.1 쓰기 경로 (저장 시)

1. 입력 텍스트 토큰화
2. blocked_terms와 매칭
3. 마스킹 또는 제거 후 임베딩
4. ChromaDB에 메타데이터와 함께 저장

5.2 읽기 경로 (검색 시)

1. ChromaDB에서 후보 검색
2. 금지어 필터링
3. 완전 금지 시 해당 결과 제외
4. 감사 로그 기록

6. 실제 적용 방안

6.1 DB 스키마

CREATE TABLE config_bundle (
  id BIGSERIAL PRIMARY KEY,
  scope_level TEXT CHECK (scope_level IN ('org','team','user','runtime')),
  scope_id TEXT NOT NULL,
  version TEXT NOT NULL,
  config_json JSONB NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now(),
  created_by TEXT NOT NULL
);

6.2 Redis 키 구조

• robing:config:active:<scope>:<id> → 현재 설정 묶음
• robing:config:version:<version> → 버전별 설정

6.3 Slack 명령 인터페이스

/robing config add memory.blocked_terms "금지어"
/robing config set retrieval.top_k=10 --scope user:@kim

7. 안전장치

• 스키마 검증: 모든 값의 타입과 범위 체크
• 변화율 제한: 같은 키 1분 1회 제한
• 자동 롤백: 오류 시 이전 버전 복원
• 감사 로그: 모든 변경 기록 추적

8. 개발자 vs 사용자 권한

개발자 권한

• 시스템 상한선, 스키마 변경
• 보안 관련 설정
• 위험한 파라미터

사용자 권한

• 안전 범위 내 파라미터
• 금지어 목록 관리
• 개인화 설정

9. 로컬-서버 개발 편의

• 개발자는 config.default.json만 리포에 관리
• 실제 운영 값은 중앙 DB/UI로 관리
• gitignore 문제 해결: 컨테이너는 중앙에서 설정 구독
• LOCAL_MODE=true 시 로컬 파일 허용

10. 도입 순서

1. JSON Schema 정의
2. PostgreSQL 테이블 생성
3. Redis 캐시 구조 구현
4. 설정 변경 API 개발
5. ChromaDB 파이프라인 통합
6. Slack 명령어 연결
7. 배치 리인덱싱 작업

핵심 메시지

"로빙은 생명체처럼 적응합니다. 하드코딩된 값이 아닌, 동적으로 변화하는 파라미터를 통해 성장하고 진화합니다."

이 원칙을 통해 로빙은:

• 사용자 요구에 즉시 대응
• 환경 변화에 유연하게 적응
• 경험을 통한 지속적 최적화
• 안전하고 추적 가능한 변경 관리

를 실현할 수 있습니다.

---

이 문서는 아이디어 단계이며, 구체적인 구현 계획으로 발전 예정입니다.