DevJong12

Electron 학습기록

Jong12 — Mon, 13 Jan 2025 14:29:59 +0900

카드 이벤트를 잡기위한 기록

일반적으로 카드리더기를 잡으려면 USB를 통해 연결을 잡은 이후, 카드리더기인 경우 해당 카드정보를 Electron에서 React로 이벤트를 쏴주는 형태로 가야함.

여기서 문제는 다음과 같음.

Electron은 기본적으로 Node.js기반 Main Processor에서 실행이 된다.
1. 해당 영역을 ipcMain이라고 칭하며, 해당 영역은 Node.js로 구동이 되고, Electron이 실행하는 main.js 또는 electron.js등등 실행에 필요한 소스코드 영역임.
2. React Web(크로미움) 영역 에서는 Node.js를 통한 특정 라이브러리를 실행할 수가 없음.
현재 내가 카드리더기를 읽기 위해 사용되는 모듈은 아래의 링크와 같음.(약간 변형은함)
위의 라이브러리들에서 PCSC관련 라이브러리는 Node.js를 통해 C++ 레벨의 코드를 실행한다.

문제의 해결방안은 다음과 같음.

렌더링 영역은 React에서 실행한다.
Node.js가 필요한 영역은 main영역으로 와서 실행한다.
이를 위해서는 채널을 열어야 하며 다음의 방법을 활용한다
- React

const {ipcRenderer} = window.require("electron");

// 보내고 받기.
export default function () {
	const handleChannel = (event, args) => {
    	console.log('test');
    }
    useEffect(()=> {
        console.log('[ipcRenderer Effect] Renderer Effect')
        ipcRenderer.send('channel', 'hihi') // Data는 Optional , Json을 줘도 된다.
        ipcRenderer.on('channel', handleChannel);
    }, [ipcRenderer])
    
    return <>
        Test
    </>
}

Main.js

const ipcMain = require('electron').ipcMain;

// 둘중 편한방법을 사용하면됨.
ipcMain.on("channel", (event, data) => {
  event.sender.send("channel", "From Main Process");
});

ipcMain.on("channel", (event, data) => {
  event.reply("channel", data);
});

차라리 라이브러리를.. nfc-pcsc 나 node-pcsclite 를 쓰는게 나아보이긴하는데... ㅠㅠ

글은 나중에 정리하는걸로..

[JUnit] JUnit을 활용한 다양한 테스트방법

Jong12 — Thu, 26 Sep 2024 15:32:54 +0900

글을 작성하기에 앞서서... 이 JUni이란게 뭔지에 대해서 앞의 아티클에 설명을 해놓았다.

해당글을 먼저 읽으면 좋을 듯하여 링크를 남겨놓는다..

https://devjong12.tistory.com/123

[JUnit] JUnit 이란?

목차 1️⃣ 글을 작성하기에 앞서..사실 글을 적을까 말까 고민했는데, 회사에서 JUnit에 대해서 교육을 하게 될 계기가 생겨서 작성을 하다 보니 너무 많은 지식을 망각했다는 것을 깨닫게 되었

devjong12.tistory.com

추가적으로 모든 코드는 아래의 Repository에서 확인이 가능합니다.

https://github.com/donsonioc2010/my-junit-example

GitHub - donsonioc2010/my-junit-example

Contribute to donsonioc2010/my-junit-example development by creating an account on GitHub.

github.com

1️⃣ JUnit, 유닛테스트를 위한게 아니야?

맞다. 기본적으로는 유닛테스트에 목표를 두고 있기 때문에 테스트의 주된 목적은 제목그대로 유닛테스트를 위한 도구다.

하지만 필자의 경우에는 Java를 베이스로 해서 Spring을 사용하는 Java + Spring(일명 자프링) 생태계를 활용한 개발을 하고 있다.

그러다 보니 특정 외부 API에 대한 타임체크나, DB에 대한 세션변경 등등의 다양한 설정의 테스트 또는 특정환경에서만의 테스트등이 필요할 수도 있다.

그런 특정환경 또는 특정 설정에 대한 테스트를 지원하고 있으며, 이 아티클은 어떠한 상황에서 활용이 가능한지를 기록해 보고자 한다.

2️⃣ Unit Test

JUnit이 존재하는 기본적인 이유인 유닛테스트부터 방법에 대해서 코드로 기록해보고자 합니다.

유닛테스트는 간단하게 메소드의 기능에 대한 테스트를 하는 것입니다.

테스트타겟 코드는 간단한 계산 기능으로, 아래의 코드를 참조하시기 바랍니다.

위와 같은 코드를 테스트를 해보고자 합니다. 간단하게 2개의 숫자를 더하고 더한 결과를 반환하는 코드입니다.

위의 코드는 이제 Calculator의 add메소드에 대한 테스트를 진행하는 테스트케이스 입니다.

Calculator객체를 생성하고, 숫자 두개를 add메소드에 제공하여 결과물을 받고, 이 받은 결과물이 개발자가 의도한 결과와 동일하게 작동하는 가를 확인하는 검증단계로 흐름이 이뤄집니다.

이처럼 단위테스트 자체는 간단하게 제작이 가능합니다.

단 위와같이 간단한 경우는 간단한 로직뿐이고... 실제 작업을 하면서 저런 케이스는 많이 없겠지만요

3️⃣ 다양한 OS환경에서의 테스트

저도 자료들을 준비하면서 알게 된 방법중 하나입니다.

간단하게 Annotation만 추가하면 Jupiter에서는 OS별로 테스트를 실행할 수 있도록 환경을 제공해 주고 있습니다.

어노테이션은 @EnableOnOS로 org.junit.jupiter.api.condition패키지에 해당 어노테이션이 존재하고 있습니다.

해당 어노테이션은 아래처럼 이뤄져 있으며, 클래스 또는 메소드에 선언이 가능합니다.

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@ExtendWith({EnabledOnOsCondition.class})
@API(
    status = Status.STABLE,
    since = "5.1"
)
public @interface EnabledOnOs {
    OS[] value() default {};

    @API(
        status = Status.STABLE,
        since = "5.9"
    )
    String[] architectures() default {};

    @API(
        status = Status.STABLE,
        since = "5.7"
    )
    String disabledReason() default "";
}

실제 사용 방법은 아래의 코드를 보면 직관적으로 확인이 가능합니다.

필자의 경우 메소드에 모든 케이스를 기록하였으나, 클래스에 기록할 경우 전체 메소드에 동일하게 적용 됩니다.

위의 케이스를 실행하게 되면, 필자는 Mac을 사용하기 떄문에 Mac의 환경만 테스트가 진행됩니다.

테스트를 구현해 보면서 현재 컨테이너, 리눅스기반의 자프링 개발이 아닌 특정 어플리케이션 같은 부분들 즉 OS를 고려한 개발을 하게 될 경우에 유용한 테스트 방식이라고 생각을 할 수 있었습니다.

4️⃣ 반복테스트

여러번 동일한 테스트가 필요한 경우 사용할 수 있는 RepeatedTest입니다.

코드를 보면 바로 이해가 가능합니다.

위와 같이 명시가 가능하며, @RepeatedTest어노테이션을 통하여 테스트가 가능합니다.

DisplayName은 제가 수정을 안했으나, 실제 10회 테스트를 하며 반복테스트 하위로 10개의 테스트가 @RepeatedTest의 name Format에 맞게 표시 됩니다.

아래의 결과처럼요.

하지만, 이런 단순 반복테스트라면 저는 부하테스트를 할 것 같습니다. 성능을 확인해야 하는 경우도 많기 때문에요.

