[오라클]전문가가 되고자 하는 사람들을 위하여

데이터베이스 전문가가 되고자 하는 사람들을 위하여

 

사람들은 SQL 서버를 어떻게 시작했을까? 항상 궁금했던 사항이지만 아마 대부분의 사람들을 몇 가지 방식들로 구분할 수 있을 것이다. 내가 말하는 것들과 여러분들이 겪었던 것과 얼마나 다른지 생각해보았으면 한다.

 

필자가 생각했을 때 가장 큰 구분은 그 사람이 대학 때 관계형 데이터베이스 학문을 배운 적이 있는가 없는가 하는 것이다. 우리나라 대학 학부에서 관계형 데이터베이스 학과나 SQL 서버 학과니 하는 것은 없는 것으로 알고 있다. 아마도 정확히는 모르지만 데이터베이스 학과도 없을 것이다. 그러므로 이러한 전공 여부는 Computer Science나 Programming 부분들이 전공 과목 안에 포함되느냐의 여부일 것이다. 

굳이 전공 여부를 따지는 이유는 단 하나다. 그 사람이 아카데믹하게 데이터베이스를 공부한 적이 있는가 하는 것이다. 왜냐면 여기서 몇 가지 문제들이 파생되기 때문이다. 데이터베이스를 이론으로만 공부하게 되었을 때 발생되는 문제가 바로 너무나 추상적인 이미지의 데이터베이스로 자리잡게 되기 때문이다. 누가 데이터베이스를 만들었는지는 알고 있어도 오라클이니 SQL 서버가 무엇인지를 모른다는 것이고, 데이터베이스라고 하면 너무 어렵고 하기 힘든 부분으로만 인식되게 된다는 것이다. 즉, 이론을 현장에 바로 적용하라면 할 수가 없다는 말이기도 하다. 

아카데믹한 데이터베이스론이 잘못되었다는 이야기가 아니다. 왜냐면 이론적으로 데이터베이스를 다루고 발전시켜야 할 분야도 있기 때문이다. 하지만 실무 현장은 전쟁터와 같다. 머리만 가지고는 싸울 수 없고 전투하기 위해서는 총검술도 배워야 하고 무기도 좋아야 할 것이다. 

필자는 그러한 많은 사람들을 보았다. 물론 필자도 그 안에 포함된다. “Select * from customers”라는 명령은 알지만, 이 명령을 어디에서 어떻게 실행해야 하는지는 모른다. 

다르게 시작한 사람으로는 관계형 데이터베이스를 목적으로 해서 한게 아니라, 그 주변 지역에서 어쩌다 보니 필요해서 다루게 된 경우이다.

여기에는 두 가지 유형이 있다. 첫 번째는 프로그래머에서 시작한 유형이 있고 두 번째는 시스템 엔지니어에서 시작한 유형이 있다. 많은 DBA(Database Administrator)들이 이 두 가지 유형들에 속하며 한쪽을 잘 하면 다른 쪽은 잘하지 못하는 경우가 있다. 

프로그래머로 시작한 사람들은 쿼리 기술, 스토어드 프로시저 프로그래밍, 데이터 모델링 등에 관심을 보인다. 엔지니어로 시작한 사람들은 데이터베이스 백업, 시스템 튜닝, DBCC와 같은 시스템 관련 프로시저 명령들, 데이터 복제 등에 관심 있어 한다. 그래서 간혹 SQL 서버를 설치하고 백업 및 몇 개의 튜닝 작업들을 진행하지만 INNER JOIN 구문은 알지 못하는 사람들도 있고, 정말 기차게 쿼리를 작성하고 데이터베이스를 설계하지만 DTS Export & Import는 한번도 해보지 않은 사람도 있다. 물론, 둘을 모두 하는 사람들도 있다. 그러고 보면, DBA라는 것 안에도 여러 가지 전문분야들이 있는 것 같다. 

이러한 것들이 자신의 백그라운드가 된다. 필자는 프로그래머로 시작해서 데이터베이스 엔지니어가 된 케이스이다. 그래서 데이터 모델이니 쿼리니 ADO니 하는 이야기가 편하다. 시스템 관련 기술이나 네트워크 관련 지식은 사실 많이 부족하기 때문에 노력하지 않으면 알 수 없다. 사실 처음에는 RAID가 무엇인지 SAN이 무엇인지에 대해서도 몰랐다고 솔직하게 고백한다. 두 가지 백그라운드를 모두 가진다는 것은 너무나 어려운 일이다. 왜냐면 프로그래밍적 백그라운드는 스스로 노력해서 성취할 수 있는 부분이 많이 있다. 환경들도 시뮬레이션 해보기 쉽다. 물론, 다양한 케이스를 본다는 것은 실무적인 경험에서 나오는 것이기는 하지만 말이다. 하지만, 프로그래밍 백그라운드만으로 시스템적 백그라운드를 가지는 것은 어렵다. 

