# 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, robeing_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_micro_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_micro_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, robeing_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 user(id),        -- 우리 시스템 사용자
    robeing_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, robeing_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 봇 이벤트는 nginx→Gateway(8100)→로빙으로 전달됩니다**

### 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**
   - Gateway 이벤트 엔드포인트 지정
   - 예: `https://ro-being.com/api/slack/events` (nginx가 Gateway 8100으로 프록시)
   - Gateway가 사용자/로빙 매핑 후 해당 로빙으로 라우팅

3. **사용자-로빙 연결**
   - Auth 서버가 사용자와 로빙 매핑
   - Slack user_id → system user_id → robeing_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**: robeing-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 사용자 분리 전략
- 컬렉션 명명 규칙: `{robeing_id}_{system_user_id}_{type}`
- 기존 데이터 마이그레이션 계획
- 백업 및 복구 정책

### 9.6 배포 우선순위
1. DB 테이블 생성 (51123)
2. Gateway 라우팅 로직 (로컬→배포)
3. skill-slack 수정 (로컬→배포)
4. rb10508_micro 사용자 매핑 적용

## 10. 51123 서버 DB 구조 분석 (로컬 개발자 제공)

### 10.1 현재 테이블 구조

1. **users 테이블**
   - 사용자 기본 정보 (email, username, name, OAuth 정보)
   - 3명의 사용자 등록됨 (happybell80, eagle0914, hhyong91)

2. **workspaces 테이블**
   - 워크스페이스 정보 (robeing_id, robeing_port, robeing_url 포함)
   - 현재 1개 워크스페이스: ivada-robeing (rb10508_micro 사용)

3. **workspace_member 테이블**
   - 사용자와 워크스페이스 연결
   - robeing_id 필드로 각 멤버가 사용할 로빙 지정 가능

4. **slack_workspaces 테이블**
   - Slack 워크스페이스 정보 (team_id, bot_token, bot_user_id 등)
   - 2개 Slack 워크스페이스 등록됨 (GoodGang Labs, test)
   - company 테이블과 연결됨

5. **company 테이블**
   - 회사 정보 관리
   - 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_workspace(id),
    user_id UUID REFERENCES user(id),
    workspace_member_id UUID REFERENCES workspace_member(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_member에서 robeing_id 확인
    ↓
해당 로빙으로 라우팅
    ↓
ChromaDB: rb10508_micro_{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 user 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 메시지를 정상적으로 처리하고 있지만, 사용자 식별과 매핑 시스템이 부재하여 개인화된 서비스 제공에 한계가 있습니다.

51123 서버의 기존 DB 구조를 활용하여 slack_user_mapping 테이블만 추가하면, 최소한의 변경으로 사용자별 메모리 분리가 가능합니다.

로빙 설계 철학에 따라 Slack을 "아이템"으로 취급하고, Auth 서버를 통한 중앙화된 권한 관리를 구현하는 것이 장기적으로 확장 가능한 아키텍처가 될 것입니다.

---

*이 문서는 2025년 8월 12일 51124 서버에서 실측한 데이터와 로컬 개발자의 DB 분석을 기반으로 작성되었습니다.*