PR 작성, 피드백, 개선

오늘은 Member 도메인 작업 이후, PR 작성 및 피드백을 받고, 이를 개선하기 위한 방법을 생각해보았다. 그리고 구매한 책도 와서 재미나게 읽어보았다.

 

책이 예상 도착시간보다 빨리 도착해서 그 시간동안 읽어보았다.

 

책은 생각보다 많이 얇았다. 하지만 앞 부분을 읽어보았는데, 진짜 몇일간 머릿 속에 둥둥 떠다니지만 잡히지 않았던 그런 내용들이 정리가 되어있었다.(정말 내가 말하고 싶던 말들이 적혀있었다.) 이 책은 정말 내게 많은 도움이 될 것 같다. 관련된 내용으로 내가 공부를 하고싶어하기도 했지만, 현재 알고있는(?) 확실하게 알게되는 계기가 될 것같은 느낌이다.

---

만들면서 배우는 클린 아키텍처

 

아직 앞부분 밖에 읽지 못했지만, 정말 짧은 부분임에도 불구하고, 내용이 하나같이 다 챙겨가야할 내용들이라는 생각이 들었다. 진짜 내가 가렵던 부분을 무슨 유도미사일처럼 정확하게 때리고 긁다못해 삭제시켜주는 기분이다.. 특히 계층형 아키텍처의 문제점에 대한 부분에서 그랬다.

 

---

계층형 아키텍처(Layered architecture)

 

흔히들 알고있는 MVC 패턴의 계층형 아키텍처는 전통적인 아키텍처이다. 이는 오랫동안 표준처럼 사용되었고, 실무에서도 많이 선택된 아키텍처이다.(내가 담당했던 프로젝트도 MVC기반의 프로젝트였다.) 하지만 MVC 패턴의 아키텍처는 한계점이 분명하다.

 

첫 코딩 프로젝트를 진행하면서, 먼저 그 한계점을 몸소 경험했다. 팀원들과 역할을 분담하여 작업을 진행하면서, 각기 다른 기능을 개발했음에도 불구하고, 코드 병합 과정에서 충돌로 인한 문제에 개발보다 더 많은 시간과 노력을 했던 기억이 난다. 하지만 당시에는 우리가 경험이 부족해서 역할 분담을 잘못한 것이라고 생각했다. 그리고 지금 다시 생각해본다면, 이는 반은 맞고, 반은 틀렸다.

 

시간이 지나 취업을하고 첫 프로젝트를 진행할 때, 또한 이런 일이 발생했다. 당시 나에게는 사수라는 거대한 벽에 막혀, 주어지는 일만 가능한 상태였다.(주니어는 사수가 주는 것만 받아서 하라나 뭐라나... 그랬다.) 좋게 말하면 사수가 판단하여 영향도가 적은일부터 시작하자이고, 내가 바라본 현실적으로 바라본다면, 자기가 하기 귀찮은 일은 나에게 시켰다.(혹은 자기가 못하는 일; 프론트 작업이라든가.. 디자인도했다..) 이런 상황에서도 나는 기능개발을 진행하면서 사수와 Conflict 가 발생했다. 최대한 자기와 겹치지 않도록 업무를 자기가 분담했음에도, 코드 충돌이 발생한 것이다. 당시 개발건은 소스코드 전체에 영향이 있는 운송사 추가관련한 업무였기에 코드 충돌은 불가피한 사실이었다.

 

하지만 이것은 계층형 아키텍처의 한계점이라고도 이야기할 수 있다. 동시작업이 어려워진다는 것이다. 책에서는 맨먼스 미신의 글을 인용한다.

 

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다. - 프레더릭 P.브룩스-

 

그러하다. 특히 계층형 아키텍처에서는 동시에 여러작업이 이뤄질 수 없다. 정확히는 이뤄질 수 있으나, 더 늦어진다. (혼자서 개발해야한다.) 그래서 나는 이것때문에 사수가 내게 일을 주지 않았던 것이지 않을까 생각을 해본다. 계층형 아키텍처의 한계점은 이뿐만이 아니다. 가장 큰 문제점으로 생각하는 계층형 아키텍처는 데이터베이스 주도 설계를 유도하게된다.

 

계층형 아키텍처의 모습, 종속성이 결국 DB를 향하게 된다.

 

