이전에 중고 거래 플랫폼 프로젝트를 하면서 동기로 처리하고 있던 이미지 업로드 속도를 개선하기 위해 비동기로 개선했던 적이 있는데, 취준하느라 미루었던 기록을 이제 작성하고자 한다.

📸 비동기로 이미지 업로드 속도 개선

문제점

해당 프로젝트는 당근 마켓과 같이 중고 거래 상품을 등록할 때 이미지를 등록할 수 있고, 이미지는 S3에 업로드되어 저장하고 있었다.

그런데 다음 코드 처럼 이미지 업로드 시 순차적으로 S3에 저장하고 있기 때문에 여러 개의 이미지를 업로드하는 경우, 속도가 매우 느렸다.

ImageService.java

포스트맨으로 여러 번 확인했을 때 응답을 받기까지 평균 5~6초의 시간이 소요되었다. 테스트한 이미지는 3MB 크기의 10개 이미지였다.

이미지 업로드를 순차적으로 할 필요는 없다고 생각했기 때문에 속도를 개선하기 위해 생각이 났던 방법은 비동기 처리였다.

@Async 적용

비동기 처리를 처음해보기 때문에 @Async 어노테이션을 공부하고 적용해보았다. Spring에서는 @Async 어노테이션으로 비동기 처리를 지원한다.

@Async를 적용하기 위해서 다음과 같은 순서로 진행했다.

1. 비동기 처리에 필요한 스레드 풀을 만들기 위한 Config 파일 작성
2. 메서드에 @Async 적용

1. 비동기 처리에 필요한 스레드 풀을 만들기 위한 Config 파일 작성

• @Async를 적용하기 위해서는 @EnableAsync를 Config 클래스 혹은 프로그램 Main 메서드에 붙여줘야 한다.
• 어디에 붙이든 똑같이 동작하지만, 개인적으로 Main 메서드에 어노테이션이 덕지덕지 붙는게 싫어서 Config에 붙여주었다.

@EnableAsync // 필수!
@Configuration
public class AsyncConfig {

    @Bean(name = "imageUploadExecutor")
    public Executor imageUploadExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();

        executor.setThreadGroupName("imageUploadExecutor");
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(20);
        executor.setQueueCapacity(50);
        executor.initialize();

        return executor;
    }
}

💡참고:

• setCorePoolSize(): 동시에 실행시킬 쓰레드의 개수를 설정
• setMaxPoolSize(): 스레드 풀의 최대 사이즈 설정
• setQueueCapacity(): 스레드 풀 큐의 사이즈 설정
  • corePoolSize 개수를 넘어서는 task가 들어왔을 때 queue에 해당 task가 쌓인다.

해당 프로젝트에서는 이미지를 최대 10개까지 업로드할 수 있기 때문에 corePoolSize를 10으로 설정했는데, maxPoolSize랑 queueCapacity는 어떻게 설정하는게 좋을지 모르겠어서 우선 예제 따라서 설정해주었다.

2. 메서드에 @Async 적용

그리고 이미지 업로드하는 메서드에 @Async 어노테이션을 적용했다

ImageUploader.java

    @Async("imageUploadExecutor")
    public URL uploadImage(MultipartFile multipartFile) {
        long startTime = System.currentTimeMillis();

        String uuid = UUID.randomUUID().toString();

        ObjectMetadata metadata = new ObjectMetadata();
        metadata.setContentLength(multipartFile.getSize());
        metadata.setContentType(multipartFile.getContentType());

        try {
            amazonS3.putObject(bucket, uuid, multipartFile.getInputStream(), metadata);
        } catch (IOException e) {
            throw new RuntimeException();
        }

        long endTime = System.currentTimeMillis();
        log.info("{} - 실행 시간: {}", Thread.currentThread().getName(), endTime - startTime);

        return amazonS3.getUrl(bucket, uuid);
    }

과연.. 속도가 얼마나 개선되었을까 두근거리며 포스트맨으로 요청을 날렸다.

3-1. Invalid return type for async method 에러 발생

(짠! 어림도 없지 ㅋㅋ)

에러 메시지 보니까 return 타입이 잘못된 것 같은데, 찾아보니까 @Async는 return value가 void인 경우만 적용 가능하다.

그런데 우리 프로젝트는 이미지를 업로드하고 URL을 프론트에게 응답해줘야 했기 때문에 void면 안된다.

그렇담 어떻게 해야할까? return value가 필요하다면 CompletableFuture를 사용해야 한다.

3-2. 메서드에 CompletableFuture 적용

ImageUploader.java

    @Async("imageUploadExecutor")
    public CompletableFuture<URL> uploadImage(MultipartFile multipartFile) {
        CompletableFuture<URL> future = new CompletableFuture<>();

        // 이미지 업로드 로직 생략...

        future.complete(amazonS3.getUrl(bucket, uuid));

        return future;
    }

ImageService.java

    private List<URL> uploadImages(List<MultipartFile> files) {
        List<CompletableFuture<URL>> futures = new ArrayList<>();

        for (MultipartFile file : files) {
            futures.add(imageUploader.uploadImage(file));
        }

        List<URL> urls = new ArrayList<>();
        futures.forEach(future ->
                urls.add(future.join())
        );

        return urls;
    }

⚠️ 주의: @Async는 AOP 기반으로 작동되기 때문에 다음과 같은 경우 비동기 처리가 되지 않는다.

1. 프록시를 생성해야 하기 때문에 private 메서드에서는 작동하지 않는다.
2. 마찬가지 이유로 동일 클래스에서 내부 호출하는 메서드에서는 작동하지 않는다.
3. Bean으로 관리되지 않고 있는 경우

다행(?)히 프로젝트 구조상 ImageService랑 ImageUpload가 분리되어 있었서 정상적으로 적용되었지만 꼭 주의해서 사용하자!

이젠 되겠지...?

결과!!

포스트맨

우와... 속도가 진짜 빨라졌다. 평균 5.5초 걸리던 업로드 속도가 평균 0.75초로 개선되었다.

동기 비동기 처리 속도가 이렇게 차이날 줄 몰랐다..

스레드 로그

실제로 비동기로 처리되고 있는지 로그도 확인해보았는데 멀티 스레드로 잘 동작하고 있었다. 🙂

🔗 참고

• https://velog.io/@cotchan/AsyncConfigurer%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-return-value%EC%9E%88%EB%8A%94-Async-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0
• https://mangkyu.tistory.com/263

상황

Github Actions으로 배포할 때 scp-action을 통해 EC2로 파일을 전달하는 과정에서 에러가 발생했다.

이전까지 배포가 잘 되었고 에러 메시지만 보고서는 무슨 상황인지 파악이 어려워서 우선 에러 메시지로 구글링을 해보았다.

에러 메시지

error copy file to dest: ***, error message: Process exited with status 1

drone-scp error: error copy file to dest: ***, error message: Process exited with status 1

원인

결론적으로 말하면 EC2에 디스크 용량이 꽉차서 파일 전달이 불가능한 것이었다.

Github Issue 내용을 보다보니 저장공간 얘기가 있어서 "혹시...?" 나 했는데 공간이 100프로 차있었다.

EC2 디스크 용량... 🤣

💡 참고:

• EC2 디스크 용량 확인하는 명령어:

  df -h

• df는 disk free의 약자이고 h는 human의 약자다.
• 즉 디스크 용량을 사람이 보기 좋게 표기해준다.
• -h 옵션을 사용하지 않으면 M(메가), G(기가)등의 단위 표시가 되지 않는다.

해결

우선 디스크 확보를 하기 위한 방법을 찾아보았다.

디스크 용량 확보 방법

1. 필요하지 않은 패키지 삭제

sudo apt autoremove --purge

이 명령어는 시스템에서 더 이상 필요하지 않은 패키지들을 자동으로 제거하고, 그 패키지들과 관련된 설정 파일들도 함께 제거한다.

2. 캐시 정리

sudo apt-get autoclean

이 명령어는 시스템에서 다운로드한 패키지 파일 중에서 사용되지 않는 오래된 버전의 파일을 정리한다.

Write error - write (28: No space left on device) 에러 발생

하지만 나 같은 경우, 2번 방법으로는 디스크 용량을 충분히 확보하지 못했고 1번 방법은 에러가 발생했다. 디스크 용량이 부족해서 명령어 실행조차 불가능했던 것이다.

에러 메시지

E: Write error - write (28: No space left on device)
E: IO Error saving source cache
E: The package lists or status file could not be parsed or opened.

그래서 우선 /var 디렉토리에서 사용하지 않는데 용량을 크게 차지하는 파일을 삭제 후 명령어를 실행해서 문제를 해결했다.

💡 참고:

• 현재 디렉토리의 각 항목에 대한 디스크 사용량을 요약하여 표시하는 명령어

  sudo du -sh *

  

🔗 Reference

• https://m.blog.naver.com/hongganz/222437398559
• https://install-django.tistory.com/36
• https://suhyunsim.github.io/2021-09-27/Linux-disk
• https://blog.naver.com/baek2sm/222198250764

상황

static inner class를 JPQL @Query를 통해 조회하는 쿼리를 작성했는데 다음과 같은 에러를 마주했다.

쿼리

@Query("SELECT new woowa.promotion.dto.response.CouponGroupSimpleResponse.CouponGroupSimpleDto("
            + "couponGroup.id, couponGroup.title) FROM CouponGroup couponGroup "
            + "WHERE (:cursor = 0L OR couponGroup.id < :cursor) "
            + "ORDER BY couponGroup.id DESC"
    )

에러 메시지

org.springframework.beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name ...

...

Caused by: org.springframework.data.repository.query.QueryCreationException: 
Could not create query for public abstract java.util.Optional ...
Reason: Validation failed for query for method public abstract java.util.Optional

...

Caused by: java.lang.IllegalArgumentException: 
org.hibernate.hql.internal.ast.QuerySyntaxException: Unable to locate class 

...

해결

처음에는 대소문자 문제나 오타가 있는줄 알고 쿼리를 눈빠지게 봤는데 문제가 없었다.

찾아보니 inner class의 경우 $로 표시해야 한다고 한다.

@Query("SELECT new woowa.promotion.dto.response.CouponGroupSimpleResponse$CouponGroupSimpleDto("
            // 생략
    )

참고로 쿼리에 $ 표시를 사용하게 되면 빨간줄이 뜨는데 무시하면 된다.

관련해서 Jetbrains 커뮤니티에 이슈가 있는데 아직 해결이 안된 것 같다.

🔗 참고 링크

• https://stackoverflow.com/questions/11388840/java-compiled-classes-contain-dollar-signs/11388863#11388863
• https://stackoverflow.com/questions/35503917/hql-and-inner-classes-such-as-builders
• https://docs.jboss.org/hibernate/orm/3.5/reference/en/html_single/#mapping-declaration-class
• https://velog.io/@kwg527/Query%EB%A1%9C-Dto-%EC%A1%B0%ED%9A%8C-%EC%8B%9C-%EB%82%B4%EB%B6%80%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A0%91%EA%B7%BC-%EB%B0%A9%EB%B2%95

상황

팀프로젝트를 하며 처음으로 SSL 인증서를 발급받아 https로 배포를 해보았는데 API 요청을 받았을 때 이런 오류를 맞이하게 되었다.

너무 이상했던 것은 이 오류가 뜨기 전 API 요청과 응답이 정상적으로 되고 있었고, 당시 프론트/백 모두 휴식 기간을 가지며 코드를 수정한 적이 없었는데 갑자기 오류가 발생했다.

Spring 에러 로그

o.apache.coyote.http11.Http11Processor   : Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.

java.lang.IllegalArgumentException: Invalid character found in method name 
// 생략
. HTTP method names must be tokens

구글링을 해보니 대부분 "https가 활성화되지 않았는데 https로 요청하면 발생할 수 있는 오류로, http로 요청하면 해결된다" 고 하는데 우리 상황에는 맞지 않은 것 같았다.

왜냐면 프론트/백 모두 코드를 수정하지 않았고 오류가 뜨기 전까지는 https로 통신했기 때문이다.

그래도 혹시 몰라 http로도 요청해보았는데 그래도 안됐다. 아 참고로 Postman으로는 http/https 모두 통신 가능했다.

도대체 뭐가 문제일까...?

WAS 앞단에 Nginx가 있어 Nginx 에러 로그도 살펴보았다.

Nginx 에러 로그

SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking

Spring 단의 에러 로그만 봤을 때는 도대체 무슨 오류인지 감이 잡히지 않았는데, Nginx 오류를 보니 SSL 관련 오류인 것 같았다.

에러 메시지로 구글링을 해보고 있던 차에 프론트 분이 웹브라우저에서 뜨는 에러 메시지도 전달주셨다.

웹 브라우저 에러 메시지

웹 브라우저에서 이런 오류 메시지가 떴다고 한다. (아쉽게도 스크린샷은 없었다 ㅠㅠ)

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

이 에러 메시지까지 더해지니 SSL 관련 오류가 확실해보였다. 더불어 CIPHER라는 키워드까지 얻을 수 있었다!

원인

ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류의 원인은 다음과 같다.

1. 보안에 취약한 SSL 프로토콜을 사용하고 있거나, 취약한 암호묶음을 사용하고 있을 경우
2. 서버에서 응답한 Cipher Suites(암호화 형식)을 브라우저에서 처리 할 수 없는 경우

일단 보안에 취약한 SSL 프로토콜을 사용하고 있지는 않았다. 크롬 브라우저 기준 TLS 1.0 혹은 TLS 1.1의 경우 발생할 수 있으나, 우리 서버에서는 TLS 1.3을 사용하고 있었다.

그래서 Cipher Suites나 암호 묶음 관련 오류가 아닐까 추측했다. 아니면 클라이언트-서버의 프로토콜이 호환되지 않거나, 아니면 암호화 알고리즘 협상 과정에서 실패한 것으로 생각이 든다. (Cipher Suites 관련해서는 공부를 좀 더 해보고 별도로 다시 정리할 예정이다.)

해결

관련해서 스택오버플로우 글을 참고해서 Nginx에 설정을 추가하니 해결되었다.

오류 해결은 됐지만 원인이 정확하게 파악이 되지 않아서 찝찝한 트러블 슈팅이었다. https, SSL, Nignx 옵션, Cipher 등과 관련해서 공부를 좀 더 해봐야겠다.

server {
    // 생략

    ssl_prefer_server_ciphers   on;

    location / {
         // 생략
    }
}

ssl_prefer_server_ciphers 옵션 SSL/TLS 프로토콜에서 사용할 암호화 알고리즘을 지정하는 Nginx 옵션이다. 이 옵션은 클라이언트-서버 간 통신할 때 어떤 알고리즘을 사용할지에 대한 우선순위를 설정한다.

일반적으로 보안을 위해 on으로 설정하는 것이 권장된다.

• on:

  • 서버 측의 암호화 알고리즘 우선순위에 따라 클라이언트의 제안을 무시하고 서버 측의 알고리즘을 사용

• off:

  • 클라이언트가 제안한 알고리즘 중에서 서버가 가장 강력한 알고리즘을 선택

🔗 참고 링크

• https://serverfault.com/questions/905011/nginx-ssl-do-handshake-failed-ssl-error1417d18cssl/905019
• https://intro0517.tistory.com/200
• https://1004lucifer.blogspot.com/2018/11/chrome-errsslversionorciphermismatch.html
• https://www.hostinger.com/tutorials/ssl-version-cipher-mismatch-error

