2023 회고 1 - 좋은 개발 방법에 대한 고민 (MSA, DDD)

 

고민의 시작 

요즘 회사가 점점 성장하다 보니 많은 프로젝트들이 쏟아지며 진행되고 있는 중이다. 일정과 개발의 편의를 위해 비즈니스 단위로 프로젝트들이 관리되고 있는데, 점점 많은 프로젝트들이 생기다보니 클라우드 인스턴스와 깃 레포만 점점 많아지고 있는 느낌이 들었다.

 

 

인원은 한정적인데 반해 여러명이 진행한 프로젝트들이 점차 생기다보니 인원 수 보다 레포지토리가 몇배는 많아지고 있다. 

또 여러 프로젝트들에 조금씩 걸쳐있기 때문에, 해당 프로젝트에 대한 전문성도 떨어지고 있어 결과적으로 효율이 떨어진다는 느낌이 들었다. 더군다나 기존 레거시 프로그램도 같이 운영되고 있어 스프링 프레임워크를 안쓰는 프로젝트의 코어를 변경할 필요가 생겼을때는

분석하는데 시간이 더 많이 걸린 경험도 있었다. 옛날에 만들어서 유지보수가 힘든 프로그램이야 점차적으로 새로운 기술스택으로 변경해 나가면 된다고는 하지만, 새로운 프로젝트들을 진행하면서도 명확한 방향성 없이는 곧 누군가의 레거시가 될것 같다는 생각이 들었다. 

 

그래서 조금씩 좀 더 좋은 개발 방식이나 아키텍쳐를 청사진을 정해놓고 느리지만 올바른 길로 가고싶었다.그 전에 먼저 현재 시스템 구조를 생각해 보기로 했다. 현재 구조는 프로젝트 별로 나뉘어 각각 있으면서 서로 간의 통신이 유기적으로 일어난다. 모듈화 된 프로젝트들도 여럿 존재한다. 프로젝트가 새로 생길 시 기존 프로젝트에 추가되는것이 아닌 새로운 프로젝트로 관리된다.

하지만 대부분 하나의 레거시 데이터베이스 데이터 지향적이라 메인 DB 에러 발생 많은 프로젝트에 영향을 준다. 현재 서비스 구조를 생각해봤을때 MSA를 호소하는 모놀리식 아키텍쳐가 아닐까 생각이 들었다. 그나마 모듈형 모놀리식 아키텍쳐에 가장 비슷한것 같다고 생각한다. 

 

하지만 진짜 중요하다고 생각이 들었던것은, 청사진이 없는 아키텍쳐 구조보단 개발 방식이라고 생각이 들었다. 좀 더 효율적으로 진행 할 수 있는 방법이 있을까 고민이 들었다. 비효율적이다 라고 생각했던 부분은 크게 두가지였다. 

 

첫번째로는, 개발자와 기획간의 상상속 설계가 다른 부분이 발생하고 있었다. 그 간극은 생각보다 일을 비효율적으로 만들고 있다는 생각이 들었다. 똑같은 회의에서 서로 다르게 이해함에 따라 구현 후 기획의 의도랑 달라 다시 구현하는 경우도 생겼고, 확장성도 서로 다르게 생각하는 부분이 생겨 개발 공수의 시간도 더 많이 들었다.

 

두번째로는, 산재되어 있는 프로젝트들에 대한 중복 코드였다. 최대한 여러 프로그램들이 하나의 테이블에 접근하는걸 지양하려고는 했지만 업무상 그렇게 되기 힘든 영역들이 존재했다. A프로젝트와 B프로젝트의 메소드들이 대부분 비슷하지만 조금씩 다른 메소드를 처리 할때, 

이런 메소드를 한곳에 몰아두면 리팩토링이나 유지보수 하기에 좋겠다는 생각이 들었다. 또 ACID 속성을 지키기 어려운 경우가 많이 발생 할 수 밖에 없는 구조는 최대한 지양했으면 했다.

 

하지만 막상 또 그래서 어떻게 할껀데? 라고 지금 누군가 물으면 정답을 말할 수도 없다. 모든 상황을 완벽히 타파할만한 은탄환은 동화속에만 나오는 이야기이고, 사실 구조부터 시작해서 기술부채들을 처리할 시간도 많진 않다는걸 너무 잘 안다. 

이런 바쁜 상황속에서는 아키텍쳐 설계를 다시하자고 제안하는건 시간내에 도착해야 하는 열차에서 제동을 거는 일이지만, 그런 상황이 왔을 어떤 방법으로 해야하나 생각하다가 이번의 공부 목적을 정했다. 

 

 