왜냐면 시스템 엔지니어로써의 케리어는 상당 부분 시스템을 다루는 현장에서 지식을 습득하고, 여기에는 그만한 규모가 되는 회사에서 시간과 노력을 기울여야 나올 수 있는 지식이기 때문이다. 그렇다면 반대의 경우는 쉽게 습득할 수 있는가? 시스템 백그라운드를 가진 사람이 프로그래밍을 쉽게 접근할 수 있을까? 사실 이것도 쉽지 않다. 아무리 책을 보고 공부하고, 학원에 다닌다고 하더라도 근본적으로 시스템 엔지니어들은 프로그램을 작성하는 사람이 아니라, 프로그램을 이용하는 사람이다. 이러한 근본적인 차이를 무시하는 것은 어렵다. 
따라서 현실적으로 자신의 백그라운드가 무엇인지를 인정하고 들어가는 것이 스트레스를 덜 받는다. 자신이 둘다 잘한다고 생각한다면 복 받았다고 생각해라. 스스로를 잘 알게 되면, 자신의 강점은 무엇이고 자신의 약점은 무엇인지가 명확해진다. 주변의 여러 DBA들을 보면 이러한 필자의 주장에 공감할 것이다. 

관계형 데이터베이스는 어떻게 공부해야 할까?

데이터베이스 전문가가 되고자 하는 많은 후배들의 경우 겪는 아픔이 어떤 것을 어떻게 공부해야 데이터베이스 전문가가 될 수 있는지를 모른다는 것이다. 그건 맞다. 왜냐면 나도 모르니까. 대부분의 이런 경우는 목표가 불분명한 경우가 많다. 도대체 어떤 데이터베이스 전문가를 원하는 것이냐. 모든 것을 다 잘하는 사람은 없다. 샘플을 만들어서 원하는 유형이 무엇인지를 찾는 것이 급선무다. 쿼리 및 애플리케이션 튜닝을 전문적으로 하는 사람이냐, 모델러냐, 아니면 유지관리 전문가냐, 아니면 데이터베이스 시스템 아키텍트냐. 아니면 전문 강사냐? 여러 가지가 있다. 하나를 골라 잡아라. 

물론, 여기에는 국내 실정도 잘 살펴 보아야 할 것이다. 우리나라에 그런 직함을 가진 전문가들이 몇이나 될까? 그리 많지 않다. 수요와 공급을 잘 판단해서 내가 가야 할 분야를 파악해야 할 것이다. 목표가 구체적이라면 내가 가야 할 단계들이 명확해진다. 그럼, 무엇을 먼저 시작할 것인가? 

어떤 사람들은 오라클을 공부해야 하나 SQL 서버를 공부해야 하나를 가지고서 고민하는 경우도 있다. 올바른 고민이다. 객관적인 입장에서 어떤 데이터베이스를 공부하느냐에 따라서 해 야할 것들이 많이 달라진다. 유닉스 환경과 윈도우 환경은 사고 구조부터가 다르니 말이다. 어떤 것을 선택해야 하느냐에 대해서는 이야기할 수 없다. 그것은 개인적인 선호의 판단이지, 기준이 있는 것은 아니다. 

다만, 어떤 데이터베이스를 공부할 때에도 중요한 것은 단편적으로 해서는 안 된다는 것이다. 처음부터 끝까지 자신의 머리로 이해가 가고 아귀가 맞물려 있어야 해당 제품을 잘 알고 있다고 할 수 있다. 필자는 항상 매트릭스 이야기를 자주 하는데, 네오가 안 것은 기능이 아니라, 기능이 왜 나와야 하는지에 대한 이해로 매트릭스를 이해했다. 

집합형 사고란....?

