알고리즘 문제풀이, 웹계층 테스트 에러 해결?, 도메인주도설계로 시작하는 마이크로서비스 개발 독서

어제는 이제 여름 한정, 여자친구와 주중에 데이트를하고, 주말에는 공부를 하기로 하여, 오전에 독서와 문제를 풀이하고서 일탈을 했다. 좋아하는 신발들도 잔뜩 보고, 또 교보문고에서 수 많은 재밌는 책들도 보았다. (진짜 눈돌아가서 다 사서 집에서 읽어보고 싶었다..) 서서 한시간 반을 넘게 보다가 다리가 아파서 잠시 스타벅스에서 쉬다가 집에가는데, 그 잠깐 쉬었다고 다시 책에 눈돌아가서 혼났다..

 

진짜 여기있는거 다 집에가져가서 보고싶다.. 어서 빨리 돈벌어야겠다.. 책사려면...

 

무튼 오늘 하루는 정말 쾌적한 환경(에어컨 빵빵)에서 즐겁게(?) 고민과 고민을 했다. 오전에는 도메인 주도 설계로 시작하는 마이크로 서비스 개발 책을 읽었다. 기존에는 책의 순서 대로(외부 아키텍처 부분)에서부터 보고 있었다. 그런데 문득 지금 이부분을 보는 것보다는 내부 아키텍처 부분을 보는 것이 나에게 좀 더 도움이 될 것 같다는 생각에 해당 부분을 건너 뛰고 내부 아키텍처 부분을 독서했다.

 

---

도메인주도설계로 시작하는 마이크로서비스 개발: 비즈니스 로직은 어디에?

 

(재미 없는 책은 없지만) 이 책은 정말 재밌다. 현재 관심이 있고 고민이 되는 부분에 대해서 주제로 다루기 때문인것도 있지만, 만약 내가 지금 이 주제에 관심이 없었어도, 이 책을 보면 관심이 생길 것 같은 내용들이 가득하기 때문이다.

 

나는 코드를 공부하면서 코드에는 패턴과 규칙(원칙)이 존재한다는 것을 알게되었다. 그리고 이의 연장선으로 객체에 대하여(객체지향) -> 모듈화 -> 아키텍처의 공부의 수순을 밟게 되었다. 그런데 왜 나는 코드를 공부하게 되었을까?

 

나는 지난 회사에서 프로젝트를 담당하면서 가장 먼저, 그리고 가장 많이 한것이 바로 코드 분석이다. 비즈니스 규칙(로직)이 녹아져있는 거대한 레거시를 이해하고 분석하면서 올바른 곳에 신규 기능을 개발하고, 기존 기능을 유지보수하는 것이 내 책임이었다.

 

오래되고(?) 거대한 레거시는 토이 프로젝트 정도만 경험했던 내겐 너무나도 어려웠다. 당시 처음 보는 PHP 언어로 작성되어 더 그렇게 다가 온 것 일 수도 있지만, 다 아는 코드로 작성되었는데 이해하기 힘들었다.(마치 자국어인데 외국어같았다. 한글인데 이게 무슨말이야?하는 그런..)

 

반복해서 보고 분석하고 정리하면서 나는 코드 작성에 패턴이 존재한다는 사실을 알게되었다. 그래서 나는 패턴을 공부해야겠다! 하고서 패턴을 공부했다. 이렇게보면 나는 코드 작성의 패턴을 공부하기 위해 코드를 공부하게 된걸까? 이는 맞으면서 틀린말이다.

 

지금 돌이켜볼 때,내가 코드를 공부하게 된 이유는 업무를 하기 위함이다. 내 업무는 레거시를 이해하고 분석하면서 올바른 곳에 신규 기능을 개발하고, 기존 기능을 유지보수하는 것 이다. 그리고 나는 업무를 위해 나는 코드를 공부했다. 더 나아가 패턴을 공부했고, 아키텍처를 공부하게 되었다. 왜 이렇게 생각의 흐름과 공부의 흐름이 이어지게 되었을까?(이야기를 한다면 무진장 길다.. 그리고 이이야기의 끝은 현재의 고민과 모습이고, 중간에는 퇴사가 존재한다.)

 

