Entity vs DTO 논쟁의 본질: 순수성인가, 실용성인가?

July 31, 2025 · 12 min read

BackEnd Software Developer

소프트웨어 설계에서 자주 반복되는 논쟁 중 하나는 바로 Entity를 Presentation Layer에서 사용하는 것이 적절한가? 하는 질문이다. 이 논쟁은 단순히 기술적인 분리가 옳으냐를 넘어서, 실용성과 유지보수 비용, 협업의 복잡성, 그리고 조직적 일관성이라는 주제를 포함하고 있다.

이 글에서는 실용주의 관점에서 Entity와 DTO 사이의 경계를 바라보고, 그에 따른 trade-off를 분석하고자 한다.

Entity는 Presentation Layer에서 써도 되는가?

가능하다. Entity는 단순히 persistence 객체가 아니라 도메인 개념을 표현하는 모델이기 때문이다. 복잡한 변환이 필요 없는 단순 CRUD나 목록 조회 화면에서, DTO를 만드는 것은 오히려 과설계가 될 수 있다.

✅ 사용할 수 있는 근거

불변성과 은닉은 설계로 통제 가능 (val, @JsonIgnore 등)
매핑/변환 없이 생산성과 유지보수성을 확보할 수 있다
단순 응답 모델에서는 오히려 DTO가 비용만 증가시킴

⚠️ 우려 사항들

Entity가 도메인 모델이라면 Presentation Layer에서 직접 사용하는 것은 지양해야 한다. 이유는 다음과 같다: • 도메인 캡슐화 침해: 화면 요구사항(View 특화 필드 등)이 도메인 내부로 침투할 수 있다. • 단일 책임 원칙 위배: 도메인은 비즈니스 규칙에 집중해야 하며, 표현 책임은 별도 객체가 가져야 한다. • 변경 전파 위험: 도메인 모델 구조 변경 시, View 및 API 응답 구조도 영향을 받을 수 있다. • 아키텍처 원칙 위배: Hexagonal Architecture 등 계층적 설계 원칙에서 도메인과 UI는 간접적으로만 연결되어야 한다.

따라서 도메인 모델은 Presentation Layer에 직접 노출되지 않도록, Response와 같은 표현 계층 전용 객체를 두는 것이 바람직하다.

Entity는 도메인 모델인가, 영속화 모델인가?

Entity는 원래 도메인 모델의 개념이다. 즉, 식별 가능한 객체이며 비즈니스 의미를 가진다.

하지만 실무에서는 흔히 @Entity 어노테이션을 통해 JPA 기반의 영속화 모델로도 사용된다. 이는 현실적인 경계 융합이며, trade-off를 전제로 한다면 수용 가능하다.

Entity에 `@Entity` 어노테이션이 붙는 것이 괜찮은가?

이론적으로는 기술 의존성 침투이며, Clean Architecture나 DDD에서 지양된다.
하지만 도메인 로직이 기술에 오염되지 않는 한, @Entity 정도의 침투는 허용 가능한 절충안이 될 수 있다.

단, @Query, @Transactional 같은 구체적인 persistence 행위가 도메인에 포함되는 것은 지양해야 한다.

저장소 설계와 도메인 모델이 충돌할 때?

이럴 땐 다음과 같은 전략이 필요하다:

Projection DTO, ReadModel을 사용해 조회 모델 따로 설계
ViewEntity나 @SecondaryTable 같은 기능으로 DB 구조에 대응
도메인 모델은 유지하고, Repository 단에서 native query 처리로 흡수

협업 환경에서 분리 기준은 명확해야 한다

모델이 섞여서 사용된다면, 팀 간 커뮤니케이션 비용, 리뷰 혼란, 중복 구현, 파편화된 설계가 발생한다.

따라서 아래와 같은 기준이 반드시 필요하다:

유형	전략
단순 CRUD	Entity 그대로 사용
핵심 도메인	도메인/영속화 모델 분리
조회 전용	Projection/DTO 사용
민감 정보 포함	DTO 강제 분리

분리 전략 vs 혼재 전략: 유지보수 비용 비교

항목	완전 분리	혼재 구조
초기 개발	느림	빠름
일관성	높음	낮음
변경 대응	국지적	파급 큼
테스트	명확함	불안정
장기 비용	일정	비선형 증가

장기 프로젝트이거나 팀원이 3명 이상인 환경에서는 혼재 구조가 더 큰 비용을 초래할 수 있다.

결론

Entity는 도메인 모델이다.
상황에 따라 persistence 모델로 겸용할 수 있지만, 명확한 기준과 관리가 필요하다.
“절대 금지”보다 중요한 것은 의사결정의 명확성과 일관된 팀 컨벤션이다.

참고

이 글은 실무 경험 기반의 논쟁을 토대로 정리된 내용이며, 팀 규모, 개발 문화, 아키텍처 철학에 따라 충분히 유연하게 해석될 수 있다. 정답은 없다. 다만 정교한 기준 없이 섞이는 것이 위험하다는 점은 분명하다.

🔍 부록: “Entity를 Presentation Layer에서 써도 된다”는 주장에 대한 정리

실무에서는 종종 "Entity를 프레젠테이션에서 그냥 써도 된다"는 말이 반복적으로 회자되곤 한다. 그러나 이 주장은 반드시 다음의 명확한 전제와 설계 인식이 함께 동반되어야만 의미가 있다.

