개발하면서 배운 Map vs DTO 방식의 차이점

목차

• 서론
  • 도입
  • 기능 요건
  • 문제점

 

• 본론
  • 초기 객체 구조(Map) - Bad
  • 최종 객체 구조 (DTO) - Good

 

• 결론

---

서론

도입

사이드 프로젝트에서 "제로웨이스트 관련 장소"를 지도에 띄우는 작업을 담당했다. "제로웨이스 관련 장소" (이하 place) 는 다양한 카테고리로 분류될 수 있는데, 기획 단계에서 아래 이미지의 필터 부분 처럼 정의하여 카테고리화 하였다.

악필 ㅈㅅ

기능 요건

사용자가 원하는 카테고리의 상점을 선택할 수 있도록 '필터'를 기능을 제공하는 것이 목표였다.

1. 큰 카테고리에 해당되는 소비를 돕는, 순환을 돕는, 보상을 주는 카테고리를 우선 만든다.
2. 각 카테고리에 속하는 여러 개의 필터를 넣는다.
3. 클라이언트 단에서 각각의 값을 알 수 있도록 key, value 형식으로 전송한다. key 값을 조회하면 해당 카테고리의 영문 코드가, value 를 조회하면 해당 카테고리의 한글 코드를 조회할 수 있도록 한다.

문제점

백엔드 개발자인 필자는 이 '필터' 를 코드화 하여 화면단에 보내주어야 했다. 이 과정에서 필자는 필터를 map 형태로 구성하여 클라이언트로 전송한 실수를 범했는데, 1) 이게 왜 잘못된 방식인지, 2) map 대신 Dto 를 사용해야 하는 이유가 무엇인지 를 중심으로 글을 풀어보겠다.

 

본론

초기 객체 구조(Map) - Bad

아래 객체 구조는 필자가 처음 설계한 방식으로, Java 의 Map 을 이용해 구성했다.

최상위 key 값으로 RECYCLE, COMPENSATION, CONSUME 을 가지도록 했고, 각각의 key 에 대응되는 value 는 또다른 Key-value 구조를 리스트로 받도록 했다.

{
    "RECYCLE": {
        "name": [
            "무해한 순환을 돕는"
        ],
        "filters": [
            "아이스팩수거함",
            "소형가전수거함",
            "동사무소"
        ]
    },
    "COMPENSATION": {
        "name": [
            "보상을 주는"
        ],
        "filters": [
            "수퍼빈",
            "분리수거"
        ]
    },
    "CONSUME": {
        "name": [
            "무해한 소비를 돕는"
        ],
        "filters": [
            "제로웨이스트샵",
            "리필스테이션",
            "채식식당"
        ]
    }
}

사실 지금 보면 어처구니 없는 코드인데, 당시에는 무슨 근거로 이렇게 객체를 구성했는지 모르겠다.

Map 을 사용해 위 객체를 어떻게 구성했는지 살펴보자.

우선 최상위 key 에 대응되는 value 의 타입도 Map 이 돼야한다. (이미 여기서부터 복잡하다)

왜냐하면 각각의 객체 구조는 (name 과 filters 는 라는) String key 에 대응하는 문자열 리스트를 value 로 받기 때문이다.

코드로 표현하면 대강 이런 모습이다.

public Map<String, Map<String, List<String>>> category = new HashMap<>();

딱 보고 복잡하다~ 싶으면 잘못됐음을 파악해야한다.

당연히 코드리뷰 때 팀원으로 부터 아래와 같은 피드백을 받았다.

빨간 글씨는 필자가 덧붙여 쓴것임으로 오해하기 없깅

팀원분의 마지막 스레드를 보고, 내가 짠 객체 설계의 문제점이 이해됐다.

위 처럼 설계한 것의 문제점

1. 클라이언트 개발자가 과연 RECYCLE, COMPENSATION, CONSUME 이란 key 값을 다 알고 있을까?
2. 지금은 전체 카테고리가 3개 뿐이지만, 추후에 카테고리가 수십, 수백개로 늘어난다면? 그 때도 클라이언트 개발자가 일일이 key 값에 해당되는 값을 모두 파악할 수 있을까?

때문에 value 에 해당되는 RECYCLE, COMPENSATION, CONSUME 같은 값들은 key가 아닌, value 의 위치에 두는 것이 옳다.

이런 점을 염두하여 객체 구조를 map 에서 DTO 로 리팩토링 해보자.

최종 객체 구조 (DTO) - Good

{
    "categoryGroup": [
        {
            "key": "CONSUME",
            "value": "무해한 소비를 돕는",
            "filters": [
                {
                    "value": "제로웨이스트샵",
                    "key": "ZEROWASTESHOP"
                },
                {
                    "value": "리필스테이션",
                    "key": "REFILLSTATION"
                },
                {
                    "value": "채식식당",
                    "key": "VEGANSHOP"
                }
            ]
        },
        {
            "key": "RECYCLE",
            "value": "무해한 순환을 돕는",
            "filters": [
                {
                    "value": "아이스팩수거함",
                    "key": "ICEPACK"
                },
                {
                    "value": "소형가전수거함",
                    "key": "APPLIANCES"
                },
                {
                    "value": "행정복지센터",
                    "key": "DONG"
                }
            ]
        },
        {
            "key": "COMPENSATION",
            "value": "보상을 주는",
            "filters": [
                {
                    "value": "수퍼빈",
                    "key": "SUPERBEAN"
                }
            ]
        }
    ]
}

