From bc4bd7cdb433b4e87f5128ccd14edfbb263acaaf Mon Sep 17 00:00:00 2001
From: Claude-51124 <claude@51124.local>
Date: Tue, 12 Aug 2025 15:05:30 +0900
Subject: [PATCH] =?UTF-8?q?Update:=20=EB=A1=9C=EC=BB=AC=20=EA=B0=9C?=
 =?UTF-8?q?=EB=B0=9C=EC=9E=90=EC=9D=98=20DB=20=EB=B6=84=EC=84=9D=20?=
 =?UTF-8?q?=EB=B0=8F=20=ED=86=B5=ED=95=A9=20=ED=95=B4=EA=B2=B0=20=EB=B0=A9?=
 =?UTF-8?q?=EC=95=88=20=EC=B6=94=EA=B0=80?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- 51123 서버 DB 구조 분석 추가
- slack_user_mapping 테이블 설계 구체화
- 실행 계획 및 우선순위 정리
- 임시 테스트 방안 제시
---
 ...ck_메시지_처리_아키텍처_분석.md | 142 +++++++++++++++++-
 1 file changed, 138 insertions(+), 4 deletions(-)

diff --git a/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md b/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md
index 7d0bb64..0a42530 100644
--- a/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md
+++ b/ideas/250812_claude_Slack_메시지_처리_아키텍처_분석.md
@@ -286,14 +286,148 @@ class SlackItem(APIItem):
 3. skill-slack 수정 (로컬→배포)
 4. rb10508_micro 사용자 매핑 적용
 
