1.4 도메인 주도 설계를 개발 프로세스에 도입하기: 다양한 현장에서 바라본 네 가지 관점

[jongfeel]

1.4 도메인 주도 설계를 개발 프로세스에 도입 하기: 다양한 현장에서 바라본 네 가지 관점

1.4.1 도메인 주도 설계를 적용하기 쉬운 개발 방법은?

<도메인 주도 설계>에서는 다음과 같은 두 가지 관행이 정착되어 있다고 가정합니다.

• 개발 방식을 반복적으로 적용함으로써 변화와 불확실성에 대처한다.
• 반복적인 개발 과정에서 개발자와 도메인 전문가(업무에 정통한 사람)가 밀접하게 관여하여 방대한 지식을 기반으로 도메인에 대한 깊은 통찰력과 집중해야 할 주요 개념을 반영하는 모델을 만들어 낸다.

핵심에 집중하고 거기에 집중하여 도메인 모델을 만들고 구현까지 진행하는 스타일을 도입할 수 있는 개발 프로세스라면, 어떤 형태로든 도메인 주도 설계의 사고 방식과 설계 방식을 활용할 수 있을 것입니다.

1.4.2 개발 프로세스에 도입할 때 네 가지 관점

• 도메인 지식을 얻기 쉬운 환경을 만든다.
• 업무 규칙을 잘 도출한다.
• 팀에서 도메인 지식을 공유한다.
• 현실의 제약 속에서 도메인 주도 설계를 계속 적용한다.

1.4.3 도메인 지식을 얻기 쉬운 환경 만들기

• 고객에게 미리 설명하고 가능한 한 참여시킨다.
• 고객은 아니지만 업무에 정통한 사람을 찾는다.
• 클래스 이름이나 패키지 이름을 고객과 같은 언어(한국어)로 구현한다.

고객에게 미리 설명하고 잘 참여시킨다

• 비즈니스 배경이나 개발 대상 외의 업무에 대해서도 많이 들어 보고, 그 부분을 이해한 후에 개발을 진행하고 싶다.
• 도메인 주도 설계라는 기법을 도입하여 용어와 설계에 집중하고 싶다.

고객은 아니지만 업무에 정통한 사람을 찾는다

예를 들어 고객사에 10년째 상주하고 있는 엔지니어 같은 경우입니다.
유지보수와 운영을 경험한 이런 사람들을 잘 활용하면 도메인 지식의 귀중한 출처가 될 수 있습니다.

고객사와 동일한 언어로 클래스 이름과 패키지 이름을 구현한다

고객과 같은 언어(한국어)로 프로그래밍을 하면 업무 용어와 프로그래밍 모델이 일치하고, 유비쿼터스 언어로서 고객과 개발자 간에 언어를 공유할 수 있기 때문에 모델로 성장하기 쉽습니다.

상황을 변화시키기 위한 노력

• 고객도 업무 내용을 언어화하거나 사양을 결정하는 것에 익숙하지 않다.
• 다단계 하도급 구조로 되어 있어 개발을 실제로 담당하는 기술자와 고객과의 거리가 멀다.

다음과 같은 접근법을 통해 상황을 좋은 방향으로 바꿀 수 있다고 생각합니다.

• 고객에게 조금이라도 더 가까이 다가갈 수 있도록 미팅을 잡거나 미리 질문할 내용을 준비한다.
• 고객의 의도를 쉽게 이해할 수 있도록 개발자가 업무에 대한 일반적 지식을 충분히 습득한다.
• 파트타임이나 일시적이라도 좋으니 업무에 정통한 사람을 개발팀에 참여시킨다(특히 초기 단계).
• 고객의 업무를 수행하고 있는 곳(창고나 현장 등)을 견학하여 도메인 지식을 얻는 동시에 고객에게 좋은 인상을 준다.

1.4.4 업무 규칙을 효과적으로 도출하기

• 대상 업무 영역을 한정하여 진행한다.
• 고객 업무를 이해하고 있는지 검증한다.

대상 업무 영역을 한정하면서 진행하기

처음에는 대상 영역을 한정하여 그 좁은 영역에 대해서 깊이 이해합니다.
이를 바탕으로 대상 영역을 조금씩 넓혀 가면서 도메인 지식을 습득하다 보면 업무 규칙을 파악할 수 있습니다.

고객 업무에 대한 이해도 검증하기

실제 데이터를 통해 검증함으로써 업무 규칙을 제대로 이해하고 적절하게 구현하고 있는지 초기 단계부터 검증할 수 있습니다.
모델에 대해 잘못 이해한 부분이나 고객과 인식이 어긋난 부분을 서로 맞춰 가면서 구현하고 성장시켜 나갑니다.

