Dev./Spring

[Spring] 응답DTO에 엔티티 의존성을 주입해야 하는 경우

limitation01 2025. 11. 19. 08:33

Response DTO란

도메인 엔티티를 외부에 그대로 노출하지 않고 프론트에서 필요한 형태로 변환해 전달하는 역할

즉, Response DTO는 도메인의 상태를 읽기 전용으로 표현하는 포장지다.

그렇기 때문에 엔티티를 주입 DTO 안에서 필요한 정보만 꺼내 포맷팅하는 방식이 자연스럽다.

주입 해야 하는 경우 - 필드 수

처음에 Response DTO 만들 때 필드를 직접 하나씩 넣는 방식을 택했다.

return new UpdateCommentResponse(
    comment.getId(),
    comment.getUser().getUsername(),
    comment.getSchedule().getTitle(),
    comment.getContent(),
    comment.getModifiedAt()
);

이 방식은 필드가 적을 땐 괜찮지만 필드가 많아지면

 

  • 순서 실수 위험 ↑
  • 빠뜨린 값 발생 위험 ↑
  • 서비스 코드 가독성 저하
  • 유지보수 시 수정 포인트 증가

와 같은 문제가 발생할 수 있다.

엔티티 자체 전달

return new UpdateCommentResponse(comment);

 

이 방식은 다음과 같은 장점이 있다

  • 생성자가 단순해지고 코드가 읽기 쉬워진다
  • 서비스 레이어의 책임이 줄어든다 -> 단순 책임 위임
  • 필드 변경 시 DTO만 고치면 됨 → 서비스는 그대로
  • 실수로 필드를 빼먹는 문제 없음

실무에서는 필드가 4-5개 이상이면 엔티티 자체를 주입하는 방식을 선호한다고 한다.

왜 의존성 주입으로 구현하는 게 좋을까?

1. 응집도 증가

  • DTO가 엔티티를 직접 받아 필요한 데이터만 개발자가 원하는 구조로 가공하면 서비스와 DTO의 책임이 명확하게 분리되며 응집도가 높아진다.

2.의존 방향이 올바르다

  • DTO는 바깥쪽 레이어이고 Entity는 안쪽 레이어이다. 내부로 갈 수록 핵심 영역인데 바깥쪽 레이어가 안쪽 레이어를 의존 하는 것은 괜찮다.
  • 반대로 Entity가 DTO/Controller/Service를 의존하면 계층이 무너진다.

왜 반대로 엔티티가 DTO 의존을 할 수 없을까?

위에서 말했듯이  내부로 갈 수록 핵심 영역이다. Entity가 안쪽 레이어인데 바깥쪽 레이어의 변화에 흔들리면 안되는 중요한 객체이다. 하지만 DTO는 계층간의 데이터 전달자로 바뀔 수 있는 객체이다.

예를 들어 프로젝트가 변경되며 어떤 API가 응답 DTO를 

{
  "id": 1,
  "title": "Spring 입문",
  "author": "kkk"
}

에서

{
  "id": 1,
  "nickname": "kkk",
  "text": "Sping 입문"
}

이런 구조로 바뀌어야 한다면 보통은 DTO만 바꾸면 끝이지만

 

  • 엔티티 수정해야 함
  • 엔티티를 쓰는 서비스 전부 수정됨
  • 도메인 규칙에 영향감
  • 전체 레이어가 DTO 하나 때문에 무너짐

이런 문제가 발생하며 도메인 전체를 수정해야 하는 일이 생기게 된다.