객체지향의 탄생-객체지향과 관계형 데이터베이스

 

1. 객체지향과 관계형 데이터베이스의 조화

처음 봤는데도 왠지 끌리는 사람이 있고 물건이 있고 기술이 있다. 나는 처음 프로그래밍을 배울때부터 객체지향 관련 기술을 좋아했다. 아마도 철학같은 깊이가 느껴지는 기술이라 좋아했던 것 같다.

 

객체지향을 배우면 어떤 요구사항이라도 고스란히 내 프로그램으로 옮길수 있을 것 같았다. 그러나 공부와 실전은 달랐다. 나는 객체지향 기술 공부와 실전 개발을 병행하면서 종종 알기 힘든 괴리감을 느꼈다.

 

처음에는 단순한 웹코딩을 했기 때문에 객체지향을 써먹을 일이 없었다. 그때 프로그래머는 머리를 쓰는 지식 노동자가 아니고 단순 복사/붙여넣기 노동자 일수도 있구나라는 생각을 했다.

 

드디어 기회가 왔다. 회사 업무에 쓰일 프레임워크를 개발해 보라는 지시였다. 그때 그동안 배운 객체지향, 디자인패턴, 리팩토링 기술을 총 동원하여 장기간에 걸쳐 회사에 쓰일 프레임워크를 개발하였다. 프레임워크를 개발하면서 느낀점은 객체지향과 디자인패턴, 리팩토링등의 기술들이 어플리케이션 개발에는 대단히 유익하게 쓰인다는 것이다. 유지보수 편하고 확장성 높고 유연하다는 진부한 말이 조금은 이해가 되는 것 같았다. 나는 나름대로 짜임새 있게 구축되고 잘 돌아가는 프레임워크를 보면서, 객체지향 기술에 파고들기 잘했다며 안도의 한숨을 내쉬었다.

 

한편으론 프레임워크 개발 종종 업무적인 요구사항을 구현할 일이 몇번 생겼다. 예를 들어 고객사를 위한 관리자, 통계 사이트를 구현해야 하는 경우였다. 이 경우는 보통 웹으로 구현되며 서비스 로직은 프레임워크에서 제공하는 틀을 사용한다. 그리고 데이터베이스와 연결한다. 이런 프로젝트는 프레임워크를 직접 개발하지 않으면 객체지향 기술을 사용할 기회가 없다. 웹페이지 코딩 방법, 프레임워크 사용법, DB 모델링 및 SQL쿼리 작성등의 기술이 사용될 뿐이다. 이점이 나를 곤란하게 만들곤 했다.

 

문제는 업무 분석 단계에서 DB 모델링 작업을 할때 생기곤 했다. 나는 업무 분석과 업무 분석 결과를 DB로 모델링 할때 버벅거렸다. 그때 선배 개발자들은 이렇게 지적하곤 했다. "언제까지 개발만 할꺼야. 개발만 좋아하지 말고 업무 분석과 DB 모델링도 할줄 알아야지" 당시 나는 객체지향 어플리케이션 개발 분야에 매달리고 업무 분석과 DB 모델링을 소흘히 하기도 했다.

 

하지만 업무 분석을 하고, 업무 분석 결과를 DB 모델링으로 구현하고, 구축된 DB 스키마로부터 효과적인 쿼리를 던져 원하는 결과를 가져오는 방법은 쉽지 않았다. 내가 느낀 객체지향 공부와 실전과의 괴리감이 이것이다. 객체지향 기술로 업무 분석도 하고 업무 분석 결과를 데이터베이스 결과물로도 이어갈수는 없을까 고민하였다. 답은 잘 떠오르지 않았다.

 

당시 업무분석과 DB모델링에는 객체지향 기술 자체가 개입될 여지가 어려웠다는 사실에서 단서를 찾았다. 당시 업무분석은 DB모델링과 바로 연결되는 방식으로 분석과 문서화가 진행됐고, DB모델링은 전형적인 관계형 데이터베이스 구조 였다. 관계형 데이터베이스 관련 기술에 종속되어 업무분석을 진행해야 했다. 그리고 정규화/반정규화 모델링 방법, 50줄이 넘는 SQL문 작성, 옵티마이저를 사용한 SQL 최적화등 관계형 데이터베이스 관련 기술은 대단히 복잡하고 어려웠다.

 

만약 업무분석에 객체지향 모델링을 활용하고 데이터베이스도 객체지향 데이터베이스 였다면 나같은 경우 조금은 쉽게 진행했을지도 모를 일이다. '세상을 설계하는 객체지향'이란 이름에 걸맞게 다양한 UML등의 객체지향 모델링 기법을 사용하여 업무를 분석하고 객체지향 데이터베이스로도 구현이 가능했을 것도 같다.

 

그러나 현실은 관계형 데이터베이스가 탄탄히 자리를 잡고 있으므로 타협점을 찾아야 한다. 다행히 어플리케이션은 객체지향 기술이 인정을 받고 있으며 요즘에는 요구사항 분석, 설계 단계에서도 객체지향 모델링 기법이 사용된다.

 