상황을 변화시키기 위한 노력

• 개발팀의 생각대로 개발을 진행해 버린다.
• 개발자에게 익숙하지 않은 업무이기 때문에 고객의 이야기를 들어도 잘 모른다.
• 업무 규칙을 파악하거나 도메인 모델을 만드는 데 너무 많은 시간을 할애해 버린다.

이런 상황에서는 다음과 같이 접근하면 좋은 방향으로 나아갈 수 있습니다.

• 해당 영역의 일반적인 업무 지식이나 업무 규칙을 책이나 인터넷 정보를 통해 파악한다.
• 해당 업무를 수행하고 있는 곳을 견학하여 업무에 대한 이해도를 높인다.
• 실제 사용하고 있는 제품이나 사용 중인 물건의 실물을 보여 줌으로써 업무에 대한 이해도를 높인다.
• 범위를 제한적으로 시작해서 모든 것을 똑같이 분석하는 것이 아니라 핵심에 집중한다.
• 고객이나 제품 소유자를 포함해 업무 규칙을 파악하고 있는지 검증할 수 있는 기회를 늘린다.

1.4.5 팀에서 도메인 지식 공유하기

• 팀원들이 고객 업무에 관심을 갖도록 한다.
• 도메인 모델의 발전과 함께 팀원을 성장시킨다.

팀원들이 고객 업무에 관심을 갖도록 한다

팀 내 업무에 관심이 있는 구성원이 많을수록 도메인 주도 설계를 추진하기 쉬운 팀이 될 수 있습니다.
도메인 모델을 만들고 그것을 코드로 표현하는 것을 실제로 해보면 도메인(실제 업무)과 설계가 밀접하게 연관되어 있다는 것을 깨닫고 의식이 바뀌는 팀원이 늘어납니다.

도메인 모델과 함께 팀원을 성장시킨다

팀에 도메인에 대한 지식이 스며들면 팀원들도 업무에 관심을 가지기 쉽고, 관심을 가지면 이해도가 높아지는 선순환이 이루어집니다.
업무에 관심을 가지면 구성원들이 모여서 모델링할 기회가 많아지고, 대화하면서 용어를 조정하거나 핵심적인 부분을 파악하기 쉬워지고, 집단지성으로 업무도 이해할 수 있게 됩니다.

상황을 변화시키기 위한 노력

• 실력이 좋은 특정 팀원에게 지식이 편중된다.
• 업무 분석 작업을 나눠서 따로따로 해버린다.
• 팀원이 바뀌어서 지식이 남지 않는다.

팀원의 동기나 역량 부족으로 도메인 주도 설계를 추진하기 어려운 상황이라면 다음과 같은 접근 방법을 적용해 나가면 좋은 방향으로 진행될 수 있습니다.

• 몹 프로그래밍을 통해 업무와 관련된 다양한 사람이 참여하게 함으로써 흥미를 유도한다.
• 기능이나 구현 부분에 맞춰 팀을 나누는 것이 아니라 업무에 맞춰 팀을 나눈다.
• 지속적으로 팀원이 업무 지식을 얻을 수 있는 환경/기회를 정비한다.
• 팀원이 바뀌어도 전달되는 업무 지식을 최대한 늘리기 위해 개발자에게 가장 중요한 표현 수단인 소스 코드에 업무 지식이 작성되어 있는지를 리뷰의 중요한 관점으로 규정한다.

1.4.6 현실의 제약 속에서 도메인 주도 설계를 계속 적용하기

• 작업 공정에 도메인 모델을 발전시키는 과정을 추가한다.
• 팀원의 스킬 수준에 따라 진행한다.
• 도중에 참여한 팀원이 이해하기 쉽도록 한다.

작업 공정에 도메인 모델을 발전시키는 과정을 추가한다

도메인 모델에 대한 변경이나 리팩터링을 통해 모델을 성장시키는 작업을 미리 확보해 두면 이를 실행할 여유가 생깁니다.

팀원의 스킬 수준에 따라 진행한다

도메인에 대한 지식이나 기술력에 따라 전문가, 시니어, 주니어로 나누고, 전문가의 지시 아래 시니어가 주도해 업무에 대한 이해를 바탕으로 도메인을 분석한 다음, 주니어에게 전파하는 방법이 있습니다.
이러한 진행 방법으로, 주니어가 시니어로, 시니어가 전문가로 성장할 수 있는 기회가 생깁니다.

도중에 참여한 팀원이 이해하기 쉽도록 한다

