고민하다가 다시 글을 씁니다. 사실 김대우님께서 글을 쓰신 얼마 후에 그 내용을 봤습니다. 저도 감정이 받쳐서 몇시간동안 격한 반론을 쓰다가 이게 뭐하는 짓인가... 싶어서 덮어버렸었습니다.

처음 글을 썼을 때부터 지금까지, 제 목적은 김대우님과 싸우는 것이 아닙니다. 전 SQL 서버 전문가에게 짧은 SQL 서버 지식을 뽐내려고 할 만큼 어리지도 않고, 난투에서 희열을 느끼는 성격도 아닙니다. 감정은 정리하고, 논점이 궤도를 벗어난 것 같아 차근차근 다시 써보겠습니다. 김대우님께 답을 내놓으라고 강요하려고 쓰는 것은 아닙니다. 단지 제가 애초에 가졌던 불만의 내용이 크게 왜곡되고 있는 것 같아 정리를 해보고 싶은 것 뿐이랍니다. (어쩌면 제대로 이해하고 계시는데 제가 거꾸로 잘못 짐작하고 있는 걸 수도 있습니다만...)

저는 지금도 SQL 서버가 ACID 원칙을 지키지 않는다고 생각합니다. 왜냐하면 적어도 제가 알기로는 트랜잭션에 있어서 ACID 원칙이란 어떠한 경우에도 반드시 지켜져야 하는 것이라고 배웠고, 다시 여기저기 검색이나 서적을 뒤져봐도 그렇게 나와있으니까요. '어떠한 경우에도'라는 것은 에러처리 코드가 있건 없건 디비 서버에 부하가 크건 적건 그런 모든 조건들을 막론하고 항상 지켜져야 하는 것이라는 뜻이 아닌가요. 스크립트 작성자가 에러처리를 제대로 하지 않았다고 해서 롤백이 되지 않는다면 하나의 최소 동작으로 돌아가야 할 트랜잭션이 일부는 적용되고 일부는 적용되지 않는, 데이터가 불일치하는 경우가 생기게 되지 않습니까.

물론 김대우님이 보여주신 스크립트의 의미는 압니다. 문제가 생겼던 저희 소스(제가 작성한 것은 아닙니다만)에도 보여주신 것과 거의 같은 에러처리 코드가 있었습니다. 그런데도 문제가 발생했습니다. 원인이 파악되지 않는 모종의 에러가 발생했는데, 에러처리 코드에서 Rollback을 명시했는데도 롤백되지 않았습니다. 한마디로 에러처리 코드를 뚫어버린 겁니다. 김대우님은 DBA이시기 때문에 이런 일은 있을 수 없다고 생각하시겠지만 저는 개발자이기 때문에 있을 수도 있다고 생각합니다. 적어도 현실에서 저희 회사의 사례에서는 분명히 에러처리코드를 타지 않았습니다.

그렇다고 에러처리 코드에 문제가 있었다고도 생각되지 않는 상황이었습니다. 에러처리 코드가 정상적이었다는 것은, 제가 썼던 최초의 글을 보시면 아실 겁니다. 그 에러를 발견하게 된 것이 연달아 계속 자료 입력이 안되는 것 때문이었는데, 자료 입력이 안되었던 이유가 바로 키 위반으로 에러처리 코드에서 롤백되었기 때문입니다. 적어도 최초의 에러가 발생한 이후, 그 다음에는 에러처리 코드가 정상적으로 동작했기 때문에 연이은 자료 입력들이 줄줄이 롤백되어버린 거죠.

그 에러 자체는 분명히 버그라고 생각되지만, 그 버그를 문제삼을 것은 아닙니다. 그리고 에러처리 코드를 타지 않은 것도 부차적인 문제이구요. 제가 당황한 것은 그 모든 에러가 발생한 후에 자동 롤백이 되지 않은 것입니다. (그러니까 여기서 김대우님과 저의 초점이 달라지게 되겠습니다)

제가 직면한 현실에 해당되지 않는, 제가 쉽게 알아보고 사용하는 수준보다 더 복잡한 레벨에서 문제가 생겼다면 그다지 문제삼을 이유가 없었을 것입니다. 그리고 어떻게 상황이 굴러가다보니 제가 튜닝을 하기도 했습니다만 원래 저는 DB 관리를 즐기지도 잘하는 편도 못됩니다. 그런데 저희 팀 전체가 매달려서 뒤져봐야 했던 문제였기에 원래는 DB 관리와는 업무 관련이 적은 저까지 매달려야 했고, 그 과정에서 에러처리가 되지 않은 부분과 그 이후 다시 롤백까지 되지 않은 부분을 발견한 겁니다.

처음 엔지니어 기질이 있다고 말씀하신 의미를 이제야 짐작하는지도 모르겠습니다만, 다른 SW도 아닌 데이터베이스 서버에서 트랜잭션이 완벽한 ACID를 지원하지 못한다면... 그것도 김대우님이 말씀하신 것과 같은 일반적인 방법인 에러처리 코드를 통한 롤백 처리까지도 했는데도 롤백이 이루어지지 못했다면 그건 마이크로소프트의 책임이라고 생각한 겁니다.