5️⃣ 가정기반 테스트

AssumptionsTest라고 하며, 특정 조건이 만족해야 테스트를 진행하도록 할 때, 사용하는 테스트입니다.

org.junit.jupiter.api의 Assumptions를 사용해서 조건을 만족시키는 경우 테스트를 진행합니다. 간단한 예제는 아래 코드를 확인 가능합니다.

위의 코드처럼 최초에 Property를 부여하고, 해당 값이 Test인경우, Test가 아닌 경우로 테스트 케이스를 진행합니다.

실제 그러면 실행이 되어야 하는 테스트케이스는 두건이 됩니다. 또한, 아래의 이미지처럼

위처럼 특정 Value나 상황이 필요한 경우에만 Test를 진행하게 하는법이 필요하면 재고해 보면 좋을 듯 합니다.

6️⃣ 타임아웃 테스트

특정 시간내에 기능이 실행되어야 하는 경우 테스트를 통과하게 하는 것 또한 가능합니다.

방법은 크게 두가지로, @Timeout어노테이션을 사용하거나 Jupiter의 Assertions의 assertTimeout통해 검증이 가능하며, 샘플코드는 아래와 같습니다.

위처럼 assertTimeout의 경우에는 Duration을 인자로 받아, 특정 로직이 실행시 테스트시간의 검증이 가능합니다.

반면에 @Timeout어노테이션의 경우에는 희망하는 시간, 시간의 단위를 기록하여 로직의 검증이 가능합니다.

만약 시간의 단위를 기록하지 않으면 기본적으로 초단위로 지정이 되며, 실제 외부 API를 검증 테스트해야 하는 경우 또는 MSA환경에서 API콜을 통한 테스팅이 필요한 경우 유용하지 않을까 넌지시 생각이 들었던 방법입니다.

7️⃣ 글을 마치며..

사실 필자 역시도 유닛테스트를 제외하고 거의 하고 있지는 않습니다만, 자주 활용이 가능할만한 것들도 많이 있다고 생각합니다.

해당 챕터에서는 어떠한 방식의 테스트 종류가 있고, 어떻게 활용해 볼 수 있을까에 대한 주관만 가져가면 좋지 않을까 합니다.

그 뒤에 자신에게 맞는 방법을 적용하는 것은 글을 읽는 독자들의 판단에 맡길 뿐이라고 저는 생각합니다.

또한 해당 포스트에서는 다루지 않은 방법이 많이 존재하는데요, TestContainers를 통한 특정환경 테스트라든가, @Tag어노테이션을 바탕으로 특정 빌드환경에서 특정 테스트만 실행되도록 하는 환경등 방식은 많이 존재합니다. 아니면 문서를 자동화 하기 위한 SpringRestDocs등의 환경등에 대해서도 추가가 가능합니다.

해당 아티클에는 제기준에서 활용이 가능할만한 항목들에 대해서만 기록을 해뒀기 때문에, 다른 기능들에 대해 더 설명이 필요하면 Third Party에 대해서 알아보시길 바랍니다.

다음 글은 JUnit의 유닛테스트에서 자주 사용하는 Jupiter의 Assertions와 AssertJ의 Assertions에 대해 기록하고자 합니다.

읽어주셔서 감사합니다.

[JUnit] JUnit 이란?

Jong12 — Sat, 21 Sep 2024 15:26:53 +0900

1️⃣ 글을 작성하기에 앞서..

사실 글을 적을까 말까 고민했는데, 회사에서 JUnit에 대해서 교육을 하게 될 계기가 생겨서 작성을 하다 보니 너무 많은 지식을 망각했다는 것을 깨닫게 되었다..

잊으면 안되는데도... 심지어 최근에 코드를 작성할 일도 많이 없었어서 코드도 어떻게 작성하는거였지 하면서 약간씩 망각하게 되는걸 보고 잘쓰던거여도 기록을 해두자 생각을 하게 되어서 이렇게 글로 작성해두려 한다.

해당 시리즈는 JUnit에 대해서, 그리고 JUnit을 바탕으로 무엇을 할 수 있는지, JUnit의 응용방법, 라이브러리에 대한 소개를 진행할 예정이다.

2️⃣ JUnit 그게 뭔데?

JUnit이란 Java 프로젝트에서 단위 테스트를 진행하기 위한 프레임워크로, 코드의 작동 방식을 확인하고 변경으로 인한 오류를 사전에 방지하는 도구이다.

테스트 주도 개발론인 TDD를 자바진영에서 이루기 위해서는 꼭 필요한 프레임워크이며, Kent Beck과 Erich Gamma가 제작하였다.

3️⃣ JUnit의 의존성 구성

위의 이미지는 JUnit 5 Tutorial 에서 참조를 해왔다.

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

JUnit의 공식문서와 같이 이미지를 보면서 이해를 하게 되었는데, JUnit은 Vintage, Jupiter와 Third Party로 구성이 되어있어 JUnit 5에서도 오래된 테스트를 돌릴 수 있는 이유가 JUnit 5가 Vintage를 포함하고 있어서 가능한것을 알수가 있다...

또한 Assertj는 Junit에 포함이 되지 않는 것 자체는 알고 있었는데, Third Party중 하나가 Third Party여서 실행이 가능한게 아닐까 하는 생각을 해볼 수 있었다.

4️⃣ JUnit의 필요성

사실 해당 챕터에서 다룰 내용은 아니긴하다. 정확히는 JUnit보다는 Unit테스트가 필요한 이유라고 볼 수 있겠다. 유닛테스트가 필요한 이유로 봐도 생각해도 된다. 또한 필요성이라고 기록은 했으나, 장점으로 보면 좋을듯 하다.

첫번째로, 코드의 품질을 향상시켜 코드 자체의 신뢰성을 높이고, 코드가 변경이 되거나 하면서 발생하는 오류에 대하여 조기에 발견이 가능하고 빠른 수정이 가능해진다.

두번째로, JUnit은 개발자에게 코드의 변경에 대한 확신을 제공해준다. 이런 심리적으로 확신감을 준다는 말은, 추후 리팩토링과 기능을 추가하는 과정에서 코드의 안정성을 유지시키고 개발의 효율을 증대시키는 점이다.

세번째로, 개발자들간의 커뮤니케이션을 개선 할 수 있다. 테스트케이스는 테스트 자체의 목적도 있지만, 기능의 요구사항과 동작 방식을 명확하게 설명하는 문서의 역할도 할 수가 있다.

이게 가능한 이유는, JUnit을 결국 작성하려면 코드의 동작을 명확하게 명시해야 하며, 예상되는 결과를 검증해야 하기 때문이며 이 모든게 코드로 이뤄져 있기 때문에 코드를 읽고 해석이 가능하다면 불필요한 커뮤니케이션을 감소하는게 당연하기 떄문이다.

마지막으로 소프트웨어의 안정성을 높이게 되는데, 최근의 추세에 대부분의 프로젝트는 CI 와 CD가 당연하게 포함이 된다. 이런 자동화된 테스트와 배포의 과정에서 코드의 변경이 기존 시스템에 미치는 영향을 신속하게 파악하며, 안정적인 소프트웨어를 배포하는게 가능해지기 떄문이다.

5️⃣ JUnit의 사용방법 흐름

JUnit은 매우 단순하게 기능들에 대해서 테스트를 진행 할 수 있도록 되어있으며, 크게 아래의 4개의 단계를 거치면 된다.

