devFancy BE Developer

DDD 세레나데 7기 1주차 (feat. 이벤트 스토밍)

2025-02-02
devFancy
Technology

이번 글은 DDD 세레나데 7기의 1주차에 대한 필자의 자극히 개인적인 후기입니다. 혹시 문제가 되는 부분이 있다면, 언제든 말씀해 주시면 감사하겠습니다. ☺️

Prologue

2023년, 2024년에 상반기까지는 코드 에 집중해서 그런지, 2024년 하반기부터는 코드 보다는 설계 쪽에 관심이 생겼다.

그래서 ‘설계를 어떻게 하면 잘할 수 있을까?’에 대해 스스로 고민을 하면서 처음에는 멀티 모듈에 대해 먼저 공부를 하게 되었다.

멀티 모듈과 관련된 영상을 보면서 현업 개발자분들이 왜 사용하고 어떤 이점이 있는지를 알게 되면서 이와 관련된 글을 블로그에 작성한 바 있다.

(멀티 모듈과 관련해서 이전에 작성한 글 - Kotlin, SpringBoot 기반으로 멀티 모듈 설계와 적용하기)

멀티 모듈에 대해 도움이 되었던 대표적인 영상과 자료는 아래와 같습니다. 이 외에도 다양한 영상과 자료를 참고했으나 이 글에서는 중요한 부분이 아니므로 생략했습니다.

멀티 모듈에 대해 이론적으로나마 어떤 내용인지는 이제 알게 되었다. 그런 다음에 ‘IT 회사는 현재 시점으로 지난 3년간 어떤 설계에 관심을 가지고 있을까?’에 대한 궁금증이 생겼다.

그 결과 흔히 알고 있는 여러 IT 회사에서 도메인 주도 설계(Domain Driven Design)을 현업에서 사용하는 것을 찾게 되었다. (이후 아래부터는 도메인 주도 설계를 DDD라는 단어로 표현하겠다)

DDD 관련 영상과 자료들은 아래와 같습니다. (최신순 으로 내림차순 정렬)

이 외에도 다양한 영상과 자료가 있습니다.

DDD 세레나데 7기 신청

이전에 DDD 라는 단어를 많이 들어봤지만 이론/실무적으로 사용해 본적이 없어서 한번 경험해보고 싶다는 생각이 들었다.

그런데 정말 우연하게도 DDD 관련 강의가 넥스트스텝에서 존재한다는 걸 지인을 통해 알게되었고, 해당 강의가 나왔을 때 신청하게 되었다.

알고보니, 이전에 필자 봤던 우아콘 2023, 2024 영상에서 나온 재성님이 해당 강의를 진행해서 그런지 더 신뢰가 갔다.

(해당 강의비가 99만원이라는 사실을 알고 난 뒤, 고민을 많이 했지만 미래의 ‘나’ 자신에게 투자한다는 생각으로 결제를 하게 되었다. 내돈내산 🥲)

어느 강의보다 비쌌기 때문에, 무조건 열심히 들어야 겠다는 다짐을 하게 되었고 해당 강의가 끝난 이후에도 ‘DDD 세레나데 7기 강의’에 대한 후기글을 남기려고 한다.

이번 글은 1주차에 있었던 부분들에 대해 간단히 배웠던 점을 정리하고자 한다.

앞으로 해당 강의를 진행하면서 수행한 미션들은 깃허브에 업로드할 예정입니다.

1주차

1주차 때는 해당 강의에 대한 과정을 어떻게 진행하는지, 그리고 강의를 듣는 수강생이 어떻게 임해야 하는지에 대해 강의를 진행하는 재성님이 이해하기 쉽게 자세히 알려주셨다.

또한, DDD 관련 기술적 지식을 알려주기도 하지만 참여자가 해당 강의를 듣고 실무에 적용하도록 하기 위해 주차별로 미션이 주어진다는 점이다.

해당 미션에 대한 진행 방법과 미션을 진행하는 과정 속에 온라인 코드 리뷰가 있고, 리뷰어 분들은 대부분 해당 강의를 이전에 수강했던 분들이셨다.

