사내 스터디를 마치며

22년 1분기 동안 사내 스터디를 진행했다.

주제는 DDD (Domain Driven Design) 였고 모두가 공통의 주제를 공부하며 우리 코드에 적용해 볼 수 있는 곳과 책에서 배운 예시와 비슷한 지점을 찾아보았다.

책 한 권을 읽는데 생각보다 많은 시간이 걸렸다.

양이 많은 것도 있었지만 점점 어려워지는 난이도와 복잡한 예시들로 인해 여러번 좌절할 뻔했다 ..

그래도 포기하지 않고 모두와 함께 끝까지 달릴 수 있었고 오늘은 그 회고를 작성해 보고자 한다.

(이 글은 Eric Evans 의 Domain Driven Design 을 참고해 작성했습니다.)

---

용어 정리

DDD (Domain Driven Design) 란?

해당 도메인과 일치하도록 소프트웨어를 모델링하는데 중점을 둔 소프트웨어 설계 접근 방식이다.
위키 백과 참고

도메인 (Domain) 란 ?

지식이나 영향력, 또는 활동의 영역으로 프로그래밍 관점에서 문제 영역을 해결하기 위해 설계된 어떤 소프트웨어 프로그램에 대한 기능성을 정의하는 영역이다.

도메인 전문가 (Domain expert) 란 ?

소프트웨어 프로젝트에서 자신의 활동 범위가 소프트웨어 개발이 아니라 애플리케이션 도메인인 구성원. 도메인 전문가는 단지 불특정 다수의 소프트웨어 사용자가 아니라 주제 영역에 관해 깊이 있는 지식을 갖추고 있다.

이 외에도 많은 중요한 용어들이 있지만 책을 읽으며 직접 습득하는 것을 권장한다.

책의 목표

• 핵심 도메인과 도메인 논리 프로젝트에 초점을 두며 도메인 모델에 기반한 디자인을 목표로 한다.
• 특정 도메인의 개념적 모델을 개선하기 위해 기술 전문가와 도메인 전문가 사이의 창의적인 협력을 목표로 한다.
• 설계와 관련된 의사결정을 내리는 데 기반이 되는 틀과 도메인 설계에 대해 논의할 때 사용되는 기술적인 어휘를 제공한다.
• 복잡한 도메인에 직면한 소프트웨어 개발팀은 도메인 주도 설계에 체계적으로 접근하는 데 이 틀을 활용할 수 있을 것이다.

스터디 방식

Reference Java-Bom

자바봄이라는 블로그를 참고하여 스터디 방식을 정하고 진행했다.

아래는 우리가 정한 룰이다.

1. 일주일에 한 번씩 스터디 시간을 한 시간 정도 갖는다.
   1) 깃헙 이슈에 올라온 질의 응답을 중점으로 스터디 리더가 진행한다.
   2) 리더는 해당 시간에 질의 응답 외에도 우리가 적용할 수 있을 법한 주제와 토론할 주제들을 미리 준비한다.
2. 한 주 동안 1 ~ 2 챕터 (또는 3 챕터) 정도의 분량을 정하고 해당 주차의 스터디 리더를 정한다.
3. 서로의 방식대로 책을 읽은 다음 궁금한 점이 있으면 깃헙에 이슈로 올린다. (질문은 최대한 토요일 전까지 올린다.)
4. 스터디 리더는 이슈에 올라온 질문에 성실히 답글을 달며 해당 스터디 시간에 스터디를 주도한다.

이 방법을 책을 모두 읽을 동안 반복한다.

생각보다 스터디 속도를 내기 힘들었고 처음의 열정을 마지막까지 유지하는 것은 정말 힘들었다.

스터디를 통해 얻은 점

이전의 나는 개발을 할 때 있어 어떻게든 기한 안에 돌아가는 기능 개발, 로직과 알고리즘 등에 집중했었다.
DDD 를 알고 난 뒤는 개발도 물론 중요하지만 설계가 얼마나 중요한지 깨닫게 되었고 설계에 좀 더 많은 시간을 투자하며 더 나은 설계를 위해 노력하게 되었다. 그리고 설계를 바탕으로 깔끔하고 가독성이 좋은 구조란 무엇인가에 고민을 하면서 개발에 들어갈 수 있게 되었다. (물론, 아직 멀었지만... 시도를 하게 된 것이 의미있다고 생각한다.)

내 개발 진로를 아키텍트로 관심을 두게 되었다. 예전에 코더와 개발자, 아키텍트에 대해 누군가 정의해 둔 글을 읽은 적이 있었는데 그 당시에는 그냥 그렇구나 하고 넘겼지만 책을 읽고나니 소프트웨어 아키텍트에 관심이 생겼고 개발 지식을 쌓아 좋은 아키텍트로 성장하고 싶다는 새로운 목표를 세울 수 있게 되었다. 소프트웨어 아키텍트란

팀내에서 공통적으로 부를 수 있는 단어가 생겼다. 함께 공부하고 같은 것을 공부하다보니 공통적으로 사용하는 단어가 생기고 좀 더 의사소통이 수월해 졌다. 좀 더 내가 모르는 부분이나 부족한 부분을 잘 물어볼 수 있게 되었고 회사 소프트웨어에 대해서 구조적으로 더 잘 이해가 되는 듯 하다.

위기

스터디를 진행하면서 나에게 총 세 번의 위기가 왔다.

1. 첫번째 : 모르는 용어와 복잡하고 어려운 예시의 연속
2. 두번째 : 예시가 조금 익숙해지니 크몽에 적용해 보려 했다가 실패의 연속
3. 세번째 : 매일 공부해야 하는 부담감, 뒤로 갈수록 점점 많아지는 양과 난이도에서 직면해 버린 번아웃

사실 세 번째 위기는 아직 현재 진행형이다. 회사 일이 끝나면 자바와 DDD 를 공부했었는데 이게 몇 달 지속하려니 너무 힘들었다.
스터디 처음의 열정을 마지막까지 끌고 가는 것이 생각보다 많은 에너지를 소모했고 에너지가 고갈되자 번아웃이 찾아왔다.
중간중간 업무양도 늘어나 더 빨리 소진된 것 같다.

다음 스터디를 위한 다짐

• 처음의 열정을 끝까지 끌고 가는 것은 애초에 불가능하다. 적당히 불태우고 꺼뜨리지 말자.
• 오 이거 좋은데 ? 싶은걸 시도해 보는 것은 좋으나 실패를 두려워하지 말자. (시도에 의의를 두자 !)
• 공부하는 것이 뒤로 갈수록 힘들었는데 한 번에 하려 하지말고 매일 조금씩 꾸준히 공부하자.
• 중간 중간 블로깅 시도했다가 포기했던 주제들이 몇 개 있는데 (정리하다 양이 많아지고 귀찮아져서 미뤘다..) 짧게라도 꾸준히 정리하는 습관을 가지자.

어렵고도 힘들었던 스터디가 끝이 났다.
물론 이 뒤로도 쭉 스터디 모임을 가지고 새로운 주제로 스터디를 진행하기로 했다.

개인적인 사정 + 회사 업무 가중 + 늘어나는 스터디양 으로 에너지가 고갈되어 번아웃이 와버렸지만 ..ㅎㅎ

재충전의 시간을 가지고 힘내서 다음 스터디를 진행해야지 오늘의 다짐은 꼭꼭 잊지 말아야겠다.