만약 나에게 다시 업무분석과 DB모델링을 해야 된다는 지시가 떨어진다면, 나는 일단 객체지향 모델링으로 업무분석을 하고 다음의 표를 참고로 하여 DB모델링을 할 것이다.

 

객체관계맵핑표

구분	객체	관계
식별자	객체 고유 식별자	PK
객체와 객체간의 관계	상대방객체에대한 포인터를 갖음, 그러면 상대방 객체에 존재하는 메모리를 가리키고 있으므로 상대방 객체의 값이 변하여도 참조하고 있는 객체에서 관계 유지를 위해 값을 수정해야 하는 작업이 없어진다.	논리적인 관계, FK
데이터타입	자유롭다.	숫자,문자,날짜로 고정
구성항목	클래스 오브젝트 인스턴스 관계 메소드	엔티티타입 엔티티 속성 관계
상속의맵핑	상속	필터드맵핑,오직 하나의 테이블로 대응 수평적맵핑,구상 클래스를 하나의 테이블로 대응하고 상위클래스의 속성을 삽입 수직적맵핑,추상또는구상에 관계없이 하나의 테이블로 만들고 추상과 구상을 FK로 묶는다.
일대일관계		바로 대입
일대다관계		FK추가
다대다관계		맵핑테이블추가
모델링방법	데이터와 프로세스를 동시 모델링	데이터와 프로세스는 별개

 

이렇게 설계단계에서 객체관계맵핑으로 생성된 DB스키마는, 나중에 구현단계에서 SQL쿼리를 던져 원하는 데이터를 가져와야 한다. 그 단계에서는 이제 반대로 관계형 테이블을 객체 클래스로 맵핑하는 작업을 진행한다. 그때는 아마 하이버네이트나 아이바티스등의 전문 객체관계맵핑 프레임워크를 사용할 것이다.

 

보통 하나의 기술만 좋아하면 그 기술만 추종하는 경우가 있다. 나는 유독 객체지향 기술만 좋아했다. 그러나 객체지향이 만능은 아니다. 데이터베이스는 관계형 데이터베이스만의 튼튼한 장점이 있길래 계속 유지되는 것이다. 어플리케이션 개발에는 객체지향 기법이 효과적이기 때문에 각광받고 있는 것이다. 그리고 이 두 세계를 이어주는 객체관계맵핑 기술은 잘 마련되어 있다.

 

결국 객체지향과 관계형 데이터베이스는 공존/공생 할 것이며, 관계형 데이터베이스와 연결되는 정보 분석 방법도 있고, UML을 사용한 객체지향 모델링 방법도 있고, 구현 단계에서 이들을 이어주는 객체관계맵핑 기술도 마련되어 있기 때문에, 처음 업무분석을 객체지향 모델링으로 했다가 나중에 관계형 테이블로 변환해도 되고, 쿼리 작업때는 관계형 테이블에서 객체 클래스로 객체관계맵핑 하면 될 것이다.

 

1. 디자인패턴과 리팩토링

블로그처럼 네티즌을 위한 훌륭한 도구가 또 하나 있다. 트위터라는 도구이다. 블로그는 '자기 생각과 주장을, 자유롭게 글이나 사진으로 편집해서 올리고, 댓글, 트랙백, RSS, 태그등의 기법으로 쉽게 전파하는 도구' 이다. 트위터는 '블로그 처럼 자기 생각과 주장을, 짧은 글로 올리고, 친구(following, followers) 맺기, RT(친구의 글을 내가 전파함), 댓글등의 기법으로 쉽게 전파하는 도구'라고 정의한다.

 

블로그와 트위터의 정의로부터 이 둘의 공통점과 차이점을 찾아 보았다. 블로그는 편한대로 쓰기도 하지만 대부분은, 글을 쓰기전에 미리 이런식으로 글을 구성하겠다고 생각한다. 블로그는 글쓰기 전에 또는 글을 쓰면서 많은 노력을 요구한다. 트위터는 편한대로 쓴다. 편한대로 쓰면서 친구(follower)들과 교류하면 된다. 트위터는 글을 쓰면서 또는 글쓰기 후에 RT같은 간단한 작업들이 요구된다.

 

블로그는 대부분 어느정도 글의 덩치가 있기 때문에 해당 주제에 대하여 숲에서 나무를 보는 방식으로 작업을 진행한다. 그래서 블로그 글쓰기의 작업 범위는 크다. 트위터는 편하게 쓴 짧은 글로 상대방과 교류하고 다시 의견을 내면서 자신의 생각과 주장을 발전시킨다. 그래서 트위터의 작업 범위는 작다.

 

블로그는 글쓰기 전에 글을 어떻게 전개할지 생각이 요구되기 때문에, 글의 주제에 대해 명확히 이해하고, 대상 독자를 명확히 알아야 한다. 더구나 메타블로그 추천 상위권을 노리는 글이라면 글감 준비부터 쓰는 과정까지 상당한 시간이 필요하기도 하다.

 

