175. DTO 패턴 (Data Transfer Object Pattern)

핵심 인사이트 (3줄 요약)

본질: DTO (Data Transfer Object)는 계층이나 프로세스 경계를 넘길 데이터를 한 번에 묶어 전달하는 전송 전용 객체로, 비즈니스 규칙보다 계약과 페이로드 형태에 초점을 둔다.

가치: 원격 호출 횟수를 줄이고, 도메인 모델의 내부 구조를 외부에 직접 노출하지 않으며, API (Application Programming Interface) 응답 형식을 유스케이스별로 안정적으로 설계할 수 있게 한다.

판단 포인트: DTO를 Entity나 Value Object와 혼용하거나, 도메인 객체를 DTO처럼 빈 껍데기로 만들면 빈혈 도메인 모델 (Anemic Domain Model) 안티패턴으로 이어지므로 경계와 책임을 분명히 해야 한다.

Ⅰ. 개요 및 필요성

DTO는 원래 "말이 많은 원격 호출(chatty remote call)" 문제를 줄이기 위해 등장했다. 초기 J2EE (Java 2 Platform, Enterprise Edition) 환경에서는 EJB (Enterprise JavaBeans) 원격 객체의 getter를 여러 번 호출할 때마다 네트워크 왕복 비용이 발생했다. 사용자 이름, 이메일, 권한, 주소를 하나씩 묻는 구조는 로컬 객체에서는 단순하지만, 원격 경계에서는 성능과 결합도를 동시에 악화시켰다.

오늘날 DTO의 의미는 더 넓어졌다. REST (Representational State Transfer) API, 메시지 큐, 마이크로서비스, 프런트엔드 백엔드 분리 구조에서는 원격 호출 횟수만큼이나 계약 형태를 별도로 관리하는 일이 중요하다. 도메인 Entity를 그대로 외부에 노출하면 내부 속성 변경이 API 깨짐으로 이어지고, 민감 정보나 불필요한 연관 객체가 함께 새어 나갈 수 있다.

┌──────────────────────────────────────────────────────────────────────┐
│ Why DTO was created                                                 │
├──────────────────────────────────────────────────────────────────────┤
│ Without DTO                                                         │
│   Client -> getName()                                               │
│          -> getEmail()                                              │
│          -> getRole()                                               │
│          -> getAddress()                                            │
│   = many remote round trips                                         │
│                                                                     │
│ With DTO                                                            │
│   Client -> getUserSummaryDTO()                                     │
│   = one call, one shaped payload                                    │
└──────────────────────────────────────────────────────────────────────┘

그래서 DTO의 필요성은 단순 성능 최적화를 넘어, 경계 밖으로 내보낼 데이터 형태를 의도적으로 설계하는 것에 있다. 무엇을 실어 보낼지, 무엇을 숨길지, 어떤 이름과 형식으로 계약을 고정할지를 분리해 주는 도구가 바로 DTO다.

📢 섹션 요약 비유: DTO는 음식 자체가 아니라 배달 상자와 같다. 주방 안의 조리 과정은 숨기고, 손님이 받아야 할 음식만 정리해서 한 번에 전달한다.

Ⅱ. 아키텍처 및 핵심 원리

DTO의 핵심 원리는 세 가지다. 첫째, 경계 전용성: DTO는 경계를 넘을 때만 의미가 있다. 둘째, 무행동성: 비즈니스 규칙을 담기보다 데이터를 담는 데 집중한다. 셋째, 형태 분리: 내부 도메인 모델과 외부 계약 모델을 분리해 각각 다른 변경 주기를 허용한다. 이 때문에 DTO는 보통 Controller, API Adapter, Application Service 경계에서 생성되거나 변환된다.

┌──────────────────────────────────────────────────────────────────────┐
│ DTO at a system boundary                                            │
├──────────────────────────────────────────────────────────────────────┤
│ Client                                                              │
│   │ Request DTO                                                     │
│   ▼                                                                 │
│ Controller / API Adapter                                            │
│   │ map                                                             │
│   ▼                                                                 │
│ Application Service                                                 │
│   │ uses                                                            │
│   ▼                                                                 │
│ Domain Entity / Value Object                                        │
│   │ map                                                             │
│   ▼                                                                 │
│ Response DTO / Integration DTO                                      │
└──────────────────────────────────────────────────────────────────────┘