JUnit의 라이브러리를 프로젝트에 추가한다.
@Test어노테이션을 활용하여 테스트 메소드를 작성한다.
테스트 러너를 사용해 테스트 케이스를 실행하며, 보통 필자는 IDE를 활요한다.
테스트가 실행된 결과를 확인

6️⃣ 단위테스트 작성 방법

위의 이미지처럼 @Test 어노테이션을 사용해 테스트 메소드를 정의한다.

assert메소드의 경우에는 필수는 아니나, 없으면 검증의 의미가 없는 빈 메소드지 않겠는가?

assert메소드는 검증의 단계기 때문에 넣는걸 권장한다.

순서는 다음과 같다. Calculator클래스 객체를 생성하고, 내부에 메소드를 호출해서 2와 3을 더했을때, 결과가 5가 나오는지를 확인하는 간단한 코드다.

7️⃣ JUnit의 단점? 고려사항?

JUnit을 사용하지 않는 환경에서 갑작스레 도입을 진행하려고 할때 한번쯤 생각해봤으면 좋을 항목들이다.

1. 개발팀의 규모

개발팀 규모가 큰 경우다. 이런 경우 코드의 변경이 빈번할 수 있기 떄문에 품질을 유지하면서 개발이 가능해지는 장점이 있다.

하지만 기존에 JUnit을 활용하고 있지 않았던 환경이라면 모든 개발자가 전부 JUnit을 학습해야 하는 부분들이 발생하며, 실제 JUnit테스트케이스를 작성해보지 않은 사람들은 테스트케이스를 작성해보면서 도입 초기에 생산성이 낮아질 수도 있는 부분을 염두해야 한다.

도입기간 과정에서 학습의 편차가 다르기때문에 유닛테스트의 결과에 만족을 못하는 시기가 존재할 수 있다.

2. 프로젝트 규모

프로젝트의 규모가 크고 복잡한 경우이다. 모놀리식으로 여러 시스템을 묶어놓는다든가, 많은 모듈을 동시에 실행시켜야 하는 환경등등..

많은 종류가 존재할 수 있겠다.

테스트 케이스는 많아지면 많아질 수록 전체 테스트를 진행하는 시간이 길어지게 된다. 테스트는 자주 쉽게 실행을 해야하는데, 길어지는 테스트 진행시간을 해결할 방법을 찾아야 하게 된다는 점이 해결해야 할 문제라 필자는 생각한다.

3. 코드의 복잡성

필자가 현재 재직중인 회사의 경우에는 오랜시간 개발을 하신 개발자님이 한분 계셨다. 그분은 트렌트에 맞게 개발하는 분은 아니셨다. 절차지향으로 개발을 하시던 분이었으며, 대부분 한개의 메소드에 모든 비즈니스로직이 포함되어 있었다.

그러다 보니 매우 복잡한 로직의 메소드만 제작을 하셨으며, 설명이 없으면 이해가 힘들정도였다. 테스트케이스 역시 존재하지 않았다.

이런 복잡한 코드로만 이루어진 경우에 JUnit을 도입하면 변경점이나 오류가 있을때 조기에 발견할 수 있는 장점이 있을 수는 있다.

하지만 이런 복잡한 로직의 분석이후 테스트케이스를 작성은 누가할것인가? 코드가 복잡할 수록 테스트케이스를 작성하는 상황이 배보다 배꼽이 더큰 즉 리소스가 더 많이들어가는 상황이 나와버릴 수도 있는 점을 유의해야 한다.

8️⃣ 글을 마치며

정리하면서, JUnit을 사용하면서 보니 이론을 실제로 경험해본 경우들이 대부분이라는게 눈에 보인다는게 신기하다.

필자의 경우에도 실제로 확신을 갖고 개발을 할 수 있는 점 때문에라도 JUnit은 너무 필요하다고 생각을 하게 되었으나, 처음에 적응을 하는 과정에서는 생산성이 심각하게 떨어졌던 과거가 있었던 것 같다.

JUnit이 꼭 장점만 있는 것이 아니기 때문에 염두를 해두면서 사용하면 좋을 것 같다.

다음 아티클은 JUnit으로 할 수 있는 테스트 케이스의 종류에 대해서 정리해보고자 한다.

내가 오픈소스 기여자?

Jong12 — Wed, 5 Jun 2024 09:41:39 +0900

결론부터 말하자면 사실 기뻐서 자랑하고자 쓴 글이다.

회사에서 성능테스트를 하면서 APM을 같이 붙여서 확인해 보고자 PinPoint를 같이 선택하였다. (편해서)

도중에 Profiles설정을 해야할 일이 좀 생겨서 핀포인트 Client페이지에있는 Document와 Guide페이지를 참고하고있었다.

아래와 같은 페이지다.

해당 페이지에서, Pinpoint개발자가 작성한 Pinpoint 기술문서 가 아래의 이미지처럼 helloworld.naver.com으로 링크를 페이지탭을 추가하고 있었다..

최근에 언제 한번 네이버 메일을 정리하면서 helloworld.naver.com의 도메인이 d2.naver.com으로 변경될 예정이라는 네이버 메일을 받은 적이 있던부분이 기억이 났고 도메인을 변경해서 링크를 실행해봤고 아래처럼 이미지가 출력되었다.

이걸 보고 들었던 생각이, '아 보기 불편하네'라는게 바로 들고서는 내가 바꿔봐야지 라는 생각을 했던 것 같다.

이후 프로젝트를 포크떠서 변경을 진행했었다.

링크만 고치면 되는 부분이기 때문에 별다른 테스트는 불필요 할거라는 생각이 들었었고, 그래도 한번만 실행해볼까 했는데... 의존성 문제로 실행해서 직접 확인까지는 실패했었다.

이후 PR로 컨트리뷰터가 되었고, 추후 3.0.1에 반영되어 나올 예정으로 보인다. (이게 진짜 되네;)

되게 간단한 부분이라 기여라고 하기도 민망하긴 하지만, 내 수정한 코드가 반영된다는게 되게 기분이 좋았던 하루였다.

[기능구현] Method의 실행 시간을 확인해보자

Jong12 — Sat, 27 Jan 2024 17:34:32 +0900

1️⃣ 개요

회사에 입사하고 코드를 분석을 하고 있었는데, 도저히 분석만 하고 있을 수 없고 리팩토링을 진행할 수밖에 없는 환경이었다.

회사 코드를 보여줄수 없으나, 발생하는 문제가 비즈니스 로직이 20N + 1, 15N + 1 을 로직에서 직접 구현을 하고 있었다(아니 JPA를 쓰면서, 왜 이해를 못하고 쓰는데..)

그러다 보니 10개, 20개를 조회하는데도 쿼리가 200번, 400번 , 데이터가 좀 많으면 수만건의 Select절을 실행하고 있었다.

그리 생긴 결과물은, 데이터가 거의 없음에도 API의 요청이 10초~ 15초~ 20초~ 가지각생으로 매우매우 느린상황이었다.

그래서 내가 선언한 어노테이션이 달려있는 메소드들만의 실제 실행 시간을 확인해보고자 기능을 구현하게 되었다...

APM등의 부가적인걸 붙여볼 수 있는 환경이면 좋겠지만 아무런 모니터링툴도 설치하지 못하고 Local을 통해 테스트만 가능한 환경이어서 AOP를 채택하게 되었다.

2️⃣ 환경사항

JDK 17
Spring Boot 3.2.0

3️⃣ 필요 의존성

AOP가 필요하나, Security, JPA등 Spring프로젝트 대부분에 AOP가 존재하여 의존해 사용해도 상관은 없다.
하지만 직접 관리하는게 용이하니, 필자의 경우 AOP를 추가하였다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-aop'
}

