1️⃣ 서론

현재 관리자가 웹 사이트의 Header 타이틀을 변경하고자 합니다. 이때, 해당 타이틀은 아래의 사진과 같이 왼쪽 상단에 어느 페이지든지 제공되어야 합니다. 또한 관리자가 변경하기 전에 로그인한 유저의 화면에도 변경된 타이틀이 반영되어야 합니다.

해당 Header와 관련된 정보는 아래와 같이 <h1>MySite</h1> 고정된 값으로 받고 있었습니다.

<%@ taglib uri="jakarta.tags.core" prefix="c"%>
<%@ taglib uri="jakarta.tags.fmt" prefix="fmt"%>
<%@ taglib uri="jakarta.tags.functions" prefix="fn"%>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<div id="header">
    <h1>MySite</h1>
    <ul>
        <c:choose>
            <c:when test="${empty authUser}" >
                <li><a href="${pageContext.request.contextPath}/user/login">로그인</a></li>
                <li><a href="${pageContext.request.contextPath}/user/join">회원가입</a></li>
            </c:when>
            <c:otherwise>            
                <li><a href="${pageContext.request.contextPath}/user/update">회원정보수정</a></li>
                <li><a href="${pageContext.request.contextPath}/user/logout">로그아웃</a></li>
                <li>${authUser.name}님 안녕하세요 ^^;</li>
            </c:otherwise>
        </c:choose>    
    </ul>
</div>

따라서 2가지의 방법을 사용해서 변경되는 Header의 타이틀을 반영하도록 하겠습니다.

2️⃣ 본론 1 : Interceptor

가장 먼저, Interceptor를 생각해볼 수 있습니다. Interceptor는 아래의 사진과 같이 원하는 Controller로 넘어가기 전에 거쳐가는 역할을 합니다. 따라서 Client의 요청인 URL을 보고 나서 원하는 작업이 가능합니다.

즉, 해당 사이트로 들어오는 사용자의 URL마다 title이 업데이트되었는지 확인하며 가져오는 코드를 Interceptor에 추가하여 최신의 title을 가져오도록 할 수 있습니다.