필자가 좋아하는 데이터베이스 용어로 집합이라는 말이 있다. 하지만 이만큼 모호한 개념으로 사람들의 머리를 아프게 하는 경우도 없을 것이다. 어떤 사람들은 모든 데이터베이스 사용자들이 집합형 사고로 전환하면 쿼리 성능이 수십 배 빨라지고 코드의 길이도 줄일 수 있는 것처럼 이야기하기도 하고, 지금 필자가 생각하는 작업 방식과 집합형 사고 방식과 아주 많은 차이가 있는 것처럼 말하기도 한다. 

사실은 필자도 잘 모르겠다. 그러한 이야기를 다루는 책이나 세미나를 들어도 도대체 집합형 사고가 무엇인지 어떻게 하라는 것인지 혼란스러웠다. 그래서 필자 나름대로 우리의 SQL 서버 환경에서 집합형 사고가 무엇인지에 대해서 진지하게 고민해보고 내린 결론은 아주 쉽고, 명쾌한 데이터베이스의 원래 개념으로 회귀하라는 것이다. 

지금 우리가 쓰고 있는 오라클이니 SQL 서버, MySQL 등은 데이터베이스라고 불리우지만, 보다 원래의 종류는 관계형 데이터베이스(Relational Database)이다. 학교에서 배웠겠지만 데이터베이스에도 네트워크니 객체 지향형이니 하는 여러 종류의 데이터베이스들이 있고 그 중에서 가장 많이 이용되는 것이 관계형 데이터베이스이다. 

관계형 데이터베이스는 Relational Database의 번역된 의미이고 우리나라에서는 모두 그렇게 해석해서 사용하고 있다. 이 데이터베이스 카테고리에서 가장 중요한 개념은 관계 즉 Relation이다. 우리나라 말에서 관계라는 것은 어떤 하나의 대상과 다른 대상간에 미치는 영향이나 교섭 등의 의미를 가진다. 자, 이렇게 되면 Relation이라는 의미는 더욱더 모호하고 추상적인 개념이 된다. 하지만 원래의 이론에서 Relation이라고 지칭되는 것은 일반적으로 물리적 모델에서 테이블(Table)이다. 그리고 일반적으로 이해되기로 Relation은 관계라는 의미보다는 집합(Set)의 의미에 더욱 가깝다. 

다시 이야기하면, Relational Database는 Set-based Database(집합 기반 데이터베이스) 혹은 Set-Oriented Database(집합 지향형 데이터베이스)라고 보는 것이 맞는다는 것이다. 이게 차라리 우리가 원어민이라면 훨씬 더 쉽게 이해할 수 있을텐데 말이다. 

이런 데에서 우리는 집합형 사고를 시작해야만 한다. 집합형 사고로 전환할 때 우리가 가장 비근한 예로 드는 것이 바로, 절차형 프로그래밍에서 객체 지향형 프로그래밍으로 전환하는 케이스를 들고 있다. 간략히 설명하면 C 언어 등에서 사용되는 절차형 프로그래밍은 매우 명쾌하다. 프로그램의 시작부터 끝까지 하나 하나의 프로세스를 밟아서 기능을 수행해 간다. 복잡한 작업의 경우에는 시작부터 끝까지 너무 코드가 길어져서 나중에 디버깅이 힘들어지니까 중간 중간에 공유 코드들을 함수(Function), 프로시저(Procedure) 혹은 라이브러리(Library)로 두어서 공유한다. 

객체 지향형은 개념을 유기체의 세계와 유사하게 하나 하나의 독립된 단위들을 두어서 독립된 단위 간에 메시지를 보내고 받아서 일을 처리하게 된다. 예를 들어서 윈도우 XP라는 메인 클래스 세상이 있다면 오피스 워드라는 하나의 다큐먼트 클래스가 프린터에게 “이 문서를 프린터 해줘”라고 부탁하면, 해당 프린터 클래스 프랜드가 이 메시지를 수락해서 업무를 처리하고, 처리 못하는 경우에는 “나 지금 바빠서 못해”라는 식으로 대꾸하는 경우이다. 그러면 우리는 각각의 클래스에 대해서 얼마나 개성 있게 만들것인지만 잡아서 프로그래밍하면 된다. 가장 중요한 것은 내가 언제 어떤 클래스와 커뮤니케이션 할 것인지만 고민하면 되는 방식으로 사고가 전환된 것이다. 

