Life is Simple, Thinking is High

열렬한 팬사이트 중의 하나였던 엔코아에서 작년에 SQL Quiz 게시판을 없애버렸다. 참여율이 저조해서인지 아니면 다른 이유가 있는지는 모르겠지만 개인적으로는 아쉽기 그지 없었다. 그래서 개인적으로 재미삼아 퀴즈문제를 만들어 보기로 했다 -ㅅ-  사실 이 블로그 자체가 남에게 보여주기 위함보다 그냥 개인적인 목적으로 만든 블로그지만 - 그동안 하도 글들을 날려먹어서 -ㅅ- 머 어쩌랴 싶기도 하다. 퀴즈는 아마도 이 블로그에서 유일하게 타인만을 위한(정말?) 글이 될 예정...

웬일인지 개인적으로 면접을 본 횟수보다 면접을 한 횟수가 10배정도 많은데 그 때마나 DB파트에서는 꼭 SQL 문제를 내곤 했다. 단순한 암기적 지식이 필요한 질문은 면접 질문중 최악이지만 SQL은 암기적 지식이 필요 없고 평소 RDMS를 제대로 관계형 패러다임으로 인식하고 있는지 알아볼 수 있기 때문이다. 문제별 난이도는 주관적이고 상대적이다.

1. 해당년원을 인풋으로 받아서 SQL을 사용하여 달력을 출력하기 (난이도 D)


ex)
입력 : 200801

출력 :

일 월 화 수 목  금  토
         1   2  3    4   5
6   7   8  9  10  11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31




1-1 입력은 같지만 이전달과 이후달의 날짜도 같이 출력하기. (난이도 C)


입력 : 200801

출력 :

일 월 화 수 목  금  토
30  31 1  2  3    4   5
6   7   8  9  10  11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  1  2

DB 아키텍처에 대해 깊히 이해하지 못하는 객체지향 개발자가 흔히 하는 실수중의 하나는 DB에 대한 블랙박스 증후군이다.

이들은 마치 데이타베이스를 라디오의 건전지처럼 교체할 수 있어야 한다고 생각하고 데이타베이스의 특정 기능을 사용하는 것을 마치 나쁜짓인양 무슨 수를 써서라도 피하려고 한다. 그래도 데이타베이스 독립이라는 명록으로 데이타베이스의 기능을 사용하고 데이타베이스 활용을 거부한다. (데이타베이스 종속이란 말 자체가 사실 우물에 독뿌리기 오류를 범하고 있다. 종속이란 그리 듣기 좋은 단어가 아니기 때문이다.) 사실 데이터베이스의 독립을 이루기란 극히 어려울뿐 아니라 반대의 경우보다 훨씬 더 많은 비용이 든다.

이 문제는 크게 경제성과 비경제성 문제로 나눌수 있는데

첫번째로 블랙박스 증후군에 걸린 개발자는 수학이 아니라 공학이 가져야 하는 경제성 즉 비싼 데이타베이스 비용을 낭비하거나 이미 존재하는 기능임에도 직접 작정하는 수고를 통해 많은 시간을 낭비하게 된다.

두번째로 앞에서도 말한바와 같이 실질적으로 매우 어렵다. Ansi SQL만을 사용해서 어떤 제품을 만든다는 것은 Hello World 프로그램 따위에서나 생각할 수 있다. DB 벤더마다 Length, substring 같은 기본 함수들의 사용법이나 명칭등이 다르기 때문에 고작 쓸 수 있는 SQL이란 select * from emp 같은 정도를 사용할 수 있을 뿐이다.

세번째로 어려울뿐 아니라 어떤 문제는 사실 불가능한 것들도 있다. 예컨데 트랜잭션 모델의 경우 Oracle과 MSSQL은 많은 차이가 있고 이는 설사 같은 SQL을 사용했다고 하더라도 다른 결과를 일으키는 경우가 있다.

이러한 등등의 문제로 10년이 넘는 개발자의 생활중 사실 단 한번도 DB 독립을 갖춘 제품을 보지 못했다는 경험적인 이유도 있다. 그 많은 제품들은 물론 데이타베이스의 종속을 피하고자~ 라는 말이 대부분 있었음에도 불구하고 말이다. 실질적으로 제품정도의 코드에서 데이타베이스의 종속을 제거한 코드를 만드는것은 이론적으로 불가능은 아닐지라도 매우매우 어렵다.

그래서 객체지향과 DB는 서로간에 한발 양보를 하고 타협을 하게 되는데.
하나는 객체지향쪽에서 DB쪽으로 한발 접근한 DB를 객체형식으로 다루는 등의 하이버네이트식의 접근이고
다른 하나는 DB쪽에서 아예 객체기반 DB를 만드려는 시도이다.

