'한국인'을 위한 DDD와 '모던' 객체지향설계 소개

도전적인 제목이다. 예전에는 무려 어떤 컨퍼런스 자리에서 설계 담론을 정리해보겠다고 선언만 하고, 용두사미로 내용없는 발표를 한 일도 있었다. 흑역사다. 그럼에도 불구하고 또 무모한 도전을 해볼 생각이다. 난 직업 작가가 아니라 글 내용으로 욕을 좀 먹어도 괜찮다. 다만, 내가 직업으로 하는 일에서 축적한 내용이 매우 빈약하다는 사실이 무모한 도전을 하게 만든다고 해두자.
대충 그정도로 '구상' 따위를 왜 발표하는지 명확히 한다.  그렇지만, 실제로 이 글을 타이핑 하고 있는 직접적인 동기는 따로 있다. 아침에 페이스북에서 만난 질문과 답변하는 과정에서 내가 느낀 찜찜함1)에서 비롯되었다. 아래 그림에서 '글쎄요. ㅠㅠ'으로 표현한 부분이 그것이다.
presentation
이 글을 쓰는 직접적인 동기가 된 한 페이스북 친구의 질문

글쎄요. ㅠㅠ 이 뭐길래?

질문을 보자마자 머리 속에서 순식간에 질문이 튀어나왔다.
  • DDD와 같은 책의 입문이란 무엇일까?
  • 10년이 훨씬 넘은 옛날 미국 책들을 읽으라 권할 수 있을까?
  • 대안이 되는 우리나라 책이 없지 않나?
  • 나는 개념서를 열심히 읽었지만, 과연 그 책들이 다른 사람에게도 효과가 있을까?
  • ...
이런 잡스런 생각을 '난감하긴'으로 요약해서 답하면서, DDD에 대해 가장 구체적인 지식을 전달하는 책을 추천했다. 그렇게 말하고 나서 찜찜함이 나를 찾아왔다. 그 찜찜함을 털어내는 것이 가능한 일인지 그냥 잊고 평생 찜찜하게 살아야 하는지 모르겠지만, 일단 서두에 말한대로 모무한 시도를 한다.

이제 '모던'하게 객체를 바라보자

한글 파괴논란을 무릅쓰고 모던 객체를 말한다. 모던 객체란 뭔가? 구닥다리 말고 새로운 것을 강조하려고 쓴 말인데... 명확한 선긋기가 없으면 그저 미사여구에 지나지 않는다. 그래서 선을 그어보겠다. 감히 말이지... ㅋㅋ
방금 몇 줄 쓰다가 다 지웠다. 이건 늪이란 생각이 들었다. 일단 객체부터 설명해야 한단 말인가? 이쯤에서 잠시 책 소개를 하겠다. 필자가 좋아하는 지인이 쓴 객체지향의 사실과 오해라는 책이 있다. 하필 그 책을 서울 집에 두고 와서 인용을 못한다. 그래서, 여기서는 엄밀함이나 과거 지식체계를 활용하는 대신 과감하게 내 생각 그대로 써보자.
객체 독립적인 단위로 유지할만한 프로그램 덩어리이며, 객체지향이라 함은 객체의 상호작용으로 시스템을 인식/정의/설계/구현하려는 사고나 태도를 지칭한다.
학자가 아니기 때문에 용어 사용의 엄밀성은 떨어질 것이다. 하지만, 서양의 지식을 그대로 받아 학습한 이후에 현장에서 20년 가까이 활용하여 소화한 내용을 날 것 그대로 내놓는 일이 더 가치있닥 봤다. 혹여 피드백(혹은 태클)이 있다면 이를 통해 보완할 수 있는 행운이 있기를 기대하며 정의는 이 정도로 마친다.
이제 '모던'이란 말을 붙인 이유를 설명하자. 첫 번째로 이 글에서 혹은 앞으로 내가 설명할 객체는 객체 지향 프로그래밍에서 다루는 객체가 아니다. 내 친구(?) 위키피디아를 살펴보자.
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data, in the form of fields(often known as attributes), and code, in the form of procedures (often known as methods).
위 내용에 부합하는 객체는 아니라는 말이다. 프로그래밍 언어와 1:1로 연결할 생각은 전혀 없고, 어떤 프로그래밍 언어를 써야 한다고 생각하거나 배경에 두는 바는 없다.
두 번째는 마이크로 서비스 아키텍처 혹은 꼭 그렇게 특정하지 않더라도 인터넷 기반으로 구동하는 분산 서비스를 설계를 다루는 맥락으로 한다. 객체지향이 가장 효용성을 낼 수 있는 부분이라 그렇기도 하고, 필자의 직업 일상 대부분이 그쪽 영역에서 이뤄지기 때문이기도 하다. 따라서, 그 밖의 영역에서 여기 풀어내는 내용을 응용할 수 있을지는 미지수다.

그런데 왜 하필 '모던'이냐?

그 두 가지 이유를 표현하는데, 모던이란 어휘가 적절할까2)? 표현이 적절하냐 여부를 떠나 '모던'이라는 말에 담아두려는 내용은 앞서 말한 두 가지이다.
  • OOP에 갇혀 있지 않기
  • 분산 서비스 맥락(배경)에서 설계 문제 다루기