-## 10. 결론
+## 10. 51123 서버 DB 구조 분석 (로컬 개발자 제공)
+
+### 10.1 현재 테이블 구조
+
+1. **users 테이블**
+   - 사용자 기본 정보 (email, username, name, OAuth 정보)
+   - 3명의 사용자 등록됨 (happybell80, eagle0914, hhyong91)
+
+2. **workspaces 테이블**
+   - 워크스페이스 정보 (robing_id, robing_port, robing_url 포함)
+   - 현재 1개 워크스페이스: ivada-robeing (rb10508_micro 사용)
+
+3. **workspace_members 테이블**
+   - 사용자와 워크스페이스 연결
+   - robing_id 필드로 각 멤버가 사용할 로빙 지정 가능
+
+4. **slack_workspaces 테이블**
+   - Slack 워크스페이스 정보 (team_id, bot_token, bot_user_id 등)
+   - 2개 Slack 워크스페이스 등록됨 (GoodGang Labs, test)
+   - companies 테이블과 연결됨
+
+5. **companies 테이블**
+   - 회사 정보 관리
+   - slack_workspaces와 1:N 관계
+
+### 10.2 누락된 부분
+
+**Slack 사용자 매핑 테이블이 없음**
+- Slack user_id (예: U0925SXQFDK)와 시스템 user_id를 연결하는 테이블 부재
+- slack_user_mapping 테이블이 필요
+
+현재 구조는 Slack 워크스페이스는 관리하지만, 개별 Slack 사용자와 시스템 사용자를 매핑하는 방법이 없습니다.
+
+## 11. 통합 해결 방안
+
+### 11.1 새 테이블 생성 (권장)
+
+```sql
+CREATE TABLE slack_user_mapping (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    slack_user_id VARCHAR(100) NOT NULL,
+    slack_workspace_id INTEGER REFERENCES slack_workspaces(id),
+    user_id UUID REFERENCES users(id),
+    workspace_member_id UUID REFERENCES workspace_members(id),
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    UNIQUE(slack_user_id, slack_workspace_id)
+);
+```
+
+### 11.2 개선된 매핑 플로우
+
+```
+Slack 메시지 수신 (U0925SXQFDK)
+    ↓
+slack_user_mapping 조회
+    ↓
+user_id 획득
+    ↓
+workspace_members에서 robing_id 확인
+    ↓
+해당 로빙으로 라우팅
+    ↓
+ChromaDB: rb10508_test_{user_id}_episodic
+```
+
+### 11.3 초기 매핑 데이터
+
+```sql
+-- happybell80을 Slack 사용자와 연결
+INSERT INTO slack_user_mapping (slack_user_id, slack_workspace_id, user_id)
+SELECT 'U0925SXQFDK', sw.id, u.id
+FROM users u, slack_workspaces sw
+WHERE u.username = 'happybell80' 
+AND sw.team_name = 'GoodGang Labs';
+```
+
+## 12. 실행 계획
+
+### 12.1 즉시 실행 가능한 작업
+
+#### 51124 서버
+1. rb10508_micro 코드 수정:
+   - Slack user_id로 DB 조회 추가
+   - ChromaDB 컬렉션명에 user_id 포함
+   - 매핑 없으면 기본 컬렉션 사용
+
+#### 로컬 개발자
+1. slack_user_mapping 테이블 SQL 작성
+2. Auth 서버 API 엔드포인트 추가:
+   - `/api/slack/mapping` - 매핑 조회/생성
+3. Gateway 수정:
+   - 사용자별 로빙 라우팅
+
+#### 51123 서버
+1. PostgreSQL에 테이블 생성
+2. nginx 라우팅 규칙 업데이트
+
+### 12.2 임시 테스트 방안
+
+테이블 생성 전 하드코딩으로 테스트:
+
+```python
+# rb10508_micro에서 임시 매핑
+TEMP_USER_MAPPING = {
+    "U0925SXQFDK": "happybell80",  # Slack → username
+    "U04KJHGLS": "eagle0914",
+}
+
+def get_system_user_id(slack_user_id: str) -> str:
+    username = TEMP_USER_MAPPING.get(slack_user_id)
+    if username:
+        # DB에서 users 테이블 조회
+        return get_user_id_by_username(username)
+    return "default_user"
+```
+
+## 13. 우선순위별 작업 목록
+
+### Phase 1 (즉시)
+1. slack_user_mapping 테이블 생성
+2. 임시 하드코딩으로 사용자 매핑 테스트
+3. ChromaDB 컬렉션 분리 확인
+
+### Phase 2 (1주 내)
+1. Auth 서버 API 구현
+2. rb10508_micro DB 연동
+3. 사용자별 메모리 분리 완료
+
+### Phase 3 (2주 내)
+1. Gateway 동적 라우팅
+2. skill-slack 다중 로빙 지원
+3. OAuth 자동 매핑
+
+## 14. 결론
 
 현재 rb10508_micro는 Slack 메시지를 정상적으로 처리하고 있지만, 사용자 식별과 매핑 시스템이 부재하여 개인화된 서비스 제공에 한계가 있습니다.
 
-로빙 설계 철학에 따라 Slack을 "아이템"으로 취급하고, Auth 서버를 통한 중앙화된 권한 관리를 구현하는 것이 장기적으로 확장 가능한 아키텍처가 될 것입니다.
+51123 서버의 기존 DB 구조를 활용하여 slack_user_mapping 테이블만 추가하면, 최소한의 변경으로 사용자별 메모리 분리가 가능합니다.
 
-skill-slack 서비스는 메시지 전송 도구로서의 역할을 유지하고, 각 로빙이 독립적으로 이벤트를 수신하는 구조가 가장 이상적입니다.
+로빙 설계 철학에 따라 Slack을 "아이템"으로 취급하고, Auth 서버를 통한 중앙화된 권한 관리를 구현하는 것이 장기적으로 확장 가능한 아키텍처가 될 것입니다.
 
 ---
 
-*이 문서는 2025년 8월 12일 51124 서버에서 실측한 데이터를 기반으로 작성되었습니다.*
\ No newline at end of file
+*이 문서는 2025년 8월 12일 51124 서버에서 실측한 데이터와 로컬 개발자의 DB 분석을 기반으로 작성되었습니다.*
\ No newline at end of file