[데브코스] Spring Boot REST API 실습 (7강) - 프론트 요구사항 변경과 DTO 도입의 필요성
[데브코스] Spring Boot REST API 실습
이번 글은 데브코스 Spring Boot REST API 실습 7강 내용을 정리한 글이다.
7강에서는 프론트엔드 개발자와 협업하는 상황을 가정하여,
프론트 요구사항을 엔티티에 직접 반영했을 때 발생하는 문제점을 실습을 통해 확인하고
DTO 도입의 필요성을 이해하는 것이 목표였다.
1️⃣ 7강 실습의 시작: 프론트엔드 요구사항 변경
실습 중 프론트엔드 개발자와의 협업 상황을 가정하여
다음과 같은 데이터 이름 변경 요구가 주어졌다.
title → subject
content → body
createDate → createdDate이 요구사항은 JSON 응답 스펙(API 계약) 변경에 해당한다.
강의에서는 이를 그대로 엔티티에 반영했을 때
어떤 문제가 발생하는지 직접 경험해보도록 실습이 구성되어 있었다.
2️⃣ 실습 1: 엔티티 필드명을 그대로 변경
변경 전
private String title;
private String content;
private LocalDateTime createDate;변경 후
private String subject;
private String body;
private LocalDateTime createdDate;엔티티 필드명을 프론트 요구사항에 맞게 수정한 뒤 서버를 실행했다.
3️⃣ DB에서 발생한 변화 확인
H2 콘솔에서 테이블을 조회해보니 다음과 같은 상태가 되었다.
- 기존 컬럼
TITLE,CONTENT,CREATE_DATE는 그대로 유지 - 새로운 컬럼
SUBJECT,BODY,CREATED_DATE가 추가됨 - 새로 추가된 컬럼의 값은 모두
NULL
즉, 컬럼 rename이 아니라
기존 컬럼 유지 + 신규 컬럼 추가가 발생한 것이다.
이는 spring.jpa.hibernate.ddl-auto=update 환경에서
Hibernate가 필드 변경을 “스키마 변경”으로 해석했기 때문이다.
4️⃣ API 응답(JSON)에서 발생한 문제
DB에는 기존 CREATE_DATE 컬럼에 값이 있음에도 불구하고,
API 응답에서는 다음과 같이 createdDate가 null로 내려왔다.
{
"subject": "제목 1",
"body": "내용 1",
"createdDate": null
}5️⃣ 왜 이런 현상이 발생했을까?
1. JPA는 엔티티 필드를 기준으로 컬럼을 매핑한다
- 엔티티에
createdDate필드가 존재 - JPA는
CREATED_DATE컬럼만 읽음 CREATE_DATE컬럼은 엔티티에 매핑된 필드가 없으므로 무시됨
2. @CreatedDate는 INSERT 시점에만 동작한다
- 기존 데이터에는 소급 적용되지 않음
- 새로 추가된 컬럼은 기본값
NULL유지
3. Jackson은 엔티티 필드를 그대로 JSON으로 직렬화한다
- 엔티티 필드 값이
null - JSON 응답에도 그대로
null출력
이 실습을 통해
엔티티 필드 변경 → DB 스키마 영향 → API 응답 오류로 이어지는 흐름을 확인할 수 있었다.
6️⃣ 7강의 핵심 메시지
엔티티는 프론트엔드와의 API 계약이 아니다.
엔티티는:
- 백엔드 내부 도메인 모델
- DB 구조와 직접 연결됨
반면 JSON 응답은:
- 프론트엔드와의 계약
- 변경 가능성이 높은 영역
프론트 요구사항을 엔티티에 직접 반영하면
도메인 모델과 API 스펙이 강하게 결합되어
스키마 변경, 데이터 불일치, 유지보수 문제로 이어질 수 있다.
7️⃣ 강의에서 제시한 결론: DTO 도입
강의에서는 이 문제를 통해 다음 결론을 자연스럽게 도출한다.
- 엔티티는 내부 모델로 유지
- API 응답은 DTO로 분리
- 프론트 요구사항 변경은 DTO에서 처리
- 필요 시 API 버저닝으로 분리
강사의 커밋 메시지는 이 실습의 목적을 잘 드러낸다.
프론트엔드 개발자와의 협의 중에 정해진 데이터 이름을
백엔드 로직 내부에 바로바로 반영하는 것은 바보짓이라는 것을 깨닫고
원상복구, DTO 도입 필요
8️⃣ 7강 정리
- 프론트엔드 요구사항 변경을 엔티티에 직접 반영하는 실습을 진행했다
- 그 결과 DB 스키마와 API 응답에 문제가 발생함을 확인했다
- 엔티티와 API 응답을 분리해야 하는 이유를 실습을 통해 이해했다
- DTO는 선택이 아니라 설계를 위한 필수 요소임을 확인했다
💡 한 줄 요약
7강 실습은 프론트엔드 협업 상황에서
엔티티와 API 응답을 분리해야 하는 이유를
문제 발생 과정을 통해 체험하도록 설계된 강의였다.
