사용자에게 장바구니 기능 제공하는데 Mysql을 사용할 수도 있다. 하지만 비용임으로 상대적으로 저렴한 Redis 사용하기로 결정했다. 기능은 장바구니 생성, 장바구니 목록 읽기, 장바구니 목록 삭제 구현했다. redisConfig에서는 redisconnectionfactory, redistemplate, cachemanage를 기본적인 기능 셋팅했다. 이 외로 보통 스프링 코드처럼 dto, controller, service 기능 추가했고 jpa 대신 dao에서 redistemplate 메소드 사용했다.

향후

다른 기능들 추가로 구현하고, 기능 테스트 하면서 다른 모듈에 레디스 추가 계획이다.

@Cacheable를 roomController의 Getroom메소드에 적용하니 아래처럼 호출 API 호출 시간이 대략 5배 정도 빨라졌다. 콘솔 확인해보면 처음 요청땐 SQL 요청하고, 그 이후에는 SQL 요청하지 않는다. DB 부하를 분산시킬 수 있게 됐다. postman 실행 결과는 다음과 같다.

@Cacheable 사용 전 Room 정보 호출 결과

@Cacheable 사용 후 Room 정보 호출 결과

구현 방법

컨트롤러의 일부코드, DTO, gradle 수정해서 구현했다. 컨트롤러에서는 ResponseEntity 이 코드를 직렬화 할 수 없기 때문에 제거 했고, DTO 에서는 redis 저장 및 읽기 때를 위한 직렬화 인터페이스 상속 받고, gradle에서는 클래스로더에서의 DTO 호환성 문제 발생으로 해당 패키지는 주석처리했다.

//수정 전 

//RoomController

   @Cacheable(value = "room", key = "#id")
   @GetMapping("/id/{id}")
   public ResponseEntity<RoomDto> getRoom(@PathVariable Long id){
       Optional<RoomDto> roomDtoOpt = roomService.getRoomAndIncrementViewCount(id);
       return ResponseEntity.ok(roomDtoOpt.get());
   }

//RoomDto
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class RoomDto{}


//gralde
developmentOnly 'org.springframework.boot:spring-boot-devtools'

//수정 후 

//RoomController

   @Cacheable(value = "room", key = "#id")
   @GetMapping("/id/{id}")
   public RoomDto getRoom(@PathVariable Long id){
       Optional<RoomDto> roomDtoOpt = roomService.getRoomAndIncrementViewCount(id);
       return (roomDtoOpt.get());
   }

//RoomDto
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class RoomDto implements Serializable {}



//gralde
//developmentOnly 'org.springframework.boot:spring-boot-devtools'

쿼리 최적화를 위해 Room 에서의 RUD 는 @Cacheable, @CachePut, @CacheEvict를 활용해서 캐싱 구현했다.

향후

쿼리 최적화를 위해서 Room 에 대한 장바구니 기능 구현 계획이다. redistemplate 혹은 Redis jpa 사용 계획이다.

현재 코드는 프론트엔드에서 모임 목록 페이지에 접근하면 1번 페이지 열리면서 가장 최근의 Room 데이터 10개 호출해서 렌더링한다.

Room 테이블은 HostUser, Category, RoomImage 테이블과 관계 맺고 있는 상태다. Dto 변환시 각 테이블 데이터가 필요하기에 10개 데이터 호출되면 각 테이블데이터까지 포함해서 약 40번 쿼리 발생했다. 문제다.

Fetch Join과 PageNation

1개의 데이터 호출시 Fetch Join 사용하면 연관된 테이블 쿼리를 1번으로 압축 시킬 수 있었다. findAll도 가능할 것이라 예상했다. 아래 처럼 서비스와 레포지토리 코드를 수정 후 실행했다. 하지만 에러 발생했다.

Fetch Join는 4개의 연관 엔티티 데이터를 가져오고, Pagenation은 10개의 로우 데이터를 Limit 등 제한 조건적용해서 데이터를 가져온다. 하지만 위 두 기능에서 데이터 로딩때 데이터 중복 및 예상되지 않은 데이터 꼬임 및 성능저하 발생할 수 있다고 한다.

그런 이유로 Jpa에서는 두 기능 함께 사용을 미지원 및 상황에 따라서 제한한다고 한다. 그럼 어떻게 하면 좋을까?

