DTO와 Response를 분리해야 하는 이유

🤔 그냥 DTO 하나로 쓰면 안 되냐는 질문을 진짜 많이 받는다.

결론부터 말하면 분리하는 게 맞다.
그리고 프로젝트가 급작스럽게 Mybatis 로 변경되어 이렇게 쓰는 것이지, JPA 의 경우는 Entity 까지 분리했을 것이다.

 

나도 첨에는 DTO만 쓰려고 했었는데 (Mapper에서 DTO로 받아서 그대로 리턴하면 편하니까..)

몇 번 겪어보니까 분리하는게 맞더라

 

📦 내가 사용하는 패턴

domain/
└── book/
├── controller/
│ └── BookController.java
├── dto/
│ └── BookDto.java ← DB 매핑용
├── mapper/
│ └── BookMapper.java ← MyBatis 인터페이스
├── model/
│ └── BookListResponse.java ← API 응답용
│ └── BookDetailResponse.java
└── service/
└── BookService.java

 

 

DTO - DB 조회 결과를 담는다

@Getter
@Setter
public class BookDto {
    private Long seq;
    private String title;
    private String author;
    private String isbn;
    private String publisherCode;    // DB에는 코드로 저장
    private String statusCode;       // 'A': 대출가능, 'B': 대출중, 'D': 폐기
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
    private String createdBy;        // 내부 관리용
    private String internalMemo;     // 민감 정보 (API 노출 X)
}

 

이건 말 그대로 DB 결과 담는 용도다.
컬럼이 늘어나든, 이름이 바뀌든 상관없다.

 

Response - API로 내보낼 형태를 정의한다

@Getter
@Builder
public class BookListResponse {
    private Long id;
    private String title;
    private String author;
    private String publisher;        // 코드 → 이름으로 변환됨
    private String status;           // 'A' → "대출 가능"
    private String registeredDate;   // yyyy-MM-dd 포맷

    public static BookListResponse from(BookDto dto) {
        return BookListResponse.builder()
                .id(dto.getSeq())
                .title(dto.getTitle())
                .author(dto.getAuthor())
                .publisher(PublisherCode.toName(dto.getPublisherCode()))
                .status(BookStatus.fromCode(dto.getStatusCode()).getDisplayName())
                .registeredDate(formatDate(dto.getCreatedAt()))
                .build();
    }

    private static String formatDate(LocalDateTime dateTime) {
        if (dateTime == null) return null;
        return dateTime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
    }
}

 

여기서는 프론트가 바로 쓰기 좋은 형태로 만든다.
DB 구조는 신경 안 써도 된다.

 

Service에서 변환

@Service
@RequiredArgsConstructor
public class BookService {
    private final BookMapper bookMapper;

    public List<BookListResponse> getBookList(BookSearchCondition condition) {
        List<BookDto> books = bookMapper.selectBookList(condition);
        
        return books.stream()
                .map(BookListResponse::from)   // DTO → Response 변환
                .collect(Collectors.toList());
    }
}

 

Service가 깔끔해진다. 비즈니스 로직 읽기도 편하다.

---

 

🎯 왜 이렇게 분리할까?

1. DB 스키마 바뀌어도 API는 안 건드리고 싶어서

DB 컬럼명이 `pub_code`에서 `publisher_cd`로 바뀌어도?
→ DTO만 수정하면 됨. Response는 그대로.

// DTO만 변경
public class BookDto {
    // private String pubCode;     // before
    private String publisherCd;    // after - MyBatis 매핑만 수정
}

// Response는 변경 없음 - API 스펙 유지
public class BookListResponse {
    private String publisher;  // 그대로
}

2. 민감한 정보가 실수로 노출되는걸 막기 위해

// DTO에는 있지만
public class BookDto {
    private String internalMemo;    // 내부 관리용 메모
    private String createdBy;       // 등록자 사번
    private BigDecimal purchasePrice; // 구매가
}

// Response에서는 의도적으로 제외
public class BookListResponse {
    // 위 필드들 없음 = API에 절대 노출 안 됨
}

 

>> `@JsonIgnore` 로도 가능하지만, 아예 필드가 없는 게 더 안전하다.

 

3. API 버전 관리가 쉬워진다

🔎 V1, V2 API를 동시에 운영해야 할 때:

// V1 - 기존 응답
public class BookListResponseV1 {
    private String status;  // "대출 가능"
    
    public static BookListResponseV1 from(BookDto dto) { ... }
}

// V2 - 새로운 응답 포맷
public class BookListResponseV2 {
    private BookStatus status;  // { code: "A", name: "대출 가능", available: true }
    
    public static BookListResponseV2 from(BookDto dto) { ... }
}

 

>> DTO는 하나, Response만 버전별로 관리.

 

 

4. 프론트엔드 친화적인 응답을 만들 수 있다

// DB에는 이렇게 저장되어 있지만
BookDto {
    statusCode: "A",
    publisherCode: "PUB001",
    createdAt: "2024-01-15T14:30:00"
}

// API 응답은 프론트가 바로 쓸 수 있게
BookListResponse {
    status: "대출 가능",
    publisher: "민음사",
    registeredDate: "2024-01-15"
}

 

---

💡 from() 메서드를 Response에 두는 이유

변환 로직을 어디에 둘까? 세 가지 선택지가 있다:

위치	예시	특징
Service	`toResponse(dto)`	Service가 비대해짐
별도 Mapper	`BookMapper.toResponse(dto)`	파일이 늘어남
Response 내부	`BookListResponse.from(dto)`	응집도 높음

 

나는 Response 클래스 내부에 `from()` 정적 메서드를 두는 방식을 선호한다.

// Response가 "나는 이 DTO로부터 만들어질 수 있어"를 스스로 정의
public static BookListResponse from(BookDto dto) {
    return BookListResponse.builder()
            .id(dto.getSeq())
            // ... 변환 로직
            .build();
}

 

장점:

• 응집도: 변환 로직이 Response 클래스 안에 캡슐화됨
• 가독성: `BookListResponse.from(dto)` - 읽기 쉬움
• 테스트: Response 클래스만 단위 테스트하면 됨

---

🏷️ 정리

구분	DTO	Response
역할	DB ↔ 애플리케이션	애플리케이션 ↔ 클라이언트
위치	`dto/` 패키지	`model/` 패키지
필드	DB 컬럼과 1:1	API 스펙에 맞게 가공
민감정보	포함 가능	노출할 것만
변경 주기	DB 스키마 변경 시	API 스펙 변경 시

 

처음에 설계할 땐 클래스가 너무 많아지는 거 아닌가 생각했지만 적용해보니 매우 합리적인 선택이라는 생각이 든다 ㅋ