쿠폰 프로모션 프로젝트를 진행하며 쿠폰 발급 시 동시성 문제가 발생하는지 확인하는 테스트 코드를 작성해야 했다. 그런데 그동안 순차적으로 진행되는 테스트 코드만 작성해보아서 동시성 테스트 코드를 어떻게 작성하는지 알지 못했다. 그래서 동시성 테스트 코드는 어떻게 작성하는지 공부하고 그 내용을 정리해보려고 한다.

프로젝트 레포지토리: https://github.com/woowa-coupons/woowa-coupons

⌨️ 쿠폰 발급 코드

참고차 현재 프로젝트에서 쿠폰을 발급하는 코드의 일부를 발췌해 왔다. 쿠폰 발급 시, 프로모션의 조건을 확인하고 회원이 발급받을 수 있는 조건을 확인한 후 쿠폰을 발급한다.

    @Transactional
    public void issueCoupon(CouponIssueRequest request, Member member) {
        // 프로모션의 조건을 찾고
        List<PromotionOption> promotionOptions = promotionOptionRepository.findByPromotionId(request.promotionId());

        // 회원이 발급받을 수 있는 쿠폰 조건 확인
        CouponGroup allMatchedCouponGroup = promotionOptions.stream()
                .filter(promotionOption -> isMemberSatisfied(member, promotionOption.getConditions()))
                .map(this::getCouponGroups)
                .findFirst()
                .flatMap(couponGroups -> couponGroups.stream()
                        .filter(this::hasRemainCoupon)
                        .filter(couponGroup -> !isExpiredCouponGroup(couponGroup))
                        .filter(couponGroup -> !isAlreadyIssued(member, couponGroup))
                        .findFirst())
                .orElseThrow(() -> new ApiException(CouponGroupException.NOT_FOUND));

        // 쿠폰 발급
        issueCouponInCouponGroup(allMatchedCouponGroup, member);
    }

쿠폰이 발급되면 잔여 수량에서 -1을 한다.

    @Builder
    private Coupon() {
        // 생략
    }

    public void issue() {
        if (this.remainQuantity <= 0) {
            throw new ApiException(CouponException.EXHAUSTED);
        }
        this.remainQuantity--;
    }

✔️ 동시성 테스트

그러면 이제 여러 회원이 동시에 쿠폰을 발급하면 잔여 수량만큼 발급되는지 확인이 필요하다. 동시성 테스트를 위한 방법을 찾아보았는데 CountDownLatch와 ExecutorService를 활용한 예제 코드가 많았다.

우선 예제 코드를 먼저 보고 CountDownLatch와 ExecutorService에 대해 알아보자.

테스트 코드

테스트 코드 흐름을 정리해보면 다음과 같다.