//service

    @Override
    public List<RoomDto> getRoomList(Integer page, Integer size) {
        PageRequest pageRequest = PageRequest.of(page-1, size, Sort.by("id").descending());
        Page<Room> roomsPage = roomRepository.findAllWithCategoryAndHostUsersAndImage(pageRequest);

        List<Room> rooms = roomsPage.getContent();
        if (rooms.isEmpty()) {
            return new ArrayList<>(); 
        }

        List<RoomDto> roomDtos = rooms.stream().map(r -> roomMapper.toRoomDto(r)).collect(Collectors.toList());

        return roomDtos;
    }

//repository

    @Query("SELECT DISTINCT r FROM Room r " +
            "LEFT JOIN FETCH r.category " +
            "LEFT JOIN FETCH r.hostUserList " +
            "LEFT JOIN FETCH r.roomImage"
    )
    Page<Room> findAllWithCategoryAndHostUsersAndImage(Pageable pageable);

Batch (40 -> 4)

먼저 떠오른 생각은 모든 데이터 다 호출 후 Page구분 하려고 했다. 문제는 데이터가 쌓일수록 문제도 쌓일 것이라 판단했다.

결국 사용한 방법은 Fetch Join을 빼고 application-dev.yml에 Batch 값을 10으로 셋팅했다. 최대 여러 번 쿼리를 한 번에 묶어서 요청하는 방식인데 한 페이지에 10개씩 데이터 필요해서 10으로 할당했다.

이 후 Room 목록 10개 조회하니 40번의 쿼리는 4번으로 줄었다.(page로 인해 생긴 Count 쿼리 추가하면 5번) 임시적으로 이전보다는 쿼리 최적화 시켰다.

할 수 있으면 1번의 쿼리로도 가능할까 싶은데 아직은 잘 모르겠다. 나중에 알게되면 그 방법 사용할 계획이다.

user 부분 리팩토링 중이다. 상황은 다음과 같다.

user entity는 userImage entity와 1:1 관계를 가진다. user는 6명이다. 코드는 아래와 같다. 작동 순서는 user list 가져온 후 User 참조형을 UserDto 로 바꾼다. userDto로 바꿀때 연관관계에 있는 UserImage를 가져온다.

<ReviewRepository>

    List<User> findAllUserWithUserImage();



<UserMapper>

  default UserDto toUserDto(User user) {
        if (user == null) {
            return null;
        }

        return new UserDto(
                user.getId(),
                user.getUsername(),
                user.getUserImage().getProfile(),
                user.getEmail(),
                user.getDescription(),
                user.getRoleType()
        );
    }

이때 아무런 조치를 취해주지 않으면 콘솔에 쿼리는 userList 호출 쿼리 + 각 유저의 userImage 정보를 가져오느라 6번 추가 쿼리 발생한다. 총 7번 쿼리가 발생한다. 가령 아래와 같다.

하지만 fetch join을 사용하면 쿼리는 아래와 같이 1번으로 줄어든다.

<UserRepository>

@Query("SELECT u FROM User u LEFT JOIN FETCH u.userImage")
    List<User> findAllUserWithUserImage();

그럼 이렇게 쿼리가 줄어들면 뭐가 좋을까?

Fetch join과 검색 속도

fetch join 적용 전 후 코드에 대해 포스트 맨에서 검색 테스트 해봤다. 테스트는 각각 1000번씩 요청 보내고 속도를 측정했다.

먼저 fetch join을 적용하지 않아서 N+1 발생하는 상황이다. 위에서 첨부한 사진처럼 1회 요청에 1+6회, 총 7회 쿼리가 날아간다. 그럼 1000번 요청은 1000 + 6000 = 7000 요청 발생했다. 속도는 아래 사진 처럼 약 24초다.

다음은 fetch join 적용한 코드다. 1000번 요청에 1000개의 쿼리 발생했다. 약 20초 정도 걸렸다.

1000번의 쿼리 발생에서 약 4초 정도 차이 발생했다. 실제 서비스 24/7 다양한 유저의 요청 환경에서는 위와같은 차이는 적지 않은 성능 및 비용 발생으로 예상된다.

그럼 아예 안전하게 모든 N+1 발생 레포지토리에 fetch join 쓰면 좋을까?

fetch join 비용

