✅ DTO란?

 

✅ DTO란?

DTO(Data Transfer Object) 는 말 그대로
컨트롤러 ↔ 서비스 ↔ 프론트엔드 사이에서 데이터를 “주고받을 목적”으로만 쓰는 객체예요.
즉, 데이터 운반용(transfer) 객체입니다.

---

✅ DTO의 역할

(1) Entity(=DB 구조) 와 API 요청/응답 데이터 구조를 분리시켜줍니다.

• Entity는 DB 테이블 구조 그 자체이지만,
• DTO는 API 요청마다 필요한 필드만 포함하거나, 추가로 계산된 데이터를 담을 수도 있죠.

(2) 보안 / 유연성 / 문서화를 동시에 확보합니다.
예를 들어,

• 회원가입 시 → password, email, nickname만 필요
• 로그인 시 → email, password만 필요
• 마이페이지 조회 시 → nickname, profileImage, bookmarkCount 등 필요
  이렇게 요청마다 구조가 달라요.

즉,
👉 “User 관련”이라도 “모든 API에서 같은 필드”를 주고받지 않아요.
그래서 UserDTO 하나로 모든 상황을 커버하려 하면, 필드가 비대해지고 의미가 불분명해집니다.

---

✅ 그렇다면 “DTO를 계속 만들어야 하나?”

정확히 말하면 “필요한 만큼만, 목적에 따라 분리” 하는 게 맞습니다.

예를 들어 User 관련이라면 보통 이렇게 나뉘어요 👇

DTO 이름 용도 포함 필드 예시

UserSignupRequest	회원가입 요청	name, email, password, nickname, phone
UserLoginRequest	로그인 요청	email, password
UserResponse	응답용 (회원정보 조회 등)	userId, email, nickname, createdAt
UserDTO (공용)	간단한 내부 전달	userId, email, token 등
RefreshTokenRequest	토큰 갱신용	refreshToken

이렇게 나누는 이유는:

• Swagger 문서가 자동으로 요청/응답 구조를 명확히 보여줍니다.
• 실수로 password를 응답에 포함시키는 등 보안 위험을 줄입니다.
• 필드 이름/형식이 각 API 목적과 1:1로 대응됩니다.
• 팀 개발 시, API 변경 범위를 최소화할 수 있습니다.

---

✅ “그럼 왜 UserDTO 하나만 쓰면 안 되나요?”

지금 UserDTO는 이미 로그인, 회원가입, 응답 등 서로 다른 책임을 다 포함하고 있죠.

예를 들어, UserDTO 안에는:

private String password;
private String token;
private String refreshToken;
private String preferenceKeywords;

이렇게 요청용 + 응답용 + 내부용 필드가 뒤섞여 있습니다.

그래서 이걸 전부 다 모든 API에서 쓰면 이런 문제가 생깁니다:

• Swagger 문서에는 password/token/refreshToken이 전부 노출됨.
• 회원가입 요청에 token이 붙어도 오류가 안 나서 디버깅 어려움.
• 다른 팀원이 API를 볼 때, “이 DTO가 어디서 어떤 필드로 쓰이는지” 불분명해짐.

즉, 재사용성은 좋아 보이지만 유지보수성이 급격히 떨어집니다.

---

✅ 정리 (핵심 3줄)

(1) DTO는 “요청/응답 목적별로 가볍게 분리”하는 게 맞습니다.
(2) UserDTO 하나로 모든 걸 커버하면 Swagger 문서와 실제 로직이 불일치하게 됩니다.
(3) DTO를 여러 개 두는 이유는 “엔티티를 오염시키지 않고, API 단위로 의미를 명확히” 하기 위함입니다.

---

💡 결론:

“User 관련 API니까 UserDTO 하나로 통일하자”는 발상은 초반엔 편하지만,
실무에서는 “요청/응답 단위로 분리된 DTO”가 훨씬 깔끔하고 안전합니다.
RefreshTokenRequest처럼 단일 필드 전용 DTO는 작지만, API 명세·보안·확장성 측면에서 큰 이점을 줍니다.