리팩토링한 객체는 DTO 형태로 정의했다.

categoryGroup 이란 key 에 대응되는 value 는 동일한 DTO 를 리스트 형태로 받는다. 이 DTO 는 아래 코드에서 CategoryDto 의 inner class 인 Response 에 해당된다. Response 클래스는 key, value, filters 라는 세가지 필드를 가지며, filters 는 Map 을 제너릭으로 받는 리스트로, 즉 카테고리의 하위에 속하는 다수의 필터 값들이 key-value 의 맵 형태로 filters 에 포함되는 구조다.

CategoryDto 클래스

@Data
@AllArgsConstructor
public class CategoryDto {
    private List<Response> categoryGroup;

    @Data
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    public static class Response {

        private CategoryGroups key;
        private String value;
        private List<Map<String, String>> filters;

        public static Response of(CategoryGroups categoryGroups) {
            List<Category> categoryList = CategoryGroups.getFilterList(categoryGroups);
            List<Map<String, String>> filters = new ArrayList<>();
            for (Category category : categoryList) {
                Map<String, String> map = new HashMap<>();
                map.put("value", category.getCategory());
                map.put("key", category.toString());
                filters.add(map);
            }
            return Response.builder()
                    .key(categoryGroups)
                    .value(categoryGroups.getCategory())
                    .filters(filters)
                    .build();
        }
    }

    public static CategoryDto response(List<Response> categoryGroup) {
        return new CategoryDto(categoryGroup);
    }
}

CategoryGroups Enum 클래스

Category Enum 클래스

Category 호출 API

CategoryDto 클래스 version 2

처음 짠 CategoryDto 클래스엔 한가지 문제가 있는데, 바로 filters 리스트가 map 타입을 제너릭으로 받는다. 겉은 DTO 형태로 받을지라도, 그 내부의 값을 map 으로 받는 기이한 형태임을 깨달았고, 아래 코드처럼 리팩토링했다. 그리하여 filters 리스트의 제너릭 타입도 FilterResponse 라는 DTO 를 받도록 리팩토링할 수 있었다.

@Data
@AllArgsConstructor
public class CategoryDto {
    private List<Response> categoryGroup;

    @Data
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    private static class FilterResponse{  // 추가된 부분
        private Category key;
        private String value;
    }

    @Data
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    public static class Response {

        private CategoryGroups key;
        private String value;
        private List<FilterResponse> filters; // 변경된 부분

        public static Response of(CategoryGroups categoryGroups) {
            List<Category> categoryList = CategoryGroups.getFilterList(categoryGroups);
            List<FilterResponse> filters2 = new ArrayList<>();
            for (Category category : categoryList) {

                // 추가 및 변경된 부분
                FilterResponse build = FilterResponse.builder()
                        .key(category)
                        .value(category.getCategory())
                        .build();
                filters.add(build);
            }
            return Response.builder()
                    .key(categoryGroups)
                    .value(categoryGroups.getCategory())
                    .filters(filters)
                    .build();
        }
    }
}

결과

이렇게 하여 기존에 map 형태에서 DTO 로 Response 를 리팩토링 할 수 있었다.

 

map 대신 DTO 를 사용하여 얻을 수 있는 장점은 무엇이 있을까?

1. 가독성이 크게 개선된다. 위에서 언급했듯이 중첩된 map의 형태를 보면 . . . 그 내부를 파악하는 것이 꽤나 복잡하다. 아래 코드야 Map 내부에 map 이 하나밖에 추가되지 않은 간단한 케이스지만, 중첩 레벨이 깊어진다면 코드 트래킹하는데 더 많은 시간이 소모될 것이다.

2. key 값에 String 대신 특정 타입을 사용함으로 타입 안정성을 높일 수 있다. 위 코드에서는 DTO 사용시 enum 을 key 로 사용하기에, 오타나 잘못된 문자열 입력시 곧바로 컴파일 에러로 문제를 파악할 수 있다. -> 하지만 이 부분은, map 을 사용할 때도 key 부분에 String 이 아닌 특정 데이터 타입을 넣어 타입 안정성을 강화할 수 있다고 생각한다. 이게 꼭 DTO 를 사용했을 시의 장점인지는 의문이다. (댓글로 다양한 의견 부탁드림다)

3. 가독성과 연관된 부분일 수도 있는데, 클라이언트단에서 원하는 데이터가 무엇인지 쉽게 파악할 수 있다. DTO 클래스 내부에 정의된 멤버 변수를 보면 클라이언트 단으로 보내야할 값이 어떤것인지 쉽게 파악할 수 있다. API 의 명세가 변경될 때에도, 해당 필드를 변경하면 되기 때문에 변경에도 유연할 것이라 생각한다. 

 

 

결론

map 대신 DTO 를 쓰자. 물론 코드양이 늘어나고 map 을 사용할 때 보다 복잡한 코드 구조를 갖게 되는 것이 단점으로 받아들여질 수 도 있다. 하지만 이런 불편함을 감수해서라도, 개발의 안정성과 클라이언트 개발자와의 협업 측면에서는 DTO 를 사용하여 서로 협의된 형태로 데이터를 주고 받는 것이 좋다고 생각한다.