의문의 발단

팀프로젝트 땅콩을 개발하기 위해 컨벤션을 설정하는 과정에서 팀원과 의견이 달라 토론의 시간을 가졌었다.

논의의 주제는 @RequestMapping 설정과 관련된 내용이었는데, 나는 최상위 Resource를 각각의 API Endpoint에 설정해주는 방안을 지향하는 편이었다.

@RequestMapping("/api")
class MemberControlelr {

    @GetMapping("/members/{memberId}")
    public List<MemberDTO> findAllMembers() {
    }
}

프로젝트가 점점 커지면 API 구현을 확인하기 빠르게 확인하기 위해서는, 최상위 리소스도 API 매핑 정보에 함께 두어야한다고 생각한다.

실제로 과거 스프링으로 프로젝트를 진행할 때, 종종 Endpoint 를 통해서 컨트롤러의 메서드를 검색한 경험이 있었는데 그때는 지금처럼 최상위 Path를 분리하지 않았었기에 편리하게 탐색이 가능했다.

의식하고 그렇게 개발한 것은 아니었다.

또 팀 단위로 서버 개발을 진행한다고 했을 때, 프로젝트에 익숙하지 않은 새로운 팀원이 들어왔다고 가정해보자.

애플리케이션의 코드에서 찾고자하는 API 메서드의 Endpoint 를 검색했는데, 여러 개의 메서드가 탐색된다면 새로운 팀원은 여러 컨트롤러 또는 메서드를 돌아다니며 원하는 API 메서드가 맞는지 하나하나 확인해야할 것이다.

이렇듯 최상위 Path를 분리하는 것은 중복코드를 제거한다는 이점보다, 개발의 유지보수성을 떨어뜨린다는 문제가 더 크게 다가왔다.

물론 프로젝트 크기가 작을 때는 큰 문제는 안되겠지만 일회성 프로젝트가 아닌 앞으로 운영 및 유지보수 해나갈 프로젝트를 설계하는데 이런 것을 고려하는 것은 오버엔지니어링의 영역은 아니라고 생각했다.

팀원의 의견

하지만 팀원의 생각은 조금 달랐고 충분히 고민해볼만한 포인트를 제시해주었다.