Add: Slack 메시지 처리 아키텍처 분석 및 개선 방안 문서

2025-08-12 14:57:55 +09:00 · 2025-08-12 14:57:55 +09:00 · 61321126a7
commit 61321126a7
parent 6e6f6e32ca
1 changed files with 299 additions and 0 deletions
--- a/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md
+++ b/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md
@ -0,0 +1,299 @@
+# Slack 메시지 처리 아키텍처 분석 및 개선 방안
+
+작성일: 2025년 8월 12일  
+작성자: Claude (51124 서버)
+
+## 1. 현재 상황 분석
+
+### 1.1 rb10508_micro Slack 메시지 처리 흐름
+
+#### 메시지 수신 경로
+1. nginx (51123) → `/api/slack/events` (10508 포트)
+2. endpoints.py:115-135에서 POST 요청 수신
+3. BackgroundTasks로 비동기 처리 (Slack 3초 룰 준수)
+4. 즉시 {"ok": True} 반환
+
+#### 비동기 메시지 처리 (slack_service.py)
+1. process_slack_event() 호출
+2. 봇 자신 메시지 필터링 (bot_user_id 체크)  
+3. _handle_message_event() 비동기 실행
+4. user_id, channel_id, text 추출
+5. thread_ts 처리 (스레드 대화 유지)
+
+#### Brain 처리 (think_functional)
+1. 입력 추출: message, user_id, context
+2. 의도 분석: "general_conversation" (하드코딩)
+3. Identity 조회: user_name, robing_name
+4. 이름 감지: "내 이름은", "너를 ~라고 부를게"
+5. 메모리 검색: ChromaDB query (100개 → 선택)
+6. Gemini API 응답 생성
+7. 이모지/마크다운 제거
+8. 메모리 저장 준비
+9. ChromaDB 저장
+10. 감정 분석
+11. 결과 반환
+
+#### 메모리 저장 (storage.py)
+1. prepare_memory(): user/assistant 각각
+2. save_memories(): 일괄 저장
+3. ChromaDB collection: rb10508_test_episodic
+4. HTTP 임베딩: skill-embedding (8515)
+5. 메타데이터: user_id, role, timestamp
+
+#### Slack 응답 전송
+1. chat.postMessage API 호출
+2. thread_ts 포함 (스레드 유지)
+3. 응답 시간 추가 (선택)
+
+### 1.2 저장 상태 확인
+
+- **정상 작동 중**: 로그에서 확인
+  - "Processing message from U0925SXQFDK"
+  - "[메모리] 검색: 6개 → LLM 선택: 4개"
+  - "[대화] 2개 메모리 저장 완료"
+- **ChromaDB 저장**: rb10508_test_episodic에 5개 문서
+
+## 2. 현재 문제점
+
+### 2.1 Slack 메시지 라우팅 문제
+- skill-slack이 rb8001에만 연결됨
+- rb10508_micro는 nginx를 통해서만 메시지 수신
+- 직접적인 Slack 봇 연결 없음
+
+### 2.2 사용자 식별 문제
+- Slack user_id (U0925SXQFDK)를 그대로 사용
+- 실제 시스템 user_id와 매핑 없음
+- 모든 Slack 사용자가 같은 ChromaDB 컬렉션 공유
+- 사용자별 개인화된 기억 분리 안 됨
+
+### 2.3 데이터 저장량 부족
+- 5개 문서만 저장됨 (실제 대화량 대비 적음)
+- 저장은 되지만 누적이 제대로 안 됨
+- 사용자별 컬렉션 분리 없어서 혼재 가능
+
+### 2.4 아키텍처 불일치
+- skill-slack → rb8001 (하드코딩)
+- nginx → rb10508_micro (프록시)
+- 이중 경로로 인한 혼란
+
+### 2.5 Identity 관리 미흡
+- user_name, robing_name은 저장하지만
+- 실제 사용자 계정과 연결 안 됨
+- OAuth 로그인과 Slack 사용자 매핑 없음
+
+## 3. Slack 사용자 매핑 방안
+
+### 3.1 필요한 DB 테이블 구조
+
+```sql
+CREATE TABLE slack_user_mapping (
+    id UUID PRIMARY KEY,
+    slack_user_id VARCHAR(100) NOT NULL,      -- U04KJHGLS
+    slack_workspace_id VARCHAR(100),          -- T1234567
+    user_id UUID REFERENCES users(id),        -- 우리 시스템 사용자
+    robing_id VARCHAR(100),                   -- rb10508_micro
+    created_at TIMESTAMP,
+    UNIQUE(slack_user_id, slack_workspace_id)
+);
+```
+
+### 3.2 사용자 식별 플로우
+
+```
+Slack 메시지 수신
+  ↓
+slack_user_id (U04KJHGLS) 추출
+  ↓
+DB 조회: slack_user_mapping
+  ↓
+user_id, robing_id 획득
+  ↓
+해당 로빙의 ChromaDB에 저장
+```
+
+### 3.3 구현 필요 사항
+
+#### 51124 서버 (로빙)
+- Slack 이벤트에서 user_id 추출
+- DB 조회하여 사용자 매핑
+- ChromaDB에 사용자별 컨텍스트 저장
+
+#### 51123 서버 (DB)
+- slack_user_mapping 테이블 생성
+- API 엔드포인트 제공 (조회/생성)
+
+### 3.4 초기 매핑 방법
+- Slack OAuth 로그인 시 매핑 생성
+- 또는 관리자가 수동 매핑
+
+### 3.5 추가 고려사항
+1. 멀티 workspace: 한 사용자가 여러 workspace 사용
+2. 로빙 변경: 사용자가 다른 로빙 선택 시 업데이트
+3. 권한 관리: Slack 봇 토큰 안전한 저장
+
+## 4. skill-slack 서비스 분석
+
+### 4.1 skill-slack이 하는 일
+
+**skill-slack은 Slack API 기능만 제공하는 마이크로서비스입니다:**
+
+#### 주요 기능
+1. **메시지 전송** (`/api/v1/messages/send`)
+   - 다른 서비스가 Slack에 메시지 보낼 때 사용
+   - 채널, 텍스트, 블록 전송
+
+2. **메시지 업데이트** (`/api/v1/messages/update`)
+   - 기존 메시지 수정
+
+3. **다이제스트** (`/api/v1/digest`)
+   - 스레드 요약
+
+4. **액션 처리** (`/api/v1/actions`)
+   - Slack 버튼/인터랙션 처리
+
+### 4.2 중요한 발견
+- **skill-slack은 Slack 이벤트를 수신하지 않습니다**
+- **단순히 API 래퍼 역할만 합니다**
+- **실제 Slack 봇 이벤트는 rb8001이나 rb10508이 직접 받습니다**
+
+### 4.3 실제 상황
+- rb10508_micro가 `/api/slack/events`로 이벤트 직접 수신
+- skill-slack은 메시지 전송 도구일 뿐
+- nginx 라우팅 설정이 핵심
+
+## 5. 로빙 설계 철학과 Slack 통합
+
+### 5.1 스킬 시스템 철학 (문서 분석)
+- 스킬은 **"아이템"처럼 장착/해제** 가능한 능력
+- 레벨과 스탯에 따라 사용 가능 여부 결정
+- 외부 도구를 통합하는 **API 아이템** 개념
+
+### 5.2 Slack의 위치
+- **API 아이템 유형** (외부 서비스 접근권)
+- 레벨 요구사항과 권한 관리 필요
+- OAuth 기반 인증으로 보안 관리
+
+### 5.3 아이템 시스템 적용
+
+```python
+class SlackItem(APIItem):
+    name = "Slack Messenger"
+    level_req = 3  # 레벨 3부터 사용 가능
+    permissions = ["chat:write", "channels:read"]
+    
+    async def send_message(self, channel, text):
+        # skill-slack 서비스 호출
+        return await httpx.post(
+            "http://localhost:8502/api/v1/messages/send",
+            json={"channel": channel, "text": text}
+        )
+```
+
+## 6. 권장 아키텍처
+
+### 6.1 Slack 아이템 방식 아키텍처
+
+1. **Auth 서버에서 Slack 권한 관리**
+   - 사용자가 Slack OAuth 인증
+   - Auth 서버가 봇 토큰 저장
+   - 사용자별 workspace 권한 관리
+
+2. **Slack 앱 설정의 Event URL**
+   - 직접 로빙 엔드포인트 지정
+   - 예: `https://ro-being.com/rb10508/api/slack/events`
+   - 각 로빙이 자체 Slack 이벤트 처리
+
+3. **사용자-로빙 연결**
+   - Auth 서버가 사용자와 로빙 매핑
+   - Slack user_id → system user_id → robing_id
+   - 로빙이 직접 해당 사용자 메시지 처리
+
+4. **skill-slack의 역할**
+   - 로빙이 응답 보낼 때만 사용
+   - 아이템처럼 필요시 호출
+   - 이벤트 수신 X, 전송 도구 O
+
+### 6.2 장점
+- ✅ 로빙 설계 철학과 일치
+- ✅ 권한 관리 명확
+- ✅ 다른 메신저로 교체 용이
+- ✅ skill-slack 재사용
+- ✅ 각 로빙이 독립적으로 Slack 이벤트 수신
+
+## 7. 구현 제안
+
+### 7.1 skill-slack을 아이템 서비스로 유지
+- 메시지 전송, 수정, 스레드 관리
+- 모든 로빙이 공유하는 Slack API 래퍼
+
+### 7.2 각 로빙의 역할
+- Slack 이벤트 직접 수신 (`/api/slack/events`)
+- 메시지 처리 후 skill-slack으로 응답 전송
+- Auth 서버에서 토큰 관리
+
+### 7.3 사용자 매핑
+- Auth 서버가 Slack OAuth 처리
+- `slack_user_mapping` 테이블로 관리
+- 로빙별 사용자 컨텍스트 분리
+
+## 8. 마이그레이션 계획
+
+### Phase 1: 현재 직접 통합 유지
+- rb10508_micro 내부 Slack SDK 사용
+- 기존 코드 안정화
+
+### Phase 2: skill-slack 호출로 점진적 전환
+- 응답 전송만 skill-slack 사용
+- 이벤트 수신은 직접 처리
+
+### Phase 3: Slack을 완전한 아이템으로 분리
+- Auth 서버 통합 완료
+- 사용자 매핑 테이블 활용
+- 다중 메신저 지원 준비
+
+## 9. 51123 서버/로컬 개발자와 논의 필요 사항
+
+### 9.1 Slack 라우팅 아키텍처 결정
+- **옵션 A**: skill-slack에서 다중 로빙 지원
+  - 환경변수로 rb8001, rb10508 둘 다 설정
+  - 사용자별로 어느 로빙 사용할지 결정 로직
+- **옵션 B**: robing-gateway에서 중앙 라우팅
+  - Gateway가 사용자→로빙 매핑 관리
+  - skill-slack은 Gateway로만 전송
+
+### 9.2 DB 스키마 추가
+- slack_user_mapping 테이블 생성
+- users 테이블과 연결
+- 초기 데이터 마이그레이션 방법
+
+### 9.3 인증 플로우 통합
+- Slack OAuth 로그인 시 자동 매핑
+- 기존 OAuth 사용자와 Slack 사용자 연결
+- workspace별 봇 토큰 관리
+
+### 9.4 메시지 필드 표준화
+- "message" vs "text" 필드 통일
+- Gateway에서 변환 vs 각 서비스에서 호환
+
+### 9.5 ChromaDB 사용자 분리 전략
+- 컬렉션 명명 규칙: `{robing_id}_{system_user_id}_{type}`
+- 기존 데이터 마이그레이션 계획
+- 백업 및 복구 정책
+
+### 9.6 배포 우선순위
+1. DB 테이블 생성 (51123)
+2. Gateway 라우팅 로직 (로컬→배포)
+3. skill-slack 수정 (로컬→배포)
+4. rb10508_micro 사용자 매핑 적용
+
+## 10. 결론
+
+현재 rb10508_micro는 Slack 메시지를 정상적으로 처리하고 있지만, 사용자 식별과 매핑 시스템이 부재하여 개인화된 서비스 제공에 한계가 있습니다.
+
+로빙 설계 철학에 따라 Slack을 "아이템"으로 취급하고, Auth 서버를 통한 중앙화된 권한 관리를 구현하는 것이 장기적으로 확장 가능한 아키텍처가 될 것입니다.
+
+skill-slack 서비스는 메시지 전송 도구로서의 역할을 유지하고, 각 로빙이 독립적으로 이벤트를 수신하는 구조가 가장 이상적입니다.
+
+---
+
+*이 문서는 2025년 8월 12일 51124 서버에서 실측한 데이터를 기반으로 작성되었습니다.*