클라우드를 옮겨도 서비스는 계속: 쓰기 DB를 하나로 두는 이전 설계

이미 사용자가 있는 서비스를 다른 클라우드로 옮기는 일은 복사로 끝나지 않습니다. 같은 이름의 리소스라도 권한, 오류, 재시도의 의미가 다르고, 전환하는 순간에도 요청은 계속 들어옵니다.

저는 SoftBank Hackathon 2026 본선 팀 과제로 이 문제를 다루는 플랫폼을 설계하고 있습니다. 기준은 이렇습니다. 전환 중에 요청이 잠깐 기다리는 건 허용하되, 전환 때문에 요청이 실패하거나, 성공 응답한 쓰기가 사라지거나, 같은 요청이 두 번 처리되는 일은 0건을 목표로 합니다. 이 글은 그 기준을 지키기 위한 구조와 전환 순서를 정리한 설계안입니다.

먼저 범위를 밝힙니다. 아래 구조와 순서는 2026년 10월 31일에 제가 AI(Codex)와 논의해 정한 설계입니다. 설명 사이트와 글 끝 모형의 문구는 Codex가, 구성도와 영상은 Claude Code가 제 지시로 만들었습니다. 구성도에는 archify를, 영상에는 Remotion을 썼고, 일러스트는 ChatGPT 이미지 생성으로 만들었습니다. 실제 계정 연결, CDC(변경된 데이터만 따라 보내는 복제 방식), 전환, 롤백은 아직 구현하거나 측정하지 않았습니다. 글에 나오는 숫자는 측정값이 아니라 목표입니다.

위 그림은 ChatGPT 이미지 생성으로 만든 설명용 일러스트입니다. 실제 화면이나 측정 결과가 아닙니다.

복사보다 먼저, 차이를 이해합니다

이전은 네 단계로 나눴습니다.

1. 구성 수집: 클라우드 설정 내보내기(Export) 결과, 클라우드 API, 소스 코드, 환경 변수를 함께 읽습니다. 권한이 없어 읽지 못한 리소스도 "미확인"으로 기록합니다.
2. 의존성 모델: 클라우드마다 이름이 다른 리소스를 하나의 그래프로 정리합니다. 발견한 사실과 아직 모르는 부분을 구분합니다.
3. 목적지에 맞게 적응: 대상 클라우드의 공식 지원 조건과 비교해 대체 서비스를 찾고, 코드 수정이 필요한 항목은 AI 작업과 테스트로 연결합니다.
4. 검증하고 전환: 대상 환경과 앱을 준비하고 DB를 동기화합니다. 조건을 만족한 단계만 실행합니다.

Export만 믿지 않는 이유는 단순합니다. 메시지 큐 호출처럼 코드에서만 보이는 의존성이 있기 때문입니다. 설정 파일만 옮기면 이런 호출을 놓칠 수 있습니다.

전체 구조: 판단하는 쪽과 실행하는 쪽

플랫폼은 두 평면으로 나뉩니다. 위쪽 분석·적응 평면은 "옮길 수 있는가, 무엇을 바꿔야 하는가"를 판정합니다. 아래쪽 실행·전환 평면은 검증을 통과한 계획만 실제 환경에 적용합니다. 두 평면 사이에는 실행 관문이 있습니다. 필수 조건이 하나라도 해결되지 않으면 실행을 시작하지 않습니다.

구성도는 제 지시로 Claude Code가 archify로 그린 것입니다. 노드를 눌러 연결을 따라가는 인터랙티브 구성도에서 각 단계의 입력과 출력을 볼 수 있습니다.

같은 이름, 다른 동작: 호환성 4분류

대체 리소스가 있다고 같은 동작은 아닙니다. 그래서 리소스마다 아래 네 가지 중 하나로 분류합니다. 근거 문서가 없으면 "대응 가능"으로 판정하지 않습니다.

