Oracle APEX, SQLcl, Liquibase를 활용한 팀 개발의 실제 과제: 논의를 위한 시작점
Source: Dev.to
현대 CI/CD에서 목표는 단순합니다: 1 Jira 티켓 = 1 Pull Request. 모든 커밋은 깔끔하고, 격리되어 있으며, 자동화되어야 합니다. Oracle APEX와 데이터베이스 객체를 팀 환경에서 다룰 때, 이 “깨끗한 상태”를 유지하는 일은 결코 쉽지 않습니다.
1. Working Copies: APEX에는 좋지만…
접근 방식
APEX의 기본 Working Copies 기능을 사용해 애플리케이션 메타데이터를 브랜치합니다.
“하지만”
Working Copies는 APEX 구성 요소(페이지, 아이템 등)만 격리합니다. 여전히 공유 파싱 스키마를 가리키고 있습니다.
결과
Working Copy를 내보내면 깔끔한 APEX 메타데이터는 얻을 수 있지만, 데이터베이스 내보내기에는 여전히 그 공유 스키마에 있는 다른 개발자의 변경 사항이 포함됩니다.
2. Liquibase Automation: 스키마에는 좋지만…
접근 방식
liquibase generate-schema -split을 사용해 데이터베이스 객체 내보내기를 자동화합니다.
“하지만”
공유 스키마(예: BO_SHARED)에서는 Liquibase가 전체 스키마 상태를 캡처합니다.
결과
개발자 A가 티켓 1을 위해 테이블을 만들고, 개발자 B가 티켓 2를 위해 패키지를 만들면, 개발자 A의 내보내기에는 자동으로 개발자 B의 작업이 포함됩니다. 자동화가 무산되고, 개발자는 자신이 만든 파일만 git add 해야 하는 수동 작업을 해야 합니다.
3. Separate Schemas: 격리에는 좋지만…
접근 방식
각 개발자에게 고유 스키마(DEV1, DEV2, DEV3)를 부여해 진정한 격리를 구현합니다.
“하지만”
이 방법은 APEX 파싱 연결을 깨뜨립니다.
결과
개발자는 공유 APEX 애플리케이션 내에서 자신의 변경 사항을 쉽게 테스트할 수 없으며, 먼저 해당 객체들을 마스터 스키마로 마이그레이션해야 합니다. 이는 또 다른 형태의 통합 병목을 초래합니다.
4. Git Filtering: 정밀도에는 좋지만…
접근 방식
고급 Git 기법(인터랙티브 스테이징, 체리‑픽, 리베이스 등)을 사용해 관련 없는 변경을 필터링합니다.
“하지만”
이는 개발자에게 막대한 수동 작업 부담을 줍니다.
결과
우리는 Liquibase를 자동화 도구라기보다 단순 파일 생성기로만 사용하게 됩니다. 개발자가 생성된 50개 파일 중 48개를 수동으로 리셋해야 한다면, “자동화”는 실패한 것입니다.
현재 현실: 트레이드‑오프 수용
공유 환경에서 APEX와 데이터베이스 객체 모두에 대해 100 % 완전 자동화를 제공하는 현재 방법은 없다는 결론에 도달했습니다.
현재 “우회책”
- Working Copies를 사용할 때 발생하는 수동 선택을 “세금”으로 받아들입니다.
- 수동 스테이징 단계에서 인간 오류를 줄이기 위해 강력한 프로세스와 체크리스트에 의존합니다.
- 사전 개발 리뷰를 통해 아키텍처를 정렬하고, “푸시”가 수동이라도 논리는 견고하도록 합니다.
논의해 봅시다
- 별도 스키마 없이 APEX에서 Jira 작업을 PR에 1‑대‑1 매핑하는 진정한 자동화·격리를 이룰 방법이 있을까요?
- 아니면 “수동 선택” 병목이 공유‑데이터베이스 IDE를 사용할 때 감수해야 할 비용일 뿐일까요?
팀에서는 공유 스키마 병목을 어떻게 해결하고 있나요? 수동 작업 없이 이를 자동화한 경험이 있다면 피드백을 부탁드립니다.