도메인 주도 설계가 잘되어 있으면 업무 지식은 유비쿼터스 언어로서 소스 코드에 반영되어 있는 형태가 됩니다.
그렇게 되면, 프로젝트 도중에 참가하는 팀원이 있거나 얼마 지나지 않아 유지보수 개발로 소프트웨어를 개선할 때도 업무를 이해하면서 소프트웨어의 내용을 파악하기 쉬워집니다.

상황을 변화시키기 위한 노력

• 도메인 주도 설계 방식에 대한 프로젝트 관리자의 이해가 부족하다.
• 프로젝트가 잘 진행되지 않으면 도메인 주도 설계를 도입한 것이 화근이 될 수 있다.
• 계약 형태 등으로 도메인 주도 설계 방식에 대한 동기 부여가 되지 않는 구성원도 있다.

다음과 같은 접근법을 적용했을 때 좋은 방향으로 나아갈 수 있을 거라고 생각합니다.

• 도메인 주도 설계로 개발한 경험이 있는 사람을 팀원으로 추가해 지식을 공유하도록 한다.
• 도메인 주도 설계의 좋은 점과 나쁜 점을 잘 파악하여 좋은 점을 효과적으로 사용할 수 있도록 한다.
• 혼자서는 마음이 꺾이기 쉬우므로 여러 명이 함께 작업하고 서로 동기 부여를 할 수 있는 환경을 만든다.
• 경영진을 참여시켜 탑 다운(하향식)으로 추진할 수 있는 환경을 만든다.

1.4.7 적용 사례 ① - 적절한 팀 구성

개발 프로젝트 상황

개발 체계는 다음과 같습니다.

• 고객 측: 경영진, 사업팀, 정보 시스템팀
• 개발 회사: SI의 X사, Y사

개발은 정보 시스템팀 주도로 진행되었으며, X사는 화면 담당 개발을 수행하는 프런트엔드팀, Y사는 서버측 개발을 수행하는 백엔드팀으로 구성되어 있습니다.

프런트엔드팀은 사업팀 담당자에게 들은 As-Is(현재)의 화면 이미지를 기반으로 검토하고, 그 화면 사양에 따라 필요한 API를 백엔드팀에 요청했습니다.
한편 백엔드팀은 To-Be(미래)의 화면 이미지를 경영진에게 듣고 프런트엔드팀에서 요청하는 API를 개발했습니다.

이 개발 프로젝트를 네 가지 관점에서 바라본 상황은 표 1-6과 같습니다.

표 1-6 사례 ①의 개발 프로젝트 상황

네 가지 시점	상황
도메인 지식을 얻기 쉬운 환경 만들기	도메인 지식을 얻을 수 있는 환경은 잘 갖춰져 있으나 정보의 출처가 여러 곳이어서 팀마다 업무 이해도가 달랐다.
업무 규칙을 효율적으로 도출하기	프런트엔드팀은 As-Is 화면을 기반으로 하는 업무 규칙에서 사양을 도출하고, 백엔드팀은 To-Be를 중심으로 업무 규칙을 도출하다 보니 컨텍스트의 차이로 의미의 혼동이 빈번하게 발생한다.
팀 내 도메인 지식 공유하기	가장 큰 문제점은 바로 이 부분이다. 컨텍스트가 다르거나 화면 기반으로 업무를 파악하는 등 팀마다 업무에 대해 다른 도메인 모델을 사용하고 있었다.
현실의 제약 속에서 도메인 주도 설계를 계속하기	용어와 정보 구조가 맞지 않는 문제는 인지하고 있었다. 지속적으로 도메인 주도 설계를 적용하고 개선하려는 동기 부여는 있었다.

개선의 노력

• 각 팀의 용어와 사양이 서로 맞지 않아 일관성이 없는 상태가 되어 버렸다.
• 업무에 대한 인식이 엇갈려 팀 간에 개발 우선순위와 진행 방식이 합의되지 않은 상태가 되어 버렸다.
• 그러한 상황을 고객이 정리하고 조정할 수 없게 되었다.

이 상황을 개선하기 위해서, 프런트엔드팀과 백엔드팀으로 나누지 않고, ‘업무 영역마다 팀을 나누는 체제로 바꾸었습니다.

경계 컨텍스트 단위로 팀이 구성되어 하나의 도메인 모델을 공유할 수 있게 되었습니다.
그 결과 다음과 같은 개선 효과를 얻었습니다.

