초보 DBA 삽질기 2

잘 돌아가면 건드리지 말라는 말이 있다. 100% 완벽하게 이해하지 못하는 시스템에 대해서는 이 말이 좋은 충고일 수도 있겠다는 생각이 든다. 데이터베이스 관리 시스템은 매우 복잡한 소프트웨어이므로 이것을 완벽하게 이해하기란 정말 어려운 일이다. 더군다나 데이터베이스가 어떻게 구성되어 있느냐에 따라 같은 명령도 다른 양상을 보일 수 있다. 중단이 허용되지 않는 데이터베이스 시스템에서 뭔가 작업하려면 더욱 주의해야 하고 가능한 보수적으로 접근해야 한다.

그러나 나는 뼈속까지 DBA는 아니었던 모양이다. 뭔가 사용되지 않는 불필요한 것이 있는 꼴을 못 본다. 사용되지 않는 게 확실하다면 삭제해야 마음이 편하다. 새로 관리하는 된 데이터베이스에 대해 이해를 높여가야 하는 상황이었고, 불필요한 것이 있다면 제거하는 것이 시스템을 좀더 관리하기 쉽게 만드는 방법이라 생각했다.

그날도 역시 데이터베이스를 살펴보다 이상한 스키마를 발견했다. exp_dp란 이름의 스키마였는데 데이터는 없었고 exclude_table이란 함수만 하나 달랑 있었다. exclude_table 함수는 아무 것도 하지 않는 빈 껍데기 함수였고 개발자에 확인한 결과 이 함수를 호출하는 곳은 없었다. 개발팀에서 이 스키마의 존재를 아는 사람은 없었다.

나는 생각했다. '프로그램 소스 코드도 그렇고 데이터베이스도 그렇고 항상 깔끔하게 관리해야 하며, 사용하지 않는 부분은 삭제해야 한다. 따라서 이 정체불명의 스미카와 함수는 삭제하는 것이 옳다.' 지난 번과 같은 실수를 방지하기 위해 신경써 준비했다. 작업 계획서를 작성해 팀장에게 결재를 받았고, 전산센터에도 미리 작업 내용을 알렸다.

스키마를 한 번에 날렸다가는 사고나 난 경우 복구가 불가능하다고 생각해 한 단계씩 작업하는 것이 좋겠다 생각했다. 먼저 함수를 날리고 문제가 없으면 스키마를 날려야지. 함수를 날리기 직전 잠시 망설였다.

'함수 소스를 복사해둘까?'

그러나 다시 생각을 바꾸었다.

'에잇, 아무 것도 안 하는 함수인데 설마 문제가 있겠어? 그냥 날리자.'

약간의 불안한 마음이 있었지만 과감하게 날렸다. 잠시 후 다시 여기 저기서 전화벨이 울리기 시작했다. 거래가 안 된다는 소리가 들렸다. 전산센터에서 모든 테이블에 insert가 안 된다고 알려왔다. 아니 사용되지도 않는 함수를 하나 지웠다고 테이블에 insert가 안 되다니, 모두지 말이 안 되는 상황이었다. 어떻게 해야 할지 알 수 없었다. 머리속이 하얘졌다.

결국 다른 분이 급히 오라클 지원 센터에 전화를 걸어 도움을 요청했고, 생전 처음 들어본 보안 정책이 적용되어 있어 그럴 수 있다는 답을 들었다. 데이터베이스를 조회해 해당 정책을 확인하고 모두 삭제 처리했다. 이 정책은 모든 테이블에 insert가 실행될 때마다 exp_dp.exclude_table이란 함수를 호출하도록 되어 있었던 것이다. DBA 경력이 짧아서였는지 이런 정책이 적용된 것은 처음 보았다. 아니, 이런 정책이란게 있는지도 몰랐다.

정책을 삭제하니 거래가 정상으로 돌아왔다. 약 22분간의 장애였다. 이번 장애는 그냥 넘어가기 힘들어 보였다. 대형 고객사에서 클레임을 제기했다는 소리가 들렸고, 피해액 수천 만원을 배상해야 한다는 얘기도 들렸다. 아아... 함수를 삭제하기 전에 함수 소스를 복사해 뒀다면 문제가 생겼을 때 재빨리 함수를 재생성하는 방법으로 대처할 수 있지 않았을까?

개발팀 내에서 데이터베이스에 대해 잘 아는 사람은 나뿐이었다. 팀장이 승인을 했다 하더라도 무사히 작업을 처리할 책임은 내게 있었던 것이다. 입사 두 달만에 두 번 대형 사고를 쳤다. 마음이 무거웠다. 사람들이 '데이터베이스 전문가라고 데려다 놨는데 와서 사고만 친다'고 생각할 것 같았다. 이상한 것은 이런 대형 사고를 쳤는데 아무도 나를 질책하지 않았다는 것이다. 오히려 그래서 마음이 더 편치 못했다.

이제 정말 조심해야 겠다. 모든 작업을 한 단계씩 진행하고, 각 단계별 복구 절차도 미리 준비해야 겠다고 생각했다.