4️⃣ 코드 구현

다시보니 매우간단하네...ㅋㅋㅋㅋ

5️⃣ 사용방법 및 결과물

사용방법은 아래의 이미지처럼 실제 실행 시간을 측정하고 싶은 메소드에 위에서 생성했던 어노테이션인 @TimeCheck 어노테이션을 선언하면 된다.

또한 실제 요청을 발송하게 될 경우 아래처럼 실제 호출한 메소드와 실행 시간을 확인해 볼 수 있게 된다.

6️⃣ 글을 마치며

이게 세네번 할 때 까지는 별로 필요성을 못느꼈는데, 로직체크하려고 매번 작성하다보니 너무 불편함을 느껴서 만든 기능인데 너무 편했었다. 기능자체가 간단해서 사실 별다르게 적을건 없는데.. 이걸 만들어서까지 확인해야 할 정도로 느린걸 주구장창 만들었다면... 다시 기본적인 개념을 공부해야 할 사람이지 않을까 싶다...

소스코드 레벨에서부터 자신의 코드가 얼마나 나쁜 습관의 코드인지를 모르는 것이니까... 해당 기능을 계속쓰면서 성능체크를 하면서 다시금 코드를 작성할 때는, 생각을 깊게 하면서 작성해야하는걸 체감했다...

[이슈] 파일 업로드시 OriginalFilename에 대한 고찰

Jong12 — Sat, 27 Jan 2024 17:06:57 +0900

1️⃣ 개요

파일의 명칭에 대해서, 내가 간단하게 개발을 진행할 때 OriginalFileName에 대해서 저장을 하지 않았었다.

많은 웹사이트를 쓰면서 원본 파일명을 다시 돌려받은 경우가 거의 없다 보니, 신경을 쓰지 않았었으나 이와 관련되어 문제가 발생하여서 기록을 남겨보게 되었다.

환경은 JDK 17, Spring 3.2.0을 사용하였다.

2️⃣ 이슈내용

Window나 Mac에서 파일을 업로드를 하게 될 경우 들어오는 Multipart의 경우에는 별다른 문제없이 OriginalFileName이 기록이 되었으나, 이걸 DataBase에서 Query를 통해 OriginalFileName이 들어가있는 Column을 Like문으로 검색을 할 때 검색이 되지 않는 문제가 발생하였으며, 검색이 되지 않는 파일들은 모두 한글이라는게 공통점이었다.

아래의 이미지는 발생 증상이다. 두번째와 세번째는 쿼리가 같아보일 수 있으나, 유니코드의 타입이 다른 쿼리이다.

3️⃣ 이슈 발생 코드

아래와 같이 이루어져 있으며, OriginalFileName을 넣을때 getAttach의 getOriginalFilename()을 사용해서 파일명을 넣는 것을 확인 할 수 있다.

불필요해 보일 수 있는 Annotation은 모두 제거를 하였다.

4️⃣ 발생 원인 및 해결방법

유니코드에는 크게 NFC와 NFD가 존재하며, 운영체제마다 서로 다른 게 원인으로 판단되었으며, 해당 포스트에서 유니코드나 NFC, NFD까지 다루지는 않을 것이기 때문에 더 알아보고 싶은 경우에는 따로 검색하는 것을 권장한다.

NFC : Window와 Linux계열에서 사용
NFD : Mac에서 주로 사용

추가적으로, Mac에서 Window로 파일을 이동하는 등 할때 문자열이 분리가 되는 이유도 이 유니코드가 다르기 때문이었다.

해결방안으로는 OriginalFileName을 NFC로 변환한 이후에 변환된 문자열을 DB에 삽입해 주면 된다.

5️⃣ 해결된 코드

Entity나 DTO, Data등의 클래스는 무의미하기 때문에, ServiceLayer만 업로드를 한다.

OriginalFileName을 업로드 할 때 Normalizer로 감싼뒤, NFC로 변환을 하고 업로드를 하도록 하면된다.

6️⃣ 해결된 결과물

이슈내용과 동일한 쿼리이며, 두번째가 직접 입력한 문구이고 세먼째 쿼리가 NFC로 이뤄진 문자열의 쿼리이다.

Like문이 정상적으로 실행되는 걸 볼 수 있다.

7️⃣ 글을 마치며

원본 파일명을 검색할 수 있는 기능을 만들어 달라는 요청을 받다보니 처음 생각해보게 된 문제였는데, 쿼리가 제대로 실행이 안될때 매우 당황했었다..

그래도 나름 재밌었던 부분이었다. 코드는 아래의 Repository에서 확인이 가능하다.

https://github.com/donsonioc2010/sample-spring-project

GitHub - donsonioc2010/sample-spring-project: 기능구현만 하는 스프링 프로젝트

기능구현만 하는 스프링 프로젝트. Contribute to donsonioc2010/sample-spring-project development by creating an account on GitHub.

github.com

2023년을 돌아보는 리뷰

Jong12 — Mon, 1 Jan 2024 16:10:28 +0900

1️⃣ 개요

2023년을 돌이켜 보자면, "내가 이길이 맞나?"와 "계속 할 수 있을까?", 그리고 무기력이었던것같다.

F-Lab이 끝난 이후, "나 그래도 열심히 했고, 이제 어느정도 잘 할수 있어라는 마인드"를 가지고 내가 주도적으로 해볼 가능성이 있겠다 싶은 회사에 취업을 했다고 생각했었다.

그리고 고생이란 쌩고생은 다했는데 3개월뒤 권고사직을 당했었을때, 내가 세상 보는 안목이 너무 없는거 같은데 계속 하는게 맞나 라는 생각을 좀 많이 했었다. 그리고 같이 찾아왔던게 정말 허탈해서 아무것도 하기 싫은 상태가 되버렸었다.

그냥 아무것도 하기싫었고, 실업급여나 받으면서 뭐하면서 살지 고민을 해보고 싶었던 시간이었다.

그럼 퇴사한 이후의 나에 대한 회고를 시작해보자

2️⃣ 네이버 클라우드 국비교육

쉬고자 했던 장소로 선택을 하게 되었다. 두가지의 이유가 있었는데 아래와 같다.

실업급여를 받을 수 있는 조건은 되었는데, 매번 이력서를 내고, 면접확인서 받아서 제출하기가 귀찮았다. 그래서 국비교육을 들으러 갔다.
네이버 클라우드 비용을 300만원을 준다고해서 300만원으로 그냥 장난감마냥 가지고 놀아보자 생각을 했다.(개발을 계속하려 했다면)

애초부터, 처음 프로그래밍에 입문하는 사람들을 타겟으로 하다보니, 기술적인 발전과 성장 부분으로는 글쎄 잘모르겠다 라고 말할수 있을 것같다. (애초애 혼자 인프런보면서, 책보면서 공부한게 더 도움이 많이 되었다.)

근데 멘토/멘티의 관계마냥 멘토역할을 해야해주는 일이 많았고, 지식을 전파해주면서 내가 역으로 곤란했던, 즉 도움이 되었던 상황을 많이 겪게 되었고, 내가 지식을 전파해주면서 어떻게 해야 멘티에게 지식을 조금이라도 더 많이 깊이있게 알려줄 수 있을까를 생각하면서 말하게 되다 보니 기술적으로 말하는 방법들도 많이 겪어 볼 수 있었다.

