공공 DB 서버 교체기 — Oracle 버전업과 SQL 호환성 검증

2014년에 공공기관 노후 DB 서버 교체 작업을 맡았을 때 가장 크게 느낀 점은 서버를 바꾸는 일보다 기준을 다시 세우는 일이 더 어렵다는 사실이었다. 겉으로 보면 장비 교체와 버전업으로 보이지만, 실제 현장에서는 오래된 SQL이 새 환경에서도 같은 결과를 내는지 하나씩 확인해야 했다. 특히 공공 시스템은 한 번의 조회 차이도 곧 민원으로 이어질 수 있어서, 속도보다 신뢰를 먼저 챙겨야 했다. 그래서 처음부터 성능 개선보다 호환성 검증 순서를 앞에 두고 접근했다.

당시에 가장 먼저 한 일은 화면과 배치에서 어떤 SQL이 실제로 쓰이는지 목록을 정리하는 것이었다. 오래 운영된 시스템일수록 비슷해 보이는 쿼리가 여러 곳에 숨어 있고, 개발자가 바뀌며 관용적으로 남은 문법도 적지 않았다. 단순히 실행 여부만 보는 식으로는 부족해서, 결과 건수와 정렬, 널 처리 같은 차이까지 비교 기준에 넣었다. 이 과정을 문서로 남겨 두니 수정 이유를 설명하기 쉬웠고, 나중에 같은 유형의 점검이 다시 생겼을 때도 출발점이 분명했다.

버전업 작업에서 배운 또 하나는 SQL 수정이 기술 문제이면서 동시에 커뮤니케이션 문제라는 점이었다. 개발자는 문법 차이를 빠르게 이해해도 운영 담당자는 왜 검증 기간이 필요한지 체감하기 어렵다. 그래서 변경 전후를 짧은 예시로 나누고, 영향 범위를 업무 용어로 풀어 설명하려고 했다. 그 덕분에 단순히 "고쳤다"가 아니라 "어떤 조회가 왜 달라질 수 있었는지"를 함께 공유할 수 있었고, 검수도 훨씬 차분하게 진행됐다.

돌아보면 이 경험은 이후 어떤 마이그레이션 작업을 하더라도 먼저 비교표를 만들게 한 출발점이 됐다. 데이터베이스 버전업은 새 기능을 쓰는 일보다 기존 기능을 깨뜨리지 않는 일이 더 중요하다. 다음에 비슷한 작업을 한다면 SQL 자체만 보지 않고, 화면과 배치와 운영 문서까지 한 묶음으로 보고 검증 범위를 더 일찍 확정할 것이다.