정규화 된 환경에서 N+1 이 많이 발생하는 상황이라면 항상 fetch join을 사용할 것이다. 하지만 어느 순간 역정규화해서 한 테이블에서 검색하는게 fetch join 으로 인해 발생하는 join 비용보다 저렴할 상황이 발생할 수 있다. 이때는 과감히 정규화 + fetch join 을 버리고 역정규화를 선택하는게 좋다고 생각한다.

컨트롤러 각 메소드에서 요청 유저 토큰 인증 유효성 체크 코드가 중복이었다. 요청 쿼리 중복 제거를 위해 jwt 필터에서 요청시 유저유효성 확인하게 하고 각 컨트롤러에서는 토큰에서 유저 정보 받아와서 사용하도록 중복 코드 제거했다. 또한 예외처리 로직을 전부 서비스 클래스로 옮겼다. 해당 코드 수정에 대한 성능 향상 체크하기 위해 포스트 맨으로 200번 요청 테스트 했다.

이전 코드

수정 코드

200번 요청에 기존 속도보다 약 10% 정도 속도 빨라졌다.

각 모듈에 만들어진 코드들에서 중복 쿼리 제거하면 이전보다 전체 서비스 속도는 빨라질 것 같다.

meetup 프로젝트는 기능 구현에 중점을 두고 개발했다. 기능 작동되니 다음 단계는 코드의 가독성, 중복제거, shell script, 테스트 등 수정 계획이다.

한 주동안 어떻게 하면 리팩토링 할 수 있는 안목을 기를 수 있을까 찾아다녔다. 유튜브 둘러보고, 도서관에서 책들 훑고, 스프링 오픈소스 열어보기, 다른 동료의 코드리뷰 등 이것저것했다. 정말 좋은 컨텐츠가 많았지만 지금 이순간 가장 실용적이었던 것은 다른 프로젝트의 코드를 보고 그 패턴을 익히는 것이었다.

깃허브에서 java spring 으로 만들어진 백엔드 프로젝트를 찾아봤다. 보면서 내 코드와 비교하니 어디를 개선하면 좋을지 아이디어 떠올랐다. 참 많다... 이것말고도 고치고 고치고 고쳐야될 텐데 약간 기대된다.

리팩토링 계획

1. DB 정규화
   • 업로드 파일과 이미지 파일을 엔티티별로 따로 관리하고 있다. 코드도 각 엔티티별로 만들어서 3개씩 존재한다.중복있다. 엔티티와 코드를 1개로 합칠까 생각했다. 코드는 확실히 엄청 유사하니 한 모듈 내 콩통 로직으로 묶을 수 있다고 판단된다. 하지만 엔티티는 데이터의 일관성을 유지하기 위해서 그대로 두는게 낫겠다는 판단 든다.
   • 코드 수정하다가 필요성 발견되면 DB 정규화 할 것이지만, 아직은 필요성 보이지 않는다.

2. 업데이트
   • 부분 수정은 patch 메소드로 고치고, 전체 덮어쓰기는 put 쓰고, 영속성컨텍스트 더티체킹 기능 활용으로 내부에서 데이터 호출 후 수정하는 코드로 간단하게 업데이트 쪽은 수정해야겠다.

3. 설정
   • application.yml dev, prod, local 별 관리하는 환경셋팅 -실행환경별 로그 출력 aop
   • ddl 대신 sql init + shell -어드민 유저 생성
   • 테스트 환경은 h2 db 사용
   • properties묶음 관리 - (mail, oauth, jwt, db, ...)
   • properties와 config는 분리해서 관리

4. 코드 수정 및 추가 기능

• 생성자 사용시 static of 사용. pagenate 내장 클래스도 이 방법을 사용하고, 이를 사용하게 되면 생성자 생성시 내부에서 예외 체크 할 수 있다. 또한 특정 인스턴스와 관련없음을 명시해서 해당 메소드로 인한 상태 변화는 클래스만 된다는 것을 명시할 수 있어서 가독성 향상 될 것이라 생각한다.

• try-catch를 줄임. 테스트 코드를 줄일 수 있고 가독성 향상 시킬 수 있고 기능 최적화 가능하다.

• custom annotation은 기능

• social login을 spring security 없이 구현 계획

