- 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/*)
105 lines
2.7 KiB
Markdown
105 lines
2.7 KiB
Markdown
# 2025년 8월 6일 - 100% 함수형 프로그래밍 전환 성과
|
|
|
|
## 오후 6시 30분
|
|
|
|
### 함수형 프로그래밍 전환 완료
|
|
|
|
#### 배경
|
|
- 하드코딩된 값과 복잡한 상태 관리로 인한 문제
|
|
- 캐시 시스템의 중복 응답 문제
|
|
- 메모리 누수 및 성능 저하
|
|
|
|
#### 전환 과정
|
|
1. **코드 정리 (1차)**
|
|
- 캐시 시스템 완전 제거
|
|
- 하드코딩된 값 제거
|
|
- 템플릿 응답 제거
|
|
|
|
2. **함수형 전환 (2차)**
|
|
- 모든 클래스를 순수 함수로 변환
|
|
- 상태(self.*) 완전 제거
|
|
- 불변 데이터 구조(NamedTuple) 사용
|
|
- I/O와 계산 로직 분리
|
|
|
|
#### 성능 측정 결과
|
|
|
|
| 항목 | 전환 전 (OOP) | 전환 후 (FP) | 개선율 |
|
|
|------|--------------|-------------|---------|
|
|
| **메모리** | 106.7MiB | 95.87MiB | ✅ 10.1% 감소 |
|
|
| **CPU** | 0.06% | 0.05% | ✅ 16.7% 감소 |
|
|
| **PID** | 39개 | 20개 | ✅ 48.7% 감소 |
|
|
| **코드량** | 1,434줄 | 1,064줄 | ✅ 26% 감소 |
|
|
|
|
#### 파일별 코드 감소량
|
|
|
|
- **brain.py**: 338줄 → 178줄 (47% 감소)
|
|
- **memory.py**: 264줄 → 171줄 (35% 감소)
|
|
- **emotion.py**: 120줄 → 32줄 (73% 감소)
|
|
- **ethics.py**: 27줄 → 14줄 (48% 감소)
|
|
|
|
#### 아키텍처 변화
|
|
|
|
**Before (OOP):**
|
|
```python
|
|
class RobeingBrain:
|
|
def __init__(self):
|
|
self.memory = MemoryCore()
|
|
self.emotion = EmotionCore()
|
|
self.user_names = {} # 상태 유지
|
|
|
|
async def think(self, input_data):
|
|
# 복잡한 상태 관리
|
|
```
|
|
|
|
**After (FP):**
|
|
```python
|
|
async def think_functional(
|
|
input_data: Dict,
|
|
search_memories_fn, # 의존성 주입
|
|
store_memory_fn,
|
|
get_identity_fn,
|
|
store_identity_fn
|
|
) -> Dict:
|
|
# 순수 함수 체이닝
|
|
```
|
|
|
|
#### 주요 개선 사항
|
|
|
|
1. **프로세스 수 절반 감소**
|
|
- 멀티프로세싱 오버헤드 감소
|
|
- 컨텍스트 스위칭 감소
|
|
|
|
2. **메모리 효율성**
|
|
- 객체 인스턴스 오버헤드 제거
|
|
- 가비지 컬렉션 부담 감소
|
|
|
|
3. **코드 가독성**
|
|
- 입력 → 출력 명확
|
|
- 부작용 없는 예측 가능한 동작
|
|
|
|
4. **테스트 용이성**
|
|
- 각 함수 독립적 테스트 가능
|
|
- 목(Mock) 객체 불필요
|
|
|
|
#### 교훈
|
|
|
|
1. **"적을수록 좋다"**
|
|
- 코드가 적으면 버그도 적다
|
|
- 단순함이 최고의 설계
|
|
|
|
2. **상태는 복잡성의 근원**
|
|
- 상태를 제거하니 버그가 사라짐
|
|
- 함수형 프로그래밍의 힘
|
|
|
|
3. **측정 없이 최적화 없다**
|
|
- 실제 측정 결과가 예상과 일치
|
|
- 프로세스 수 감소가 가장 큰 효과
|
|
|
|
#### 결론
|
|
|
|
함수형 프로그래밍 전환으로:
|
|
- 리소스 사용량 대폭 감소
|
|
- 코드 복잡도 해결
|
|
- 유지보수성 향상
|
|
|
|
**"Less is More" - 적을수록 더 강력하다** |