6월 마지막 주 주말, 클린아키텍처 공부

벌서 6월의 마지막 주말이다. 6월달은 퇴사하고나서 첫 달인데, 정말 순식간에 지난것같다. 퇴사를 하고 난 뒤, 그간 받아오던 사수로 인한 스트레스로 부터 해방되면서, 정말 힐링을 많이 한 것 같다. 하고싶던 공부 를 실컷 할 수 있다는 것이 너무 행복하다. 특히 잘못이라고 인지한 부분에 대하여, 이를 해결하고 지나가는 이 부분이 가장 내 마음을 편안하게 해주는 것 같다. 안되는 이유만 찾던 그곳에서 벗어나, 문제를 인식하고, 해결하는 과정이 너무 즐겁다. 좀 더 정확하게 이야기한다면, 힘들지만 즐겁다.

---

---

6월동안 나는 무엇을 했는가?

 

6월 한달 동안 정말 많은(?)일이 있었다. 퇴사, 예비군, 프로젝트, 공부로 가득한 6월이었다. 그 중 가장 기억에 남는 일을 꼽아본다면, 단언코 프로젝트(신발 주문 시스템)을 꼽을 것이다.

 

GitHub - KEEMSY/shoes-ordering-system: shoes-ordering-system

 

신발 주문 시스템은 지난 회사를 다니면서 독서 및 강의를 통해 공부한 내용을 적용하여 만들어본 프로젝트이다. 주제(도메인)선정에서부터, 아키텍처 및 도메인 설계 뿐만아니라, 이전 회사에서 해보고 싶던 내용(문서화, kafka 등)을 직접 적용해 보면서 나에게 많은 배움을 선사해주고있다.

 

특히, 내가 가장 중요하게 생각하는 가치인 "쉽게 작성할 수 있는 코드 보다는, 확장 가능하고 가독성 높은 코드" 에 대하여 내 스스로 좀 더 고민하고, 이 생각을 확장 할 수 있게 되었다는 생각을 하게 되어 기쁘다. 과거에는 코드레벨에서의 고민만을 핵심으로 생각했다면, 이제는 코드를 넘어 아키텍처까지 이를 확장하게 되었다.

 

코드를 보는 것 만으로도 어떤 아키텍처인지 확인할 수 있다면 좋지 않을까?

확장 가능하고 가독성 높은 코드 작성을 목표로하면서 특히 나는 가독성에 대한 부분에 큰 관심을 갖고있다. 가독성을 통해 얻을 수 있는 부분이 업무를 진행하면서 가장 크게 도움이 될 것이라고 생각했기 때문이다. 하지만 코드적인 부분으로는 해결할 수 없는 문제가 존재했다.

 

아키텍처는 코드에 직접적으로 매핑될 수 없는 추상적인 개념이다. 이는 아키텍처-코드 갭(architecture-code gap) 혹은 모델-코드 갭(model-code gap)으로 불린다. 반대로 생각해보면, 코드 또한 아키텍처에 직접적으로 매핑이 될 수 없다. 그리고 이는 내가 집중하고 있던 (가독성 있는) 코드의 한계점이라고 생각한다.

 

아무리 가독성있는 코드를 작성하더라도, 아키텍처 혹은 패키지 구조가 엉망이라면?(코드는 엉망까지는아니라고 가정..한다..) 확장가능한 코드라고 할 수 있을까? 이 생각을 통해, 클린아키텍처(Ports and Adapters)에 대해 공부하고, 내 생각을 확장하게되는 시발점이 되었다.

 

---

클린 아키텍처 의 적용

 

본래의 신발 주문 시스템은 클린아키텍처를 적용한 생각을 하지 않았다. 프로젝트의 목표는 도메인주도설계(DDD)를 통해, 도메인을 식별하고 각각의 도메인 서비스의 경계(바운디드 컨텍스트)를 분명하게하는 것이다. 그리고  추후 MSA로의 고도화 과정에서 서비스를 원할하게 분리, 관리하는 것 이었다.

 

 왜 나는 도메인 주도 설계를 하고 싶었을까?  내가 담당했던 프로젝트의 불편했던 유지 관리 경험 때문이다. 당시 나는 시스템을 분석을 틈틈히 하고, 신규 기능 개발 및 개선이 주된 업무였다. 그리고 업무진행 간 큰 불편함을 느꼈다. 불분명한 도메인 경계는  좋게 말하면, 만능의 모듈을, 나쁘게말하면 짬뽕 잡탕 처치 곤란 모듈을 만들어냈다. 이 뿐만 아니다. 개발 요청이 들어왔을 때, 사업적인 부분(비즈니스)에 관한 부분을 추가(혹은 수정)하는데 있어 많이 힘들었다. 이에 대한 원인으로 나는 기술적으로 프로젝트가 개발되었기 때문이라 생각한다. 개발은 기술적인 관점이 중심이 아니라 비즈니스 중심의 개발이 되어야하는데말이다.(비즈니스가 있어야 개발이있다!)

 

