도메인 주도 설계(Domain-Driven Design) in Real Project — 한계
소프트웨어 프로젝트에서 모든 문제를 해결할 수 있는 완벽한 이론은 없습니다. 따라서, 각 문제들을 해결할 수 있는 다양한 방법들을 시도할 필요가 있습니다. 다양한 방법들을 프로젝트에 어떻게 녹여낼 수 있을까요?
TL;DR
- 모든 패러다임은 장/단점이 있고 결국은 그 ‘단점’에 막혀 이론적인 또는 경험적인 길을 벗어나는 편법을 반영하여 적용하게 됩니다.
- 의사 소통은 생각보다 많은 것을 요구합니다. 소프트웨어 개발을 위한 도메인 지식은 물론, 도메인 이외의 지식들도 필요로 합니다.
- 도메인을 이해하고 소프트웨어에 녹여내는 것이 목표가 되어야 합니다.
- 원할한 의사 소통을 위해서는 각자가 알고 있는 지식이나 아이디어를 설명하는 것이 우선이 아니라, 그 도메인이 무엇인지 이해하고 관련된 요소들과 필요로 하는 것들을 고민해야 합니다.
- 소프트웨어 프로젝트에서 나타나는 여러 가지 한계를 극복하기 위해 Bounded context를 어떻게 활용할 수 있을까요?
패러다임(Paradigm)의 한계
하나의 소프트웨어 프로젝트는 수많은 패러다임(paradigm) 속에서 개발이 진행됩니다. 이는 코드를 작성하는 프로그래밍만을 의미하지 않습니다. 팀을 구성하는 방법, 아이디어를 내는 방법, 요구사항을 정리하는 방법, 프로그래밍의 방법, 소통의 방법 등 다양한 주제에서 효율적인 해결 방법들을 찾아 적용하게 됩니다.
하지만, 어떤 방법이든 장/단점이 있고 결국은 그 ‘단점’에 막혀 이론적인 또는 경험적인 길을 벗어나는 편법을 반영하여 적용하게 됩니다. 그리고, 편법들은 계속해서 곳곳에 쌓여가기 시작합니다.
예를 들어, 애자일 개발 방법론(agile development methology)은 빠르게 소통하는 것을 통해 개발 항목들과 이슈들을 정리하고 해결해 나가는 것을 지향하는데, 실제 프로젝트에서는 기획, 개발, 소통, 고객 등으로부터 발생하는 이슈들로 인해, 이상과 현실의 격차는 생각보다 큽니다.
- 개발해야 할 항목이 줄어들지 않습니다.
- 기존의 이슈들을 해결하더라도, 프로젝트가 진행되면서 더 많은 이슈들이 발생합니다.
- 서로 간의 의견이 달라 논의가 길어지거나 자주 발생합니다.
- 고객이 기다려주지 않습니다.
- 기존의 이슈들의 우선순위가 자주 다음으로 미루어집니다.
- …
이 때, 애자일 프로세스 개선을 위해 지속적으로 소통하고 많은 논의를 하게 됩니다. 그리고 프로세스 개선이 끝났다고 느껴질 때는 서로가 개선을 위한 논의를 멈추었을 때 입니다. 하지만 실제 프로젝트에서는 개선을 위한 논의는 프로젝트가 끝나기 전엔 끝나지 않습니다. 논의가 더 이상 되지 않을 때가 있다면, 사실상 서로가 침묵하거나 애자일 프로세스가 더 이상 의미가 없을 때 입니다.
왜 이러한 패러다임이 완벽하게 진행될 수 없을까요?
패러다임은 법칙이 아닌, 경험을 통해 도출된 참고 사항이기 때문입니다. 실제 프로젝트의 환경과 상황들은 매우 다양하고, 수많은 변수들이 있습니다. 프로젝트에서 발생하는 수많은 경우의 수들을 특정 패러다임에 맞추려고 하면, 그 패러다임의 의미는 더 추상화되어지고 규칙들은 쌓여갑니다. 결과적으로, 모든 프로젝트 관련자들이 쉽게 따라가기 어려운 이론이 됩니다. 이러한 패러다임의 증명은 회사가 성공했다는 것을 통해 알려지게 되는데, 향후에 다른 회사들이 이것을 반영하더라도 환경과 상황이 다르기 때문에, 패러다임을 변경하고 개선은 결국 진행될 것입니다.
DDD도 패러다임일까요?
패러다임이라고 말할 수 있습니다. 사용자가 필요로 하는 것(도메인)을 우선적으로 사고해야 한다는 규칙 아닌 규칙이 있기 때문입니다. 그 외에는 ‘이렇게 해야한다’라는 것은 없습니다. 도메인이 필요로 하는 모든 방법들을 이용할 수 있습니다. Bounded context, 보편 언어(ubiquiotous language), Aggregate 등 DDD에서 사용되는 용어들과 방식들은 도메인을 먼저 사고할 때, 만들어지는 상황과 구조들을 설명하기 위해 편의상 사용하는 용어라고 생각하는 것이 좋습니다.
그러므로, DDD도 한계를 지니고 있습니다. 어떤 한계를 가지고 있을까요? 이 내용은 향후 다른 글에서 구체적으로 살펴보도록 하겠습니다. :)
의사 소통(Communication)의 한계
의사 소통은 모든 프로젝트에서 가장 중요한 요소입니다. 프로젝트 내에서 한 명이라도 중요시 여기지 않는다면, 프로젝트에서 문제가 발생하게 됩니다. 의사 소통은 단순히 대화를 하는 것을 의미하지 않습니다. 상대를 설득하고 내 자신이 납득하는 과정을 통해 프로젝트와 소프트웨어를 이해합니다. 누군가를 설득하고 내가 납득하기 위해서는, 매우 객관적으로 접근할 필요가 있습니다.
객관적으로 판단하기 위해서는 전제 조건이 필요합니다. 주제와 관련된 배경을 알아야하고, 과거/현재/미래의 환경과 상황도 함께 고려되어야 합니다. 생각해야 하는 것들은 프로젝트 요소들의 존재 여부와 그 요소 간의 관계들입니다. 그런데, 대화하는 모든 사람이 다른 지식을 가지고 있고, 이해하고 있는 수준이 다르기 때문에 의사 소통은 생각보다 어려워집니다. 특히, 개발자와 도메인 전문가는 일반적으로 서로 알고 이는 지식이 크게 다릅니다. 이를 다음과 같이 크게 두 가지 경우로 생각해볼 수 있습니다.
연관된 요소가 많을 경우
- 대화 주제의 범위가 작으면 개발자와 도메인 전문가 모두가 어떤 대화를 할 지 또는 하고 있는지 쉽게 알 수 있습니다.
- 대화하고 있는 범위가 커지기 시작하면, 개발자와 도메인 전문가 모두 상대의 주제를 해석하기 위해 훨씬 더 많은 것을 고려해야 할 수 있습니다.
표현의 차이가 있을 경우
- 서로 같은 의미로 말하고 있는지 다른 의미로 말하고 있는지 마음 속으로 다시 한 번 생각해볼 필요가 있습니다.
- 개발자는 자신이 구현한 범위를 벗어나면, 도메인 지식이 상대적으로 부족하기 때문에, 점점 대화 내용을 이해하기 어려운 상황에 도달하게 됩니다.
의사 소통은 생각보다 많은 것을 요구합니다. 소프트웨어 개발을 위한 도메인 지식은 물론, 도메인 이외의 지식들도 필요로 합니다. 대화를 하는 관계자들의 성격, 상대와 나의 환경과 상황, 프로젝트의 상황 등을 고려하여야 합니다. 의사 소통에 의해 문제가 발생한다면, 의사 소통 방법의 문제일까요? 아니면 그 이외의 요소에 의한 문제일까요?
소프트웨어 프로젝트의 목적
소프트웨어 프로젝트를 진행하면서 가장 많이 고민해야하는 것은 소프트웨어를 이해하고, 그 의미와 가치를 생각하는 것입니다. 패러다임을 효율적으로 적용하는 것, 의사 소통을 효율적으로 적용하는 것이 목표가 아닌, 도메인을 이해하고 소프트웨어에 녹여내는 것이 목표가 되어야 합니다. 즉, KPI가 어떤 방법이나 기술적 요소가 되어서는 안됩니다.
모두가 어디에 관심을 가지고 집중하느냐에 따라, 같은 결과를 향해 나아가더라도 프로젝트의 진행 방법은 크게 달라집니다. 앞에서 예를 든 것과 같이, 애자일은 하나의 패러다임일 뿐입니다. 완벽한 패러다임을 적용하기 위해서는, 소프트웨어 프로젝트에 필요한 것이 아닌, 그 패러다임을 위한 요소들이 준비되어야 합니다. 더 나아가서, 원하던 이상적인 패러다임이 완성된다고 하더라도, 그것이 프로젝트와 어울린다는 것은 보장할 수 없습니다. ‘의사 소통을 효율적으로 하는 방법’도 결국 패러다임에 불과합니다. 수많은 상황적 경우의 수와 서로의 다른 지식에 대응하기 위해 많은 시간이 소요됩니다.
소프트웨어 프로젝트의 목적은 사용자에게 가치 있는 소프트웨어를 개발하는 것입니다.
사용자가 요구하는 대로 만든다는 의미가 아닙니다. 사용자의 요구를 충족하기 위해 고민해야 할 다양한 요소들을 나열하고 순차적으로 해결하는 방향을 지향합니다. 다시 말하면, 도메인 문제를 이해하고 해결하는 것이 목표가 되고, 그 외에 것들은 부차적인 요소가 됩니다.
예를 들어, 이상적이고 완벽한 패러다임 x와 y가 있다고 가정하겠습니다. 이 때, x와 y를 이용해서 도메인 A를 도출해내는 것이 아니라, 도메인 A를 도출해내기 위해 x와 y를 검토하고 적용합니다. x와 y가 완벽하다고 해서 도메인 A 도출을 위해 두 가지 모두 필요하다고 말할 수는 없습니다. 또는, x와 y 이외에 다른 z의 패러다임을 필요로 할 수도 있습니다.
의사 소통도 동일합니다. 원할한 의사 소통을 위해서는 각자가 알고 있는 지식이나 아이디어를 설명하는 것이 우선이 아니라, 그 도메인이 무엇인지 이해하고 관련된 요소들과 필요로 하는 것들을 고민해야 합니다. 이러한 대화를 지속적으로 진행하며 쌓아가면 모두가 동일한 이해로 소프트웨어를 개발해 나아갈 수 있고, 향후 도출되는 요소들의 역할을 명확하게 구분할 수 있기 때문에, 서로가 알아야 하는 지식의 부담도 덜 수 있습니다.
이와 같이, 도메인에 집중하면 도메인이 설명하는 범위와 도메인 간의 경계들이 명확하게 드러나는데, 이를 Bounded context라고 합니다. Bounded context는 하나의 도메인 또는 도메인의 집합이며, DDD에서 소프트웨어를 쉽게 바라볼 수 있도록 하는 시야를 제공합니다. 소프트웨어 프로젝트에서 나타나는 여러 가지 한계를 극복하기 위해 Bounded context를 어떻게 활용할 수 있을까요?
