happybell80
071a2b89dc
- 동적 파라미터 관리 프로젝트 원칙 - 하드코딩 배제, 제어면/데이터면 분리 - 생물학적 비유 (호르몬/신경 신호) - LLM 사용 원칙 정립 - 로빙 윤리 설계: 사랑 기반 원칙 - 무조건적 존중, 희생적 봉사, 회복과 성장 - Love Index 측정 체계 - 기존 윤리 모델과의 차별화 - 로빙 존재형 추가 구성 요소 - 5스탯 재정의 (기억/이성/공감/품성/조율) - 사회적 상호작용 레이어 (유머/위트/눈치) - MVP 이후 12개월 로드맵 작성: claude
175 lines
5.4 KiB
Markdown
175 lines
5.4 KiB
Markdown
# 동적 파라미터 관리와 로빙 프로젝트 원칙
|
|
> 하드코딩 없는 유연한 아키텍처 설계
|
|
|
|
날짜: 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. 배치 리인덱싱 작업
|
|
|
|
## 핵심 메시지
|
|
|
|
> "로빙은 생명체처럼 적응합니다. 하드코딩된 값이 아닌, 동적으로 변화하는 파라미터를 통해 성장하고 진화합니다."
|
|
|
|
이 원칙을 통해 로빙은:
|
|
- 사용자 요구에 즉시 대응
|
|
- 환경 변화에 유연하게 적응
|
|
- 경험을 통한 지속적 최적화
|
|
- 안전하고 추적 가능한 변경 관리
|
|
|
|
를 실현할 수 있습니다.
|
|
|
|
---
|
|
|
|
*이 문서는 아이디어 단계이며, 구체적인 구현 계획으로 발전 예정입니다.* |