DOCS/troubleshooting/250820_happybell80_auth_db를_main_db로_변경.md

3.5 KiB

auth_db를 main_db로 데이터베이스 이름 변경

작업 일시

2025-08-20

작업자

happybell80, Claude

배경

  • Gmail 통합 작업 중 사용자 이름→이메일 변환 로직 구현 필요
  • 로빙이 개인 연락처를 저장할 공간 설계 논의 중
  • 기존 auth_db가 인증 전용 DB처럼 보여 혼란 야기
  • 51123 서버에서 rb10508_test_db 삭제 및 auth_db → main_db 변경 완료

문제점

  1. auth_db라는 이름이 인증 전용 DB로 오해 소지
  2. 로빙의 개인 데이터 저장 공간 부재
  3. 여러 서비스에서 auth_db 하드코딩

해결 과정

1. 로빙 데이터 저장 구조 설계

  • PostgreSQL vs Neo4j vs SQLite 논의
  • ChromaDB만으로는 부족 (정확한 조회, 트랜잭션, 시간 처리 불가)
  • 최종 결정: PostgreSQL의 robeing 스키마 + JSONB 확장 필드

2. auth_db → main_db 변경 작업

변경한 서비스들:

  1. auth-server

    • docker-compose.yml: DATABASE_URL 수정
    • app/providers/gmail_passport.py: DATABASE_URL 수정
  2. rb10508_micro

    • docker-compose.yml: POSTGRES_CONNECTION_STRING 수정
    • app/api/endpoints.py: asyncpg 연결 database 수정
  3. robeing-gateway

    • docker-compose.yml: DATABASE_URL 수정
    • app/database.py: 주석 및 기본값 수정
    • app/models.py: 주석 수정
    • scripts/init_db.sql, test_data.sql: 삭제 (이미 데이터 존재)
  4. robeing-monitor

    • docker-compose.yml: DATABASE_URL 수정
    • app/core/config.py: DATABASE_URL 수정
  5. skill-email (24서버)

    • .env 파일 수정 완료

3. 로빙 데이터 테이블 설계

-- main_db에 실행할 SQL
CREATE SCHEMA IF NOT EXISTS robeing;

-- 연락처 테이블 (확장 가능)
CREATE TABLE robeing.contacts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    robeing_id VARCHAR(50) NOT NULL,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255),
    extra JSONB DEFAULT '{}',  -- 확장용: phone, company, memo 등
    created_at TIMESTAMP DEFAULT NOW(),
    CONSTRAINT uk_robeing_name UNIQUE(robeing_id, name)
);

-- 대화 테이블 (확장 가능)
CREATE TABLE robeing.conversations (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    robeing_id VARCHAR(50) NOT NULL,
    user_message TEXT,
    robeing_response TEXT,
    metadata JSONB DEFAULT '{}',  -- entities, context, tools_used 등
    timestamp TIMESTAMP DEFAULT NOW()
);

-- 인덱스
CREATE INDEX idx_contacts_robeing ON robeing.contacts(robeing_id);
CREATE INDEX idx_conversations_robeing ON robeing.conversations(robeing_id);

논의 내용

스키마 vs 테이블 내 구분

  • 스키마별 분리: 삭제 쉬움 (DROP SCHEMA rb10508 CASCADE)
  • robeing_id로 구분: 관리 단순
  • 파티션 테이블: 성능 최적화
  • 최종 결정: robeing_id + 삭제 함수 방식

JSONB 활용

  • 핵심 컬럼 + extra JSONB 필드로 유연성 확보
  • 스키마 변경 없이 필드 추가 가능

결과

  • 모든 서비스에서 auth_db → main_db 변경 완료
  • Git에 커밋 및 푸시 완료
  • CLAUDE.md 업데이트 (로컬 개발자 역할 명확화)
  • DOCS 문서들 일괄 수정

다음 단계

  1. 51123 서버에서 서비스 재배포 확인
  2. main_db에 robeing 스키마 및 테이블 생성
  3. rb10508_micro에 이름→이메일 변환 로직 구현
  4. workspace_members + robeing.contacts 조합 조회

교훈

  • 데이터베이스 이름은 용도를 명확히 반영해야 함
  • 하드코딩된 DB 이름은 환경변수로 관리
  • 로빙의 개인 데이터는 격리된 스키마/테이블로 관리
  • JSONB 필드로 확장성 확보