그래서 나는 불분명한 도메인 경계로인한 관리의 불편함을 극복하고, 프로젝트를 기술관점이 아닌 비즈니스 관점으로 접근해보고자 도메인 주도 설계를 프로젝트에 적용해보고 싶었다.

 

하지만 이전 담당했던 프로젝트는 내가 분석한 원인(불분명한 도메인경계) 뿐만아니라 아키텍처적인 문제도 존재했다. 아키텍처는 계층형 아키텍처(MVC) 였다. 계층형 아키텍처는 장점과 단점이 분명하다. 장점으로는 간단하고 빠르게 프로젝트를 개발할 수 있다는 것, 나눠진 계층을 통해 관심사를 분리할 수 있다는 것이다. 하지만 단점으로 관심사를 분리한 계층을 잘못 사용할 수 있다는 것, 도메인(비즈니스)가 영속성 계층에 의존한다는 것이다. 이는 가장 큰 단점으로 생각한다. 왜냐하면 도메인이 변경될 이유가 한가지가 아님을 의미하기 때문이다. 그래서 나는 고민이었다. 아키텍처적인 문제를 어떻게 해결해야할까.. 하는 고민으로 말이다.

 

그러다 문득, 과거 MSA 프로젝트 강의를 수강하면서 들었던 클린아키텍처(Ports and Adapters) 가 생각났다. 내가 기억하고 있던 강의에서의 클린아키텍처는 도메인주도설계와 핵심 개념이 동일한다는 것이었다. 하지만 나는 해당 내용을 깊게 생각해본 적이 없었다. 단지 클린아키텍처는 경계가 분명하다. 이게 전부였다.

 

그럼에도 불구하고 나는 어차피 공부한 것을 적용해보려는거잖아? 하는 생각에, 클린 아키텍처(Ports and Adapters) 를 적용하기로 맘먹었다. 그리고 나는 클린 아키텍처를 공부하기 시작했다.

 

이와 관련한 이야기는 Member 도메인 개발을 마치며, 정리한 기록에 존재한다.

Member 도메인 완료, 느낀점

 

클린아키텍처(Ports and Adapters)를 적용한 Member 도메인 개발 후,  만들면서 배우는 클린 아키텍처를 통해 클린 아키텍처(Ports and Adapters) 에 대한 좀 더 깊은 고민과 사용방법에 알게되는 것 같다. 매일 꾸준하게 읽고 내용을 곱씹어보면서, Member 도메인 개발과 비교하여, 개선점들을 파악해 나가고 있다.

 

Member 도메인의 의존성 관계도, 이를 통해 내 프로젝트 구조를 좀 더 쉽게 파악할 수 있지 않을까?

 

책을 공부하면서, 새롭게 알게되고 얻어가는 정보에는 클린아키텍처에 대한 부분 뿐만아니라, 내가 설계한 프로젝트에 대한 효율적인 설명 방법 또한 많이 배울 수 있었다. 모두에게 적용되는 정답은 아니겠지만, 프로젝트(혹은 개발한 내용)를 다른 사람에게 더 쉽게 설명할 수 있을까? 에 대한 고민의 답을 알아가는 것 같다 기쁘다.

 

PR 및 피드백을 통해 프로젝트 구조 및 패키지에 대한 설명이 부족함을 인지하게 되었다.

 

 

---

클린아키텍처 공부

 

자투리시간에는 다른 책들을 보고, 메인으로 만들면서 배우는 클린아키텍처 를 보고있다. 자투리시간은 매일 10분에서 시작해서 길게는 30분, 메인으로 보는 책은 한시간씩 보고 있다. 다른 개발자들과 이야기를 할 수 없는(?) 나로써는 정말 최고의 소통 수단이 책인 것 같다.

 

특히 이 만들면서 배우는 클린 아키텍처 는 은 추천사에도 적혀있듯이, 유연하고 유지보수가 용이한 아키텍처를 구축하는 방법이 궁금하다면, 아키텍처를 어떻게 개선할지, 도메인 중심의 개발을 위해 필요한 아키텍처를 어떻게 구현할지 알지 못한다면, 도메인 주도 설계를 지원할 수 있는 아키텍처의 모습이나 클린아키텍처의 실체가 궁금하다면 이 책을 읽으라고 추천한다. 그리고 나는 이 책을 읽으면서, 언급한 부분들을 고민하고 공부하고 있다.

 

책을 보며 내 생각을 같이 덧붙여 기록하고 있다.

 

책을 보면서 과거 순간순간 들었던 기억들이 많이 떠올랐다. 원인은 기억이 나지 않지만, 불편함 만 기억하던 그 원인을 책을 공부하면서 알 수 있었다.

 

클린아키텍처의 모습 및 원칙

