[데브코스] Spring Boot REST API 실습 (30강) - DTO 설계 가이드 정리 (RsData / ReqBody / ResBody / Entity DTO)

zuno·2026년 1월 5일

이번 강의는
“DTO를 언제, 왜, 어떻게 나누어 써야 하는지”가 아주 명확하게 정리된 강의였다.

이전까지는 DTO를 만들긴 했지만

이게 언제 필요한지
어디까지 만들어야 하는지
안 만들어도 되는 경우는 언제인지

가 좀 애매했는데,
30강에서 이 기준이 깔끔하게 정리됐다.


📌 DTO를 왜 이렇게 많이 나누는가?

핵심 목적은 딱 하나다.

엔티티를 그대로 외부에 노출하지 않고
상황에 맞는 “형태”로만 데이터를 전달하기 위해서

이를 위해 DTO는 크게 4가지 역할로 나뉜다.


1️⃣ RsData DTO (공통 응답 래퍼)

🔹 역할

  • 조회 API를 제외한 거의 모든 API 응답에 사용
  • 성공 / 실패 여부 + 메시지 + (필요 시) 데이터 전달

🔹 특징

  • 조회 API에서는 보통 사용하지 않음
  • 조회는 성공 시 구조가 단순하기 때문
  • 실패 상황에서는 조회 API도 RsData 형태로 응답 가능

🔹 RsData 사용 형태 정리

✅ 형태 1 : 단순 성공/실패만 알려줄 때

RsData<Void>
{
  "resultCode": "200-1",
  "msg": "삭제되었습니다.",
  "data": null
}

✅ 형태 2 : 간단한 데이터 1개

RsData<PostDto>
{
  "resultCode": "200-1",
  "msg": "조회 성공",
  "data": {
    "id": 1,
    "title": "제목"
  }
}

✅ 형태 2-2 : 간단한 데이터 여러 개

RsData<List<PostDto>>

✅ 형태 3 : 데이터가 2개 이상인 경우

RsData<PostWriteResBody>
{
  "resultCode": "201-1",
  "msg": "글이 작성되었습니다.",
  "data": {
    "totalCount": 10,
    "post": {
      "id": 10,
      "title": "제목",
      "content": "내용"
    }
  }
}

👉 이 경우에는 전용 ResBody DTO를 만든다.


❗ 핵심 기준

  • RsData의 data항상 하나
  • 두 개 이상이면 ResBody를 하나 더 만들어서 감싼다

2️⃣ 엔티티 DTO (Entity DTO)

🔹 역할

  • 엔티티를 외부에 그대로 노출하지 않기 위해 사용
  • 필요한 필드만 선택적으로 노출

🔹 사용 형태 1 : 기본 정보만

PostDto
MemberDto

예)

PostDto
- id
- 날짜
- 제목
MemberDto
- id
- 날짜
- 권한

🔹 사용 형태 2 : 정보가 더 필요한 경우

PostWithContentDto
MemberWithUsernameDto

예)

PostWithContentDto
- id
- 날짜
- 제목
- 내용
MemberWithUsernameDto
- id
- 날짜
- 권한
- username

절대 넣으면 안 되는 것

  • 비밀번호
  • 민감 정보

👉 “내 정보 조회”처럼 필요한 상황이 아니면 절대 포함하지 않는다.


3️⃣ 액션 메서드 입력 DTO (ReqBody)

🔹 역할

  • JSON 요청 본문을 받을 때 사용하는 DTO
  • @RequestBody + @Valid와 함께 사용

🔹 사용 예

PostWriteReqBody
PostModifyReqBody
PostCommentWriteReqBody
PostCommentModifyReqBody
record PostWriteReqBody(
    @NotBlank
    @Size(min = 2, max = 100)
    String title,

    @NotBlank
    @Size(min = 2, max = 5000)
    String content
) {}

✔ JSON으로 입력받는다면 반드시 만든다
✔ 검증(@Valid)을 위한 최소 단위


4️⃣ 액션 메서드 응답 DTO (ResBody)

🔹 역할

  • 특정 액션 메서드에서만 사용하는 전용 응답 DTO
  • 응답 데이터가 복잡해질 때 사용

🔹 사용 예

PostWriteResBody
PostModifyResBody
PostCommentWriteResBody
PostCommentModifyResBody
record PostWriteResBody(
    long totalCount,
    PostDto post
) {}

무조건 만들 필요는 없다

  • RsData로 충분하면 굳이 만들지 않는다
  • 데이터가 2개 이상일 때만 고려

🧠 DTO 설계 최종 가이드 정리

✔ RsData

  • 조회 API 제외하고 거의 다 사용
  • 상태 + 메시지 + (선택) 데이터

✔ Entity DTO

  • 엔티티 직접 노출 금지
  • 필요한 정보만 조합해서 생성

✔ ReqBody DTO

  • JSON 입력값을 받을 때 필수
  • @RequestBody + @Valid 세트

✔ ResBody DTO

  • 응답 데이터가 복잡할 때만
  • “정말 필요할 때만” 만든다

✍️ 개인적인 정리

이 강의에서 가장 좋았던 점은
“무조건 이렇게 해라”가 아니라,

어디까지가 적절한 선인지
언제는 단순하게 가도 되는지

그 기준을 명확히 잡아줬다는 점이다.

앞으로 DTO를 만들 때

  • 이건 RsData로 충분한가?
  • ResBody를 하나 더 만들어야 할까?

이 판단을 훨씬 수월하게 할 수 있을 것 같다.

0개의 댓글