# 동적 파라미터 관리와 로빙 프로젝트 원칙
> 하드코딩 없는 유연한 아키텍처 설계

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

## 핵심 철학

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

## 1. 하드코딩 배제 원칙

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

### 적용 예시
```json
{
  "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 스키마
```sql
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. 배치 리인덱싱 작업

## 핵심 메시지

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

이 원칙을 통해 로빙은:
- 사용자 요구에 즉시 대응
- 환경 변화에 유연하게 적응
- 경험을 통한 지속적 최적화
- 안전하고 추적 가능한 변경 관리

를 실현할 수 있습니다.

---

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