또 개발자로서 내가 많이 부족하다고 항상 생각했는데, 오히려 내가 현재 연차에 비해서 너무 방대한 지식을 알고 있고 많은 걸 알려 줄 수 있는 사람이었다는걸 알게 되었던 시간이었다.

알고리즘 스터디

심심해서 해보게된 스터디였다, 매주 입문하기 쉬운 난이도에서부터 알고리즘을 풀고 설명을 해봤었는데, 다양한 생각을 들어볼 수 있던 시간이었다고 말할 수 있다! (역시 수학과...)

아 근데 사진 너무귀엽다

프로젝트를 하면서

프로젝트를 할때는 일부로 PM을 자처했다. 팀원과 나의 기술 격차가 크다는걸 알고 있었기 때문에, 빠른시간안에 쳐내면서 진행을 해야했기 때문이다.

그러면서도, 프로젝트 팀원들이 내가 하고싶었던 인원들과 하는 부분이다보니 챙겨주고 싶은 마음이 많았는데 그러다 보니 잔소리가 많아질 수밖에 없었다.

사용한 기술에대해서, 구현한 기능에 대해서 공유를 하거나, 피드백을 하던가 기능구현을 같이 얘기하면서 도움을 주고 받는 과정을 많이 시켜보려고 노력했다.

또한 나역시 프로젝트를 하면서 들게되었던 생각은.. 기능구현을 하던가 개발을 하는 과정자체가 아직도 너무 재밌게 느껴졌고, 타인과 같이 경험을 해나가는 그 과정 하나하나가 재밌다 보니 계속 도전해야 겠다는 생각을 굳힐 수 있던 시간이었다.

3️⃣ 공식으로 소개된 내 블로그

제목을 어떻게 지을지 잘 모르겠어서 그냥 이렇게 지었다. 프로젝트를 진행하면서 내가 기능구현한 내용들, 생각들을 블로그에 포스팅을 해놨었다.

그리고 그 글들은 네이버 클라우드를 기반으로 사용했던 경험들을 적어놨다보니 네이버 클라우드에서 게시물을 확인하게 되었던 것 같다.

그렇게 네이버 클라우드 기술을 활용해 게시물작성한 11월 글들중 베스트로 뽑혀서 네이버 클라우드 블로그에 공식으로 소개가 되었다.

최근에 지속적으로 글을 작성하려고 하다 보니 느낀게 한개 있었는데, "아 내가봐도 옛날에 비해서 매우 확연하게 글을 잘 쓰게 되었네" 였다. 글을 쓰면서 최대한 읽기 쉽게 해보려고 노력하자가 당첨된 큰 이유지 않을 까 싶다.

PS. 정말 기분 좋았습니다. 감사합니다 NCP

제목을 어떻게 지을지 잘 모르겠어서 그냥 이렇게 지었다. 프로젝트를 진행하면서 내가 기능구현한 내용들, 생각들을 블로그에 포스팅을 해놨었다.

그리고 그 글들은 네이버 클라우드를 기반으로 사용했던 경험들을 적어놨다보니 네이버 클라우드에서 게시물을 확인하게 되었던 것 같다.

그렇게 네이버 클라우드 기술을 활용해 게시물작성한 11월 글들중 베스트로 뽑혀서 네이버 클라우드 블로그에 공식으로 소개가 되었다.

PS. 정말 기분 좋았습니다. 감사합니다 NCP

4️⃣ 다시 도전한 취업시장

거의 반년만에 이력서를 다듬고.. 회사에 지원하고 면접을 보러 다녔다. 시장이 안좋은 것은 알고 있었지만, 이렇게 연락이 안올줄은 생각도 못했다.

원티드에서 가고 싶은 회사를 리스트업하고 이력서를 넣어봤는데, 단 한곳도 연락이 오지를 않았다.

난 이제 놀고 있을 수 없는 상황인데....

어쩔 수 없이 좀 많이 범위를 넓혔다. 기술과 개발 중심, 유지보수는 약간 후자로 미뤄지는 장소들을 찾고자 했다.

이력서를 다듬으면서 항상 들었던 생각이 실제 회사에서 "개발 포지션"으로의 경력이 아얘 없는게 내 심각한 단점이라고 생각했기 때문이다.

채용과 관련된 사이트면 모두 사용을 했고, 일치해 보이는 조건의 채용공고는 다 지원해 봤다.

범위를 매우 넓히니 연락이 오기 시작했고, 면접을 보러 다니면서 아 내가 확실히 개발부터 오픈까지 해본 부분이 없다 보니, 관련된 부분으로 실제 경험의 면접답변을 할 수가 없구나를 더 절실히 느꼈던 것 같다.

회사를 구할때 전략중 하나로, 대부분의 채용 사이트가 추천순으로 되어 있어서 인기 있는 글들만 보이게 되어있는데, 마감일 순 등으로 소팅을 바꿔보면서 대부분의 모집공고를 다 보는 방식으로 바꿨고, 그렇게 지원자가 별로 없는 회사들도 많이 지원을 해보게 되면서 취업을 할 수 있었다.

비록 남들 눈에 봤을 때, 큰 서비스기업이라든가, 트래픽이라든가 그런 부분들은 없지만 일단 내가 "개발 포지션"으로 확실하게 갈 수 있고, "팀으로 개발"하는 요소만 봤기 때문에 크게 불만은 없다.

또 면접을 보러 다니면서, 내가 부족한게 느껴졌다보니 이전 회사보다 처우에서 깎아서 다니고 있었는데, 그냥 이전회사처럼 대우해 주겠다고 하는 모습을 보면서 사람을 많이 챙겨준다는 느낌을 강하게 받기도 했다.

5️⃣ 올해의 실패들

크게 두가지가 있는것 같다.

첫번째는 네이버 클라우드 300만원 바우처를 받으면서 k8s를 바탕으로 한 어플리케이션 생태계를 구축하고 싶었다. 하지만 내 의지박약으로 실천까지 가지는 못했던게 일단 가장 큰 아쉬움 같다. 남들은 아까워서 못쓰는 서비스를 난 원없이 쓸 수 있는 절호의 기회였는데 말이다.

두번째는 채용과 관련된 부분 같다. 내가 너무 옛날을 생각하고 쉽게 봤던 것 같다. 채용시장이 안좋다 보니, 실제로 절대적인 지원자 수가 많을 수밖에 없었다. 몇년째 이어져온 국비학원들의 대규모 광고와 모집, IT서비스업들의 구조조정등으로 나보다도 뛰어난 개발자들도 많이 풀려있는 시장인데 얕잡아봐서 크게 실패한 것이지 않나 싶다.

6️⃣ 2024의 다짐

항상 내가 생각하는 꿈중 하나인, "타인이 일을 맡길 때, 내 이름을 들으면 최소한 나한테는 믿고 맡길 수 있다."라는 말또는 생각을 가지게 되는 순간이 올때까지 노력을해야하니... 목표를 잡아보고자 한다.

일단 다시 회사에 들어가게 된지 얼마 되지를 않다 보니.. 적응하는게 우선이지 않을까 싶다. (출퇴근이 왕복 세시간이 넘는다) 그러면서 회사원으로써 성과를 내고 회사의 구성원들과 화합을 이뤄보는 것을 일순위로 잡아볼 예정이다.

다음으로 블로그글을 꾸준히 쓰는걸 두번째 목표로 하고싶다.

이 의미는 나는 지속적으로 학습을 게을리 하지 않아야 하며, 회사를 다니면서도 꾸준히 토이프로젝트를 진행해야 한다.

내가 잡은 마음가짐은 실제 내가 개발한 기능, 기술, 그리고 작업을 하면서 했던 생각만 기록하기로 마음을 잡았다.

