[BE] Topic 패키지 관련 코드 리팩토링

[cpot5620]

작업 대상

Topic 패키지

📄 작업 내용

Topic 패키지 관련 코드 리팩토링 및 테스트 추가 구현

🙋🏻 주의 사항

TopicController는 구현되지 않은 테스트만 추가하였고, 관련 리팩토링은 수행하지 않은 상태입니다.
일정을 맞추기 위해, 해당 테스트 코드 리팩토링은 이후로 미루겠습니다.

스크린샷

📎 관련 이슈

closed #215

레퍼런스

[kpeel5839]

쥬니 너무 고생하셨습니다!!

몇개 의견 남겼습니다 확인 부탁드려용.

[kpeel5839]

emptyTopic 과 topicWithPins 를 나눈 이유가 있을까요?

[junpakPark]

나누더라도 해당 분기가 Service 내에서 발생해도 괜찮을 것 같은데
어떤 이유에서 컨트롤러에 두셨나요?

[cpot5620]

하나의 메서드는 하나의 기능만을 수행한다.

Service 내부에서 두 메서드는 서로 다른 기능을 수행하기 때문에 분리했습니다.

해당 코드가 서비스의 흐름을 제어하는 것 처럼 보이기 때문에 잘못된 구조로 보일수도 있을 것 같습니다.
하지만 이는, 해당 컨트롤러에서 사용하는 API 스펙이 동일하기 때문에 발생하는 문제라고 생각합니다.

[junpakPark]

토픽을 생성한다는 기능 자체는 하나가 아닐까요?
저희가 API 스펙을 동일하게 정했을 때 모두가 동의를 하고 넘어간 건
이게 하나의 기능이 맞다고 암묵적인 동의를 했다고 생각합니다.

[cpot5620]

저희가 API 스펙을 동일하게 정했을 때 모두가 동의를 하고 넘어간 건
이게 하나의 기능이 맞다고 암묵적인 동의를 했다고 생각합니다.

준팍 말씀에 동의합니다 ! 토픽을 생성한다는 기능은 하나로 볼 수 있을 것 같아요.
근데 저는 "토픽 생성" 이라는 기능을 조금 더 작은 단위로 생각했던 것 같아요.
(1) 비어있는 토픽 생성, (2) 핀을 통해 토픽 생성 으로요 ㅎㅎ

각 기능에 대해 하나의 API 명세로 가자고 동의가 되었다면, Service 구현 과정에서도 이 부분을 고려해야 했던 것 같아요.

만약, API 스펙을 동일하게 하자는 이야기가 해당 기능 구현 이후였다면, API를 고려한 서비스를 구현하는 것은 옳지 않다라고 이야기 했을 테지만, 제 불착입니다 !

분기처리는 Service에서 하는 것으로 수정하여 반영하였습니다 ~!

[yoondgu]

저도 하나의 기능이기에 Service에서 분기를 두는 쪽에 동의합니다!

[cpot5620]

추가적으로 의견을 달자면, Service에서 분기처리했을 때 나오는 아래와 같은 구조가 어색했던 것 같아요.

    public Long saveTopic(AuthMember member, TopicCreateRequest request) {
        List<Long> pinIds = request.pins();

        if (pinIds.size() > 0) {
            return saveTopicWithPins(member, request);
        }

        return saveEmptyTopic(member, request);
    }

return 하는 부분에서 저장하는 로직을 수행하는 것이 어색하다고 느끼는건 저뿐일까요 ㅠ_ㅠ

[cpot5620]

혼란을 드려 죄송합니다 ~
생각을 잘못 했어요.. 아래와 같이 수정하면 자연스럽네요 ㅎㅎ

    public Long saveTopic(AuthMember member, TopicCreateRequest request) {
        Topic topic = convertToTopic(member, request);
        List<Long> pinIds = request.pins();

        if (pinIds.size() > 0) {
            copyPinsToTopic(member, topic, pinIds);
        }

        topicRepository.save(topic);

        return topic.getId();
    }

[junpakPark]

쥬니 갓...

[kpeel5839]

제가 생각했을 때는 검증하는 것이 좋을 것 같다는 생각이 들어요!

사용자가 웹을 통해 접근한 경우를 고려해봤을 때, 해당 메서드를 통해 전달된 토픽의 id 가 존재하지 않는 경우라면, 사용자가 해당 토픽을 선택할 때에는 존재했지만, 같이 보기를 누르기 이전에 사라진 경우일 것 같아요.

