분리를 분리하자

Source: Dev.to

소개

2025년 마지막 며칠 동안, 우리 팀 리드가 하루를 추가로 쉬면서 중요한 회의를 놓쳤습니다. 최근 구조조정 이후, 한 동료가 프로젝트를 떠났고 두 명의 신입이 합류했습니다. 논의는 Spring Boot 웹 프로젝트의 새로운 코드를 어떻게 구조화할 것인가에 초점이 맞춰졌습니다.

현재 접근 방식

지난 약 10 년간 제 직업 경력에서 가장 일반적인 패턴은 다음과 같습니다:

1. DTO POJO 를 REST 컨트롤러의 입출구에 두는 것.
2. 엔티티 객체 를 스토리지 스키마(예: 관계형 데이터베이스)에 직접 매핑하는 것.

가끔 프로세스 전용 POJO가 존재하지만, 여기서는 단순화를 위해 생략했습니다. 워크플로는 다음과 같습니다:

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper
   ↔ Entity (persistence)

요청/응답 객체를 스토리지 엔티티와 분리하면 구조가 달라질 수 있고, 향후 변경에 대비해 코드를 보호할 수 있습니다.

하지만 이는 핵심 로직을 레포지토리 계층으로부터 완전히 분리하지는 못합니다: 엔티티가 변경되면 바로 핵심에 영향을 미치기 때문입니다. 실제로 엔티티는 비즈니스 로직상의 필요가 없으면 거의 변경되지 않으므로, 저는 습관적으로 DTO와 엔티티만 사용해 왔습니다.

완전 분리를 위한 결정

제 우려에도 불구하고 팀은 핵심을 레포지토리와 완전히 분리하기로 했습니다. 새로운 레이아웃은 추가적인 매퍼 클래스와 엔티티를 복제한 POJO를 도입합니다:

REST Controller
   ↔ DTO (request/response)
   ↔ Mapper (DTO ↔ Domain Model)
   ↔ Domain Model (core)
   ↔ Mapper (Domain Model ↔ Entity)
   ↔ Entity (persistence)

우려 사항

• 복잡성 증가: 클래스가 늘어나면 요구사항이 바뀔 때 수정해야 할 곳이 많아집니다.
• 유지보수 부담: 시간이 지나면서 추가된 레이어가 불필요한 복잡성의 원인이 될 수 있습니다.

반면에, 핵심 내부 구조가 레포지토리 스키마와 크게 달라질 경우 이 분리는 각 레이어가 독립적으로 진화할 수 있게 해 유용할 수 있습니다.

결론

추가된 추상화가 가치가 있다면 기꺼이 조정하고 싶으며, 건설적인 피드백을 환영합니다.

모두에게 즐거운 연말연시 되세요!