happybell80 97e0888ce0 Fix more incorrect table names in documentation

- users → user in SQL contexts (94 occurrences)
- robeings → robeing in SQL contexts
- user_preferences → user_preference (14 files)
- slack_workspaces → slack_workspace in SQL contexts (17 files)

All table names now correctly match PostgreSQL schema

2025-09-26 00:52:15 +09:00

13 KiB

Raw Blame History

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

작성일: 2025년 8월 12일
작성자: Claude (51124 서버)

1. 현재 상황 분석

1.1 rb10508_micro Slack 메시지 처리 흐름

메시지 수신 경로

nginx (51123) → /api/slack/events (10508 포트)
endpoints.py:115-135에서 POST 요청 수신
BackgroundTasks로 비동기 처리 (Slack 3초 룰 준수)
즉시 {"ok": True} 반환

비동기 메시지 처리 (slack_service.py)

process_slack_event() 호출
봇 자신 메시지 필터링 (bot_user_id 체크)
_handle_message_event() 비동기 실행
user_id, channel_id, text 추출
thread_ts 처리 (스레드 대화 유지)

Brain 처리 (think_functional)

입력 추출: message, user_id, context
의도 분석: "general_conversation" (하드코딩)
Identity 조회: user_name, robeing_name
이름 감지: "내 이름은", "너를 ~라고 부를게"
메모리 검색: ChromaDB query (100개 → 선택)
Gemini API 응답 생성
이모지/마크다운 제거
메모리 저장 준비
ChromaDB 저장
감정 분석
결과 반환

메모리 저장 (storage.py)

prepare_memory(): user/assistant 각각
save_memories(): 일괄 저장
ChromaDB collection: rb10508_micro_episodic
HTTP 임베딩: skill-embedding (8515)
메타데이터: user_id, role, timestamp

Slack 응답 전송

chat.postMessage API 호출
thread_ts 포함 (스레드 유지)
응답 시간 추가 (선택)

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 테이블 구조

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 추가 고려사항

멀티 workspace: 한 사용자가 여러 workspace 사용
로빙 변경: 사용자가 다른 로빙 선택 시 업데이트
권한 관리: Slack 봇 토큰 안전한 저장

4. skill-slack 서비스 분석

4.1 skill-slack이 하는 일

skill-slack은 Slack API 기능만 제공하는 마이크로서비스입니다:

주요 기능

메시지 전송 (/api/v1/messages/send)
- 다른 서비스가 Slack에 메시지 보낼 때 사용
- 채널, 텍스트, 블록 전송
메시지 업데이트 (/api/v1/messages/update)
- 기존 메시지 수정
다이제스트 (/api/v1/digest)
- 스레드 요약
액션 처리 (/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 아이템 시스템 적용

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 아이템 방식 아키텍처

Auth 서버에서 Slack 권한 관리
- 사용자가 Slack OAuth 인증
- Auth 서버가 봇 토큰 저장
- 사용자별 workspace 권한 관리
Slack 앱 설정의 Event URL
- Gateway 이벤트 엔드포인트 지정
- 예: https://ro-being.com/api/slack/events (nginx가 Gateway 8100으로 프록시)
- Gateway가 사용자/로빙 매핑 후 해당 로빙으로 라우팅
사용자-로빙 연결
- Auth 서버가 사용자와 로빙 매핑
- Slack user_id → system user_id → robeing_id
- 로빙이 직접 해당 사용자 메시지 처리
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 배포 우선순위

DB 테이블 생성 (51123)
Gateway 라우팅 로직 (로컬→배포)
skill-slack 수정 (로컬→배포)
rb10508_micro 사용자 매핑 적용

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

10.1 현재 테이블 구조

users 테이블
- 사용자 기본 정보 (email, username, name, OAuth 정보)
- 3명의 사용자 등록됨 (happybell80, eagle0914, hhyong91)
workspaces 테이블
- 워크스페이스 정보 (robeing_id, robeing_port, robeing_url 포함)
- 현재 1개 워크스페이스: ivada-robeing (rb10508_micro 사용)
workspace_member 테이블
- 사용자와 워크스페이스 연결
- robeing_id 필드로 각 멤버가 사용할 로빙 지정 가능
slack_workspaces 테이블
- Slack 워크스페이스 정보 (team_id, bot_token, bot_user_id 등)
- 2개 Slack 워크스페이스 등록됨 (GoodGang Labs, test)
- company 테이블과 연결됨
company 테이블
- 회사 정보 관리
- slack_workspaces와 1:N 관계

10.2 누락된 부분

Slack 사용자 매핑 테이블이 없음

Slack user_id (예: U0925SXQFDK)와 시스템 user_id를 연결하는 테이블 부재
slack_user_mapping 테이블이 필요

현재 구조는 Slack 워크스페이스는 관리하지만, 개별 Slack 사용자와 시스템 사용자를 매핑하는 방법이 없습니다.

11. 통합 해결 방안

11.1 새 테이블 생성 (권장)

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 초기 매핑 데이터

-- 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 서버

rb10508_micro 코드 수정:
- Slack user_id로 DB 조회 추가
- ChromaDB 컬렉션명에 user_id 포함
- 매핑 없으면 기본 컬렉션 사용

로컬 개발자

slack_user_mapping 테이블 SQL 작성
Auth 서버 API 엔드포인트 추가:
- /api/slack/mapping - 매핑 조회/생성
Gateway 수정:
- 사용자별 로빙 라우팅

51123 서버

PostgreSQL에 테이블 생성
nginx 라우팅 규칙 업데이트

12.2 임시 테스트 방안

테이블 생성 전 하드코딩으로 테스트:

# 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 (즉시)

slack_user_mapping 테이블 생성
임시 하드코딩으로 사용자 매핑 테스트
ChromaDB 컬렉션 분리 확인

Phase 2 (1주 내)

Auth 서버 API 구현
rb10508_micro DB 연동
사용자별 메모리 분리 완료

Phase 3 (2주 내)

Gateway 동적 라우팅
skill-slack 다중 로빙 지원
OAuth 자동 매핑

14. 결론

현재 rb10508_micro는 Slack 메시지를 정상적으로 처리하고 있지만, 사용자 식별과 매핑 시스템이 부재하여 개인화된 서비스 제공에 한계가 있습니다.

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

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

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

13 KiB Raw Blame History