그리고 아래와 같이 spring-servlet.xml 파일에 interceptor를 추가하여 /**처럼 모든 URL마다 해당 interceptor를 적용할 수 있습니다.

해당 코드의 가장 큰 단점으로는 매번 URL 요청마다 *siteService.getSite().getTitle()이라는 코드가 실행되면서 *쿼리가 항상 실행된다는 점입니다.

따라서 이를 개선하기 위해 타이틀이 수정될 때에만 쿼리를 요청하는 방법으로 수정해야 합니다.

2️⃣ 본론 2. Interceptor + ServletContext

따라서 ServletContext의 Attribute Map에 타이틀이 있는지 확인하고 없으면 쿼리문을 실행하고, 있으면 기존의 타이틀을 가져오도록 구현할 수 있습니다. 이때, 타이틀을 siteVo라는 객체에 담아 표현하였습니다. 가장 먼저, spring-servlet.xml의 interceptors에 SiteInterceptor를 추가해줍니다.

    <!-- Interceptors -->
    <mvc:interceptors>
        <mvc:interceptor>
            <mvc:mapping path="/**"></mvc:mapping>
            <mvc:exclude-mapping path="/assets/**"></mvc:exclude-mapping>
            <bean class="mysite.interceptor.SiteInterceptor"></bean>
        </mvc:interceptor>
    </mvc:interceptors>

그리고 아래의 코드에서 본격적으로 SiteInterceptor를 작성합니다. 이때 ServletContext에 siteVo가 있는지 확인하고 없으면 쿼리를 수행하여 siteVo를 가져오는 코드를 실행합니다.

public class SiteInterceptor implements HandlerInterceptor {

    private SiteService siteService;

    public SiteInterceptor(SiteService siteService) {
        this.siteService = siteService;
    }

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception {

        SiteVo siteVo = (SiteVo) request.getServletContext().getAttribute("siteVo");

        if(siteVo == null) { // siteVo가 ServletContext's Attribute Map이 없는 경우 세팅
            siteVo = siteService.getSite();
            request.getServletContext().setAttribute("siteVo", siteVo);
        }

        return true;
    }

}

마지막으로 관리자가 타이틀과 같은 사이트 정보를 수정할 때 ServletContext의 siteVo를 수정해줍니다. servletContext.setAttribute("siteVo", siteVo)

@Auth(role = "ADMIN")
@Controller
@RequestMapping("/admin")
public class AdminController {

    private final SiteService siteService;
    private final FileUploadService fileUploadService;
  private final ServletContext servletContext;

    public AdminController(SiteService siteService, ServletContext servletContext, FileUploadService fileUploadService) {
        this.siteService = siteService;
        this.servletContext = servletContext;
        this.fileUploadService = fileUploadService;
    }

    @RequestMapping("/main/update")
    public String date(
        @RequestParam("title") String title, 
        @RequestParam("welcomeMessage") String welcomeMessage, 
        @RequestParam("description") String description, 
        @RequestParam("file1") MultipartFile file) {

        String url = Optional.ofNullable(fileUploadService.restore(file)).orElse("");

        SiteVo siteVo = new SiteVo();

        siteVo.setDescription(description);
        siteVo.setProfile(url);
        siteVo.setWelcome(welcomeMessage);
        siteVo.setTitle(title);

        siteService.updateSite(siteVo);
        servletContext.setAttribute("siteVo", siteVo);

        return "redirect:/admin";
    }
}

그리고 헤더 관련 jsp에서 해당 siteVo.title를 출력할 수 있습니다. <h1>${siteVo.title }</h1>

<%@ taglib uri="jakarta.tags.core" prefix="c"%>
<%@ taglib uri="jakarta.tags.fmt" prefix="fmt"%>
<%@ taglib uri="jakarta.tags.functions" prefix="fn"%>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<div id="header">
    <h1>${siteVo.title }</h1>
    <ul>
        <c:choose>
            <c:when test="${empty authUser}" >
                <li><a href="${pageContext.request.contextPath}/user/login">로그인</a></li>
                <li><a href="${pageContext.request.contextPath}/user/join">회원가입</a></li>
            </c:when>
            <c:otherwise>            
                <li><a href="${pageContext.request.contextPath}/user/update">회원정보수정</a></li>
                <li><a href="${pageContext.request.contextPath}/user/logout">로그아웃</a></li>
                <li>${authUser.name}님 안녕하세요 ^^;</li>
            </c:otherwise>
        </c:choose>    
    </ul>
</div>

이전에 작성한 게시글에서도 말씀드렸듯이 저희 서비스에서는 DND을 이용한 보드에 스크랩을 추가하고 이동하는 기능인 보드 기능을 추가하였습니다.

https://velog.io/@da_na/UUID-사용자에게-보여주는-URL-관련-보드의-고유키-값-구성하기

이때, 프론트 파트에서 React의 DND-kit 라이브러리를 사용하여, 보드 기능을 구현하였습니다.

아래의 링크는 저희 팀의 프론트 개발자의 관련 글입니다.

https://velog.io/@hannatoo/프로젝트-타입스크립트-프로젝트에서-jsx-import하기

따라서 보드 기능을 사용하기 위해서 어떠한 DB를 가져야 하는지 데이터 구조가 적합한지 살펴보겠습니다!

1️⃣ 본론

1. 보드 기능의 데이터 구조 살펴보기

위의 그림의 보드 DND-kit 라이브러리에서 사용하는 데이터 구조입니다.

헤딩 구조는 JSON과 같은 데이터 구조임을 알 수 있습니다.

즉, "A"는 첫번째 열을 의미하고, A열에 배열을 가지고 있으며 배열의 순서에 따라서 A열의 행이 정해집니다.

아래의 데이터 구조는 중요한 부분을 위주로 간략하게 나타내었습니다.

{"A":[
    {"scrapId":9,
    "description":"이번에 프로젝트에서 보드 관련된 기능을 제공하기로 하였습니다...",
    "pageUrl":"https://velog.io/@da_na/HTTP-API-URI-설계-프로젝트에-컨트롤-URI-설계하기","siteName":"Velog",
    "title":"[HTTP API URI 설계] 프로젝트에 컨트롤 URI 설계하기",
    "author":"da_na",
    "authorImageUrl":"https://velog.velcdn.com/images/da_na/profile/image.jpg",
    "blogName":"da_na.log",
    "dtype":"article",
    "id":"9.616648527914574"}],
"B":[
    {"scrapId":8,
    "description":"IS NULL을 사용하면 인덱스를 사용해도, 전체 table을 full scan한다는 글을 보았습니다...",
    "pageUrl":"https://velog.io/@da_na/SQL-튜닝-유저-조회-SQL-튜닝-및-성능-최적화-1","siteName":"Velog",
    "title":"[실행계획] MySQL 데이터 베이스의 실행계획(Explain)을 통한 유저 테이블 인덱스 설계/수정 1","author":"da_na",
    "blogName":"da_na.log",
    "dtype":"article",
    "id":"8.425313977182695"}],
"C":[
    {"scrapId":7,
    "description":"이전에 마지막으로 이야기한 유저 조회 최적화 방법을 적용해보겠습니다...",
    "pageUrl":"https://velog.io/@da_na/실행계획-MySQL-데이터-베이스의-실행계획Explain을-통한-유저-테이블-인덱스-설계수정-2",
    "siteName":"Velog",
    "title":"[실행계획] MySQL 데이터 베이스의 실행계획(Explain)을 통한 유저 테이블 인덱스 설계/수정 2",
    "author":"da_na",
    "blogName":"da_na.log",
    "dtype":"article",
    "id":"7.837758400701152"}]}

2. MySQL의 데이터 구조

저희 서비스는 MySQL인 RDBMS의 DB 구조를 가지고 있습니다.

따라서 RDBMS 구조로 보드의 기능을 구현하는 경우 기존에 저장되어 있는 스크랩과 보드를 연결해주는 또다른 스크랩-보드를 매핑하는 테이블을 추가하여, 보드 내의 해당 스크랩 위치 정보를 저장해야 합니다.

저희는 x를 열, y를 행을 저장하는 column을 추가해주었습니다.

위의 데이터 구조에서 몇 번째 열인지(예시 : "A"), 몇번째 행("A"열에서 배열의 몇 번째 스크랩인지)인지를 저장하면 됩니다.

예시로 scrapId가 9번인 것은 x = A, y = 1를 저장할 수 있습니다.

여기에서 살펴봐야 할 점은 장점과 단점을 살펴보고 해당 데이터 구조가 적합한지 살펴보겠습니다.

가장 큰 장점은 데이터가 중복되지 않는다는 점입니다. 스크랩의 정보가 이미 스크랩 테이블에 저장되었기 때문에 해당 scrapId만 참조하는 정보가 있으면 해당 스크랩의 정보를 따로 저장하지 않아도 됩니다.

첫 번째 단점은 보드 내에서 스크랩을 삭제하거나, 스크랩의 행을 변경하는 등 스크랩 위치를 변경하는 경우 다른 스크랩의 행과 열에 영향을 주게 됩니다. 저희 서비스는 DND를 사용하기 때문에 스크랩의 위치 변경이 매우 빈번할 것이라고 예상됩니다.

예를 들어, 아래의 표와 같이 스크랩이 보드안에 존재한다고 하면, 스크랩 ID가 1인 스크랩을 B 열에 1로 옮기겠습니다.

그러면 같은 x좌표에 있었던 스크랩들의 y좌표 모두 변경해야 합니다.

두 번째 단점은 DND-kit의 데이터 구조인 JSON으로 변경해줘야 합니다.

위의 DB의 데이터를 프론트에게 전달해주기 위해서 A : ["scrapId:1", "scrapID:2", "scrapID:3"] 이런식으로 변경해줘야 합니다. 더 나아가, 프론트에서 백엔드로 데이터를 전달해줄때에도 y좌표를 찾기 위해서 해당 배열을 돌면서 y좌표를 추출해내는 과정이 필요합니다.

그리고 마지막 단점은 JOIN문이 빈번해집니다.

현재 보드 테이블과 스크랩 테이블을 매핑하는 테이블에서 스크랩 테이블을 참조하고 있기 때문에 해당 스크랩 ID와 스크랩 테이블의 ID를 조인해야 합니다. 그리고 해당 스크랩의 메모들도 별도의 메모 테이블이 존재하기 때문에, 스크랩 테이블과 메모 테이블을 조인하는 쿼리가 발생하게 됩니다.

보드에서는 업데이트가 계속 발생하므로 조회가 몇초 간격으로 일어나는 데 이때에 JOIN문이 다수 발생합니다.

장점

• 데이터가 중복되지 않는다.

단점

• 행을 변경한 경우, 다른 스크랩의 모든 y를 변경해야 한다.
• json으로 변환해줘야 한다.
• join이 빈번하다.

따라서 이러한 여러 단점이 있기 때문에 RDBMS를 활용한 데이터 구조는 적합하지 않다고 판단하였습니다.

3. NoSQL 데이터 구조

그러면 이러한 단점을 해결하기 위해서는 어떠한 데이터 구조가 적합할지 생각하던 중에 DND-kit의 데이터 구조와 매우 유사한 NoSQL 데이터 베이스를 사용하면 따로 위치 정보를 저장할 필요없이, 그대로 저장하면 되지 않을까??라는 생각을 하게 되었습니다.

따라서 NoSQL 중 가장 대표적인 DB인 MongoDB를 사용하려고 하였습니다.

하지만, MongoDB를 사용하면, 기존의 AWS RDS가 아닌 MongoDB 용 DB를 따로 생성해야 하며 사용해본 적이 없어서 학습 시간이 소요되는 등 시간 및 비용 측면에서 부담이 되었습니다.

그리고 RDBMS보다 NoSQL 데이터 베이스는 비교적 조회 속도가 훨씬 빠르지만, 업데이트와 삽입이 느리다는 단점이 있습니다.

더 나아가, 보드에서는 하나의 보드 안에 들어가는 스크랩을 조회하는 기능과 업데이트하는 기능만 존재하기 때문에 해당 보드 안에 스크랩을 검색하거나, 정렬하는 기능을 제공할 예정이 없어서 NoSQL의 장점을 잘 살릴 수 없었습니다.

4. JSON 형태를 MySQL의 열에 저장

따라서 저희는 MySQL의 장점과 NoSQL 구조를 살리기 위해서, 원래의 MySQL의 데이터 구조에서 하나의 열만을 추가하여 해당 열에 보드의 정보인 JSON 데이터구조를 저장하기로 하였습니다.

해당 열은 @Column(columnDefinition = "TEXT") private String contents; 매우 긴 문자열 구조이기 때문에 TEXT 데이터 타입으로 데이터를 저장하였습니다.

public class Board extends BaseTimeEntity {

    @Id
    @GeneratedValue
    @Column(name = "board_id")
    private Long id;

    @Column(columnDefinition = "BINARY(16)", nullable = false, unique = true)
    private UUID uuid;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false)
    private User user;

    @Column(length = 100, nullable = false)
    private String title;

    @Column(columnDefinition = "boolean", nullable = false)
    private boolean isPublic;

    @Column(columnDefinition = "boolean default false", nullable = false)
    private boolean isShared;

    private LocalDateTime fixedDate;

    @Column(nullable = false)
    private TAG tag;

    @Column(length = 1000)
    private String description;

    @Column(columnDefinition = "TEXT")
    private String contents;

    @ColumnDefault("0")
    private Long heartCnt;

    @ColumnDefault("0")
    private Long viewCnt;

    @ColumnDefault("0")
    private Long shareCnt;
}

첫 번째 단점으로는 '스크랩 데이터가 중복된다.'입니다.

스크랩 테이블이 따로 존재하지만, 해당 contents의 컬럼에도 해당 데이터가 동시에 들어가므로 데이터가 중복될 수 있습니다.

두 번째 단점은 '유효성 검사가 되지 않는다'입니다.

해당 컬럼이 null일 수도 있고, null이 아닐 수도 있어서 null 관련된 유효성을 검사하지 못하고, 데이터 구조가 올바르게 저장되었는지도 정확하게 파악할 수 없습니다.

세 번째 단점은 '검색과 정렬 등 여러 기능을 사용하지 못한다.'입니다.

그러나, 현재 저희 보드 서비스에서는 검색, 정렬을 사용하지 않으므로 해당되지는 않습니다. 그러나, 나중에 서비스가 더 고도화되어 검색, 정렬, 개수 조회등을 구현하게 된다면 MonogDB를 사용할 계획을 하고 있습니다.

하지만 이러한 단점에도 불구하고, 빠른 기능 구현 및 새로운 DB 구축 최소화와 같이 시간 및 비용 측면에서도 우수하고, 프론트와 백엔드 모두 정보를 가공할 필요가 없는 등 여러 장점이 더 많아서 해당 방법을 사용하기로 하였습니다.

참고 자료 : https://velog.io/@effirin/DB에-JSON-저장하기

2️⃣ 결론

• 이전까지는 MySQL은 당연히 관계형 데이터구조를 가지고 있어야하고, NoSQL DB는 JSON과 같이 비관계형 데이터구조를 가지고 있으므로 두 가지를 혼합해서 사용하는 방법을 생각해보지 못했습니다. 그러나, 멘토님들의 조언과 참고자료를 바탕으로 장점과 단점을 비교해보니, 현재 저희 서비스에 적합한 DB 구조는 MySQL과 NoSQL 데이터 베이스 구조를 혼합한 구조라는 것을 알 수 있었습니다. 그러나, 여러 단점이 아직도 존재하기 때문에 완벽한 구조라고는 할 수 없지만 현재 상황에서는 빠른 개발과 배포 및 비용 측면에서 적합한 구조였고, 서비스가 더 고도화될수록 언제든지 데이터베이스 구조가 변경될 수 있기 때문에 앞으로 기능 개발을 위해서 MongoDB도 학습하여 철저하게 꼭 필요한 순간이 되면 도입할 수 있도록 대비해야겠다는 생각을 하게 되었습니다.

저희 서비스에서 이번에 새로운 기능으로 스크랩들을 정리하는 보드 기능을 추가하기로 하였습니다.

해당 보드에서 원하는 스크랩들을 추가하여, 주제에 맞는 스크랩들을 정리할 수 있습니다.

저희는 어떤 보드인지 식별해야 하므로, 유저가 직접 보는 보드의 URL에 보드의 고유 식별키를 넣는 방식을 선택하였습니다.

이때, 보드의 고유 식별키를 UUID로 할지 아니면, auto increment인 board_id로 할지를 선택해야 했습니다.

저희가 위의 사진처럼 boardUUID를 사용했는데, 왜 UUID를 선택하였는지 board_id로 하면 어떠한 문제가 발생할지 작성해보겠습니다.

1️⃣ 본론

1. Auto Increment인 board_id를 선택하면 발생하는 문제점

board_id는 아래의 코드로 생성된 id로 GeneratedValue입니다.

public class Board extends BaseTimeEntity {

    @Id
    @GeneratedValue
    @Column(name = "board_id")
    private Long id;
}

✍️ 사용자가 임의로 ID 값을 변경하여 오류 발생

이전의 스크랩 관련 API에서는 해당 스크랩을 식별하는 값으로 scrap의 id와 같이 자동으로 증가되는 키 값을 사용했습니다. 이때에는 사용자가 직접 보는 URL이 아닌 API 자체에서 사용하고 있었습니다. 따라서 사용자가 직접적으로 id의 값을 볼 수 없습니다.

사용자에게 직접 공유되는 URL 자체에 id를 넣게 되면, 사용자가 손쉽게 임의로 ID 값을 변경하여 남의 보드를 보게 되는 경우가 발생할 수 있다고 생각했습니다.

물론 남의 보드를 보게 되는 경우, 해당 보드의 유저가 아니므로 에러가 발생하는 로직이 추가는 되어 있습니다.

하지만, 이러한 경우 API에서 발생하는 오류가 많아지고, 악의적인 유저에 의해 DB에서 해당 유저의 보드인지 확인하는 로직 등 API 서버에 요청을 많이 보내어 부담을 주게 될 수도 있습니다.

✍️ DB의 데이터 예측 가능

Auto Increment를 사용하면, 저장되는 보드의 개수가 많아질 수록 숫자가 커지기 때문에 DB에 보드 데이터가 얼마나 존재하는지를 예측할 수 있습니다. 하지만, 올바르게 API 호출을 통해서 얻은 데이터 정보가 아닌 board_id 값으로 알 필요는 없다고 생각했습니다.

✍️ 단축 URL

저희 서비스에서는 보드를 다른 사람들에게 공유할 수 있는 기능도 제공할 예정입니다. 그러나, 자동으로 증가하는 키를 사용하면 URL을 단축할 때 이때에도 key의 길이가 일정하지 않고 일정한 길이의 URL로 단축할 수 없다는 판단을 하였습니다.

즉, 6자리로 줄이려고 했는데, 이미 board_id가 1~2자리이면 동일한 단축 URL을 사용할 수 없습니다.

2. UUID이란?

UUID는 네트워크 상에서 고유성이 보장되는 id를 만들기 위한 표준 규약입니다.

즉, Universally Unique IDentifier의 약어입니다.

32자리의 16진수로 표현되며, 8자리-4자리-4자리-4자리-12자리 패턴으로 되어 있습니다.

UUID는 사용자가 최대한 예측할 수 없는 값을 사용하고, DB 데이터 개수와 연관이 없습니다. 그리고 길이가 일정하기 때문에 단축 URL도 동일하게 모든 URL에 적용할 수 있습니다.

• UUID 종류
  • 버전은 1,3,4,5가 있습니다.
  • 이중 가장 많이 사용하는 버전은 1,4 버전입니다.
  • 1버전 : 타임스탬프를 기준으로 생성합니다. -> 호스트 ID, 시퀀스 번호 및 현재 시각으로 UUID를 발급합니다.
  • 4버전 : 랜덤 생성 (무작위 UUID 생성)
  • 주로 1버전보다는 4버전을 많이 사용합니다.
  • 이때, 애플에서도 UUID를 생성할 때 4 버전을 사용하는데, 보안성이 높은 랜덤 생성 UUID인 4버전을 사용합니다.

따라서 저희는 사용자가 DB를 예측하면 안되고, 보안상으로 뛰어나며 일정한 길이를 가지고 있는 4버전의 UUID를 선택하여 보드의 키를 선택하겠습니다.

참고 자료 1 : https://mattmk.tistory.com/31

참고 자료 2 : https://americanopeople.tistory.com/378

3. UUID 적용하기

Java에서의 UUID를 사용해보겠습니다.

자바에서는 java.util.UUID의 randomUUID로 4버전의 UUID를 생성할 수 있습니다.

import java.util.UUID;

public class UUIDService {
    public static UUID generateUUID() {
        return java.util.UUID.randomUUID();
    }
}

그러면 위에서 본 UUID처럼 f1c0e2e0-b2af-43e1-b4c9-3d017215c657가 생성됩니다.

이때, 위의 UUID에서 43e1에서 맨 앞의 4는 UUID의 버전을 나타냅니다.

따라서 4버전의 UUID가 정상적으로 생성되었음을 알 수 있습니다.

4. UUID 컬럼 생성하기

UUID가 겹칠 확률은 매우 매우 낮지만, unique = true를 설정하여 unique 값이 아닌 경우에는 보드를 생성할 수 없도록 설정을 하였습니다.

그리고 unique로 설정하면, 이전의 게시글에서도 볼 수 있듯이 index도 생성해주기 때문에 uuid로 보드를 찾을 때에도 조회 성능이 향상될 것입니다.

https://velog.io/@da_na/실행계획-MySQL-데이터-베이스의-실행계획Explain을-통한-유저-테이블-인덱스-설계수정-2

이때, UUID 컬럼은 columnDefinition = "BINARY(16)"으로 생성하였습니다.

UUID가 32자리의 숫자로 이루어져 있어서, CHAR(32)라고 정의할 수도 있지만, BIGINT(8바이트)보다 4배가 크기 때문에 Binary형태로 변환하면 크기를 절반 줄일 수 있고 Binary(16)으로 설정하였습니다.

참고 자료 : https://chanos.tistory.com/entry/MySQL-UUID를-효율적으로-활용하기-위한-노력과-한계

아래의 코드는 Board 테이블에 대한 코드입니다.

public class Board extends BaseTimeEntity {

    @Id
    @GeneratedValue
    @Column(name = "board_id")
    private Long id;

    @Column(columnDefinition = "BINARY(16)", nullable = false, unique = true)
    private UUID uuid;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false)
    private User user;

    @Column(length = 100, nullable = false)
    private String title;

    @Column(columnDefinition = "boolean", nullable = false)
    private boolean isPublic;

    private LocalDateTime fixedDate;

    @Column(nullable = false)
    private TAG tag;

    @Column(length = 1000)
    private String description;

    @Column(columnDefinition = "TEXT")
    private String contents;

    @ColumnDefault("0")
    private Long heartCnt;

    @ColumnDefault("0")
    private Long viewCnt;

    @ColumnDefault("0")
    private Long shareCnt;
}

2️⃣ 결론

• 이전까지는 당연히 key값은 Auto Increment한 키일거야!라는 생각을 하고 있었고, UUID를 사용하면 길이가 길어지기 때문에 성능을 고려하면 board_id로 해야 되지 않을까하는 우려가 있었습니다. 그러나, 실제로 기능을 개발하면서 여러 가지의 상황을 비교하고 문제점을 파악하였을 때, 성능도 중요하지만 보안과 사용자의 측면에서 바라볼 때 UUID가 더 적합함을 파악하고 도입하게 되었습니다. 이처럼 이론으로 배울 때보다 실제 서비스를 구축해나가면서 운영에 대한 생각을 하게 되는 시각을 배우게 되었습니다.

이전에 마지막으로 이야기한 유저 조회 최적화 방법을 적용해보겠습니다.

https://velog.io/@da_na/SQL-튜닝-유저-조회-SQL-튜닝-및-성능-최적화-1

그리고 해당 유저 조회 최적화 방법으로 얼마나 이전보다 성능이 향상되었는지를 확인해보는 시간을 가지도록 하겠습니다.

이전에 이야기한 최적화 방법은 아래와 같습니다.

1. email을 unique 키로 변경하여 MySQL Explain의 type을 const로 변경한다.
2. email에 index를 생성합니다.

• 현재 아래의 사진처럼 users의 index는 primary인 user_id만 되어있습니다.
• 따라서, email 관련 index를 추가하여 테이블 풀 스캔을 하지 않도록 할 예정입니다.

이때, 이전에는 유저가 1천만 명인 경우를 예를 들어서, 더미데이터를 생성했지만 실제 성능 향상을 비교할 때에는 실제 서비스 사용자가 될 가능성이 높은 1만명의 유저를 더미데이터로 생성하여 성능을 비교하고자 합니다.

1️⃣ 본론

1. Email을 Unique index 생성하기

이전에 이야기한 방법은 총 2가지 방법이었습니다.

1. email을 unique 키로 변경한다.
2. email 관련 index를 생성한다.

그러나, JPA에서는 unique 키로 설정해주면 index를 생성해주기 때문에 따로 index 설정은 하지 않아도 되기 때문에 아래의 코드처럼 unique = true만 추가하여 주겠습니다.

@Column(length = 320, nullable = false, unique = true)
private String email;

그러면 아래의 그림과 같이 users 테이블의 indexes에 email이 생성되었음을 알 수 있습니다.

Users 테이블 관련 JPA 전체 코드입니다.

@Getter
@NoArgsConstructor
@Entity
@ToString(exclude = "scrapList")
@Table(name = "users")
public class User extends BaseTimeEntity implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long id;

    @OneToMany(mappedBy = "user")
    private List<Scrap> scrapList = new ArrayList<>();

    @Column(length = 100, nullable = false)
    private String name;

    @Column(length = 320, nullable = false, unique = true)
    private String email;

    @Column(length = 2083, nullable = false)
    private String profileUrl;

    @Column(nullable = false)
    private Provider provider;

    private String uuid;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private Role role;
}

그리고 MySQL 데이터 베이스의 실행계획(Explain)의 결과를 확인해보겠습니다.

EXPLAIN
    SELECT
        users.user_id,
        users.created_date,
        users.deleted_date,
        users.modified_date,
        users.email,
        users.name,
        users.profile_url,
        users.provider,
        users.role,
        users.uuid
    from
        users
    where
        users.email = '7000@gmail.com'
        and users.deleted_date is null

• EMAIL UNIQUE 인덱스 전

• EMAIL UNIQUE 인덱스 후

여기에서 가장 크게 달라진 점은 type 부분입니다.

즉, 이전에 예측한 결과처럼 EMAIL을 Unique로 변경하였기 때문에 반드시 1건의 레코드만을 반환한다는 조건을 만족하게 됩니다.

따라서 Type이 ALL 테이블 풀 스캔에서 const로 변경되었습니다.

다시 한번 const의 방식을 설명해보면, const는 테이블의 레코드 건수와 관계없이 쿼리가 프라이머리 키나 유니크 키 컬럼을 이용하는 WHERE 조건절을 가지고 있으며, 반드시 1건을 반환하는 쿼리의 처리 방식입니다.

Type에는 system, const, eq_ref, ref, ref_or_null, index_merge, unique_subquery, index_subquery, range, index, all 방식이 있는데 system에서 all로 갈 수록 성능이 느려지기 때문에 all에서 const로 변경되었으므로 성능이 향상되었다고 예측할 수 있습니다.

2. 인덱스 생선 전 후의 성능 비교

성능을 비교하기 전에 속도에 영향을 주는 캐시를 지워서, 성능 비교를 정확하게 비교하고자 하였습니다.

SELECT SQL_NO_CACHE * FROM users;

SELECT
    users.user_id,
    users.created_date,
    users.deleted_date,
    users.modified_date,
    users.email,
    users.name,
    users.profile_url,
    users.provider,
    users.role,
    users.uuid
from
    users
where
    users.email = '7000@gmail.com'
    and users.deleted_date is null

그러나, 아래와 같이 현재 MySQL의 버전이 8.0.33이기 때문에, SQL_NO_CACHE 관련 Query Cache문은 MySQL 5.7.20 버전부터 Deprecated되었습니다.

SELECT SQL_NO_CACHE * FROM users;

따라서 해당 쿼리를 사용하지 않고, mysql 서버를 종료했다가 다시 실행시켜서 캐시를 직접 없애는 방법을 사용하여 시간을 측정하였습니다.

• 인덱스 생성 전 (1만건의 더미데이터)

• 인덱스 생성 후 (1만건의 더미데이터)

Actual Total Time : 12msec -> 0.000292msec 로 줄어들었음을 알 수 있습니다.

2️⃣ 결론

• 이때, 유의해야 할 점은 인덱스를 생성하면 조회 성능은 향상되지만, 삽입, 수정 성능은 떨어질 수 있습니다. 유저 테이블에 유저를 생성하고 수정하는 경우가 많은지 아니면 조회하는 경우가 많은지 판단하여 성능을 최적화해야 합니다. 하지만 이번 경우에는 회원가입을 하는 경우보다 유저가 회원을 조회하는 경우가 많기 때문에, 해당 인덱스를 추가하도록 하겠습니다.
• 스크랩 테이블과 같은 경우에는 생성이 많은지 조회가 많은지를 알 수 없기 때문에 사용자 로그 분석을 통해서 사용자들의 행동 패턴을 추적하여 성능을 최적화하는 방식으로 진행해야 될 것 같습니다.
• 이번 경우의 1만건의 더미 데이터에서는 12msec -> 0.000292msec로 줄어들었지만, 더 많은 데이터가 있을 수록 더 많은 격차가 생길 것입니다. 하지만 유저가 1만건보다 더 적을 수도 많을 수도 있기 때문에, 적절하게 생성하거나 현재 데이터를 토대로 최적화하는 것이 좋을 것이라고 생각합니다.
• 정확한 성능 비교를 위해, 비슷한 조건을 만들어 주고자 하였습니다. 따라서 성능에 영향을 줄 수 있는 캐시를 지우고 mysql 서버를 종료시켜서 비슷한 조건으로 통일시켰습니다. 이처럼 성능을 수치화해서 비교하는 것을 하기 위해서, 정확한 환경을 구축하는 것의 중요성을 다시 한 번 깨달을 수 있었습니다.

API 성능 향상을 위해서, SQL 튜닝 관련 블로그 글을 읽다가 IS NOT NULL, IS NULL을 사용하면 인덱스를 사용해도, 전체 table을 full scan한다는 말을 보게 되었습니다.

저희 서비스에서는 User Table에서 탈퇴 날짜인 deleted_date를 null로 하고, 탈퇴하면 해당 column을 업데이트하는 방식으로 탈퇴여부를 확인하고 있었습니다.

모든 API에서는 해당 회원이 유효한 회원인지 확인하기 위해서 탈퇴한 회원인지 확인하는 과정이 모두 들어갑니다.

아래의 코드는 스크랩을 검색하는 서비스 로직입니다.

이처럼 User user = userService.validateUser(email);으로 해당 회원의 유효성을 검사를 하는 과정이 있습니다.

@Transactional
public Slice<GetScrapResponse> searchScraps(String email, String keyword, Pageable pageable) {
    User user = userService.validateUser(email);

    Slice<Scrap> scrapSlice = scrapRepository.searchKeywordInScrapOrderByCreatedDateDesc(user,
            keyword, pageable);

    return scrapSlice.map(scrap -> GetScrapResponse.of(scrap,
            memoRepository.findMemosByScrapAndDeletedDateIsNull(scrap)));
}

@Transactional
public User validateUser(String email) {
    return userRepository.findByEmailAndDeletedDateIsNull(email).orElseThrow(
            () -> new NotFoundException(ErrorCode.NOT_EXISTS_MEMBER)
    );
}

즉, users 테이블에서 Email이 유저의 email 인 지와 deletedDate is null인지를 확인하는 SQL 쿼리가 나가게 됩니다.

그러면 해당 SQL 쿼리가 유저가 10000000(1천만)명인 경우에 성능이 어떻게 되는지와 해당 SQL 쿼리를 개선하기 위해서 튜닝하는 과정까지 알아보겠습니다.

1️⃣ 본론

1. 더미데이터 생성

우선, SQL 쿼리의 성능의 차이를 확실하게 비교하기 위해서는 데이터가 최대한 많이 있는 것이 좋습니다.

따라서, 유저가 10000000(1천만)명인 경우의 SQL의 성능을 확인하기 위해서, 아래의 더미데이터들을 생성하겠습니다.

이때의, 프로시저를 이용해서 생성해주었습니다.

• 프로시저는 RDBMS에서 다수의 쿼리를 하나의 함수처럼 실행하기위한 쿼리의 집합입니다.
• 장점은 하나의 요청으로 SQL 명령을 여러번 실행할 수 있습니다.
• 단점은 데이터에 대한 내용 변경시, 프로시저를 변경해야 할 가능성이 존재합니다.

참고 자료 : https://velog.io/@jkijki12/MySql-더미데이터-생성하기

DELIMITER $$

DROP PROCEDURE IF EXISTS insertUserDummyData$$

CREATE PROCEDURE insertUserDummyData()
BEGIN
    DECLARE i INT DEFAULT 1;

    WHILE i <= 10000000 DO
      IF i <= 1000000 THEN
            INSERT INTO users(user_id, created_date, modified_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), concat(i,'@gmail.com'), concat('이름', i), concat('profile_url', i), 0, 'USER');

      ELSEIF (i<= 3000000 AND i >= 1000001) THEN
            INSERT INTO users(user_id, created_date, modified_date, deleted_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), now(), concat(i,'@gmail.com'), concat('이름', i), concat('profile_url', i), 0, 'USER');

      ELSEIF (i<= 5000000 AND i >= 3000001) THEN
            INSERT INTO users(user_id, created_date, modified_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), concat(i,'@gmail.net'), concat('이름', i), concat('profile_url', i), 0, 'USER');

      ELSEIF (i <= 6000000 AND i>= 5000001) THEN
            INSERT INTO users(user_id, created_date, modified_date, deleted_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), now(), concat(i,'@gmail.com'), concat('이름', i), concat('profile_url', i), 0, 'USER');

      ELSEIF (i<= 8000000 AND i >= 6000001) THEN
            INSERT INTO users(user_id, created_date, modified_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), concat(i,'@gmail.com'), concat('이름', i), concat('profile_url', i), 0, 'USER');
      ELSE
        INSERT INTO users(user_id, created_date, modified_date, deleted_date, email, name, profile_url, provider, role)
          VALUES(i, now(), now(), now(), concat(i,'@gmail.com'), concat('이름', i), concat('profile_url', i), 0, 'USER');
      END IF;
        SET i = i + 1;

    END WHILE;
END$$
DELIMITER $$

위의 사진에서 더미 데이터들이 성공적으로 생성되었음을 확인할 수 있습니다.

2. MySQL Explain을 사용하여 현재 유저 조회 SQL 성능 살펴보기

MySQL Explain은 '데이터 베이스가 데이터를 찾아가는 일련의 과정을 사람이 알아보기 쉽게 DB 결과 셋으로 보여주는 것'입니다.

따라서, MySQL Explain 실행계획을 활용하여 기존의 쿼리를 튜닝할 수 있을 뿐만 아니라 성능 분석, 인덱스 전략 수립 등과 같이 성능 최적화에 대한 전반적인 업무를 처리할 수 있습니다.

아래의 SQL 쿼리를 MySQL Explain으로 데이터 베이스의 성능 및 쿼리를 살펴보겠습니다.

위의 SQL 쿼리를 아래의 EXPLAIN으로 나타내었습니다.

EXPLAIN
    SELECT
        users.user_id,
        users.created_date,
        users.deleted_date,
        users.modified_date,
        users.email,
        users.name,
        users.profile_url,
        users.provider,
        users.role,
        users.uuid
    from
        users
    where
        users.email = '7000000@gmail.com'
        and users.deleted_date is null

MySQL Explain 결과의 각 항목별 의미

1. id

• SELECT 쿼리 별 부여되는 식별자 값(행이 어떤 SELECT 구문을 나타내는 지를 알려주는 것)

2. select_type : 각 단위 SELECT 쿼리가 어떤 타입의 쿼리인지 표시되는 칼럼

• SIMPLE : 단순 SELECT (Union 이나 Sub Query 가 없는 SELECT 문)
• PRIMARY : UNION이나 서브쿼리를 가지는 SELECT 쿼리의 실행 계획에서 가장 바깥쪽에 있는 단위 쿼리
• UNION : UNION 쿼리에서 Primary를 제외한 나머지 SELECT, UNION과 UNION ALL 절로 생성된 임시 테이블을 의미
• DEPENDENT_UNION : UNION 과 동일하나, 외부 결과에 의존할 때 표현된다. UNION 쿼리가 내부에서 사용되었을때 표현된다.
• UNION_RESULT : UNION 쿼리의 결과물
• SUBQUERY : Sub Query 또는 Sub Query를 구성하는 여러 쿼리 중 첫 번째 SELECT문(FROM절 외에서 사용되는 서브 쿼리를 의미한다.)
• DEPENDENT_SUBQUERY : Sub Query 와 동일하나, 외곽쿼리에 의존적임 (값을 공급 받음)
• DERIVED : SELECT로 추출된 테이블 (FROM 절 에서의 서브쿼리 또는 Inline View)
• MATERIALIZED : MySQL 5.6 에서부터 추가되었으며, IN 절 내의 서브쿼리를 임시테이블로 만들어 조인을 하는 형태로 최적화를 해준다.
• UNCACHEABLE SUBQUERY : Sub Query와 동일하지만 공급되는 모든 값에 대해 Sub Query를 재처리하여 캐싱되지 못한다.
• UNCACHEABLE UNION : UNION 과 동일하지만 공급되는 모든 값에 대하여 UNION 쿼리를 재처리

3. Type : 각 테이블의 레코드를 어떻게 읽었는지에 대한 접근 방식

💡 쿼리 튜닝 시 반드시 체크해야 할 중요한 정보입니다.

• ALL(테이블 풀 스캔)을 제외한 나머지는 모두 인덱스를 사용하는 접근 방식입니다.
• system에서 ALL으로 갈수록 성능이 느려집니다.
• MySQL 옵티마이저는 이러한 접근 방법과 비용을 함께 계산해서 최소의 비용이 필요한 접근 방법을 선택해 쿼리를 처리합니다.

접근 방식

• system : 레코드가 1건만 존재하는 테이블 또는 한 건도 존재하지 않는 테이블을 참조하는 형태
• const : 테이블의 레코드 건수와 관계없이 쿼리가 프라이머리 키나 유니크 키 컬럼을 이용하는 WHERE 조건절을 가지고 있다.
  • 반드시 1건을 반환하는 쿼리의 처리 방식
• eq_ref : 조인을 할 때 Primary Key
• ref : 조인을 할 때 Primary Key 혹은 Unique Key가 아닌 Key로 매칭하는 경우
  • 동등(Equal) 조건으로 검색할 때 사용하는 접근 방식
  • ref 타입은 반환되는 레코드가 반드시 1건이라는 보장이 없으므로 const, eq_ref 보다는 느리지만 동등한 조건으로만 비교되기에 매우 빠른 레코드 조회 방법 중 하나
• ref_or_null : ref 와 같지만 null 이 추가되어 검색되는 경우
• index_merge : 두 개의 인덱스가 병합되어 검색이 이루어지는 경우
• unique_subquery : IN 절 안의 서브쿼리에서 Primary Key가 오는 특수한 경우
• index_subquery : unique_subquery와 비슷하나 Primary Key가 아닌 인덱스인 경우
• range : 특정 범위 내에서 인덱스를 사용하여 원하는 데이터를 추출하는 경우
  • 인덱스를 하나의 값이 아닌 범위로 검색하는 경우
  • 주로 “<, >, IS NULL, BETWEEN, IN, LIKE” 등의 연산자를 이용해 인덱스 검색할 때 사용
  • 일반적으로 애플리케이션의 쿼리가 가장 많이 사용하는 접근 방법
• index : 인덱스를 처음부터 끝까지 찾아서 검색하는 경우(인덱스 풀스캔)
• all : 테이블을 처음부터 끝까지 검색하는 경우(테이블 풀 스캔)
  • 가장 비효율적인 방법

4. key : 최종 선택된 실행 계획에서 사용되는 인덱스

• 쿼리 튜닝 시 key 칼럼에 의도했던 인덱스가 표시되는지 확인하는 것이 중요
• 실행 계획의 type이 ALL일 때와 같이 인덱스를 전혀 사용하지 못하면 NULL로 표시됨

5. key_len : 선택된 인덱스의 길이

• 쿼리를 처리하기 위해 다중 칼럼으로 구성된 인덱스에서 몇 개의 칼럼까지 사용했는지 표기

6. ref : 접근 방법이 ref면 참조 조건(equal 비교 조건)으로 어떤 값이 제공됐는지 표시

• 상숫값 → const, 다른 테이블의 칼럼값이면 그 테이별명과 칼럼명이 표시
• 조인 칼럼의 타입(NUMBER, VARCHAR 등)은 동일하게 일치시키는 편이 좋다.

7. rows : 실행 계획의 효율성 판단을 위해 예측했던 레코드 건수

• 쿼리를 처리하기 위해 얼마나 많은 레코드를 읽고 체크해야 하는지를 의미

8. filtered : 필터링되고 남은 레코드의 비율

• 통계 값 바탕으로 계산한 값으로 실제 결과 값과 반드시 일치하지 않는다.

9. extra : 옵티마이저가 어떻게 동작하는지에 대해 알려주는 힌트 값

• Using filesort : ORDER BY 처리가 인덱스를 사용하지 못할 때 실행 계획의 Extra 칼럼에 표시
  • 이는 조회된 레코드를 정렬용 메모리 버퍼에 복사해 퀵 소트 또는 힙 소트 알고리즘을 이용해 정렬 수행
  • ORDER BY가 사용된 쿼리의 실행 계획에서만 나타날 수 있음
  • 많은 부하를 일으키므로 가능하다면 쿼리를 튜닝하거나 인덱스를 생성하는 것이 좋음
• Using index(커버링 인덱스) : 인덱스만 읽어서 쿼리를 모두 처리할 수 있는 경우
• Using temporary : 쿼리를 처리하는 동안 중간 결과를 담아 두기 위해 임시 테이블(Temporary Table)을 생성하여 표시된 것
• Using index for skip scan : MySQL 옵티마이저가 인덱스 스킵 스캔 최적화를 사용할 경우
• Using join buffer(Block Nested Loop, hash join) : 빠른 쿼리 실행을 위해 조인되는 칼럼에는 인덱스를 생성
• Using where : MySQL 엔진에서 별도의 가공을 해서 필터링 작업을 처리한 경우

참고 자료

• https://nomadlee.com/mysql-explain-sql/
• https://zzang9ha.tistory.com/436

위의 MySQL Explain을 실행하면, 아래와 같이 결과가 나오게 됩니다.

위의 결과표를 각 항목에서 SQL 성능에서 중요한 항목인 type과 rows, extra를 해석해보겠습니다.

• type은 ALL입니다.
  • 즉, 현재는 테이블을 처음부터 끝까지 검색하는 경우(테이블 풀 스캔)입니다.
  • 따라서, 가장 비효율적인 방법이므로 성능을 최적화하는 것이 중요합니다.
• rows는 9966666입니다.
  • 실행 계획의 효율성 판단을 위해 읽고 체크해야하는 레코드 건수가 9966666로 매우 많습니다.
• extra는 Using where입니다.
  • 즉, MySQL 엔진에서 별도의 가공을 해서 필터링 작업을 처리한 경우입니다.

3. 최적화할 수 있는 방법 생각해보기

MySQL Explain 결과값을 보고 나서, 생각한 최적화 방법입니다.

따라서, 실제로 최적화되었는지 알 수 없지만, 다음 블로그글으로 실제로 최적화되는지 확인해보겠습니다.

1. *저희는 이메일이 고유값이기 때문에 반환되는 레코드가 반드시 1건이라는 보장이 있습니다. *

• const: 모든 컬럼에 대해 PK, 유니크 키 등 동등 조건으로 검색 (반드시 1건의 레코드만 반환)
• 따라서, email을 unique 키로 변경하여 MySQL Explain의 type을 const로 변경하려고 합니다.

@Getter
@NoArgsConstructor
@Entity
@ToString(exclude = "scrapList")
@Table(name = "users")
public class User extends BaseTimeEntity implements Serializable {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long id;

    @OneToMany(mappedBy = "user")
    private List<Scrap> scrapList = new ArrayList<>();

    @Column(length = 100, nullable = false)
    private String name;

    @Column(length = 320, nullable = false)
    private String email;

    @Column(length = 2083, nullable = false)
    private String profileUrl;

    @Column(nullable = false)
    private Provider provider;

    private String uuid;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private Role role;
}

2. email에 index를 생성합니다.

• 현재 아래의 사진처럼 users의 index는 primary인 user_id만 되어있습니다.
• 따라서, email 관련 index를 추가하여 테이블 풀 스캔을 하지 않도록 할 예정입니다.

2️⃣ 결론

• 이전까지는 기능 개발을 하는 데에만 집중하고, 프로젝트 기간이 2~3개월로 짧아서 최적화까지는 하지 못했습니다. 그러나, 이번달 초에 출시하고 나서 거의 기능 개발이 마무리 되어서 성능 향상을 위해서 최적화를 하기 시작하면서 새로운 부분과 SQL을 더 깊이 알 수 있는 시간이어서 아주 뜻깊은 시간이었습니다.
• 처음으로 MySQL Explain을 사용해서 현재 작성한 코드 및 쿼리의 성능을 살펴보았습니다. 당연히 email과 같은 부분이 index되어 있는 줄 알았는데, 자세히 살펴보면서 index가 user_id만 되어 있는 모습을 보고, 당연한 것은 없고 더 자세하게 살펴보아야겠다는 생각을 했습니다.
• 성능을 향상할 부분은 스크랩 조회 기능과 같이 여러 테이블을 조인하고 복잡한 쿼리만 해당되는 줄 알았습니다. 더 나아가, index는 되어 있으므로 SQL 튜닝보다는 open search와 같은 검색 오픈소스를 사용하는 것이 성능면에서는 훨씬 좋지 않을까 생각했습니다. 그러나, 바로 새로운 기술을 도입하면 새로운 기술을 배우고 DB를 만들고 비용이 들기 때문에 현재 시점에서 최대한 SQL을 최적화하여 최대한 투입되는 리소스를 줄이고 최적화가 더이상 되지 않는 경우에 새로운 기술을 도입하는 것이 좋겠다는 생각을 했습니다.

이번에 프로젝트에서 보드 관련된 기능을 제공하기로 하였습니다.

이때, 저희는 보드 관련 기능을 아래와 같이 정의하였습니다.

1. 보드 생성
2. 보드 삭제
3. 보드 수정
4. 보드 조회
5. 보드 고정

이때, 다른 기능들은 CRUD로 정의가 되지만, 5번의 보드 고정은 CRUD로 정의할 수 없었습니다.

보드 고정은 아래의 피그마의 예시와 같이 스크랩들을 담은 보드를 고정핀(별)으로 고정하게 된다면, 보드 목록 내에서 맨 위에 고정되어 맨처음에 조회할 수 있는 기능을 만들고자 하였습니다.

저는 해당 기능의 HTTP API의 URI를 설계하려고 했습니다.

그러나, HTTP 메소드는 GET, POST, PUT, PATCH, DELETE로 이루어져 있어서 리소스와 행위를 분리하는 방식을 적용해서 보드를 고정하는 행위를 HTTP의 메소드로 나타내기가 어려웠습니다.

따라서 김영한님의 인프런 HTTP 강의를 듣고 나서, 프로젝트에 어떻게 적용시켜야할지를 되돌아보았습니다!

해당 강의 주소 : https://www.inflearn.com/course/http-웹-네트워크/dashboard

1️⃣ 본론

1. HTTP API URI 설계

여기에서 가장 중요한 점은 "리소스 식별"입니다.

즉, 위에서 이야기한 보드의 기능을 살펴보면서 이야기하겠습니다.

아래의 보드 기능에서 리소스는 바로 "보드"입니다.

1. 보드 생성 -> /boards
2. 보드 삭제 -> /boards/{id}
3. 보드 수정 -> /boards/{id}
4. 보드 조회 -> /boards/{id}
5. 보드 고정 -> /boards/{id}

리소스와 행위를 분리해야 합니다.

• URI는 리소스만 식별합니다.
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리합니다.
• 위에서의 행위는 "생성, 삭제, 수정, 조회, 고정"입니다.

행위는 HTTP 메소드로 구분합니다.

주요 메소드

1. GET : 리소스를 조회합니다.
2. POST : 요청 데이터 처리, 주로 등록에 사용됩니다.
3. PUT : 리소스 대체, 해당 리소스가 없으면 생성합니다.
4. PATCH : 리소스 부분을 변경합니다.
5. DELETE : 리소스를 삭제합니다.

Control URI (컨트롤 URI)

• 단순한 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우에 사용됩니다.
• 예를 들어서, 주문에서 결제완료 -> 배달 시작 -> 배달 완료처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우에 사용될 수 있습니다.
• HTTP 주요 메소드로 나타낼 수 없는 경우에도 사용됩니다.
  • POST /orders/{orderId}/start-delivery

2. 프로젝트에 적용하기

저희 프로젝트는 API의 버전 관리를 위해서 v1을 맨 처음에 붙이기로 하였습니다.

그리고 고정하다를 "fix"로 하여 API를 설계해줍니다.

따라서 /v1/boards/{boardId}/fix로 해주었습니다.

그러나, 과연 boardId가 가운데에 API URI로 들어가는 것이 좋을까??라는 의문이 들었습니다.

가운데에 넣으면 URI의 Validation 유효성 검사를 하기가 어려워질 것 같다는 생각을 했습니다.

/v1/boards/{boardId}/fix를 한다면, boardId가 null일 때에는 boardId가 fix로 인식되어서 @NotNull을 못 잡아낼 수도 있을 것 같았습니다.

따라서 {boardId}를 마지막에 한다면, /v1/boards/fix와 /v1/boards/fix/1 처럼 null과 boardId 여부가 명확해져서 null 관련 validation 처리가 좋을 것 같다고 판단하였습니다.

/v1/boards/{boardId}/fix로 작성해도 유효성 검사가 잘 작동될지를 검토하고, URI를 선택해보겠습니다.

service 로직을 검증하는 것이 아니므로 간단하게 controller 테스트를 위해서 간단하게 아래의 코드로 시험해보겠습니다!

1. /v1/boards/{boardId}/fix

이때의 API URI만 테스트하기 위해서, POST와 PATCH로 나눠서 진행하였습니다.

따라서 해당 테스트에서는 HTTP 메소드에 크게 의미를 부여하지 않고 있습니다.

@Operation(summary = "보드 고정", description = "1개의 보드를 보드 카테고리에서 상단에 고정합니다.")
@PostMapping("/v1/boards/{boardId}/fix")
public ApiResponse<String> fixBoards(@PathVariable(required = false) @Positive @NotNull Long boardId,
        Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success("boardId : " + boardId + " email : " + email);
}

2. /v1/boards/fix/{boardId}

@Operation(summary = "보드 고정", description = "1개의 보드를 보드 카테고리에서 상단에 고정합니다.")
@PatchMapping("/v1/boards/fix/{boardId}")
public ApiResponse<String> fixedBoards(@PathVariable(required = false) @Positive @NotNull Long boardId,
        Authentication authentication) {
    String email = authentication.getName();
    boardService.fixedBoards(email, boardId);
    return ApiResponse.success();
}

이때, 두 가지의 URI 모두 @NotNull임을 확인하지 못하고 에러가 난다는 사실을 알 수 있습니다.

따라서 Controller에서는 @NotNull인 상황은 기본적으로 처리해주지 못하기 때문에 /v1/boards/{boardId}/fix와 /v1/boards/fix/{boardId}가 동일한 null 처리를 추가해주어야 하기 때문에 큰 차이가 없을 것이라고 생각했습니다.

참고 자료

• https://memo-the-day.tistory.com/108
• https://www.baeldung.com/spring-optional-path-variables

3. @NotNull 처리

위의 두 개를 @NotNull인 경우를 처리를 해보겠습니다.

@Operation(summary = "보드 고정", description = "1개의 보드를 보드 카테고리에서 상단에 고정합니다.")
@PatchMapping(value = {"/v1/boards/fix/{boardId}", "/v1/boards/fix"})
public ApiResponse<String> fixedBoards(@PathVariable(required = false) @Positive @NotNull Long boardId,
        Authentication authentication) {
    String email = authentication.getName();
    boardService.fixedBoards(email, boardId);
    return ApiResponse.success();
}

@Operation(summary = "보드 고정", description = "1개의 보드를 보드 카테고리에서 상단에 고정합니다.")
@PostMapping(value = {"/v1/boards/{boardId}/fix", "/v1/boards/fix"})
public ApiResponse<String> fixBoards(@PathVariable(required = false) @Positive @NotNull Long boardId,
        Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success("boardId : " + boardId + " email : " + email);
}

따라서, 위의 코드로 NotNull 처리가 가능합니다.

많은 예시를 찾아보았을 때, NotNull을 처리하는 경우에는 대부분 null로 들어오면 디폴트 값을 설정해주어서 에러가 나지 않게 하는 방향으로 많이 하는 방향으로 많이 했습니다.

저희 서비스는 보드 ID가 사용자마다 다르기 때문에, 임의값을 지정해줄 수 없어서 디폴트 값 처리가 필요하지 않습니다.

그러나, 아래와 같이 @NotNull인 경우에는 404 NOT FOUND 에러가 아닌 500 Internal Server Error가 나오기 때문에, Null로 입력한 클라이언트 오류가 서버 오류가 되어서 최대한으로 500에러를 안내는 것이 서버 API가 좋다고 판단하여서 아래의 사진 밑 코드로 프로젝트에 반영하기로 하였습니다!

• NotNull을 처리하지 못한 경우
• 최종적으로 프로젝트에 적용한 코드

  @Operation(summary = "보드 고정", description = "1개의 보드를 보드 카테고리에서 상단에 고정합니다.")
  @PostMapping(value = {"/v1/boards/{boardId}/fix", "/v1/boards/fix"})
  public ApiResponse<String> fixBoards(@PathVariable(required = false) @Positive @NotNull Long boardId,
        Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success("boardId : " + boardId + " email : " + email);
  }

2️⃣ 결론

• HTTP API URI 설계가 쉬운 듯 해보이지만, 클라이언트와의 약속 및 API 서버로 들어오기 위한 출입구 같은 역할을 하기 때문에 잘 설계하는 것이 매우 중요하고, 팀끼리 정하기에 따라서 달리지는 만큼 사람들마다 다르게 설계하여 명확한 기준이 없어서 어려운 부분도 있었습니다.
• 그러나, 이번 기회에 HTTP API를 다시 한 번 살펴보고 처리를 어떻게 해야할지 테스트를 해보면서 더 많이 알게 된 것 같았습니다.
• 그리고 이전에는 GET, POST, PATCH, DELETE와 같이 CRUD 기본적인 것들만 API를 구현하다보니까, 컨트롤 URI를 처음으로 사용하게 되었는데, 실제 서비스에서는 이것보다 더 훨씬 복잡한 로직을 수행하는 API를 구현할 수도 있는 만큼 이번에 했던 것들을 떠올리면서 더 좋은 설계를 위해서 힘써야겠다는 다짐을 하게 되었습니다.

이전에 저희 프로젝트의 크롬 확장 프로그램을 개발한 글을 작성한 적이 있습니다!

https://handayeon-coder.github.io/posts/크롬-익스텐션-다담다-확장-프로그램-개발-회고/

저희의 다담다 크롬 확장 프로그램을 누르면, 해당 웹 페이지에 HTML 와 CSS에 같이 들어가게 됩니다.

즉, 아래의 크롬 확장 프로그램의 구조를 살펴보면 contentscript.js를 통해서 웹 페이지에 DOM에 접근할 수 있게 되고, DOM에 원하는 HTML과 CSS을 삽입하여 사용자가 보고 있는 웹 페이지에서 확인할 수 있게 됩니다.

사진 출처 : https://developer.chrome.com/docs/extensions/mv2/architecture-overview/

사진 출처 : https://developer.chrome.com/docs/extensions/mv3/devtools/

저희 서비스는 스크랩하고 싶은 웹 페이지에서 크롬 확장 프로그램을 누르게 된다면, 아래의 사진과 같이 스크랩이 저장되고 있는 화면과 성공, 실패 여부를 알려주는 화면을 확장 프로그램을 누른 웹 페이지에 보여주게 됩니다.

그러나, 아래의 사진과 같이 원래 의도한 CSS가 제대로 적용되지 않는 모습을 확인할 수 있습니다.

이러한 원인이 무엇인지, 그리고 이를 해결하기 위해서 어떻게 해야할지를 이야기해보겠습니다.

1️⃣ 본론

1. 현재 코드 살펴보기

아래의 코드는 background.js로 크롬 익스텐션에서 특정한 웹 사이트 tabId를 통해서 해당 페이지에 JS와 CSS를 넣어주게 되는 로직입니다.

background.js 파일 일부분

function contentScriptJS(tabId, file) {
  chrome.scripting.executeScript({
    target: { tabId: tabId },
    files: [`${file}`]
  });
}

function contentScriptCSS(tabId, file) {
  chrome.scripting.insertCSS({
    target: { tabId: tabId },
    files: [`${file}`]
  })
}

function handleScrapOrHighlightResponse(url, tab, data) {
  chrome.storage.local.get('signedIn').then(async (result) => {
    if (result.signedIn) {
      contentScriptJS(tab.id, "content/content.js");
      contentScriptCSS(tab.id, "content/content.css");

      await chrome.storage.local.get('accessToken').then((result) => {
        newToken = result.accessToken;
      });

      let response = await postAPI(url, data);

      if (response === "Success") {
        contentScriptJS(tab.id, "content/successContent.js");
      } else if (response === "BR002") {
        contentScriptJS(tab.id, "content/duplicatedScrap.js");
      } else if (response === "NF002" || response === "BR001") {
        googleLogin();
      } else {
        contentScriptJS(tab.id, "content/errorContent.js");
      }
    } else {
      googleLogin();
    }
  })
}

content.css

@import url(https://cdn.jsdelivr.net/gh/moonspam/NanumSquare@2.0/nanumsquare.css);

#dadamda-popup{
  box-sizing: border-box;
  font-family: 'NanumSquare', sans-serif;
  z-index: 100001212 !important;
  position: fixed !important;
  left: 80%;
  margin: 10px 0 20px 0;
  background: #fff;
  padding: 25px;
  border-radius: 15px;
  max-width: 380px;
  width: 100%;
  box-shadow: 0 10px 15px rgba(0,0,0,0.1);
  top: 80px;
  opacity: 1;
  pointer-events: auto;
  transform:translate(-50%, -50%) scale(1);
}

#dadamda-icon {
  width: 13%;
}

#dadamda-popup :is(header){
  display: flex;
  align-items: center;
  justify-content: space-between;
}

#dadamda-popup header{
  padding-bottom: 15px;
}

#dadamda-title{
  font-size: 21px;
  font-weight: 700;
  color: #475467;
}

#dadamda-popup #dadamda-content{
  margin: 20px 0;
}

#dadamda-text1 {
  font-size: 16px;
  font-weight: 300;
  color: #98A2B3;
}

#dadamda-loader {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
}

#dadamda-progress-bar {
  position: relative;
  width: 100%;
  height: 5px;
  border-radius: 100px;
  background-color: #F8FAFC;
  overflow: hidden;
}

#dadamda-progress-bar-gauge {
  position: absolute;
  height: 5px;
  border-radius: 15px;
  background-color: #B2CCFF;
  animation-name: loading-bar;
  animation-duration: 15s;
  animation-iteration-count: infinite;
  animation-timing-function: ease-out;
}

@keyframes loading-bar {
  0% {
    width: 0;
    opacity: 1;
  }
  80% {
    width: 100%;
    opacity: 1;
  }
  100% {
    width: 100%;
    opacity: 0;
  }
}

더 자세한 코드는 https://github.com/SWM-team-forever/dadamda-chrome-extension 에서 확인할 수 있습니다.

아래의 사진과 같이 똑같은 content.js와 successContent.js를 웹 페이지에 삽입하더라도 웹 페이지 별로 적용되는 CSS가 다르기 때문에, 제가 크롬 확장 프로그램을 통해서 넣은 CSS와 HTMl이 작용되지 않습니다.

• 정상적인 경우

• 정상적으로 적용되지 않은 경우

즉, 해당 웹 페이지의 CSS의 영향을 받지 않도록 해야 합니다.

2. 해결 방법 검토하기

해당 웹 페이지에 적용된 기존 CSS의 영향을 받지 않도록 하기 위해서 해결 방법을 검토했습니다.

즉, 기존의 CSS와 새롭게 적용할 CSS 스타일 충돌을 방지해야 했습니다.

따라서 아래의 3가지의 방법 중 한 가지를 사용하기로 하였습니다.

1. 문제가 되는 부분을 !important로 처리하기
2. 기존 CSS 스타일 초기화하기
3. Shadow DOM 사용하기

2-1. 문제가 되는 부분을 !important로 처리하기

문제가 되는 부분을 !important하는 것은 어떤 웹 페이지의 CSS와 충돌날지를 모르기 때문에 제가 작성한 크롬 익스텐션의 CSS 모든 부분을 !important를 적용시켜야 했습니다.

그리고 나중에 다른 스타일을 적용하는 경우 우선순위를 정하기 어렵다는 생각을 했습니다.

따라서 모든 부분의 공통적으로 적용되어야 하는 부분인 위치 정보와 관련된 #dadamda-popup의 z-index와 position에서만 !important를 적용시켰습니다.

2-2. 기존 CSS 스타일 초기화하기

CSS 스타일 초기화는 브라우저마다 기본으로 제공하는 스타일을 기본값으로 설정해주는 세팅입니다.

따라서 크로스 브라우징 문제를 해결하기 위해서 자주 사용되는 방법입니다.

https://stackoverflow.com/questions/10608924/how-can-i-efficiently-overwrite-css-with-a-content-script

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font: inherit;
    vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
    display: block;
}

그러나, 동일하게 injected stylesheet보다 우선순위가 높은 CSS가 적용되기 때문에 CSS 스타일이 초기화되지 않고 그대로 CSS가 이상하게 적용되는 모습을 볼 수 있습니다.

더 나아가서, CSS 스타일을 초기화하면 기존의 CSS 스타일이 초기화되어 웹 페이지의 모든 CSS 스타일에 영향을 줄 수도 있어서, 해당 방법은 사용하지 않는 것이 좋다고 판단하였습니다!

위의 사진에서 중간에 회색의 선을 보면, 의도한 CSS가 적용되지 않음을 알 수 있습니다.

출처 : https://inpa.tistory.com/entry/CSS-📚-RESET-스타일-초기화-🔨

2-3. Shadow DOM 사용하기

크롬 익스텐션을 사용한 CSS를 초기화하는 방법만 찾아보다가, isolate라는 단어를 보게 되었습니다!!

따라서, 이처럼 CSS를 기존의 CSS에도 영향을 주지 않도 나만의 HTML에 CSS를 적용시키는 독립(격리)시켜야겠다고 생각했습니다.

아래의 참고 자료를 통해서 shadow DOM을 사용해야겠다고 생각했습니다.

https://stackoverflow.com/questions/12783217/how-to-really-isolate-stylesheets-in-the-google-chrome-extension

Shadow DOM이란?

• 웹 컴포넌트는 재사용할 수 있는 커스텀 HTML element를 생성하고, 해당 요소를 캡슐화하는 기술입니다.
• 캡슐화를 통해 마크업, 스타일, 동작을 외부로부터 격리하여, 웹페이지의 다른 구성 요소의 간섭을 방지할 수 있게 도와줍니다.

따라서 저의 크롬 익스텐션을 통해서 넣은 CSS와 HTML element를 Shadow Tree를 통해서 분리시켜서 외부로부터 격리하고 캡슐화를 하면 외부의 CSS의 간섭을 방지할 수 있다고 판단하였습니다.

3. Shadow DOM 적용하기

먼저, shadow DOM을 붙일 Shadow host(Shadow DOM이 붙어 있는 일반적인 DOM 노드)를 선언해주고 일반적인 DOM에 해당 Shadow host를 child로 추가해줍니다.

// 여기에서 shadowDiv는 shadow host입니다.
var shadowDiv = document.createElement("div"); 
shadowDiv.setAttribute("id", "dadamda-shadow");

document.body.appendChild(shadowDiv);

shadowRoot를 생성해줍니다.

var shadowRoot = shadowDiv.attachShadow({ mode: 'open' });

그리고 해당 shadowRoot 안에 독립될 element들(shadow tree)을 넣어줍니다.

저희는 CSS와 dadamda-popup 창을 독립시킬 예정이라서 shadowStyle이라는 CSS 스타일 코드를 만들어서 shadowRoot의 child로 넣어줍니다.

var shadowStyle = document.createElement('style');
shadowStyle.textContent = ``; // 실제 위의 content.css를 넣어주면 됩니다. 
shadowRoot.appendChild(shadowStyle);

그리고 dadamda-popup의 div를 생성하여 shadowRoot의 child로 추가해주었습니다.

var popupDiv = document.createElement("div");
popupDiv.setAttribute("id", "dadamda-popup");
shadowRoot.appendChild(popupDiv);

따라서 아래와 같이 정상적으로 원하는 CSS만 적용되는 모습을 확인할 수 있었습니다.

참고 자료

• https://tech.inflab.com/202208-shadow-root/
• https://leeproblog.tistory.com/185

2️⃣ 결론

• 이전까지는 웹 페이지마다 다르게 적용되어서, 어디에서 오류가 날지를 예측하지 못한 채로 크롬 확장 프로그램을 사용하면서 불안감을 느꼈습니다. 그러나, 이번에 드디어 모든 웹 페이지에서 동일하게 적용되어 크롬 확장 프로그램을 안정적으로 운영할 수 있게 되어서 정말 뿌듯한 시간이었습니다.
• shadow DOM이라는 새로운 용어와 DOM의 기술을 살펴보면서 새로운 웹 기술에 대해서 알 수 있게 되는 시간이었습니다.
• 이번에 CSS 스타일을 분리하자!!라는 생각으로 구글에 검색했는데, 원하는 내용을 얻기까지 많은 시간이 걸렸고, isolate라는 단어만 검색하면 바로 원하는 답을 얻을 수 있었다는 것을 알고 나서, 검색의 중요성을 다시 한 번 알게 되었습니다. 앞으로는 알고 싶은 내용을 검색하기 전에 어떠한 단어를 선정하여 검색할 지를 신중하게 선택해야겠습니다!

이전에 검색 기능을 QueryDSL로 변경하면서, 검색 기능이 무한 스크롤을 적용하고 있어서 반환값을 Slice로 반환해줘야 했습니다!

• https://velog.io/@da_na/QueryDSL-검색-기능-QueryDSL로-변경하기

위의 블로그 글에서는 QueryDSL에서 Slice의 로직을 사용해서 잘 적용하고 있습니다.

그러나, QueryDSL을 사용하는 초기에는 Slice의 값으로 반환하지만, Page를 사용해서 하는 로직으로 하고 있었습니다.

즉, Slice와 Page 사용방법을 혼동하여 로직은 Page이지만 반환값은 Slice인 혼합된 코드가 되어버렸습니다.

@Override
public Slice<Scrap> searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword,
        Pageable pageable) {
    List<Scrap> contents = queryFactory
            .selectFrom(scrap)
            .where(
                    scrap.user.eq(user)
                            .and(scrap.deletedDate.isNull())
                            .and(scrap.title.containsIgnoreCase(keyword)
                                        .or(scrap.description.containsIgnoreCase(keyword)))
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .orderBy(scrap.createdDate.desc())
                .fetch();

        JPAQuery<Long> count = queryFactory.query()
                .from(scrap)
                .select(scrap.count())
                .where(scrap.user.eq(user));

        return PageableExecutionUtils.getPage(contents, pageable, count::fetchOne);
}

그 이유는 QueryDSL을 사용하면서, Slice에 대한 작동 원리 등을 정확하게 고려하지 않았기 때문이었습니다.

Slice<Scrap> scrapSlice = scrapRepository.findAllByUserAndDeletedDateIsNullAndTitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase(user, keyword, keyword, pageRequest)

따라서 이번 기회에 Slice와 Page의 차이점을 명확하게 파악하여 무한 스크롤 기능을 구현해보겠습니다!!

1️⃣ 본론

1. Pagination vs 무한 스크롤

1-1. Pagination

페이지네이션은 페이지 단위로 분할하는 방법입니다.

즉, 아래의 사진과 같이 웹 사이트 내에서 보려는 목록이 많은 경우 페이지 단위로 분할하여 사용자가 필요한 부분만 볼 수 있도록 도와줍니다.

이미지 출처 : 네이버 검색 페이지 결과 일부

1-2. Infinite Scroll

무한 스크롤은 스크롤을 내릴때마다, 새로운 컨텐츠가 계속해서 로드되는 방식입니다.

흔히 인스타그램에서 피드를 보기 위해서 계속해서 내리면 새로운 컨텐츠가 나오는 형식입니다.

2. Page vs Slice

Spring Data JPA에서는 Pagination을 위한 두 가지의 객체인 Page와 Slice를 제공합니다.

Page와 Slice에 공통적으로 필요한 정보가 있습니다.

1. page : 페이지 번호
2. size : 한 페이지에 불러올 데이터 건수
3. sort : 정렬 조건

Pageable의 구현체인 PageRequest를 통해서 page, size, sort를 입력받음을 알 수 있습니다.

아래의 저희 프로젝트의 스크랩 Controller 중 스크랩 조회 메소드에서 Pageable은 Pagination을 위한 정보를 저장하는 객체입니다.

@GetMapping("/v1/scraps")
public ApiResponse<Slice<GetScrapResponse>> getScraps(Pageable pageable,
        Authentication authentication) {

        String email = authentication.getName();

        return ApiResponse.success(scrapService.getScraps(email, pageable));
}

위의 그림처럼 Swagger에서 Pageable이라는 객체의 page, size, sort를 입력받습니다.

2-1. Slice

https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/domain/Slice.html

2-2. Page

Page는 Slice를 상속하고 있기 때문에 Slice의 모든 메소드를 사용할 수 있습니다.

그러나, 아래의 사진과 같이 Page는 Slice에는 없는 getTotalElements, getTotalPages를 가지고 있습니다.

따라서 이러한 getTotalElements를 위해서 조회 쿼리 이후 전체 데이터 개수를 조회하는 count 쿼리가 한번 더 실행하게 됩니다.

이러한 점이 가장 큰 차이점이라고 할 수 있습니다!!

저희 프로젝트에서 스크랩을 조회하는 부분을 Slice와 Page 모두 적용해보면서 실제 실행되는 query비교해보겠습니다.

@Transactional
public Slice<GetScrapResponse> getScraps(String email, Pageable pageable) {
        User user = userService.validateUser(email);

        Sort sort = Sort.by(Sort.Direction.DESC, "createdDate");
        PageRequest pageRequest = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize(),
                sort);

        Slice<Scrap> scrapSlice = scrapRepository.findAllByUserAndDeletedDateIsNull(user,
                pageRequest).orElseThrow(() -> new NotFoundException(ErrorCode.NOT_EXISTS_SCRAP));

        return scrapSlice.map(scrap -> GetScrapResponse.of(scrap,
                memoRepository.findMemosByScrapAndDeletedDateIsNull(scrap))
        );
}

@Transactional
public Slice<GetScrapResponse> getScraps(String email, Pageable pageable) {
        User user = userService.validateUser(email);

        Sort sort = Sort.by(Sort.Direction.DESC, "createdDate");
        PageRequest pageRequest = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize(),
                sort);

        Page<Scrap> scrapSlice = scrapRepository.findAllByUserAndDeletedDateIsNull(user,
                pageRequest).orElseThrow(() -> new NotFoundException(ErrorCode.NOT_EXISTS_SCRAP));

        return scrapSlice.map(scrap -> GetScrapResponse.of(scrap,
                memoRepository.findMemosByScrapAndDeletedDateIsNull(scrap))
        );
}

위의 사진에서도 볼 수 있듯이, Page를 사용하면 count 쿼리가 실행되지만, Slice는 count 쿼리가 실행되지 않는 모습을 볼 수 있습니다.

3. Slice VS Page 중 프로젝트에 적합한 것 찾기

• Slice는 전체 데이터 개수를 조회하지 않고 이전이나 다음의 데이터가 존재하는지만을 확인할 수 있습니다.
  • 따라서 Slice는 데이터의 개수가 많은 경우 Page보다 성능상으로 유리합니다.
• Page는 전체 데이터 개수를 조회하기 때문에, 전체 페이지 개수가 필요한 경우인 상황에서 사용됩니다.
  • Page는 pagination과 같이 아래의 검색 결과 페이지 수를 보여줘야 하는 경우에도 사용됩니다.

이미지 출처 : 네이버 검색 페이지 결과 일부

저희 프로젝트에서는 스크랩의 개수를 조회하고 있지만, 무한 스크롤하고 있는 중에는 전체 스크롤의 개수를 계속해서 구하지 않아도 되고, 스크랩을 추가한 순간에만 해당 전체 스크랩 전체 개수를 부르기 때문에 count를 호출하는 API를 따로 만들어놓았습니다. 따라서 Slice를 사용하여 프로젝트에 도입하기로 하였습니다!

참고 자료

• https://colour-my-memories-blue.tistory.com/10
• https://rachel0115.tistory.com/entry/QueryDsl-Page-Slice-페이지네이션-무한-스크롤
• https://junior-datalist.tistory.com/342

4. 프로젝트에 적용하기

4-1. Page 사용하기

• 아래의 코드는 맨 위의 서론에서 언급한 코드입니다.

• 즉, JPAQuery count = queryFactory.query().from(scrap).select(scrap.count()).where(scrap.user.eq(user)) 코드가 포함되어 있다는 의미는 Page를 사용했다는 것을 의미합니다.

  @Override
  public Slice<Scrap> searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword,
        Pageable pageable) {
    List<Scrap> contents = queryFactory
            .selectFrom(scrap)
            .where(
                    scrap.user.eq(user)
                            .and(scrap.deletedDate.isNull())
                            .and(scrap.title.containsIgnoreCase(keyword)
                                        .or(scrap.description.containsIgnoreCase(keyword)))
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .orderBy(scrap.createdDate.desc())
                .fetch();
  
        JPAQuery<Long> count = queryFactory.query()
                .from(scrap)
                .select(scrap.count())
                .where(scrap.user.eq(user));
  
        return PageableExecutionUtils.getPage(contents, pageable, count::fetchOne);
  }

하지만 저희 프로젝트에서는 count 쿼리가 필요없기 때문에 Slice 방식으로 변경해주겠습니다!

4-2. Slice 사용하기

• Page와 다르게 count하는 부분이 사라졌고, 다음의 데이터가 존재하는 지만을 확인할 수 있도록 hasNextPage만 추가되었습니다.
• 그리고, 요청한 pagesize보다 1을 크게 조회하여 만약에 1개가 더 조회되었다면 다음 데이터가 존재하는 것이므로 다음 페이지의 존재 여부는 true가 되고 아니라면 false가 됩니다.

@Override
public Slice<Scrap> searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword,
        Pageable pageable) {
        List<Scrap> contents = queryFactory
                .selectFrom(scrap)
                .where(
                        scrap.user.eq(user)
                                .and(scrap.deletedDate.isNull())
                                .and(scrap.title.containsIgnoreCase(keyword)
                                        .or(scrap.description.containsIgnoreCase(keyword)))
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize()+1)
                .orderBy(scrap.createdDate.desc())
                .fetch();

        return new SliceImpl<>(contents, pageable, hasNextPage(contents, pageable.getPageSize()));
}

private boolean hasNextPage(List<Scrap> contents, int pageSize) {
        if (contents.size() > pageSize) {
                contents.remove(pageSize);
                return true;
        }
        return false;
}

2️⃣ 결론

• 무한 스크롤에 대해서 학습하다가, no-offset 방식을 사용하여 성능을 개선하는 블로그를 보게 되었습니다. 따라서 출시 이후에 사용자 수가 많아져서 스크랩의 개수가 많아진다면 조회가 매우 느려질 것으로 예상되어 성능 개선하기 위해서 no-offset 방식을 적용해야겠다는 생각을 했습니다. 이처럼 조회의 Slice와 Page 객체들의 원리와 동작을 정확하게 이해하면서, 제공되는 기본 로직뿐만 아니라 성능 개선을 위해서 어떤 부분을 수정해야 할지를 볼 수 있는 시야를 가지게 된 것 같습니다.
  • https://jojoldu.tistory.com/528
• 더 나아가서, Slice와 Page의 공식 문서를 확인하고 구현된 코드를 확인해보면서 어떠한 점이 다르고 왜 다르게 설계되었는지를 파악할 수 있게 되어서 신기하기도 했고, 공식 문서를 어떻게 봐야할지를 조금이나마 알게 되었습니다!!

이전에 Spring Security를 사용하여 JWT를 구현하였습니다.

https://velog.io/@da_na/Spring-Security-OAuth2-로그인-JWT-구현하기

따라서 JWT를 사용하여 인증과 인가가 성공적으로 구현되었고, 그대로 프로젝트 개발을 진행하였습니다.

그러다가,,, JWT 만료된 시간이 다가왔고, 만료된 JWT를 사용하여 API를 요청했을 때 아래와 같이 500 Internal Server Error가 나왔습니다. 🥲

따라서 클라이언트쪽에서는 위의 에러가 어떠한 에러인지 자세하게 알 수 없기 때문에 다시 JWT를 발급하기 위해서 로그인으로 돌아가는 과정을 추가할 수 없었습니다.

즉, JWT 예외가 발생하는 경우에 이전에 유효성 검사와 같이 에러 응답과 동일한 형태로 아래의 사진 형태처럼 resultCode와 message를 전달해야했습니다.

하지만 유효성 검사의 에러 응답 같은 경우에는 @RestControllerAdvice에서 처리가 가능했지만, 이번에 발생한 JWT 만료 에러의 경우에는 Spring Security 필터에서 발생한 에러이기 때문에 Controller 단까지 가지 않기 때문에 Filter 자체에서 에러를 처리하는 로직이 추가되어야만 했습니다.

이전에 작성한 JWT 처리하는 로직을 천천히 다시 살펴보면서 어떤 부분을 추가해야 할지를 생각해보겠습니다! 그리고 이 과정에서 발생한 문제점과 해결책을 같이 이야기하겠습니다.

1️⃣ 본론

1. JWT 만료 예외 메시지를 살펴보자.

위의 JWT 만료시에 스프링 부트 내에서 발생한 오류 기록을 보면, ExpiredJwtException이 발생한 것을 알 수 있습니다.

• 즉, JwtAuthFilter에서 Jwt 토큰의 만료기한을 확인하는 validateToken에서 만료기한이 넘으면 ExpiredJwtException 예외가 발생함을 알 수 있습니다.

2. 잘못된 JWT 만료 처리 추가

따라서 Spring Security의 Filter에서 예외가 발생할 경우, 예외를 처리해줄 부분을 추가해주어야 했습니다.

JWT 만료 처리를 하는 방법이 아래와 같이 크게 2가지로 있었습니다.

.exceptionHandling().authenticationEntryPoint(new JwtAuthenticationEntryPoint())와 .addFilterBefore(new JwtExceptionFilter(), JwtAuthFilter.class) 중에서 addFilterBefore를 사용하여 SecurityFilterChain의 filterChain에 추가하였습니다.

addFilterBefore(new JwtExceptionFilter(), JwtAuthFilter.class)

• JwtAuthFilter에서 발생한 예외를 JwtExceptionFilter에서 잡아내고, ExpiredJwtException 예외에 대한 request.setAttribute("exception", e.getMessage());를 설정하여 JwtAuthenticationEntryPoint에서 commence에서 에러 응답을 클라이언트에 보내도록 하였습니다.

@RequiredArgsConstructor
@EnableWebSecurity
public class SecurityConfig {

    private final CustomOAuth2UserService customOAuth2UserService;
    private final TokenService tokenService;
    private final OAuth2SuccessHandler oAuth2SuccessHandler;
    private final OAuth2FailureHandler oAuth2FailureHandler;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http
                .csrf().disable()
                .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .cors().configurationSource(corsConfigurationSource())
                .and()
                .headers().frameOptions().disable()
                .and()
                .authorizeRequests()
                .antMatchers("/h2-console/**", "/actuator/**",
                        "/", "/api-docs/**", "/swagger-ui/**").permitAll()
                .antMatchers("/v1/**", "/login/**").hasRole(Role.USER.name())
                .anyRequest().authenticated()
                .and()
                .logout()
                .logoutSuccessUrl("/")
                .and()
                .addFilterBefore(new JwtAuthFilter(tokenService),
                        UsernamePasswordAuthenticationFilter.class)
                .addFilterBefore(new JwtExceptionFilter(), JwtAuthFilter.class)
                .oauth2Login()
                .successHandler(oAuth2SuccessHandler)
                .failureHandler(oAuth2FailureHandler)
                .userInfoEndpoint()
                .userService(customOAuth2UserService);

        return http.build();
    }
}

@Slf4j
public class JwtExceptionFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        response.setCharacterEncoding("utf-8");

        try{
            filterChain.doFilter(request, response);
        } catch (ExpiredJwtException e){
            request.setAttribute("exception", e.getMessage());
        }
        filterChain.doFilter(request, response);

    }
}

@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
            AuthenticationException authException) throws IOException {

        response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
    }
}

@RequiredArgsConstructor
public class JwtAuthFilter extends GenericFilterBean {

    private final TokenService tokenService;

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {

        String token = tokenService.resolveToken((HttpServletRequest) request);

        if (token != null && tokenService.validateToken(token)) {
            String email = tokenService.getEmail(token);

            Authentication auth = new UsernamePasswordAuthenticationToken(email, "",
                    Arrays.asList(new SimpleGrantedAuthority("ROLE_USER")));

            SecurityContextHolder.getContext().setAuthentication(auth);
        }

        chain.doFilter(request, response);
    }
}

• JWT 만료시에도 Internal Server가 아니라, 위에서 입력한 대로 JwtAuthenticationEntryPoint에서 처리한 대로 SC_UNAUTHORIZED가 나옴을 알 수 있습니다.
• 따라서 JWT 만료의 경우, 원하는 대로 에러를 처리할 수 있게 되었습니다.

• 그런데 오히려 JWT 만료되지 않는 경우가 에러가 발생했습니다...

• NullPointerException이 null로 출력되었습니다. 그리고 Usercontroller의 getUserInfo 메소드(UserController의 29번째 줄)인 String email = authetication.getName() 부분이 null임을 알 수 있습니다. 따라서 authetication 부분이 null로 들어가고 있는 것이었습니다.
• authetication 부분은 인증을 받고 나서 SecurityContextHolder 부분에 들어가 있는 부분입니다.

• 오류를 찾기 위해서, 다시 localhost에 API를 호출하였는데, 1개의 API에 2개의 응답이 오고 있었습니다.

• 다른 API를 호출하였을 때에는 호출을 제대로 하고, 다음으로는 null을 반환하였습니다.
• 즉, 1개의 API가 2번 수행되고 있고, 1번의 수행은 제대로 되었지만, 2번째의 수행에서는 제대로 되지 않았음을 알 수 있습니다.

따라서 JwtExceptionFilter에서 filterChain.doFilter를 1개 지워졌더니, null에러가 나오지 않았지만 JWT 만료시에도 예외처리가 되지 않은 모습을 볼 수 있었습니다.

public class JwtExceptionFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        response.setCharacterEncoding("utf-8");

        try{
            filterChain.doFilter(request, response);
        } catch (ExpiredJwtException e){
            //만료 에러
            request.setAttribute("exception", e.getMessage());

        }
//        filterChain.doFilter(request, response);

    }
}

따라서, JwtExceptionFilter에서 dofilter가 2번 되어 있기 때문에 만료되지 않은 JWT를 사용하면 2번의 API가 실행됨을 알 수 있습니다. 하지만 dofilter를 지우게 되면 만료된 경우를 예외 처리할 수 없게 됩니다.

참고 자료

• https://velog.io/@jkijki12/JWT-스프링-시큐리티-JWT-예외처리하기-및-고찰
• https://ailiartsua.tistory.com/25
• https://velog.io/@hellonayeon/spring-boot-jwt-expire-exception
• https://yoo-dev.tistory.com/28

3. 성공한 JWT 만료 처리 추가 방법

exceptionHandling().authenticationEntryPoint(new JwtAuthenticationEntryPoint())

• filter에서 발생한 예외를 handling 할 수 있도록 추가해줍니다.
• 이때, 저희는 Jwt 인증 관련 예외를 처리할 예정이기 때문에, 인증 예외를 처리하는 authenticationEntryPoint를 추가해주겠습니다.
• 저희는 기본 오류 페이지가 아닌 만료된 JWT임을 알려주는 JSON 데이터 등으로 응답해야 하기 때문에, 직접 AuthenticationEntryPoint 인터페이스를 구현하고 구현체를 시큐리티에 등록하여 사용하겠습니다.
• 즉, AuthenticationEntryPoint 인터페이스는 인증되지 않은 사용자가 인증이 필요한 요청 엔드포인트로 접근하려 할 때, 예외를 핸들링 할 수 있도록 도와줍니다.

@RequiredArgsConstructor
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .csrf().disable()
                .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .cors().configurationSource(corsConfigurationSource())
                .and()
                .headers().frameOptions().disable()
                .and()
                .authorizeRequests()
                .antMatchers("/h2-console/**", "/actuator/**",
                        "/", "/api-docs/**", "/swagger-ui/**").permitAll()
                .antMatchers("/v1/**", "/login/**").hasRole(Role.USER.name())
                .anyRequest().authenticated()
                .and()
                 .logout()
                 .logoutSuccessUrl("/")
                 .and()
                 .exceptionHandling()
                 .authenticationEntryPoint(new JwtAuthenticationEntryPoint())
                 .and()
                 .addFilterBefore(new JwtAuthFilter(tokenService),
                         UsernamePasswordAuthenticationFilter.class)
                 .oauth2Login()
                .successHandler(oAuth2SuccessHandler)
                .failureHandler(oAuth2FailureHandler)
                .userInfoEndpoint()
                .userService(customOAuth2UserService);
        return http.build();
    }
}

public class JwtAuthFilter extends GenericFilterBean {

    private final TokenService tokenService;

    @Override
     public void doFilter(ServletRequest request, ServletResponse response,
             FilterChain chain) throws IOException, ServletException {

         try {
             String token = tokenService.resolveToken((HttpServletRequest) request);

             if (token != null && tokenService.validateToken(token)) {
                 String email = tokenService.getEmail(token);

                 Authentication auth = new UsernamePasswordAuthenticationToken(email, "",
                         Arrays.asList(new SimpleGrantedAuthority("ROLE_USER")));

                 SecurityContextHolder.getContext().setAuthentication(auth);
             }
         } catch (Exception e) {
             request.setAttribute("exception", e.getMessage());
         }

         chain.doFilter(request, response);
     }
}

@Service
@Slf4j
public class TokenService {

    public boolean validateToken(String token) {
        Jws<Claims> claims = Jwts.parserBuilder().setSigningKey(secretKey)
                .build().parseClaimsJws(token);

        return claims.getBody().getExpiration()
                .after(new Date(System.currentTimeMillis()));
    }
}

@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
            AuthenticationException authException) throws IOException {

        response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
    }
}

• 아래의 사진처럼 성공적으로 JWT 만료시에는 401 에러가 나오고, JWT가 만료되지 않았다면 200 성공 응답과 관련 json이 응답됨을 알 수 있습니다.

• 이때, 저희는 아래와 같이 401 에러가 아닌 400 에러와 함께 json으로 응답 메시지까지 설정해주어서 동일한 에러 응답 형태로 반환할 수 있게 되었습니다!

@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
            AuthenticationException authException) throws IOException {

        response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
        response.setCharacterEncoding("utf-8");
        response.setContentType("application/json");

        JwtErrorResponse jwtErrorResponse = new JwtErrorResponse(
                ErrorCode.INVALID_AUTH_TOKEN.getCode(), ErrorCode.INVALID_AUTH_TOKEN.getMessage());
        ObjectMapper objectMapper = new ObjectMapper();
        String result = objectMapper.writeValueAsString(jwtErrorResponse);

        response.getWriter().write(result);
    }
}

2️⃣ 결론

• 이번 계기로 JWT 도입과 같이 새로운 기능을 추가하게 되는 경우, 모든 에러 처리를 대비하는 것이 매우 중요하다는 것을 알게 되었습니다.
• 다행히도 출시 전인 개발 과정에서 에러 처리를 추가할 수 있게 되었지만, 만약에 출시 후였다면 모든 회원들에게 영향을 미칠 정도로 매우 큰 에러이기 때문에 다음부터는 더 세세하게 많은 에러의 상황을 고려하고 전반적인 에러 처리를 해야겠다는 다짐을 할 수 있게 되었습니다.
• 에러를 처리할 때에도 여러 개의 예시들을 찾아보면서 나의 프로젝트에 맞는 에러 방법을 찾아가고, 예외를 처리를 추가하다가 오히려 JWT 만료되지 않은 경우와 같이 정상적으로 동작하는 로직을 건들여서 에러를 발생할 수 있는 것처럼 추가한 상황에 대한 테스트뿐만 아니라 이전의 모든 테스트 상황도 테스트가 완벽하게 되는지 확인하고 코드를 추가해야겠다는 다짐을 한 번 더 하게 되었습니다!!

이전에 클라이언트의 요청 관련 Validation을 @Valid를 사용해서 @NotBlank, @URL, @Size 어노테이션을 사용하여 DTO에서는 유효성 검사를 했습니다.

아래의 예시는 스크랩 생성할 때, url을 입력하지 않고 "" 공백을 입력하는 경우에 에러가 발생하고 클라이언트에게 에러 메시지를 보내주게 됩니다.

이러한 유효성 검사가 있어야만 사용자의 잘못된 입력으로 인한 서버 오류(sql에 null이 들어가면 안되는 경우 등)를 미리 처리하여 시간 및 리소스 낭비 등을 방지할 수 있습니다!

@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class CreateScrapRequest {

    @NotBlank(message = "url을 입력해주세요.")
    @URL(message = "URL 형식이 유효하지 않습니다.")
    @Size(max = 2083, message = "최대 2083자까지 입력할 수 있습니다.")
    private String pageUrl;
}

따라서 아래와 같이 RestControllerAdvice인 ControllerExceptionAdvice의 handleValidationError로 잡아서 에러를 클라이언트에게 알려주었습니다.

/**
* 400 Bad Request (잘못된 요청, Validation Exception)
*/
@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(BindException.class)
private ApiResponse<Object> handleValidationError(BindException e) {
String errorMessage = e.getBindingResult().getFieldErrors().stream()
        .map(DefaultMessageSourceResolvable::getDefaultMessage)
        .collect(joining("\n"));
Sentry.captureException(e);
return ApiResponse.error(ErrorCode.INVALID, errorMessage);
}