뿐만 아니라, 해당 강의에 도움이 되는 영상과 자료들도 되게 감사했다. 해당 강의를 꼼꼼히 준비하신 게 들을 수록 느껴졌다.

(해당 강의가 끝나고 이후 미션들에 대해 완료한 결과, 아래 PR에 정리했다.)

0단계: JUnit 5 학습

해당 강의에 대한 과정을 전반적으로 알려준 뒤, 마지막 시간에는 Junit 5에 대해 재성님이 직접 Java 언어로 어떻게 작성하는지 알려주었고 해당 코드 부분을 따라가면서 학습했다.

해당 부분에 대한 깃허브 PR은 아래와 같다.

아래부터는 필자가 단계별로 미션을 진행했던 후기이다.

1단계: 문자열 덧셈 계산기

1단계는 “문자열 덧셈 계산기”로 해당 주제에 맞게 코드를 작성하고 PR를 보내서 리뷰어분으로부터 코드 리뷰를 받게 된다. (해당 리뷰어의 PR 승인을 받게되면 미션을 완료했다는 결과이다)

1주차이고 해당 주제가 간단해서 그런지, 초반에는 세세한 부분 보다는 구현에 집중해서 PR를 제출했다. 하지만 리뷰어분의 피드백은 내 생각과 달랐다.

아무리 쉬운 미션이라도 꼼꼼하게 작성하는 걸 원하셨고, 강의를 진행하시는 재성님 역시 ‘매주 전달받은 미션을 진지하고 꼼꼼하게 진행해주셨으면 한다’와 비슷한 메시지를 전달 받은 후에는 제대로 임하게 되었다.

그래서 리뷰어분의 피드백이 논리적으로 맞다면 받아들이고, 해당 코드(or 문서) 부분을 수정하고 다시 리뷰를 보낸다. 그리고 다시 리뷰를 받으면서 리뷰어분이 만족할 때 까지 이 과정을 반복했다.

이 과정에서 단일 책임 원칙, 배열 대신 컬렉션 활용, 일급 컬렉션, Java 16 이후의 새로운 기능들에 대해 알게 되었다.

그 결과, 해당 1단계 미션을 성공적으로 끝냈다.

2단계: 요구 사항 정리

2단계는 해당 강의에서 수행하는 최종 미션 주제인 키친 포스에 대해 요구 사항을 작성하는 미션이다.

이번 2단계 미션에서 필자가 고민했던 부분은 ‘요구 사항을 어떻게 정리해야 하면 좋을까?’ 였다.

초반에는 비즈니스 로직 순서대로 작성해보았지만, 필자가 아닌 제 3자가 보기에 이해하는 부분과 깔끔하게 정돈되지 못한다고 판단했다.

그래서 도메인별 API 기준으로 재구성해서 요구 사항을 작성했고, 이 부분에 대해 PR를 작성하면서 리뷰어분의 의견을 듣고 싶어서 해당 내용을 작성했다.

리뷰어님의 의견을 간단하게 정리하면 아래와 같다.

  • 개발 실무진들 간 도메인 지식을 공유하는 목적이라면 도메인별 API 기준으로 요구 사항을 작성한다. 도메인 단위로 요구 사항을 명확하고 체계적으로 표현할 수 있기 때문이다.

  • 그게 아니라 다른 직무(기획자나, 디자이너 또는 상위 직책자)를 위한 문서라면 유저 시나리오를 기준으로 요구 사항을 작성한다. 유저의 액션과 그에 따른 흐름을 한 눈에 파악할 수 있기 때문이다.

해당 리뷰어님의 의견을 듣고, 필자가 생각했던 부분과 거의 일치해서 신기하기도 했고, 해당 의견을 자세히 알려주셔서 정말 감사했다.

이 외에도 다양한 피드백을 PR에 남겨주셨는데, 필자가 생각한 그 이상으로 도움받은게 많아서 정말 감사했다. (해당 리뷰어님이 이후의 단계들도 이어서 피드백 해주시면 좋겠지만, 강의 특성상 단계별 리뷰어분이 랜덤으로 바뀌어서 아쉬웠다 😭)

3단계: 테스트를 통한 코드 보호