집합형 사고는 모든 처리의 단위가 집합(Set)이라는 개념에서 출발하면 된다. 상식적인 우리의 사고 방식으로 1 + 2 = 3이라는 연산은 단순한 더하기 연산이다. 여기에 더 부가할 상황 설명은 없을 것이다. 하지만 좀더 깊게 파고들면, 여러 가지 이론적 배경을 생각할 수 있다. 여기서 1이라는 것은 무엇인가? 정수이다. 2라는 것은 무엇인가? 또한 정수이다. 1 + 2라는 것은 무엇인가? 바로 정수간의 더하기라는 연산이다. 연산의 결과는 3이다. 3이라는 것은 어떻게 나왔는가? 1+2라는 것에서 나왔다. 하지만 1+2가 3이 된다는 것은 누가 정했는가? 

바로, 우리가 정하였다. 이것은 일종의 약속이며 이 약속은 정수와 정수간에만 발생된다. 예를 들어서 “1” + “2” = “12”라는 것도 있을 수 있다. 이것은 문자 간의 정해진 약속이다. 이렇게 세상에는 단일 데이터 값간에 발생되는 연산자 및 연산 결과에 대해서 미리 헌법처럼 규정해 놓았다. 데이터베이스에서는 이러한 데이터 형식 및 연산을 스칼라 타입(Scalar type) 및 스칼라 연산자(Scalar operator)라고 부른다. 

스칼라라는 의미는 벡터(Vector)의 개념과 대비되는 개념이다. 벡터는 방향과 크기를 가지고 있는 데에 비해서, 스칼라는 크기 밖에는 없다. 즉, 1차원적 개념이라는 의미이다. 집합은 여러 원소들을 가짐으로써 성립된다. 원소가 하나도 없어도 일종의 집합이다. 즉 구조만을 가진 테이블도 일종의 집합이 될 수 있고, 하나의 원소만을 가지는 집합도 가능한 것이다. 

그래서 다음의 연산은 어떻게 될까? {1} -{2} = {1}, 각각 원소 하나씩만을 가지는 {1} 집합에서 {2} 집합의 차 집합 연산(Difference operation)이다. 이것은 차감(Minus) 스칼라 연산이 아니라 집합 개념에서 정의된 차 집합 연산이다. 차 집합 연산의 의미는 {1} 집합에서 {2} 집합의 원소를 제외한 나머지 집합을 구하는 것이다. 보다 쉽게 보자면 {1,2,3} - {2} = {1,3}이 되는 것이 차 집합 연산이다. 

집합형 사고라는 것은 바로 이렇게 집합 간에 이루어지는 연산 방식에 익숙해지고, 연산 결과로써 산출되는 집합이라는 대상에 대해서 고민하는 것일 뿐이다. 무언인가 특별한 방법이 숨어있거나 시스템 성능을 확 올릴 수 있는 비전은 아닌 것이다. 

집합이라는 것은 이렇게 집합 간의 연산 방식이 다르다는 것 이외에도 몇 가지 특성들이 더 있다. 집합이라는 데이터 형식은 매우 자유롭게 표현될 수 있고, 그 크기를 더 크게 만들거나 줄여서 만드는 파생 연산이 가능하다는 것이다. 아래 여러 쿼리들에서 1번 쿼리는 원래의 소스 집합이다. 이 집합을 가공하여 2번에서는 더 작은 집합으로, 3번에서는 추가 컬럼을 가지는 집합으로 4번에서는 집합의 크기를 더블로 만들었다. 즉, 파생 집합으로 가공하는 것이다. 

1. select a, b from tables
2. select a, b from tables where a < b 
3. select a, b, c=a+b from tables 
4. select * from (select a, b from tables) as x, (select 1 union all select 2) as y 

더 찾아보면 집합의 재미있는 여러 구조들을 알 수 있을 것이다. 결론을 내자면 집합형 사고라는 것은 기존의 스칼라 연산 방식에서 탈피해서 집합과 집합간의 연산 방식으로 생각을 고쳐먹는 것이다. 그것만으로도 좀더 사고의 폭을 확장시킬 수 있을 것이다. 

필요한 비타민, 아카데믹한 것

쿼리를 잘하려면, 대략 두 가지 지식들을 공부해야만 한다. 첫 번째는 쿼리를 어떻게 결합시켜서 다양한 용도로 사용할 것인가에 관한 문제이다. 이것은 쿼리 테크닉에 관한 정보이고, 프로그래밍에서 겪게 되는 다양한 문제들을 해결시켜 준다. 두 번째는 쿼리의 내부적인 개선이다. 이것은 쿼리가 어떻게 해석되고 수행되는 지를 잘 이해하고 의도하는 대로 수행되도록 쿼리를 작성하는 것이다. 