저희가 이전에 delete 할 때 id가 존재하지 않는 경우를 검증해야 하는가에 대해서 토의할 때, 쥬니 말을 빌리면, 사용자가 삭제하려던 토픽이었으니 삭제하기 이전에 이미 삭제되었어도 사용자의 의도대로 된 것이니까 상관이 없지만, 이번에는 사용자가 해당 토픽의 내용을 보려고하는데 사라진 경우이니 사용자의 의도와 다른 방향으로 흘러갔다고 생각이 들기 때문에 예외를 터트리는 것이 맞을 것 같다는 생각이 드네요!

[cpot5620]

해당 사항 검증 로직 추가 및 테스트 추가 구현 완료하였습니다 !

[kpeel5839]

createPinAssociatedWithLocationAndTopic 은 반환값이 있기 때문에 사용하지 않았다는 말씀이신 건가용?

[cpot5620]

간단하게 정리하자면 맞는 말씀입니당

한줄요약
create~를 사용하면 반환 값이 발생하는데, copy가 필요한 곳에서 해당 반환 값을 사용하지 않는다. 즉, 반환 값을 무시하게 된다.

[kpeel5839]

오 이거 기가막히네요 ㅋㅋㅋㅋ

[junpakPark]

쥬니 코드 잘 봤습니다~!!
궁금한 점 댓글 남겨봤습니다 ㅎㅎ

[junpakPark]

validation 훌륭한데요?

[junpakPark]

저희 파라미터의 길이에 상관 없이 3개 이상이면 개행하기로 하지 않았나요?

[cpot5620]

@yoondgu @kpeel5839 우리 이거 얘기해봐요 .....ㅠ_ㅠ

[yoondgu]

처음 정할 때는 기준이 모호해지는 것때문에 무조건 하자고 얘기했었지만,
위 코드 같은 경우 개행이 오히려 가독성을 저해한다는 생각이 들긴 해요.. ㅜㅜ
또, 메서드 호출 시에도 파라미터에 개행을 하다보니 한 메서드 내 라인 수가 늘면서 읽기 피곤해지는 경우도 있더라고요.
그래서 메서드 호출 시에는 파라미터의 변수명이 길거나 개수가 많아서 한 줄을 넘어갈 때에만 개행을 하는 방법도 생각이 들어요

[kpeel5839]

저도 인정합니다

[junpakPark]

null인 경우의 예외 메시지도 단순히 null이라고 표현하는 것보다 메시지를 정확히 적어주시는 건 어떨까요?

[cpot5620]

TopicInfo를 크게 신경 못 썼네요 ㅎㅎ..

해당 사항 아래와 같이 수정했습니다 !

    private static void validateName(String name) {
        if (Objects.isNull(name)) {
            throw new IllegalArgumentException("이름은 null일 수 없스빈다.");
        }
        if (name.isBlank() || name.length() > MAX_NAME_LENGTH) {
            throw new IllegalArgumentException("이름 길이 이상");
        }
    }

[junpakPark]

스빈다요?ㅋㅋㅋ

[cpot5620]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 수정했습니다 ..

[junpakPark]

저랑 취향이 비슷하시군요 ㅋㅋ 좋습니다

[junpakPark]

validation 좋네요 👍

[junpakPark]

개행 해주시면 더 좋을 것 같습니다

[cpot5620]

이 부분을 놓쳤네요 !! 반영했습니다 !

[junpakPark]

이거 PinInfo를 새로 생성해야할 필요가 있을까요?
PinInfo는 Id값이 없는 단순한 VO라서 기존의 PinInfo를 바로 넣어줘도 될 것 같습니다!

[cpot5620]

VO라고 하기에는 내부에 값을 변경할 수 있는 update가 존재하고, 불변을 보장할 수 없지 않나요 ?

기존의 pinInfo를 그대로 사용한다고 가정했을 때, 하나의 트랜잭션에서
(1) 기존의 핀들을 복사한다.
(2) 복사된 핀의 값을 변경(update)한다.
라는 로직이 수행된다면, 기존의 핀의 데이터에도 변화가 생길 것 같아요.

현재 존재하는 기능은 아니지만, 특정 핀을 복사해서 나의 토픽으로 넣을 때 핀의 정보를 수정해서 넣을 수 있게끔 하는 기능이 추가될 수 있지 않을까요 ?