추가한 날짜: 2025.03.15(토)

3단계는 해당 강의에서 제공한 ddd-legacy 프로덕션 코드와 2단계에서 필자가 작성한 요구 사항을 토대로 테스트 코드를 작성하는 미션이다.

3단계에서는 Fixtures 클래스를 만들어서 활용했고, 매 테스트 실행 후 DB를 정리하기 위해 tearDown() 메서드를 적용했다.

그리고 테스트 코드를 이전에 인프런 강의인 ‘Practical Testing’ 에서 학습했는데, 해당 강의에서 배운 내용을 기반으로 적용하고자 했다.

아래는 해당 강의에서 배운 내용을 개인 블로그에 정리한 글이다.

미션을 수행하는 도중에 궁금한 점들을 PR에 작성했고, 리뷰어님의 의견을 듣고자 했다. (리뷰어님이 나의 궁금한 점들을 최대한 구체적 + 경험에 비추어 답변해주셔서 정말 감사했다)

리뷰어님의 피드백과 해당 강의에서 배운 결과, 테스트 컨테이너와 DB를 정리하는 tearDown() 메서드를 사용하는 것 보다 테스트 시간이 짧은 인메모리로 Mocking 하고 Fake 객체를 사용하는 방법을 택했다.

테스트 컨테이너를 사용하면 매번 DB를 생성/종료하거나 데이터를 정리해야 하므로 실행 시간이 상대적으로 길어진다. 반면 Mock/Fake는 DB 의존성이 없기 때문에 테스트가 가볍고 빠르며, 변경 사항을 자주 적용해야 하는 TDD 상황이나 대량의 테스트 케이스를 돌릴 때 빠른 피드백을 얻기에 훨씬 유리하다고 느꼈다.

  • 실제 DB 연결 없이 테스트 구동이 빨라진다. (네트워크 비용, DB 초기화 시간 소모 X)

  • 개발 환경에서 쉽게 세팅 가능하다.

단, 단순한 비즈니스 로직이 아닐 경우에는 주의할 점도 있다.

  • 실제 DB와 달리, 인메모리에서 발생하지 않는 문제(복잡한 쿼리 최적화, 락 문제 등)가 숨겨질 수 있다.

  • 즉, “핵심 비즈니스 로직”은 Fake/Mock으로 빠르게 커버하되, “DB 트랜잭션이나 복잡한 쿼리 로직 테스트“처럼 프로덕션과 유사한 환경의 시뮬레이션이 필요한 경우에는 Testcontainers 등 실 DB 테스트도 추가로 진행할 수 있다.

결국 테스트코드가 많아질수록 테스트 실행 시간을 단축해야 하므로 인메모리를 적극 활용해야 한다는 점을 배웠고, 비즈니스에 중요한 부분을 중심으로 테스트코드를 작성하는 것이 유지보수 관리에 드는 시간과 비용을 절감하는 데 효과적이라는 것을 이번 미션을 통해 다시 한번 깨달았다.

1주차 복습하기

1주차 미션에서 나온 용어들에 대해 한 줄로 정리하면 아래와 같다.

  • 도메인 - 소프트웨어로 해결하고자 하는 문제 영역 입니다.

    • 예를 들어, 예를 들어, 핸드폰을 이용하여 사용자 간에 거래를 할 때 필요한 도메인은 송금입니다.

    • 송금 도메인을 제대로 이해하려면, 송금과 관련된 금융, 계좌, 수수료 등의 지식이 필요합니다.

  • 모델 - 목적을 위해 현실 세계에 존재하는 것을 가공하고 편집하여 우리에게 정보를 제공하는 것입니다.
    • 예를 들어, 금융 송금 시스템에서는 실제 은행 계좌, 송금 금액, 수수료, 거래 일자 등의 정보를 단순화하여 송금 요청, 송금 내역 등의 모델로 표현할 수 있습니다.
  • 도메인 모델 - 도메인의 핵심 개념과 비즈니스 규칙, 행동(메서드)까지 모두 반영한 목적을 가진 의사소통 수단입니다. 이는 회의, 기획, 디자인, 개발 등 여러 단계에서 공유되어, 시스템의 핵심 개념을 풍부하게 표현하고 비즈니스 로직을 구현하는 데 사용됩니다.
    • 예를 들어, 금융 송금 도메인에서는 ‘송금’, ‘계좌’, ‘거래’, ‘수수료’ 등의 개념을 객체와 연관관계로 표현하여, 송금 내역 생성, 수수료 계산, 계좌 잔액 검증 등의 비즈니스 로직을 포함하는 도메인 모델을 구축할 수 있습니다.
  • 도메인 주도 설계 - 비즈니스 관점에서 도메인을 중심으로 설계해 나가는 접근 방식입니다. 도메인 모델을 활용하여 복잡한 비즈니스 규칙과 요구사항을 코드에 명확하게 반영하고, 개발팀과 비즈니스 전문가 간의 효과적인 의사소통을 도모합니다.

