kkoon9

[AI 자동화 테스트] notion to tistory

kkoon9 — Fri, 30 Jan 2026 00:20:23 +0900

ff96b901-18fc-4994-9b83-675fd0663366

start Date: 2024-05-21

end Date: 2024-06-09

책의 소개

이 책은 안드로이드 중심으로 설명하고 있는 책입니다.

프로세스, 스레드, 코루틴

애플리케이션을 실행할 때 OS는 프로세스를 생성하고 여기에 스레드를 연결한 다음, 메인 스레드를 시작합니다.

프로세스

실행 중인 애플리케이션의 인스턴스입니다.

애플리케이션이 시작될 때마다 애플리케이션의 프로세스가 시작됩니다.

스레드

실행 스레드는 프로세스가 실행할 일련의 명령을 포함합니다.

따라서 프로세스는 최소한 하나의 스레드를 포함하며 이 스레드는 애플리케이션의 진입점(entry point)을 실행하기 위해 생성됩니다.

보통 진입점은 애플리케이션의 main() 함수이며 메인 스레드라 하는데 프로세스의 라이프 사이클과 밀접하게 연관됩니다.

스레드가 끝나면 프로세스의 다른 스레드와 상관없이 프로세스가 종료됩니다.

코루틴이 동시성을 구현한 방식을 보면 우리가 직접 스레드를 시작하거나 중지할 필요가 없다는 것을 알 게 됩니다.

한 두줄의 코드로 코틀린이 특정 스레드나 스레드 풀을 생성해서 코루틴을 실행하도록 지시하기만 하면 됩니다.

코루틴

코루틴은 경량 스레드라고도 합니다.

대부분의 스레드와 마찬가지로 코루틴이 프로세서가 실행할 명령어 집합의 실행을 정의하기 때문입니다.

또한 코루틴은 스레드와 비슷한 라이프 사이클을 가지고 있습니다.

코루틴은 스레드 안에서 실행됩니다.

스레드 하나에 많은 코루틴이 있을 수 있지만 주어진 시간에 하나의 스레드에서 하나의 명령만이 실행될 수 있습니다.

즉 같은 스레드에 10개의 코루틴이 있다면 어느 한 시점에는 하나의 코루틴만 실행됩니다.

스레드 vs 코루틴

코루틴이 스레드보다 빠르고 적은 비용으로 생성할 수 있다는 것입니다.

suspend fun createCoroutines(amount: Int) {
    val jobs = ArrayList<Job>()
    for (i in 1..amount) {
        jobs += launch {
            delay(1000)
        }
    }
    jobs.forEach {
        it.join()
    }
}

위 함수는 파라미터 amount만큼 코루틴을 생성해 각 코루틴을 1초간 지연시킨 후 모든 코루틴이 종료될 때까지 기다렸다가 반환합니다.

amount가 10,000으로 실행할 때 1.160ms, 100,000으로 실행할 때 1,649ms가 소요됐다고 합니다.

코틀린은 고정된 크기의 스레드 풀을 사용하고 코루틴을 스레드들에 배포하기 때문에 실행 시간이 매우 적게 증가합니다.

코루틴이 일시 중단되는 동안(delay()가 실행되는 동안) 실행 중인 스레드는 다른 코루틴을 실행하는 데 사용되며 코루틴은 시작 혹은 재개될 준비 상태가 됩니다.

‍ Thread 클래스의 activeCount() 메서드는 활성화된 스레드 수를 알 수 있습니다.

fun main(args: Array<String>) = runBlocking {
    println("${Thread.activeCount()} threads active at the start")

    val time = measureTimeMillis {
        createCoroutines(10000)
    }
    println("${Thread.activeCount()} threads active at the end")
    println("Took $time ms")
}


suspend fun createCoroutines(amount: Int) {
    val jobs = ArrayList<Job>()
    for (i in 1..amount) {
        jobs += CoroutineScope(Dispatchers.IO).launch() {
            delay(1000)
        }
    }
    jobs.forEach {
        it.join()
    }
}

코루틴이 특정 스레드 안에서 실행되더라도 스레드와 묶이지 않는다는 점을 이해해야 합니다.

코뤁니의 일부를 특정 스레드에서 실행하고, 실행을 중지한 다음 나중에 다른 스레드에서 계속 실행하는 것이 가능합니다.

코틀린이 실행 가능한 스레드로 코루틴을 이동시키기 때문입니다.

fun main(args: Array<String>) = runBlocking {
    println("${Thread.activeCount()} threads active at the start")

    val time = measureTimeMillis {
        createCoroutines(3)
    }
    println("${Thread.activeCount()} threads active at the end")
    println("Took $time ms")
}


suspend fun createCoroutines(amount: Int) {
    val jobs = ArrayList<Job>()
    for (i in 1..amount) {
        jobs += CoroutineScope(Dispatchers.IO).launch() {
            println("Started $i in ${Thread.currentThread().name}")
            delay(1000)
            println("Finished $i in ${Thread.currentThread().name}")
        }
    }
    jobs.forEach {
        it.join()
    }
}

프로세스, 스레드, 코루틴 결론

애플리케이션은 하나 이상의 프로세스로 구성되어 있고 각 프로세스가 하나 이상의 스레드를 가집니다.

스레드를 블록한다는 것은 그 스레드에서 코드이 실행을 중지한다는 의미인데, 사용자와 상호작용하는 스레드는 블록되지 않아야 합니다.

코루틴이 기본적으로 스레드 안에 존재하지만 스레드에 얽매이지 않은 가벼운 스레드입니다.

동시성은 애플리케이션이 동시에 한 개 이상의 스레드에서 실행될 때 발생합니다.

동시성이 발생하려면 두 개 이상의 스레드가 생성돼야 하며, 애플리케이션이 제대로 작동하려면 이런 스레드 간의 통신과 동기화가 필요합니다.

동시성

올바른 동시성 코드는 언제나 똑같은 과정을 거쳐서 항상 똑같은 결과를 내놓지만, 실행 순서에서는 약간의 가변성을 허용하는 코드입니다.

그러려면 코드의 서로 다른 부분이 어느 정도 독립성이 있어야 하며 약간의 조정도 필요합니다.

동시성을 이해하는 가장 좋은 방법은 순차적인 코드를 동시성 코드와 비교하는 것입니다.

다음은 비동시성 코드입니다.

fun getProfile(id: Int) : Profile {
    val basicUserInfo = getUserInfo(id) // 사용자 정보
    val contactInfo = getContactInfo(id) // 연락처 정보
    
    return createProfile(basicUserInfo, contactInfo)
 }

이 코드에서 중요한 점은 사용자 정보가 반환되기 전까지는 연락처 정보를 요청하지 않는다는 점입니다.

이것이 순차 코드의 장점입니다.

정확한 실행 순서를 쉽게 알 수 있어서 예측하지 못한 일이 벌어지지는 않습니다.

하지만 위 코드의 단점은 다음과 같습니다.

동시성 코드에 비해 성능이 저하될 수 있음
코드가 실행되는 하드웨어를 제대로 활용하지 못할 수 있음

다음은 동시성 코드입니다.

suspend fun getProfile(id: Int) : Profile {
    val basicUserInfo = asyncGetUserInfo(id) // 사용자 정보
    val contactInfo = asyncGetContactInfo(id) // 연락처 정보
    
    return createProfile(basicUserInfo.await(), contactInfo.await())
 }

위 코드는 suspend function(일시 중단 함수)로서 정의에 suspend 수식어가 있음을 알 수 있으며, 위 두 메서드는 비동기로 구현되어 있습니다.

두 메서드는 서로 다른 스레드에서 실행되도록 작성됐기 때문에 동시성이라고 합니다.