여담입니다만, 관련 문서를 뒤져보다가 윈도우 서버에 포함된 트랜잭션 코디네이터에 대한 내용을 봤습니다. 자세히 살펴볼 시간은 없었지만 아마도 다른 일반적인 DTP 환경에서의 TP 모니터의 역할을 하는 듯 하더군요. 그 내용으로 때려짐작해보건대, 김대우님이 말씀하신 '분산 트랜잭션'에서 SQL 서버의 트랜잭션의 ACID 속성들을 보장해주는 역할을 하는 듯 한데요. 제 생각에는 이 트랜잭션 코디너이터가 SQL서버의 트랜잭션에서의 부족한 면을 채워주지 않나 싶습니다.

하지만 제가 생각하는 문제는.. DTP 환경에서야 여러 DB 서버들이 동시에 트랜잭션에 참여하게 되므로 단일 DB 서버의 트랜잭션 기능만으로 충분하지 않게 되지만, DTP가 아닌 단일 DB 서버 환경에서라면 TP 모니터나 트랜잭션 코디네이터 없이도 DB 서버 자체만의 기능으로도 최악의 경우를 가정한 트랜잭션 보장이 되어야 한다고 생각하는 겁니다. 그제가 아는 트랜잭션이니까요. 오라클에서 그렇게 동작하기는 하지만, 오라클과 SQL 서버를 비교한 것이 아닙니다. (저는 오히려 마이너 디비인 파이어버드를 더 선호합니다.)

제가 SQL 서버에 가진 불만의 핵심은 이것입니다. 트랜잭션에 대해서는 분명한 정의가 있고, 너무나 단순한 개념이라서 정규건 비정규건 전산 교육을 받은 사람이라면 누구나 아는 것인데 왜 그것이 지켜지지 않는가, 입니다. 물론 다른 DB 서버에서도 트랜잭션을 제대로 지원하지 않는 경우가 있습니다만 그 경우에는 트랜잭션의 이런 부분은 지원하지 않는다, 라고 공공연하게 알려져 있지 않습니까. 제가 먼저번에 썼던 글의 마지막에서도, 김대우님의 설명이 제게 답이 되지 못한다고 썼던 것도 이것 때문입니다.

그 다음의 것들은 부차적인 문제가 되는데... 먼저 클러스터드 인덱스의 내부적인 동작 방식에 대해서는 제가 잘못 알았던 것 같습니다. 클러스터드 인덱스가 가진 장단점을 알아보기 위해 여기저기 문서들을 뒤져보다가 잘못 이해한 부분이 있었던 것 같은데요. 적어도 하나의 레코드가 삽입된다고 해서 그 뒤의 모든 레코드가 시프트되지는 않는 것 같습니다.

하지만 제가 클러스터드 인덱스터드 인덱스에 대해 가졌던 의문점은 아직 거의 그대로 있습니다. 튜닝 과정에서 클러스터드 인덱스를 제거했던 이유는 클러스터드 인덱스가 항상 최적의 결과를 내지 못한다는 msdn의 공식 문서나 테크넷 강의 문서 등 여러 문서들 때문이었습니다. 제가 기억하기로 클러스터드 인덱스가 최고의 선택이 아닐 수 있는 몇몇 경우가 있는데, 제 판단으로는 저희 회사 서버가 그런 경우들과 공통점이 많다고 생각했던 겁니다.

물론 저도 다른 어떤 필드이든 클러스터드 인덱스를 새로 잡아주는 것이 좋다고는 생각했으나 현재 필드들 중 마땅히 클러스터드 인덱스로 잡을만한 것이 없었고, 또 의미없는 일련번호 등을 추가하기에는 껄끄러운 문제들도 있어 그냥 힙으로 두게 되었습니다.

결과적으로 PK 필드에서 클러스터드 인덱스만 넌클러스터드로 바꾸었는데, 실로 놀랄만한 성능 향상이 있었습니다. 수시로 CPU 점유율이 100%를 치는 상황이 뭐가 튜닝이 된 거냐고 말씀하셨지만, 그 전까지만 해도 하루에만도 두세차례씩 SQL 서버가 아예 먹통이 되어서 길게는 두세시간까지 아예 응답을 하지 않는 상황이 계속 반복되었었기 때문에, CPU가 100%를 치건 말건 몇달이 되도록 단 한번도 멈추지 않는 지금 상황을 성공적인 튜닝이라고 부르는 것에는, 전문 DBA가 아닌 제 입장에서는 양심에 손을 얹고 전혀 거리낌이 없네요. 물론 그 이후에 수백개의 테이블들 중에서 자주 사용되는 몇개 테이블에 대해서는 필요없는 몇개의 인덱스를 삭제하고 스토어드 프로시저 몇개도 수정하기는 했지만, 1차로 했던 클러스터 인덱스 제거가 가장 큰 영향이 있었다고 판단하고 있습니다.