이벤트 스토밍 워크숍

2월 1일 토요일에는 처음 오프라인 모임을 진행하게 되었다.

선릉역에 있는 우아한 테크코스에서 오후 2시부터 6시까지 약 4시간 동안 진행했는데, 여기는 글또 10기 백엔드/인프라 반상회때도 온 적이 있어서 친숙한 공간이기도 했다.

해당 오프라인 모임을 진행하기 전에 재성님이 슬랙에 해당 주제와 비슷한 영상을 추천해 주셔서 필자는 미리 보고 왔다.

필자는 이벤트 스토밍을 위의 영상을 이전에도 봤고 실제로 3번 정도 적용한 경험이 있어서 그런지, 4시간이면 충분히 할 수 있겠다라는 생각이 들었다.

(이번 오프라임에서의 이벤트 스토밍의 목표는 영상에 있던 모든 걸 적용하지 않고, 4시간동안 1-2단계만 진행하는 것으로 했다)

초반에는 도메인 이벤트 (주황색)으로 최종 미션 주제인 ‘키친 포스’에 대해 작성했고, 이후에는 시간순으로 정렬하는 부분과 도메인 기준으로 나누면서 정해진 시간안에 끝마칠 수 있어서 뿌듯했다.

이벤트 스토밍을 작성할 때 중간마다 드라이버와 내비게이터를 수시로 바꾸면서 진행하게 되었는데, 이때 두 가지의 역할에 대해 제대로 알게되었다.

1단계 - 도메인 이벤트를 기준으로 생각나는 대로 작성해서 포스트잇 붙이기

(아래는 이벤트 스토밍의 1단계를 적용한 결과이다)

2단계 - 타임라인 적용(왼쪽 -> 오른쪽, 위 -> 아래) + 핫 스폿, 액터, 시스템 적용하기

(아래는 이벤트 스토밍의 2단계를 적용한 결과이다)

이벤트 스토밍 영상을 만들어주신 재성님을 직접 볼 수 있어서 영광이였고, 해당 오프라인에 참가할 수 있어서 감사했다. 기회가 된다면 회사에 적용하고 싶고 만약 그렇게 된다면, 퍼실리테이터 역할을 맡고 싶다.

(퍼실리테이터 역할 뿐만 아니라 이벤트 스토밍에 관심이 있거나 알고 싶으면 위의 영상을 참고해 주시면 감사하겠습니다)

이벤트 스토밍에서 배운 점

이전에는 이벤트 스토밍을 주로 기획 초기 단계에서 진행하는 경우가 많았다. 하지만 “[우아콘 2023] 이벤트 스토밍 인 액션” 영상(31분)에서 언급된 것처럼, 일정 수준의 기획이 나온 후에 진행하는 것이 더 효과적이라는 점을 새롭게 알게 되었다.

오프라인 모임에서도 재성님이 같은 맥락의 말씀을 해주셨다. “기획이 어느 정도 구체화되고, 개발이 일정 부분 진행된 이후에 이벤트 스토밍을 하면 더욱 유용하다”는 것이다. 기획 초기에는 도메인 용어, 유저 시나리오 등이 자주 변경될 가능성이 크기 때문에, 기획이 어느 정도 안정된 후 진행하는 것이 좋다는 점이 인상적이었다.

