운영 DB 변경 관리

운영 DB 변경 관리(change management)는 스키마·데이터를 바꾸는 SQL을 작성 → 검토 → 결재 → 적용의 단계로 통제하고, 각 단계의 책임자와 판단을 감사 시점에 제시할 수 있는 증적으로 남기는 절차다.

언제 찾게 되는가

• 운영 DB에 ALTER TABLE 한 줄을 넣어야 하는데, 그 절차가 메신저 스레드와 각자의 기억에만 있을 때.
• 감사·내부통제 대응으로 “이 변경을 누가 검토했고 누가 결재했는지” 물었는데, 스프레드시트 대장과 메일 스레드밖에 없을 때.
• 결재자가 휴가라 승인이 멈춰 있거나, 승인 없이 적용된 쿼리를 사후에 발견했을 때.

핵심 답

마이그레이션 도구와 변경 통제 도구는 최적화 대상이 다르다. Flyway·Liquibase는 자동화 속도를 최적화하고, 변경 통제는 강제된 사람 검수를 최적화한다. 규제 환경에서 필요한 건 후자이며, 전자 위에 얹어 해결되지 않는다.

📄 문서 기반 (미검증) — Flyway/Liquibase에는 지정 결재자 개념이 없다는 것은 두 도구의 설계 관심사에 대한 판단이다.

두 도구는 배타적이지 않다. 마이그레이션 도구는 어떻게 적용할지를, 변경 통제는 적용해도 되는지를 다룬다.

통제형 워크플로우의 단계

작성 → 제출 → 검토(지정 검토자) → 결재(지정 결재자) → 백업 → 적용

설계 원칙 세 가지:

1. 각 단계에 책임자가 명시된다. “팀에서 봤다”가 아니라 특정 계정이 특정 시각에 승인했다는 기록.
2. 승인과 반려가 모두 기록된다. 반려 이력이 빠지면 “한 번에 통과된 변경”과 “세 번 반려 후 통과된 변경”을 구분할 수 없다.
3. 검수를 건너뛰는 옵션을 제공하지 않는다. 긴급 우회 경로를 만들면 그 경로가 기본 경로가 된다.

절차가 무너지는 지점은 기술이 아니라 사람이다

절차 도구가 현실에서 실패하는 원인은 대부분 조직 사정이다. 시스템에 넣어야 할 장치:

✅ 실측 (DBFlow 구현, 2026-07)

적용 전 백업과 롤백을 기본 동작으로

승인까지 받은 SQL이라도 실행 후 되돌릴 수 없는 것이 있다. 적용 직전 대상 테이블을 자동 백업하고, 실패 시 롤백 경로를 남긴다.

핵심은 한계를 숨기지 않는 것이다. 데이터가 큰 테이블은 임계치를 넘으면 스키마만 백업하고 넘어가게 되는데, 이 경우 “이 백업으로는 데이터 복구가 불가능하다”를 UI에 명시해야 한다. 조용히 안전한 척하는 백업은 백업이 없는 것보다 위험하다 — 복구 가능하다고 믿고 더 과감한 변경을 승인하게 만들기 때문이다.

증적이 증적이 되려면

감사 로그를 남기는 것은 쉽다. 어려운 것은 그 로그가 나중에 고쳐지지 않았음을 증명하는 것이다. 애플리케이션에 수정 API를 만들지 않았다는 건 증명이 아니다 — DB에 직접 접속하면 그만이다. 스토리지 계층에서 강제해야 한다.

→ MySQL 감사 테이블 append-only 강제

왜 이 간극이 생기는가

규제는 조직 규모를 보지 않는다. 소규모 금융·공공 도메인 조직도 대형사와 같은 기준의 내부통제를 요구받는다. 반면 DB 거버넌스 상용 솔루션은 대기업 기준으로 가격이 매겨지고, 라이선스 외에 컨설팅·구축 기간이 붙는다. 결과적으로 필요한 절차는 아는데 살 수는 없어서, 엑셀과 메신저와 사람의 성실성으로 절차를 흉내 내게 된다.

셀프호스팅 오픈소스가 이 간극을 메우는 자리다. 구현 사례: DBFlow  (AGPL-3.0, 단일 컨테이너, 대상 DB는 MySQL만 지원).

셀프호스팅 도구의 기본 원칙 하나 — 기본 시크릿이나 약한 값으로는 부팅을 거부해야 한다. 자기 인프라에 올리는 도구가 기본값 그대로 도는 것이 가장 흔한 사고 경로다. ✅ 실측 (DBFlow 구현, 2026-07)

Related

• MySQL 감사 테이블 append-only 강제
• 트랜잭션과 ACID
• 작은 팀의 아키텍처 방법론