1. ExecutorService를 통해 스레드 풀 생성
2. 생성된 스레드 풀에서 비동기로 쿠폰 발급 요청
3. 요청이 성공했을 경우 successCount +1, 실패했을 경우 failCount +1
4. CountDownLatch를 통해 비동기 작업이 끝났는지 확인
5. 테스트 결과 학인

    @Test
    void issueCoupon() throws InterruptedException {
        // ---- 테스트를 위한 데이터 준비 ----
        // given
        Long promotionId = savePromotion(); // 쿠폰 발급을 위해 프로모션 생성

        int couponAmount = CouponFixture.추석_쿠폰_신규.getInitialQuantity(); // 쿠폰 개수
        int memberCount = couponAmount + 100; // 동시 요청하는 회원수

        ExecutorService executorService = Executors.newFixedThreadPool(30); // 스레드 풀 생성
        CountDownLatch latch = new CountDownLatch(memberCount); // CountDownLatch 생성

        AtomicInteger successCount = new AtomicInteger();
        AtomicInteger failCount = new AtomicInteger();

        // 쿠폰 발급에 필요한 회원 가입
        List<Member> members = new ArrayList<>();
        for (int i = 0; i < memberCount; i++) {
            Member member = 랜덤_회원_가입();
            members.add(member);
        }

        // ---- 쿠폰 발급 ----
        // when
        for (int i = 0; i < memberCount; i++) {
            Member member = members.get(i);

            executorService.execute(() -> {
                try {
                    memberCouponService.issueCoupon(new CouponIssueRequest(promotionId), member);
                    successCount.incrementAndGet(); // 쿠폰 발급에 성공하면 successCount 증가
                } catch (Exception e) {
                    failCount.incrementAndGet(); // 쿠폰 발급에 실패하면 failCount 증가
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();

        // ---- 테스트 결과 확인 ----
        // then
        List<MemberCoupon> memberCoupons = supportRepository.findAll(MemberCoupon.class);

        assertThat(memberCoupons.size()).isEqualTo(couponAmount); // 발급 받은 쿠폰 수가 발급된 쿠폰 개수와 일치하는지 확인
        assertThat(successCount.get()).isEqualTo(couponAmount);
        assertThat(failCount.get()).isEqualTo(100);
    }

ExecutorService

• 공식 문서 링크:
  • https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html
• Baeldung 링크:
  • https://www.baeldung.com/java-executor-service-tutorial

ExecutorService는 java.util.concurrent에서 제공하는 클래스다.

공식 문서에 따르면 ExecutorService는 Executor를 상속받은 인터페이스로, 동시에 여러 작업들을 싱행시키는 메서드를 제공하고 하나 이상의 비동기 작업 진행 상태를 추적하고 관리할 수 있는 메서드를 제공해주는 클래스이다.

An Executor that provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks.

비동기 작업을 지원하는 메서드 일부를 살펴보면 execute()와 submit()이 있다.

• execute():
  • 인자: Runnable 인터페이스
  • 리턴 타입: void

• *submit(): *
  • 인자: Runnable과 Callable 인터페이스
  • 리턴 타입: Future 객체

테스트 코드 예제를 찾아보았을 때 두가지 메서드를 많이 사용하고 있었는데, 작업 결과가 필요하면 submit()을 쓰고 비동기 작업만 실행할 것이라면 execute()를 사용하면 될 것 같다는 생각이다.

💡 참고:

• execute()는 Executor 인터페이스에 정의 되어 있고, submit()은 ExecutorService 인터페이스에 정의되어 있다.
• ExecutorService는 Executor를 상속받았기 때문에 두 메서드 모두 호출할 수 있다.

CountDownLatch

• 공식 문서 링크:
  • https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CountDownLatch.html
• Baeldung 링크:
  • https://www.baeldung.com/java-countdown-latch

CountDownLatch도 java.util.concurrent에서 제공하는 클래스다.

공식 문서에 따르면 CountDownLatch는 1개 혹은 그 이상의 스레드가 다른 스레드의 작업이 완료될 때까지 기다릴 수 있게 도와주는 클래스이다.

A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.

CountDownLatch 메서드

테스트 코드에 활용한 메서드를 살펴보자.

• 생성자
  • 인자로 Latch 숫자 전달

CountDownLatch latch = new CountDownLatch(memberCount);

• countDown()
  • 호출 시, Latch 숫자가 1씩 감소

latch.countDown();

• await()
  • Latch의 숫자가 0이 될 때까지 대기

latch.await();

동시성 테스트할 때 왜 CountDownLatch가 필요할까?

쿠폰 발급을 비동기 작업으로 여러 스레드에서 처리하면 모든 스레드의 작업이 언제 끝났는지 알 수가 없다. 따라서 CountDownLatch를 활용해 모든 스레드의 작업이 끝났는지 확인이 필요하다.

CountDownLatch를 생성할 때 Latch 수를 작업 횟수만큼 설정하고, 작업이 한번 실행할 때마다 latch.countDown()를 호출한다.

latch.await()를 통해 작업이 끝날 때까지 대기 후, Assertions으로 테스트 결과를 확인한다.

🔗 참고

• https://parkadd.tistory.com/114
• https://velog.io/@mohai2618/%EB%8F%99%EC%8B%9C%EC%84%B1-%ED%99%98%EA%B2%BD-%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%95%98%EA%B8%B0
• https://codechacha.com/ko/java-countdownlatch/

이번주 미션은 로또 게임이다. 내가 작성한 코드와 PR은 밑에 링크에서 확인할 수 있다.

• 로또 미션 레포지토리: https://github.com/jinny-l/java-lotto-6
• 로또 미션 PR: https://github.com/woowacourse-precourse/java-lotto-6/pull/262

메일에 보면 이번주 미션의 목표는 "클래스 분리"와 "단위 테스트 작성"이었다. 이전에도 로또 미션은 한번 구현해보았는데, 오히려 저번보다 이번에 머리가 더 아팠다.

이전 2번의 미션에 비해 이번 미션은 더 잘할 것이라고 생각했는데 코드를 짜면서 절망의 계곡에 와버렸다,, 객체지향은... 알면 알수록 어렵다.

각설하고 회고를 시작해보겠다.

🔍 공부한 내용과 고민들

원시값 랩핑

클래스의 책임 분리를 더 잘해보기 위한 방법을 찾아보다가 "원시값 랩핑"에 대한 키워드가 많이 보였다.

그래서 로또 숫자 하나를 의미하는 Integer를 랩핑해 우테코에서 제공한 Lotto 클래스의 List<Integer>를 List<LottoNumber>로 변경하였다.

원시값을 포장하기 전에는 Lotto가 List의 각 요소들이 1~45 사이의 숫자인지 검증하고, 길이가 6인지도 검증하고 등등 유효성 검증을 많이 해야 했다.

원시값을 포장하니 LottoNumber가 일부 유효성 검증을 책임지게 되면서 확실히 책임이 분리되는 것을 느꼈다.

단점 아닌 단점(?)으로는 원시값이 포장되었다 보니 값을 출력하기 위해 toString()을 OverRiding해야 했다. 아니면 getter를 사용하면 되는데 출력을 위한 메서드로는 getter 보다는 toString()를 더 깔끔하다고 느껴졌다.

LottoNumber.class

public record LottoNumber(int value) {

    public LottoNumber {
        // 생략
    }

    @Override
    public String toString() {
        return String.valueOf(value);
    }
}

일급 컬렉션

또한 클래스 분리를 위해 일급 컬렉션을 활용했다. 원시값을 랩핑하고 일급 컬렉션을 활용하다보니 다음과 같은 구조가 되었다.

• LottoNumber: 1~45 사이의 숫자를 랩핑한 클래스(숫자 범위 검증 등 담당)
• Lotto: List<LottoNumber>를 랩핑한 클래스(중복 숫자 검증 등 담당)
• Lottos: List<Lotto>를 랩핑한 클래스

그런데 Lottos가 갑자기 붕 떠버렸다. Lottos는 단순히 컬렉션을 랩핑하고, 내부에는 별다른 로직이 없다.

만약 고객이 구매할 수 있는 로또 장수에 제한이 있는 등 제약사항이 있다면 Lottos도 도메인 로직이 생기겠지만, 현재 상태에서는 제약사항이 없기에 오버프로그래밍한 것은 아닌지 고민이 되었다.

계속 고민을 하다가 일급 컬렉션의 장점 중 하나는 “컬렉션에 이름을 붙일 수 있다는 것”이라고 생각이 들었고 오버프로그래밍이라면 이로부터 파생될 수 있는 문제점도 직접 느껴보는 것이 좋을 것 같아서 일단은 해당 클래스를 유지하는 것으로 결론을 내렸다.

메서드 책임에 대한 고민

수익률을 계산하는 책임은 누구한테 있는건데...?

처음에는 Service 없이 Controller에서 도메인 호출만 해서 프로그램을 구현했다. 그런데 그러다보니 누구에게도 속하기 애매한 로직이 생겼다. 바로 수익률을 계산하는 로직이다.

특히 이 두개 클래스 중 어디에 속해야 하는 로직인지 고민을 엄청 많이 했다.

• Money: "구입 금액"을 책임지는 도메인
• LottoResult: "당첨 결과"를 책임지는 도메인

Money는 구입 금액을 알고 있고, LottoResult는 당첨 금액에 대해 알고 있다. 수익률을 계산하려면 이 두 금액에 대해 모두 알고 있어야 하는데... getter로 둘다 꺼내와서 외부에서 계산해야 하나 고민하다가 이 두 객체를 필드로 갖고 있는 Profit이라는 객체를 만들었다.

두 개의 객체 어디에도 속하기 애매한 로직인것 같고, 그렇다고 굳이 객체를 만들어야 하나 싶기도 하고... 그렇다고 Controller나 Service에 getter로 값을 꺼내서 직접 계산하기에는 도메인 로직이 외부에 있고! 🤯 내가 느끼기에는 어디에 위치하기가 참 애매한 로직이었다.

고민했던 방법 중에 그나마 제일 났다고 판단한 방법은 그나마 Profit 객체를 만드는 것이었다. (다른 더 좋은 방법은 없는지 미션 제출 시점까지, 끝까지 고민했던 부분인데 프리코스 끝나고 다시 찬찬히 봐야겠다.)

EnumMap과 저장순서

로또 당첨 정보 관련 정보들을 모아 Enum으로 구현했다.

Rank.class

public enum Rank {

    FIFTH(3, false, 5_000),
    FOURTH(4, false, 50_000),
    THIRD(5, false, 1_500_000),
    SECOND(5, true, 30_000_000),
    FIRST(6, false, 2_000_000_000),
    NO_RANK(0, false, 0);

    public final int matchedCount;
    public final boolean matchesBonusNumber;
    public final int prize;

    Rank(int matchedCount, boolean matchesBonusNumber, int prize) {
        this.matchedCount = matchedCount;
        this.matchesBonusNumber = matchesBonusNumber;
        this.prize = prize;
    }

    // 이하 생략
}

해당 정보를 view에서 다음과 같이 출력하기 위해 당첨 정보를 LottoResult 클래스에 EnumMap을 활용하여 저장했다.

그리고 출력 시 사용하기 위해 Collections.unmodifiableMap()에 감싸서 값을 넘겨주고 있었는데 순서 보장에 대한 의문이 들었다.

출력 예시

3개 일치 (5,000원) - 1개
4개 일치 (50,000원) - 0개
5개 일치 (1,500,000원) - 0개
5개 일치, 보너스 볼 일치 (30,000,000원) - 0개
6개 일치 (2,000,000,000원) - 0개
총 수익률은 62.5%입니다.

LottoResult.class

public class LottoResult {

    private final Map<Rank, Long> results = new EnumMap<>(Rank.class);

    public LottoResult(Map<Rank, Long> results) {
        // 생략
    }

    public Map<Rank, Long> getResults() {
        return Collections.unmodifiableMap(results);
    }

    // 생략
}

EnumMap의 저장 순서

EnumMap은 Enum에 정의된 순서로 저장된다. 그런데 Collections.unmodifiableMap()으로 감싸도 순서가 보장이 될까?

출력할 때마다 순서가 바뀐다면 LinkedHashMap과 같은 다른 대안을 생각해야 되니까 얼릉 내부 코드를 살펴보자.

두번째의 private 메서드를 살펴보면 UnmodifiableMap이라는 구현체를 반환할 때 인자로 받는 Map을 참조하고 있다.

그리고 스크린샷의 1504 라인쪽 메서드를 보면 삭제하거나 추가하는 등 기존 Map을 수정하지 못하도록 막고 있는 것을 확인할 수 있다.

즉 원본 객체인 EnumMap을 그대로 참조하고 있기 때문에 순서가 보장된다.! (이 말은 반대로 하면 원본 데이터가 바뀌면 참조하는 데이터도 순서가 바뀐다는 뜻이다.)

👋 마치며

미션 구현하면서 엄청 많은 고민들을 했는데, 이렇게 또 회고하면서 정리해보니 별로 많게 안 느껴지도 하는 것이... 코딩 능력과 더불어 글 쓰기 능력도 키워야겠다는 생각이 든다.

어느새 날씨가 쌀쌀해졌고, 프리코스도 절반 이상을 지나 이제 1개의 미션만 남겨두고 있다. 마지막까지 후회없이 최선을 다하자.

이번주차 미션은 자동차 경주 게임이었다. 미션 요구사항과 필자가 작성한 코드는 밑에 링크에서 확인할 수 있다.

• 자동차 경주 미션 레포지토리:
  • https://github.com/jinny-l/java-racingcar-6
• PR:
  • https://github.com/woowacourse-precourse/java-racingcar-6/pull/672

이번주 미션을 진행하면서 구조 설계에 대해 많은 고민을 했던 것 같다.

구현하다보니 Service와 Controller는 비슷한 역할을 했고 역할을 나누는 것이 오히려 오버 프로그래밍인 것 같다는 생각이 들어서 이번 미션에는 Service없이 domain과 controller로 구성하게 되었다.

그럼 회고를 시작해보자!!

🔍 공부한 내용과 고민

테스트 코드

테스트 라이브러리의 존재는 알고 있었지만 그동안 이런저런 이유로 학습을 미뤄왔었는데 이참에 기술부채를 좀 해결해보았다.

• 일단은 Junit과 AssertJ에 대해 공부를 했고, 많은 사람들이 가독성 측면에서 AssertJ를 더 선호한다는 것을 알게되었다.

• 여러 개의 Assertion이 있을 경우, 테스트 코드가 실패해도 모두 검증하고 결과를 보여줄 수 있는 방법에 대해 찾아보다가 assertAll()과 SoftAssertions의 차이점의 대해 공부했다.

결과 출력을 위한 Dto 사용

우선 Dto 사용 이유에 대해 이해를 돕기 위해 내가 했던 고민과 프로젝트 구조에 대해 간단하게 설명을 해보겠다.

고민

사실 별거 아닌 고민일 수도 있지만, 회차별 결과를 바로바로 출력할지 경주가 끝날 때까지 결과를 모아두었다 한꺼번에 출력할지 고민했다.

실행 결과 예시

실행 결과
pobi : -
woni : 
jun : -

pobi : --
woni : -
jun : --

pobi : ---
woni : --
jun : ---

게임이 좀 더 확장된다면 유저가 쫄깃한(?) 게임을 위해 라운드를 한번씩 누르며 게임을 진행할 수도 있겠지만 그런 요구사항은 없었기에 일단 주어진 그 자체로 생각하기로 했다.

한번씩 출력을 한다해도 사람이 시간 간극을 느끼지 못할정도로 동시에 출력이 될 것으로 생각했다. 그리고 System.out.println()은 무겁기 때문에 호출 횟수를 줄이고 싶었다.

그래서 List에 결과를 담아두었다가 결과를 한꺼번에 출력하게 되었는데, 그 과정에서 여러가지 문제점이 발생했다. 😅

프로젝트 구조

최종 프로젝트 구조는 다음과 같다.

• 도메인:

  • Car.java: 경주 게임에 참여하는 자동차 1대를 의미하는 클래스
  • Cars.java: 경주 게임에 참여하는 자동차 여러 대를 담당하는 클래스
  • Game.java: 경주 게임을 담당하는 클래스

• Dto

  • RoundResult.java: 경주 라운드별 결과를 담당하는 클래스

Game.java

• Cars와 경주 횟수가 정해져야 Game 객체가 생성되고, List<RoundResult>에 모든 게임 결과가 저장된다.
• 결과를 출력할 때는 List<RoundResult>를 StringBuilder로 붙여서 한번에 출력한다.

(List<RoundResult>도 Repository로 따로 분리할까하다가 오버프로그래밍인 것 같아서 Game 도메인 안에 두었다.)

public class Game { // 이해를 돕기 위해 첨부한 코드로, 생략된 부분이 있다.

    private final Cars cars;
    private final int numberOfAttempts;
    private final List<RoundResult> results;

    public Game(Cars cars, int numberOfAttempts) {
        this.cars = cars;
        this.numberOfAttempts = numberOfAttempts;
        this.results = new ArrayList<>();
    }

    public void moveCars() {
        for (int i = 0; i < numberOfAttempts; i++) {
            cars.moveAll(getMovingNumbers());
            saveResult();
        }
    }

    private void saveResult() {
        results.add(RoundResult.from(cars));
    }
}

Dto가 만들어지기 까지 다음과 같은 시도가 있었다.

첫번째 시도: List<Map<String, Integer>>

Dto를 만들기 전에는 자동차 이름과, 이동한 자리를 Map<String, Integer>에 저장하고, 회차별 구분을 위해 Map<String, Integer>를 랩핑한 클래스를 만들었다.

그런데 코드 짤 때는 생각치도 못했던 문제를 테스트를 하면서 발견했는데, HashMap이라서 자동차들의 출력 순서가 보장되지 않는 문제가 있었다.

RoundResult.java

public record RoundResult(Map<String, Integer> carsPositions) {

    public static RoundResult from(Cars cars) {
        return new RoundResult(cars.getCars().stream()
                .collect(Collectors.toUnmodifiableMap(
                        Car::getName,
                        Car::getPosition
                )));
    }
}

두번째 시도: List<LinkedHashMap<String, Integer>>

출력 순서를 보장하기 위해 LinkedHashMap으로 변경했는데, Car로부터 변환을 위해 스트림의 merge function을 사용해야 했다.

merge function에 대해 아직 완벽하게 이해가 되지 않아서 이해하지 못하는 코드를 쓰고 싶지 않았다. (회고를 하면서 다시 보니 스트림이 오히려 for문 보다 가독성이 떨어지는 것 같아서 for문을 사용해도 좋았을 것 같다.)

그리고 외부에서 볼 때 Map의 String, Integer가 각각 무엇을 의미하는지 안보이는 것도 가독성이 떨어진다고 생각이 들었다.

public record RoundResult(LinkedHashMap<String, Integer> carsPositions) {

    public static RoundResult from(Cars cars) {
        LinkedHashMap<String, Integer> carsPositions = cars.getCars().stream()
                .collect(Collectors.toMap(
                        Car::getName,
                        Car::getPosition,
                        (existing, replacement) -> existing,
                        LinkedHashMap::new
                ));
        return new RoundResult(carsPositions);
    }
}

세번째 시도: Dto 생성

앞선 두가지 문제점을 해결하기 위한 방법을 고민하다가 문득 최근에 공부했던 inner class를 활용한 Dto를 만들어보면 어떨까하는 생각이 들었다.

[Spring] DTO 관리 - Inner Class

Dto 구현을 통해 앞서 말한 두가지 문제점을 해결해보았다.

• 출력 시 순서 보장
• 각 필드가 무엇을 의미하는지 표현

public record RoundResult(CarsDto carsDto) {

    public static RoundResult from(Cars cars) {
        return new RoundResult(CarsDto.from(cars));
    }

    public record CarsDto(List<CarDto> carDtos) {

        private static CarsDto from(Cars cars) {
            return new CarsDto(cars.getCars().stream()
                    .map(CarDto::from)
                    .toList());
        }
    }

    public record CarDto(String name, int position) {

        private static CarDto from(Car car) {
            return new CarDto(car.getName(), car.getPosition());
        }
    }
}

👋 마치며

자동차 경주 미션을 어느정도 마무리하고 우테코 커뮤니티에서 서로 PR 리뷰를 하였는데, 모든 사람들이 정말 열정이 가득했다.!

그 열정 속에서 남들 코드 보면서 내가 생각치 못한 부분도 배울 수 있었고, 내 코드에 대한 피드백을 통해 내가 작성한 코드에 대해 한번 더 돌아볼 수 있어서 좋았다!

그리고 점점 체력이 떨어지는 것을 느끼는데, 이번주 회고도 떨어진 체력만큼 퀄리티가 좋지 않다고 느껴졌다..🥲

앞으로 꾸준히 코딩도 하고 글도 잘 쓰려면 체력 관리를 잘 해야겠다!

우아한테크코스 6기 프리코스에 참여하게 되어 앞으로 4주간을 기록하고자 한다.

이번 1주차 미션은 근본의 숫자 야구 게임이었다. 필자가 작성한 코드는 밑에 첨부한 링크에서 확인 가능하다.

숫자 야구 Github Repository

최근까지 Spring으로 프로젝트를 하다가 순수 Java로만 미션을 진행하니까 색다른 느낌이기도 하고 재미있었다. ㅎㅎ

1주차에는 기본에 충실하면서 남들이 읽기 쉬운 코드를 작성하는 것이 나만의 목표였다. (과연 읽기 쉬운 코드를 짰는지...는 우테코 디스코드를 통해 PR 리뷰 요청을 해 피드백을 받아볼 예정이다.!)

✏️ PR Review 블로그 보고 들어오시는 분도 있을 것 같아 개인 레포지토리에 리뷰용 PR을 올렸습니다. ↓↓ PR 리뷰는 언제나 환영입니다! ↓↓ https://github.com/jinny-l/java-baseball-6/pull/1

그리고 미션을 구현하면서 전반적인 설계나, 테스트 등 다양한 다양한 고민을 하게 되었다.

본글은 미션을 진행한 과정과 고민등에 대해 기록하고자 한다. 그럼 회고를 시작해보자!

🏃🏻 미션 진행 과정

✨ 기능 목록 작성

"기능을 구현하기 전 docs/README.md에 구현할 기능 목록을 정리해 추가한다."라는 요구사항이 있어 우선 기능 목록을 작성하고 기능 구현을 시작했다.

처음부터 모든 목록을 다 작성한 것은 아니고 구현하면서 누락한 내용이 있으면 그때그때 추가했다.

그리고 커밋할 때 구현한 기능은 to do 박스에 체크하면서 진행했다.

사실 정신없이 구현하다보면 어디까지 구현이 되었고, 어느 부분이 남았는지 헤맬때가 있었다. 머리속에 다음에 뭐 해야하지?라는 갈고리(🤯)가 생겼는데, 이때 기능 목록이 길잡이가 되어주었다.

기능 목록에 따라 하나 하나 구현하다보니 기능 구현이 완료되었다.

README.md (캡쳐하기에 너무 길어서 일부 내용만 캡쳐했다. 원본은 여기서 확인할 수 있다.)

✅ 테스트 케이스 목록 작성

기능 구현을 다하고 기능 확인을 위해 테스트 코드를 작성했다.

테스트 코드 작성 전에도 기능 목록 작성한 것과 같이 README에 미리 테스트 케이스 목록을 만들었다.

테스트 코드를 짜다보면 어떤 케이스를 테스트했는지, 어떤 케이스를 테스트 안했는지 한눈에 안 보이기도 하고 코드를 짜면서 케이스를 생각하기 어렵다보니 목록을 짜게 되었다.

아직 테스트 코드 짜는 게 어렵지만... 테스트 코드를 짤 때도 케이스가 미리 정리되어 있다보니 한결 수월하게 진행할 수 있었던 것 같다.

README.md (캡쳐하기에 너무 길어서 일부 내용만 캡쳐했다. 원본은 여기서 확인할 수 있다.)

🔍 공부한 내용과 고민

☕️ Java 17

작년 우테코 요구사항은 Java 11이었는데, 올해는 Java 17로 바뀌었다. 지금까지 Java 11만 썼는데 Java 17을 사용하기 위해 변경점을 공부했다.!

그리고 변경점만 공부하는 것보다는 올해에는 왜 요구사항이 바뀌었고 Java 17을 써야 하는지 알고 쓰는 것이 좋을 것 같아서 관련 내용을 공부하고 블로깅하였다.

[Java] Java 17을 사용해야 하는 이유와 Java 17 변경점

다음 미션에는 Java 17에 추가된 기능을 하나씩 사용해볼 예정이다!

🧐 랜덤으로 생성된 숫자는 어떻게 테스트하지?

숫자 야구는 1부터 9까지 서로 다른 수로 이루어진 3자리의 수로 이루어져 있는데 미션 요구사항을 보면 이 숫자는 제공된 Randoms API를 활용하여 랜덤 값을 추출하여 만들어야 한다.

그때부터 고민이 시작되었다... 🤔

컴퓨터가 생성한 숫자 야구가 있고, 플레이어의 입력 값에 대한 결과(스트라이크, 볼, 낫싱)를 테스트해야 하는데... 숫자가 랜덤으로 생성되면 어떻게 테스트하지..?

랜덤으로 생성된 숫자를 테스트하는 방법에 대해 찾아보다가 좋은 블로그 글을 발견하게 되어 인사이트를 얻게 되었다!

🔗 참고한 블로그:

• https://velog.io/@jhp1115/자동차-경주-게임-구현-테스트-코드에서의-팁#4-테스트-하기-어려운-부분을-테스트-가능하게-바꾸는-법

바로 인테페이스로 추상화하는 것이다..!

• 랜덤 숫자 생성기를 인터페이스로 추상화하고
• main에서는 실제로 랜덤으로 숫자를 생성하는 클래스를 구현하고
• test에서는 의도한 숫자를 생성하는 클래스를 구현하면 테스트하기 수월해진다.

코드로 자세하게 알아보자.

1. 랜덤 숫자 생성기를 인터페이스로 추상화한다.

NumberGenerator.java

@FunctionalInterface
public interface NumberGenerator {

    List<Integer> generate();
}

2. 각 상황에 맞게 인터페이스를 구현한다.

RandomNumberGenerator.java - main에서 사용하는 구현체 : 랜덤 숫자 3개를 리턴하게 구현

@Override
    public List<Integer> generate() {
        List<Integer> numbers = new ArrayList<>();
        while (numbers.size() < BASEBALL_LENGTH) {
            int randomNumber = Randoms.pickNumberInRange(BASEBALL_START_NUMBER, BASEBALL_END_NUMBER);
            if (!numbers.contains(randomNumber)) {
                numbers.add(randomNumber);
            }
        }
        return numbers;
    }

TestNumberGenerator.java - test에서 사용하는 구현체 : 생성자 생성 시 입력받은 값을 그대로 리턴하게 구현

public static class TestNumberGenerator implements NumberGenerator {

        private final List<Integer> numbers;

        TestNumberGenerator(List<Integer> numbers) {
            this.numbers = numbers;
        }

        @Override
        public List<Integer> generate() {
            return numbers;
        }
    }

3. 의도한 테스트를 진행한다.

다음 코드는 실제로 제출한 미션 코드에서 일부를 발췌한 내용이다. 필자는 Service 클래스에서 랜덤 숫자를 생성해 Baseball을 생성하게끔 구현해서 Service 테스트를 했는데, 각자 상황에 맞게 응용하면 될 듯 하다!

public class GameServiceTest {

    private GameService service;

    @BeforeEach
    void setUp() {
        // ↓ 의도한 숫자를 생성하는 TestNumberGenerator 생성(컴퓨터 Baseball이 1, 2 ,3으로 생성됨)
        service = new GameService(new TestNumberGenerator(List.of(1, 2, 3)));
        service.startGame();
    }

    @DisplayName("낫싱 상황일 때 맞는 결과를 리턴한다.")
    @Test
    void get_nothing_game_result() {
        // given
        service.setPlayerBaseball(List.of(4, 5, 6)); // 플레이어 Baseball을 4, 5, 6으로 생성

        // when
        GameResult gameResult = service.getGameResult();

        // then
        assertThat(gameResult).isEqualTo(GameResult.nothing()); // 낫싱 결과 예상
    }

    // ↓ 테스트용 NumberGenerator 구현
    public static class TestNumberGenerator implements NumberGenerator {

        private final List<Integer> numbers;

        TestNumberGenerator(List<Integer> numbers) {
            this.numbers = numbers;
        }

        @Override
        public List<Integer> generate() {
            return numbers;
        }
    }
}

👋 마치며

미션도 해야하고, 공부한 내용 정리하고, 회고까지 하니까 1주일이 뚝딱이다. 🥲

마치기 전에 다음주에 개선하고 싶은 점을 쓰고 회고를 마무리하려고 한다. 이번주 미션하면서 다음 미션에는 꼭 개선해야지 했던 것이 있는데... 바로 테스트 코드이다.

기능 구현이 모두 완료되고 나서 테스트 코드를 짜니까 기능이 제대로 동작하는지 바로바로 확인이 어려웠고, 기능 구현 → 기능 확인 간의 호흡이 너무 긴 느낌이 들었다.

다음 목표는 1기능 1테스트 코드 짜는것을 목표로 진행하려고 한다!

이번 미션에 참여한 분들 모두 고생하셨습니다! 🙇🏻

우아한테크코스 6기 프리코스에 참여하게 되었는데, 프로그래밍 요구사항이 Java 17이었다.

처음 Java를 공부하면서 지금까지 Java 11을 썼는데 최근 시작한 팀프로젝트도 팀원이 Java 17을 써보자해서 겸사겸사 Java 17에 대해 공부하고 내용을 정리하고자 한다! 💪

☕️ 왜 Java 17을 사용해야 할까?

💡 참고:

• Java 17은 2021년 9월에 공개된 LTS 버전으로 Oracle JDK 기준 2029년 9월까지 지원된다.
• 공식 문서: https://openjdk.org/projects/jdk/17

우선 Java 17을 사용해야 하는 이유에 대해 알아보자.

Java LTS 버전의 기술 지원 기간

Java 17 이전의 LTS 버전은 Java 8과 Java 11이 대표적이다. 그런데 현재 서비스하고 있는 많은 레거시 프로젝트이 대부분 Java 8을 사용하고 있다.

Jetbrains에서 제공하는 통계만 봐도 Java 8의 점유율이 앞도적인 것을 확인할 수 있다.

• 2021년 Java 버전별 점유율 - Jetbrains

이에 따라 현재 프로젝트들의 기술 지원을 위해 Java 8은 11보다 더 긴 지원 시간을 갖게 되었다.

• Java 버전별 기술 지원 기간:

Java 17을 사용해야 하는 이유

Java 17을 사용하게 된 계기는 앞서 얘기한 바와 같이 개인적으로 학습이 주된 이유였다.

현업자인 제이든이 작성하신 블로그 글을 보면 현업에서는 다음과 같은 이유로 사용한다고 한다.

1. 신규 버전을 위한 대비
   • 회사들은 Java 8의 지원 종료일이 다가옴에 따라 새로운 버전으로 마이그레이션을 준비해야 하는 상황
   • 8 → 17 이후 버전으로 바로 마이그레이션하기에는 리스크가 있으니, 17버전의 기술 적응을 완료된 상태로 마이그레션을 하면 영향이 최소화 될 것
2. 다음 세대 플랫폼 호환을 위한 준비
   • SpringBoot 3.0부터 Java 17 이상을 지원하여 다음 세대 플랫폼 호환 준비도 주된 이유

실제로 2022년 Java 버전별 점유율을 보면 Java 8은 감소하고 Java 17은 크게 증가한 것을 확인할 수 있다.

• 2022년 Java 버전별 점유율 - Jetbrains

✨ Java 17의 변경점

그럼 Java 11과 비교했을 때 Java 17의 변경점에 대해 알아보자. 참고로 해당 글에서는 모든 변경점을 다루지 않고 아래 몇가지 추가된 기능만 추려서 다룰 예정이다.

• Text Block

• Record
• Sealed Classes
• Switch Expression
• Stream.toList()

Text Block

Java 11

Java 11 버전에서는 Json 형식의 문자열을 다음과 같이 표현해야 했다. 한눈에 봐도 가독성이 매우 안좋은 것을 확인할 수 있다.

String jsonString = "{\n" +
    "  \"name\": \"Jinny\",\n" +
    "  \"age\": 20\n" +
    "}";

Java 17

Java 17에서는 텍스트 블록을 제공해서 3개의 큰 따옴표로 랩핑해서 표현할 수 있다.

String jsonString = """
        {
          "name": "Jinny",
          "age": 20
        }
        """;

Record

Java 11

롬복 어노테이션이 편리성을 제공해주긴 하지만... Dto 클래스를 만들 때 여러 보일러 플레이트 코드를 추가해야 했다.

public class Dto {

    private final int data;

    public Dto(int data) {
        this.data = data;
    }

    public int getData() {
        return data;
    }
}

Java 17

Java 17에서는 Record를 활용하면 불필요한 코드를 제거할 수 있고, 클래스 자체로 명확한 의도를 표현할 수 있다.

public record Dto(
    int data
) {
}

💡 Record 특징:

• 멤버변수는 private final로 선언된다.
• 필드별 getter가 자동으로 생성된다.
• equals, hashcode, toString이 자동으로 생성된다.
• 기본생성자는 제공하지 않으므로 필요한 경우 직접 생성해야 한다.
• final 클래스이므로 다른 클래스를 상속하거나/상속시킬 수 없다.
• private final fields 이외의 인스턴스 필드를 선언할 수 없다.

Sealed Class

• Sealed 클래스는 상속하거나(extends), 구현(implements) 할 클래스를 지정해두고, 해당 클래스들만 상속/구현이 가능하도록 제한하는 기능이다.
• 이에 따라 개발자는 Sealed 클래스 코드만 봐도 어떤 클래스가 구현/상속했는지 쉽게 파악할 수 있게 되었다.
• 또한, 의도치 않은 클래스가 상속받았을 경우, 컴파일 시점에 에러를 체크할 수 있어 의도치 않은 실수를 방지할 수 있다.

// Parent.java
public sealed class Parent permits Son, Daughter {
    ...
}


// Son.java
// permits 로 선언된 class 만 Parent class 를 상속할 수 있다.
public sealed class Son extends Parent {}

Sealed Class 특징:

• super-class 에 sealed 키워드를 사용한다.
• permits 키워드 뒤에 해당 클래스를 상속받을 sub-class를 선언한다.
• sealed 된 클래스를 활용하기 위해서는 같은 모듈 혹은 같은 패키지 안에 존재 해야한다.

Switch Expression

Java 11

기존의 switch문은 다수의 case와 break가 존재하며 불필요한 중복 코드가 발생하고 있다.

public static void printDayOfWeek(String dayOfWeek) {
    switch (dayOfWeek) {
        case "Monday":
        case "Tuesday":
        case "Wednesday":
        case "Thursday":
        case "Friday":
            System.out.println("평일입니다.");
            break;
        case "Saturday":
        case "Sunday":
            System.out.println("주말입니다.");
            break;
    }

Java 17 변경된 문법에서는 똑같은 의미를 훨씬 간결하게 표현하고 있다.

public static void printDayOfWeek(String dayOfWeek) {
    switch (dayOfWeek) {
        case "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" 
            -> System.out.println("평일입니다.");
        case "Saturday", "Sunday"
            -> System.out.println("주말입니다.");
    }

변경된 Switch문 문법:

• -> 화살표를 사용해 실행문을 나타낸다.
• 조건들을 ,를 이용해 나열할 수 있다.
• break를 사용하지 않는다.

또한 출력문 안에서 사용이 가능해졌다.

public static void printDayOfWeek(String dayOfWeek) {
    System.out.println(
            switch (dayOfWeek) {
                case "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" -> System.out.println("평일입니다.");
                case "Saturday", "Sunday" -> System.out.println("주말입니다.");
                default -> "디폴트 값입니다.";
            }
        );
    }

Stream.toList()

기존에 Collectors.toList()를 .toList()로 표현할 수 있게 되었다.

Java 11

List<Integer> numbers = List.of(1, 2, 3, 4, 5);

List<Integer> result = numbers.stream()
        .filter(number -> number > 1)
        .collect(Collectors.toList());

Java 17

List<Integer> numbers = List.of(1, 2, 3, 4, 5);

List<Integer> result = numbers.stream()
        .filter(number -> number > 1)
        .toList(); // 변경
System.out.println(result);

🔍 그렇다면 두 메서드는 완전 동일한 것으로 볼 수 있을까? JavaDocs를 살펴보면 두 메서드의 return type이 다르다.

Collectors.toList() : ArrayList를 리턴하고 있으며, 불변 타입이 아니다.

toList() :불변 List를 리턴한다.

🔍 그렇다면 toList()는 Collectors.toUnmodifiableList() 과 동일할까?

• JavaDocs에 따르면 Collectors.toUnmodifiableList()는 내부에서 null 체크를 하고 있지만, toList()는 null 체크를 하지 않아 null 값이 들어갈 수 있다.

The returned Collector disallows null values and will throw NullPointerException if it is presented with a null value.

번역: 반환된 Collector는 null 값을 허용하지 않으며, null 값을 전달받으면 NullPointerException을 throw합니다.

Collectors.toUnmodifiableList()

🔗 참고 자료:

• https://velog.io/@ililil9482/Java17%EC%9D%84-%EA%B3%A0%EB%A0%A4%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C
• https://techblog.gccompany.co.kr/%EC%9A%B0%EB%A6%AC%ED%8C%80%EC%9D%B4-jdk-17%EC%9D%84-%EB%8F%84%EC%9E%85%ED%95%9C-%EC%9D%B4%EC%9C%A0-ced2b754cd7
• https://binux.tistory.com/146

상황

현재 프로젝트의 요구사항 중 "이미지 업로드 기능"이 있어 기능 개발 후 로컬에서 테스트를 하고 배포를 하니 413 오류가 발생했다.

파일 1, 2개 정도는 업로드가 되는데 3~4개 정도를 넘어가면 오류가 발생했다.

설정 파일에 분명 업로드 가능한 파일 사이즈를 넉넉히 설정했는데 말이다.

application.yml 파일 설정

  servlet:
    multipart:
      enabled: true
      max-file-size: 30MB
      max-request-size: 30MB

원인 및 해결

서버에서 오류 로그를 살펴보았는데 로그가 안찍혀 있었다. 로그가 안찍혔으니 요건 또 분명히 Nginx 설정 관련 문제겠거니 싶었다.

찾아보니, 파일 업로드 크기를 따로 설정해주지 않으면 기본 설정이 1M라고 한다. (그러니 파일 34개 이상 업로드하면 오류가 발생했지...ㅠ)~~

다음과 같이 설정을 추가하니 오류가 해결되었다.

http {
    client_max_body_size 30M;
}

💡 참고: 만약 Nginx 설정을 추가했는데 501 에러가 발생한다면 위와 같이 application 설정에 multipart 파일의 업로드 크기와 관련된 설정을 했는지 확인해야 한다.

상황

현재 프로젝트의 개발 서버 환경은 EC2로, Spring Boot + NGINX로 구성되어 있다. 프론트가 개발 서버로 Stomp 통신을 위해 Web Socket Handshake 요청을 보내는데 문제가 생겼다.

문제

1. 프론트에서 Handshake 요청 시 백엔드로 넘어오기 전에 Fail 오류 발생 (웹브라우저에서 오류 로그를 볼 수 있으나 백엔드 서버에서는 아무런 로그가 찍혀있지 않았음)
2. 1번 문제를 해결하고 나니 "Handshake failed due to invalid Upgrade header: null" 오류 발생 (백엔드 서버에 로그 찍힘)

고민

일단 상황을 돌아보면서 원인의 근원지를 추측해보았다.

• 프론트의 문제인지, 프론트 -> 백엔드로 넘어오는 사이에 모종의 이유로 유실된 것인지 파악이 필요
• local에서 Apic으로 테스트 했을 때는 문제가 없었는데 서버로 올라갔을 때 문제가 발생했음

그래서 일단 프론트 문제가 아니고 프론트 -> Nginx -> 백엔드로 요청하면서 발생한 문제로, 1번 문제는 로그가 안 찍혀서 Nginx 이슈이고, 2번 문제는 백엔드 문제라고 생각이 들었다.

원인 및 해결

1. Handshake 요청 시 백엔드로 넘어오기 전에 Fail 오류 발생

원인 이 문제는 프론트 코드와도 관련이 있는 것으로 생각이 드는데, 예제 코드에는 대부분 다음과 같이 SockJS 연결 위에 Stomp 프로토콜을 설정했다.

그런데 우리 프론트는 Stomp 클라이언트를 설정하고 생성하는 코드밖에 없었다.

예제 코드)

var sockJS = new SockJS("/ws");
var ws = Stomp.over(sockJS);

우리 프론트 코드)

import { Client } from "@stomp/stompjs”;
const client = new Client();

해결 반면 백엔드 설정은 SockJS 연결 위에 Stomp 프로토콜을 설정하고 있었다. 프론트엔드 백엔드 환경이 달라서 에러가 발생한다고 생각이 들어 백엔드 설정을 바꿔보았다.

(프론트엔드 설정 바꿔보는 테스트도 해보고 싶었는데, 시간 부족으로 다음에 프론트분이랑 같이 테스트 해보기로 했다. 테스트한 결과가 나오면 블로그도 업데이트할 예정이다.)

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("*");
                // .withSockJS(); // 해당 옵션 삭제
    }

2. "Handshake failed due to invalid Upgrade header: null" 오류

첫번째 문제 해결 후 handshake에 실패했다. 오류 로그를 보니 업그레이드 header가 없다는 것인데, trace 원인도 안찍히고 딸랑 저것만 찍혀있다.

지금까지의 경험상 로컬에서 문제가 없는데 배포하면서 문제가 발생했다면, 특히 http header 관련이면 Nginx 설정 관련 오류일 가능성이 높아서 공식 문서를 찾아보았다.

원인 Nginx 공식 문서에 따르면 다음과 같다.

"Upgrade"는 홉별 헤더이므로 클라이언트에서 프록시 서버로 전달되지 않습니다. 리버스 프록시에서는 클라이언트가 프록시 서버를 알지 못하며 프록시 서버에서 특별한 처리가 필요합니다. 프록시 서버가 클라이언트의 WebSocket으로의 프로토콜 전환 의도를 알기 위해서는 이러한 헤더를 명시적으로 전달해야 합니다.

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

즉, "Upgrade" 및 "Connection"을 포함한 홉별 헤더는 클라이언트에서 프록시 서버로 전달되지 않기 때문에 handshake 과정에서 헤더를 찾지 못해 발생한 문제로 Nginx 설정에 위 내용을 추가하니 해결이 되었다.

참고

• http://nginx.org/en/docs/http/websocket.html
• https://7357.tistory.com/300
• https://velog.io/@myway00/Handshake-failed-due-to-invalid-Upgrade-header-null

프로젝트 규모가 커질수록 DTO가 많아져 관리 방법에 대한 고민이 생겼다. 특히 Json 응답에 랩핑된 형태의 개수만큼 DTO가 늘어났다.

예를 들면 다음과 같은 응답이 형태가 있다면, SellerDto, CategoryDto, AddressDto를 만들어야 한다.

    "product": {
        "seller": { 
            "id": 1,
            "nickname": "나판매자ㅋ"

        },
        "category": {
            "id": 7,
            "name": "가구/인테리어"
        },
        "address": {
            "id": 1,
            "name": "역삼 1동"
        },
        "title": "자전거",
        "contents": "싸게 팔아요"
    }

최종적으로ProductDto을 만들고 DTO를 조합하면 최소 4개의 파일이 필요하다.

완성된 클래스 형태는 대략 다음과 같겠다.

ProductDto

public class ProductDto {

    private final SellerDto seller;
    private final CategoryDto category;
    private final AddressDto address;
    private final String title;
    private final String contents;

    }

SellerDto

public class SellerDto {

    // 생략...

    }

CategoryDto

public class CategoryDto {

    // 생략...

    }

AddressDto

public class AddressDto {

    // 생략...

    }

👎🏻 문제점

이렇게 DTO가 늘어나면서 내가 느낀 문제점은 다음과 같다.

1. 랩핑된 형태가 많아질 수록 파일이 늘어난다.

• 단순히 파일이 늘어나는 것이 문제가 아니라 2번 3번 문제가 1번 문제로 인해 파생된다.

2. 비슷한 역할을 하지만 응답 형태가 다른 DTO가 많은데, 클래스 이름 짓기가 힘들다.

• ProductDetail, ProductSummary 이후에는 ProductLessDetail 이렇게 할 것인가?
  • 마치 최종, 최최종, 최최최종처럼...
• 아님 CRUD에 따라 ProductCreate, ProductRead, ProductUpdate, ProductDelete 이렇게 이름 짓고 이후에는?
• VO도 있다면 ProductVo랑 ProductDto의 역할이 더더욱 헷갈린다.

3. 어떤 DTO가 어디에서 쓰이고 있는지 헷갈린다.

• 프로젝트 규모가 작을 때는 문제가 되지 않았는데, 규모가 커지고 수정사항이 생길 때 어떤 DTO가 어디서 조합되어서 사용되고 있는지 찾는데 시간이 오래 걸린다.

⚡️ 개선 방법

DTO 관리 방법을 찾아보다보니 Inner Class를 활용하는 방법이 있어서 프로젝트에 도입해보았다.

Inner Class를 활용하면 여러개의 DTO 하나의 클래스에서 깔끔하게 관리할 수 있다. 수정사항이 생기면 여러 곳을 돌아다니면서 수정할 필요가 없고 위에서 내가 느꼈던 문제점을 대부분 해결할 수 있었다.

또 Request, Response 내용이 많지 않을 경우에도 활용해보았는데 보기에도 깔끔하고 관리하기에도 좋았다.

1. 여러개의 DTO를 Inner Class로 관리

public class ProductDto {

    private final String title;
    private final String contents;
    private final SellerDto seller;
    private final CategoryDto category;
    private final AddressDto address;

    // 생성자, getter, setter 등 생략

    private static class SellerDto {
        private int id;
        private String nickname;

        // 생성자, getter, setter 등 생략
    }

    private static class CategoryDto {
        private int id;
        private String name;

        // 생성자, getter, setter 등 생략
    }

    private static class AddressDto {
        private int id;
        private String name;

        // 생성자, getter, setter 등 생략
    }
}

2. Request & Resonse를 Inner Class로 관리

실제로 프로젝트에서 사용했던 코드인데, 회원의 프로필 이미지 수정 요청 및 응답을 한 곳에서 관리했다.

public class MemberProfileImgUpdateDto {

    @Getter
    public static class Request {

        private final MultipartFile newProfileImg;

        public Request(MultipartFile newProfileImg) {
            this.newProfileImg = newProfileImg;
        }
    }

    @Getter
    public static class Response {

        private final String updatedImgUrl;

        public Response(String updatedImgUrl) {
            this.updatedImgUrl = updatedImgUrl;
        }
    }
}

서비스나 컨트롤러에서는 다음과 같이 사용하면 된다.

    public MemberProfileImgUpdateDto.Response updateMemberProfileImg() {
        // 로직 생략...
        return new MemberProfileImgUpdateDto.Response(newImageUrl);
    }

💬 소결

Inner Class 로 DTO 관리를 하면서 아직까지 추가적인 문제점은 느끼지 못했다.

다만 여러 곳에서 똑같은 형태로 사용하는 DTO가 Inner Class로 존재한다면 재사용하기 애매한 감이 있다. 이럴 경우 공용 DTO로 분리를 해도 되고, 사실 여러 곳에서 공용으로 사용한다고 꼭 재사용할 필요는 없다고 생각한다.

왜냐면 추후 한 곳에서만 요구하는 정보가 달라질 경우가 있을 수 있다. 물론 개발자는 중복 코드를 싫어하지만, 이때 의도치 않게 여러 곳이 부수적으로 변경될 이슈가 있으니 정보가 똑같아도 DTO가 여러개 존재해도 괜찮다고 생각한다.

아마 프로젝트 규모가 커지면 결국에 Inner Class 로 관리를 하더라도 이런저런 문제점이 생길 것 같은데, 그때 또 고민해보고 개선을 해보겠다!

팀 프로젝트를 하면서 협업을 하면서 관리해야 하는 yml 파일이 늘어나며 yml 파일 관리의 필요성과 중요성을 느꼈다.

지금까지 코드스쿼드 팀 미션을 4번 진행하면서 yml 파일 관리하는 방법도 점차 성장한 것 같아 그 과정을 기록해 보려고 한다.

참고로 사용하는 방법은 본문에 있으니, 급하면 밑의 본문부터 보면 된다.

4번의 팀프로젝트 과정을 요약해보면 다음과 같다.

☕️ 첫번째 팀 프로젝트 - Kiosk 미션

yml 관리 방법

• github에 올리지 않고 각자 local에서 관리
• 사용하는 기술이 많지 않아 yml에는 DB 정보밖에 없어서 딱히 불편함은 느끼지 못했다.

단점

• 하지만 관리해야 하는 yml 파일이 늘어날 수록, 또 팀원이 늘어날 수록 파일 관리가 어려운 단점이 있다.

✅ 두번째 팀 프로젝트 - Todo App 미션

yml 관리 방법

• Jasypt을 활용하여 파일 암호화 - Bean으로 설정
• 본문에서 다룰 내용인데 Jasypt로 파일 암호화를 해서 Github 레포지토리에 올렸다.

첫번째 프로젝트 때의 단점 해결

• 이렇게 하면 별도로 파일 관리를 하지 않아도 되고 팀원이 모두 같은 버전의 파일을 사용하고 있다는 보장을 할 수 있다.

문제: 배포 시 복호화 키 주입하는 방법

local에서는 Jasypt 복호화 키를 IntelliJ에서 환경변수로 설정해서 사용하였지만 배포 시에 Jasypt의 암호화 키를 어떻게 넣어줘야 하는지 몰라서 헤맸다.

ToDo App 팀 프로젝트 회고 글에 작성했던 내용인데 jar 실행할 때 복호화 키를 주입하는 방법을 몰라서 찾아보다가 Java vm option에 대해 알게 되었다.

이때는 vm option이 뭐가 있는지 몰라서 결국엔 서버에 미리 application.yml 작성해놓고 대체하는 방법을 사용했지만 다음 프로젝트 때 개선했다.

ToDo App 팀 프로젝트 회고 글 일부 내용:

📈 세번째 팀 프로젝트 - Issue Tracker 미션

yml 관리 방법

• Jasypt을 활용하여 파일 암호화 - yml로 설정
• 이전 프로젝트와 똑같이 Jasypt 기술을 활용하여 내용 암호화를 진행했지만 이번에는 Bean으로 등록하지 않고 yml로 설정해서 사용했다.

두번째 프로젝트 때의 문제 해결

두번째 프로젝트 때 배포 시 복호화 키 주입하는 방법을 몰라 헤맸는데 vm option을 더 공부해보니 배포할 때 -Djasypt.encryptor.password={시크릿키}를 option으로 주면된다.

🍆 네번째 팀 프로젝트 - Second Hand 미션

지금 막 시작한 프로젝트인데 Github Actions와 docker-compose로 배포를 진행하고 있다.

문제: 환경 변수 관리

앞서 경험한 것들을 총 집합해서 구성했지만 Dockerfile에 시크릿키를 전달해야 하는 이슈가 있다.

물론 docker-compose.yml 파일을 통해 변수를 직접 주입해주면 되지만 docker-compose.yml도 버전 관리를 위해 Github에 올리고 있으므로 Github에는 환경변수를 작성하지 않은 파일을 올려야 했고, 서버에서는 직접 변수를 입력해줘야 하는 번거로움이 있다.

그래서 docker-compose 파일에 시크릿키를 직접 작성하지 않을 수 있는 방법을 찾아보았다.

서버(EC2)에 환경변수 파일을 만들어 놓고 변수를 주입받으면 된다.

이 내용도 본문에서 다룰 예정이다.

1. Bean으로 Jasypt 암호화 설정

공식 홈페이지: http://www.jasypt.org/

1-1. build.gradle에 의존성 추가

implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.5'

1-2. Bean 등록

• Config 클래스 작성

@Configuration
class JasyptConfig {

//    @Value("${jasypt.encryptor.password}") 외부 환경변수를 어노테이션으로 주입받아도 되고 아래처럼 설정하는 방법도 있다.
//    private String JASTYPTKEY;

    @Bean("jasyptStringEncryptor")
    public StringEncryptor stringEncryptor() {

        PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
        SimpleStringPBEConfig config = new SimpleStringPBEConfig();

        // !!주의: 암복호화에 사용되는 키로 1-4번 과정에서 설정하는 변수명이랑 동일해야 한다. 
        config.setPassword(System.getenv("JASYPTKEY")); 

        config.setAlgorithm("PBEWITHMD5ANDDES"); // 암호화 알고리즘
        config.setPoolSize("1");                 // 암호화 인스턴스 pool
        config.setKeyObtentionIteration("1000"); // 반복할 해싱 횟수
        config.setSaltGeneratorClassName("org.jasypt.salt.RandomSaltGenerator"); // salt 생성 클래스
        config.setStringOutputType("base64");    // 인코딩 방식

        encryptor.setConfig(config);
        return encryptor;
    }
}

💡 참고:

• saltGenerator를 지정하지 않으면 default 값으로 RandomSaltGenerator를 사용한다.
• 고정된 salt 값을 사용하려면 StringFixedSaltGenerator를 사용하면 된다.
  • 이 경우 암호값이 동일하고 복호화 시에도 기존에 설정한 salt와 동일한 값을 지정해야 복호화가 가능하다.

이 외에도 config 설정이 더 있는데 보다 상세한 내용은 아래 URL에서 확인 가능하다.

• https://github.com/ulisesbocchio/jasypt-spring-boot#use-you-own-custom-encryptor

1-3. 내용 암호화

• 암호화 사이트에서 암호화를 진행하고 나온 결과를 yml 파일에 ENC()로 감싸서 작성한다.

application.yml 예시

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: ENC(URcBC2us4EiLrKbeiOdQIGnOz8USQI3Ct6VO9M0geIwetzGFzoMKJPupbvYgrv95uy8+2vdcRKq/xNfo9n367v9y/dFFHwSghtNYo5BX27iJpvCMoY4F+tXmV6RBjy6AlXyCifu+QMorBD+EpA7c2jDGZh3OQx6Y)
    username: ENC(aaAZtXujmwi47WvLzuFZEA==)
    password: ENC(msP9S4m29/R0bw6IN3Q6Kuasi4h4UENu)

1-4. Jar 실행 시 암복호화키 전달

IntelliJ

• 환경변수 추가

1. 인텔리제이 상단에 Edit Configurations... 클릭

2. Environment variables 영역에 변수 작성

스크립트

 java -jar -DJASYPTKEY=secret-key app.jar

2. yml로 Jasypt 암호화 설정

2-1. 의존성 추가

implementation 'com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.5'

2-2. yml 설정 파일 작성

jasypt:
  encryptor:
    iv-generator-classname: org.jasypt.iv.NoIvGenerator
    algorithm: PBEWithMD5AndTripleDES
    password: # 2-3번 과정때 사용하고 이후 지워야 함

⚠️ 주의:

• password에 암복화에 사용될 키를 작성하는데 해당 내용은 2-3 과정에 필요하다.
• 공개된 곳에 올릴 때는 지워야 한다.

2-3. 내용 암호화

Bean으로 등록했을 때처럼 암호화 사이트에서 암호화해도 되는데 해당 방법은 위에서 사용했으니 이번에는 다른 방법으로 암호화해보겠다.

출력에 필요한 클래스 파일을 임시로 하나 생성해서 암호화하는 방법이다.

• 임시로 클래스 하나 생성

@SpringBootTest
class SecondHandApplicationTests {

    @Autowired
    StringEncryptor stringEncryptor;

    @Test
    void encrypt() {
        String encrypt = stringEncryptor.encrypt("secret-key");
        System.out.println("encrypt = " + encrypt);
    }
}

• 출력된 내용을 yml 파일에 작성

2-4. Jar 실행 시 암복호화키 전달

IntelliJ

• 2-2번 과정에서 삭제한 password를 전달해야 한다.

1. 인텔리제이 상단에 Edit Configurations... 클릭

2. Modify options > Add VM options 클릭

3. vm options에 password 작성

-Djasypt.encryptor.password=key

스크립트

java -jar -Djasypt.encryptor.password=$JASYPT_PASSWORD app.jar

3. 서버 환경변수 설정

3-1. 환경변수 설정

서버에 환경변수를 미리 작성해두고 배포 시 활용할 수 있다.

1. Vim으로 bash_profile을 생성한다.

vi ~/.bash_profile

2. 해당 파일에 환경변수 작성

export MY_NAME=Jinny
export JASYPT_PASSWORD=secret

3. 설정 적용

source ~/.bash_profile

4. 변수 적용 확인

echo $MY_NAME

• 잘 적용되었다면 아래와 같이 변수가 잘 출력되는 모습을 볼 수 있다.

3-2. Docker 배포 시 환경변수 활용

1. Dockerfile 작성

• 도커파일에 아래와 같이 변수를 작성하고 docker-compose 파일을 통해 주입받는다.

  # 생략...
  ENTRYPOINT ["java", "-jar", "-Djasypt.encryptor.password=${JASYPT_PASSWORD}", "/app.jar"]
  

**2. `docker-compose.yml` 작성** 
- `docker-compose` 파일 내의 변수는 `.bash_profile`의 변수로부터 전달 받는다.
- 즉 다음과 같이 전달되는 것이다.
    - `.bash_profile` 내의 변수 → `docker-compose` → `Dockerfile`

```shell
services:
  was:
    container_name: 
    image: 
    environment:
      - JASYPT_PASSWORD=${JASYPT_PASSWORD}

⚠️ 참고: 그런데 어쩔 때는 환경 변수가 잘 적용되고 어쩔 때는 적용이 안될 때가 있다. 구글링을 해보니 이런 글을 찾았다. 뭔가 도커 버그가 아닌가 싶다.

만약 도커를 사용하여 컨테이너 실행 시 환경변수를 사용하고싶다면 버전은 3.0.4를 필수로 사용해야한다. 3.0.3으로 한참을 시도했는데 안되다가 3.0.4버전 사용 시 잘 실행되었다. 출처: https://velog.io/@rnjsals1575/Jasypt%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%9C-%EB%AF%BC%EA%B0%90%EC%A0%95%EB%B3%B4-%EC%95%94%ED%98%B8%ED%99%94

🧞‍♂️ 소결

Jasypt를 사용하면서 느낀점은... 지금처럼 팀미션을 진행할 때 사용하는 것은 나쁘지 않은 것 같다.

하지만 암호화는 항상 뚤릴 위험이 있기 때문에 실제 실무에 들어가면 잘 사용하지 않을 것 같다. 내가 사장이면 안쓴다.!

그렇다면 또 무슨 방법이 있냐!!하면 Github의 submodule을 활용하는 것인데 아직 사용해보지 못해서 기회가 되면 블로그글을 작성해보겠다.

참고:

• 팀원 Ape, Albert의 지식 공유
• Jasypt 설정 관련
  • https://luvstudy.tistory.com/67
  • https://kitty-geno.tistory.com/160
  • https://yjkim97.tistory.com/64
• 배포 서버 환경 변수 설정 관련
  • https://bibi6666667.tistory.com/319

✅ 두번째 팀 프로젝트

첫번째 프로젝트가 끝나고 1주일간의 방학을 갖고 두번째 팀프로젝트가 시작되었다. 두번째 팀 프로젝트는 Todo App을 만드는 것이었다.

하기에 첨부한 이미지는 Todo App의 메인페이지인데 Todo App은 흔히 알고 있는 Trello 같은 칸반 보드 형태의 To do List를 관리하는 프로그램이다.

그리고 유저가 어떤 행동을 했는지 확인할 수 있는 사용자 활동 기록을 볼 수 있는 것이 Main Feature다.

보다 상세한 내용은 아래 깃허브 레포지토리에서 확인 가능하다.

Github: To do App 프로젝트

1. 🧐 회고

요번 글은 프로젝트 관련 고민 포인트에 대한 내용이 길어 회고는 간단하게 언급하고 넘어가려 한다.

1-1. 새로 공부한 내용

preflight

• CORS 에러가 발생하면서 preflight에 대해 공부했다.

JWT

• 로그인 기능을 구현하며 JWT에 대해 공부했다.
• 하지만 아직 JWT 시그니처 암호화는 잘 이해하고 있지 못하다.
• HS256 개념, 암복호화, 대칭키, 단방향/양방향 암호화에 대해 더 공부가 필요하다.
• 어떤 상황에 세션 기반 인증을 하고 어떤 상황에 토큰 기반 인증을 선택하는지 공부가 더 필요하다.

1-2. 새로 시도해 본 것

Redis

• 데이터/로그 캐싱을 위해 Redis를 처음 사용해봤다.

jayspt

• application.properties 파일 암호화를 위해 jayspt을 사용했다.
• CI/CD 사용 금지가 프로젝트 요구사항이어서 배포 스크립트만 작성했는데 스크립트에 복호화 암호를 쓰지 않고 복호화하는 것이 고민이었다. (스크립트를 깃허브에 올리거라 복호화 암호를 써놓으면 암호화 의미가 없기 때문)
• 방법을 찾지 못해서 서버에 미리 application.yml 파일을 만들어 놓고 jar 파일 돌릴 때 다음과 같이 option을 추가했다.

  --Dspring.config.location=~/app/application.yml

슬라이싱

• 조회 최적화 관련 고민을 하다가 팀원의 의견으로 활동 기록 조회 기능을 슬라이싱으로 구현해보았다.
• 위에 gif 보면 스크롤 할 때마다 살짝 끊기는 느낌인데 그때 api 요청을 보내서 n개씩 데이터를 받아오는 식이다.
• 자세히 쓰고 싶은데 캡쳐해둔 것이 없어서 살짝 언급하고 지나가겠다. 🥹

1-3. 아쉬운 점

요번 프로젝트는 공부해야 할 것도 많고 밑에 써놓은 고민포인트 논의 등으로 인해 시간이 엄청 엄청 부족해서 디테일을 많이 버려야 했다.

테스트 코드

• 테스트 코드 작성을 아예 못했다.
• JWT 테스트를 하려면 header에 유효한 토큰을 넣어줘야 API가 정상 작동 할텐데 어떻게 테스트해야 할지 고민해보지 못했다.

보안 관련 고민

• 회원가입 시 비밀번호 암호화 등 보안 관련된 것은 아예 고민도 못 했다.

미구현 기능

• JWT의 꽃은 로그아웃 기능이라고 느꼈는데 로그인 기능만 구현하고 로그아웃 기능은 구현 못했다.
• 로그인을 여러번 하면서 토큰을 재발급 받으면 이전 토큰을 계속 사용할 수 있는 점이 문제가 없을까?에 대한 고민이 있었는데 깊게 생각하지 못했다.

1.4 프론트와 협업

두번의 팀프로젝트를 하면서 프론트(리액트)에 대해 협업 관련 이해도가 조금 생긴 것 같다.

리액트 build 결과는 정적 파일이다?(feat. S3 배포) (잘못 이해한 부분이 있다면 댓글로 알려주세용 🥲)

• 첫번째 프로젝트 때 프론트 서버를 어떻게 배포해야 할지 이런저런 고민을 하다가 EC2에 배포를 했다.
• 프론트 서버 배포를 하면서 build한 파일이 main.ts인가 main.html인가 파일이 꼴랑? 하나 생겼던 것으로 기억한다.
• 이때 프론트분들한테 질문을 했었는데 리액트의 특징이 화면이 새로 고침 되지 않고(새로운 url로 가서 화면을 새로 랜더링하는 것이 아니라) 현재 페이지에서 다른 페이지로 렌더링을 다시 해주는 방식이라고 알게되었다.
• 그래서 요번에는 AWS S3의 정적 웹 호스팅 기능을 이용해 프론트 서버를 배포해보았다. (이해도가 없었으면 리액트가 왜 S3로 배포가 가능한지 이해하지 못했을 것 같다.)

컴포넌트는 상태 값을 갖고 있다.

• 프론트에서 어떤 값을 들고 있고, 어떤 데이터를 보내줘야 하는지에 대한 감이 조..금 생긴 것 같다.

+) 해결하지 못한 이슈가 마음에 걸려 팀원인 Ape랑 프로젝트 끝나고 에러를 해결했다. 고쳐졌는지 확인하기 위해 프론트 코드를 하나씩 떼다가 퍼즐 조각을 맞춰 api 정상 응답을 확인했는데, 요 과정도 프론트에 대한 이해도를 높여준 것 같다.

2. 🤯 고민 포인트

프론트엔트, 백엔드 가릴 것 없이 요번 프로젝트의 최대 난제는 카드를 동일 컬럼 안에서 위 아래로 움직이는 기능과 다른 컬럼 간 이동하는 기능이었다.

이 이슈 하나로 고려해야 할 것이 굉장히 많았다. 우리 팀의 주된 고민은 다음 두가지였다.

1. 카드 이동 로직을 어떻게 구현할 것인가?
2. 카드 CRUD + 카드 이동 시 DB 접근이 빈번하게 일어나는데 어떻게 DB 접근 횟수를 줄일 수 있을까?

2-1. 카드 이동 로직

** ① Linked List 방식**

맨 처음에 나왔던 의견은 Linked List처럼 각 카드가 앞뒤 카드 id를 갖고 있고, 이동 시 Linked List 처럼 앞뒤 카드 id를 변경해주는 것이다.

해당 방법은 밑에 이유로 탈락했다. (+ 효율적이지도 않은데 2번 3번 방식에 비해 드는 시간과 짜야하는 코드량이 몇배일 것으로 예상되었다.)

🤔 우려되는 점:

• 정보 업데이트 시에는 소수 데이터만 변경하면 되지만, 메인 페이지에서 전체를 조회하게 되면 정렬을 해야 한다.
• 그럼 카드 이동 시마다 매번 DB에서 데이터를 꺼내온 다음, 전체 카드 정보를 탐색해서 전체 정렬을 해줘야 하는데, 효율적이지 않다.
  • 만약 유저가 계~속 카드를 이동한다면?
  • 카드 수가 많~이 늘어난다면?

** ② 클라이언트에서 전체 정보 전달**

카드가 이동되면 각 카드의 id와 순서 정보를 통으로 서버에 전달해주면 DB에 해당 user의 전체 카드 순서 정보를 전부 업데이트하는 방법이다.

제일 원시적이지만 제일 간단한 방법이다.

하지만 해당 방법도 우려되는 점이 있었다.

🤔 우려되는 점:

• 카드 이동 시, 카드 개수만큼 DB를 업데이트 해야 한다.
• 이동 요청이 엄청 많다면?
• 카드 개수가 엄청 많다면?
• 회원이 엄청 많다면?

** ③ Positioning 방식** (정확히 어떤 방식으로 불리는지 모르겠으나 팀내에서 포지셔닝으로 불렀다.)

밑에 그림을 참고해보면 카드는 일정 간격의 가중치를 갖고 있고, 이동 시마다 위, 아래 카드의 평균값을 갖게 된다.

이렇게 되면 카드 이동 시 위아래 카드 가중치 값 조회를 위한 2개 데이터의 SELECT과, 이동할 카드의 포지션 값 변경을 위한 1개 데이터의 UPDATE만 하면 된다.

출처: 팀원 Ape가 그린 그림

이때 우려했던 점은 값이 점점 줄어 들다가 어느 시점이 되면 순서에 따른 값이 맞지 않는 순간이 올텐데 "이 순간"을 어떻게 체크하냐가 관건이었다.

여러 논의 끝에 카드 이동 시마다, 위의 카드의 가중치를 조회해서 1차이가 나면 전체 데이터의 간격을 1000으로 다시 조정하기로 했다.

이때 해당 컬럼의 카드 전체가 업데이트 되지만, 어쩌다 한번 발생하는 것이고 분할 상환 분석 이런 개념으로 보면 괜찮다는 생각이 들었다.

(개인적으로 수학을 못해서 가중치가 잘못되는 또다른 경우의 수가 있을 것 같아서 아직까지 조금 찝찝한 면은 있다.)

+) 카드 이동 로직 고민 시 참고했던 블로그

2-2. DB 접근 횟수를 어떻게 줄일 것인가?

카드 이동 로직과 제일 많이 고민하고 논의했던 부분은 "DB 접근 횟수를 어떻게 줄일 수 있는가?"였다.

카드 CRUD 와 카드 이동이 발생할 때마다 DB에 접근하고, 또 모든 액션이 발생할 때마다 사용자 활동 기록을 보여주기 위해 로그를 DB에 쌓아야 했다.

로컬 스토리지에 데이터를 일정 시간 저장 후 서버에 요청하는 등 다양한 방식을 고려했으나 결론적으로는 write back 방식의 Redis를 사용해서 데이터를 캐싱하기로 했다. (JWT 토큰을 이용한 로그인 기능이 요구사항에 있어서, TTL을 설정해 Refresh token과 만료된 Access Token을 저장/처리하기 위함도 있었다.)

...라는 원대한 꿈을 꾸었지만 결론적으로 서버 배포 한번 해보고 Redis 관련 코드를 모두 들어냈다.

이유는 카드 이동 로직 관련 논의에 시간을 많이 쏟기도 했고, JWT도 새로 공부해서 구현해야 했는데 Redis에 대한 이해도 부족과 공부할 시간 부족으로 낯선 에러를 처리할 수가 없었다... 🥲

나중에 참고차 에러 메시지를 적어두려 한다.

에러메시지 1

• left pop을 할 때 데이터가 없으면 발생하는 것으로 추측된다.
• 그런데 Redis 데이터를 확인했을 때 데이터가 들어있었다.

  Error in execution; 
  nested exception is io.lettuce.core.RedisCommandExecutionException: 
  ERR wrong number of arguments for 'lpop' command

에러메시지 2

• 구글링해보면 @scheduled 어노테이션이랑 @transactional 어노테이션이랑 같은 클래스에서 사용하면 나타나는 에러라고 한다.
• 확인차 어노테이션 하나를 제거했는데도 동일한 에러가 발생했다.
• 그리고 두 어노테이션을 같이 쓰면 안되는 이유에 대해서도 공부해봐야 할 것 같다.

Unexpected error occurred in scheduled task

Redis는 다음에 다시 시도해 보는 것으로!!

3. 🔥 Trouble Shooting

요번 프로젝트를 진행하면서 Trouble Shooting한 내용은 블로그에 별도로 정리해놓았다.

3-1. CORS

• 로그인 filter 기능 구현 후 CORS 설정이 먹히지 않다가 이런저런 설정을 하면서 해결이 되긴 했는데 원인을 정확히 모르겠다.
• Spring이랑 Http 흐름에 대해 공부를 더 해봐야 할 것 같다.

[Spring] filter 기능 구현 후 CORS 에러가 발생하는 이슈

3-2. JWT

• JWT 토큰 파싱하면서 오류가 있어서 삽질을 반나절했는데 대단한(?) 원인은 아니었다.
• 개발자는 눈을 크게 떠야 한다.

[JWT] SignatureException 에러

3-3. S3

• S3 정적 호스팅을 기능을 처음 경험해봤는데, 새로운 기능을 알게되어서 좋았다.

[AWS] S3 정적 호스팅 페이지 새로고침 시 404 NoSuchKey 에러가 발생하는 이슈

4. 🧹 세 줄 정리

• 투두앱 쉽게 보다가 카드 이동에 큰코 다쳤다.
• 구현 못한 기능과 디테일을 챙기지 못한 점이 아쉽다.
• 블로그 글을 쓰면서 원인을 모르겠는 것들이 많아 공부가 필요하다고 적어놓은 것이 많다. 공부를 한다고 하지만 기술 부채가 쌓이고 있어서 반성해야겠다.

• 팀 프로젝트를 진행하며 Spring Filter를 사용하여 로그인 기능 구현
• CORS는 Configuration으로 설정

보다 상세한 코드는 Gihub에서 확인 가능하다.

Configuration 코드

• 모든 url, origin, method를 해용해준 상태

  @Configuration  
  public class WebConfig implements WebMvcConfigurer {  
  
    @Override  
    public void addCorsMappings(CorsRegistry registry) {  
        registry.addMapping("/**")  
         .allowedOrigins("*")  
         .allowedMethods("*")  
         .maxAge(3000);  
    }  
  }

Filter 코드

public class JwtAuthorizationFilter implements Filter {

    // 생략

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

        HttpServletRequest httpServletRequest = (HttpServletRequest) request;

        // api의 화이트리스트 여부 체크
        if(whiteListCheck(httpServletRequest.getRequestURI())){
            chain.doFilter(request, response);
            return;
        }

        // request header에 토큰 포함 여부 체크
        if(!isContainToken(httpServletRequest)){
            sendErrorApiResponse(response, new MalformedJwtException(""));
            return;
        }

        // 필터 로직 진행
        try {
            String token = getToken(httpServletRequest);
            Claims claims = jwtProvider.getClaims(token);
            request.setAttribute("memberId", claims.get("memberId"));
            chain.doFilter(request, response);
        } catch (RuntimeException e) {
            sendErrorApiResponse(response, e);
        }
    }
}

단계 별로 에러가 발생해서 단계별 Trouble Shooting 과정을 정리했다.

1) 첫 화면인 login 페이지는 CORS 에러가 발생하지 않지만 로그인 완료 이후 CORS 에러 발생

상황

• POST 요청인 login은 CORS 에러가 발생하지 않는데, 로그인 완료 후 GET요청으로 메인 페이지(api/columns)로 리다이렉트되면서 CORS 에러 발생

에러 메시지

Access to fetch at 'http://localhost:8080/api/columns' 
from origin 'http://localhost:5173' has been blocked by CORS policy: 
Response to preflight request doesn't pass access control check: 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

### 의문
- CORS 에러가 날 거면 다 같이 나지 왜 따로 따로 나는가?
- 왜 `preflight` 요청은 `CORS` 에러가 안 뜨고 본요청만 `CORS` 에러가 발생하는가?

### 시도한 해결 방법
- 팀 프로젝트를 시작하기 전에 WAS 미션을 진행하며 `Spring` 구조에 대해 공부하면서 봤던 구조가 생각났다.
> ![](https://i.imgur.com/kMX17WR.png)
출처: https://ee-22-joo.tistory.com/20
- `Filter`가 `Dispatcher Servlet` 실행되기 전에 먼저 실행되니까 `WebMvcConfigurer`의 설정이 적용이 안되는 것 같다는 생각이 들었다.
  ~~- 근데 왜 login 페이지 진입은 되는 것인지? 이해할 수가 없네...(답답)~~
- 무튼 그래서 "`Login Filter` 이전에 `CORS Filter`를 넣어주면 되지 않을까?"라는 생각이 들어 `WebConfig`를 삭제하고 `CORS Filter`를 추가했다.

**`FilterConfig` 코드**
```java
@Configuration  
public class FilterConfig {  

    // 추가한 필터
    @Bean  
    public FilterRegistrationBean corsFilter() {  
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();  
        filterRegistrationBean.setFilter(new CorsFilter());  
        filterRegistrationBean.setOrder(1);  // 첫번째 순서로 넣어주기
        return filterRegistrationBean;  
    }  

    // 기존 필터
    @Bean  
    public FilterRegistrationBean jwtAuthorizationFilter(ObjectMapper mapper) {  
        FilterRegistrationBean<Filter> filterRegistrationBean = new  
                FilterRegistrationBean<>();  
        filterRegistrationBean.setFilter(new JwtAuthorizationFilter(mapper));  
        filterRegistrationBean.setOrder(2);  // 순서 1에서 2로 변경
        return filterRegistrationBean;  
    }  

}

CorsFilter 코드

public class CorsFilter implements Filter {  

    @Override  
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)  
            throws IOException, ServletException, IOException {  
        HttpServletResponse response = (HttpServletResponse) res;  
        response.setHeader("Access-Control-Allow-Origin", "*");  
        response.setHeader("Access-Control-Allow-Methods", "POST, OPTIONS, GET, DELETE, PUT");  
        response.setHeader("Access-Control-Max-Age", "3600");  
        response.setHeader("Access-Control-Allow-Headers", "Authorization, x-requested-with, origin, content-type, accept");  
        chain.doFilter(req, res);  
    }  

}

2) CORS Filter → Login Filter 설정 이후에도 동일한 에러 발생

상황

• 1)번 상황이랑 동일