또 하나 인상 깊었던 점은, 이벤트 스토밍은 결과를 만들어내는 자리가 아니라, 그 과정을 공유하는 자리라는 것이다. 이벤트 스토밍 자체를 최종 문서처럼 관리하기보다는, 워크숍 이후 변경 사항을 추적할 수 있도록 정책과 문서를 체계적으로 정리하는 것이 중요하다고 한다.

예를 들어, GitHub의 WIKI 같은 공간에 도메인 지식을 기록하면 효과적일 것이다.

또한, 변경할 사항이 많아진다면 최대한 빠르게 이벤트 스토밍을 다시 진행하는 것이 좋다. 한 번 이벤트 스토밍을 경험한 후에는 도메인에 대한 이해가 깊어지기 때문에, 다음 워크숍에서는 더 빠르고 효과적으로 진행할 수 있다.

무엇보다도, 이벤트 스토밍의 궁극적인 목표는 참여한 모든 구성원이 동일한 도메인 지식을 공유하고, 같은 이해를 가지는 것이라는 점을 다시금 깨닫게 되었다.

이벤트 스토밍 워크숍 복습하기

이벤트 스토밍 워크숍에서 배웠던 용어들에 대해 한 줄로 정리하면 아래와 같다.

  • 이벤트 스토밍 워크숍 이란?
    • 프로젝트에 같이 참가한 팀원들이 서로가 공통된 이해를 가지기 위해 도메인 지식을 탐구하는 과정입니다.
  • 내가 퍼실리테이터라면 어떤 마음가짐을 가져야 할까요?
    • 참가자들이 자유롭게 아이디어를 내고 논의할 수 있도록 돕고, 개입은 최소화하되 필요할 때 적절한 방향을 제시하는 조력자 역할의 마음가짐을 가진다.
  • 내가 드라이버라면 무엇을 염두에 두어야 할까요?
    • 도메인 이벤트를 논리적인 흐름에 맞게 배치하고, 팀원들과의 피드백을 주고받으며 조정합니다.
  • 내가 내비게이터라면 드라이버를 돕기 위해 어떻게 안내해야 할까요?
    • 도메인 이벤트의 맥락과 연관성을 고려하여 드라이버가 올바른 결정을 내릴 수 있도록 논리적으로 설명하고 안내해 줍니다.

Review

이번 글에서는 넥스트스텝의 “DDD 세레나데 7기”를 수강하게 된 배경과 1주차 미션에 대한 후기를 정리했다.

평소 DDD에 관심이 많았고, 그 철학에 공감하는 부분이 많았던 만큼, 미션을 수행하면서 흥미로웠다. 특히, 코드뿐만 아니라 설계와 도메인에 대한 깊은 고민을 할 수 있도록 유도하는 과정이 인상적이었고, 앞으로 남은 미션들도 기대된다.

이번 1주차는 설 연휴와 겹쳐서 미션을 수행할 시간이 많지 않았다. 그럼에도 가족이나 지인과 시간을 보내는 틈틈이 노트북을 열어 미션을 진행했고, 주말에도 카페에서 이어서 작업했던 기억이 남는다. (연휴 기간에도 빠르게 피드백을 남겨주신 리뷰어님께도 감사한 마음이다)

또한, 오프라인 모임에서 진행한 이벤트 스토밍을 통해, 단순히 기획 초기 단계에서만 활용하는 것이 아니라, 일정 수준의 기획이 진행된 후에 더욱 효과적이라는 점을 새롭게 배울 수 있었다. 뿐만 아니라, 이벤트 스토밍의 목적이 결과물을 만들어내는 것이 아니라, 참여자들이 도메인 지식을 공유하고 같은 이해를 가지는 과정 자체에 있다는 점도 깊이 와닿았다.

Reference

(추가) Domain-Driven Design Europe 2025

아래는 유럽에서 DDD 컨퍼런스 관련 부분이다. 이벤트 스토밍 가격만 €1,000, 환율로 계산하면 현재 기준(2025.02.05)으로 약 150만원(총 9.5시간)으로 비싼 워크샵이다.

DDD 관련 참고 자료

이벤트 스토밍 관련 참고 자료

Index