자동 실행의 함정: 운영 서버 무조건 실행 금지

앱 구동 시 자동 마이그레이션의 유혹

현대의 백엔드 프레임워크나 바이브코딩 튜토리얼을 보면, 서버 애플리케이션이 시작될 때(Startup) 마이그레이션 코드를 호출하는 로직이 흔히 등장합니다.

로직은 매우 단순합니다.

1. 앱이 실행된다.
2. 데이터베이스에 연결한다.
3. 내장된 마이그레이션 도구를 실행하여 최신 스키마로 업데이트한다.
4. 웹 서버가 트래픽을 받기 시작한다.

개발자의 컴퓨터나 트래픽이 없는 테스트 서버에서는 이 방식이 정말 환상적입니다. 코드를 실행하기만 하면 귀찮은 명령어 없이 DB가 알아서 최신 상태로 맞춰지기 때문입니다. 하지만 이것을 그대로 운영 서버로 가져가면 재앙이 시작됩니다.

첫 번째 함정: 분산 환경에서의 동시 실행 충돌

운영 서버는 보통 한 대의 컴퓨터로 돌아가지 않습니다. 트래픽을 분산하기 위해 똑같은 앱 여러 개(인스턴스 또는 컨테이너)를 동시에 띄워 놓는 것이 일반적입니다.

마이그레이션 레이스 컨디션(Race Condition)

만약 새로운 버전을 배포하기 위해 앱 인스턴스 3대를 동시에 재시작했다고 가정해 봅시다. 이 3대의 앱은 켜지자마자 약속이라도 한 듯 동시에 데이터베이스에 달려가 마이그레이션을 실행하려고 할 것입니다.

데이터베이스 입장에서는 똑같은 테이블을 만들거나 컬럼을 추가하려는 명령이 3곳에서 동시에 쏟아지는 셈입니다.

• 최악의 경우, 데이터베이스 데이터가 꼬이거나 데드락(Deadlock)에 빠져 통신이 끊어집니다.
• 운이 좋아 마이그레이션 툴의 자체적인 잠금(Lock) 기능이 작동하더라도, 하나의 앱이 마이그레이션을 진행하는 동안 나머지 앱들은 데이터베이스 연결을 대기하다가 시간 초과(Timeout)로 기동에 실패하게 됩니다.

결국 정상적인 배포가 불가능해지고, 서버가 올라오지 않아 서비스 다운타임(장애)이 발생합니다.

두 번째 함정: 실패 시 롤백의 어려움

자동 실행의 또 다른 문제는 과정이 철저하게 숨겨져 있다는 점입니다.

마이그레이션은 생각보다 실패할 확률이 높습니다.

• 예상치 못한 중복 데이터로 인한 제약조건 위반
• 컬럼 데이터 타입 변경 시 발생하는 용량 문제
• 쿼리 작성 실수 등

만약 마이그레이션을 사람이 직접 수동 명령어로 실행(CLI)했다면, 에러 로그를 즉각 확인하고 즉시 이전 상태로 롤백하거나 문제를 파악할 수 있습니다. 하지만 앱이 켜질 때 은밀하게 자동 실행되다가 실패하면 앱은 그냥 조용히 죽어버립니다. 개발자는 앱이 죽은 원인이 코드 버그 때문인지, 아니면 DB 마이그레이션이 꼬여서 그런 것인지 파악하기 위해 수많은 로그 더미를 뒤져야 하며, 이는 귀중한 골든타임을 낭비하게 만듭니다.

결론: 앱과 마이그레이션의 생명주기 분리하기

핵심은 하나입니다. "앱의 실행과 데이터베이스 스키마의 변경은 완전히 독립적인 이벤트로 취급해야 합니다."

현대적인 클라우드 운영(DevOps) 환경에서는 배포 스크립트를 분리합니다. 새로운 코드를 서버에 올리기 직전, 배포 관리자(GitHub Actions 등)가 마이그레이션 전용 명령어를 단 한 번만 독립적으로 실행하여 DB를 갱신합니다. 마이그레이션이 성공적으로 완료된 것을 100% 확신한 뒤에야, 비로소 새로운 앱 인스턴스들을 재시작하여 트래픽을 받게 하는 것입니다.

이것이 다운타임을 방지하고 운영 서버의 안정성을 지키는 가장 중요한 아키텍처 규칙입니다.