분류	처리 방식	확인하는 것
기능 대응 가능	설정 변환	이름이 같아도 사양, 네트워크 접근, 가용성 요구를 비교
대체 서비스 존재	코드 적응 (AI)	SDK, 인증, URL 생성, 재시도와 오류 처리의 차이
직접 운영 가능	운영 책임 검토	백업, 모니터링, 확장, 장애 복구 책임이 함께 넘어옴
동등한 대체 없음	사용자 결정	원본 유지, 기능 변경, 이전 제외 중 사람이 선택

각 분류에서 무엇을 확인하는지는 글 끝 직접 바꿔보기의 첫 번째 모형에서 분류를 바꿔 가며 볼 수 있습니다.

AI는 고치고, 테스트가 증명합니다

"대체 서비스 존재"로 분류된 리소스는 코드를 바꿔야 합니다. 예를 들어 S3의 서명 URL 생성 코드를 대상 클라우드의 스토리지 SDK로 바꾸면 서명 URL의 형식이나 만료 방식이 달라질 수 있습니다.

에이전트는 대상 서비스의 공식 문서를 근거로 SDK 호출, 인증, 연결 방식을 바꾼 변경안을 만듭니다. 그다음 원본과 분리된 시험 환경(샌드박스)에서 빌드, 계약 테스트(다른 서비스와 주고받는 요청·응답 형식이 그대로인지 확인), 통합 테스트, 멱등성 검사(같은 요청을 다시 보내도 한 번만 반영되는지 확인)를 실행합니다. AI가 "된다"고 답한 것은 호환성의 증거가 아닙니다. 테스트를 통과한 변경만 이전 계획에 들어갑니다. 동등한 대체가 없으면 사용자 결정으로 돌아갑니다.

앱은 두 곳에서, 쓰기는 한 곳에서

전환에서 가장 위험한 순간은 DB입니다. 두 DB가 동시에 쓰기를 받으면 어느 쪽이 맞는 데이터인지 알 수 없게 됩니다. 그래서 앱은 두 클라우드에서 동시에 돌 수 있게 허용하되, DB 쓰기는 언제나 한 곳에서만 받도록 설계했습니다.

위 상태도도 제 지시로 Claude Code가 archify로 만든 것입니다.

단계	앱	쓰기를 받는 DB	하는 일
A 준비	원본 앱 운영 (대상 앱은 격리 테스트)	원본 DB	원본 DB를 대상 DB로 복사하고 CDC로 계속 따라가게 함. 대상 DB에는 테스트 쓰기도 금지
B 앱 동시 운영	원본 앱 + 대상 앱	원본 DB	대상 앱에 트래픽을 조금씩 보냄. 양쪽 앱 모두 원본 DB를 씀
C 전환 구간	새 쓰기는 잠깐 대기	잠깐 없음	아래 순서로 쓰기 DB를 바꿈
D 완료	대상 앱 (원본 앱을 유지하면 함께)	대상 DB	양쪽 앱 모두 대상 DB를 씀. 원본 DB 쓰기 차단 유지

C 단계의 순서는 다음과 같습니다.

1. 새로 들어오는 쓰기 요청을 실패시키지 않고 잠깐 기다리게 합니다.
2. 이미 처리 중인 트랜잭션이 끝나기를 기다립니다.
3. 원본 DB의 쓰기를 막습니다.
4. 원본의 마지막 변경까지 대상 DB에 넘어갔는지 확인합니다.
5. 대상 DB를 쓰기 가능한 정식 DB로 바꾸고, 앱의 DB 연결(연결 풀)을 대상으로 옮깁니다.
6. 기다리던 요청을 처리합니다. 같은 요청이 두 번 들어와도 한 번만 반영되게 합니다(멱등 처리).

단계별로 연결과 쓰기 주체가 어떻게 바뀌는지는 글 끝 두 번째 모형에서 직접 넘겨 볼 수 있습니다.

무중단의 정의: 대기는 허용, 누락과 중복은 0

이 설계에서 "무중단"은 응답이 전혀 느려지지 않는다는 뜻이 아닙니다. 사용자에게 약속하려는 기준은 세 가지입니다.

• 성공 응답을 받은 쓰기의 누락 0건
• 같은 요청의 중복 반영 0건
• 전환 때문에 생긴 요청 실패 0건

