패키지 구조에 대한 고민

패키지 구조의 종류, 장/단점

패키지 구조는 어떻게 가져가는 것이 좋을까?

자바지기 박재성님의 10년 전 글을 읽으며, 오늘 처음으로 진지하게 패키지 구조에 대한 고민을 해 보았다.

위 글을 요약하자면, 패키지 구조는 크게 두 가지로 나뉜다.

1안) layer 우선

• net.slipp.domain.modulename
• net.slipp.service.modulename
• net.slipp.dao.modulename
• net.slipp.web.modulename

2안) module 우선

• net.slipp.modulename.domain
• net.slipp.modulename.service
• net.slipp.modulename.dao
• net.slipp.modulename.web

나는 우리 서비스인 풀방 프로젝트를 개발하면서 1안을 따랐는데, 각 패키지 구조를 비교해 보니 장단점이 명확히 갈리는 듯하다.

도메인 모델 위주 개발에 적합한 1안은 패키지 간 cyclic dependency가 발생할 가능성이 적고, 중복된 부분을 제거하기 용이하다는 장점이 있지만, 모듈 단위 분리에 어려움이 있다는 단점이 있다.

반면 2안은 모듈 단위 분리가 용이하지만 패키지 간의 cyclic dependency, 중복 코드의 발생 가능성이 (상대적으로) 높고, 도메인 간의 관계보다 모듈별로 구현할 가능성이 높다는 단점이 있다.

더 나은 패키지 구조에 대한 나의 생각

사실 박재성님의 글을 읽고 패키지 구조에 대해 이렇게 고민해보기 전까지는 1안의 패키지 구조로 개발함에 따라 어떤 장점과 단점이 있는지를 체감하지 못했었는데, 두 방식을 비교해 보니 장단점이 명확히 갈리는 것 같다.

나는 스프링 개발을 본격적으로 시작한 지 얼마 되지 않았고, 2안의 패키지 구조로는 개발을 해본 적이 없기에 어떤 패키지 구조가 더 낫다고 섣불리 판단하기는 어려울 것 같다.

그렇지만 적어도 내가 현재 개발 중인 풀방 프로젝트는 구조상 도메인 객체 간의 관계가 복잡하게 얽혀 있기 때문에, 모듈 간의 빈번한 호출과 cyclic dependency의 발생 위험 등을 고려했을 때 2안보다 1안이 조금 더 안전하고 자연스럽다는 점에서 적절하다고 생각했다.

개발자는 명확한 논거가 있어야 한다

패키지 구조에 대해 고민해보게 된 것은, 오늘 같은 학교 선배이자 든든한 소마 동료인 형에게 받았던 코드 리뷰가 발단이었다.

"패키지 구조를 이렇게 구성한 이유는 뭐야?"

코드 리뷰를 통해 정말 많은 피드백을 받았지만, 가장 기억에 남는 것은 패키지 구조에 대한 것이었다.

사실 피드백이라기보다는, 상기와 같이 단순히 내가 명확한 논거를 갖고 패키지 구조를 설계했는지를 묻는 질문이었다.

패키지 구조 뿐만이 아니라, 특정 애너테이션을 왜 사용했는지, DTO를 왜 사용해야 하는 것인지 등 백엔드 개발자로서 당연히 고민해보았어야 하는 질문에 대해 제대로 답변하지 못한 것이 부끄러웠다.

내가 1안의 패키지 구조를 따른 것은 스프링 개발이 아직 미숙하다는 핑계로, 김영한님의 스프링부트 강의 코드를 레퍼런스 삼아 우리 서비스를 개발했기 때문이었다.

기본적으로 다른 패키지 구조에 대한 선택지를 전혀 고려하지 않고, 이유 없이 패키지 구조를 따라 만들어 가며 개발했던 것이다.

코드 리뷰가 모두 끝나고, 개발자는 모든 선택에 대한 명확한 논거가 있어야 한다는 무거운 한 마디를 건네받았다.

내가 놓치고 있는 부분이었다. 정말 많이 반성했다.

앞으로는 개발자로서 명확한 논거를 찾기 위한 고민이 동반되는 개발을 할 수 있도록 노력하자.