[junpakPark]

제가 (2) 사례를 고려하지 못했군요 ㅋㅋ

[junpakPark]

copyToTopic 메서드에서 반환값이 필요 없다는 생각은 동의합니다.
근데 반환 값이 있을 경우, topic과의 연관관계를 맺어주지 않은 상태로 반환한다는 말이
무슨 의미인지 잘 이해가 되지 않네요.
createPinAssociatedWithLocationAndTopic내의 topic.addPin(pin)이 연관관계를 맺어주고 있지 않나요?

[cpot5620]

간략하게 쓰려다보니 생략된 부분이 다소 존재해서, 혼란의 여지가 있었던 것 같아요.

반환값이 있을 경우, topic과의 연관관계를 맺어주지 않은 상태로 반환하고,
외부에서 해당 연관관계를 맺어주어도 됨 -> 이 방법은 객체가 불안정한 상태라고 판단 됨.

의 의미는 다음과 같습니다.

(1) copyToTopic 메서드를 사용하지 않고 createPinAssociatedWithLocationAndTopic를 재사용할 경우 반환 값을 외부에서 사용해야 한다. (반환 값을 무시하지 말아야 한다고 생각하기 때문에)

(2) (억지로라도 ?) 외부에서 사용할 수 있도록 하는 방법은 외부에서 연관관계를 맺어주는 방법이 있다.

(3) (2)의 방법을 위해서는 기존의 createPinAssociatedWithLocationAndTopic에서 연관관계를 맺어주는 로직을 제거하고, 해당 메서드를 호출하는 쪽에서 연관관계를 맺어주도록 수정한다.

(4) 이 방법은 객체를 불안정한 상태로 반환하는 것과 같다.

(5) 따라서, 별도의 메서드로 분리했다.

글로 표현하려다보니 전달이 잘 안될 수도 있을 것 같네요.
혹시 이해가 안 되신다면 다시 한 번 말씀해주세요 !

[yoondgu]

이 부분을 놓쳐서 추가 코멘트 남깁니다!
(1)에서 반환값을 무시하지 말아야 한다고 생각하는 이유는, 반환값을 사용하지 않으면 불필요한 값을 반환하는 메소드 호출이 되기 때문일까요?
그렇다면 update 후 변경된 행의 개수를 반환하는 메서드 같은 경우는 어떻게 생각하시나요?
저는 해당 메서드를 사용할 때 절대 반환값을 쓸 일이 없다면 비효율적인 행위겠지만, 그게 아니라면 반환값의 사용은 꼭 필수는 아니라는 생각이 들어서 여쭤봅니다!

또, Pin 리팩터링 PR에 반영되어있는 Pin.copy 메서드를 보시면,
Pin 객체는 Pin.createXXX 메서드로만 생성할 것이라 기대하여 해당 메서드에서 PinImage의 복사를 함께 하도록 작성했는데요.
이 부분에 대한 고려도 같이 해야 할 것 같습니다!

[cpot5620]

(1)에서 반환값을 무시하지 말아야 한다고 생각하는 이유는, 반환값을 사용하지 않으면 불필요한 값을 반환하는 메소드 호출이 되기 때문일까요?

제가 아는 선에서는 "프로그래머가 예상치 못한 동작을 할 수 있다"라는 이유에서의 권장사항으로 알고 있습니다.
관련 링크

그렇다면 update 후 변경된 행의 개수를 반환하는 메서드 같은 경우는 어떻게 생각하시나요?

저는 변경 된 행의 개수를 검증하는 것도 필요하다고 생각해요.
예를 들어, 내가 id값을 통해 update하여 변경하려던 행의 개수가 1개라고 예상을 했었는데, 실제로 2개의 행이 변경될 수 있죠.
(테이블의 제약조건을 잘못 설정했거나 하는 이유로)

위 상황에서 이를 무시하게 되면 프로그래머가 예상치 못한 동작을 할 수도 있다고 생각해요.
그래서 반환 값을 무시하지 않고 검증을 수행해야 한다고 생각하는 편이에요.

물론, List의 add 메서드에서도 성공/실패 여부를 반환해주지만, 이는 대부분 무시하잖아요 ?
이는 위의 데이터베이스 예제와는 다르게, 프로그래머의 실수로 인해 add가 잘못 동작하는 경우가 없어서 무시하는 것이라고 생각해요.
(예외가 아닌, 예기치 못한 동작을 말하는 겁니다 !!)