• cookie manager 쿠키의 생성 및 파싱 등 관리하는 모듈을 만드는 게 가독성 및 유지관리 효율

• stream().collect(), collectors, hashmap<> 등 collector 프레임워크를 최대한 적용. 기능 향상 및 코드 가독성

  • "dto::getter" 이런 형식 사용. 매개변수 추론인듯?

• @query fetch join

• @Lock

  • 낙관적락 비관적락

• @Transactional(readOnly = true)

• mapper (obj -> dto, dto->obj, dto 생성), 이전 코드는 각 엔티티 및 각 dto에서 맵핑 기능을 구현했지만 mapper라는 하나의 클래스에서 관리하게 하면 코드 가독성 및 유지보수 효율 -@mapper() - A -> Adto 없는 필드 기본값 셋팅가능(dto에서 @allargsconstrutor 때문인듯)

   - 셋팅안하면 못 씀
   - 참조값은 기본값 자동설정 어렵다네
   - 여러 참조값넣는데 겹치는 값 있을때 사용

  • 일일히 객체 -> 객체dto 값할당 방식 제거
  • 만들려는 DTO에 해당하는 필드에 알아서 일치되는것만 넣어줌
  • @mapping이나 인자로 넣나 동작은 같은데, 로직이 복잡해서 명시적 표현

• javadoc

• 페이징 수정

• service로직에서 R과 CUD를 분리. R은 인덱스 및 최적화 코드로 직접 관리할 수 있도록 구분해서 두고, 트랜잭션이 필요한 서비스만 따로 묶고, 트랜잭션 필요하지 않은 서비스 따로 묶어서 최소 3개의 덩어리로 구분하기

  • admin은 주로 유저 요청이 제대로 동작되지 않거나, 제제를 가한다는 전제에서 기능 추가

  • dto는 엔티티 존재 시 들어온 요청에 대한 데이터 , 응답할 데이터 최대 2개로 만들어서 domain/dto에서 관리. 엔티티 없으면 공통 dto폴더 내 개별관리.

  • 생성자 빌더패턴 사용. 유연한 매개변수를 가진 생성자를 만들 수 있음. -롬복의 빌더패턴 (cf. 기본생성자+셋터주입 , 생성자주입과 같이 객체만들기 위함이지만, 할당하는 객체 값이 어디에 되는지 가독성 향상 및 순서 어겨도됌), 빌더채턴은 내부적으로 기본생성자 생성+셋터주입 -@NoArgsConstructor(access = AccessLevel.PROTECTED) 사용해도 빌더패턴사용가능함. 두개를 같이 쓰는게 캡슐화에 안전

       -@Builder(allArgsConstructor = true) 빌더에 강조할수있음.
       -@Builder() - 매개변수 갯수가다른 객체 코드 작성할 필요 없이 사용가능.

    -@builder() 만 사용한다면, 이는 기본생성자, 모든 값을 할당하는 생성자, 일부 값만 할당하는 생성자 를 만들수있단느 것을 의미하니까 @AllArgsConstructor와 @NoArgsConstructor(access = AccessLevel.PROTECTED) 를 쓰지 않는게 낫 -이거 위 설명 틀릴수도 잇어직접테스트 해봐야됌.

  • domain에 equals, hashcode 오버라이딩 하고, isvalid 메소드 구현 및 셋터 내 사용.

  • @EqualsAndHashCode(onlyExplicitlyIncluded = true) @EqualsAndHashCode.Include

  • @embeddable ( 다른 엔티티에서 재사용할 수 있는 값 타입을 정의할 때 사용)

  • swagger 이나 javadoc 관리 모듈로 구분하면 좋을듯

  • {} 형식 데이터 관리를 적극적으로 할 필요. @JsonUnwrapped -> 멤버변수로 어떤 객체를 사용하는데, 이걸 JSON변환할때, 가령 api응답할때 가만히두면 한단계 깊이에서 객체만들어지는데 그걸 부모수준으로 끌어올려서 한단계 더 깊이 안들어가도 되게 함

• @EventListener 특정 동작발생시 마치 트리거처럼 작동되는 기능인듯. 비동기처리, 로그, 알림 등 여러기능으로사용

• 예외에 대한 메시지를 한 Enum에서 전부 관리하게 해서 코드 가독성 높이기

• 룸이나 유저 검색시 특정 글자 포함시 검색하도록