그 요소들을 회사에서 개발한걸 올릴 수는 없기 떄문에, 토이프로젝트에서 진행한 걸 올릴 수밖에 없다.

그러면서 써보고 싶은 기술들은 아쉬웠던 부분인 k8s와 Spring Cloud를 접목해서 MSA환경으로 구축을 해보고 싶고, 이걸 코틀린으로 진행하고 싶은게 내 토이프로젝트의 우선순위로 잡아 볼 예정이다.

또한 이론으로만 생각하고 있는 OOP의 장점들을 내가 작성하는 기능, 코드들에 계속 생각하면서 녹이면서 몸에 체득하는걸 목표로 잡고싶다.

[OrientalUnity] HookKiller팀의 OrientalUnity프로젝트 회고

Jong12 — Tue, 21 Nov 2023 17:25:35 +0900

1️⃣ 프로젝트 소개

프로젝트의 시작을 알리는 아티클에서 적었지만 또 적어보면...

번역을 기반으로 피해자와 가해자들의 모임인 한.중.일이라는 언어도 틀리고, 역사가 꼬여있는 세개의 국가를 주제로 동북아 커뮤니티이다

깃허브 코드

아래 이미지처럼 글을 남길 경우 한국어, 영어, 일본어, 중국어 총 4개국어로 글들이 자동번역되어 타 국가의 사용자와 교류할 수 있는 커뮤니티다.

2️⃣ 구현에 사용된 기술스택

Front의 경우에는 React를 채택하였고, 메인으로 집을만한 라이브러리는 다국어의 페이지를 만들기 위한 i18next과 게시물의 내용을 HTML로 받기 위한 React Quill을 짚어볼 수 있을 것 같다.

Back의 경우에는 Java + Spring을 기본으로 채택하였고, 추가적으로 짚어볼 만한 라이브러리는 Security와 JPA를 사용한 정도로 보인다.

사용한 외부 API의 경우에도 매우 핵심이라 짚을 만한건 Naver Cloud Platform의 Papago Translation이라 할 수 있다.

3️⃣ KPT방식의 회고?

어떻게 이글을 작성해야 좋을까 계속 생각하면서 보게된게 KPT회고란걸 알게 되었다.

Keep, Problem, Try의 약자로 Keep은 만족을 했고, 계속해서 이어나가고자 하는 요소, Problem은 내가 불편하게 느꼈고 개선이 필요하다 생각되는 부분, Try는 Problem에 대한 해결책과 당장 실행가능한, 다음회고때 판별이 가능한 요소를 정의한다고 한다.

근데 나는 KP만 할 수밖에 없는 환경같은데..?

쩃든 KP에 대해 적어보도록 하며, Problem에서 기술적인 이슈 문제는 블로그에 포스팅한 내용에 대해서는 적지 않으려 한다..(이미 블로그에 그와 관련된 내용을 다 포스팅 한 것이기 때문)

1. Keep

리뷰를 하면서 팀원들한테 지속적으로 "왜 그렇게했어?"를 물고 늘어졌었다. 팀원들의 성장이 눈에 띄게 빠르게 올라가는걸 보면서 정말 기뻤다. (다라고 말할 수는 없겠지만...)
최대한 매일 일일스크럼을 하려고 했다, 그러면서 팀원들한테 자신이 배운 것, 익힌것을 스크럼시간에 다른 팀원한테 전파하도록 시키고자 하였고 그 시간이 매우 소중했다.
Reference가 없는 서비스를 내가 직접 사용해 보면서 Reference를 만들어 버린 것. (NCP의 ELSA사용방법)
Docker를 바탕으로 실행하는 Spring Boot Application에 PinPoint Agent를 실행하는 방법을 알게 된 것
서버의 모든 인프라 환경을 Private로 구축에 성공한것

2. Problem

k8s환경을 구축해보지 못했던 것
부하테스트를 진행해보지 못한 것
Front와 React의 지식이 BackEnd에 비하여 많이 부족했던 부분
BackEnd에서의 아쉬웠던점 (일부로 하지 않은 부분이며, 팀원이 못따라 올 것이라 판단하여 하지 않음)
- TestCase의 작성을 하지 못한 것
- QueryDSL을 사용해보지 못한 것
- Swagger나 Spring Rest Docs를 사용하지 못한 것
- BackEnd도 다국어 처리를 해야했는데 하지 못한 것
- RestAPI에서 Entity를 반환하는 기능들이 많다는 것?
FrontEnd에서의 아쉬웠던점
- 상태관리 Redux와 Redux Saga의 개념이 너무 부족했던 것
- 한개의 컴포넌트에 어쩔 수 없이 모든 기능을 다 떄려박을 수 밖에 없던 것
Jenkins에서 Pipeline을 통한 배포를 하지 못한 것

이정도 인것 같다..

4️⃣ 프로젝트를 하면서 느낀 점?

사실 매번 PM을 어쩔 수 없이 맡게 될 때마다 불편했다. 나도 그냥 팀원으로써 기능구현을 하고 PM마음고생시키면서 같이 작업하는게 더 재밌는데 말이다.

어쨋든 토이프로젝트를 할 때면 같이 하게 되는 사람들이 다들 PM이 되는 것도 기피하고 실제 자신의 문제를 털어놓거나 자신의 의견을 강하게 밀어주는 사람들이 없었고, 그냥 어떻게든 될대로 되겠지 하면서 의욕없어하는 팀원들을 보면서 늘 재미가 없었고 불편했다. (내가 팀운이 없는건지, 팀원들한테 의욕이 없어지도록 만드는건지 모르겠는데 매번 이러니까 후자같아보이기도 하다.. )

그래서 실력과 상관없이 마음맞는 사람끼리 하고자 싶어 했고, 심지어 잘 안되더라도 다들 끝까지 노력하는 모습을 보면서 처음으로 타인과 같이 하는 프로젝트가 재밌었었다.

또한, 내가 재직할때 당시 팀장이 날 보던 모습이 이러지 않았을까 했던 생각도 많이 들었었고, 아 시니어의 고충이 이런거구나를 얄팍하게나마 느낄 수 있던 시간이었다.

팀원의 전체 코드리뷰를 해주고, 코멘트를 달아주면서, 기능에 대해서 생각하고, 기능구현 못한걸 119마냥 가서 구급대처럼 구현해주고, 팀원들한테 내 말에 대한 신뢰를 주고자 했던 행동들을 생각해보면 정말... 많은걸 경험해 볼 수 있고 느꼈던 프로젝트다.

그리고 마지막으로 내 탱킹과 말빨이 그래도 나쁘지 않다는걸 많이 체감했었다.

5️⃣ 아쉬웠던 점?

되돌아 보면, 치열하게 싸우면서 논쟁을 했던 시간이 거의 없었다. 이게 좀 아쉬웠던 점이지 않을까 싶다.

매번 이슈가 발생하면 CS적으로, 코드적으로 문제를 추적하면서 이슈를 바로바로 해결했었다 보니 논쟁을 펼칠 일이 안생겨 버린게 아쉬웠지 않았나 생각이 든다.

또한, 프로젝트의 기간이 짧았던 것도 너무 아쉬운 요소라고 생각했다.

실제 구현해보고 싶은 것은 너무 많았는데 기능구현이 2주였나밖에 되지를 않았다. 이게 가장 아쉬웠던 요소라 생각이 지금은 든다.

6️⃣ 추가적인 리팩토링이 필요한 것?