아래와 같이 resultCode, message 형태로 response를 반환함을 알 수 있습니다.

그러면 DTO를 사용하지 않고 Parameter와 PathVariable로 입력받는 경우에 유효성 검사를 위해서 @Valid를 사용했는데 이 과정에서 발생한 오류와 해결과정을 소개해드리겠습니다!

1️⃣ 본론

1. @Validated 어노테이션, @NotBlank 사용하기

저는 처음에는 @RequestParam("keyword") 뒤에 @NotBlank를 붙여주고, Controller Class에 @Validated 어노테이션을 작성함으로써 유효성 검사를 하려고 했습니다.

@Validated
@RequiredArgsConstructor
@RestController
public class ArticleController {
    @Operation(summary = "아티클 스크랩 검색", description = "스크랩을 검색할 수 있습니다.")
    @GetMapping("/v1/scraps/article/search")
    public ApiResponse<Slice<GetScrapResponse>> searchArticles(
            @RequestParam("keyword") @NotBlank String keyword,
            Pageable pageable,
            Authentication authentication) {

        if(keyword.isBlank()) {
            throw new InvalidException("검색어를 입력해주세요.");
        }
        String email = authentication.getName();

        return ApiResponse.success(articleService.searchArticles(email, keyword, pageable));
    }
}