저는 해당 메서드를 사용할 때 절대 반환값을 쓸 일이 없다면 비효율적인 행위겠지만, 그게 아니라면 반환값의 사용은 꼭 필수는 아니라는 생각이 들어서 여쭤봅니다!

사실, 권장사항일 뿐 항상 지켜야 하는 것은 아니라고 생각해요.
재사용하지 않은 이유에 대해 추가적인 의견을 덧붙이자면, 재사용했을 때의 코드를 확인하면 조금은 납득이 되실까 싶어요.

   // Pin 클래스의 일부

   public void copyToTopic(Topic otherTopic) {
        createPinAssociatedWithLocationAndTopic(
                pinInfo.getName(),
                pinInfo.getDescription(),
                location,
                otherTopic
        );
    }

저는 위 코드에서 메서드 이름과는 다르게, 핀을 복사한다는 로직이 안 보이는 것 같아요.

또한, createXXX 메서드를 재사용 하게 됐을 경우, 나중에 정책이 변경되면 copyToTopic 메서드에도 영향이 가지 않을까요?
예를 들어, 핀 사진에 대한 저작권 문제로 인해, 복사시에는 핀 사진을 제외하고 복사해야하는 경우에요 !
파라미터에 null을 넣어주는 방법도 있겠지만, Pin과 PinImage 사이의 연관관계 매핑을 해주는 작업에서 문제가 발생하지 않을까 싶네요.
(적절하지 않은 예시일수도 있습니다 ㅎㅎ)

추가적인 질문이나, 의견 환영입니다 !!
글 쓰는 솜씨가 없어서, 의사 전달이 제대로 이루어졌을지 모르겠네요.
이해가 안 되는 부분이 있다면 내일 추가적으로 이야기해봅시다 !

[yoondgu]

자세히 설명해주셔서 이해가 갔습니다 !!
저는 반대로 copy도 사실상 객체 생성이기 때문에 정책 변경 시 copyToTopic에 영향이 가는 것이 당연하다고 생각했고,
객체를 생성하는 방식이 여러 가지로 분화된다는 점이 걸려요!
하지만 반환값을 쓰지 않는 것을 지양하고자 하는 이유도 이해가 가서 다른 분들 의견까지 마저 듣고 정리하면 좋겠네요!

[junpakPark]

SaveEmptyTopic과 saveTopicWithPins을 굳이 나눠줄 필요 있을까요?

해당 부분만

        pinIds = request.pins();
        if (pinIds.size() > 0) {
            List<Pin> originalPins = findAllPins(pinIds);
            validateCopyablePins(member, originalPins);
            copyPinsToTopic(originalPins, topic);
        }

이렇게 처리하면 한 메서드로 처리 가능할 것 같습니다.

[cpot5620]

(메서드 명만 보고 해당 로직이 무엇인지 유추할 수 있게 하기 위해) 조건문에 따라 다른 로직을 수행한다면, 이는 메서드로 분리해야 한다고 생각해요 !

이럴 경우, 해당 코멘트에도 남겨놓았지만 해당 구조가 조금 어색하게 느껴지네요.. 메서드 분리를 하지 말아야 할까요

[cpot5620]

ㅎㅎㅎㅎㅎㅎㅎㅎ 생각을 잘못 했네요 수정했습니다

[junpakPark]

updateTopicStatus도 수정하는 메서드가 필요할 것 같습니다

[cpot5620]

해당 사항 반영했습니다 !

[yoondgu]

P1: 꼭 반영해주세요 (Request changes)
P2: 적극적으로 고려해주세요 (Request changes)
P3: 웬만하면 반영해 주세요 (Comment)
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
P5: 그냥 사소한 의견입니다 (Approve)

쥬니 고생 많으셨습니다!! ㅎㅎ 꼼꼼하게 잘 해주셔서 오히려 제가 반영해야 할 부분이랑, 같이 얘기할 만한 것들 위주로 코멘트 남겼습니다!

[yoondgu]

저도 하나의 기능이기에 Service에서 분기를 두는 쪽에 동의합니다!

[yoondgu]