때마침 클린아키텍처를 적용하여 개발한 Member 를 바탕으로 책의 내용과 내가 알고 있는 것을 많이 비교하며, 공부하고있다. 기본적인 핵심 개념은 동일(당연하다.)하나, 약간의 차이가 조금씩 존재했다. 지금 기억에 남는 차이점은 패키지 구조이다.

 

신발 주문 시스템의 패키지 구조는 Controller(책의 웹어댑터계층), DataAccess(책의 영속성계층), Domain(책의 도메인계층), Messaging 이다.

 

내 패키지 구조는 크게 Controller, DataAccess, Domain, Messaging 으로 구성된다.

 

이 중 Messaging 은 내가 이벤트발행을 위해 추가한 패키지이므로 나머지를 비교해보면, 책에서 소개하는 패키지 구조와는 약간의 차이가 존재한다. 패키지 구조가 다를 수 있는거아냐? 하는 생각을 할 수 있지만, 클린아키텍처를 사용하는 목적에는 아키텍처적으로 표현력 있는 패키지 구조를 갖는 것 또한 포함되므로 비교하고 더 나은 방법을 적용하는 것이 반드시 필요하다고 생각한다.

 

책의 패키지 구조는 adapter, domain, application 계층으로 나뉜다. 내가 구성한 패지키 구조인 Controller, DataAccess, Domain 와는 유사한듯 다르다.

 

먼저 Application 패키지는  도메인 계층에서 Core 부분(책에서의 Domain)과, Application(책에서의 Application)으로 포함시키면서 차이가 존재한다. 그렇다면 어떤 것이 표현력 측면에서 더 좋은 패키지 구조일까?

 

Application 패키지의 목적을 생각해볼 때,내가 설계한 패키지 구조가 더 표현력이 좋다고 생각한다. Application 패키지의 목적은 유스케이스를 구현하는 것이다. 이는 Application 에서는 도메인로직(=비즈니스로직)을 사용함을 의미한다. 뿐만아니라, 외부 요소인 영속성계층(JPA)의 구현체를 사용한다. 즉, 도메인과 관련된 로직들이라 나는 판단하였고, 해당 패키지를 Domain 패키지 구조 내에 위치시키는 것이 더 표현력이 있다고 생각했다. 따라서, 나는 영속성계층의 구현체를 모아두는 DataAccess 패키지를 만들고, Application을 Domain 패키지 안에 생성하였다.

 

하지만 책의 Adapter 패키지를 생각해보면, 책의 패키지 구조가 훨씬 표현력이 좋다고 생각이 든다. Adapter 패키지 내에는 in, out 이 존재하며, in 에는 Web(나의 Controller) 계층이, out 에는 영속성 계층(나의 DataAcceess)이 존재한다.

 

내가 구축한 패키지의 구조보다 책의 패키지 구조가 더 좋다생각한 이유는, Adapter의 대한 일반적인 생각때문이다. 클린아키텍처(Ports and Adapters)에 대한 지식이 전무하다는 전재하에, Adapter를 생각한다면, 나는 Mapper인가? 를 생각할 것이다. 하지만 패키지를 보면 Adapter 와 Mapper 패키지가 함께 존재한다. 이는 혼동을 줄 수 있을 것이라고 생각한다. 그래서 나는 이 구조가 최적이 아니라고 생각했다. (하지만, 개선책을 어떻게 생각하고 찾아볼지 몰랐다..)  책을 읽으면서, Adapter 를 최상위 패키지로, 내부 패키지로 in 과 out 으로 나누면서 이 내부에서 계층을 나누는 것이 더 이해하기 쉬운 구조가 될 수 있다는 생각을 하게 되었다.

 

그래서 프로젝트 패키지 구조를 개선한다면? "Adapter 패키지 생성, 하위 패키지 Controller, DataAccess 위치, DataAccess의 하위패키지 중 하나인 Adapter 패키지는 삭제" 될 것 같다. 하지만 다음 도메인 개발이 개발 완료되었을 때, 비교를 통해 어느 패키지 구조가 더 표현력이 훌륭한지 이야기를 나눠보고자 하기 위해 Member 에는 적용을하지 않을것이다. (어서빨리 다음 도메인 개발해야겠다.)

 

---

6월, 한달이일을 할 때보다 더 빠르게 지나간것같다. 일을 할 때보다 더 많은 것을 배우고 성장하는 느낌이다. 하지만, 원래 내가 세운 계획하고는 많이 틀어져서 조금 불안하다.. 어서빨리 프로젝트를 잘 마무리하고 정리하고서, 다른 많은 개발자들과 이 이야기(혹은 개발과 관련된 이야기)를 나누고싶다. 더 성장하고싶다. 답이 없지만 답을 찾고싶다. 힘들지만 행복하다. 얼마 남지 않은 6월, 후회없이 잘 보낼 수 있도록 잘 마무리 하자! 아좌좌