첫 Spring 프로젝트인 Traduler에서는 DTO라는 데이터 전송 객체를 말 그대로 "그냥" 썼다. 대충 "보안상 문제때문에 클라이언트에게 보여질 데이터만 전달하는구나" 라고는 알고 있었지만 사실 다들 쓰니까 썼던 기억이 있다.
그리고 아직 진행중인 MyMiChef에서 또 다시 기계적으로 DTO 객체를 만들고 있는 나를 발견했다. 근거없는 코드를 쓰지 않겠다고 다짐했는데..
그래서 다음에 DTO에 대해서 제대로 공부해봐야 겠다 하고 있었는데, 마침 생각이 나서 포스팅 해보려 한다.
DTO는 데이터 전송 객체(Data Transfer Object)를 말한다. DTO는 데이터베이스나 외부 API와 같은 다른 소스에서 데이터를 가져와 컨트롤러나 서비스, 뷰 등에서 사용하는 데이터 객체이다. DTO는 가져온 데이터를 저장하거나, 새로운 데이터를 생성할 때 사용되며, 데이터 전송을 위한 필드만을 가지고 있다.
DTO의 주요 목적은 데이터 전송 과정에서 데이터 객체의 역할을 분리하는 것이다. DTO는 뷰와 서비스, 컨트롤러와 DAO 등 다른 계층 간 데이터 전송을 위한 중간 객체로 사용된다. 이를 통해 뷰와 서비스, 컨트롤러와 DAO 등 다른 계층 간 의존성을 줄일 수 있다.
DTO를 사용하는 이유
- 데이터 전송의 명확성: DTO는 데이터 전송 객체로, 여러 개의 속성을 가질 수 있다. 따라서 DTO를 사용하면 컨트롤러와 뷰 간에 데이터 전송이 명확하게 이루어질 수 있다.
- 보안: DTO는 민감한 데이터를 전송하는 데에도 사용될 수 있다. 예를 들어, 사용자의 비밀번호를 포함하는 User 객체를 전송하는 대신, UserDTO 객체를 생성하여 사용자 이름과 이메일만 전송할 수 있다. 따라서, 민감한 정보가 노출되지 않도록 보안성을 높일 수 있다.
- 유지보수성: DTO는 데이터의 전송을 담당하므로, 변경된 데이터 속성이나 컬럼명 등이 있을 경우, DTO만 수정하면 된다. 이렇게 하면 컨트롤러나 뷰 등 다른 부분의 수정이 필요하지 않으므로 유지보수성이 높아진다.
- 비즈니스 로직 분리: DTO를 사용하면 비즈니스 로직을 처리하는 모델 객체와 데이터 전송을 담당하는 객체를 분리할 수 있다. 따라서, 코드의 가독성과 유지보수성이 높아지며, 유연한 구조를 유지할 수 있다.
- API 설계: API를 설계할 때 DTO를 사용하면, API의 입력/출력 데이터 구조를 명확하게 정의할 수 있다. API 사용자들이 어떤 데이터를 보내야 하며, 어떤 데이터를 받아야 하는지에 대한 혼동을 방지할 수 있다.
위와 같이 DTO의 개념과 사용하는 이유를 알아보았다.
내가 느끼기엔 DTO를 사용하는 목적이 보안을 제외하고는 유지보수 측면의 목적이 강하다는 느낌이 들었다.
그리고 다음과 같은 의문이 들었다.
"노출되어도 문제 없는 데이터면 DTO를 쓰지 않아도 되는게 아닌가?"
"클라이언트로부터 받아온 데이터는 DTO가 필요한가?"
알아본 바로는, 사실 보안상의 이슈가 없다면 DTO를 사용하지 않아도 무방하다.
하지만, 보안상으로 문제가 되지 않더라도 DTO를 사용하는 것에는 많은 이점이 있다.
- DTO는 데이터 전송에만 사용되므로, 필요한 필드만 가지고 있다. 따라서 객체의 크기가 작아지며, 전송 시간도 단축된다.
- DTO는 읽기 전용 객체로, 객체 생성 후 필드 값을 변경할 수 없다. 이를 통해 객체의 안정성과 무결성을 보장할 수 있다.
- DTO는 데이터의 전송을 담당하므로, 변경된 데이터 속성이나 컬럼명 등이 있을 경우, DTO만 수정하면 된다.
- API를 설계할 때 DTO를 사용하면, API의 입력/출력 데이터 구조를 명확하게 정의할 수 있다.
그리고 클라이언트로부터 받은 데이터를 유효성 검사나 삭제 없이 엔터티로 사용하면 보안 문제가 발생할 수 있다. SQL 삽입, XSS(교차 사이트 스크립팅) 및 기타 유형의 삽입 공격과 같은 공격에 취약하다. 악의적인 사용자는 잠재적으로 서버로 전송되는 데이터를 조작할 수 있으며 이로 인해 데이터 손상, 손실 또는 도난이 발생할 수 있다.
DTO를 사용하여 클라이언트에서 수신한 데이터의 유효성을 검사하고 삭제하면 애플리케이션에서 항목을 생성하거나 업데이트하는 데 유효한 데이터만 사용하도록 하여 보안 취약점의 위험을 줄일 수 있다.
그렇다면 DTO를 쓰는게 무조건 좋을까?
내가 DTO에 대해 포스팅 하는 목적이 이것이다.
DTO를 쓰는데 오히려 코드베이스가 복잡해지고, 굳이 사용할 이유가 없어 보였기 때문이다.
실제로 DTO가 애플리케이션의 코드 품질을 저하시킬 수 있는 경우가 있다.
- 복잡성 증가: 경우에 따라 DTO를 사용하면 코드베이스의 복잡성이 증가할 수 있다. 예를 들어 DTO에 많은 논리나 매핑이 포함되어 있으면 코드를 이해하고 유지하기가 더 어려워질 수 있다.
- 코드 중복: DTO를 과도하게 사용하면 코드 중복이 발생하여 코드 유지 관리가 더 어려워질 수 있다.
- 개발 시간 증가: DTO를 적절하게 사용하지 않으면 개발에 걸리는 시간이 늘어날 수 있다. 특히 관리해야 할 DTO와 매핑이 많은 경우 코드베이스를 유지해야 한다.
따라서 DTO는 특정 경우에 유용할 수 있지만, 관련된 장단점을 고려하여 신중하게 사용해야 한다. 경우에 따라 DTO를 사용하면 실제로 코드 품질이 저하될 수 있으므로 각각의 특정 경우에 DTO가 실제로 필요한지 여부를 고려하는 것이 중요하다.
보안, 유지보수, 설계 측면에서 DTO를 사용하는 것이 일반적으로 좋은 습관이 될 수 있다.
하지만 근거가 있는 코드를 작성하자.
참고 자료
