Back world

로깅(Logging)은 왜 해야할까?

PgmJUN — Mon, 30 Dec 2024 01:51:20 +0900

해당 게시글은 SOPT 35기 8차 세미나에서 후배 기수 대상으로 로깅에 대해 발표한 내용입니다.

로깅이란

시스템이 동작할 때 시스템의 상태 및 동작 정보를 시간 경과에 따라 기록하는 것

로그 레벨 (Log Level)

로그의 레벨은 총 5가지로 구분된다.

Error : 예상하지 못한 심각한 문제가 발생하는 경우

DB 연결 실패
예상하지 못한 예외 발생
필수 파일이나 리소스 누락으로 인해 애플리케이션 실행 불가

Warn : 애플리케이션이 정상적으로 작동하지만, 주의가 필요한 경우

이미 예측해서 처리한 예외에 대해 남기는 로그
설정 파일이 누락되었으나 기본값 사용하여 동작은 가능

Info : 운영에 참고할만한 사항

서버 애플리케이션 시작/중지
주요 작업의 완료 여부 (ex. 스케줄러)

Debug : 개발 단계에서 디버깅 용도

SQL 쿼리 로깅
외부 API 호출 요청/응답 로깅

Trace : Debug 레벨보다 더 세부적인 실행 흐름을 추적하는 경우

반복문 내부에서 변수 값 변화 추적
메서드 호출 체인 상세 추적
복잡한 비즈니스 로직의 모든 단계 로깅

왜 로깅을 해야할까

왜 로깅을 해야할까에 대해 고민하기 전에 반대로 생각해보자.

로깅을 안하면 어떤 문제가 발생할까?

간단한 예제를 통해 알아보자.

예제1. 결제

고객에게 이런 CS 문의가 들어왔습니다.
“제가 방금 결제를 했는데 돈은 나갔는데 상품 주문은 안됐어요!”

이 상황에서 로깅이 제대로 되어 있지 않다면, 다음과 같은 부분을 빠르게 인지할 수 없다.

고객이 실제로 결제를 진행했는가?
결제 정보를 처리하는 시스템에서 오류가 발생했는가?
주문 요청이 성공적으로 처리되었으나 그 결과가 고객에게 전달되지 않았는가?
문제의 원인이 외부 결제 시스템에 있는가, 내부 주문 시스템에 있는가?

로그가 남아있다면 아래처럼 빠르게 대처할 수 있었을 것이다.

”고객님께서 실제로 결제를 진행하셨지만, 결제 정보를 처리하는 시스템에서 오류가 발생해서 돈이 저희 서비스에 묶여있는 상태네요! 제가 처리해서 상품 주문 처리 해드리겠습니다.”

예제2. 디버깅

운영중인 서비스에서 에러가 발생했다.
그런데 문제는, 에러가 발생한 메서드가 여러 API에서 공용으로 사용되고 있다.

이 상황에서 로깅이 제대로 되어 있지 않다면, 다음과 같은 부분을 빠르게 인지할 수 없다.

문제가 발생한 API는 무엇인가?
어떤 사용자 요청이 문제를 유발했는가?
요청 데이터는 정상적인 값이 들어왔는가

결국 이러한 문제가 발생한다.

문제가 발생한 메서드를 사용하는 모든 API를 일일히 점검
디버깅 시간과 비용이 크게 증가
서비스 복구 시간 지연

결론적으로 이러한 문제는 '유저 이탈'이라는 치명적인 문제로 이어질 것이다.

로깅은 시스템의 ‘블랙박스’ 다.

결국 로깅은 자동차의 블랙박스와 같은 역할을 한다는 것을 알 수 있다.

자동차의 블랙박스가 사고 원인을 파악하는데에 효과적인 도움을 주는 것처럼,
로깅 또한 시스템에서 발생한 문제의 원인을 파악하는데에 효과적인 도움을 준다.

이렇듯 로그는 운영에 있어서 굉장히 중요한 정보로 사용된다.

어디까지 로깅 해야할까

그럼 어디까지 로깅을 해야하는지에 대해서도 굉장히 고민이 될 것이다.

현재 상황에서 필요한 것에 대해서만 로깅하라

이 질문에 대한 답은 "현재 필요한 것에 대해서만 로깅하라"이다.

불필요한 로그를 모두 남기게 되면 아래와 같은 문제로 이어질 수 있다.

데이터 저장공간 낭비
너무 많은 로그로 인해서 분석에 어려움

반면 필요한 정보만 로깅하게 된다면 이와 반대로 아래와 같은 장점을 얻는다.

데이터 저장공간 절약
필요한 로그만 빠르게 확인할 수 있어 분석에 용이

필요한 로그는 어떻게 구분하는데요?

처음부터 필요한 로그를 구분하긴 어렵다. 몸으로 느껴라

동일한 로직이더라도 서비스마다 해당 로직의 중요도에 따라서 로그의 필요성은 매번 다를 것이다.

때문에 아래 방법을 통한 직접 몸으로 느끼는 방식을 추천한다.

로그 없이 개발해보기
이 부분은 로그가 있으면 좋았을텐데 느껴보기
하나하나 필요한 부분에 추가해보기

이런 순서대로 직접 부딪히면서 개발해나가면 좋겠다.

API 요청/응답 로깅은 해두면 굉장히 편리해서 추천하는 편이다.
관심이 있다면 여기를 참조

마치며

기술 선택이든 로깅이든 결국 근거가 중요하다.

필요한 부분에 대해서 근거있게 로깅하며 개발해나갔으면 좋겠다!

AWS Parameter Store로 SpringBoot 프로퍼티 값 암호화해서 관리하기

PgmJUN — Sat, 21 Dec 2024 22:55:04 +0900

Spring Cloud & Parameter Store

적용 배경

DB password 등을 관리하는 application.yml 파일을 Github에 그대로 올리게 된다면 보안 상 문제가 될 수 있다.

이러한 문제를 해결하고 application.yml 값을 안전하게 다루기 위해 사람들은 다양한 방식을 적용한다.

현재 왓캠퍼스 프로젝트는 빠른 배포를 위해서 단순히 application-prod.yml를 Git Actions Secrets을 통해 관리하고 있었다.

그리고 CD 과정에서 artifact 파일을 생성하기 전, resources 패키지에 해당 파일을 저장해주는 방식을 사용했다.

하지만 그렇게 관리했을 때 특정 프로퍼티 값은 위와 같이 읽을 수 없는 문제가 발생했다.
application-prod.yml 을 통해 다른 로컬에서 작업하려면 직접 해당 파일을 전달해야 한다는 문제도 존재했다.

아무튼 이러한 설정으로 인해 구축해놓은 CI/CD 배포 자동 파이프라인이 정상적으로 동작하지 않았고

이로 인해 로컬에서 bootJar를 통해 artifact 파일을 만들어 FTP 프로토콜을 통해 EC2에 파일을 전달 후 수동 배포하는 상황이었다.

무료 이용 가능한 ParameterStore

과거에는 이러한 문제를 해결하기 위해 과거에는 AWS Cloud에 private 값을 저장해서 사용할 수 있는 AWS SecretsManager를 사용했었다.

하지만 SecretsManager는 유료 서비스이기 때문에 무료로 이용할 수 있는 AWS Parameter Store를 사용하여 문제에 해결책을 제시고자 하였다.

설정 난이도또한 Secrets Manager보다 쉽다고 느껴서 사용해보면 좋을 것 같다고 느꼈다.

Secrets Manager를 사용하는 방법도 궁금하다면 여기서 확인할 수 있다.

적용 방법

1. AWS Parameter Store에 프로퍼티 값 추가

AWS ParameterStore 접속

파라미터 생성 시에 가장 중요한 것 중 하나는 이름이다. 이름은 계층 구조로 표현할 수 있다.

수십 또는 수백 개의 매개변수를 Flat 목록으로 관리하는 것은 전체 값을 다룰 때 시간이 많이 걸릴 수도 있고

매개변수 값이 많아짐에 따라 식별도 어려울 수 있다.

결국 실수로 잘못된 매개변수를 사용하거나 동일한 구성 데이터를 여러 개 만드는 일도 생길 수 있다.

때문에 ParameterStore는 파라미터를 계층으로 관리하여 매개변수를 구성할 수 있도록 만들었다.

/{APP_NAME}/secrets_{PROFILE}/{KEY_NAME}

최대 15개의 레벨 계층을 만들 수 있으며 본인은 위와 같은 형태로 계층을 나눠보았다.

APP_NAME : 서비스하는 애플리케이션 이름
PROFILE : 사용할 환경 (ex. prod, dev, test)
KEY_NAME : 파라미터 값의 구분자

더 자세한 내용은 공식문서에서 확인할 수 있다.

해당 값을 입력했다면 '유형', '값'을 설정하면 끝이다.

'유형'은 3가지 값이 있는데 보안이 필요한 값이라면 보안 문자열을 사용하는 것이 안전하다.

그리고 자세히 보면 조금 생소한 용어들이 있다.

KMS (AWS Key Management Service)

데이터 암호화에 사용되는 암호화 키를 쉽게 생성하고 제어할 수 있는 AWS 서비스이다.

Key 암호화 구조

데이터를 보호할 때는 암호화 키를 보호해야한다.

키를 암호화하는 경우 암호화 키도 보호해야 하고, 데이터 보호 계층에서 가장 높은 레벨에 있는 암호화 키(Root Key)를 보호해야 한다.

여기서 AWS KMS가 사용된다.

KMS의 Root Key 암호화

위와 같은 암호화 구조에서 KMS는 Root Key를 보호한다.

KMS는 AWS 내에서 완전히 생성, 관리, 사용 및 삭제된다.

자세한 내용은 공식문서에서 확인할 수 있다.

SSM (AWS Systems Manager)

AWS에서 제공하는 리소스 및 애플리케이션 관리를 자동화하고 운영 작업을 간소화하기 위한 서비스 중 하나로 Parameter Store 및 다양한 기능을 제공한다.

2. AWS IAM 역할 생성

다음으론 AWS에서 역할을 생성해야한다.

역할은 AWS 서비스나 애플리케이션이 특정 리소스에 접근할 수 있는 권한을 부여하는 IAM 엔티티이다.

지금부터 SSM에 접근 가능한 IAM 역할을 생성하여 서비스의 EC2에 적용할 것이다.

[필수 참고 내용]
현재 개발중인 왓캠퍼스의 CI/CD는 Git Actions에서 동작하고 있으며,
특히 artifact 파일을 EC2에서 실행시키는 CD는 Self Hosted Runner를 통해 EC2에서 직접 동작하고 있다.
때문에 본인은 AWS에 IAM 역할을 적용해주는 것만으로 설정을 마칠 수 있지만, 나와 같은 환경이 아니라면 CD 스크립트에 추가적인 설정이 필요할 수 있다.

Self Hosted Runner에 대한 내용은 여기서 확인할 수 있다.

IAM 역할 생성

IAM 역할 생성 클릭 후 AWS 서비스 엔터티 유형 선택

사용 사례는 EC2를 선택해주면 된다.

SSM(AWS Systems Manager)에 대한 ReadOnlyAccess 권한 정책을 선택

만약 더 많은 권한이 필요하다면 AmazonSSMFullAccess 권한 정책을 선택하면 된다.

이름은 식별이 가능할 정도로만 잘 정해주면 된다.

EC2 역할 설정

다음으로 EC2에 방금 생성한 역할을 적용한다.

적용할 EC2를 선택 - 작업 - 보안 - IAM 역할 수정

방금 생성한 역할을 적용하면 끝!

(Optional) 로컬 환경 세팅

해당 ParameterStore 설정 값을 로컬에서도 이용하려면 IAM을 사용해야한다.

SSM 관련 권한을 가진 IAM 사용자를 생성하고, 로컬에 AWS Configuration 작업을 통해 IAM의 권한을 등록해주어야 한다.

AWS IAM 사용자 생성

이번엔 역할이 아닌 사용자를 생성한다.

이름은 식별이 간편할 정도로만 정해주면 된다.

역할과 똑같이 용도에 맞게 AmazonSSMReadOnlyAccess 또는 AmazonSSMFullAccess 중 하나를 선택하면 된다.

정해졌다면 사용자 생성!

이제 해당 사용자의 보안 자격 증명을 클릭한다.

그리고 csv 파일인 엑세스 키를 발급받으면 된다.

AWS Configuration

이제 흭득한 IAM 사용자 엑세스 키를 활용해서 로컬 환경에 configuration 을 진행할 수 있다.

관련된 내용은 이전에 작성해둔 포스팅에서 확인할 수 있다.

3. SpringBoot 환경 설정

마지막으로 SpringBoot 환경 설정을 통해서 Parameter Store에 등록해놓은 파라미터 값을 사용하기만 하면 된다.

해당 내용은 코프링 프로젝트이기 때문에 build.gradle.kts 로 설정을 수행한다.

Spring Cloud 의존성 추가

dependencies {
    implementation(platform("io.awspring.cloud:spring-cloud-aws-dependencies:3.2.0"))
    implementation("io.awspring.cloud:spring-cloud-aws-starter-parameter-store")
}

build.gradle.kts 에 'Spring Cloud AWS BOM'과 'Spring Cloud AWS'에서 제공하는 Parameter Store의 의존성을 추가한다.

Spring Cloud AWS BOM 의존성은 그냥 사용해서는 안되고 버전과 함께 사용해야한다.

implementation(platform())은 'BOM(Bill of Meterials)'를 나타내며 BOM은 '자재 명세서' 라는 뜻을 가진다.
BOM에 관련 버전을 명시해줌으로써 spring-cloud-aws에 포함된 의존성을 사용할 때 어떤 버전에 호환되는 의존성을 가져올 지 정의할 수 있다.

이를 통해 Parameter Store 의존성의 버전이 자동으로 맞춰질 수 있는 것이다.

Could not find org.springframework.cloud:spring-cloud-starter-aws-parameter-store-config: Required by: project

만약 해당 설정을 해주지 않는다면 위와 같은 오류가 발생한다.

자신의 스프링부트 버전에 맞는 Spring Cloud AWS의 버전은 Github 문서에서 확인할 수 있다.

내가 사용하는 Spring Boot 버전은 3.3.x 버전이다.

그렇다면 내 프로젝트에 호환되는 Spring Cloud AWS 버전은 3.2.x 버전이며 때문에 3.2.0 버전을 선택해주었다.

application.yml 파일 설정

spring:
  config:
    activate:
      on-profile: prod
    import: aws-parameterstore:/whatcampus/secrets_prod/

이젠 application.yml 파일에서 Parameter Store의 환경변수를 끌어다가 사용하기만 하면 된다.

나는 위와 같이 application-prod.yml 에 spring:config:import 를 통해서 파라미터 값을 가져왔다.

'aws-parameterstore:{파라미터_계층}' 을 입력해주면 된다.

나는 굉장히 가볍게 설정했지만 좀 더 자세한 설정이 알고 싶다면 공식 문서를 확인하자

  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

위 설정이 끝났다면 이제 파라미터 계층에 등록해준 파라미터의 이름을 입력해줌으로써 값을 끌어다 쓸 수 있게 된다.

4. 정상 동작 확인

이 설정을 통해서 로컬에서도 정상적으로 실행됨을 확인할 수 있었고

build되고 artifact 파일이 실행되어 배포가 수행된 것을 확인할 수 있었다.

결론

오늘은 private한 값을 AWS의 서비스 중 하나인 ParameterStore를 통해 무료로 암호화하여 관리하는 방법에 대해서 알아보았다.

최대한 잘 정리해보려고 노력했는데 이 내용이 많은 이들에게 도움이 되었으면 좋겠다.

아래 글들도 참고하기에 충분히 좋은 것 같으니 읽어보면 좋을 것 같다.

- https://gong-story.tistory.com/45
- https://treecode.tistory.com/122
- https://jojoldu.tistory.com/509

스프링부트 Filter로 요청/응답 정보 로깅 시스템 구축하기

PgmJUN — Thu, 19 Dec 2024 17:16:50 +0900

작업 배경

서버를 운영할 때는 로깅을 통해 서비스 운영에 유용한 매트릭을 흭득할 수 있다.

특히 요청/응답 정보 로깅은 실제로 서비스를 운영하면서 버그가 발생했을 때 해당 버그가 어떤 요청에서 비롯되어 어떻게 처리되다가 버그가 발생된 것인지를 쉽게 확인할 수 있도록 만들어준다.

또한 '어떤 요청을 받고 있는지', '적절한 응답을 보내고 있는지', '수상한 요청(Dos, DDos 등)은 없는지', '요청에 소요된 시간이 길진 않은지' 등 유용한 지표를 얻을 수 있다.

이렇듯 장점이 명확하기 때문에 요청/응답 정보 로깅은 서버를 개발하는 과정에서 필수적으로 진행해야하는 과정이라고 생각한다.

때문에 오늘은 스프링부트에서 Request/Response 정보를 로깅하는 방법에 대해서 알아볼 것이다.

AOP 로깅 vs Filter 로깅

그럼 먼저 요청/응답 정보를 무엇을 통해 로깅해야할까?

먼저 떠올랐던 것은 Filter와 AOP가 있었다.

AOP 로깅

AOP는 공통관심사를 별도의 모듈로 분리해서 비즈니스 로직에서 반복되는 코드를 제거하여 유지보수성을 높여주는 스프링의 장점 중 하나이다. AOP를 통해 Controller의 RequestMapping 애노테이션을 Pointuct으로 Controller 메서드를 호출했을 때 메서드를 호출한 요청 정보, 그리고 메서드 호출 이후에 응답 정보를 로깅할 수 있다.

Filter 로깅

필터는 DispatcherServlet이 '동작하기 전'과 '동작한 후' 에서 작동한다.

이러한 특징을 바탕으로 요청과 응답에 대한 정보를 각 시점에 로깅하도록 구현할 수 있다.

어떤 방식이 적절할까?

둘 다 적용해 본 사람으로서, 구현 방법은 사실 둘 다 구현에 필요한 리소스는 비슷하다고 느꼈다.

AOP로 요청 정보에 대한 로깅을 수행한다면 '@RestController 애노테이션이 붙은 클래스의 @RequestMapping 애노테이션이 붙은 메서드' 로 Pointcut을 잡아서, Request 및 Response에 대한 로그를 찍어주면 되고

Filter로 로깅을 수행한다면 Filter 인터페이스를 implements 하여, Request 및 Response에 대한 로그를 찍어주도록 구현하면 된다.

서버 정보를 빼가기 위한 공격성 요청

다만 AOP로 구현하는 경우 존재하지 않는 Endpoint로 들어오는 요청은 로깅할 수 없는 문제가 있었다.

이게 왜 문제인지는 위 이미지를 보면 조금은 이해할 수 있을 것이다.

위는 실제 땅콩 서버에 들어온 존재하지 않는 정적 리소스를 조회하려고 시도한 요청의 에러 로그이다.

서버의 중요한 정보가 담겨있는 파일을 조회하여 탈취하기 위해 무작위 Endpoint로 요청을 마구 보내는 일종의 공격성 요청 기록인데 존재하지 않는 Endpoint이기 때문에 HandlerMapping이 수행되지 않고, 그렇기 때문에 컨트롤러의 메서드가 실행되지 않는다.

'누가' '어떤 정보'를 담아서 요청을 보낸 것인지 정확한 모니터링이 되지 않았다.

때문에 이번 프로젝트에는 DispatcherServlet에 요청이 도달하기 전 요청 정보, 그리고 요청이 처리된 후 응답 정보를 모두 로깅할 수 있는 'Filter 방식'을 통해 서버로 들어오는 모든 요청에 대해서 로깅 시스템을 구축해보고자 한다.

물론 Filter로 로깅하는 것뿐만 아니라, 존재하는 API 이외의 요청은 서버에서 받지 않도록 별도의 처리를 해주어야 한다고도 생각한다. 이에 대한 자세한 내용은 여기에서 확인할 수 있다.

Filter란?

jakarta.servlet.Filter

Filter는 스프링 컨테이너의 DispatcherServlet에 요청이 도달하기 전 그리고 DispatcherServlet에서 요청이 처리된 이후 시점에 존재하는 요청 사후/사전 처리 작업 객체이다.

servlet 패키지에 포함되어 있는 필터는 Filter 인터페이스를 implements 하여 직접 구현할 수 있다.

Filter 인터페이스에 들어가보면 위와 같이 설명이 되어있는데 요청/응답에 대한 로깅 필터로도 사용하는 것이 적절한 사용 방식들 중 하나임을 알 수 있다.

Filter의 메서드

init()

default void init(FilterConfig filterConfig) throws ServletException

Filter가 정상적으로 서비스에 배치되고 있음을 나타내기 위해 웹 컨테이너에 의해 호출되는 메서드

서블릿 컨테이너는 Filter를 인스턴스화한 후 init() 메소드를 정확히 한 번 호출한다.

init 메소드가 성공적으로 완료되어야 Filter가 Filtering 작업을 수행하도록 요청할 수 있다.

destroy()

default void destroy()

doFilter() 메소드 내의 모든 스레드가 종료되거나 제한 시간이 경과한 후에 로직이 종료되었음을 알리기 위해 호출되는 메서드

doFilter

doFIlter()

void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException;

유저가 서버 리소스를 흭득하기 위해 보낸 요청으로 인해 요청/응답 정보 쌍이 FilterChain을 통해 전달될 때마다 컨테이너에 의해 호출되는 메서드

ServletRequest, ServletResposne 를 통해 응답 요청 정보를 활용할 수 있으며, FilterChain 매개변수를 통해 체인의 다음 엔티티로 요청/응답 정보를 전달할 수 있다.

적용 방법

Filter를 통해 적용해보는 과정에서 몇 가지 시행착오를 겪고 이에 대한 과정과 결론을 정리해보고자 한다.

1. Request Body 정보 캐싱 처리

@Throws(IOException::class, ServletException::class)
override fun doFilter(servletRequest: ServletRequest, servletResponse: ServletResponse, filterChain: FilterChain) {
}

위 코드는 Filter에서 로깅에 사용할 수 있는 doFilter() 메서드이다.

ServletRequest를 통해 요청 정보를 로깅할 수 있는데 이때 요청 정보는 InputStream 형태로 들어오며 Stream은 단 한 번만 읽을 수 있다.

때문에 InputStream을 로깅 시점, 요청 정보 사용 시점에서 모두 사용하려면 캐싱 처리를 수행해야한다.

캐싱으로 인해 추가적인 메모리를 사용하게 되지만 요청이 거의 없는 현재 프로젝트 구조에서는 나쁘지 않은 선택이라고 생각한다.

어떻게 캐싱하는 것이 좋았을까?

고민1 - ContentCachingRequestWrapper, ContentCachingResponseWrapper

첫 번째 방법으로 Spring에서 제공하는 ContentCachingWrapper를 고민해보게 되었다.

Filter 로깅과 관련해서 찾아보면 주로 나오는 것이 ContentCachingRequestWrapper이다.

해당 객체는 HttpServletRequest 정보를 Wrapper 패턴으로 감싸고, InputStream 값을 캐싱하여 여러 번 사용할 수 있도록 만들어주는 유용한 도구이다.

ContentCachingWrapper의 문제점

하지만 해당 방식에는 문제가 하나 있었다.

요청 정보에 대한 InputStream을 ContentCachingWrapper에 담는다고 캐싱이 끝이 아니었다.

ContentCachingWrapper를 사용하면 Stream의 값이 캐싱되어 맘껏 값을 사용해도 된다고 생각했는데,

그게 아니라 해당 InputStream을 읽으면 해당 내용이 클래스 내부 필드인 cachedContent에 캐싱되는 구조였다.

이 이후부터는 getContentAsByteArray() 메서드를 통해 캐시된 Stream 값을 사용할 수 있는 구조이다.

결국 로깅하고 싶은 요청/응답 정보가 각자 원래 사용되던 곳에서 한 번은 읽힌 뒤에야 캐싱된 값을 사용할 수 있게 되는 것이다.

Stream은 1회성인데 Filter에서 읽어버리면 위와 같이 로깅은 성공하지만 Controller에서는 HttpMessageNotReadableException 예외가 발생하면서 사용할 수 없게 된다. (Controller에서 getContentAsByteArray() 메서드를 사용하진 않으니까)

결국 이렇게 요청에 대한 처리가 모두 끝난 뒤에 요청/응답에 대한 로깅을 남길 수 밖에 없다.

하지만 나는 요청/응답 로깅을 요청이 들어온 순서에 맞게 순차적으로 기록하는 것이 가독성에 더 좋겠다 싶어서 다른 방법을 고민해보았다.

고민2 - 커스텀 Request Body 캐싱 객체 구현하기 ✅

다음 대안으로 찾은 방식은 커스텀으로 Request Body를 캐싱하는 객체를 구현하는 방법이다.

CachedBodyHttpServletRequest 구현

import jakarta.servlet.ReadListener
import jakarta.servlet.ServletInputStream
import jakarta.servlet.http.HttpServletRequest
import jakarta.servlet.http.HttpServletRequestWrapper
import java.io.ByteArrayInputStream
import java.io.IOException

class CachedBodyHttpServletRequest(request: HttpServletRequest) : HttpServletRequestWrapper(request) {

    private val cachedBody: ByteArray

    init {
        cachedBody = request.inputStream.readAllBytes()
    }

    @Throws(IOException::class)
    override fun getInputStream(): ServletInputStream {
        return object : ServletInputStream() {
            private val byteArrayInputStream = ByteArrayInputStream(cachedBody)

            override fun read(): Int {
                return byteArrayInputStream.read()
            }

            override fun isFinished(): Boolean {
                return byteArrayInputStream.available() <= 0
            }

            override fun isReady(): Boolean {
                return true
            }

            override fun setReadListener(listener: ReadListener?) {
                // 비동기 처리가 필요하다면 구현을 추가
            }
        }
    }

    fun getBody(): String {
        return String(cachedBody, Charsets.UTF_8)
    }
}

이 코드는 ContentCachingWrapper 의 문제를 해결하기 위해 직접 구현한 객체이다.

ContentCachingWrapper와 동일하게 HttpServletRequestWrapper를 상속받아 구현하였기에 대체로 사용할 수 있다.

해당 객체의 특징

객체의 인스턴스가 생성되는 시점에 'init 블럭'을 통해서 cachedBody에 InputStream의 byte 값을 모두 캐싱해버린다.
getInputStream() 메서드를 override 하여, 해당 메서드 호출 시 항상 캐싱해둔 byte 값을 통해 ServletInputStream 객체를 만들어 return 한다.

이를 통해 InputStream을 담아서 인스턴스를 생성하면 그 시점부터 항상 캐싱된 cachedBody 값을 사용할 수 있게 되었다.

때문에 컨트롤러에서 getInputStream() 메서드를 한 번 호출 하고, 그 이후에 getContentAsByteArray() 를 통해 캐싱된 body값을 얻을 수 있는 ContentCachingWrapper보다 활용도가 높아졌다.

결론적으로 해당 커스텀 객체를 만든 캐싱 방식을 채택하게 되었다.

2. 요청정보 로깅 Filter 구현하기

import com.whatcampus.whatcampus.logger
import jakarta.servlet.*
import jakarta.servlet.http.HttpServletRequest
import jakarta.servlet.http.HttpServletResponse
import org.slf4j.MDC
import org.springframework.core.annotation.Order
import org.springframework.stereotype.Component
import java.io.IOException
import java.util.*

private val X_FORWARDED_FOR_HEADER = "X-Forwarded-For"
private val TRACE_ID = "traceId"

@Component
@Order(1)
class RequestLoggingFilter : Filter {

    val log = logger()

    @Throws(IOException::class, ServletException::class)
    override fun doFilter(servletRequest: ServletRequest, servletResponse: ServletResponse, filterChain: FilterChain) {
        val request = CachedBodyHttpServletRequest(servletRequest as HttpServletRequest)
        val response = servletResponse as HttpServletResponse
        MDC.put(TRACE_ID, UUID.randomUUID().toString())

        val requestLine = "${request.method} ${request.requestURI}${getRequestParams(request)}"
        log.info("Request (${getRequestAddr(request)}) : $requestLine ${request.getBody()}")
        filterChain.doFilter(request, response)
        log.info("Response : $requestLine : ${response.status}")
    }

    fun getRequestAddr(request: HttpServletRequest): String {
        val requestAddr = request.getHeader(X_FORWARDED_FOR_HEADER)
        return requestAddr ?: request.remoteAddr
    }

    fun getRequestParams(request: HttpServletRequest): String {
        var queryParameters = request.parameterMap
            .entries
            .joinToString("&") { (key, values) -> "$key=${values[0]}" }

        if (queryParameters.isNotEmpty()) {
            queryParameters = "?$queryParameters"
        }
        return queryParameters
    }
}

위에서 구현한 CachedBodyHttpServletRequest 를 바탕으로 구현된 요청 응답 정보 로깅 Filter이다.

FilterChain에 Filter 등록

@Component
@Order(1)
class RequestLoggingFilter : Filter {

@Component 애노테이션을 선언해주면 컴포넌트 스캔에 의해 Bean으로 등록된다.
- Bean으로 등록된 Filter 타입 객체는 Spring Boot AutoConfiguration에 의해 자동으로 FilterChain에 추가된다.
@Order 애노테이션과 order 매개변수 값을를 입력해줌으로써 FilterChain에서 몇 번째 순서로 동작할 지를 정의할 수 있다.
- order를 1로 설정해주었기 때문에 가장 앞단에서 RequestLoggingFilter는 동작하는 필터가 되었다.

doFilter()

@Throws(IOException::class, ServletException::class)
override fun doFilter(servletRequest: ServletRequest, servletResponse: ServletResponse, filterChain: FilterChain) {
    val request = CachedBodyHttpServletRequest(servletRequest as HttpServletRequest)
    val response = servletResponse as HttpServletResponse
    MDC.put(TRACE_ID, UUID.randomUUID().toString())

    val requestLine = "${request.method} ${request.requestURI}${getRequestParams(request)}"
    log.info("Request (${getRequestAddr(request)}) : $requestLine ${request.getBody()}")
    filterChain.doFilter(request, response)
    log.info("Response : $requestLine : ${response.status}")
}

요청 정보를 HttpServletRequest로 캐스팅하여 CachedBodyHttpServletRequest에 담는다.
응답 정보를 HttpServletResponse로 캐스팅한다.
- 이렇게 캐스팅하는 이유는 ServletRequest/ServletResponse 에서는 로깅에 필요한 정보를 얻을 수 없기 때문이다.
MDC에 요청 추적을 위한 TraceId를 등록한다. (자세히 알고 싶으면 여기 클릭)
요청 정보 로깅 -> 다음 필터 호출 및 요청 처리 -> 응답 정보 로깅
- [Request 로그 형태 예시] Request (IP주소) : GET /api/v1/test?key=value { "key":"value"}
- [Response 로그 형태 예시] Response : GET /api/v1/test?key=value : 200

getRequestAddr()

fun getRequestAddr(request: HttpServletRequest): String {
    val requestAddr = request.getHeader(X_FORWARDED_FOR_HEADER)
    return requestAddr ?: request.remoteAddr
}

로그에 남길 요청을 보낸 주소를 흭득한다.
- WAS 앞단에 구현해둔 Nginx 리버스 프록시 서버에서 요청을 먼저 받고 'X_FORWARDED_FOR' 헤더로 WAS에 실제 요청 주소를 전달하도록 설정해놓은 상태이기 때문에, X_FORWARED_FOR 헤더가 존재한다면 그 값으로 로깅한다.

getRequestParams()

fun getRequestParams(request: HttpServletRequest): String {
    var queryParameters = request.parameterMap
        .entries
        .joinToString("&") { (key, values) -> "$key=${values[0]}" }

    if (queryParameters.isNotEmpty()) {
        queryParameters = "?$queryParameters"
    }
    return queryParameters
}

요청에 포함된 쿼리 파라미터 값을 파싱하여 "?key1=value1&key2=value2" 형태로 문자열을 만든다.

3. 결과 확인

Request 로그

[Request 로그 형태 예시] Request (IP주소) : GET /api/v1/test?key=value { "key":"value"}

Response 로그

[Response 로그 형태 예시] Response : GET /api/v1/test?key=value : 200

커스텀 Logger를 통해 최종적으로 출력된 로그

Filter에서 함께 설정했던 TraceId 값과 함께 요청/응답 로그가 잘 출력되는 것을 확인할 수 있다.

결론

오늘은 Filter를 통한 스프링부트 요청/응답 정보 로깅 시스템 구축하기에 대해서 알아보았다.

위에서 말했듯이 AOP를 통해 로깅 시스템을 구축하는 것과 난이도에 큰 차이는 없었던 것 같다.

존재하는 약간의 차이는 '존재하지 않는 HTTP API 메서드에 대한 요청이더라도 로그를 남기느냐 아니냐' 인 것 같다.

AOP로도 구현하려면 할 수 있겠지만 그렇게 할 거면 그냥 Filter를 쓰면 될 것 같다.

다음에는 땅콩에서 적용해보았던 AOP를 통한 요청/응답 정보 로깅 방식도 작성하여 공유해겠다.

나도 모르게 책 출판해버린 이야기 : 일단 나부터 리팩터링 합니다2

PgmJUN — Thu, 19 Dec 2024 01:59:29 +0900

일단 나부터 리팩터링 합니다2

수료 후 오랜만에 울린 슬랙 알림

오늘 땅콩 팀원들과 연말파티를 보내고 있었는데 수료 후 잠잠하던 우테코 6기 슬랙에서 한 알림이 도착했다.

읽어보니 워니가 우테코 6기의 주요 활동 중 하나인 '유연성 강화 스터디'의 레벨 별 회고를 바탕으로 책을 출판해주신 것이었다..!

크루원들이 작성한 유연성 강화 스터디 내용을 하나하나 정리하여 책으로 출판해주셔서 너무 감동이었다..

유연성 강화 스터디란?

우아한테크코스는 소프트 스킬 향상을 위해 다양한 활동을 제공하고 있었는데, 유연성 강화 스터디는 그 중 하나이다.

유연성 강화 훈련은 ‘고통스럽다고 느끼던 특정 상황을 유연하게 대처할 수 있게 만들어주는 스킬’ 훈련이다. 쉽게 말해, 유연해져야 하는 부분에 대해 목표를 정하고 달성을 위해 노력하는 훈련이다.

나 또한 유연성 강화 훈련을 만나고 뻣뻣했던 마인드에 유연함이 생기기 시작했다.

책 소개

"일단 나부터 리팩터링 합니다."

개발자라면 누구나 한 번쯤 코드 리팩터링의 필요성을 느껴봤을 거예요. 그럴 때 우리는 더 나은 구조와 논리를 찾아 리팩터링을 시작합니다. 그런데 가끔은 이런 생각이 들 때가 있습니다. “이 과정, 나에게도 필요하지 않을까?” 우리의 일상과 마음도 종종 코드처럼 복잡해지곤 합니다. 이럴 때 필요한 건 새로운 지식이나 도구를 더하는 것이 아니라, 나 자신을 들여다보고 불필요한 것들을 덜어내는 일일지도 모릅니다. 이 책은 우아한테크코스 6기 크루들이 각자 자신의 강점과 약점을 마주하고, 더 나은 방향으로 나아가기 위한 과정을 고민하며 써 내려간 이야기입니다. 자신을 리팩터링하며 더 유연하고 단단한 사람이 되어가는 여정을 담고 있습니다. 변화는 거창한 데서 시작하지 않고 나 자신을 이해하고 조금 더 나아지려는 작은 실천에서 비롯됩니다. 이 책이 여러분에게 그런 작은 출발점이 되길 바랍니다.

- '일단 나부터 리팩터링 합니다' 중

어떤 내용인지 궁금해할 사람들을 위해 책의 핵심 소개 내용을 가져와보았다.

관심이 생겼다면 '무료' 전자 책이니 한 번 읽어봐도 좋을 것 같다.

궁금한 사람들을 위한 링크

일단 나부터 리팩터링 합니다 2 - 우아한테크코스 6기 크루 / 조경찬, 나영서, 이상진, 양경호, 남

개발자라면 누구나 한 번쯤 코드 리팩터링의 필요성을 느껴봤을 거예요. 그럴 때 우리는 더 나은 구조와 논리를 찾아 리팩터링을 시작합니다. 그런데...

bookk.co.kr

내가 작성한 유강스 내용은 '일단 나부터 리팩터링 합니다 2' 에 있다.

궁금한 사람들은 해당 서적의 목차 중 이든(최승준) 을 찾거나 '523Page' 에서 확인할 수 있다.

일단 나부터 리팩터링 합니다1 - 우아한테크코스 6기 크루 / 김주하, 김민수, 고상현, 이낙헌, 송

개발자라면 누구나 한 번쯤 코드 리팩터링의 필요성을 느껴봤을 거예요. 그럴 때 우리는 더 나은 구조와 논리를 찾아 리팩터링을 시작합니다. 그런데...

bookk.co.kr

일단 나부터 리팩터링 합니다 3 - 우아한테크코스 6기 크루 / 정회성, 강다빈, 권기호, 이재민, 정

개발자라면 누구나 한 번쯤 코드 리팩터링의 필요성을 느껴봤을 거예요. 그럴 때 우리는 더 나은 구조와 논리를 찾아 리팩터링을 시작합니다. 그런데...

bookk.co.kr

다른 크루원들의 유연성 강화 스토리도 궁금하다면 여기서 확인할 수 있다:)

GitHub 브랜치 보호: CI 통과 전 머지 금지 브랜치 전략 세우기

PgmJUN — Sat, 14 Dec 2024 01:29:01 +0900

설정 근거

프로젝트 과정에서 CI/CD 배포 자동화 파이프라인을 구축하였다.

나는 보통 CI 과정에서 애플리케이션의 테스트를 진행하는데, CI가 다 돌지 않아도 변경사항을 운영(prod) 환경으로 Merge할 수 있다는 점에 문제를 느꼈다.

테스트가 실패하는 변경사항이 운영환경에 올라갈 수 있다는 것이 말이 되지 않는다고 생각했다.

이 문제를 해결하기 위해 브랜치 보호 규칙을 떠올리게 되었고 문제 해결과정을 블로그에 기록 및 공유하고자 글을 작성한다.

설정 과정

Github Repository - Settings

설정을 적용하려는 Repository 의 Settings에 접속한다.

Settings - Branches

Settings 탭에서 Branches를 선택한다.

Branch protection rules - Add classic branch protection rule

그럼 브랜치 보호 규칙 설정 페이지가 나오는데 'classic branch protection rule'을 클릭해서 설정해보겠다.

브랜치 규칙 설정

Branch name pattern

브랜치 이름 패턴을 설정하는 입력창이다.

나는 prod 브랜치에 대해서 이 규칙을 적용할 계획이므로 'prod'를 입력해주었다.

이렇게 설정하면 feat, refactor 등의 브랜치에서 prod로 Merge 하고자 할 때, 지금 설정하는 보호 규칙이 적용된다.

이를 통해 prod 브랜치에 대한 Merge를 더욱 안전하게 만들 수 있다.

Require status checks to pass before merging

오늘 소개하고자하는 핵심 기능이다.

'Require status checks to pass before merging' 선택을 통해 merge하기 전 브랜치의 상태를 점검할 수 있다.

나는 CI 스크립트에서 'test' 라는 job을 통해 애플리케이션의 테스트를 수행한다.

바로 이 test job을 Merge 전에 체크하도록 함으로써 test job이 돌지 않으면 prod 브랜치에 변경사항을 Merge 할 수 없도록 구성한다.

이를 통해 안전한 브랜치 운용이 가능해진다.

Require branches to be up to date before merging

Merge 하기 전, 브랜치가 최신 상태여야 함을 강제할 수 있는 규칙이다.

머지 전 prod 브랜치의 최근 변경 사항을 반영해야 하도록 강제함으로써 충돌과 같은 문제를 방지할 수 있다.

이제 Create 버튼을 클릭하면 위에서 설정한 브랜치 보호 규칙이 적용된다.

주의사항

Free 요금제의 Organization을 사용중이고, Repository가 private 이라면 해당 설정은 적용되지 않는다.

Organization 기준으로 해당 설정은 'Github Team' 이나 'Enterprice' 요금제를 사용해야만 적용 가능하다!

[우아한테크코스 6기] 레벨5 돌아보기 (2024/10/28 ~ 2024/11/29)

PgmJUN — Thu, 12 Dec 2024 16:22:00 +0900

우테코 덕분에 1년간 많은 것을 배우고 느낄 수 있었다. 또 소중한 동료와 멘토를 만나 말로 표현할 수 없을 정도로 유익한 시간을 보낼 수 있었다고 생각한다.
이번엔 우아한테코크스의 마지막 기간인 레벨5를 마무리하고 이 과정에 대한 기록을 남겨놓고자 한다. 마지막 글인 만큼 조금은 진지하게 적어보았다.

취업준비 기간

우테코 레벨5는 취업 준비 기간이다. 때문에 우아한형제들 우테코 전형 신입 지원 기회도 주어졌다.
취업 설명회도 우형 직원분들께서 오셔서 진행해주셨고 꽤나 흥미롭게 들을 수 있었다.

토스뱅크 취뽀

토스뱅크 최종 합격

이 기간에 나는 토스뱅크 테크니컬 면접에 합격하여 컬처핏 면접을 준비하고 있어 굉장히 바쁜 기간이었다.
우형 자소서 마감이 11월 1일 오전 7시였는데, 컬쳐핏 면접은 10월 31일 저녁이었다.
자소서는 토뱅 면접을 준비하느라 단 한 자도 써두지 않은 상태였고, 31일 저녁 면접을 보고 와서 자소서를 쓰는 인원들과 카페에서 모였지만 손에 잡히지 않았다.

우형이라는 회사는 네카라쿠배의 '배'로 유망한 IT 대기업 중 하나이다.
하지만 당시에는 회사에 공감 가는 가치가 크게 없었고 그래서인지 자소서를 적을 수가 없었다. 자소서에 어느 정도 예쁘게 포장해서 쓰는 것들은 있다고 해도 아예 거짓말을 하고 싶진 않았다.
이게 당연하긴 하다. 우테코에서 교육을 받았지만 우아한형제들이라는 회사는 우테코와는 완전히 별개이다.
그래서 공감 가는 포인트를 찾아보려면 기업에 대한 서칭을 많이 했어야 했는데 개인적으로 당시 최고의 관심사였던 토뱅 취업준비를 더 우선시하느라 기업에 대해 거의 알고 있는 게 없었다. 또 우형에서 우테코에 크게 관여하는 일은 없었고 우테코의 교육 철학과 우형의 실무는 많이 다른 듯했기에 나에게 우형은 '잘 모르는 회사'였다.

그래서 결국 우아한형제들 지원은 때가 아니었다는 생각을 갖고 이 시점에 포기하고 자소서 제출을 하지 않았다.
지금 생각해 보면 좋은 경험을 해 볼 기회를 하나 놓친 것은 아닌가 싶은 생각도 들지만, 당시에 그 선택은 최선이었고 후회하지 않는다.
토스뱅크 컬처핏 면접을 정말 즐겁게 보고 와서 더욱이 후회는 없었다.

그리고 우아한 형제들 지원 마감시간인 11/1 오전 7시에서 2시간이 지난 오전 9시 토스뱅크에서 첫 커리어를 시작하게 되었다.
사실 아쉬워할 시간조차 없긴 했던 것 같다.

자세한 토스뱅크 취업 회고가 궁금하면 여기서 확인할 수 있다.

구구의 재테크강의

레벨5는 백엔드 코치인 구구가 재테크강의(일명 '우아한(재)테크코스')도 해주어서 굉장히 유익했다.
취업을 하게 되어서 돈을 모으고 굴릴 방법을 공부해야 했는데, 많인 키워드와 힌트를 얻어갈 수 있었다.
투자, 저축에 대해 무지해서 알바비를 받으면 전부 써버렸던 과거의 나를 반성하는 시간이 되었다.
구구 얘기를 듣고 ISA 계좌도 개설했고 노후연금, 투자 등등에 대해서 하나하나 공부해보고 있다.
지금도 늦지 않았기 때문에 열심히 모아보려고 한다.

우테코 6기 수료식

수료증을 들고 캡틴 포비와의 한 컷

우테코를 시작했던 날은 2월이었는데 어느덧 수료식 날이 되어버렸다.
1년간 함께한 크루원들, 그리고 정들었던 잠실캠퍼스를 떠난다고 생각하니 마음이 허전해짐을 느꼈다.
하지만 최선을 다해 달렸던 만큼 최대한 즐거운 분위기로 수료식을 즐기려고 했다.

소중한 추억 돌아보기

레벨1 솔라조 ☀️

우테코에 들어와서 처음 만난 사람들인 레벨1 솔라조도 정말 많이 기억에 남는다.
함께 레벨 인터뷰 스터디를 하기도 했고 한강에 놀러 가기도 했고 술도 먹고 밥도 먹고 보드게임도 하고 정말 즐거운 시간들을 보냈다.
다들 성향이 제각각이라 다 같이 제대로 놀러 가보진 못했지만 함께 보낸 시간만으로도 충분히 즐거웠다.
서로 좋은 영향을 많이 주고받았던 것 같다. 땅콩팀과 더불어서 가장 터놓고 대화할 수 있던 사람들 중 하나였지 않았나 싶다.

땅콩팀

땅콩 수료식 단체사진

정말 많은 시간을 땅콩팀과 보냈기에 각별했던 우리 팀과 이제 매일 볼 수는 없게 되니 많이 아쉬웠다.
그래도 한 명 한 명 취업에 성공할 때마다, 그리고 종종 보고 싶을 때마다 모여서 얼굴을 보기로 했다.
끝나고 땅콩 디벨롭도 계속해서 이어나갈 예정이니 앞으로 볼 날이 수두룩하다~
회고를 쓰고 있는 지금 시점엔 연말파티를 하자고 파티룸도 잡아두었다.
7월부터 동고동락한 우리 땅콩팀 앞으로 오래오래 만났으면 한다!

평균 DAU 8

우아한형제들 네트워킹에 소개된 땅콩

'땅콩'은 우아한형제들 개발 밋업에서 사용되었다. 이후 서비스에 접속하는 실제 유저들이 발생하는 중이다.

아직 홍보도 제대로 하지 않았는데, 밋업 이후 평균 DAU가 8로 측정되었다.
모니터링 시스템을 강화하고 적극적인 홍보를 바탕으로 서비스를 더욱 키워나갈 예정이다.
우선 지금 자체로도 사용성이 좋으니, 더 다양하고 재밌는 밸런스 게임 질문들을 만들어보려고 한다.

앞으로의 땅콩

앞으로 땅콩은 사실 다들 팀원들이 취업 준비에 들어간 상태라서 뭔가 새로운 기능을 추가하는 등의 큰 작업은 하기 어렵다고 판단되었다.
때문에 앞으로는 팀원들이 모두 작업에 관여하기란 어렵다는 생각이 들었다. 그래서 TF팀 단위 작업을 제안했다.
필요하다고 생각되는 기능이 있다면 그 부분에 대한 내용을 바탕으로 시간이 되는 팀원들을 모아 TF팀을 구성한다.
그리고 '근거-과정-결과'를 문서화하여 팀 협업툴 채널에 공유한다.
모두가 참여할 수 없는데 참여하도록 강요하는 방식보다는 TF팀 방식을 적용해야 지속가능한 팀이 될 것이라고 생각했기 때문이다.

TF TEAM 채널

이 의견에 팀원들도 공감해 주었고 팀 디스코드에 이런 채널이 하나 생기게 되었다. (디스코드 이름은 무시해 주세요 백엔드 팀 컨셉입니다^^)
앞으로의 땅콩과 팀의 성장도 정말 기대된다!

우테코를 떠나보내며

공허해진 우테코

사람들이 북적거렸던 시간에 한산해진 잠실 캠퍼스의 사진을 보며 정말 우테코가 끝났음을 실감하게 되었다.
이 공간에서 참 많이도 배웠고 성장했다.

스스로 성장하는 방법

우테코에서 얻은 가장 큰 배움은 스스로 성장하는 방법을 얻은 것이라고 생각한다.
이곳에서 1년간 구르며 지식적인 성장도 얻었다. 하지만 우테코에서와 같이 양질의 인적 자원이나 특별한 상황이 주어지지 않더라도 스스로 성장하는 방법을 배우는 것이 앞으로 개발자로서의 커리어에 가장 도움이 될 것이라고 생각한다.
그리고 그 방법을 배워서 나가게 된 것 같아 스스로 만족스러웠다.
우테코가 아니었다면 이런 것들을 어떻게 배울 수 있었을까? 몇 년이 지난 뒤에나 많은 시도 끝에 배우지 않았을까?
이거 하나만으로도 우테코에서 얻을 건 다 얻었다고 느낀다.

협업의 소중함

평소 함께의 가치와 협업의 소중함을 알고 있었지만, 우테코에서 다시 한번 이러한 가치들을 깊이 있게 느끼고 나가는 것 같다.
프로젝트 과정에서 다양한 문제를 마주쳤는데, 빠른 이슈 공유와 소통으로 이루어진 협업을 통해 문제를 빠르게 분석 및 해결해 나갈 수 있었고
크루원들과 스터디를 통해 서로의 부족한 부분을 채워나갈 수 있었다. 혼자였다면 이렇게 하지 못했을 것 같았지만 함께여서 가능했고 정말 좋은 사람들을 많이 만나고 가는 것 같아 행복했다.

우테코에서 다시 한번 느낀 동료와 협업의 소중함을 바탕으로, 앞으로 만나게 될 동료들과도 균형 있게 어우러질 수 있는.. 그리고 함께 성장을 도모해 나갈 수 있는 사람이 된 것 같아 만족스러웠다.

다시 처음으로

토스뱅크에서의 새로운 시작

우테코를 마무리하고 새롭게 도착하게 된 정착지는 토스뱅크이다.
토스뱅크에서 토스를 사용하는 많은 사람들에게 혁신적이고 가치 있는 금융 서비스를 제공하여 토스와 함께 금융계의 혁신을 이끌어가고자 한다. 물론 쉽진 않을 것을 알기에 많이 노력할 것이다.

남은 기간 동안 토스뱅크에서 주로 사용하는 언어인 Kotlin을 학습하고 기록해나가 보고자 한다. 사실 이미 대학 공지 알림이 왓캠퍼스 프로젝트에 Java to Kotlin 마이그레이션을 진행하며 학습 중에 있다. 또 이미 관련해서 재밌거나 신기한 내용을 몇 가지 기록해두기도 하였다.

차근차근 노력해서 토스뱅크에 없어선 안 될 사람이 되고 싶다고도 생각한다.
이전에 한 크루원이 백엔드 코치였던 구구에게 "어떤 기업이 좋은 기업이고, 어떤 회사를 가는 게 좋은가요?"라는 뉘앙스의 질문을 한 적이 있다.
그때 들었던 답변 중 이 내용이 기억에 강렬히 남아있다.

네카라쿠배같은 회사에 집착하지 마시고 본인이 있는 곳을 네카라쿠배처럼 만들어보세요.

말처럼 쉬운 이야기는 아니지만, 유명하지 않았던 배달 앱인 '배달의민족'에 가치를 느끼고 입사하셔서 현재 IT 최고의 기업 '네카라쿠배' 중 하나인 배민이 될 때까지 함께 하고 계신 구구를 보면서 이 말에 큰 힘을 느꼈다.

내가 있는 곳을 더 나은 곳으로 만들려는 목표와 의지를 가지고 더 많은 사람들이 토스뱅크의 유저가 될 수 있도록 노력해보고자 한다.

앞으로의 목표

나는 공유와 협업 그리고 이를 통해 동료들과 함께 성장해 나가는 과정에서 가장 큰 가치를 느끼는 사람이다.
앞으로 현업에서 만나게 될 문제에 대해 이러한 가치를 지속적으로 실천해 나가면서 살아나갈 계획이다.

그리고 주변 사람들에게 항상 하는 이야기지만, 언젠간 초심자도 쉽게 이해할 수 있는 백엔드 기술에 대한 강의나 책도 만들어보고 싶다.
본인 또한 김영한 님의 강의를 들으면서 정말 쉽게 스프링부트 기초를 이해하고 지금까지 왔기 때문에, 김영한 님과 같이 초심자들을 이끌어주는 이정표 같은 사람이 되고 싶다는 목표를 품고 있었다.
그러기 위해선 더 많은 지식과 경험이 필요하다. 그 경험들을 얻기 위해 꾸준히 힘차게 달려 나갈 것이다.

[우아한테크코스 6기] 레벨4 돌아보기 (2024/09/03 ~ 2024/10/25)

PgmJUN — Thu, 12 Dec 2024 00:25:51 +0900

우아한테크코스의 레벨 4가 끝나면서 이에 대한 기록도 남겨보고자 한다.

항상 조금은 무겁게 쓰던 회고였지만, 이번 회고는 사진을 많이 담아 조금 프리하게 써보려고 한다.

어떤 일들이 있었는지 되돌아보자!

방학 중 힐링 여행

제주도 여행

레벨4를 들어가기에 앞서, 레벨3 종료 이후 방학 기간을 활용하여 제주도에 다녀왔다 ️

프로젝트로 인한 스트레스와 그동안 운동도 못가고 맘편히 쉬지도 못했던 것들에 대해 보상받는 느낌이었다.

그리고 제주도에서 시간을 보내며 이렇게 맘편히 힐링하며 쉬어가는 시간이 정말 필요하다고 다시 한 번 느꼈다.

우리는 사람인지라 매번 달릴 수는 없으니 말이다. 하지만 매번 일에 몰입하게 되면 이걸 잊게 되는 것 같다..

아무튼 레벨4를 대비할 수 있는 힘을 비축한 좋은 시간이었다.

실제로 레벨4는 정말 바빠서 가장 정신없던 기간이었다.

"지금 이 순간이 가장 여유로울 때다" 라고 말하던 우테코 선배들의 말들이 여러 번 뇌리를 스쳤던 기억이 난다.

레벨3에 마지막 데모데이에서 받은 피드백을 바탕으로 서비스 개선

평온했던 방학 이후 시작된 레벨4는, 레벨3 데모데이에서 받은 피드백을 우리 팀의 서비스 '땅콩'에 적용하는 것으로 시작되었다.

레벨3 데모데이 피드백

레벨3를 마무리하면서 위와 같은 다양한 피드백을 받게 되었는데, 이 부분을 개선하면서 사용자 경험을 발전시키기 위해 노력했다.

(그런데 대부분 프론트엔드 측의 개선사항이어서 마루,포메,썬데이가 너무 고생해줬다.. 우리팀 프엔 최고..!)

부족한 부분을 개선해나감으로써 레벨4 데모데이에서 사용자들의 반응을 다시 살펴보고 더 나은 방향으로 서비스를 개선시켜나가고자 하였다.

레벨3 이후 팀의 변화 측정

레벨3는 프로젝트만 진행했지만, 레벨4는 과제/프로젝트/취준/스터디 등 정말 다양한 업무 병행이 이루어진 레벨이었다.

결국 레벨4는 시간 분배가 정말 중요한 레벨이었기에 프로젝트 참여가 필수는 아니었는데 이러한 부분에 대해서 팀에 생긴 변화에 대한 측정을 갖는 시간을 코치님들이 마련해주셨다.

땅콩 팀의 긍정/부정 변화

레벨3 동안 대체적으로 긍정적이었던 우리팀은 부정적인 변화도 꽤 많이 발생했었다.

일단 다른 영역의 팀원들과의 '소통'이 많이 줄어들었다.

우리 팀은 적절한 시간 분배를 위해 신기능 개발은 하지 않고 '데모데이 피드백 반영' 작업만 주로 수행하였다.

때문에 함께 함께 모여서 작업할만한 일이 거의 없었다.

또 바빠지면서 다함께 회식하고 즐길 수 있는 시간이 없어서 많이 아쉬웠다.

개인만의 시간이 거의 없던 우리 팀에 필요했던 변화였을지도 모르겠으나, 너무 친했던 우리 팀에는 조금은 어색한 변화였다.

어쩌다 찍은 측정 기념사진ㅋㅋ

취업 준비와 미션 수행

레벨4는 인프라 설계 미션, MVC 설계 미션, Spring 설계 미션 등등 난이도가 있는 미션들이 다수 주어진다.

이 와중에 나는 몇 곳에 서류합격을 하게 되어 '플젝 / 취준 / 스터디(2개) / 미션' 이라는 말도 안되는 일정을 소화하게 됐다..

토스뱅크 취준

여러 기업에 합격해서 면접을 보러 가기도 했고 최종 합격도 했지만, 그 중에 가장 가고 싶은 것은 토스뱅크였다.

레벨4에는 토뱅의 기술면접이 겹쳐있었는데 준비 기간이 거의 한 달 가까이 되어서 레벨4 전체가 토뱅 취준기간이었다.

지옥같은 일정 속에서 취업 준비까지 하느라 너무 힘들었다.

하지만 학습한 내용들을 돌아보고, 그 중에 문제점을 발견하고 개선해나가는 경험들을 바탕으로 유익하고 즐거운 시간도 많이 보낼 수 있었다.

함께 서류 합격했던 초코칩, 페드로와 함께 모의면접을 바탕으로 기술 면접을 준비했는데 이것도 너무 즐거운 시간이었다.

레벨4 기간동안은 기술 면접 합격 결과를 얻을 수 있었는데, 그 어려운 토스에서 기술적으로 인정받았다는 것이 너무나 자랑스러웠던 기억이 난다.

자세한 토스뱅크 취준 기록이 궁금하다면 여기

포비와의 면담

레벨4에선 한 번도 제대로 대화해보지 못했던 포비와 면담을 신청했다.

포비와 같이 개발자로서 많은 경험을 겪어오신 분과 대화해볼 기회는 우테코를 하고 있을 때 뿐이라고 생각했다.

포비와의 면담에선 항상 고민거리였던 '나만의 성장 방식 찾기'에 대해서 얘기를 주고 받았다.

우테코를 하며 내가 개발하는 방식을 확립할 수 있었다.

나는 필요한 부분에 대한 공부만 하는 것을 즐긴다. 지금 당장 필요하지 않은 부분에 대해 공부할 때는 공감이 가지 않아 지루함을 느낀다.

필요한 것만 학습해서 사용하는 좋은 습관같지만, 학습해오는 과정에서 이 방식에는 문제가 있다는 걸 깨달았다.

'필요한 것만 학습함 -> 경험하지 못한 부분에 대해서는 지식 공백 발생' 이라는 사이클이 무한 반복되어 성장에 한계를 경험하고 있었다.

포비는 이러한 문제에 대해서 정말 쉬운 해결책을 제시해주었다.

"그럼 한 번 상상해보세요."

간단한 답변이었지만, 명료한 해결책이었다.

내가 아직 경험하지 못한 부분을 경험했다고 상상하고 그 문제를 해결하기 위한 다양한 방법들을 고민해보면 나의 성장에 큰 도움이 될 것 같다는 것이었다.

명쾌한 답변이었고 바로 시도해보았다. 그리고 정말 많은 도움을 얻을 수 있었다.

포비와의 DM

그리고 포비에게 면담 이후 얻은 인사이트를 바탕으로 실험해본 내용과 결과를 공유드렸다.

포비도 만족해하셨고 나도 너무 만족스러운 면담이었다.

만약 우테코를 하게 된다면 꼭!! 포비와의 면담을 가져보길 바란다.

6차 데모데이 (마지막 데모데이)

마지막 데모데이인 6차 데모데이는 레벨3의 4차 데모데이와 같이 부스 운영을 하게 된다.

우리 팀은 부스 운영에 필요한 여러 작업들을 TF를 구성하여 착실히 수행해 대비했다.

'현수막 제작', '부스 운영 기획', '질문 검수', '굿즈 제작' 등 여러 작업들을 병행했는데, 전부 중요한 작업들이었다.

땅콩 데모데이 부스

현수막 재밌다고 칭찬 많이 받았고, 부스 운영 잘해서 사람이 가장 많이 왔고, 질문 검수 잘 해서 재미있다고 피드백 많이 받았다!

실제로 우형 개발자 밋업에서 사용된 '땅콩'

심지어 우형에서 오신 직원분들이 너무 재미있다고 개발자 밋업에서 사용하시겠다고 링크를 따가셨다..!

우리팀 진짜 최고다.

땅콩 굿즈

우리팀 굿즈는 이렇게나 귀여운 스티커다.

우리 서비스 캐릭터 '땅콩이'의 다양한 모습으로 스티커를 만들어서 주문했다.

인기가 꽤나 많아서 100개 만들었는데 다 털렸다.

스티커 제작 과정에서는 파일 형식과 관련해서 몇몇 문제가 있었는데, SOPT 라이온하트팀에서 만난 참 아끼는 디자이너 동생이 도와줘서 문제를 해결할 수 있었다. 어려운 문제들을 슥삭 해결해버리는 디자이너들이 참 대단한 것 같다고 다시 한 번 느꼈다.

포비와 매칭도 100%

부스에 방문해주신 포비와 같이 땅콩을 했는데, 밸런스 게임 질문에 대한 매칭도가 100%가 떠서 기념 사진도 남겨두었다ㅋㅋ

천하제일 땅콩 그리기 대회

우리 서비스의 캐릭터 이름은 '땅콩이' 이다.

이유는 모르겠다만 꽤나 인기가 많았는데 부스 뒤에서는 은밀하게 '천하제일 땅콩이 그리기 대회'도 진행되고 있었다.

근육 땅콩들 대체 누가 그렸을까..

땅콩팀 단체사진

땅콩팀 단체사진을 마지막으로 우테코 레벨4 회고를 마치겠다.

너무 고생한 땅콩팀 최고에요! 땅콩 포에버~!

Certbot을 사용한 Nginx SSL 인증서 등록 및 자동 갱신 설정 방식

PgmJUN — Thu, 28 Nov 2024 13:42:14 +0900

설정 이유

기존에 인증서 흭득에 사용했던 certbot standalone 방식은 80번 포트에 직접 "독립형" 웹서버를 사용하여 인증서를 갱신하는 방식이다.

하지만 Nginx같이 80번 포트를 사용하는 웹서버가 떠있는 경우 사용이 불가능하다.

이전에는 Nginx를 사용하지 않아 standalone을 적용했지만, 이제는 Nginx를 사용하는 환경이기 때문에 다른 설정이 필요해졌다.

사전 작업

1. Gabia DNS 설정

땅콩 서비스는 도메인 주소를 Gabia에서 구매했기 때문에 Gabia에서 설정을 건드리게 됐다.

DNS 관리툴에 들어가서 DNS 설정을 클릭한다.

Gabia - DNS 관리툴 - DNS 설정

그리고 A 레코드 : 서브 도메인 : EC2 IPv4 주소 를 입력해서 기본 설정을 수행한다.

2. Nginx 설치

sudo apt-get update
sudo apt-get install nginx

apt-get update 후 Nginx 설치

Nginx 연결 설정

sudo vi /etc/nginx/sites-available/default

default 파일에 연결 설정 수행

설정 전) /etc/nginx/sites-available/default

server {
        listen 80; 
        location / { 
                return 302 https://$host$request_uri;
        }
}

server {
        listen 443;
        server_name your_domain; # 본인의 도메인 주소 설정

        location / { 
                proxy_pass <http://127.0.0.1:8080>;  # 8080번 포트로 요청 전달
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        }
}

위와 같이 기본 설정을 수행

설정 과정

1. certbot 설치

sudo apt-get install python3-certbot-nginx

nginx 인증서 흭득이 가능한 certbot을 설치

2. 인증서 흭득

certbot Nginx를 통해 인증서를 얻고 설정

# nginx를 사용해서 인증서를 관리하는 nginx certbot
sudo certbot --nginx

nginx를 사용하는 인증서 등록 명령어이다.

해당 명령을 입력하면 ssl 인증서 관련 알림을 받을 'Email' , SSL 설정을 수행할 '도메인 주소'를 입력하라고 한다.

잘 입력해주면 관련 설정은 끝난다.

만약 Rollback이 필요하다면?

sudo certbot --nginx rollback --nginx

공식 문서에서는 설정을 되돌릴 수 있는 롤백 명령어도 제공한다.

만약 Nginx default 파일의 설정이 예상과 다르게 망가진 경우 사용하면 좋을 것 같다.

설정 후) /etc/nginx/sites-available/default

server {
        listen 80;

        return 302 https://$host$request_uri;
}

server {
				listen 443 ssl; # managed by Certbot
        server_name your_domain;

        ssl_certificate /etc/letsencrypt/live/api.dev.ddangkong.kr/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/api.dev.ddangkong.kr/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot     

        location / {
                proxy_pass <http://127.0.0.1:8080>;  # 8080번 포트로 요청 전달
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        }
}

자동 설정 후에 내가 조금 조정해준 default 파일(기본 서버 블록 설정 파일)이다.

웬만한 경우, 이대로 사용하면 문제없이 사용할 수 있을 것이다.

3. HTTPS 정상 동작 확인

설정 이후에는 위와 같이 https 요청이 정상적으로 수행된다.

인증서 자동 갱신 설정

User Guide — Certbot 3.1.0.dev0 documentation

공식 문서를 보면 SSL 인증서 갱신을 자동화시킬 수 있는 방안도 제시하고 있다.

바로 인증서 renew 명령어와 crontab 을 활용한 방안이다.

1. cron 설정 명령

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

위 명령은 공식문서에서 제공한 crontab 설정 명령어이다.

/etc/crontab

위 명령을 쉘에 입력하면 다음과 같이 자동으로 crontab 설정이 완료된다.

왜 0~3600초를 랜덤하게 대기하고 실행하는 지는 잘 모르겠다만 아마도 하나의 인증서를 여러 서버에서 갱신하는 경우 Rate Limit에 의해 갱신 요청 수가 초과되어 갱신이 되지 않는 문제를 막기 위함일까 싶다.

2. cron 재시작

sudo systemctl restart cron
sudo systemctl status cron

정상적으로 동작하도록 해주기 위해 cron을 재시작한다.

여기까지 완료되었다면 문제없이 지속적으로 HTTPS 통신을 이용할 수 있다.

AWS IAM Region 제한하기

PgmJUN — Tue, 26 Nov 2024 21:44:15 +0900

우테코 수료일이 다가오면서, 우테코에서 제공했던 AWS 계정 만료일도 코 앞으로 다가왔다.

때문에 우리 팀 계정으로 서버를 이관하기 위해 사전 작업을 수행하는 과정에서 IAM 관리자 사용자에 Region 제한 설정을 하게 되어 글로 남겨보려고 한다.

문제 상황

AWS에서 솔루션을 이용하다보면 실수로 타 리전을 이용하고 있었던 경험이 한 번쯤은 있을 것이다.

이런 문제가 발생하면 사용할 리전에 동일한 설정을 반복해야하는 문제가 있고,

거의 그럴 일은 없겠지만 타 리전에 실수로 만든 것을 모르고 넘어가게 된다면 비용 문제로도 이어진다.

이를 해결하고자 사용할 IAM 사용자에 권한 정책 설정을 통해 서울 리전만 사용 가능하도록 설정해보고자 했다.

설정 과정

사용할 IAM에 권한 추가 - 인라인 정책 생성 선택

그리고 위 권한 지정 탭의 내용을 아래 코드와 같이 설정한다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "*",
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:RequestedRegion": [
						"ap-northeast-2"
					]
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": [
				"iam:*",
				"cloudfront:*",
				"s3:*"
			],
			"Resource": "*"
		}
	]
}

위 권한 설정 값은 AdministratorAccess 권한에 서울(ap-northeast-2) 리전 제한을 걸어둔 것이다.

AdministratorAccess 라는 권한은 관리자 직무 IAM에게 설정하는 권한이다.

AWS 계정 내 모든 리소스와 서비스에 대해 무제한 액세스 권한을 가지도록 설계된 정책인데,

"Action": "*" 는 모든 AWS 서비스의 모든 작업을 허용을 뜻하고

"Resource": "*" 는 모든 리소스에 대한 접근을 허용을 뜻한다.

관련 내용은 공식 문서에 적혀있다.

IAM, CloudFront, S3는 왜 모든 리전에서 허용해주는가?

{
	"Effect": "Allow",
	"Action": [
		"iam:*",
		"cloudfront:*",
		"s3:*"
	],
	"Resource": "*"
}

이 권한 설정은 의아할 것이다.

IAM, CloudFront, S3는 Global한 솔루션이기 때문에 ap-northeast-2에 대해서만 설정해주었을 때 리전 관련 오류가 발생했다.

때문에 해당 솔루션들은 따로 빼서 리전 설정을 해주지 않았다.

위 권한의 이름은 AdministratorAccessOnlySeoul 로 설정해주었다.

이를 통해 서울 리전에 한정된 어드민 권한을 설정할 수 있다.

Kotlin 코드를 Java 코드로 디컴파일(Decompile) 하는 방법

PgmJUN — Sat, 23 Nov 2024 16:03:36 +0900

문제 상황

자바 코드를 코틀린 코드로 마이그레이션 하는 과정에서 "이거 자바 코드로 바꾸면 어떻게 되지?" 라는 의문이 들었다.

특히 상수 선언 방법이 2개인 코틀린에서 companion object, const 를 각각 사용하여 상수 선언 시

둘의 결과는 같은 지, 아니면 내가 아는 것과 조금 다르게 동작할 지에 대한 의문으로 디컴파일 방법을 탐색하여 알게 되었다.

Kotlin to Java 디컴파일(Decompile)이란?

Kotlin 을 Java로 디컴파일 한다는 것은

Kotlin으로 작성된 언어를 .class 파일로 컴파일한 다음, 다시 Java로 디컴파일을 수행한다는 것을 의미한다.

결국 Kotlin으로 작성된 코드가 Java로 보면 어떤 지 확인할 수 있기 때문에 Java -> Kotlin 마이그레이션 상황에서 굉장히 유용하게 사용할 수 있다.

방법

IntelliJ는 JetBrains에서 만들었다.

Kotiln 또한 JetBrains에서 만든 언어이다.

때문에 JetBrains에선 Kotlin 언어에 대한 지원이 풍족한데, 이 기능 또한 IntelliJ에서 제공하는 기능이다.

IDE 화면에서 shift를 2번 연속으로 누르게 되면 위와 같은 입력창이 나타난다.

여기서 show kotlin bytecode 를 검색하게 되면 위와 같은 기능이 보여진다.

한 번 선택해보자.

그럼 위와 같이 화면 우측에 Decompile 버튼이 나타나는데, 클릭해보자

(좌) Kotlin 코드 / (우) Decompile된 코드

그럼 위와 같이 Kotlin 코드가 class 파일로 컴파일되었다가, 다시 Java 코드로 디컴파일된 위와 같은 결과를 얻을 수 있다.

이를 통해 내가 작성한 Kotlin 코드가 Java에선 어떨지 확인하여 내가 의도한 코드가 맞는 지 확인하면서 마이그레이션을 진행할 수 있게 된다.

Kotlin에서의 상수 선언 (feat. const와 static final의 차이)

PgmJUN — Sat, 23 Nov 2024 15:47:20 +0900

문제 상황

자바 코드를 코틀린으로 마이그레이션 하는 과정 중, 상수 선언 과정에서 문제 상황을 겪게 되었다.

public class SampleClass {
    private static final DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss");
    //...
}

자바에서 객체를 static final을 통해 상수로 선언하는 것은 일반적으로 가능한 일이다.

private const val DATE_TIME_FORMATTER: DateTimeFormatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss")

class SampleClass(

하지만 상수 선언 로직을 코틀린으로 마이그레이션하는 과정에서 컴파일 에러를 마주할 수 있었다.

const 키워드에 위와 같이 primitives and String 타입만 허용된다는 에러 메시지가 나타난 것이다.

const 키워드

문제 해결 전, const가 무엇인지부터 먼저 알아보자.

const는 자바의 static final 과 동일한 상수 선언 역할을 수행한다.

만약 const로 선언해둔 상수에 변경을 시도하면 위와 같은 컴파일 에러가 발생할 것이다.

알고가면 좋은 점1) Kotlin final과 Java final의 차이

자바에서는 static final이 상수 선언이었는데 그럼 코틀린에서의 final은 뭘까?

코틀린 final의 역할은 불변이 아닌 상속을 불가능하게 만드는 역할을 수행한다.

메서드나 클래스 옆에 final 키워드를 붙이게되면 상속이 불가능해지며, 코틀린은 기본적으로 final이다.

때문에 JPA를 사용할 때 Entity 객체는 직접 open 키워드를 붙여서 상속을 열어주거나,
Plugin을 사용해서 JPA 관련 객체 (MappedSuperclass, Entity 등) 에 open을 자동으로 붙여주는 등의 추가적 설정이 필요하다.

알고가면 좋을 점2) val과 const의 차이

val과 const의 차이도 간혹 헷갈려하는 사람이 있는 것 같아 적는다.

[할당되는 메모리 공간]

우선 할당되는 JVM의 메모리 공간부터 다르다.

const는 글로벌한 상수로 JVM 런타임 데이터 영역(Runtime Data Area) 중 Method 영역에 할당된다.

하지만 val로 선언된 프로퍼티는 객체의 인스턴스가 생성될 때마다 매번 같은 값이 Heap 영역에 새로 할당된다는 차이점이 존재한다.

[상수와 변수]

const는 상수로 단 하나만 선언되어있고 글로벌한 값이기 때문에 여러 클래스에서 공유해서 사용된다.

반면 val는 setter를 막아 불변 설정만 되어있는 read-only 변수이다. 주생성자를 통해 주입받아 클래스마다 다른 값을 가지기도 한다.

원인

const가 뭔지는 알았는데, 그럼 const를 사용하면 왜 Primitive Type과 String만 선언이 가능할까?

그 이유는 const 키워드는 컴파일 시점에 값을 할당하기 때문이다.

컴파일 시점에는 객체의 인스턴스가 생성되지 않았기 때문에 참조 타입 등의 인스턴스를 상수로 정의할 수 없는 것이다.

자바의 static final은 런타임 시점을 지원했지만, 코틀린의 const는 그렇지 않다.

때문에 String, Primitive Type만 const를 통한 상수 선언이 가능한 것이다.

해결 방안

private const val CONST_STRING = "const"

class SampleClass(
) {
    companion object {
        private val COMPANION_STRING = "companion"
    }
}

코틀린에서 상수를 선언하는 방법은 2가지가 있다.

1. const 키워드를 통해 클래스 최상위에 상수를 선언하는 방법

2. companion object를 통해 내부 클래스를 만들어 선언하는 방법

객체를 상수로 선언하기 위해서는 const가 아닌 companion object를 사용하는 방법을 선택해야한다.

한 번 자세히 알아보자.

동반 객체 (companion object) 활용하기

class SampleClass(
) {
    companion object {
        private val DATE_TIME_FORMATTER: DateTimeFormatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss")
    }
}

companion object를 활용하면 이처럼 DateTimeFormatter 와 같은 객체도 상수로 선언하는 것이 가능하다.

Kotlin to Java 디컴파일(decompile)을 통해 결과 확인해보기

IntelliJ의 유용한 기능인 Kotlin to Java 디컴파일(decompile)을 통해서 정말 static final로 선언이 되는지 확인해보았다.

IntelliJ Kotlin to Java 디컴파일(decompile) 사용법 알아보기

결과는 위와 같이 DateTimeFormatter가 정상적으로 상수 선언되었다.

결론

앞으로 객체를 상수로 등록해야하는 지금과 같은 상황이 있다면 companion object 를 활용해보려고 한다.

다만 상수 객체가 존재하는 경우에는 companion object에 상수가 정의되고, 그렇지 않은 경우에는 const로 정의되는 등 지저분한 코드가 발생되는 것을 우려하여 개인적으로 다음과 같은 규칙을 정의했다.

코틀린 상수 선언 규칙

1. 상수 객체는 companion object에 정의

2. Primitive Type & String은 클래스 최상위에 const로 정의

private const val CONST_STRING = "const"

class SampleClass(
) {
    companion object {
        private val DATE_TIME_FORMATTER: DateTimeFormatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss")
    }
}

그럼 결론적으로 위와 같은 코드가 만들어질 것이다.

만약 더 좋은 방안이 있다면 댓글로 남겨주면 참고해보겠습니다!

Kotlin에서 Lombok 적용이 안되는 이유 (feat. 코틀린 Slf4j)

PgmJUN — Fri, 22 Nov 2024 15:09:26 +0900

문제 상황

왓캠퍼스 프로젝트를 Java/Spring -> Kotlin/Spring 으로 마이그레이션 하는 과정에서 하나의 문제를 마주했다.

바로 'Kotlin 코드에서 Lombok 적용이 안 된다는 점' 이었다.

이에 따라 간편한 로깅을 위해 사용하던 Lombok의 @Slf4j 애노테이션까지 사용이 불가능해졌다.

때문에 로깅을 해야하기도 하고, 이유도 궁금해서 해당 문제의 원인에 대해 찾아보게 되었다.

Lombok이란?

Lombok 공식문서의 소개에 따르면 Lombok은 아래와 같은 라이브러리이다.

Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java.
Never write another getter or equals method again, with one annotation your class has a fully featured builder, Automate your logging variables, and much more.

"Project Lombok은 편집기와 빌드 도구에 자동으로 플러그인되는 Java 라이브러리로, Java를 더욱 즐겁게 해줍니다.
다시는 getter나 equals 메서드를 쓰지 마세요. 하나의 주석으로 클래스에 모든 기능을 갖춘 빌더가 생깁니다. 로깅 변수를 자동화하고, 훨씬 더 많은 작업을 할 수 있습니다."

즉 Lombok이란 Java의 Getter, Setter, Eqauls&Hashcode, LoggingFactory 등과 같은 매번 작성해야하는 보일러플레이트 코드를 애노테이션 설정을 통해 간편화 시켜주는 라이브러리이다.

Slf4j란?

Slf4j란 Simple Logging Facade for Java의 약자이다.

로깅 프레임워크의 추상화 계층으로, 프레임워크의 종류에 상관없이 일관된 코드로 로깅을 할 수 있도록 해준다.

Logback, Log4j, java.util.logging 등 다양한 로깅 프레임워크와 연동 가능하게 설계되어있다.

(참고로 스프링부트에서 사용되는 기본 로깅 프레임워크 구현체는 Logback이다)

@Slf4j 란?

@Slf4j는 Lombok에서 제공하는 애노테이션이다.

Slf4j를 사용하기 위해 필요한 보일러플레이트 코드를 애노테이션을 통해 Lombok이 컴파일 시점에 대신 작성해준다.

@Slf4j
class Sample {
	private val log = LoggerFactory.getLogger(this::class.java)
	//...
}

원래는 로깅을 위해 위와 같은 코드를 직접 작성해야 했다면

@Slf4j
class Sample {
	//...
}

Lombok을 사용하면 위와 같이 애노테이션만으로 손쉽게 보일러플레이트 코드를 제거할 수 있도록 만들어준다.

원인 분석

그럼 이렇게 간편한 Lombok의 @Slf4j 애노테이션을 사용해서 쉽게 Kotlin 코드에서도 로깅을 하려했으나 실패한 이유는 무엇일까?

이는 'Lombok이 어떻게 동작하는 지' 와 'Java, Kotlin의 컴파일 과정의 차이' 에 대해서 이해하면 빠르게 이해할 수 있다.

Lombok은 javac의 컴파일 과정 중 Annotation Processing 과정에서 클래스에 선언된 Lombok 애노테이션을 바탕으로 실제 코드를 작성해주는 방식으로 동작한다.
Kotlin은 Java의 컴파일러인 Javac와는 별도의 컴파일러인 Kotlinc를 사용하며, Kotlinc는 Javac보다 먼저 컴파일을 수행한다.

위 2가지 사실을 바탕으로 문제의 원인을 분석해보자.

Annotation Processing 등의 Javac의 동작 과정에 대해 자세히 알고 싶다면 이 글을 참조하자

Kotlin 코드에서 Lombok 적용이 안 된 이유

Javac의 동작 과정 중 Annotation Processing 과정에서 Lombok의 보일러플레이트 처리 작업이 수행된다고 했다.

또한 Kotlinc가 Javac보다 더 먼저 동작한다고 했다.

때문에 Kotlinc의 컴파일 시점에는 Lombok에 의한 코드가 작성되지 않는다.
이로 인해 Lombok 애노테이션으로 아무리 선언하더라도 적용이되지 않던 것이었다.

단독으로 Kotlin만 사용하는 경우에도 마찬가지로 Javac가 동작할 일이 당연히 없으니, Lombok을 사용할 수 없다.

정말 그럴까?

내가 해보기 전까진 믿지 않는다. 직접 테스트해서 결과를 얻어보자.

먼저 자바부터 실험해보자.

실제로 @Getter를 설정해둔 Campus.java 를 컴파일하게 되면

위와 같이 Getter들이 생성되는 것을 알 수 있었다.

해당 내용은 build 이후 생성되는 build - classes 패키지의 .class 파일을 통해 확인할 수 있다.

이번엔 코틀린으로 실험해보겠다.

똑같이 @Getter를 선언해둔 Member.kt 파일을 컴파일하는 경우

위와 같이 별도의 Getter 메서드는 생성되지 않은 것을 확인할 수 있었다.

@Slf4j 와 같은 애노테이션도 마찬가지였다.

문제 해결

1. Kotlin Lombok Plugin (실패)

문제 해결을 위해 코틀린 공식문서를 찾아보는 과정에서 Lombok 관련 Kotlin의 플러그인이 있는 것을 발견했다.

공식문서에서는 Kotlin에서 Lombok을 사용할 수 있도록 도와주는 Plugin을 제시하고 있으나,
완벽한 버전은 아니며 아직은 모든 Lombok 애노테이션이 호환되고 있지는 않는다고 한다.

아쉽게도 여기에 @Slf4j 애노테이션은 없었다.

궁금한 사람은 해당 공식문서 링크를 참조하자

2. Logger 흭득 코드 직접 작성

class SampleClass {
    private val log = LoggerFactory.getLogger(this::class.java)
    //...
}

@Slf4j 애노테이션 없이, Logger를 흭득하려면 위와 같이 로그를 찍는 모든 클래스마다 일일히 LoggerFactory 코드를 작성해주어야 한다.

하지만 이는 너무 번거롭고 복잡하지 않은가.

@EnableScheduling
@SpringBootApplication
class SampleClass

inline fun <reified T> T.logger() = LoggerFactory.getLogger(T::class.java)!!

fun main(args: Array<String>) {
    SpringApplication.run(SampleClass::class.java, *args)
}

이 문제는 최상위 클래스 Application 클래스에 inline, reified 키워드를 통한 LoggerFactory.getLogger() 함수를 선언해주어 문제를 해결할 수 있다.

class SampleClass {
	private val log = logger()
    //...
}

위와 같이 선언해두게 되면, 하위 클래스에서 위와 같이 간단하게 logger를 흭득하여 사용할 수 있다.

inline 키워드

Kotlin에서의 함수는 일급 함수이다.

컴퓨터 과학에서 프로그래밍 언어는 함수를 일급 객체로 취급하는 경우 일급 함수(first-class function)를 갖는다고 한다. 이는 언어가 함수를 다른 함수에 대한 인수로 전달하고, 이를 다른 함수의 값으로 반환하고, 변수에 할당하거나 자료 구조에 저장하는 것을 지원한다는 것을 의미한다.[1] 일부 프로그래밍 언어 이론가들은 익명 함수(함수 리터럴)에 대한 지원도 요구한다.[2] 일급 함수를 사용하는 언어에서는 함수 이름에 특별한 상태가 없다. 이는 함수 유형의 일반 변수처럼 취급된다

위키피디아 (https://en.wikipedia.org/wiki/First-class_function)

자바의 함수형 프로그래밍을 사용해봤다면 함수를 저장할 수 있는 Supplier, Consumer 등의 객체를 알고 있을 것이다.

일급이라는 의미는 함수의 결과로 함수를 return하거나, 변수에 함수가 할당되는 등 함수가 일반 변수처럼 취급되는 것을 의미한다.

private val log = logger()

이러한 이유로 위와 같은 코드를 그냥 사용하게 되는 경우 logger() 함수를 저장하기 위한 메모리 공간이 필요해지는 등 오버헤드가 발생하게 된다.

이러한 단점을 해결하기 위해 inline 키워드가 존재한다.

logger() 함수에 inline 키워드를 사용하게 되면 logger()가 일급 함수로서 특정 메모리 공간에 할당되는 것이 아니라 코드로 작성되어 컴파일된다.

그럼 logger() 함수 호출 시점에 호출한 함수를 찾아서 동작을 수행시키고 return 받은 값을 가져와 메모리 공간에 올리는 등의 오버헤드를 제거할 수 있게 된다.

반면, 바이트코드의 크기가 커지는 등의 단점도 존재한다.
자세한 내용은 공식문서 참조

reified 키워드

reified 키워드는 inline함수에만 사용할 수 있으며,

제네릭을 사용해서 함수를 호출 시 매개변수로 Class 정보를 전달하는 것보다 더 쉽고 간편한 방법을 제공합니다.

제네릭과의 차이점은 타입 소거가 발생하지 않는다는 점이다.

fun <T> isString(value: T): Boolean {
    return value is String // 경고: 'Unchecked cast'
}

제네릭은 런타임 시점에 타입 정보가 제거되는 타입 소거가 발생한다.

JVM은 모든 제네릭 타입을 기본적으로 Object 로 간주한다.

때문에 런타임에는 타입 체크가 불가능하다.

inline fun <reified T> isInstance(value: Any): Boolean {
    return value is T // 런타임에 T 타입 체크 가능
}

println(isInstance<String>("abc")) // true
println(isInstance<Int>("abc"))    // false

반면 reified를 사용하면 제네릭 타입 정보를 런타임에도 유지하도록 만들어서 제네릭의 타입 소거 제한을 우회할 수 있다.

제네릭만 사용했을 경우

제네릭만 사용해서 logger() 메서드를 구현하는 경우,

런타임 시점에 호출되는 메서드이기 때문에 컴파일 시점 이후 타입 소거가 발생하는 제네릭으론 구현이 불가능하다.

inline, reified를 사용했을 경우

반면 inline, reified는 타입 소거가 발생하지 않기 때문에 이렇게 에러가 나지 않는다.

좀 더 자세한 내용은 공식문서 참조

3. Kotlin-Logging 사용

GitHub - oshai/kotlin-logging: Lightweight Multiplatform logging framework for Kotlin. A convenient and performant logging facad

Lightweight Multiplatform logging framework for Kotlin. A convenient and performant logging facade. - oshai/kotlin-logging

github.com

Kotlin-Logging 을 사용하는 방식도 하나의 해결책으로 존재한다.

내부적으로 SLF4J API를 사용하여 다른 로깅 프레임워크와 호환되며, logback Xml 파일을 만들어 로깅을 커스터마이징하는 것도 가능하다.

사용법

private val logger = KotlinLogging.logger {}

위와 같이 가볍고 간단하게 KotlinLogging.logger {} 만 입력하면 logger를 흭득할 수 있다.

logger.debug { "Some $expensive message!" }

기존 사용하던 로깅 방법과는 다르게 중괄호를 사용해서 로깅한다는 차이점이 존재한다.

장점

가장 큰 장점은 로깅 시에 로그 수준 활성화 체크를 자동으로 해준다는 점이다.

만약 로깅을 할 때, 로그 수준 활성화 체크를 처리하지 않으면 오버헤드가 발생할 수 있다.

logger.debug("User data: " + user.toString());

예를 들어 위와 같이

로그 내용에 객체가 담겼을 경우 출력할 수 있는 형태로 변경하는 비용, 문자열 연산이 존재할 경우 해당 연산 비용 등이 존재한다.

또한 사용되지도 않을 데이터에 대해서 메모리 할당, GC 등 자원 사용까지 오버헤드에 포함된다.

logger.debug { "Some $expensive message!" }

반면 kotlin-logging 프레임워크를 사용하면 위와 같은 로깅 로직이 존재할 때

// This is what happens when you write the above ^^^
if (logger.isDebugEnabled) logger.debug("Some $expensive message!")

위와 같이 로그 수준 활성화에 대한 검사를 자동으로 처리해준다는 이점이 있다.

자세한 내용은 공식 깃허브 참조

결론

개발에 정답은 없다. 다만 트레이드 오프는 존재한다.

여러 기술들의 트레이드 오프를 고려해서 프로젝트 상황에 가장 적합한 방식을 사용하자!

[Java] Javac의 동작 과정은 어떻게 될까?

PgmJUN — Thu, 21 Nov 2024 01:44:52 +0900

문제상황

Java/Spring을 Kotlin/Spring으로 마이그레이션 하는 과정에서 Kotlin의 Lombok 사용에 어려움을 겪었다.

그리고 그 이유 Lombok이 Javac의 Annotation Processing 과정에서 처리되는데, Javac보다 Kotlinc가 더 먼저 작동하여 Javac에서 Annotation Processing 과정을 통해 생성되는 코드를 Kotlin 코드에서는 알 수가 없기 때문임을 알게 되었다.

이 과정에서 Javac의 Annotation Processing을 포함한 전반적인 과정을 흝어보고 싶어 학습하여 기록해 두게 되었다.

javac의 동작 과정

javac의 동작과정에 대해 자세히 파헤쳐보자.

javac는 대략 아래 7가지 단계로 컴파일을 수행한다.

1. Parsing: 소스 코드를 읽고 AST 생성.

2. Annotation Processing: 애노테이션 처리 및 코드 생성.

3. Semantic Analysis: 타입 검증과 의미 분석.

4. Intermediate Code Generation: 중간 코드 생성.

5. Optimization: 코드 최적화.

6. Bytecode Generation: 바이트코드 생성.

7. Class File Output: .class 파일 저장.

1. Parsing (구문 분석)

Javac는 입력받은. java파일의 소스 코드를 읽고, 이를 추상 구문 트리(Abstract Syntax Tree, AST)로 변환한다.

세부내용

• 토큰화(Tokenization): 코드의 각 요소를 토큰으로 나눈다. (ex. public class HelloWorld → [public] [class] [HelloWorld])

• 구문 분석(Syntax Analysis): 토큰을 기반으로 코드 구조를 파악하고, AST를 생성한다.

• 이 단계에서 구문 오류(Syntax Error)를 발견하면 컴파일이 중단된다.

2. Annotation Processing (애노테이션 처리)

@Override, @Deprecated, 또는 사용자 정의 애노테이션(예: Lombok) 등을 처리한다.

세부내용

• Annotation Processor가 등록된 애노테이션에 대해 지정된 작업을 수행한다.

• Lombok 라이브러리는 이 단계에서 보일러플레이트 코드를 생성한다.

• 출력: 수정된 AST 또는 추가 생성된 파일(예: 자동 생성된 클래스).

3. Semantic Analysis (의미 분석)

코드의 의미를 검증한다.

세부내용

• 변수나 메서드가 선언된 위치와 호출 위치를 연결한다.

• 타입 체크(Type Checking): 변수와 메서드 호출이 올바른 타입으로 사용되는지 확인한다.

• 이 단계에서 발견된 오류는 컴파일 에러로 표시된다.

4. Intermediate Code Generation (중간 코드 생성)

AST를 바탕으로 JVM이 이해할 수 있는 중간 표현(Intermediate Representation, IR)을 생성한다.

세부내용

• 이 단계는 소스 코드를 바이트코드로 변환하기 위한 중간 단계로, 구체적인 JVM 명령어로 변환되지 않았지만 구조가 더 단순화된 상태이다.

5. Optimization (최적화)

생성된 중간 코드를 최적화한다.

세부내용

• 중복된 연산 제거.

• 불필요한 코드 제거.

• 더 효율적인 명령어로 대체.

• 이 단계는 JVM의 Just-In-Time(JIT) 컴파일러 최적화보다는 덜 강력하지만, 일부 성능 최적화를 수행한다.

6. Bytecode Generation (바이트코드 생성)

최적화된 중간 코드를 JVM에서 실행될 수 있는 바이트코드(.class 파일)로 변환한다.

7. Class File Output (클래스 파일 출력)

최종적으로 생성된 .class 파일을 디스크에 저장한다.

Test Fixture Factory 구현을 통한 테스트 코드 가독성, 생산성 개선

PgmJUN — Thu, 14 Nov 2024 22:24:43 +0900

문제 상황 정의

생산성 저하

우리 팀에서는 땅콩 개발 초기에, 테스트 코드를 작성할 때 위와 같은 init-test.sql 파일을 사용했었다.

초반에는 위와 같이 사용함으로 인해 테스트 코드 작성 시에 굉장히 길어질 수 있는 데이터 초기화 로직을 제거할 수 있었다.
미리 init-sql에 정의되어 있는 값만 가져다가 사용하면 되어서 편리하다고도 생각했다.

하지만 위 방식에서는 문제점이 있었다.

데이터가 얼마 없을 때는 편리할 줄 알았으나
테스트 코드에서 사용할 데이터를 참조할 때 매번 init-test.sql 파일에 접근해서 사용할 데이터의 ID값을 확인해야하는 것이 굉장히 불편했다.

이로 인해 테스트 코드 작성의 생산성이 저하 되었다.

가독성 저하

생산성 저하로 인해서 잘 사용하지 않게 되자, 결국 테스트 코드는 점점 init-test.sql 파일을 사용하지 않았던 형태로 돌아가게 되었다.

그러다보니 위와 같은 코드가 나타나게 되었는데, 매번 직접 테스트 코드에 필요한 데이터를 테스트 코드에 작성해주고 있으니
이번에는 가독성에 이어 생산성이 함께 저하 되었다.

테스트 코드를 위해 열려있는 생성자

public static Room createNewRoom() {
        String uuid = UUID.randomUUID().toString().replace("-", "");
        return new Room(uuid, START_ROUND, RoomStatus.READY, RoomSetting.createNewRoomSetting());
}

비즈니스 로직에서 Room 생성은 정해진 비즈니스 규칙 에 따라 위와 같이 세팅된 특정 값으로 생성되어야 했다.
하지만 createNewRoom() 만 열어두게 되면 테스트 코드에서 특정 상태를 가진 Room 객체 생성이 불가능한 문제가 있었다.

public Room(String uuid, int currentRound, RoomStatus status, RoomSetting roomSetting) {
        this.uuid = uuid;
        this.currentRound = currentRound;
        this.status = status;
        this.roomSetting = roomSetting;
}

때문에 어쩔 수 없이 위와 같은 생성자를 하나 만들어서 다양한 형태의 Room 객체 생성을 가능하게 열어둔 상태였다.
이러한 문제점을 가지고 작성되어있는 테스트 코드가 약 230개 정도 있었고, 테스트가 더 늘어나기 전에 이를 처리 해야겠다고 생각했다.

문제 해결 방안 선정

문제 해결을 위해서 Test Fixture Factory 객체를 만들어서 사용하는 방법을 선택하게 되었다.

Test Fixture란?

테스트 픽스처(Test Fixture)는 테스트가 매번 일관성있게 작동할 수 있도록 환경을 준비하고 유지하는데 필요한 코드, 데이터, 설정 등을 의미한다.
나는 이러한 테스트 픽스처를 세팅해주는 Fixture Factory 객체를 만들어 테스트가 일관성있게 작동할 수 있는 환경을 쉽고 간편하게 구성할 수 있도록 개선해볼 생각이다.

Fixture Monkey

Fixture Monkey는 제어 가능한 임의의 테스트 객체를 생성하도록 설계된 Java 및 Kotlin 라이브러리이다.
이 기술도 사용해볼 수 있을 것 같았지만, 굳이 직접 처리할 수 있는 작업을 외부 라이브러리에 의존하고 싶진 않았다. 정말 없어선 안되는 것이 아니라면 최대한 외부 라이브러리 의존은 지양하고 있다. (직접 만들어서 쓰고 말지)
또 세부적인 Fixture 객체 값 컨트롤을 위해 그냥 직접 Fixture 클래스를 구현해서 사용하고자 하였다.

테스트 코드 개선

Fixture 관련 코드

Fixture를 생성하기 위한 코드로, 테스트를 위한 생성자 사용 문제 해결이 시급한 Room 을 기준으로 작성해보겠다.

RoomFixture.java

@Component
public class RoomFixture {

    private final RoomRepository roomRepository;

    public RoomFixture(RoomRepository roomRepository) {
        this.roomRepository = roomRepository;
    }

    public Room createNotStartedRoom() {
        return roomRepository.save(Room.createNewRoom());
    }
}

먼저 Room 픽스처를 생성하기 위한 RoomFixture 클래스를 생성하였다.

Room의 상태는 READY , PROGRESS , FINISH 가 존재한다.
그 중 READY 상태의 Room을 생성하기 위한 메서드 createNotStartedRoom() 을 먼저 만들어주었다.
이후에 필요에 따라 점점 픽스처 생성 메서드를 추가하면서 아래와 같이 변화되었다.

@Component
public class RoomFixture {

    private static final String CURRENT_ROUND_FIELD = "currentRound";
    private static final String STATUS_FIELD = "status";
    private static final String ROOM_SETTING_FIELD = "roomSetting";

    private final FixtureSettingManager fixtureSettingManager;
    private final RoomRepository roomRepository;

    public RoomFixture(FixtureSettingManager fixtureSettingManager, RoomRepository roomRepository) {
        this.fixtureSettingManager = fixtureSettingManager;
        this.roomRepository = roomRepository;
    }

    public Room createNotStartedRoom(int currentRound, int totalRound, int timeLimit, Category category,
                                     RoomStatus roomStatus) {
        RoomSetting roomSetting = new RoomSetting(totalRound, timeLimit, category);
        return createNotStartedRoom(currentRound, roomSetting, roomStatus);
    }

    public Room createNotStartedRoom(int currentRound, RoomSetting roomSetting, RoomStatus roomStatus) {
        Room room = Room.createNewRoom();
        setRoom(currentRound, roomSetting, roomStatus, room);
        return roomRepository.save(room);
    }

    public Room createNotStartedRoom() {
        return roomRepository.save(Room.createNewRoom());
    }

    public Room createProgressRoom() {
        int currentRound = 1;
        return createProgressRoom(currentRound);
    }

    public Room createProgressRoom(int currentRound) {
        int totalRound = 5;
        int timeLimit = 10_000;
        Category category = Category.IF;
        RoomStatus roomStatus = RoomStatus.PROGRESS;

        Room room = Room.createNewRoom();
        RoomSetting roomSetting = new RoomSetting(totalRound, timeLimit, category);
        setRoom(currentRound, roomSetting, roomStatus, room);

        return roomRepository.save(room);
    }

    public Room createProgressRoom(int currentRound, RoomSetting roomSetting) {
        RoomStatus roomStatus = RoomStatus.PROGRESS;

        Room room = Room.createNewRoom();
        setRoom(currentRound, roomSetting, roomStatus, room);

        return roomRepository.save(room);
    }

    public Room createFinishedRoom() {
        int currentRound = 5;
        int totalRound = 5;
        int timeLimit = 10_000;
        Category category = Category.IF;
        RoomStatus roomStatus = RoomStatus.FINISH;

        Room room = Room.createNewRoom();
        RoomSetting roomSetting = new RoomSetting(totalRound, timeLimit, category);
        setRoom(currentRound, roomSetting, roomStatus, room);

        return roomRepository.save(room);
    }

    private void setRoom(int currentRound, RoomSetting roomSetting, RoomStatus roomStatus, Room room) {
        fixtureSettingManager.setField(room, CURRENT_ROUND_FIELD, currentRound);
        fixtureSettingManager.setField(room, STATUS_FIELD, roomStatus);
        fixtureSettingManager.setField(room, ROOM_SETTING_FIELD, roomSetting);
    }
}

3가지 상태의 Room을 생성하기 위한 다양한 메서드를 Overloading 을 활용하여 객체지향적으로 구현하였다.

private void setRoom(int currentRound, RoomSetting roomSetting, RoomStatus roomStatus, Room room) {
        fixtureSettingManager.setField(room, CURRENT_ROUND_FIELD, currentRound);
        fixtureSettingManager.setField(room, STATUS_FIELD, roomStatus);
        fixtureSettingManager.setField(room, ROOM_SETTING_FIELD, roomSetting);
}

또 눈여겨볼 점은 최하위에 있는 setRoom() 메서드이다.
Reflection을 사용하는 FixtureSettingManager를 구현했고, 이를 통해 객체의 특정 필드에 특정 값을 채워넣을 수 있도록 구현하였다.

FixtureSettingManager.java

@Component
public class FixtureSettingManager {

    public void setField(Object targetObject, String fieldName, Object newValue) {
        try {
            Field field = targetObject.getClass().getDeclaredField(fieldName);
            field.setAccessible(true);
            field.set(targetObject, newValue);
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new RuntimeException("Failed to set field value", e);
        }
    }
}

FixtureSettingManager 클래스의 내부이다.

Reflection을 사용하는 경우 필드의 네이밍이 변경되는 경우 관련된 테스트 코드를 찾아 모두 변경해주어야 한다.
이때 setField() 메서드를 구현하고 이를 사용해서 필드 값을 초기화하도록 하면, 이후에 Reflection을 수행하고 있는 코드를 찾기 수월할 것이라고 생각했다.

또 Reflection이 필요한 곳마다 생기는 코드 중복 제거되어 유지보수성도 증가된다.

개선 결과

<개선 전>

<개선 후>

위와 같이 Test Fixture 클래스 구현을 통해 결론적으로 코드는 위와 같은 형태로 개선되었다.

Fixture를 하나하나 생성하던 과정을 Fixture 객체에 위임함으로써 위와 같이 가볍고 가독성 좋은 형태로 개선 할 수 있었다.
또한 메서드에 객체 생성의 세부적인 로직을 위임하게되니 테스트 코드 생산성이 굉장히 향상됨을 느낄 수 있었다.

PR 링크

https://github.com/woowacourse-teams/2024-ddangkong/pull/400
전체적인 개선 내용이 궁금하다면 PR 참조

Logback MDC(Mapped Diagnostic Context) 활용하여 Observability 개선하기

PgmJUN — Tue, 5 Nov 2024 22:05:57 +0900

고민의 시작점

다수의 사람들이 서비스를 이용하는 우아한테크코스의 데모데이 직전,

모니터링이 수월하게 작동할 지 확인하는 도중 다른 크루원과 기존 로깅 방식에 대해 이야기를 나누는 과정에서 현재 로깅 방식에 아쉬움을 느끼게 되었다.

때문에 로깅 방식을 개선해보고자 몇 가지 고민을 했고, 그 과정과 결과를 기록해두고자 한다.

현재 Logging의 문제점

땅콩의 로그 형태

현재 우리 땅콩 서버의 로그는 다음과 같은 형태로 남겨지고 있다.

Request, Response에 대한 정보를 남기고 있는 효율적인 로깅 방식으로 보여진다.

하지만 여기에 하나의 문제점이 있다.

서버에 동시에 요청이 마구잡이로 들어왔을 때, 특정 로그를 어떻게 추적하여 확인할 수 있을까?

어떤 요청에서 예외가 발생했을 때, 빠른 속도로 어떤 요청에서 예외가 발생한 것인지 인지할 수 있을까?

본인은 지금 상태로는 사실상 굉장히 어려운 문제라고 생각했다.

때문에 이 문제를 해결하여 Observability를 개선해보고자 한다.

Observability란?

Observability는 소프트웨어 시스템의 상태를 외부에서 파악하고 이해할 수 있는 능력을 의미한다.

Observability는 아래 3가지 요소로 구분된다.

로그(logging): 시스템에서 발생하는 이벤트나 상태 변화를 기록한 정보. 각종 요청, 에러, 상태 변경 등과 같은 정보를 포함하며, 상세한 디버깅이나 시스템의 상태 파악에 도움을 준다.
메트릭(metrics): 시스템의 성능과 관련된 수치 데이터이다. CPU 사용률, 메모리 소비량, 요청 처리 시간, 오류 발생 횟수 등의 데이터를 수집하여, 시스템 성능을 모니터링하고 병목 현상이나 성능 저하를 탐지할 수 있다.
트레이싱(tracing): 개별 요청이나 트랜잭션이 시스템 내부에서 어떻게 처리되는지를 추적하는 방법이다. 여러 마이크로서비스나 애플리케이션 컴포넌트에서 요청이 어떤 경로를 통해 전달되는지 추적할 수 있어, 성능 문제나 오류가 발생한 지점을 파악하는 데 도움을 준다.

해결 방안

해결방안으로 떠올린 방법은 MDC를 사용하는 것이다.

요청이 도착했을 때, 각 요청마다 TraceID(UUID)를 생성하고, MDC에 삽입한다.

그리고 Log를 찍을 때 해당 정보를 함께 표시해준다.

그럼 요청별로 구분하는 것이 굉장히 쉽게 변할 것이라고 생각했다.

MDC (Mapped Diagnostic Context) 란?

MDC는 주로 로그 관리에서 사용하는 개념으로, 스레드 로컬(Thread Local) 변수를 통해 각 스레드별로 고유한 컨텍스트 데이터를 저장하고, 이를 로그에 포함시키는 기능을 제공한다.

스프링 부트와 같은 환경에서 요청 단위로 고유한 TraceID를 생성해 로그에 삽입할 때 자주 사용된다.

[MDC의 주요 기능]

스레드 별로 독립된 데이터를 관리할 수 있다. 이는 특히 멀티스레드 환경에서 유용하다.
특정 요청이나 작업에 관련된 메타데이터를 로그에 자동으로 삽입할 수 있다.
예를 들어 TraceID, 사용자 ID, 세션 ID 등과 같은 정보를 로그 메시지에 포함할 수 있다.

만약 위와 같은 예외가 발생했을 때, 요청이 굉장히 많이 발생하고 있다면 어디서 예외가 발생한 건 지 어떻게 알 수 있을까?

지금은 DELETE 요청과 해당 요청에서 발생한 경고 로그가 붙어있지만, 굉장히 많은 요청이 들어오고 있는 와중에 저런 문제가 발생하면 오류의 원인을 로그에서 쉽게 찾아볼 수 있을까?

ThreadName으로 검색한다고 하더라도, Thread 는 ThreadPool에 한 번 등록된 Thread를 계속 재사용하기 때문에

검색한 ThreadName으로 처리된 굉장히 많은 작업 로그가 검색될 것이다.

내 생각엔 에러의 발생 원인 추적이 굉장히 복잡해질 것 같다고 생각한다.

이러한 상황에서 요청단위로 관리되는 TraceID(RequestID)를 사용하면, 위와 같이 문제 원인을 추척하기 수월해질 것이라고 생각했다.

한 눈에 들어오지 않는가?

구현하기

요청이 들어올 때 Controller Aspect 에서 MDC 사용하여 traceID 생성

@Slf4j
abstract class ControllerLoggingAspect {

    private static final String TRACE_ID_KEY = "traceId";

    //..PointCut 설정 중략

    protected void logControllerRequest(JoinPoint joinPoint) {
        setTraceId(); // TraceID 생성
        HttpServletRequest request = getHttpServletRequest();
        String uri = request.getRequestURI();
        String httpMethod = request.getMethod();
        String queryParameters = getQueryParameters(request);
        String body = getBody(joinPoint);

        log.info("Request Logging: {} {} body - {} parameters - {}", httpMethod, uri, body, queryParameters);
    }

    protected void logControllerResponse(JoinPoint joinPoint, Object responseBody) {
        HttpServletRequest request = getHttpServletRequest();
        String uri = request.getRequestURI();
        String httpMethod = request.getMethod();

        log.info("Response Logging: {} {} Body: {}", httpMethod, uri, responseBody);
        removeTraceId(); // TraceID 삭제
    }

		private void setTraceId() {
        String traceId = UUID.randomUUID().toString();
        MDC.put(TRACE_ID_KEY, traceId);
    }

    private void removeTraceId() {
        MDC.remove(TRACE_ID_KEY);
    }
    //.. 타 메서드 중략
}

위와 같이 setTraceId(), removeTraceId() 메서드를 바탕으로 MDC에 traceId를 생성 및 삭제 처리 해준다.

LogBack.xml 사용해서 traceID 남기기

<appender name="DDANGKONG_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH}/ddangkong.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/ddangkong-%d{yyyy-MM-dd}.log</fileNamePattern> <!-- 매일 새로운 파일 생성 -->
            <maxHistory>365</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss,Asia/Seoul} [%thread] %-5level %logger{36} [%X{traceId}] - %msg%n
            </pattern>
        </encoder>
</appender>

logback-{env}.xml 파일에서 로그 출력 패턴을 정하는 <pattern> 태그에

[%X{traceId}] 설정을 추가하여 MDC에 기록한 traceId를 출력하도록 만든다.

그럼 위와 같이 로그에 TraceID 가 함께 기록되기 시작한다.

요청/응답이 아닌 경우 TraceID 설정

그런데 위 로그에 문제가 있어보이지 않은가?

바로 요청/응답이 아닌 경우에 TraceID가 작성되지 않고 [] 로만 작성되는 문제인데, 이 문제도 해결해보자

위에서 설정해주었던 [%X{traceId}] 값 설정을 [%X{traceId:-NoTraceID}] 로 변경해주면 traceId가 없을 때 NoTraceID가 찍히게 된다.

이제 로그가 이렇게 위와 같이 표시된다.

깔끔하지 않은가?

결론

다수의 사람들이 서비스를 이용하는 우아한테크코스의 데모데이 직전, 모니터링이 수월하게 작동할 지 확인하는 과정에서 현재 로깅 방식에 아쉬움을 느꼈다. 로그를 요청 별로 구분해 줄 무언가가 필요하다고 느꼈다.

이를 해결하기 위해서 Thread Local을 사용하는 MDC를 사용하여 각 요청마다 TraceID를 갖도록 구성하고, 이를 로그 별로 함께 찍어줌으로써 로그 추적이 간편해지도록 구성할 수 있었다.

실제로 Toss의 SLASH 23에서도 위와 같은 주제를 다루었던 것을 검색 과정에서 알게 되었다.

기술적으로 훌륭한 실력을 가진 Toss에서도 고민했던 부분인 것을 확인하고 괜찮은 접근이라고 생각하였다.

자세히 알고 싶은 사람들은 위 영상을 시청하면 많은 도움이 될 것이라고 생각한다.

2024 토스뱅크 Server Developer (Product) 최종 합격 회고

PgmJUN — Tue, 5 Nov 2024 19:39:51 +0900

최근 우아한테크코스와 취준을 병행하느라 글을 적지 못하고 있던 중에 좋은 소식이 찾아와서 오랜만에 글을 적어보려 한다.
평소 토스 문화를 살펴보면서 개발자로서 첫 커리어를 시작한다면 '토스'에서 시작하고 싶다고 생각해왔는데, 그게 실현되었다는 기쁜 소식이다.
그리고 그 과정을 회고로 남겨 종종 되돌아보고자 글을 적는다.

물론 이후에 지원하는 이들에게도 도움이 되었으면 하는 마음에 소소한 팁도 적어두었다.

2024 토스뱅크 테크 직군 대규모 채용 공고 홈페이지 (현재는 마감된 화면)

올해 8월 2024 토스뱅크 테크 직군 대규모 채용이 열렸다.

평소 개발자로서 생각해왔던 금융권 기업의 이미지는 '보수적인 곳', '개발 안 하는 곳', '커리어의 무덤' 이었다.
물론 '정년은 보장되는 곳'이라는 타이틀도 있었지만 별로 가고싶다는 생각은 없었다.
사람들에게 필요한 가치를 찾고 개발을 통해 서비스로 실체화시키는 그 모든 과정이 너무나도 보람차고 즐거워서 개발을 하고 있는 나는
차라리 도전적인 업무를 수행해볼 수 있는 스타트업에 더 마음이 갔다.

그럼 어쩌다가 토스라는 회사에 눈이 가게 되었는가

토스라는 회사의 문화는 내 인생의 경험에 걸쳐보았을 때 너무나도 와닿는 문화가 많은 회사였기 때문에 꼭 가고싶은 회사였다.
토스는 내가 생각하던 금융권과는 전혀 다른 회사였다.
꼭 금융권이 아니고 모든 IT 회사와 비교해보아도 이런 문화를 만들어가고 있는 회사는 극히 드물었고, 인생 처음으로 가고싶은 회사가 토스가 되었다.

본인은 고등학생 시절 학생회장 업무를 수행하며 하향식 업무 구조와 사람에 대한 스트레스를 받으며 업무라는 것에 대한 큰 회의감을 느껴본 적이 있다. 특히 공약을 통해 전하려던 가치를 대부분의 학생들은 원했지만 학교 측에서는 제대로된 이유도 알려주지 않고 지속적으로 기각을 시켜버린 경험 등 여기에 적어내기엔 정말 다양한 경험을 해왔다.
겁을 먹고 해보지 않았던 일들을 해보려고 나서지 않으면 결국 도태된다고 생각한다. 변화를 만들려면 실패하던 성공하던 계속 움직여야한다. 다만 학교는 그렇지 못했던 것 같다. 생각보다 보수적인 환경에 많이 실망했고 어느 순간부터 빨리 학교에서 졸업하고 싶었다. 더는 그곳에 있기 싫었다.

이러한 인생의 경험이 있다보니, 직급에 상관없이 전직원이 하나의 공동 목표를 추구하며 그 안에서 도전적인 시도에 대한 자유로운 의사결정권을 가지며 끝없는 시도를 통해 혁신을 이끌어갈 수 있는 토스라는 회사는 나에겐 너무나도 의미있는 기업이었다.

지인과의 대화를 통해 우연히 토스의 문화를 알게 되었을 땐 너무나 충격적이었는데, 토스라는 기업에 관심있는 사람은 꼭 확인해보길 바란다. [토스 핵심 가치 아티클]

토스 계열사 중 토스뱅크에 가장 매력을 느낀 이유

사실 토스의 문화 아래에 있는 모든 계열사는 어디든 훌륭하다고 생각하지만, 그중에 토스뱅크에 가장 매력을 느낀 이유는 경험 때문이었다고 생각한다.
토스뱅크의 '키워봐요 적금'을 통해 즐거움과 기대감을 느끼며 돈을 모았던 경험이 있다.
'키워봐요 적금'은 어릴 적 즐겨하던 게임 '동물농장'을 벤치마킹해서 만든 것 같다고 생각이 들었는데, 적금을 계속 할 수록 동물이 성장하고 적금과 함께 최종 성장체까지 키워내는 그런 적금 상품이었다.

평소 돈 모으는 것에 재미를 느낀 적이 없었지만, 처음으로 돈 모으는 것이 재미있고 기대된다고 느꼈다.
때문에 나 또한 토스에 들어간다면, 여러 계열사 중 토스뱅크에 들어가서 사람들이 즐겁게 돈을 모을 수 있는 다양한 상품을 개발하며 사람들에게 '돈 모으는 즐거움' 이라는 가치를 제공하고 싶었다.

채용 과정

[서류 전형] - [기술 면접] - [문화적합성 면접]
토스뱅크에 입사하기 위한 과정은 총 3가지 단계로 진행되었다.
보안서약서를 작성했기 때문에 간단히 밖에 말 못하겠지만, 그래도 경험과 느낀점이라도 적어보려고 한다.

[서류 지원 과정]

서류는 이력서와 포트폴리오를 제출했다.
토스 개발직군은 보통 자기소개서나 정해진 이력서 형식이 없는 자율 양식 지원으로 알고 있는데 이 점이 너무 좋았다.

굉장히 바쁜 우아한테크코스를 진행하면서 서류를 작성하기란 쉽지 않다.
그래도 평소에 작성해온 이력서와 포트폴리오가 있었기 때문에 지원까지는 얼마 걸리지 않았다.

"이력서에 쓸만한 경험이 없다면, 평소에 일을 똑바로 하고 있는 것인지 되돌아보라" 라는 말이 있는데, 난 이 말을 꽤나 좋아했다.
내가 제대로 된 경험을 하고 있는지 판가름할 수 있는 기준을 잡아준 말이다.

때문에 매번 새로운 경험을 할 때마다 이력서를 업데이트했다. 거의 1개월에 1번씩은 이력서를 고쳤던 것 같다.
먼저 현직자로 일하고 있는 지인들에게 연락을 돌려서 이력서의 경험과 가독성 검토를 부탁했고 지속적으로 개선시켜나갔다.
때문에 이번 채용에서 기회를 잡을 수 있었던 것 같다. (도와주신 분들 너무 감사합니다)

만약 평소에 "이력서 만들어야하는데,," 라고 생각만 하면서 시도를 미루고 있다면 지금이라도 이 글을 닫고 이력서부터 만들어보길 바란다.
운과 기회는 언제 찾아올 지 모른다. 그리고 항상 준비가 되어있는 자에게 찾아간다.

[기술 면접 과정]

서류 전형 합격

평소의 경험을 잘 녹여낸 덕분인지 서류 전형에서 좋은 결과를 얻게 되었다.
그렇게 기술 면접 준비 과정으로 들어가게 되었다.

자세한 건 기록할 수 없지만, 토스의 기술 면접은 의미없는 CS 같은 것들에 대해 물어보지 않고, 해왔던 일들에 대해서 넓고 깊게 학습해야 한다고 정도 말해주고 싶다.
의미없는 CS라고 함은 "객체지향의 의미를 설명해주세요", "OSI 7계층에 대해서 설명해주세요" 와 같이 내가 제출한 이력과는 어떠한 연관성도 없이 CS에 대한 내용들로만 구성된 질문이라고 할 수 있을 것 같다.
토스는 해왔던 것 바탕으로 깊게 파고드는 느낌이 컸고, 그 과정에서 관련이 있는 CS 질문만 나오는 것 같았다.

평소에 항상 고민하고 생각하면서 개발해 온 사람이라면 이 면접의 준비 과정부터 면접 당일까지 너무 즐겁게 생각하고 고민하면서 지낼 수 있을 것이다.
다만 본인은 면접일이 서류전형 합격 발표날로부터 거의 한 달 뒤로 잡혀서 이 과정이 너무 길고 힘들게 느껴질 때도 있었다.
하지만 학습하고 생각했던 것을 되돌아보며 더욱 크게 성장함을 느낄 수 있었던 것이 더 컸다.

나는 면접 일주일 쯤 전부터 긴장도 됐지만 사실 기대감이 더 컸다.
토스의 기술 면접에 대한 내용들을 찾아보면서 훨씬 개발 선배이신 면접관분들과 대화를 주고받으며
내가 생각하지 못했던 부분에 대해 인사이트를 얻고 함께 고민해보는 즐거운 시간을 만들 수 있을 거라고 확신했다.
실제로도 그랬고, 면접이 끝난 뒤에는 너무 즐겁게 대화를 주고받았다는 느낌이 강하게 들었다.

기술 면접 팁

1. 모의면접
아무리 기술적 고민을 많이 하는 사람이더라도, 그걸 생각만 하는 것과 말로 표현하는 것은 천지차이다.
때문에 나는 모의면접을 수차례 진행했다.
함께 지원한 우테코 사람들과도 진행하고, 근처에 있는 현직자분들과도 여러 번 모의면접을 진행했다.
덕분에 내가 말하고자 하는 것을 설명할 수 있는 능력이 많이 자리 잡혀서, 면접 당일날 내가 표현하고 싶은 것을 전부 말로 표현하고 왔다.

2. 기록
항상 고민하고 개발했던 내용들을 기록해놨기 때문에 과거에 기술적 선택을 했을 때 어떤 근거를 바탕으로 선택했는지 빠르게 복기할 수 있었다. 인간의 기억력은 유한하기 때문에 항상 기록하는 습관을 들여놓으면 좋은 것 같다.

[문화적합성 면접]

기술 면접 합격

문화적합성 면접은 토스의 문화와 지원자의 문화적 지향점이 매칭되는지 검증하는 시간이라고 생각한다.
평소 토스에서 만들어가는 문화에 대해 큰 가치를 느끼고 있었기 때문에 면접 과정에서 즐거운 시간을 보낼 수 있던 것 같다.

문화적합성 면접은 기술 면접 합격 발표 이후 7일 정도의 텀이 주어졌다.
처음엔 너무 길다고 생각했는데, 준비하다보니 딱 적합한 시간이었다고 느꼈다.

평소에 기술에 대해서는 생각하지만, 자기 자신의 사고에 대해서 돌아보는 사람은 거의 없을 것이라고 생각한다.
나 또한 매일 회고를 통해 내 자신을 돌아보게 된 것이 오래되지 않았기 때문에 오히려 기술 면접보다 더 생각해볼 내용이 많았던 것 같다.

개인적으로 면접 자체는 기술 면접때보다 더 즐거웠다고 느꼈는데, 기술 면접은 생각보다 조금 더 무거운 분위기였던 반면
문화적합성 면접은 면접관님과 웃으면서 너무 즐겁게 대화하고 왔기 때문이다.
개발자로서 내가 어떤 삶을 살아왔고, 어떤 문화를 추구하며, 협업에 있어서 어떤 성향을 가졌는 지 등을 주로 나눴던 것 같다.
기술적인 얘기도 하긴 했지만, 주는 아니었다. (근데 진짜 이것도 너무 즐거웠다...)

면접을 보고 나오는 길에는 그냥 행복했다. 너무 즐겁고 소중한 시간이 되었다고 생각한다.

문화적합성 면접 팁

준비를 어떻게 했는가에 대해서 말해보고 싶은데, 크게 말할 내용이 없는 것 같다.

1. 멍 때리면서 개발인생 돌아보기
그냥 매일 4~5시간 정도 멍때린 것 같다.
아무 생각없이 멍을 때린 건 아니고 그냥 인생을 계속 돌아봤다.
생각 깊은 곳까지 들어왔다 나가기를 계속 반복했다.
"난 어떤 삶을 살았지?", "내가 개발자로서 이루고 싶은 목표는 뭐지", "난 언제부터 컴퓨터를 좋아했지?", "개발은 왜 시작했지?" 등 인생을 돌아볼 수 있는 질문들을 스스로에게 끊임없이 던졌다.

기억을 돌아볼수록 정말 깊은 사고까지 들어갈 수 있었고 바쁘게 살아가며 잊고 지내던 일들도 많이 떠올랐다.
즐거운 기억, 아쉬운 기억, 슬픈 기억 모두 떠오르면서 신기하고 즐거운 시간을 보낼 수 있었다.

2. 러버덕 디버깅
그리고 이 또한 모의면접을 해보니 좋았다. 사실 각잡고 하는 건 아닌 것 같고, 러버덕 디버깅이었던 것 같다.
대화할 사람을 앉혀두고 서로 자신의 개발자로서의 인생에 대해서 설명하는 시간을 갖는 걸 추천한다.
위에서 말했듯이 말로 설명하는 것과 생각하는 것은 큰 차이가 있다.

최종 합격

토스뱅크 최종 합격

정신없이 달려온 이 채용과정의 끝은 '합격' 이었다. 많이 가고싶었던 회사인 만큼 감격이 굉장히 컸다.
채용 과정이 길어서 지치는 순간들도 있었으나, 오히려 길게 주어진 시간이 기회라고 여기며 최선을 다했다.
채용 과정에 깊게 몰입했고 매 순간을 감사하고 즐기기 위해 노력했다.

올해 초 우아한테크코스와 한 스타트업에 동시 합격했을 때, 성장하는 방법을 깨달은 이후에 현업으로 나가고자 우아한테크코스를 선택했었다.
그렇게 선택한 우아한테크코스 안에서 너무나 좋은 사람들을 많이 만났다.
배울 점이 다양한 여러 크루원들과 1년을 보내며 그들에게 정말 많은 것을 느끼고 배웠으며
더욱 오랜시간 개발자로서의 길을 걸어온 여러 코치님들과 대화를 주고 받으며 개발자로서 어떻게 성장해나갈 수 있을 지 생각해나갈 수 있었다.

너무나 얻은 것이 많은 1년이었고, 그 경험과 과정이 있었기에 지금의 좋은 결과를 만들어낸 것이라고 생각한다.
앞으로 토스뱅크에서 걸어갈 길 위에서도 많은 것들을 바라고 느끼며 살아가길 소망한다.

지금까지의 인생을 돌아보며

이 감격스런 순간이 있기까지 어떤 인생을 걸어왔는지 돌아보고자 한다.

되돌아보면 20대 초반에는 굉장히 막막했던 것 같다.
지원했던 모든 4년제 대학에 떨어지고 전문대로 가게 되었을 때, 전문대라는 특성에 의해서 학교에서 배우는 내용들이 인서울 4년제 대학과는 많이 다름을 알게 되었을 때 참 막막했던 것 같다.
또 백엔드로 방향을 잡기 전 안드로이드, iOS, 프론트엔드 등 여러 분야를 먼저 접해보면서 재미를 전혀 느끼지 못했었고 이때 개발을 접으려고 했던 기억도 있다.

하지만 매번 포기하지 않았고 매번 나만의 방향을 찾기 위해 발버둥쳤고 항상 고민했다.
항상 포기하지 않고 노력한 그 끝에는 결국 의미있는 결과가 돌아올거라 믿었고 실제로도 그랬다.
이러한 경험을 통해 자연스럽게 '항상 당장의 상황에 좌절하지 않고 계속 나아가야함' 을 느꼈던 것 같다.

그리고 이 과정의 모든 순간에는 사람들이 있었다.
항상 어렵고 힘든 순간에 주위에서 힘이 되어주는 사람들이 있었다.
특히 개발을 접으려고 했을 때 백엔드로의 전향에 가장 많은 도움을 주었던 친형.
그리고 항상 즐거움과 도움이 되어준 SOPT 사람들, 우테코 사람들에게 너무 감사하다.

때문에 입사 전까지는 도움을 받은 주변 사람들의 이력서나 면접을 소소하게 도우면서 개인적으로 미뤄뒀던 학습을 하며 여유있게 지내려고 한다.
또 입사 이후에는 일에 몰입할 계획이라 휴식 계획은 생각해두지 않아서, 지금 시점에 여행도 많이 가려고 한다.

이 글을 얼마나 볼 지는 모르겠으나, 항상 현재 상황에 좌절하지 말고 포기하지 말기를 바란다.
실패를 하더라도 그 안에서 배우는 점들만 있다면 그 실패의 경험들이 언젠가 성공으로 이끌어줄 거라 전하며 글을 마친다.

[우아한테크코스 6기] 레벨3 돌아보기 (2024/07/02 ~ 2024/08/23)

PgmJUN — Mon, 26 Aug 2024 01:07:31 +0900

어느덧 우아한테크코스의 레벨 3까지 끝나게 되었다.

프로젝트 팀원들과의 너무나 즐겁고 소중한 시간들이었고, 지금까지의 개발 인생에 있어서 가장 유의미한 협업의 한 사이클을 경험한 나날들이었기에 회고를 통해 글로 기록해두고자 한다.

프로젝트와 함께 시작된 협업

우아한테크코스 레벨 3 시작과 함께 함께 레벨 1,2를 거치며 학습한 내용을 바탕으로 프로젝트를 시작하게 되었다.

레벨 1을 통해 단련한 자바와 레벨 2를 통해 단련한 스프링을 기반으로 프로젝트의 백엔드를 개발하게 되었다.

팀원들과 첫 만남

지금은 누구보다도 터놓고 지내는 팀원들이지만, 그래도 첫 만남은 조금은 어색했던 것 같다.

백엔드 팀원은 3명 중 2명이 레벨 2에서 같은 조원이라 굉장히 가까웠지만, 프론트엔드 팀원들은 완전히 처음 보거나 한 번 정도 대화를 주고받은 사이였다.

하지만 누구 하나 빠짐없이 좋은 성격을 가진 덕분에 금방 친해지게 되었다.

프로젝트 기획

팀 구성과 동시에 바로 프로젝트 기획에 들어가게 되었다.

거의 일 주 밖에 안 되는 너무나 짧은 시간이었지만, 금방 기획을 마무리할 수 있었다.

나는 정말로 사용되는 서비스를 개발하고 싶단 생각에 여태까지의 프로젝트 경험을 바탕으로 누구보다 열심히 기획에 임하려 노력했다.

다양한 아이디어를 제시하고, 팀원들을 설득하였다.

직전에 경험한 프로젝트 '라이온하트'는 운영과 출시까지에 필요한 준비기간과 리소스가 너무 크고 길어서 출시에 실패하였으며,

그 이전에 경험한 졸업작품 프로젝트 '코리', 걱정기록 서비스 '흐릿'은 우리 팀에서 필요하다고 생각했지만 사실은 유저가 필요로 하지 않았던 것이라 실패했다. 유저가 원하고 필요로 하는 것을 만들어내야 한다고 생각했다.

다수의 기획 회의 흔적..

그리고 이러한 과정을 거쳐 결론적으로 팀원들이 모두 함께 공감해 준 프로젝트 '땅콩'의 기획안을 도출해 내었다.

'땅콩'은 심심풀이 땅콩의 약자로 심심풀이로 사용할 수 있는 아이스브레이킹 & 친목 서비스이다.

다양한 주제로 밸런스 게임 문항을 제공하는데, 특이한 점은 '다 함께' 즐길 수 있다는 점이다.

실시간성을 보장하는 서비스로 다 같이 하나의 방에 접속해서 밸런스 게임을 진행하고 서로의 결과를 확인한다.

중간중간 대화를 이끌 수 있는 각종 지표들을 제시하며, 게임이 종료되면 투표 결과를 바탕으로 함께 게임한 팀원들과의 매칭도를 확인할 수 있는 재미있는 서비스이다.

자세한 내용은 프로젝트 Github에서 확인할 수 있다.

팀 문화, 코드컨벤션 확립하기

개발만큼이나 중요한 것은 바로 팀 문화와 컨벤션들이다.

초기에 이것들을 잡기 위해 최선을 다했다.

팀 문화 정의를 통해 전체적인 업무 문화와 분위기를 확립하고, 코드컨벤션 설정을 통해 통일성 있는 코드를 작성하기 위해 노력했다.

땅콩팀 문화 문서 (일부)

협업툴인 노션에 기록해 둔 팀문화 문서 중 일부이다.

이것들을 지키기 위해 정말 많이 노력했다.

매번 데모데이가 끝날 때마다 팀문화에 대한 진중한 회의를 거쳐가며 튼튼하고 세련된 팀문화를 만들어가기 위해 최선을 다했다고 자부한다.

덕분에 잘 정의된 안정적인 업무 문화 속에서 편안히 일할 수 있었다고 생각한다.

회고 문화

솔직히 우리 팀을 가장 하나로 이끌어줬던 것은 매번 데모데이날마다 진행했던 회고 문화였던 것 같다.

내가 개인적으로 열심히 주장해서 만들어낸 문화였는데, 'KPT 방식을 통한 팀문화 회고'와 '좋아요/서운해요 회고를 통한 익명 팀원 회고'가 있었다.

이 시간만큼은 팀원들이 어느 때보다 솔직해질 수 있었으며 팀과 팀원들끼리 서로의 보완을 위해 열심히 피드백을 주고받았던 순간들이 기억에 남는다.

땅콩팀 코드 컨벤션 (일부)

코드 컨벤션도 개행부터, 매개변수까지 굉장히 세부적으로 잡아서 지키려고 노력했다.

일관성 있는 코드에 가독성이 따른다는 점에 모두가 공감했기 때문이다.

조금 더 세부적인 기록을 보고싶다면 여기 클릭

다양한 문제 상황을 마주하다..!

본격적으로 프로젝트가 시작되고 나서는 정말 많은 크고 작은 사건들이 발생했었다.

문제를 마주하고 해결하는 과정에서도 정말 많이 성장했던 것 같은데 그 기록들도 남겨보려고 한다.

Github Rebase로 인한 깃 대폭발 사건

Rebase에 대해 자세히 모르고 사용해서 발생했던 깃 대폭발 사건이 있었다.

우리는 이 사건을 '썬데이의 스노우볼' 사건이라고 부른다.. (사건번호는 다행히 3에서 멈췄다..)

Rebase Merge를 하게 되면 동일한 커밋 내용이어도 Merge 되는 브랜치의 '커밋 해시'와 Merge 시킨 브랜치의 '커밋 해시'가 상이해진다.

때문에 특정 커밋이 Rebase Merge로 Merge된 Develop 브랜치에서 현재 작업이 진행 중인 Feature 브랜치로 Rebase를 수행했을 때

이미 Develop에 반영이 되어있는 커밋과 Feature에서 Rebase 받은 커밋은 동일한 커밋이지만 서로 다른 커밋 해시를 가진다.

그렇기에 이러한 작업 이후에 Feature 브랜치에서 Develop으로 PR을 보내게 되면 커밋 해시 관련 오류가 발생한다.

이해를 위해 이미지를 준비했다.

예를 들어 A -> B 라는 커밋이 이미 Develop 브랜치에 반영되어, 현재 상태가 'A'에서 'B'가 된 Dev 브랜치가 있다고 가정하자.

이때 A -> B 라는 내용을 가진 다른 커밋 해시의 커밋이 Dev 브랜치에 또 다시 올라가는 것이다.

이미 상태가 'B'인 코드에게 A -> B 요청을 보내면 당연히 상태는 'A'가 아니라 'B'이니 오류가 발생할 수 밖에 없다.

이러한 매커니즘으로 인해서 커밋 해시가 꼬여 깃 커밋 로그가 대폭발하는 사건이 발생하게 된다.

결국 어찌저찌 해결하고 Rebase에 대차게 당한 우리 팀은 Merge and Commit 방식을 반 강제로 애용하게 된다.

API Spec 변경 소통 미스로 인한 프론트엔드의 무한 디버깅 사건

백엔드 팀은 개발 환경에 배포된 내용에 대해서는 RestDocs를 활용해 테스트를 거쳐 문서화를 진행하기로 하였다.

하지만 문서가 변경될 때마다 프론트엔드가 알 방법이 없었고, 백엔드 팀에서 직접 프론트 팀원들에게 구두로 전달해주지 않으면 이를 인지할 수가 없다.

때문에 프론트엔드에서는 "이거 맞는데 왜 안되지 내 잘못인가ㅠㅠ" 해버리는 무한 디버깅 사태가 발생하는 문제가 이따금 있었다.

Discord Document Notificator

이러한 문제 해결을 위해서 Github Actions와 땅콩 팀의 협업툴 Discord를 활용하여 API 문서 변경 알림 시스템 구축을 수행하였다.

변경 사항을 빠르게 파악할 수 있도록 PR링크와 Docs 링크를 첨부하여 생산성 향상을 위해 노력했다.

(다만 알 수 없는 문제로 인해 PR 바로가기 링크가 안 만들어지고 있다. 이 문제는 최대한 빨리 해결해보려고 한다.)

Polling 과정에서 발생한 캐싱 관련 문제

버스정류장 디버깅

프론트엔드의 기술 스택인 React에서 Polling을 통해 흭득한 데이터를 어떠한 저장소에 캐싱해버려서 문제가 된 적도 있었다.

가볍게 설명하자면 API 요청에 대한 응답값과 React에서 어딘가에 캐싱해둔 값이 꼬여, 프론트에서 이상한 값을 가지고 비즈니스 로직을 수행하는 오류였다.

이 문제 때문에 게임 진행이 정상적으로 동작하지 않았고 다같이 우테코 문 닫는 시간인 11시까지 집에 가지 못했다..

밖에 나가서도 버스 정류장에 걸터앉아 문제 해결책을 찾아나섰던 추억도 있다..ㅎ

처음 문제가 발생한 시점에는 백엔드 문제인 줄 알았는데, 결국 프론트엔트 팀에서 문제가 캐싱 때문이라는 것을 알게 되어 캐싱을 끄는 방법을 찾아 문제를 해결하였다.

(데모데이 전날 밤이어서 심장이 너무 쫄깃했다...)

방 입장 로직에서 발생한 동시성 문제

게임 방에 입장하는 로직에서 동시성 문제도 발생했다.

땅콩 서비스를 QA하는 과정에서 방의 최대 인원 제한인 12명 중 11명이 방에 접속해 있는 경우, 동시에 입장 요청이 발생한다면 방의 최대 인원은 12명임에도 불구하고 13명 이상의 유저가 접속되는 동시성 문제를 발견하였다.

문제 해결을 위해서 synchronized, 낙관적 락 방식 등 다양한 동시성 처리 방법을 비교하며 문제해결을 시도하였고

결론적으로 '비관적 락(X-Lock)' 을 통해 문제를 해결할 수 있었다.

@Transactional
public RoomJoinResponse joinRoom(String nickname, String uuid) {
	Room room = roomService.getRoomWithLock(uuid);
	Member member = memberService.saveCommonMember(nickname, room);
	return new RoomJoinResponse(room.getId(), room.getUuid(), new MemberResponse(member));
}

방 입장 로직은 가장 먼저 요청을 통해 전달받은 roomId 를 통해 Room을 조회한다.

이때 roomId를 가진 Room 테이블의 레코드에 비관적 락(X-Lock)을 걸어 트랜잭션이 종료될 때까지 다른 트랜잭션에서 해당 roomId를 가진 레코드에 접근을 막았다.

이를 통해 방 입장 로직이 순차적으로 동작할 수 있게 되었고, 동시성 문제를 해결할 수 있었다.

@Test
void 최대_인원보다_많은_인원이_방에_접속할_수_없다() {
	// given
	Room room = roomRepository.save(Room.createNewRoom());
	memberRepository.save(PRIN.master(room));
	for (int i = 0; i < 10; i++) {
		memberRepository.save(EDEN.common(room, i));
	}

	// when
	Thread t1 = new Thread(() -> roomFacade.joinRoom("t1member", room.getUuid()));
	Thread t2 = new Thread(() -> roomFacade.joinRoom("t2member", room.getUuid()));
	t1.start();
	t2.start();

	try {
		t1.join();
		t2.join();
	} catch (InterruptedException ignored) {
	}

	Room foundRoom = roomRepository.findById(room.getId()).orElseThrow();
	long memberCountInRoom = memberRepository.countByRoom(foundRoom);

	// then
	assertThat(memberCountInRoom).isEqualTo(12);
}

문제 해결을 정확히 검증하기 위해 Thread 활용한 동시성 테스트를 작성하여 문제가 확실히 해결되었는지 검증하기도 했던 재미난 경험이었다.

팀원들과 스터디

레벨 인터뷰 스터디

저번 기수 우테코에서는 매 레벨마다 레벨 인터뷰라는 것이 존재했다.

레벨 인터뷰는 크루원들끼리 서로 돌아가며 인터뷰이, 인터뷰어가 되어 레벨동안 학습한 내용에 대해서 인터뷰 형식으로 설명하는 과정이다.

이 레벨 인터뷰가 메타인지에 큰 도움이 될 것이라는 생각에 꼭 경험하고 싶었지만, 이번 기수는 레벨 1,2에 레벨 인터뷰를 진행하지 않았기 때문에 개인적으로 아쉬웠다.

그래서 뜻이 맞는 크루원들을 모아 레벨 인터뷰 스터디를 진행하게 되었다.

Java, Spring에 대해서 깊이있게 공부하고 2주마다 학습한 내용을 바탕으로 서로 인터뷰이, 인터뷰어가 되어 면접을 진행하는 스터디였다.

해당 스터디를 바탕으로 면접에 대한 두려움을 없애고 메타인지를 기르는 것을 목표로 하였다.

(실제로 이 스터디 덕분에 면접 분위기를 즐길 줄 알게 되었으며 많은 메타인지를 기를 수 있어 너무나 유익한 스터디였다. 강추!)

자세한 내용과 진행 방식이 궁금한 사람은 이 Github Discussion을 확인하면 된다.

Real MySQL 8.0 스터디

프로젝트 팀원들과는 우리가 선택한 MySQL DB를 더욱 이해도있게 다루기 위해서 Real MySQL 8.0 탐구 스터디를 진행하였다.

줄여서 '리마탐(리얼마이에스큐엘 탐구)' 라고 불렀는데 이 스터디를 통해 MySQL의 동작원리를 이해하고 프로젝트에 효율적으로 녹여낼 수 있는 방법을 배우는 걸 목표로 하였다.

실제로 이 책을 통해 얻은 흰트로 User 설정, Index 설정, Lock에 대한 지식 습득 후 동시성 문제 처리 등 프로젝트에서 많은 도움을 받았다.

자세한 내용과 진행 방식이 궁금한 사람은 이 Github Repository를 확인하면 된다.

레벨 인터뷰

레벨인터뷰

레벨3에서는 우테코에 들어와서 너무나 원하던 레벨인터뷰를 진행하게 되었다.

레벨3 프로젝트에서 진행한 내용들을 PDF로 정리하여 배정된 팀원들에게 전달하고, 서로 인터뷰이/인터뷰어가 된 팀원들은 서로에 대한 질문과 응답을 준비하여 인터뷰를 진행할 수 있었다.

레벨 인터뷰 스터디와 더불어 매번 고민하고 문제를 해결하던 습관을 바탕으로 질문들에 대해서 조리있게 설명해나갔다.

내가 받은 피드백

레벨인터뷰 피드백

팀원들이 인터뷰 피드백도 너무 착실하게 작성해주어서 의미있는 시간을 보낼 수 있었다.

내가 생각하고 학습하고 적용했던 내용들을 최대한 녹여내보려고 했으나, 아쉽게 놓친 부분들도 있었지만 최선을 다했고 괜찮은 피드백들을 받을 수 있었다.

부정적인 피드백들은 따로 정리하여 더욱 깊이있게 채우고, 긍정적인 피드백도 정리하여 강점으로 만들기 위해 노력할 예정이다.

처음으로 사용자를 만나다

우테코의 데모데이

우테코는 데모데이라는 것이 존재하는데, 레벨3는 1차~4차 데모데이까지 존재한다.

1차~3차는 코치님들에게 프로젝트 진척 상황에 대해 발표하는 것이고 4차 데모데이는 우테코 크루원들끼리 서로 서비스를 사용해보고 피드백하는 시간이다.

우리가 만든 '땅콩'이 처음으로 사용자를 만나는 너무나 소중한 시간이라는 뜻이다.

데모데이 준비(1)

이 시간을 통해 잠재적 유저들인 크루원들에게 서비스를 '잘' 선보이기 위해 정말 열심히 준비했다.

밤 늦게까지 남아 회의하고 QA하던 기억이 새록새록 하다.

우리팀은 데모데이 전날마다 매번 야근을 했던 것 같다.

그땐 너무 힘들었는데 지나고보니 너무나 소중하고 따듯했던 기억들 뿐이다.

데모데이(2)

결론적으로 엄청난 호평을 받고 마무리된 땅콩의 4차 데모데이!

생각보다 훨씬 긍정적인 유저반응을 얻고 너무나 행복해던 하루였다.

회고를 적으며 되돌아보니 나와 우리팀에게는 이 날이 레벨3에서의 유종의 미를 거두는 가장 소중하고 행복한 순간이었던 것 같다.

땅콩 1차 MVP 개발 완료!

서비스 피드백

고심하여 개발한 서비스에 대해 좋은 피드백받고 하루종일 감정이 부풀어올랐던 것 같다.

이 날은 개발자로 진로를 결정한 이후 가장 의미있던 날 중 하나라고 자부한다.

피드백 정리하며 팀원들과 회고하는 과정에서도 서로 너무 벅차올라서 땅콩의 미래에 대해서 뜨거운 토론을 주고 받았다.

잠도 제대로 못자서 너무 피곤하고 힘들었는데, 그것도 잊고 엄청나게 떠들고 회식까지 즐겨버렸다..! (사실 이러다 회식때 잠들어서 사진찍혔다;)

사소한 행복들

우테코 후드티 수령..!

이젠 나도 정말 엄연한 우테코 사람.

우테코 근로에서 고생해서 만들어준 후드티를 드디어 수령했다..! 너무 맘에 들어서 자주 입고 있었다 ㅋㅋ

타칸의 코로나..

타칸의 코로나 대소동

우리의 소중한 팀원 타칸이 코로나에 걸려서 다같이 코찌른 날이다.

재미난 추억 중 하나다.

지각하면 커피 문화

팀원들의 7회 지각 적립으로 만들어진 커피 7잔..

우리 팀은 재미난 문화가 있다. 바로 '지각하면 커피' 문화인데

땅콩팀 커피 문화

이렇게 지각할 때마다 1개씩 적립해서 7번 지각자가 발생하면 커피 타임이 발생한다 ㅋㅋㅋ

나도 이 커피 타임의 대주주 중 하나였는데, 프린과 내가 모든 커피의 절반을 샀다고 해도 과언이 아니다..

정신 차리고 살아야겠다. (죄송합니다 우리팀 ㅎㅎ..)

마치며

레벨1,2가 각자의 개발적 가치관을 쌓아가는 시기라면 레벨3는 쌓아올린 것들을 바탕으로 팀원들을 설득하고 이를 통해 함께 성장해나가는 뜻깊은 시간으로 느껴졌다.

개발자로서의 성장뿐만 아니라 사람으로서, 팀원으로서의 성장도 팀원들과 시간을 보내며 정말 많이 이룰 수 있었다.

너무 좋은 우리 팀원들 프린,타칸,커찬,마루,썬데이,포메 와 함께한 덕분에 시간가는 줄 모르고 보냈던 레벨3였다.

또 개발자 인생 처음으로 만난 서비스의 유저들로부터 긍정적인 피드백을 받으며 마무리한 레벨3는 레벨4에 대한 기대감을 한껏 끌어올려주었던 것 같다.

이전엔 잘 짜여진 코드와 잘 동작하는 프로그램을 보며 재미를 느꼈다면, 요즘은 내가 만든 서비스를 통해 유저가 가치를 느꼈을 때가 가장 재미와 보람을 느끼게 되었다.

더운 여름 함께 고생한 우리 땅콩팀 수고 많았고, 레벨4,5 그리고 우테코 수료 이후에도 계속 즐겁게 달려나갔으면 좋겠다:)

외부에서 접근이 불가능한 EC2에 Self Hosted Runner를 적용해서 CI/CD 구축하기

PgmJUN — Tue, 23 Jul 2024 01:04:02 +0900

사용기술

AWS EC2
Git Actions
Nginx
Springboot/Java

AWS 보안 그룹 및 권한 제한으로 인한 고민

ec2는 우테코에서 기본 제공해주는 VPC, Subnet, 보안그룹을 사용해야했으며, 여러 기능에 대해서 권한 제한이 걸려있었다.

우아한형제들 계정의 IAM 사용자 계정이기 때문에 혹시라도 AWS 사용에 미숙한 크루원이 pem키 같은 중요한 정보를 Github에 업로드하는 등의 실수를 하게 되면, 회사에 큰 재산적 피해가 갈 수 있기 때문인 것 같았다.

AWS IAM 에서 SecretKey를 발급받을 수 있는 권한이 없었고, EC2 접근도 80,443 포트만 전체 접근으로 열려있었고 ssh 프로토콜 통신을 위한 22번 포트는 우테코 캠퍼스 내부 LAN에 연결된 상태로만 접근 가능했다.

때문에 원래 ssh를 통해 EC2에 접근하는 방식으로 CD 스크립트를 작성하려던 나는, 어떤 방식으로 CD 스크립트를 작성해야할 지에 대한 고민이 커지게 되었다.

배포 도구로 Git Actions를 사용할 예정이었는데,

Git Actions이 돌아가고 있는 Runner는 Github 가 구축한 네트워크 환경에서 작동 중일 것이라서

우테코 LAN에서만 접근 가능한 땅콩의 EC2 환경에, 일반적인 Git Actions 환경을 통해 접근하기란 불가능할 것이기 때문이었다.

나는 이를 해결하기 위해 Self hosted Runner를 사용해서 문제에 접근해보았고,
다행히 Git Actions를 사용하여 우리의 프로젝트 땅콩의 API 서버를 정상적으로 배포하는 것에 성공할 수 있었다.

그리고 그 과정들을 기록해보고자 글을 작성하게 되었다.

프로젝트 패키지 구조

프로젝트 패키지 구조는 조금 특이한데 최상위 패키지 아래에 backend, frontend 패키지가 나뉘어있는 구조이다.

클라이언트와 백엔드는 다른 Repository에 구현하는게 일반적으로 알고 있지만, 이러한 상태로 구현하도록 환경을 제공받아서 이렇게 구현하게 되었다.

CI/CD 워크플로우는 ~/.github/workflows/ 내부에 존재한다.

(이곳에 작성해야 Repository의 Action 탭에서 워크플로우를 인식할 수 있다.)

이제 본격적으로 내용을 살펴보자

EC2에 외부 접근이 불가능한 문제 해결하기

위에서 말했듯이, Self-Hosted Runner 설정을 통해 EC2에 외부 접근이 안되는 문제를 해결했다.

그럼 Self-Hosted Runner란 무엇이며, 어떻게 문제를 해결할 수 있었을까?

GitHub Actions - Self-Hosted Runner

Self-Hosted Runner는 기본적으로 Github Actions 환경에서 제공하는 Runner가 아닌,
커스텀 환경에서 Runner를 Self로 hosting 하여 사용하는 방식이다.

우테코 AWS 계정의 권한 이슈로 인하여

외부로부터 ssh 프로토콜로 EC2에 접속하여 배포 스크립트를 수행시키는 등의 작업이 제한되었기 때문에,

애초에 Runner 자체를 우리 EC2에서 Hosting하고 그 Runner를 사용함으로써

외부에서 EC2에 접근하여 배포작업을 시키는 방식이 아닌,
EC2 내부에서 Git Action 스크립트를 수행시키는 것이다.

추가로 EC2에 SSH 접속을 통해 배포를 수행하는 방법은 다음과 같은 오버헤드 발생

보통 SSH를 통해 배포하는 경우, EC2에 Github Repository를 clone 받아둔 상태로 사용하고
배포할 때마다 git pull , artifact build 작업을 dev 환경에서 수행해야한다.

반면 Self Hosted Runner를 사용하면 artifact actions를 활용해 오버헤드를 줄여볼 수 있음.
Actions Runner에서 build를 수행하고 artifact 파일을 흭득한 후, 배포할 EC2에서 artifact 파일을 artifact actions로 다운로드 받기만 하면 된다.

Self-Hosted Runner 설정 과정

설정 권한

우선 개인 레포지토리에 Self-Hosted Runner를 설정하려면 Repository의 Owner여야 한다.

조직 레포지토리의 경우, 조직의 소유자이거나 레포지토리에 대한 관리자 엑세스 권한이 있어야한다.

Repository - Settings 접속

설정을 원하는 Repository의 Settings에 접속한다.

Actions - Runners 탭 접속

Actions 의 Runners 탭을 눌러 들어간다.

New self-hosted runner 버튼 클릭

runner 추가를 위해 해당 버튼을 클릭한다.

EC2에 맞는 환경 설정 및 Runner 생성 스크립트 입력

Runner를 설치 및 세팅할 EC2의 환경과 동일한 설정을 해준 뒤에,
아래 나와있는 스크립트를 EC2에서 실행해주면 설정이 끝난다.

Download 스크립트를 실행하여 self-hosted runner application을 EC2에 설치하고

Configure 스크립트를 실행하여 자체 호스팅 러너 애플리케이션을 구성하고 GitHub Actions에 등록한다.
구성 스크립트에는 요청을 인증하기 위해 대상 URL과 자동 생성된 시간 제한 토큰이 설정되어 있는데, 검정색으로 가린 부분이다.

[Self-Hosted Runner Name, Label 설정]

'ddangkong-dev'라는 runner name 지정

'dev' label 추가

Configure 설정에서는 self-hosted runner의 '구별자(이름)'와 '레이블(Label)'을 지정할 수 있다.

레이블은 self-hosted, Linux, X64가 기본값으로 주어진다.

설정 내용은 Github Runners에서 다음과 같이 보여진다.

성공 문구 확인

√ Connected to GitHub
2019-10-24 05:45:56Z: Listening for Jobs

EC2에서 위 문구가 출력되면 성공이다.

워크플로우가 동작할 Runner 설정

jobs:
  deploy:
    runs-on: [dev]

실행기에 할당된 레이블(Label) 또는 해당 그룹 멤버 자격 또는 이러한 것들의 조합을 기반으로,
워크플로에서 사용할 자체 호스트 Runner를 지정할 수 있다.

나는 레이블을 통해 위와 같이 Runner를 설정해주었다.

레이블은 Runner를 사용하려는 운영체제 또는 아키텍쳐 등에 적합한 Runner 타겟팅 목적으로 사용할 수 있다.

job의 Runner를 설정하는 옵션인 runs-on 에 레이블을 입력해두면
입력된 모든 레이블을 가진 Runner에서 job의 스크립트가 실행된다.

이 외에도 그룹 정보를 통해 Runner 지정도 가능한데,

자세한건 공식문서 에서 확인할 수 있다.

백그라운드 실행 설정

Configure 설정을 마치면 run.sh 명령을 통해 Self-Hosted Runner를 실행하게 된다.

그리고 편의를 위해 해당 sh 스크립트를 백그라운드에서 실행할 수 있는 run-bg.sh 를 만들어두고자 한다.

sudo vi run-bg.sh

위와 같이 run-bg.sh 를 생성하고

#!/bin/bash

nohup ./run.sh &

내부에 위와 같이 백그라운드 실행 코드를 작성한다.

nohup이 아니라 sh로 설정해도 상관은 없다만, sh로 설정 시 가끔 runner가 종료되는 이슈가 있어서 nohup으로 설정했다

Nginx Reverse Proxy 설정

우테코에서 제공하는 EC2 보안 그룹은 80, 443 포트 외에 다른 포트는 외부에서 접근할 수 없게 되어 있었다.

아직 프로젝트 극초반이라, HTTPS 설정은 하지도 않았기 때문에

우선 80번 포트로 요청이 들어오면 포트포워딩하여 스프링부트 애플리케이션으로 요청을 전달해주면 되겠다고 생각했다.

이때 리버시 프록시 서버를 WAS 앞에 두어 일시적으로 포트포워딩 문제를 해결해보고자 하였다.

프록시 서버가 무엇인지 모르는 이들은 아래 게시글을 참고하면 될 것이다.

스프링부트에 Nginx 리버스 프록시(Reverse Proxy) 서버 연결하기

리버스 프록시를 도입하게된 계기 졸업작품인 코리(Co:RE)의 서버를 개발하면서 실제로 배포를 위한 환경을 만들려고 하다보니,보안적인 요소를 생각하지 않을 수 없었다. 1차적으로 생각이

pgmjun.tistory.com

설정법 또한 친절하게 작성해두었는데, 그래도 잘 이해가 안간다면 댓글을 남겨주세요!

CI 스크립트

name: BE CI for Dev

on:
  workflow_dispatch:

  pull_request:
    branches: [ "develop" ]
    paths:
      - backend/**

jobs:
  build:
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: ./backend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        run: ./gradlew build

이는 CI 스크립트이다.

코드가 길기 때문에 스니펫 형태로 설명하겠다.

on: workflow_dispatch

on:
  workflow_dispatch:

workflow_dispatch 설정이다.

workflow_dispatch는 Repository의 Actions 탭에서 수동으로 스크립트를 실행시킬 수 있는 기능이다.

현재 스크립트의 trigger path가 ./backend 패키지로 구분되어있어서 최상위에 있는 .github 디렉토리에 대한 변경 정보에 대해서는 CI/CD 가 작동하지 않는다.

때문에 workflow_dispatch 설정을 통해 버튼으로 Actions에 있는 스크립트를 실행시킬 수 있도록 구현한다.

패키지 구조가 backend, frontend로 구분되어 있어서 어쩔 수 없이 발생하는 문제였는데, 브랜치를 통해 be, fe 작업 단위를 나눌 것이 아니라면 이렇게 관리해야했다.

이번 스프린트가 끝나고 브랜치 관리 전략이 be, fe 단위로 변경될 가능성이 있으나
아직은 그렇지 않으니 이렇게 처리하는 것이 최선이었다. 자세한 내용은 여기에서 확인하자.

on: pull_request

on:
  pull_request:
	branches: [ "develop" ]
	paths:
	  - backend/**

on: <시점> 은 언제 해당 스크립트가 동작할 지에 대한 설정이다.

시점은 pull_request로 설정하였고, branches 옵션의 값을 develop, path를 backend/** 로 두었기 때문에 develop 브랜치에 backend 디렉토리 내부 변경이 포함된 PR이 올라오면 해당 스크립트를 동작시킨다.

만약 PR 이후, PR에 커밋이 추가되어도 스크립트가 작동된다.

공식문서에서 자세한 내용을 확인할 수 있다.

build job

jobs:
  build: # build 작업
    runs-on: ubuntu-latest #ubuntu 최신 버전에서 동작

    defaults: # 기본 설정
      run:
        working-directory: ./backend # 작업 디렉토리를 ./backend 로 선언

    steps:
      - name: checkout # PR 브랜치 checkout
        uses: actions/checkout@v4

      - name: Set up JDK 17 # Oracle Temurin JDK 17 설치
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Grant execute permission for gradlew # gradlew 실행 권한 설정
        run: chmod +x gradlew 

      - name: Build with Gradle # Gradle을 사용하여 빌드
        run: ./gradlew build # clean build 명령을 통해 애플리케이션 테스트 및 컴파일 과정 수행

jobs는 스크립트에서 수행할 작업을 나열한다.

CI 스크립트에는 build 작업만이 존재하는데 내용이 길어 주석으로 설명하겠다.

따로 설명할 가장 주요한 포인트는 Build with Gradle인데

빌드를 위한 세팅을 완료한 이후, 최종적으로 테스트와 컴파일 과정을 포함한 ./gradlew build 를 작동시켜 CI 과정을 완료한다.

CI에서 build Task를 수행하는 이유는 다음과 같다.

build Task는 모든 테스트 실행, 프로덕션 artifact 생성을 포함하여 모든 것을 빌드한다고 공식문서에 작성되어 있다. 이를 통해서 정상적으로 프로덕트가 정상 작동 가능한 지 검증하는 것이다.

그리고 이 과정을 CI에서 이미 거치기 때문에 성능적인 측면을 고려하여,
CD에서는 bootJar task만 동작시켜 실행가능한 artifact 생성만 수행하도록 구현하였다.

이제 CD 스크립트를 살펴보자.

CD 스크립트

name: BE CD for Dev

on:
  workflow_dispatch:

  push:
    branches: [ "develop" ]
    paths:
      - backend/**

jobs:
  deploy:
    runs-on: [self-hosted, linux, ARM64] # Self hosted runner 사용
    steps:
      - name: Execute script on EC2 to deploy
        run: sudo sh ~/deploy-script-dev.sh

CD 스크립트는 Github에서 내려받아 CI 스크립트보다 훨씬 짧다.

이 코드도 스니펫 형식으로 자세히 알아볼 건데, 중복된 부분은 설명하지 않고 넘어가겠다.

on: push

on:
  push:
    branches: [ "develop" ]
    paths:
      - backend/**

pull_request 시점에 작동하는 CI 스크립트와는 달리,

CD 스크립트는 develop 브랜치의 backend 패키지에 변경사항이 push되는 시점에 동작하도록 만들었다.

deploy job

jobs:
  deploy:
    runs-on: [self-hosted, linux, ARM64] # Self hosted runner 사용
    steps:
      - name: Execute script on EC2 to deploy
        run: sudo sh ~/deploy-script-dev.sh

이번 배포의 가장 중요한 부분인 deploy job이다.

위에서 설명한대로 우테코 AWS 계정 EC2는 ssh 접근이 특정 네트워크로 제한되어 있었다.

나는 이를 해결하기 위해 Self hosted Runner를 사용해서 문제에 접근해보았고, 정상적으로 배포하는 것에 성공할 수 있었다.

Self hosted Runner는 기본적으로 Github Actions 환경에서 제공하는 Runner가 아닌,

직접 자신의 환경에서 Runner를 Self로 host하여 사용하는 방식이다.

Git Actions에서 EC2에 ssh로 접근하여 스크립트를 수행시키는 등의 작업이 불가능하기 때문에,

애초에 Runner 자체를 우리 EC2에서 Host하고 그 Runner를 사용함으로써

외부에서 EC2에 접근하는 방식이 아닌 EC2 내부에서 스크립트를 수행시킬 수 있는 것이다.

runs-on 에 들어간 내용은 내가 설정한 Self hosted runner의 Label이다.

Label을 통해 동작시킬 Self hosted Runner를 지정할 수 있다.

그럼 마지막으로 이러한 설정을 통해 실행시키려는 deploy-script-dev.sh 에는 어떤 스크립트가 작성되어 있는지 확인해보자.

deploy-script-dev.sh

#!/bin/bash

# 1. 프로젝트 디렉터리로 이동
cd /home/ubuntu/2024-ddangkong/backend/ || { echo "Directory not found"; exit 1; }

# 2. develop 브랜치로 체크아웃
git checkout develop || { echo "Failed to checkout develop branch"; exit 1; }

# 3. 원격 저장소의 최신 상태를 가져와서 병합
git pull origin develop || { echo "Failed to pull latest changes"; exit 1; }

# 4. gradlew bootJar 명령을 실행하여 빌드
./gradlew clean bootJar || { echo "Build failed"; exit 1; }

# 5. 빌드된 JAR 파일을 실행
cd build/libs || { echo "Build directory not found"; exit 1; }
JAR_FILE=$(ls *.jar | head -n 1)

if [ -z "$JAR_FILE" ]; then
  echo "No JAR file found"
  exit 1
fi

# 이전에 돌아가고 있던 Spring 애플리케이션 종료
PID=$(lsof -t -i:8080)

if [ -n "$PID" ]; then
  echo "Killing process $PID running on port 8080"
  kill -9 $PID
  echo "Process $PID has been killed"
else
  echo "No process is running on port 8080"
fi

# 우선 nohup에 로그 출력하고 이후에 logback 붙이기
nohup java -Dspring.profiles.active=dev -Duser.timezone=Asia/Seoul -Dserver.port=8080 -jar "$JAR_FILE" &
~

EC2 ~/ 경로에 작성해둔 dev 환경의 deploy 쉘 스크립트 파일이다.

이 sh 파일을 실행하면 [Github에서 땅콩의 Repository를 Pull] → [build] → [기존에 작동하던 스프링부트 애플리케이션 종료] → [새로운 애플리케이션 실행] 과정을 수행한다.

이 스크립트를 Runner에서 작동시킴으로써 CD 과정을 마무리할 수 있었다.

마치며

이 글에서 작성된 내용은 아직 부족한 점이 많은 초기의 CI/CD 스크립트들이다.

가장 중요한 문제는 CD 과정의 핵심적인 부분인 deploy script가 EC2 환경에 의존적이라는 점인데,

다음 글에서는 이러한 부족한 점과, 부족한 점들을 개선해본 CI/CD 파이프라인을 가지고 돌아오려고 한다.

Reference

GitHub Actions 설명서 - GitHub Docs

Github Action으로 CI/CD 구성하기

About self-hosted runners - GitHub Docs

[협업] 누군가 해주길 기다리지 않고 직접 나서기

PgmJUN — Mon, 15 Jul 2024 01:25:49 +0900

우테코의 프로젝트는 2주 간격으로 데모데이가 있어서, 2주 단위 스프린트 방식으로 개발이 진행된다.

이렇게 짧은 단위로 빠르게 치고 나가는 환경에서 같이 일하고 싶은 ‘좋은’ 팀원이 되기 위해, 그리고 ‘좋은’ 팀을 만들기 위해 첫 스프린트 기간인 2주 간 몇 가지 시도와 노력을 거쳐왔다.

좋은 팀원이 되기 위해 노력하게 된 가장 큰 계기는 우테코 때문인데
우테코에서 진행하는 소프트스킬 수업을 들으면서
“협업에 있어서 함께 일하고 싶은 사람은 어떤 사람일까?”, “그런 사람이 되려면 어떻게 해야할까?” 에 대해 고민하게 되었고,
‘좋은 팀원’이란 무엇일지에 대해 정의를 내려보면서 점차 그런 사람이 되기 위해 노력하게 되었다.

내가 생각하는 ‘좋은’ 팀원이란 누군가 해주길 기다리지 않고 직접 나서는 사람이었다.

여기서 “해준다” 에 내포된 행위들은 문제 해결이 될 수도 있겠고, 귀찮은 잡무일 수도 있다.
또는 문제에 대한 적극적인 고민과 해결 방안 제시일 수도 있을 것이다.

서로를 배려하는 생각으로 “내가 할게!”, “이거 해보는거 어떨까?” 라며 직접 나서서 움직이고 제안하는 사람이
내가 되고 싶은 모습이자 진심으로 함께 하고 싶어하는 사람의 모습이었다.

그렇기에 이번 우테코 팀프로젝트에서 서로에게 긍정적 영향을 미치는 팀 분위기를 만들어보고자
내가 먼저 행동으로 실천하기로 다짐했다.

이번 글은 이러한 배경을 바탕으로
레벨3 스프린트1 기간을 어떤 태도로 임했는 지 되돌아보는 글이다.

1. 적극적으로 고민하기

프로젝트를 기획하는 단계에서 괜찮은 프로덕트를 만들고 싶다는 생각을 팀원들에게 전가하지 않고
직접 행동하고 생각해서 다양한 의견들을 많이 제시하였다.

기획 회의 도중 막혔던 부분은
캠퍼스에서 퇴근 후 집에 가서 수 차례 고민하고 다음날 데일리 미팅 시간에 공유하였고,
바보같은 의견 같을지라도 의견을 최대한 많이 내기 위해 노력했다.

보통 그렇게 던져지는 의견 중 쓸만한 내용이 10개 중 1개씩은 있었기 때문이다.

실제로 이 중 팀원들에게 긍정적으로 받아들여진 부분이 다수 있었고, 프로젝트 기획에 열정적으로 기여를 할 수 있었다.
너무나도 소중한 우리 팀원들은 근거를 기반으로 아닌 것은 확실히 쳐내주고, 좋은 것은 받아들여주어서 더 만족스러운 기획을 할 수 있었다.

이러한 노력을 알아주었는지, 스프린트 회고 시간에 팀원들로부터 주도적으로 행동한 부분에 대해 긍정적인 피드백들을 받을 수 있었다.

티는 안냈지만 혼자 읽어보면서 감동받았고, 노력을 알아봐준 팀원들에게 고마워서 더 열정이 생겼다

2. 적극적으로 공유하기

개발적인 부분에 있어서 팀원들이 고민하는 포인트가 있으면 직접 나서서 확인하고 빠르게 공유해주었다.

회의 시간에 백엔드 팀원인 프린으로부터 내가 주장한 @RequestMapping 애노테이션 설정이
핸들러 매핑 과정에서 성능 이슈 를 유발할 수 있지 않느냐는 이야기를 듣게 되었다.

충분히 고려해볼만한 좋은 의문이었지만 이에 대해 자세히 알고 있는 팀원들이 없었기에
직접 RequestMappingHandlerMapping 로직을 뜯어보고 그 결과를 팀원들에게 공유해주었다.

이러한 공유 문화가 활성화되면 '선삽자(먼저 삽질하는 사람)' 인 나도 학습할 수 있고,
팀원들도 학습에 필요한 시간을 줄여서 또 다른 삽질 & 공유 사이클을 만들어 어느 팀보다 빠르게 성장할 수 있다고 생각한다.

3. 개발 생산성 향상 방안 고민하기 (with. 협업 툴)

협업 과정에서 개발 생산성을 향상시키는 방법은 다양하지만,
그중 협업을 편하게 만들어주는 협업툴을 활용하는 것도 좋은 방식이라고 생각한다.

우리팀은 우테코에서 사용하고 있는 Slack을 사용하여 프로젝트 협업 관리를 하려했지만,
무료 버전에서는 대화 기록이 3개월 밖에 유지되지 않는 Slack의 단점이 너무 크다는 판단 하에
Discord를 협업툴로 정하게 되었다.

Discord는 정말 다양한 서비스와 연동하여 사용할 수 있는 협업툴인데,
Discord 채널에 Webhook을 연결하여 Github 내에서의 Issue 생성, PR 생성 등 특정 행위가 발생하면
알림을 보내도록 설정할 수 있었다.

우리 팀의 VCS(Version Control System)는 Github이고,
VCS와 관련된 주요 동작이 발생하면 우리의 협업 공간에 알림은 주는 것은
개발 생산성에 큰 효력이 있을 것이라고 생각했다.

이 부분은 팀원들도 공감하는 내용이었고,
때문에 Webhook을 활용하여 ‘Github to Discord 알림’ 설정을 주도하게 되었다.

팀 Discord 채널에 연결된 Github 알림

위 사진과 같이 알림을 받겠다고 설정해둔 이벤트가 발생하면, Github에서 우리의 슬랙 github 채널로 알림을 보내도록 설정하였다.

이를 통해 팀원들이 더욱 빠르게 깃헙에서 발생하는 프로젝트 진행 상황을 공유받을 수 있게 되었고 이는 분명 우리팀의 생산성을 높여줄 것이라고 생각한다.

설정 방식과 관련 내용은 여기에서 확인할 수 있다.

마치며

좋은 팀원이 되기 위한 다짐은 이번 프로젝트에 몰입할 수 있도록 만들어주는 원동력이 되고있다.

지금의 모습에서 나태해지지 말고 항상 내가 할 수 있는 것을 찾고, 분석하고, 시도하자.
팀에 긍정적인 영향을 끼칠 수 있도록 힘든 일도 앞장서는 사람이 되자.
겁먹지 말고 시도하고 깨지고 그 속에서 배움을 얻는 사람이 되자.
그리고 그 과정에서 내가 팀원들의 경험 기회를 뺏어가고 있지는 않은지 항상 경계하고 인지하자.

Github Webhook을 협업툴과 연결해서 팀의 생산성 높이기 (with. Discord)

PgmJUN — Mon, 15 Jul 2024 01:12:50 +0900

협업 과정에서 개발 생산성을 증가시키는 방법은 다양하지만, 그중 협업을 편하게 만들어주는 협업툴을 활용하는 것도 좋은 방식이라고 생각한다.

우리 땅콩 팀은 우테코에서 사용하고 있는 Slack을 사용하여 프로젝트 협업 관리를 하려했지만,
무료 버전에서는 대화 기록이 3개월 밖에 유지되지 않는 Slack의 단점이 너무 크다는 판단 하에
Discord를 협업툴로 정하게 되었다.

Discord는 정말 다양한 서비스와 연동하여 사용할 수 있는 협업툴인데,
Discord 채널에 Webhook을 연결하여 Github 내에서의 Issue 생성, PR 생성 등 특정 행위가 발생하면 알림을 보내도록 설정할 수 있었다.

우리 팀의 VCS(Version Control System)는 Github이고,
VCS와 관련된 주요 동작이 발생하면 우리의 협업 공간에 알림은 주는 것은 개발 생산성에 큰 효력이 있을 것이라고 생각했다.

이 부분은 팀원들도 공감하는 내용이었고, 때문에 Webhook을 활용하여 ‘Github to Discord 알림’ 설정을 주도하게 되었다.

아래에는 그 과정을 설명해놓았으니 필요한 사람들은 따라서 해보면 될 것이다.

Discord에 알림을 전달받을 채널 생성

디스코드 서버에 깃허브 알림을 받을 채널을 하나 생성한다.
이름은 자신이 원하는 대로 설정하면 되는데, 나는 github이라는 이름으로 설정하였다.

Discord 채널 Webhook 설정

이제 본격적으로 Webhook 설정을 수행해보자.
아래 사진의 설명을 따라가보자.

Webhook 설정을 원하는 서버의 ‘서버 설정’ 클릭

좌측 설정 탭 - 연동 - 웹후크 만들기 클릭

이름은 원하는 대로 설정하고, 채널은 알림을 보내줄 채널을 선택한다.
나는 방금 알림을 위해 만든 github 채널을 선택했다.

Webhook 생성 후에는 ‘웹후크 URL 복사’ 버튼을 통해 URL을 복사해주고 알림을 받을 Github Repository로 이동한다.

Github Repository Webhook 설정

이젠 Github Repository에서 Webhook 설정을 통해 Discord와 연결을 해주면 알림 설정이 마무리된다.

Repository - Settings 클릭

좌측 설정 탭 - Webhooks 클릭

좌측 상단에 ‘Add webhook’ 버튼 클릭

기본 설정

‘Payload URL’에 Discord에서 복사해온 웹후크 URL + /github 입력
‘Content type’에 application/json 입력

트리거 설정

최하단 설정을 보면 webhook의 trigger를 설정할 수 있다.

첫 번째는 push 이벤트만 알림을 보내는 것
두 번째는 모든 이벤트의 알림을 보내는 것
세 번째는 선택 사항에 대한 알림만 보내는 것이다.

트리거는 세 번째를 선택하여 선택 사항에 대한 알림만 받도록 하였다.

push만 알림을 받기에는 정보가 적어 생산성 향상에 큰 도움이 되지는 않을 것이다 싶었고, 모든 이벤트에 대한 알림을 보내는 것은 오히려 알림을 통해 전달받는 정보의 질을 저하시킨다고 느꼈다.

때문에 세 번째를 선택했고, Issue, PR, Release, PR에 리뷰가 달렸을 때 를 알림이 필요한 정보라고 생각해서 받도록 설정해주었다.

팀 Discord 채널에 전달된 Github 알림

이제는 Issue, PR, Release, Milestone, Push 와 관련된 이벤트가 발생하면 위 사진과 같이 Github에서 우리의 슬랙 github 채널로 알림을 보낸다.

이를 통해 팀원들이 더욱 빠르게 깃헙에서 발생하는 프로젝트 진행 상황을 공유받을 수 있게 되었고
이는 분명 우리 팀의 생산성을 높여줄 것이라고 생각한다.

스프링 MVC 내부 동작 원리 (with. 핸들러 매핑, 어뎁터 매핑, Filter, Interceptor.. etc)

PgmJUN — Sat, 13 Jul 2024 17:01:18 +0900

이 글은 김영한님의 스프링 MVC 강의 영상을 참조하여 작성되었습니다.

Spring MVC 동작 과정

0. HTTP 요청

Client로부터 요청이 들어오면 Front Controller인 Dispatcher Sevlet이 요청을 받는다.

Dispatcher Sevlet은 받은 요청을 처리할 수 있는 Handler 객체를 가져온다.

0번 과정에서 Dispatcher Servlet에 요청이 들어오기 직전이 Filter의 동작 시점이다.

Dispatcher Servlet 이후에 동작하는 ControllerAdvice는 이러한 동작 시점에 의해 Filter 측에서 발생하는 예외까진 잡지 못한다는 특징이 있다.

1. 핸들러 조회

핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.

✅ RequestMappingHandlerMapping

SpringBoot를 사용하면 0순위로 @RequestMapping 애노테이션 기반 Handler를 찾아 반환한다.

URI에 입력된 Endpoint와
@RequestMapping 애노테이션에 설정된 Endpoint를 비교하여
요청을 담당하는 Handler를 조회하는 것이다.

✅ BeanNameUrlHandlerMapping

0순위가 실패하면 1순위로는 요청한 URI와 일치하는 스프링 빈 이름의 Handler를 찾아 반환한다.

2. 핸들러 어댑터 조회

핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.

✅ RequestMappingHandlerAdpater

SpringBoot를 사용하면 0순위로 @RequestMapping 애노테이션 기반 Handler의 Adapter를 찾아 반환한다.

✅ HttpRequestHandlerAdapter

HttpRequestHandler를 implements하여 구현한 Handler를 처리하는 일을 수행하며 1순위로 동작한다.

✅ SimpleControllerHandlerAdpater

Controller를 implements하여 구현한 Handler를 처리하는 일을 수행하며 2순위로 동작한다.

3. 핸들러 어댑터 실행

핸들러 어댑터를 실행한다.

4. 핸들러 실행

핸들러 어댑터가 실제 핸들러를 실행한다.

4번 과정 전/후 가 Intercepter의 동작 시점이다.

5. ModelAndView 반환

HandlerAdapter는 Handler가 반환하는 정보를 ModelAndView 객체로 변환해서 반환한다.

6. viewResolver 호출

5번 과정에서 얻은 ModelAndView 객체를 통해 view의 이름을 뷰 리졸버에 전달한다.

JSP의 경우 InternalResourceViewResolver가 자동 등록되고, 사용된다.

7. View 반환

뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 view 객체를 반환한다.

8. 뷰 렌더링

View Resolver를 통해 얻은 view 객체에 5번 과정에서 얻은 ModelAndView의 Model을 파라미터로 넘겨주고 render() 메서드를 실행하여 페이지 렌더링을 수행한다.

9. 페이지 반환

최종적으로 렌더링된 페이지를 Client에게 response한다.

마치며

Spring은 이미 대부분의 Handler Mapping과 Handler Adpater를 구현해 두었기 때문에 직접 구현할 일은 거의 없다.
하지만 동작원리를 충분히 이해하고 사용하는 것과 그렇지 못한 것은 큰 차이가 있다.
항상 돌아가게만 만들어 사용하지 말고 어느정도는 이해하고 사용하는 습관을 갖자

[우아한테크코스 6기] 레벨2 돌아보기 (2024/04/15 ~ 2024/6/14)

PgmJUN — Mon, 1 Jul 2024 23:52:52 +0900

우테코에 들어온 지 진짜 얼마 안된 것 같은데 어느덧 시간이 지나 레벨3가 시작하기 전날이 되었다.
레벨3를 시작하기 전, "내가 어떤 것들을 중점에 두고 레벨2에 임했는가", "레벨2를 거치며 어떤 성장을 이루었는가" 를 되돌아보는 글을 적어보려고 한다.

무엇을 중점에 두었는가

하나의 레벨은 내가 원하는 걸 다 챙길 수 없는 2달 가량의 짧은 기간이기 때문에
이 안에서 가장 효율적으로 무언가를 얻을 수 있는 방법을 찾기 위해 힘쓴 것 같았다.

우테코에서 가장 많이 얻어갈 수 있는 학습 방법 찾기

특히 학습 방법에 고민이 많았다.
레벨1을 되돌아보면 생각보다 공부할 시간이 많이 없다고 느꼈다.
미션을 수행하면서 스터디도 하고 책도 보고 하는 사람들 정말 신기했다.

만약 어떤 날 하루동안 A,B를 하려고 했다면 A를 다 끝내지도 못한 상태로 하루가 지나가는 경우가 너무 많았다.
시간 컨트롤이 정말 힘들었다.
(레벨3 팀원들과 시간관리에 대해서 얘기해보고 싶다.)

아무튼 나는 이 짧디 짧은 시간 속에서 가장 많은 정보를 챙겨가는 방법을 찾아나섰고
내가 사용한 방법은 이것들이다.

1. 학습 키워드 기록

미션 1개에 2주의 시간이 주어지는데, 2주는 생각보다 짧다.
이 안에 가장 많이 챙겨가는 방법은 하나 뿐이었다.
바로 '기록'

키워드 학습 기록

나는 미션을 수행하면서 정말 궁금하고 당장 알지 못하면 못참겠다 싶은 내용들은 그날그날 학습하면서 기록했지만
일단 돌아가게 만들고 나중에 찾아보아도 괜찮은 부분들에 대해서는 학습 키워드만 기록해두고 넘어갔다.
그리고 나중에 시간에 여유가 있을 때, 궁금했던 부분들 부터 하나하나 학습하며 기록해두곤 하였다.
그리고 내가 기록하지 않아도 이미 잘 정리된 래퍼런스가 있는 경우는 그냥 래퍼런스를 기록해두곤 하였다.

최근 블로그에 하나씩 올리는 포스팅은 이때 작성해둔 글들을 다듬어서올리는 것이다ㅋㅋ

2. 좋은 질문 많이하기

예전에는 질문한다는 것 자체가 정말 어려웠다.
내가 뭘 모르는 지 몰랐고, 모르는 것을 드러내는 것이 부끄럽다고 생각했다.
그래서 질문을 잘 하는 사람들이 정말 멋있어보였고 나도 그렇게 되고 싶었다.

하지만 우아한 테크코스의 분위기는 질문을 권장하고, 질문을 제대로 못해도 아무도 비난하지 않았다.
때문에 질문이라는 것 자체에 대한 부담이 많이 없어졌다.

또한 질문은 그저 많이한다고 좋은 것은 아니다.
의미있는 질문을 던져야 똑같이 의미있는 답변을 들을 수 있었다.

항상 질문 잘 하는 사람들을 보면 "어떻게 저렇게 근본적인 의문을 가지게 되는 걸까?" 라는 생각이 들었는데,
생각하며 학습하다보면 자연스럽게 근본적인 질문이 만들어지는 것 같았다.

생각하며 학습한다는 것은 "이게 뭐지" 하고 넘기는 것이 아니라 그 의문을 정확히 캐치해서 '궁금증'으로 바꿔내는 능력이다.

항상 개발을 하다가 문제가 발생하면 어떻게든 해결만 하고 넘어가던 나는 질문할 거리가 없는 것이 당연했을 터다.

문제가 어떻게든 해결되었다고 그냥 넘기지 말고 "이건 왜 이렇게 되는거지?" 라는 의문을 항상 품자

3. 잡담은 경쟁력!

공부하다가 내가 어떤 사고의 흐름을 만들어냈다고 가정하자.
예를 들어 어떠한 근거를 통해 DB 테이블을 설계했다.
그럼 그냥 넘어가지 말고 근처에 사람들이 있는 곳에 가서 이러한 설계에 대해서 어떻게 생각하는 지 물어보았다.

다양한 사람들이 있고 다양한 의견이 있다.
여러 사람들의 의견을 듣다보면 내 의견을 더욱 좋은 방향으로 개선해나갈 수 있다.
또 다른 이들도 그 대화속에서 배움을 얻을 수 있다.

우테코는 이런 분위기인 것 같다.
많이 떠드는 사람이 많이 얻는다.

레벨1에서는 이를 깨닫지 못해 다른 이들과 대화를 많이 시도하지 않았지만, 레벨2에서는 대화를 많이했다.

라이트닝 토크 ⚡️

가벼운 주제라도 내 생각을 얘기하고 상대방의 의견을 물어보는 것은 '라이트닝 토크' 라는 활동을 통해 우테코에서도 제공되었다.

나는 API를 유연하게 설계하는 방법에 대해서 고민한 기록을 가볍게 발표를 해보았고 사람들의 의견을 들을 수 있었다.

위는 내가 'API 유연하기 설계하기' 에 대해 발표한 영상이다.
솔직히 여기 올리는게 부끄럽지만 성장하는 과정이니 귀엽게 봐줬으면 좋겠다..ㅋㅋ

이 내용에 대한 사람들의 답변을 들으면서 유연하게 설계하는 것도 좋지만 클라이언트를 너무 믿지 않아야한다는 점도 생각하게 되었다.

만약 내가 조회할 데이터의 수 등을 클라이언트가 설정할 수 있도록 열어준다면 비슷한 API를 여러개 만들 지 않고 재활용할 수 있을 것이다.
하지만 이렇게 설계하고 어떠한 조치도 없는 경우 모든 데이터를 반복적으로 조회하는 악의적인 요청을 대해 열린 상태가 되기도 한다. 이는 메모리 문제로 이어질 수 있었다.

또한 인기테마의 기준은 비즈니스 정책에 따라 결정되는 것이기 때문에 클라이언트로부터 받은 기준을 바탕으로 조회하는 것은 어색하다는 의견도 들을 수 있었다.

나는 유연한 설계에 대한 고민에 빠져서 이 부분은 생각하지 못했지만 라이트닝 토크를 통해 좁아졌던 시야를 넓힐 수 있었다.

또한 여러 잡담을 거치고 다양한 의견에 반박도 당해보는 과정에서, 스스로 생각할 때도 다양한 관점에서 접근해보아야 더 좋은 프로덕트를 만들어나갈 수 있다는 깨달음도 얻을 수 있었다.

역시 "잡담은 경쟁력"

리뷰어와 많은 대화

레벨1에서 아쉬운 점을 꼽으라면 리뷰어와 의미있는 대화를 많이 하지 못한 점이다.
내가 적극적으로 주도해서 질문하지 못했었고, 어떤 질문을 해야하는 지도 제대로 떠올리지 못했다.
또 한편으로는 현업자인 리뷰어에게 내 코드를 보여주는 것이 부끄럽기도 무섭기도 했다.

하지만 레벨2에서는 보다 열심히 질문하고 의문을 가지려고 노력했다.
'2. 좋은 질문 많이하기' 에서 말했던 것처럼 개발하면서 스쳐지나가는 의문을 놓치지 않고 궁금증으로 이어나갔다.

그리고 혼자만으로 해결하지 못한 문제들을 리뷰어에게 질문했고, 좋은 답변들을 받을 수 있었다.
그 과정에서 필요이상의 내용을 과하게 학습하는 실수도 있었지만, 레벨1에서는 받지 못했던 "의미있는 질문들을 했다"라는 리뷰어들의 피드백을 보면서 성장을 느꼈으며 꽤나 뿌듯해했던 기억이 난다.

어떤 성장을 이루었는가

이번 레벨2에서 가장 성장했다고 할 법한 부분은 '내면의 유연성' 과 '학습 방식' 이었다고 생각한다.

'유연성' 이란?

고통스럽다고 느끼지 않고 그런 상황에서 유연하게 대처할 수 있게 만들 수 있는 스킬이다.
고통스러운 상황을 이겨내고 그 상황으로부터 무언가를 배우는 것이 목표이다.

각 레벨마다 유연성 강화 목표를 설정하는데
레벨2에서 나의 목표는 '나에 대한 메타인지 기르기' 였다.

나에 대한 메타인지 기르기

이런 목표를 설정한 것은 큰 이유가 있다.
나는 남들이 공부했다고 하는 것들에 자극을 많이 받았다.

누군가 A를 학습했다고 하고, 누구는 B를 학습했다고 얘기하면
나는 "나도 사람들을 따라잡으려면 저것들을 학습해야하는데" 라는 생각이 들어서 학습목표가 점점 넓어지고
그렇게 넓어지는 학습 목표를 보며 의욕이 떨어지고 자신감이 줄어들던 사람이었다.

이를 해결하기 위해 레벨1에서는 페이스 조절을 목표로 생활하였고 조급한 마음을 느슨하게 풀어가는 과정이라는 돌아보기 글을 작성했었다.
그리고 레벨2에서는 개발이라는 행위 자체를 즐기던 내가 언제부터 이렇게 학습에 대한 강박과 조급한 마음을 가지게 되었는가를 찾는 근본적인 원인 탐색 시간을 가지게 되었다.
나의 인생의 흐름과 나 자신에 대해 이해하는 것이
앞으로 평생 학습을 해야하는 직업인 개발자로 살아가는데에 큰 도움이 될 것이라고 생각했다.

그렇게 레벨2의 유연성 강화 목표는 자연스레 '나에 대한 메타인지 기르기'가 되었고 그 과정에 대해 돌아보는 글도 작성하였다.

일일회고

일일 회고 기록

이 활동을 제대로 하기 위해 레벨2 기간동안 매일 나의 생각/느낀점/감정/배운점 을 글로 풀어내는 일일회고를 해보았다.

이 활동을 하게된 이유는 내가 평소에 어떤 생각을 하고 사는지 스스로 캐치하기 위함이다.
생각을 기록해야한다고 인지하고 있으면 어떤 생각이 떠올랐을 때 다시 한 번 곱씹어보게 되었고
기록하고 다시 한 번 흝어보면서 내 솔직한 생각의 흐름들을 파악할 수 있어 유익했다.

나는 이러한 유연성 강화 훈련을 통해 나 자신에 대해 약간이나마 이해할 수 있었고, 이로인해 개발에 임하는 자세 자체가 많이 변했다.
이제는 남들의 시선에 휘둘리지 않고 부족함을 인정하고 천천히 나아가려는 태도를 갖게 되었다.

남들이 보기에는 잘못된 주장일 수도 있어 부끄럽지만 내 라이트닝 토크 영상을 여기 올린 것도 내 자세가 개선되었음을 반증하는 것이라 생각한다. 예전의 나였다면 올리지 않고 숨겼을 것이다.

학습 방식 개선

이전의 나는 문제를 해결할 때, 어느정도 해결이 되었다면 그냥 넘어가는 학습방식을 가졌었다.
왜그랬는지 생각해보니 공부라는 것에 대해 '조급함'이 너무 커서 그랬다.
남들은 이미 할 줄 아는 것들을 쩔쩔매며 공부하는 내가 부족해보였고 싫었던 것 같다.
이러한 생각 때문에 질문하는 것도 부끄럽고 어려워했다.

다시 생각해보면 남들은 쩔쩔매며 공부해서 습득한 지식일텐데 나는 왜 쩔쩔매는 것이 스스로 부끄럽고 부족해보였나 싶다.

아무튼, 그랬던 나는 유연성 강화 훈련을 거치며 조급한 마음이 덜어져서인지 더는 그렇게 학습하지 않는다.

개발을 하다가 모르는 부분이 나오면 원인을 생각해본 뒤에,
구글에 마주한 상황을 영문으로 검색하고 여러 래퍼런스, 공식문서들을 참조한다.
그리고 글을 아주 천천히 읽어본다.

영문으로 검색하는 이유는 보통 공식문서가 영어이고, 외국 자료가 훨씬 양질이라고 느꼈기 때문이다. (ex. Baeldung)

이정도로 아주 작은 개선만 했는데 정말 큰 변화가 있었다.
찾은 래퍼런스들을 급하지 않게 천천히 읽으니 웬만한 내용은 다 적혀있었다.
급하게 찾을 때는 쓸만한 참고자료가 거의 없다고 느꼈는데 사실은 내 문제였다.

우테코에 오지 않았더라면 이렇게 될 수 없지 않았을까?? 라고 나는 항상 생각한다.

레벨2를 떠나보내며

레벨2를 떠나보내기에는 솔직히 아쉬운 점이 많이 떠오른다.
"스프링 스터디라도 하면서 책 한 권이라도 읽을걸..", "레벨1때 자바 공부 더 할 걸..", "사람들이랑 좀 더 많은 대화를 나눠볼걸.." 등등 많은 후회가 든다.

하지만 이러한 아쉬움보다 얻어간 것이 더 많다. 우테코에서 만난 소중한 인연들, 내면의 유연성, 앞으로 어떻게 학습해나가야하는지 등등

또 우테코의 레벨은 아직 3개나 남았고 이 아쉬움을 떨쳐낼 충분한 시간이 있다.

깨달은 부족한 점 아쉬운 점은 남은 기간동안 채워나가고
배운 점들은 이 회고를 계속 돌아보며 잊지않고 습관화해나가고자 한다.

내일부터 시작되는 레벨3는 같은 아쉬움이 남지 않기를 바라며 글을 마친다.

Spring @Sql 애노테이션의 동작 원리와 트러블슈팅 기록

PgmJUN — Sat, 22 Jun 2024 23:05:57 +0900

우아한테크코스 레벨2에서 스프링부트를 활용한 미션을 수행하면서, 테스트 코드를 어느때보다 열심히 작성하고 있는 것 같다.

하지만 테스트 코드에서 @Sql 을 사용하는 과정에서 문제를 마주하게 되었고,

이를 @Sql 애노테이션의 동작 원리를 살펴보는 좋은 기회로 여겨 문제 상황과 학습 내용을 기록해보고자 한다.

@Sql 애노테이션이란?

마주한 문제에 대해 알아보기 전에

우선 Sql 애노테이션이 무엇인지부터 알아보자.

정확한 설명을 위해 공식문서의 말을 빌려보자면,

‘@Sql 애노테이션은 통합 테스트 환경에서 주어진 데이터베이스에 실행시키기 위한 SQL의 scripts 또는 statements를 구성하기 위한 목적으로 테스트 클래스 또는 테스트 메서드에 붙여주는 애노테이션’ 이라고 한다.

간단히 @Sql 애노테이션의 역할을 살펴보았으니 이제 문제 상황에 접근해보자

마주한 문제 상황

@JdbcTest
@Sql(scripts = "/truncate.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
class ThemeRepositoryTest { 
   
    //...
   
    @Test
    @DisplayName("예약 수 상위 10개 테마를 조회했을 때 내림차순으로 정렬된다. 만약 예약 수가 같다면, id 순으로 오름차순 정렬된다.")
    @Sql(scripts = "/reservationData.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
    void readTop10ThemesDescOrder() {

나는 RepositoryTest 에서 클래스 레벨에 @Sql 애노테이션을 선언하여 truncate.sql 을 실행시켜 DB를 초기화하고

메서드 레벨에 선언한 reservationData.sql 로 초기 테이터를 삽입하고자 하였다.

하지만 예상한 바와는 다르게

reservationData.sql은 수행되지만 truncate.sql 제대로 실행되지 않아 문제가 발생한 것이다.

@JdbcTest
@Sql(scripts = "/truncate.sql", executionPhase = ExecutionPhase.AFTER_TEST_METHOD)
class ThemeRepositoryTest { 
   
    //...
   
    @Test
    @DisplayName("예약 수 상위 10개 테마를 조회했을 때 내림차순으로 정렬된다. 만약 예약 수가 같다면, id 순으로 오름차순 정렬된다.")
    @Sql(scripts = "/reservationData.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
    void readTop10ThemesDescOrder() {

이때 truncate.sql을 ExecutionPhase.AFTER_TEST_METHOD 로 실행시키면 정상 작동했고,

그 이유가 궁금해 기록해보기로 하였다.

원인 분석

스프링 공식문서를 통해 알게된 원인은 다음과 같았다.

@Sql 애노테이션은 클래스 레벨 + 메서드 레벨 모두 선언되어 있다면

'메서드 레벨 설정'이 '클래스 레벨 설정'을 오버라이드하여, 메서드 레벨에 명시된 sql 파일만 수행된다고 한다.

때문에 truncate.sql과 reservationData.sql 실행을 모두 BEFORE_TEST_METHOD로 설정해두면

메서드에 선언된 @Sql 애노테이션이 오버라이드되면서 reservationData.sql 만 실행시킨 것이었다.

그리고 이때 truncate.sql을 AFTER_TEST_METHOD로 설정하면

서로 다른 시점(AFTER_TEST, BEFORE_TEST) 의 설정이기 때문에 오버라이드가 되지 않아서 문제가 해결되었던 것이다.

하지만 DB 초기화는 테스트 실행 전에 수행시켜주는 것이 훨씬 안정성있기 때문에
truncate.sql과 reservationData.sql을 BEFORE_TEST 시점에 한 번에 실행시킬 방법을 찾기로 했다.

Executing SQL Scripts :: Spring Framework

In addition to the aforementioned mechanisms for running SQL scripts programmatically, you can declaratively configure SQL scripts in the Spring TestContext Framework. Specifically, you can declare the @Sql annotation on a test class or test method to conf

docs.spring.io

해결 방안

1. Mulitple scripts 사용

@JdbcTest
@Sql(scripts = "/truncate.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
class ThemeRepositoryTest { 
    
    //...
    
    @Test
    @DisplayName("예약 수 상위 10개 테마를 조회했을 때 내림차순으로 정렬된다. 만약 예약 수가 같다면, id 순으로 오름차순 정렬된다.")
    @Sql(scripts = {"/truncate.sql", "/reservationData.sql"}, executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
    void readTop10ThemesDescOrder() {

같은 시점에 truncate.sql 외에 다른 쿼리를 가지는 메서드에는

메서드의 @Sql 애노테이션 내에 truncate.sql을 함께 추가해주면 오버라이드로 인해 reservationData.sql 만 실행되는 문제가 해결된다.

2. @SqlGroup 애노테이션 사용

@JdbcTest
@Sql(scripts = "/truncate.sql", executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
class ThemeRepositoryTest { 
    
    //...
        
    @Test
    @DisplayName("예약 수 상위 10개 테마를 조회했을 때 내림차순으로 정렬된다. 만약 예약 수가 같다면, id 순으로 오름차순 정렬된다.")
    @SqlGroup({
            @Sql(scripts = {"/truncate.sql"}, executionPhase = ExecutionPhase.BEFORE_TEST_METHOD),
            @Sql(scripts = {"/reservationData.sql"}, executionPhase = ExecutionPhase.BEFORE_TEST_METHOD)
    })
    void readTop10ThemesDescOrder() {

또다른 방법으로는 @SqlGroup 을 사용하는 방법이 있다.

@SqlGroup 을 사용하면 2개 이상의 쿼리를 각각 명시하여 실행시켜줌으로써 문제를 해결할 수 있다.

@Sql 애노테이션에 선언한 scripts 실행 순서

이제 truncate.sql과 reservationData.sql 을 같은 시점인 BEFORE_TEST에 실행시킬 수 있게 되었다.

하지만 여기서 더 중요한 포인트는

truncate.sql을 통해 DB가 truncate된 후에 reservationData.sql를 실행시켜서 데이터를 초기화시켜주어야 하는데,

그 순서를 어떻게 보장할 수 있는가이다.

때문에 @Sql 애노테이션에 선언한 스크립트의 실행 순서를 알아보기로 하였다.

우선위 @Sql 애노테이션의 'scripts' 속성에 선언된 스크립트는

스크립트가 선언된 순서대로 실행될 것이라는 믿음 아래서 작성된 코드이다.

하지만 과연 실제로도 그럴까?

직접 코드를 타고 들어가면서 알아보자.

ResourceDatabasePopulator

@Sql 애노테이션은 org.springframework.jdbc 에 선언이 되어있다.

해당 패키지에 들어가보니 @Sql 애노테이션과 더불어

@Sql 애노테이션의 스크립트 실행 리스너인 SqlScriptsTestExecutionListener 를 마주할 수 있었다.

이 SqlScriptsTestExecutionListener에 존재하는 메서드들을 파고 하위로 들어가다보면

org.springframework.jdbc.datasource.init 에 존재하는 ResourceDatabasePopulator 라는 객체를 확인할 수 있다.

스크립트의 실행은 정확히 이 객체의 execute() 메서드에서 시작된다.

이제 타점을 찾았으니 자세히 살펴보자.

ResourceDatabasePopulator의 execute() 메서드

해당 객체는 execute() 라는 메서드를 통해 자기 자신(ResourceDatabasePopulator)과 dataSource를 넘겨

DatabasePopulatorUtils의 메서드 execute()를 호출한다.

DatabasePopulatorUtils의 populate(), execute() 메서드

DatabasePopulatorUtils 의 execute() 메서드는, try/catch 구문 내에서 매개변수로 전달받은 dataSource를 사용하여 DataSourceUtils 로부터 커넥션을 얻어온다.

그리고 그 connection을 매개변수로 담아

execute() 메서드의 호출자인 ResourceDatabasePopulator의 populate() 메서드를 호출한다.

바로 아래에서 살펴볼 예정이지만 살짝 설명하자면 populate()는 script를 실행시켜 DB에 쿼리를 날리는 메서드이다.

이때 populate() 메서드가 예외 발생없이 정상적으로 수행되는 경우

만약 connection이 autoCommit 상태가 아니고, 트랜잭션을 타고있지 않다면

여기서 connection을 직접 commit한다.

ResourceDatabasePopulator의 populate() 메서드

DatabasePopulatorUtils 의 execute() 에서 호출한 ResourceDatabasePopulator의 populate() 메서드이다.

코드를 살펴보면 String[] scripts의 Iterator를 얻어 순차적으로 쿼리를 실행시키는 것을 확인할 수 있었다.

이 scripts는 우리가 @Sql 애노테이션의 scripts 속성에 정의한 바로 그 스크립트이며,
입력 순서대로 scripts String배열에 담겨있다가 이 시점에 하나씩 순서대로 실행되는 것이다.

ScriptUtils의 executeSqlScript() 메서드

executeSqlScript() 메서드는 내부적으로 Statement를 생성하여, script에 담긴 쿼리를 DB에 날리는 역할한다.

결론

테스트에서 Multiple Scripts 또는 @SqlGroup 애노테이션을 통해 여러 sql을 같은 시점에 실행시킬 수 있다.
실행하고자 입력한 Sql 스크립트는 입력해준 순서대로 실행된다.

Springboot Toss 결제 API 연동

PgmJUN — Sat, 22 Jun 2024 02:15:55 +0900

외부 API 연동하기

우테코에서 방탈출 미션을 수행하면서, 방탈출 예약 결제 처리에 Toss 결제 API 를 연동하게 되었다.
방탈출 미션은 방탈출 예약 웹 서비스를 만드는 미션으로 JS/CSS/HTTP 기반 웹 클라이언트 와 Springboot/Java 기반 백엔드를 함께 개발한다.

하지만 백엔드에서 고려할 부분에 대한 흐름을 기록하고싶기 때문에
이번 내용은 클라이언트 측이 아닌 백엔드 측의 기준으로 설명한다.
또한 Toss API 연결이라는 하나의 작업보다는 외부 API 연결이라는 큰 틀에 집중해보았다는 점을 참고해서 글을 읽으면 도움이 될 것이다.

또한 이번에 다루는 내용은 실제 결제까지의 과정이 아니라 학습을 위한 과정이기 때문에
토스에서 지원하는 '테스트'용 키값 등을 사용했다는 점도 참고바란다.
(실제 결제까지 연결하려면 사업자등록부터 꽤나 복잡한 것으로 알고 있다.)

Toss 공식 문서

사실 내가 어떻게 쓰든간에 중요한건 공식문서니까 맨 위에 첨부하고 글을 시작한다.
여태껏 보았던 문서 중 가장 친절한 문서인 것 같다.
문서보는게 편한 사람이라면 이 글을 통해서는 외부 API 연결 시 고려해야하는 부분들에 대해서만 구경하고 가면 좋을 것 같다 :)

연동하기 | 토스페이먼츠 개발자센터

토스페이먼츠의 간편한 결제 연동 과정을 한눈에 볼 수 있습니다. 각 단계별 설명과 함께 달라지는 UI와 코드를 확인해보세요.

docs.tosspayments.com

Toss 결제 API Flow

우선 Toss 결제는 어떤 플로우로 진행되는 지 알아보자
위 이미지는 결제 플로우이며, 우리는 Promise 방식을 사용하기 때문에 successUrl, failUrl 이 없다는 점에서 흐름이 조금 다르다는 점을 인지하고 보자.

[참고사항] 방탈출 예약 서비스는 웹 서비스이기 때문에 Promise 방식을 사용할 수 있지만, 앱이라면 Promise 방식 사용이 불가능하다.

0. 상품 선택

방탈출 웹사이트에서 원하는 상품을 선택하고 결제버튼을 클릭한다.

1. 결제위젯 렌더 요청

Toss 결제 연동의 첫 단추는 Toss 공식문서에서 제공하는 결제위젯을 클라이언트 코드에 추가하는 것이다.
해당 코드가 존재하는 페이지가 열리면, 클라이언트는 토스에 결제위젯 렌더 요청을 보내어 위와 같은 화면을 띄워준다.

2. 결제 요청 호출

결제 수단을 선택하고 나면 위와 같은 화면으로 넘어온다.
여기서 화면 하단에 보이는 ‘동의하고 결제하기’ 버튼을 클릭하면 ‘Toss 결제요청 API’ 를 호출한다.
‘결제 요청’ 은 토스 서버에 현재 수행하려하는 결제에 대한 정보를 등록하는 과정이다.

현재 서버에서는 orderId, orderName, amount 를 통해 결제 요청을 호출하여 Toss에 해당 결제정보를 저장한다.
결제 요청은 PaymentWidget의 requestPayment() 메서드를 통해 수행할 수 있는데, 각각의 파라미터는 아래와 같은 역할을 갖는다.

orderId: 주문을 구분하는 ID이다. 충분히 무작위한 값을 생성해서 각 주문마다 고유한 값을 넣어야한다. 값은 영문 대소문자, 숫자, 특수문자 -, _, =로 이루어진 6자 이상 64자 이하의 문자열이어야 한다.
orderName: 구매상품명이다. 예를 들면 생수 외 1건 같은 형식입니다. 최대 길이는 100자입니다.
amount: 상품의 가격이다.

이 외에 더 많은 파라미터가 존재하는데 해당 문서에서 확인할 수 있다.

requestPayment() 메서드는 응답을 리다이렉트URL 또는 Promise 형식으로 반환받을 수 있다. 관련 내용은 해당 문서를 참고하자.

어찌되었건 위 과정을 거쳐 ‘결제 요청’ 에 성공하면 클라이언트는 토스 서버로부터 paymentType, paymentKey, orderId, amount이 4가지 값을 응답받는다.
orderId와 amount는 위에서 설명했으니 나머지에 대해서 설명한다.

paymentKey: 결제를 식별하는 키 값으로 토스페이먼츠에서 발급한다. 결제에 대한 처리(결제 승인, 결제 조회, 결제 취소 등)와 운영에 필요한 값이다.
paymentType: 결제 유형으로 NORMAL, BRANDPAY, KEYIN 중 하나이다.

결제 요청 실패 시에는 error code 를 응답받는데, 그에 대한 내용은 해당 문서를 참고하자.

3. 결제정보 전달

결제 요청이 정상적으로 완료되어 클라이언트로부터 paymentType, paymentKey, orderId, amount 를 응답받았다면 클라이언트는 결제승인 요청을 위해 우리 서버의 방탈출 예약 API 를 통해 해당 정보와 예약에 필요한 정보를 전달한다.

4. 결제 승인 API 호출

서버는 결제승인 API 호출을 위해 클라이언트로부터 paymentType, paymentKey, orderId, amount 와 그 외 예약 관련 정보들을 전달받았다.
서버는 클라이언트로 전달받은 값 중 paymentKey, orderId, amount 와 토스에서 발급받을 수 있는 SecretKey 를 통해 토스의 결제승인 API를 호출한다.
이때 orderId가 이전에 클라이언트 측에서 보낸 orderId와 동일한 지 비교하고 호출한다.

SecretKey 발급 방법은 공식문서를 참조하자

만약 승인에 성공했다면 위와 같은 화면이 클라이언트 측 토스 위젯에 출력될 것이다.
하지만 승인을 요청한 사용자나 클라이언트 또는 서버에 모두 문제가 없다면 결제가 완료되고, 문제가 있다면 실패한다.
이때 발생할 수 있는 문제들은 해당 문서를 참고하자.

이번 글에서 다룰 내용

PaymentWidget을 초기화하고 결제요청(PaymentRequest)를 보내서 PaymentKey를 흭득하여 서버로 보내주는 것은 클라이언트의 역할이다.

위에서 말했듯이 이번 글에서는 서버의 역할에 대해서만 다룰 예정이기 때문에 사전 설명은 여기까지하고 아래 글에서는 서버 관점에서의 결제승인 API 호출, 결제취소 API 호출 만을 다루겠다.
클라이언트를 포함한 전체 코드가 보고싶다면 깃허브 주소를 올려둘테니 참고하길 바란다.

GitHub - PgmJun/spring-roomescape-payment

Contribute to PgmJun/spring-roomescape-payment development by creating an account on GitHub.

github.com

코드에 대해 질문이나 의견이 있으시다면 댓글에 남겨주세요!

Reference

코어 API | 토스페이먼츠 개발자센터

토스페이먼츠 API 엔드포인트(Endpoint)와 객체 정보, 파라미터, 요청 및 응답 예제를 살펴보세요.

docs.tosspayments.com

결제위젯 JavaScript SDK | 토스페이먼츠 개발자센터

결제위젯 JavaScript SDK를 추가하고 메서드를 사용하는 방법을 알아봅니다.

docs.tosspayments.com

HttpClient 선택

외부 API를 사용하기 전에는 어떤 HttpClient를 사용할 지 정하고 시작해야한다.
HttpClient는 HTTP로 요청을 날릴 수 있도록 도와주는 역할을 하는데, 바로 이 HttpClient를 통해 Toss 결제 API에 요청을 보낼 계획이다.

Client-Server에 대해서

우리 서비스의 Client에게는 스프링부트 애플리케이션이 Server지만, Toss 입장에서는 우리 스프링부트 애플리케이션이 Client가 된다.
이렇듯 요청을 보내는 쪽이 Client, 요청을 받아 무언가를 제공하는 곳이 Server이며, HttpClient 사용 학습은 꼭 스프링부트 애플리케이션이라고 해서 Server의 역할만을 가지지는 않는다는 살짝의 학습 키 포인트가 있다고 생각한다.

아무튼 스프링 환경에서 외부 API 연결은 HttpClient로 수행할 수 있는데, 스프링에서는 HttpClient로 WebClient, RestClient, RestTemplate가 존재한다.

각각의 클라이언트들은 장단점이 존재하는데, 이 중에 나는 RestClient를 선택하였다.
그 이유는 아래와 같다.

WebClient

WebClient는 WebFlux 의존성에 있는 비동기/논블로킹 을 지원하는 HttpClient이다.
조금 사용해보긴 했지만 능숙하게 다룰만큼 사용해보지 않았던 기술을 시간 제한이 있고, 그 시간이 조금은 부족하다고 느껴지는 현재 시점에 공부해보면서 적용하는 것은 좋지 않은 판단이라고 생각했다.
그리고 WebClient를 도입한다고 해도 해당 클라이언트의 장점인 비동기/논블로킹 방식을 통해 얻을 수 있는 이점이 크게 없다고 생각했다.

RestTemplate Vs RestClient

우테코에서 제공해준 자료중 RestTemplate이 Deprecated된다는 내용의 Baeldung 글이 있었는데, 반면 RestClient는 스프링 6.2부터 나온 메서드 체이닝 형식의 깔끔한 HttpClient 이라고 소개되고 있었다.
이때 굳이 Deprecated라는 단점을 감안하고 RestTemplate을 선택할 이유가 없다고 느꼈고 메서드체이닝 방식의 편리하고 깔끔한 코드를 장점삼아 RestClient를 선택하였다.

그런데 그 뒤에 조금 더 알아보니 RestTemplate이 사실은 Deprecated 되지 않는 것 같았다.
RestTemplate에 대한 공식 문서를 아무리 찾아보아도 Deprecated에 대한 내용은 존재하지 않았다.

토비님이 말씀하시는 RestTemplate Deprecated

이 시점에 Baeldung에서 이상한 정보를 줬나? 싶어서 더 찾아보게 되었는데, 위 영상에서 알게 된 점은 스프링 공식 문서에 표시가 되었었지만 이후에 Deprecated를 철회했다고 한다.
(아마 이미 RestTemplate을 사용하고 있는 코드가 많아서 Deprecated 된다면 유지보수에 어려움을 겪을까봐 철회한 것 같다.)

이번 HttpClient 선택 과정을 통해 직접 본 게 아니면 완전히 믿지 말자는 신념이 조금 자라난 것 같다. Baeldung이 아무리 인지도가 높고 의미있는 글이 많은 곳이라고는 하지만, 거기서 보았다고 하더라도 직접 공식문서를 흝어보고 찾아보는 습관을 가지자.

아무튼 RestTemplate이 Deprecated 되지 않는다고 하더라도 나는 RestClient를 선택하게 되었다.
공식문서에서 RestTemplate 보다 현대적인 API를 제공한다고 권장하는데 한 번 써봐야하지 않겠는가.
그리고 개인적으로 나는 가독성, 불필요한 변수 생성 로직X 등의 이유로 메서드 체이닝 방식을 좋아한다.

RestClient 공식문서

REST Clients :: Spring Framework

WebClient is a non-blocking, reactive client to perform HTTP requests. It was introduced in 5.0 and offers an alternative to the RestTemplate, with support for synchronous, asynchronous, and streaming scenarios. WebClient supports the following: Non-blocki

docs.spring.io

Timeout 처리

외부 API를 연결하기 위해선 Timeout에 대한 처리에 대한 고민도 필요하다.

Timeout 이란?

타임아웃이란 서버로 요청을 보냈을 때, 요청 시간이 오래 걸리거나 요청은 도달했으나 응답까지의 시간이 너무 오래 지연되는 경우, 일정 시간이 지나면 요청을 취소하는 것을 의미한다.

타임아웃은 시스템 자원을 효율적으로 사용하기 위해 중요한 요소 중 하나이다.
연결되지 않는 API 또는 응답이 너무 늦는 API에 쓰레드가 묶여있으면 이는 자원 낭비이다.
따라서 타임아웃을 적절히 설정하여, 특정 시간이 지나도 응답이 없는 경우 해당 요청을 취소하고 시스템 자원을 해제하는 타임아웃이 필요한 것이다.

타임아웃은 클라이언트 측과 서버 측에서 각각 설정될 수 있다. 클라이언트 측에서는 요청을 보내고 일정 시간 내에 응답이 없으면 요청을 취소하고, 서버 측에서는 요청을 받아들이고 처리하는 과정에서 일정 시간 내에 작업이 완료되지 않으면 해당 요청을 중단할 수 있다.

이러한 타임아웃은 크게 2종류로 구분할 수 있는데, 바로 살펴보자.

Connection Timeout

요청한 서버에 연결하는 시간에 대한 타임아웃이다.
HTTP 연결은 TCP 3way handshake를 통해 수행되는데, 해당 연결 과정 중에 설정해둔 ConnectionTimeout 설정 시간이 지나게 되면 해당 타임아웃이 발생한다.

Read Timeout

요청을 보낸 서버에서 데이터를 읽어오는 시간에 대한 타임아웃이다.
Connection이 성공하고, 그 이후 서버에서 데이터를 읽어오는 과정에서 설정해둔 ReadTimeout 설정 시간이 지나게 되면 해당 타임아웃이 발생한다.

ConnectTimeout은 몇 초가 적당할까?

HTTP는 3way-handshaking 과정을 통해 연결하고, 결국 ConnectTimeout의 Time은 TCP 3way-handshacking에 걸리는 시간을 의미한다.

나는 이러한 핸드셰이킹 과정의 타임아웃 발생은 몇 초 뒤에 발생해야 적당하며, 어떤 기준을 둘 수 있을까에 대해 아래와 같이 정의해보았다.

핸드셰이킹(handshaking) 과정에서 패킷은 광섬유를 통해 전달된다.
광섬유에서는 데이터(패킷)가 빛의 속도로 이동하며, 빛은 1초에 약 300,000km, 1밀리초(ms)에 약 300km를 이동한다.
제주도에서 강원도 철원까지의 최대 거리는 약 545km이다. 한국 내에서만 서비스를 제공한다는 기준 하에 크게 잡아 요청의 end-to-end 최대 거리를 600km로 설정한다.
이 거리를 기준으로 대한민국 끝에서 끝으로 1번 패킷이 전달되는 데 걸리는 시간은 약 2ms이고, 3번 오가는 데 걸리는 시간은 약 6ms 이다.
위에서 설명한 네트워크 연결에서 발생하는 다양한 상황을 고려하여, connectTimeout 시간을 넉넉하게 1초~3초 로 설정하면 된다고 생각하였다.

개인적인 생각일 뿐이기 때문에 이견이 있으시다면 남겨주시면 감사하겠습니다!

ReadTimeout은 몇 초가 적당할까?

타임아웃(Timeout) | 토스페이먼츠 개발자센터

네트워크 타임아웃(Timeout)은 서버로 요청을 보냈지만 일정 시간 동안 답변을 받지 못하면 발생해요.

docs.tosspayments.com

토스에서 제공하는 문서를 읽어보면 토스 API의 ReadTimeout은 30~60초로 설정하는 것이 적절하다고 적혀있다.
ReadTimeout은 토스 서버 내부에 의해 응답시간이 결정되는 것이기 때문에 내가 생각해서 처리하는 것보다 토스에서 계산한 값을 사용하는 것이 가장 안정적일 것이라고 생각한다.
때문에 권장하는 값 중 가장 작은 값인 30초로 설정하였다.

API 문서를 흝어보면 위와 같이 기능마다 최대로 소요되는 초가 적혀있는데, 이걸 기준으로 설정하자.

리뷰어였던 호돌에게도 ReadTimeout과 관련해서 질문했는데, 다음과 같은 답변을 얻을 수 있었다.
요약하자면 결제와 같이 시간이 오래걸려도 사용자가 용인할 수 있는 부분이라면 타임아웃을 길게 잡아도 괜찮을 것 같다는 의견이었고 나도 충분히 동의했다.

타임아웃 처리 로직이 제대로 터지는 지도 테스트를 해야할까?

그렇지 않다고 생각한다.
타임아웃이 터지는 지를 테스트하는 것은 라이브러리의 기능을 테스트하는 것이므로 내가 하고자하는 테스트의 본질과는 조금 거리가 먼 것같다고 생각한다.

나는 타임아웃이 제대로 발생하는 지를 테스트하기 보다, 타임아웃 발생 시 서버에서 설정한 커스텀 예외로 변환이 잘 되는 지 등의 우리 애플리케이션 로직을 테스트하는 것이 더 적절한 테스트라고 생각했다.

물론 제대로 잘 터지는 지 궁금해서 테스트해보는 것은 절대 나쁘지 않다. 하지만 ‘타임아웃이 잘 터지는 지’를 테스트하는 것은 사실 상 라이브러리를 테스트하는 것이기 때문에 “과연 적절한 테스트일까?” 라는 생각이 든다. ”타임아웃을 발생시키는 로직은 라이브러리 로직이며, 라이브러리 로직은 우리 애플리케이션의 로직이 아니기에 테스트 범위가 아니라고 생각한다.”

Reference

[TIL] TCP 3-way Handshake와 네트워크 레이턴시(latency)

TCP는 신속보다는 정확한 데이터 교환에 초점이 맞춰진 프로토콜로, 3-way Handshake를 통해 클라이언트/서버 간 통신이 진행된다. 따라서 최초 1회 왕복 패킷 교환이 반드시 수반되어야 하며, 이는

chaewonkong.github.io

결제승인 API 연동해보기

코어 API | 토스페이먼츠 개발자센터

토스페이먼츠 API 엔드포인트(Endpoint)와 객체 정보, 파라미터, 요청 및 응답 예제를 살펴보세요.

docs.tosspayments.com

사전에 필요한 퍼즐조각을 모두 모았으니, 이제 직접 코드로 API 연결 퍼즐을 맞춰보자

application.yml 설정

payment:
  secret-key: test_gsk_docs_OaPz8L5KdmQXkzRz3y47BMw6
  base-url: https://api.tosspayments.com/v1/payments
  confirm-endpoint: /confirm

먼저 application.yml 에 API 연동에 필요한 프로퍼티 값들을 담아준다.
결제 승인 API 호출에 필요한 정보는 결제승인 API URL, 그리고 SecretKey 이다.
API URL은 공식문서에서 확인할 수 있으며, SecretKey 또한 토스 개발자 센터에서 얻을 수 있다.

다만 실제로 결제를 연동하기 위해서는 여러 복잡한 사전 작업을 수행해야하며, 지금 만드는 것은 연습용이니 테스트용 SecretKey를 사용한다. 테스트용 SecretKey 또한 개발자 센터의 문서에서 제공한다.

PaymentProperties.java 설정

@Component
@ConfigurationProperties(prefix = "payment")
public class PaymentProperties {
    private String secretKey;
    private String baseUrl;
    private String confirmEndpoint;


    public String getSecretKey() {
        return secretKey;
    }

    public String getBaseUrl() {
        return baseUrl;
    }

    public String getConfirmUrl() {
        return baseUrl + confirmEndpoint;
    }

    public void setSecretKey(final String secretKey) {
        this.secretKey = secretKey;
    }

    public void setBaseUrl(String baseUrl) {
        this.baseUrl = baseUrl;
    }

    public void setConfirmEndpoint(String confirmEndpoint) {
        this.confirmEndpoint = confirmEndpoint;
    }
}

다음으로 만들어줄 것은 PaymentProperties 클래스이다.

@Value 애노테이션을 통해 yml 파일의 프로퍼티 값을 가져올 수 있지만, 필요한 값들을 하나하나 가져와야하기 때문에 코드가 길어지고 보기도 안좋다.

스프링의 @ConfigurationProperties(prefix = "") 를 활용하면 이런 문제를 없애준다.

prefix에 yml파일의 프로퍼티값 prefix를 적어주면 prefix 하위에 존재하는 값들을 객체에 담아준다.
해당 객체는 @Component 를 통해 빈으로 등록하여 싱글톤으로 어디서든 재활용할 수 있다.
또한 baseUrl과 confirmEnpoint 를 외부에서 별도로 합칠 필요없이 최종 URL을 만들어주는 메서드를 두어 편리하게 값을 다룰 수도 있다.

PaymentClient.java - RestClient 설정

@Component
public class PaymentClient {
    private static final String BASIC_DELIMITER = ":";
    private static final String AUTH_HEADER_PREFIX = "Basic ";
    private static final int CONNECT_TIMEOUT_SECONDS = 1;
    private static final int READ_TIMEOUT_SECONDS = 30;

    private final ObjectMapper objectMapper;
    private final PaymentProperties paymentProperties;
    private RestClient restClient;

    public PaymentClient(PaymentProperties paymentProperties,
                         ObjectMapper objectMapper) {
        this.paymentProperties = paymentProperties;
        this.objectMapper = objectMapper;
        this.restClient = RestClient.builder()
                .requestFactory(createPaymentRequestFactory())
                .requestInterceptor(new PaymentExceptionInterceptor())
                .defaultHeader(HttpHeaders.AUTHORIZATION, createPaymentAuthHeader(paymentProperties))
                .build();
    }

    private ClientHttpRequestFactory createPaymentRequestFactory() {
        ClientHttpRequestFactorySettings settings = ClientHttpRequestFactorySettings.DEFAULTS
                .withConnectTimeout(Duration.ofSeconds(CONNECT_TIMEOUT_SECONDS))
                .withReadTimeout(Duration.ofSeconds(READ_TIMEOUT_SECONDS));

        return ClientHttpRequestFactories.get(SimpleClientHttpRequestFactory.class, settings);
    }

    private String createPaymentAuthHeader(PaymentProperties paymentProperties) {
        byte[] encodedBytes = Base64.getEncoder().encode((paymentProperties.getSecretKey() + BASIC_DELIMITER).getBytes(StandardCharsets.UTF_8));
        return AUTH_HEADER_PREFIX + new String(encodedBytes);
    }

PaymentClient는 위에서 정한 RestClient를 통해 결제 관련 HTTP 요청을 수행하는 객체이다.
코드를 하나하나 살펴보자

requestFactory() 로 요청 관련 설정값 적용

.requestFactory(createPaymentRequestFactory())

createPaymentRequestFactory() 메서드에서 ConnectTimeout, ReadTimeout 시간을 설정 후, SimpleClientHttpRequestFactory 객체로 만들어 Return 한다.
ClientRequestFactory는 다양한 종류가 존재하니 학습해보고 필요한 팩토리를 골라 사용하면 된다.

예외 핸들링 Interceptor 적용

.requestInterceptor(new PaymentExceptionInterceptor())

RestClient는 요청에 대해 Interceptor를 따로 적용시킬 수 있다.
요청 시, 발생하는 예외에 대한 처리역할을 맡길 수 있는데 직접 핸들링하는 것보다 인터셉터에게 시키는 것이 간편하고 코드도 보기 좋다.

ClientHttpRequestInterceptor 코드

import org.springframework.http.HttpRequest;
import org.springframework.http.client.ClientHttpRequestExecution;
import org.springframework.http.client.ClientHttpRequestInterceptor;
import org.springframework.http.client.ClientHttpResponse;
import roomescape.exception.payment.PaymentConfirmException;
import roomescape.exception.payment.PaymentTimeoutException;

import java.io.IOException;

public class PaymentExceptionInterceptor implements ClientHttpRequestInterceptor {

    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) {
        try {
            return execution.execute(request, body);
        } catch (IOException e) {
            throw new PaymentTimeoutException(e);
        } catch (Exception e) {
            throw new PaymentConfirmException(e);
        }
    }
}

ClientHttpRequestInterceptor를 implements하면 되는데, execution을 execute하는 과정에서 예외를 잡을 수 있도록 try/catch 문을 사용했고, 내부에서 잡히는 예외를 직접 만든 커스텀 예외로 변환시켰다.
굳이 이렇게까지 하나 싶을 수도 있지만 아래 남겨놓은 적용 전, 적용 후 코드를 통해 장점을 비교해보면 그 효용을 자세히 이해할 수 있다.

Interceptor 적용 전

public PaymentConfirmOutput confirmPayment(PaymentConfirmInput confirmRequest) {
        try {
            return restClient.method(HttpMethod.POST)
                    .uri("/confirm")
                    .contentType(MediaType.APPLICATION_JSON)
                    .body(confirmRequest)
                    .retrieve()
                    .onStatus(HttpStatusCode::is4xxClientError, (request, response) -> {
                        throw new PaymentConfirmException(getPaymentConfirmErrorCode(response));
                    })
                    .onStatus(HttpStatusCode::is5xxServerError, (request, response) -> {
                        throw new PaymentConfirmException(getPaymentConfirmErrorCode(response));
                    })
                    .body(PaymentConfirmOutput.class);

        } catch (ResourceAccessException e) {
            if (e.getCause() instanceof SocketTimeoutException) {
                throw new PaymentTimeoutException(e);
            }
            throw new PaymentIOException(e);
        } catch (Exception e) {
            throw new PaymentConfirmException(e);
        }
    }

Interceptor 적용 후

public PaymentConfirmOutput confirmPayment(PaymentConfirmInput confirmRequest) {
        return restClient.method(HttpMethod.POST)
                .uri("/confirm")
                .contentType(MediaType.APPLICATION_JSON)
                .body(confirmRequest)
                .retrieve()
                .onStatus(HttpStatusCode::isError, (request, response) -> {
                    throw new PaymentConfirmException(getPaymentConfirmErrorCode(response));
                })
                .body(PaymentConfirmOutput.class);
    }

DefaultHeader 설정

.defaultHeader(HttpHeaders.AUTHORIZATION, createPaymentAuthHeader(paymentProperties))

토스 결제 요청은 secretKey 뒤에 콜론(:)을 붙이고 Base64로 인코딩한 값 앞에 “Basic ” prefix를 붙여 Authorization 헤더에 담아 요청을 보내야한다.

때문에 기본 헤더에 이를 추가해주었다.
헤더 Value 생성은 PaymentClient.java의 createPaymentAuthHeader() 메서드를 참고하자.

PaymentClient.java - 결제승인(Confirm) API 호출 로직

@Component
public class PaymentClient {
		//.. 생략
		
		// 결제 요청 API 호출
    public PaymentConfirmOutput confirmPayment(PaymentConfirmInput confirmRequest) {
        return restClient.method(HttpMethod.POST)
                .uri(paymentProperties.getConfirmUrl())
                .contentType(MediaType.APPLICATION_JSON)
                .body(confirmRequest)
                .retrieve()
                .onStatus(HttpStatusCode::isError, (request, response) -> {
                    throw new PaymentConfirmException(getPaymentConfirmErrorCode(response));
                })
                .body(PaymentConfirmOutput.clbass);
    }
    
    /**
     * @see  결제 승인 API 에러 코드 문서
     */
    private PaymentConfirmErrorCode getPaymentConfirmErrorCode(final ClientHttpResponse response) throws IOException {
        PaymentFailOutput confirmFailResponse = objectMapper.readValue(
                response.getBody(), PaymentFailOutput.class);
        return PaymentConfirmErrorCode.findByName(confirmFailResponse.code());
    }

위에서 세팅을 마친 RestClient에 결제승인 API에서 요구하는 값들을 담아 호출하는 메서드이다.

body

body에 담는 값(paymentConfirmInput)은 orderId, amount, paymentKey 이다.

각 값들의 역할은 위에서 설명했으니 넘어간다.

onStatus

RestClient는 onStatus 메서드에서 HttpStatusCode의 isError() 메서드를 통해 4xx, 5xx 응답을 한 번에 잡을 수 있다.
onStatus 메서드는 Request, Response 값을 모두 제공하기 때문에 요청 실패 응답 시, 예외를 발생시키는 것 또한 간편하게 처리할 수 있다.

에러 발생 시, 토스는 에러 코드, 메시지가 담긴 에러 객체를 resposne하는데, 해당 에러 객체 매핑역할은 getPaymentConfirmErrorCode 에서 수행하며 PaymentConfirmErrorCode 객체에서 에러코드를 관리한다.

PaymentConfirmErrorCode 객체는 단순히 에러 응답을 우리 서버만의 객체로 변경해주는 역할 뿐만 아니라, 에러 메시지 중, 클라이언트에게 공개하기 어려운 정보(예를 들어 보안과 관련된 정보)가 담긴 메시지를 공개할 수 있는 정보만 담은 메시지로 변환하여 클라이언트에게 제공하는 역할도 수행한다.

PaymentConfirmErrorCode.java

public enum PaymentConfirmErrorCode {
    ALREADY_PROCESSED_PAYMENT(HttpStatus.BAD_REQUEST, "이미 처리된 결제 입니다."),
    PROVIDER_ERROR(HttpStatus.BAD_REQUEST, "일시적인 오류가 발생했습니다. 잠시 후 다시 시도해주세요."),
    INVALID_REQUEST(HttpStatus.BAD_REQUEST, "잘못된 요청입니다."),
    INVALID_API_KEY(HttpStatus.BAD_REQUEST, "잘못된 시크릿키 연동 정보 입니다."),
    INVALID_EXCEED_MAX_DAILY_PAYMENT_COUNT(HttpStatus.BAD_REQUEST, "하루 결제 가능 횟수를 초과했습니다."),
    EXCEED_MAX_PAYMENT_AMOUNT(HttpStatus.BAD_REQUEST, "하루 결제 가능 금액을 초과했습니다."),
    NOT_FOUND_TERMINAL_ID(HttpStatus.BAD_REQUEST, "단말기번호(Terminal Id)가 없습니다. 관리자에게 문의해주세요."),
    UNAPPROVED_ORDER_ID(HttpStatus.BAD_REQUEST, "아직 승인되지 않은 주문번호입니다."),
    UNAUTHORIZED_KEY(HttpStatus.BAD_REQUEST, "인증되지 않은 시크릿 키 혹은 클라이언트 키 입니다."),
    INVALID_PASSWORD(HttpStatus.BAD_REQUEST, "결제 비밀번호가 일치하지 않습니다."),
    NOT_FOUND_PAYMENT(HttpStatus.BAD_REQUEST, "존재하지 않는 결제 정보 입니다."),
    NOT_FOUND_PAYMENT_SESSION(HttpStatus.BAD_REQUEST, "결제 시간이 만료되어 결제 진행 데이터가 존재하지 않습니다."),

    INVALID_AUTHORIZE_AUTH(HttpStatus.BAD_GATEWAY, "유효하지 않은 인증 방식입니다."),
    NOT_AVAILABLE_PAYMENT(HttpStatus.BAD_GATEWAY, "결제가 불가능한 시간대입니다"),
    INCORRECT_BASIC_AUTH_FORMAT(HttpStatus.BAD_GATEWAY, "서버 측 오류로 결제에 실패했습니다. 관리자에게 문의해주세요."),
    FAILED_PAYMENT_INTERNAL_SYSTEM_PROCESSING(HttpStatus.BAD_GATEWAY, "결제가 완료되지 않았어요. 다시 시도해주세요."),
    FAILED_INTERNAL_SYSTEM_PROCESSING(HttpStatus.BAD_GATEWAY, "내부 시스템 처리 작업이 실패했습니다. 잠시 후 다시 시도해주세요."),
    UNKNOWN_PAYMENT_ERROR(HttpStatus.BAD_GATEWAY, "결제에 실패했어요. 같은 문제가 반복된다면 은행이나 카드사로 문의해주세요."),

    PAYMENT_CONFIRM_ERROR_MISMATCH_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, "결제 과정에서 서버 에러가 발생했습니다. 관리자에게 문의해주세요."),
    ;

    private final HttpStatus httpStatus;
    private final String message;

    public static PaymentConfirmErrorCode findByName(String name) {
        return Arrays.stream(values())
                .filter(v -> v.name().equals(name))
                .findAny()
                .orElse(PAYMENT_CONFIRM_ERROR_MISMATCH_ERROR);
    }

    PaymentConfirmErrorCode(final HttpStatus httpStatus, final String message) {
        this.httpStatus = httpStatus;
        this.message = message;
    }

    public HttpStatus getHttpStatus() {
        return httpStatus;
    }

    public String getMessage() {
        return message;
    }
}

PAYMENT_CONFIRM_ERROR_MISMATCH_ERROR 는 토스에서 전달하는 에러는 아니고,
해당 객체의 에러코드와 토스 객체의 에러코드명이 일치하지 않을 때 발생시키기 위해 따로 만든 에러코드이다.

retrieve 이후의 body

retrieve 는 요청을 전송하는 메서드이기 때문에, retrieve 이후의 body는 응답값을 담을 body이다.
응답에서 받을 값(PaymentConfirmOutput) 은 다음 값들이다. paymentKey, orderId, totalAmount(총 결제금액), orderName, requestedAt(요청시간), approvedAt(승인시간), status(결제상태)
응답값에 대한 자세한 설명은 위에 첨부한 공식문서를 참고하자.

결과

로깅(Logging)

이제 거의 다 왔으니 이제 로깅에 대해서 고려해보면 좋을 것 같다.
주변 대기업에 다니는 지인들에게 물어보니, 보통 로깅에 있어서 개인정보 관련 고려사항이 많은걸로 알고 있는데 회사마다 규정도 다르고 관리방법도 달라서 이것까진 고려하지 않고 로깅 자체에 대해서만 생각해보겠다.

우선 나누고 싶은 주제는 “외부 API 호출 시, 로깅은 왜 해야할까?” 이다.
주변 크루원들의 코드를 보면 LoggingInterceptor 등의 로깅 시스템을 구축해서 외부 API에 대한 request, response 정보를 로깅하고 있었다.

사실 처음에는 이걸 로깅할 필요가 있을까? 싶었는데, 조금 생각해보니 그 이유는 확실히 있었다.
만약 우리 방탈출 서비스에서 누군가 결제를 했는데 돈만 빠져나가고 예약이 안됐다고 전화가 오면, 개발자는 무엇을 해야할까?
로그를 통해 해당 고객이 실제로 결제 요청을 보내 결제에 성공까지 했는지에 대해 확인해야한다.

그러나 로그가 없다면 어떻게 될까?

우리는 아무런 정보도 얻을 수 없어 문제 해결 과정이 복잡해진다. 아마 소비자에게 이런저런 증빙자료를 요구해야할 것이고 소비자는 돈을 돌려받는 것에 어려움을, 우리는 이 문제를 해결하는 데에 어려움을 느낄 것이다.

실제로 개인정보 보호 문제로 필수적인 몇몇 데이터만 로깅하기 때문에, 위와 같은 CS가 들어왔을 때 로그가 없어 추적이 힘들 때도 있다는 IT 대기업에 근무하는 지인의 이야기도 들어볼 수 있었다.
이와 같이 로깅은 critical한 외부 API 호출에 있어서 필수적이라고 생각이 든다.

물론 지금 한 이야기들은 방금 말했듯이 결제 등과 같은 critical한 API에 한해서이다. 날씨 정보 조회 API 와 같은 내용은 실패하던 성공하던 로깅을 남길 필요가 전혀 없는 non-critical의 범주에 있다. 이런 부분들을 잘 고려하면서 로깅 처리도 잘 해두면 분명 효용을 얻을 수 있을 것이다.

이러한 로깅은 아까 예외처리 방식과 동일하게, 로깅 또한 Interceptor를 활용할 수 있다.

PaymentLoggingInterceptor

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpRequest;
import org.springframework.http.client.ClientHttpRequestExecution;
import org.springframework.http.client.ClientHttpRequestInterceptor;
import org.springframework.http.client.ClientHttpResponse;

import java.io.IOException;

public class PaymentLoggingInterceptor implements ClientHttpRequestInterceptor {

    private static final Logger logger = LoggerFactory.getLogger(PaymentLoggingInterceptor.class);

    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {
        String host = request.getURI().getHost();
        String path = request.getURI().getPath();
        String httpMethod = request.getMethod().toString();

        logger.info("[Payment Request] {}\t: {} {} \n \t{}", path, httpMethod, host, new String(body));
        return execution.execute(request, body);
    }
}

요청을 보내는 host, path, httpMethod 그리고 Http Body를 기록한다.

PaymentClient - 로깅 Interceptor 등록

@Component
public class PaymentClient {
		//.. 생략
		
		public PaymentClient(PaymentProperties paymentProperties,
                         ObjectMapper objectMapper) {
        this.paymentProperties = paymentProperties;
        this.objectMapper = objectMapper;
        this.restClient = RestClient.builder()
                .requestFactory(createPaymentRequestFactory())
                .requestInterceptor(new PaymentExceptionInterceptor())
                .requestInterceptor(new PaymentLoggingInterceptor()) // 로깅 인터셉터 등록
                .defaultHeader(HttpHeaders.AUTHORIZATION, createPaymentAuthHeader(paymentProperties))
                .build();
    }

이렇게 만든 Interceptor를 RestClient builder에 requestInterceptor 메서드로 등록한다.

결제취소 API

결제 취소하기 | 토스페이먼츠 개발자센터

토스페이먼츠 결제 취소 API를 호출하세요. 결제 금액 전액 또는 일부를 고객에게 환불하는 방법, 가상계좌 결제 취소하는 방법, 결제위젯에서 가상계좌 정보 확인하는 방법을 소개합니다.

docs.tosspayments.com

예약을 취소하면 결제 또한 취소되어야 한다.
때문에 우리는 결제승인 API 뿐만 아니라 취소 API도 연결해야한다.

한 번 구현해보자.

application.yml 에 cancel 관련 값 추가

payment:
  secret-key: test_gsk_docs_OaPz8L5KdmQXkzRz3y47BMw6
  base-url: https://api.tosspayments.com/v1/payments
  confirm-endpoint: /confirm
  cancel-endpoint: /%s/cancel #cancel 엔드포인트 추가

위에 세팅해둔 코드가 있으니 cancelEndpoint만 추가해준다.
endpoint에 %s 가 들어가있는 이유는 저 부분에 PaymentKey 가 들어가기 때문에
String.format() 으로 값을 삽입해줄 예정이기 때문이다.

PaymentProperties.java 에 cancel 프로퍼티값 추가

@Component
@ConfigurationProperties(prefix = "payment")
public class PaymentProperties {
    private String secretKey;
    private String baseUrl;
    private String confirmEndpoint;
    private String cancelEndpoint; // cancelEndpoint 추가


    public String getSecretKey() {
        return secretKey;
    }

    public String getBaseUrl() {
        return baseUrl;
    }

    public String getConfirmUrl() {
        return baseUrl + confirmEndpoint;
    }

    public String getCancelUrl(String paymentKey) { // cancelUrl 흭득 메서드 추가
        return String.format(baseUrl + cancelEndpoint, paymentKey);
    }

    public void setSecretKey(final String secretKey) {
        this.secretKey = secretKey;
    }

    public void setBaseUrl(String baseUrl) {
        this.baseUrl = baseUrl;
    }

    public void setConfirmEndpoint(String confirmEndpoint) { // cancelEnpoint Setter 추가
        this.confirmEndpoint = confirmEndpoint;
    }

    public void setCancelEndpoint(String cancelEndpoint) { // cancelEnpoint Getter 추가
        this.cancelEndpoint = cancelEndpoint;
    }
}

Properties 객체에도 cancel과 관련된 필드, 메서드를 추가한다.

PaymentClient.java에 cancel 메서드 추가

@Component
public class PaymentClient {
		//.. 생략
		
		// 결제 취소 API 호출
    public PaymentCancelOutput cancelPayment(Payment payment) {
        PaymentCancelInput cancelRequest = new PaymentCancelInput("단순 변심");

        return restClient.method(HttpMethod.POST)
                .uri(paymentProperties.getCancelUrl(payment.getPaymentKey()))
                .contentType(MediaType.APPLICATION_JSON)
                .body(cancelRequest)
                .retrieve()
                .onStatus(HttpStatusCode::isError, (request, response) -> {
                    throw new PaymentCancelException(getPaymentCancelErrorCode(response));
                })
                .body(PaymentCancelOutput.class);
    }

    /**
     * @see  결제 취소 API 에러 코드 문서
     */
    private PaymentCancelErrorCode getPaymentCancelErrorCode(final ClientHttpResponse response) throws IOException {
        PaymentFailOutput cancelFailResponse = objectMapper.readValue(
                response.getBody(), PaymentFailOutput.class);
        return PaymentCancelErrorCode.findByName(cancelFailResponse.code());
    }

RestClient API 요청에 대해서는 위에서 많이 살펴보았기 때문에 이곳에서는 Body만 살펴보자.

나머지 다른 부분(PaymentCancelException, getPaymentCancelErrorCode, PaymentCancelErrorCode)가 존재하지만, 에러만 다르지 내부 구현은 똑같다.
관련 에러는 역시 위에 첨부한 공식 문서를 참고하면 쉽게 확인할 수 있다.

Body

PaymentCancelInput cancelRequest = new PaymentCancelInput("단순 변심");

결제 취소 API의 필수 요청 값은 paymentKey와 cancelReason이다. 이 외의 값은 지금 필요하지 않기 때문에 추가하지 않았다.
paymentKey는 결제취소 API URL에 포함되었으니, body에는 cancelReason만 담아주면 된다.

취소 사유는 사용자에게 받을 수도 있지만, 클라이언트를 그 부분까지는 구현해두지 않아서 단순 변심 으로 통일했다.

Retrieve 이후의 Body

결제 취소 Response body 중 나는 다음 값만 받았다.
paymentKey, orderId, orderName, status, requestedAt, approvedAt
이 값을 통해 DB에 취소 작업 처리 시간을 기록한다.

적용 결과

외부 API 테스트

외부 API가 정상 작동하는지 검증하는 테스트도 작성해야할까?

나는 이번에 학습을 진행하면서 외부 API를 꼭 테스트 해야할 지에 대해 고민해보았다.
결론적으로 나는 외부 API를 테스트하지는 않고, 외부 서버에서 특정 응답이 왔을 때 서버가 어떻게 작동할 지에 대한 테스트만 Mocking을 통해 진행하기로 하였다.

그 이유는 다음과 같다.

Toss API는 외부 API이기 때문에, 우리가 원하는 대로 컨트롤할 수 없다.
성공하던 테스트가 항상 성공하고 실패하는 테스트는 항상 실패해야한다는 테스트의 일관성이 외부의 상황 또는 네트워크 상태에 따라 어긋날 가능성이 있다.

때문에 이렇게 외부에 의존하는 부분은 Mock 또는 테스트 더블로 처리해야한다는 생각이 들었다.
이번 미션에 배포가 있어서 함께 고려해보자면 우리 코드에 문제는 없지만 Toss API가 잠깐 먹통이 되었을 때, build가 되지 않아 배포가 되지 않는다면 이건 문제가 아닐까 싶었다.

Toss의 결제 API가 먹통이되는 것은 새로운 버전을 배포하나 현재 버전에서나 똑같이 발생하고 있을텐데
이 문제 때문에 저희 애플리케이션의 새로운 버전이 배포되는 것이 막히는 건 문제가 아닐까 싶었다.

그리고 외부 서버 문제가 아니라 정말로 우리가 요청을 잘못보내고 있는 경우도
“테스트가 통과되더라도 개발단에서의 검증과 QA만 제대로 되면 발생하지 않는 문제이지 않을까?” 라는 생각이 들었다.

물론 검증과 QA로 모든 것을 해결할 순 없겠지만 최소 95% 정도는 웬만한 버그 발생을 잡을 수 있을 거라고 생각한다.
트레이드 오프의 관점으로 보았을 때도 테스트를 외부에 의존시키는 것보다 꼼꼼한 개발단의 검증과 QA를 하는 것이 더 낫지 않을까 라는 생각이 들었다.

때문에 나는 외부 API를 직접 호출해서 테스트하지는 않기로 했다.

결론

이전에 외부 API를 적용할 때는 빨리빨리 되는대로만 구현했던 경험이 있다. 그때는 왜 그랬는 지 모르겠지만 연결만 되면 끝인 줄 알았다.
반면, 우테코에 들어와서 이것저것 많이 배우고 주워들은 결과 한 번의 외부 API 요청에 대해 정말 많은 것들을 고려해야한다는 것을 깨닫게 되었다.

항상 코드 한 줄 한 줄 생각하며 개발하자.
그리고 그 생각을 충분히 코드에 녹여낼 수 있는 개발자가 되기 위해 수준을 길러나가자.
성장에 지름길은 없다. 꼼수없이 깊게 배우고 기억을 위해 기록하자.

+ 추가로 토스 API 문서 진짜 친절했다..! 짱!

긴 글 읽어주셔서 감사합니다. 피드백은 환영입니다! 댓글에 얼마든지 남겨주세요!

GPT API의 응답 값을 원하는 형태로 만들어보자 (with. Chat Completion API & Fine-Tuning)

PgmJUN — Fri, 21 Jun 2024 15:54:23 +0900

졸업작품 프로젝트에서 마주한 문제

졸업작품 프로젝트 ‘코리’를 개발하는 과정에서 GPT API를 사용하여 AI로부터 원하는 응답값을 얻어오는 기능을 구현하던 중 너무나도 어지러운 문제에 직면했다.

코리는 GPT를 사용해서 개발자들의 전반적인 작업에 도움을 주는 어시스턴트 서비스이다.

‘코드 리팩토링’, ‘변수명 추천’, ‘주석을 통한 코드 설명’ 기능이 존재하는데, 이를 구현하기 위해 SpringBoot 환경에서 HttpClient를 사용하여 GPT API에서 제공하는 gpt-3.5-turbo 모델과 통신하여 응답 값을 얻어오는 것 까지는 성공했다.

하지만 여기서부터 몇 가지 문제에 직면하면서 고민이 시작되었다.

문제1. 일정하지 않은 응답 형태

GPT 사이트에 접속하여 질문을 던질 때, 질문을 조금만 다르게 보내도 GPT가 응답하는 형식이 계속 바뀌었으며, 정해진 형식 없이 텍스트로 나열하는 형태였다.

아무래도 프로덕트를 구성한다면, 이렇게 얻어온 GPT의 응답 값을 그대로 사용하는 것은 유저 경험과 프로덕트의 완성도 측면에서 문제가 된다고 생각했다.

문제2. 유효하지 않은 요청도 어떻게든 응답함

GPT에게 Java 코드를 Python 코드라고 말하면서 주석 설명을 붙여달라고 요청해보았다.

말도 안되는 요청이지만 GPT는 어떻게든 응답을 쥐어짜내어 Java코드를 Python 코드로 변경하고, 주석을 달아서 응답하였다.

사실 이건 요청, 응답 모두 유효하지 않은 경우이다.

GPT API는 돈을 내고 사용하는 것이기 때문에 이렇게 유효하지 않은 요청과 응답을 주고받는 것은 의미없는 비용만 낭비하게 되는 것이다.

이렇게 유효하지 않은 요청 상황이 발생하면 예외처리를 할 수단이 필요하다고 느껴졌다.

Chat Completion API

위에서 나열한 문제들을 해결하기 위해 선택한 방법은 Chat Completion API 이다.

Chat Completion API를 사용하면 대화 형식으로 GPT와 응답을 주고받을 수 있는데, 이 방식을 통해 assistant에게 가상의 역할을 부여하고, 응답 형태를 알려줄 수 있어서 문제를 해결할 수 있을 것으로 생각했다.

공식 문서

채팅 모델은 메시지 목록을 입력으로 받고 모델이 생성한 메시지를 출력으로 반환합니다. 채팅 형식은 여러 차례에 걸친 대화를 쉽게 할 수 있도록 설계되었지만, 대화가 없는 단일 턴 작업에도 유용합니다.

라는 Chat Completion API에 대한 공식문서의 내용을 읽을 수 있었다.

Chat Completion 방식은 우리가 일반적으로 웹사이트에 접속하여 사용하는 GPT 처럼 이전에 대화한 내용을 통해 응답값을 유추하는 방식과 같은 방식으로, 우리는 이 API를 통해 이전 요청, 응답 내용을 알려줄 수 있고 이를 바탕으로 다음 대답을 생성하도록 유도할 수 있다.

예시를 통해 살펴보자

우리가 무턱대고 GPT에게 “그것이 어디서 진행되었나?” 라는 질문을 한다면 GPT는 이상한 답변을 내놓게 될 것이다.

하지만 Chat Completion 방식을 통해 “그것이 어디서 진행되었나?” 라는 질문 이전 ‘2020 World Series’에 대한 대화의 문맥이 포함된 대화뭉치를 제공한다면 GPT는 훨씬 정확하고 수월한 답을 내놓을 수 있게 되는 것이다.

이것이 Completion 방식의 기본 개념이다.

Chat Completion Role

GPT의 Chat Completion에는 3가지 Role이 존재한다.

system Role (시스템 역할):

"system" 역할은 API 요청에서 GPT-3 모델에게 주어지는 지시 또는 문맥을 정의한다.
이 역할은 모델이 요청에 대답할 때 원하는 행동을 나타내며, 일반적으로 문맥을 설정하고 대화 스타일의 상호 작용을 정의하는 데 사용된다.
system Role을 통해 model에게 너는 ‘어떤 역할인지’, ‘어떻게 답변해야하는 지’ 등을 알려주어 대화 스타일을 지정할 수 있었다. 예를 들어 “말 끝마다 ^^를 붙여서 대답해” 라고 하면 모든 응답의 끝에 “^^”를 붙여서 응답하게 된다.

user Role (사용자 역할):

"user" 역할은 API 요청에서 사용자의 입력 또는 질문을 정의한다.
이 역할은 모델이 질문에 답하거나 특정 주제에 대한 정보를 생성하는 데 사용된다. 쉽게말해 사용자는 "user" 역할을 통해 모델에게 질문하거나 정보를 요청할 수 있다.

assistant Role (응답자 역할):

요청에 대한 AI model의 응답을 전달하는 응답자 역할입니다.

그리고 user Role을 통해 model에게 질문을 전송하면, model은 system으로부터 부여받은 내용을 통해 응답을 생성하여 assistant 역할로 return한다.

나는 이 방식이 응답 형태를 고정하는 하나의 열쇠라고 생각했다.
때문에 Chat Completion 방식을 어떻게 활용하여 API 호출에 응용할 수 있을 지 연구해보기로 결정했다.

Fine Tuning

Chat Completion 방식을 API 호출 과정에서 응용할 수 있는 해결책을 찾는 과정에서 Fine Tuning이라는 것을 알게 되었다.

‘미세 조정' 이라는 뜻을 가진 Fine Tuning은 어떤 요청을 받았을 때 어떤 형식으로 응답을 해야하는 지에 대한 데이터셋을
Chat Completion API 방식으로 만들어서 GPT 모델에 학습시키면 원하는 출력 포맷팅을 학습시킬 수 있었다.

공식문서

공식문서에 나와있듯이 Fine Tuning을 통해 믿을 수 있는 출력 포맷팅 이라는 이점을 얻을 수 있었다.

즉 학습 시킨대로 출력 형태를 지정할 수 있다는 뜻이었다.

Fine-Tuning 가능 모델

현재 공식 문서에서 말하는 Fine-Tuning이 가능한 모델은 이렇게 3가지가 존재하는데
나는 애초에 gpt-3.5-turbo 모델을 사용하고 있기도 했고, 가장 권장하는 모델이기에 gpt-3.5-turbo-0613을 택했다.

뒤에 0613은 해당 모델의 릴리즈 날짜인데, 이는 21년 6월 13일에 릴리즈 되었음을 뜻한다. 다음 모델이 릴리즈 되면 뒤에 숫자는 바뀔 수 있으니 참고하자.

학습시킬 대화 형식을 담은 파일 준비

학습파일

학습 파일은 Completions API 형태이며, 무조건 jsonl 형식여야함

학습파일 예시

{"messages": [{"role": "system", "content": "당신은 java 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "자동차"}, {"role": "assistant", "content": "1. car\n2. automobile\n3. vehicle\n4. motorcar\n5. auto\n6. ride\n7. wheels\n8. transport\n9. machine\n10. drive"}]}
{"messages": [{"role": "system", "content": "당신은 python 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "자동차"}, {"role": "assistant", "content": "1. car\n2. automobile\n3. vehicle\n4. motorcar\n5. auto\n6. ride\n7. wheels\n8. transport\n9. machine\n10. drive"}]}
{"messages": [{"role": "system", "content": "당신은 java 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "게임결과"}, {"role": "assistant", "content": "1. gameResult\n2. resultOfGame\n3. gameOutcome\n4. gameScore\n5. gameRecord\n6. gameStatistics\n7. gameAchievement\n8. gameProgress\n9. gameEvaluation\n10. gameSummary"}]}
{"messages": [{"role": "system", "content": "당신은 python 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "게임결과"}, {"role": "assistant", "content": "1. game_result\n2. result_game\n3. gameOutcome\n4. gameScore\n5. game_result_1\n6. game_result_2\n7. game_result_3\n8. game_result_4\n9. game_result_5\n10. game_result_final"}]}
{"messages": [{"role": "system", "content": "당신은 javascript 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "던전입구"}, {"role": "assistant", "content": "1. dungeonEntrance\n2. entranceToDungeon\n3. dungeonGate\n4. dungeonEntry\n5. dungeonAccess\n6. entranceOfDungeon\n7. dungeonIngress\n8. gatewayToDungeon\n9. dungeonOpening\n10. dungeonPortal"}]}
{"messages": [{"role": "system", "content": "당신은 go 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "던전입구"}, {"role": "assistant", "content": "1. dungeonEntrance\n2. entranceToDungeon\n3. dungeonGate\n4. dungeonEntry\n5. gateToDungeon\n6. dungeonAccess\n7. entranceOfDungeon\n8. dungeonIngress\n9. dungeonPortal\n10. dungeonWaypoint"}]}
{"messages": [{"role": "system", "content": "당신은 typescript 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "던전입구"}, {"role": "assistant", "content": "1. dungeonEntrance\n2. entranceToDungeon\n3. dungeonGate\n4. dungeonAccess\n5. dungeonEntry\n6. entranceOfDungeon\n7. dungeonIngress\n8. gatewayToDungeon\n9. dungeonOpening\n10. dungeonPortal"}]}
{"messages": [{"role": "system", "content": "당신은 ruby 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "가게"}, {"role": "assistant", "content": "1. store\n2. shop\n3. market\n4. boutique\n5. emporium\n6. outlet\n7. establishment\n8. storehouse\n9. mart\n10. bazaar"}]}
{"messages": [{"role": "system", "content": "당신은 java 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "로또"}, {"role": "assistant", "content": "1. lotto\n2. lottery\n3. luckyNumber\n4. drawResult\n5. jackpot\n6. winningTicket\n7. numberSelection\n8. prizeMoney\n9. ticketPurchase\n10. randomPick"}]}
{"messages": [{"role": "system", "content": "당신은 python 언어 변수명 추천 전문가이다. 단어를 입력받으면 그 단어의 영어 변수명을 10개 생성하여 출력해라"}, {"role": "user", "content": "유저 위치"}, {"role": "assistant", "content": "1. user_location\n2. location_user\n3. userPos\n4. user_place\n5. userLoc\n6. position_user\n7. user_location_data\n8. user_location_info\n9. user_position\n10. user_geo"}]}

//...

유효하지 않은 요청 처리 예시

{"messages": [{"role": "system", "content": "당신은 java 언어로 작성된 코드를 받으면 이를 분석하여 설명 주석을 달아주는 코드 전문가이다. 만약 받은 코드가 java 언어의 문법이 아니거나 java라는 언어가 존재하지 않다면 X를 출력하고, 받은 코드가 java 언어로 작성된 것이 맞다면 각 코드 라인의 윗줄에 코드 기능 설명을 주석으로 언어 형식에 맞는 주석으로 달아라."}, {"role": "user", "content": "a = int(input())\nprint(a)\n"}, {"role": "assistant", "content": "X"}]}

위에서 언급했던 유효하지 않은 요청에 대해서는 ‘X’ 를 응답하도록 학습시켰다.

서버 내에서는 응답값이 ‘X’ 이면 그에 따라 예외처리를 수행해줄 것이다.

학습 파일 업로드 API 호출

curl https://api.openai.com/v1/files \
-H "Authorization: Bearer ${GPT-API-KEY}" \
-F purpose="fine-tune" \
-F file="@학습파일명.jsonl"

학습파일이 준비되었다면 학습파일 업로드 API(https://api.openai.com/v1/files) 를 호출하여 준비된 학습파일을 OpenAI에 업로드해야한다.

이때 GPT API KEY가 사용되는데, 이 KEY는 유료로 사용할 수 있다.

응답값

{
  "object": "file",
  "id": "학습파일ID",
  "purpose": "fine-tune",
  "filename": "학습파일명.jsonl",
  "bytes": 4372,
  "created_at": 1697785733,
  "status": "uploaded",
  "status_details": null
}

여기서 사용할 내용은 학습파일ID이다.
이는 OpenAI에 학습파일이 등록된 ID를 뜻하며 이를 통해 파인튜닝을 시작하거나 종료하는 등의 작업을 수행할 수 있다.

파인튜닝 시작

curl https://api.openai.com/v1/fine_tuning/jobs \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${GPT-API-KEY}" \
-d '{
"training_file": "학습파일ID",
"model": "gpt-3.5-turbo-0613"
}'

학습파일ID과 FineTuning할 모델명을 포함한 curl요청으로 파인튜닝을 시작할 수 있다.

파인 튜닝의 진행상황은 OpenAI Playground에서 실시간 확인이 가능하다
위 FineTuning 과정은 Playground웹페이지에서 UI로 간편하게 진행이 가능하다.

Fine-Tuning 완료

Fine-Tuning이 완료되면 이렇게 튜닝된 모델의 이름이 출력된다!

이제 이 모델을 사용하기만 하면 된다.

Fine-Tuning gpt-3.5-turbo VS Default gpt-3.5-turbo 비교

파인튜닝이 정상적으로 완료되어서 우리가 원하던 고정된 형태의 응답값을 얻을 수 있는 지 검증하기 위해서 기존의 GPT 기본 모델과 파인튜닝한 모델의 ‘응답 형태’ 를 비교해보았다.

변수명 추천

gpt-3.5-turbo 모델

[응답 형태]

고정되지 않은 형태의 응답 형태이며 매 요청마다 달라진다.

gpt-3.5-turbo FineTuning 모델

[응답 형태]

모든 요청에서 항상 고정된 형태의 응답 형태이며, 언어의 종류에 따라 각 언어의 변수명 네이밍 패턴에 맞게 작명한다.

코드 리팩터링

gpt-3.5-turbo 모델

gpt-3.5-turbo FineTuning 모델

데이터셋을 통해 리팩토링된 코드를 출력하고 마지막에 리팩토링 내용 요약을 출력하도록 학습시켰다. 한 눈에 들어오는 깔끔하고 통일성있는 응답결과로 변한 것을 확인할 수 있었다.

gpt-3.5-turbo FineTuning 모델 - 오류 처리

모델을 학습하는 데이터셋에 유저가 전송한 코드와 언어가 매칭되지 않으면 ‘X’라는 응답 결과만을 Response하도록 학습시켰다.

서버에서는 요청 결과로 ‘X’를 Response받으면 다음과 같이 예외를 발생시키도록 구현하였다.

주석 달기

gpt-3.5-turbo 모델

gpt-3.5-turbo FineTuning 모델

설명 주석 달기 기능은 “입니다.” 등의 표현없이 단답으로 깔끔하게 응답하도록 만든 부분 외에 많이 다른 점이 없다.

gpt-3.5-turbo FineTuning 모델 - 오류 처리

리팩토링 기능의 오류처리와 동일하게 모델을 학습하는 데이터셋에 유저가 전송한 코드와 언어가 매칭되지 않으면 서버에서는 다음과 같은 예외를 발생시키도록 구현하였다.

사용 비용 (Cost)

FineTuning을 하면, 튜닝 중에 발생하는 초기 훈련 비용과 사용 비용 두 가지의 비용이 분류된다.

아래에는 공식문서에서 볼 수 있는 가격표이니 확인하길 바란다.

스프링부트 S3 PreSignedURL을 통한 이미지 저장

PgmJUN — Fri, 21 Jun 2024 01:04:48 +0900

적용을 고려한 이유

“우리집 반려동물의 AI 프로필 사진관” 펫튜디오 프로젝트를 개발하는 과정에서 반려동물 AI 프로필 사진을 만들기 위해 Stable Diffusion 모델에 학습시킬 10~12장의 이미지를 S3에 저장해야하는 상황이 발생하였다.

일반적으로 이러한 경우에 클라이언트→서버 방향으로 이미지 파일을 전송하고 서버→S3 방향으로 이미지를 저장시키는 구조를 대체적으로 많이 봐왔을 것이다.

하지만 10장~12장이나 되는 이미지를 서버로 전송하는 일은 일반적은 요청과는 다르게 서버에 가하는 부하가 컷고, 금전적인 이슈로 AWS 프리티어의 t2.micro를 사용 중인 현재 인프라 환경에서 최대한 부하를 줄이는 작업은 불가피했다.

때문에 이미지 저장의 책임을 클라이언트 측에 위임하여 서버에 가해지는 부하를 감소시키고자 PreSignedURL 방식을 도입하기로 결정하였다.

PreSignedURL이란?

PreSignedURL은 S3 버킷의 특정 디렉토리URL에 대하여 미리 접근에 대한 서명(권한을 부여하는 일이라고 생각하면 된다)을 받은 후, 서명된 URL, 즉 PreSignedURL 을 사용자에게 넘겨주어 특정 권한에 대한 요구없이 S3에 파일을 업로드할 수 있는 방식이다.

원래는 S3에 파일을 업로드하려면 S3 관련 권한을 가진 IAM 또는 루트 계정으로 접근해야 하지만, 미리 서명을 통해 권한을 가진 PreSignedURL을 사용하면 권한에 대한 증명없이 서명된 S3 버킷 디렉토리 경로에 파일 업로드가 가능하다.

미리 권한을 부여한 URL이면 보안적으로 안 좋지 않을까?

PreSignedURL은 생성 시에 만료 일자를 정할 수 있기 때문에 안전한 관리가 가능하다.

우리가 활용할 IAM 사용자는 AWS 서명 버전 4를 사용할 경우 최대 7일 동안 유효하다고 문서에 적혀있다.

물론 최댓값인 7일을 다 사용할 건 아니고, 업로드에 필요한 시간에서 조금 넉넉하게 잡은 1~2분 정도의 시간으로 제한할 예정이다.

업로드된 파일의 소유권

PreSignedURL 방식을 통해 권한이 없는 유저도 S3에 파일을 올릴 수 있지만, 파일의 소유권은 버킷 소유자가 객체를 소유하게 된다.

AWS Docs

자세한 내용은 문서를 통해 살펴보자

미리 서명된 URL을 통해 객체 공유 - Amazon Simple Storage Service

미리 서명된 URL을 통해 객체 공유 미리 서명된 URL을 사용하여 다른 사람이 Amazon S3 버킷에 객체를 업로드하도록 허용할 수 있습니다. 미리 서명된 URL을 사용하면 상대방에게 AWS 보안 자격 증명

docs.aws.amazon.com

♻️ PreSignedURL 동작 플로우

펫튜디오에선 클라이언트에서 PreSignedURL을 요청하는 API를 호출하면, 로직을 통해 서명된 URL과 저장될 Image의 경로 를 클라이언트에게 전송할 예정이다.

어떤 방식으로 동작하는 지, 그림을 통해 이해해보자

1. PreSignedURL 요청

클라이언트에서 파일 저장을 위해 S3 관련 권한을 가지고 있는 WAS에게 PreSignedURL 발급을 요청한다.

PreSignedURL은 각 파일 별로 생성해야 하기 때문에 2개 이상의 파일을 저장할 예정이라면, 해당 과정에서 파일 개수에 대한 정보를 WAS에 함께 넘긴다.

2. PreSignedURL 생성 요청

WAS는 파일 개수에 따른 파일을 저장할 S3 버킷 디렉토리 경로를 지정 후, 요청에 담아 S3에 PreSignedURL 생성을 요청한다.

3. PreSignedURL 발급

S3는 WAS의 권한을 확인 후, 요청받은 S3 버킷 디렉토리 경로에 대한 PreSignedURL을 발급하여 WAS에게 전달한다.

4. 발급받은 PreSignedURL, ImageURI, S3DirectoryPath 전달

WAS는 발급받은 PreSignedURL과 ImageURI, S3DirectoryPath 를 클라이언트에게 전달한다.

여기서 ImageURI 란, 이미지가 S3에 저장되었을 때 해당 이미지에 접근할 수 있는 주소이다. WAS는 이미지 저장의 역할을 Client에게 넘기기 때문에 이미지가 정상적으로 저장되었는 지 확인할 방법이 없다.

때문에 클라이언트가 PreSignedURL을 통해 이미지를 저장한 후, 저장에 성공한 Image의 URI를 서버에게 전달하여 해당 이미지가 업로드에 성공하였음을 전달하도록 하였다.

ImageURI는 클라이언트로부터 다시 전달받은 후에 DB에 저장되어 모델 파인튜닝 등에 적극적으로 활용된다.

S3DirectoryPath는 이미지가 저장될 S3의 디렉토리 경로이다. 해당 디렉토리 안에 이미지들이 저장되며, 문제 발생 시 이미지 삭제 요청 등에 사용된다.

5. PreSignedURL을 통해 이미지 업로드

클라이언트는 PreSignedURL을 통해 이미지를 업로드한다. 이미지 업로드는 PreSignedURL에 PUT 메서드로 바이너리 파일을 전송한다.

만약 이때 업로드 실패 등의 오류 발생 시 클라이언트에선 오류를 발생에 대한 처리를 수행 후, 4번 과정에서 받은 S3DirectoryPath를 WAS의 이미지 삭제 API에 요청하여 해당 디렉토리와 디렉토리에 저장된 이미지를 제거한다.

6. ImageURI, S3DirectoryPath 전달

클라이언트는 이미지를 업로드 후 ImageURI와 S3DirectoryPath를 WAS에게 전달한다.

WAS는 해당 데이터를 활용하여 애완동물 정보를 저장하고, 이후 이미지 관련 작업에 활용한다.

앱에서 직접 S3에 업로드 VS 서버에서 PreSignedURL 발급받아 업로드

PreSignedURL을 도입하기로 했던 개발 초기에는 이런 생각이 들었다.

서버에서 PreSignedURL을 발급받지 않고 앱에서 직접 S3에 업로드하는 방식을 사용하면 PreSignedURL을 발급하는 복잡한 코드를 작성하지 않고 속도도 더욱 개선되지 않을까?

이러한 고민을 해결하기 위해 인터넷 여러 글들을 찾아본 결과, 위처럼 굳이 서버에 PreSignedURL을 요청하지 않고 앱에서 직접 S3에 업로드하는 방식 또한 가능하다는 것을 알게 되어 고민을 시작하게 되었다.

결론부터 말하자면 본인은 이 문제에 대한 깊은 고민의 끝에 서버에서 PreSignedURL을 발급받아 업로드하는 방식을 선택했고, 같은 고민을 할 누군가를 위해 내 생각을 기록해두고자 한다.

왜 서버에서 PreSignedURL을 발급하도록 구현했을까?

S3에 접근하기 위해선 S3에 대한 Access 권한을 가진 AWS IAM의 사용자 정보를 사용자의 로컬에 직접적으로 설치되는 앱에 포함하여 개발해야한다.

하지만 앞으로 만들어질 AI프로필 이미지와 사용자가 등록한 본인의 애완동물 사진 등의 주요 정보가 담길 S3에 대한 주요 권한 정보를 앱에 지니게 하는 것은 보안적으로 큰 문제를 불러일으킬 수 있을 것 같다고 생각했다.

때문에 앱보다 훨씬 안전한 환경인 WAS에 S3에 대한 주요 정보를 관리하면서 필요할 때 API 호출을 통해 PreSignedURL을 발급할 수 있도록 구현하기로 결정하였다.

✨ 구현

S3 버킷 생성

ap-northeast-2 선택 후, 버킷 이름 입력

ACL 비활성화됨 선택
버킷 소유자 선호

해당 설정을 해주지 않으면 ACL 관련 400번대 오류가 발생

외부에서 이미지 URI를 통해 이미지에 접근하도록 할 예정이므로, 버킷을 퍼블릭 엑세스로 변경

여기까지 따라왔다면, 그대로 버킷 만들기 선택

S3 버킷 권한 설정

PreSignedURL을 활용하기 위해선 만들어진 버킷의 권한을 수정해야함.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:Put*",
                "s3:Get*"
            ],
            "Resource": "arn:aws:s3:::{현재_버킷_이름}/*"
        }
    ]
}

버킷이 Put 또는 Get 작업을 허용하도록 정책 설정

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "HEAD",
            "GET",
            "PUT",
            "POST"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

HEAD, GET, PUT, POST 메서드에 대해 CORS 설정

해당 설정을 해주지 않으면 CORS 에러 발생

IAM 생성

다음으로 S3에 PreSignedURL 요청을 가능하게 하기 위한 권한을 얻기 위해 AWS IAM을 통해 S3FullAccess 권한을 가진 사용자를 생성해야한다.

AWS IAM에서 사용자 생성 클릭

S3FullAccess 권한 선택

사용자 생성 클릭

생성된 사용자를 클릭하고 보안 자격 증명 클릭

해당 사용자로 엑세스하기 위한 엑세스 키 생성

사용 사례는 CLI 선택

필요하다면 설명 태그를 추가 후, 엑세스 키 만들기 클릭 후 만들어진 엑세스 키를 저장한다.

build.gralde

// AWS
implementation "org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE"

spring-cloud-starter-aws 라이브러리 implementation

application.yml

cloud:
  aws:
    credentials:
      accessKey: ${AWS_ACCESS_KEY_DEV} # S3 관련 권한을 가진 AWS IAM Access Key
      secretKey: ${AWS_SECRET_KEY_DEV} # S3 관련 권한을 가진 AWS IAM Secret Key
    s3:
      bucket: ${AWS_S3_BUCKET_NAME} # S3 버킷 이름
      path: ${AWS_S3_FILE_DEFAULT_PATH} # S3에서 이미지 저장에 활용할 기본 경로
    region:
      static: ${AWS_REGION_DEV} # AWS Region
    stack:
      auto: false

application.yml에 PreSignedURL 구현에 필요한 환경변수 등록

S3Config

@Configuration
public class S3Config {
    @Value("${cloud.aws.credentials.accessKey}")
    private String accessKey;
    @Value("${cloud.aws.credentials.secretKey}")
    private String secretKey;
    @Value("${cloud.aws.region.static}")
    private String region;

    @Bean
    public AmazonS3 amazonS3() {
        BasicAWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
        return AmazonS3ClientBuilder.standard()
                .withRegion(region)
                .withCredentials(new AWSStaticCredentialsProvider(credentials))
                .build();
    }
}

S3Config에서 S3FullAccess 권한을 가진 사용자의 accessKey, secretKey와 region을 통해 AmazonS3 Bean 생성
AmazonS3 Bean을 PreSignedURL 생성에 사용

S3FileService

@Service
@RequiredArgsConstructor(access = AccessLevel.PROTECTED)
public class S3FileService {
    private final AmazonS3 amazonS3;

    @Value("${cloud.aws.s3.bucket}")
    private String bucketName;
    @Value("${cloud.aws.s3.path}")
    private String s3DefaultPath;
    private static final String BUCKET_DIRECTORY_NAME = "petProfile";
    private static final String FILE_NAME_PREFIX = "Petudio_";


    /**
     * presigned url 발급
     *
     * @param s3DirectoryPath 파일을 저장할 S3 디렉토리 경로
     * @param index           이미지 순서
     * @return presigned url
     */
    public String getPreSignedUrl(String s3DirectoryPath, int index) {
        try {
            String filePath = createFilePath(s3DirectoryPath, index);

            GeneratePresignedUrlRequest generatePresignedUrlRequest = getGeneratePreSignedUrlRequest(bucketName,
                    filePath);
            URL url = amazonS3.generatePresignedUrl(generatePresignedUrlRequest);
            return url.toString();
        } catch (Exception exception) {
            throw new BadGatewayException(ErrorCode.BAD_GATEWAY_EXCEPTION,
                    String.format("S3 버킷의 디렉토리(%s/%d) 에 대한 PreSignedURL을 생성하는 과정에서 에러가 발생하였습니다.", s3DirectoryPath, index));
        }
    }

    /**
     * 파일의 전체 경로를 생성
     *
     * @param index 이미지 순서
     * @return 파일의 전체 경로
     */
    private String createFilePath(String directoryPath, int index) {
        // 경로: {BUCKET_DIRECTORY_NAME}/{memberId}/Petudio_{fileId}/{index}
        return String.format("%s/%d", directoryPath, index);
    }

    /**
     * 파일 업로드용(PUT) presigned url 생성
     *
     * @param bucket   버킷 이름
     * @param filePath S3 업로드용 파일 경로
     * @return presigned url
     */
    private GeneratePresignedUrlRequest getGeneratePreSignedUrlRequest(String bucket, String filePath) {
        GeneratePresignedUrlRequest generatePresignedUrlRequest =
                new GeneratePresignedUrlRequest(bucket, filePath)
                        .withMethod(HttpMethod.PUT)
                        .withExpiration(getPreSignedUrlExpiration());
        generatePresignedUrlRequest.addRequestParameter(
                Headers.S3_CANNED_ACL,
                CannedAccessControlList.PublicRead.toString());
        return generatePresignedUrlRequest;
    }

    /**
     * presigned url 유효 기간 설정
     *
     * @return 유효기간
     */
    private Date getPreSignedUrlExpiration() {
        Date expiration = new Date();
        long expTimeMillis = expiration.getTime();
        expTimeMillis += 1000 * 60 * 2;
        expiration.setTime(expTimeMillis);
        return expiration;
    }

    /**
     * 파일을 저장할 디렉토리 경로를 생성
     *
     * @param memberId 회원 Primary Key
     * @return 파일의 전체 경로
     */
    public String createS3DirectoryPath(Long memberId) {
        return String.format("%s/%d/%s", BUCKET_DIRECTORY_NAME, memberId, FILE_NAME_PREFIX + createFileId());
    }

    /**
     * 파일 고유 ID를 생성
     *
     * @return 36자리의 UUID
     */
    private String createFileId() {
        return UUID.randomUUID().toString();
    }

    /**
     * s3 파일 접근 URI 생성
     *
     * @param filePath S3 업로드용 파일 경로
     * @return s3 파일 접근 URI
     */
    public String createImageUri(String filePath) {
        return s3DefaultPath + filePath;
    }


    /**
     * s3 Directory 데이터 삭제
     *
     * @param s3DirectoryPath 파일 삭제를 위한 S3 디렉토리 경로
     */
    public void deleteImagesByS3DirectoryPath(String s3DirectoryPath) {
        try {
            // s3DirectoryPath에 속한 객체들 나열
            ListObjectsV2Request listObjectsRequest = new ListObjectsV2Request()
                    .withBucketName(bucketName)
                    .withPrefix(s3DirectoryPath);
            ListObjectsV2Result objectsResult = amazonS3.listObjectsV2(listObjectsRequest);

            // s3DirectoryPath 내의 객체들 삭제
            for (S3ObjectSummary objectSummary : objectsResult.getObjectSummaries()) {
                String key = objectSummary.getKey();
                amazonS3.deleteObject(new DeleteObjectRequest(bucketName, key));
            }
        } catch (Exception exception) {
            throw new BadGatewayException(ErrorCode.BAD_GATEWAY_EXCEPTION,
                    String.format("S3 버킷의 디렉토리(%s) 내부 데이터를 삭제하는 과정에서 에러가 발생하였습니다.", s3DirectoryPath));
        }
    }
}

S3의 파일을 다루기 위한 객체로 PreSignedURL 생성, S3 파일 삭제 등의 역할을 함

PetController

    // 반려동물 이미지 저장용 S3 PreSignedURL 요청
    @GetMapping("/pet/images/presigned-url")
    public ApiResponse<CreatePetImagesUploadUrlsResponse> createPreSignedUrlForSavePetImages(
            @MemberId final Long memberId, @RequestBody @Valid final CreatePetImagesUploadUrlsRequest request) {
        return ApiResponse.success(petQueryService.createPreSignedUrlForSavePetImages(memberId, request));
    }

PreSignedURL 요청을 받는 Controller 로직이다.

CreatePetImagesUploadUrlsRequest

public record CreatePetImagesUploadUrlsRequest(
        @Min(value = 10, message = "이미지 갯수는 10개 이상, 12개 이하이어야 합니다.")
        @Max(value = 12, message = "이미지 갯수는 10개 이상, 12개 이하이어야 합니다.")
        short imageAmount
) {}

이미지는 10~12개 이어야하기 때문에 Validation 로직 구현

PetService

public CreatePetImagesUploadUrlsResponse createPreSignedUrlForSavePetImages(Long memberId,
                                                                                CreatePetImagesUploadUrlsRequest request) {
        String s3DirectoryPath = s3FileService.createS3DirectoryPath(memberId);
        List<PetImageUploadInfo> petImageUploadInfos = new ArrayList<>();
        
        // s3Directory 경로를 통해, 요청받은 이미지 갯수 만큼 PreSignedURL, ImageURI 생성  
        for (int i = 1; i <= request.imageAmount(); i++) {
            String s3FilePath = s3DirectoryPath + "/" + i;
            petImageUploadInfos.add(
                    new PetImageUploadInfo(s3FileService.getPreSignedUrl(s3DirectoryPath, i),
                            s3FileService.getImageUri(s3FilePath)));
        }

        return new CreatePetImagesUploadUrlsResponse(s3DirectoryPath, petImageUploadInfos);
    }

입력받은 이미지 개수만큼 PreSignedURL, ImageURI를 생성하기 위한 Service 메서드

S3FileService의 createS3DirectoryPath를 활용하여 파일을 저장할 디렉토리 경로 s3DirectoryPath를 생성 후, 슬래시(/) + index 를 덧붙여 각 파일의 s3filePath를 생성한다.
그리고 s3DirectoryPath, s3filePath 를 활용하여 PreSignedURL, ImageURI를 생성하고 만들어진 경로와 s3DirectoryPath를 CreatePetImagesUploadUrlsResponse DTO 객체에 담아 보낸다.

CreatePetImagesUploadUrlsResponse

public record CreatePetImagesUploadUrlsResponse(
        String s3DirectoryPath,
        List<PetImageUploadInfo> petImageUploadInfos) {
}

PetImageUploadInfo

public record PetImageUploadInfo(String preSignedUrl, String imageUri) {
}

✅ 테스트

Postman

Postman으로 해당 API에 요청을 보낸 결과 이렇게 10개의 PreSignedURL이 정상적으로 호출되는 것을 확인할 수 있었다.

S3

클라이언트에서 PreSignedURL을 통해 S3에 이미지 저장을 시도해보았는데 이미지가 정상적으로 저장되었음을 확인할 수 있었다.

ImageUri

PreSignedURL 요청 시에 함께 받은 imageURI를 통해서도 정상적으로 이미지에 접근할 수 있었다.

추후 개선 방향

지금으로도 괜찮은 것 같다고 생각했지만, 문제가 되는 부분이 아직 남아있었다.

PreSignedURL을 통한 이미지 저장에 실패하여, 삭제 API가 요청되었을 때 만약 삭제 API 또한 실패한다면 잘못 저장된 이미지는 계속해서 S3에 남아있게 된다.

이러한 문제 해결을 위한 개선 방향을 고민할 필요가 있을 것 같다.

향후에 개선이 완료된다면 이곳에 기록하겠다.

H2 DB - 인메모리(In-Memory) 모드

PgmJUN — Thu, 20 Jun 2024 17:45:37 +0900

H2 DB를 공부하면서 H2를 In-Memory 모드로 사용할 수 있다는 것을 알게 되었다.

(H2 DB는 보면 볼수록 유용한 기능을 많이 제공하는 것 같다.)

이 In-Memory 모드를 사용하면 개발환경 및 테스트 환경에서 유용하게 사용할 수 있을 것 같다는 생각에 학습하여 적용해보았고,

학습 기록을 포스팅해보려고 한다.

인메모리 모드 (In-Memory Mode)

H2의 인 메모리 모드 는 데이터베이스의 데이터가 메모리에만 존재하고 디스크에 저장되지 않는 모드이다.

테스트 또는 개발 환경 같은 특정 케이스에서는, 데이터의 영속이 필요하지 않을 수도 있다.

H2 DB는 그러한 상황을 위해 데이터가 영속되지 않는 인 메모리 모드를 지원한다.

인메모리 모드는 모든 Connection이 close되면, DB도 close되며 DB에 요청된 CRUD 작업에 대한 내용이 영속되지 않고 모두 휘발된다.

H2에 대해 자세히 알기 이전에는 사람들이 왜 테스트 DB로 H2를 선택하는 지 몰랐지만,
RDB와 똑같이 사용할 수 있지만 모드를 지원한다는 점과, 인메모리 모드로 사용함으로써 얻을 수 있는 성능상의 이점만으로
테스트 DB로 사용할만하다고 생각이 들었다. (테스트 속도는 빠를 수록 좋으니까)

In-Memory Mode의 2가지 종류

이러한 인 메모리 모드는 2가지 종류가 있고 DB URL을 통해 설정이 가능하다.

그 2가지 모드에 대해 알아보자.

• 1 Connection per 1 Database 모드

해당 모드를 적용하는 경우, 동일한 JVM 내에서 두 개의 커넥션을 열면 각각의 커넥션은 서로 다른 DB를 사용할 수 있다.

해당 모드를 사용하면 각각의 커넥션이 각각의 DB를 사용하기 때문에 성능면에서 단점이 있어보였다.
커넥션 별로 다른 DB를 사용해야하는 특수한 상황이 아니라면 사용을 지양하는 편이 좋겠다고 생각이 든다.

• N Connections per 1 Database 모드

여러 커넥션을 통해 하나의 DB에 접근하려면 해당 모드를 선택하면 된다.

해당 모드를 적용하는 경우, 동일한 JVM 내에서 두 개의 커넥션을 여는 경우 두 커넥션은 하나의 같은 DB에 접근한다.

굳이 커넥션 단위로 DB를 분리할 이유가 없다면, 이 N Connections per 1 Database 모드를 사용하는 것을 추천한다.

In-Memory Mode 의 장단점

장점

DB를 설치하고 DB 서버를 실행할 필요없이 build.gradle에서 의존성만 추가해주어도 사용할 수 있다.
모드에 따라 커넥션 단위로 각각의 DB를 사용하게 할 수 있는 등, 세부 옵션이 존재한다.
In-Memory 모드는 매우 빠른 초기화 및 쿼리 성능을 제공하므로, 테스트 및 개발 환경에서 신속한 반복 작업이 가능하다.

단점

여러 JVM을 사용하는 분산환경에서 자원 공유가 불가능하다.
메모리 관리는 JVM 내에서 수행하기 때문에 Embedded 모드와 마찬가지로 동일한 DB에 접근하는 것은 오직 같은 JVM 내에서만 가능하다.
JVM의 메모리를 사용하기 때문에 메모리가 부족한 환경에서 OOM(Out Of Memory)를 유발할 수 있다.

적용 방법

build.gradle

dependencies {
    runtimeOnly 'com.h2database:h2' // h2 의존성 추가
}

• 1 Connection per 1 Database 모드

application.yml

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem
    username: sa
    password:

• N Connections per 1 Database 모드

application.yml

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem:이름
    username: sa
    password:

application.properties의 datasource URL 설정 값을 다음과 같이 설정한다.

이렇게만 설정해주면 H2DB 설치 없이 인 메모리 방식으로 H2 DB를 사용할 수 있다.

Reference

Features

Features Feature List H2 in Use Connection Modes Database URL Overview Connecting to an Embedded (Local) Database In-Memory Databases Database Files Encryption Database File Locking Opening a Database Only if it Already Exists Closing a Database Ignore

www.h2database.com

H2 DB - 3가지 Connection 모드

PgmJUN — Thu, 20 Jun 2024 17:12:35 +0900

우테코 레벨2의 미션을 수행하면서 로컬 DB로 H2를 사용하게 되었는데, 신기한 점이 있어 기록해보고자 한다.

H2는 DB를 작동시키지 않아도 사용이 가능했던 것이다.

위 코드는 실제로 DB에 접근하는 통합 테스트인데,
로컬에 H2 DB 서버를 설치하지도 실행시키지도 않은 상황에서도 정상적으로 작동한다.

어떻게 그럴 수 있는 지에 대해서 H2 DB의 3가지 모드를 살펴보면서 알아보겠다.

H2 DB의 3가지 Connection Mode

H2는 다른 DB와 다르게 3가지 연결 모드를 가지고 있다는 특징이 있다.

H2 DB는 위와 같이 3가지 모드가 있는데

그 중 Embedded Mode 와 Mixed Mode 는 H2 DB 를 설치해서 서버를 실행할 필요없이
스프링부트에서 h2db 의존성만 build.gradle에 추가해주면
그 의존성만으로 DB를 사용할 수 있었다.

나는 Embedded Mode를 사용하고 있었기 때문에 DB 설치 및 DB 서버 실행 과정을 거치지 않고 H2 DB를 사용할 수 있었던 것이다.

그럼 이 3가지 모드가 각각 어떤 특징이 있고 어떻게 동작하는지에 대해서 한 번 살펴보자

임베디드 모드 (Embedded Mode)

H2 Embedded Mode

임베디드 모드는 JDBC를 사용하여, JVM 내에 DB를 열게 된다.

Embedded Mode를 사용하면 DB 서버를 실행시키지 않고도 데이터베이스 연결 및 사용이 가능하다.

Embedded Mode의 장단점

장점

H2가 제공하는 모드들 중에 가장 빠르고 가장 쉬운 커넥션 모드이다.
H2를 설치하지 않고 build.gradle에서 의존성만 추가해주어도 H2 DB를 사용할 수 있다.

단점

Embedded Mode의 DB는 JVM(및 클래스 로더) 당, 단 하나만 열려있을 수 있다. 데이터베이스가 JVM의 내부에 직접 포함되어 있기 때문에 다른 JVM에서는 접근할 수 없는 것이다.
때문에 분산 환경에서는 Embedded Mode 를 사용하는 것은 좋지 않은 선택일 것이다.

적용 방법

build.gradle

dependencies {
    runtimeOnly 'com.h2database:h2' // h2 의존성 추가
}

application.yml

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2://path/name
    username: sa
    password:

서버 모드 (Server-Mode)

H2 Server Mode

h2는 h2 DB의 Server를 통해 DB를 사용하는 방식이다.

위에서 소개한 In-Memory 모드와 Embedded 모드는 build.gradle에서 의존성만 추가해주면
메모리 내에서, 또는 애플리케이션 내에서 정상적으로 작동했지만
H2를 DB Server를 통해 사용하려면 DB가 완전히 외부 의존성으로 분리되므로 H2를 직접 설치하고 서버를 가동시켜주어야 접근이 가능해진다.

적용 방법

build.gradle

dependencies {
    runtimeOnly 'com.h2database:h2' // h2 의존성 추가
}

application.yml

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:tcp://localhost/path/name
    username: sa
    password:

DB의 URL에 tcp를 붙여 h2:tcp://localhost/{path}/{name} 형식으로 사용한다.

혼합 모드 (Mixed-Mode)

H2 Mixed Mode

혼합 모드는 임베디드 모드와 서버 모드가 합쳐진 모드이다.

때문에 이름이 Mixed Mode 인 것이다.

혼합 모드를 사용하면 먼저 실행된 애플리케이션은 '임베디드' 모드로 DB와 연결되지만,
다른 프로세스 또는 JVM에서 실행중인 애플리케이션이 동일한 데이터에 동시에 엑세스 할 수 있도록 'DB 서버'를 실행시킬 수 있다.

즉, 애플리케이션이 DB서버의 호스팅을 담당하는 것이다.

혼합 모드 DB 서버는 'Server API 사용'을 통해 애플리케이션 내에서 또는 종료 또는 시작시킬 수 있으며,

'Automatic Mixed Mode'를 사용하면 자동으로 시작 또는 종료시킬 수 있다.

Automatic Mixed Mode

Automatic Mixed Mode를 사용하면, DB에 연결하려고 하는 모든 클라이언트는

로컬이던 리모트이던 상관없이 완전히 동일한 DB URL을 사용해서 연결을 수행할 수 있다.

적용 방법

build.gradle

dependencies {
    runtimeOnly 'com.h2database:h2' // h2 의존성 추가
}

application.yml

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:~/${dbName};AUTO_SERVER=TRUE
    username: sa
    password:

데이터베이스 URL 끝에 AUTO_SERVER=TRUE 옵션을 추가해주면 된다.

이렇게만 설정해주면 다른 애플리케이션에서도

DB Connection URL에 `jdbc:h2:~/${dbName};AUTO_SERVER=TRUE` 을 사용하여 같은 DB에 접근할 수 있다.

dbName.lock.db 파일

Mixed Mode로 실행시키면, url로 설정한 경로에 dbName.lock.db 라는 파일이 생성된다.

dbName.lock.db 파일을 살펴보면 DB서버의 Private IP와 Port를 확인할 수 있다.

'lsof -i :PORT' 명령으로 터미널에서 조회하면 정상적으로 작동중인 DB 프로세스를 확인할 수 있다.

다른 애플리케이션에서 접속해보기

Mixed Mode를 사용하면 정말 로컬이 아닌 Remote에서도 접근이 되는 지 확인해보았다.

실제로 다른 애플리케이션 환경에서 동일한 URL을 사용하여 연결을 확인했고, 연결에 성공하는 것을 확인할 수 있었다.

Mixed Mode의 장단점

장점

서버 모드처럼 사용가능하지만, 로컬에서 사용할 때는 임베디드 모드와 동일한 연결 속도를 얻을 수 있다.
혼합 모드를 사용하면 로컬에서의 연결은 임베디드 모드를 사용했을 때처럼 빠르다.

단점

혼합 모드를 사용하면 로컬이 아닌 다른 연결은 로컬 연결에 비해 조금 느리다.

Reference

Features

www.h2database.com

내 테스트 코드는 제대로 작성되었을까? (with. 코드 커버리지)

PgmJUN — Wed, 19 Jun 2024 22:16:46 +0900

내 테스트 코드는 제대로 작성되었을까?

우테코 프리코스를 진행하면서 요구사항에 의해 테스트 코드를 작성하였다.
실수를 방지하기 위해 정말 꼼꼼하게 테스트 코드를 작성하며, 엣지 케이스를 찾기 위해 열심히 노력하였다.

하지만 미션 코드가 길어지다보니 "모든 로직에 대한 테스트가 되어있는가?"라는 스스로에 대한 의구심이 들기 시작했다.

때문에 이 의구심을 해결하기 위한 방법을 찾아보았고, 인텔리제이에서 플러그인 설치없이 코드 커버리지를 측정을 할 수 있다는 것을 알 수 있었다.

나는 이를 활용해 최대한 모든 로직을 테스트 할 수 있었고, 몇 번의 클릭만으로 많은 장점을 얻을 수 있다고 생각했기 때문에 이를 공유하고자 간단히나마 글을 작성해보고자 한다.

코드 커버리지란?

코드 커버리지는 내 프로젝트의 코드들의 테스트 코드에서 사용된 정도를 백분율(%)로 나타낸 것이다.
이를 확인함으로써 내가 테스트 코드를 작성하지 못한 부분이 존재하는지를 확인하며, 꼼꼼히 테스트를 작성할 수 있다.

이에 대해 자세히 학습하고자 한다면 아래 블로그를 참고하면 좋을 것 같아 함께 첨부한다.

[소프트웨어 공학] Code Coverage(코드 커버리지)란 무엇인가?

Coverage란, 소프트웨어를 테스팅하는 데 사용되는 중요한 지표중 하나로, 보통 Code가 얼마나 실행되었느냐를 측정합니다. 보통 Coverage를 측정하기 위해서 instrumentation을 합니다. Instrumentation은 많

educoder.tistory.com

[IntelliJ] 코드 커버리지 확인하기

코드 커버리지와 IntelliJ에서 브랜치 커버리지를 확인하는 방법에 대해 알아보자

amaran-th.github.io

커버리지 측정 방법

먼저 이 글은 IntelliJ Ultimate 기준으로 작성되었음을 밝힌다.

Test 패키지를 오른쪽 마우스로 클릭하고, More Run/Debug를 선택한 다음
Run 'Tests in '...' with Coverage를 클릭한다.

그럼 인텔리제이는 코드를 분석하여 백분율로 코드의 Coverage를 출력해준다.

더 정확한 Coverage 확인법 ️‍♂️

인텔리제이는 브랜치 커버리지(Branch Coverage) 측정 방식을 지원하여,
위보다 더욱 정확하고 세밀하게 Coverage를 측정할 수 있도록 돕는다.

브랜치 커버리지(Branch Coverage)란?

브랜치 커버리지는 조건문(if, else if, else)에서 각 조건(branch)이 실행되었는지를 검증한다.

예를 들어 if(조건1 || 조건2 || 조건3)과 같은 조건식이 존재할 때,
3개의 조건에 대해 true인 경우와 false인 경우를 각각 측정한다고 알고 있다.

⚙️ 설정 방법

Test 패키지를 오른쪽 마우스로 클릭하고, More Run/Debug를 선택한 다음
Modify Run Configuration을 클릭한다.

우측에 존재하는 Modify options를 클릭한다.

Code Coverage 탭에 있는 Enable branch coverage and test tracking을 선택한다.

버전에 따라 Use tracking 이라고 나와있을 수도 있다고 한다.

그럼 이렇게 Branch Coverage에 대한 결과를 얻을 수 있는데,
이렇게 확인하니 아직 테스트 면에서 부족한 부분이 드러났다.

그럼 문제의 위치는 어떻게 파악하는데?

100%로 측정되지 않은 클래스에 접근하여 좌측 코드라인을 살펴보면 이렇게
녹색과 갈색이 표시되는 것을 확인할 수 있다.

테스트되지 않은 부분은 갈색, 테스트되는 부분은 녹색으로 표시되는 것이다.

이를 클릭해보면 테스트 코드 상에서 조건이 true였던 경우와 false였던 경우의 수가 출력되는데,
갈색인 부분은 결과값이 한 번도 true였던 적이 없었기 때문에, 이 클래스의 커버리지가 낮게 측정되었음을 확인할 수 있었다.

마치며

단순히 테스트 코드를 작성하는 것 뿐만 아니라

잘 작성하고 있는지에 대한 검증 과정을 통해 코드를 개선해나가면 더 안전하고 좋은 코드를 만들 수 있을 것이라고 생각한다.

테스트 코드가 제대로 작성되었는 지, 확인하고 싶다면 이 방법을 통해 측정해보는 것을 추천한다!

[우아한테크코스 6기] 우테코 최종 테스트 및 합격 회고

PgmJUN — Wed, 19 Jun 2024 01:53:32 +0900

실패의 연속

나는 작년 말 우테코 5기의 최종 테스트에서 떨어졌었다.
사실 아쉽게 떨어진 수준이 아니라, 간단한 문제였지만 문서를 디테일하게 보지 않은 탓이 컸다.

(A로직 수행 후, B로직 수행)을 n번 반복해야 했는데

A를 n번 수행 후, B를 n번 수행하는 방식으로 구현해 버린 것이다. 문서에 설명이 나와있었지만 그 당시의 나는 초긴장 상태였고 글 읽는 것을 평소에 하지 않아 꼬여잇는 글은 잘 이해하지 못했던 것 같다.

그리고 마음을 놓고 지내던 작년 12월 28일, 탈락 소식을 찜질방에서 보게 되었다.

기대하던 활동이었기에 너무나도 허무했다.

디프만 탈락

SW마에스트로 탈락

그런데 여기까지는 역량 부족으로 넘긴다고 쳐도, 그 뒤로 몇 달간 계속해서 탈락의 연속이었다.

우테코 탈락, 소프트웨어 마에스트로 탈락, 디프만 탈락 등등..

자존감도 많이 낮아졌었고, 탈락이 점점 늘어나자 최종까지 갔던 프리코스에서 좀 더 열심히 해볼걸이라는 후회도 많이 되었으며, 멘탈이 나가 매일 하던 개발 공부도 1주 가까이 놓았었다.

SOPT를 만나다

그렇게 시간이 흘러 올해 3월, 지금은 내 개발 인생의 전환점이 된 SOPT라는 동아리를 모집 마감 4시간 전에 우연히 알게 되었고 4시간 동안 5000자가량의 지원서를 작성해서 냈다. 이상할 만큼 문항 하나하나가 내가 공감 가는 내용들이었고 때문에 빠른 속도로 작성할 수 있었다.

총 5000자 이상의 글을 4시간 내로 작성하다 보니, 아카이빙을 제대로 해두지 못했을 정도로 급하게 제출하게 되었는데 운 좋게 서류 합격을 얻어낼 수 있었다.

기분은 좋았지만 서류를 저장해 둔 것이 없으니 자소서에 썼던 내용들의 기억만으로 면접을 준비하게 되었다. 하지만 너무나 소중한 기회로 다가올 것 같은 이 동아리에 모든 걸 걸어보고자 여태껏 공부했던 것들을 모두 흝으며 면접을 준비했고, 덕분에 32기 서버파트에 최종 합격을 할 수 있었다.

[SOPT] 솝트 32기 서버 파트 지원 및 합격 후기

이때부터 너무나 우울했던 내 개발 인생이 변하기 시작했다. 주변에 서버에 대해 깊게 공부한 사람들이 없어서 개발 공부를 매번 혼자 해야 했던 내게 너무나도 좋은 동반자들이 생겼고, 서버뿐만 아니라 기획, 디자인, iOS, 안드로이드 등 다양한 파트의 사람들과 친해지며 개발자로서 다양한 관련 업종의 사람들과 소통하는 법을 배울 수 있었다.

특히 활동 후 매번 있는 뒤풀이를 통해 내가 가장 못하는 ‘놀 땐 노는 방법’도 배워나가게 되었다.

처음엔 어색했지만 너무 따듯하고 재밌는 사람들과 금방 친해지기 시작했고 탈락의 쓴맛을 잊어가며 소중한 추억도 많이 쌓아나갔다.

그리고 정말 신기하게도 나와 같이 탈락의 딜레마에 빠졌었고, 똑같이 우테코 5기 백엔드 최종에서 탈락하게 된 동규형을 만나게 되었다.

나는 이 형과 금세 친해지게 되어 동아리 내에서 우테코 대비 스터디를 만들고 뜻이 있는 사람들을 모아 6기를 함께 준비해 나갔다.

이펙티브 자바 책을 읽고 우테코 미션에 적용한 후 함께 온라인에서 모여 자신이 적용한 것을 공유하며, 프리코스와 최종 코딩 테스트를 대비했고 지식을 길러나갔다. 또 운 좋게도 SOPT를 수료하시고 우테코 5기에 합격하여 활동 중이신 정훈님께서 선뜻 멘토로 나서주셔서 코드 리뷰 등 깊이 있는 활동 또한 진행할 수 있었다.

이 외에도 SOPT에서 파트 세미나, 클디서 합동 세미나, 솝커톤(1박 2일 단기 해커톤), 앱잼(5주간의 장기 해커톤) 등을 거치며 너무나도 빠르게 성장할 수 있었고 어디에서도 못 만날 소중한 인연들을 정말 많이 만나게 되었다.

그렇게 상반기가 지나고 10월이 되면서 우테코의 새로운 모집 소식이 들려왔다. 그때부터 이전에 우테코 대비 스터디를 함께 이끌었던 형과 ‘진짜’ 우테코 대비 스터디를 수행하게 되었다.

실전에서 프리코스 문제를 해결하고 제출 마감 후에 서로 코드를 리뷰해 주며 서로 더욱 좋은 방향으로 이끌어주는 목적의 스터디였는데, 코드에 대해 여러 얘기들을 나누며 생각한 것보다 더 큰 도움이 되었다.

뿐만 아니라 우테코 커뮤니티(디스코드)에서 만나게 된 인연도 생겨 이들과도 코드 리뷰 스터디를 진행하며 근거 있는 코드 작성을 위해 노력하고 몰입했다.
그러다 보니 코드에 대해 얘기하는데 5시간이 순식간에 지나가는 경험도 할 수 있었고 개발 얘기를 너무나도 재밌게 하는 내가 진짜 개발자에 한 걸음 가까워졌구나 싶었다.

다시 찾아온 기회

우테코 6기 1차 합격

4주의 프리코스를 마친 나는 정성 들여 쓴 지원서류, 그리고 매 주차 별 배운 점과 느낀 점을 4~5000자씩 꽉꽉 채워냈던 소감문 덕분인지 다시 한번 최종 코딩 테스트에 임할 수 있게 되었다.

인턴 합격

그리고 이쯤에 지원한 기업 가치관이 너무나도 적합하다고 생각해서 지원했던 스타트업의 인턴도 서류, 면접 과정을 거쳐 당당히 최종 합격을 하여 내년에 대한 대비가 되어있었다.

하지만 1년간 다시 한번 도전하기 위해 칼을 갈고 있던 우테코가 남아있었기에 합격한 곳이 있음에도 불구하고 큰 긴장과 부담감을 가지고 최종 시험을 준비했다.

최종 코딩 테스트 전날 밤엔 심장이 쾅쾅 뛰어서 잠도 제대로 자지 못했다..

그렇게 몽롱한 상태로 침대에서 일어난 나는 밥을 든든히 챙겨 먹고 시험 장소로 향했다.
두 번째이다 보니 지난번과는 다르게 조금은 마음이 편했고, 같이 열심히 준비한 형도 합격했기 때문에 함께 점심도 먹고 커피도 마시며 시험장 입장을 대기하는 시간들은 꽤나 평온했다. 그렇게 시간을 보내다 어느덧 12시가 되어 입장이 시작되었고 자리를 잡고 마음을 가다듬은 뒤 1시 반부터 시험을 보기 시작했다.

시험 시작

처음 문제를 마주했을 때는 조금 놀랐다.
긴장했기 때문이었는지 생각보다 난이도가 높아 보였고, 실제로 지난 기수에 최종 시험에 비해 꽤나 복잡한 구현이 필요했기 때문이다.

나는 최대한 마음을 가다듬고 기능구현 문서부터 꼼꼼히 검수하며 50분가량 작성했다.

저번 기수 탈락의 원인이 문제 분석 불충분이었기 때문에
이번엔 이 문제는 내가 설계했다고 생각될 정도로 어떻게 돌아가는지 완벽히 이해하는 것이 나의 전략이었기 때문에 문제 이해와 문서 작성에 한 시간 가까이 투자했다.

그렇게 문서 작성 후, 순조롭게 개발을 시작한 지 1시간 30분 뒤 나는 거대한 난관에 마주치게 됐다

우선 빠르게 코드를 작성하려고 메서드 분리 없이 길게 늘여 적은 로직에서 오류가 발생하여 원하는 데이터와는 전혀 다른 데이터가 도출되는데, 코드가 길어 어디서 난 오류인지 알 수 없어 디버깅 과정이 꽤나 복잡했다.

나는 필사적으로 노력했지만 에러 포인트가 1시간 이상 찾아지지 않는 불상사가 발생했고, 심장이 미친 듯이 뛰기 시작했다.
포기라는 생각이 머릿속에 살짝이나마 들었지만 오늘을 위해 노력해 온 1년 간의 나를 실망시키고 싶지 않았다. 그리고 곧바로 큰 결심과 함께 해당 로직을 모두 지우고 다시 작성하기 시작했다.

마음을 내려놓고 차근차근 주석을 통해 코드에 대해 설명을 적어나가며 개발하다 보니 깔끔하고 가독성 높은 로직으로 재탄생하였고,
로직의 흐름을 천천히 따라가는 과정에서 이 로직과 함께 사용되는 다른 메서드에서 ArrayList의 특정 인덱스 값을 교체할 때 add(index, Object) 메서드를 사용하고 있던 부분을 발견할 수 있었다.

이는 중간에 데이터를 끼워 넣는 메서드인데 set(index, Object) 메서드를 사용해야 하는 것을 긴장하다 보니 잘못 끼워 넣고 만 것이었다.
이 포인트를 수정하고 길었던 코드를 하나하나 메서드로 분리해 나가니 로직은 정상적으로 작동하기 시작했고 시험 시작 3시간 후 모든 기능 구현에 성공하게 되었다.

너무 기뻐서 소리 지르고 싶었지만 끝날 때까지 긴장감을 유지한 채 최대한 리팩토링을 진행했고, 기능 문서에 작성한 내용들을 꼼꼼히 체크하였으며, 마지막엔 객체의 테스트 코드를 작성하다 시간이 종료되어 제출하고 나오게 되었다.

최종 코딩테스트 예제 테스트 통과

작년에 그렇게 보고 싶었던 화면이 올해는 나와주었고 1년을 멋지게 마무리했다는 생각과 함께 만족스러운 퇴실을 할 수 있었다.

최종 합격, 그리고 1년을 돌아보며 ✨

집에 돌아와 코드를 살펴보니 조금 실수한 부분이 있어 걱정이 되었지만, 정말 다행히도 12월 27일 오늘 오후 3시,, 우테코 6기에 최종 합격할 수 있었다.

올해 초엔 불합격의 연속으로 고통받고 있던 나였지만 포기하지 않고 1년간 열심히 달린 결과, 다양한 합격을 경험하고 개발자로서 그리고 대학생으로서 다신 없을 추억들을 쌓아온 소중한 24살을 보낼 수 있었고
인턴쉽과 우테코 동시 합격이라는 행복한 연말 선물을 받게 되어 행복한 고민을 하며 하루를 보내고 있는 나를 마주할 수 있었다.

사람은 살아가다 보면 누구에게나 벼랑 끝에 매달린 것 같은 순간이 오는 것 같다.
그 벼랑에서 포기하고 힘을 놓으면 절벽 밑으로 떨어지지만 힘을 내어 땅 위로 올라온다면 다시 살아갈 수 있게 된다. (물론 그 절벽의 높이가 떨어지고 보니 생각보다 낮아서 금방 위로 올라올 수도 있을지도 모른다. 하지만 그건 절벽 밑으로 떨어져 봐야 알 수 있고 그것 또한 용기가 있어야 가능하다.)

나는 절벽에서 땅 위로 올라오는 과정을 1년이라는 시간 동안 겪어온 것 같다. 위에서 말한 내용은 우테코와 관련된 2023년 만을 적어놓은 것이며 이 외에도 글 읽는 능력 향상을 위해 독서를 정말 많이 시도했으며, 졸업작품 프로젝트 설계 및 개발, SOPT 32/33기의 다양한 활동, 기술에 근거를 가지고 사용하기 위해 활용 방법과 이유 등을 꼼꼼히 체크하고 나중의 나를 위해 기록하는 습관 들이기, 대학 컴퓨터공학부 전공 동아리 회장, 동아리 부원 대상 8주간의 자바 특강 진행, 무중단 CI/CD 과정 익히기, GPT 모델 FineTuning 하여 응답 형태 고정 및 성능 개선 경험 등 내 인생 중 2023년은 개발자로서 가장 큰 성장을 했다고 자신 있게 말할 수 있을 정도로 할 수 있는 건 모두 다 하며 1년을 보냈다.

“포기하지 않고 끝까지 노력하는 사람에게 기회는 잡힌다.”라고 지금의 나는 생각한다.

21년 10월의 나는 여러 언어와 프레임워크를 공부해 봤지만 전혀 흥미가 생기지 않아 개발이 적성에 맞지 않는다고 생각되어 포기하려고 했었다. 하지만 포기하지 않고 달려온 지금의 나는 꽤나 멋진 개발자로 성장하고 있지 않은가.

아버지가 하셨던 말 중에 가장 기억에 남는 말이 있다.

“미친 듯이 해도 안되면 그때 포기해라”

몇 번이고 쓰러져도 다시 일어나 달려본 뒤에, 그래도 난 아닌 것 같다는 생각이 들면 그때 가서 포기해도 늦지 않는다.

지금 당신이 미친 듯이 해보지 않았다면 조금만 미쳐보길 바란다.

마치며

긴 글 읽어주셔서 감사합니다. 그리고 모든 분들 올 한 해 수고 많으셨습니다!
이 글을 읽고 계신 모든 분들! 행복한 하루 되셨으면 좋겠습니다.

[우아한테크코스 6기] 프리코스 4주차 회고

PgmJUN — Wed, 19 Jun 2024 01:53:24 +0900

https://velog.io/@pgmjun/%EC%9A%B0%ED%85%8C%EC%BD%94-6%EA%B8%B0-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-4%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[우테코 6기] 프리코스 4주차 회고

매주 미션을 수행하면서 코드에 애정을 가지고 최선을 다해 몰입하여 열심히 했기 때문인지, 코드가 정말 만족스러웠고 더 수정할 곳이 없어보였다. 하지만 항상 한 곳 정도는 문제가 발생해 급

velog.io

[우아한테크코스 6기] 프리코스 3주차 회고

PgmJUN — Wed, 19 Jun 2024 01:53:15 +0900

https://velog.io/@pgmjun/%EC%9A%B0%ED%85%8C%EC%BD%94-6%EA%B8%B0-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-3%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[우테코 6기] 프리코스 3주차 회고

3주차가 시작된 후 새로운 미션을 수행하기 전에, 우테코 커뮤니티(디스코드)에서 만난 사람들과 함께2주차 미션에 대한 자신의 코드를 설명하고 서로 리뷰하며 토론하는 시간을 가졌다.처음엔

velog.io

[우아한테크코스 6기] 프리코스 2주차 회고

PgmJUN — Wed, 19 Jun 2024 01:53:06 +0900

https://velog.io/@pgmjun/%EC%9A%B0%ED%85%8C%EC%BD%94-6%EA%B8%B0-2%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[우테코 6기] 프리코스 2주차 회고

2주간의 프리코스 1주차 미션이 끝나고 사람들에게 코드리뷰를 받는 과정에서 내 코드에 대해 명쾌하게 설명할 수 없는 내 모습을 통해 아직 메타인지가 부족함을 깨달을 수 있었다. 나름

velog.io

[우아한테크코스 6기] 프리코스 1주차 회고

PgmJUN — Wed, 19 Jun 2024 01:51:50 +0900

https://velog.io/@pgmjun/%EC%9A%B0%ED%85%8C%EC%BD%94-6%EA%B8%B0-%ED%94%84%EB%A6%AC%EC%BD%94%EC%8A%A4-1%EC%A3%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

[우테코 6기] 프리코스 1주차 회고

프리코스와 함께 보낸 1주는 좋은 사람들을 많이 만나 행복이 꽉꽉 들어찼던 시간이었다.열심히 활동해서 그런지 1주 밖에 지나지 않았는데 벌써부터 우테코에 정이 많이 든 것 같다. 살면서 이

velog.io

[인증/인가] JWT란? (with. AccessToken, RefreshToken 사용법)

PgmJUN — Wed, 19 Jun 2024 01:11:54 +0900

프로젝트 중 로그인 기능 구현을 위해 JWT, OAuth2 를 사용해서 카카오 로그인하기 구현을 해보았다.

그 중 사용했던 JWT는 서버에서 인증/인가에 사용되는

서버 레벨에서 보안과 가장 밀접한 내용이고,

깊이있게 학습해보면 많은 도움이될 거라는 생각에 학습과 함께 이곳에 기록하게 되었다.

JWT 공식문서

jwt의 더 깊고 자세한 내용은 아래 공식문서를 통해 확인할 수 있다.

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

JWT

Jwt란 Json Web Token 의 줄임말로 '인증에 필요한 최소한의 정보들을 담아 암호화시킨 토큰' 이며,

서버와 클라이언트 통신 시 HTTP의 Authorization 헤더에 담아서 인증/인가 수단으로 사용할 수 있다.

JWT에는 어떤 정보를 담아야할까?

방금 JWT에 인증에 필요한 최소한의 정보를 담는다고 했다.

그 이유는 JWT 토큰의 Body, Header 정보는 쉽게 열어볼 수 있기 때문에 인증에 필요한 최소한의 정보만을 두어야한다.

당장에도 아래 사이트에 들어가서 jwt 토큰을 올려두면 헤더와 바디를 파싱해서 보여준다.

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

때문에 나는 보통 JWT가 어떤 회원의 토큰인지 정도만 알 수 있도록

회원의 고유 식별자이자 DB의 PrimaryKey인 'memberId' 만을 담아두곤 한다.

JWT의 구조

Jwt Header

JWT는 위와 같은 구조로 디코드 되어있는데 . 을 중심으로 Header, Payload, Signiture 로 나누어진다.

1. Header

Jwt Header(Decoded)

Jwt의 헤더는 alg와 typ으로 구성되어 있다.

"alg" : 암호화할 해싱 알고리즘

"typ" : 토큰의 타입

2. Payload

Jwt Payload(Decoded)

Payload는 위와 같은 형식으로 주요 내용들을 담고 있다.

여기서는 하나의 정보를 클레임(Claim) 이라고 부른다.

Payload에 들어가는 클레임은 3종류로 이루어져 있으며 아래와 같다.

등록된 (registered) 클레임

Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.

등록된 클레임은 유용하고 상호운용 가능한 클레임 설정을 제공하며,

필수는 아니지만 사용이 권장되는 JWT 에서 미리 선언된 클레임이다.

등록된 클레임의 종류로는 아래 클래임들이 존재한다.

iss

토큰 발급자 (issuer)

sub

토큰 제목 (subject)

aud

토큰 대상자 (audience)

exp

토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야 한다. (자바에서 설정시 new Date(System.currentTimeMillis()) 사용)

nbf

Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념이다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다.

iat

토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단할 수 있다.

jti

JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용된다. 일회용 토큰에 사용하면 유용하다.

공개 (public) 클레임

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

공개 클레임은 JWT를 사용하는 사람들이 마음대로 정의할 수 있습니다.

하지만 공개 클레임을 사용하려면 다른 클레임들 간의 충돌을 방지하기 위해서 IANA JSON 웹 토큰 레지스트리에 정의하거나

충돌 방지 네임스페이스를 포함하는 URI로 정의해야 합니다.

비공개 (private) 클레임

Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.

등록된 클레임도 아니고, 공개된 클레임들도 아니다.

양 측간에 (클라이언트 - 서버) 협의 하에 특정 정보를 공유하기 위해 사용되는 커스텀 클레임이다.

예시)

{
  "memberId": 1
}

3. signature

Jwt Signature(Decoded)

Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성한다.

Header와 Payload는 단순히 인코딩 된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만,

Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다.

따라서 Signature는 토큰의 위변조 여부를 확인하는 데 사용된다.

해싱(Hashing)이란?

해시 함수 또는 해시 알고리즘 또는 해시함수 알고리즘은 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다.

해시 함수에 의해 얻어지는 값은 해시 값, 해시 코드, 해시 체크섬 또는 간단하게 해시라고 한다.

이렇게 해시 알고리즘을 사용하여 해시 코드를 얻는 과정을 해싱이라고 한다.

JWT 사용법

보통 JWT 를 사용할 때는 AccessToken, RefreshToken 방식으로 사용한다.

우선 AccessToken과 RefreshToken에 대해서 먼저 알아보자.

AccessToken 이란?

AccessToken은 그 이름과 같이 접근에 사용되는 JWT 토큰이다.

AccessToken은 로그인 시에 서버에서 클라이언트에게 인증/인가의 수단으로 발급하며
클라이언트는 이 AccessToken을 사용하여 서버에 자신의 권한 증명을 포함한 요청을 보낼 수 있다.

유효 시간(exp)

AccessToken의 유효시간은 보통 10분~1시간 정도로 굉장히 짧게 주어지는 편이다.

위에서 말했듯이 AccessToken은 회원의 인증/인가이다.

때문에 이 AccessToken이 공격자에게 탈취당한다면 문제가 발생한다.

HTTP는 무상태성(Stateless)이라는 특징이 있기 때문에 JWT를 한 번 발급하게 되면

누구에게 어떤 엑세스 토큰을 발급했는지에 대한 정보를 가지고 있지 않는다.

그래서 서버에서 발급한 올바른 형태의 JWT만 포함하여 요청을 보내면 공격자든, 진짜 회원이든 응답 결과를 내려준다.

이러한 문제가 있기 때문에 AccessToken은 짧은 유효시간을 갖는다.

RefreshToken 이란?

RefreshToken은 AccessToken을 갱신하기 위해 사용되는 JWT 토큰이다.

위에서 말했듯이 AccessToken은 굉장히 짧은 생명주기를 갖는다.

그런 AccessToken만을 통해 회원이 서비스를 사용하게 된다면, 짧은 주기마다 재로그인을 해야하고

그렇게 된다면 보안성은 향상되겠지만, 유저경험(UX)는 그닥 좋지 않은 서비스가 만들어질 것이다.

이러한 문제를 해결하기 위해 AccessToken을 갱신하는 목적을 가진 JWT 토큰인 RefreshToken 이라는 개념이 생겨나게 되었다.

RefreshToken을 사용하면 만료된 AccessToken을 갱신하여

재로그인 없이 계속해서 인증/인가를 할 수 있으며,

AccessToken의 유효시간을 짧게 설정하는 것에 의해 유저경험이 떨어지는 문제를 고려하지 않아도 된다.

JWT 방식 동작 플로우

JWT는 정답이 없다고 할 정도로 다양하게 사용할 수 있는데

이번에 설명할 플로우는 다양한 방법 중 하나이니 이 점을 참고하자.

1. 클라이언트는 서버에 로그인 요청을 보낸다.

2. 로그인에 성공하면 서버는 클라이언트에게 AccessToken & RefreshToken을 발급한다.

3. 클라이언트는 발급받은 AccessToken을 HTTP Header에 담아 인증/인가가 필요한 API를 요청할 수 있다.

보통 JWT 토큰은 Authorization 헤더의 값으로 담아 보내며,

Token값의 앞에 'Bearer ' 라는 Prefix를 붙여서 사용한다.

Ex) Authorization: Bearer AccessToken

4. AccessToken이 만료된다.

5. 클라이언트가 AccessToken을 HTTP Header에 담아 인증/인가가 필요한 API를 요청한다.

6. 서버는 AccessToken이 만료되었음을 확인하고 AccessToken가 만료되었다고 Response한다.

7. 클라이언트는 RefreshToken, AccessToken을 Body에 담고, 서버에 토큰 갱신 요청을 보내 만료된 AccessToken을 갱신한다.

이때 RefreshToken을 함께 갱신해주는 방법도 있고, AccessToken만 갱신하는 방법도 있고 다양한 방식이 있다.

이번 글에서 다룰 내용은 후자이다.

"RefreshToken은 어떻게 전달해야할까?"

AccessToken은 Authorization 헤더에 담는데 RefreshToken은 어떻게 담아보낼지 고민하다가
토큰 갱신을 위해 RefreshToken, AccessToken을 함께 보낼때는 Header가 아니라,
Http Body에 담아서 보내기로 하였다.

RefreshToken 만료 시, 동작 플로우

이번에 다룰 방식은 토큰 갱신 시점에 AccessToken만을 갱신하기 때문에

RefreshToken이 만료되면 유저가 로그아웃되고 재로그인을 하는 방식으로 설계해보았다고 했다.

그럼 RefreshToken이 만료되면 어떤 플로우로 동작하는 지에 대해 알아보자.

1. RefreshToken이 만료되고, 그 이후에 AccessToken 도 만료된다.

2. 클라이언트는 RefreshToken, AccessToken을 Body에 담고, 서버에 토큰 갱신 요청을 보내 만료된 AccessToken을 갱신한다.

3. 서버는 RefreshToken이 만료되어 토큰 갱신이 불가능하다는 Response를 전달한다.

4. 클라이언트는 유저를 '로그아웃' 시킨다.

5. 로그아웃된 유저가 재로그인을 시도하면 클라이언트는 서버에 로그인 요청을 보낸다.

6. 로그인에 성공하면 서버는 클라이언트에게 AccessToken & RefreshToken을 발급한다.

결론

이번 포스팅에서는 JWT란 무엇인지, 그리고 JWT를 다루는 하나의 플로우에 대해서 학습해보았다.

JWT를 다루는 플로우는 정말 다양하며, 이번에 소개한 방식은 정말 기초적인 방식 중 하나라고 생각한다.

탈취에 취약한 JWT를 안전하게 사용하기 위해

토큰 갱신마다 RefreshToken을 함께 갱신시키며 DB에서 RefreshToken을 관리하는
RTR(Refresh Token Rotation) 방식도 존재하며,

JWT를 탈취당하지 않기 위한 다양한 보안적인 요소들도 존재한다.

탈취에 취약한 JWT를 사용하려면, 안전하게 토큰을 다루기 위한 여러 요소들을 학습하는 것은 필수라고 생각한다.

이 포스팅으로 JWT 이해를 마치기보단 고민과 탐색과정을 더하여

JWT를 안전하게 다루는 방법을 생각하고 적용하여 안전한 통신 환경을 구축하시길 바란다.

현재 JWT 관련 로직의 성능/보안과 관련하여

RTR 방식 + Redis에서 RefreshToken을 다루는 이유에 대한 포스팅을 작성해두었으니,

더 자세히 학습하고 싶은 분들은 참고하길 바란다.

[인증/인가] RefreshToken은 왜 Redis를 사용해 관리할까? (with. RTR 방식)

1. “왜?” 우리는 MySQL과 같은 일반 DB를 다룰 줄 아는데 사람들은왜 굳이 리프레시 토큰을 Redis에 저장하여 사용하는지 이유가 궁금했으며,왜 다들 Redis를 사용해서 리프레시 토큰을 저장하는

pgmjun.tistory.com

Bucket4j를 사용해서 스프링부트 트래픽 제한하기

PgmJUN — Tue, 18 Jun 2024 18:05:42 +0900

트래픽 제한을 고려하게 된 이유

트래픽 제한에 대한 고민은 gpt-3.5-turbo 모델을 Fine-Tuning하여 사용하는 졸업작품 코리를 개발하면서 시작되었다.

코리는 초기 유저들을 모으기 위해 한동안은 유료인 GPT API 사용 비용을 운영측에서 부담하는 구조로 운영하게 되었고, 아직은 BM(Business Model)이 딱히 존재하지 않았기 때문에 당장은 손해로 지어질 수 밖에 없는 구조였다.

결론적으로 사용자들의 GPT 모델 사용 비용을 운영 측에서 부담하게 되었으니, 유저들의 요청 횟수에 제한을 두어야한다는 생각이 들게 되었다.

Java/SpringBoot 환경에서 트래픽 제한 구현하기

토큰 형태의 트래픽 제한 라이브러리 Bucket4j

회원들의 트래픽을 제한할 수 있는 방법을 찾던 와중에 Bucket4j라는 라이브러리를 발견하게 되었다.

Token Bucket 알고리즘이 적용된 해당 라이브러리는 회원마다 일정 개수의 Token이 담긴 Bucket을 쥐어주고 Token을 사용하여 요청을 보낼 수 있도록 해준다.
만약 Bucket에 Token이 존재하지 않는다면 429 Too Many Requests를 return 하여 요청을 제한할 수 있다.
유저의 Bucket에 Token이 존재한다면 토큰을 사용하고 요청을 수행한다.
Bucket에 담긴 Token은 설정한 시간마다 설정한 갯수만큼 충전된다.

환경

Java 17
SpringBoot 3.0.6

의존성 추가

// Bucket4j
implementation group: 'com.github.vladimir-bukhtoyarov', name: 'bucket4j-core', version: '7.0.0'

RateLimitBucketProvider

@Component
@RequiredArgsConstructor
public class RateLimitBucketProvider {
    private Map<Long, Bucket> buckets = new ConcurrentHashMap<>();

    public Bucket getBucket(Member member) {
        long memberId = member.getId();
        if (!buckets.containsKey(memberId)) {
            Bucket memberBucket = createBucketByRole(member.getRole());
            buckets.put(memberId, memberBucket);

            return memberBucket;
        }
        return buckets.get(memberId);
    }

    private Bucket createBucketByRole(MemberRole role) {
        Bandwidth memberLimit = BucketPlan.findByMemberRole(role);
        return Bucket.builder()
                .addLimit(memberLimit)
                .build();
    }
}

회원의 id를 통해 Map에서 userId에 적합한 Bucket을 찾아 return해주는 객체이다.

만약 id에 해당하는 Bucket이 존재하지 않는다면 유저의 권한을 담은 객체인 MemberRole에 따라 Bucket을 생성하여 return해준다.

concurrentHashMap을 통한 유저 Bucket 관리

버킷에 대한 정보는 메모리 내에서 Key(UserId), Value(Bucket) 기반의 ConcurrentHashMap에서 관리하도록 하였다.

처음 구현할 때는, 일반적인 HashMap을 사용하였는데 ConcurrentHashMap을 사용하면 Thread Safety하게 데이터에 접근 및 제어가 가능했기 때문에 변경하였다.

왜 ConcurrentHashMap을 사용했을까?

ConcurrentHashMap은 HashMap의 멀티스레드 환경에서의 안전한 버전이다.

Map 내에 있는 하나의 데이터에 대해 두 Thread에서 동시에 수정 요청을 보내면 먼저 요청한 측에 Lock을 주고 수정이 끝나면 Lock을 반환, 그리고 그 다음 순서로 요청을 보낸 측에서 Lock을 흭득하고 데이터를 수정을 하는 방식으로 동시에 데이터가 수정되어 문제가 발생되는 일을 방지한다.

또한 읽기 연산에서 Lock을 사용하지 않기 때문에 여러 쓰레드에서 동시에 읽기 연산이 가능하여 읽기 연산이 많은 환경의 경우 성능 향상을 기대할 수 있다.

Map의 데이터를 수정할 일이 많진 않아 처음 말한 이점이 적용되어 이점을 얻을 일은 많이 없겠지만, 유저가 로직을 보낼 때마다 Map에서 Bucket 정보를 읽어와야 해야하기 때문에 읽기 연산이 많은 환경이라고 판단이 되었고, 때문에 읽기에 대한 Lock이 걸리지 않는 다는 점이 성능 향상에 도움을 줄 수 있을 것이라고 생각되어 ConcurrentHashMap을 적용하였다.

BucketPlan

public enum BucketPlan {
    // 총 5개의 토큰, 1분마다 5개의 토큰 충전
    MEMBER {
        public Bandwidth getLimit() {
            return Bandwidth.classic(5, Refill.intervally(5, Duration.ofMinutes(1)));
        }
    };

    public abstract Bandwidth getLimit();

    public static Bandwidth findByMemberRole(MemberRole memberRole) {
        return Arrays.stream(values())
                .filter(v -> v.name().equals(memberRole.name()))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException(ErrorCode.NOT_EXIST_MEMBER_ROLE))
                .getLimit();
    }
}

BucketPlan객체는 회원에 권한에 다른 버킷/토큰 정보를 담고 있는 Enum객체이다.

MemberRole과 똑같이 BucketPlan Enum의 열거 상수명을 네이밍하여, MemberRole을 통해 Role에 따른 버킷을 조회할 수 있도록 하였다.

Bandwidth

enum에 담겨있는 Bandwidth는 버킷에 대한 설정 객체이며, 다음과 같이 2가지 매개변수를 가진다.

Bucket이 가질 수 있는 최대 토큰 개수
Token Refill 규칙

현재 설정을 통해 role이 MEMBER이면 최대 5개의 토큰을 가질 수 있으며, 1분마다 5개의 토큰이 채워진다는 것을 알 수 있다.

RateLimitFilter

@Component
@Slf4j
@RequiredArgsConstructor
public class RateLimitFilter implements Filter {
    private final JwtUtils jwtUtils;
    private final RateLimitBucketProvider bucketProvider;
    private final MemberRepository memberRepository;

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String authorizationHeader = httpRequest.getHeader("Authorization");

        // authorizationHeader가 없는 경우 Filter 동작 생략
        if(authorizationHeader == null || !authorizationHeader.startsWith("Bearer ")) {
            chain.doFilter(request, response);
            return;
        }

        //authorizationHeader가 있는 경우 JWT AccessToken이 정상적인 경우 token을 사용
        String accessToken = authorizationHeader.substring("Bearer ".length());
        if (jwtUtils.validateToken(accessToken)) {
            Long memberId = jwtUtils.getMemberIdFromJwt(accessToken);
            Member member = MemberServiceUtils.findMemberById(memberRepository, memberId);
            //관리자 계정이면 Token 사용X
            if(member.getRole() == MemberRole.ADMIN) {
                log.info("MemberRole이 ADMIN이기 때문에 토큰이 소모되지 않았습니다.");
                chain.doFilter(request, response);
                return;
            }

            Bucket memberBucket = bucketProvider.getBucket(member);
            if (!memberBucket.tryConsume(1)) {
                log.error(String.format("회원ID(%d)의 잔여 토큰이 존재하지 않습니다.", memberId));
                throw new RateLimitException(ErrorCode.TOKEN_NOT_EXIST_EXCEPTION);
            }
            log.info(String.format("회원ID(%d)의 토큰 사용 : 잔여 토큰(%d)", memberId, memberBucket.getAvailableTokens()));
        }

        chain.doFilter(request, response);
    }
}

해당 클래스가 지금까지 만든 버킷 로직을 통해 트래픽 제한을 적용시켜줄 Filter이며, Filter 인터페이스를 implements 하여 구현할 수 있다.

들어온 요청에 대해 Authorization Header를 검사하여 만약 Header가 존재하지 않으면 doFilter를 통해 다음 필터로 요청을 넘긴다.

권한에 대한 검사는 이후 Intercepter에서 처리하도록 구현했기 때문에 여기서는 넘겨도 괜찮다.

만약 Authorization 헤더가 존재하면 Authorization 헤더에 담겨있는 JWT 토큰을 검사 후, 토큰을 통해 memberId를 흭득하여 member에 대한 정보를 얻는다.

여기서 만약 관리자 권한(ADMIN)의 유저이면 토큰을 사용하지 않는다.

그리고 bucketProvider를 통해 Bucket을 흭득하여 토큰을 소모하고 다음 Filter로 요청을 전달하는데, 사용 가능한 token이 존재하지 않으면 잔여 토큰이 존재하지 않는다는 예외를 발생시킨다.

ExceptionHandlerFilter

@Component
@Order(Integer.MIN_VALUE)
@Slf4j
public class ExceptionHandlerFilter implements Filter {
    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        try {
            chain.doFilter(request, response);
        } catch (RateLimitException | IllegalArgumentException exception) {
            setErrorResponse((HttpServletResponse) response, exception);
        }
    }

    private void setErrorResponse(HttpServletResponse response, CustomException exception) throws IOException {
        ApiResponse<Object> errorResponse = ApiResponse.error(exception.getErrorCode());

        response.getWriter().write(objectMapper.writeValueAsString(errorResponse));
        response.setContentType(MediaType.APPLICATION_JSON_VALUE);
        response.setStatus(exception.getErrorCode().getHttpStatusCode());
    }
}

보통 Rest API 서버를 개발할 때 예외를 핸들링은 @RestControllerAdvice 애노테이션을 적용한 ExceptionController를 개발하여 수행한다.

하지만 @RestControllerAdvice 애노테이션을 통해 캐치할 수 있는 예외는 컨트롤러 단에서 발생한 예외뿐이다. Filter는 DispatcherServlet에 요청이 도달하기 전 실행되는 영역이므로 ExceptionController에서 처리가 불가능하다.

때문에 Filter에서 발생한 예외처리를 담당하는 ExceptionHandlerFilter를 작성해주었다.

@Order 애노테이션을 통한 Filter를 최상단에 위치시키기

해당 필터를 최상단에 위치시키고 try/catch 를 통해 다음 필터들에서 발생하는 예외를 캐치하도록 하였다.

그리고 캐치된 예외는 setErrorResponse메서드를 통해 response되어 사용자에게 전달되도록 구현하였다.

작동 결과

유저가 1분 내에 5번 연속으로 API를 호출하자 예측한대로 429 Too Many Requests가 발생하여 23ms라는 빠른 속도로 요청을 거부하였다.

성능 개선

사람들마다 구현하는 방식이 다르겠지만 본인은 SpringBoot의 Filter단에서 요청에 대한 Token 개수를 검사하도록 구현하였다.

처음에 인터넷에서 찾은 예시에는 Interceptor에서 토큰 개수 검사를 수행하도록 구현하고 있었고 본인도 처음에는 그 예제를 따라 코드를 작성했다.

하지만 현재 프로젝트는 전체적인 트래픽 조절을 위해 모든 API에 대해서 토큰 검사를 수행하고 있기 때문에 Handler의 정보가 필요하지 않았고 때문에 Interceptor가 아닌, Filter에서 검사해야 불필요한 Controller Mapping등의 작업을 수행하지 않기 때문에 성능 면에서 가장 최적화된 방법이라고 생각했다.

개선 결과

실제로 비교를 해본 결과 예측한대로 Filter와 Interceptor의 차이는 386msec만큼 차이가 났다. 작은 수 같지만 이런 작은 차이가 쌓여 성능을 낮추기 때문에, 이런 것들을 하나하나 줄여나가는 것이 개발의 재미이자 덕목이라고 생각한다.

✅ 만약 이후에 모든 API가 아닌 특정 API에 대해서만 요청을 제한하도록 변경한다면 다시 Interceptor에서 토큰 검사를 수행하거나, 다른 방안을 생각해볼 것이다.

[우아한테크코스 6기] 테코톡 - 방어적 복사

PgmJUN — Mon, 17 Jun 2024 11:40:42 +0900

안녕하세요. 이번에 방어적 복사를 주제로 찍은 테코톡이 유튜브에 올라와서 공유드립니다:)
관련 지식 얻고싶으신 분들은 참고하시면 좋을 것 같아요!

질문은 언제나 대환영입니다! 편하게 물어보세요.

스프링부트에 Nginx 리버스 프록시(Reverse Proxy) 서버 연결하기

PgmJUN — Mon, 20 May 2024 01:24:27 +0900

리버스 프록시를 도입하게된 계기

졸업작품인 코리(Co:RE)의 서버를 개발하면서 실제로 배포를 위한 환경을 만들려고 하다보니,

보안적인 요소를 생각하지 않을 수 없었다.

1차적으로 생각이 난 부분은 당시 학습하고 있었던 프록시 서버였다.

프록시 서버에 대해 모르는 사람은 해당 포스팅을 참고해주세요!

리버스 프록시 서버를 적용하면 보안상 이점과 여러 장점들을 얻을 수 있는데,

그 중 내가 생각한 장점은 아래와 같았다.

⚙️ 보안

개발자 도구에 WAS의 주소가 그대로 노출되어 다양한 공격의 가능성이 발생한다.

여기에 리버스 프록시를 적용하게 되면 서버를 직접 노출시키지 않고 클라이언트와의 통신을 중계하므로 서버의 실제 위치를 숨기고 보안을 강화할 수 있다.

프록시 서버로 인해 본래 서버의 IP 주소를 노출시키지 않을 수 있어, 해커들의 DDos 공격과 같은 공격을 막는데 용이하다.

⚙️ 로드 밸런싱

리버스 프록시는 여러 서버로 요청을 분산할 수 있으며, 부하 분산을 구현할 수 있다.

추후 서버를 Scale Out 했을 때 Load Balancing 기능까지 수행할 수 있다.

이는 트래픽이 여러 서버에 고르게 분산되어 서버의 성능을 향상시키고 가용성을 높이는 데 도움이 된다.

작업 환경

• AWS EC2 't2.micro'
• 'ubuntu 22.04' AMI
• `Nginx 1.18.0`

생략 과정 ✂️

• AWS 계정 생성
• EC2 생성 (Ubuntu 22.04 AMI 사용)
• 보안규칙 설정
• HTTP 80번 포트에 대해 IPv4, IPv6 허용
• HTTPS 443번 포트에 대해 IPv4, IPv6 허용
• SSH 22번 포트 IPv4 허용
• 볼륨 크기는 EC2 프리티어에서 사용할 수 있는 최댓값인 27GiB 설정
• 스프링부트 서버가 죽지 않도록 `Swap Memory` 설정하여 `t2.micro` 환경에서 3GB의 메모리 흭득

Nginx Reverse Proxy 설정 방법 ⚙️

Shell 명령

# apt-get 업데이트
sudo apt-get update

# Nginx 설치
sudo apt-get install nginx
sudo service start nginx

# nginx Config 파일 열기
sudo vi /etc/nginx/site-available/default

# http 설정 바로 아래에 server 설정을 추가하여 리버스 프록시 설정(사용하지 않는 주석 전부 제거)

/etc/nginx/site-available/default 설정

http {
        server {
                listen 80; # 포트를 필요에 따라 조정하세요.
                #server_name your_domain.com; # 도메인 이름 대신 IP 주소를 사용할 경우 필요 없습니다.

                location / {
                        proxy_pass http://서버_주소:포트; # 백엔드 서버의 IP 주소
						proxy_http_version 1.1;

                        proxy_set_header Connection ""; #504 Bad GateWay 문제 방지
                        proxy_set_header Host $host;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                }
        }

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
}

⚙️ proxy_set_header Host $host;

이 헤더는 원격 서버로 전달되는 HTTP 요청 헤더 중 하나이다.
`$host` 변수는 클라이언트가 요청한 호스트 헤더 값을 가지고 있다.

호스트 이름은 일반적으로 `도메인 이름`이나 `IP 주소`인데,
이를 통해 리버스 프록시는 요청을 받은 원격 서버에게 어디로부터 온 요청인지 알려준다.

⚙️ proxy_set_header X-Real-IP $remote_addr;

이 헤더는 `클라이언트의 실제 IP 주소`를 리버스 프록시를 통해 전달한다.
이것은 원격 서버가 클라이언트의 실제 IP를 알고자 할 때 사용된다.

⚙️ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

일반적으로 HTTP 요청에는 `X-Forwarded-For` 헤더가 포함되어 있다.
이 헤더는 `클라이언트`가 `어떤 IP 주소를 통해 요청을 보냈는지`를 기록하며, 여러 프록시 서버를 거친 경우 쉼표로 구분된 목록으로 기록된다.

Nginx에서 `$proxy_add_x_forwarded_for` 변수는 이 `X-Forwarded-For` 헤더의 값을 가져와 저장한다.
이를 통해 서버는 실제 클라이언트의 IP 주소를 파악할 수 있다.

예를 들어, 클라이언트 A에서 요청이 오고, 그 요청이 Nginx 프록시 서버 를 거쳐 백엔드 서버로 전달되면,
X-Forwarded-For 헤더에는 "A, Nginx_IP" 와 같이 표시된다.

이때 $proxy_add_x_forwarded_for 변수에는 "A, Nginx_IP"와 같은 값이 저장된다.

연결 완료 ✅

`Nginx` EC2의 IP에 `80번 포트`로 접속했는데 `SpringBoot` EC2의 IP에 `8080번 포트`로 접속한 것과 동일한 화면이 출력되는 것을 확인할 수 있다.

또한 `SpringBoot`의 포트인 `8080`번으로 접속하면, 접속할 수 없는 것을 알 수 있다.

이는 우리가 `AWS의 EC2 보안 그룹의 인바운드 규칙`에서 `8080번` 포트를 외부에서 접속하지 가능하도록 설정해주지 않았기 때문이다.
위와 같은 설정들을 통해 무조건 `리버스 프록시`를 거쳐서 접속할 수 있게 된 것이다.

추후 프로젝트 개선 방향

`WAS`에 대한 접근과 정보 노출을 방어했지만 아직 `Nginx`를 통해서 요청하면 `WAS`에 요청하는 것과 똑같이 요청하여 데이터를 흭득할 수 있다. 그렇기에 고의적으로 `리버스 프록시 서버`에 많은 요청을 보내게 되면, 그대로 받아들여 서버에 과부하가 오게 된다.
또한 지금 개발하고 있는 서비스 `Co:RE`는 유저들이 운영 측의 `GPT API Key`를 사용하여 무료로 응답값을 얻는 형식이다. 때문에 더더욱 많은 고의적인 요청이 보내지면 금전적으로 큰 손해를 볼 수 밖에 없다
- 이에 대한 결론으로 다음 개발 과제는 `과도한 트래픽에 대한 방어`로 잡았다.
- `Bucket4j` 라이브러리를 사용하면 Token-Bucket 알고리즘을 통해
  유저들에게 API를 요청할 수 있는 `Token`을 주고 Token의 `사용 시간` 또는 `사용 횟수`에 제한을 걸어,
  고의적인 요청을 방어할 수 있다고 한다.
  때문에 이를 공부하여 적용해보고자 한다.

프록시(Proxy) 서버란?

PgmJUN — Sun, 19 May 2024 23:26:06 +0900

프록시 서버란?

`Proxy`라는 단어는 대리(행위)나 대리권, 대리 투표, 대리인 등을 뜻하며 말 그대로 서버 요청에 대한 대리자 역할을 수행하는 것을

프록시 서버 라고 한다.

프록시 서버(Proxy Server) 는 클라이언트와 서버 사이에서 동작하는 중간 서버를 의미한다.

클라이언트가 서버에 직접 요청을 보내는 대신 `프록시 서버`는 클라이언트 요청을 받아 서버로 전달하고,

서버에서 받은 응답을 클라이언트에게 다시 전달하는 중계자 역할을 한다.

프록시 서버의 종류 ⚙️

프록시 서버는 아래와 같이는 2가지 형태가 있다.

포워드 프록시(Forward Proxy)

`클라이언트`와 `인터넷` 사이에 있는 프록시 서버를 뜻한다.
`포워드 프록시`는 클라이언트의 익명성을 보장한다.
- 클라이언트의 요청을 가로채 통신을 대리 수행해준다.
- 때문에 `WAS`는 `클라이언트`에 대해 알 수 없다. IP 역추적을 해도 프록시 서버의 IP만 보인다.
클라이언트가 요청한 내용을 캐싱한다.
- 연결된 클라이언트가 요청한 데이터를 반환할 때 저장했다가 다른 클라이언트가 동일한 데이터를 요청하면 인터넷을 거치지 않고 바로 반환해준다.
- 전송 시간이 절약되고 외부 요청이 감소되어 네트워크 병목 현상을 방지한다.

포워드 프록시는 요청을 보내는 `클라이언트 측`에 설정해두는 프록시 서버로,
클라이언트에서 특정 서버로 요청을 보내기 전에 프록시를 거쳐서 요청을 전송하는 것이다.
즉, 클라이언트가 아닌 프록시 서버의 입장에서 요청을 보내 익명성을 보장할 수 있는 것이다.

자세한 내용과 Nginx를 통한 설정 방법은 아래 참고 자료를 통해 확인해보길 바란다.

[참고자료]

[Nginx 포워드 프록시 사용법1](https://recordsoflife.tistory.com/m/924)
[Nginx 포워드 프록시 사용법2](https://earth-95.tistory.com/m/138)
[Nginx 포워드 프록시와 리버스 프록시](https://medium.com/humanscape-tech/nginx%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-forward-proxy-%EA%B5%AC%ED%98%84-91f3555549be)

리버스 프록시(Reverse Proxy)

리버스 프록시는 대표적으로 로드 밸런싱(Load Balancing)에 사용된다.
- 리버스 프록시를 2개 이상의 서버 앞에 두면 대용량 요청이 들어왔을 때 서버가 과부화 되지않도록
  프록시 단에서 `로드 밸런싱`이 가능하다.
서버의 정보를 숨겨 보안성을 얻는다.
- 클라이언트는 `리버스 프록시`이 진짜 서버인 것처럼 요청을 보내게 되기 때문에 클라이언트는 서버의 정체를 알 수 없어 보안성이 좋다.
- 본인은 AWS EC2에서 서버들을 관리하기 때문에 인바운드 보안 규칙 설정을 통해
  Reverse Proxy Server를 거쳐서만 WAS에 접근할 수 있도록 설정하여 보안성을 더욱 개선 하였다.
클라이언트가 요청한 내용을 캐싱한다.
- Forward Proxy와 동일하지만 이미 프록시 서버가 캐싱하여 알고 있는 내용도 인터넷을 거친다는 차이가 있어
  Forward Proxy가 캐싱된 데이터를 조금 더 빠르게 전송하는 것으로 이해했다.

리버스 프록시는 요청을 받는 `서버 측`에 설정해두는 프록시 서버로,
WAS에 요청이 도달하기 전에 프록시를 거치게 되는 것이다.

이는 WAS가 직접 요청을 받는 것이 아니라 프록시 서버가 WAS의 앞단에서 요청을 대신 전달받는 것이기 때문에 WAS의 `익명성`을 보장할 수 있는 것이다.

정리

내가 이해한 바를 정리해보면

`포워드 프록시`는 `클라이언트의 정보를 보호`하는 것에 효과적이며
`리버스 프록시`는 `서버의 정보를 보호`하는 것에 효과적이다.

다음 포스팅에서는 직접 Nginx를 통해 리버스 프록시 서버를 만드는 과정을 진행해보겠다 :)

[길벗 리뷰어] 현직 LINE 개발자가 알려주는 읽기 쉽고 코드 리뷰하기 좋은 코드 작성 가이드 리뷰

PgmJUN — Sun, 19 May 2024 21:51:08 +0900

최근 길벗에서 "읽기 쉽고 코드 리뷰하기 좋은 코드 작성 가이드"라는 책 리뷰어를 구하는 것을 보고 고민없이 지원하여 읽게 되었다.

한참 읽기 쉽고 리뷰하기 좋은 코드에 대해 고민하고 있던 나에게 정말 절실한 책이었다.

이 책을 받기 전, 서적을 판매하는 각종 사이트에 들어가 해당 책에 대한 리뷰를 확인하였는데, 대부분의 리뷰가 만점일 정도로 좋은 책이었다.

실제로 받아본 이 책은 현직 LINE 개발자들의 실제 경험을 바탕으로 작성된 이 책은 실용적인 조언과 유용한 팁으로 가득 차 있었고

본인도 이 책 덕분에 소프트웨어 개발 능력을 한 단계 끌어올리는 데 도움이 받을 수 있었다.

보통 해외에서 작성되어 번역본으로 출판된 개발 서적들은 번역본이 어색해서 이해하기 어려운 내용들이 많다.

이 책도 국내 개발자분이 아니라 일본 LINE 개발자분이 작성하신 책이라 사실 조금은 걱정이 되었다.

하지만 일본어의 문법과 한국어의 문법이 비슷해서 번역본도 그리 어색하지 않았다. 편하게 읽었던 것 같다.

주요 내용

주요 내용을 살펴보자면 아래와 같았다.

코딩 스타일, 클린 코드 원칙, 리팩토링, 테스트 작성, 코드 리뷰, 도구 및 설정 등 여섯 가지 주제로 나뉘어 있는 책이었고

각 장은 구체적인 예시로 설명되어 있어 이해하기 쉽고 내 코드 작성에 직접 적용할 수 있었다.

본인은 그 중 이 2가지 주제가 가장 도움이 되었던 것 같다.

테스트 작성: 유닛 테스트, 통합 테스트 등 다양한 테스팅 접근 방식과 효과적인 테스트 코드 작성 방법을 설명한다.

코드 리뷰: 효과적인 코드 리뷰 방법, 코드 리뷰의 이점, 리뷰를 잘 받는 팁 등을 다룬다.

테스트를 작성하다보면 세팅을 위한 부수적인 코드가 늘어나 테스트 코드의 가독성을 향상시켜야겠다는 필요성을 느끼고 있었는데, 마침 해당 책에서 도움을 받을 수 있었다.

또한 현재 코드 리뷰를 정말 많이 주고받고 있는 만큼 효과적인 코드 리뷰 방식을 잡아가고 싶었는데 이 또한 책에서 주로 다루는 내용이었기에 많이 도움을 받았다.

결론

이 책을 읽은 후, 좋은 코드와 좋은 코드 리뷰 문화를 조성하기 위해 책에서 좋다고 느낀 부분들을 계속 흝어보며 노력하고 있다.

또한, 철저한 테스트 코드 작성에 더 많은 기존 코드의 품질을 리팩토링을 통해 향상시키고 있다.

앞으로도 이 책에서 제공하고 있는 지식들을 꾸준히 습득해나가며 어제보다 더 나은 내가 되기 위해 계속 노력할 것이다.

[Git] Github 협업 이것만은 알자!

PgmJUN — Sat, 13 Apr 2024 23:11:10 +0900

벨로그에 연재하고 있는 깃허브 협업에 대한 기초 지식을 쌓을 수 있는 시리즈입니다!

필요하시면 참고하세요 :)

시리즈 | Github 협업, 이것만은 알자 - pgmjun.log

이슈(Issue)란 프로젝트에서 작업해야할 단위라고 할 수 있습니다.개발해야하는 기능 발생, 수정해야할 사항 버그 발생, 리팩터링 해야하는 코드 발생 등 프로젝트에서 발생되는 작업들을 이슈로

velog.io

@PostConstruct, Static Block, Instance Block 초기화 시점 차이

PgmJUN — Sat, 13 Apr 2024 15:36:44 +0900

자바 스프링 기술로 개발을 해봤다면 @PostConstruct 과 Static block, Instance block 을 사용해본 경험이 있을 것이다.

이는 객체 초기화를 위한 콜백(callback) 함수를 선언하기 위한 기술이다.

콜백(Callback) 함수란?

콜백 함수는 다음과 같은 의미를 가진다.

다른 함수 인자로서 사용되는 함수
어떠한 이벤트에 의해 호출되는 함수

이 글에서의 설명은 2번째 의미인 '어떠한 이벤트에 의해 호출되는 함수' 에 가깝다.

본인또한 이 3가지를 종종 다루긴 했지만,

@PostConstruct 와 Static block 중 어떤 것을 사용할 지 고민하던 중
이 두 가지의 초기화 시점 차이에 대해 정확히 인지하지 못한 채로 사용하고 있었다는 것을 깨닫게 되었다.

때문에 이를 공부하며 정리해보고자, 관련 내용에 대한 포스팅을 작성하게 되었다.

Static Block

static 키워드로 선언된 블록이며, 클래스가 처음으로 메서드(Method) 영역에 로드될 때 실행된다.
클래스 로딩 시 한 번만 실행되며, 클래스 변수(static 변수)의 초기화나 클래스 수준의 작업을 수행할 수 있다.
일반적으로 클래스 변수의 초기화에 사용된다.
여러 개의 static 블록이 있다면, 선언된 순서대로 실행된다.

public class MyClass {
    static {
        // static block
        // 클래스가 로드될 때 실행됩니다.
        // 클래스 변수의 초기화 등에 사용됩니다.
    }
}

Instance Block

객체의인스턴스를 생성할 때마다 실행되는 블록이다.
각 인스턴스마다 초기화 작업을 할 수 있다.
생성자가 호출되기 전에 실행된다.

public class MyClass {
    {
        // instance block
        // 인스턴스를 생성할 때마다 실행됩니다.
        // 생성자가 호출되기 전에 실행됩니다.
    }
}

@PostConstruct

Spring 프레임워크에서 사용되는 어노테이션으로, 객체의 Bean 생성 및 DI(Dependency Injection) 후에 호출된다.
주로 Spring Bean의 초기화 작업에 사용되며, Spring Bean의 생명주기 콜백 메서드를 정의하기 위해 사용된다.
해당 객체의 모든 의존성이 주입된 후 호출된다.
@PostConstruct와 반대로 스프링 빈이 소멸되기 직전에 호출되는 @PreDestroy 라는 애노테이션도 존재한다.

public class MyClass {
    @PostConstruct
    void init() {
        // @PostConstruct annotated method
        // 객체 생성 및 의존성 주입 후 호출됩니다.
        // 주로 초기화 작업에 사용됩니다.
    }
}

정리

Static Block: 클래스가 로드될 때 실행되며, 한 번만 실행
Instance Block: 인스턴스가 생성될 때마다 실행되며, 생성자 호출 전에 실행
@PostConstruct: Spring Bean의 초기화 작업에 사용되며, 의존성 주입 후 호출

흐름에 따른, 각 콜백 함수 호출 시점

(Static Block 호출) -> 스프링 컨테이너 생성 -> 스프링 빈 생성(Instance Block 호출) -> 의존관계 주입 -> 초기화 콜백(@PostConstruct 호출) -> 빈 사용 -> 소멸전 콜백(@PreDestroy 호출) -> 스프링 종료

본인은 @PostConstruct와 Static Block의 차이가 크지 않을 줄 알았으나 이번 계기를 통해 내용을 정리하게 되면서

@PostConstruct는 클래스 로딩 시점에 사용되는 Static Block과는 별개로, 스프링 빈의 생명주기와 관련된 기술임을 깨닫게 되었다.

보통 객체 초기화 콜백 정의는 항상 @PostConstruct를 사용하곤 했는데, 앞으로는 상황에 맞게 사용할 수 있는 지식이 쌓인 것 같다고 느껴졌다.

혹시라도 정리된 내용 중 잘못 설명된 내용이 있다면 댓글 부탁드립니다!

의존성 주입 시, 같은 Type의 빈이 2개 이상일 경우

PgmJUN — Sat, 13 Apr 2024 14:29:58 +0900

우리는 스프링을 사용할 때, 생성자 주입을 통해 의존성을 주입하곤 한다.

DiscountPolicy 정적 의존관계

그런데 의존성을 주입하는 경우, 2개의 의존성 중 하나를 주입해야하는 경우가 있을 것이다.

public interface DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
private DiscountPolicy discountPolicy

만약 위와 같이 FixDiscountPolicy와 RateDiscountPolicy가 스프링 빈으로 존재할 때,
다음과 같이 @Autowired를 수행하면 어떻게 될까?

예외 발생

NoUniqueBeanDefinitionException: No qualifying bean of type
 'hello.core.discount.DiscountPolicy' available: expected single matching bean
 but found 2: fixDiscountPolicy,rateDiscountPolicy

결과는 다음과 같이 NoUniqueBeanDefinitionException 예외가 발생할 것이다.

1개의 빈이 매칭되어야 하지만, 2개의 빈이 매칭되었기 때문에 예외가 발생하는 것이다.

@Autowired는 Type으로 빈을 매칭하기 때문에
`applicationContext.getBean(DiscountPolicy.class)` 이렇게 빈을 조회하는 것과 유사하다.

때문에 두 구현체 중에 어떤 것을 선택할 지 스프링이 정하지 못해서 예외가 발생한다.

문제 해결 방안

이에 대한 해결 방안으로 다음 3가지 방식이 존재한다.

@Autowired 필드 명 매칭
@Qualifier 사용
@Primary 사용

1. @Autowired 필드 명 매칭

@Autowired는 타입 매칭을 시도할 때 같은 타입의 빈이 여러 개 존재하면 필드 이름, 파라미터 이름으로 추가 매칭을 시도하는 방식이다.

@Autowired
private DiscountPolicy discountPolicy

이렇게 타입의 이름을 필드 명으로 사용하는 대신

@Autowired
private DiscountPolicy rateDiscountPolicy

이렇게 타입의 이름을 필드 명으로 정의하게 되면 동일한 타입의 빈이 2개 이상 있을 경우,
필드 명과 스프링 빈의 이름을 매칭하여 의존성 주입을 할 수 있다.

2. @Qualifier 사용

Qualifier는 '예선의' 라는 뜻으로, 추가 구분자를 붙여주고 의존성 주입 시 어떤 빈을 주입할 지 지정하여
충돌없이 의존성 주입을 수행할 수 있는 방식이다.

ComponentScan 등록 시 예시

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

다음과 같이 빈 등록 시, @Qualifier 애노테이션과 함께 추가 구분자(이름)를 설정하면 된다.

@Bean 애노테이션을 통한 빈 직접 등록 시 예시

@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
   return new ...
}

@Bean 애노테이션을 통해 빈을 직접 등록하는 경우에도 다음과 같이 @Qualifier 애노테이션을 사용할 수 있다.

사용법

생성자 자동 주입 예시

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

생성자 자동 주입을 하는 경우, 생성자의 파라미터 옆에 @Qualifier 애노테이션과 함께 어떤 이름의 빈을 주입시킬 지 정할 수 있다.

수정자 자동 주입 예시

@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy")
DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

수정자 자동 주입을 하는 경우, 수정자 메서드의 파라미터 옆에 @Qualifier 애노테이션과 함께 어떤 이름의 빈을 주입시킬 지 정할 수 있다.

@Qualifier 구분자를 찾지 못할 경우

만약 @Qualifier("mainDiscountPolicy")를 찾지 못한다면 어떻게 될까?

그렇게 되면 스프링은 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다.

하지만 @Qualifier는 @Qualifier를 찾는 용도로만 사용하는 것이 명확하고 유지보수성과 휴먼에러 방지에 탁월하다.

@Primary 사용

@Primary는 여러 빈이 매칭되는 경우에 우선 순위를 부여할 수 있는 애노테이션이다.

같은 타입의 빈이 여러 개 조회되는 경우, @Primary 애노테이션을 가진 빈이 우선권을 가진다.

사용법

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

사용법은 다음과 같이 우선권을 부여할 빈에 애노테이션을 붙여주면 끝이다.

@Qualifier 를 사용할 경우 해당 애노테이션을 사용하는 모든 생성자 주입 과정에는

@Qualifier 애노테이션을 통해 주입할 빈을 특정해주는 코드를 작성해주어야 하는데

그 방식에 비해 굉장히 간단하고 쉬운 방식이다.

@Primary, @Qualifier 함께 사용하는 방법

만약 서비스가 대체로 사용되는 메인DB와, 가끔 특정 동작을 위해 사용되는 서브DB가 모두 연결되었다고 가정하자.

그럼 서비스는 메인DB의 커넥션을 사용하는 빈과, 서브DB의 커넥션을 사용하는 빈이 따로 존재할 것이다.

이렇게 2개의 빈이 모두 사용되는데 하나는 자주 사용되고, 하나는 가끔 사용되는 경우 @Primary, @Qualifier를 함께 사용함으로써
편리하게 사용이 가능하다.

스프링은 자동 보단 수동이, 넓은 범위의 선택권 보다는 좁은 범위의 선택권이 우선순위가 훨씬 높다.

때문에 @Qualifier 애노테이션 설정이 없는 경우, @Primary로 설정해놓은 빈이 주입될 것이고

@Qualifier를 설정한 경우 해당 설정이 적용될 것이다.

Custom Annotation을 통한 @Qualifier 사용 방식 개선

@Qualifier는 위에서 설명한 예제와 같이 사용하면 정말 편리하게 의존성을 조절하며 개발을 해나갈 수 있다.

하지만 @Qualifier는 한 가지 단점이 존재한다.

컴파일 시점에서 구분자 오류가 잡히지 않음

@Qualifier는 컴파일 시점에서 구분자(이름)이 잘못되었음을 체크하지 못한다.

때문에 런타임에서 예외가 발생하게 된다.

뿐만 아니라 문자열로 이름을 설정해주기 때문에, 이름에 변경이 발생하면 모든 @Qualifier 애노테이션을 찾아다니면서
이름을 변경해주어야 한다.

이러한 문제를 해결해야 @Qualifier를 더욱 안전하게 사용할 수 있을 것 같은데, 어떻게 해결할 수 있을까?

Custom Annotaion 만들기

import org.springframework.beans.factory.annotation.Qualifier;
import java.lang.annotation.*;
 
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {}

위 문제는 직접 커스텀 애노테이션을 만들어 해결책을 제시해볼 수 있다.

커스텀 애노테이션 내부에 정확한 구분자를 설정해놓은 @Qualifier 애노테이션을 추가해놓으면

매번 @Qualifier를 사용할 때마다, 구분자를 문자열로 설정해줄 필요없이 애노테이션만 추가해주면 되어

문자열을 잘못 입력함으로써 발생하는 런타임 오류를 방지할 수 있을 것이다.

뿐만 아니라 구분자가 변경된 경우 해당 애노테이션 내부의 @Qualifier 애노테이션의 구분자만 수정해주면 전체적으로 변경이 발생하기에 관리가 편리해진다.

사용법

생성자 자동 주입 예시

@Autowired
 public OrderServiceImpl(MemberRepository memberRepository,
                         @MainDiscountPolicy DiscountPolicy discountPolicy) {
     this.memberRepository = memberRepository;
     this.discountPolicy = discountPolicy;
}

생성자 자동 주입을 하는 경우, 생성자의 파라미터에 애노테이션을 설정하여 원하는 빈을 주입시킬 수 있다.

수정자 자동 주입 예시

@Autowired
 public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy discountPolicy) {
     this.discountPolicy = discountPolicy;
 }

수정자 자동 주입을 하는 경우, 수정자 메서드의 파라미터에 애노테이션을 설정하여 원하는 빈을 주입시킬 수 있다.

조회한 빈이 모두 필요한 경우 (with. Collection)

개발을 하다보면 같은 타입의 빈이 모두 필요한 경우도 존재할 것이다.

예를 들어서 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자.

스프링을 사용하면 소위 말하는 전략 패턴을 매우 간단하게 구현할 수 있어 이러한 문제에 간편한 해결책을 제시한다.

예제 코드

예제코드를 통해 어떻게 이 문제를 해결할 수 있는 지 알아보자.

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import
org.springframework.context.annotation.AnnotationConfigApplicationContext;
import java.util.List;
import java.util.Map;
import static org.assertj.core.api.Assertions.assertThat;
 
public class AllBeanTest {
    @Test
    void findAllBean() {
        ApplicationContext ac = new
AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000,
"fixDiscountPolicy");

        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
    
    static class DiscountService {
    
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        
        public DiscountService(Map<String, DiscountPolicy> policyMap,
List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }
        
        public int discount(Member member, int price, String discountCode) {
        
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            
            return discountPolicy.discount(member, price);
		}
	}
}

고정 할인 정책(fixDiscountPolicy)은 1000원을 고정으로 할인해주는 전략이다.

우리는 클라이언트로 부터 "fixDiscountPolicy" 라는 discountCode를 입력받은 상태이고,
이에 맞게 고정 할인 정책을 적용해주어야 하는 상황이다.

DiscountService를 살펴보면

Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies 두 개의 필드가 존재하는 것을 알 수 있다.

이 컬렉션들에는 생성자 주입을 통해 무언가가 주입되는데 무엇이 존재되는 것일까?

주입 동작 설명

Map<String, Type>

Map<String,DiscountPolicy> 형태의 필드가 존재하면 스프링은 의존성 주입 시, DiscountPolicy 타입의 빈을 모두 탐색한다.

그리고 Key(String) 에는 discountPolicy 빈의 이름, Value(DiscountPolicy) 에는 빈 객체를 삽입한 Map을 생성하여

의존성을 주입한다.

List<Type>

List<DiscountPolicy> 형태의 필드가 존재한다면 스프링은 의존성 주입 시, DiscountPolicy 타입의 빈을 모두 탐색한다.

그리고 List 내부에 DiscountPolicy 타입의 빈을 모두 담아 의존성을 주입한다.

찾는 타입의 빈이 존재하지 않을 경우

찾는 타입의 빈이 존재하지 않는 경우 빈 컬렉션이 주입된다.

컬렉션 주입 사용 시 주의점!

해당 로직과 같이 Map,List를 통해 다형성을 적극적으로 활용하는 경우 내가 개발한 코드라면 이해하기 쉽겠지만

남이 개발한 로직인 경우,

컬렉션에 어떤 빈들이 주입될 지 단번에 파악하기가 어려울 것이다.

때문에 해당 방식을 사용하는 경우 같은 타입의 빈을 Config 파일에서 수동으로 등록하여 응집도를 높게 관리하거나,

같은 타입의 빈과 다형성 사용 객체를 특정 패키지에 같이 묶어 관리하는 것이 코드의 가독성에 도움이 된다.

컴포넌트 스캔(ComponentScan)

PgmJUN — Fri, 12 Apr 2024 00:56:09 +0900

이전 글을 통해 @Configuration 애노테이션을 통한 스프링 빈 등록에 대해 알아보았다.

[Spring] @Configuration과 싱글톤 (with. CGLIB)

@Configuration public class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService() { return new OrderServiceImpl(memberRepository(), discountPolicy()); } @Bean p

pgmjun.tistory.com

하지만 꼭 빈을 등록할 때, @Configuration, @Bean 애노테이션을 선언해야만 할까?

그렇지 않다.

우리는 스프링이 지원하는 컴포넌트 스캔이라는 기능을 통해 아주 간편하게 스프링 컨테이너에 빈 등록이 가능하다.

컴포넌트 스캔 (Component Scan) 이란?

컴포넌트 스캔은 스캔 범위 내에 존재하는 @Component 애노테이션이 붙은 클래스를 스프링 빈으로 등록하기 위한 스캔 과정이다.

컴포넌트 스캔은 @ComponentScan 애노테이션을 통해 설정이 가능하다.

@SpringBootApplication

스프링부트 프로젝트 생성 시, Main 클래스에 설정되는 @SpringBootApplication 애노테이션은
내부에 @ComponentScan 애노테이션을 기본으로 가지고 있다.

덕분에 우리는 따로 @ComponentScan 애노테이션을 선언하지 않고도 @Component 애노테이션이 붙어있는 클래스들을 스프링 컨테이너에 빈으로 등록할 수 있던 것이다.

컴포넌트 스캔이 작동하는 애노테이션 종류

컴포넌트 스캔은 @Component 애노테이션이 붙어있는 클래스에만 해당되는 이야기라고 하였다.

하지만 @Component 애노테이션 외에도 몇 가지 애노테이션도 컴포넌트 스캔 범위에 해당된다.

그 종류는 바로 @Controller, @RestController, @Service, @Configuration, @Repository 이다.

이 애노테이션들은 왜 컴포넌트 스캔에 포함될까?

@Repository 살펴보기

예시로 사진을 가져와본 Repository 애노테이션의 코드를 보면 알 수 있듯이
해당 애노테이션들은 내부에 @Component 애노테이션을 포함하고 있다.

때문에 컴포넌트 스캔 범위에 해당이 되는 것이며, 우리는 이들을 스프링 컨테이너의 가호 아래에서 싱글톤으로 사용할 수 있는 것이다.

컴포넌트 스캔의 탐색 범위

그렇다면 컴포넌트 스캔의 탐색 범위는 어떻게 될까?

대규모 프로젝트라면 컴포넌트 스캔을 위해 모든 자바 클래스를 탐색하는 것은 비용 낭비일 것이다.

컴포넌트 스캔 basePackage 설정

@Configuration
@ComponentScan(
        basePackages = "com.example"
)
public class AutoAppConfig {
}

컴포넌트 스캔은 위와 같이 basePackage 설정을 통해 컴포넌트 스캔의 기반 패키지를 설정할 수 있다.

basePackage를 설정하게 되면, 설정된 패키지와 그 하위의 패키지의 클래스들을 모두 탐색하며 컴포넌트 스캔을 수행한다.

이를 통해 프로젝트의 모든 클래스를 찾지 않고 필요한 부분만 컴포넌트 스캔을 수행할 수 있다.

@SpringBootApplication의 basePackage 설정

@SpringBootApplication(
       scanBasePackages = ""
)

SpringBootApplication 또한 내부에 @ComponentScan 애노테이션을 가지고 있기 때문에,
scanBasePackages 이라는 속성을 통하여 컴포넌트 스캔 범위를 설정할 수 있도록 되어있다.

컴포넌트 스캔의 Default basePackage

만약 위와 같이 컴포넌트 스캔 범위를 지정해주지 않는다면, @ComponentScan 애노테이션을 선언해준 클래스의 패키지를 basePackage로 설정한다.

때문에 해당 클래스가 존재하는 패키지를 포함하여, 그 하위의 패키지에 있는 클래스들에 대해서 컴포넌트 스캔이 이루어진다.

스프링 신 김영한 선생님의 권장 방식

김영한님께서 개인적으로 즐겨 사용하는 방법은 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것 이라고 한다.

basePackageClasses 옵션

@Configuration
@ComponentScan(
        basePackageClasses = {
                AutoAppConfig.class
        }
)
public class AutoAppConfig {
}

basePackages 외에 basePackageClasses 라는 속성도 존재하는데,
이 속성은 특정 클래스를 설정하면 그 클래스가 위치한 패키지와 그 하위 패키지에 대해 컴포넌트 스캔을 수행하여 빈을 등록한다.

컴포넌트 스캔 탐색 제외(exclude) / 포함(include) 속성

컴포넌트 스캔은 basePackages와 basePackageClasses 속성 외에도

특정 부분에 대해 컴포넌트 스캔을 제외(exclude) 시킬 수 있는 excludeFilters와
특정 부분에 대해 컴포넌트 스캔을 포함(include)시킬 수 있는 includeFilters 속성이 존재한다.

includeFilters

먼저 includeFilters에 대해 살펴보자

@Configuration
@ComponentScan(
        includeFilters = {
                @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
        }
)
public class AutoAppConfig {
}

includeFilters 속성을 @ComponentScan 애노테이션의 속성으로 추가하게 되면,
해당 속성에 정의한 type, classes를 바탕으로 컴포넌트 스캔에서 포함(include) 시킬 클래스를 정의할 수 있다.

위 코드와 같이 includeFilters 옵션을 사용하게 되면,
컴포넌트 스캔 범위에 해당하는 클래스 + @Configuration 애노테이션이 붙은 클래스를 스프링 빈으로 등록하게 된다.

excludeFilters

@Configuration
@ComponentScan(
        excludeFilters = {
                @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
        }
)
public class AutoAppConfig {
}

excludeFilters 속성을 @ComponentScan 애노테이션의 속성으로 추가하게 되면,
해당 속성에 정의한 type, classes를 바탕으로 컴포넌트 스캔에서 제외(exclude) 시킬 클래스를 정의할 수 있다.

위 코드와 같이 excludeFilters 옵션을 사용하게 되면,
컴포넌트 스캔 범위에 해당하는 클래스를 탐색하되, @Configuration 애노테이션이 붙은 클래스를 발견하면 스캔에서 제외하고
이외의 것들만 스프링 빈으로 등록한다.

FilterType의 종류

FilterType이 Enum으로 되어있기에, 어떤 종류가 있는 지 궁금해서 정리해보았다.

FilterType Enum 클래스는 다음과 같은 열거 상수들을 가지고 있다.

ANNOTATION : 지정된 애노테이션을 가지고 있는 클래스를 탐색
ASSIGNABLE_TYPE : 지정된 클래스 또는 그 클래스를 상속하는 클래스들을 탐색
ASPECTJ : AspectJ 패턴을 기반으로 빈을 탐색
REGEX : 정규 표현식을 사용하여, 정규 표현식 패턴에 일치하는 이름의 클래스들을 탐색
CUSTOM : 사용자 정의 필터 로직을 구현하여 원하는 방식으로 빈을 선택적으로 탐색
(TypeFilter 인터페이스를 구현해서 처리)

컴포넌트 스캔 중복

컴포넌트 스캔 시에, 동일한 이름의 빈 등록이 발생하면 어떻게 될까?

1. 자동 빈 등록 vs 자동 빈 등록

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 만약 같은 이름으로 설정한 빈이 존재하면
스프링은 ConflictingBeanDefinitionException 예외를 발생시킨다.

2. 자동 빈 등록 vs 수동 빈 등록

그렇다면 만약 자동 빈 등록과 수동 빈 등록을 함께 사용할 때 빈 이름이 겹치면 어떻게 될까?

이전 스프링은 수동 빈이 자동 빈 보다 우선권을 가지도록 하였었다.

하지만 지금의 스프링은 자동 빈 vs 자동 빈 등록 케이스와 마찬가지로 예외를 발생시킨다.

@Configuration
@ComponentScan(
        excludeFilters = {
                @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
        }
)
public class AutoAppConfig {

    @Bean(name = "memoryMemberRepository")
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

다음과 같이 memoryMemberRepository를 @Configuration 클래스 내부에서 Bean으로 등록하고

@Repository
public class MemoryMemberRepository implements MemberRepository {
}

이와 동일한 MemoryMemberRepository를 @Repository 애노테이션을 통해 컴포넌트 스캔 범위로 잡아 스프링 빈으로 등록한다.

Bean의 기본 네이밍 패턴은 클래스명에서 맨 앞자만 소문자로 변경하는 형태이다.

때문에 위 Config에 수동으로 등록한 빈의 이름("memoryMemberRepository")과 동일함을 인지할 수 있다.

과거 스프링은 이러한 경우에
아래와 같은 로그를 출력하고 수동 빈 등록이 우선권을 가지게 하였다.
(수동 빈이 자동 빈을 오버라이드 해버렸다.)

Overriding bean definition for bean 'memoryMemberRepository' with a different
definition: replacing

하지만 현재 스프링은 스프링 빈의 이름이 같다면 예외를 발생시킨다.

그 이유는 대부분의 빈 네임 중복은 개발자의 의도가 아닌 휴먼 에러에 의해서 발생했던 것이었는데,
이로 인하여 나도 모르는 사이에 빈 네임 중복으로 인해 스프링 빈이 2개 중 1개만 생성이 되는 등 스프링 빈을 다루는 데에 문제점을 느끼게 되었다고 한다.

빈 네이밍 중복 시, 오버라이딩 시키기

Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true

때문에 빈 등록이 자동이건 수동이건 이름이 중복되면 위와 같은 메시지를 출력하고 무조건 예외를 발생시키도록 조치했다고 한다.

이때 예외 메시지를 잘 살펴보면 `spring.main.allow-bean-definition-overriding` 옵션을 `true`로 설정하면 Bean 오버라이딩이 가능해질 것이라고 한다.

실제로 해당 옵션을 yaml 또는 properties 파일에 추가해주면

수동 빈 등록 vs 자동 빈 등록 상황에서 빈 네이밍이 중복되어도 예외가 발생하지 않고
수동 빈이 자동 빈을 오버라이드 하도록 설정이 가능하다.

@Configuration과 싱글톤 (with. CGLIB)

PgmJUN — Thu, 11 Apr 2024 01:45:41 +0900

@Configuration
 public class AppConfig {
 
     @Bean
     public MemberService memberService() {
         return new MemberServiceImpl(memberRepository());
     }
     
     @Bean
     public OrderService orderService() {
         return new OrderServiceImpl(memberRepository(), discountPolicy());
		 }
		 
     @Bean
     public MemberRepository memberRepository() {
         return new MemoryMemberRepository();
     }
}

해당 코드는 OrderService, MemberService, MemberRepository 빈(Bean)을 정의하는 설정 파일의 코드이다.

이렇게 코드를 작성해둔다면 @Bean 애노테이션에 의해 스프링 빈으로 등록되고 싱글톤으로 관리된다.

그런데 이상한 부분이 있다.

MemberRepository 를 빈으로 등록하기 위해 return new로 구현체를 생성해주는 것은 알겠지만,
memberRepository() 메서드를 orderService(), memberService() 에서도 호출해주고 있으니
총 MemoryMemberRepository를 3번 생성해주는 것이 아닐까?

정말 싱글톤으로 관리가 되고 있는 것일까?

싱글톤 테스트

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

@SpringBootTest
public class AppConfigTest {

    @Test
    @DisplayName("싱글톤 테스트")
    void singleton() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
        MemberRepository memberRepository1 = orderService.getMemberRepository();

        MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
        MemberRepository memberRepository2 = memberService.getMemberRepository();

        Assertions.assertThat(memberRepository).isSameAs(memberRepository1);
        Assertions.assertThat(memberRepository).isSameAs(memberRepository2);
    }
}

위 코드는 memberRepository가 싱글톤이 맞는 지 검증하는 테스트이다.

스프링 컨테이너에 존재하는 MemberRepository 빈과 OrderService, MemberService에 주입된 MemberRepository 가 같은 지 검사하는 테스트 코드로 구성되었다.

이 테스트 코드의 결과는 어떨까?

테스트 결과

테스트의 결과는 성공이다.

스프링이 MemberRepository를 싱글톤으로 관리할 수 있도록 처리해주었다는 얘기인데 과연 어떻게 그럴 수 있는 걸까?

@Configuration

그 이유는 바로 @Configuration에 있다.

스프링이 스프링 빈을 싱글톤으로 관리하도록 보장해준다고 하는데, 사실 스프링이 자바 코드까지 변경하기는 어렵다.

그래서 스프링은 바이트코드를 조작하는 CGLIB 라이브러리를 사용하는데

@Configuration 내에서 @Bean 을 통해 스프링 빈을 등록 시,
바이트코드 조작 라이브러리가 Config 객체의 코드를 조작하여 싱글톤을 보장하도록 코드를 변경시킨 CBLIB 객체를 생성하고
그 객체를 스프링 컨테이너에 빈으로 등록한다.

실제로 AppConfig의 class를 출력시켜보면 아래와 같이 출력되는 것을 확인할 수 있었다.

AppConfig appConfig = ac.getBean(AppConfig.class);
System.out.println(appConfig.getClass());
        
// 출력 값: class com.example.demo.AppConfig$$SpringCGLIB$$0
// 일반 객체의 경우, 이렇게 출력된다(class com.example.demo.AppConfig)

AppConfig가 CGLIB에 의해 컨테이너에 등록된 AppConfig@CGLIB 예상 코드를 보자면 아래와 같지 않을까 싶다. (실제로는 훨씬 복잡하게 구현되어있을 것이며, 이 코드는 간략한 예상 코드이다.)

@Bean
public MemberRepository memberRepository() {
		if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) { 
				return 스프링 컨테이너에서 찾아서 반환;
		} else { //스프링 컨테이너에 없으면
				기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
				return 반환
		}
}

@Bean 만 사용한다면?

그렇다면 스프링 빈을 등록을 위해 사용되는 @Bean 애노테이션만 사용한다면, 스프링 빈을 싱글톤으로 관리하기 어려울까?

한번 테스트해보자

public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

이전 AppConfig 코드에서 @Configuration 애노테이션을 제거했다.

테스트

그리고 아까와 똑같은 테스트를 다시 진행해보자

결과는 실패이다.

그럼 @Configuration 애노테이션이 없다면 어떻게 동작하는 것일까?

내부 동작

우선 Configuration 애노테이션이 없으니 CGLIB 라이브러리가 바이트코드를 조작하지 않고 싱글톤을 보장하지 않는다.
위와 같은 AppConfig 코드라면 memberRepository가 총 3개 생성되고 각각의 스프링 빈으로 등록된다.

@Bean
public MemberRepository memberRepository() {
		System.out.println("memberRepository 생성");
    return new MemoryMemberRepository();
}

memberRepository() 메서드에 위와 같이 로그를 추가하는 경우

총 3번의 memberRepository 생성이 발생하는 것을 알 수 있다.

@Configuration 애노테이션이 존재하는 경우에는 단 1번만 호출되는 것을 확인할 수 있었다.

결론

컴포넌트 스캔 방식이 아닌 직접 Config 객체 선언하여 IoC 컨테이너를 구성하는 경우에는 @Configuration, @Bean 애노테이션을 통해 스프링 빈들의 싱글톤을 보장할 수 있다.
스프링에서 @Configuration 내부에 @Bean 애노테이션을 통해 선언한 빈들이 싱글톤을 보장할 수 있는 것은 @Configuration 애노테이션에 의해 동작하는 CGLIB이라는 바이트 코드 조작 라이브러리에 의해서이다.
@Configuration 애노테이션 없이 @Bean 만 붙이더라도, 스프링 빈 등록은 되지만 싱글톤 보장은 되지 않는다.

AWS 예상치 못한 과금 환불기 (with. 과금 방지법)

PgmJUN — Tue, 9 Apr 2024 16:05:26 +0900

킹갓AWS

이 글은 AWS에서 예상치 못한 과금을 때려맞은 본인의 환불 기록을 담은 글이다.

나는 이런 글을 쓰게 될 줄 몰랐고, 평생 안 쓸 생각이었다.

그런데 인간은 생각보다 멍청했고, 나도 그러했다ㅋ..

사건 수습 이후, 누구든 실수로 인해 AWS에서 과금폭탄을 맞은 경우
멘붕없이 이 글을 보며 차분히 대처할 수 있기를 바라는 마음에 기록으로 남겨보고자 글을 적게 되었다.

여행 중, 갑작스런 비용 결제 알림

즐거운 제주도 가족 여행 마지막 날 새벽 6시 50분,,, 내 폰에 한 통의 결제 알림이 수신되었다.

AWS로부터 결제 금액 75000원 가량이 빠져나가려다 잔액부족으로 실패했다는 알림이었다.

해당 계좌에는 다행히(?) 잔액을 만원만 입금해놓았기 때문에 돈이 출금되지는 않았고, 당황했지만 침착하게 원인 분석에 나섰다.

그리고 아래와 같은 원인이었음을 알게 되었다.

원인

Elasticache 생성 시에, 요금제에 손대지 않고 기초 설정대로 생성했는데 프리티어에서 무료 제공되는 t2.micro가 아니라 r6g.Large 로 설정되어 과금이 되었던 것.

이전에는 자동으로 t2.micro로 설정이 되어 있었기 때문에 이번에는 Elasticache에서 Redis 생성 시 요금제를 자세히 확인하지 않았고,, 이건 명백히 나의 잘못이었다…ㅠ

AWS 지원 센터(Support Center)에 문의 넣기

나의 잘못이었기에 일단 Elasticache 인스턴스를 삭제하고 발생된 비용은 결제를 하려던 찰나에 AWS에 문의하여 결제를 취소했다고 말하던 블로그가 생각나 시도라도 해보기로 하였다. (1월, 2월 합치면 10만원 정도의 돈이었고 학생인 나의 입장에선 너무나도 큰 금액이었다..ㅠ)

인터넷을 찾아보니 이렇게 예상치 못한 결제가 발생할 경우 AWS 지원 센터에 문의를 넣으면 AWS 측의 판단 하에 결제를 취소 시켜줄 수 있다고 했다.

때문에 나도 같은 방법으로 결제 취소 문의를 시도해보기로 하였다.

문의 방법

우측 상단 ? 버튼을 클릭 후, 지원 센터 클릭

사례 생성 버튼 클릭

문제에 대한 제목, 내용을 입력하고 증빙할 내용이 있다면 파일을 첨부한다.

그리고 아래에 있는 부가 정보들을 입력하면 AWS에 문의를 넣을 수 있다. (물론 제목, 내용 외에는 부가 정보들이기 때문에 적지 않아도 된다. 하지만 신속한 처리를 하고 싶다면 꼭 넣자)

Name of the Service : 비용 발생 서비스명
Invoice ID : 결제 청구서의 고유번호
Total Amount : 총 발생 금액이다.
Time Frame : 문제 발생 기간을 상세히 적어주면 된다.

문의 내용

글의 내용이 길어서 요약해주자면 "I'm poor student. plz help me" 이다.

한글도 지원을 해준다고는 하는데 나는 혹시 몰라 이렇게 영어 버전과 한글 버전 2개로 AWS에 문의를 넣었고,
AWS에서는 두 내용 모두 같은 내용이라 하나만 답변하겠다고 연락이 왔다.

(그리고 영어 문의에 대해서도 한글로 답변이 온 걸 보니 한글 지원이 가능한 것 같다!)

AWS의 답변

AWS는 과금이 발생되는 부분을 모두 삭제하고, 비용 조정 접수 의사를 밝힌 회신을 해달라고 했다.

나는 바로 답변에 달린 내용을 처리하고 비용 조정 요청을 부탁드렸다.

RDS 인스턴스 삭제
EC2 인스턴스 종료
EBS 볼륨 삭제
키 페어 삭제

추가로 답변에서 잡히지 않은 2월 사용 내역까지 부탁드렸다.

요청받은 서비스를 모두 삭제하고 나니, AWS에서 본인의 계정을 모니터링하기 시작했다.

우선 더는 비용이 발생하지 않도록 조치했으니 조용히 AWS에서 승인이 떨어지기를 기다렸다.

결과 ⭐️

그렇게 며칠을 기다린 결과 고객지원팀에서 전액 면제 처리를 해주셨다

1월 금액은 면제되었고, 2월 청구 금액은 결제 이후 환불해주시는 것으로 해주셨다.

애꿎은 10만원이 사라질 뻔했지만, 자비로우신 AWS 선생님들께서 선처해주셨다….. (정말 감사합니다..)

정리하고 보니 짧게 보이는데, 정말 피말리는 1달 간의 여정이었다....

환불까지 걸린 기간

1달 정도의 기간에 거쳐 환불을 받게 된 것 같다.

글에서는 생략되었지만, AWS에서 삭제해야 조치가 가능하다는 서비스를 본인이 잘못 알아들어 오래 걸렸던 부분이 큰데
AWS 서비스 센터 자체는 답변이 빠른 편이니 요구사항을 빠르게 처리한다면 더 빠르게 환불받을 수 있을 것이다.

과금 발생 방지법

1. 요금제 확인하고 서비스 이용

본인과 같은 경우에는 요금이 발생한다는 것을 알았지만, 이전에 자동으로 프리티어 요금제 설정이 되었던 경험이 있기에 이번에도 그렇게 될 줄 알고 확인하지 않고 넘어갔던 것이 큰 문제가 되었다.

여러분들은 항상 요금제를 확인하고 서비스를 이용하시길 바란다.

프리티어에서 어디까지 지원이 되는 지 모른다면 아래 글을 확인하면 될 것이다.

프리티어 지원 내용 확인하러 가기

2. AWS Budget(예산) 생성

Managing your costs with AWS Budgets - AWS Cost Management

고객지원팀에서 다시 똑같은 문제가 벌어지지 않도록 예산을 설정하는 것을 권장해주었다.

예산을 설정하면, 해당 예산이 초과되는 과금이 발생할 경우 설정해둔 메일을 통해 알림을 보내준다.

이를 통해 예상치 못한 과금이 발생하는 것을 미연에 방지할 수 있을 것이다.

위에 첨부한 링크를 참고하면 여러분들도 쉽게 설정할 수 있을 것이다.

이 외에도 과금 방지할 수 있는 다양한 방법들이 있는 것으로 알고 있는데

더 좋은 방법이 있다면 댓글에 공유해주시면 감사하겠습니다!

[Java] Java 반복 작업 수행 시, For-Loop와 Stream 사이 성능 비교

PgmJUN — Sat, 6 Apr 2024 14:43:29 +0900

미션 도중 생긴 고민

public Cars(List<String> carNames) {
        ArrayList<Car> cars = new ArrayList<>();
        for (String carName : carNames) {
            cars.add(new Car(carName));
        }

        this.cars = cars;
    }

Cars 객체를 생성할 때, List<String>형태의 carNames를 입력받은 뒤,
For-Loop 문을 통해 cars 필드를 초기화 해주었다.

하지만 For-Loop문을 생성자 로직에 적용하니 개인적으로 생성자 로직이 지저분하다는 생각이 들었다.
때문에 Stream을 사용하여 짧고 가독성있는 코드로 리팩토링하여 사용하고자 하였다.

그리고 이때 머릿속에 한가지 고민이 생겼다

미션의 요구사항에 자동차의 수는 제한이 없는데,
그럼 Integer.MAX_VALUE 대의 자동차 이름을 입력받았을 때 For-Loop와 Stream 중
무엇이 더 성능 면에서 뛰어날까?
성능이 더 좋은 것을 사용해야 할텐데,,

고민 해소을 위한 웹서칭 결과

평소 자세한 이유는 몰랐지만 주워들은 것이 있어 Stream의 성능이 더 좋지 않을 것이라고 생각했는데,
정말 Stream을 사용하는 것이 For-Loop를 사용하는 것보다 성능이 안 좋다고 한다.

가장 큰 이유는 For-Loop는 만들어진지 40년 이상 지났기 때문에 최적화가 굉장히 잘 되어 있었고,
Stream은 2015년 쯤에 Java8과 함께 생겨났기 때문에 아직 최적화 작업이 덜 되어있다는 것이 원인이라고 하는데,,

여기서 또 하나의 고민이 생겼다

그럼 무조건 For-Loop만을 사용해야만 하는 걸까?

나는 이 고민을 해소하기 위해 Stream과 For-Loop의 차이에 대해 공부를 시작하게 하게 되었고,
그 과정에서 좋은 글을 발견하여 학습하며 알게된 것을 공유하고자 포스팅을 작성하게 되었다.

Stream과 For-Loop의 성능 비교

Primitive Type 성능 비교

Primitive Type의 경우 JVM 메모리의 Stack에 값을 저장하고 있기 때문에
접근 속도가 빨라 For-Loop가 본래의 성능을 발휘할 수 있기에 빠른 반복문 수행이 가능하다.

스택(Stack)이란?

JVM의 스택(Stack)은 실행중인 스레드의 함수 호출 및 지역 변수 관리에 사용되며,
각 스레드는 자체 스택을 가진다.

Primitive Type은 변수 선언 시 JVM의 Stack 에 값을 저장하고, 변수 호출 시에 Stack에서 값을 바로 불러오는 방식을 채택하기 때문에 접근 속도가 굉장히 빠르다.

예를 들어, Primitive Type인 int 타입의 변수에 42라는 값을 저장하는 경우 42가 스택에 저장되며,
Stack에 저장된 값은 변수가 선언된 스코프(블록) 내에서만 사용 가능하다.

때문에 Primitive Type의 경우 Stream을 사용했을 때와, For-Loop를 사용했을 때
일반적으로 예측 가능한 결과를 내놓는다.

Test 로직

public class StreamAndForLoop {
    static final int MAX_INT = 5000000;
    static int[] testData = new int[MAX_INT];

    public static void main(String[] args) {
        init();

        calcForLoop();
        calcStream();
    }

    private static void init() {
        for (int i = 0; i < MAX_INT; i++) {
            testData[i] = i;
        }
    }

    private static void calcStream() {
        int standard = 0;
        long before = System.currentTimeMillis();
        Arrays.stream(testData)
                .filter(t -> t > standard)
                .count();
        System.out.println("Stream : " + (System.currentTimeMillis() - before));
    }

    private static void calcForLoop() {
        int standard = 0;
        int count = 0;

        long before = System.currentTimeMillis();
        for (int data : testData) {
            if(data > standard) {
                count++;
            }
        }
        System.out.println("For-Loop : " + (System.currentTimeMillis() - before));
    }
}

이는 standard라는 변수에 저장된 값과, testData에 저장된 값들의 크기를 비교하여
더 큰 값이 존재하면 count하는 로직을 Stream과 For-Loop 방식으로 각각 5000000번 수행하는 코드이다.

로직 수행 결과

당연하게도 Primitive Type은 접근 속도가 빠르기 때문에 일반적인 경우인
“For-Loop 방식이 더 빠르다” 라는 말에 들어맞는 결과가 출력된다.

결론적으로,
실험한 5000000번의 경우에는 3배 가까이 차이가 나는 것을 확인할 수 있다.

Wrapped Type 성능 비교

그렇다면 Wrapped Type은 어떨까?

Wrapped Type의 경우 Primitive Type과 달리 값을 저장할 때, Heap 메모리에 저장한다는 특징이 있다.

힙 메모리(Heap Memory)란?

Wrapped Type 변수가 선언되면 Heap 메모리에 객체가 할당되고, Stack에는 객체를 담고 있는 Heap 메모리 주소가 저장된다.

결국 우리는 Stack에 저장된 Heap 메모리 주소를 참조하여 Heap메모리에 접근하는 방식을 사용함으로써 저장된 데이터에 접근할 수 있게 되는 것이다.

말로만 들어도 Stack에 값을 저장하고 바로 참조할 수 있는 Primitive Type의 접근 방식보다 느려보이는데,
과연 위에서 사용했던 로직과 같은 로직을 Wrapped Type 으로 변환하여 실행시키면 어떤 결과가 나올까?

Test 로직

public class StreamAndForLoop {
    static final int MAX_INT = 5000000;
    static List<Integer> testData = new ArrayList<>();

    public static void main(String[] args) {
        init();

        calcForLoop();
        calcStream();
    }

    private static void calcStream() {
        int standard = 0;
        long before = System.currentTimeMillis();
        testData.stream()
                .filter(t -> t > standard)
                .count();
        System.out.println("Stream : " + (System.currentTimeMillis() - before));
    }

    private static void calcForLoop() {
        int standard = 0;
        int count = 0;

        long before = System.currentTimeMillis();
        for (Integer data : testData) {
            if(data > standard) {
                count++;
            }
        }
        System.out.println("For-Loop : " + (System.currentTimeMillis() - before));
    }

    private static void init() {
        for (int i = 0; i < MAX_INT; i++) {
            testData.add(i);
        }
    }
}

이는 위와 똑같이 standard라는 변수에 저장된 값과 testData에 저장된 값들의 크기를 비교하여
더 큰 값이 존재하면 count하는 로직을 수행한다.

하지만 이전처럼 Primitive Type을 사용하지 않고 Wrapped Type인 Integer를 사용하도록 변경하였다.

과연 Wrapped Type을 사용했을 때, 결과는 어떨까?

로직 수행 결과

신기하지 않은가?? 아까는 3배 가까이 차이가 나던 실행 결과가 이제는 거의 동일한 수준으로 측정되거나 역전해버렸다.

이는 Stack에 저장된 데이터(객체)의 주소를 통해 Heap 메모리에 접근하여 참조하는 비용이
Stack에 값을 저장하고 호출 시에 바로 값에 접근하는 비용에 비해 굉장히 크기 때문에,
Stream과 For-Loop의 속도 격차를 완화시켜버린 것이다.

이를 통해 Wrapped Type을 사용하는 For-Loop 경우,
Stream을 사용하는 경우와 비용이 크게 차이나지 않으므로,
가독성이 더 좋은 측을 선택하여 개발해도 괜찮다는 인사이트를 얻을 수 있었다.

로직 변경 ♻️

변경 전

public Cars(List<String> carNames) {
    ArrayList<Car> cars = new ArrayList<>();
    for (String carName : carNames) {
        cars.add(new Car(carName));
    }

    this.cars = cars;
}

내가 고민하던 로직의 경우 String이라는 Wrapped Type을 사용하고 있었기에,
관리하던 생성자 로직에 Stream을 적용하여 아래와 같이 변경하였다.

변경 후

public Cars(List<String> carNames) {
    this.cars = carNames.stream()
              .map(Car::new)
              .toList();
}

ArrayList<Car> 객체 선언 후, 반복문을 돌며 객체에 값을 저장하지 않아도 되기 때문에 ArrayList<Car> cars 변수 선언부 삭제 후, 필드에 바로 초기화하도록 수정
Stream을 사용하여 짧고 간결한 코드 작성으로 가독성 향상
굉장히 많은 반복 작업을 거친다고 해도 For-Loop문과 비교하여 더 좋거나 비슷한 성능을 발휘함

테스트를 위한 객체, 테스트 더블(Test Double)

PgmJUN — Thu, 4 Apr 2024 21:15:20 +0900

Test Double이란?

테스트 더블이란 실제 구현체로 테스트를 진행하기 어려운 경우, 이를 대신해서 테스트를 진행할 수 있도록 만들어지는 객체이다.

Test Double 이란 명칭의 유래

영화를 촬영하는 경우, 위험한 장면 촬영할 때 실제 배우를 대신해서 촬영하는 스턴트 더블에서 유래된 단어이다.

사용 이유

이전에 '테스트 주도개발 시작하기' 라는 책을 읽은 적이 있는데, 해당 책 저자의 말을 빌리자면

테스트 더블은 외부 요인에 의존하는 객체에 대한 테스트를 작성할 때 "실패하는 테스트는 항상 실패하고, 성공하는 테스트는 항상 성공한다" 라는 테스트의 일관성을 지키기 위해 사용한다고 했다.

예를 들어 DB, 외부 API 등을 사용할 때, 네트워크 연결 상태 등을 포함한 다양한 변칙적 이유에 의해서 테스트가 실패하는 상황이 발생할 수 있을 것이다.

이러한 문제에 대해 실제 구현체의 대역인 테스트 더블을 사용하여 테스트가 어떤 상황이든 간에 동작할 수 있도록 만들어주는 것이다.

'외부 요인' 의 범위

코드 리뷰를 주고받으며 현업자인 리뷰어는 테스트 더블로 처리해야하는 외부 요인의 범위를 지정하는 것이 가장 중요하다고 얘기해주셨다.

이에 대해서 본인의 기준을 한 줄 적어보자면

API 서버 개발에 사용하는 스프링부트 애플리케이션이 아닌 모든 외부 의존성들을 외부 요인이라고는 생각하지는 않는다.

예를 들어 H2 DB를 In-Memory & Embedded 모드로 사용한다면, 이는 스프링부트 애플리케이션 내부에서 작동하며 네트워크가 없이도 애플리케이션 내부에서 정상적으로 작동할 수 없으니 외부 의존성인 DB라고 해도 외부 요인으로 생각하지 않는다.

외부 API, 데이터베이스 서버, 그리고 다른 포트에서 동작하는 다른 애플리케이션 등
애플리케이션의 동작에 영향을 미칠 수 있는 외부 의존성을 외부 요인이라고 생각했고
이에 대해 타당한 의견인 것 같다는 리뷰도 받아 합리적인 생각에 가깝다고 판단할 수 있었다.

하지만 모든 상황마다 범위는 다를 수 있고 개발에 정답은 없으니 참고만 하길 바란다.

가짜를 사용하면 의미가 없지 않을까?

본인은 가짜 객체인 테스트 더블의 테스트 결과는 실제 구현체의 객체의 결과와 다르기 때문에 별 의미가 없는 것 아닐까? 라고 생각했었다.

하지만 실제로 애플리케이션에 대해 테스트를 작성하면서 테스트 더블의 필요성을 느끼게 되었다.

예를 들어 0~10 사이의 난수를 발생시키는 generate() 메서드를 가진 RandomNumberGenerator가 있고 외부에서는 해당 난수 값이 0~4면 false, 5~10이면 true를 return하는 로직이 존재한다고 가정하자.

이러한 로직을 테스트해야하는 상황에서, 난수는 우리가 조작할 수 없는 값이기 때문에 테스트를 작성하기 꽤나 곤란해진다.

이런 경우 우리는 테스트 더블을 통해 간단히 문제를 해결할 수 있다.

NumberGeneratorStub을 만들고 generate() 메서드의 return값을 0~10 중 테스트에 필요한 값으로 직접 설정하여 우리가 원하는 특정값을 얻도록 할 수 있다.

물론 해당 결과는 우리가 조작한 가짜이지만, 이렇게 통제가 100% 가능한 상황이 아닌 때에만 적절히 활용한다면 테스트를 통해 기능에 대해 쉽게 파악할 수 있고, 내부적으로 어떻게 동작하는 지 이해하는 것에 큰 도움을 줄 수 있는 훌륭한 테스트를 작성에 큰 도움을 줄 것이다.

이렇듯 우리가 통제할 수 없는 요인에 대해서 테스트 더블을 사용할 때, 효용을 얻을 수 있을 것이다.

Test Double의 종류

출처: https://tecoble.techcourse.co.kr/post/2020-09-19-what-is-test-double/

테스트 더블의 종류는 위와 같이 꽤나 다양하다.

Dummy

더미는 어떠한 동작도 필요하지 않지만, 어떠한 기능을 사용할 때 특정 객체의 인스턴스만이 필요할 때 사용된다.

다시 말해, 더미는 동작하지 않아도 테스트에 어떠한 영향도 미치지 않는 객체를 뜻한다.

예제를 통해 정확한 사용 상황을 살펴보자

Accelerator.java

public interface Accelerator {
    int push();
}

자동차를 앞으로 가게하기 위한 자동차의 힘(int)을 return하는 push()라는 행위에 책임을 가진 Accelerator 가 존재한다.

RandomMoveAccelerator.java

public class RandomMoveAccelerator implements Accelerator {
    public static final int MIN_ACCEL_POWER = 0;
    public static final int MAX_ACCEL_POWER = 9;
    public static final int MIN_MOVABLE_POWER = 4;

    public int push() {
        return RandomNumberUtils.generate(MIN_ACCEL_POWER, MAX_ACCEL_POWER);
    }
}

애플리케이션의 프로덕션 코드는 push() 메서드 실행 시에, 0~9 사이의 난수를 생성하여 return해야한다.

Car.java

public class Car {
    private final CarName name;
    private int position;
    private final Accelerator accelerator;

    public Car(String name, Accelerator accelerator) {
        this.name = new CarName(name);
        this.position = 0;
        this.accelerator = accelerator;
    }

    public void pushAccelerator() {
        moveForward(accelerator.push());
    }

    private void moveForward(int power) {
        if (power >= RandomMoveAccelerator.MIN_MOVABLE_POWER) {
            position++;
        }
    }

Car 클래스는 이러한 RandomMoveAccelerator를 생성자 주입받아, 애플리케이션 내부에서 랜덤값을 활용하여 position을 증가시킨다.

하지만 테스트에서 이러한 Car 객체를 생성할 때, RandomMoveAccelerator는 사용하지 않지만, Car 객체를 생성하기 위해 Accelerator는 주입해야주어야 하는 경우에는 어떻게 할까?

이때 사용하는 것이 더미이다.

BridgeGeneratorDummy.java

public class AcceleratorDummy implements Accelerator {
    @Override
    public int push() {
        return 0;
    }
}

이러한 상황에 빗대어 보았을 때, 위와 같이 아무런 동작도 하지 않는 AcceleratorDummy 클래스를 통해 ”어떠한 동작도 하지 않고 인스턴스 자체만을 제공한다” 라는 Dummy의 역할에 대해 직관적으로 이해할 수 있다.

물론 return type이 int형이기 때문에 0을 return하긴 하지만, 어떠한 로직처리도 하지 않으며 그저 0을 리턴한다.
Dummy로 사용될 것이기 때문에 push 라는 메서드가 사용될 일이 없는 경우에만 사용한다.

어짜피 실행시키지 않을 거면 프로덕션 코드에 구현해놓은 구현체를 사용하면 되지 않을까?

물론 가능하다고 생각한다. 하지만 이 기준은 상황에 따라 다를 것 같다.

하지만 만약 프로덕션 코드에 구현해놓은 구현체가 싱글톤으로 사용되고 있다면, 테스트에서도 프로덕션 코드에서 사용중인 인스턴스와 같은 인스턴스를 사용하게 된다.

이때 프로덕션 코드의 구현체 내부에 정적으로 상태를 가지고 있는 클래스 변수가 있다고 하면? 테스트의 동작이 실제 애플리케이션 작동에 영향을 끼칠 수도 있다.

이러한 경우에 더미를 사용하면 적절하지 않나 싶다.

Fake

페이크 객체는 복잡한 로직이나, 객체에서 필요로하는 다른 외부 객체들의 동작을 단순화하여 구현한 객체이다.

페이크 객체에서 단순화된 동작은 실제 플로우와 유사하게 구현은 되어 있지만, 실제 프로덕션 코드에는 적합하지 않는 코드이다.

예제를 통해 자세히 살펴보자

예제 코드

MemberRepository.java

public interface MemberRepository {
    Member save(Member member);
}

Member 객체를 입력받아서 저장소에 저장한다는 행위의 책임을 가진 MemberRepository 인터페이스의 save() 메서드가 존재한다고 가정하자.

MemberRepositoryImpl.java

public class MemberRepositoryImpl {
    Member save(Member member) {
				// DB 저장 로직..
		}
}

실제 프로덕션 코드에선 MemberRepositoryImpl이라는 구현체가 Member 객체를 DB에 저장하는 로직을 수행할 것이다.

그리고 저장되는 Member 엔티티의 PK는 1번부터 자동으로 증가하는 Auto Increment 설정이 되어있다.

우리는 이제 이 로직에 대해 테스트를 작성해보려고 했지만 문제를 발견하게 된다.

DB는 애플리케이션 서버의 외부로 분리되어 있다. 때문에 네트워크에 문제가 발생하면, DB에 접근해서 데이터를 추가하는 로직을 테스트하는 과정에서 에러가 발생한다. 네트워크에 따라 테스트가 실패할 수도 있게 된다는 것이다.

이러한 네트워크 영향을 없애면서 똑같은 동작을 수행하여 테스트 코드를 통해 기능이 어떻게 작동하는 지 직관적으로 개발자에게 인식시켜주기 위한 방법으로 무엇이 있을까?

이때 사용되는 것이 바로 Fake 객체이다.

FakeMemberRepository.java

public class FakeMemberRepository implements MemberRepository {
    private static final Map<Long, Member> members = new ConcurrentHashMap<>();
    private static Long idSequence = 1L;
    
    @Override
    public Member save(Member member) {
        members.put(idSequence++, member);
        return member;
    }
}

FakeMemberRepository는 실제 DB가 아닌 Map에 데이터를 저장함으로써 데이터가 저장소에 저장되는 것과, idSequence를 사용함으로써 Member의 PK가 Auto Increment 되는 것을 정확히 구현한 Fake 객체이다.

이러한 내부 구현 단순화를 통해 테스트를 하는 개발자에게 DB에 수행되는 것과 동일한 결과를 전달하며, 외부 요인에 영향을 받지 않고 항상 성공하는 테스트를 작성할 수 있도록 돕는 것이 바로 Fake 객체의 역할이다.

Stub

스텁은 위에서 소개한 더미 객체가 실제 동작하는 것처럼 보이게 만들어놓은 객체이다.

인터페이스 또는 기본 클래스가 최소한으로만 구현된 상태이며, 테스트에서 호출된 요청에 대해 미리 준비된 결과를 제공한다.

쉽게 말해 스텁은, 상태 검증을 위한 테스트 더블이다.

정리하자면 내부 동작에 대한 구현은 모두 제외하고, 동작에 대한 결과만을 얻고 싶을 때 사용한다.

아래 예제는 초반에 가자 객체를 사용하면 의미가 없지 않을까? 에서 설명한 내용과 동일한 예제이다.

예제를 통해 스텁을 이해해보자

예제 코드

Accelerator.java

public interface Accelerator {
    int push();
}

자동차를 앞으로 가게하기 위한 자동차의 힘(int)을 return하는 push()라는 행위에 책임을 가진 Accelerator 가 존재한다.

RandomMoveAccelerator.java

public class RandomMoveAccelerator implements Accelerator {
    public static final int MIN_ACCEL_POWER = 0;
    public static final int MAX_ACCEL_POWER = 9;
    public static final int MIN_MOVABLE_POWER = 4;

    public int push() {
        return RandomNumberUtils.generate(MIN_ACCEL_POWER, MAX_ACCEL_POWER);
    }
}

애플리케이션의 프로덕션 코드는 push() 메서드 실행 시에, 0~9 사이의 난수를 생성하여 return해야한다.

Car.java

public class Car {
    private final CarName name;
    private int position;
    private final Accelerator accelerator;

    public Car(String name, Accelerator accelerator) {
        this.name = new CarName(name);
        this.position = 0;
        this.accelerator = accelerator;
    }
		
		public void pushAccelerator() {
        moveForward(accelerator.push());
    }

    private void moveForward(int power) {
        if (power >= RandomMoveAccelerator.MIN_MOVABLE_POWER) {
            position++;
        }
    }

Car 클래스는 Accelerator 인터페이스를 통해 이러한 RandomMoveAccelerator를 생성자 주입받고, moveForward(int power) 메서드를 통해 내부에서 랜덤값을 활용하여 position을 증가시킨다.

position 증가로직의 분기처리는 아래와 같다.

난수가 0~4이면 position을 그대로
5~10이면 position을 1 증가

하지만 moveForward(int power)는 난수에 의존하기 때문에 moveForward의 position 증가 테스트를 작성할 때, 우리가 원하는 결과를 만들기 어려워보인다.

테스트를 하겠다고 private인 moveForward의 접근제어자를 public으로 변경할 수도 없는 노릇이다.

이럴 때 Stub 객체를 사용하여, 우리가 원하는 값을 return하도록 구현하면 moveForward에 대해 원하는 결과를 만들어낼 수 있다.

StubAccelerator.java

public class StubAccelerator implements Accelerator {
    private int power;
    
    public StubAccelerator() {
        this.power = 0; // NPE 방지를 위해 기본값 주입
    }
    
    public void setPower(final int power) {
        this.power = power;
    }

    public int push() {
        return power;
    }
}

위와 같이 Accelerator에 대한 스텁을 생성하면 push() 메서드가 랜덤 값이 아닌 우리가 설정한 값을 return하도록 만들 수 있다.

보통 위 코드와 같이 원하는 설정 값을 필드로 만들어두고 setter를 통해 값을 설정하도록 구현한다.

생성자를 통해 power의 값을 지정하는 방법도 있겠지만,
프로덕션 코드의 Accelerator 구현체는 power를 인자로 입력받는 생성자가 존재하지 않는다.
때문에 테스트를 위해 새로운 인스턴스 생성 규칙(생성자)을 만들어주는 것은 테스트 코드를 통해 프로덕션 코드의 동작 로직을 파악하는 것에 혼란을 야기할 수 있다.
때문에 Stub 사용에 있어서는 생성자보단 Setter 사용을 지향하자!

Spy

스파이 객체는 스텁의 역할을 가지면서 객체의 상태를 관찰하고 기록하는 데 사용되며 주로 메소드 호출과 관련된 정보를 기록하고 반환한다. 이는 특히 테스트 중에 객체가 어떻게 상호작용하는지 추적하고 확인하는 데 유용하다.

스텁의 역할을 가진다고 해서 완전히 스텁과 동일한 것은 아니다.

특정 부분은 실제 객체와 동일하게 구현할 수 있고, 특정 부분은 스텁으로 구현할 수 있다. 그리고 스텁은 어떠한 행위에 대한 결과를 얻기 위해 사용하지만, 스파이 객체는 내부 로직에 숨어서 실행 횟수 등의 객체의 상태를 관찰하고 기록하는 역할을 한다.

실제 객체와 동일하게 로직을 구현하는 이유는 로직의 실행 속도 등을 체크해야하는 상황일 듯 싶다. 물론 실제 객체와 동일하게 동작하도록 구현할 필요가 없거나, 구현할 수 없는 부분에 대해서는 스텁으로 구현해도 된다.

결론적으로 구현은 실제 객체와 스텁 사이에서 필요한 것을 취해서 만들면 되는 것이고, 객체의 내부에서 어떠한 정보를 측정하거나 기록하기 위해 사용되는 객체인 것이다.

예제 코드

SpyRandomMoveAccelerator.java

public class SpyRandomMoveAccelerator implements Accelerator {
    public static final int MIN_ACCEL_POWER = 0;
    public static final int MAX_ACCEL_POWER = 9;
    public static final int MIN_MOVABLE_POWER = 4;

    private int calledCount = 0;

    public int push() {
        calledCount++;
        return RandomNumberUtils.generate(MIN_ACCEL_POWER, MAX_ACCEL_POWER);
    }
    
    public int getCalledCount() {
        return calledCount;
    }
}

위 코드는 RandomMoveAccelerator의 Spy 객체이다.

위에서 소개한 RandomMoveAccelerator 클래스와 똑같이 작동하지만, 내부적으로 calledCount 라는 정수 자료형이 push() 메서드의 호출 횟수를 기록한다.

또한 getCalledCount() 메서드를 통해 push() 메서드가 얼마나 호출 되었는 지 확인할 수 있다.

이렇게 메서드의 호출 횟수 등과 같은 객체의 행위 또는 상태 등을 관찰하고 기록하는 역할을 하는 객체가 바로 스파이 객체이다.

Mock

Mock이란 한글로 모의의, 가짜의 라는 뜻을 가지는 테스트 더블 객체로, 실제 객체와 동일한 모의 객체를 만들어 테스트의 효용성 높이기 위해 사용한다.

상태를 검증하는 Stub과는 다르게, 어떠한 행위를 잘 수행하는 지에 대해 검증하는 행위 검증 을 위한 테스트 더블 객체이다.

Java환경에선 주로 Mockito를 통해 테스트를 수행하게 된다.

Mockito란?

mock을 쉽게 만들고 mock의 행동을 정하는 stubbing, 정상적으로 작동하는 지 검증하는 verify 등 다양한 기능을 제공해주는 프레임워크이다.

DB연동 작업등과 같은 테스트 자동화가 어렵거나, 요청에 시간이 오래 걸리는 내용들은 Mockito를 통해 가짜 객체를 생성하여 행위에 대한 검증을 신속하게 수행한다.

예제 코드

(적용해보고 작성)

결함 내성

(학습해서 채우기)

[Java] Fluent API란? (feat. JDBC에 적용해보기)

PgmJUN — Thu, 4 Apr 2024 21:06:15 +0900

Fluent API는 API의 패턴 중 하나이다.

Fluent API는 메서드 체이닝 형태로 설계된 API이며, 그 목표는 도메인별 언어 (DSL)를 생성하여 코드 가독성을 높이는 것이다.

이 용어는 Eric Evans 와 Martin Fowler 가 2005년에 만들어냈다고 한다.

Fluent API를 사용하는 대표적인 라이브러리로 AssertJ가 존재한다.

이전에는 Junit을 통해 하나의 메서드로 처리해야 했던 코드를

Fluent API 패턴을 적용한 AssertJ를 통해, 직관적인 형태로 메서드를 풀어내어 테스트 코드를 작성할 수 있도록 구현되어 있다.

// Junit
Assertions.assertTrue(true);

// assertJ
Assertions.assertThat(true).isTrue();

// ===

// Junit
 Assertions.assertEquals(object1,object2);

 // assertJ
 Assertions.assertThat(object1).isEqaulTo(object2);

하나의 메서드를 통해 테스트를 수행하던 이전 Junit이 아닌

Fluent API로 구현된 assertJ를 사용함으로써 테스트 질의를 다양화하는데에 도움을 얻고,

쉽고 빠르게 코드를 이해할 수 있게 되었다.

확실히 Junit보다 assertJ를 사용한 코드가 더 직관적임을 확인할 수 있다.

Fluent는 ‘유창한’ 이라는 의미처럼 메서드 체이닝 방식을 통해 자신의 행위에 대해 유창하게 표현할 수 있다.

이러한 Fluent API 패턴을 우테코 미션을 수행하는 과정에서 적용해보게 되어 그 기록을 남겨보고자 한다.

적용 배경

@Override
    public Long add(Connection conn, GameEntity game) throws SQLException {
        try {
            PreparedStatement preparedStatement = conn.prepareStatement(
                    "INSERT INTO game (turn) VALUES(?)",
                    Statement.RETURN_GENERATED_KEYS
            );
            preparedStatement.setString(1, game.getTurn().now().name());
            preparedStatement.executeUpdate();

            ResultSet generatedKeys = preparedStatement.getGeneratedKeys();
            generatedKeys.next();

            return generatedKeys.getLong(1);
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }

본인은 Java, JDBC를 사용해 DB 접근을 수행해야하는 우테코 체스 미션을 수행하면서, 위와 같은 DAO 클래스의 로직을 만들게 되었다.

JDBC를 사용하는 로직은 위와 같이 연결된 Connection을 통해 PreparedStatement를 얻고

여기에 쿼리를 설정하여 execute 메서드를 통해 DB에 요청을 보내는 구조이다.

리뷰어 알렉스의 리뷰

이번 미션에서 리뷰어를 맡아주신 알렉스는 이 코드를 보고 비슷한 패턴이 반복되는 DAO 클래스 메서드들의 개선을 제안했다.

이 리뷰에 대해 본인은 “함수형 프로그래밍 등을 사용하면 처리할 수 있지 않을까?” 라고 생각하였지만 그렇지 않았다.

패턴은 비슷하지만 완전 중복되는 로직이 아니라 중간중간 다르게 작동되어야하는 부분이 많았다.

예를 들어 PreparedStatement를 사용하면 쿼리를 입력하고 이후에 setString, setLong 등을 통해 쿼리에 사용되는 값들을 주입해주어야 했는데 이러한 처리 하나하나를 분리하는 것이 굉장히 복잡하게 느껴졌다.

PreparedStatement 자체를 생성하는 것도 Create 로직은 AUTO_INCREMENT Key 설정을 적용해두었기 때문에 이를 알아내어 사용하기 위해 Statement.RETURN_GENERATED_KEYD 설정을 적용해주어야했다.

다른 부분이 굉장히 많은 로직에서 중복을 제거하기란 쉽지 않았다.

이때 문뜩 Query 작성을 메서드 체이닝 방식을 기반으로 편리하게 만들어준 QueryDSL이 떠올랐다.

본인은 지금 겪고있는 문제에 대해 메서드 체이닝 방식을 적용하여 중복코드를 최대한 제거하고,

코드의 가독성을 높여보고자 Fluent API 패턴을 JDBC 사용에 적용해보고자 한다.

구조

QueryManager: Connection 연결을 담당
- ConnectedQueryManager: Connection이 연결된 상태로 insert, select, update, delete 중 하나를 선택하고 쿼리를 입력받음
  - CrudQueryManager: CRUD 각각의 쿼리 매니저의 중복로직을 가지고 있음
    - InsertQueryManager: Create 쿼리 수행을 담당
      - AfterExecuteQueryManager: Create 쿼리 수행 이후, Auto_Increment로 생성된 키값을 리턴하는 로직을 담당
    - SelectQueryManager: Read 쿼리 수행을 담당
    - UpdateQueryManager: Update 쿼리 수행을 담당
    - DeleteQueryManager: Delete 쿼리 수행을 담당

코드 보기

QueryManager

import java.sql.Connection;

public class QueryManager {

    public static ConnectedQueryManager setConnection(final Connection conn) {
        return new ConnectedQueryManager(conn);
    }
}

ConnectedQueryManager

import java.sql.Connection;
import java.sql.SQLException;

public class ConnectedQueryManager {
    private Connection conn;

    public ConnectedQueryManager(final Connection conn) {
        this.conn = conn;
    }

    public InsertQueryManager insert(final String query) throws SQLException {
        return new InsertQueryManager(conn, query);
    }

    public SelectQueryManager select(final String query) throws SQLException {
        return new SelectQueryManager(conn, query);
    }

    public UpdateQueryManager update(final String query) throws SQLException {
        return new UpdateQueryManager(conn, query);
    }

    public DeleteQueryManager delete(final String query) throws SQLException {
        return new DeleteQueryManager(conn, query);
    }
}

CrudQueryManager

import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

sealed class CrudQueryManager permits InsertQueryManager, SelectQueryManager, UpdateQueryManager, DeleteQueryManager {
    private final PreparedStatement pstmt;

    protected CrudQueryManager(final PreparedStatement pstmt) {
        this.pstmt = pstmt;
    }

    protected void setStringParameter(final int paramIndex, final String value) throws SQLException {
        this.pstmt.setString(paramIndex, value);
    }

    protected void setLongParameter(final int paramIndex, final Long value) throws SQLException {
        this.pstmt.setLong(paramIndex, value);
    }

    protected void setIntParameter(final int paramIndex, final int value) throws SQLException {
        this.pstmt.setInt(paramIndex, value);
    }

    protected ResultSet executeQuery() throws SQLException {
        return pstmt.executeQuery();
    }

    protected void executeUpdate() throws SQLException {
        pstmt.executeUpdate();
    }

    public PreparedStatement getPreparedStatement() {
        return pstmt;
    }
}

InsertQueryManager

import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.regex.Pattern;

public final class InsertQueryManager extends CrudQueryManager {
    private static final Pattern INSERT_PATTERN = Pattern.compile("(?i)^insert\\s.*");

    public InsertQueryManager(final Connection conn, final String query) throws SQLException {
        super(conn.prepareStatement(query, Statement.RETURN_GENERATED_KEYS));
        validate(query);
    }

    private void validate(final String query) {
        if (!INSERT_PATTERN.matcher(query).matches()) {
            throw new IllegalArgumentException("삽입 쿼리는 INSERT 구문으로 시작해야합니다.");
        }
    }

    public InsertQueryManager setString(final int paramIndex, final String value) throws SQLException {
        setStringParameter(paramIndex, value);
        return this;
    }

    public InsertQueryManager setLong(final int paramIndex, final Long value) throws SQLException {
        setLongParameter(paramIndex, value);
        return this;
    }

    public AfterExecuteQueryManager execute() throws SQLException {
        super.executeUpdate();
        return new AfterExecuteQueryManager(super.getPreparedStatement());
    }
}

AfterExecuteQueryManager

import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class AfterExecuteQueryManager {

    private final PreparedStatement pstmt;

    public AfterExecuteQueryManager(final PreparedStatement pstmt) {
        this.pstmt = pstmt;
    }

    public ResultSet getGeneratedKeys() throws SQLException {
        return pstmt.getGeneratedKeys();
    }
}

SelectQueryManager

import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.regex.Pattern;

public final class SelectQueryManager extends CrudQueryManager {
    private static final Pattern SELECT_PATTERN = Pattern.compile("(?i)^select\\s.*");

    public SelectQueryManager(final Connection conn, final String query) throws SQLException {
        super(conn.prepareStatement(query));
        validate(query);
    }

    private void validate(final String query) {
        if (!SELECT_PATTERN.matcher(query).matches()) {
            throw new IllegalArgumentException("조회 쿼리는 SELECT 구문으로 시작해야합니다.");
        }
    }

    public SelectQueryManager setString(final int paramIndex, final String value) throws SQLException {
        setStringParameter(paramIndex, value);
        return this;
    }

    public SelectQueryManager setLong(final int paramIndex, final Long value) throws SQLException {
        setLongParameter(paramIndex, value);
        return this;
    }

    public ResultSet execute() throws SQLException {
        return super.executeQuery();
    }
}

UpdateQueryManager

import java.sql.Connection;
import java.sql.SQLException;
import java.util.regex.Pattern;

public final class UpdateQueryManager extends CrudQueryManager {
    private static final Pattern UPDATE_PATTERN = Pattern.compile("(?i)^update\\s.*");

    public UpdateQueryManager(final Connection conn, final String query) throws SQLException {
        super(conn.prepareStatement(query));
        validate(query);
    }

    private void validate(final String query) {
        if (!UPDATE_PATTERN.matcher(query).matches()) {
            throw new IllegalArgumentException("수정 쿼리는 UPDATE 구문으로 시작해야합니다.");
        }
    }

    public UpdateQueryManager setString(final int paramIndex, final String value) throws SQLException {
        setStringParameter(paramIndex, value);
        return this;
    }

    public UpdateQueryManager setLong(final int paramIndex, final Long value) throws SQLException {
        setLongParameter(paramIndex, value);
        return this;
    }

    public void execute() throws SQLException {
        super.executeUpdate();
    }
}

DeleteQueryManager

import java.sql.Connection;
import java.sql.SQLException;
import java.util.regex.Pattern;

public final class DeleteQueryManager extends CrudQueryManager {
    private static final Pattern DELETE_PATTERN = Pattern.compile("(?i)^delete\\s.*");

    public DeleteQueryManager(final Connection conn, final String query) throws SQLException {
        super(conn.prepareStatement(query));
        validate(query);
    }

    private void validate(final String query) {
        if (!DELETE_PATTERN.matcher(query).matches()) {
            System.out.println(query);
            throw new IllegalArgumentException("삭제 쿼리는 DELETE 구문으로 시작해야합니다.");
        }
    }

    public DeleteQueryManager setString(final int paramIndex, final String value) throws SQLException {
        setStringParameter(paramIndex, value);
        return this;
    }

    public DeleteQueryManager setLong(final int paramIndex, final Long value) throws SQLException {
        setLongParameter(paramIndex, value);
        return this;
    }

    public void execute() throws SQLException {
        super.executeUpdate();
    }
}

적용 전/후 비교

Before

@Override
    public Long add(Connection conn, GameEntity game) throws SQLException {
        try {
            PreparedStatement preparedStatement = conn.prepareStatement(
                    "INSERT INTO game (turn) VALUES(?)",
                    Statement.RETURN_GENERATED_KEYS
            );
            preparedStatement.setString(1, game.getTurn().now().name());
            preparedStatement.executeUpdate();

            ResultSet generatedKeys = preparedStatement.getGeneratedKeys();
            generatedKeys.next();

            return generatedKeys.getLong(1);
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }

After

public Long add(Connection conn, GameEntity game) throws SQLException {
        ResultSet generatedKeys = QueryManager
                .setConnection(conn)
                .insert("INSERT INTO game (turn) VALUES(?)")
                .setString(1, game.getTurn().now().name())
                .execute()
                .getGeneratedKeys();

        generatedKeys.next();
        return generatedKeys.getLong(1);
    }

확실히 이전보다 JDBC 코드를 다루는 것이 간편해졌으며,
메서드 체이닝 형식을 사용하니, 이전보다 직관적이고 가독성 높은 코드로 변화했다는 생각이 든다.

역할 분리 및 구현을 위해 Fluent API 패턴 적용을 위한 클래스가 많이 생성된다는 단점이 존재하지만 그 부분을 제외하고는 중복로직도 상당히 제거되고 가독성이 증가하는 것이 굉장히 맘에 들었다.

학습하는 과정에서 배운 내용을 적용해보는 행동은 항상 즐겁고 의미있는 것 같다.

그리고 이렇게 학습한 것들을 모두 시도해보고 도전해볼 수 있는 학습 환경을 제공하고 만들어주는 우테코에게도 굉장히 감사한다!

Reference

Fluent interface

[Java] 생성자 체이닝(Constructor Chaining) 기법

PgmJUN — Tue, 2 Apr 2024 16:15:54 +0900

생성자 체이닝(Constructor Chaining)이란?

생성자 체이닝은 생성자가 2개 이상일 경우, 전체 인스턴스 필드의 값 초기화를 담당하는 하나의 주 생성자를 두고 이 외의 부 생성자들은, 자신보다 상위의 부 생성자를 호출하는 체이닝 구조를 거쳐 최종적으로 주 생성자를 호출하여 객체를 생성하도록 만드는 방식이다.

즉, 실제 객체 초기화를 담당하는 주 생성자 이 외에는 상위 생성자를 호출해나가는 구조인 것이다.

적용

기존 코드

public Player(final String name) {
	super(Cards.createEmpty());
	this.name = new Name(name);
}

public Player(final String name, final Cards cards) {
	super(cards);
	this.name = new Name(name);
}

생성자 체이닝 적용

public Player(final String name) {
		this(new Name(name), Cards.createEmpty());
}

public Player(final Name name, final Cards cards) {
	super(cards);
	this.name = name;
}

생성자들 중, 가장 아래에 주 생성자를 배치
부 생성자들은 체이닝 순서에 맞게 순차적으로 주 생성자 위쪽에 배치

사용 목적

1. 중복 로직 제거

기존 코드를 보면 `this.name = new Name(name);` 코드가 두 생성자에서 중복되고 있다.
지금은 인스턴스 필드가 간단하게만 존재하지만, 인스턴스 필드의 종류와 오버로드가 더 많다면 중복 코드가 훨씬 많이 생성될 것이다.
- 여기에 생성자 체이닝 적용을 통해 부 생성자에서 this 키워드를 통해 주 생성자를 호출하도록 함으로써
  `코드 중복을 제거` 및 `생성자의 재사용`이 가능하다

2. 유지보수성 향상

`생성자 체이닝 패턴 적용`을 통해 중복 코드가 제거되고, 인스턴스 필드 초기화 책임이 하나의 생성자(주 생성자)에만 존재하므로
변경이나 확장이 더 간단하다.

3. 가독성 향상

중복 코드가 제거되고, 필드 초기화의 책임이 하나의 생성자(주 생성자)에만 존재하며 부생성자들이 체이닝 순서에 맞게 순차적으로 배치되기 때문에 객체 필드 초기화의 흐름을 읽을 수 있어 가독성이 향상