함께 측정할 값은 최대 대기 시간, 느린 쪽 5%·1% 요청의 응답 시간(p95·p99), CDC 적용 위치(대상 DB가 원본의 변경을 어디까지 따라잡았는지), 전환 소요 시간입니다. 허용 대기 시간은 서비스마다 정해야 합니다. 아직 어느 것도 측정하지 않았습니다.

이 기준이 성립하려면 전제가 있습니다. API, 백그라운드 작업, 배치까지 모든 쓰기 경로를 통제할 수 있어야 하고, 재시도가 멱등해야 합니다. 정해진 대기 시간 안에 전환을 끝낼 수 없거나 외부 부작용을 안전하게 처리할 수 없는 서비스는 분석 단계에서 막습니다.

문제가 생기면: 롤백의 세 구간

롤백은 언제 문제가 생겼는지에 따라 다르게 설계했습니다.

시점	문제가 생기면	설계 상태
분석 단계 (옮기기 전)	이전 자체를 하지 않음. 원본은 그대로 운영	정해짐
대상 승격 전 (A–C, 대상 DB가 아직 쓰기를 받지 않음)	전환을 멈추고 원본 운영을 계속함. C에서 막았던 원본 쓰기는 다시 엶. 새 데이터가 원본에만 있으니 잃는 것 없음	정해짐
전환 후 (D, 대상 DB가 이미 쓰기를 받음)	DB 주소만 되돌리면 그동안 대상에 쓴 데이터가 사라짐. 역동기화(대상에서 원본으로 거꾸로 복제)가 검증된 경우에만 되돌림	원칙만 있고 방법 미정

세 번째 칸은 설계 단계에서 아직 정하지 않은 항목입니다. 지금 설계로는 전환 직후 버그나 성능 문제를 발견해도, 데이터를 잃지 않고 되돌릴 확정된 수단이 없습니다. 검토할 후보는 이렇습니다(아직 정하지 않음).

• 대상 DB가 쓰기를 받기 시작하는 순간부터, 그 변경을 원본의 별도 복제본(A′)으로 계속 보내 둡니다. 문제가 생기면 앱을 그 복제본으로 돌립니다.
• 되돌리는 기준(예: 오류율, p99 응답 시간)을 미리 정합니다.
• 이 방식을 쓸 수 없는 DB 조합은 분석 단계에서 "되돌리기 불가, 사람 확인 필요"로 표시합니다.

첫 번째 후보를 원본 DB가 아니라 별도 복제본으로 적은 이유가 있습니다. AWS의 DMS 이전 후 롤백 전략은 새 DB에서 원본 DB로 직접 거꾸로 복제하는 방식을 권하지 않습니다. 그 복제 흐름을 미리 시험할 수 없기 때문입니다. 대신 원본의 별도 복제본으로 보내는 fall forward(A → B → A′)를 권합니다.

58초로 보는 흐름

결정된 것과 앞으로 증명할 것

• 정한 것: 구성 수집 → 호환성 분류 → AI 적응·검증 → 데이터·트래픽 전환의 흐름. 두 앱 동시 실행과 단일 DB 쓰기.
• 아직 정하지 않은 것: 처음 지원할 클라우드·DB 조합, 서비스별 최대 대기 시간, 역동기화 지원 범위, 대체 불가 리소스의 정책.
• 아직 증명하지 않은 것: 실제 계정 연결, CDC·전환·롤백, 요청 실패·데이터 누락·중복 0건. 이 글의 모형과 영상은 설계를 설명할 뿐 실행 증거가 아닙니다.

설계 전체와 공식 문서 근거는 설명 사이트 migration.taeyun.blog에 함께 정리했습니다.

참고한 공식 문서

• AWS: 기존 리소스에서 IaC 생성
• Google Cloud: Terraform 구성 추출
• Azure: 현재 구성을 템플릿으로 추출
• AWS RDS MySQL → Cloud SQL: 복제와 전환
• AWS RDS MySQL → Azure MySQL: Data-in replication
• AWS: DMS로 이전한 뒤 롤백하기