그러나, 위의 코드에서 ControllerExceptionAdvice의 handleValidationError로 에러를 처리하지 못하고 원하는 응답값을 얻을 수 없었습니다.

아래의 사진처럼 Internal Server Error가 나왔습니다.

원하는 형태의 에러 응답 형식이 나오지 않았습니다.

따라서 아래와 같이 if 문을 사용해서 예외 처리하는 로직을 추가했습니다.

그러면, 예외 처리 로직이 추가될 때마다 if문이 늘어나기 때문에 DTO의 @NotBlank와 같은 어노테이션이 없는지 처리를 더 간결하게 할 수 없는지 고민해보았습니다.

@Operation(summary = "스크랩 검색", description = "스크랩을 검색할 수 있습니다.")
@GetMapping("/v1/scraps/search")
public ApiResponse<Slice<GetScrapResponse>> searchScraps(
        @RequestParam("keyword") String keyword,
        Pageable pageable,
        Authentication authentication) {

    if(keyword.isBlank()) {
        throw new InvalidException("검색어를 입력해주세요.");
    }
    String email = authentication.getName();

    return ApiResponse.success(scrapService.searchScraps(email, keyword, pageable));
}

그러면 어떻게 에러를 처리해야 할까?? 유효성 검사니까 동일한 에러가 나오지 않을까?라는 의문을 가지다가 에러의 trace 응답값에 주목하게 되었습니다.

이전에는 유효성 검사 handler는 @ExceptionHandler(BindException.class)였습니다.

그러나, Parameter의 유효성 검사에서 발생한 예외는 BindException이 아닌 ConstraintViolationException였습니다.

따라서 아래와 같이 ConstraintViolationException 예외를 처리해주는 handler를 추가해주었습니다.

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(ConstraintViolationException.class)
private ApiResponse<Object> handleValidationParameterError(ConstraintViolationException e) {
    String errorMessage = e.getMessage();
    Sentry.captureException(e);
    return ApiResponse.error(ErrorCode.INVALID, errorMessage);
}

아래와 같이 원하는 형태의 에러 응답 형식을 반환할 수 있게 되었습니다.

2. @Valid와 @Validated 차이점

그러면 왜 비슷한 어노테이션에서 동일한 유효검사를 해주었는데 왜 다른 예외가 발생하고 어느 차이가 있을지 학습하고 싶었습니다.

2-1. @Valid 어노테이션 동작 원리

@Valid 어노테이션은 SR-303 표준 스펙(자바 진영 스펙)으로써 빈 검증기(Bean Validator)를 이용해 객체의 제약 조건을 검증하도록 지시하는 어노테이션입니다.

Controller 로 요청이 들어오면, Dispatcher Servlet을 걸쳐서 Controller가 호출이 됩니다. 이 과정에서 Dispatcher Servlet 에서 @Valid 를 찾아서 검증을 진행하게 됩니다.

@Valid를 통해 검증을 한 후, 만약 요구사항을 충족하지 못하여 실패한 경우 위의 두 예외를 발생시키게 됩니다.

@ModelAttribute 어노테이션으로 받은 파라미터에서 검증 오류가 발생한 경우 BindException이 발생하고 @RequestBody 어노테이션으로 받은 파라미터에서 검증 오류가 발생한 경우 MethodArgumentNotValidException를 발생시킵니다.

2-2. @Validated 어노테이션 동작 원리

@Validated는 AOP 기반으로 메소드 요청을 인터셉터하여 처리됩니다.

@Validated를 클래스 레벨에 선언하면 해당 클래스에 유효성 검증을 위한 AOP의 어드바이스 또는 인터셉터(MethodValidationInterceptor)가 등록됩니다.

그리고 해당 클래스의 메소드들이 호출될 때 AOP의 포인트 컷으로써 요청을 가로채서 유효성 검증을 진행합니다.