이는 결국 다른 계층이 모두 DB에 의존하게 된다는 것을 의미하게 된다. 이것은 왜 문제일까?  각 계층의 변경할 이유가 늘어난다는 것이다. 각 계층의 변경할 이유가 1개가 아니라는 의미이다. 그럼 변경해야할 이유가 1개가 아니라는 것은 왜 문제일까? 이는 정상 작동 하던 기능이, 다른 기능의 변경으로 인해 잠재적으로 장애가 발생할 수 있음을 의미하기 때문이다. 또한 이것은 SRP(Single Responsibility Principle, 단일 책임 원칙)에 어긋난다. 여기서 끝이 아니다. 우리의 개발의 핵심인 비즈니스에 영향을 준다. 잘 개발해둔 비즈니스 로직이 다른 계층에 의존하게되면서, 갑자기 장애가 발생하여 손실이 발생했다 생각하면, 아주 끔찍하다.

 

도메인은 왕이다!

 

계층형 아키텍처의 단점은 이뿐만이아니다. 더 이야기할 수 있다. 비즈니스로직의 유스케이스를 식별하기 어려워진다. 이는 또 계층을 나눈 목적이 사라지기도 하며, 개발에 있어서 큰 문제가 악이된다. 왜 악이될까? 의존성이 DB 에 있다는 것은, DB에 비즈니스 로직이 녹아들어갈 수 있음을 의미한다.(아닐수도 있지만, 내가 경험상 그렇다. DB 뿐만아니라 Presentation 계층에도 녹아들어있고 난리도 아니였다.) 이게 왜 또 문제를 넘어 악이될까? 해당 프로젝트를 담당하는 다른 개발자는 그걸보고 그렇게 다시 하게된다.(내 사수였던 사람이 그렇게 말하더라) 이건 왜이렇게 되있는걸까요?(잘못됬다고 생각했으나, 내가 모르는 이유가 있을거라 생각해서 물어봤었다.) 하지만 돌아오는 답은 이거 원래부터 이렇게 되어있었다는 말뿐이었다. 자기도 문제라는 것을 안다. 하지만 고치지 않았다.(사실 고치는것까지 바라지도 않았다.) 이것은 문제지만 문제가 되지않는다. 더 큰 문제는 다른 코드가 이렇게 되어있는데(과거에 이랬는데) 나도 하면 안되나? 하는 생각으로 개발을 진행했었다. 또 자기가 한것 아니라고 했지만 커밋히스토리는 거짓말을 하지 않았다.(거짓말은 나쁘다. 책임을 회피하는건 더 나쁘다.) 즉, 쉬운길(악)으로 프로젝트를 더럽힐 가능성이 높다.

 

하지만 계층형 아키텍처가 무조건 나쁜 것만은 아니다. 개발 초기상태에서는 이만한 아키텍처가 없다고 생각한다. 하지만 시간이 지나면서 프로젝트가 커지면 커질수록 점점 아키텍처 또한 진화를 하여야하고, 여기서 계층형 아키텍처는 나쁜 아키텍처가 되는 것이라고 생각한다.

 

나는 이번 책을 보면서 내가 불편했던 계층형 아키텍처의 문제점 및 그 원인에 대해 좀 더 명확하게 알게 된 것 같다. 그리고 클린 아키텍처에 대한 관심과 호기심 또한 더 커지고 공부하고자 하는 열정이 생기게 되었다. 하지만 당연하게 실무에서는 해당 내용을 쉽게 적용할 수 없음을 인지하고 있다. 그럼에도 불구하고 해당 내용을 공부하고싶다. 한번에 바뀔순 없더라도, 조금씩 조금씩 좋은 프로젝트를 만들어가기 위해서는 이러한 좋은 아키텍처에 대한 고민, 유지보수가 좋은 프로젝트를 만들기 위한 고민을 해야하고 또 그 방법을 알아야하기 때문이다.

 

 

---

PR작성

 

