baron_qa_write/docs/관리페이지 md 파일/제품-배포-및-EGBIM-데이터-이관-실행계획.md

# 제품 배포 및 EGBIM 데이터 이관 실행계획

## 1. 문서 목적

현재 상태를 다음과 같이 전제하고, 앞으로의 작업 순서와 의사결정 기준을 정리한다.

- 스테이징 배포 완료
- 스테이징 작성페이지에 EGBIM 홈페이지 UI를 적용하는 작업 진행 또는 검증 단계
- 관리페이지와 API 연동 구조 존재
- 제품 배포 파이프라인 설계 초안 작성 완료
- 기존 EGBIM 홈페이지 데이터는 아직 제품 데이터로 최종 이관하지 않음

이 문서의 목표는 다음과 같다.

1. 스테이징 기능을 제품 수준으로 안정화한다.
2. 같은 검증 결과를 사용해 product 환경으로 승격할 수 있는 배포 파이프라인을 완성한다.
3. 기존 EGBIM 데이터를 원본 보존·재실행·검증 가능한 방식으로 이관한다.
4. 내부 오픈 후 문제를 관찰하고, 외부 정식 오픈으로 안전하게 확장한다.

---

## 2. 먼저 결정할 최적의 전체 순서

권장 순서는 다음과 같다.

```text
현재 상태
  │
  ▼
1. 기준선 고정 및 제품 요구사항 확정
  │
  ▼
2. 스테이징 작성페이지·관리페이지·API 통합 검증
  │
  ▼
3. 진입 루트 설계 및 스테이징 적용
  │
  ▼
4. Product 배포 파이프라인 최소 운영 수준 구현
  │
  ▼
5. Product 작성페이지·관리페이지·API 적용
  │
  ▼
6. EGBIM 데이터 이관 설계 확정 및 도구 구현
  │
  ▼
7. 스테이징 Dry Run 및 전체 이관 검증
  │
  ▼
8. Product DB 백업 후 데이터 이관
  │
  ▼
9. 내부 오픈 및 관찰 운영
  │
  ▼
10. 외부 정식 오픈
```

### 이 순서를 권장하는 이유

- 작성페이지와 관리페이지의 데이터 계약이 확정되기 전에 이관하면, 기존 데이터의 필드·상태·첨부파일 매핑을 다시 수정해야 한다.
- 진입 루트를 먼저 확정하면 SSO callback URL, API base URL, CORS, cookie domain, reverse proxy 규칙을 product 배포 전에 검증할 수 있다.
- Product 배포 파이프라인을 먼저 최소 수준으로 구현해야 스테이징에서 검증한 동일 버전을 product에 재현할 수 있다.
- 데이터 이관은 기존 데이터를 변경하거나 중복 생성할 위험이 있으므로, 내부 오픈 직전에 한 번에 시도하기보다 스테이징에서 반복 가능한 방식으로 검증해야 한다.
- 내부 오픈은 최종 사용자 전체 오픈이 아니라 업무 담당자 중심의 제한된 검증 구간으로 사용해야 한다.

---

## 3. 단계별 실행 계획

### 0단계. 기준선 고정 및 오픈 범위 확정

가장 먼저 다음 내용을 문서로 확정한다.

- 스테이징과 product의 도메인·포트·환경변수·Secret 분리
- product에 적용할 commit SHA 또는 release tag
- product의 서비스 구성과 외부 연동 범위
- EGBIM 기존 데이터의 이관 기준일
- 내부 오픈 대상자와 권한
- 외부 정식 오픈 대상 서비스 및 오픈 시각
- 장애 발생 시 오픈 중단 기준

완료 조건:

- product 오픈에 필요한 기능 목록과 제외 기능이 합의됨
- 데이터 이관 기준일과 원본 데이터 보존 정책이 확정됨
- 스테이징에서 검증할 시나리오 목록이 확정됨

### 1단계. 스테이징 작성페이지·관리페이지·API 통합 안정화

EGBIM 홈페이지 UI를 적용한 작성페이지를 실제 사용자 흐름 기준으로 검증한다.

필수 검증 항목:

- 작성페이지 진입 및 로그인/비로그인 정책
- 필수값·선택값·HTML 본문·특수문자 처리
- 비밀글 정책
- 첨부파일 업로드·다운로드·실패 재시도
- 작성 완료 후 관리페이지 목록 노출
- 관리페이지 상세 조회
- 상태·중요도·담당자 변경
- 댓글과 내부 메모의 노출 범위
- 동일 요청 재전송 시 중복 생성 방지
- API 오류와 네트워크 오류 화면 처리

이 단계에서는 UI의 시각적 동일성만 확인하지 말고, EGBIM 화면이 보내는 데이터와 ABC API가 저장하는 데이터의 필드 매핑을 확정해야 한다.

