b24014/baron_qa_write

Fork 0

Files

T

root 3c10478482

Deploy EG-BIM QA Gateway / deploy (push) Successful in 2m4s

Details

관리페이지 데이터 전송 구현

2026-09-21 14:46:36 +09:00

32 KiB

Raw Blame History

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

1. 문서 목적

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

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

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

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

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

권장 순서는 다음과 같다.

현재 상태
  │
  ▼
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단계. 진입 루트 설계 및 스테이징 적용

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

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 배포 파이프라인 구현

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

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만 승격한다.

적용 순서:

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

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로 저장한다.

기존 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 구축

예시:

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
실패 메시지
최초 처리 시각과 최종 처리 시각

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

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 최종 이관

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

기존 EGBIM 원본을 읽기 전용으로 전환
이관 기준시각 기록
기준시각 이전 데이터를 전체 이관
이관 중 발생한 오류를 별도 실패 목록으로 분리
건수·checksum·샘플 검증
기준시각 이후 변경분이 있다면 증분 이관
관리 담당자 승인
신규 작성 경로를 Product로 전환
기존 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 테이블로 전달한다.

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

순서

원본 DB 전체 dump
dump checksum 생성
임시 DB 복원
원본 테이블 구조와 데이터 건수 확인
변환 스크립트 실행
Product staging에 적재
검증 및 보정
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에 전달한다.

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

순서

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

장점

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

단점

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

적용 조건

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

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

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

최종 권장안

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

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

원본: 읽기 전용 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. 최종 실행 순서 요약

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 방식 선택이 아니다.

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

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

10.2 최종 권장안

다음 방식을 권장한다.

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: 작성 중지 및 최종 이관

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

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

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

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

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

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

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

권장도: 가장 높음

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

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

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

장점:

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

단점:

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

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

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

권장도: 조건부

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

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하는 작업으로 만들지 않는다. 최소한 다음 추적 정보를 남긴다.

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 업데이트된 최종 실행 순서

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 폐쇄

32 KiB Raw Blame History

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

1. 문서 목적

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

이 순서를 권장하는 이유

3. 단계별 실행 계획

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

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

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

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

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

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

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

7단계. 외부 정식 오픈

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

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

권장도: 가장 높음

순차 실행 방법

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

A-2. 매핑 규칙 확정

A-3. 원본 Export API 구축

A-4. Import Worker 구현

A-5. Staging Dry Run

A-6. Staging 전체 이관

A-7. Product 이관 전 백업

A-8. Product 최종 이관

장점

단점

5. EGBIM 데이터 이관 대안

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

방식

순서

장점

단점

적용 조건

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

방식

순서

장점

단점

적용 조건

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

최종 권장안

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

원본 보존

멱등성

기준시각과 증분 이관

첨부파일 무결성

사용자 식별

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

Product 배포 전

데이터 이관 전

내부 오픈 전

외부 정식 오픈 전

9. 최종 실행 순서 요약

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

10.1 현재 상황에 대한 전제

10.2 최종 권장안

10.3 권장 전환 절차

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

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

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

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

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

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

권장도: 가장 높음

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

권장도: 조건부

방안 C. 원본과 Product의 Dual Write

권장도: 낮음

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

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

10.7 권장 운영 정책

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

32 KiB

Raw Blame History