• 즉, validated 어노테이션은 createMethodValidationAdvice() 메서드를 통해 AOP Advice인 MethodValidationInterceptor를 등록합니다.

• 여기서 등록된 MethodValidationInterceptor가 메서드 요청을 가로채 유효성 검사를 진행하게 됩니다.

이러한 이유로 @Valid에 의한 예외는 MethodArgumentNotValidException이며, @Validated에 의한 예외는 ConstraintViolationException입니다.

참고 자료 1 : https://mangkyu.tistory.com/174

참고 자료 2 : https://kapentaz.github.io/spring/Spring-Boo-Bean-Validation-제대로-알고-쓰자/#

참고 자료 3 : https://wildeveloperetrain.tistory.com/158

참고 자료 4 : https://kdhyo98.tistory.com/80

3️⃣ 결론

• 스프링의 어노테이션을 사용하면서, 어노테이션의 동작하는 원리에 대해 더 깊이 있게 이해할 수 있는 시간이 된 것 같습니다.
• 이름과 기능이 비슷한 valid과 validated 어노테이션을 사람들의 코드를 참고하여 무조건 사용하기보다는 동작 원리를 이해하면서 나의 상황에 맞는 처리 방법을 알게 되었습니다.
• 라이브러리의 로직 및 스프링의 동작 원리(AOP, Dispatcher Servlet)을 알고 이해하며, 라이브러리가 처리하는 방식을 통해서 예외 처리 방법을 알게 된 것 같습니다.

Mediator 패턴은 멤버(Colleague)들이 Medaiator 조정자이자 중재자에게 이야기를 하고, 중재자만이 멤버에게 지시를 내리는 패턴입니다.

예를 들어서, 관제탑을 생각했을 때 여러 비행기의 조종사가 대화하지 않고 관제탑과 이야기를 하는 것과 유사하다고 생각할 수 있습니다.

따라서 위의 패턴 다이어그램에서 볼 수 있듯이 여러 Colleague가 있고 서로 이야기하지 않고 Mediator와 연결되어 있음을 알 수 있습니다.

Colleague 쪽에서는 Mediator를 설정(setMediator)해줘야 하고, Mediator는 Colleauge들을 설정(생성)(createColleagues)해줘야 합니다.

colleagueChanged는 Colleague들이 Mediator에게 이야기를 하는 메소드이고, controlColleague는 Mediator가 내린 지시를 따르는 과정입니다.

즉, N:M 관계를 N:1 관계로 바꾸어줍니다. (이때, 1은 Mediator, N은 Colleague입니다.)

하지만 여기에서 혼동하지 말아야 할 점은 Colleague들은 서로 이야기를 하고 싶어한다는 점입니다.

그러면 Mediator는 언제 사용될까요??

주로 다수의 객체 사이에서 조정해야 할 때 사용됩니다.

Mediator 패턴은 단순화하다라는 챕터에 있습니다.

이처럼 Colleague들이 서로 조정해야 하는 복잡한 상황에서 Mediator를 통해서 소통하도록 단순화할 수 있음을 의미합니다.

public interface Mediator {
    public abstract void createColleagues();
    public abstract void colleagueChanged();
}

public interface Colleague {
    public abstract void setMediator(Mediator mediator);
    public abstract void setColleagueEnabled(boolean enabled);
}

public class ConcreteColleague1 implements Colleague {
    private Mediator mediator;

    public ConcreteColleague1() {}

    @Override     // Mediator를 설정한다.
    public void setMediator(Mediator mediator) {
        this.mediator = mediator;
    }

    @Override     // Mediator에서 지시한다.
    public void setColleagueEnabled(boolean enabled) {
        setEnabled(enabled);
    }
}

public class ConcreteColleague2 implements Colleague {
    private Mediator mediator;

    public ConcreteColleague2() {}

    @Override     // Mediator를 설정한다.
    public void setMediator(Mediator mediator) {
        this.mediator = mediator;
    }

    @Override     // Mediator에서 지시한다.
    public void setColleagueEnabled(boolean enabled) {
        setEnabled(enabled);
    }

    @Override
    public void textValueChanged(TextEvent e) {
        // 문자열이 바뀌면 Mediator에 알린다.
        mediator.colleagueChanged();
    }
}

public class ConcreteMediator implements Mediator {
    private ConcreteColleague1 colleague1;
    private ConcreteColleague2 colleague2;

    public ConcreteMediator() {
        createColleagues();
        colleagueChanged(); // Colleague 생성
    }

    @Override
    public void createColleagues() { 
        //Colleague를 생성한다. (Mediator가 관리할 멤버를 생성) 
        colleague1 = new ConcreteColleague1();
        colleague2 = new ConcreteColleague2();

        // Mediator 설정
        colleague1.setMediator(this);
        colleague2.setMediator(this);
    }

    @Override
    public void colleagueChanged() {
        if(colleague1.getState()) {
            colleague2.setColleagueEnabled(false);
        } else { 
            colleague2.setColleagueEnabled(true);
        }
    }
}

ConcreteMediator에서 가장 주목해야 할 부분은 colleagueChanged입니다!

여기에서는 ConcreteColleague들이 서로 통신해야 하는 부분을 Mediator에서 파악하고 지시를 내리는 부분이기 때문입니다.

지금은 ConcreteColleague가 2개라서 복잡해보이지는 않지만 ConcreteColleague 클래스가 늘어날 수록 colleagueChanged 메소드의 처리 부분이 늘어나서 더 복잡한 처리를 수행해줄 수 있습니다.

아래의 시퀀스 다이어그램에서도 확인할 수 있듯이 ConcreteMediator에게 ConcreColleague가 이야기하고 지시를 내리는 부분을 확인할 수 있습니다.

하지만 ConcreteColleague1은 특정한 상황에 의존하는 코드가 없어서 다른 클래스에서 재사용하기 쉽지만, ConcreteMediator는 if, else 문과 같이 특정한 상황을 처리하고 대처하는 코드가 작성되어 있어서 재사용하기 어렵고 애플리케이션에 대한 의존성이 높다고 할 수 있습니다.

PART 2. 높은 Coupling 줄이기

PART 1에서 Mediator 패턴은 N:M의 관계를 N:1 관계로 바꿔주는 패턴이라고 이야기를 했습니다.

그러면 N:M 관계이면 어떠한 문제가 발생할까요??

바로, 높은 Coupling이 발생한다는 점입니다.

높은 Coupling은 서로 서로를 의존하기 때문에 다른 한개가 바뀌면 다른 것도 영향을 크게 받습니다.

여러 프로그램에서는 높은 coupling 같은 경우 complie이 안되는 경우도 있습니다.

따라서 Spring에서는 DI 의존성 주입을 통해서 이러한 Coupling을 낮추고 있습니다.

이때, DI 의존성 주입 방법으로 setter 주입이 있습니다.

이처럼 Mediator 패턴에서도 setMediator라는 메소드를 통해서 ConcreteColleauge들과 Mediator를 연결하여 Coupling을 낮출 수 있습니다.

public class ConcreteColleague1 implements Colleague {
    private Mediator mediator;

    public ConcreteColleague1() {}

    @Override     // Mediator를 설정한다.
    public void setMediator(Mediator mediator) {
        this.mediator = mediator;
    }

    @Override     // Mediator에서 지시한다.
    public void setColleagueEnabled(boolean enabled) {
        setEnabled(enabled);
    }
}

Visitor 패턴은 "방문자"라는 의미로 데이터 구조와 처리를 분리합니다.

즉, 데이터 구조 안을 돌아다니면서 처리할 ‘방문자’를 나타내는 클래스가 있습니다.

그리고 새로운 처리를 추가하고 싶을 때는 새로운 방문자를 만들면 됩니다.

데이터 구조 쪽에서는 방문자를 받아들일 수 있습니다.

여기에서 가장 주목해야 할 점은 Visitor와 Element가 연결되어 있는 구조가 아닌 끊어있는 구조라는 점입니다.

따라서 Visitor 패턴은 ConcreteElementA 클래스나 ConcreteElementB 클래스의 부품으로서의 독립성을 높여줄 수 있습니다.

만약에 Visitor 패턴을 사용하지 않고 ConcreteElementA 클래스에 처리할 내용을 작성하는 경우 새로운 처리를 추가하고 싶을 때마다 ConcreteElementA 클래스의 내용을 수정해야 합니다.

아래의 코드는 visitor 패턴을 사용하지 않고 accept 메소드에 처리할 내용을 작성하는 경우입니다.

이때, 처리할 내용은 간단하게 출력하는 함수로 대체해주겠습니다.

public class ConcreteElementA extends Element {

    public ConcreteElementA() {}

    @Override
    public void accept() {
        System.out.println("hello");
    }
}

• accpet 메소드에서 hello 뿐만 아니라 hello2, hello3를 출력하는 처리를 추가하면 아래와 같이 ConcreteElementA를 수정해주게 됩니다!!

public class ConcreteElementA extends Element {

    public ConcreteElementA() {}

    @Override
    public void accept() {
        System.out.println("hello");
        System.out.println("hello2");
        System.out.println("hello3");
    }
}

하지만 Visitor 패턴을 사용하게 된다면 아래의 코드와 같이 나타낼 수 있습니다.

public class ConcreteElementA extends Element {

    public ConcreteElementA() {}

    @Override
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class ConcreteVisitor extends Visitor {

    @Override
    public void visit(ConcreteElementA concreteElementA) {
        System.out.println("hello");
    }
}

• 처리를 추가하고 싶은 경우, ConcreteElementA는 건들이지 않은 채로 ConcreteVisitor 클래스의 visit 메소드를 수정해주면 됩니다!

public class ConcreteElementA extends Element {

    public ConcreteElementA() {}

    @Override
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class ConcreteVisitor extends Visitor {

    @Override
    public void visit(ConcreteElementA concreteElementA) {
        System.out.println("hello");
        System.out.println("hello2");
        System.out.println("hello3");
    }
}

이처럼 처리를 데이터 구조와 분리할 수 있기 때문에, 데이터 구조는 수정하지 않고 처리를 담당하는 visit 클래스만 수정하면 되기 때문에 역할 분리가 명확하여 유지 보수가 용이해질 수 있습니다.

PART 2. OCP 개방 폐쇄 원칙

OCP는 개방 폐쇄 원칙으로 확장에 대해서는 열려있고, 수정에 대해서는 닫혀있는다는 것을 의미합니다.

즉, Visitor 패턴을 사용하면 OCP를 지킬 수 있게 됩니다.

PART 1에서도 살펴본 예시로도 처리의 내용을 추가하는 확장에 대해서도 ConcreteElementA의 입장에서는 아무런 수정이 없었지만 처리의 내용이 추가되어서 확장에 대해서는 열려 있다는 것을 살펴보았습니다!

하지만, OCP는 Element에만 해당하는 이야기입니다.

PART 1에서 Visitor 패턴을 사용하여 처리의 내용을 추가하는 과정에서 ConcreteElementA는 수정하지 않았지만, ConcreteVisitor는 확장을 하기 위해서 수정을 했기 때문입니다.

더 나아가서 Visitor는 Element 인터페이스를 구현하는 클래스(ConcreteElementA, ConcreteElementB)가 늘어날 수록 아래와 같이 Visitor 인터페이스와 ConcreteVisitor 클래스의 메소드가 늘어나게 됩니다.

public class ConcreteElementA extends Element {

    public ConcreteElementA() {}

    @Override
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class ConcreteElementB extends Element {

    public ConcreteElementB() {}

    @Override
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class ConcreteVisitor extends Visitor {

    @Override
    public void visit(ConcreteElementA concreteElementA) {
        System.out.println("hello");
        System.out.println("hello2");
        System.out.println("hello3");
    }

    @Override
    public void visit(ConcreteElementB concreteElementB) {
        System.out.println("Bye");
        System.out.println("Bye2");
        System.out.println("Bye3");
    }
}

즉, Visitor는 모든 Element를 알고 있어야 합니다.

그리고 모든 Element의 상세 내용을 정의해야 합니다.

그러므로 Visitor 패턴은 Element의 관점에서는 OCP를 지킨다고 할 수 있지만, Visitor의 관점에서는 OCP를 지키지 않는다고 이야기할 수 있습니다.

따라서 이러한 장단점을 명확하게 파악하여 패턴을 더 적합한 상황에 적용해야함을 알 수 있습니다!!

Strategy 패턴은 해당 이름 뜻에서도 알 수 있듯이 전략과 관련된 패턴입니다.

즉, 전략(알고리즘)을 바꿔서, 같은 문제를 다른 방법으로 해결하기 쉽게 만들어주는 패턴입니다.

여기에서 살펴보아야 할 것은 Context 클래스입니다.

Context 클래스가 전략(알고리즘)을 선택적으로 교체할 수 있도록 합니다.

전략(알고리즘)을 선택적으로 교체해야 하는 상황을 살펴보겠습니다.

1. 알고리즘을 개량해서 더 빠르게 만들고 싶은 경우

• Strategy패턴을 이용하면, Strategy 역의 인터페이스를 변경하지 않고, ConcreteStrategy역만 수정하면 됩니다.

2. 원래 알고리즘과 개량한 알고리즘의 속도를 비교하고 싶은 경우

3. 알고리즘의 동작이 런타임에 실시간으로 교체 되어야 하는 경우

• 만약에 메모리가 적은 환경인 경우 속도는 느리지만, 메모리를 절약하는 전략을 사용하고, 메모리가 많은 환경에서는 속도가 빠르지만 메모리를 더 쓰는 전략을 사용할 수 있습니다.

여기에서 가장 중요하게 Strategy 패턴를 사용해야 하는 경우는 3번과 같이 알고리즘의 동작이 런타임에 실시간으로 교체되어야 하는 경우라고 할 수 있습니다.

즉, 객체가 할 수 있는 행위들 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴입니다. (출처 : https://victorydntmd.tistory.com/292)

PART 2. Strategy 패턴 다이어그램과 Builder 패턴 다이어그램 비교

1. Strategy 패턴 다이어그램

2. Builder 패턴 다이어그램

이전 글에서 Builder 패턴에 대해서 다루어보았습니다.

만약에 Builder 패턴에서 Client가 없다면, Strategy 패턴 다이어그램과 Builder 패턴 다이어그램은 굉장히 유사한 구조라고 할 수 있습니다.

따라서, 해당 패턴을 비교하기 위해서는 Context와 Director의 역할을 잘 생각하면 됩니다.

• Context 클래스가 전략(알고리즘)을 선택적으로 교체할 수 있도록 한다.
• director 클래스는 builder의 복잡도를 낮추기 위한 것입니다.

PART 3. Strategy 패턴이 사용되는 예시

• Collections의 sort() 메서드에 의해 구현되는 compare() 메서드에서 사용됩니다.

비교하려는 전략 알고리즘을 변경하여, 원하는 전략으로 선택적인 교체가 가능합니다.

class StrategyInJava {
    public static void main(String[] args){
        List<Integer> numbers = new ArrayList<>();
        numbers.add(1);
        numbers.add(2);

        Collections.sort(numbers, new Comparator<Integer>()){
            @Override //비교하는 전략 알고리즘을 지정하여, 전략 객체 할당
            public int compare(Integer o1, Integer o2) {
                return o1 - o2;
            }
        }
    }
}

• 더 나아가서, 위의 예시뿐만 아니라 시간을 비교해서 정렬하는 경우와 같이 여러 상황에 맞추어서 전략을 변경할 수도 있습니다.

출처 1 : https://inpa.tistory.com/entry/GOF-💠-전략Strategy-패턴-제대로-배워보자#comparator

출처 2 : https://m.blog.naver.com/writer0713/221896418002

먼저, 생성 패턴 중 하나인 builder 패턴에 대해서 알아보도록 하겠습니다!

build라는 영어의 뜻에서도 이 패턴을 왜 사용하는지 추측해볼 수도 있습니다.

• build는 구조를 갖춘 구조물을 짓다를 의미합니다.

• 구조물을 짓기 위해서는 매우 복잡한 과정을 차례 차례 수행해야합니다.

따라서, builder 패턴은 복잡한 객체의 생성 과정을 위해서 만들어진 패턴입니다.

여기에서 가장 주목해야 하는 것은 Director 클래스입니다.

위의 builder 패턴 다이어 그램에서 client는 director 클래스를 사용해서, 단지 construct 메소드만 호출하면, director 클래스가 알아서 복잡한 과정(buildPart1, buildPart2)를 수행해서 인스턴스를 만들어줍니다.

이처럼 director 클래스는 builder의 복잡도를 낮추기 위한 것입니다.

따라서, 복잡도가 높은 로직을 만들 때에는 builder 패턴을 사용하면 client가 쉽게 사용할 수 있어서 유용하게 사용됩니다.

public class Director {
    private Builder builder;

    //생성자
    public Director(Builder builder) { 
        //Builder 클래스는 추상 클래스 -> 인스턴스 생성 X
        //Director의 생성자에 실제로 전달되는 것 = Builder의 하위 클래스의 인스턴스
        this.builder = builder;
    }

    public void construct() {
        builder.builPart1("Greeting");
        builder.buildPart2("일반적인 인사");
    }
}

public class Main {
    public static void main(String[] args) {
        Builder b = (Builder) o;
        Director director = new Director(b);
        director.construct();
    }
}

PART 2. lombok @Builder

위의 패턴과 동일한 이름을 가진 스프링 부트의 어노테이션이 있습니다.

여기에서 언급하는 GoF의 디자인 패턴 중 Builder 패턴과 완벽하게 동일하지는 않지만, 해당 이름과 연관성이 있습니다.

먼저, @Builder 어노테이션을 주로 사용하는 이유에 대해서 언급해 보겠습니다.

@Builder 어노테이션은 클래스의 선택적 매개변수가 많은 상황에서 가장 유용하게 사용됩니다.

아래의 코드처럼 여러 속성값이 가지고 있는데, 인스턴스 생성시에 어떤 속성값은 들어가야 하고, 안 들어가는 속성값을 따로 명시해줘야 하는 경우 여러 생성자를 명시해주기 어렵습니다.

@Builder
public class Person {

    private String username;
    private int age;
    private String area;
    private String phoneNumber;
    private Long money;
    private int cars;
}

따라서 @Builder 어노테이션을 사용하면, 아래의 코드처럼 자동적으로 여러 생성자를 생성해줍니다.

만약에, username을 지정해주지 않더라도 해당 값을 제외한 생성자를 사용할 수 있습니다.

public class Person {
    private String username;
    private int age;
    private String area;
    private String phoneNumber;
    private Long money;
    private int cars;

    Person(String username, int age) {
        this.username = username;
        this.age = age;
    }

    public static Person.PersonBuilder builder() {
        return new BuildMe.BuildMeBuilder();
    }

        //Builder 클래스
    public static class PersonBuilder {
        private String username;
        private int age;

        BuildMeBuilder() {
        }

        public Person.PersonBuilder username(String username) {
            this.username = username;
            return this;
        }

        public Person.PersonBuilder age(int age) {
            this.age = age;
            return this;
        }

        public Person.PersonBuilder area(String area) {
            this.area = area;
            return this;
        }

        public Person.PersonBuilder phoneNumber(String phoneNumber) {
            this.phoneNumber = phoneNumber;
            return this;
        }

        public Person.PersonBuilder money(Long money) {
            this.money = money;
            return this;
        }

        public Person.PersonBuilder cars(int cars) {
            this.cars = cars;
            return this;
        }

        public Person build() {
            return new Person(this.username, this.age, this.area, this.phoneNumber, this.money, this.cars);
        }
    }
}

이와 같이 속성값이 많은 것도 복잡도가 높다는 측면에서 보면, 속성값이 많은 클래스의 인스턴스를 쉽게 생성해주기 때문에 복잡도가 높은 클래스를 사용하기 편리하게 만들어 줍니다.

기존에는 JPA를 사용하여 스크랩의 검색을 원하는 로직을 구현하려고 했습니다.

그러나, 원래 의도는 타이틀이나 디스크립션(설명)에서 keyword가 있는 삭제되지 않고 사용자만의 스크랩을 찾는 로직이었습니다.

따라서 위의 로직을 지키기 위해서 생성되어야 하는 sql문의 조건을 살펴보겠습니다.

1. 삭제되지 않는 스크랩(DeletedDateIsNull)이어야 한다.
2. 사용자의 스크랩이어야 한다. (User)
3. 대소문자를 무시하고 타이틀이나 디스크립션(설명)에서 keyword가 있어야 한다. (TitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase)

따라서 아래와 같이 코드를 작성했습니다!

@Transactional
public Slice<GetScrapResponse> searchScraps(String email, String keyword, Pageable pageable) {
    User user = userService.validateUser(email);

    Sort sort = Sort.by(Sort.Direction.DESC, "createdDate");
    PageRequest pageRequest = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize(),
            sort);

    Slice<Scrap> scrapSlice = scrapRepository
                .findAllByUserAndDeletedDateIsNullAndTitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase(
                        user, keyword, keyword, pageRequest)
                .orElseThrow(() -> new NotFoundException(ErrorCode.NOT_EXISTS_SCRAP));

    return scrapSlice.map(GetScrapResponse::of);
}

그러나, 아래와 같이 실제로 작동되는 로직은 제가 의도한 로직이 아니라 타이틀이나 디스크립션에 or문이 적용되지 않고 아래로 내려갑니다.

따라서 삭제된 scrap에서도 keyword가 검색되는 로직이 됩니다...🥲

더 나아가서, jpa에서 주어진 sql문을 사용하면 메소드 명이 엄청나게 길어져서 조건을 붙일 때마다 길어져서 메소드를 파악하기 어렵습니다. scrapRepository.findAllByUserAndDeletedDateIsNullAndTitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase(user, keyword, keyword, pageRequest)

그리고 keyword를 2번 입력해주었는데 sql문의 조건이 4개이기 때문에 각각의 조건을 맞추어주기 위해서 동일한 keyword임에도 불구하고 두 번 반복해서 중복이 발생하게 된다는 문제점이 있습니다.

그러면 이러한 문제를 해결하기 위해서 도입한 방법을 소개하겠습니다!!

1️⃣ 본론

먼저 중요한 점은 의도한 로직을 지키기 위해서는 타이틀이나 디스크립션에 or문이 먼저 적용되어야 하는 우선순위가 있습니다.

즉, 완벽하게는 sql을 작성하지는 않았지만 아래와 같이 scrap의 타이틀과 디스크립션에서 키워드가 있는지 판단하는 sql문이 ( ) 소괄호 부분이 먼저 실행되어야 합니다.

select scrap.blog_name from scrap where scrap.user_id =? and scrap_deleted_date is null and (scrap.title like %keyword% or scrap.description like %keyword%)

이렇게 우선순위를 정해야 하거나, 검색 같이 조건문과 로직이 복잡한 경우에는 2가지 방식으로 해결할 수 있습니다.

1. ✍️ 직접 Query문 작성하기

• Java Persistence Query Language(JPQL)은 객체지향 쿼리로 JPA가 지원하는 다양한 쿼리 방법 중 하나입니다.
• @Query 어노테이션를 사용해서 직접 query문을 정의할 수 있게 됩니다.

public interface ScrapRepository extends JpaRepository<Scrap, Long> {

    @Query(value = "SELECT s FROM Scrap s WHERE s.user = :user AND s.deletedDate IS NULL AND (s.title LIKE %:keyword% OR s.description LIKE %:keyword%) ORDER BY s.createdDate DESC")
    Optional<Slice<Scrap>> findAllByUserAndDeletedDateIsNullAndTitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase(User user, String title, String description, Pageable pageable);
}

위에와 같이 @Query 어노테이션을 사용하여 원하는 query를 직접 지정해서 우선순위 및 자세한 사항을 직접 작성할 수 있습니다.

그러나, query문을 직접 작성하면 조건 및 오타를 작성하게 될 수도 있으며, 쿼리 문자열이 상당하게 길어집니다.

2. 🐳 QueryDSL 적용하기

우선은 QueryDSL이 무엇인지 자세하게 설명해드리겠습니다.

QueryDSL은 하이버네이트 쿼리 언어(HQL: Hibernate Query Language)의 쿼리를 타입에 안전하게 생성 및 관리해주는 프레임워크입니다.

• 문자가 아닌 코드로 쿼리를 작성할 수 있어 컴파일 시점에 문법 오류를 확인할 수 있습니다!!
• 인텔리제이와 같은 IDE의 자동 완성 기능의 도움을 받을 수 있습니다.
• 복잡한 쿼리나 동적 쿼리 작성이 편리합니다.
• 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있습니다.
• JPQL 문법과 유사한 형태로 작성할 수 있어 쉽게 적응할 수 있습니다.

2-1. QueryDSL 의존성 추가하기

• 아래 부분은 QueryDSL로 추가되는 부분만 나타내었습니다.

buildscript {
    ext {
        queryDslVersion = "5.0.0"
    }
}

plugins {
    //위에 부분은 생략
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
}

dependencies {
    //위에 부분은 생략

    // QueryDSL
    implementation "com.querydsl:querydsl-jpa:${queryDslVersion}"
    implementation "com.querydsl:querydsl-apt:${queryDslVersion}"
}

// querydsl
def querydslDir = "$buildDir/generated/'querydsl'"

querydsl {
    jpa = true
    querydslSourcesDir = querydslDir
}

sourceSets {
    main.java.srcDir querydslDir
}

compileQuerydsl {
    options.annotationProcessorPath = configurations.querydsl
}

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
    querydsl.extendsFrom compileClasspath
}

2-2. QuerydslConfig 파일 설정하기

@Configuration
public class QuerydslConfig {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

2-3. Repository 구조 변경하기

여기에서는 Spring Data Jpa Custom Repository를 사용하여 repository 구조(ScrapRepsitory, ScrapRepositoryCustom, ScrapRepositoryCustomImpl)를 변경하였습니다.

2-4. QueryDSL 사용하기

public interface ScrapRepository extends JpaRepository<Scrap, Long>, ScrapRepositoryCustom {

}

• ScrapRepositoryCustom 클래스에 원하는 기능의 메소드를 작성합니다.
• 이때, 저는 스크랩에서 키워드를 검색하고, 최신순으로 조회할 예정이라서 searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword, Pageable pageable)라고 작성하였습니다.
• 이전과 달라진 점은 scrapRepository.findAllByUserAndDeletedDateIsNullAndTitleContainingIgnoreCaseOrDescriptionContainingIgnoreCase(user, keyword, keyword, pageRequest)에서 메소드명이 간결해지고 명확하게 나타낼 수 있게 되었습니다.
• 그리고 keyword를 한 번만 넘겨주어도 됩니다.

public interface ScrapRepositoryCustom {
    Slice<Scrap> searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword, Pageable pageable);
}

• JPAQueryFactory을 사용해서 QueryDSL을 본격적으로 작성해보겠습니다.
• 이때, 여기에서 주목해야 할점은 where 문 부분입니다.
• scrap.user.eq(user).and(scrap.deletedDate.isNull()).and(scrap.title.containsIgnoreCase(keyword).or(scrap.description.containsIgnoreCase(keyword))) 에서 타이틀과 디스크립션에서 keyword를 검색하는 부분에서 () 소괄호를 붙여서 or문이 우선순위가 높도록 설정할 수 있습니다.
• @Query문과 다른 점은 @Query(value = "SELECT s FROM Scrap s WHERE s.user = :user AND s.deletedDate IS NULL AND (s.title LIKE %:keyword% OR s.description LIKE %:keyword%) ORDER BY s.createdDate DESC")보다 더 구조적이라서 의도한 로직을 더 쉽게 파악할 수 있다는 점입니다.
• 그리고 offset, limit와 같이 세세한 부분도 설정해줄 수 있어서, 나중에 no-offset과 같이 성능을 향상시켜야 할 경우에도 쉽게 작성할 수 있습니다.

@RequiredArgsConstructor
public class ScrapRepositoryCustomImpl implements ScrapRepositoryCustom {

