📦 DTO

DTO

DTO(Data Transfer Object)는 계층 간에 데이터를 전달하기 위해 사용하는 객체로 비즈니스 로직을 포함하지 않는 순수한 데이터로만 이루어진 객체이다.

DTO는 아래 네 가지 역할만을 수행해야 한다.

1. getter
2. setter
3. serialize
4. deserialize

객체 지향의 관점으로 보면, '관심사의 분리(Separation of Concerns, SoC)'를 위해 사용한다.

장점

1. 호출 횟수 감소

한 호출에 여러 도메인의 데이터를 조합하고 정제하는데 많은 비용이 든다고 생각할 수 있지만, 통상적으로 서버와 클라이언트 간의 호출에 드는 비용이 더 크다.

w/o DTO

response: { "User": {} }

response: { "Payment": {} }

response: { "Product": {} }

w/ DTO

response: {
			"User": {},
            "Payment": {},
            "Product": {}
		  }

한 주문에 대한 정보가 '고객 정보 / 결제 정보 / 상품 정보'로 나누어져 있을 때, FE가 각각의 도메인에 알맞는 키로 조회하여 데이터를 가져온 뒤 결합하게 되면 총 세 번의 API 호출이 필요하다. 반면 DTO를 사용하면 여러 도메인의 데이터를 한 번의 API 호출만으로 가져올 수 있다.

2. FE - 도메인 모델 결합 방지

FE가 도메인의 모델과 강하게 결합되는 것은 좋지 않다. DTO로 감싸지 않고 데이터를 모델 그대로 전달할 경우, 도메인의 모델링에 변경사항이 있으면 FE도 그에 맞추어 대응하여야 한다.

1번

response: {
			"Angle": "90",
  			"Side": "4"
		  }

2번

response: {
			"Shape": "Rectangle"
		  }

한 예시로 '90도 / 4개의 변'을 도메인이 저장하고 있으며, FE는 사각형인지만 필요하다고 가정했다. 1번처럼 데이터를 그대로 전달한 경우, 2번과 같이 모델이 바뀌었을 때 그에 맞추어 FE도 Response를 재정의해야 한다.
간단하면서도 종종 발생하는 예시로는 단순히 컬럼 이름이 바뀌는 경우가 있다. 도메인 모델의 Shape이 GeometricShape으로 더 명시적으로 바뀌었을 때, 이러나 저러나 FE는 해당 컬럼의 value가 중요할 뿐 컬럼명 자체는 필요하지 않을 수 있다. 이 때 사전에 정의해둔 DTO에서 Shape이라는 컬럼명으로 꾸준히 데이터를 보내준다면 FE 유지보수 비용이 추가로 들지 않는다.
또는 특정 컬럼이 사라지거나, 추가되는 경우에도 문제가 발생할 수 있다.

3. 응답 값 정제

도메인 모델을 그대로 FE에 전달하면 불필요한 데이터나 민감한 데이터가 그대로 사용자에게 노출될 수 있다. 이는 또한 도메인의 상태를 외부에서 호출하거나 변경하는 등의 위험에 노출될 수 있음을 의미한다.

w/o DTO

response: {
			"id": "1234",
  			"name": "Kim",
  			"password": "4321",
  			"regDate": "2024-01-24",
  			"plan": "Standard"
		  }

w/ DTO

response: {
			"id": "1234",
  			"name": "K*m",
  			"plan": "Standard"
		  }

물론 위와 같이 민감한 데이터는 다양한 방법으로 보호되고 있겠지만, 극단적인 예시로 유저 정보 데이터를 가공 없이 전달하는 과정에서 비밀번호가 노출 되면 다양한 고난이 기다리게 된다. 유저의 이름을 꼭 모자이크 해야하는 경우에는 BE에서 모자이크 처리 후 데이터를 DTO에 담아 FE에 내려줄 수 있다.
이렇듯 FE에서 사용하지 않는 값은 제거하고, 사용하는 값도 필요에 따라 가공하여 DTO로 전달할 수 있다.

예시

업무 중 BE에서는 두 개의 Enum의 조합으로 표현되는 값이지만 FE에서는 한 개의 Enum으로도 표현될 수 있는 데이터가 있어서 DTO에 어떻게 담아야 할지 고민이 되었다.

response: {
			"gender": "female",
  			"age": "minor"
		  }

간단하게 '성별 / 미성년자 여부'로 모델에 저장되고 있는 유저에 대한 정보가 있다고 예를 들었다.
이 데이터가 화면 상에서는 'man / woman / boy / girl' 네 종류의 라디오 버튼으로 표현되어, FE는 네 종류 중 어디에 속하는지만 필요로 했다.
결과적으로 BE에 성별과 미성년자 여부로 유저 종류를 결정하는 로직을 구현하고, DTO에는 gender와 age 대신 userType이라는 컬럼명을 사용하는 방식으로 데이터를 내려주었다.