### 2단계. 진입 루트 설계 및 스테이징 적용

권장 진입 구조는 다음과 같다.

```text
EGBIM 홈페이지
  ├─ Q&A 작성 → Product 작성페이지
  └─ 관리자 진입 → 통합 관리페이지

Product Web
  ├─ 내부 API BFF
  ├─ ABC API
  └─ Secretary API
```

결정할 항목:

- 기존 EGBIM URL에서 신규 작성페이지로 이동하는 방식
- 기존 URL의 redirect 여부와 유지 기간
- 관리자 URL과 일반 사용자 URL 분리
- SSO callback 및 logout URL
- `/support`, `/admin`, `/api` 등 경로 규칙
- reverse proxy에서 Web만 외부 공개할지 여부
- 기존 검색엔진 링크와 즐겨찾기 대응
- 잘못된 경로·권한 없는 경로·만료된 링크 처리

완료 조건:

- 스테이징 도메인에서 실제 진입·로그인·작성·관리 흐름이 끝까지 동작함
- callback URL, cookie, CORS, API route가 product 도메인 기준으로 변경 가능함
- URL 전환 시 기존 사용자가 어디로 이동하는지 명확함

### 3단계. Product 배포 파이프라인 구현

파이프라인 설계 초안을 다음 최소 운영 수준까지 구현한다.

```text
PR 검증
  ↓
lint · format · typecheck · unit/integration/E2E
  ↓
commit SHA 이미지 Build
  ↓
Registry Push
  ↓
staging 배포
  ↓
health check · smoke test
  ↓
승인
  ↓
동일 이미지 digest로 product 배포
```

현재 staging workflow는 소스를 SSH로 전송한 뒤 서버에서 다시 빌드한다. Product 배포에서는 다음을 우선 적용하는 것을 권장한다.

- CI에서 API·Web·Secretary API 이미지를 동일 commit 기준으로 빌드
- commit SHA 또는 release tag로 이미지 태깅
- staging과 product에서 동일 이미지 digest 사용
- 환경별 동시 배포 잠금
- 배포 전 필수 환경변수와 외부 연결 Preflight
- 배포 전 MySQL 전체 백업과 checksum 생성
- TypeORM과 Alembic Migration을 별도 one-shot job으로 직렬 실행
- API → Secretary API → Web 순서로 기동
- 배포 후 API·Redis·SSO·첨부파일·주요 업무 기능 Smoke Test
- commit SHA, 이미지 digest, migration revision, backup checksum 기록

완료 조건:

- 실패한 CI 결과가 product 배포로 넘어가지 않음
- product는 staging에서 검증한 동일 artifact를 사용함
- 이전 이미지와 DB 백업 식별자로 롤백 절차를 재현할 수 있음

### 4단계. Product 작성페이지·관리페이지·API 적용

Product 환경에는 개발 브랜치의 최신 소스를 직접 배포하지 않고, staging 검증을 통과한 release artifact만 승격한다.

적용 순서:

1. Product Secret·Variable 등록 및 값 검증
2. Product 도메인 기준 진입 루트·SSO callback 등록
3. Product DB 연결 Preflight
4. 백업 생성 및 checksum 확인
5. 필요한 Migration 실행
6. API 및 Secretary API 기동
7. 작성페이지와 관리페이지 기동
8. 제한된 운영 계정으로 Smoke Test
9. 내부 오픈 승인

### 5단계. EGBIM 기존 데이터 이관

데이터 이관은 작성페이지와 API의 필드 계약이 확정된 뒤 진행한다. 이관 완료 전까지 기존 EGBIM 원본은 읽기 전용 또는 보존 상태로 유지한다.

권장 방식은 다음 절의 “방안 A”이다.

### 6단계. 내부 오픈 및 관찰 운영

내부 오픈은 다음 대상부터 시작한다.

- 운영 담당자
- 관리자
- 개발·QA 담당자
- 제한된 내부 사용자

최소 관찰 기간 동안 다음을 확인한다.

- 작성 성공률
- API 4xx/5xx 비율
- 첨부파일 실패율
- SSO 로그인 실패율
- 관리자의 상태·담당자 변경 성공 여부
- 알림 전송 성공 여부
- 데이터 중복·누락 여부
- 응답시간과 컨테이너 재시작 여부

### 7단계. 외부 정식 오픈

내부 오픈에서 치명적 장애가 없고, 데이터 이관 검증이 완료된 뒤 외부 정식 오픈을 진행한다.

오픈 직전에는 다음을 다시 확인한다.

- 기존 URL의 redirect 및 안내문
- 외부 사용자의 작성 권한
- 개인정보·비밀글 노출 정책
- 첨부파일 저장소와 다운로드 권한
- 장애 공지 및 문의 대응 담당자
- 롤백 가능한 이전 이미지와 DB 백업