    private final JPAQueryFactory queryFactory;

    @Override
    public Slice<Scrap> searchKeywordInScrapOrderByCreatedDateDesc(User user, String keyword,
            Pageable pageable) {
        List<Scrap> contents = queryFactory
                .selectFrom(scrap)
                .where(
                        scrap.user.eq(user)
                                .and(scrap.deletedDate.isNull())
                                .and(scrap.title.containsIgnoreCase(keyword)
                                        .or(scrap.description.containsIgnoreCase(keyword)))
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize()+1)
                .orderBy(scrap.createdDate.desc())
                .fetch();

        return new SliceImpl<>(contents, pageable, hasNextPage(contents, pageable.getPageSize()));
    }

    private boolean hasNextPage(List<Scrap> contents, int pageSize) {
        if (contents.size() > pageSize) {
            contents.remove(pageSize);
            return true;
        }
        return false;
    }
}

아래와 같이 위의 QueryDSL을 사용하면 의도한 로직대로 query문이 동작함을 알 수 있습니다.

그리고 이전에는 JPA를 사용해서 단순한 로직이어서 Repository에 대한 test 코드를 작성하지 않았지만, 이번에는 직접 QueryDSL로 정의해주었기 때문에 해당 메소드에 대한 테스트를 작성했습니다.

@DataJpaTest
@ActiveProfiles("test")
@Sql(scripts = "/truncate.sql", executionPhase = ExecutionPhase.AFTER_TEST_METHOD)
@Sql(scripts = "/setup.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
@Import(TestConfig.class)
public class ScrapRepositoryTest {

    @Autowired
    private ScrapRepository scrapRepository;

    @Autowired
    private UserRepository userRepository;

    String email = "1234@naver.com";

    @Test
    void should_has_next_is_returned_true_when_the_next_page_is_present() {
        // 다음 페이지가 있을 때, hasNext가 true로 반환된다.
        // given
        User user = userRepository.findByEmailAndDeletedDateIsNull(email).get();
        String keyword = "오늘";
        Pageable pageable = PageRequest.of(0, 2);

        //when
        Slice<Scrap> results = scrapRepository.searchKeywordInScrapOrderByCreatedDateDesc(user,
                keyword, pageable);

        // then
        assertThat(results.hasNext()).isTrue();
    }

    @Test
    void should_the_title_is_returned_when_searching_for_keywords_without_case_insensitive() {
        // 대소문자를 구분하지 않고 keyword를 검색할 때, 검색 결과가 있으면 해당 title을 반환된다.
        //스크랩 검색할 때, 대소문자를 구분하지 않고 검색할 수 있는 지 확인
        // given
        User user = userRepository.findByEmailAndDeletedDateIsNull(email).get();
        String keyword = "toDay";
        Pageable pageable = PageRequest.of(0, 2);

        //when
        Slice<Scrap> results = scrapRepository.searchKeywordInScrapOrderByCreatedDateDesc(user,
                keyword, pageable);

        // then
        assertThat(results.getContent().get(0).getDescription()).isEqualTo("Today is rainy");
    }
}

참고 자료 1 : https://tecoble.techcourse.co.kr/post/2021-08-08-basic-querydsl/

참고 자료 2 : https://velog.io/@soyeon207/QueryDSL-Spring-Boot-에서-QueryDSL-JPA-사용하기

2️⃣ 결론

• 이전 프로젝트에서 QueryDSL을 사용해본 적이 있어서, 어떤 방식으로 동작하는지는 알고는 있었지만, 이전에는 필요해서 QueryDSL을 도입하기보다는 프로젝트가 이미 QueryDSL을 사용하고 있어서 사용했습니다.
• 따라서 왜 QueryDSL을 사용해야 하는지 정확하게 알지는 못한 채로 JPA의 기본 문법보다 길어서 최대한 JPA를 사용하려고 하고 QueryDSL을 사용하려고 하지 않았던 것 같습니다.
• 그러나, 이번에는 QueryDSL을 먼저 도입하지 않고 직접 JPA를 사용하다가 불편함을 느끼고 왜 QueryDSL을 사용하는 지 직접 체험해보고 정말 필요하구나!!라는 점을 깨닫고 사용하게 된 것 같아서 QueryDSL의 진가를 더 알게 되고 더 잘 사용할 수 있겠다는 생각을 했습니다☺️
• 앞으로도 기술이나 새로운 라이브러리 등을 도입할 때 필요성을 깨닫고 제대로 사용해야겠다는 다짐을 했습니다!!

이전 글에서 작성한 WebClient 관련 리팩토링을 진행한 뒤에 develop 브랜치로 머지하고 dev 환경에 배포를 마쳤습니다.

https://velog.io/@da_na/WebClient-WebClient-사용해서-외부-API-호출하기

그리고 dev 환경에서 실제로 스크랩을 추가한 뒤에 스크랩이 잘 조회되는지 확인해보았습니다.

그러나,,, 아래와 같이 1개의 스크랩을 추가했는데, 아래의 사진에서 빨간색 박스로 되어 있는 것처럼 정상적인 스크랩 1개와 비정상적인 스크랩(아무것도 나오지 않는 스크랩)이 2개가 추가되었습니다.

그래서, dev DB를 확인해봤는데 2개의 스크랩이 추가되었습니다.

• Article 스크랩과 Other 스크랩 2개가 생성되었습니다.

그래서 WebClient 리팩토링 코드에서 어느 부분이 틀렸는지 앞으로 이러한 상황을 대비하기 위해서는 어떻게 해야할지를 이야기해보겠습니다!!

1️⃣ 본론 1

이전 코드

• 이전에는 WebClient의 에러가 발생하는 경우 NotFoundException처리가 되어 있기 때문에 따로 스크랩을 저장하지 않는 로직이었습니다.

@Transactional
public JSONObject crawlingItem(String pageUrl) throws ParseException {
    Map<String, Object> bodyMap = new HashMap<>();
    bodyMap.put("url", pageUrl);
    WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

    Map<String, Object> response = webClient.post()
            .bodyValue(bodyMap)
            .retrieve()
            .bodyToMono(Map.class)
            .block();

    JSONParser jsonParser = new JSONParser();

    Object obj = jsonParser.parse(response.get("body").toString());

    JSONObject jsonObject = (JSONObject) obj;

    return jsonObject;
}

@Transactional
public Scrap saveScraps(User user, String pageUrl) throws ParseException {
    JSONObject crawlingResponse = webClientService.crawlingItem(pageUrl);

    String type = "";
    try {
        type = crawlingResponse.get("type").toString();
    } catch (NullPointerException e) {
        throw new NotFoundException(ErrorCode.NOT_EXISTS);
    }

    switch (type) {
        case "video":
            return videoService.saveVideo(crawlingResponse, user, pageUrl);
        case "article":
            return articleService.saveArticle(crawlingResponse, user, pageUrl);
        case "product":
            return productService.saveProduct(crawlingResponse, user, pageUrl);
    }
    return otherService.saveOther(crawlingResponse, user, pageUrl);
}

수정된 코드

• WebClient를 리팩토링하면서, WebClient 에러가 발생하면 null을 반환하여 other 스크랩으로 저장되도록 로직을 변경했습니다.

@Transactional
public WebClientBodyResponse crawlingItem(String crawlingApiEndPoint, String pageUrl) {
    Map<String, Object> bodyMap = new HashMap<>();
    bodyMap.put("url", pageUrl);

    WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

    try {
        WebClientResponse webClientResponse = webClient.post()
                .bodyValue(bodyMap)
                .retrieve()
                .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                    throw new RuntimeException("4xx");
                })
                .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                    throw new RuntimeException("5xx");
                })
                .bodyToMono(WebClientResponse.class)
                .block();

        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

        return objectMapper.readValue(
                webClientResponse != null ? webClientResponse.getBody() : null,
                WebClientBodyResponse.class);


    } catch (Exception e) {
        return null;
    }
}

@Transactional
public Scrap saveScraps(User user, String pageUrl) throws ParseException {
    WebClientBodyResponse crawlingResponse = webClientService.crawlingItem(crawlingApiEndPoint, pageUrl);

    return Optional.ofNullable(crawlingResponse)
            .map(response -> {
                String type = response.getType();
                switch (type) {
                    case "video":
                        return videoService.saveVideo(response, user, pageUrl);
                    case "article":
                        return articleService.saveArticle(response, user, pageUrl);
                    case "product":
                        return productService.saveProduct(response, user, pageUrl);
                    case "place":
                        return placeService.savePlace(response, user, pageUrl);
                    default:
                        return otherService.saveOther(response, user, pageUrl);
                }
            })
            .orElse(otherService.saveOther(new WebClientBodyResponse(), user, pageUrl));
}

• 여기에서 잘못된 부분은 .orElse(otherService.saveOther(new WebClientBodyResponse(), user, pageUrl)); 이었습니다.
• orElse 문을 사용하면 안되는 이유를 아래의 문법 관련해서 같이 설명드리겠습니다.

📄 Optional orElse문

Java Optional 클래스는 Java 8에서 추가되었으며 NullpointerException 문제를 해결할 수 있는 방법을 제공합니다.

Optional 클래스는 Integer나 Double 클래스처럼 'T'타입의 객체를 포장해 주는 래퍼 클래스(Wrapper class)입니다. 따라서 Optional 인스턴스는 모든 타입의 참조 변수를 저장할 수 있습니다.

이러한 Optional 객체를 사용하면 예상치 못한 NullPointerException 예외를 제공되는 메소드로 간단히 회피할 수 있습니다.

즉, 복잡한 조건문 없이도 널(null) 값으로 인해 발생하는 예외를 처리할 수 있게 됩니다.

Optional.ofNullbale() - 값이 Null일수도, 아닐수도 있는 경우

만약 어떤 데이터가 null이 올 수도 있고 아닐 수도 있는 경우에는 Optional.ofNullbale로 생성할 수 있습니다. 그리고 이후에 orElse 또는 orElseGet 메소드를 이용해서 값이 없는 경우라도 안전하게 값을 가져올 수 있습니다.

orElse문과 orElseGet 문 차이점

• orElse는 null이든지 말든지 항상 불립니다.
• orElseGet은 null일 때만 불립니다.

orElse문

• orElse문은 optional이 null일 때도 null이 아닌 경우에도 2번 다 호출됨을 알 수 있습니다.

orElseGet 문

• orElseGet 문은 optional이 null일 때에만 실행됨을 알 수 있습니다.

참고 자료 1 : https://engkimbs.tistory.com/646

참고 자료 2 : https://cfdf.tistory.com/34

참고 자료 3 : http://www.tcpschool.com/java/java_stream_optional

참고 자료 4 : https://mangkyu.tistory.com/70

리팩토링힌 코드 잘못된 점

• 제가 원래 의도대로 설계한 로직은 WebClient 에러가 발생하면 null을 반환하여 other 스크랩으로 저장되는 로직이었습니다.
• WebClient 에러가 발생하지 않는다면, 반환한 스크랩으로만 저장하는 로직입니다.
• 그러나, .orElse(otherService.saveOther(new WebClientBodyResponse(), user, pageUrl)) 코드가 WebClient가 응답한 값인 crawlingResponse가 null이 아닌 경우에도 실행되므로 articleService.saveArticle(response, user, pageUrl)과 otherService.saveOther(new WebClientBodyResponse(), user, pageUrl) 총 2번 스크랩이 저장됩니다.

return Optional.ofNullable(crawlingResponse)
            .map(response -> {
                String type = response.getType();
                switch (type) {
                    case "video":
                        return videoService.saveVideo(response, user, pageUrl);
                    case "article":
                        return articleService.saveArticle(response, user, pageUrl);
                    case "product":
                        return productService.saveProduct(response, user, pageUrl);
                    case "place":
                        return placeService.savePlace(response, user, pageUrl);
                    default:
                        return otherService.saveOther(response, user, pageUrl);
                }
            })
            .orElse(otherService.saveOther(new WebClientBodyResponse(), user, pageUrl));

• 따라서 orElse문이 아닌 orElseGet을 사용해서 원래의 의도로 null이 아닌 경우 1번만 동작하도록 변경해주도록 하겠습니다.

return Optional.ofNullable(crawlingResponse)
            .map(response -> {
                String type = response.getType();
                switch (type) {
                    case "video":
                        return videoService.saveVideo(response, user, pageUrl);
                    case "article":
                        return articleService.saveArticle(response, user, pageUrl);
                    case "product":
                        return productService.saveProduct(response, user, pageUrl);
                    case "place":
                        return placeService.savePlace(response, user, pageUrl);
                    default:
                        return otherService.saveOther(response, user, pageUrl);
                }
            })
            .orElseGet(() -> otherService.saveOther(new WebClientBodyResponse(), user, pageUrl));

2️⃣ 본론 2

🚨 문제가 생긴 원인과 앞으로의 대비책

• 다행히도 Dev 서버(개발 환경)과 Prod 서버(운영 환경)을 따로 분리했기 때문에, 실제로 개발 서버에서 동작을 점검해보면서 미처 놓쳤던 부분을 확인할 수 있었고, 운영환경에는 배포하지 않아서 영향이 없었습니다.

1. 문제 원인 : 테스트 코드가 모든 로직을 커버하지 못함

• 테스트 코드를 모두 통과한 상태였기 때문에, 테스트 코드가 모든 로직을 커버하지는 못하고 있음을 알게 되었습니다.
• 실제로 테스트 코드를 살펴봐도 ScrapService 부분에서 scrapService.saveScraps() 메소드 부분은 아래의 코드만 있었습니다.
• 아래의 코드는 null인 경우만 확인했기 때문에 not null인 경우는 정상적인지를 확인할 수 없는 것이었습니다.

@Test
void should_other_type_of_scrap_is_saved_When_webClientService_crawlingItem_returns_null() throws ParseException {
    // webClientService.crawlingItem()이 null을 반환할 때, Other 타입의 Scrap이 저장되는지 확인
    //given
    memoRepository.deleteAll();
    scrapRepository.deleteAll();

    BDDMockito.when(webClientService.crawlingItem("http://localhost:123", pageUrl))
            .thenReturn(null);

    User user = userRepository.findById(1L).get();

    //when
    //then
    assertThat(scrapService.saveScraps(user, pageUrl)).isInstanceOf(Other.class);
    assertThat(scrapRepository.findByPageUrlAndUserAndDeletedDateIsNull(pageUrl, user)
            .isPresent()).isTrue();
}

• 따라서 not null인 경우의 테스트를 추가해주겠습니다.

@Test
void should_one_article_scrap_is_saved_When_webClientService_crawlingItem_returns_article() throws ParseException {
    // webClientService.crawlingItem()이 type을 article로 반환할 때, Article 타입의 Scrap이 1개만 저장되는지 확인
    //given
    memoRepository.deleteAll();
    scrapRepository.deleteAll();

    WebClientBodyResponse webClientBodyResponse = new WebClientBodyResponse().builder()
            .title("title")
            .type("article")
            .build();

    BDDMockito.when(webClientService.crawlingItem("test", pageUrl))
            .thenReturn(webClientBodyResponse);

    User user = userRepository.findById(1L).get();

    //when
    //then
    assertThat(scrapService.saveScraps(user, pageUrl)).isInstanceOf(Article.class);
    assertThat(scrapRepository.count()).isEqualTo(1);
}

• 만약에 이 테스트를 넣고 리팩토링 코드를 orElse문을 그대로 사용했다면, 테스트에서 통과하지 못해서 dev 서버에 반영하지 못했을 것입니다.

• 그리고 orElse문이 아닌 orElseGet으로 변경했다면, 성공적으로 저장됨을 알 수 있습니다.

따라서 앞으로는 이러한 문제가 발생하지 않도록 테스트 코드를 예외 처리뿐만 아니라 정상적인 로직 및 로직을 체계적으로 세워서 발생할 수 있는 다양한 상황을 테스트 코드에 반영해야겠다고 다짐하게되었습니다!!

2. 문제 원인 : PR 단위가 크다.

• 리팩토링 과정에서 WebClient 로직 뿐만 아니라, Optional 처리까지 여러 가지 코드를 수정하다 보니, WebClient 로직만 테스트 코드를 작성해서 Optional과 같이 문법적인 요소는 크게 신경쓰지 못한 것 같습니다. 따라서, 앞으로는 리팩토링 과정도 세분화해서 하나의 PR이 아닌 여러 개의 PR로 나누어서 로직 변경, 문법 변경과 같이 나눈 뒤에 그에 맞는 테스트 코드와 에러 처리를 추가해야겠다는 생각을 하게 되었습니다.

3️⃣ 결론

• (위에서 언급한 이야기) 앞으로는 이러한 문제가 발생하지 않도록 테스트 코드를 예외 처리뿐만 아니라 정상적인 로직 및 로직을 체계적으로 세워서 발생할 수 있는 다양한 상황을 테스트 코드에 반영해야겠다고 다짐하게되었습니다!!
• (위에서 언급한 이야기) 리팩토링 과정에서 WebClient 로직 뿐만 아니라, Optional 처리까지 여러 가지 코드를 수정하다 보니, WebClient 로직만 테스트 코드를 작성해서 Optional과 같이 문법적인 요소는 크게 신경쓰지 못한 것 같습니다. 따라서, 앞으로는 리팩토링 과정도 세분화해서 하나의 PR이 아닌 여러 개의 PR로 나누어서 로직 변경, 문법 변경과 같이 나눈 뒤에 그에 맞는 테스트 코드와 에러 처리를 추가해야겠다는 생각을 하게 되었습니다.
• 멘토님이 '회사에서 신입이 실수를 했는데, 이로 인해서 큰 장애가 서비스 전체에 영향을 미쳤어. 그런데, 이러한 원인은 신입에게 서비스 전체에 영향을 줄 수 있는 권한을 부여한 시스템의 잘못이지 신입의 잘못이 아니야.'라고 말씀해주셨습니다. 그리고 '회사에 코드 리뷰 시간을 늘리고, 실제 운영 환경에 배포하기 전에 승인받는 시스템으로 변경되었다'고 말씀해주셨습니다.
• 문법의 실수로 에러가 발생해서 약간 부끄럽지만, 언제나 실수나 에러가 발생할 수 있는 만큼 부끄러움을 이겨내고 기록으로 남겨 놓음으로써 실수의 원인을 바로 직면하여 파악하고 시스템을 점검하고 대책을 마련하여 해결해나가는 것이 중요함을 깨닫게 되었습니다!!
• 마지막으로 운영 환경과 개발 환경을 나누어서 테스트를 여러 번 하는 것처럼 테스트 코드로는 모든 상황을 다 대비하고 알아낼 수 없기 때문에 테스트 환경을 최대한으로 마련하는 것이 매우 매우 유용하고 실제 서비스에서는 필수적임을 알았습니다!

📄 현재 프로젝트 구조

현재 Scrap이라는 부모 클래스로 Video, Product, Article, Place, Other 카테고리의 자식 클래스가 있습니다.

따라서 각각의 자식 클래스는 각각의 Entity로 되어 있습니다.

하지만, 상속 관계에 있는 만큼 조회 기능, 검색 기능, 수정 기능 등 각각의 Video, Product, Article, Place, Other 카테고리는 기능이 거의 유사합니다.

그러나, 각각은 다른 Repository와 Service, Controller를 가지고 있기 떄문에 ArticleController, OtherController, ProductController, VideoController에서는 동일한 기능이어도 아래와 같이 따로 각자 분리되어 있습니다.

@Operation(summary = "아티클 스크랩 개수 조회", description = "아티클 스크랩 개수 정보를 조회할 수 있습니다.")
@GetMapping("/v1/scraps/articles/count")
public ApiResponse<GetArticleCountResponse> getArticleCount(Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success(
            GetArticleCountResponse.of(articleService.getArticleCount(email)));
}

@Operation(summary = "기타 스크랩 개수 조회", description = "기타 스크랩 개수 정보를 조회할 수 있습니다.")
@GetMapping("/v1/scraps/others/count")
public ApiResponse<GetOtherCountResponse> getOtherScrap(Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success(GetOtherCountResponse.of(otherService.getOtherCount(email)));
}

@Operation(summary = "상품 스크랩 개수 조회", description = "상품 스크랩 개수 정보를 조회할 수 있습니다.")
@GetMapping("/v1/scraps/products/count")
public ApiResponse<GetProductCountResponse> getProductScrap(Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success(
            GetProductCountResponse.of(productService.getProductCount(email)));
}

@Operation(summary = "비디오 스크랩 개수 조회", description = "비디오 스크랩 개수 정보를 조회할 수 있습니다.")
@GetMapping("/v1/scraps/videos/count")
public ApiResponse<GetVideoCountResponse> getVideoCount(Authentication authentication) {
    String email = authentication.getName();
    return ApiResponse.success(GetVideoCountResponse.of(videoService.getVideoCount(email)));
}

이 때의 단점은 동일한 기능을 나눠서 작성했기 때문에 코드의 길이가 길어진다는 단점이 있습니다.

저희 서비스는 카테고리가 점차 늘어날 수도 있기 때문에 그럴 때마다 동일한 로직이 계속되어서 추가됩니다.

그러나, 제가 생각한 가장 큰 단점은 "테스트 코드 작성시 동일한 기능을 테스트하게 된다"라는 점입니다.

즉, 테스트 코드 작성시에 카테고리의 스크랩 개수를 조회하는 같은 기능도 Controller의 메소드로 나누어져 있기 때문에 각각의 테스트 코드를 작성해줘야 합니다.

그러나, 한 개의 Controller를 테스트 완료하면 다른 Controller의 메소드도 동일한 로직이기 때문에 동일한 결과가 나올지 알 수 있지만 커버리지 및 테스트 코드를 위해서는 동일한 로직도 테스트 코드를 작성해야 한다는 단점이 있었습니다.

