Spanner 마이그레이션: Antigravity CLI를 사용한 이중 쓰기 자동화로 중단 최소화

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

기존 데이터 레이어를 현대화해야 했던 Google의 재무 엔지니어링팀은 고가용성 기능을 제공하고 전 세계에 분산된 strong consistency를 갖춘 멀티모델 데이터베이스인 Spanner를 선택했습니다. 하지만 프로덕션 서비스를 오프라인으로 전환하지 않고 Spanner로 마이그레이션하는 것은 엔지니어링 측면에서 어려운 과제였습니다. 애플리케이션을 담당하는 내부 팀으로서 수십 개의 데이터 액세스 객체(DAO)에서 이중 쓰기 로직을 수동으로 다시 작성해야 했는데, 이 프로세스는 시간도 오래 걸리고 인적 오류가 빈번하게 발생했습니다. 또한 중단 없이 이 작업을 수행하려면 코드베이스의 모든 DAO에서 여러 단계에 걸쳐 이중 쓰기 아키텍처를 구현해야 했습니다. 

이 문제를 해결하기 위해 다른 접근 방식을 취했습니다. 헤드리스 모드에서 Antigravity CLI를 사용하는 자동화된 리팩터링 파이프라인을 빌드했습니다. 이를 통해 프로덕션 환경을 준비하는 동안 스테이징 환경에서 엄격한 데이터 동등성을 유지하면서 마이그레이션 속도를 크게 높일 수 있었습니다. 

과제: 이중 쓰기 마이그레이션의 구조

재무 정보 정확성이 필수적인 높은 처리량의 프로덕션 서비스를 마이그레이션할 때는 단순한 컷오버 스크립트로는 충분하지 않습니다. 모든 이전 데이터 백필 및 검증이 완료될 때까지 기존 데이터 스토어와 Spanner 양쪽에 동일한 쓰기 작업이 동시에 이루어지는지 확인해야 합니다.

마이그레이션은 다음과 같은 세 가지 단계로 구성했습니다.

• 이전 백필: 참조 무결성을 유지하면서 기존의 이전 기록을 Spanner에 복사합니다.

• 이중 쓰기/이중 읽기 구현: 마이그레이션 기간 동안 모든 DAO를 수정하여 기본 데이터 스토어와 Cloud Spanner에 모두 변경 사항을 동시에 기록합니다.

• 자동화된 API 검증 및 동등성 검사: RPC 트래픽을 가로채고 모든 쓰기 작업이 두 저장소에서 바이트 단위로 동일하게 기록되는지 엔드 투 엔드로 검증합니다.

아키텍처 패턴은 깔끔했지만 현재 규모에서는 마찰이 발생하기 시작했습니다. 각 DAO에는 다음이 필요하기 때문입니다.

• 복잡한 도메인 모델을 Spanner 스키마 열에 매핑하는 전용 MutationConverter 클래스

• 이중 쓰기 브랜치 처리 및 롤백 또는 오류 보고 로직

• FakeTimeSource와 같은 가짜 시간 소스와 테스트 더블을 사용하여 기본 데이터 스토어와 Spanner에서 모두 쓰기 작업을 검증하는 단위 테스트 모음

30개가 넘는 DAO에 정밀도가 높은 이러한 코드 변경을 동일하게 수동으로 수행하려면 엔지니어링 작업에 수개월이 걸렸을 것입니다.

솔루션: 표준화된 변형 컨버터 패턴

자동화 파이프라인이 안정적으로 깔끔한 코드를 생성할 수 있는지 검증하기 위해 먼저 분리된 MutationConverter 인터페이스를 중심으로 DAO 리팩터링 패턴을 표준화했습니다.

핵심 DAO 비즈니스 로직 내에 원시 Spanner 테이블 이름과 열 할당을 직접 삽입하는 대신 Spanner 스키마 변환을 전용 컨버터 단위로 분리했습니다.

DAO와 Spanner SDK(spanner.Mutation) 간에 엄격하고 결정론적인 계약을 수립함으로써 AI 코딩 에이전트가 추론하고 안정적으로 생성할 수 있는 정확한 대상 사양을 만들었습니다.

헤드리스 모드에서 Antigravity CLI를 사용하는 이유

IDE의 대화형 AI 채팅 인터페이스는 탐색적인 코딩 작업에는 적합하지만 전체 코드베이스에서 여러 파일을 체계적으로 업데이트하는 작업에는 적합하지 않습니다. 예외 상황을 놓치지 않으면서 수십 개의 대상에 반복 가능한 리팩터링을 적용해야 하는 경우 자동화된 워크플로가 필요합니다.

이에 따라 헤드리스 모드(-p)에서 Antigravity CLI를 실행하는 조정 스크립트(migration_ui.py)를 빌드하여 이 문제를 해결했습니다.