• 통계 관련 모듈

• 일반유저를 어드민 만드는 로직 추가

• cookiemanager 처럼 datemanager(jwt, room) 구현

• enum은 전부 enum폴더에서 관리하게 하고, 차라리 dto도 그렇게 해보는걸 고민

• nginx, 캐싱

• 환경변수를 중복되지 않게 따로 한번에 관리 (code, test, docker, git action)

5. 테스트 코드

• db init sql 환경
• 테스트 자체 도커
• 모듈, 컨트롤러, 도메인, 서비스 별 테스트
• mokito 단위테스트 , 스프링 통합테스트 부분 의도적 분리.

meetup 프로젝트를 시작하면서 가장 먼저 한 것은 구현할 서비스에 대한 DB 모델링이었다. 일단 브레인스토밍 하듯 필요할 것 같은 객체에 대해 나열하고, 동작할 것 같은 방식으로 관계 맺고, 이를 기준으로 엔티티 파일 생성했다.

모임이니까 당연히 유저와 모임 룸은 필요하다고 판단했다. 이것을 중심으로 유저는 업로드사진 테이블이 필요하다고 생각했다. 유저와 모임은 다대다 관계가 될 수 있으니 참여유저, 호스트유저, 리뷰, 호스트의 리뷰 작성 을 조인테이블로 만들었다. 모임 룸은 카테고리 테이블과 다대일로 관계를 만들었고 업로드파일 및 업로드 이미지 테이블들과는 일대일 관계를 만들었다. 유저의 경우 관리자 기능을 위해 공지사항 테이블과 일대다 관계를 맺고 공지사항 테이블은 이미지와 업로드파일 각 테이블과 일대일 관계를 맺었다. 모든 테이블에서 공통으로 쓰일 생성과 수정 시간에 대한 정보는 BaseEntity로 만들고 모든 테이블에서 상속받아서 구현했다.

만들면서 몇몇 의문이 떠올랐다. 유저와 룸 사이 조인테이블을 굳이 4개씩 만들 필요가 있으며, 특히 호스트 유저 테이블과 호스트유저의 댓글 테이블이 꼭 필요할까? 정규화에 어긋나는데 데이터 관리 및 보기 편할 것 같은 이유로 유저, 공지사항, 룸에 각각 업로드 내지는 이미지 테이블을 1:1로 각각 만들어줄 필요 있을까? 등 테이블 간 관계에서 각 테이블의 필요에 대한 정당성에 의문이 들었다. 설계의 기준을 적용할 수 있더라면 했겠지만 역량이 부족했다. 일단은 학습 위한 기능구현에 집중했다.

전반적으로 기능하는 프로젝트 만들고나서 다시 기존의 DB 모델링 결과를 둘러보니 무지성으로 DB 모델링 했던 기억이 떠올라 불편하다. 개선하고 싶은데 어떤 방식으로 하면 좋을지 고민중이다. 그 중 생각 및 적용해볼 만한 한가지 기준에 대해 알 수 있는 글 읽었다. 42 동료가 쓴 "42체크인 DB 설계 – 정규화와 역정규화 (https://42place.innovationacademy.kr/archives/9463) " 이 글이다.

DB 모델링 수정 기준 1 - 정규화와 역정규화

글 요약해보니 42 서울 체크인 시스템 클론코딩하면서 DB 모델링 시행착오 공유 내용이었다. 인상 깊은 내용은 다음과 같다. 무의식으로 항상 정규화하고, 객체구조와 DB 테이블 관계를 일치시켰지만, 핵심은 효율적인 문제해결이고 정규화와 역정규화는 문제해결의 과정일 뿐이라는 내용이 기억 남는다.

이 내용을 토대로 무지성으로 모델링한 테이블 구조를 살피니 다음 스탭이 보인다. 먼저는 해결하고자하는 문제가 무엇이고, 그것을 해결하기위해 빼도 될만한 부분은 어디인지 찾아봐야겠다. 그 부분을 발견한다면 역정규화는 당연히 될거고 객체와의 관계는 깨져도 괜찮겠다.

그렇지만 이 기준 말고도 여러 기준이 더 필요 할 것 같다.

다른 DB 모델링 기준은 ...

일단은 더 이것저것 알아봐야겠다.