api 요청할 때 preflight 요청이 계속 발생하여 preflight에 대해 공부하고 다시 Trouble Shooting 시작

원인(추측)

• preflight 요청은 header에 authorization 헤더가 없어서 인증을 하지 못해 401 에러가 발생하고, 이로 인해 본 요청에서 무슨 오류가 생긴게 아닐까 생각했다.

의문

• preflight 요청이 401이 발생했다는 것은 CORS는 통과한 것으로 이해된다.
  • 로그를 찍었을 때 Login Filter까지 들어온 것을 확인했기 때문이다.
• 그러면 본요청도 CORS 에러가 나지 않아야 하는 것이 정상이 아닌가?
  • 본요청은 request 메시지를 파싱하는 순서가 다른가?
  • 예를 들면 header를 파싱하는 과정에서 allow-origin header를 authorization header 보다 늦게 파싱해서? (설마.. 브라우저가 얼마나 똑똑한데...)

시도한 해결 방법

• OPTIONS로 preflight 요청이 올 경우 필터 통과하는 코드 추가

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

            HttpServletRequest httpServletRequest = (HttpServletRequest) request;

        // OPTIONS로 api 요청 시 필터 통과
        if (httpServletRequest.getMethod().equals("OPTIONS")) {   
            return;
        }

        // 이하 코드 생략...

            // api의 화이트리스트 여부 체크

            // request header에 토큰 포함 여부 체크

             // 필터 로직 진행
        }