---

## 4. EGBIM 데이터 이관 권장 방안

### 방안 A. 읽기 전용 Export API + 중앙 Import Worker

#### 권장도: 가장 높음

기존 EGBIM 홈페이지 서버에 일회성 읽기 전용 Export API를 만들고, 중앙 시스템의 Import Worker가 페이지 단위로 데이터를 읽어 Product API 또는 내부 import service로 저장한다.

```text
기존 EGBIM
  │
  │ 인증된 읽기 전용 Export API
  ▼
Import Worker
  ├─ 필드·상태·사용자 매핑
  ├─ 첨부파일 다운로드
  ├─ checksum 검증
  └─ migration mapping 기록
  ▼
ABC API / Product DB / R2
```

#### 순차 실행 방법

##### A-1. 원본 데이터 목록과 범위 확정

- 게시글, 댓글, 첨부파일, 작성자, 상태, 작성일·수정일 목록화
- 이관 기준일 확정
- 삭제글·비밀글·관리자 메모의 이관 여부 결정
- 원본의 전체 건수와 첨부파일 개수 기록
- 원본 데이터의 시간대 확인

##### A-2. 매핑 규칙 확정

다음 매핑표를 먼저 확정하고 코드로 고정한다.

| 원본 EGBIM | Product/ABC | 결정 사항 |
|---|---|---|
| 게시글 번호 | `source_post_id` 또는 migration metadata | 원본 추적용으로 보존 |
| 게시글 제목·본문 | feedback title/content | HTML·줄바꿈·특수문자 처리 |
| 작성자 | ABC 사용자 식별자 | SSO ID, 이메일, 전화번호 우선순위 |
| 원본 상태 | feedback status | 상태 변환표 필요 |
| 비밀글 | `is_secret` 등 | 사용자·관리자 노출 정책 확인 |
| 댓글 | ABC 댓글 | 작성자와 작성일 보존 |
| 첨부파일 | attachment metadata + R2/local object | 파일 checksum 보존 |
| 프로젝트/채널 | Product project/channel | 고정 UUID 또는 이름 매핑 |

##### A-3. 원본 Export API 구축

예시:

```http
GET /api/migration/qna?cursor=...&limit=100
Authorization: Bearer <one-time-migration-token>
```

API는 다음 조건을 가져야 한다.

- 읽기 전용
- 일회성 토큰 또는 IP 제한
- cursor 기반 페이지네이션
- 게시글·댓글·첨부파일의 안정적인 원본 ID 제공
- `created_at`, `updated_at` 제공
- 재조회 가능한 정렬 기준 제공
- 요청 로그와 반환 건수 기록

첨부파일은 원본 API에서 직접 다운로드하거나, 인증된 임시 URL을 발급하는 방식으로 분리한다.

##### A-4. Import Worker 구현

Import Worker는 다음 정보를 모든 레코드에 남긴다.

- `source_system = EGBIM_QA`
- `source_post_id`
- `source_comment_id`
- `migration_batch_id`
- 원본 checksum
- 중앙 저장 ID
- 처리 상태: `PENDING`, `MIGRATED`, `FAILED`, `SKIPPED`
- 실패 메시지
- 최초 처리 시각과 최종 처리 시각

중복 방지를 위해 다음 키를 사용한다.

```text
source_system + source_entity_type + source_entity_id
```

같은 batch를 다시 실행해도 기존 레코드를 새로 만들지 않고 기존 mapping을 조회하도록 한다.

##### A-5. Staging Dry Run

실제 저장 없이 다음만 수행한다.

- 원본 건수 조회
- 필드 매핑 가능 여부 검사
- 사용자 식별 가능 여부 검사
- 상태 변환 가능 여부 검사
- 첨부파일 접근 가능 여부 검사
- HTML·특수문자·긴 본문 검사
- 누락·중복·미매핑 목록 생성

##### A-6. Staging 전체 이관

Dry Run 오류를 해결한 뒤 스테이징 DB에 전체 이관한다.

검증 항목:

- 원본 게시글 수 = Product 저장 게시글 수
- 원본 댓글 수 = Product 저장 댓글 수
- 원본 첨부파일 수 = Product 저장 첨부파일 metadata 수
- 샘플 제목·본문·작성자·상태 비교
- 원본 ID를 통해 Product 상세 페이지 추적 가능
- 첨부파일 다운로드 가능
- 같은 batch 재실행 시 중복이 생성되지 않음

##### A-7. Product 이관 전 백업

Product 이관 직전에 다음을 수행한다.