• 일반적인 Queue와는 다르게 맨 앞과 맨 뒤에서 모두 삽입과 제거가 가능한 자료구조

정렬코드

- 버블정렬, 선택정렬, 삽입정렬, 퀵정렬, 병합정렬

    ```jsx
    #==========================
    #========= 버블정렬 =========
    print("============================\n========= 버블정렬 =========\n=============================")
    #==========================

    arr = [1,10,5,8,7,6,4,3,2,9]; print("정렬 전 =", arr)

    for i in range(len(arr)):
        for j in range(len(arr)-i-1):
            if arr[j] > arr[j+1]:
                arr[j], arr[j+1] = arr[j+1], arr[j]

    print("정렬 후 =", arr)

    #==========================
    #========= 선택정렬 =========
    print("\n\n============================\n========= 선택정렬 =========\n=============================")
    #==========================

    arr = [1,10,5,8,7,6,4,3,2,9]; print("정렬 전 =", arr)

    for i in range(len(arr)):
        min_index = i
        for j in range(i+1, len(arr)):
            if arr[min_index] > arr[j]:
                min_index = j
        arr[i], arr[min_index] = arr[min_index], arr[i]

    print("정렬 후 =", arr)

    #==========================
    #========= 삽입정렬 =========
    print("\n\n============================\n========= 삽입정렬 =========\n=============================")
    #==========================

    arr = [1,10,5,8,7,6,4,3,2,9]; print("정렬 전 =", arr)

    for i in range(1, len(arr)):
        for j in range(i, 0, -1):
            if arr[j] < arr[j-1]:
                arr[j], arr[j-1] = arr[j-1], arr[j]
            else:
                break

    print("정렬 후 =", arr)

    #==========================
    #========= 퀵정렬 =========
    print("\n\n============================\n========= 퀵정렬 =========\n=============================")
    #==========================

    arr = [1,10,5,8,7,6,4,3,2,9]; print("정렬 전 =", arr)

    def quick_sort(arr, start, end):

        if start >= end:
            return

        pivot = start
        left = start + 1
        right = end

        while left <= right:

            while left <= end and arr[left] <= arr[pivot]:
                left += 1

            while right > start and arr[right] >= arr[pivot]:
                right -= 1

            if left > right:
                arr[right], arr[pivot] = arr[pivot], arr[right]
            else:
                arr[left], arr[right] = arr[right], arr[left]

        quick_sort(arr, start, right-1)
        quick_sort(arr, right+1, end)

    quick_sort(arr, 0, len(arr)-1)

    print("정렬 후 =", arr)

    #==========================
    #========= 병합정렬 =========
    print("\n\n============================\n========= 병합정렬 =========\n=============================")
    #==========================
    #https://www.youtube.com/watch?v=zo-tz1vGutM

    arr = [1,10,5,8,7,6,4,3,2,9]; print("정렬 전 =", arr)

    def merge_sort(arr):

        if len(arr) <= 1:
            return arr

        mid = len(arr) // 2
        left = merge_sort(arr[:mid])
        right = merge_sort(arr[mid:])

        i = 0
        j = 0
        k = 0

        # left와 right를 비교하면서 arr에 정렬된 값을 넣어준다.
        while i < len(left) and j < len(right):
            if left[i] < right[j]:
                arr[k] = left[i]
                i += 1
            else:
                arr[k] = right[j]
                j += 1
            k += 1

        # left나 right가 남아있는 경우 arr에 넣어준다.
        if i == len(left):
            while j < len(right):
                arr[k] = right[j]
                j += 1
                k += 1
        else:
            while i < len(left):
                arr[k] = left[i]
                i += 1
                k += 1

        return arr

    arr = merge_sort(arr)
    print("정렬 후 =", arr)
    ```

• 해시충돌회피방법 == 해쉬 버킷에 같은 값 이미 있을때 처리법

       - open addressing - 다른 해시값에 저장
       - chaining - 해쉬 테이블이 원소 하나를 담는게 아니라 링크드 리스트를 담음.

  • 해시버킷에 키(해쉬펑션에들어가는값)를 해쉬펑선기준(가ㅁ령, %3의 나머지)으로 해쉬(해쉬펑션의 결과)와 값(밸류) 을 저장해둔상태
    • 검색 = O(1), 삽입=O(1), 삭제 =O(1)