<div id="readability-page-1" class="page"><div>최근에 <a href="http://www.yes24.com/Product/Goods/101818336">파이썬으로 살펴보는 아키텍처 패턴</a>이라는 책을 보고 있습니다. 
여러가지 좋은 이야기가 나오는데, 그 중에서 BIG BALL OF MUD(BBOM - 큰 진흙공) 방식에 대한 이야기가 나옵니다. 
간단하게 말하면 큰 진흙공 방식은 아키텍처가 없는 소프트웨어 시스템을 뜻합니다. 
즉, 되는대로 만들어지고, 요구사항에 따라 즉흥적인 코드를 만들고, 설계가 없다는 뜻이죠.
말만 들으면 BBOM은 우리 모두가 지양해야 할 안티 패턴처럼 보입니다. 그리고 많은 글들에서도 동일하게 나쁘니까 따라하지 말자는 논조를 가지고 이야기하죠.
하지만, 어떤 시스템이 완벽한 설계를 기반으로 이루어질 수 있을까요?
우리 모두 알아야 할 건, 완벽한 설계 따위는 없다는 겁니다. 
크고 단단하고 아름다우며 고결한 프로그램을 작성하겠다는 개발자들의 의욕은 높이 사지만 2021년의 개발은 1990년대 데스크탑 프로그램처럼 디스켓이나 CD-ROM에 담아서 출시하고 나면 2년동안은 업데이트가 불가능한 프로그램을 만드는 것이 아닙니다. 
우리는 매일 크고 작은 기능을 수정하고 릴리즈합니다. 굳이 웹 프로그램 뿐만 아니라 데스크탑 프로그램도 마찬가지입니다.
다 만들어진 시스템을 가지고 완벽한 설계를 아쉬워하는 건 쉽습니다. 하지만 만드는 과정에서 완벽한 설계를 한다는 건 불가능에 가깝다고 생각합니다.
<hr>
만약에 "모든 설계가 완벽해지는" 순간이 만약 온다고 하면 일부 "설계자"와 "코더"가 분리될 겁니다.
<a href="http://www.yes24.com/Product/Goods/96264038">생계형 개발자, SI에서 살아남기</a> 에서 저자는 이렇게 말합니다.
<blockquote>
멋진 설계는 AA가 합니다. 
업무 협의는 PM이 합니다. 
일반 개발자는 PM이 협의하고 AA가 설계한 시스템을 그대로 만들어냅니다. 
이런 의미에서의 개발자는 기능공에 가깝습니다.
</blockquote>
설계자는 AA일테고, 기능공은 개발자(코더)가 되는거죠. 
AA에게 불행한 점은 절대로 이런 순간은 오지 않는다는 것이고, AA에게 행복한 점은 이런 순간이 절대 오지 않으므로 본인의 업무를 개발자들에게 미룰 수 있다는 점이 될테죠.
<hr>
DDD(Domain Driven Design - 도메인 주도 설계)를 한번 살펴봅시다. 
도메인 주도 설계에서는 업무 도메인을 나누고, 나눈 도메인을 <code>aggregate</code>로 묶고, 도메인 혹은 애그리거트 단위로 개발을 하는 것을 중요하게 여깁니다.
"업무 도메인"은 "현장의 업무"를 반영해야 하고, 적어도 작은 단위의 개발, 즉 "도메인"은 현업과 완벽하게 일치하는 것을 최대한 지향한다는 거죠.
큰 단위의 완벽한 시스템을 만들 수는 없으니 작은 단위의 시스템이라도 완벽하게 만들고 서로 끼워넣자..라는 것이 DDD의 핵심입니다.
그런데.. 작은 단위의 시스템이라고 해서 완벽 같은 게 가능할까요? 
물론 비행기를 만드는 일보다는 종이컵을 만들어내는 일이 더 쉬울수는 있습니다만, 그렇다고 종이컵을 만드는 과정이 더 완벽하리라는 보장이 어디 있을까요?
오해하지 마세요. 저는 DDD가 나쁘다고 말하는 것이 아닙니다. 
DDD는 굉장히 현명한 접근이고, 최근에 MSA의 추세와 맞물려서 엄청나게 각광받고 있습니다. 작은 도메인들을 작은 서비스로 만들고 서비스들끼리의 연결을 통해 큰 서비스를 만들어나간다는 거죠.
한가지 단점은, 사실 단일 개발은 그다지 어려울 게 없다는 점입니다. 시스템을 만들 때 어려운 점은 대부분 두가지 이상의 복합 개념이 섞이는 시점에 등장하는데, 아직 여기에 대한 명쾌한 해법은 없네요.
<hr>
그래서 저는 처음부터 DDD에 따라 업무 도메인을 나누지 말고, BBOM에 따라 일단 동작을 구현한 다음, 업무 도메인을 분리하는 리팩토링을 하는 것이 더 좋다고 생각합니다. 
일단 동작이 구현된 상태에서는 업무 도메인이 더 명확하게 보이고, 프로덕트의 출시일이 밀릴 이유도 없으며 사용자의 반응에 따라 쓸모없는 업무 도메인이 도출될 가능성이 높기 때문이죠.
물론 <del>현실은 시궁창이기 때문에</del> BBOM으로 일단 만들어놓고 나면 더이상 도메인을 분리할 여유가 없는 경우가 다반사이기는 합니다만.. 이부분은 각 회사의 분위기나 상황에 따라 다르기 때문에 열심히 경영진을 설득하라고밖에 말씀을 못드리겠네요.
<del>성장하는 개발자가 되고 싶다면 리팩토링은 꿈도 꾸지 말라는 회사는 가능한 빨리 도망치세요.</del></div></div>