트위터는 140자 이내로 편하게 쓰면 되기 때문에, 친구(=follower)들과 어떻게 교류할지 대략 생각만 하면 쉽게 사용할 수 있다. 심지어 '나 이제 자요~' 등의 단순한 일상을 올리더라도 친한 친구(=follower)라면 자신의 글에 반응해줄 것이다.

 

블로그가 자기 생각을 깊이있게 전달한다면, 트위터는 가볍게 그러나 지속적으로 자기 생각을 전달하는 특징이 있다. 블로그는 자신의 내적인 사고력으로 자신의 생각을 전파하는 경향이 있지만, 트위터는 친구(=follower)와의 지속적인 커뮤니케이션으로 자신의 생각을 전파한다. 블로그가 내향적이라면 트위터는 외향적이다.

 

블로그와 트위터는 노력이 필요한 단계도 틀리고, 글의 양도 틀리고, 글재주와 사진찍기 능력과 편집 능력의 난이도도 틀리다. 그러나 결국 자기 생각과 자기 자신을 블르고와 트위터란 도구들을 이용해 널리 알려서, 자신이 원하는 무엇인가를 이룬다는 것에 궁극적인 공통점을 가진다. 블로그와 트위터의 용도와 효과는 비슷하다.

 

 

여기 객체지향 선각자들의 고마운 선물이 또 하나 있다. 리팩토링이라 불리는 기법이다. 디자인패턴은 '특정한 객체지향 개발 영역에서 자주 발생되는 설계 및 구현 문제에 대하여, 유연하고 확장성 높은 객체지향적 설계 패턴으로 해결하는 방법들의 모음' 이라고 정의한적이 있다. 리팩토링은 '기능은 그대로인 상태에서 내부 소스를 유연하고 확장성 높은 객체지향 스러운 코드로 개선하는 작업'이다.

 

디자인패턴과 리팩토링의 정의로부터 이 둘의 공통점과 차이점을 찾아본다. 디자인패턴은 어플리케이션의 설계 단계에서 미리 이런식으로 객체를 구성해야겠다고 결정한다. 디자인패턴은 어플리케이션 개발 전에 투입된다. 리팩토링은 어플리케이션 개발 후 코드를 점검하면서 잘못된 코드가 발견되면 객체지향스러운(=유연하고 확장하기 쉽고 유지보수하기 편한) 코드로 개선한다. 주로 리팩토링은 어플리케이션의 특정 모듈 개발 후에 투입된다.

 

디자인패턴은 설계단계에서 사용되기 때문에 숲에서 나무를 보는 방식으로 작업을 진행한다. 그래서 디자인 패턴을 적용하는 작업의 범위는 크다. 리팩토링은 완성된 코드의 작은 모듈을 개선하는 작업부터 사용되기 때문에 나무에서 숲을 보는 방식으로 작업이 진행된다. 그래서 리팩토링을 적용하는 작업의 범위는 작다.

 

디자인패턴은 어플리케이션 설계단계에서 사용되기 때문에 어플리케이션의 요구사항을 명확히 이해하고, 시스템을 명확히 이해하며, 디자인패턴의 근본 기술인 객체지향 원리에 대해서도 깊게 알아야 한다. 더구나 숲에서 나무를 보는 관점에서 대규모의 작업이 이루어지기 때문에 디자인 패턴은 배우기도 쉽지 않고, 어느 정도 숙달되지 않으면 적용하기 쉽지 않다. 그러나 제대로 적용만 할 수 있다면 한번에 튼튼한 토대를 구출할 수 있다.

 

리팩토링은 작은 코드의 개선단계에서 사용되기 때문에 개선할 코드의 요구사항과 로직만 명확히 이해하며, 코드의 무엇을 개선할것인지 리팩토링 카탈로그만 알면 쉽게 구현할 수 있다. 심지어 객체지향의 근본적인 원리를 이해하지 못하더라도 리팩토링 카탈로그를 따라하면 저절로 잘못된 코드가 바람직한 객체지향 코드로 진화되기도 한다.

 

디자인패턴을 구현하기 위해 미리 깊이 있는 사고가 요구된다면, 리팩토링은 가볍게 그러나 지속적으로 코드 개선이 이루어지는 특징이 있다. 디자인 패턴이 설계자의 깊이있는 한번의 사고로 어플리케이션의 토대를 구축한다면, 리팩토링은 가볍고 활발하게 이미 구축된 토대를 개선한다. 디자인패턴이 정적이라면 리팩토링은 동적이다.

 

디자인패턴과 리팩토링은 쓰이는 단계도 틀리고, 쓰이는 범위도 틀리고, 배움과 적용의 난이도도 틀리다. 그러나 결국 객체지향적으로 어플리케이션을 개발하여 유연하고 확장성 높고 유지보수 편리한 어플리케이션으로 진화하는 목표를 가지고 있다는 것에 궁극적인 공통점을 가진다.

 

디자인패턴과 리팩토링의 적용 효과는 같다.

 

[아키텍트가 소프트웨어 개발 전 단계에서 디자인패턴으로 소프트웨어를 설계한다. 소프트웨어가 완성되었다. 아키텍트나 개발자가 완성된 소프트웨어를 리팩토링한다. ]

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다. 매주 월요일 발행 예정입니다.