물론 이것으로 튜닝이 완벽하다고는 절대로 말할 수 없는 것이기는 하지만, 이전에 말씀드렸다시피 문제의 근본적인 원인은 총체적으로 엉망이 되어있는 구조 때문이기 때문에 현 상황에서 완벽에 가까운 튜닝은 완전한 재개발을 통해서만 가능한 상황입니다. 재개발을 계획중이기는 하지만 몇달 정도는 지체될 상황이기 때문에, 그 이상의 튜닝은 힘듭니다. 지금은 엉망이 되어있는 현 시스템의 자잘한 버그들을 잡고 재개발 계획을 잡는데만도 인력이 너무 부족한 상황이기 때문입니다.

어쨌든.. 제가 클러스터드 인덱스를 거론한 이유는, 이렇게 클러스터드 인덱스가 오히려 성능에 좋지 않은 결과를 내는 경우도 있는데도 굳이 비표준이라고 할 수 있는 클러스터드 인덱스를 PK 필드에 무조건 암시적으로 잡아버리는 것이 문제가 있지 않나 하는 것이었습니다. 물론 말씀하신 것처럼 SQL 서버의 인덱스 설계 자체가 클러스터드 인덱스가 존재하는 테이블(그러니까 힙이 아닌) 구조를 위주로 설계되어 있기 때문이라는 것은 이해를 합니다만, 결과적으로는 클러스터드 인덱스의 장단점을 잘 알지 못하는 경우에 기본설정 때문에 성능이 오히려 떨어질 수 있다는 거죠.

위의 두 예에서... 물론 대체적으로는 그렇지 않고 특이한 경우일 수도 있겠습니다만, 기본 설정이 어떻다는 것, SQL 서버의 설계 철학이 어떻다는 것을 알지 못하면 오히려 예상 밖의 에러가 발생하거나 성능이 저하되는 경우가 생길 수 있지 않습니까. 실제로 제가 겪었던 두가지 예에서처럼 말입니다.

마지막 한가지, 비주얼 C++의 표준 준수에 대해서 말해보겠습니다. 말씀하신대로 ISO C++ 표준이 비주얼 C++ 6.0보다 뒤에 제정되었습니다. 그런데 그 차이는 겨우 수개월로, 비주얼 C++ 6.0이 한참 개발중일 때 이미 ISO C++ 스펙은 거의 완전히 안정 상태였고 그 내용이 공개적으로 알려진 가운데 최종 인준만 기다리는 상태였습니다. 따라서 당시에 개발중이던 다른 대부분의 C++ 개발툴들은 많건 적건 그 표준안을 반영하면서 개발중이었습니다. 그런데 표준안 발표 직전에 출시된 비주얼 C++이 가장 표준안에서 거리가 멀었구요. 뭐 표준안까지 거론하지 않아도 저희 사이트에 뒤져보면 표준이 아니라 C++에 대한 일반 상식을 벗어나는 황당한 예들도 있습니다.


아마도 김대우님이나 김상욱님이 그렇게 격하게 반응하셨던 것은 제가 반MS 성향을 가지고 있기 때문이 아닌가 생각됩니다. 물론 저는 반MS적입니다. 하지만 그렇다고 무조건 뭐든지 다 나쁘다라고 몰아붙이거나, MS 망해라 하고 저주를 퍼붓는 막가파식 안티는 아닙니다.

저희 포럼 내에도 상당한 친MS적인 분들이 있는데, 오프모임에서나 온라인상에서나 자주 논쟁을 하기는 하지만 그 논쟁이 감정으로 치달은 적은 단 한번도 없었던 것으로 기억합니다. 오히려 얘기를 주고받을 수록 더욱 더 재밌게 전개되죠. 저는 MS가 보여주는 나쁜 점들에 대해 객관적인 사실과 논거를 제시하고, 또 다른 몇분들은 그에 대해 역시 객관적인 사실과 논거로 반박하고, 그런 식입니다. MS를 두고 서로 반대쪽에 앉아서 몇시간씩 술잔을 부딛히면서 즐겁게 논쟁하는 기분을 이해하실지요. 혹 전혀 이해가 안되신다면 돌파리 정치꾼들이 판치는 100분토론을 너무 많이 본 후유증이라 생각됩니다. ^^

저는 아마도 영원히 반MS일 겁니다. 그렇다고 MS를 옹호하는 분들과 얘기가 안된다고는 전혀 생각하지 않습니다. 오히려, 생각이 다른 엔지니어들끼리 제대로 토론하면 같은 생각을 하는 사람들끼리는 가질 수 없는 재미가 장난 아니랍니다. 더욱이 김대우님과 같은 분과 함께라면 더욱 그렇지 않겠습니까.