어제 clojure 관련 글을 읽다가 의문이 생겨 글을 남긴다. 한편으로는 역사는 돌고 돈다는 것을 다시 한번 느끼는 계기가 되기도 했다. 내가 어제 읽은 글은 간략히 요약하면 다음과 같다.

객체 지향 언어를 기반으로 하는 웹 프레임워크를 활용해 개발했다면 아마도 먼저 object model을 생성한 후에 이 model을 데이터베이스 테이블로 매핑하는 방식으로 개발을 진행했을 것이다. 하지만 clojure는 로직이 데이터를 분리해 개발하기 때문에 data model만 설계하고, data model부터 개발을 시작한다. (물론 우리나라는 객체 지향 언어를 사용하고 있지만 data model을 먼저 설계한 후 object는 data에 대한 매핑 도구로만 사용하는 경우가 일반적이다. 이럴 바에 object를 만들지 말고 map을 사용해도 충분할 듯하다.)

위 요약한 내용의 원본 글은 다음과 같다.

If you’ve worked with a web framework in an OO language you’re probably used to creating an object model and then mapping this model to the database either by writing SQL statements by hand or using an ORM frameworks such as Hibernate1 to do that for you.


In our application the database will be our data model. Because the logic is kept separate from the data in Clojure, there is no value in taking the maps returned from the database and copying them over to different data structures.

지금까지 나는 객체 지향 개념으로만 프로그래밍을 했기 때문에 데이터와 로직을 분리했을 때의 장,단점을 피부로 느끼지 못하고 있다. 분명 과거에 데이터와 로직을 분리해서 관리할 경우 많은 단점이 있었기 때문에 객체 지향 개념이 나오면서 데이터와 로직을 객체라는 개념을 두고 같은 곳에서 관리하려는 노력을 했을 것으로 생각한다. 그렇다면 데이터와 로직을 같이 관리했을 때의 단점이 나타나고 있는 것인가? 복잡도가 이슈인가?

최근에 functional programming이 부각되는 이유 중의 여러 가지가 있겠지만 복잡도를 낮추기 위한 일환도 포함되는 것으로 생각한다. 데이터와 로직의 분리 또한 복잡도를 낮출 수 있는 일환으로 볼 수 있는 것인가?

세상은 참 재미있다. 언제는 적합하지 않아서 새로운 개념이 등장했다가 다시금 과거로 돌아가는 것을 보면 말이다. 그런 관점에서 본다면 국내 소프트웨어 개발 환경은 강점을 가지고 있는 것인가? 지금까지 object model에 대한 설계는 경시하고 data model만 강조해 왔으니 그에 적합한 functional programming으로 빨리 넘어가면 되겠네. data model의 중요성을 강조해온 분들은 뭐하나 모르겠다. 이런 좋은 기회를 살리지 않고 말이야.