결과

• 여기까지 하고나니 CORS 에러는 없어졌지만 매우 찝찝하다.
• 왜냐면 이게 왜 "돼"? 하는 상황이기 때문이다.
• 과정을 상세히 기록하고 Spring과 http 요청 흐름에 대한 지식을 더 쌓고 의문을 해결해야겠다.

💡 참고:

• 401 에러가 난 부분은 JWT 인증 관련 에러인데 해당 에러에 대한 Trouble Shooting 과정은 블로그 글 → [JWT] SignatureException 에러에서 확인 가능하다.

글을 작성하다가 문득 팀원이 공유해주신 블로그 글을 다시 보면서 Filter를 Bean으로 설정하면 Spring에서 Filter를 관리해주니까 CorsFilter를 구현하지 않고 처음 설정했던 WebMvcConfigure를 설정해주면 먹히지 않을까라는 생각이 갑자기 들었다.

지금은 팀프로젝트가 끝나 서버도 내려가고 당장 쌓인일이 많아서 3일 뒤 새로 시작하는 팀프로젝트 때 꼭 확인해봐야겠다.

• 참고:
  • https://velog.io/@gillog/Spring-CORS-preFlightOPTIONS-Method-Interceptor-%EA%B2%80%EC%A6%9D-%EB%A1%9C%EC%A7%81-%EC%A0%9C%EC%99%B8%ED%95%B4%EC%A3%BC%EA%B8%B0Access-to-XMLHttpRequest-at-https-from-origin-https-has-been-blocked-by-CORS-policy-Response-to-preflight-request-doesnt-pass-access-control-check-It-does-not-have-HTTP-ok-status
  • https://wonit.tistory.com/572
  • https://junhokims.tistory.com/29