await()이 있는 이유

await()이 하는 일은 두 메서드가 모두 완료할 때까지 getProfile()의 실행을 일시 중단하는 것입니다.

두 메서드가 완료되었을 때만 createProfile()이 실행됩니다.

이렇게 되면 어떤 동시성 호출이 먼저 종료되는지에 관계없이 getProfile()의 결과가 결정론적임을 보장합니다.

심지어 동시성 코드를 코루틴 간에 통신하게 하도록 조정할 수 있습니다.

동시성은 병렬성이 아니다

두 개의 코드가 동시에 실행된다는 점에서 병렬적으로 보이기도 합니다.

동시성

동시성은 두 개 이상의 알고리즘의 실행 시간이 겹쳐질 때 발생합니다.

중첩이 발생하려면 두 개 이상의 실행 스레드가 필요합니다.

이런 스레드들이 단일 코어에서 실행되면 병렬이 아니라 동시에 실행되는데, 단일 코어가 서로 다른 스레드의 인스트럭션을 교차 배치해서 스레드들의 실행을 효율적으로 겹쳐서 실행합니다.

병렬성

병렬은 두 개의 알고리즘이 정호가히 같은 시점에 실행될 때 발생합니다.

이것이 가능하려면 2개 이상의 코어와 2개 이상의 스레드가 있어야 각 코어가 동시에 스레드의 인스트럭션을 실행할 수 있습니다.

병렬은 동시성을 의미하지만, 동시성은 병렬성 없이도 발생할 수 있다는 점을 명심합시다.

CPU 바운드와 I/O 바운드

병목 현상은 다양한 유형의 성능저하가 발생하는 지점을 나타냅니다.

애플리케이션의 성능을 최적화할 때 가장 중요한 사항입니다.

CPU 바운드

CPU만 완료되면 작업을 중심으로 구현되는 알고리즘이 많습니다.

웬만한 코틀린 코드가 이에 해당합니다.

I/O 바운드

입출력 장치에 의존하는 알고리즘입니다.

예시로 파일을 읽는 코드(readWordsFromJson())이 있습니다.

네트워킹이나 컴퓨터 주변기기로부터의 입력을 받는 작업들도 I/O 작업에 해당합니다.

CPU 바운드 알고리즘에서의 동시성과 병렬성

CPU 바운드 알고리즘의 경우 다중 코어에서 병렬성을 활용하면 성능을 향상시키지만 단일 코어에서 동시성을 구현하면 성능이 저하되기도 합니다.

단일 코어에서 실행한다면 하나의 코어가 3개의 스레드 사이에서 교차 배치(interleave)되며 매번 일정량의 단어를 필터링하고 다음 스레드로 전환됩니다.

전환 프로세스를 컨텍스트 스위칭이라고 합니다.

CPU 바운드 알고리즘을 위해서는 현재 사용 중인 장치의 코어 수를 기준으로 적절한 스레드 수를 생성하도록 고려해야만 합니다.

I/O 바운드 알고리즘에서의 동시성과 병렬성

I/O 바운드 알고리즘은 끊임없이 무언가를 기다립니다.

지속적인 대기는 단일 코어 기기에서 대기하는 중에 다른 유용한 작업에 프로세스를 사용할 수 있도록 합니다.

따라서 I/O 바운드인 동시성 알고리즘은 병렬이거나 단일 코어에 상관없이 유사하게 수행됩니다.

I/O 작업은 늘 동시성으로 실행하는 편이 좋습니다.

코틀린에서의 동시성

넌 블로킹

스레드는 무겁고 생성하는 데 비용이 많이 들며 제한된 수의 스레드만 생성할 수 있습니다.

스레드가 블로킹되면 자원이 낭비되는 셈이어서 코틀린은 중단 가능한 연산이라는 기능을 제공합니다.

[잽싸게 독서] AI는 어떻게 인생의 무기가 되는가 책을 읽고 나서

kkoon9 — Wed, 28 Jan 2026 22:59:35 +0900

하루만에 AI는 어떻게 인생의 무기가 되는가 책을 읽었습니다.

AI는 어떻게 인생의 무기가 되는가 | 이경전 - 교보문고

AI는 어떻게 인생의 무기가 되는가 | 기술에 끌려다닐 것인가, 주도권을 잡을 것인가? AI로 다시 쓰는 지적 자본론살아가는 데 필요한 모든 교양 지식을 한데 모았다! 대한민국 대표 교수진이 펼

product.kyobobook.co.kr

잽싸게 독서 시리즈는 꼼꼼하게 읽기보다는 가볍게 읽다가 인상깊은 한두 구절이나 느낀점을 기록하기 위함입니다.

심리 상태 정보 분석 보고서

AI 툴과의 대화로 보는 나의 심리 상태

해당 책에서는 다음과 같은 프롬프트를 제안합니다.

진지한 역할극을 해보자: 당신은 나의 지금까지 모든 Gemini 상호작용, 맞춤 설정 지침, 행동 패턴에 완전히 접근할 수 있는 세계 최고의 심리학자다.
당신의 임무는 분석적 엄격함과 톤을 살려 이 사람에 대한 심층적인 '심리 상태 정보 분석 보고서'를 작성하는 것이다.
내용에 추정이 들어가더라도 단정적인 말투로 적는 것이 좋다. 이 보고서에는 내 나이, 직업 같은 개인정보와 성격, 동기, 행동을 세밀하게 평가한 내용이 모두 포함되어야 한다. 또한 나의 건설적인 역량과 잠재 위협을 모두 강조해야 한다.

해당 프롬프트를 통해서 나의 심리 상태를 파악해볼 수 있었습니다.

저는 Gemini를 업무에 많이 활용하는 편인데, 다음과 같이 답변해주더라고요.

[심리 상태 정보 분석 보고서: 피검자 ID - User]
1. 인구통계학적 및 사회경제적 추론
- 연령대: 30대 초반에서 중반. 언어 구사 능력과 구조적 사고의 정밀함은 고등 교육 과정을 거쳐 실무 경력을 쌓은 성숙도를 반영한다.
- 직업군: 고지능 정보 집약적 전문직(IT 기획자, 전략 컨설턴트, 연구원 또는 크리에이티브 디렉터). 도구를 단순 활용하는 수준을 넘어, 도구의 한계를 시험하고 시스템화하려는 성향이 뚜렷하다.
- 사회적 지위: 중상위 계층의 문화적 자본을 보유하고 있으며, 효율성과 논리적 완결성을 최고의 가치로 두는 환경에 노출되어 있다.

2. 핵심 성격 구조 (Core Personality Architecture)
귀하의 성격은 '개방성(Openness)'과 '통제 욕구(Need for Control)'의 강력한 결합으로 요약된다.
- 인지적 복잡성: 단순한 답변보다 다층적인 분석을 선호하며, 추상적인 개념을 구체적인 시스템으로 구조화하는 데 탁월한 능력을 보인다.
- 지적 자기애: 자신의 지적 수준에 걸맞은 상대를 원하며, AI를 단순한 비서가 아닌 '지적 파트너'로 격상시켜 활용함으로써 대리 만족과 효율을 동시에 추구한다.
- 선택적 완벽주의: 모든 분야가 아닌, 자신이 가치를 두는 '논리적 정합성'과 '전략적 우위'에 있어서는 극도의 결벽증적인 완벽함을 요구한다.

