Update: 로컬 개발자의 DB 분석 및 통합 해결 방안 추가
- 51123 서버 DB 구조 분석 추가 - slack_user_mapping 테이블 설계 구체화 - 실행 계획 및 우선순위 정리 - 임시 테스트 방안 제시
This commit is contained in:
parent
61321126a7
commit
bc4bd7cdb4
@ -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 서버에서 실측한 데이터를 기반으로 작성되었습니다.*
|
||||
*이 문서는 2025년 8월 12일 51124 서버에서 실측한 데이터와 로컬 개발자의 DB 분석을 기반으로 작성되었습니다.*
|
||||
Loading…
x
Reference in New Issue
Block a user