DTO 클래스를 어떤 기준으로 생성해야 좋을까?

 

DTO 클래스를 어떤 기준으로 만들어야할지 고민이 생겼습니다. 주변 네이버, 카카오 개발자 친구들의 의견과 저와 같은 SI/SM 기업 개발자의 의견이 사뭇 달라서 정리하고자 글을 작성해봅니다.

---

DTO 클래스를 목적마다 파일을 생성해야 한다 !

목이 길어.. 아니.. DTO 클래스가 많아 슬픈 기린...

 

게시판 기능을 만든다고 가정해보면 게시글 등록/수정/삭제 기능과 댓글 등록/수정/삭제 등 다양한 기능 구현이 필요합니다. 이렇게 기능별로 DTO 클래스를 작성하는 경우에는 명확한 목적이 있어 다른 API의 요청이나 응답에 영향이 없다는 장점이 있습니다. 하지만, 클래스가 너무 많아져서 유지보수가 어렵다는 단점이 있습니다.

 

현재 제가 개인적으로 했던 사이드 프로젝트에서 사용했던 방법입니다. 무언가 파일이 많아지면서 있어보이는 프로젝트가 되는 것이 매력적이라 생각이 듭니다. 그러나 기능을 확장하면서 파일이 너무 많아지자 감당이 안 되고 있긴 합니다...

---

오직 하나의 DTO 클래스로만 !

실례가 안된다면... DTO 클래스 하나만 해주세요...

 

하나의 DTO 클래스 파일로 관리하는 방법은 개발자가 단순하게 개발하기 편하다는 장점이 큽니다. 등록, 수정.. 어떤 기능이든 하나의 객체가 가진 필드만 모두 나열하고 데이터 전송 시 하나의 객체만 사용하기 때문에 편합니다. 하지만 하나의 값을 보낼 때에도 그 외 모든 필드를 null로 채워 보내는 방법이라 오류 발생률이 높습니다.

 

Inner Class (내부 클래스) 사용하여 관리하는 방법

최근 사이드 프로젝트를 하면서 발견한 방법 중 괜찮은 방법을 하나 발견해서 소개드립니다! Inner Class를 활용한 방법입니다. 

 

public class BoardDto {
	@Getter
	@Builder
	@AllArgsConstructor
	@NoArgsConstructor
	public static class BoardInsertDTO {
		private String title;
		private String title;
		private String Category;
		private String content;
	}

	@Getter
	@Builder
	@AllArgsConstructor
	public static class BoardUpdateDTO {
		private String content;
	}
}

 

하나의 게시글 관련 DTO 클래스 파일을 생성하고 내부에 기능별로 클래스를 만들어서 사용하는 방법입니다. 프로젝트 내 파일이 하나라 관리하기도 편하면서 기능별로 클래스를 나눠 사용할 수 있는 장점이 있습니다.

 

물론 이 방법도 내부 클래스가 많아지면 하나의 파일에 방대한 내용이 담겨져 있어서 관리하기가 어렵다는 단점이 있습니다. 

 

---

그럼 대체 어떻게 해야하지 ?

DTO 클래스 파일을 어떻게 관리해야 하는지에 대해 김영한 님의 답변이 유명합니다. 

항상 유지보수에서 가장 문제가 되는 것이 바로 애매한 것입니다. 특히 같은 필드인데, 어떤 경우에는 null이고 어떤 경우에는 값이 있고 이렇게 모호하면 정말 유지보수가 어려워집니다.

 

애매한 것에 대해 기준을 세워야 한다면 그것은 PM의 역할이 될 수도 있겠습니다. 하나의 시스템을 담당하며 개발/운영하는 저는 다른 동료들과 의견을 나눠 기준을 세워봐야 할 것 같습니다.

 

어떻게 보면 제공 단위를 크게 만들어서 모든 데이터를 다 반환하는 API 하나를 만들면 될 것 같지만, 이렇게 너무 공통화해도 유지보수가 어렵고, 성능 이슈가 있습니다. 반대로 너무 각각의 케이스를 대응하도록 만들어도 API 자체가 많아져서 유지보수가 어렵습니다.

 

어떤 방법을 사용하더라도 결국엔 장단점이 모두 존재한다는 것을 이해하고, 상황에 맞게 적절히 혼합해서 사용하는 방법도 좋은 것 같습니다. 

 

이 사이에서 적절한 단위로 API를 설계하고 제공하는 것이 묘미이지요 ^^!
제가 선호하는 방법은 기본 공통 API를 제공하고, 이 기본 공통 API로 해결이 안되는 특수한 경우에 한해서 별도의 API를 제공하는 방법을 선호합니다.

 

김영한님의 방법이 정답에 가깝지 않을까요 ^^? API 기준으로 DTO 클래스 파일을 나누게 된다면 하나의 API에 대한 유지보수할 때 그 기능에 대해서만 수정하게 되면서 다른 API 영향도가 없다는 장점이 있기 때문에 대다수 개발자분들이 선호하는 방법입니다. 물론 필자 또한 그렇습니다.

 

하지만 저만의 짬뽕 기준을 세워본다면... (안 쓸거 같지만)

 

어떤 도메인에 대한...

• 기능이 적은편이다? 기능별로 파일 나누기!
• 기능이 3개 이상이면서 필드가 많은 편이다? 내부 클래스 사용하기!
• 기능이 많은편이다? 하나의 도메인 DTO로 관리하기!

 

정답이 없기 때문에 난해하지만 자신만의 기준을 정하고, 기준을 따르면 그게 정답 아닐까요?

 

저는 개인적으로 어떤 시스템을 빠르게 개발해야하고 프로토타입을 우선적으로 선보여야 하는 개발 건에 대해서는 단일 DTO 클래스 파일을 두는 편입니다. 개발 단계에서 최대한 시간을 줄이기 위한 방법입니다. 추후 요구사항에 맞는 개발이 어느정도 완료되면 최적화를 위해 기능별로 파일을 나누고 있습니다.