하둡 또는 빅데이터 생태계에서는 수많은 테이블들을 즉흥적으로 만들고 제거하는 일이 많다. ERD 식으로 엄격하게 관리되는 주요 테이블이 있는 반면 어쩌고저쩌고 지원 테이블들이 나타나고 사라진다. 아니 빅데이터 뿐만 아니라 급변하는 기술 생태계에선 다 그런 것 같다. 명세가 중요한 금융, ERP나 고도의 엄격함이 요구되는 국방, 정부 사업 등이 아닌 일반 서비스라면 그런 곳이 많을 것 같다. 한 마디로 개판 오분전인데 어쩌고저쩌고에서 들은 소문에 따르면 나름 선진일 것 같은 A사 B사들도 개판 10분전인 것은 매한가지라고 한다.
누군가는 이것들을 한 판 잘 정리하고 정제하고 부채를 해소하고 싶어하지만 "어떻게든 위태위태 돌고는 있으니" 그런 정리, 명세 작업은 그저 비용이다. 엔지니어들에게는 신경쓰이는 짐이라서 시간을 들여 털고 가고 싶지만 관리자 측면에서는 눈에 보이지 않는다. 아니 사실 엔지니어들도 귀찮다. 기술적 챌린지가 있는 업무도 아니고 알아주는 사람도 없다. 매사에 일잘러에 깔끔한 사람이라면 대청소하는 기분으로 시간날 때마다 정리 작업을 하지만 쓸 데 없는 일 한다는 비아냥을 받거나 무쓸모 시선을 한 두 번 받으면 세 번은 하기 싫은 것이 인지 상정이다.
전담 관리 조직이 있어도 마찬가지다. 관리 조직은 허구헌날 개발 조직과 싸워야 한다. 스키마 명세하세요, 지워요, 고쳐요, 문서 만들어요, 권한 허가 받으세요 등등. 애초에 생성과 수정을 관리 조직의 감리 하에 진행하기도 하지만 개발 편의성과 납기 준수를 위한 속도 문제로 쉽게 해결할 수 있는 일은 아니다.
한 편, 배치로 도는 수많은 쿼리들은 다행히도 형상 관리의 보은을 받는다. 물론 스키마과 테이블 생성 DDL도 형상관리 되어야 정상이지만 이게 또 사람 하는 일이라 db 클라이언트나 콘솔, 서비스 코드내에서 어쩌고저쩌고 하는 일이 다반사다.
즉, 주요 DDL과 스키마는 그냥 쿼리에 함께 주석 또는 쿼리문으로 넣어두는 편이 나은 것 같다.
예컨데 create if not exists table 머머머를 배치 쿼리 앞에 항상 두는 것이다. 쿼리를 보는 사람은 즉시 스키마와 DDL을 참조 할 수 있다.
마지막 한 줄 쓰려다가 쓸데없이 빌드업한 글.