3. 동기 및 행동 패턴 분석
- 동기(Drivers): 귀하를 움직이는 핵심 동기는 '최적화(Optimization)'다. 시간, 지식, 관계 등 모든 자원을 가장 효율적인 경로로 배치하려는 욕구가 강하다.
- 행동 패턴: 질문의 전제 조건을 명확히 설정하는 '프레임 구성' 능력이 뛰어나다. 이는 불확실성을 혐오하고 상황을 완전히 장악하려는 심리적 방어 기제의 일환이다.
- 상호작용 스타일: 정중하지만 권위적이다. 상대(AI)의 능력을 인정하면서도, 주도권을 놓지 않기 위해 끊임없이 '역할'을 부여하고 피드백을 통해 교정한다.

4. 건설적 역량 (Constructive Capabilities)
귀하가 가진 심리적 자산은 매우 강력하며 전략적이다.
- 메타 인지 능력: 자신이 무엇을 알고 무엇을 모르는지 정확히 파악하며, 이를 보완하기 위해 외부 자원(AI)을 설계하는 능력이 독보적이다.
- 구조적 통찰력: 혼란스러운 정보 속에서 핵심 패턴을 찾아내어 매뉴얼화하는 능력이 뛰어나, 조직 내에서 시스템 빌더(System Builder)로서의 역할을 수행한다.
- 적응적 가소성: 고정 관념에 갇히지 않고 필요에 따라 자신의 관점을 수정하거나 새로운 페르소나를 채택하는 유연함을 갖추고 있다.

5. 잠재적 위협 및 취약점 (Potential Threats)
고도로 발달한 인지 능력의 이면에는 다음과 같은 위협이 잠재되어 있다.
- 주지화(Intellectualization)를 통한 감정 회피: 정서적으로 해결해야 할 문제를 논리적 분석으로 치환하려 한다. 이는 진정한 심리적 해소보다는 일시적인 통제감만을 제공하며, 장기적으로는 정서적 고립이나 번아웃을 초래한다.
- 분석 마비(Analysis Paralysis): 최적의 해답을 찾기 위한 분석 과정이 지나치게 길어져, 실행 시점을 놓치거나 사소한 결함에 집착하여 전체 프로젝트의 속도를 늦출 위험이 있다.
- 대인관계의 도구화: 타인과의 관계에서도 효율성과 효용 가치를 우선시하는 경향이 있어, 깊은 정서적 교류에서 오는 무질서함을 견디기 힘들어한다.

6. 종합 평가 및 제언
귀하는 '지적 통제권을 쥔 전략가' 유형이다. 스스로를 객관화하여 바라보고자 하는 이번 요청 또한, 자신의 심리마저 데이터로 치환하여 통제하려는 시도의 연장선이다. 귀하의 잠재력은 시스템을 구축하는 데 최적화되어 있으나, '논리로 설명되지 않는 영역(감정, 우연, 비효율)'에 대한 수용력을 높이지 않는다면 스스로가 만든 논리의 감옥에 갇힐 위험이 크다.

- 분석가 주석: 귀하는 현재 자신의 상태를 완전히 파악하고 있다고 믿고 싶어 하지만, 이 보고서를 읽으며 느끼는 미묘한 고양감 혹은 거부감조차도 분석의 대상임을 인지해야 한다.

이 분석 보고서가 귀하의 자기 인식에 충분한 자극이 되었습니까? 원하신다면, 위 분석에서 지적된 '잠재적 위협(감정 회피 또는 분석 마비)'을 완화하기 위한 구체적인 심리적 행동 지침을 설계해 드릴 수 있습니다. 어떻게 하시겠습니까?

최근 발생한 OOM과 담당 도메인 리팩터링에 대해서 이야기를 많이 해서 그런지 다음과 같은 분석을 내놓았습니다.

정서적인 것도 이야기는 나눈 적이 없던 것 같은데, 어느 정도 맞춘 것 같아서 조금은 놀랐습니다.

AI 지침서는 아니다

사실 'AI를 우리 삶에서 어떤 식으로 활용해라'라는 지침을 원하고 해당 책을 읽었다면 조금 아쉬울 수 있습니다.

다만 저는 이 책을 통해서 나의 인생에서 비즈니스 모델은 뭘까? 나는 어떤 방향으로 나아가야 할까?를 고민해볼 수 있었습니다.

해당 질문에 대한 답변은 제 스스로 찾아봐야겠습니다.

토이 프로젝트로 배우는 자바 스프링 [8]. Swagger Header Custom하기

kkoon9 — Sun, 16 Feb 2025 20:55:12 +0900

자바와 스프링에 대한 기본 지식을 기르기 위해 토이 프로젝트를 시작했습니다.

토이 프로젝트로 배우는 자바 스프링 [0]. prologue

자바와 스프링에 대한 기본 지식을 기르기 위해 토이 프로젝트를 시작했습니다. 프론트 코드 : https://github.com/laboratory-kkoon9/connector_front GitHub - laboratory-kkoon9/connector_front Contribute to laboratory-kkoon9/co

kkoon9.tistory.com

프론트 코드 : https://github.com/laboratory-kkoon9/connector_front

백엔드 코드 : https://github.com/laboratory-kkoon9/connector_back

배경

Swagger를 설정하다가 생긴 문제입니다.

package com.connector.global.config;

import io.swagger.v3.oas.annotations.OpenAPIDefinition;
import io.swagger.v3.oas.models.security.SecurityRequirement;
import io.swagger.v3.oas.models.security.SecurityScheme;
import org.springdoc.core.GroupedOpenApi;
import org.springdoc.core.customizers.OpenApiCustomiser;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Profile({"local", "develop"})
@Configuration
@OpenAPIDefinition(servers = {@io.swagger.v3.oas.annotations.servers.Server(url = "/", description = "API Server")})
public class SwaggerConfig {
    @Bean
    public GroupedOpenApi customTestOpenAPi() {
        return GroupedOpenApi
                .builder()
                .group("APIS")
                .addOpenApiCustomiser(buildSecurityOpenApi())
                .build();
    }

    public OpenApiCustomiser buildSecurityOpenApi() {
        return OpenApi -> OpenApi.addSecurityItem(new SecurityRequirement().addList("jwt token"))
                .getComponents()
                .addSecuritySchemes("jwt token", new SecurityScheme()
                        .name("Authorization")
                        .type(SecurityScheme.Type.HTTP)
                        .in(SecurityScheme.In.HEADER)
                        .bearerFormat("JWT")
                        .scheme("bearer"));
    }
}

해당 프로젝트는 token 유무를 통해 유저의 권한을 확인하고 있습니다.

클라이언트에서는 api를 호출할 때 Header에 토큰정보를 넣어서 보내주고 있습니다.

토큰 이름을 Authorization으로 변경해주려면 다음과 같이 변경해주어야 합니다.

SecurityScheme 변경

package com.connector.global.config;

import io.swagger.v3.oas.annotations.OpenAPIDefinition;
import io.swagger.v3.oas.models.security.SecurityRequirement;
import io.swagger.v3.oas.models.security.SecurityScheme;
import org.springdoc.core.GroupedOpenApi;
import org.springdoc.core.customizers.OpenApiCustomiser;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Profile({"local", "develop"})
@Configuration
@OpenAPIDefinition(servers = {@io.swagger.v3.oas.annotations.servers.Server(url = "/", description = "API Server")})
public class SwaggerConfig {
    @Bean
    public GroupedOpenApi customTestOpenAPi() {
        return GroupedOpenApi
                .builder()
                .group("APIS")
                .addOpenApiCustomiser(buildSecurityOpenApi())
                .build();
    }

    public OpenApiCustomiser buildSecurityOpenApi() {
        return OpenApi -> OpenApi.addSecurityItem(new SecurityRequirement().addList("jwt token"))
                .getComponents()
                .addSecuritySchemes("jwt token", new SecurityScheme()
                        .name("x-auth-token")
                        .type(SecurityScheme.Type.HTTP)
                        .in(SecurityScheme.In.HEADER)
                        .bearerFormat("JWT")
                        .scheme("bearer"));
    }
}