상황

• 팀 프로젝트를 진행하며 JWT로 로그인 기능 구현
• 클라이언트에서 서버로 API 요청 시 SignatureException 에러 발생

에러 메시지

io.jsonwebtoken.security.SignatureException: 
JWT signature does not match locally computed signature. 
JWT validity cannot be asserted and should not be trusted.

원인

• JWT 파싱 오류
• 클라이언트에서 JSON.Stringfy()로 토큰을 감싸서 전송
• 헤더에 담긴 토큰을 잘 보면 ""로 감싸져 있다.

해결

• JSON.Stringfy() 코드 제거

처음에 JWT 토큰 발행 시 넣었던 Signature와 Claim 파싱할 때 넣은 토큰의 암호화를 잘못했나 생각이 들어 온갖 삽질을 했던 것은 안비밀

트러블 슈팅하면서 계속 봤는데 따옴표가 자연스러웠다...

머리가 혼탁해지면 잠깐 쉬다오고 눈을 크게 뜨고 보자,,,

상황

• 팀 프로젝트를 진행하면서 리액트 서버는 S3, API 서버는 EC2로 배포 진행
• 로그인 이후 진입한 페이지에서 새로 고침하면 404 NoSuchKey 에러 발생

원인

• S3 도메인은 index.html 과 매핑되어 있음
• 로그인 이후 진입한 페이지 url은 http://{도메인}/main 과 매핑
• http://{도메인}/main 과 매핑된 리소스가 없기 때문에 에러 발생

