내가 만들어가는 거대한 레거시

코드스쿼드 부트캠프 기간동안 언젠가 이린이 이런 얘기를 했었다.
 
"내가 짠 코드가 1주일밖에 안되었는데 벌써 레거시가 된 것 같아요!"
 
그때는 그냥 호응만 하고 넘어갔지만, 사실 크게 공감을 못했다.
왜냐면 코드스쿼드때에서 팀프로젝트할 때는 사실 매 프로젝트마다 새로운 기술을 학습하면서 구현해야 했던 터라
학습과 구현에 치여서 구현도 100% 못해서 이전의 코드를 돌아볼 새도 없었다.
 
사실 이린은 코드스쿼드 과정이 나랑 달라 3개월 먼저 끝났고 몇달 간 프로젝트를 더 했다고 들었다.
그런 유지보수 기간의 차이였을까?
 
암튼 그때 이린이 했던 얘기가 최근에 문득 떠올랐다.
지금 회사에 있는 스프링 프로젝트는 아키텍처부터 시작해서 기능 구현까지 혼자서 했다.
(백엔드가 나 혼자밖에 없다.)
 
헥사고날 아키텍처니 레이어드 아키텍처니, 이런 아키텍처 구조보다 OOP나 다른 곳에 관심이 많았던 터라
관심도 좀 적었고 공부도 많이 안했어서... 프로젝트 구축하기 전에 주위에 많이 물어보았고
 
이런저런 고민을 하다가 결론적으로 혼자서 개발하려면, 그리고 나중에 다른 팀원이 합류해서도 빠르게 적응하기 위해서는
레이어드 아키텍처가 적합하다는 판단을 내렸고, 스프링 멀티 모듈 + 레이어드 아키텍처로 프로젝트 구성하게 되었다.
(물론 완벽한 레이어드 아키텍처는 아니다.)
 
그런데 그렇게 구성한 프로젝트가 한달도 안돼서 거대한 쓰레기가 되어버렸다.
프로젝트 아키텍처 설계하기 전에 우형 테크 블로그에서 멀티모듈 설계 이야기 with Spring, Gradle 을 참고해서 설계한건데도
내 경험이 부족한 탓도 있고, 아키텍처에 대한 지식도 부족한 탓도 있겠다.
 
내가 원래 목적했던 바는 서비스 별로 모듈화해서 서비스 모듈간에는 서로에 대한 의존성이 없는 거였는데...
 
"어? 중복된 설정이네 common 모듈로 빼자!"
"infra쪽 설정이네 infra 모듈로 빼자! 근데 appplication layer에도 해당 기능을 사용하려면 이 의존성이 필요하네? 의존성 추가!"
 
이러다 보니 결국에는 말만 레이어드 아키텍처에 멀티 모듈 구조지 결국에 얽히고 설켜버렸다.
 
피처 개발, 테스트 코드 작성, 연동 테스트, 아키텍처 무엇 하나 놓고 싶지 않은데
하나씩 타협해나가고 있는 내 자신을 발견했다.

그래도 피처개발이랑 테스트 코드 작성은 놓치지 않고 있는데
현재 상황에서 아키텍처 개선은 엄두도 나지 않는다. 

아키텍처가 문제있는 걸 알지만 일단 계속 개발해나가는 것이 최선일까?

한정된 시간과 리소스 안에서 타협하지 않으려면 어떻게 해야할까?