여기서 두번째는 이 글의 주제와 맞지 않고 사실 논리적으로도 문제가 있다. DB의 종속을 피하기 위해 객체지향 DB를 사용하라는것 자체가 모순이다.(그리고 사실 객체기반 DB는 단순히 종속성의 문제때문에 개발된게 아니다. )


첫번째 하이버네이트식의 접근은 그 열렬한 추종자가 많이 줄긴 했지만 지금도 충분히 지나치게 과대평가라고 생각한다. 몇년전 하이버네이트 소스를 며칠동안 뜯어본적이 있었는데 그 대부분이 케이스별 SQL을 만드는 string 연산이였다. 지금은 나아졌는지 모르겠지만 어쨌거나 이방식은 겉보기에는 종속을 피할 수 있을지라도 DB의 효율성을 심각하게 감소시킨다. 무료(?)인 오픈소스 디비를 사용하면 비용이 안든다고 주장하지만 그 만큼의 저 효율을 어딘가에서 메꿔야 하기 때문에 그닥 납득하지는 못하겠다.

IBatis의 방법은 조금 더 현실적이긴 하지만 이도 역시 다른 문제가 있다. 이건 머 차차 쓰기로 하고 잠이나 -ㅅ-;;;;

이전 글에서 객체지향 프로그래밍 십계에 대해 언급한 적이 있는데
(물론 모세처럼 신약을 받은건 아니고-ㅅ- 그렇다고 새로운 이론을 창조하는 것도 아니다. 굳이 말하자면 요구사항을 캐내듯이 - 수집이 아니라 - 별다섯개짜리 책들에서 캐낸 것이다.)

1계는 당연히 재사용 성배를 뜻한 DRY(Dont Repeat, yourself)이다.
3계는 앞서 말한대로 더 이상 분해가 불가능한 원자단위까지 쪼개서 하나의 Aspect관점으로 묶어라 이다.

마음대로 정한 2계는 SOC 즉 변화의 속도이다. (SOC는 Service-Orinted Programming같은게 아니라 Speed Of Change로 맘대로 지어낸 용어다 -ㅅ-) 객제 지향은 "Object는 관련 있는 변수와 메소드의 모음" 이라는 정의로 출발하는 관계 있는것끼리 묶자라는 시도이다.

좋아~ 그럼 관련 있는 것이란 무엇인가 ?

관계(혹은 관련)에 대한 화두는 이화식씨에게 RDBMS를 배우던 시절로 올라간다. 관계형 DB 모델링 과정에서 엔티티란 '... 어쩌고 저쩌고....  관계 있는 개체의 집합' 라고 정의했을때

"관계란 무엇인가? 저기 창문밑의 길가는 사람은 나와 관계 있는 건가? 아닌가?" 라는 질문을 던졌을때 당시의 나는 매우 당황스러웠지만 그 후 몇 년이 지난후에야 나름대로의 답을 찾게되었다.  RDBMS에서 모든 개체는 관련을 가지고 있다. 따라서 창문밑의 길가는 사람과 나는 관계가 있는 것이다. 다만 RDBMS에서는 직접적 관계와 간접적 관계를 구분한다. 그래서 모델링시 사원과 부서가 일차적 직접 관계를 가지느냐 이차적 이상의 간접적 관계를 가지느냐에 대한 판단을 하게 된다.

이러한 RDBMS에서의 관계의 의미와는 달리 객체지향에서 관계의 의미는 조금 다르다. 설계시 A라는 클래스와 B라는 클래스는 관계가 있느냐? 혹은 a라는 메소드와 b라는 메소드는 관계가 있느냐를 판단할때의 기준은 공간적 시간적 변화의 속도이다. 즉 어떤 클래스를 수정할때 다른 클래스도 마찬가지로 수정해야 된다면 이 두개의 클래스는 관련이 있으므로 묶어두어야 한다. - 클래스 통합이 될수도 있고 같은 패키지에 둘수도 있고 inner 클래스를 사용할수도 있겠다. - 이러한 공간적 관련성 말고도 시간적으로 어떤 부분의 변동과 다른 부분의 변동이 같이 일어난다면 이도 시간적 관계가 있다고 할 수 있다.

쉽게 말하면 객체지향의 디자인은 관련있는 것들은 그 관련정도에 따라 거리를 조절하는 것을 뜻한다. SOC가 아주 비슷하다면 그 거리도 가까워야 하고 SOC가 서로 관련이 없다면 가능한 서로 의존하지 말아야 한다. 달리 말하면 소프트웨어 공학에서 말하는 커플링(Loose cupling)과 코헨션(Tight cohesion)에 대한 얘기이다. 언뜻보면 모순으로 보이는 이 두 개념은 SOC에 따라 커플링이나 코현션이냐를 판단하게 되는 것이다.



객체지향 프로그래밍 제 2계
관련있는 것은 가능한 묶고 관련없는 것들은 가능한 떨어뜨려 놓는데 여기서의 관련이란 이 두개의 시간적 공간적 변화의 속도이다.