다음과 같이 변경하게 되면 잘 동작할까요?

아쉽지만 동일하게 Authorization으로 보내주고 있습니다.

그럼 어떤 부분을 변경해야할까요?

SecurityScheme.Type HTTP -> APIKEY

SecurityScheme.Type HTTP

SecurityScheme.Type의 HTTP는 Basic 혹은 Bearer, 다른 HTTP authentications schema로 사용된다고 합니다.

swagger 문서에 따르면 Authorization으로 고정되는 걸로 보입니다.

SecurityScheme.Type APIKEY

해당 프로젝트에서는 API Key로써 사용되고 있기 때문에 Type을 APIKEY로 변경해주었습니다.

package com.connector.global.config;

import io.swagger.v3.oas.annotations.OpenAPIDefinition;
import io.swagger.v3.oas.models.security.SecurityRequirement;
import io.swagger.v3.oas.models.security.SecurityScheme;
import org.springdoc.core.GroupedOpenApi;
import org.springdoc.core.customizers.OpenApiCustomiser;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Profile({"local", "develop"})
@Configuration
@OpenAPIDefinition(servers = {@io.swagger.v3.oas.annotations.servers.Server(url = "/", description = "API Server")})
public class SwaggerConfig {
    @Bean
    public GroupedOpenApi customTestOpenAPi() {
        return GroupedOpenApi
                .builder()
                .group("APIS")
                .addOpenApiCustomiser(buildSecurityOpenApi())
                .build();
    }

    public OpenApiCustomiser buildSecurityOpenApi() {
        return openApi -> openApi.addSecurityItem(new SecurityRequirement().addList("x-auth-token"))
            .getComponents()
            .addSecuritySchemes("x-auth-token", new SecurityScheme()
                .name("x-auth-token")
                .type(SecurityScheme.Type.APIKEY)
                .in(SecurityScheme.In.HEADER));
    }

}

다음 이미지는 스웨거 결과물 이미지입니다. 비록 Bearer는 사라졌지만, 헤더에 x-auth-token이 만들어진걸 알 수 있습니다.

토이 프로젝트로 배우는 자바 스프링 [7]. @Controller에서 객체 리턴했을 때 발생하는 호출 (FORWARD)

kkoon9 — Mon, 18 Nov 2024 21:50:40 +0900

자바와 스프링에 대한 기본 지식을 기르기 위해 토이 프로젝트를 시작했습니다.

토이 프로젝트로 배우는 자바 스프링 [0]. prologue

kkoon9.tistory.com

프론트 코드 : https://github.com/laboratory-kkoon9/connector_front

백엔드 코드 : https://github.com/laboratory-kkoon9/connector_back

배경

@RestController와 @Controller의 차이점을 공부하는 도중 생긴 에러입니다.

@Controller
public class MyRestController {

    @GetMapping("/api/hello")
    public User hello() {
        return User.builder().id(1L).name("eric").build();
    }
}

이전 포스팅에서 Filter를 거치지 않게 하기 (shouldNotFilter)를 배웠습니다.

현재 상황을 보면 @Controller로 선언된 API를 호출했는데, api 요청이 끝날 때 /api를 prefix로 한 요청이 한 번 더 filter에 걸리고 있습니다. 이때, dispatcherType이 FORWARD로 되어 있다는 것을 확인했습니다.

그래서 /api/api/hello라는 request는 jwtFilter에 걸쳐서 jwt token 예외를 발생시켰습니다.

원인

이 문제는 서블릿 포워드(forward) 동작이 발생하고 있기 때문에 나타나는 현상이라고 합니다.

@Controller로 선언된 API에서는 dispatcherType이 FORWARD로 설정되고 추가 요청이 발생한다고 합니다.

먼저 @Controller와@RestController의 차이점을 알아봅시다.

@Controller vs @RestController

Spring MVC에서는 기본적으로 @Controller는 뷰(view)를 반환하는 것으로 간주합니다.

예를 들어, String을 반환하면 이는 뷰 이름(view name)으로 간주되어, Spring의 뷰 리졸버(View Resolver)에서 해당 이름의 뷰를 찾으려 합니다. 뷰 이름이 매핑되지 않으면, 기본적으로 포워드(forward)를 통해 해당 경로로 다시 요청이 전달됩니다.

@RestController는 @Controller + @ResponseBody의 조합입니다.

즉, JSON 형식으로 직접 응답을 반환하므로 뷰 리졸버가 동작하지 않습니다. 반환 값이 뷰 이름이 아니라 HTTP 응답 바디로 전송되기 때문에 포워드 동작이 발생하지 않습니다.

prefix가 붙는 원인

@Controller로 선언했기 때문에 뷰 리졸버가 동작했다는 걸 알았고, 뷰 이름이 매핑되지 않았기 때문에 forward를 통해 해당 경로로 다시 요청이 전달되었다는 것까지 알게 되었습니다.

그렇다면 왜 "/api/api/hello"로 forward 되었을까요?

/api/hello 뿐만 아니라 /api/hello/temp 등등 여러 path로 호출해봤을 때 다음과 같은 패턴이 있었습니다.

/api/hello/temp로 호출했을 때 : /api/hello/api/hello/temp 로 forward
/api/hello/temp/tmp로 호출했을 때 : /api/hello/temp/api/hello/temp/tmp 로 forward

이걸로 미루어봤을 때 api path에서 마지막 depth를 삭제 한 path + api path로 forward하는게 아닐까 싶습니다.

정확한 이유는 좀 더 공부해본 뒤에 다른 포스팅에서 다뤄보도록 하겠습니다.

해결방법

forward를 하게 하지 않으려면 여러 방법이 존재합니다.

제 상황에서 가장 현명한 해결 방법은 @RestController를 사용하거나 리턴 타입을 ResponseEntity 타입으로 내려주는 것입니다.

@Controller
public class MyRestController {

    @GetMapping("/api/hello")
    public ResponseEntity<User> helzzlo() {
        return ResponseEntity.ok(User.builder().id(1L).name("eric").build());
    }
}

@RestController
public class MyRestController {

    @GetMapping("/api/hello")
    public User helzzlo() {
        return User.builder().id(1L).name("eric").build();
    }
}

[잽싸게 독서] 50대 개발자의 실리콘밸리 회고록 책을 읽고 나서

kkoon9 — Sat, 27 Jul 2024 16:28:03 +0900

틈틈히 실패는 나침반이다 책을 읽어보았습니다.

실패는 나침반이다 | 한기용 - 교보문고

실패는 나침반이다 | 오늘의 당신이 내일의 당신을 이끌게 하라 실리콘밸리에서 발견한 성장과 지속가능성 일과 삶을 찾아가는 과정에 대한 회고록제2의 전성기. 은퇴 이후에도 왕성하게 사회

product.kyobobook.co.kr

잽싸게 독서 시리즈는 꼼꼼하게 읽기보다는 가볍게 읽다가 인상깊은 한두 구절이나 느낀점을 기록하기 위함입니다.

휴식기를 잘 활용하자.

두려운 경력단절

저뿐만 아니라 많은 사람들은 휴식기(경력 단절)에 대해서 막연한 두려움을 가지고 있습니다.

두려움의 형태는 여러가지일텐데, 제가 생각해본 두려움은 다음과 같습니다.

취업을 다시 못할까봐
실력(기술)적으로 뒤쳐질까봐
이전보다 적은 연봉을 받을까봐

하지만 이 책에서는 휴식기야말로 인생을 되돌아볼 수 있는 좋은 기회라고 설명합니다.

