잊는다[忘]는 것은 돌아보지 않는다는 뜻이다. 따지지 않는다는 뜻이다. 이것을 해서 먹고 사는 데 도움이 될지, 출세에 보탬이 될지 따지지 않는다는 말이다. 그냥 무조건 좋아서, 하지 않을 수 없어서 한다는 말이다. 붓글씨나 그림, 노래 같은 하찮은 기예도 이렇듯 미쳐야만 어느 경지에 도달할 수가 있다. 그러니 그보다 더 큰 인생의 문제를 해결하려면, 깨달음에 도달하려면 도대체 얼마나 미쳐야 할 것인가?
- 정민의 "미쳐야 미친다[조선 지식인의 내면 읽기] 중에서
아마도, 올해 안에는 유콘(Yukon)이라 불리우는 SQL Server 2005가 출시될 것이다. 마이크로소프트가 SQL Server 2006이라고 이름을 바꾸지 않는 이상은 그렇지 않겠는가. 아마도 이번에도 일정을 연기한다면, 마이크로소프트가 아니라, 양치기 소프트라 불러야할것이다. 이미, 2003년말을 약속하였다가, 2004년을 지나서야 베타 2 버전을 내놓고 있으니 말이다.
항상 느끼는 것이지만, 새로운 제품이 출시되면, 내가 알고 있던 노하우들이나 기술들을 더 이상 이용할 수 없는 것은 아닐까 느끼기도 하고, 새로운 제품에서 지원되는 기능들로 나의 고단한 하루가 조금은 편안해지지 않을까 즐거워하기도 한다.
새로운 유콘 서버는 양자의 두려움과 설레임을 모두 가지고 있다. 엔지니어로서의 DBA들은 닷넷이라는 객체 지향 언어를 알아야만 하고, 이것은 나 자신이 나와바리를 벗어나는 것이다. CTE와 같은 기술들은 SQLER들이 지겹도록 써야만 했던, 상관 쿼리나 크로스 조인을 쓰지 않아도 되도록 할 것이다.
필자도 이러한 두려움과 설레임을 가지고서 유콘을 접하려고 한다. 이 글을 읽는 사람들보다 필자가 유콘과 더 많이 친할 것이라고 생각하지 말아주기 바란다. 내가 마이크로소프트에 근무하는 것도 아니고, 더 더구나 유콘을 개발하거나 테스트한 것도 아니다. 여러분과 같은 선상에서 출발할 것이다. 빠르다면 발가락 하나 정도.
유콘 & 닷넷(Yukon and .NET)
유콘의 정식 명칭은 SQL Server 2005이다. 이전 네이밍 룰과 크게 다르지 않다. 혹자는 SQL Server.NET이라고도 부른다. 그만큼이나 유콘의 주요 특징은 닷넷 코드가 데이터베이스 엔진에 포함되었다는 것일 것이다. 인터넷에서 유콘 관련 기사를 찾아보면, 많은 경우 위드비(Whidbey)와 같이 출시가 연기되었다는 기사를 많이 볼 수 있다. 알고있다시피, 위드비는 차 세대 비주얼 스튜디오의 이름이다. 개발도구 때문에 SQL 서버의 출시가 늦어진다고 명시적으로 말하고 있지는 않지만, 위드비와 유콘은 많은 관련이 있다.
왜냐면, 위드비가 유콘 서버를 이용하는 데에 필수적인 도구이기 때문이다. <그림 1>은 닷넷에서 데이터베이스 관련 작업을 수행하는 SQL Server Management Studio라는 것이다. 새로운 데이터베이스를 생성할수도 있고, 쿼리를 수행하거나 실행 계획을 확인해 볼 수도 있다. 즉, 기존의 쿼리 분석기가 발전한 모습이라고 볼 수 있다.
<그림 1> SQL Server Management Studio
더보기
<그림 2>는 위드비의 데이터베이스 프로젝트 화면이다. 두 환경의 모습이 그리 다르지 않다. 아니다. 인터페이스 자체가 완전히 동일하다. 왜냐하면, SQL Server Management Studio 자체가 유콘에 내장된 비주얼 스튜디오 닷넷이기 때문이다.
위드비의 화면에서 데이터베이스 프로젝트를 보면, 아예 스토어드 프로시저를 추가할 수도 있다. 물론, 닷넷 스토어드 프로시저이다. 여기서 프로시저를 작성하고 Deploy하면, 유콘 서버에 스토어드 프로시저로 생성된다. 사용할때는 프로시저로 래핑시켜 이용할 수 있다.
<그림 2> 위드비에서의 데이터베이스 프로젝트
유콘에 와서 데이터베이스와 닷넷은 구분하기 어려울 정도로 완전히 통합된 모습을 보인다. 물론, 아직 베타 2 버전이기는 하지만, 유콘과 닷넷은 하나라고 할 수 있고, 유콘 안에는 닷넷이 있다. 닷넷으로 유콘에 접근하는 것은, SQL 서버에서 저장 프로시저를 작성하는 것만큼이 쉬워졌고, T-SQL 프로시저가 할 수 있는 일들은 닷넷으로도 가능하게 될것이다.
오라클은 이전 버전부터 JVM(Java Virtual Machine)이라는 것을 통해서 데이터베이스 환경 안에서 자바를 지원하였다. 유콘에서와 마찬가지로 오라클에서 자바 저장 프로시저를 작성하는 것이 가능하다. 어떻게 보면, 마이크로소프트에서의 유콘은 이러한 경쟁사의 장점을 통합한 것일 수도 있다. 보다 심한 것은, 닷넷 CLR(Common Language Runtime)이 데이터베이스 프로세스 안에(In-Process)서 움직인다는 것이다. 닷넷을 해석하기 위해서 외부의 프로세스와 통신하지 않을 것이고, 닷넷 DLL들은 등록된 이후에 삭제되어도 무방하게, IL 코드 자체가 저장되게 된다. 마이크로소프트는 이 모든 제품들이 자신들이 개발한 것이고, 앞으로 죽~ 운영체제에 내장될 것이기 때문에, 더 더욱 시너지 효과를 가진다.
앞으로 개발자들은 여러 가지 언어들을 지원하는 닷넷 프로그램 코드들을 작성해서 데이터베이스를 확장하거나 SQL 서버와 클라이언트들과의 직접적인 통신을 하는 것이 가능하다. 닷넷 2.0에서는 SQL 서버에 Native한 여러 클래스들을 지원한다. 물론, SQL 서버와 무관한 네트워크나 암호화 등의 여러 프로그래밍 기술들을 사용할 수도 있을 것이다. 이것은, 닷넷 환경에서 개발자는 시스템 및 백 엔드 데이터베이스에 대한 모든 자원들을 액세스하고 이용할 수 있는 아키텍처를 지니는 것이 된다.
개발자들은 자신들의 스타일대로, SQL 서버를 이용할 수 있을 것이다. T-SQL의 에러 처리가 마음에 들지 않는다면 C#의 Try … Catch를 사용하면 된다. 데이터베이스에 VB.NET으로 작성된 암호화 모듈을 사용하여 여러가지 암호화 모듈을 만들 수도 있다. 이전에는 C++로 작성된 확장 DLL을 사용하거나, 클라이언트 단에서 개발해야만 한다.
데이터베이스 엔지니어들에게는 이것이 악몽일 수도 있을 것이다. 이전 데이터베이스 엔지니어들은 데이터베이스에 대한 모든 제어권을 가지고 있었다. C++로 작성된 확장 프로시저만 아니라면, 모든 저장 프로시저들을 이해할 수 있었고, 트리거들의 소스 코드들도 이해할 수 있었다. SQL 서버 2000의 쿼리 분석기는 전통적으로 데이터베이스 엔지니어에게 익숙한 가벼운 클라이언트 환경이었고, 이것만으로도 SQL 서버를 이용하는 데에 아무런 문제가 없다.
이제는 엔지니어들도 두 가지 중에 하나를 선택해야만 한다. 닷넷 언어를 배워서 이를 응용하던지, 완저히 데이터베이스의 저장 공간 및 백업, 모니터링만을 담당하는 SE로서의 역할만을 담당할 것인지 말이다.
새로운 환경이 수많은 데이터베이스 엔지니어들에게 거부감을 들게 하고 있다. 물론, 필자도 포함해서 말이다. 마이크로소프트에서는 닷넷이 배우기 쉽고, 이를 배우고 나면, 더 높은 생산성을 기대할 수 있다라고 말하고 있지만, 쉬운 일은 아닌 것 같다. 하지만, 중요한 것은 데이터베이스 엔지니어들이 스토리지, SQL 서버 엔진, 백업 및 리스토어 기술, 리플리케이션, 저장 프로시저 및 쿼리의 올바른 이용, 네트워크 구성 등에는 전문가일 수 있지만, 프로그래밍 전문가는 아니라는 것이다. 물론, 모두를 다 잘하는 사람도 있겠지만 말이다.
그러나, 불평만을 할 것은 아니다. 경험해보지 않고, 비평만을 일삼는 것은 용기없는 짓이다. 분명히, 유콘에 적용된 새로운 기술들은 SQL 서버의 응용 및 확장을 가능하게 할 것이고, 이전 버전에서는 불가능했던 일들을 가능하게 할 것이기 때문이다. 따라서, 우리는 항상 실제로 해봐야만 진실을 알 수 있다.
앞으로의 진행 방향
별다른 순서 없이 진행할 예정이다. 예를 들어서, 설치부터 T-SQL은 무엇이 달라졌느냐?, 유콘에 등장한 스키마라는 개념은 무엇이냐부터 시작하지는 않을 것이다. 아무거나 자료가 준비되는 대로, 그것을 설명할 것이다. 필자도 제대로 모르기 때문에, 잡지에 실린 글을 모조리 믿어버리면 곤란하다. 최대한 노력하겠지만, 아시다시피 그다지 나는 부지런한 사람은 아니다. 내가 생각하는 만큼 믿어버리고 말할 테니, 조금은 산만하겠지만, 한번에 하나씩 유콘이라는 산을 정복해보자.
서비스 브로커(Service Broker)
고맙게도, 필자가 속한 세미나에서 서비스 브로커에 대해서 설명할 기회가 있어서, 다른 유콘 구성 요소에 비해서 서비스 브로커는 조금 익숙하다. 따라서, 그때 말했던 그대로 서비스 브로커에 대해서 설명해보고자 한다.
필자가 보았던 자료에서 서비스 브로커의 장점으로 다음과 같은 네 가지가 있었다. 원래 영어였으니, 그대로 적는다. 출처는 잘 기억나지 않으나, MSDN에서 보았던 자료인 듯하다.
Distributed Server-Side Processing for Client Applications
Data Consolidation for Client Applications
Large-Scale Batch Processing
Asynchronous Triggers
클라이언트 애플리케이션을 위한 분산된 서버 사이드 처리 능력, 클라이언트 애플리케이션들을 위한 데이터 통합, 대규모 배치 프로세서 처리, 비동기 트리거들 이라고 해석이 된다. 솔직히, 한국말로 해석해놓아도 무엇을 하는 놈인지 모르겠다.
부끄럽지만, 처음에 서비스 브로커라는 이름을 들었을 때에, 오라클의 리스너(Listener)와 유사한 것인줄 알았다. 서비스를 브로커 해주니, 아둔한 필자이 머리로는 "오호라. SQL 서버 연결을 브로커하는 서비스이구나"라고 밖에는 생각이 안되었다. "SQL Message Queue Transaction"이라든지, "SQL Queue Management System", "Asynchronous Transaction Queue" 정도의 용어를 쓰면, 얼마나 깔끔할까? 때늦은 필자의 불평이다.
요즘은 웹 서비스(Web Service)가 대세이다. 웹 서비스는 HTTP라는 환경을 통해서 메시지를 교환하여 처리하는 구조를 가진다. 웹 서비스 자체가 80 포트만 열려 있으면, 자유로이 네트워크를 드나들 수 있고, 대부분의 네트워크들에서 80 포트는 열려있다. 데이터 자체는 XML로 자유로운 형식을 가지면서도, 융통성 있게 응용 될 수 있다. 백엔드 시스템이 유닉스이든지 윈도 환경이든지 상관하지 않는다. 왜냐, 웹이니깐 말이다. 세상이 참 좋아졌다. 어떤 URL 하나만 호출하면 정보들이 처리되는 구조를 가지게 되었으니 말이다.
다음 그림은 SOA(Service Oreiented Architecture)를 나타낸 것이다. 그림이 매우 심플하니 이해해 주시기 바란다. SOA라는 말은 서비스 지향적인 구조라고 볼 수 있다. 어떤 서비스이냐? 바로 위에서 이야기한 웹 서비스이다. 웹 서비스를 이용하는 구조가 될 때, 세상은 자유로와 진다. 또한, 웹 서비스라는 것 자체가 단순하면서도 강력하다. 어떤 소켓 서버보다도 동시 처리 능력이 강하며, 동일한 서버들을 증설함으로써도 확장하는 능력도 강력하다.
SOA에서 서비스와 서비스 끼리는 메시지를 교환한다. 그것은 어떠한 시스템에서도 마찬가지 일 것이다. 다만, SOA 아키텍처에서는 그 메시지가 주로 XML이라는 것이 특징일 것이다. 서비스 A가 이러한 메시지를 서비스 B로 보낸다. 이것은 하나의 트랜잭션이다.
<그림 3> SOA(Service Oriented Architecture)
기존의 SQL 서버 클라이언트 서버 환경도 마찬가지로 패킷이라는 메시지를 주고 받는다. 다른 점은 SOA에서는 이러한 묶음 자체가 느슨하게 연결(Loosely coupled communication) 된다. 가끔씩, SOA의 어떤 말들은 상당히 모호한 의미를 가지고 있다. 대표적인것이 Loosely Coupled Communication이라는 말인데, 반대되는 의미는 Closely Coupled Communication이다. 느슨하게 연결되어 있다는 것은 유연하다는 의미인 것 같다. 유연하게 짝지어졌다는 것은 서비스들 간에 네트워크 연결이나 응답 상태가 불안정할 수 있고, 그럼에도 정상적으로 커뮤니케이션이 이루어지도록 하는 구조이다. 즉, 불안정한 웹의 단점들을 장점으로 승화시킨다고 볼 수 있다.
반대의 의미를 보면 더욱 쉽게 이해할 수 있다. Closely Coupled Communication이라는 환경은 커플이 된 한쪽 서비스에 문제가 있다면, 곧바로 서비스 불능이 되는 구조이다. 둘 사이에 주고 받는 메시지(보통은 소켓 전문 형식)의 변경이 있다면, 보내는 서비스나 메시지를 받는 서비스 모두 변경해야만 한다. 특히, 변경 사항들을 적용하기 위해서 컴파일되는 경우들이 대부분이다. 즉, 한 서비스의 변경 사항이 다른 서비스의 변경 사항을 요구한다는 의미에서 이것은 매우 Closely하다.
SOA구조에서 메시지 구조가 변경되더라도, 모든 서비스의 코드를 재 컴파일 할 필요가 없다. 메시지의 구조가 추가되더라도 기존 메시지는 그대로 처리 될 수 있다. 필요한 해당 서비스만을 조정하면 된다. 서비스가 커넥티드 되지 않아도, 에러가 나지 않는다. 다만, 메시지는 서비스가 정상화된 이후에 처리될 수 있다. 이러한 SOA 구조를 지원하기 위해서 서비스 브로커라는 것이 나온 것 같다. 역시, 필자의 사견이다.
서비스 브로커의 구조
SQL Management Studio에서 Object Exlorer를 클릭해서 보면, 각 데이터베이스 카탈로그마다 "Service Broker"라는 카테고리가 존재한다. 새로운 카탈로그를 만들때마다, 서비스 브로커 카테고리가 생성된다. 이제는 기본 항목으로 제공되는 것이다.
<그림 4> 서비스 브로커
그림에서 보는 것처럼 서비스 브로커는 Message Type, Contract, Queue, Service, Route와 같은 항목들로 이루어져 있다. 아직, 각각이 무엇을 하는 것인지는 모른다. 거기에 대한 설명은 좀 이후에 할 것이다. 여기서는 간단히 외형만을 살펴보자. 그림 5에서는 메시지 타입(Message Type) 항목을 클릭해 보았다. XML URI들이 나타난다. 처음 보았을 때는 황당함 자체이겠지만, 서비스 브로커는 이러한 XML URI 구조로 항목들이 생성된다. 그러니깐, 개별 항목들이 이 서비스 브로커에서 사용되는 메시지 타입들인 것이다.
<그림 5> 서비스 브로커의 항목들
살펴보면 알겠지만, 유콘의 새로운 요소들은 대부분이 XML을 기반으로한 구조로 되었있다. 서비스 부로커또한 마찬가지이다. 모든 네이밍 및 데이터 구조가 XML을 기반으로 하고 있다. 하지만, 보는 만큼 사용하기는 쉽다.
댓글 영역