좀 더 좋은 서비스를 만들기 위한 개발 방법과 구조 생각해보기

 

 

이때 여러가지 개발 방법론(TDD,BDD,DDD)에 대해서 찾아본 것 같다. 여기서 가장 잘 맞을 것 같다고 느껴졌던것은 개발방식은 DDD였다. 강의를 듣고 공부해보면서 느낀점은, 단순히 개발 방법의 일종에 맥락에서만 생각했었는데 그 보다 훨씬 거대한 개념이였다. 

어려운 개념을 이해하는데 가장 많이 도움을 받은 것은 조영호님의 "도메인 주도설계의 사실과 오해"라는 글이였다. 

특히 DDD가 단순한 기술적 방법론을 넘어서 실제 도메인 문제를 해결하기 위한 깊은 이해와 협업을 강조한다는 측면에 있어서

내가 개발을 하며 너무 시야를 좁게 보고 있었구나 생각이 들게했다. 

가장 크게 느낀점은, 지금까지 문제 해결에 있어 도메인보다 기술에 대해서만 생각하고, 대부분 기술적으로 해결하려 했다는 생각이 들었다. 

너무나 당연하게 개발은 자연어를 기계어로 "잘" 번역하는 과정인데, 번역에만 치중해서 원래의 핀트를 놓치고 있었던 것 같다. 

 

공부하며 찾아본 DDD의 특징은 아래와 같았다.

 

1. 데이터베이스 지향적인 관점에서 벗어나 해당 도메인에 대한 로직에 좀 더 집중하는것이다. 

 

2. 실제 비즈니스 요구사항을 반영하는 도메인 모델의 창조와 보편적인 유비쿼터스 언어의 활용에 있으며, 이를 통해 소프트웨어 개발의 복잡성을 관리하고 해결하는 데 중점을 둔다. 

 

3. DDD는 단순히 기술적, 기법적 요소에 국한되지 않는다. DDD는 도메인 전문가와 개발자가 함께 팀을 이루어 지식을 탐구하고, 도메인 모델을 창조하는 과정이다.

 

신기하게도, DDD에 대해서 공부할 수록 아리송한 다른 개념들에 대해서도 어느정도 퍼즐이 맞춰지는 기분이였다.

DDD는 도메인 모델은 현실 세계의 복잡한 관계를 객체화 모델링을 통해 표현한다는 점에서 객체지향에 대해서 더 이해하게 되고,  도메인을 "잘" 나누는 방법에 있어어 캡슐화, 상속등의 개념들을 생각함으로써 좀 더 객체지향에 친숙해진다는 생각이 들었다 .

또한 마이크로서비스를 나누는 기준에 있어 도메인은 중요한 기준점이 되는데, MSA와 DDD은 비슷한 개념에서 출발한다는 생각이 들었다.  잘 작성된 DDD의 구조는 명확한 마이크로서비스간의 경계가 아닐까라는 생각이 든다. 

DDD는 2003년에 나온 패턴이지만, 요즘들어 MSA가 점점 각광 받으니 핵심 개념이 맞는 DDD가 주류 패턴이 되어가는 것 같다. 

 

 

이상과 현실

 

 

하지만 이런 장점들이 있어도, 막상 DDD나 MSA를 실 서비스에 적용하기엔 쉽지 않겠다라는 생각이 들었다. 

이러한 장점은 크고 복잡한 프로젝트에 적합하며, 팀의 높은 이해도와 많은 리소스 투자가 수반되어야 되는 점.

그렇게 큰 규모의 프로젝트나 생산성이 없다고 판단 될 경우 그다지 좋은 방법이 아닐것 같다.

출처 : https://yozm.wishket.com/magazine/detail/1813/

 

열심히 많은 리소스를 들여가며 아키텍쳐 구조를 변경했는데 , 막상 트래픽이 생각 보다 없으면 유지보수 시간만 길어 질것 같다는 생각이 들었다. 가장 중요한건 그 상황에 대한 객관적인 판단으로 진단을 하고 시작을 해야될 것 같다. 

 

하지만, 실제로 적용하지 않아도 공부하는것 만으로 좁았던 시야를 좀 더 넓게 볼 수 있게 해준것 같았다. 작년 이맘때쯤 DDD나 MSA구조에 대해서 찾아보고 이해를 잘 못했던 그때와 다르게, 이제는 이해한 부분들을 정리하고 글로 쓸 수 있다는 점에서 나름 만족한다. 

이번 2024년의 목표는 인지가 아닌 학습을 할 수 있는 해가 됐으면 좋겠다.