FrontEnd의 코드를 전체적으로 기능단위를 잘게 잘라서 제작하는것과, KP의 Problem에 적은 BackEnd의 코드적인 부분을 좀 건드려보면 좋지 않을까 싶다~

7️⃣ 참고한 Reference

KPT회고에 대하여
- https://brunch.co.kr/@jinha0802/35

[OrientalUnity][React] i18next를 활용한 다국어 처리

Jong12 — Tue, 21 Nov 2023 15:57:31 +0900

1️⃣ 글을 작성하기에 앞서...

필자의 경우 BackEnd를 위주로 공부하다 보니 Spring, Java 코드들에 비해서는 깔끔하면서 능숙한 코드가 안나올 수도 있다.

그 점은 양해하며, 어떻게 작업을 했는지를 중점으로 봐주면 좋을 듯 하다..

2️⃣ 다국어 처리를 하게 된 이유 그리고 i18next

해당 프로젝트는 게시물을 작성 할 때 4개국어로 번역한 이후 저장이 되는 타 국가와 소통이 가능한 프로젝트이다.

정작 게시물은 4개국어로 저장이 되는데 반해, 페이지는 한국어로 계속해서 표현이 되면 부자연스럽다 생각하게 되었다.

이후 생각이 들었던 프로젝트의 방향은 다양한 사이트에서 봤던 기능인, 국가 변경을 했을 때 해당 국가의 언어에 맞게 페이지, 데이터가 변경이 되어야 겠다는 생각을 하게 되었고 다국어 처리를 할 수 있는 방법이 무엇이 있는지를 확인하다 i18next를 사용할 수 있다는 것을 알아 선택하게 되었다.

3️⃣ i18next란? 설치방법은?

공식페이지를 보면 JavaScript를 기반으로 한 국제화 프레임워크로, 다국어 처리를 할 수 있는 프레임워크다.

사용할 수 있는 도구를 다 기록해 놓은 것 같다.. (이미지에는 없지만 스프링도 사용은 가능하다는걸 처음알았다.)

설치의 경우에는 FrontEnd 프로젝트에서 다음의 Json적용을 하면 된다.

필자의 경우에는 두개 전부 적용을 했다.

4️⃣ i18next 설정

필자가 프로젝트에 적용한 설정은 다음과 같다.

4개국어의 정보를 resources로 담고, 이후 i18n객체에 지정을 하였다.

또한 localStoreage에 기존에 선택한 값이 없는 경우 한국어가 기본적으로 설정하게 하였다.

resources의 언어값은 개발하는 본인이 직접 지정을 해도 상관없다.

실제 src하위의 디렉토리 구조가 locales아래에 번역된 정보들이 존재한다.

번역정보를 담는 일부인 중국어와 한국어에 대한 번역 메세지 정보를 담는 파일역시 전부 json으로 구성하였다.

5️⃣ 각 컴포넌트에서 해야하는 작업

다국어 메세지를 가져와야 하는 컴포넌트에서는 아래와 같이 useTranslation()을 통하여 i18next의 hook을 가져와야한다.

이후 메세지가 필요한곳에 useTranslation의 첫번째 변수를 사용해 메세지를 가져 올 수 있게 된다.

이후 필자의 경우에는 i18n을 effect를 통해 감지를 하였는데, 선택한 국가의 변경이 일어날 때 페이지의 모든 언어를 선택한 국가의 언어로 변경하고자 하여 감지를 진행하였다.

6️⃣ 헤더에서의 언어 선택과 데이터 변경

완성된 기능은 아래의 이미지처럼 Header에서 언어를 선택할 경우 언어가 변경되도록 진행하였다.

데이터가 변경되는 기능은 각페이지마다 useEffect를 통해 변경감지로 데이터가 변경되게 하였다.

해당 챕터에서는 Header의 코드를 나열해보고자 한다.

우선 Header에서는 Language를 선택할 수 있는 컴포넌트를 호출합니다. (원본 소스에서는 다양한 props가 있지만 가독성을 위해 전부 제거하였습니다.)

이후 셀렉트가 가능한 드롭박스의 코드는 아래와 같이 작성을 하였습니다.Option의 Value를 i18n.js의 resources에 선언했던 Key값으로 지정을 하였으며, onChange이벤트가 발생할 경우에는 i18n.changeLanguage의 설정 언어를 변경해 주었습니다.

i18n의 useTranslation자체가 Hook으로 작동이 되는 원리이다 보니, 각기 다른 컴포넌트에서 사용이 가능했으며 한곳에서 변경을 시켜도 다른곳에서 감지를 하고 그에 맞는 언어로 변경이 되는 원리여서 다음과 같이 onChange이벤트에서 언어변경만으로 구현이 가능하였습니다.

7️⃣ 글을 마치며...

Front.. 특히 SPA에 대해서는 매우 해박한 지식까지 가지고 있는 부분이 아니다 보니, 실제 구현을 하면서 작동원리를 깊게 이해를 하지 못하는걸 느낄 수 있었던 부분이었습니다.

그러다 보니 정말 참고한 Reference도 많았던 것 같습니다.

그래도 기능의 구현과 구현된 기능을 가져다 쓰는 부분이다 보니 금방감은 잡고 사용이 가능했어서 큰 문제는 없었고.. 단지 메세지를 전부 미리 채워놔줘야 한다는 불편함을 크게 느낄 수 있었습니다.

막상 완성되고 보니 언어감지를 해가지고 페이지가 자동으로 변경되는것을 봤을떄는 아 이래서 프론트 하는 구나 하는 생각도 들었던 작업이었습니다.

8️⃣ 참고한 Reference

[OrientalUnity][React, Spring] React Quill의 바이트 코드이미지 삽입이슈와 해결법

Jong12 — Mon, 20 Nov 2023 17:19:06 +0900

1️⃣ 글 작성에 앞서...

해당 이슈는 우리 팀이 구현한 사용한 도구에 대한 이해가 필요하다.

일단 FrontEnd의 경우 React를 기반으로 작성을 진행하였으며, 이슈가 발생한 장소는 게시물을 등록하는 곳에서 발생이 되었다.

게시물을 등록시 필자의 팀의 경우에는 에디터를 사용하여 게시물을 등록할 수 있도록 기능 구현을 하였으며, 오픈소스중 하나인 React Quill을 활용하였다.

Quill자체에는 이미지를 업로드하는 기능이 존재하였으나, 이미지를 업로드할때 발생이 되는 이슈사항에 대하여 기록을 해보고자 한다.

2️⃣ ReactQuill와 Quill을 선정한 이유?

1. ReactQuill이란?

공식페이지에서 소개되어있는 내용으로, 긴 텍스트를 작성할 수 있는 에디터라고 설명이 되어있다.

에디터를 작성하게 되면 TextArea와는 다르게 HTML마크업을 그대로 전달받을 수 있게 된다.

https://quilljs.com/

Quill - Your powerful rich text editor

Sailec Light Sofia Pro Slabo 27px Roboto Slab Inconsolata Ubuntu Mono Quill Rich Text Editor Quill is a free, open source WYSIWYG editor built for the modern web. With its modular architecture and expressive API, it is completely customizable to fit any ne

quilljs.com

2. 필자가 생각하는 에디터를 사용해야 하는 이유

에디터를 써야하는 이유는 필자가 생각함에 있어서는 일단 정보를 전달하는 글을 작성함에 있어 강조의 표현을 다르게 꾸며논다든가 등 글의 가독성을 높일 수 있기 위해서는 HTML언어를 적용 시킬 수 있어야 하는데, TextArea로는 작성자가 의도대로 작성하는지의 확인이 힘들다는 단점이 가장 큰 문제이지 않나 싶다.

