egbim_qa_platform/docs/ssot-feedback-rearchitecture-tasks.md

피드백 SSOT 구조 개편 Task

추가 진행 메모 (2026-08-20): ABC 채널의 feedback_status 6단계 필드를 사용하도록 목록·상세·칸반 상태 변경을 연결했다. 댓글은 ABC feedback_comments로 저장하고 is_internal로 공개 댓글과 내부 메모를 분리했으며, 댓글 BFF는 세션 사용자·테넌트 기준 수정/삭제 권한을 검증한다. ABC 워크스페이스의 댓글 첨부파일은 Secretary로 중복 저장하지 않도록 명시적으로 차단했다.

추가 진행 메모 (2026-08-20): ABC 댓글 CRUD와 댓글 첨부파일 메타데이터/업로드 API를 구현했다. 첨부파일은 채널의 R2 설정을 사용해 private object로 저장하고 5분 만료 presigned URL로 조회한다. 로컬 egbim 채널에 R2 설정을 저장하고 연결 검증을 완료했다.

추가 진행 메모 (2026-08-20): 활성 Secretary 댓글 11건(공개 댓글 4건, 내부 메모 7건)과 댓글 첨부파일 4건을 ABC DB/R2로 이전했다. 이전 스크립트는 중복 실행 시 기존 데이터를 건너뛴다.

진행 메모 (2026-08-20): ABC에 저장된 관리자 필드(IP, MAC_address, Category)를 사용자 작성 폼의 ip_address, mac_address, category로 매핑했다. Category는 ABC의 선택 옵션을 그대로 표시하고, 생성·수정·상세 조회가 ABC API를 사용하도록 연결했다. Secretary fallback 제거와 인증 기반 requester 처리 등 전체 SSOT 전환은 계속 진행 중이다. 추가 진행 메모: ABC의 IP/MAC/Category 및 requester 메타데이터를 사용자 폼·단일 BFF에 연결했고, 인증 requester/tenant와 소유권 검증을 적용했다. 사용자 페이지의 테스트 상수와 support-stub 타입 의존성은 제거했다. 상태 변경은 Secretary가 아니라 ABC의 feedback_status 필드를 통해 처리한다.

1. 목표

피드백 데이터의 원본을 ABC API/DB 한 곳으로 통일한다.

관리자 콘솔과 사용자 피드백 페이지는 동일한 ABC API를 사용하고, 사용자 페이지는 데이터 저장소나 자체 fallback 데이터를 갖지 않는 API 클라이언트로 동작한다.

ABC API/DB
  └─ 피드백 데이터의 유일한 원본(SSOT)

관리자 콘솔
  └─ ABC API를 통한 조회·관리 화면

사용자 피드백 페이지
  └─ ABC API를 통한 조회·작성·수정·삭제 화면

Secretary API
  └─ SSO·접근권한·운영 보조 기능

관리자 콘솔 화면 자체가 원본은 아니며, 콘솔이 사용하는 ABC API/DB가 원본이다.

2. 현재 문제

• 피드백이 Secretary DB와 ABC DB에 중복 저장됨
• 사용자 페이지의 Next.js API route에 support-stub fallback이 존재함
• 폼 템플릿 원본이 Secretary DB와 로컬 stub으로 분산됨
• 사용자 작성 시 테스트용 requester/tenant 값이 사용됨
• IP/MAC이 Secretary의 extra_fields에만 저장되고 ABC 피드백 원본에는 전달되지 않음
• 사용자 페이지와 관리자 콘솔이 서로 다른 데이터 경로를 사용할 수 있음
• Secretary 저장 성공과 ABC 저장 성공 사이의 데이터 불일치 가능성이 있음

3. SSOT 정책

ABC API/DB가 보유하는 원본 데이터

• 피드백 ID
• 제목 및 내용
• 작성자 및 작성자 연락처
• 카테고리
• 비밀글 여부
• 첨부파일 및 첨부파일 메타데이터
• IP 주소 및 MAC 주소
• 피드백 중요도
• 피드백 처리 상태
• 생성일 및 수정일
• 이슈 연결 정보
• 관리자 댓글 및 내부 메모

피드백 상태와 이슈 상태는 서로 다른 필드와 생명주기로 관리한다. 이슈 상태를 피드백 상태의 원본으로 사용하지 않는다.

Secretary API가 보유할 수 있는 데이터

• SSO 인증 및 접근권한
• 사용자·워크스페이스 접근 설정
• 운영에 필요한 보조 매핑

Secretary DB에 피드백 원본을 복제 저장하지 않는다. 불가피한 매핑이 필요한 경우 abc_feedback_id를 외래 식별자로 사용하고, 피드백 제목·내용·상태를 별도로 저장하지 않는다.

4. 단계별 Task

Phase 1. 데이터 및 API 설계

