백엔드 API 만들면서 나만 헷갈렸던 DTO 설계 기준 정리!
API를 만들다 보면 "DTO를 하나로 처리해도 되지 않을까?", "아니면 따로 만들어야 하나?"
하는 고민이 자주 생긴다.
나 역시 프로젝트를 하면서 이 부분이 헷갈려서 직접 여러 케이스를 경험하고 기준을 정리하게 되었다.
그 내용을 공유해보려고 한다.
📌 DTO, 꼭 나눠야 할까?
결론부터 말하면,
도메인이 같더라도 API 응답의 목적이 다르면 DTO는 나눠야 했다.
처음에는 PeerReviewResponse 하나로 여러 API 응답을 처리했는데,
API마다 필요한 데이터가 다르고,
클라이언트에서는 쓸모없는 필드까지 받아야 해서 혼란이 생겼다.
✅ 실무 예시: 응답 목적별로 나뉜 DTO
DTO 클래스 응답 목적 사용되는 API
| PeerReviewDetailResponse | 단일 리뷰 상세 정보 제공 | 리뷰 생성, 리뷰 상세 조회 |
| UserReviewSummaryResponse | 유저 리뷰 통계 요약 | 유저 평균 점수 조회 |
| ProjectReviewStatusResponse | 프로젝트 리뷰 완료 여부 | 프로젝트 상태 조회 |
같은 도메인인 PeerReview 기반이지만,각 API가 다루는 데이터의 범위와 의미가 달랐기 때문에
DTO를 분리하는 게 훨씬 명확하고 효율적이었다.
⚠ 하나로 합치면 생기는 문제들
- 필요 없는 필드까지 포함되어 응답이 무거워졌다.
- 일부 필드는 특정 API에만 의미가 있었고, 다른 API에서는 null로 채워야 했다.
- 프론트엔드에서는 어떤 필드를 써야 하는지 헷갈려했다.
- DTO 하나가 바뀌면 여러 API에 영향을 주어 유지보수가 어려워졌다.
🤔 필드가 몇 개 없는데도 굳이 나눠야 할까?
처음엔 나도 이렇게 생각했다.
"이 정도면 하나로 처리해도 되지 않나?"
하지만 정리를 해보니, 필드 개수가 아니라 ‘의도’가 다르면 무조건 나눠야 했다.
1. 📌 응답 목적이 다르면 DTO도 달라야 했다
- PeerReviewDetailResponse는 리뷰 상세 보기용
- UserReviewSummaryResponse는 리뷰 요약 정보 제공용
API의 목적이 완전히 다르기 때문에, DTO도 그에 맞게 분리하는 게 맞았다!
단순히 “필드가 적다”는 이유로 합쳤다가는 나중에 유지보수할 때 더 골치 아픈 상황이 생길 것이다..
2. 🔮 확장 가능성을 고려해야 했다
지금은 단순히 평균 점수만 주고 있지만, 나중에는 리뷰 날짜, 작성자 닉네임, 히스토리 등 더 많은 정보가 들어갈 수도 있다.
DTO를 API 목적에 맞게 나눠두면, 나중에 확장할 때도 구조가 망가지지 않는다.
3. 🔧 API마다 책임을 나눠야 유지보수가 편했다
DTO 하나를 여러 API가 공유하면,한쪽에서 필드 하나 바꾸는 순간 다른 API까지 의도치 않게 영향을 받는다.
반대로 DTO를 명확히 나눠두니 각 API의 응답이 딱 고정되고, 서로 간섭하지 않아 연동도 깔끔했다.
4. 🚀 응답 크기와 속도도 신경 써야 했다
리스트 API에서 상세 리뷰 데이터를 몽땅 내려주면 응답 크기도 커지고, 렌더링도 느려진다.
따라서 필요한 정보만 담은 DTO로 가볍게 구성하면 사용자 경험도 좋아질 수 있다.
(특히 모바일 환경에서 더 중요하게 작용한다.)
💡 DTO는 View에 맞춰 설계해야 했다
처음엔 도메인 객체 그대로 DTO로 쓰고 싶었지만,
DTO는 서버 입장에서 데이터를 전달하는 게 아니라, 사용자(또는 프론트엔드)가 필요한 정보를 구조화해서 주는 용도였다!
❌ 나쁜 설계 예
- password, isAdmin 같은 보이면 안 되는 정보가 그대로 포함
- 시스템 내부 시간 등 클라이언트에게 쓸모없는 데이터가 같이 감
✅ 좋은 설계 예
- 화면에 보여질 정보만 명확하게 포함
- 구조가 깔끔해서 프런트도 쉽게 사용할 수 있음
✅ 정리: DTO를 나누는 4가지 기준
✍️ 마무리: DTO는 API 응답의 얼굴!
DTO는 단순한 데이터 꾸러미가 아니라 API의 목적과 구조를 보여주는 응답의 얼굴이다.
하나의 DTO로 여러 응답을 처리하려다 보면 정작 아무 API에도 딱 맞지 않는 애매한 구조가 되기 쉽다.
각 API가 “무엇을 보여주기 위한 것인지”를 먼저 생각하고,
DTO는 그 목적에 맞게 분리하는 것이 훨씬 유지보수도 쉽고 명확했다!
-> DTO를 여러 개 만드는걸 겁내지말자!