DTO 유형	주 사용 위치	설계 포인트
Request DTO	클라이언트 → 애플리케이션	입력 형식 검증, 필수값 확인, 과도한 필드 차단
Response DTO	애플리케이션 → 클라이언트	필요한 필드만 노출, 민감 정보 제거, 화면 친화적 구조
Integration DTO / Event DTO	서비스 간 통신, 메시지 브로커	버전 호환성, 직렬화 형식, 스키마 안정성

실무에서는 Mapper나 Assembler가 DTO와 도메인 객체를 상호 변환한다. 중요한 것은 변환 기술이 아니라 책임의 위치다. DTO가 도메인 규칙을 품기 시작하면 전송 객체가 아니라 또 하나의 도메인 객체가 되어 버리고, 반대로 도메인 객체가 단순 getter/setter 묶음으로 전락하면 모델이 빈혈 상태가 된다.

또한 과거 J2EE 문헌에서는 DTO를 Transfer Object 또는 Value Object라고 부르기도 했다. 그러나 DDD (Domain-Driven Design)에서 말하는 Value Object는 도메인 의미, 불변성, 값 동등성을 갖는 별도 개념이므로 오늘날에는 둘을 같은 말로 취급하지 않는 편이 안전하다.

📢 섹션 요약 비유: DTO는 이삿짐 목록표와 같다. 어떤 상자를 어디로 보낼지는 적지만, 그 목록표가 가구 배치나 집 수리 방법까지 결정하지는 않는다.

Ⅲ. 비교 및 연결

DTO를 설계감리 관점에서 볼 때 가장 중요한 일은 비슷한 객체들과 경계를 나누는 것이다. 특히 Entity, Value Object, DAO (Data Access Object)는 이름이 함께 등장해 혼동되기 쉽지만 역할이 전혀 다르다.

개념	식별자	비즈니스 로직	변경 가능성	핵심 역할
DTO	보통 없음	없음 또는 최소 검증 수준	상황에 따라 가변/불변	계층 간 데이터 운반, 계약 형태 정의
Entity	있음	핵심 규칙 보유 가능	생명주기 동안 상태 변화	도메인 식별과 행위 표현
Value Object	없음	도메인 의미와 불변 규칙 보유	보통 불변	값 자체를 모델링
DAO	객체가 아니라 접근 계층	저장소 접근 로직	구현별 상이	데이터베이스 접근 분리

이 표에서 핵심은 DTO가 "도메인 진실"을 대표하지 않는다는 점이다. DTO는 특정 화면, 특정 API, 특정 통합 시나리오에 맞춰 설계되는 계약이다. 그래서 UserSummaryResponse, UserCreateRequest처럼 유스케이스 중심으로 잘게 나누는 편이 UserDTO 하나를 전 구간에 재사용하는 것보다 안정적이다.

또한 역사적 문맥도 기억할 필요가 있다. 구 J2EE 자료의 "Value Object = DTO" 표기는 오늘날 DDD의 Value Object와 충돌한다. 설계감리 답안에서는 이 차이를 짚어 주면 객체 개념을 단순 암기하지 않고 맥락적으로 이해하고 있음을 보여 줄 수 있다.

📢 섹션 요약 비유: Entity는 학생 본인, Value Object는 학생의 키나 점수 같은 값, DTO는 가정통신문, DAO는 행정실 창구에 가깝다. 모두 학교 안에 있지만 맡은 일이 다르다.

Ⅳ. 실무 적용 및 기술사 판단

DTO는 경계가 분명할수록 효과가 크다. 외부 API 응답, 모바일 앱 전용 화면, 서비스 간 이벤트, 읽기 모델 조합처럼 "내부 모델과 외부 계약을 다르게 가져가야 하는 경우"에는 DTO가 강력하다. 반대로 동일 프로세스 내부에서 짧은 메서드 호출만 반복되는 단순 구조라면 DTO를 과도하게 늘리는 것이 오히려 복잡도를 높일 수 있다.

상황	DTO 적용 판단	이유
외부 공개 API	적극 권장	계약 안정성, 민감 정보 차단, 버전 관리가 필요하다.
화면별 조회 모델	권장	필요한 필드만 조합해 전송량과 응답 구조를 최적화할 수 있다.
서비스 간 이벤트 전송	권장	직렬화 형식과 하위 호환을 독립적으로 관리해야 한다.
동일 계층 내부의 단순 로컬 호출	선택적	경계 이점보다 매핑 비용이 커질 수 있다.

실무 체크리스트