• 현재 ABC 피드백 엔티티, 관리자 필드 설정, 채널 필드 구조 확인
• 피드백 원본 필드 목록 확정
• IP 주소 및 MAC 주소 저장 방식 확정
• 중요도 옵션과 색상 메타데이터 확정
• 피드백 6단계 상태 코드 및 표시명 확정
• 피드백 상태와 이슈 상태의 독립성 확인
• 댓글과 내부 메모의 저장 위치 및 공개 범위 확정 (ABC feedback_comments; is_internal=false/true)
• 사용자용 API와 관리자용 API의 권한 범위 정의
• 피드백 CRUD API 계약서 및 응답 DTO 작성
• 페이지네이션, 정렬, 검색, 상태 필터 API 규격 확정
  • ABC 검색 API: POST /api/v2/projects/:projectId/channels/:channelId/feedbacks/search
  • 요청: page, limit, sort, queries, operator
  • 관리자 목록: ABC 네이티브 응답의 meta 기준 페이지 이동, 사용자 목록: BFF 응답을 10건 단위로 표시
  • 상태 필터: feedback_status 필드 query, 이슈 상태 필터와 분리

Phase 2. ABC 백엔드에 원본 기능 구현

• 피드백 엔티티에 IP 주소 필드 추가
• 피드백 엔티티에 MAC 주소 필드 추가
• 피드백 엔티티에 중요도 필드 추가
• 피드백 엔티티에 피드백 상태 필드 추가
• 댓글·내부 메모 저장 구조 추가 (ABC feedback_comments 테이블 및 API)
• 댓글 첨부파일 메타데이터·R2 저장/삭제/서명 URL API 추가 (feedback_comment_attachments)
• 이슈 연결 관계와 피드백 상태를 별도 필드로 유지
• 피드백 필드는 데이터베이스 migration 불필요 확인 (ABC JSON 데이터 + 채널 필드 설정 사용; 댓글은 별도 feedback_comments migration 적용)
• 사용자 작성 API 구현
• 사용자 조회 API 구현
• 사용자 수정 API 구현
• 사용자 삭제 API 구현
• 관리자 상세 조회 API에 모든 피드백 필드 포함
• 관리자 수정 API에 IP/MAC·중요도·피드백 상태 포함
• API에서 requester/tenant를 인증 정보 또는 안전한 요청 정보로 처리
• 첨부파일 처리와 피드백 원본의 연결 보장
• 중복 생성 방지를 위한 idempotency 또는 중복 요청 검증 추가

Phase 3. 관리자 콘솔 개편

• 관리자 피드백 목록이 ABC API만 조회하도록 통일
• 관리자 피드백 상세에 IP 주소와 MAC 주소 표시
• 관리자 수정 화면에서 IP 주소와 MAC 주소 표시·수정
• 중요도 옵션 및 배경색 표시
• 피드백 6단계 상태 및 배경색 표시
• 칸반 드래그 시 ABC API의 피드백 상태만 변경
• 이슈 상태는 이슈 API를 통해 별도로 변경
• 피드백과 이슈 상태가 서로 덮어쓰지 않는지 확인
• 댓글과 내부 메모의 저장 API 분리
• 내부 메모가 외부 댓글로 복제되지 않도록 보장 (is_internal 분리 및 ABC 워크스페이스 Secretary 첨부댓글 경로 차단)
• 목록의 페이지네이션·정렬·필터를 ABC API 기준으로 통일 (관리자 native search; 사용자 BFF의 정렬·검색·10건 페이지)
• fallback 또는 임시 데이터가 표시되지 않도록 처리 (ABC 워크스페이스는 오류 응답; 비-ABC 호환 경로만 유지)

Phase 4. 사용자 피드백 페이지 개편

• 작성 페이지에서 관리자 필드 설정을 ABC API로 조회
• 페이지 내부의 support-stub 의존성 제거
• 페이지 내부의 테스트용 requester/tenant 상수 제거
• 사용자 인증 정보로 작성자 정보 처리
• 작성 요청을 ABC API로 직접 전달하거나 단일 BFF를 통해 전달
• 제목·내용·카테고리·비밀글·IP·MAC·첨부파일을 ABC API에 저장
• 사용자 본인이 작성한 피드백 목록을 ABC API로 조회
• 사용자 피드백 상세를 ABC API로 조회
• 사용자 수정·삭제 권한 검증
• 접근 불가·존재하지 않는 피드백에 대한 오류 처리
• API 오류 시 stub 데이터로 대체하지 않고 명확한 오류 표시
• 작성 성공 후 ABC 피드백 ID 기준으로 상세 또는 목록 이동

Phase 5. Secretary API 정리