P3. 사소한 부분이긴 한데, 한 클래스 내에서 id와 topicId 변수명이 둘 다 쓰이는데 topicId로� 통일하면 어떨까요?

[cpot5620]

topicId라는 변수명으로 통일 했습니다 ~!

[yoondgu]

처음 정할 때는 기준이 모호해지는 것때문에 무조건 하자고 얘기했었지만,
위 코드 같은 경우 개행이 오히려 가독성을 저해한다는 생각이 들긴 해요.. ㅜㅜ
또, 메서드 호출 시에도 파라미터에 개행을 하다보니 한 메서드 내 라인 수가 늘면서 읽기 피곤해지는 경우도 있더라고요.
그래서 메서드 호출 시에는 파라미터의 변수명이 길거나 개수가 많아서 한 줄을 넘어갈 때에만 개행을 하는 방법도 생각이 들어요

[yoondgu]

P3. 매튜 PR에 남긴 코멘트와 같은 내용인데, 통일하는 게 좋을 것 같아 똑같이 의견 여쭐게요! (TopicInfo를 외부에서 받기)

코멘트 링크

[cpot5620]

P3. 이 부분은 취향 차이일 것 같은데, 한 방향으로 통일하면 좋을 것 같아서 의견 여쭤봅니다!
Pin과 PinInfo의 경우 저는 생성 시 파라미터에서 포장된 PinInfo를 직접 받도록 변경했습니다. (관련 커밋)
이렇게 하면
Pin에 쓰이는 name, email, imageUrl, role이 PinInfo의 검증 로직을 거친다는 사실을 명시할 수 있고
PinInfo에 필드가 추가되어도, Pin의 생성자 파라미터를 수정할 필요가 없기 때문입니다.
매튜의 생각은 어떠신가요?!
[도이의 코멘트] (#237 (comment))

제 의견은 아래와 같습니다 !

Pin에 쓰이는 name, email, imageUrl, role이 PinInfo의 검증 로직을 거친다는 사실을 명시할 수 있고

저는 PinInfo의 검증 로직을 거친다는 사실을 명시하는 것의 장점이 무엇인지 잘 모르겠어요.
혹시, Pin 관련 정책(이름 길이 등)을 확인할 때, 접근하는 depth를 줄일 수 있다는 것일까요 ?
이와 관련하여 의견 주시면 감사하겠습니다 !

오히려 저는 각 데이터를 그대로 매개변수로 전달하여야 한다고 생각하는 편이긴 해요.
현재는 단순히 PinInfo를 만들기 위해서 값을 그대로 사용하지만, 정적 팩토리 메서드 내부에서 별도의 정책에 따라 해당 데이터를 가공하는 경우가 있지 않을까요 ?
물론, PinInfo에서는 마땅한 예시가 없는 것 같지만 다른 정적 팩토리 메서드에서도 동일하게 적용한다면, 위와 같은 문제가 발생할수도 있을 것 같아서요 !

PinInfo에 필드가 추가되어도, Pin의 생성자 파라미터를 수정할 필요가 없기 때문입니다.

Pin의 생성자 파라미터라는 것이 정적 팩토리 메서드(이하 정팩메)의 파라미터를 말씀하신 것이겠죠 ?
이 부분은 확실히 매리트 있는 것 같아요.

하지만, PinInfo를 생성하는 정팩메에서는 동일하게 파라미터가 추가되어야 할 것이고, Pin을 생성하기 위해 PinInfo를 생성하는 쪽에서도 마찬가지겠죠 ?
코드 전체적인 부분에서는 변경해야 하는 사항이 크게 달라지진 않는다고 생각이 들어요.

도이가 위와 같이 말씀하신 이유는 PinInfo의 변화가 Pin에 영향을 미치지 않게 한다는 것으로 받아들이면 될까요 ?
저는 PinInfo가 Pin에서 사용하기 위한 객체라면 Pin에 영향이 가도 괜찮지 않을까 싶어요 ㅎㅎ..

이 부분은 내일 다 같이 이야기 해봅시다 !!
내일 이야기 후에 정해지게 되면, 상황에 맞게 반영하도록 할게요 !

[yoondgu]

P3. 이 부분도 매튜 PR에 남긴 코멘트와 같은 내용인데, 통일하는 게 좋을 것 같아 똑같이 의견 여쭐게요!
(update는 객체 재할당해서 불변객체처럼 쓰기)

코멘트 링크

[cpot5620]

완전 동의합니다 ! 불변 객체처럼 사용하는거 무지 좋아요.

제 코드 상에는 pinInfo가 불변 객체 아니다 보니, 핀을 복사하는 과정에서 새로운 PinInfo를 생성했었는데요.
불변 객체라면 그대로 사용해도 무관할 것 같네요 !!

[yoondgu]

P4. Wrapper vs primitive 타입 기준이 어떻게 되시는지 궁금합니다!
null이 오면 안되는 경우, primitive 타입을 써서 이를 드러내는 것이 좋다는 생각도 들어서용

[cpot5620]

primitive 타입이 null 값이 없지 않나요 !!?

Wrapper 타입을 쓴 이유는 null 값이 들어오면 안 되는 경우라고 생각해서 사용하였습니다.

[yoondgu]

저는 primitive는 null을 못받기 때문에 오히려 파라미터로 null을 넘길 여지를 없애준다고 생각했습니다!
Wrapper를 쓰면 pinCount에 null이 들어와도 잘못된지 모른 채로 Response가 정상 생성되기 때문에용

[cpot5620]

그렇군요 !

primitive 타입을 사용한다고 가정하면,
내부 로직이 잘못되어서 토픽에 존재하는 핀의 개수를 null 값으로 처리했을 때, Response에는 0으로 들어가는 것이 잘못된 동작이라고 생각했어요 !

[yoondgu]

이 경우에는 0이 할당되지 않고 NPE가 터져요!

[yoondgu]

validate을 이렇게 빼니까 훨씬 깔끔하네요!!

[yoondgu]

findAllReadable이라는 네이밍이 아주 이해하기 좋네요!!
PinQueryService의 findAll 메서드 네이밍도 동일하게 통일하겠습니다 😀

[yoondgu]

근데 저희 모든 조회 쿼리에서 isDeleted = true 인 건 걸러줘야겠네요....?

[cpot5620]

맞아요.. 걸러줘야해요..
근데, 아직 유저가 삭제하는 경우가 없다고 해서, 따로 구현하지 않았는데 Repository에서 @Query 어노테이션을 활용하면 될 것 같아요.

[yoondgu]

유저 삭제가 없으니 저도 아직은 구현 안하겠습니닿ㅎㅎ
@where 를 쓰면 @query 처럼 매 쿼리 마다 직접 저희가 설정해줄 필요 없을 것 같은데,
그러면 대신 테스트에서 쓰던 조회 메서드들 따로 처리해줘야 해서
나중에 한번에 수정하는 게 좋을것같아요

https://www.baeldung.com/spring-jpa-soft-delete

[yoondgu]

P3. TopicCommandService와 예외처리 메서드 분리 방식을 통일해도 괜찮을 것 같아요!

[cpot5620]

어떤 메서드에서는 조건문 안에서 예외를 던지고, 어떤 메서드에서는 조건문 안에서 early return을 해서 이를 통일해달라는 말씀이신거죠 ?

사실 이 부분을 적용하고자 했었는데, 부정 조건문 사용을 지양하려다보니까 통일이 잘 안 되더라구요 ㅠ_ㅠ
혹시 좋은 아이디어 있으실까요 !?

[yoondgu]

이미 TopicCommandService에서 쓴 방식이 좋아서, 같은 방식으로 하면 좋겠다 싶었어요!!
이렇게요

    public TopicDetailResponse findDetailById(AuthMember member, Long topicId) {
        Topic topic = findTopic(topicId);
        validateReadAuth(member, topic);

        return TopicDetailResponse.from(topic);
    }
    
    private void validateReadAuth(AuthMember member, Topic topic) {
        if (member.canRead(topic)) {
            return;
        }

        throw new IllegalArgumentException("조회 권한이 없습니다.");
    }

[cpot5620]

반영했어요 !!

[yoondgu]

권한에 따른 테스트까지.. 👍👍 핀 관련 테스트에도 반영해야겠어요

[github-actions]

Unit Test Results

  42 files    42 suites   7s ⏱️
179 tests 179 ✔️ 0 💤 0 ❌
189 runs  189 ✔️ 0 💤 0 ❌

Results for commit 5699a7d.

[junpakPark]

수고하셨습니다 쥬니!!

[yoondgu]

수고 많으셨습니다 !!!

[kpeel5839]

고생했어요 쥬니짜아아앙