- `userfeedback` 전체 백업
- 백업 압축 및 암호화
- SHA-256 checksum 생성
- 첨부파일 저장소의 versioning 또는 별도 백업 확인
- 백업 복원 테스트 또는 최소한 파일 무결성 테스트
- 이관 시작 시각과 기준 commit 기록

##### A-8. Product 최종 이관

최종 이관은 다음 순서로 진행한다.

1. 기존 EGBIM 원본을 읽기 전용으로 전환
2. 이관 기준시각 기록
3. 기준시각 이전 데이터를 전체 이관
4. 이관 중 발생한 오류를 별도 실패 목록으로 분리
5. 건수·checksum·샘플 검증
6. 기준시각 이후 변경분이 있다면 증분 이관
7. 관리 담당자 승인
8. 신규 작성 경로를 Product로 전환
9. 기존 EGBIM에 안내문 또는 redirect 적용

#### 장점

- 원본 DB 스키마에 강하게 결합되지 않는다.
- 필요한 데이터만 Product 모델에 맞게 변환할 수 있다.
- 원본 ID와 중앙 ID의 mapping을 보존할 수 있다.
- 실패한 일부 batch만 재처리할 수 있다.
- 재실행 시 중복 방지가 쉽다.

#### 단점

- 원본 Export API 개발이 필요하다.
- 필드·상태·사용자·첨부파일 매핑 작업이 필요하다.
- 대량 첨부파일 이관 시간이 오래 걸릴 수 있다.

---

## 5. EGBIM 데이터 이관 대안

### 방안 B. 기존 DB Dump 후 ETL 변환

#### 방식

기존 EGBIM DB를 SQL dump로 백업한 뒤, 별도의 임시 MySQL에 복원한다. ETL 스크립트가 임시 DB에서 데이터를 읽어 Product의 ABC API 또는 import 테이블로 전달한다.

```text
기존 EGBIM DB
  ↓ SQL dump
임시 변환 DB
  ↓ ETL
Product import API / ABC DB
```

#### 순서

1. 원본 DB 전체 dump
2. dump checksum 생성
3. 임시 DB 복원
4. 원본 테이블 구조와 데이터 건수 확인
5. 변환 스크립트 실행
6. Product staging에 적재
7. 검증 및 보정
8. Product 백업 후 최종 적재

#### 장점

- 원본 Export API를 새로 만들 필요가 없다.
- 대량 데이터 추출이 빠르다.
- 원본 테이블을 직접 조회하므로 누락을 확인하기 쉽다.

#### 단점

- 기존 DB 스키마에 강하게 결합된다.
- 개인정보와 원본 전체 DB가 변환 서버에 복사된다.
- Product 스키마와 원본 스키마가 다르면 변환 로직이 복잡해진다.
- 운영 DB에 직접 SQL을 실행할 위험이 있다.
- 재실행·중복 방지·첨부파일 매핑을 별도로 구현해야 한다.

#### 적용 조건

- 원본 DB 접근 권한을 안전하게 확보할 수 있을 때
- Export API를 추가할 수 없을 때
- 원본 DB의 schema와 첨부파일 저장 위치를 정확히 파악했을 때

단순히 기존 SQL dump를 Product DB에 그대로 복원하는 방식은 권장하지 않는다. Product의 ABC·Secretary 스키마와 원본 EGBIM 스키마가 다르고, 데이터 소유권과 ID 체계도 다르기 때문이다.

### 방안 C. 파일 기반 Export(JSON/CSV + 첨부파일 묶음)

#### 방식

기존 EGBIM에서 게시글·댓글·사용자·첨부파일 metadata를 JSON 또는 CSV로 추출하고, 첨부파일은 별도 archive로 묶어 Import Worker에 전달한다.

```text
qna.json
comments.json
users.json
attachments-manifest.json
attachments.tar.gz
```

#### 순서

1. 추출 스크립트 작성
2. 파일별 schema와 encoding 확정
3. 각 파일 checksum 생성
4. 첨부파일 manifest 생성
5. staging Import Worker 실행
6. 검증 리포트 생성
7. Product 백업 후 최종 import

#### 장점

- 원본 시스템에 API를 추가하지 않아도 된다.
- 결과물을 보관하고 재검증하기 쉽다.
- 소규모·일회성 이관에 적합하다.
- 운영 DB에 지속적으로 접근하지 않아도 된다.

#### 단점

- 추출 시점 이후 변경분을 자동으로 반영하기 어렵다.
- 대용량 파일 전달·보관·암호화 관리가 필요하다.
- JSON/CSV 포맷이 원본 데이터의 모든 관계를 표현하지 못할 수 있다.
- 파일 재생성 시 원본과 결과의 동일성을 추적해야 한다.

#### 적용 조건

- 원본 데이터를 특정 시점에 동결할 수 있을 때
- 데이터 규모가 관리 가능한 수준일 때
- Export API를 운영할 수 없고, DB 직접 접근도 제한될 때