✅ '써도 된다'의 전제가 성립하는 조건

해당 Entity는 기술(예: JPA) 에 과도하게 의존하지 않는다
표현 계층에서 불변성, 보안성, 출력 제어가 유지된다 (@JsonIgnore 등)
DTO로 분리함으로써 얻을 이점이 충분히 낮다 (즉, 복잡하지 않다)
팀 내에서 어떤 경우에 겸용이 가능한지에 대한 일관된 기준이 존재한다

이러한 전제 없이 “그냥 써도 된다”는 주장은, 설계 원칙을 훼손하거나 예외를 일반화하는 위험을 내포한다.

❌ 흔히 간과되는 문제: 레이어 구분 없는 Entity 사용

Entity는 도메인 모델이자 persistence 대상 객체일 수 있지만,
그렇다고 아무 레이어에서도 자유롭게 사용할 수 있는 '만능 객체'는 아니다.

레이어 간에는 다음과 같은 책임의 경계가 존재한다:

[도메인] ↔ [영속성] ↔ [프레젠테이션]
 의미 중심   저장 기술     사용자 표현

→ 이 경계를 고려하지 않은 Entity 사용은 Separation of Concerns 위반이다.

📌 팀을 위한 실용적 체크리스트

"Entity를 API 응답에 바로 써도 되는가?" 판단 기준:

항목	체크
기술 의존성을 최소화하고 있는가?	✅
JSON 응답에 민감 정보가 포함되지 않는가?	✅
View 특화 필드가 필요 없는가?	✅
단일 책임 원칙을 충족하는가?	✅
팀의 설계 기준에 부합하는가?	✅

이러한 기준 없이 반복되는 “써도 된다니까요?”는
근거 없는 실용주의이며, 팀과 프로젝트에 지속 가능한 설계 부채를 야기할 수 있다.

부록2: DTO보다 layer의 특성 혹은 구체적인 용도에 맞게 명명하자.

✅ 왜 “DTO” 대신 XxxRequest, XxxResponse 라고 부르는 것이 더 나은가?

“DTO”는 너무 추상적이고 모호하다
- DTO(Data Transfer Object)는 너무 일반적인 용어여서 어떤 계층에서 어떤 목적을 위한 객체인지 명확하지 않음
- 예: UserDto → 요청용인지, 응답용인지, 내부 서비스용인지 구분이 안 됨
의도를 명확하게 표현하는 이름이 더 유지보수에 유리
- UserCreateRequest, UserDetailResponse, UserSearchResult처럼 객체의 사용 목적이 명확히 드러나는 이름은 코드를 읽는 사람에게 즉시 의미 전달
- 이는 Clean Code, Domain-Driven Design, Hexagonal Architecture 모두에서 권장하는 방향
Request / Response는 표현 계층(presentation layer)의 명확한 개념
- 대부분의 “DTO”는 실제로는 HTTP 요청/응답을 위한 데이터 구조임
- 즉, “Request/Response”가 진짜 이름에 들어가야 더 정확한 표현임
- 예: UserDto ❌ → UserCreateRequest, UserDetailResponse ✅
계층 간 전송을 분명히 구분하면 의존성도 명확해짐
- UI ↔ Controller ↔ Application → Domain 각 단계에서 쓰는 객체의 명명 방식이 계층 구조를 반영하면, 불필요한 의존성 전이가 줄고, 코드 구조도 명확해짐

✅ 정리

항목	DTO 사용
의미 명확성	❌ 모호함	✅ 명확함
계층 구분	❌ 추측 필요	✅ 이름만 봐도 파악 가능
유지보수성	❌ 혼동 발생	✅ 목적 기반 구분 용이
클린 아키텍처 적합도	⚠️ 떨어짐	✅ 높음

🔁 결론

DTO는 너무 일반적이다. 대신 XxxRequest, XxxResponse처럼 역할과 방향이 명확한 이름을 사용하자. 이게 실무에서 더 안전하고 명확한 설계 방식이다.

Entity는 Presentation Layer에서 써도 되는가?​

✅ 사용할 수 있는 근거​

⚠️ 우려 사항들​

따라서 도메인 모델은 Presentation Layer에 직접 노출되지 않도록, Response와 같은 표현 계층 전용 객체를 두는 것이 바람직하다.​

Entity는 도메인 모델인가, 영속화 모델인가?​

Entity에 @Entity 어노테이션이 붙는 것이 괜찮은가?​

저장소 설계와 도메인 모델이 충돌할 때?​

협업 환경에서 분리 기준은 명확해야 한다​

분리 전략 vs 혼재 전략: 유지보수 비용 비교​

결론​

참고​

🔍 부록: “Entity를 Presentation Layer에서 써도 된다”는 주장에 대한 정리​

✅ '써도 된다'의 전제가 성립하는 조건​

❌ 흔히 간과되는 문제: 레이어 구분 없는 Entity 사용​

📌 팀을 위한 실용적 체크리스트​

부록2: DTO보다 layer의 특성 혹은 구체적인 용도에 맞게 명명하자.​

✅ 왜 “DTO” 대신 XxxRequest, XxxResponse 라고 부르는 것이 더 나은가?​

✅ 정리​

🔁 결론​