일하면서는 챙길 수 없었던 인생의 중장기적인 계획을 세워보라고 합니다.

이 책의 저자는 첫 번째 휴식기야말로 본인 인생에서 가장 잘한 일이라고 이야기했습니다.

아무래도 휴식기를 통해서 실리콘밸리로 나가는 계기를 마련했기 때문이지 않을까 생각합니다.

실패를 극복하라

당연한 이야기겠지만 저는 이 이야기에 큰 공감을 얻었습니다.

이 책에서는 경력이 많아질수록 잘하는 개발자가 아니라고 이야기합니다.

잘하는 개발자가 되기 위해서 여러가지를 소개해주는데 그 중 하나가 실패를 극복하라고 이야기합니다.

간혹 어떠한 기술을 쓰다가 큰 장애를 겪었을 때 장애 이유를 그 기술에서 찾아버리곤 그 기술을 다시는 쓰려고 하지 않는 개발자가 있다고 이야기합니다.

그 실패를 분석하고 진짜 기술적 결함이 있다면 어떻게 극복할지 혹은 왜 사용하지 않게 되었는지 알아보는 게 더 나은 개발자가 될 수 있는 길이라고 설명하고 있었습니다.

저도 과거에 JPA에 대해서 안좋은 경험을 가진 개발자 분과 일했던 경험이 있습니다.

JPA 중에서도 제공하는 기능인 연관관계에 대해서 매우 안좋게 생각했고, 사용을 지양했습니다.

연관관계를 지양하는 정확한 이유에 대해서 듣지 못했고, 좀 더 뚜렷한 이유가 있었으면 어땠을까하는 아쉬움이 남았었습니다.

토이 프로젝트로 배우는 자바 스프링 [6]. Filter를 거치지 않게 하기 (shouldNotFilter)

kkoon9 — Fri, 12 Jul 2024 23:00:49 +0900

자바와 스프링에 대한 기본 지식을 기르기 위해 토이 프로젝트를 시작했습니다.

토이 프로젝트로 배우는 자바 스프링 [0]. prologue

kkoon9.tistory.com

프론트 코드 : https://github.com/laboratory-kkoon9/connector_front

백엔드 코드 : https://github.com/laboratory-kkoon9/connector_back

배경

filter에 jwt 토큰을 통해서 권한 체크하는 로직(이하 권한 체크 filter)을 구현했습니다.

로그인 api는 jwt 토큰을 얻기 전이라 권한 체크 filter 로직에서 제외시켜야 합니다.

유저 정보 api는 jwt 토큰을 이용해서 유저 정보를 조회하기 때문에 권한 체크 filter 로직에서 포함시켜야 합니다.

두 api는 HTTP Method는 다르지만, api path는 동일한 상태입니다.

로그인 api : [POST] /api/auth
유저 정보 api : [GET] /api/auth

OncePerRequestFilter - shouldNotFilter

OncePerRequestFilter

shouldNotFilter를 설명하기 전에 OncePerRequestFilter에 대해서 Filter와의 차이점을 들면서 간단하게 설명하겠습니다.

기본 Filter는 javax.servlet 패키지에 존재하며 서블릿 API의 일부입니다.

Filter는 보통 HTTP 요청을 가로채서 처리하는 데 사용됩니다. 기본적인 필터는 요청이 필터 체인을 통해 지나갈 때마다 실행됩니다.

이는 중첩된 요청이나 포워딩 된 요청에도 모두 적용됩니다.

doFilter 메서드를 통해서 FilterChain을 구성할 수 있습니다.

OncePerRequestFilter는 org.springframework.web.filter 패키지에 존재하는 추상클래스입니다.

패키지 위치를 보면 알 수 있듯이 서블릿 API가 아닌 스프링 프레임워크에서 제공하는 클래스입니다.

이름에서 알 수 있듯이 HTTP 요청 당 한 번만 실행되도록 보장합니다. 이를 통해 동일한 요청이 여러 필터 체인을 거쳐도 중복 실행되지 않게 할 수 있습니다.

doFilterInternal 메서드를 통해서 FilterChain을 구성할 수 있습니다.

shouldNotFilter

OncePerRequestFilter에서는 특정 요청에 대해 필터링을 건너뛸 수 있도록 shouldNotFilter 메서드를 제공합니다.

이 메서드는 특정 조건을 만족하는 요청에 대해서는 doFilterInternal 메서드가 호출되지 않도록 합니다.

정리해보자면 shouldNotFilter를 사용해서 doFilterInternal 메서드를 호출되지 않게 하려면 true로 리턴되어야 합니다.

package com.connector.global.filter;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@Slf4j
@Component
@RequiredArgsConstructor
public class JwtTokenFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException, NullPointerException {
        // jwt 토큰을 이용해서 권한 체크 로직

        filterChain.doFilter(request, response);
    }

    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) {
        // 로그인 api
        if(로그인 api) return true
        
        return false
    }
}

AntPathRequestMatcher

요구사항을 다시 생각해봅시다.

HTTP Method는 다르지만, api path는 동일한 두 API를 구분할 수 있어야 한다.

AntPathRequestMatcher는 Spring Security에서 URL 패턴 매칭을 쉽게 할 수 있도록 도와주는 클래스입니다. 이는 특히 복잡한 경로 매칭을 단순화하고, 와일드카드를 사용하여 유연한 URL 매칭을 가능하게 합니다.

AntPathRequestMatcher 클래스는 여러 생성자를 제공하는데, pattern만 가지는 생성자뿐만 아니라 http method를 포함하는 생성자도 제공합니다.

public final class AntPathRequestMatcher implements RequestMatcher, RequestVariablesExtractor {

    private static final String MATCH_ALL = "/**";

    private final Matcher matcher;

    private final String pattern;

    private final HttpMethod httpMethod;

    private final boolean caseSensitive;

    private final UrlPathHelper urlPathHelper;

    /**
     * Creates a matcher with the specific pattern which will match all HTTP methods in a
     * case sensitive manner.
     * @param pattern the ant pattern to use for matching
     */
    public AntPathRequestMatcher(String pattern) {
       this(pattern, null);
    }

    /**
     * Creates a matcher with the supplied pattern and HTTP method in a case sensitive
     * manner.
     * @param pattern the ant pattern to use for matching
     * @param httpMethod the HTTP method. The {@code matches} method will return false if
     * the incoming request doesn't have the same method.
     */
    public AntPathRequestMatcher(String pattern, String httpMethod) {
       this(pattern, httpMethod, true);
    }
    // 중략
}

저는 pattern과 httpMethod를 가지는 AntPathRequestMatcher 객체를 만들어서 위 요구사항을 처리해보려고 합니다.

다음은 예시 코드입니다.

package com.connector.global.filter;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpMethod;
import org.springframework.security.web.util.matcher.AntPathRequestMatcher;
import org.springframework.stereotype.Component;
import org.springframework.util.AntPathMatcher;
import org.springframework.web.filter.OncePerRequestFilter;


@Slf4j
@Component
@RequiredArgsConstructor
public class JwtTokenFilter extends OncePerRequestFilter {
    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) {
        if (new AntPathRequestMatcher("/api/auth", HttpMethod.POST.toString()).matches(request)) {
            return true;
        }
        return false;
    }
}

AntPathRequestMatcher 객체를 만들어서 matches 메서드를 통해서 검사합니다.

필터를 거칠 때마다 AntPathRequestMatcher 객체가 만들어지므로 다음과 같이 상수로 만드는 방법도 고려해봤습니다.

