DB 변경 쿼리를 작업과 배포 단위로 추적하기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

DB 변경은 그 변경이 필요한 작업과 함께 움직여야 한다. 기능 개발과 테스트가 끝나지 않았는데 운영 DB의 컬럼이나 테이블부터 바꾸면 설계가 수정될 때마다 다시 전달해야 한다. 추가한 컬럼을 지우거나, 컬럼 구성을 다시 고치거나, 아예 별도 테이블로 바꿔야 할 수도 있다. 개발 중에 자연스럽게 생기는 수정을 매번 운영에 반영하면 운영 DB를 계속 건드리는 일이 된다.

내가 실무에서 택하는 방법은 쿼리를 이슈와 PR에 붙여 두고, 개발 환경에서는 충분히 바꾸며 테스트한 뒤, 해당 릴리스에 들어갈 최종 묶음만 전달하는 것이다. 의도적으로 단순한 수동 방식이다. 모든 팀이 반드시 이렇게 DB 변경을 관리해야 한다는 뜻은 아니다.

환경마다 권한의 경계가 다르다

환경 구성은 회사마다 다르다. 개발, 알파, 베타, 스테이징, QA, 라이브를 모두 둘 수도 있고 그중 일부만 둘 수도 있다. DB 권한도 그 구성에 따라 달라진다.

개발 환경에서는 개발자에게 DDL과 DML 권한이 열려 있을 수 있다. 이곳에서는 스키마 모양을 시도하고, 수정하고, 애플리케이션과 함께 검증할 수 있다. 처음 실행된 쿼리를 곧바로 최종본으로 취급할 필요는 없다.

스테이징 이상의 환경에서는 운영 방식이 달라질 수 있다. 회사의 규모와 상황에 따라 DBA가 상위 환경의 변경을 관리하기도 한다. 이 경우 개발자는 DBA가 반영할 쿼리를 전달해야 한다. 구현 과정에서 나온 모든 초안보다 검증을 거친 릴리스 후보를 넘기는 편이 훨씬 다루기 쉽다.

쿼리를 작업 가까이에 둔다

기능을 개발하는 동안 필요한 DDL, DML과 그 밖의 쿼리를 이슈 트래커에 모아 둔다. 하위 작업이 있다면 관련 변경을 해당 작업과 함께 기록해 각 쿼리가 필요한 이유를 볼 수 있게 한다. 개발 환경에서 애플리케이션과 DB 구조를 시험하는 동안 쿼리도 계속 고친다.

중요한 전환점은 피처 브랜치를 개발 브랜치로 넘길 준비가 되었을 때다. 이때의 작업은 초기 탐색 단계보다 신뢰도가 높다. 나는 최종 DB 변경을 이슈에만 남기기보다 해당 피처 PR에 붙이는 편이다. 이슈가 작업의 맥락을 보존한다면, PR은 그 쿼리에 의존하는 구체적인 코드 변경을 가리킨다.

그러면 릴리스 단위로 추적할 지점도 생긴다. 릴리스 브랜치에 여러 PR이 들어간다면 각 PR에 딸린 DB 변경을 확인해 이번 릴리스에서 운영에 반영할 묶음을 만든다. DB 작업 단위가 애플리케이션 작업 단위와 맞춰진다.

DB 변경 전달 시점도 개발 작업이 실제 배포 준비를 마친 시점과 맞출 수 있다.

코드보다 먼저 릴리스 쿼리를 반영한다

운영 변경을 요청하기 전에 개발 환경에서 가능한 한 많이 테스트한다. 실제 릴리스 준비가 되면 포함된 PR의 쿼리를 모아 DBA나 운영 DB를 관리하는 담당자에게 전달한다. 이 흐름에서는 관련 애플리케이션 코드를 배포하기 전에 DB 변경을 먼저 반영한다.

이 순서가 아직 끝나지 않은 작업을 미리 운영에 적용해도 된다는 의미는 아니다. 개발과 내부 테스트를 거쳐 필요한 DB 구조가 충분히 안정된 뒤, 곧 배포할 릴리스의 정확한 변경 묶음을 준비하자는 뜻이다. 그렇지 않으면 변경을 반영하고, 설계가 달라진 사실을 발견하고, 운영 담당자에게 다시 수정을 요청하는 핑퐁이 반복된다.

팀에 필요한 관리 수준을 고른다

이 수동 방식은 아주 체계적인 관리법은 아니다. Flyway 같은 마이그레이션 도구는 특히 여러 사람이 변경을 조율할 때 더 강한 구조를 제공할 수 있다. 나는 Flyway를 직접 사용해 보지 않았으므로 경험에 근거한 비교를 할 수는 없다. 다만 한 팀이 잘 사용하고 있다는 이야기를 들었고, 여러 사람의 작업을 안정적으로 지원한다면 각자의 맥락에서 검토해 볼 수 있다.

내가 이슈와 PR 방식을 선호하는 이유는 평소 일을 짧게 나누고, 여러 작업이 서로 충돌하기 어려운 직관적인 과정을 선호하기 때문이다. 팀이 더 크거나, 권한 구조가 다르거나, 릴리스 과정이 복잡하다면 다른 도구가 더 알맞을 수 있다.

도구와 무관하게 남는 실무 원칙은 단순하다. 개발자가 자유롭게 수정할 수 있는 환경에서 DB 변경을 검증하고, 각 변경을 그것이 필요한 작업과 연결하며, 실제 릴리스를 구성하는 PR에서 운영 반영 묶음을 만들어야 한다.