• ABC 매핑 워크스페이스의 Secretary 피드백 생성·복제 경로 비활성화 (비-ABC 호환 경로는 별도 유지)
• ABC 매핑 워크스페이스의 SupportTicket 피드백 원본 중복 저장 제거 (BFF는 abc_feedback_id로 합성)
• 기존 매핑은 abc_feedback_id 중심으로 사용
• ABC 매핑 워크스페이스에서 Secretary는 SSO·접근권한·운영 보조 API로만 사용
• ABC 매핑 워크스페이스에서 Secretary 피드백 제목·내용·상태 수정 경로 차단
• ABC 매핑 워크스페이스의 기존 Secretary 기반 사용자 페이지 API route를 ABC BFF로 전환
• support-stub.ts fallback 제거
• ABC 매핑 워크스페이스 장애 시 임의 데이터가 노출되지 않도록 오류 응답 처리

Phase 6. 기존 데이터 이전

• Secretary DB의 피드백 원본·댓글 데이터 목록 read-only inventory (로컬: 매핑 티켓 11건, 댓글/내부메모 14건)
• ABC DB에 이미 존재하는 피드백과 매핑 확인 (로컬 ABC 피드백 27건, Secretary 매핑 11건)
• 활성 매핑 댓글 11건 및 댓글 첨부파일 4건을 ABC DB/R2로 idempotent 이전
• 이전 실행 전 Secretary/ABC 백업 승인 및 백업
• 누락된 ABC 피드백 생성 또는 이전 스크립트 작성
• IP/MAC·중요도·상태·댓글·내부 메모 이전 범위 확정 (댓글/내부메모 14건 및 댓글 첨부파일 4건의 ABC 저장 방식·중복 처리 기준 결정 필요)
• 중복 피드백 병합 기준 확정
• abc_feedback_id 매핑 검증
• 이전 전 Secretary DB와 ABC DB 백업
• staging에서 migration dry-run
• 이전 후 건수·ID·내용·상태 대조
• 이전 완료 후 Secretary 중복 데이터 읽기 차단

Phase 7. 테스트

API 테스트

• 관리자 피드백 목록·상세 조회
• 사용자 피드백 작성
• 사용자 피드백 조회
• 사용자 피드백 수정
• 사용자 피드백 삭제
• IP/MAC 저장 및 조회
• 중요도 저장 및 조회
• 피드백 6단계 상태 변경
• 이슈 상태와 피드백 상태의 독립 변경
• 첨부파일 저장 및 조회
• 댓글과 내부 메모 분리
• 권한 없는 사용자의 수정·삭제 차단
• 중복 요청 방지

화면 테스트

• 관리자 콘솔과 사용자 페이지의 제목·내용·상태·중요도 일치
• 작성 후 관리자 콘솔에 즉시 표시
• 관리자 수정 후 사용자 페이지에 동일하게 표시
• IP/MAC이 관리자 상세에서 표시
• 사용자에게 내부 메모가 노출되지 않음
• 10개 단위 페이지네이션 및 마지막 페이지 이동
• 리스트/칸반 조회 결과 일치
• 칸반 드래그 상태 변경 결과가 목록에도 반영
• API 장애 시 stub 데이터가 노출되지 않음

Phase 8. 배포 및 운영 검증

• staging DB 백업
• migration 적용
• staging API 배포
• staging Web 배포
• Secretary API의 변경된 권한·매핑 검증
• 관리자 로그인 후 피드백 조회
• 일반 사용자 로그인 후 피드백 작성
• 작성 데이터가 ABC 관리자 콘솔에 표시되는지 확인
• 관리자 수정 결과가 사용자 페이지에 반영되는지 확인
• 브라우저 Console 및 Network 오류 확인
• API 응답 401/403/404/500 확인
• 데이터 건수 및 원본 ID 대조

5. 완료 기준

다음 조건을 모두 만족해야 SSOT 개편 완료로 판단한다.

• 피드백 원본 데이터가 ABC API/DB 한 곳에만 존재한다.
• 관리자 콘솔과 사용자 페이지가 동일한 피드백 API를 조회한다.
• 사용자 페이지에 실제 데이터용 stub/fallback이 없다.
• Secretary DB에 피드백 제목·내용·상태를 중복 저장하지 않는다.
• IP/MAC·중요도·피드백 상태·이슈 연결 정보가 관리자 콘솔에서 조회된다.
• 피드백 상태와 이슈 상태가 독립적으로 처리된다.
• 사용자 작성·수정·삭제 결과가 관리자 콘솔에 동일하게 반영된다.
• 관리자 수정 결과가 사용자 페이지에 동일하게 반영된다.
• 내부 메모가 사용자에게 노출되지 않는다.
• 데이터 이전 후 중복·누락·불일치가 없다.

6. 주의사항

• 운영 또는 staging DB에서 down -v를 실행하지 않는다.
• 기존 데이터 이전 전 DB 백업을 확보한다.
• ABC DB를 원본으로 전환하기 전 Secretary 기반 작성 API를 동시에 활성화하지 않는다.
• migration 적용 순서와 기존 데이터의 abc_feedback_id 매핑을 먼저 검증한다.
• ABC API 장애 시 임시 데이터를 노출하지 말고 오류 상태를 사용자에게 표시한다.