OOP에 갇혀 있지 않기를 착안한 계기는 15개월 전쯤이 아닐까 추측한다. 그 즈음에 Go가 객체지향이냐 아니냐를 어설프게나마 다뤄보고 쓴 글이 남아 있다. 그런데 부질없는 일이었다. 객체지향이냐 아니냐의 흑백논리 혹은 이분법으로 Go를 취급하는 일은 전혀 쓸모 없어 보였다. Java가 기조로 삼는 클래스에 입각한 객체 생성과 여기에서 자유로워지기 위해 인터페이스를 활용하는 경험에서 나온 생각은 자꾸만 Go 언어에 어울리지 않는 왜곡을 하게 만들었다.
시간이 한참 흐른 지금에 와서 한발 떨어져서 바라보면 현장에서 Go의 장점은 REST 형태를 띄는 웹 개발에 있어 Java 에 비해 코드가 간결하고 메모리 사용이 적다는 점이다. 반면에 RDBMS 접속에 있어서 Java가 오래전에 갖췄던 도구는 손쉽게 얻을 수 없었다. 문법적으로도 코드량 자체를 줄일 수 있겠으나 변수 참조를 표현할 때 오해의 소지가 있어 실수를 한다는 동료들이 다수 있었다. 이런 이야기를 다루면 실용적인 논의를 할 수 있다. 그 과정에서 언어를 두고 객체지향이냐 아니냐 따지는 일은 Java가 태동하던 시기에나 어울리는 고리타분한 일이라고 주장하며 모던이란 말을 쓴다.
마찬가지 이치로 '객체지향 언어 시대가 가고 함수형 언어 시대가 왔다'는 식의 홍보성 문구를 한때 여기저기서 본 일이 있다. 앞서 정의한 모던 객체 입장에서 보면 함수형 프로그램은 객체를 구현하는 하나의 방법3)일 뿐이다.
두 번째 모던이란 수식어를 채택한 계기는 마이크로 서비스가 널리 쓰이는 상황을 반영한 결정이다. 마이크로 서비스 혹은 분산 프로그램의 단위로 객체라는 통일성 있는 개념을 활용하는 일은 과거보다는 최근에 더욱 필요한 일이다. 네트워크 상에서 접속하는 API를 묶는 단위로 객체를 쓸 수도 있고, 마이크로 서비스 하나를 객체로 볼 수도 있다. 이런 식의 사고와 응용은 90년대 혹은 2000년 초기 객체지향이 쓰이던 맥락과는 다르게 적용해야 하므로 모던 객체를 말한다.

'한국인'은 왜 나오는가?

한글이니 당연한데 굳이 '한국인'이라 쓴 이유도 있다. 나는 에릭 에반스의 DDD 책을 너무나 좋아한다. 아니 경외한다는 표현이 더 어울린다. 하지만, 그걸 제대로 써먹지는 못했다. 그리고, 지금에 와서 당시의 책을 고지식하게 따라할 생각은 추호도 없다. 그래서, 다른 분들께도 10년이 넘은 그 책을 그대로 따라가지는 말라고 권하고 싶다.
여기서 난감한 상황이 만들어진다. 그러면 대안은 뭐냐? 앞선 페이스북 댓글처럼 버논의 책 정도를 들 수 있는데, 막상 그 책을 읽어보면 틈만 나면 에반스의 책을 인용하는데?
그래서 언젠가 마음에 품었던 생각을 미적미적 행동으로 끌어낸다. 우리나라 환경에서 개발을 배운 사람들에게 적어도 서양에서 자라고 서양의 글로 쓴 책보다는 익숙하게 설명해보는 시도를 해보자는 것이다. 할 수 있다는 확신은 없으니까 일단 해보자고 썼다. (안되면 말고)

맺음말

제목 그대로 일단 소개만 한다. 그래도 (모던) 객체 개념을 설명했다. 근거도 대강 달았다. 다만, 이어지는 시리즈에서 무슨 내용을 다룰 것인가 정한 바가 없다. 연재를 계속 이어갈지 계획조차 없는 시도다. 쓰고 싶은 마음이 동하면 다음 진도를 나가고, 그게 아니라면 누군가 뜻밖의 독촉이 있을 때 그에 호응하여 앞으로 나가지 않을까 싶다.
presentation
소통은 언제나 환영하니 메일 주세요

주석

[1] 정확히 어느 글에 달린 댓글인지 찾기가 어렵지만, 페이스북의 다른 글에서도 DDD에 대해 한 페친이 설명을 해보라며 부추기는 글이 있었다는 점이 기억 저편에 깔려 있기도 하다.
[2] 잘 모르겠다. 그냥 다른 부분이 존재한다. 그것을 형상화 하여 적절하게 의미를 좁힐 수 있는 날이 오면 좋겠다. 그날까지는 그냥 '모던'이라 붙여둔다.
[3] DDD에서 말하는 서비스 빌딩블록과 유사하게 보는 수준으로 일단 넘어가자. 물론, 함수형 프로그래밍 언어에 대해 평가절하하는 것으로 오해하지 않길 바란다. 다른 패러다임의 프로그램 구성 방식을 우아하게 수용하기 위해 언어를 어떻게 활용하느냐는 지금은 고민의 범주 자체가 아니다.