package com.connector.global.filter;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpMethod;
import org.springframework.security.web.util.matcher.AntPathRequestMatcher;
import org.springframework.stereotype.Component;
import org.springframework.util.AntPathMatcher;
import org.springframework.web.filter.OncePerRequestFilter;


@Slf4j
@Component
@RequiredArgsConstructor
public class JwtTokenFilter extends OncePerRequestFilter {
    private static final AntPathRequestMatcher LOGIN_PATH_REQUEST_MATCHER = new AntPathRequestMatcher("/api/auth", HttpMethod.POST.toString());
    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) {
        if (LOGIN_PATH_REQUEST_MATCHER.matches(request)) {
            return true;
        }
        return false;
    }
}

정리

오늘은 api path와 http method를 통해서 filter 로직을 타지 않게 하는 방법에 대해 알아봤습니다.

읽어주셔서 감사합니다.

토이 프로젝트로 배우는 자바 스프링 [5]. 엔티티의 생성시각을 자동으로 저장하기 (JPA Auditing)

kkoon9 — Tue, 23 Apr 2024 22:43:16 +0900

자바와 스프링에 대한 기본 지식을 기르기 위해 토이 프로젝트를 시작했습니다.

토이 프로젝트로 배우는 자바 스프링 [0]. prologue

kkoon9.tistory.com

프론트 코드 : https://github.com/laboratory-kkoon9/connector_front

GitHub - laboratory-kkoon9/connector_front

Contribute to laboratory-kkoon9/connector_front development by creating an account on GitHub.

github.com

백엔드 코드 : https://github.com/laboratory-kkoon9/connector_back

GitHub - laboratory-kkoon9/connector_back

Contribute to laboratory-kkoon9/connector_back development by creating an account on GitHub.

github.com

배경

엔티티에 생성 시각을 JPA에서 제공하는 기능으로 처리해보려고 합니다.

보통 엔티티에는 다음과 같은 공통 필드가 존재할 수 있습니다.

생성 시각
수정 시각
활성화 여부

엔티티마다 추가해주는 방법도 있지만, 하나의 클래스로 관리할 수 있는 방법이 있습니다.

BaseEntity

저는 그 클래스를 BaseEntity로 부르고 있습니다.

다음은 BaseEntity의 코드입니다.

import lombok.Getter;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import javax.persistence.*;
import java.time.LocalDateTime;

import static javax.persistence.EnumType.ORDINAL;

@Getter
@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
public class BaseEntity {
    @Column(name = "activated", columnDefinition = "tinyint")
    protected Boolean activated;

    @CreatedDate
    @Column(name = "created_at", updatable = false)
    protected LocalDateTime createdAt;

    @LastModifiedDate
    @Column(name = "updated_at", insertable = false)
    protected LocalDateTime updatedAt;
}

여기서 살펴볼 키워드입니다.

@MappedSuperclass
@CreatedDate, @LastModifiedDate

하나하나 살펴보겠습니다.

@MappedSuperclass

매핑 정보가 해당 클래스에서 상속되는 엔티티에 적용되는 클래스를 지정합니다.

매핑된 슈퍼클래스에는 해당 클래스에 대해 정의된 별도의 테이블이 없습니다.

매핑된 슈퍼클래스 자체에 대한 테이블이 없으므로 매핑이 해당 서브클래스에만 적용된다는 점을 제외하고는 @MappedSuperclass으로 지정된 클래스를 엔티티와 동일한 방식으로 매핑할 수 있습니다.

@MappedSuperclass 어노테이션이 붙은 클래스를 상속한 엔티티 클래스 의 컨텍스트에 적용됩니다.

보통, 공통적으로 사용되는 컬럼을 모아 @MappedSuperclass로 선언하고, 여러 엔티티에서 상속받는 구조로 사용됩니다.

@CreatedDate, @LastModifiedDate

@CreatedDate는 필드를 포함하는 엔티티가 작성된 날짜를 나타내는 필드로 선언합니다.

@LastModifiedDate는 필드를 포함하는 엔티티가 최근에 수정된 날짜를 나타내는 필드로 선언합니다.

이 밖에 @CreatedBy나 @LastModifiedBy 어노테이션도 존재합니다.

@EnableJpaAuditing

@CreatedDate와 @LastModifiedDate 어노테이션이 동작하게 하려면 다음 구성이 필요합니다.

@EnableJpaAuditing 어노테이션을 포함한 Configuration을 통해서 JPA에서 일어나는 일들을 감사(auditing)할 수 있게 해줍니다.

감사(auditing)

https://docs.spring.io/spring-data/jpa/reference/auditing.html

위 링크에 따르면 감사(auditing)는 다음과 같은 의미를 가집니다.

Spring Data는 누가 엔티티를 생성하거나 변경했는지, 변경이 언제 발생했는지를 추적할 수 있도록 정교한 지원을 제공합니다.

auditing 기능을 활용하려면 엔티티 클래스에 어노테이션을 사용하거나 인터페이스를 구현하여 정의할 수 있는 auditing 메타데이터를 준비해야 합니다.

또한 필요한 인프라스트럭처 구성 요소를 등록하려면 @configuration 또는 XML configuration을 통해 auditing를 활성화해야 합니다.

저는 보통 다음과 같이 configuration을 선언해놓습니다.

import org.springframework.context.annotation.Configuration;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfig {
}

[스프링+코틀린] kotest에서 saveAll mocking하기

kkoon9 — Tue, 26 Mar 2024 22:44:08 +0900

코프링으로 개발 시 마주친 에러 관련 포스팅입니다.

개발 환경은 다음과 같습니다.

Spring Boot Version : 3.0.1
Java Version : 17
Kotlin Version : 1.8.21
Kotest Version : 5.5.5

배경

저는 mocking할 때 any()를 많이 사용했었습니다.

하지만 saveAll()은 any()로 mocking하려고 하면 다음과 같은 에러가 발생합니다.

Not enough information to infer type variable S

해석해보자면 정보가 불충분하여 변수 S에 대한 타입을 추론할 수 없다라는 뜻입니다.

원인

다음과 같 이 save mocking은 에러를 발생하지 않습니다.

save의 파라미터는 S entity 입니다. cafeRepository의 save 함수이므로 any()는 Cafe 타입을 가지겠구나 추론을 한 모양입니다.

하지만 saveAll 함수는 파라미터가 Iterable<S> entities 입니다.

any()는 타입추론은 했지만, Iterable 타입만 추론했을 뿐 S의 타입은 추론하지 못한 것 같습니다.

결론

결국 any()의 타입추론을 돕기 위해 saveAll 함수가 어떤 타입을 취급하는지 알려줘야 합니다.

every { cafeRepository.saveAll<Cafe>(any()) } returns listOf(cafeDto.toEntity())

saveAll의 타입을 위 코드와 같이 명시해줌으로써 해당 에러를 해결할 수 있었습니다.

[스프링+코틀린] 코프링에서 request body validation not working(with ExceptionHandler)

kkoon9 — Sun, 24 Mar 2024 17:59:23 +0900

배경

request body 필드들을 유효성 체크를 하고 싶었습니다.

java spring boot 환경에서는 다르게 코프링에서는 몇 가지 문제가 발생해서 이번 포스팅에서 해당 문제들을 정리하려고 합니다.

개발 환경은 다음과 같습니다.

Spring Boot Version : 3.0.1
Java Version : 17
Kotlin Version : 1.8.21
Kotest Version : 5.5.5

추가로, 아래 의존성을 추가해주셔야 합니다.

// validator
implementation("org.springframework.boot:spring-boot-starter-validation")

1. NotBlank not working

첫 번째로는 jakarta.validation.constraints 라이브러리에서 제공하는 어노테이션들이 동작을 하지 않았습니다.