내가 이런 공부의 흐름을 갖게된 것은 레거시를 이해하기 어려웠기 때문이라 생각한다. 그렇다면 내가 거대한 레거시를 이해하고 분석하기 어려웠을까? 여럿 원인이 존재하지만, 가장 큰 원인은 이곳 저곳에 일관성 없이 퍼진 비즈니스 로직 때문이라 생각한다.

 

 

---

이곳 저곳 퍼진 비즈니스로직(규칙)

 

이곳 저곳 퍼진 비즈니스로직(규칙) 은 왜 코드를 이해하고 분석하기 어렵게 만들까? 이에 대한 생각 전에, 비즈니스 로직에 대하여 먼저 이야기를 해보자.

 

비즈니스 로직이란, 비즈니스 영역의 업무규칙(Rule), 개념(Concept) 을 표현하는 용어이다.

 

우리 개발자는 문제영역의 비즈니스로직을 분석 및 이해하고 프로그래밍 언어로 기능(작동)하도록 만들며, 이해하기 쉽고, 반경하기 쉬운 시스템을 만들어야한다. 다시, 이곳저곳 퍼진 비즈니스로직은 이를 어렵게한다할 수 있을까? 나는 그렇다고 생각한다.

 

전통적으로 애플리케이션의 아키텍처는 10의 9은 MVC 패턴(계층형 아키텍처)를 따른다. 그리고 내가 담당했던 프로젝트의 내부 아키텍처구조는 MVC기반의 프로젝트였다. 계층형 아키텍처를 이야기한다면, 흔히 3계층(프리젠테이션 계층, 비즈니스(=도메인) 계층(=서비스계층), 데이터계층(=영속성계층))으로 이뤄진다. 중간에 다른 계층이 추가되기도 하지만, 일반적으로는 3계층이 일반적이다.

 