그 외에도 호환문제라든가 여러가지 사유가 존재하고, 각자가 다 다를 수 있으니 해당사항은 직접 생각해보면 좋을 듯 하다.

3. 왜 Quill이었는가?

딱히 큰 이유는 없었다. 오픈소스에 무료사용이 가능한점, Editor를 검색시 가장 먼저 나온점등이 이유였다.

그저, 이미지를 넣을 수 있고, HTML로 Content를 받아올 수만 있었다면 자료가 많은것중 아무거나 가져와서 사용했을 것이다.

Quill이 먼저 많이 나온 자료였고, 아래의 이미지 처럼 구현이 바로바로 가능했기때문에 빠르게 채택하였다.

그냥 에디터를 왜 써? 라고 묻는다면..한번 생각해보자.

우리가 블로그에서 글을 작성하건, 커뮤니티 싸이트에서 글을 작성하건.. 사진을 못올리고, 게시물의 내용을 볼드나 이태릭처리를 못하는 그런 커뮤니티나 블로그를 본적이 있는가?

이게 내가 생각했을때 커뮤니티 프로젝트를 하게 된 순간부터 에디터를 고려 할 수밖에 없단 사항이다.

3️⃣ 이슈내용

이미지를 업로드할 떄 문제가 된다고 처음에 말을 하였다.

이미지는 굉장히 긴 바이트코드로 이루어져있다. FrontEnd Application레벨에서는 이미지를 어떻게 처리하는지를 나도 몰랐다.

ReactQuill에서는 그 긴 바이트코드를 HTML태그로 img태그에 집어넣고 있었다.

오른쪽의 코드가 IMG태그의 src속성에 직접 바이트코드로 넣고 있는것을 볼 수 있으며, 저 문자열을 그대로 Spring에서 받게 된다는 것이다. 그렇게 넘어오는 것 자체를 필자는 이슈라고 정의하였다.

4️⃣ 해결 방안?

해결의 최종점은 바이트코드를 대신해서 서버에 업로드된 이미지의 Path를 기록하게 하는 것이었다.

그를 위해 어떻게 작업을 해야할까? 고민을 했고, Image를 업로드할 때 사용되는 Handler를 제작해서 적용하기로 마음먹었다.

로직을 이해하기 쉽게 이미지로만 끝내면 다음과 같이 표현이 가능해진다.

1. 기존에 React Quill을 사용시의 로직

2. Server의 Path를 가져오는 로직

5️⃣ BackEnd (Spring)의 작업내역

1. Controller

이미지를 업로드할 API를 제작한다.

해당 요청은 MultiPart를 받아야 하기때문에 POST메소드를 사용해야 한다.

2. DTO

Request를 담당할 DTO와 Response를 담당할 DTO를 생성한다.

필자의 경우 사용처를 Path에 집어넣고 있어서, 어느 기능에서 올린것인지 구분하기 위한 Enum이 존재한다.

3. Service

Service에서는 우선적으로 로그인한 사용자인지를 구분하며, 이후 테이블에 요청한 사용자의 정보를 바탕으로 올린 파일정보를 기록해두며, Response객체로 감싸서 Return을 한다.

4. FileUpload Util

해당 코드에서 실질적인 파일 업로드가 이뤄진다. 정말로 파일 업로드와 변경된 파일 명을 반환만한다.

여기서 기억할 사항은 필자의 경우 spring.profiles.active의 Value에 따라 /dev~ 로 시작할지, /local~ 로 시작할 지를 구분하였다.

또한 파일의 경우 실행위치 + 사용처 + 시간 + 파일명으로 저장이 되게 된다

5. Amazon S3 Bean

해당 코드에서는 FileUpload를 진행하는 Util에서 사용하는 S3의 Bean을 설정하는 코드만 존재한다.

StorageProperties까지는 나열하지 않을 예정이므로, Git Repository를 참고해주기 바란다.

6️⃣ FrontEnd (React)에서의 작업사항

FrontEnd에서는 굉장히 간단한 작업이 된다.

useMemo를 통해 사용할 Module을 선정한다. 이후 handlers에서 Image를 업로드하는 태그인 image의 함수를 제작해주면 작업이 완료된다.

FormData로 Dto형식에 맞게 생성한 이후 받아온 Path를 InsertEmbed메소드를 통해 기록하면 된다.

또한 useMemo를 통해 생성한 module를 ReactQuill에서는 당연히 참조를 해야한다.

7️⃣ 결과물

왼쪽의 이미지가 참조가 되지 않는 이유는 현재는 해당 Object Storage를 없앴기 떄문에 실제 업로드 기능을 BE에서 비활성화 해놓은 상황이다.

실제 해당 경로에 올라가지 않았기 때문에 이미지를 못 불러 오는건 어쩔 수 없으며, 오른쪽의 경로를 자세히 봐주면 좋을 듯 하다.

local~로 시작하면서 업로드한 Path 정보의 확인이 가능하다.

위의 경우에는 작업이 완료된 이후의 src 속성의 값이며, 아래는 작업 전의 src 속성값이다.

어떤것이 좋을 지는 게시물을 읽고있는 독자가 판단하면 좋을 듯 하다.

8️⃣ 왜 이런 작업을 생각하게 되었나?

필자의 프로젝트 컨셉에 들어가는 기능은 게시물의 자동번역이다.

그러다 보니 저 바이트코드가 전부 번역기능(Papago)에 요청을 보낼 경우 문자열 한개로 인식을 하고 있었다.

바이트코드의 길이가 수백자 수천자가 될 수 있는 상황인데, 이걸 전부 요청을 보내면 천문학적인 비용이 청부 될 수도 있겠다 생각하였다.

또한 필자가 하던 생각이 맞다 보니 더 심각하게 해당 이슈를 바라 볼 수밖에 없었다.

9️⃣ 글을 마치며

파일 업로드를 Spring으로 제작한 선례의 자료가 찾기 힘들었다. (그냥 없었다 수준인듯..?)

Image Handler를 컨트롤하는 방법만 알면 어렵진 않겠다 생각이 들었고, Next등으로 만든걸 올려준 사람이 많다보니 쉽게 할 수 있었다.

항상 하는 생각이지만, 제작하면서 더 깊이 들은 생각은 "언어는 그냥 도구일 뿐이고, 어떤 언어든 실행로직을 이해하면 다른 언어로도 어느 정도는 구현할 줄 알아야 한다" 였다. (진짜로 불가능하거나 너무 효율이 안좋은 경우도 있겠지만 말이다.)

실제 Reference에 기록을 해뒀지만, Quill의 ImageHandler를 어떻게 컨트롤 할 수 있는지 참조만하고 작업을 하였으니 말이다.

※ 진짜 작성하기 가장 무서웠던 글의 작성을 드디어 끝냈다... 내용이 많아서 언제하지 하면서 겁을 내고있었다.

참고한 Reference

Quill의 Image Handler의 사용법 참고
- https://12ahn22.tistory.com/entry/Quill-%EC%97%90%EB%94%94%ED%84%B0-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

Quill 에디터 - 이미지 처리하기

깃허브에 작성한 ReadMe를 블로그로 옮겨왔다.(형식은 조금 수정..) 요새 너무 바빠서 글을 못올려서..^^ 팀 프로젝트에서 Quill 에디터를 사용했는 데, 이미지 업로드에 고생을 좀 해서 정리해봤다.

12ahn22.tistory.com