---

## 6. 데이터 이관 방안 비교 및 최종 결정

| 기준 | 방안 A: Export API + Worker | 방안 B: DB Dump + ETL | 방안 C: JSON/CSV 파일 Export |
|---|---:|---:|---:|
| 원본 스키마 결합도 | 낮음 | 높음 | 중간 |
| 대량 추출 성능 | 중간 | 높음 | 중간~높음 |
| 재실행·증분 이관 | 매우 좋음 | 구현 필요 | 제한적 |
| 개인정보 노출 범위 | 비교적 작음 | 큼 | 중간 |
| 원본 변경 추적 | 좋음 | 좋음 | 낮음 |
| 첨부파일 처리 | 좋음 | 별도 구현 | 별도 archive 필요 |
| 초기 개발 난이도 | 중간 | 높음 | 낮음~중간 |
| 운영 안전성 | 가장 좋음 | 주의 필요 | 보통 |

### 최종 권장안

방안 A를 기본으로 선택한다.

구체적으로는 다음 조합을 권장한다.

```text
원본: 읽기 전용 Export API
추출: cursor 기반 batch
변환: 별도 Import Worker
저장: Product 내부 import service 또는 ABC API
추적: migration_batches + migration_mappings
첨부파일: manifest·checksum 검증 후 R2 또는 승인된 저장소 업로드
재실행: source_system/source_entity_id 기준 idempotent 처리
```

단, 원본 EGBIM 서버에 Export API를 추가할 수 없는 경우에만 방안 C를 우선 검토하고, 원본 DB 접근이 불가피한 경우에 방안 B를 사용한다.

---

## 7. 이관 시 반드시 지켜야 할 원칙

### 원본 보존

- 원본 EGBIM DB와 첨부파일을 이관 완료 후 즉시 삭제하지 않는다.
- 최소한 이관 완료 및 외부 오픈 후 안정화 기간까지 보존한다.
- 원본 dump 또는 export 파일은 암호화하고 접근 권한을 제한한다.

### 멱등성

- 같은 데이터를 다시 실행해도 중복 생성되지 않아야 한다.
- 게시글, 댓글, 첨부파일 각각의 원본 식별자를 보존한다.
- 실패한 레코드만 재처리할 수 있어야 한다.

### 기준시각과 증분 이관

- 전체 이관 시작 전에 기준시각을 기록한다.
- 이관 중 원본이 계속 변경되면 기준시각 이후 변경분을 별도로 추출한다.
- 최종 전환 직전에 증분 이관을 한 번 더 실행한다.

### 첨부파일 무결성

- 파일명만 비교하지 않고 크기와 SHA-256 checksum을 비교한다.
- DB metadata와 실제 객체가 모두 존재하는지 확인한다.
- Product에서 다운로드 권한과 비밀글 접근 권한을 검증한다.

### 사용자 식별

- 이메일만으로 사용자를 무조건 병합하지 않는다.
- SSO 식별자, 기존 사용자 ID, 이메일, 전화번호 순으로 매칭 정책을 정한다.
- 매칭되지 않는 사용자는 임의 병합하지 말고 관리자 검토 목록으로 보낸다.

---

## 8. 단계별 Go/No-Go 기준

### Product 배포 전

- [ ] CI 전체 성공
- [ ] staging smoke test 성공
- [ ] product용 Secret·Variable 검증
- [ ] 이미지 commit SHA·digest 확정
- [ ] Migration 순서와 호환성 확인
- [ ] DB 백업 및 checksum 성공
- [ ] 롤백 이미지와 복원 백업 식별

### 데이터 이관 전

- [ ] 원본 전체 건수 확인
- [ ] 필드·상태·사용자·첨부파일 매핑 확정
- [ ] migration batch 식별자 발급
- [ ] staging dry run 성공
- [ ] staging 전체 이관 성공
- [ ] 재실행 시 중복 없음 확인
- [ ] 첨부파일 checksum 검증 성공

### 내부 오픈 전

- [ ] Product 최종 이관 성공
- [ ] 이관 전후 건수 비교 완료
- [ ] 샘플 상세·댓글·첨부파일 확인
- [ ] 관리자 로그인 및 권한 확인
- [ ] 기존 EGBIM 링크의 이동 정책 적용
- [ ] 로그·모니터링·장애 대응 담당자 확정

### 외부 정식 오픈 전

- [ ] 내부 오픈 관찰 기간 종료
- [ ] 치명적 오류와 데이터 누락 없음
- [ ] 작성·조회·관리·첨부파일 주요 흐름 정상
- [ ] 고객 안내 및 문의 대응 준비
- [ ] 기존 시스템 read-only/redirect 정책 확정
- [ ] 오픈 당일 담당자와 중단 기준 확보