• 프리젠테이션 계층: 화면 표현 및 전환 처리를 담당한다.
• 비즈니스 계층(도메인 계층): 비즈니스 개념, 규칙이 존재하며, 흐름을 제어한다.
• 데이터 계층(영속성 계층: 데이터를 처리한다.

이렇게 나눠진 계층은 계층별 분명한 관심사가 정해져 있다는 것을 의미한다. 즉, 계층별로 관심사가 분리되어있음을 의미하며, 정해진 역할이 존재하고 경계가 분명함을 의미한다.

 

이제 다시 이곳 저곳 퍼진 비즈니스 규칙을 생각해본다면? 이는 관심사가 섞였고, 분명했던 책임이 불분명해지고, 경계가 모호해짐을 의미한다. 그리고 이것은 시스템을 이해하기 어렵고, 변경하기 어려운 시스템으로 만든다. 그래서 나는 거대한 레거시를 이해하기 더 어려웠던 것이다.

 

그렇다면 과거 레거시 프로젝트에서 비즈니스 규칙은 어느곳에 있어야 올바른 것일까? 나는 도메인계층(서비스계층)에서 비즈니스 규칙을 다워야한다고 생각한다. 하지만 그러기에 쉽지않다. 기본적으로 계층형 아키텍처는 데이터베이스 중심의 아키텍처이기에 불가능하다. (사실 가능하긴하지만, 현실적으로 불가능하다고 봐야한다..)

 

모든 업무 로직이 SQL 문에 들어있는 경우가 대부분이며, 비즈니스 로직을 처리하는 코드는 기껏해봐야 10줄 미만이 흔할 것이다.(일단 그 프로젝트는 그랬다.)  그리고 책에서는 이에 대하여 뻐를 강하게 때리는(?) "이러한 구조에서 일반적으로 비즈니스 로직은 서비스에 존재해야한다고 말하지만 서비스에 존재하게 될 로직은 흐름제어 로직밖에 없다." 

• 간단한 처리 로직의 경우에는 편리하지만, 로직이 복잡해질수록 점점 복잡성을 제어할 수 없게된다.
• 업무 개념이 특정 저장 기술인 관계형 데이터베이스 테이블로 표현되고 업무가 복잡해질수록 업무 규칙이 SQL과 섞여 표현된다.
• 저장 기술과 비즈니스 로직이 끈끈하게 붙어있게 된다.(기술적 관심사인 데이터베이스의 변경, 업그레이드가 힘들어진다.)

 

그렇다면 비즈니스 규칙을 제대로 관리하기 위해서는 지금의 아키텍처 구조에서는 불가능하다는 결론에 도달하게 된다. 그럼 어떻게 해야하는데? 에 도달한 사람이 있다면, 이제 이 책을 추천할 때이다. 도메인주도설계와, 클린아키텍처를 공부해보면 좋지않을까?! 그리고 공부하면서 생기는 고민과 생각을 같이 공유할 수 있었으면 좋겠다.ㅎㅎㅎ

 

---

웹계층 테스트 에러 해결?

 

오늘 4시간 넘게 삽질의 결과물로 드디어 지난 웹 계층 테스트 에러의 원인을 파악했다.

 

지난 TIL 참고

웹 계층 테스트, 알고리즘 문제풀이

지난 TIL의 일부분, 에러를 해결(?)하고 다음으로 직면한 에러.

 

나는 trackProductResponse 가 null 인 이유에 대하여, 분명 어디인가 Mocking 이 되었을 것이라고 판단하였다. 그래서 나는 먼저 웹 계층 테스트와 관련한 어노테이션을 먼저 중점적으로 다시 찾아보았다. 하지만 해당부분은 문제가 없었다. 아니 오히려 문제가 되는것이 더 문제라고 생각될 정도였다.

 

나는 원초적인 방법이며, 가장 확실한 print 를 찍어보기로 했다.

 

기본적인 진입점에서부터, trackProduct 에 모두 print 문을 작성하였다.

해당 결과 값, productQueryService 에 진입하지 않았다.

 

나는 대혼돈이였다. 아니... 뭐야 이거... 왜 진입을 못하지..? bean으로 등록되어있고, 해당 객체라는데.. 뭐야이거... 나는 애플리케이션을 키고 포스트맨을 통에 API를 사용해보았다.

 

포스트맨을 통해 요청할 경우

이렇게 나와야하는데 뭐지? 정말 의문이었다. 하지만 한가지 사실은 확실했다. 분명하게 Mocking 이 되었다는 것이다. 그런데 가장 큰문제는 이 Mocking 이 어디서 됬는지 모른다는 것이다.

 

나는 GPT에게 물어봤다. 지금 테스트 코드와, 테스트대사의 코드, 에러코드를 함께 하고 질문했다.

 

 

 

아.. 이게 아닌데.. 이를 어떻게 수정해야할지 나는 한참을 책상에 앉아 고민했다. 수많은 다른 테스트를 찾아보고, 또 적용해보고.. 해결이 되지 않아 고민하고... 그러다 지피티에게 그냥 내 맘을 이야기했다.

 

왜 ProductQueryController 에서 사용하는 productQueryService 가 Mocking 이 되는거야?!!

 

이것저것 다해보다가 이렇게 물어봤는데, 드디어 원인을 알 수 있었다.

 

GPT의 대답

요약을 하자면, 내가 ProductQueryService 를 Mocking 하고 있었다는 것이다. 이 답변을 보고서, 아주 당황했다... 아니... 내가 Mocking 을 해놓고서, 어디서 Mocking 한지 몰랐단 말이야..?

 

테스트의 상단부분, 나는 ProductQueryService 를 MockBean 으로 등록했다.

나는 ProductQueryService 를 다음의 이유들로 MockBean 으로 등록했다.

• ProductQueryService 는 애플리케이션 계층으로, 웹 계층에서 다른 계층의 테스트는 불필요하다 생각했다.
• 지금 테스트의 데이터를 제공할 때, 제공해주기위해 Mocking 한다.

 

하지만 나는 이것이 Cotroller 내의 productQueryService 까지 영향을 줄 것이라 생각하지 못했다.. 지금 생각해보면, Bean 을 등록하는 것은 컨테이너로 관리되고 사용되는 거니깐.. 당연한것이다..

 

그리고 해당 부분을 제거하고, 내가 원하는에러 모습을 볼 수 있었다.

내가 원하는 에러가 바로 이거야 !!

 

이제 저 노랑색을 초록색으로 만들어보자! 그리고 어서 이 Product 를 끝마치고, 대망의 Order 로 넘어가자 !!

---

 

요즘 꾸준하게 코틀린을 통해 문제풀이를 하고 있다. 기본적인 활용방법을 익히기 위해 기본적인 문제들부터 풀고있는데, 요즘에 스스로에 대한 반성을 많이 하게 된다. 기본적인 내 마음가짐에서부터, 문제해결능력에 대한 부분까지.. 반성을 많이 하게 된다. 그러다 문득 유튜브의 한 영상을 보게되었다.

 

 

클린 코딩을 하지만, 구현을 못하는 개발자.. 난...가..? 하는 생각이들었다. 물론 알고리즘 문제가 비즈니스 요구사항을 구현하는것과 완전일치하는 것은 아니지만, 그래도 그 구현에 알고리즘 문제풀이의 경험이 사용된다고 생각하기에.. 이런 저런 생각을 많이하면서 보게 되었다.

 

해당 영상을 보고서 느낀점은, 내가 고민하고 있는 아키텍처적인 고민은 모든 구현을 할줄 안다는 전제가 되어야한다는 것 이다. 하지만 이에 100% 동의하는 것은 아니다. 감히 신입개발자라고 봐도 무방한 10개월 경험의 주니어 개발자이지만, 이야기해주시는 부분들이, 결국 일단 무조건 만들어야해! 하는 부분에서 비롯된 것이지 않을까 싶다.

 

개발할 때 고민거리가 계속 생긴다. 는 것에 대하여, 어떤 고민인지 알 수 없지만, 비즈니스 요구사항이라는 전제하에, 잘못된 구조 때문에, 해당 부분에 대한 고민의 부족과 그에 대한 답을 찾는 과정의 부재 때문에 생긴것 아닐까? 하는 생각이 들었다. (감히)근본적인 고민과 문제 인식이 잘못된 것은 아닐까? 하는 생각이다.

 

과제적인 부분에서 이야기를 언급해주셨는데, 클린 아키텍처, 클린 코드를 기반으로 작성했지만, 요구사항 구현을 완벽하게 하지 못한 지원자와 일단 꾸역꾸역 개발을 완료한 사람 이 있다면, 둘다 뽑지 않거나 후자를 선택한다는 이야기를 하셨다.

 

내가 전자의 사람이라서가 아니라, 정말 내가 면접관이 된다고 상상을하고 과제를 확인할 때, 나는 전자를 선택할 것같은데.. 개인적으로 의외였다. 과연 이분들이 애플리케이션의 구조나 설계에 신경쓰지않고 기능 구현에만 집중한 프로젝트에 대한 경험이 없으신분들은 아닐텐데.. 경험해보셨다면.. 상당히 힘들으셨을텐데.. 하는 생각이 들었다. 아니면 이를 극복해내는 노하우가 있는걸까? 궁금하다.

 

소프트웨어의 가치는 행위가치와 구조가치를 이야기할 수 있는데, 개인적으로는 아직 구조가치에 대한 잠재성(?)과 중요성을 크게 생각하지 않하는 것같다.

• 행위 가치: 소프트웨어의 기능
• 구조가치: 소프트웨어 아키텍처

 

하지만 이 생각들이 내가 맞고 저사람이 틀린거야! 하는게 아니다. 오히려 정답의 가능성은 내쪽보다는 저쪽이 훨씬 높다. 그렇지만 반대대는 생각을 가진 사람들을 만났기에, 영상에서는 이야기하지 못한 더 깊은 이야기들을 나눠보고싶다. 잠깐 N의 머리로 상상해봤는데 정말 재밌을 것같다. 내가 생각하지 못한 부분을 얼마나 더 알 수 있을까?

 

메일이나... 댓글 한번 남겨볼까....