#title 튜닝에 들어가면서
이 문서는 데이터베이스 성능 튜닝에 필요한 기본 개념을 설명한다. 혹자는 데이터베이스 성능 튜닝이 고급기술(?)이라고 한다. 그러나 필자가 보기에는 결코 고급기술이 아니다. 단지 기본에 대한 응용력일 뿐이다. 몇 가지만 알아도 데이터베이스 성능 튜닝은 70% 정도는 할 수 있다. 나머지는 조금 더 심층적으로 고려하면 이룰 수 있다. 
 
이 문서는 먼저 성능 튜닝의 절차와 간단한 예제를 본다. 본격적인 내용은 데이터베이스 모델링과 설계에 대한 이야기로 시작한다. 그 이유는 설계가 성능을 결정하는 많은 요소를 가지고 있기 때문이다. 시스템의 생명 주기 동안에 모델링과 설계가 미치는 영향은 매우 크다. 계속적으로 이러한 영향을 살펴보고 우리의 목표인 “정보의 질 향상”을 위해 계속 노력할 것이다. SQL을 다루면서도 설계에 대한 언급을 계속할 것이다. 모델링과 설계 부분에서는 실제 물리적인 구현에 어떤 영향을 받는가 설명하므로 종합적으로 알지 못하면 이해가 안가는 부분도 있을 것이다. 물리적인 구현에 대한 내용을 찾아가면서 읽어야 할 것이다. 
 
중요한 것은 튜닝의 시기이다. 많은 엔지니어(필자는 개발자, 관리자 등 모든 IT하는 사람들을 엔지니어라고 한다.)들은 성능 튜닝은 개발이 끝나고 하는 작업이라고 알고 있지 않다. IT를 조금 했다 하는 사람들은 성능 튜닝이 개발 초기 단계부터 이루어져야 한다는 것을 알고 있다. 그러나 “실무는”는 그렇지 않다고 한다. 아마도 학점과 기업의 성과가 틀린 것이라 그럴까? 그렇지는 않을 것이다. 실제로 성능 튜닝을 위해 개발 초기부터 DBA를 투입하게 되면 돈이 많이 들어간다. 그러나 실패를 해본 사람들은 DBA의 중요성을 알고 있다. 실패한 원인이 뭘까? 기본을 무시했기 때문이다. 
 
두 번째로는 물리적인 요소에 대해서 다룰 것이다. 여기서 말하는 물리적인 요소는 아마도 “구축”에 관련 것일 것이다. 우리가 간과하고 대충 넘어가는 것들이 전체적인 시스템에 어떤 영향을 미치는지 살펴볼 것이다. 
 
세 번째로 우리는 SQL에 대해서 DBMS가 어떻게 움직여야 최적인지 기본 원리를 통해서 응용해 볼 것이다. 보통 이 단계를 어플리케이션 튜닝이라고 한다. 어플리케이션 튜닝이라고 이름이 붙인 것을 의아해 할 독자도 있을 것이다. 아마도 어플리케이션이라 함은 Power Point와 같은 응용 프로그램을 상상해서 그럴 것이다. SQL도 파싱하고 컴파일 되어야만 우리가 "Hello World"를 콘솔에 찍을 때처럼 동작한다. 그러므로 어플리케이션 프로그램임은 분명하다. 
 
몇 억짜리 장비를 가지고서도 몇 백만 건에 허덕이는 시스템과 몇 백 만원 남짓하는 장비를 가지고도 몇 백만 건의 데이터를 아무런 무리 없이 사용하는 것을 보면 전자의 경우 무언가 잘못된 것임은 확실하다. 이 정도면 DBA를 프로젝트 초기에 투입하는 것이 프로젝트를 성공적으로 이끌기 위해 필요하다는 것을 알 수도 있을 것이다. 
 
사실 튜닝을 하게 되면 어떤 플랫폼을 사용하느냐에 따라서 튜닝의 접근방법이 달라질 수 있다. OS 자체에서 제공되는 툴을 이용하여 진단을 할 수도 있고, DBMS에서 제공하는 툴을 이용하여 접근을 할 수도 있다. 이 책에서는 Microsoft Windows 기반의 MSSQL Server를 이용할 것이다. 또한 Oracle에 대한 접근 방법도 소개할 것이다. Oracle의 경우 많은 튜닝에 관련된 문서들이 존재하는데 MSSQL Server는 튜닝에 관련된 문서를 좀처럼 찾아보기 힘들다. 그러므로 MSSQL Server에 많은 집중을 할 것이다. 
 
많은 독자는 데이터베이스의 성능 튜닝의 목적은 "속도"에 있다고 알고 있을 것이다. 그러나 이것은 일부만을 알고 있는 것이다. 성능 튜닝의 목적은 "속도"가 아니라 "정보의 질 향상"에 있다. 정보의 질 향상은 바로 "기본"에서 나온다. 이 문서는 계속 "기본"을 다룰 것이며, 그 기본에서 조금 응용한 것이 전부다. 개발기간 중에나 개발이 종료된 시점에서도 "정보의 질 향상"은 항상 우리의 목표가 될 것이다.