첫 번째가 쿼리를 유용하게 하는 것이라면 두 번째는 쿼리를 올바르게 하는 것이다. 한 가지 문제점은 우리가 SQL 서버를 설계하지 않았으므로 쿼리가 어떤 기준으로 해석되고 수행되는 지를 정확하게 알 수 없다는 것이다. 당근, 마이크로소프트가 도와주면 좋겠지만 현재 그럴 의도는 없는 것 같다. 

따라서, 쿼리를 올바르게 수행하는 데에 도움을 주는 여러 지식들은 자신이 스스로 예측해야만 한다. 물론, BOL(Books Online)이나 여러 SQL 서버 전문서들에서 이러한 내용들을 다루고 있다. 그 밖에도 관계형 데이터베이스의 일반론적인 부분들도 있다. 이러한 것들은 상당부분 아카데믹한 지식이지만 SQL 서버는 그러한 지식들을 기반으로 해서 설계된 것이다. 필자 또한 마이크로소프트에서 별달리 제공되는 특별한 정보는 없다. 후훗. 언제나 그런것 좀 얻어볼까 하고 항상 고민한다. 요즘은 인터넷이 발달해서 유사한 케이스나 다른 사람의 의견 등을 참조하기가 쉬워졌지만 무엇이든지 쉽게 얻을 수 있는 답은 없다. 여러분 스스로가 노력하고 시간을 투자해야 유사한 답이라도 찾을 수 있다. 필자나 여러분들이나 밟고 있는 선은 같다. 

옵티마이저는 데이터베이스의 핵심이라고 할 수 있고 옵티마이저를 모두 이해하는 사람이 있다면, 필자도 한번 만나보고 싶다. 하지만 일반적인 정보까지는 누구나 접근할 수 있다. 예를 들어 대부분의 관계형 데이터베이스들은 유사한 방식의 옵티마징 테크닉을 사용한다. 

쿼리가 입력되면 이 쿼리가 이번에 한번 파싱된 쿼리인지를 확인하는 작업을 거친다. 물론, 여기서의 확인은 단순한 스트링 비교이다. 따라서 의미론적인 동일성은 따지지 못한다. 실행 계획을 생성해야만 하면 이 쿼리를 단순화 시키고, Cardinality, Density, Selectivity, Statistics 등의 통계 정보들을 로딩해서 플랜 트리를 생성하고 이 플랜들에 대해서 비용 분석을 따지게 된다. 그리고 병렬 계획을 고려해서 나름대로 최적의 쿼리 실행 계획이 나오게 되는 것이다. 

좀더 깊게 들어가면 로딩된 통계정보들은 어떤 기준으로 비용 판단이 되게 되는가? 쿼리의 Where 조건절과 여러 JOIN 방식들에 대한 선택도와 카디널러티 계산에 따라서 비용이 산정된다. 우리는 언제나 이러한 통계정보가 충분하다고 생각되지만 사용 가능한 통계 정보들이 없다면 쿼리 옵티마이저는 어떻게 판단할까? 이런 경우에는 기본 가정(Default Condition) 이라는 것이 사용된다. 여기에는 균등 분포(Uniform Distribution), 조건식 독립(Predicate Independence), 조인 독립(Join Independence) 등이 이용된다. 이러한 기본 조건들은 대부분의 경우 합리적인 것이지만 이 가정에서 멀리 벗어나는 데이터를 가지는 경우 쿼리는 잘못된 판단 하에 악성 실행 계획을 생성할 가능성을 가지고 있다. 

조인 메서드의 선택이라는 것도 매우 의미있는 공부이다. 조인 메소드는 크게 Nested Loop, Sort Merge, Hash Match 조인의 세가지가 있다. 상세 내용을 모두 다 설명할 수는 없다. 내용이 많으므로 간단한 비유를 통한다면 포커 하기 전에 카드를 어떻게 섞는 것이 빠른가에 대한 예시로 대신할 수 있겠다. 포커를 하기 전에 카드가 제대로 된 한 벌인가를 확인하는 방법은 여러 가지가 있을 것이다. 