따라서 이 구조를 refactoring하는 과정을 소개해드리겠습니다!

1️⃣ 본론 1

🖍️ if 문 사용하기

🥹 여기서 잠깐, 여기에서 if문을 사용해서 하나의 Controller method를 사용하면 안될까요??

@RequiredArgsConstructor
@RestController
public class ScrapController {

    @GetMapping("/v1/scraps/{category}/count")
    public ApiResponse<GetScrapCountResponse> getScrapCount(
            @NotNull @PathVariable Category category,
            Authentication authentication) {
        String email = authentication.getName();

        if(category == "video") {
            return ApiResponse.success(GetScrapCountResponse.of(videoService.getVideoCount(email)));
        } else if (category == "product") {
            return ApiResponse.success(GetScrapCountResponse.of(productService.getProductCount(email)));
        } else if (category == "other") {
            return ApiResponse.success(GetScrapCountResponse.of(otherService.getOtherCount(email)));
        }

        return ApiResponse.success(GetScrapCountResponse.of(scrapCount));
    }
}

그러면 카테고리가 늘어날 때마다 Controller의 코드를 수정해줘야 합니다 🥲

🔎 SOLID 객체 지향 5가지 설계 원칙

혹시 SOLID라는 객체지향설계의 원칙을 들어보셨나요??

여기에서 O는 OCP로 개방 폐쇄 원칙입니다. 확장에 대해는 열려 있고, 수정에 대해서는 닫혀 있어야 합니다.

그런데 위의 코드와 같이 if문을 사용하면, 수정에는 닫혀 있는 구조가 아닌 계속해서 if문을 추가해야 하는 수정에 열려있는 구조가 됩니다.

그리고 DIP 의존 관계 역전 원칙을 여기게 됩니다. DIP는 추상화에 의존해야 하고, 구체화에 의존하면 안된다는 것을 의미합니다.

즉, if문으로 구체화 되어 있는 videoService, productService 클래스를 의존하게 됩니다!!

2️⃣ 본론 2

🧚‍♀️ 프로젝트에 전략 패턴 적용하기

그러면 과연 이러한 문제를 해결할 수 있는 방법은 없을까?? 라는 고민을 하다가 전략 패턴을 떠올리게 되었습니다.

이전에 디자인 패턴으로 전략 패턴을 게시글로 올렸던 적이 있습니다.

https://handayeon-coder.github.io/posts/디자인-패턴-06.-Strategy-패턴/

이때, 알고리즘의 동작이 런타임에 실시간으로 교체 되어야 하는 경우에 사용될 수 있다고 했습니다.

아래는 전략 패턴 다이어그램입니다!

따라서 전략 패턴처럼 Client가 Controller에 PathVariable로 입력한 @GetMapping("/v1/scraps/{category}/count") category에 따라서 videoService.getVideoCount, productService,getProductCount와 같이 실시간으로 교체되면 될 것 같다는 생각을 했습니다.

전략 패턴 다이어그램을 저희 서비스에도 적용해보았습니다.

1. Strategy 인터페이스 생성하기

먼저 Strategy를 의미하는 ScrapService라는 인터페이스를 만들어주도록 하겠습니다.

public interface ScrapService {
    Long getScrapCount(String email);
}

2. ConcreteStrategy를 정의하기

각각의 ConcretStrategy가 되는 VideoService, ProductService, ArticleService에 getScrapCount 전략 메소드를 @Override해서 나타내줍니다.

• (이때, 다른 PlaceService, OtherService는 동일한 로직이라서 아래의 코드에서 생략하였습니다.)

@Service
@RequiredArgsConstructor
public class ProductService implements ScrapService {

    private final ProductRepository productRepository;
    private final UserService userService;

    @Override
    @Transactional
    public Long getScrapCount(String email) {
        User user = userService.validateUser(email);
        return productRepository.countByUserAndDeletedDateIsNull(user);
    }
}

@Service
@RequiredArgsConstructor
public class ArticleService implements ScrapService {

    private final ArticleRepository articleRepository;
    private final UserService userService;

    @Override
    @Transactional
    public Long getScrapCount(String email) {
        User user = userService.validateUser(email);
        return articleRepository.countByUserAndDeletedDateIsNull(user);
    }
}

@Service
@RequiredArgsConstructor
public class VideoService implements ScrapService {

    private final VideoRepository videoRepository;
    private final UserService userService;

    @Override
    @Transactional
    public Long getScrapCount(String email) {
        User user = userService.validateUser(email);
        return videoRepository.countByUserAndDeletedDateIsNull(user);
    }
}

3. Context 클래스에서 Strategy 선택하기

@RequiredArgsConstructor
@RestController
public class ScrapController {

    private final Map<String, ScrapService> scrapServices;

    @GetMapping("/v1/scraps/{category}/count")
    public ApiResponse<GetScrapCountResponse> getScrapCount(
            @NotNull @PathVariable Category category,
            Authentication authentication) {
        String email = authentication.getName();

        ScrapService scrapService = scrapServices.get(category.getServiceName());
        Long scrapCount = scrapService.getScrapCount(email);
        return ApiResponse.success(GetScrapCountResponse.of(scrapCount));
    }
}

• 이때, scrapServices로 선택할 전략을 필드에 나타내줍니다.
• @GetMapping("/v1/scraps/{category}/count")
  • @PathVariable로 원하는 Category를 입력받아줍니다.
• ScrapService scrapService = scrapServices.get(category.getServiceName());
  • 여러 전략(VideoService, ProductService, ArticleService, PlaceService, TotalService)에서 입력된 카테고리에 해당하는 서비스 로직을 선택해줍니다.

@Getter
public enum Category {
    product("productService"),
    article("articleService"),
    place("placeService"),
    video("videoService"),
    other("otherService");

    private final String serviceName;

    Category(String serviceName) {
        this.serviceName = serviceName;
    }
}

🌱 Spring 빈에 대해서 알아보자!

• 어떻게 전략 패턴을 사용해서 원하는 서비스 전략을 선택할 수 있는 건지 알아보겠습니다!!

따라서 scrapServices에는 어떠한 것들이 담겨있는지 확인해보겠습니다.

이를 위해서 System.out.println("scrapServiceMap: " + scrapServiceMap); 출력하는 문장을 추가했습니다.

@RequiredArgsConstructor
@RestController
public class ScrapController {

    private final Map<String, ScrapService> scrapServices;

    @GetMapping("/v1/scraps/{category}/count")
    public ApiResponse<GetScrapCountResponse> getScrapCount(
            @NotNull @PathVariable Category category,
            Authentication authentication) {
        String email = authentication.getName();


        for (ScrapService scrapServiceMap : scrapServices.values()) {
            System.out.println("scrapServiceMap: " + scrapServiceMap);
        }

        ScrapService scrapService = scrapServices.get(category.getServiceName());

        Long scrapCount = scrapService.getScrapCount(email);
        return ApiResponse.success(GetScrapCountResponse.of(scrapCount));
    }
}

• 즉, 여기에는 ScrapService 인터페이스를 구현한 ArticleService, OtherService, PlaceService, ProductService, VideoService이 담아졌음을 알 수 있습니다.
• private final Map<String, ScrapService> scrapServices;
  • map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 ScrapService 타입으로 조회한 모든 스프링 빈을 담아줍니다.
• 이 중에서 동일한 이름의 Service를 scrapServices.get(category.getServiceName())해서 가져오고 사용해줍니다.

🤖 테스트 코드 작성하기

@Test
@WithCustomMockUser
public void should_it_returns_the_number_of_saved_videos_When_getting_the_number_of_videos() throws Exception {
    // 비디오 개수 조회시 저장된 비디오의 개수를 반환하는지 확인
    mockMvc.perform(get("/v1/scraps/video/count")
                    .header("X-AUTH-TOKEN", "aaaaaaa"))
            .andExpect(MockMvcResultMatchers.status().isOk())
            .andExpect(MockMvcResultMatchers.jsonPath("$.data.count").value(2L));
}

위의 작성하여 카테고리별 스크랩 개수 조회하는 Controller를 테스트할 수 있습니다.

따라서, 동일한 기능의 핵심 로직을 하나의 테스트만으로 기능이 정상적으로 작동하는지 확인할 수 있고, 앞으로는 같은 기능과 로직에 대해서는 동일한 로직의 검증 테스트 코드를 여러 개 작성하지 않고 다른 에러 처리와 같은 테스트 되지 않은 부분을 더 구체적으로 테스트 코드 작성할 수 있게 되었습니다.

🔎 SOLID 객체 지향 5가지 설계 원칙 살펴보기

if문 적용하기에서 if문을 사용하면 SOLID 원칙 중 O와 D에 해당하는 원칙을 어기게 된다고 이야기했습니다.

그러면 전략 패턴을 적용했을 때에는 과연 원칙을 잘 지키고 있는지 살펴보겠습니다!

1. ScrapController가 ScrapService 인터페이스를 의존하고 있기 때문에 DIP 의존관계 역전 원칙을 지킬 수 있게 되었습니다.

2. 카테고리가 추가되어도 아래의 코드는 변화되지 않기 때문에 OCP 개발 폐쇄 원칙을 지키게 됩니다.

@RequiredArgsConstructor
@RestController
public class ScrapController {

    private final Map<String, ScrapService> scrapServices;

    @GetMapping("/v1/scraps/{category}/count")
    public ApiResponse<GetScrapCountResponse> getScrapCount(
            @NotNull @PathVariable Category category,
            Authentication authentication) {
        String email = authentication.getName();

        ScrapService scrapService = scrapServices.get(category.getServiceName());

        Long scrapCount = scrapService.getScrapCount(email);
        return ApiResponse.success(GetScrapCountResponse.of(scrapCount));
    }
}

3️⃣ 결론

• 현재 배우고 있는 GoF 디자인 패턴 중 하나인 전략 패턴을 직접 프로젝트에 적용해보게 될 수 있어서 뜻깊은 시간이었습니다.
• 이러한 리팩토링을 시작하기 전에는 어떠한 서비스를 의미하는지 모르게 되고 코드에 대한 가독성이 떨어지게 되며 디자인 패턴을 적용하고자 하는 나의 욕심이 아닐까라는 생각이 들게 되었습니다. 그러나, 이전까지는 스크랩의 카테고리가 상품, 영상, 아티클, 기타까지만 있었는데 이번에 상품 카테고리를 늘리게 되면서 앞으로 카테고리가 늘어날 수 있다는 생각을 하게 되었고 그러면 앞으로 기능 추가 및 유지 보수를 위해서라도 전략 패턴을 사용해야겠다는 다짐을 하게 되었습니다. 그리고 실제로 리팩토링을 하면서 테스트 코드와 유지보수 측면 등 여러 가지의 장점이 있는 것을 느끼고 리팩토링을 하기를 잘 했다는 생각이 들었습니다.
• 그리고 이 블로그를 작성하는 이유 중 하나가 팀원들에게 해당 리팩토링 과정을 소개하고 장점에 대해서 소개한 뒤, 실제 프로젝트에도 도입하자고 제안하기 위해서 작성된 이유도 있는 만큼 실제 프로젝트에서 리팩토링을 도입되었으면 좋겠다는 바램으로 이 글을 작성합니다 🌸

이전 게시글에서 'WebClient를 사용해서, 외부 API를 호출하기'라는 글을 작성했습니다.

https://velog.io/@da_na/WebClient-WebClient-사용해서-외부-API-호출하기

저희 서비스는 크롤링 서버를 따로 분리했기 때문에 WebClient를 사용해서 Spring Boot(AWS EC2)가 외부 API인 크롤링 서버를 호출하는 방식으로 되어 있습니다.

따라서 아래의 WebClient 서비스 로직은 Spring Boot가 외부 API 크롤링 서버를 호출하는 로직입니다.

@Service
public class WebClientService {

    @Transactional
    public WebClientBodyResponse crawlingItem(String crawlingApiEndPoint, String pageUrl) {
        Map<String, Object> bodyMap = new HashMap<>();
        bodyMap.put("url", pageUrl);

        WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

        try {
            WebClientResponse webClientResponse = webClient.post()
                    .bodyValue(bodyMap)
                    .retrieve()
                    .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                        throw new RuntimeException("4xx");
                    })
                    .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                        throw new RuntimeException("5xx");
                    })
                    .bodyToMono(WebClientResponse.class)
                    .block();

            ObjectMapper objectMapper = new ObjectMapper();
            objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

            return objectMapper.readValue(
                    webClientResponse != null ? webClientResponse.getBody() : null,
                    WebClientBodyResponse.class);


        } catch (Exception e) {
            return null;
        }

    }
}

이전의 테스트 코드를 도입하기 전까지는 POSTMAN을 사용하여 직접 외부 서버와 통신하고 값을 확인했습니다.

따라서, 테스트가 외부 서버에 매우 의존적이었고 서버를 직접 호출하기 때문에 테스트 시간이 오래 걸렸습니다.

그리고 이전 게시글의 마지막에 WebClient를 리팩토링하는데, WebClient로 부터 받은 값을 변환하는 과정을 변경할 때에도 계속 외부 서버와 통신하는 것도 계속 동일한 값을 받는 데에 외부 서버를 호출하는 것은 비효율적이라고 생각했습니다.

더 나아가, 400번 대, 500번 대의 외부 서버 에러를 발생시키려면 일부러 에러를 요청하는 크롤링 웹 페이지 URL을 찾아서 보내줘야 해서 에러 처리하기가 어려웠습니다.

그러면 직접 외부 서버와 통신하는 방법 말고는 다른 방법으로 테스트하는 방법은 없을지 고민하다가, MockWebServer를 선택하여 테스트에 도입할 수 있었습니다.

1️⃣ 본론 1

😎 MockWebServer가 무엇인가?

Square 팀에서 만든 MockWebServer는 HTTTP Request를 받아서 Response를 반환하는 간단하고 작은 웹서버입니다.

WebClient를 사용하여, Http를 호출하는 메서드의 테스트 코드를 작성할때 이 MockWebServer를 호출하게 함으로써 쉽게 테스트 코드를 작성할 수 있습니다.

그리고 실제로 Spring Team도 MockWebServer를 사용하여 테스트하라고 권장한다고 합니다.

MockWebServer 공식 문서 : https://github.com/square/okhttp/tree/master/mockwebserver

참고 자료 : https://www.devkuma.com/docs/mock-web-server/

Spring Team 출처 : https://github.com/spring-projects/spring-framework/issues/19852#issuecomment-453452354

💼 MockWebServer 사용해서 외부 서버를 Mocking하기

1. MockWebServer 의존성 추가하기

testImplementation 'com.squareup.okhttp3:mockwebserver'

2. 테스트 코드에 MockWebServer 추가하기

• @BeforeEach를 선언하여 각각의 테스트마다 mockWebServer.start()를 사용해서, 가짜 API 서버인 MockWebServer를 켭니다.
• @AfterEach를 선언하여 각각의 테스트마다 mockWebServer.shutdown()를 사용해서, 켰던 MockWebServer를 끕니다.

@Autowired
private WebClientService webClientService;

private MockWebServer mockWebServer;

private String mockWebServerUrl;

@BeforeEach
void setUp() throws IOException {
    mockWebServer = new MockWebServer();
    mockWebServer.start();
    mockWebServerUrl = mockWebServer.url("/v1/crawling").toString();
}

@AfterEach
void terminate() throws IOException {
    mockWebServer.shutdown();
}

3. MockWebServer 사용하여 서비스 로직 테스트하기

• 여기에서는 mockWebServer.enqueue를 사용하여 mockWebServer 가짜 서버가 응답할 값을 설정해줄 수 있습니다.
• 아래의 코드에서는 성공적으로 응답하는 것을 확인하고, 응답값을 DTO로 잘 변환해주는지 확인하는 과정이기 때문에 .setResponseCode(200)으로 응답값을 200으로 설정해주었습니다. 그리고 mockScrap은 따로 private String mockScrap으로 선언해었습니다.(아래에서는 선언한 것은 생략하였습니다!)

@Test 
void should_title_is_returned_When_the_webClient_server_responds_successfully() {
    //given
    mockWebServer.enqueue(new MockResponse()
            .setResponseCode(200)
            .setBody(mockScrap)
            .addHeader("Content-Type", "application/json"));

    //when
    WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(
            mockWebServerUrl, "https://www.naver.com");

    //then
    assertThat(webClientBodyResponse.getTitle()).isEqualTo("서울역");
}

4. MockServer 사용하여 400번대의 응답 코드 보내서 에러 처리 로직 테스트 하기

• 다음으로는 정상적인 응답이 아니라, 400번의 에러가 발생했을 때 서비스 로직이 에러 처리가 제대로 되고 있는지 확인하는 테스트 코드를 작성해주었습니다.

• 이때, 저는 외부 API 서버가 에러가 발생하면 null을 반환하도록 설계했기 때문에 아래의 테스트 코드는 null이 나오는지 확인하는 구조입니다.

• 이처럼 쉽게 외부 API 서버의 에러를 발생시킬 수 있어서, 에러 처리를 확인하고 더 구체적으로 작성할 수 있습니다.

  @Test
  void should_it_returns_null_When_webClient_server_responds_unsuccessfully() {
    //given
    mockWebServer.enqueue(new MockResponse()
            .setResponseCode(400)
    );
  
    //when
    WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(
            mockWebServerUrl, "https://www.naver.com");
  
    //then
    assertThat(webClientBodyResponse).isEqualTo(null);
  }

  

전체적인 MockWebServer를 이용한 테스트 코드입니다!

@SpringBootTest
@ActiveProfiles("test")
public class WebClientServiceTest {

    @Autowired
    private WebClientService webClientService;

    private MockWebServer mockWebServer;

    private String mockWebServerUrl;

    private final String mockScrap = "{\n"
            + "  \"statusCode\": 200,\n"
            + "  \"headers\": {\n"
            + "    \"Content-Type\": \"application/json\"\n"
            + "  },\n"
            + "  \"body\": \"{\\\"type\\\": \\\"place\\\", \\\"page_url\\\": \\\"https://map.kakao.com/1234\\\", "
            + "\\\"site_name\\\": \\\"KakaoMap\\\", \\\"lat\\\": 37.50359439708544, \\\"lng\\\": 127.04484896895218, "
            + "\\\"title\\\": \\\"서울역\\\", \\\"address\\\": \\\"서울특별시 중구 소공동 세종대로18길 2\\\", "
            + "\\\"phonenum\\\": \\\"1522-3232\\\", \\\"zipcode\\\": \\\"06151\\\", "
            + "\\\"homepageUrl\\\": \\\"https://www.seoul.co.kr\\\", \\\"category\\\": \\\"지하철\\\"}\"\n"
            + "}\n";

    @BeforeEach
    void setUp() throws IOException {
        mockWebServer = new MockWebServer();
        mockWebServer.start();
        mockWebServerUrl = mockWebServer.url("/v1/crawling").toString();
    }

    @AfterEach
    void terminate() throws IOException {
        mockWebServer.shutdown();
    }

    @Test 
    void should_title_is_returned_When_the_webClient_server_responds_successfully() {
        //given
        mockWebServer.enqueue(new MockResponse()
                .setResponseCode(200)
                .setBody(mockScrap)
                .addHeader("Content-Type", "application/json"));

        //when
        WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(
                mockWebServerUrl, "https://www.naver.com");

        //then
        assertThat(webClientBodyResponse.getTitle()).isEqualTo("서울역");
    }


    @Test
    void should_it_returns_null_When_webClient_server_responds_unsuccessfully() {
        //given
        mockWebServer.enqueue(new MockResponse()
                .setResponseCode(400)
        );

        //when
        WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(
                mockWebServerUrl, "https://www.naver.com");

        //then
        assertThat(webClientBodyResponse).isEqualTo(null);
    }
}

2️⃣ 본론 2

의존성 줄이기 ➡️ WebClientService 로직 구조 변경

• 이러한 WebClientService를 테스트하기 위한 과정에서 MockWebServer로 테스트가 가능한 유연한 구조를 변경했습니다.
• 아래는 이전의 테스트를 작성하기 전의 코드입니다.

이전의 구조

@Service
 public class WebClientService {

     @Value("${crawling.server.post.api.endPoint}")
     private String crawlingApiEndPoint;

     @Transactional
     public JSONObject crawlingItem(String pageUrl) throws ParseException {
         Map<String, Object> bodyMap = new HashMap<>();
         bodyMap.put("url", pageUrl);
         WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

         Map<String, Object> response = webClient.post()
                 .bodyValue(bodyMap)
                 .retrieve()
                 .bodyToMono(Map.class)
                 .block();

         JSONParser jsonParser = new JSONParser();

         Object obj = jsonParser.parse(response.get("body").toString());

         JSONObject jsonObject = (JSONObject) obj;

         return jsonObject;
     }
 }

• 이전 코드의 문제점은 WebClientService의 crawlingItem 메소드가 pageUrl만 받는 구조라는 점입니다.
  • 이러한 구조 때문에 MockWebServer로 만든 가짜 서버의 URL을 입력해주지 못해서 해당 메소드를 테스트하지 못합니다.
  • 그러면, 🤔 이때 드는 의문은 @Value로 crawling.server.post.api.endPoint에서 값을 가져오고 있는데 여기에 값을 미리 입력해주면 되는 거 아닌가?? 라는 의문이 들게 됩니다.
  • 하지만, MockWebServer는 port 번호를 테스트할 때마다 마음대로 생성하기 때문에 미리 URL을 입력할 수 없습니다.
  • 따라서, 외부 API URL을 외부에서 주입하는 구조로 변경하여 테스트에 유연한 구조로 변경하였습니다. (현재 인프런의 김영한님 스프링 강의를 듣고 있는데 생성자 주입 DI가 떠올랐습니다 ㅎㅎ)

MockWebServer의 Port 번호 확인하기

• MockWebServer는 port 번호를 테스트할 때마다 마음대로 생성하는지 확인하기 위해서 아래와 같이 출력하는 코드를 입력해서 테스트를 2번 실행해보았습니다.

@BeforeEach
void setUp() throws IOException {
    mockWebServer = new MockWebServer();
    mockWebServer.start();
    mockWebServerUrl = mockWebServer.url("/v1/crawling").toString();

    System.out.println("mockWebServerUrl = " + mockWebServerUrl);
}

• 위의 사진처럼 포트 번호가 50346, 50352로 다른 것을 알 수 있습니다.

변경한 구조

• 아래처럼 WebClientService의 crawlingItem 메소드 파라미터로 외부 API URL을 입력받는 구조로 변경하였습니다.

• 따라서, 가짜 외부 API 서버의 URL과 실제 외부 API 서버의 URL을 모두 받을 수 있는 유연한 구조가 되었습니다!

• 해당 메소드 테스트 시 사용하는 코드 : WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(mockWebServerUrl, "https://www.naver.com");

  @Service
  public class WebClientService {
  
     @Transactional
     public WebClientBodyResponse crawlingItem(String crawlingApiEndPoint, String pageUrl) {
         Map<String, Object> bodyMap = new HashMap<>();
         bodyMap.put("url", pageUrl);
  
         WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();
  
         try {
             WebClientResponse webClientResponse = webClient.post()
                     .bodyValue(bodyMap)
                     .retrieve()
                     .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                         throw new RuntimeException("4xx");
                     })
                     .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                         throw new RuntimeException("5xx");
                     })
                     .bodyToMono(WebClientResponse.class)
                     .block();
  
             ObjectMapper objectMapper = new ObjectMapper();
             objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
  
             return objectMapper.readValue(
                     webClientResponse != null ? webClientResponse.getBody() : null,
                     WebClientBodyResponse.class);
  
  

     } catch (Exception e) {
         return null;
     }

 }

}

---

# 3️⃣ 결론

### 1. ⛑️ **안정적이고 다양한 에러 처리 가능** 
- 해당 테스트 코드를 작성하기 전에는 직접 외부 API 서버를 호출해서 테스트를 진행했기 떄문에 에러가 나는 호출을 찾기 위해서 여러 번의 에러가 나는 페이지들을 찾아서 해당 페이지를 가지고 외부 API를 호출했습니다. 
- 그러나, 테스트를 준비하기 위해서 더 오랜 시간이 걸렸고, 웹 페이지 구조가 변경되면 해당 페이지가 에러가 나지 않을 수도 있는 등의 외부 서버에 너무 높은 의존도를 가지고 있었습니다. 
- 하지만 이번 테스트 코드를 작성하고 나니까, **훨씬 더 다양한 에러를 항상 빠르게 발생**시킬 수 있었고 다양한 에러를 발생시키다 보니까 **미처 놓쳤던 에러에 적합한 처리**도 할 수 있게 되어서 더 **안정적인 서비스가 가능**해진 것 같습니다.