헤드리스 모드를 사용하면 수동으로 터미널에 프롬프트를 입력할 필요 없이 Antigravity를 셸 스크립트, 지속적 통합 파이프라인, 백그라운드 자동화 작업 내에서 직접 실행할 수 있습니다. 이러한 접근 방식을 통해 다음의 세 가지 주요 방향으로 작업을 확장할 수 있었습니다.

• 결정론적 프롬프트 아키텍처: 프롬프트를 버전 제어가 가능한 엔지니어링 아티팩트로 취급했습니다. 타임스탬프 직렬화, null 허용 여부 변환, 변형 모호성, FakeTimeSource 테스트 주입과 같은 일반적인 Spanner 예외 상황을 처리하기 위한 정확한 규칙을 재사용 가능한 프롬프트 템플릿에 직접 성문화했습니다.

• 일괄 실행 및 자동 검증: 조정 스크립트는 대상 DAO 이름을 입력으로 받아 기존의 단일 쓰기 소스 코드와 스키마를 가져온 후 구조적 규칙과 함께 헤드리스 모드의 Antigravity에 전달합니다. Antigravity는 새로운 컨버터, 리팩터링된 이중 쓰기 DAO, 해당 단위 테스트를 생성합니다. 그런 다음 스크립트가 Blaze 테스트를 실행합니다. 린터 오류 또는 테스트 어설션이 실패하면 오류 로그가 Antigravity에 직접 전달되어 자체 수정됩니다.

• 대규모 야간 실행: 루프가 무인으로 실행되므로 엔지니어는 하루 일과가 끝날 때 10개의 DAO를 큐에 추가할 수 있습니다. 그러면 다음 날 아침까지 파이프라인은 10개의 변경 목록을 생성, 테스트, 검증하여 사람이 코드 검토를 할 수 있도록 준비합니다.

결과 및 클라우드 엔지니어를 위한 핵심 내용 정리

Spanner의 분산 데이터베이스 기본 요소와 Antigravity CLI의 헤드리스 자동화를 결합한 결과, 엔지니어링 조직 전반에서 다음과 같은 분명한 이점을 얻을 수 있었습니다.

• 마이그레이션 작업량 대폭 감소: 이전에는 광범위한 수동 코딩과 테스트가 필요했던 DAO 이중 쓰기 마이그레이션이 훨씬 짧은 시간 내에 완료되고 검토되었습니다. 

• 높은 안정성의 데이터 마이그레이션: 생성된 모든 DAO가 동일한 테스트를 거친 MutationConverter 패턴을 준수하고 Spanner 테스트 더블에 대한 자동화된 단위 테스트를 거쳤기 때문에 광범위한 마이그레이션 테스트 중에도 높은 수준의 데이터 충실도를 유지할 수 있었습니다. 

• 더 가치 있는 엔지니어링 업무에 집중: 엔지니어는 반복적인 상용구 리팩터링을 피하고 데이터 모델링, 아키텍처 복원력, 성능 최적화 등에 집중할 수 있는 시간을 확보했습니다.

다음 데이터베이스 마이그레이션을 위한 3가지 팁

1. 스키마 변환을 먼저 분리: 마이그레이션 스크립트를 작성하기 전에 기존 비즈니스 로직에서 새로운 클라우드 데이터베이스 SDK 요구사항을 격리하는 엄격한 인터페이스(예: MutationConverter)를 정의하세요. AI 에이전트는 명확하고 제한된 설계 패턴이 주어질 때 가장 효과적으로 작동합니다.

2. 양방향 채팅에서 헤드리스 자동화로 전환: 3~4개 이상의 파일에서 반복적인 리팩터링을 실행할 때는 스크립트 기반의 헤드리스 워크플로에 투자하세요. 프롬프트 입력과 테스트 검증을 자동화된 빌드 단계로 처리하면 품질과 일관성을 유지하는 데 도움이 됩니다.

3. 빌드 시스템을 가드레일로 활용: AI 생성 루프를 빌드 및 테스트 하네스(bazel test 또는 go test)에 직접 연결하세요. 이를 통해 모델은 개발자가 코드를 검토하기 전에 컴파일 및 어설션 오류를 수정할 수 있습니다.

시작하기

금융 시스템을 마이그레이션하는 경우에도, 클라우드 네이티브 애플리케이션을 처음부터 빌드하는 경우에도 Spanner와 Antigravity는 확장 가능한 소프트웨어 개발을 위한 기반을 제공합니다.

• Cloud Spanner 살펴보기: Google Cloud Spanner 문서에서 Spanner의 분산 아키텍처에 대해 자세히 알아보세요.

• 개발자를 위한 Gemini 알아보기: 개발자를 위한 Google Cloud AI에서 AI 지원 코딩과 헤드리스 CLI 자동화가 엔지니어링 워크플로에 어떤 도움이 되는지 알아보세요.