드디어 Member 도메인에 대한 PR을 작성했다.(정말 오래걸렸다..) 사실 PR을 계속 혼자서 작성했지만, 스스로 돌이켜보는 리뷰같은 느낌으로 작성했었다.(실무에서 PR을 작성해서, 작업 내용을 정리하고 관리하고 싶었는데 가차없이 까였기에..(PR작성도 하지 못했고, 만드는 것 조차 내가 하지 말라하셨다. 리뷰는 말모..없었다. 아니 없었다.)

 

내 첫 PR, diff가 +6676... 너무 거대하다..

 

아무래도 첫 PR은 너무 거대하게 잘못(?) 한듯 하다. 기본적으로 PR은 작성하는 사람 기준이 아니라, 리뷰하는 사람 기준으로 작성해야한다는 것을 알고 있으면서, 내가 이번 PR 작성은 실패했다.(너무 거대하다..) 그래도 감사하게 리뷰를 진행 해주신 지인분들께 감사의 인사를 전한다.(싸랑해요(하트))

 

이번 PR에서는 내가 작업한 내용을 어떻게하면 잘 전달이 될 수 있을까? 하는 고민을 하면서 작성을 했다. 사실 개발한 기능은 3개뿐(생성, 업데이트, 조회)이라서 기능을 리뷰하기에는 간단하다. 하지만, 아키텍처적인 요소 때문에 계층이 나눠지고, 각 역할에 대해 복잡하게 느껴질 수 있다는 생각이 들었다.

 

PR 내용을 보다 쉽게 이해하기 위해, 작업 내용에 대한 요약과 흐름을 정리했다.

 

간단한 기능이지만 계층이 나뉘고 아키텍처가 일반적으로 경험하는 MVC 패턴의 아키텍처와는 차이가 존재한다. 그래서 각 계층에 대한 설명을 추가적으로 간단하게 요약 정리하였다.

 

각 계층에 대한 (너무)간단한 설명

추가적인 질문이 들어왔으면 좋겠다는 생각(?)에 나름 핵심만 작성했다.(너무 괴씸한가..? 근데 정말 같이 이야기를 해보고 싶다..)

 

내가 3주가 넘도록 고민하면 개발한 내용들이지만, 작성하고 나니 너무 별거 없다는 생각이 들기도 했다.(근데 정말 별거 없다..) 글(문서)로 내 고민과 의도를 잘 녹여내고 싶은데, 이게 정말 어려운것 같다..

 

PR에는 정답이 없지만, 나는 PR을 통해 내가 한 고민을 공유하고, 이에 대한 해결책을 같이 찾아보고 싶어서 Context(회고..?) 를 작성했다.

 

나의 일기라도 봐도무방하다..

이 외에도 리뷰를 통해 앞으로 보완해야 할 부분들을 확인할 수 있었다. 그 중 가장 큰 것은 테스트 부분이었다.

 

이번 프로젝트에서 핵심요소로 클린아키텍처(Ports and Adapters), 도메인주도설계(DDD), 테스트주도개발(TDD) 를 선정했다. 각 요소들은 내 미래 목표를 위해 반드시 연습하고 내것으로 만들어야 하는 부분들로서, 해당 부분에 대한 이야기를 가장 많이 하고 싶었다. 그리고 감사하게도 테스트에 대한 조언을 들을 수 있었다. 

 

리뷰를 요청하며 나눈 이야기 일부분

 

나는 테스트를 Domain-Core 와 Domain-Application 만 작성하였다. 분리된 핵심 계층인 도메인 계층만 테스트하면 되지 않나? 하는 잘못된 생각으로 인해 이런 일이 발생한 것 같다. Handler, helper, mapper 와 같이 특정 관심사를 가진 클래스가 다수 존재한다. 하지만 테스트가 없다.. (이를 사용하는 Application 의 테스트를 통해 검증이 되는 것이라 생각했다...) 그리고 무엇보다, 영속성 계층(DB)에 대한 테스트가 없다.

 

DB 영속성 계층의 경우, Domain-Application Service의 Repository(인터페이스)를 사용하고 이 Repository 를 JPA Repository가 구현하면서 DB 영속성 계층이 형성되며, 영속성 계층이 도메인 계층에 의존하게 된다. 그래서 나는 Domain-Application 을 테스트 하면서 영속성 계층에 대한 테스트는 불필요하다고 생각했었다.(지금 생각해보니, 미친거다..)

 

하지만 이 부분에는 아주 나의 멍청한 생각이라는 것을 알 수 있다. Domain-Application 계층을 테스트 할 때에는 Repository에 대한 구현이 없어 Mocking 을 통해 해당 메서드를 실행할 경우, 원하는 값을 반환할 것이라 설정했었다.

 

작성한 MemberTestConfiguration

 

당시 repository의 구현이 되지 않아 Mocking을 통해 해당 부분을 사용했으면, repository 가 구현되었을 때(Data Access, 영속성 계층)는 해당 부분이 정상적으로 원하는 데이터를 가져오는지 확인을 했었어야 했다. 그런데 그렇지 못했다. 그리고 이 부분은 리뷰를 받기 전까지 내가 문제라고 인지하지 못했었다..

 

역시 리뷰... 짱이다...!