### 2. 🤸‍♀️ **테스트 하기 위해서 유연한 구조로 변경**
- 테스트를 진행하기 위해서 외부에서 주입받는 형식으로 변경하여 테스트에 유연한 구조로 변경하였는데, **유연한 구조 설계의 중요성**을 다시 한 번 느끼게 된 것 같습니다.

### 3. 🤝 **테스트 코드는 약속이다.** 
- 테스트 코드를 작성하면서, 이전에는 외부 API에서 에러가 발생했을 때 따로 처리를 하지 않아서 외부 API의 에러가 발생하면 현재 프로젝트의 Spring Boot 서버(외부 API 호출한 원래의 서버)도 에러가 발생하였습니다.
- 그러나, 이번 테스트 코드로 에러 처리가 가능해지면서, 외부 API 에러를 원래의 서버에 영향을 줄이고자 null을 반환하도록 하고 Other(기타 스크랩)으로 저장되는 로직으로 변경하였습니다.
- 테스트 관련 강의를 들으면서 테스트 코드를 작성함으로써, 어떠한 행동과 로직을 수행했을 때 어떠한 결과가 나와야 한다고 문서화 및 약속이 가능하다!!라는 말이 떠올랐습니다. (왜냐하면, 테스트 코드는 모든 팀원들이 봐야하고 항상 모든 서비스 로직이 테스트 코드를 통과해야 하며, 행동에 대한 결과가 정해져있기 때문입니다.)
- 따라서 이러한 과정을 아래의 테스트 코드로 작성해놓으면서,  **팀원들과 같이 이야기를 하고 로직에 대한 약속을 정할 수 있게 되었습니다**.
- **WebClient(외부 API 서버)가 비정상적인 응답을 준 경우 null로 반환하고 Other 스크랩으로 저장되는 로직**을 수행했습니다.

```java
@Test
void should_it_returns_null_When_webClient_server_responds_unsuccessfully() {
    // webClient 서버가 정상적으로 응답을 주지 않는 경우, null로 반환되는지 확인
    //given
    mockWebServer.enqueue(new MockResponse()
            .setResponseCode(400)
    );

    //when
    WebClientBodyResponse webClientBodyResponse = webClientService.crawlingItem(
            mockWebServerUrl, "https://www.naver.com");

    //then
    assertThat(webClientBodyResponse).isEqualTo(null);
}

@Test
void should_other_type_of_scrap_is_saved_When_webClientService_crawlingItem_returns_null() throws ParseException {
    // webClientService.crawlingItem()이 null을 반환할 때, Other 타입의 Scrap이 저장되는지 확인
    //given
    memoRepository.deleteAll();
    scrapRepository.deleteAll();

    BDDMockito.when(webClientService.crawlingItem("http://localhost:123", pageUrl))
            .thenReturn(null);

    User user = userRepository.findById(1L).get();

    //when
    //then
    assertThat(scrapService.saveScraps(user, pageUrl)).isInstanceOf(Other.class);
    assertThat(scrapRepository.findByPageUrlAndUserAndDeletedDateIsNull(pageUrl, user)
            .isPresent()).isTrue();
}

4. 🛟 리팩토링시, 테스트 코드를 통해서 훨씬 안전하게 변경가능

• 이전 글에서 외부 API 호출하는 로직을 리팩토링한 적이 있습니다. 이번 글의 테스트 코드와 리팩토링 글이 나누어져 있지만 원래는 리팩토링 과정에서 테스트 코드도 같이 도입된 상태였습니다.
• 이때, 느꼈던 점은 리팩토링을 할 때 테스트 코드를 작성해 놓아서 테스트 코드를 통과하면 로직이 정상적으로 돌아간다는 보장이 있기 때문에 테스트 코드를 믿으면서 안전하게 코드를 마음대로 수정할 수 있게 되었습니다.
• 그리고 테스트 코드를 통해서 응답 결과를 바로 확인할 수 있어서 실제 외부 API를 호출하지 않고도 쉽게 수정이 용이했습니다!!
• 이전 글 : https://velog.io/@da_na/WebClient-WebClient-사용해서-외부-API-호출하기

저희 서비스는 크롤링하는 서버를 EC2와 분리해서 서비스를 분리시켰기 때문에, Spring Boot(AWS EC2)에서 AWS Lambda 서버를 호출하는 형식으로 외부 API를 호출하고 있습니다.

따라서, 간략하게 AWS EC2에서 AWS Lambda를 호출하는 흐름을 아래의 그림과 같이 나타내었습니다.

그러면 Spring Boot에서는 어떻게 외부의 API를 호출시킬까요??

저희는 WebClient라는 외부 호출 방식를 사용하였습니다.

그러면 도대체 WebClient가 무엇이길래 이거를 선택했고 어떻게 사용할지 소개해드리겠습니다.

1️⃣ 본론 1

✔️ 외부 호출 방식 결정하기

먼저, 'Spring으로 외부 API 호출하기'라고 구글에 검색했을 때 가장 많이 나오는 방식은 'RestTemplate'과 'WebClient'입니다.

그러면 두 가지 방식은 어떠한 차이가 있을까요??

RestTemplate

• Rest API를 호출하고, 응답을 제어할 수 있는 스프링에서 제공하는 클래스입니다.
• 스프링 3.0에서부터 지원하는 RestTemplate은 HTTP 통신에 유용하게 쓸 수 있는 템플릿입니다.
• REST 서비스를 호출하도록 설계되어 HTTP 프로토콜의 메서드 (GET, POST, DELETE, PUT)에 맞게 여러 메서드를 제공합니다.
• 통신을 단순화하고 RESTful 원칙을 지킵니다.
• 멀티쓰레드 방식을 사용합니다.
• Blocking 방식을 사용합니다.

그러나, 스프링 5.0에서 WebClient가 나오면서 WebClient를 공식 문서에서는 추천해주고 있다. (아직은 소문이지만, RestTemplate이 deprecated 될 수도 있다는 소리를 들어서, 이전에 RestTemplate를 사용한 것이 아니라 새로운 프로젝트를 하는 저의 경우에는 WebClient가 더 좋다고 생각했습니다.)

NOTE: As of 5.0 this class is in maintenance mode, with only minor requests for changes and bugs to be accepted going forward. Please, consider using the org.springframework.web.reactive.client.WebClient which has a more modern API and supports sync, async, and streaming scenarios.

WebClient

• 스프링 5.0에서 추가된 인터페이스입니다.
• 싱글 스레드 방식을 사용합니다.
• Non-Blocking 방식을 사용합니다.
• JSON, XML을 쉽게 응답받습니다.

따라서 가장 큰 차이점은 Non-Blocking 여부와 비동기화 여부입니다.

• 즉, WebCLient는 시스템을 호출한 직후에 프로그램으로 제어가 다시 돌아와서 시스템 호출의 종료를 기다리지 않고 다음 동작을 진행합니다. 따라서 호출한 시스템의 동작을 기다리지 않고 동시에 다른 작업을 진행할 수 있습니다.
• 그리고 WebClient는 block()을 사용해서 Non-Blocking과 Blocking을 자유롭게 변경할 수 있습니다.
• 따라서 이러한 장점을 많이 가지고 있고, 공식 문서에서 추천하는 WebClient를 저희 프로젝트에 도입하게 되었습니다.
• 현재는 외부 API를 호출하고 나서 외부 API의 응답값을 DTO로 변환하여 DB에 저장하는 방식으로 진행하고 있어서 WebClient를 Blocking으로 사용하고 있습니다... 그래서 큰 장점을 활용하지 못하고 있지만, 앞으로 사용자가 많아진다면 아키텍처 구조를 변경하여 WebClient를 Non-Blocking 구조로 변경할 예정입니다.!

참고 자료 1 : https://velog.io/@chlwogur2/Spring-외부-API-호출-로직에-관해

참고 자료 2 : https://tecoble.techcourse.co.kr/post/2021-07-25-resttemplate-webclient/

💼 WebClient 사용해서 외부 API 호출하기

1. 의존성 추가하기

implementation 'org.springframework.boot:spring-boot-starter-webflux'

2. WebClient 생성하기

• Builder를 사용하여 WebClient를 생성하겠습니다.
• 이때, 외부 API의 주소를 baseUrl에 AWS Lambda의 EndPoint(API GATEWAY)를 작성해주었습니다.

WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

3. 외부 API 호출하기

• WebClient로 외부 API를 Post 메서드를 사용해서 호출해줍니다.

Map<String, Object> bodyMap = new HashMap<>();
bodyMap.put("url", pageUrl);

WebClientResponse webClientResponse = webClient.post()
                    .bodyValue(bodyMap)
                    .retrieve()
                    .bodyToMono(WebClientResponse.class)
                    .block();

• 위에 같이 webClient.post().bodyValue(bodyMap)을 사용하면 아래의 postman처럼 보내는 것과 동일한 형태입니다.

• block() 을 이용해서 Non-Blocking 형태가 아닌 Blocking 형태로 변경할 수도 있습니다.
  • 현재는 외부 API를 호출하고 나서 외부 API의 응답값을 DTO로 변환하여 DB에 저장하는 방식으로 진행하고 있어서 blocking으로 사용했습니다.
• retrive() 는 CleintResponse 개체의 body를 받아 디코딩하고 사용자가 사용할 수 있도록 미리 만든 개체를 제공하는 간단한 메소드 입니다.
• retrive() 를 사용할 때는, toEntity(), bodyToMono(), bodyToFlux() 이렇게 response를 받아올 수 있습니다.
  • bodyToFlux, bodyToMono 는 가져온 body를 각각 Reactor의 Flux와 Mono 객체로 바꿔줍니다.
  • 이때, mono는 외부 서비스에 요청을 할 때 최대 하나의 결과를 예상할 때 Mono를 사용해야 합니다.
  • 외부 서비스 호출에서 여러 결과가 예상되는 경우 Flux를 사용해야 합니다.
  • 저희 서비스는 하나의 결과가 나오기 때문에, 응답 결과를 bodyToMono로 받아오겠습니다.

WebClient 사용방법 참고 자료 : https://thalals.tistory.com/379

Mono, Flux 참고 자료 : https://recordsoflife.tistory.com/799

4. 외부 API 에러 처리하기

외부 API의 응답 status가 400대, 500대 에러가 발생할 경우, RuntimeException를 발생시켜서 null을 반환하도록 하였습니다.

• 외부 API의 오류로 인해서 Spring Boot(EC2)에도 오류를 발생하면 서로 너무 의존하고 있다고 생각해서, null을 반환하여 Spring Boot에는 외부 API 결과에 영향을 받지 않도록 하였습니다.

WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

Map<String, Object> bodyMap = new HashMap<>();
bodyMap.put("url", pageUrl);

try {
    WebClientResponse webClientResponse = webClient.post()
            .bodyValue(bodyMap)
            .retrieve()
            .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                throw new RuntimeException("4xx");
            })
            .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                throw new RuntimeException("5xx");
            })
            .bodyToMono(WebClientResponse.class)
            .block();
} catch (Exception e) {
    return null;
}

에러 참고 자료 : https://dkswnkk.tistory.com/708

2️⃣ 본론 2

😎 외부 API 호출 응답값 로직 변경 이유

이전에는 Map<String, Object> response로 외부 API 호출 응답값을 받았습니다.

WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

Map<String, Object> bodyMap = new HashMap<>();
bodyMap.put("url", pageUrl);

Map<String, Object> response = webClient.post()
        .bodyValue(bodyMap)
        .retrieve()
        .bodyToMono(Map.class)
        .block();

JSONParser jsonParser = new JSONParser();

Object obj = jsonParser.parse(response.get("body").toString());

JSONObject jsonObject = (JSONObject) obj;

따라서, JSONObject에서 각각의 속성값(title, thumbnail_url, descrption 등)을 가져와서 Object를 각각의 속성값에 맞는 타입(string, long 등)으로 변환해줘야 했습니다.

이 과정에서 만약에 null이면 타입을 변환할 때 에러가 발생하므로 null인지 파악하는 코드도 추가해줘야 했습니다.

public Article saveArticle(JSONObject crawlingResponse, User user, String pageUrl) {

    Article article = Article.builder().user(user).pageUrl(pageUrl)
            .title(Optional.ofNullable(crawlingResponse.get("title")).map(Object::toString)
                    .orElse(null))
            .thumbnailUrl(Optional.ofNullable(crawlingResponse.get("thumbnail_url"))
                    .map(Object::toString).orElse(null))
            .description(Optional.ofNullable(crawlingResponse.get("description"))
                    .map(Object::toString).orElse(null))
            .author(Optional.ofNullable(crawlingResponse.get("author")).map(Object::toString)
                    .orElse(null))
            .authorImageUrl(Optional.ofNullable(crawlingResponse.get("author_image_url"))
                    .map(Object::toString).orElse(null))
            .blogName(
                    Optional.ofNullable(crawlingResponse.get("blog_name")).map(Object::toString)
                            .orElse(null))
            .publishedDate(Optional.ofNullable(crawlingResponse.get("published_date"))
                    .map(Object::toString).map(Long::parseLong).map(
                            TimeService::fromUnixTime).orElse(null))
            .siteName(
                    Optional.ofNullable(crawlingResponse.get("site_name")).map(Object::toString)
                            .orElse(null)).build();

    return articleRepository.save(article);
}

• 앞으로 속성값이 늘어날 때마다 null 에러 처리 및 타입 변경을 일일히 해줘야 했습니다.
• 그리고 JSONParser jsonParser = new JSONParser();는 decrepted되었다고 합니다.
• 따라서 JSONObject를 사용하지 않기로 하였습니다.

JSONParser 관련 자료 : https://myeongju00.tistory.com/77

따라서 ObjectMapper를 이용해서 원하는 DTO로 변환하도록 하였습니다!

외부 API 호출하여 받은 JSON 값을 DTO로 변환하기

현재 외부 API인 AWS Lambda에서는 아래의 값을 응답 Body로 반환하고 있습니다.

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json"
  },
  "body": "{\"type\": \"place\", \"page_url\": \"https://map.kakao.com/?map_type=TYPE_MAP&itemId=\", \"site_name\": \"KakaoMap\", \"lat\": 37.50359, \"lng\": 127.044848, \"title\": \"서울역\", \"address\": \"서울\", \"phonenum\": \"1234-1234\", \"zipcode\": \"12345\", \"homepage\": \"https://www.seoul.co.kr\", \"category\": \"지하철\"}"
}

위의 구조를 큰 형태로 보면 statusCode, headers, body로 이루어져 있음을 알 수 있습니다.

아래와 같은 DTO로 응답을 받을 수 있습니다.

@Getter
@NoArgsConstructor
public class WebClientResponse {

    private String statusCode;
    private WebClientHeaderResponse headers;
    private String body;
}

그리고 body는 아래의 WebClientBodyResponse 형태를 띄고 있습니다.

@Getter
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class) //응답값이 python의 snake case이므로 아래의 속성값을 snake case로 변경해줍니다.
@NoArgsConstructor
public class WebClientBodyResponse {

    // 공통 부분
    private String type;
    private String description;
    private String pageUrl;
    private String siteName;
    private String thumbnailUrl;
    private String title;

    // Video 부분
    private String channelImageUrl;
    private String channelName;
    private String embedUrl;
    private Long playTime;
    private Long watchedCnt;
    private Long publishedDate; // Video, Article 공통 부분

    // Article 부분
    private String author;
    private String authorImageUrl;
    private String blogName;

    // Product 부분
    private String price;

    // Place 부분
    private String address;

    @JsonProperty("lat")
    private BigDecimal latitude;

    @JsonProperty("lng")
    private BigDecimal longitude;

    @JsonProperty("phonenum")
    private String phoneNumber;
    private String zipCode;

    @JsonProperty("homepage")
    private String homepageUrl;
    private String category;
}

따라서 아래의 .bodyToMono(WebClientResponse.class)에서 외부 API 호출하여 받은 JSON 값을 WebClientResponse DTO로 변환해주고. ObjectMapper를 통해서 String으로 들어온 WebClientResponse의 body 부분을 WebClientBodyResponse DTO로 변환해주는 작업을 수행해주면 됩니다.

WebClient webClient = WebClient.builder().baseUrl(crawlingApiEndPoint).build();

Map<String, Object> bodyMap = new HashMap<>();
bodyMap.put("url", pageUrl);

try {
    WebClientResponse webClientResponse = webClient.post()
            .bodyValue(bodyMap)
            .retrieve()
            .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                throw new RuntimeException("4xx");
            })
            .onStatus(HttpStatus::is4xxClientError, clientResponse -> {
                throw new RuntimeException("5xx");
            })
            .bodyToMono(WebClientResponse.class)
            .block();

    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

    return objectMapper.readValue(
            webClientResponse != null ? webClientResponse.getBody() : null,
            WebClientBodyResponse.class);


} catch (Exception e) {
    return null;
}

• 이때 유의할 점은 objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);을 사용했다는 점입니다.
• json을 Dto로 변환하는 과정에서 맵핑되지 않는 속성이 있는 경우 오류를 발생시키지 않고 서로 동일한 속성값만 변환해줍니다.

objectAmpper 관련 참고 자료 : https://tomining.tistory.com/191

public Article saveArticle(WebClientBodyResponse crawlingResponse, User user, String pageUrl) {

    Article article = Article.builder().user(user).pageUrl(pageUrl)
            .title(crawlingResponse.getTitle())
            .thumbnailUrl(crawlingResponse.getThumbnailUrl())
            .description(crawlingResponse.getDescription())
            .author(crawlingResponse.getAuthor())
            .authorImageUrl(crawlingResponse.getAuthorImageUrl())
            .blogName(crawlingResponse.getBlogName())
            .publishedDate(TimeService.fromUnixTime(crawlingResponse.getPublishedDate()))
            .siteName(crawlingResponse.getSiteName()).build();

    return articleRepository.save(article);
}

따라서 이전에 방식보다 속성값의 타입을 따로 변환해주지 않아도 되고 null 처리도 안해도 되어서 간편해졌습니다!

3️⃣ 결론

• 외부 API를 호출하는 작업은 크게 오래 걸리지 않았지만, 응답 값을 받고 이를 저희 서비스에 맞는 형태로 변환해주기 위해서는 많은 작업과 시행착오가 있었습니다.
• 그러나, 이전보다 더 에러 처리부분에서 단단해지고 코드가 간략해진 모습을 보고 refactoring의 중요성을 다시 한 번 느끼게 된 것 같습니다.
• 위에서도 언급했지만, 현재는 외부 API를 호출하고 나서 외부 API의 응답값을 DTO로 변환하여 DB에 저장하는 방식으로 진행하고 있어서 WebClient를 큰 장점인 Non-Blocking을 활용하지 못하고 있지만, 앞으로 사용자가 많아진다면 아키텍처 구조를 변경하여 WebClient를 Non-Blocking 구조로 변경해야 제대로된 WebClient를 사용할 수 있겠다는 생각을 했습니다!
• 이전에 WebClient를 사용할 때에는 응답값의 구조를 제대로 살펴보지 않아서 Dto 변환이 어려워서 MAP 구조를 사용했는데, 이번 계기로 외부 API 응답값을 더 자세하게 살펴보고 이해하게 되어 더 적합한 refactoring이 가능했던 것 같습니다.☺️

이전에 'jacoco를 사용하여 test coverage report 적용하기'라는 글의 제목으로 test coverage report 작성시 발생한 문제점 해결책으로 Pull Request를 보내는 구조를 변경한 적이 있습니다.

https://handayeon-coder.github.io/posts/jacoco를-사용하여-test-coverage-report-적용하기/

https://velog.io/@da_na/TestCode-jacoco를-사용하여-test-coverage-report-적용하기

아래의 사진으로 이전 구조와 변경된 구조를 나타냈습니다.

즉, 1회의 Pull Request와 Merge 구조에서 총 2회의 Pull Request와 Merge 구조로 변경되었음을 알 수 있습니다.

따라서, 이러한 구조로 인해서 기존의 Git-Flow 구조에서 깔끔한 Develop Branch에서 Featrue Branch로 뻗어나가는 구조에서 Develop Branch에서 2개로 분기되는 구조로 Branch를 파악하기 어려운 구조가 되었습니다.

아래의 사진은 Upstream/develop 브랜치를 기준으로 본 Github Branch 구조입니다.

• 이전의 Git-Flow의 Branch 구조
• 바뀐 후의 Git-Flow의 Branch 구조

아래의 사진으로 이러한 구조가 나오게 된 이유를 파악해보면, 2회의 Pull Request & Merge 구조와 Merge의 방식 때문이었습니다.

• 1️⃣ Pull Request and Merge 사진
• 2️⃣ Pull Request and Merge 사진

Merge 방식은 pull Request를 Merge할 때 기본적으로 설정되어 있는 'Create a merge commit'이라는 것을 선택했습니다.

그러면 바뀐 후의 Git-Flow의 Branch 구조를 이전처럼 깔끔하고 파악하기 쉬운 Git-Flow Branch으로 변경하기 위해서는 어떻게 할까??

고민하다가, Merge 방식을 Squash and merge, Rebase and merge로 변경해보면 어떨까??라는 생각이 들었습니다.

해당 Squash and merge와 Rebase and merge이 어떻게 다른지 파악해보고 더 적절한 방식을 선택해보고자 하였습니다.

1️⃣ 본론

🖍️ Merge 방식 비교하기

1. Create a merge commit

하단의 있는 브랜치를 Main 브랜치(파란색), 위의 있는 브랜치(주황색)를 feature 브랜치라고 하겠습니다.

featrue 브랜치의 변경 이력 전체(a, b, c)를 main 브랜치에 합칩니다.

이때, m이라는 노드를 통해서 a + b + c가 main 브랜치에 추가됩니다.

2. Squash and merge

featrue 브랜치의 a + b + c 커밋들을 합쳐서 새로운 commit, abc를 만들어지고 main 브랜치에 추가됩니다.

feature 브랜치의 commit history를 합쳐서 깔끔하게 만들기 위해 사용합니다.

3. Rebase and merge

모든 commit들이 합쳐지지 않고 각각 master 브랜치에 추가됩니다.

각 commit은 모두 하나의 parent를 가지게 됩니다.

참고 자료 : https://im-developer.tistory.com/182

🔄 Merge 방식 변경하기

1️⃣번의 Pull Request & merge에서 선택한 Merge 방식은 Rebase and merge로 하기로 하였습니다.

이전과 같은 Bracnh 구조를 하기 위해서는 merge된 branch는 없애고 모든 commit들을 merge한 브랜치에 추가한 구조기 때문에 Rebase and merge 구조가 적합하다고 생각했습니다.

• 이전 Branch 구조
• Rebase and merge를 사용했을 때의 Branch 구조

아래와 같이 2회의 Pull Request and Merge가 있었지만, 이전처럼 Branch 구조로 변경되었습니다.

3️⃣ 결론

이번 계기를 통해서 더 자세하게 Github의 Merge 구조를 더 정확하게 파악해볼 수 있었습니다.

이전에는 Pull Request를 합칠 때에 기본으로 되어 있는 Create a merge commit만을 사용해서 merge를 했습니다. 이렇게 3가지 옵션으로 Create a merge commit, Squash and merge, Rebase and merge이 있는지 처음으로 알게 되었습니다.

따라서 더 다양한 시각을 가지게 되었고, Github를 더 효율적으로 사용함을 익혔을뿐만 아니라 앞으로 Github를 사용할 때에는 다양한 기능을 더 자세하게 살펴본 뒤에 프로젝트에 적합한 방식을 사용해야겠다고 생각했습니다.

이번 글에서는 Rebase and merge을 사용해서 merge했지만, Git-flow를 따른다고 했을 때 유용한 구조는 아래와 같다고 합니다.

develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지 후에 feature 브렌치를 삭제해버리는 점을 떠올려 보면, feature 브렌치의 커밋 히스토리를 모두 develop 브렌치에 직접 연관 지어 남길 필요가 없습니다.

master - develop 브렌치간 머지 : Rebase and Merge가 유용합니다. develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문입니다.

hotfix - develop, hotfix - master 브렌치간 머지 : Merge 또는 *Squash and Merge *모두 유용합니다. 때에 따라 골라 사용하면 좋을 것 같습니다. hotfix 브렌치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용하면 됩니다.

출처 : https://meetup.nhncloud.com/posts/122

현재 저희 팀에서는 위의 방식으로 합의되지 않아서, 당장 위의 구조로 변경할 수는 없지만 앞으로 프로젝트에서는 위의 머지 방식으로 commit 히스토리와 branch를 관리하여 Git-flow 방식을 더 효율적으로 사용해보고 싶다는 다짐을 했습니다.