• 업무별로 팀을 구성하여 팀 내 업무 이해도와 모델을 통일할 수 있게 되었다.
• 팀 내에서 모델을 공유하여 업무 규칙에 집중하기 쉬워졌다.
• 업무 단위로 팀을 구성함으로써 프런트엔드 담당자와 백엔드 담당자 간 도메인 지식을 공유할 수 있게 되었다.
• 경계 컨텍스트를 적용한 효과가 뚜렷하게 나타나면서 도메인 주도 설계를 본격적으로 도입하려는 분위기가 형성되었다.

그 이후의 전개

유감스럽게도 개발 정책이나 체제에 큰 변경이 있어 필자가 관여할 수 있었던 것은 이 단계까지였습니다.

1.4.8 적용 사례 ② - 상세 설계서를 프로그래밍 언어로 작성

상세 설계서를 프로그래밍 언어로 작성하고, 소스 코드에 상세 설계서에 대응하는 문서를 자동으로 생성하는 방식입니다.

이 노력의 목적은 다음과 같습니다.

• 단계별로 담당자를 나눠 문서를 작성하여 제일 마지막에 산출물이 전혀 다른 문서가 되어 버리는 상황을 조금이라도 개선합니다.
• 포괄적인 문서 작성의 비효율성을 개선합니다.

그 결과는 다음과 같습니다.

• 상세 설계 단계를 없앰으로써 업무 SE의 역할과 개발자의 역할을 같은 사람이 담당하거나 담당자끼리 매우 긴밀하게 교류하여 도메인의 지식과 구현의 연결이 쉬워졌다.
• 업무 규칙의 요점을 파악하면서 도출하고, 프로그램으로 연결하여 표현할 수 있게 되었다.
• 개발자도 구현 수준의 세세한 사양에 대해 이해를 할수 있게 되어, 업무 규칙이 더욱 정교해졌다.
• 상세 설계 단계 하나가 없어짐에 따라 도메인 지식의 공유가 개선되었다.

1.4.9 적용 사례 ③ - 스케줄 관리 방법의 연구

WBS, 간트 차트 방식

도메인 모델의 진척 상황은 숫자로 나타내기 어렵습니다.
그래서 간트 차트에서 리팩터링 작업을 명시적으로 배치함으로써 도메인 모델을 발전시킬 시점을 제어할 수 있습니다.

각 구성원이 명확한 불편함이나 현재 도메인 모델로는 해결할 수 없는 구체적인 문제 등을 느끼지 못하더라도, 리팩터링 작업을 도메인 모델 검토와 인식 전환의 기회로 활용하면 도메인 모델의 성장을 촉진할 수 있습니다.

그 결과는 다음과 같습니다.

• 도메인 모델에 초점을 맞춘 작업을 정의함으로써 도메인 지식을 얻을 수 있는 기회를 늘릴 수 있었다.
• WBS와 간트 차트에서의 관리는 기존 화면이나 테이블 단위로 작업이 좁게 분할되어 있어, 업무 규칙에 초점을 맞추기가 어려웠다.
• 간트 차트라면 작업의 진행 상태나, 어떠한 기능이 필요한지에 대한 시점에서의 도메인 지식은 파악하기 쉬워졌지만, 기능 간 업무에 대한 깊이 있는 지식의 공유는 잘되지 않았다.
• 각각의 기능을 만드는 것에 초점을 맞춰 버리는 바람에, 기능 간의 관계를 업무의 시점에서 파악할 수 없었다.
• WBS를 바탕으로 한 간트 차트에서의 관리는 고객이나 프로덕트 오너에 대한 보고를 포함하여 프로젝트 관리 현황을 주위에 전달하기 쉬웠다.

마일스톤과 타임박스로 관리

또 다른 방법으로 마일스톤과 타임박스로 관리한 사례도 있습니다.
기능(업무) 단위로 마일스톤과 타임박스를 설정하고, 작업 수준은 각 타임박스 안에서 관리함으로써 개별 작업의 진행 상황보다 업무 수준의 가치 제공에 초점을 맞추는 방식입니다.

마일스톤 기반으로 관리한 프로젝트에서는 도메인 모델의 성장을 너무 의식한 나머지 과도한 분석, 검토, 리팩터링으로 인해 프로젝트 중반 이후 시간이 부족했습니다.

전체에 대한 이해가 없는 상태에서 모델 개선에만 집중하다 보면 품질을 만족했다고 생각할 수도 있지만, 잘못된 최적화나 추상화에 시간을 낭비해 버리는 경우가 대부분이기 때문입니다.
그렇기 때문에 프로젝트 초반에는 업무를 이해하는 데 시간을 들이고, 업무를 어느 정도 이해한 시점에 모델을 개선하는 것이 좋습니다.