---

## 9. 최종 실행 순서 요약

```text
1. 제품 범위·데이터 기준일·오픈 정책 확정
2. 스테이징 작성페이지와 관리페이지의 전체 업무 흐름 검증
3. 진입 루트·SSO callback·redirect·reverse proxy 적용
4. CI 결과가 배포를 통제하도록 Product pipeline 보완
5. staging 검증 artifact로 Product 작성/관리 기능 배포
6. EGBIM Export API와 Import Worker 구현
7. staging Dry Run → 전체 이관 → 재실행 검증
8. Product DB·첨부파일 백업 및 checksum 확인
9. EGBIM 원본 read-only 전환
10. Product 최종 전체 이관
11. 기준시각 이후 변경분 증분 이관
12. 내부 오픈 및 모니터링
13. 안정화 확인 후 외부 정식 오픈
```

최종적으로는 “기존 DB를 Product DB에 그대로 복원”하는 방식보다, 원본을 읽기 전용으로 유지하면서 Export API와 Import Worker를 통해 Product의 정식 데이터 모델로 변환하는 방식을 채택하는 것이 가장 안전하다.

---

## 10. 운영 중인 EGBIM 홈페이지의 데이터 이관 전략

### 10.1 현재 상황에 대한 전제

`eg-bim.com`은 현재 사용자가 계속 Q&A를 작성하는 운영 서비스이고, Q&A 플랫폼이 정식 운영되면 기존 홈페이지는 폐쇄할 예정이다.

따라서 이관의 핵심 문제는 단순한 Dump 방식 선택이 아니다.

```text
이관 시작 후에도 원본에 신규 글·수정·댓글·첨부파일이 계속 발생함
        ↓
이관 데이터와 실제 원본 데이터 사이에 시간 차이가 발생함
        ↓
최종 전환 시점의 누락·중복·충돌을 처리해야 함
```

이번 프로젝트는 기존 홈페이지를 장기간 공존시키는 사업이 아니라, 기존 운영 시스템을 Product로 교체하는 사업이다. 그러므로 복잡한 실시간 양방향 연동을 영구적으로 구축하기보다, **전환 시점의 데이터 정합성을 확보하는 일회성 이관**에 집중하는 것이 적절하다.

### 10.2 최종 권장안

다음 방식을 권장한다.

```text
1. 평상시: 기존 EGBIM은 계속 운영
2. 사전 준비: 반복 가능한 이관 도구와 staging 검증 완료
3. 전환 직전: 기존 EGBIM의 신규 Q&A 작성 일시 중지
4. 원본을 read-only로 전환
5. 최종 Dump/Export 및 첨부파일 백업
6. Product로 변환·적재
7. 건수·본문·댓글·첨부파일 검증
8. Product 작성페이지를 오픈
9. 기존 EGBIM은 일정 기간 read-only 또는 redirect로 유지
10. 안정화 후 기존 홈페이지 폐쇄
```

핵심은 “운영 중에 계속 실시간 복제하다가 어느 순간 끊는 방식”이 아니라, **이관 준비는 운영 중에 수행하고 실제 최종 데이터 확정만 짧은 점검 시간에 수행하는 방식**이다.

### 10.3 권장 전환 절차

#### T-14일 ~ T-7일: 사전 이관 준비

- Product의 프로젝트·채널·상태·사용자 매핑 확정
- 기존 EGBIM 데이터 전체 목록과 첨부파일 목록 생성
- Export API 또는 파일 Export 도구 구축
- Import Worker와 mapping 테이블 구축
- staging에 과거 전체 데이터 이관
- staging에서 재실행해도 중복이 생기지 않는지 검증
- 원본과 Product의 건수·샘플·첨부파일 checksum 비교
- Product 배포 및 롤백 절차 검증

이 단계에서는 기존 EGBIM의 신규 작성 기능을 막지 않는다. 운영 데이터에 영향을 주지 않는 읽기 전용 추출만 수행한다.

#### T-3일 ~ T-1일: 최종 전환 리허설

- 실제 운영 데이터와 동일한 규모로 이관 시간 측정
- Dump/Export부터 Product 적재까지 걸리는 시간 측정
- 실패 batch 재처리 시간 측정
- 첨부파일 업로드 시간과 저장소 용량 확인
- 최종 점검 시간에 처리 가능한지 확인
- 오픈 당일 담당자와 의사결정권자 확정

최종 이관 시간이 허용 가능한 점검 시간보다 길다면, 그때만 증분 동기화 또는 CDC 도입을 검토한다.

#### T-0: 작성 중지 및 최종 이관