🤔 그렇다면 왜 로그인 이후 에러가 발생하지 않았을까?

• React는 페이지 이동 시 새로운 url로 이동 후 화면을 새로 고침하는 것이 아닌 현재 페이지에서 렌더링을 재진행하는 방식
• 따라서 http://{도메인}/에서 로그인 이후 http://{도메인}/main으로 이동할 때 실제로 url이 리다이렉트된 것이 아니라 http://{도메인}/에 원래 매핑되어 있던 index.html 파일에서 화면만 다시 랜더링되어서 에러가 발생하지 않은 것으로 추측됨

해결

• AWS S3에서 S3에서 발생한 에러를 특정 리소스와 매핑할 수 있는 기능 제공
• 에러 페이지도 index.html로 지정하여 새로고침 해서 에러가 발생하면 index.html로 연결되게 설정

• 참고:
  • https://github.com/bluelion2/Project-issue-repo/issues/22
  • 팀원 Ape의 지식

이번 회고를 하기 전에... 10주차 ~ 15주차 회고가 없는데 약 한달 간 자율 학습에 가까운 시간을 가지면서 회고보단 급한 기술 부채를 쳐냈다. 또 블로그보단 옵시디언에 공부한 내용을 많이 기록하면서 블로깅 습관을 잃어버린 것 같다. 다시 열심히 회고를 해보려고 한다! 💪

👥 첫번째 팀 프로젝트

드디어 부트캠프의 꽃(?) 팀 프로젝트가 시작되었다. 팀 프로젝트는 카페 키오스크를 구현하는 것이었는데 첫 번째 프로젝트이고 2주간의 미션이라 그런지 엄청 어려운 요구사항은 없었다.

자세한 내용은 아래 깃허브 레포지토리에서 확인 가능하다.

Github: 카페 키오스크 프로젝트

총평을 해보자면 프론트와의 협업이 처음이라 초반에는 헤맸지만 이런저런 시행착오를 겪으면서 개선방향에 대해 생각해볼 수 있었다.

필자는 인프라랑 일부 API 개발을 담당했는데 이번 회고는 프로젝트를 진행하면서 겪었던 이슈와 Trouble Shooting 내용 위주가 될 것 같다.

조금 큰 이슈들은 위에 적어둔 레포지토리의 Wiki에 정리해두어서 Wiki에 없는 보다 자잘한 이슈들 위주로 회고할 예정이다.

1. 🛠️ 인프라

우선 인프라 구조는 이렇게 잡았다. 아직 인프라를 많이 접해보지 못했고, 각각의 장단점을 모르기 때문에 구글링해보았을 때 현재 내 지식수준에서 이해가 가능하고 적용할 수 있는 구조를 택했다.

• • •

1) 프론트 배포의 시행착오

처음엔 잘 몰라서 백엔드만 배포하면 될줄 알고 있어서, 프론트엔드 분들이 firebase로 배포를 해주셨는데 두가지 문제가 있었다.

** 1. CORS 문제**

• 프론트는 firebase로 배포하고, 백엔드는 AWS EC2로 배포했기 때문에 당연히(?)도 CORS 문제가 발생했다. (지금 생각해보면 당연한데 그때만 해도 엄청난 에러였다. 🥲)

• 구글링을 해보니 스프링으로 설정 가능한 부분이어서 코드를 추가해보니 API 요청과 응답은 문제가 없는 듯 했다.

• 다만 이부분은 당시에 *로 모든 외부 IP에 대해 허용을 했었는데, 만약 나중에 또 이런 상황이 있다면 보안 문제로 인해 특정 도메인 혹은 IP에만 허용하도록 해야겠다고 생각했다.

** 2. https 통신 문제 **

• firebase로 배포하면 프론트는 https로 배포가 되는데 백엔드는 도메인이 없기 때문에 http였다.

• 찾아보니까 https에서 http로의 API 요청은 브라우저에서 차단한다.

• 크롬의 경우, 브라우저 설정을 통해 차단을 풀 수는 있지만 보안 경고가 계속 뜬다.

• 이를 해결하려면 SSL 인증서가 필요한데, SSL 인증서를 발급받으려면 도메인이 필요하기 때문에 불가능했다.

• 백엔드에서 프론트엔드 배포도 같이 하는 것이 좋을 것 같아서 백엔드에서 모든 배포를 하기로 했다.

• • •

2) 프론트엔드 배포

처음에는 프론트엔드 배포를 한다는 것이 막막했다. 당시 월말이라 AWS 프리티어 사용량이 거의 남지 않아서 EC2 하나밖에 사용할 수 없는 상황이었다.

지금 생각해보면 바보같을 수도 있는데, 은연중에 EC2 하나당 서버 하나만 돌릴 수 있다고 생각했던 것 같다.

그리고 또 당시(라고 해봤자 2주전...이지만 배포하면서 포트에 대한 이해도가 갑자기 높아졌다.) 포트에 대한 개념이 부족해서 같은 서버에 넣는다고 해도 어떻게 통신하지? 했던 의문이 있었다.

서버 하나에 프론트 서버 백엔드 서버 배포하기

무튼 일단 t2.micro인 EC2에 서버 2개를 돌려보고 부딪히면서 이슈를 해결해야겠다고 생각했다.

프론트엔드 분 도움을 받아 리액트 서버를 돌리기 위한 3가지 명령어를 배우고 서버에 띄어봤다.

npm install
npm run build
npm start

물론 이 사이에 이런저런 이슈들이 많았다... 리액트를 처음 빌드하다보니, package.json 을 지워버리기도 하고 node module 폴더가 없어서 서버가 안 돌아간다던지...ㅎ

근데 API 요청할 때 서버에서 응답을 못하고 있었다.

이유를 못찾고 있었는데 NGINX가 궁금해서 새벽에 혼자 사용법 찾아보면서 이런저런 설정을 해보다가 API 요청 URL의 Proxy_Pass를 xxx.xxx.xx.xx:8080 이런식으로 설정해줬는데 갑자기 잘 되는 것이었다.!!

그렇다 원인은 리액트에서 API 요청할 때 포트 번호가 없었던 것이었다...

(그런데 firebase에서 배포했을 때는 어떻게 정상적으로 응답이 된거지..?)

이슈 해결하고 또 문득 들었던 생각이 Elastic IP를 사용하지 않아서 IP가 매번 바뀌고 리액트랑 스프링이랑 같은 서버 안에 있으니까 굳이 IP를 적지 않고 localhost:8080으로 보내면 요청이 받아질 것이라고 생각이 들었는데 왜인지 실패했다..

이건 이유를 차차 알아봐야겠다.

2. 🧑🏻‍💻 API 개발

팀원분이 개발한 API에서 엔티티나 DTO를 사용해야 하는데 @Getter가 없었어서 값을 못 불러오는 등 자잘한 이슈를 제외하면 큰 에러도 없었고 API 개발은 생각보다 무난했던 것 같다.

언급할만 이슈는 기획서 변경과 @Scheduled 어노테이션 관련 이슈가 있다.

• • •

1) 기획서 변경

기능 요구사항 중 "실시간 판매량을 집계하여 BEST 메뉴를 선정하여 카테고리 상단에 노출"하는 요구사항이 있었다.

팀원들이랑 여러방면으로 논의를 했었는데, 카페에서 실시간 판매량을 집계하여 노출하는 것의 목적과 의미가 서버 부하 대비 없는 것 같았다.