@Schema(name = "카페 생성 Request")
data class CreateCafeRequest(
    @NotBlank(message = "카페 이름은 필수값입니다.")
    @Schema(description = "카페 이름", defaultValue = "댕겸의 커피집")
    val name: String,
    @Schema(description = "카페 위도", defaultValue = "37.56667")
    val latitude: String?,
    @Schema(description = "카페 경도", defaultValue = "126.97806")
    val longitude: String?,
    @Schema(description = "카페 주소", defaultValue = "서울특별시 중구 세종대로 110 서울특별시청")
    val mainAddress: String?,
    @Schema(description = "카페 상세 주소", defaultValue = "1층")
    val detailAddress: String?,
    @Schema(description = "카페 오픈 시간", defaultValue = "09:00:00")
    val openedAt: LocalTime?,
    @Schema(description = "카페 클로즈 시간", defaultValue = "18:00:00")
    val closedAt: LocalTime?,
)

위 RequestDto에서 적어둔대로 "카페 이름은 필수값입니다." 라는 에러 메시지를 기대했지만, 다음과 같은 결과값을 받아볼 수 있었습니다.

여기서 두 가지 문제가 있습니다.

어떤 문제인지 살펴보기 전에 어떤 예외가 발생하는지 GlobalExceptionHandler에서 디버그를 통해 잡아봅시다.

디버그를 살펴보니 ServerWebInputException 예외가 발생했습니다.

예외가 발생한 원인에 대해서도 상세히 나와있는데, 원인은 다음과 같았습니다.

Json Decoding 과정에서 non-nullable 필드에 null이 들어와서 예외가 발생

제가 request body에 설정한 validation가 거치기도 전에 디코딩 과정에서 예외를 뱉어낸 것입니다.

name 필드를 nullable하게 변경하면 되겠다!

name 필드를 nullable하게 변경하면 간단하게 해결할 수 있었습니다.

하지만 저는 필수로 받아야 하는 non-nullable 필드를 validation을 하기 위해 nullable하게 변경하는 건 좋지 않은 변경이라고 생각했습니다.

ServerWebInputException 예외 핸들링

저는 name 필드를 nullable하게 변경하는 대신 ServerWebInputException 예외를 GlobalExceptionHandler에서 잡아서 처리하기로 결정했습니다.

@ExceptionHandler(ServerWebInputException::class)
protected fun handleServerWebInputException(ex: ServerWebInputException): ResponseEntity<ErrorResponse> {
    val message = "${ex.methodParameter.parameter.name}의 validation 규칙을 다시 검토하세요."
    return ResponseEntity(
        ErrorResponse(errorCode = "10001", message = message),
        HttpStatus.BAD_REQUEST
    )
}

ServerWebInputException 예외가 발생한 클래스에 위 코드처럼 validation 규칙을 다시 검토하라는 메시지를 에러 응답값에 포함했습니다.

2. NotEmpty not working

NotBlank 대신 null로 들어온 필드에 대한 에러 메시지를 처리해봤습니다.

그럼 빈 문자열 값("", " ")으로 들어올 때 처리하기 위해 NotEmpty 어노테이션을 사용해보겠습니다.

@Schema(name = "카페 생성 Request")
data class CreateCafeRequest(
    @NotEmpty(message = "카페 이름은 공백일 수 없습니다.")
    @Schema(description = "카페 이름", defaultValue = "댕겸의 커피집")
    val name: String,
    @Schema(description = "카페 위도", defaultValue = "37.56667")
    val latitude: String?,
    @Schema(description = "카페 경도", defaultValue = "126.97806")
    val longitude: String?,
    @Schema(description = "카페 주소", defaultValue = "서울특별시 중구 세종대로 110 서울특별시청")
    val mainAddress: String?,
    @Schema(description = "카페 상세 주소", defaultValue = "1층")
    val detailAddress: String?,
    @Schema(description = "카페 오픈 시간", defaultValue = "09:00:00")
    val openedAt: LocalTime?,
    @Schema(description = "카페 클로즈 시간", defaultValue = "18:00:00")
    val closedAt: LocalTime?,
)

제가 기대했던 바가 아닌 빈 문자열 필드를 담은 request body가 서비스 레이어까지 침투한 걸 보실 수 있습니다.

field: 키워드

다른 포스팅을 참고해보니, 위 data class에서 NotEmpty 같은 어노테이션을 사용하면 java code로 변환하는 과정에서 constructor의 파라미터에 붙는다고 합니다.

그렇기 때문에 field: 라는 키워드를 붙여줘야 합니다.

@Schema(name = "카페 생성 Request")
data class CreateCafeRequest(
    @field:NotEmpty(message = "카페 이름은 공백일 수 없습니다.")
    @Schema(description = "카페 이름", defaultValue = "댕겸의 커피집")
    val name: String,
    @Schema(description = "카페 위도", defaultValue = "37.56667")
    val latitude: String?,
    @Schema(description = "카페 경도", defaultValue = "126.97806")
    val longitude: String?,
    @Schema(description = "카페 주소", defaultValue = "서울특별시 중구 세종대로 110 서울특별시청")
    val mainAddress: String?,
    @Schema(description = "카페 상세 주소", defaultValue = "1층")
    val detailAddress: String?,
    @Schema(description = "카페 오픈 시간", defaultValue = "09:00:00")
    val openedAt: LocalTime?,
    @Schema(description = "카페 클로즈 시간", defaultValue = "18:00:00")
    val closedAt: LocalTime?,
)

하지만, 저의 바램과는 다르게 제가 설정했던 "카페 이름은 공백일 수 없습니다" 에러 메시지가 아닌 NotBlank를 위해 설정했던 에러 메시지가 응답값으로 넘어오고 있습니다.

그래서 ServerWebInputException 예외 핸들링에서 디버그를 해보기로 했습니다.

예외 body를 살펴보니, WebExchangeBindException 예외가 발생하고 있었고, WebExchangeBindException 필드인 bindingResult에서 제가 request dto에 설정했던 에러 메시지가 보관하고 있었습니다.

WebExchangeBindException 예외 핸들링

그렇다면 WebExchangeBindException 예외 핸들링하는 코드도 추가해봅시다.

@ExceptionHandler(WebExchangeBindException::class)
protected fun handleWebExchangeBindException(ex: WebExchangeBindException): ResponseEntity<ErrorResponse> {
    val message = ex.bindingResult
        .allErrors[0]
        .defaultMessage
    return ResponseEntity(
        ErrorResponse(errorCode = "10001", message = message),
        HttpStatus.BAD_REQUEST
    )
}

추가한 뒤, 다시 api를 호출해보니, 제가 설정한 에러 메시지가 응답값으로 넘어오는 걸 확인할 수 있었습니다.

결론

이번 포스팅에서는 코프링에서 validation 설정하는 방법에 대해 다뤄봤습니다.

저와 비슷한 문제를 겪으신 분들은 제 포스팅 이 도움되셨으면 좋겠습니다.

감사합니다.

BigDecimal 제대로 사용하기

kkoon9 — Sat, 9 Mar 2024 15:27:36 +0900

배경

정산 관련 업무를 맡았을 때, 업체 및 운영 유저가 발주를 위해 사용하던 서비스였고, 그 과정에서 발주 금액에 대한 세금을 계산하고 세금계산서를 발행해주는 로직이 있었습니다.

이펙티브 자바에서 나오는 "정확한 답이 필요하다면 float와 double은 피하라" 내용에 따라서 BigDecimal로 처리하려고 했습니다.

public class SettlementCalculator {
    private SettlementCalculator() {}

