ABC DB 단일화 전환 작업 목록

작성일: 2026-09-07
결정: 스테이징 및 운영에서 피드백·사용자·권한 데이터를 ABC userfeedback MySQL 하나로 관리한다.
목표: baron_support DB와 mysql-secretary를 제거하고, Secretary 서비스가 필요로 하는 보조 테이블도 ABC userfeedback DB 안에서 관리한다.

1. 확인된 현재 상태

항목	ABC DB (`userfeedback`, 13306)	구축 DB (`baron_support`, 13308)
OAuth 사용자	`users`에 저장됨	스테이징 `support_users` 0건
피드백	`feedbacks` 등 ABC 테이블에 저장됨	`support_tickets` 등은 스테이징 실사용 데이터 없음
배포 구성	Nest API가 직접 사용	`secretary-api`가 연결하도록 구성만 남아 있음

현재 배포 구성에 정의된 영속 DB는 위 두 MySQL뿐이다. MYSQL_SECONDARY_URLS는 기능으로는 지원하지만 스테이징 Compose 환경에는 설정되지 않았다.

ABC feedbacks.id를 피드백의 유일한 식별자로 유지한다.
사용자 인증과 관리자 권한은 ABC users, roles, members를 원본으로 사용한다.
Secretary 서비스는 유지하되 DATABASE_URL을 ABC userfeedback으로 전환한다. 지원 전용 테이블은 같은 물리 DB 안에 둔다.
기존 외부 작성페이지는 계속 ABC API로 등록할 수 있어야 하며, 통합관리 화면은 같은 ABC 피드백을 조회·처리한다.
이관할 구축 DB 실데이터가 없으므로 baron_support 데이터 이관은 수행하지 않는다. 삭제 전 최종 백업만 남긴다.

support_users 등 Secretary 보조 테이블을 userfeedback 스키마에 생성할 migration을 준비하고 임시 MySQL에서 검증했다. OAuth 원본 사용자는 계속 ABC users로 유지한다.
Secretary 권한 조회는 내부 API를 통해 ABC users.type 및 members → roles → projects를 원본으로 사용하도록 보완했다. 기존 Secretary 역할은 ABC API 일시 장애 시에만 호환용으로 유지한다.
로그인 직후 이동, 프로젝트 가드, 통합 대시보드의 권한 규칙이 ABC 사용자·프로젝트 정보와 같은 DB 안에서 정상 동작하는지 확인한다.

support_tickets 등 지원 화면 보조 테이블을 ABC 피드백과 동일한 userfeedback DB에 생성할 수 있음을 임시 MySQL 마이그레이션으로 확인했다.
ABC attachments와 이름이 충돌하는 Secretary 테이블을 support_attachments로 분리한다.
피드백 상태, 담당자, 이슈 연결, 댓글, 내부 메모, 첨부파일이 동일 DB에서 정상 동작하는지 검증한다.

10.13.10.4:8864 EGBIM_DEMO 작성페이지의 생성·목록 API가 ABC 프로젝트/채널을 일관되게 사용함을 확인한다.
feedback.hmac.kr 통합관리 페이지와 외부 작성페이지가 같은 ABC feedback ID를 조회하는지 검증한다.
/api/support/*를 외부 작성페이지의 공개 계약으로 사용하지 않는다. 외부 연동은 ABC 공개 API 또는 확정된 별도 API 계약을 사용한다.

스테이징 Compose의 Secretary DATABASE_URL을 mysql:3306/userfeedback으로 전환한다.
스테이징 Compose에서 mysql-secretary, baron_support volume, 외부 13308 포트를 제거한다.
기본·local·infra·apps·prod Compose에서 mysql-secretary를 제거하고 Secretary DB 연결을 userfeedback으로 통일했다. E2E는 원래 Secretary DB를 사용하지 않는다.
현재 실행에 사용되는 Secretary migration/config, 로컬 시작 스크립트, 배포 문서를 ABC 단일 DB 기준으로 갱신했다. 과거 이관 SQL·과거 설계 문서는 역사 기록으로 유지한다.
Gitea 변수 및 스테이징 배포 workflow를 ABC 단일 DB 구성으로 갱신했다.
프로젝트·채널 UUID 고정 환경변수를 제거하고 MASTER_API_KEY로 ABC 내부 API를 조회하는 동적 workspace 매핑으로 전환했다.
실제 DB 삭제 전 baron_support 백업 및 컨테이너/볼륨 참조가 없는지 재확인한다. (스테이징 배포·기능 확인 후 수행)

OAuth 로그인 후 userfeedback.users만 생성·갱신되고 권한 화면 및 통합관리 화면이 정상으로 열린다.
EGBIM_DEMO에서 피드백 작성 후 ABC feedbacks에 1건 생성되고, 통합관리 및 작성페이지 목록에 동일 ID·제목·작성자가 표시된다.
관리자 상태 변경, 담당자 지정, 이슈 연결, 댓글·첨부파일의 생성/조회/수정/삭제를 ABC 데이터만으로 확인한다.
mysql-secretary 없이 secretary-api, Web, API가 기동되고 Secretary migration이 ABC userfeedback에 적용됨을 임시 MySQL에서 확인한다.
삭제 직전 스테이징에서 baron_support 연결 시도 로그가 없는 것을 확인한 뒤 DB/볼륨을 제거한다.

아래 항목은 코드를 작성했다고 자동으로 완료되지 않는다. 실제 스테이징 배포와 사용자 동작 확인이 필요하므로 체크를 유지한다.

스테이징 배포 후 Secretary migration이 userfeedback의 alembic_version에 0021_ticket_idempotency로 기록됐는지 확인한다.
스테이징 userfeedback에 support_attachments와 Secretary 보조 테이블이 생성됐고, 기존 ABC attachments가 유지됐는지 확인한다.
OAuth 로그인, 통합관리 권한, EGBIM_DEMO 작성/목록/상세/상태변경을 실제 스테이징에서 확인한다.
SUPER 사용자와 EGBIM_DEMO의 PROJECT_MANAGER/Admin 사용자가 /api/tickets/{id}/internal-memos 등 관리자 API를 403 없이 호출하는지 확인한다.
mysql-secretary 컨테이너가 기동되지 않고, baron_support 연결 오류가 없는지 로그로 확인한다.
baron_support 전체 백업 후 DB/볼륨을 삭제한다. 이 작업은 별도 운영 승인 후에만 수행한다.

기존 로컬 mysql-secretary 컨테이너를 제거했다. 기존 볼륨은 삭제하지 않았다.
Secretary를 ABC MySQL에 연결해 재기동했고 /api/health가 200을 반환했다.
로컬 및 임시 빈 DB에서 alembic_version=0021_ticket_idempotency, support_users, support_tickets, support_attachments 생성을 확인했다.
로컬에서 Secretary → ABC 내부 identity-access API의 서비스 키 인증·응답 및 권한 조회 캐시를 확인했다.
API/Web typecheck 및 Web lint를 통과했다.

ticket_comments, 내부 메모, 승인 상태처럼 ABC 테이블과 1:1 대응하지 않는 Secretary 기능은 userfeedback DB의 지원 전용 테이블로 유지한다.
현재 작업 트리의 support-abc.ts, support-types.ts, workspace tickets API 변경은 진행 중인 표시번호 작업으로 보인다. 단일 DB 전환 시 덮어쓰지 않고 유지·검증한다.
데이터 삭제는 코드·배포 전환과 스테이징 검증이 완료된 후 별도 승인으로 수행한다.