문제 상황

프로젝트 초기 단계에서 개발과 동시에 잦은 기획 변경으로 인해 코드가 변경될 때마다 데이터베이스 스키마도 함께 수정해야 하는 일이 빈번했습니다.

• 소스 코드는 GitHub으로 형상 관리하고 있었지만, 데이터베이스 스키마는 수작업으로 관리하다 보니 다음과 같은 문제가 발생했습니다:
  1. 휴먼 에러 위험성: 담당자가 DB 업데이트 중 실수하면 에러가 발생하고 복구가 어려웠습니다.
  2. 비일관적인 DDL 관리: 팀별로 DDL 이력 파일을 관리하려 했으나 방식이 달라 체계적이지 않았습니다.
  3. 스키마 변경의 부담: 개발, 테스트, 운영 환경별로 DB 스키마 변경이 부담스러운 작업이 되었습니다.
  4. 환경 분리의 어려움: 변경 사항 반영이 꺼려져 환경별 DB를 분리하는 것이 어려워졌습니다.
• 결과적으로 개발 서버와 테스트 서버가 동일한 DB를 사용하게 되었고, 테스트 중에는 개발을 중단해야 하는 생산성 저하 문제가 발생했습니다.

Flyway 도입 검토

• 이러한 문제를 해결하기 위해 널리 사용되는 데이터베이스 마이그레이션 도구인 Flyway를 도입하고자 했습니다.
• Flyway는 레퍼런스가 풍부하고 빠르게 적용할 수 있는 장점이 있지만, Tibero 데이터베이스를 공식 지원하지 않는다는 문제가 있었습니다.

• 국내에서는 Tibero를 사용하는 곳이 많지만, Flyway 공식 레포지토리의 이슈를 살펴보니 Tibero 지원 계획은 없었습니다.

• Tibero를 개발한 회사인 티맥스에서는 Tibero를 계속 사용할 수밖에 없었고, 앞으로도 데이터베이스 마이그레이션 이슈는 지속될 것이므로 오픈 소스의 이점을 활용하여 직접 Flyway의 Tibero 지원 기능을 구현하기로 결정했습니다.

목표 설정

팀장님께 해당 이슈를 건의하여 관심 있는 동료들과 함께 Flyway 스쿼드를 구성했고, 아래와 같은 목표를 달성하기 위해 프로젝트를 진행하였습니다.

구현 과정