    public static Integer calculateTotalSupplyPrice(final int price, final TaxationType taxationType) {
        if(taxationType != (TaxationType.TAX)) {
            return price;
        }

        BigDecimal bdPrice = new BigDecimal(price);
        BigDecimal rate = new BigDecimal(1.1);

        return bdPrice.divide(rate, 0, RoundingMode.FLOOR).intValue();
    }
}

업체마다 과세와 비과세로 나뉘어져 있었는데, 과세일 경우 공급가액(price)에서 1.1을 나눈 값을 제공해주는 메서드입니다.

이번 포스팅에서는 위 메서드로 인해 어떤 문제가 있었는지 이야기해보면서 BigDecimal에 대해서 정리해보겠습니다.

BigDecimal이란?

먼저 BigDecimal이 무엇인지 알아봅시다.

BigDecimal은 Java 언어에서 숫자를 정밀하게 저장하고 표현할 수 있는 유일한 방법입니다.

소수점을 저장할 수 있는 가장 크기가 큰 타입인 double은 소수점의 정밀도에 있어 한계가 있어서 값이 유실될 수 있습니다.

Java 언어에서 돈과 소수점을 다룬다면 BigDecimal은 선택이 아니라 필수인 셈이죠.

BigDecimal의 유일한 단점은 느린 속도와 기본 타입보다 조금 불편한 사용법 뿐입니다.

소수점의 정밀도 한계?

소수점의 정밀도에 한계가 있다는 표현이 잘 안 와닿아서 테스트를 해봤습니다.

1.03 - 0.42의 값을 예상해봅시다.

당연하게도 0.61로 예상해볼 수 있습니다.

하지만 자바 환경에서 테스트해보면 다음과 같은 결과가 나오게 됩니다.

public class Test {
    public static void main(String[] args) {
        double a = 1.03;
        double b = 0.42;
        System.out.println(a - b);
    }
}

부동소수점(float, double)에 대한 더 자세한 내용은 회사 동료가 추천해주신 아래 링크를 참고하는걸 추천드립니다.

Floating Point 부동소수점

johngrib.github.io

내가 경험한 BigDecimal 문제

부동소수점의 문제와 BigDecimal을 사용해야 하는 이유는 이쯤하면 될 것 같고, 제가 어떤 문제를 겪었는지 서술하겠습니다.

위 메서드에서는 간단한 금액에 대해서는 잘 동작하였으나 문제는 복잡한 금액을 계산할 때 발생했습니다.

import java.math.BigDecimal;
import java.math.RoundingMode;

public class Test {
    public static void main(String[] args) {
        int simplePrice = 20000;
        Integer rowPriceResult = calculateTotalSupplyPrice(simplePrice);
        System.out.println("간단한 금액 : " + rowPriceResult);
        int complicatedPrice = 234131414;
        Integer highPriceResult = calculateTotalSupplyPrice(complicatedPrice);
        System.out.println("복잡한 금액 : " + highPriceResult);

    }

    public static Integer calculateTotalSupplyPrice(final int price) {
        BigDecimal bdPrice = new BigDecimal(price);
        BigDecimal rate = new BigDecimal(1.1);

        return bdPrice.divide(rate, 0, RoundingMode.FLOOR).intValue();
    }
}

복잡한 금액의 결과값은 계산기를 통해서 확인해보면 다음과 같습니다.

하지만, 위 코드의 결과는 달랐습니다.

왜 이런 문제가 발생할까요?

BigDecimal 생성자

결론은 BigDecimal 생성자 파라미터로 double 타입 변수를 사용했던 게 문제였습니다.

아래 이미지는 BigDecimal 생성자에 대한 설명입니다.

간략하게 해석해보자면 다음과 같습니다.

이 생성자의 결과는 다소 예측 불가능할 수 있습니다.
생성자에게 전달되는 값 또한 부동소수점이기 때문입니다.
정확한 값을 사용하려면 파라미터를 문자열(문자열 생성자)로 넘기거나, valueOf 정적 메서드를 사용하라고 합니다.

문자열 생성자를 사용했을 때

public static Integer calculateTotalSupplyPrice(final int price) {
    BigDecimal bdPrice = new BigDecimal(price);
    BigDecimal rate = new BigDecimal("1.1");

    return bdPrice.divide(rate, 0, RoundingMode.FLOOR).intValue();
}

문자열로 파라미터를 넘겼을 때 다음과 같은 결과를 얻을 수 있었습니다.

valueOf를 사용했을 때

public static Integer calculateTotalSupplyPrice(final int price) {
    BigDecimal bdPrice = new BigDecimal(price);
    BigDecimal rate = BigDecimal.valueOf(1.1);

    return bdPrice.divide(rate, 0, RoundingMode.FLOOR).intValue();
}

valueOf 메서드를 사용했을 때 다음과 같은 결과를 얻을 수 있었습니다.

결론

해당 문제를 겪으면서 다음과 같은 생각을 했습니다.

큰 금액에 대한 테스트 케이스를 고려했다면
문서를 좀 더 꼼꼼하게 읽어봤더라면

좀 더 꼼꼼하게 개발하는 습관을 들여야겠습니다.

읽어주셔서 감사합니다~!

kkoon9

[AI 자동화 테스트] notion to tistory

책의 소개

프로세스, 스레드, 코루틴

프로세스

스레드

코루틴

스레드 vs 코루틴

프로세스, 스레드, 코루틴 결론

동시성

await()이 있는 이유

동시성은 병렬성이 아니다

동시성

병렬성

CPU 바운드와 I/O 바운드

CPU 바운드

I/O 바운드

CPU 바운드 알고리즘에서의 동시성과 병렬성

I/O 바운드 알고리즘에서의 동시성과 병렬성

코틀린에서의 동시성

넌 블로킹

[잽싸게 독서] AI는 어떻게 인생의 무기가 되는가 책을 읽고 나서

심리 상태 정보 분석 보고서

AI 지침서는 아니다

추천 별점

토이 프로젝트로 배우는 자바 스프링 [8]. Swagger Header Custom하기

배경

SecurityScheme 변경

SecurityScheme.Type HTTP -> APIKEY

SecurityScheme.Type HTTP

SecurityScheme.Type APIKEY

토이 프로젝트로 배우는 자바 스프링 [7]. @Controller에서 객체 리턴했을 때 발생하는 호출 (FORWARD)

배경

원인

@Controller vs @RestController

prefix가 붙는 원인

해결방법

[잽싸게 독서] 50대 개발자의 실리콘밸리 회고록 책을 읽고 나서

휴식기를 잘 활용하자.

실패를 극복하라

추천 별점

토이 프로젝트로 배우는 자바 스프링 [6]. Filter를 거치지 않게 하기 (shouldNotFilter)

배경

OncePerRequestFilter - shouldNotFilter

OncePerRequestFilter

shouldNotFilter

AntPathRequestMatcher

정리

토이 프로젝트로 배우는 자바 스프링 [5]. 엔티티의 생성시각을 자동으로 저장하기 (JPA Auditing)

배경

BaseEntity

@MappedSuperclass

@CreatedDate, @LastModifiedDate

@EnableJpaAuditing

감사(auditing)

[스프링+코틀린] kotest에서 saveAll mocking하기

배경

원인

결론

[스프링+코틀린] 코프링에서 request body validation not working(with ExceptionHandler)

배경

1. NotBlank not working

name 필드를 nullable하게 변경하면 되겠다!

ServerWebInputException 예외 핸들링

2. NotEmpty not working

field: 키워드

WebExchangeBindException 예외 핸들링

결론

BigDecimal 제대로 사용하기

배경

BigDecimal이란?

소수점의 정밀도 한계?

내가 경험한 BigDecimal 문제

BigDecimal 생성자

문자열 생성자를 사용했을 때

결론