고은연

최근에 파이썬으로 살펴보는 아키텍처 패턴이라는 책을 보고 있습니다.
여러가지 좋은 이야기가 나오는데, 그 중에서 BIG BALL OF MUD(BBOM *- *큰 진흙공) 방식에 대한 이야기가 나옵니다.
간단하게 말하면 큰 진흙공 방식은 아키텍처가 없는 소프트웨어 시스템을 뜻합니다.
즉, 되는대로 만들어지고, 요구사항에 따라 즉흥적인 코드를 만들고, 설계가 없다는 뜻이죠.
말만 들으면 BBOM은 우리 모두가 지양해야 할 안티 패턴처럼 보입니다. 그리고 많은 글들에서도 동일하게 나쁘니까 따라하지 말자는 논조를 가지고 이야기하죠.
하지만, 어떤 시스템이 완벽한 설계를 기반으로 이루어질 수 있을까요?
우리 모두 알아야 할 건, 완벽한 설계 따위는 없다는 겁니다. 
크고 단단하고 아름다우며 고결한 프로그램을 작성하겠다는 개발자들의 의욕은 높이 사지만 2021년의 개발은 1990년대 데스크탑 프로그램처럼 디스켓이나 CD-ROM에 담아서 출시하고 나면 2년동안은 업데이트가 불가능한 프로그램을 만드는 것이 아닙니다.
우리는 매일 크고 작은 기능을 수정하고 릴리즈합니다. 굳이 웹 프로그램 뿐만 아니라 데스크탑 프로그램도 마찬가지입니다.
다 만들어진 시스템을 가지고 완벽한 설계를 아쉬워하는 건 쉽습니다. 하지만 만드는 과정에서 완벽한 설계를 한다는 건 불가능에 가깝다고 생각합니다.
만약에 "모든 설계가 완벽해지는" 순간이 만약 온다고 하면 일부 "설계자"와 "코더"가 분리될 겁니다.
생계형 개발자, SI에서 살아남기 에서 저자는 이렇게 말합니다.
멋진 설계는 AA가 합니다.
업무 협의는 PM이 합니다.
일반 개발자는 PM이 협의하고 AA가 설계한 시스템을 그대로 만들어냅니다.
이런 의미에서의 개발자는 기능공에 가깝습니다.
설계자는 AA일테고, 기능공은 개발자(코더)가 되는거죠.
AA에게 불행한 점은 절대로 이런 순간은 오지 않는다는 것이고, AA에게 행복한 점은 이런 순간이 절대 오지 않으므로 본인의 업무를 개발자들에게 미룰 수 있다는 점이 될테죠.
DDD(Domain Driven Design - 도메인 주도 설계)를 한번 살펴봅시다.
도메인 주도 설계에서는 업무 도메인을 나누고, 나눈 도메인을 aggregate로 묶고, 도메인 혹은 애그리거트 단위로 개발을 하는 것을 중요하게 여깁니다.
"업무 도메인"은 "현장의 업무"를 반영해야 하고, 적어도 작은 단위의 개발, 즉 "도메인"은 현업과 완벽하게 일치하는 것을 최대한 지향한다는 거죠.
큰 단위의 완벽한 시스템을 만들 수는 없으니 작은 단위의 시스템이라도 완벽하게 만들고 서로 끼워넣자..라는 것이 DDD의 핵심입니다.
그런데.. 작은 단위의 시스템이라고 해서 완벽 같은 게 가능할까요?
물론 비행기를 만드는 일보다는 종이컵을 만들어내는 일이 더 쉬울수는 있습니다만, 그렇다고 종이컵을 만드는 과정이 더 완벽하리라는 보장이 어디 있을까요?
오해하지 마세요. 저는 DDD가 나쁘다고 말하는 것이 아닙니다.
DDD는 굉장히 현명한 접근이고, 최근에 MSA의 추세와 맞물려서 엄청나게 각광받고 있습니다. 작은 도메인들을 작은 서비스로 만들고 서비스들끼리의 연결을 통해 큰 서비스를 만들어나간다는 거죠.
한가지 단점은, 사실 단일 개발은 그다지 어려울 게 없다는 점입니다. 시스템을 만들 때 어려운 점은 대부분 두가지 이상의 복합 개념이 섞이는 시점에 등장하는데, 아직 여기에 대한 명쾌한 해법은 없네요.
그래서 저는 처음부터 DDD에 따라 업무 도메인을 나누지 말고, BBOM에 따라 일단 동작을 구현한 다음, 업무 도메인을 분리하는 리팩토링을 하는 것이 더 좋다고 생각합니다.
일단 동작이 구현된 상태에서는 업무 도메인이 더 명확하게 보이고, 프로덕트의 출시일이 밀릴 이유도 없으며 사용자의 반응에 따라 쓸모없는 업무 도메인이 도출될 가능성이 높기 때문이죠.
물론 현실은 시궁창이기 때문에 BBOM으로 일단 만들어놓고 나면 더이상 도메인을 분리할 여유가 없는 경우가 다반사이기는 합니다만.. 이부분은 각 회사의 분위기나 상황에 따라 다르기 때문에 열심히 경영진을 설득하라고밖에 말씀을 못드리겠네요.
성장하는 개발자가 되고 싶다면 리팩토링은 꿈도 꾸지 말라는 회사는 가능한 빨리 도망치세요.

큰 진흙 공(BBOM) 방식과 DDD

댓글