📦 API 직렬화 (Serialization)
작성 목적
API에서 말하는 직렬화(Serialization)의 개념을 명확히 이해하고, 실무에서 왜 DTO / Serializer 계층이 필요한지 정리합니다.
1️⃣ API 직렬화란
직렬화(Serialization) 는 서버 내부에서 객체(Obejct) 를 네트워크를 통해 전달할 수 있는 데이터 형식(JSON, XML 등) 으로 변환하는 과정입니다.
반대로, 클라이언트로부터 전달받은 JSON/XML 데이터를 서버 내부에서 사용하는 객체로 변환하는 과정을 역직렬화(Deserialization) 라고 합니다.
객체 → (직렬화) → JSON → (역직렬화) → 객체
2️⃣ API에서 직렬화가 반드시 필요한 이유
🔹 서로 다른 환경 간 통신
-
서버: Java / Kotlin / Python 객체
-
클라이언트: JavaScript 객체
✔️ 객체 메모리 구조는 공유할 수 없으므로 문자열 기반 포맷(JSON) 이 필요
🔹 내부 구조 은닉 (캡슐화)
-
DB Entity를 그대로 응답하면:
- 불필요한 필드 노출
- 보안 위험 증가
- 스펙 변경에 취약
✔️ API 전용 응답 구조로 변환하는 계층이 필요
🔹 API 스펙을 안정적으로 관리
- 내부 도메인 구조 변경 ≠ API 스펙 변경
- 직렬화 계층이 완충 역할을 수행
3️⃣ 직렬화 / 역직렬화 흐름 (API 기준)
🔹 API 요청 (역직렬화)
Client JSON → 역직렬화 → Request DTO → 비즈니스 로직
- 요청 Body(JSON)를 객체로 변환
- 이 단계에서 타입 검증 / 유효성 검증 수행
🔹 API 응답 (직렬화)
도메인 객체 → Response DTO → 직렬화(JSON) → Client
- 내부 객체를 그대로 반환하지 않음
- 필요한 필드만 선택하여 응답
4️⃣ 예시로 이해하기
🔸 서버 내부 도메인 객체
User {
Long id;
String email;
String password;
LocalDateTime createdAt;
}
🔸 API 응답 JSON
{
"id": 1,
"email": "user@test.com"
}
password,createdAt은 직렬화 과정에서 제외
5️⃣ DTO / Serializer 계층을 분리하는 이유
❌ Entity 직접 반환의 문제점
- 보안 필드 노출 위험
- 연관 관계 직렬화로 인한 성능 문제
- API 변경 시 Entity 수정 강제
✅ DTO 기반 직렬화의 장점
- API 스펙을 명확히 정의 가능
- 내부 도메인 변경에 안전
- 필드 제어 (노출 / 변환) 용이
- 버전 관리에 유리