본문 바로가기

기타/객체지향 토막글

객체지향과 관계형 데이터베이스의 조화, 수필 객체지향

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

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

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

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

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

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

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

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

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

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

만약 나에게 다시 업무분석과 DB모델링을 해야 된다는 지시가 떨어진다면, 나는 일단 객체지향 모델링으로 업무분석을 하고 클래스와 엔티티끼리 동등하게 대입하는 객체관계 DB모델링을 할 것이다.

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

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

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


산골이 덧) 이글은 일단 칼럼 형식으로 가볍게 썼습니다. 객체지향 개발은 조금 더 알고, DB모델링 과 업무분석은 약한 저의 경험담을 바탕으로 객체지향과 관계형 데이터베이스를 비교해봤는데요. 만약 반대로 관계형 데이터베이스가 익숙하다면 반대로 관계형 식으로 모델링 하고 객체지향으로 맵핑하면 될것 같습니다. 오늘글은 제가 일할때 많이 부딪혔던 문제라 많은 고민했고 나름대로 답을 찾아본 내용 이었습니다. 역시 글쓰기의 재미는 글을 쓰면서 풀리지 않은 고민과 의문이 싹~ 풀리는 것이죠. ^ ^