1. 기존 EGBIM에 점검 공지 노출
2. 신규 Q&A 작성·수정·댓글·첨부파일 등록 중지
3. 기존 글 조회는 허용하거나 점검 안내 화면으로 전환
4. 관리자도 데이터 수정 작업을 중지
5. 원본 DB와 첨부파일 전체 백업
6. 백업 파일 checksum 기록
7. 최종 Export/Dump 실행
8. Product import 실행
9. 원본과 Product의 건수 및 샘플 비교
10. 실패 레코드가 없거나 승인된 예외 목록에만 존재하는지 확인
11. Product 작성페이지와 관리페이지 Smoke Test
12. Product의 신규 작성 기능 활성화
13. 기존 EGBIM을 read-only 또는 redirect로 전환

신규 작성 중지는 가능한 한 짧게 유지하되, 이관 결과 검증이 끝나기 전에는 기존 시스템과 Product 양쪽에서 동시에 신규 작성을 허용하지 않는다.

#### T+1일 ~ 안정화 기간: 기존 홈페이지 보존

기존 홈페이지를 즉시 삭제하지 않는다.

- 기존 도메인은 Product 안내 또는 redirect로 유지
- 원본 DB와 첨부파일은 보존
- 관리자용 read-only 조회 경로 유지
- 이관 누락·오류 문의에 대응
- 안정화 기간 종료 후 별도 승인으로 폐쇄

### 10.4 운영 중 연동 방식별 선택지

#### 방안 A. 작성 중지 후 최종 Dump/Export

##### 권장도: 가장 높음

운영 중에는 사전 추출과 staging 검증만 수행하고, 최종 전환 시점에만 작성 기능을 잠시 막은 뒤 최종 데이터를 이관한다.

```text
운영 중
  └─ 사전 추출·리허설·검증

전환 시점
  └─ 작성 중지 → 최종 추출 → Product 적재 → 검증 → 오픈
```

장점:

- 데이터 기준시점이 명확하다.
- 신규 글 누락과 동시 수정 충돌을 방지할 수 있다.
- 실시간 동기화 시스템을 새로 운영하지 않아도 된다.
- 기존 홈페이지를 폐쇄할 계획과 가장 잘 맞는다.
- 장애 발생 시 기존 홈페이지를 다시 read-only 기준으로 사용할 수 있다.

단점:

- 최종 이관 시간 동안 작성 기능을 중지해야 한다.
- 최종 Dump/Import가 점검 시간 안에 끝나야 한다.
- 이관 중 Product 오픈이 지연되면 작성 중지 시간이 늘어날 수 있다.

이 방식은 “기존 홈페이지 폐쇄 전환”이라는 현재 상황에 가장 적합하다.

#### 방안 B. 초기 이관 + 실시간 또는 준실시간 API 증분 연동

##### 권장도: 조건부

기존 EGBIM을 계속 운영하면서 다음 조건의 데이터를 주기적으로 Product로 보낸다.

```text
1. 전체 초기 이관
2. updated_at 또는 cursor 기준 증분 조회
3. 신규 글·수정 글·댓글·첨부파일 전송
4. 최종 전환 시점에 마지막 증분 동기화
5. 기존 EGBIM 작성 중지
6. Product를 최종 오픈
```

필요 조건:

- 원본에 안정적인 `id`, `created_at`, `updated_at`이 있어야 함
- 삭제 또는 비공개 변경을 알 수 있는 tombstone 또는 변경 이력 필요
- 댓글·첨부파일도 증분 조회 가능해야 함
- 원본과 Product의 mapping 및 idempotency key 필요
- API 재시도와 순서 뒤바뀜을 처리해야 함
- 마지막 증분 처리 완료 여부를 확인해야 함

장점:

- 작성 중지 시간을 짧게 줄일 수 있다.
- 최종 이관량이 작아진다.
- Product 전환 직전까지 데이터를 따라갈 수 있다.

단점:

- 단순 API 호출이 아니라 동기화 시스템이 필요하다.
- 수정·삭제·비밀글 변경·첨부파일 변경을 모두 처리해야 한다.
- 원본과 Product의 상태가 잠시 불일치할 수 있다.
- 동기화 오류를 감시하고 재처리해야 한다.
- 기존 홈페이지를 폐쇄하는 일회성 프로젝트에 비해 개발·운영 비용이 크다.

이 방식은 최종 Dump/Import 시간이 너무 길거나, 작성 중지를 거의 허용할 수 없을 때 선택한다. 단순히 “글 목록을 주기적으로 호출”하는 수준은 운영 이관 방식으로 충분하지 않다.

#### 방안 C. 원본과 Product의 Dual Write

##### 권장도: 낮음

기존 EGBIM에 글이 작성될 때 기존 DB와 Product API에 동시에 저장한다.

장점:

- 새로 작성되는 데이터를 거의 실시간으로 반영할 수 있다.
- 최종 전환 시 신규 데이터량이 적다.

단점:

- 두 시스템 중 한 곳만 성공하는 부분 실패가 발생할 수 있다.
- 재시도·보상 처리·순서 보장·중복 방지가 필요하다.
- 기존 홈페이지 코드를 크게 수정해야 한다.
- Product API 장애가 기존 EGBIM 작성 장애로 전파될 수 있다.
- 기존 시스템을 폐쇄할 예정이므로 투자 대비 활용 기간이 짧다.

따라서 이번 프로젝트에서는 사용하지 않는 것을 권장한다. Dual Write가 꼭 필요하다면 직접 API를 두 번 호출하지 말고, 원본에 Outbox 이벤트를 기록한 뒤 비동기 Worker가 Product로 전달하는 구조를 사용해야 한다.

### 10.5 Dump와 실시간 연동의 최종 판단 기준

다음 기준으로 결정한다.

| 판단 기준 | Dump + 작성 중지 | 증분 API 연동 |
|---|---:|---:|
| 최종 이관 시간이 짧음 | 적합 | 과도함 |
| 몇 시간의 작성 중지가 가능함 | 적합 | 필요 없음 |
| 원본 폐쇄 예정 | 매우 적합 | 장기 운영 비용 과다 |
| 작성 중지를 거의 허용할 수 없음 | 부적합 | 적합 |
| 삭제·수정 이력 제공이 불완전함 | 적합 | 위험 |
| 첨부파일이 많고 처리 시간이 김 | 사전 리허설 필요 | 조건부 적합 |
| 원본 API 개발이 어려움 | 파일/DB Export로 가능 | 부적합 |

현재 주어진 조건에서는 다음과 같이 결정한다.

> **방안 A를 기본으로 채택한다.**
> 운영 중에는 이관 도구를 만들고 staging에서 반복 검증한다. Product 정식 전환 시점에는 EGBIM의 작성 기능을 일시 중지하고, 최종 Dump/Export 후 Product 검증을 완료한 뒤 신규 작성을 Product로 전환한다.

### 10.6 최종 이관을 위한 최소 데이터 모델

최종 이관은 단순히 게시글을 INSERT하는 작업으로 만들지 않는다. 최소한 다음 추적 정보를 남긴다.

```text
migration_batch
  ├─ batch_id
  ├─ source_system
  ├─ snapshot_started_at
  ├─ snapshot_completed_at
  ├─ source_cutoff_at
  ├─ source_total_count
  ├─ imported_count
  ├─ failed_count
  └─ checksum

migration_mapping
  ├─ batch_id
  ├─ source_entity_type
  ├─ source_entity_id
  ├─ target_entity_id
  ├─ source_checksum
  ├─ status
  ├─ error_message
  └─ processed_at
```

이 구조가 있어야 다음이 가능하다.

- 어떤 원본 글이 Product의 어느 ID가 되었는지 추적
- 실패한 글만 재처리
- 같은 Dump를 다시 실행해도 중복 방지
- 이관 결과를 원본 건수와 비교
- 폐쇄 후에도 원본과 Product의 연결 관계 확인

### 10.7 권장 운영 정책

- 최종 이관일에는 기존 EGBIM에 신규 작성 중지 안내를 사전에 공지한다.
- 작성 중지와 동시에 신규 작성뿐 아니라 댓글·첨부파일 등록도 중지한다.
- 최종 이관 중 기존 데이터를 수정할 수 없게 한다.
- Product 검증 완료 전에는 기존 EGBIM을 삭제하지 않는다.
- Product 오픈 후에도 기존 도메인과 원본 백업을 보존한다.
- 기존 홈페이지 폐쇄는 Product 오픈과 별도의 승인 작업으로 처리한다.
- 이관 실패 시 원본을 다시 쓰기 가능 상태로 복구할 수 있어야 한다.

### 10.8 업데이트된 최종 실행 순서

```text
1. Product 기능·API·진입 루트 확정
2. 이관 도구 구현
3. 운영 중 원본에서 staging으로 반복 Dry Run
4. 실제 데이터 규모 기준 이관 시간 측정
5. Product 배포 pipeline과 rollback 검증
6. 최종 전환 일정 공지
7. EGBIM 작성·수정·댓글·첨부파일 등록 중지
8. 원본 read-only 전환 및 최종 Dump/Export
9. Product DB·첨부파일 백업 확인
10. Product import 실행
11. 건수·checksum·샘플·첨부파일 검증
12. Product 신규 작성 활성화
13. 기존 EGBIM read-only/redirect 유지
14. 내부 오픈 및 안정화 관찰
15. 외부 정식 오픈
16. 안정화 기간 종료 후 기존 EGBIM 폐쇄
```