실시간 판매 노출 대상은 고객이고, 베스트 메뉴는 고객의 의사결정을 돕는 것이다. 특정 메뉴를 의도적으로 노출해 판매량을 늘리는게 아니라 실제 판매량을 집계하여 노출하는 것이라면 굳이 고객 구매 1회당 서버에 요청을 보내 BEST 메뉴를 계속 갱신하는 것과 전날의 합산 통계를 노출하는 것의 큰 차이는 없다고 판단이 들었다.

실제 상황에서도 기획서를 무조건 따르는게 아니라 논의를 통해 더 나은 방향으로 나아가는 것이 맞다고 생각이 들어 요구사항을 "전날 판매 기준으로 집계"로 변경하였다.

• • •

2) @Scheduled 어노테이션 관련 이슈

전날 판매량 기준으로 집계하는 것을 매일 수동으로 할 수는 없으니 매일 00시에 자동으로 DB가 갱신되도록 하는 방법을 찾아야했다.

우리 팀이 찾은 방법으로는 다음과 같았다.

• trigger
• procedure
• @Scheduled 어노테이션 활용

이전에 호눅스 수업에서 procedure는 레거시 프로젝트에 많이 남아 있다고 했다. 요새는 DB의 책임과 어플리케이션의 책임을 분리한다고 들었던 기억이 있었다.

필자는 자동 집계는 DB의 책임이 아니고 비즈니스 로직이라고 생각이 들었고 비즈니스 로직은 어플리케이션 단에서 책임지는 것이 맞다고 생각이 들었다.

무튼 다음과 같이 코드를 짰는데, 자동 집계가 안되는 이슈가 있었다.

@Repository
public class JdbcOrdersRepositoryImpl implements OrdersRepository {

    private static int today;
    private static Long orderNumber = 0L; // 주문 번호는 매일 0으로 초기화되어야 한다.

    static {
        dailyReset(); // 날짜가 바뀌었는지 확인하고 주문번호를 0으로 리셋한다.
        setToday();   // 날짜가 바뀌었는지 확인할 수 있도록 오늘 날짜를 바꿔준다.
    }

    @Scheduled(cron = "0 0 0 * * *", zone = "Asia/Seoul")
    public static void setToday() {
        today = ZonedDateTime.now().toLocalDate().getDayOfMonth();
    }

    @Scheduled(cron = "0 0 0 * * *", zone = "Asia/Seoul")
    public static void dailyReset() {
        LocalDate current = ZonedDateTime.now().toLocalDate();
        if (current.getDayOfMonth() - today >= 1) {
            orderNumber = 0L;
        }
    }

알고보니 @Scheduled 어노테이션을 작동시키기 위해서는 @EnableScheduling을 스프링 부트 실행파일에 선언해야 했다.

다음과 같이 @EnableScheduling을 선언해주면 스케줄러가 잘 작동한다.

@SpringBootApplication
@EnableScheduling
public class KioskWebApplication {

    public static void main(String[] args) {
        SpringApplication.run(KioskWebApplication.class, args);
    }
}

3. 🤔 개선해보고 싶은 것과 고민들

프로젝트를 진행하면서 개선해보고 싶은 것과 고민들이 있었는데 기록해놓고 차차 해결하고자 한다.

• • •

1) 백엔드 팀원 간 협업 관련

백엔드 팀원이 4명이었고 요구사항이 작아 API 개발을 잘게 쪼개다보니 Class를 최대한 겹치지 않게 짰는데도 어쩔 수 없이 개발하면서 팀원 간 코드 의존성이 생겼다.

이러면서 Git 충돌이 났었는데, 충돌이 안나게 협업을 어떻게 하면 좋을지 고민이었다. 지금 당장 생각나는건 인터페이스를 만들고 인터페이스 기반으로 작업하는 것이다.

• • •

2) 시간 관련 테스트

@Scheduled 어노테이션이 잘 작동하는지 확인하기 위해서 테스트 코드를 짜는데 어려움이 있었다. 시간을 의도적으로 조작해야 했는데, 방법을 잘 모르겠어서 리플렉션을 사용했는데 맞지 않는 방법인 것 같았다.

     @Test
    @DisplayName("자정이 되면 주문번호가 0으로 초기화됩니다.")
    public void dailyReset() throws NoSuchFieldException, IllegalAccessException {

        // given
        Field today = ordersRepository.getClass().getDeclaredField("today");
        today.setAccessible(true);
        today.set(ordersRepository, yesterday.getDayOfMonth());

       // 생략...
    }

• • •

3) 이미지 요청 관련

현재 구현된 바로는 키오스크에서 표시되는 음료 이미지가 AWS S3에 저장되어 있고 키오스크에서 주문이 완료되고 메인 페이지로 돌아갈 때마다 서버로 GET 요청을 보내서 이미지를 불러온다.

개인적으로 매번 이렇게 불러오는게 매우 비효율적이라고 생각이 들었다. 키오스크가 한번 부팅될 때 최초 1회 이미지를 다 불러와서 이후에는 서버 요청 없이 이미지를 사용하는 것이 좋다고 생각이 들었다.

그리고 여러 페이지에 동일한 이미지가 다양한 사이즈로 표시되는데 한 개의 이미지로 프론트에서 사이즈 조절하는 것보다 뭔가 다른 좋은 방법이 없을까 고민이 되었다.

이 두 고민은 꼭 해결해서 다음 혹은 다다음 프로젝트에 적용해보고 싶다.

• • •

4) join 여러 개 vs select 여러 번

예를 들면 Entity ABC가 있는데 필드 A는 table A, B는 table B, C는 table C에 있다고 하면

join을 여러 번 해서 한번에 Entity를 만드는게 좋을까? 아님 select 절로 여러번 쿼리를 날려서 조합을 해 Entity를 만드는게 좋을까?

join을 몇번 하느냐, 테이블에 데이터 양이 얼마나 많은가에 따라 달라지겠지만 아직 잘 모르겠다.

• • •

5) Explain으로 쿼리 성능 개선해보기

다음 프로젝트 때 꼭 시도해볼 것!

상황

• Githun Actions 테스트 하면서 gradlew permission denied 이슈 발생

원인

• 협업 시 Springboot 세팅을 해주신 팀원분의 개발환경이 Window였다.
• Window 환경에서 작업해서 소스를 push하면 파일 생성 시 기본 권한이 644로 생성된다.
• 644는 루트 사용자, 일반 사용자, 그룹 모두 실행 권한이 없기 때문에 권한을 추가해줘야 한다.

해결

• +x 옵션 또는 755 권한으로 실행 권한을 추가해주자.

  chmod +x ./gradlew

• 혹은 git 명령어를 통해 권한을 변경할 수 있다.

  git update-index --add --chmod=+x gradlew

💡참고: 아래 명령어를 사용하면 git 인덱스에 잡혀있는 파일의 권한을 확인할 수 있다.

git ls-tree HEAD

• 참고:
  • https://may9noy.tistory.com/160

Web이란?

• 클라이언트와 서버가 인터넷을 통해 정보를 상호작용(정보 공유, 검색 등)을 할 수 있게 하는 서비스
• 웹의 3요소:
  • HTML(응답)
  • HTTP(통신 방법)
  • URL(요청하는 주소)

Web의 구조, 동작 원리

💡 잠깐! 먼저 생각해보면 좋은 것(면접 단골 질문): 웹 브라우저에 www.google.com 을 입력하면 무슨 일이 일어날까?

1. 클라이언트가 브라우저 입력창에 http://www.google.com 을 입력한다.
2. DNS 서버에서 IP 주소를 확인한다.
   • 클라이언트의 컴퓨터에 있는 로컬 DNS 캐시라는 임시 저장소의 캐시를 확인하여 해당 도메인 이름에 대한 IP 주소가 이미 저장되어 있는지 확인
   • 로컬 DNS 캐시에 도메인 이름에 대한 IP 주소가 없는 경우, 클라이언트는 DNS 서버에 질의 전송. (이때, 미리 설정된 기본 DNS 서버의 IP 주소를 사용)
   • 해당 DNS 서버에도 없을 경우, 다른 DNS 서버로 전송
3. 클라이언트(브라우저)가 서버에 Request Message를 전송한다.
4. 서버는 적절한 내용을 담아 Response Message를 전송한다.
5. 브라우저는 응답을 렌더링해서 사용자에게 보여준다.

여기서 Web Server와 WAS는 3번~4번 사이의 과정에 있다.

1. Web Server와 WAS

1) Web Server

• HTTP 기반으로 동작, 정적 리소스 제공
• 클라이언트로부터 HTTP 요청을 받아 HTML 문서나 각종 리소스를 전달하는 서버
• 동적인 요청이 들어왔을 때, 컨테이너로 보내주는 역할
• 예: NGINX, APACHE

💡 정적 리소스:

• HTML, CSS, JS, 이미지, 영상 등
• 요청 인자 값에 상관없이 달라지지 않는 컨텐츠
• 어느 사용자 요청이든 항상 동일한 컨텐츠

Web Server의 기능을 정리해보면 다음과 같다.

• 클라이언트로부터 HTTP 요청을 받을 수 있다.
• 정적 컨텐츠 요청 시 정적 컨텐츠를 제공할 수 있다.
• 동적 컨텐츠 요청시 WAS로 전달하여 WAS가 처리한 결과를 클라이언트에 전달할 수 있다.

2) Web Container

• 컨테이너는 동적인 데이터들을 처리하여 정적인 페이지로 생성해주는 소프트웨어 모듈
  • 예: 톰캣, Jetty 등
• 웹 컨테이너 중 Servlet을 관리할 수 있는 컨테이너를 Servlet Container라고 한다.
  • 예: 톰캣

3) Web Application Server

• HTTP 기반으로 동작
• 웹 서버 기능 포함 - 정적 리소스 제공 가능
• 프로그램 코드를 실행해서 애플리케이션 로직 수행
  • 동적 HTML, HTTP API
  • 서블릿, JSP, 스프링 MVC
• 예: 톰캣

WAS의 기능을 정리해보면 다음과 같다.

• 클라이언트로부터 HTTP 요청을 받을 수 있다. (대부분의 WAS는 Web Server 내장)
• 요청에 맞는 정적 컨텐츠를 제공할 수 있다.
• DB 조회나 다양한 로직 처리를 통해 동적 컨텐츠를 제공할 수 있다.

Web Server?? WAS?? 비슷한데?

• 둘의 용어가 모호하긴 한다.
• 웹 서버도 프로그램을 실행하는 기능이 있는 경우도 있고 WAS도 웹 서버의 기능을 제공하기도 한다.

그래서 자바에서는 뭐가 WAS일까?? → 서블릿 컨테이너 기능을 제공하면 WAS라고 한다. (하지만... 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음)

💬 개인적인 생각: 자료를 찾아보면서 헷갈렸던 부분은 WAS의 scope였다. WAS는 Web Server와 Web Container로 구성되어 있다고 하는데 일반적으로 Web Server는 Web Server로, Web Container는 WAS라고 부르는 것 같다. 아니면 Web Server를 따로 두기 때문에 그런 것일까?

참고: 왜 톰캣을 아파치 톰캣이라고 부를까?

• 톰캣(WAS)은 편의를 위해 아파치의 기능(웹서비스 데몬, Httpd)을 포함하고 있다.
• 즉, 톰캣이 아파치의 일부 기능을 제공해주기 때문에 합쳐서 부른다.

2. 웹 시스템 구성

부제: WAS가 Web Server 기능도 제공하는데 왜 Web Server를 따로 둘까?

1) WAS, DB로만 구성

• WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능
• 따라서 WAS, DB만으로 시스템 구성이 가능하지만 다음과 같은 우려가 있음
  • WAS가 너무 많은 역할을 담당, 서버 과부하 우려
  • 정적 리소스 서빙 때문에 비싼 어플리케이션 로직 수행이 어려울 수 있음
  • WAS 장애 시, 오류 화면 노출이 불가능

2) WEB, WAS, DB로 구성

• 웹 서버:
  • 정적 리소스 처리
  • 동적인 처리 필요 시, WAS에 요청 위임
• WAS:
  • 어플리케이션 처리 전담

WAS가 Web Server 기능도 제공하는데 왜 Web Server를 따로 둘까?

Web Server를 따로 둘 때 다음과 같은 장점이 있다.

장점

• 책임 분할을 통해 서버 부하를 방지할 수 있다.

  • WAS는 DB 조회 등 페이지를 만들기 위한 다양한 로직을 처리하는데, 단순한 정적 콘텐츠를 WAS에서 제공한다면 다른 작업에 사용하는 리소스들로 인해 지연이 생겨날 수 있다.
  • 정적 컨텐츠는 Web Server, 동적 컨텐츠는 WAS가 담당하여 서버 부하를 방지한다.

• 효율적인 리소스 관리가 가능하다.

  • 정적 리소스가 많이 사용되면 Web 서버 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS 증설

    

• 장애 대응이 가능하다.

  • 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음
  • 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음
  • WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

    

• 여러 대의 WAS 로드밸런싱

  • WAS가 처리해야 하는 요청을 여러 WAS가 나누어서 처리할 수 있도록 설정
  • 대용량 웹 어플리케이션의 경우, Web Server와 WAS를 분리하여 무중단 운영을 위한 장배 극복에 쉽게 대응할 수 있다.

• 여러 대의 WAS Health Check

  💡 Health Check란? Health Check: 서버에 주기적으로 HTTP 요청을 보내 서버의 상태를 확인

• (물리적으로 분리하여) 보안 강화

  • 리버스 프록시를 통해 실제 서버를 외부에 노출하지 않을 수 있다.
  • SSL에 대한 암복호화 처리에 Web Server를 사용한다.
  • 공격에 대해 Web Server를 앞단에 두어 중요한 정보가 담긴 DB나 로직까지 (WAS까지) 전파되지 못하게 한다.

그래서 일반적으로 Web Server, WAS, DB로 웹 시스템을 구성한다.

💡 참고: By 토비 단지 정적 리소스 처리의 성능만을 위해서라면 굳이 톰캣 앞에 Apache Httpd를 두는 것은 불필요하다. 오히려 메모리만 많이 먹어 관리부담은 커지고, 불필요한 부하만 걸릴 뿐이다.

물론 Httpd의 다른 기능이나 모듈을 사용해야 할 필요가 있다면 그때는 Httpd를 앞에 두고 사용해야겠지만. 

예를 들어 하나의 서버에서 PHP애플리케이션과 자바 애플리케이션을 함께 사용하거나, Httpd 서버를 간단한 로드밸런싱을 위해서 사용해야 하는 경우라면 Httpd를 앞에 두고 톰캣을 연결해서 사용하도록 하면 될 것이다.

Reference

• https://titanic1997.tistory.com/28
• https://carmack-kim.tistory.com/93
• https://jobc.tistory.com/114
• https://inpa.tistory.com/entry/TOMCAT-%E2%9A%99%EF%B8%8F-%EC%84%A4%EC%B9%98-%EC%84%A4%EC%A0%95-%EC%A0%95%EB%A6%AC
• https://velog.io/@kdhyo/Apache-Tomcat-%EB%91%98%EC%9D%B4-%EB%AC%B4%EC%8A%A8-%EC%B0%A8%EC%9D%B4%EC%A7%80
• https://www.youtube.com/watch?v=mcnJcjbfjrs&t=29s
• https://www.youtube.com/watch?v=F_vBAbjj4Pk&t=87s
• 인프런: 모든 개발자를 위한 HTTP 웹 기본 지식