우선, 카드를 스페이드, 하트, 클로버, 다이아몬드의 각 그룹으로 나누고, 한 그룹에서 하나의 카드, 예를 들어 9를 뽑은 다음에 나머지 그룹들에도 9가 들어있는 지를 하나씩 확인해 나간다면 이것은 Nested Loop이다. 각 카드를 그룹별로 일단 정리해놓는다. 그리고 모든 카드들에서 하나의 카드를 꺼내었을 때 최상단의 카드가 동일한 9번이면 이것은 Sort Merge이다. 카드를 종류가 아니라 적혀진 번호순으로 정리한다. 예를 들어서, 섞인 카드에서 하나를 꺼내어서, 첫 번째 카드가 9번이면, 이 카드를 놓는다. 다음 장이 J이면 그 옆에 놓는다. 다음 장이 9번이면 이제 9번 카드가 있는 곳에 더한다. 이렇게 하면 맨 나중에 4장의 카드가 되지 않은 그룹이 있다면 이것은 완전한 카드가 아니다. 이것은 일종의 Hash Match 조인이다. 상당히 줄여서 이야기한 것이지만 이것이 가장 쉬운 조인 메서드를 이해하는 방식일 것이다. 물론, 이외에도 어떤 경우에 어떤 조인 방식이 좋은지에 대한 논의도 있을 것이다. 

사람들은 어떤 경우 너무 눈에 보이는 부분에만 얽매이는 경우가 많이 있다. 서브쿼리 평면화(Subquery Flattening)도 마찬가지의 경우이다. 다음과 같은 쿼리가 있다고 가정해보자.

select pub_name from pubs.dbo.publishers 
where pub_id in (select pub_id from pubs.dbo.titles where type = ‘business’) 

괄호 안의 쿼리는 일종의 인라인 쿼리로써 많은 사람들의 경우 이 쿼리가 우선 수행된다고 믿는 경우가 허다하다. 혹자는 왜 SQL 서버만이 괄호 안의 쿼리를 우선해서 처리하지 않느냐고 불평하기도 한다. 하지만 그것은 사실이 아니다. 일반적으로 쿼리 안의 결과를 선행 처리해서 성능상의 이익을 볼 수 있는 경우에는 괄호 안의 쿼리의 대상이 되는 테이블이 소량인 경우이다. 즉, 이 말은 괄호 안의 쿼리를 선행 처리한다고 해서 항상 전체 쿼리의 성능이 높지는 않다라는 것이다. 오히려 괄호 안의 데이터가 많아진다면 전체적인 성능은 최악이 된다. 

이 경우 현실적인 판단은 괄호 안의 서브 쿼리와 밖의 쿼리를 조인 방식으로 처리해버리는 경우이다. 이것은 상당히 논리적인 근거가 있는 것이다. 게다가 이러한 조인 연산은 First Row & Semi Join 방식으로 연결된 첫 행 이외의 로우는 건너 뛰게 될 것이다. 이러한 것들도 올바르게 쿼리를 수행하기 위해서 필요한 것들이다. 

후기

필자의 새로운 SQL BOOK이 탄생했다. “Deep Inside T-SQL 테크닉”(영진닷컴, 540P)이다. 제목을 보면 알 수 있듯이 Deep Inside SQL Server 2000 컬럼을 열심히 읽어주시는 독자들과 수많은 SQLER들을 위한 책이다. 꼭 사지는 않더라도 서점에 가서 한번씩 책 내용이라도 보아주었으면 한다. 왜냐고? 그것은 이 오랜 컬럼을 끌어오면서 여러분들과 이야기했던 SQL 서버 프로그래밍에 대한 필자의 생각과 경험이 묻어난 것이기 때문이다. 많은 내용들이 여러분에게는 익숙한 것이고 약간의 보여주지 않았던 실무적인 예제들을 추가했다. 필자가 책을 쓰면서 나름대로 세워 논 원칙이 있는데, 그것은 바로 “내가 쓰고 싶은 만큼만 쓰자.” 라는 것이다. 언뜻, 이 말은 이해하기가 참 힘들다. 그럼, 다른 사람들은 쓰고 싶지 않은 내용도 쓴다는 것인가. 뭐냐? 하지만 사실 그렇다. 쓰고 싶지 않아도, 잘 알지 못해도, 그래도 책은 쓸 수 있는 것이니깐. 

끝으로 DEEP INSIDE SQL SERVER 2000에 관련되어 질문하고자 하시는 분이 있다면, 필자의 전자 메일 주소로 [SQLMAG]라는 말머리를 붙여서 메일을 보내기 바란다.