DTO 이름이 UserDTO처럼 범용적이지 않고, 실제 유스케이스를 반영하는가?
응답 DTO가 내부 Entity를 그대로 복사하는 대신 필요한 필드만 노출하는가?
입력 형식 검증과 비즈니스 규칙 검증의 책임을 구분하고 있는가?
DTO ↔ 도메인 변환 책임이 Controller나 Entity 내부에 흩어지지 않았는가?
계약 변경 시 버전 관리나 하위 호환 전략을 갖고 있는가?

자주 발생하는 안티패턴

JPA (Java Persistence API) Entity를 그대로 API 응답으로 내보내는 설계
화면, 배치, 외부 연계가 모두 같은 범용 DTO 하나를 공유하는 구조
DTO에 할인 계산, 상태 전이 같은 비즈니스 로직을 넣는 구현
도메인 객체를 DTO처럼 비어 있는 데이터 상자로 만들어 Service에 규칙을 몰아넣는 빈혈 도메인 모델

기술사 관점에서는 **"DTO는 데이터 운반과 계약 분리를 위한 경계 객체이며, Entity·Value Object·DAO와 역할을 혼동하지 말고 유스케이스별로 최소한의 형태로 설계해야 한다"**라고 쓰는 것이 핵심이다.

📢 섹션 요약 비유: DTO 설계는 우체국 소포 박스를 고르는 일과 같다. 물건 크기에 맞는 상자를 써야 안전하고 낭비가 없지, 모든 물건을 같은 큰 박스에 넣으면 공간도 새고 관리도 어려워진다.

Ⅴ. 기대효과 및 결론

DTO를 올바르게 사용하면 API 계약은 안정되고, 도메인 모델은 외부 노출 압력에서 보호되며, 원격 호출과 직렬화 경계는 더 명확해진다. 특히 시스템이 커질수록 "내부 변경과 외부 계약 변경을 분리한다"는 효과가 커져 유지보수성과 협업성이 좋아진다. DTO의 진짜 가치는 데이터를 많이 담는 데 있지 않고, 경계별 언어를 분리하는 데 있다.

다만 DTO도 비용이 있다. 매핑 코드가 늘고, 과도한 세분화는 복잡도를 높일 수 있다. 그래서 DTO는 모든 객체를 대체하는 만능 패턴이 아니라, 경계를 넘는 순간에만 꺼내 드는 도구로 이해하는 것이 맞다. 기억해야 할 핵심은 "DTO는 도메인 두뇌가 아니라 전달 계약"이라는 점이다.

📢 섹션 요약 비유: 좋은 집배원은 편지를 안전하게 전달하지만, 편지 내용을 대신 결정하지는 않는다. DTO도 마찬가지로 잘 운반하되 판단은 도메인에게 남겨 두어야 한다.

📌 관련 개념 맵

개념	연결 포인트
J2EE Core Patterns	DTO가 원격 호출 최적화 패턴으로 체계화된 역사적 배경이다.
Value Object	DDD 맥락에서는 DTO와 다른 도메인 개념이므로 구분이 필요하다.
Entity	DTO가 보호하려는 내부 도메인 모델의 대표 대상이다.
Mapper / Assembler	DTO와 도메인 객체 사이의 변환 책임을 맡는다.
DAO (Data Access Object)	DTO와 함께 계층 분리에 자주 등장하지만 역할은 저장소 접근이다.
Anemic Domain Model	DTO 남용으로 도메인 규칙이 사라질 때 발생하는 안티패턴이다.

📈 관련 키워드 및 발전 흐름도

원격 호출 비용 문제
    │
    ▼
DTO (Data Transfer Object)
    │
    ├─ 페이로드 집계
    ├─ 내부 모델 은닉
    └─ 요청 / 응답 형태 분리
    │
    ▼
Mapper / Assembler
    │
    ▼
유스케이스별 DTO + 계약 버전 관리
    │
    ▼
안티패턴 통제
    └─ Entity 직접 노출 방지 / 빈혈 도메인 모델 방지

이 흐름은 DTO가 단순 원격 호출 최적화에서 출발해, 현대 API 계약 관리와 안티패턴 통제까지 확장되는 과정을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

DTO는 선생님이 집에 보내는 알림장처럼 필요한 내용만 담아 전달하는 종이예요.
알림장에는 꼭 알려 줄 것만 적고, 교실 안의 모든 비밀을 다 쓰지는 않아요.
그리고 알림장이 숙제를 대신 풀지는 않듯이, DTO도 데이터를 옮기기만 하고 중요한 판단은 하지 않아요.