난 있다. 창피한 일이지만 10여년 전 어떤 골프장 웹사이트 개발로 바쁠 때 운영 데이터베이스 작업 중 테이블 하나를 날려버렸었다.
그땐 의욕이 앞서고 안정성에 대한 개념이 별로 없어서 개발용 데이터베이스를 따로 만들지 않고 운영 데이터베이스에 직접 붙어서 작업을 했다. 다행히 백업 테이블이 있고 고객이 수기로도 관리하던 사항이라 시간이 좀 들더라도 복구가 가능했지만 그런 대비책이 없었더라면 어떡했을까 지금도 생각해보면 아찔하다.
이런 일이 나만의 실수라면 한 번의 해프닝으로 지나칠 수도 있을 텐데 나를 포함해 앞으로도 누구나 이런 실수가 가능하다는 데에 간과할 수 없는 중요성이 있다. 10여년을 다양한 프로젝트를 하면서 다양한 개발자를 봤는데 2~3년에 한번씩은 누군가 이런 사고를 만드는 것 같다.
운영 데이터베이스에 접근할 정도면 신참은 아니고 오히려 어느 정도 개발 경력이 있는 사람들이 이런 실수를 한다. 경력이 쌓이다보니 머리보다 손이 빨라 자기도 모르게 실수를 한다. 순간의 클릭이나 엔터키 입력이 재앙을 부르는 것이다.
개인적인 문제에 더해 그 환경에 있어서도 사고를 부를 요소를 갖추고 있는 경우 이런 일이 발생한다. 웬만큼 규모가 있고 포멀한 작업 방식을 따르는 조직이라고 하더라도 개개인의 행동을 일일이 통제할 수 없기 때문에 사고의 위험성은 꼭 존재한다. 그 사고의 위험성을 간과한 어떤 빈틈이 있는 것이다.
어떤 대비책이 있을까?
가장 효과적인 방법은 운영 데이터베이스에 읽기 전용 사용자로 접근하는 것이다. 애플리케이션 단에서는 읽기, 쓰기가 다 가능한 경우가 대부분이겠지만 개발자가 데이터베이스 전용 클라이언트로 접근할 때는 읽기 전용 사용자, 즉 select만 가능한 사용자로 제한해서 데이터를 수정, 삭제할 수 없게 하는 것이 좋다. 사실 운영 데이터베이스를 개발자가 직접적으로 수정할 일은 별로 없잖아.
다음으로 접근 통제를 생각해볼 수 있다. 일정한 사용자, 일정한 컴퓨터에서만 데이터베이스에 접근할 수 있게 하고 다른 사용자나 컴퓨터는 막는 것이다. 이 경우 전반적인 위험성은 감소하겠지만 완전히 안심할 수는 없을 것이다. 그래서 관리 절차상의 접근 통제뿐 아니라 프로그램적으로 통제하는 패키지 소프트웨어가 다수 나와 있다. 데이터베이스에 애드온 형태로 동작하는 것으로서 사용자의 모든 작업을 기록하고 통제한다.
다음으로는 데이터베이스 제품별로 대비책이 있을 수 있다. Oracle은 10g부터 테이블 삭제(drop)를 복구할 수 있는 휴지통(recycle bin) 기능을 사용할 수 있으며 SQL Server인 경우 백업과 트랜잭션 로그를 잘 관리하면 어느 정도는 특정 과거 시점으로 온전하게 되돌릴 수 있다.
작업자 차원에서의 대비책으로는 auto commit되지 않게 하는 것이 필요하다. drop table을 한 경우 소용 없겠지만 단순 delete문인 경우 auto commit이 아니라면 삭제를 취소할 수 있으므로 아주 유용하다.
마지막 대비책은 긴장이다. 병사여~ 긴장을 늦추지 마라!
