실무 프로젝트는 도대체 왜 이렇게 디렉토리 뎁스가 깊을까?

결론부터 말하자면 잘 모르겠다.

 

 

 

모르겠다.

 

 

 

이번에 MSA를 시니어 분들의 참여 없이 맡게 되고 진행하면서 기존 프로젝트를 심도 있게 분석하는데, 도저히 알다가도 모르겠다. 어느 정도 이해를 하면서 넘어가다가도 어느 순간 알수가 없다. controller가 있는데 base controller라는건 도대체 왜 있을까? controller면 컨트롤러인거지 왜 new controller -> create controller가 있고 base controller가 또 있을까? 굳이 나눠야 했을까? 꼭 나눠야했다면 이유가 무엇일까? route가 있으면 있는건데 왜 register라는 녀석을 거칠까?

 

이런 식이다.

 

회사에서 백엔드는 대부분 Go 언어로 되어있는데, 그 중에 Gin이라는 프레임워크를 쓴다.

그래서 Gin을 예로 들어본다면,

Gin 공식문서를 보면 이렇게 간단하게 만들 수 있는 라우터가, 실제론 그렇지 않고 뎁스가 2개 3개가 되어있으니 알다가도 모를 일이다. (물론 gRPG를 쓰고 있기 때문에 이런 식으로 쓸 수는 없지만)

 

오늘 혼자 프로젝트를 곰곰히 뜯어보면서 분석해봤지만, 잘 모르겠다. 짐작 가는 부분은 스프링 프레임워크 같은 경우는 IoC와 의존성주입을 통해 알아서(?) 다 해결해주기 때문이 아닐까 싶다. 스프링과 다르게 Go에서는 환경변수를 다루는 것도 한 단계 더 거쳐야하는 일이 있었는데 그 때 시니어 분이 비슷한 이야기를 해주셨기 때문이다.

 

만약 확장성과 유연함을 위해서라면 어느 정도 그 부분을 포기하고 직관성을 가져가야하지 않나 싶다. 프로젝트의 복잡성을 줄이기 위해 MSA를 하는 것인데 이 마이크로 서비스 프로젝트는 누가와도 쉽게 구조를 파악 가능하고 최대한 유지보수가 가능하게 짜야하지 않을까 싶다.

 

클라이언트부터 DB로 쿼리를 날리기 까지 10번씩 단계를 거쳐야하는건 납득하기 조금 어렵다.

신입이 너무 건방진건가 ㅋㅋㅋㅋ 근데 분명 복잡한 데는 그 이유는 있을거 같긴 하다. 회사엔 다들 엄청난 분들만 계시기 때문에...

 

(일부 회사 정보가 담겨있어 블러 처리함)

 

어쨌든 어떻게 저떻게 다른 분들을 괴롭혀가며 설계를 완성했지만, 구현 또한 만만치 않은게 문제. 얼마전 MSA로 나간 프로젝트를 하나하나 분석하는데 너무 복잡하다.

 

 

 

빨리 월요일이 되서 물어보고 싶다.

 

 

 

 

우리 회사는 Go를 써서 잘 모르지만, 어쩌면 타회사의 실무 스프링 코드도 뭔가 상당히 복잡하지 않을까 궁금증이 문득 생긴다.