docs: 함수형 프로그래밍 가이드라인에 로컬/서버 테스트 전략 추가

- 개발 환경의 현실적 제약 설명
- 로컬 테스트 가능 영역 vs 서버 필요 영역
- 올바른 개발 워크플로우 정의
- 분산 아키텍처 설계 의도 명시

_archive/docs/guide/functional-programing/함수형_적용_가이드라인.md

@@ -31,7 +31,73 @@ date: 2025-07-04
 
 ---
 
-## 2. 로빙 구성요소별 순수 함수 가능성 분석
+## 2. 로컬 개발과 서버 테스트 전략
+
+### 2.1 개발 환경의 현실적 제약
+
+로빙 시스템은 **분산 아키텍처**로 설계되어 로컬에서 전체 실행이 불가능합니다:
+
+| 구분 | 로컬 환경 | 서버 환경 |
+|------|-----------|-----------|
+| **순수 함수** | ✅ 테스트 가능 | ✅ 테스트 가능 |
+| **외부 서비스** | ❌ 접근 불가 | ✅ 모두 연결 |
+| **데이터베이스** | ❌ 서버 데이터 | ✅ 실제 데이터 |
+| **스킬 서비스** | ❌ 포트 8015 없음 | ✅ skill-embedding 실행 |
+
+### 2.2 함수형 프로그래밍의 장점 활용
+
+**로컬에서 테스트 가능한 영역**:
+```python
+# ✅ 순수 함수들 - 외부 의존성 없음
+from app.llm.mistral import create_intent_analysis_prompt
+from app.core.memory.scoring import calculate_time_decay
+from app.core.emotion import EmotionState
+
+# 모듈별 단위 테스트
+prompt = create_intent_analysis_prompt("안녕하세요")
+decay = calculate_time_decay(3600)  # 1시간
+emotion = EmotionState(valence=0.5, arousal=0.3)
+```
+
+**서버에서만 테스트 가능한 영역**:
+```python
+# ❌ I/O 함수들 - 외부 서비스 필요
+- ChromaDB 쿼리 (서버 persistent storage)
+- skill-embedding:8015 (79MB ONNX 모델)
+- Gemini/Mistral API (API 키 필요)
+- Slack 웹훅 (실제 워크스페이스)
+```
+
+### 2.3 올바른 개발 워크플로우
+
+```mermaid
+graph LR
+    A[로컬 개발] --> B[모듈 테스트]
+    B --> C[Git Push]
+    C --> D[Gitea Actions]
+    D --> E[서버 배포]
+    E --> F[통합 테스트]
+```
+
+1. **로컬 개발**: 코드 작성, 문법 검증, 모듈 테스트
+2. **Push**: Git 커밋, Gitea에 푸시
+3. **서버**: 자동 배포, 통합 테스트, 실제 작동 확인
+
+### 2.4 아키텍처 설계 의도
+
+**왜 이렇게 설계했는가?**
+- **로빙은 가벼운 본체**: 118MB 메모리만 사용
+- **스킬은 공유 서비스**: 100개 로빙이 1개 스킬 서비스 공유
+- **확장성 우선**: 로빙 수가 늘어도 스킬 서비스는 하나
+
+이것이 바로 함수형 아키텍처의 핵심입니다:
+- 테스트 가능한 작은 단위
+- 외부 의존성 최소화
+- 명확한 경계 분리
+
+---
+
+## 3. 로빙 구성요소별 순수 함수 가능성 분석
 
 ### 2.1 스탯 시스템 (평균 60%)