yeseul.log

[spring-batch] 생에 처음으로 오픈 소스에 기여를 해보다

예슬 — Tue, 3 Feb 2026 21:25:13 +0900

오픈 소스라는 존재에 대해서는 "언제 한번쯤은 기여해보고 싶다"는 마음은 항상있었지만,

막연하게만 생각하고 있었습니다.

그러다 우연히 오픈소스 기여 모임이라는 곳을 알게 되었습니다.

오픈소스 기여모임

“누구나 원하는 오픈소스에 기여를” 할 수 있게 기여를 직접 돕습니다!

medium.com

초심자 분들께도 체계적으로 가이드를 주신다는 후기를 봤기 때문에 이번에는 꼭 오픈 소스에 기여를 해보겠다는 생각으로 일단 참가부터 했던 것 같습니다.

오픈소스 기여 모임 10기 모집 글

Spring Batch를 선택한 이유

기여할 프로젝트를 고를 때, 고민 없이 spring-batch를 선택했습니다.

spring-batch는 저에게 꽤 특별한 프로젝트입니다. 본격적인 개발 스터디를 시작한 게 바로 spring-batch 스터디였기 때문입니다.

특히 최근에 스프링 배치 관련 책을 잠시 읽으면서 더욱 흥미를 가지게 되었습니다.

정확히 기억은 안나지만, 책의 서문에서 "백그라운드에서 항상 돌아가고 있지만 - 유저는 느끼지 못하는 서비스"라는 표현 때문이었던 것 같습니다.

이 표현을 보고 배치 서비스야말로 진짜 '백엔드'라는 느낌이었습니다. 그래서 백엔드 개발자로서 그런 부분을 더 깊이 이해하고 싶어 자연스럽게 spring-batch 프로젝트에 기여하고자 했습니다.

그런데... "기여할 수 있는 이슈가 없다"

기여 모임이 시작하기 전부터 불안함이 컸기 때문에, spring-batch에 기여하신 분들의 후기를 먼저 찾아보었습니다. 모임장이신 인제님께서 spring-batch 기여에 대해 직접 글을 남기신 게 있었고, 바로 카톡으로 조언을 구했습니다.

정말 별 말씀 안드렸는데도 엄청난 지지를 해주신 인제님… 천사이심이 틀림없으신 것같 습니다. 실제 모임에서도 500명이 넘는 인원들 전부 케어를 해주셨으니… 대단하신 분이십니다. 별로 여쭤본 것도 없는데 엄청난 응원을 해주셔서 무척 감사했습니다..

그리고 실제로 오픈소스 모임이 시작되고, 저는 1회차 오프라인 모임에 참가했습니다.

오픈소스 기여 모임에서는 AI를 적극 활용하기를 권장하고 있습니다. 기여를 원하는 프로젝트만 선정한다면 AI가 이슈 선정부터 해결까지 가이드를 해주는 방식으로 진행됩니다.

첫 번째 과정인 이슈 선정하는 것도 AI와 함께 진행하게 되는데요, 기여하고 싶었던 spring-batch 프로젝트는 오래됐기 때문에 이미 성숙도가 높아 초심자가 손대기 어려운 이슈들이 대부분이었습니다.

적합한 이슈가 하나도 없다.

충격

여러 코멘트들을 들으면서 '나는 spring-batch 프로젝트에 기여할 수 없겠구나', '나는 왜 이런 실력을 갖고있는 거지' 하는 생각에 갑자기 너무 우울해져서 혼술까지 했던 기억이 납니다. ㅋㅋㅋㅋ

오프라인 모임에서 인제님과 얘기를 하면서 그나마 초심자가 진행 하기에 적합한 이슈를 선정 해주셨고, 개인적으로 진행한 후에 개인 브랜치에 푸시 후 피드백을 받기로 했습니다.

그때 인제님께 혹시 다른 프로젝트를 선정 해야할지 고민을 말씀드렸는데, "그래도 본인이 제일 하고 싶은 프로젝트에 기여하는 게 제일 좋죠"라고 하시며 도움을 주셨고, 그때 선정한 이슈가 아래와 같습니다.

선정한 이슈

MetaDataInstanceFactory default values cause StepContext collision in StepScopeTestUtils when @SpringBatchTest is active · Issu

Bug description: There is a logical collision in StepSynchronizationManager when using StepScopeTestUtils in a test environment managed by @SpringBatchTest. StepExecution determines equality based ...

github.com

MetaDataInstanceFactory default values cause StepContext collision in StepScopeTestUtils when @SpringBatchTest is active #5181

간단히 설명하면, @SpringBatchTest와 StepScopeTestUtils를 함께 사용했을 때, MetaDataInstanceFactory가 고정된 ID(1234L)로 StepExecution을 생성하면서 컨텍스트가 충돌하는 버그였습니다. 이로 인해 테스트에서 JobParameters가 제대로 주입되지 못하는 문제가 생겼습니다.

이슈 작성자 분이 재현 코드까지 꼼꼼히 남겨 주셔서 이해하거나 해결하는 데 수월했습니다.

AI와 함께 공부하고, 이해하는 과정

이슈를 해결하려면 spring-batch의 테스트 관련 클래스들을 어느 정도는 이해해야 했었습니다. 평소에 spring-batch 를 이용한 서비스 개발을 해본 건 맞지만, 테스트 유틸리티 클래스들은 거의 사용해본 적이 없었었습니다.

이때 AI에게 "spring-batch 테스트 클래스를 공부하려는데, 어떤 순서대로 봐야할까?"라고 물어보니 학습 경로까지 정리해주었습니다. 큰 그림을 잡고, 각 클래스를 하나씩 들어가며 읽고, 이해가 안 되는 부분은 다시 AI와 얘기하며 반복하는 방식으로 진행했습니다.

공부한 주요 클래스들은 다음과 같습니다.

MetaDataInstanceFactory — 테스트용 Job/Step 객체를 생성하는 핵심 유틸리티
ExecutionContextTestUtils — ExecutionContext에서 값을 편리하게 꺼내는 테스트 유틸리티
JobOperatorTestUtils — Job 실행과 단일 Step 테스트를 위한 헬퍼 (기존 JobLauncherTestUtils의 후속)
JobRepositoryTestUtils — 배치 메타데이터 저장소의 테스트 유틸리티
StepScopeTestExecutionListener — @StepScope/@JobScope 빈을 단위 테스트에서 사용 가능하게 해주는 리스너

이렇게 테스트 클래스들을 공부하고 나니, 이슈가 왜 발생한 건지 그리고 어떻게 접근할 수 있는지가 조금씩 보이기 시작했습니다.

PR과 merge — 실제 기여한 내용

접근 방향

이슈에서도 언급되었듯이 해결 방법은 여러 가지입니다. ID 생성 전략을 바꾸거나, 중복 등록 회피 로직을 추가하거나, 사용자에게 ID를 직접 받도록 하는 등이 있을 수 있습니다.

저는 수정을 최소화하는 방향을 선택했습니다. 기존에 사용되던 상수값을 그대로 유지하되, 새로운 ID를 생성할 때마다 해당 상수에 기반하여 매번 고유한 ID를 제공하도록 했습니다.

AtomicLong

이 과정에서 AtomigLong을 사용할 필요가 생겼는데, 사실 회사에서 서비스를 구현하면서 Long은 많이 사용하지만 AtomicXXX라는 클래스는 처음 접해보았습니다.

spring-batch 코드를 들여다보면서 그 존재를 알게 되었고, 멀티 스레드 환경에서 long 값의 정합성을 유지하기 위해 이 클래스를 사용한다는 것을 알게 되었습니다.

PR 제출

PR #5208

Fix ID collision in MetaDataInstanceFactory for test scenarios with @SpringBatchTest by HongYeseul · Pull Request #5208 · spri

Problem Tests using StepScopeTestUtils with @SpringBatchTest failed with ClassCastException due to ID collisions. MetaDataInstanceFactory always created instances with the same default IDs (123L), ...

github.com

"내가 이런 곳에 기여를 할 수 있는 건가?"라는 생각이 많이 들었지만, 인제님의 응원 덕분에 용기를 내어 PR을 올릴 수 있었습니다.

merge가 되다

PR을 올린 후, 약 열흘 정도가 지나고 이메일 알림이 하나 날아왔습니다.

짜릿했던 메인테이너 분께 LGTM 받기

이 때, 팀원 한 분과 회의 중이었는데 너무 기뻐서 바로 자랑했던 기억이 납니다. 생에 첫 오픈 소스 기여라니.

어떤 기준으로 프로필이 뜨는 건진 모르겠지만 바로 두번째 언급에서 프로필을 찾아 볼 수 있었습니다

spring-batch v6.0.2 릴리즈에서 저의 커밋 내용이 반영되었습니다.

그러고 그 다음 온라인 모임에 참여했을 때

인제님께서 스프링 배치 기여 축하드린다면서 샤라웃 ..! 까지 해주시고 감사했습니다 ㅎㅎ

한국 스프링 사용자 모임에서도 릴리즈 됐을 때 언급해주신 분도 계셔서 반가웠답니다.

뭔가 오픈소스 모임이 진행될 때는 spring-batch를 기여하겠다는 글은 못 본 것 같은데도 많은 관심을 가져주셔서 감사했던 것 같습니다.

특히 인제님께서 해당 프로젝트의 경우 메인테이너 한 분께서 전부 검토하고 계시기 때문에 머지까지 엄청난 시간이 걸리는 경우가 잦다는데 운도 엄청 좋았던 케이스라고 해주셨습니다.

그리고...

이번 기여로 "오픈소스에 기여해보고 싶다"라는 몇 년간의 숙제(??)를 하나 넘게 되었습니다.

또한 기여하는 것 자체에 대한 두려움이 많이 없어졌습니다.

앞으로는 여러 프로젝트에 기여하면서, 코드를 많이 읽고 레거시한 프로젝트도 빠르게 파악할 수 있는 개발자가 되고 싶습니다. 그리고 기여를 통해서 운영진 역할까지 맡을 수 있는 사람이 되고 싶다는 목표도 생겼습니다.

마지막으로, 이 과정 전반에서 엄청난 도움을 주신 운영진 분들, 특히 인제님께 정말 큰 감사의 인사를 드리고 싶습니다. 덕분에 오픈소스 기여에 대한 자신감을 가질 수 있었습니다.

다음 기수에도, 그 다음 기수에도 반드시 참여하고 싶은 마음입니다.

오픈 소스에 조금이라도 기여하고 싶다는 마음이 있다면 꼭 다들 참여 해보셨으면 좋겠습니다!

읽어주셔서 감사합니다.

Spring Boot에서 HTTP 요청/응답 로깅 필터 구현하기

예슬 — Sat, 3 Jan 2026 17:01:06 +0900

배경

서비스를 운영하면서 디버깅 시 어려움을 겪었습니다.

특히 예외가 발생하지 않았지만 오류인 경우를 파악하기 어려웠습니다. 예를 들어, 사용자는 A 옵션을 선택했다고 생각했으나 클라이언트 앱에서 잘못 처리되어 B로 전송되는 경우가 있었습니다. 이런 상황에서는 서버 입장에서 정상적으로 처리되기 때문에 예외 로그가 남지 않지만, 실제로는 사용자 의도와 다른 결과가 발생하는 문제였습니다.

기존에는 사용자가 어떤 요청을 했는지 로그 포맷이 따로 정해져 있지 않아 필요한 시점에 개별적으로 로그를 추가하는 방식으로 작업했기 때문에 다음과 같은 문제점이 있었습니다.

API 요청/응답 흐름을 추적하기 어려움
일관되지 않은 로그 형식
문제 발생 시 원인 파악에 시간이 오래 걸림
새로운 로그가 필요하다면 재배포가 필요함

해결 방법

HTTP 요청의 특성과 문제점

HTTP 요청의 InputStream은 한 번만 읽을 수 있습니다.

따라서 필터에서 body를 읽어버리면 실제 컨트롤러에서는 해당 내용을 읽을 수 없게 됩니다.

ContentCachingWrapper 활용

Spring에서 제공하는 다음 클래스들을 사용하면 이 문제를 해결할 수 있습니다.

ContentCachingRequestWrapper
ContentCachingResponseWrapper

이 Wrapper들은 요청/응답의 내용을 내부 버퍼에 캐싱하여, 여러 번 읽을 수 있도록 해줍니다.

LoggingFilter 구현

모든 API 요청이 LoggingFilter를 거치도록 설정하고, Wrapper를 활용하여 다음 정보들을 로그로 남겼습니다.

HTTP Method
요청 URL
요청 Body
응답 Body
HTTP 상태 코드
API 실행 시간

구현 결과

로그 예시

[INFO] [GET] /api/v1/products - Status: 200 - 45ms
Request: {"language": "ko"}
Response: {"products": [...]}

장점

일관된 로그 형식: 모든 API에 대해 동일한 형식으로 로깅
디버깅 효율성 향상: 요청/응답을 한눈에 확인 가능
CloudWatch 활용: 로그 검색 및 필터링이 용이해짐
성능 모니터링: API별 실행 시간 추적 가능
유저별 모니터링: API별 어떤 사용자가 어떤 요청을 했는지 추적 가능

LoggingFilter만 INFO 레벨 유지하고

다른 로거들은 WARN 또는 ERROR 레벨로 상향 조정한다면 불필요한 로그 출력 최소화로 성능 개선도 할 수 있을 것입니다.

마치며

간단한 필터 구현만으로도 디버깅과 모니터링이 훨씬 수월해졌습니다.

이제는 클라이언트-서버 간 데이터 불일치나 예상치 못한 동작을 로그만으로도 빠르게 파악할 수 있어

실제 서비스 환경에서의 이슈 대응 시간이 크게 단축되었습니다.

또한 예전에는 이슈 파악을 위해 여러 곳에 임시 로그를 추가하고 재배포해야 했다면,
이제는 CloudWatch에서 요청/응답을 바로 확인하며 문제를 해결할 수 있게 되었습니다.

하나의 개선만으로 많은 것들을 편리하게 디버깅 할 수 있게 되어 매우 만족한 개선 중 하나입니다

[K-DEVCON] 시스템 디자인 스터디2 - 3주차 후기(3장 구글 맵)

예슬 — Tue, 30 Dec 2025 09:26:13 +0900

이 글은 2025년 12월부터 K-DEVCON에서 진행된 시스템 디자인 스터디 시즌2의 내용을 정리한 글입니다.

'가상 면접 사례로 배우는 대규모 시스템 설계 기초 2권'을 함께 읽고 토론하는 형식으로 진행되는 스터디로,
책 내용을 그대로 옮긴 것이 아니라 스터디에서 논의된 내용과 제가 추가로 찾아본 내용을 함께 담았습니다.

좋은 스터디를 만들어주신 K-DEVCON 운영진 분들께 감사드립니다!

들어가며

2025년 12월부터 K-DEVCON에서 진행된 시스템 디자인 스터디 시즌2에 참여하고 있습니다.

'가상 면접 사례로 배우는 대규모 시스템 설계 기초 2권'을 함께 읽고 토론하는 스터디인데요, 이번 주 주제는 3장 - 구글 맵이었습니다.

스터디를 마치고 궁금했던 부분들을 직접 찾아보면서 정리해보았습니다.

왜 지도 타일은 이미지로 제공하는 것일까?

지도는 N×N개의 작은 타일(tile)들이 모여서 하나의 큰 지도를 만드는 구조인데요,

이 타일들이 주로 PNG 같은 이미지 형식으로 제공된다고 합니다.

게임에서는 벡터를 많이 쓰는데 왜 구글 맵은 PNG 이미지 타일을 쓸까? 라는 생각이 들었습니다.

찾아보니 래스터 타일과 벡터 타일은 각각 명확한 장단점이 있었습니다.

래스터 타일(PNG/JPG)의 장점:

모든 디바이스에서 렌더링이 쉽다 - 그냥 이미지니까
서버에서 미리 렌더링해두기 때문에 클라이언트 부하가 적다
복잡한 스타일과 디테일 표현이 자유롭다

벡터 타일의 장점:

파일 크기가 20-50% 더 작다
확대/축소해도 깔끔하다 (픽셀레이션 없음)
스타일을 동적으로 변경할 수 있다
하지만... 클라이언트에서 실시간 렌더링이 필요하다 → 클라이언트의 하드웨어 성능이 좋아야 한다 ~~→ 게임을 할 때 좋은 PC를 사용하는 것도 이 경우에 포함되는 게 아닐까.......?~~

결국 서버 리소스 vs 클라이언트 리소스의 트레이드오프였습니다. 구글 맵처럼 수억 명이 사용하는 서비스라면, 서버에서 한 번 렌더링해서 CDN에 올려두고 클라이언트는 단순히 이미지만 받아 표시하는 게 훨씬 효율적이겠죠. 특히 저사양 디바이스까지 고려하면 래스터 타일이 합리적인 선택이라는 생각이 들었습니다.

그래서 경로 안내용 타일은 벡터 기반(이진 파일)으로 따로 제공하는 구조인 것 같아 보입니다.

관련 아티클:

HTTP Keep-Alive, 생각보다 중요하다

책에서 위치 서비스가 HTTP를 keep-alive 옵션과 함께 사용하면 효율적이다라고 나와서 "이게 왜 효율적인거지?" 싶었습니다.

HTTP Keep-Alive란 한 번 연결한 TCP 커넥션을 여러 HTTP 요청/응답에 재사용하는 것인데요, 차이를 비교해보면 이렇습니다.

Keep-Alive 없이 매번 새 연결을 만들면

요청 1개 = TCP 연결 생성 + 요청 + 응답 + TCP 연결 종료
요청 10개 = 위의 과정 × 10

Keep-Alive를 쓰면

TCP 연결 생성 (1회) + 요청 10개 + 응답 10개 + TCP 연결 종료 (1회)

특히 SSL/TLS를 쓰는 HTTPS에서는 핸드셰이크 비용이 더 크기 때문에 효과가 상당하다고 합니다.

위치 정보처럼 짧은 주기로 계속 업데이트되는 데이터에는 필수적인 기능이었던 거죠.

참고로 HTTP/1.1부터는 기본값이 keep-alive입니다.

HTTP/1.0에서는 명시적으로 Connection: keep-alive 헤더를 보내야 했다고 하네요.

관련 아티클:

그렇다면 HTTP/3는?

스터디 중에 HTTP/3 얘기가 나왔는데, 구글이 만든 QUIC 프로토콜 기반이라고 합니다.

UDP 포트를 하나 더 열어야 한다는 게 인상적이었습니다.

HTTP/3의 핵심:

TCP 대신 UDP 기반
Head-of-line blocking 문제 해결
기본 암호화 (TLS 1.3 내장)

YouTube에서 이미 사용 중이라고 하는데, HTTP/3는 아직 제가 잘 몰라서 나중에 좀 더 공부해봐야 할 것 같습니다.

가장 궁금했던 것: 경로 알고리즘이 과연 트래픽을 분산시킬까?

이게 제일 궁금했던 부분입니다.

"모두가 같은 시간에 네비게이션을 켜면 전부 A 경로로 몰리는 거 아닌가?"

찾아보니 구글 맵의 경로 선택 방식은 생각보다 훨씬 정교했습니다.

Google Maps의 경로 선택 방식

1. 과거 패턴 + 실시간 교통 상황 결합

과거 데이터: "280번 고속도로는 오전 6-7시에 시속 65mph, 오후에는 15-20mph"
실시간 데이터: 지금 이 도로의 교통 상황

2. 머신러닝으로 미래 교통 예측 (10-20분 후)

DeepMind와 협업한 Graph Neural Networks 활용
ETA(도착 예정 시간 - Estimated Time of Arrival) 정확도를 97% 이상으로 개선
특히 베를린, 자카르타, 상파울루, 시드니, 도쿄, 워싱턴 DC에서 큰 개선

3. 다양한 요소 고려

도로 품질 (포장/비포장/자갈/진흙)
도로 크기와 직진성
실시간 사고/공사 정보

핵심은 "예측"

현재: A 경로가 가장 빠름 (10분)
30분 후 예측: A 경로에 정체 발생 예상 (25분)
            B 경로는 여전히 원활 (15분)
→ B 경로 추천

실제 예시

병원 예약 시간에 맞춰 출발했는데, 현재는 원활하지만 30분 후 예상되는 정체를 구글 맵이 미리 예측하고 우회 경로를 제안한다.

그렇다면 모든 사람이 같은 경로로 몰리는 문제는?

실제로는 여러 이유로인해 복합적으로 작용되어 자연스럽게 분산됩니다.

시간차 출발 - 모두가 정확히 같은 시간에 출발하지 않음
예측 기반 재분배 - 이미 많이 선택된 경로는 "곧 혼잡" 예측
개인 설정 - 유료도로 회피, 고속도로 선호 등
실시간 재계산 - 주행 중에도 계속 경로 재평가

물론 이 내용 말고도 더 많은 이유들이 있겠지만...

솔직히 어려워서 완전히 이해하지는 못한 것 같습니다.

관련 아티클:

지도 타일 캐싱 - 건물 정보가 바뀌면 어떻게 되지?

지도 이미지를 CDN에 캐싱하는데, 건물이 새로 생기거나 도로가 바뀌면 어떻게 업데이트할까요?
TTL도 너무 길면 문제가 될 것 같은데 말이죠.

TTL은 데이터 특성에 따라 다르게

기본 지도: 24~48시간 (건물, 도로 등은 자주 안 바뀜)
교통 정보: 5~15분 (실시간성이 중요)
날씨 레이어: 1시간 정도

업데이트가 필요할때는?

버전 기반 무효화

타임스탬프 또는 해시 기반 캐시 키
소스 데이터 변경 시 자동 업데이트
중요 업데이트(도로 폐쇄, 건물 변경)는 즉시 무효화

TTL이 48시간이어도 도로가 바뀌면 바로 반영해야겠죠. 이때 사용하는 전략들이 있습니다.

버전 기반 무효화
URL에 버전을 붙여서 /tiles/v2/{z}/{x}/{y}.png 이런 식으로 관리하면, 버전만 올려도 전체 캐시가 새로고침됩니다.
지역별 무효화
강남역 근처 건물 하나 바뀌었다고 서울 전체 타일을 갱신할 필요 없이, 해당 좌표 범위의 타일만 선택적으로 삭제합니다.

Stale-While-Revalidate 전략으로 만료 직전 백그라운드에서 미리 새로고침해두면, 사용자는 빈 화면 없이 부드러운 경험을 할 수 있습니다.

인기 있는 타일이 만료되기 전에 백그라운드에서 미리 새로고침(Background refresh)을 수행하여 캐시 히트율을 85% 이상으로 유지하면서도 데이터 정확성을 확보하는 것이죠.

관련 아티클:

마치며

평소에 매일 당연하게 사용하는 지도 서비스인데, 시스템 설계 관점에서 보니 정말 많은 고민과 최적화가 숨어있는 것 같습니다.

특히 지도 서비스는 수학적인 개념이 많이 들어있어서 다른 주제보다 좀 더 어렵게 느껴졌는데요,

다음 스터디에서는 드디어 3주간의 지도 시리즈를 마치고 다른 주제를 공부하게 되어 기대 중입니다.

그 외 참고하면 좋은 아티클:

카카오맵이 최적 경로를 결정하는 데까지

카카오맵이 최적 경로를 결정하는 데까지

카카오맵에서 불편함을 느끼고, 궁금증을 해결하다. 안녕하세요! NewCodes입니다!! 우선 이전 포스팅에서제가 가졌던 궁금증에 대해 다시 살펴보겠습니다. 위 그림은 제가 사는 동네입니

newcodes.tistory.com

카카오맵이 빠르게 길을 찾아주는 방법: CCH를 이용한 개편기 - kakao 기술 블로그

카카오맵이 빠르게 길을 찾아주는 방법: CCH를 이용한 개편기 - tech.kakao.com

카카오맵에서는 도보·자전거 길찾기 서비스를 제공하고 있습니다. 일반적으로 길찾기 ...

tech.kakao.com

Java/Kotlin 이미지 리사이징 라이브러리 간단 성능 비교 및 테스트

예슬 — Thu, 18 Dec 2025 18:08:18 +0900

제가 개발하고 있는 서비스는 이미지를 많이 다루기 때문에 썸네일 서버가 필수적입니다.

기존에는 줌(zum.com)의 썸네일 서버를 함께 사용했으나,

사용 중 이슈가 발생했고 외부 의존성을 제거하기 위해 썸네일 작업을 자체적으로 처리하기로 결정했습니다.

그래서 구글링을 통해 찾을 수 있었던 대표적인 라이브러리들을 비교해서 적합한 라이브러리를 선택하기로 했습니다.

비교 대상 라이브러리

Graphics2D - Java 기본 API
Image.getScaledInstance() - Java 기본 API
Imgscalr - 간단하고 효율적인 리사이징 전용 라이브러리
Thumbnailator - 사용하기 쉽고 기능이 풍부한 라이브러리
Marvin - 이미지 처리 프레임워크

이 중에서 저희 서비스는 Imgscalr를 사용하기로 했는데요,

아래는 간단하게 테스트를 거친 후 왜 적용하게 되었는지 적어보았습니다.

1. JDK 기본 제공 방식

1.1 Graphics2D

Java의 기본 그래픽 라이브러리인 AWT(Abstract Window Toolkit)를 사용하는 방식입니다.

java.awt.Graphics2D
외부 라이브러리 의존성 없음
세밀한 렌더링 옵션 제어 가능
구현이 다소 복잡할 수 있다

import java.awt.RenderingHints
import java.awt.image.BufferedImage
import java.io.File
import javax.imageio.ImageIO

fun resizeWithGraphics2D(inputFile: File, targetWidth: Int): BufferedImage {
    val originalImage = ImageIO.read(inputFile)
    val targetHeight = calculateTargetHeight(
        originalImage.width, 
        originalImage.height, 
        targetWidth
    )
    
    val resizedImage = BufferedImage(
        targetWidth, 
        targetHeight, 
        BufferedImage.TYPE_INT_RGB
    )
    
    val graphics = resizedImage.createGraphics()
    
    // 고품질 렌더링 설정
    graphics.setRenderingHint(
        RenderingHints.KEY_INTERPOLATION,
        RenderingHints.VALUE_INTERPOLATION_BILINEAR
    )
    graphics.setRenderingHint(
        RenderingHints.KEY_RENDERING,
        RenderingHints.VALUE_RENDER_QUALITY
    )
    graphics.setRenderingHint(
        RenderingHints.KEY_ANTIALIASING,
        RenderingHints.VALUE_ANTIALIAS_ON
    )
    
    graphics.drawImage(originalImage, 0, 0, targetWidth, targetHeight, null)
    graphics.dispose()
    
    return resizedImage
}

private fun calculateTargetHeight(
    originalWidth: Int, 
    originalHeight: Int, 
    targetWidth: Int
): Int {
    val aspectRatio = originalHeight.toDouble() / originalWidth.toDouble()
    return (targetWidth * aspectRatio).roundToInt()
}

1.2 Image.getScaledInstance()

Image 클래스의 기본 스케일링 메서드를 사용하는 방식입니다.

javax.imageio.ImageIO
사용이 매우 간단함
성능이 가장 느림
이미지 품질 제어가 제한적

import java.awt.Image
import java.awt.image.BufferedImage
import java.io.File
import javax.imageio.ImageIO

fun resizeWithScaledInstance(inputFile: File, targetWidth: Int): BufferedImage {
    val originalImage = ImageIO.read(inputFile)
    val targetHeight = calculateTargetHeight(
        originalImage.width, 
        originalImage.height, 
        targetWidth
    )
    
    // Image.SCALE_SMOOTH: 가장 부드러운 스케일링
    val scaledImage = originalImage.getScaledInstance(
        targetWidth, 
        targetHeight, 
        Image.SCALE_SMOOTH
    )
    
    // Image 객체를 BufferedImage로 변환
    val bufferedImage = BufferedImage(
        targetWidth, 
        targetHeight, 
        BufferedImage.TYPE_INT_RGB
    )
    val g2d = bufferedImage.createGraphics()
    g2d.drawImage(scaledImage, 0, 0, null)
    g2d.dispose()
    
    return bufferedImage
}

2. 외부 라이브러리

2.1 Thumbnailator

사용하기 쉬운 Fluent API를 제공하며 다양한 기능을 지원합니다.

빌더 패턴으로 읽기 쉬운 코드
워터마크, 회전, 크롭 등 추가 기능 풍부
활발한 유지보수 (최근까지 업데이트)
직관적인 API
공식 문서
- GitHub: https://github.com/coobird/thumbnailator
- Javadoc: https://coobird.github.io/thumbnailator/javadoc/0.4.20/
- Examples: https://github.com/coobird/thumbnailator/wiki/Examples

implementation 'net.coobird:thumbnailator:0.4.19'

import net.coobird.thumbnailator.Thumbnails
import java.io.File

// 간단한 리사이징
fun resizeWithThumbnailator(inputFile: File, targetWidth: Int): File {
    val outputFile = File("output_thumbnailator.jpg")
    
    Thumbnails.of(inputFile)
        .width(targetWidth)  // 너비만 지정하면 비율 자동 유지
        .toFile(outputFile)
    
    return outputFile
}

// 고급 옵션 사용
fun resizeWithThumbnailatorAdvanced(
    inputFile: File, 
    targetWidth: Int,
    quality: Double = 0.9
): File {
    val outputFile = File("output_thumbnailator_quality.jpg")
    
    Thumbnails.of(inputFile)
        .width(targetWidth)
        .outputQuality(quality)  // JPEG 압축 품질
        .outputFormat("jpg")
        .toFile(outputFile)
    
    return outputFile
}

// BufferedImage로 반환받기
fun resizeWithThumbnailatorAsImage(
    inputFile: File, 
    targetWidth: Int
): BufferedImage {
    return Thumbnails.of(inputFile)
        .width(targetWidth)
        .outputQuality(0.85)
        .asBufferedImage()
}

2.2 Imgscalr

간단한 API로 한 줄에 리사이징이 가능한 라이브러리입니다.

성능과 품질의 균형이 좋음
비율 유지 자동 처리
기능이 제한적 (리사이징, 크롭, 회전만)
2013년 이후 업데이트 중단
2013년 이후 업데이트 중단 (마지막 릴리즈: 4.2, 2012년)

implementation 'org.imgscalr:imgscalr-lib:4.2'

import org.imgscalr.Scalr
import java.awt.image.BufferedImage
import java.io.File
import javax.imageio.ImageIO

// QUALITY 모드 (품질 우선)
fun resizeWithImgscalrQuality(inputFile: File, targetWidth: Int): BufferedImage {
    val originalImage = ImageIO.read(inputFile)
    
    return Scalr.resize(
        originalImage,
        Scalr.Method.QUALITY,      // 품질 우선
        Scalr.Mode.FIT_TO_WIDTH,   // 너비 기준 맞춤
        targetWidth
    )
}

// SPEED 모드 (속도 우선)
fun resizeWithImgscalrSpeed(inputFile: File, targetWidth: Int): BufferedImage {
    val originalImage = ImageIO.read(inputFile)
    
    return Scalr.resize(
        originalImage,
        Scalr.Method.SPEED,        // 속도 우선
        Scalr.Mode.FIT_TO_WIDTH,
        targetWidth
    )
}

// 정확한 크기 지정
fun resizeWithImgscalrExact(
    inputFile: File, 
    width: Int, 
    height: Int
): BufferedImage {
    val originalImage = ImageIO.read(inputFile)
    
    return Scalr.resize(
        originalImage,
        Scalr.Method.QUALITY,
        Scalr.Mode.FIT_EXACT,      // 정확한 크기로 맞춤
        width,
        height
    )
}

2.3 Marvin

이미지 처리 프레임워크
필터, 효과 등 다양한 이미지 처리 가능
API가 다소 복잡함

implementation 'com.github.downgoon:marvin:1.5.5'
implementation 'com.github.downgoon:MarvinPlugins:1.5.5'

import marvin.image.MarvinImage
import org.marvinproject.image.transform.scale.Scale
import java.awt.image.BufferedImage
import java.io.File
import javax.imageio.ImageIO

fun resizeWithMarvin(inputFile: File, targetWidth: Int): BufferedImage {
    val image = ImageIO.read(inputFile)
    
    val originWidth = image.width
    val originHeight = image.height
    val targetHeight = calculateTargetHeight(originWidth, originHeight, targetWidth)
    
    // 다운스케일링만 수행
    if (originWidth >= targetWidth || originHeight >= targetHeight) {
        val imageMarvin = MarvinImage(image)
        
        val scale = Scale()
        scale.load()
        scale.setAttribute("newWidth", targetWidth)
        scale.setAttribute("newHeight", targetHeight)
        scale.process(imageMarvin.clone(), imageMarvin, null, null, false)
        
        // JPEG는 알파 채널을 지원하지 않으므로 제거
        return imageMarvin.bufferedImageNoAlpha
    }
    
    return image
}

성능 비교 테스트 해보기

성능 측정 방법

실행 시간 측정 (CPU 사용량 지표)

실행 시간은 CPU 사용량을 간접적으로 나타내는 지표라고 생각했습니다.

System.nanoTime()을 사용하여 나노초 단위로 측정한 후 밀리초로 변환했습니다.

val startTime = System.nanoTime()

// 리사이징 작업 수행
for (i in 0..<TEST_ITERATIONS) {
    val resizedImage = Scalr.resize(originalImage, Scalr.Method.SPEED, Scalr.Mode.FIT_TO_WIDTH, targetWidth)
}

val endTime = System.nanoTime()
val executionTime = (endTime - startTime) / 1_000_000 // 나노초 -> 밀리초
val averageTime = executionTime / TEST_ITERATIONS

측정 시 주의사항

각 테스트마다 10회 반복 수행하여 평균값 계산
첫 실행은 JVM 워밍업 효과가 있을 수 있어 여러 번 반복 측정

메모리 사용량 측정

JVM의 Runtime 클래스를 사용하여 테스트 전후의 메모리 사용량을 측정했습니다.

// 메모리 측정을 위한 헬퍼 함수
private val usedMemory: Long
    get() {
        val runtime = Runtime.getRuntime()
        return runtime.totalMemory() - runtime.freeMemory()
    }

// 테스트 전 가비지 컬렉션 강제 실행
System.gc()
Thread.sleep(100) // GC 완료 대기

val startMemory = usedMemory

// 리사이징 작업 수행
for (i in 0..<TEST_ITERATIONS) {
    val resizedImage = Scalr.resize(originalImage, Scalr.Method.SPEED, Scalr.Mode.FIT_TO_WIDTH, targetWidth)
}

val endMemory = usedMemory
val memoryUsed = max(0, endMemory - startMemory) // 음수 방지

측정 시 주의사항

테스트 전 System.gc()로 가비지 컬렉션을 강제 실행하여 정확도 향상
JVM의 메모리 관리 특성상 정확한 측정이 어려울 수 있으나, 상대적 비교에는 유효
totalMemory() - freeMemory()로 실제 사용 중인 메모리 계산

파일 크기 및 압축률

생성된 이미지 파일의 크기를 측정하고, 원본 대비 압축률을 계산했습니다.

val outputFile = File("output.jpg")
val fileSize = outputFile.length() // 바이트 단위

// 압축률 계산
val compressionRatio = (1 - (fileSize.toDouble() / originalFileSize)) * 100

// 파일 크기를 사람이 읽기 쉬운 형식으로 변환 (B, KB, MB, GB 등)
private fun formatBytes(bytes: Long): String {
    // 1KB(1024바이트) 미만이면 바이트 단위 그대로 반환
    if (bytes < 1024) return "$bytes B"
    
    // 로그를 이용해 어떤 단위를 사용할지 결정
    // ln(bytes) / ln(1024) = log₁₀₂₄(bytes)
    // 결과: 1=KB, 2=MB, 3=GB, 4=TB, 5=PB, 6=EB
    val exp = (ln(bytes.toDouble()) / ln(1024.0)).toInt()
    
    // 지수에 해당하는 단위 접두사 선택
    // exp=1이면 K(킬로), exp=2이면 M(메가), exp=3이면 G(기가)...
    val pre = "KMGTPE"[exp - 1]
    
    // 원본 바이트를 해당 단위로 나눠서 소수점 2자리까지 포맷팅
    // 예: 2048 bytes → 2048 / 1024¹ = 2.00 KB
    // 예: 5242880 bytes → 5242880 / 1024² = 5.00 MB
    return String.format("%.2f %sB", bytes / 1024.0.pow(exp.toDouble()), pre)
}

이러한 측정 방식으로 아래와 같이 비교 했습니다.

원본 이미지

원본 크기: 848 x 1264 pixels
원본 파일 크기: 713.26 KB
목표 크기: NNN x 626 (원본 비율 유지)
테스트 반복 횟수: 10회

실제 서비스에서 사용될 이미지를 기준으로 테스트 해보았습니다.

테스트 1: 420x626 픽셀로 축소

원본 이미지 848*N 사이즈 이미지를 420*?(비율 유지)로 변경하는 경우

테스트 2: 848x1264 픽셀 유지 (원본 크기)

원본 이미지 848*N 사이즈 이미지를 848*?(원본 크기와 동일하게)로 변경하는 경우

속도 순위 (빠른 순):

Imgscalr (SPEED)
Imgscalr (QUALITY)
Graphics2D (압축)

메모리 사용량 순위 (적은 순):

Thumbnailator (압축)
Thumbnailator(기본)
Imgscalr (SPEED)

두 라이브러리의 성능을 비교하기 위해 메모리 사용량과 실행 시간을 측정했습니다.

실행 시간은 CPU 사용량을 간접적으로 나타내는 지표로 판단했습니다.

테스트 결과 Imgscalr와 Thumbnailator 모두 안정적인 성능을 보여주었지만, Imgscalr를 SPEED 설정과 함께 사용했을 때 메모리 사용량은 비슷하면서도 평균 연산 시간이 더 짧고 압축률도 높았습니다.

다만 Imgscalr는 2013년 이후 업데이트가 중단된 반면, Thumbnailator는 비교적 최근까지 활발히 유지보수되고 있습니다. 또한 코드 가독성 측면에서도 Thumbnailator가 더 읽기 쉬운 것은 사실입니다.

하지만 제가 맡고 있는 서비스에서 현재 필요한 기능은 '이미지 용량 및 사이즈 줄이기'라는 단순한 작업이기 때문에, 많은 기능을 제공하는 라이브러리까지는 필요하지 않다고 판단했습니다. 향후 더 복잡한 이미지 처리 기능이 필요해지면 그때 다른 라이브러리로 전환하는 것도 충분히 가능할 것 같습니다.

실제로 두 라이브러리로 생성된 썸네일 이미지를 육안으로 비교했을 때도 품질 차이를 거의 느낄 수 없었기 때문에, Imgscalr를 선택하기로 했습니다.

Cloud Club 7기 - 스터디 기록

예슬 — Sun, 2 Nov 2025 21:13:23 +0900

클라우드 클럽에서는 한 기수를 완료하기 위해 2번의 스터디에 참여해야 한다.

7기 활동을 마친 지 꽤 시간이 지났지만, 기록으로 남겨본다.

1번째 스터디 - 시붕방: 시스템 붕괴 방지 위원회

스터디 장으로 참여한 첫 번째 스터디였다.

재미를 더하기 위해 스터디만의 컨셉과 로고도 만들었다.

나는 책 스터디를 할 때 챕터마다 내용을 꼼꼼히 정리하고 기록하는 스타일은 아니다.

편하게 읽되, 동기부여를 위한 스터디를 진행하고 싶었다.

그래서 자유로운 인증 방식으로 각자만의 정리를 해서 독서하는 것으로 했다.

해당 스터디는 '가상 면접 사례로 배우는 대규모 시스템 설계 기초' 1권과 2권을 모두 읽는 것이 목표였다.

1권까지는 비교적 순조로웠지만, 2권부터 난이도가 급상승하면서 결국 완독하지 못했다.

발표 자료나 PDF가 남아있지 않아 기록으로 남길 수 없는 점이 아쉽다.

스터디 장으로서 본보기가 되어야 했는데, 개인적으로 몰입도가 낮았던 것 같아 많이 아쉬웠다.

책의 난이도가 생각보다 높아서 한 번으로는 소화하기 어려웠다.

기회가 된다면 다음에 다시 도전해보고 싶다.

2번째 스터디 - 클클 북클럽

첫 번째 스터디와 비슷하게 책을 읽고 발표하는 방식으로 진행되었다.

자유롭게 책을 선정할 수 있어서 '주니어 백엔드 개발자가 반드시 알아야 할 실무 지식'을 선택했다.

최근에 출간된 책이었고, 주니어 개발자에게 좋은 길잡이가 될 것 같아 선택했다.

실제로 개발하면서 자주 마주치는 문제 상황에 대한 해결책을 제시하고,

더 깊이 공부하면 좋을 부분들을 짚어주어 현업 선배의 조언을 듣는 느낌이었다.

각자 10분의 발표 시간이 주어졌고, 나는 책에서 기억에 남았던 3가지 주제를 발표했다.

DB의 단편화와 최적화
B+ 트리를 사용하는 DB의 특성상 단편화가 발생하며, Optimize 명령어를 통해 최적화할 수 있다는 점을 배웠다.
Kafka와 RabbitMQ 간단 비교
경량 스레드와 비동기 I/O
I/O 대기와 컨텍스트 스위칭으로 인한 CPU 낭비, 요청마다 스레드를 할당하면서 발생하는 높은 메모리 사용량 문제를 다뤘다. 이를 해결하기 위해 가상 스레드나 코루틴 같은 경량 스레드, 논블로킹 또는 비동기 I/O를 활용할 수 있다는 내용이었다.

발표 당시에는 "그렇구나" 정도로만 이해했는데,

이후 비동기, 코루틴, 이벤트 기반 처리에 관심을 갖게 되면서 관련 강의를 찾아보게 되었다.

"그때 그 내용이 이거였구나!" 하며 조금씩 이해의 폭을 넓혀가고 있다.

아래는 당시 발표 자료를 아카이브용으로 첨부한다.

클클북클럽_발표자료.pdf

3.15MB

10월의 이모 저모

예슬 — Sat, 1 Nov 2025 16:23:54 +0900

10월에는 긴 연휴가 있었습니다.

바로 추석!

인프런에서 특별한 이벤트를 진행했어요. 바로 '향로'와 함께하는 추석 완강 챌린지였는데요.

연휴 동안 매일 1강 이상 듣고 인증을 남기면 신청비를 환급해주는 이벤트였어요.

'향로' 와 함께하는 추석 완강 챌린지 챌린지 | 향로 - 인프런

40% 강의 쿠폰도 받고, 연휴 동안 미션 완주하면 신청비까지 몽땅 환급! 향로와 함께하는 밑져야 본전 그 이상인 추석 챌린지!

www.inflearn.com

그런데 제가 당첨됐어요!

사실 1600명이 넘는 분들이 참여하는 챌린지에서 딱 10명만 추첨이라 기대도 안 하고 있었거든요.

문자를 받고 진짜 깜짝 놀랐어요.

제가 구매한 강의가 25만 7천원이었는데,

솔직히 전액이 다 환급될 거라고는 생각도 못 했어요. 확인하고 정말 기뻤답니다

여기에 챌린지 성공 보상으로 받은 40% 할인 쿠폰과 환급받은 25만 7천 포인트를 합치니,

무려 40만원이 넘는 금액의 강의를 추가로 구매할 수 있었어요. (완전 개이득)

환급받은 돈으로 평소 제가 부족하다고 생각하거나 눈여겨보던 강의들로 꽉꽉 채워서 구매했어요.(무려 9개 강의..!)

현재 하나씩 열심히 듣고 있는 중이고요.

이미 완강한 강의들도 있는데,

특히 로그 관리(개발자에게 필요한 로그 관리: https://inf.run/4XD3B) 관련된 강의는 회사에 바로 적용해서 디버깅할 때 쏠쏠하게 도움받고 있습니다 ☺️

개발자에게 필요한 로그 관리| 이준형(Foo) - 인프런 강의

현재 평점 4.9점 수강생 1,033명인 강의를 만나보세요. 어떤 로그를 남겨야 하는지부터 시작하여 로그를 수집하고 활용하기까지 전체적인 사이클에 대해 다룹니다. 애플리케이션에서 어떤 로그를

www.inflearn.com

Spring Boot 다국어 서비스 구현하기

예슬 — Thu, 14 Aug 2025 19:54:51 +0900

글로벌 서비스를 개발할 때 다국어 지원은 필수적인 기능입니다. HTTP의 Accept-Language 헤더를 활용하면 사용자의 언어 설정에 따라 자동으로 적절한 언어로 서비스를 제공할 수 있습니다. 이번 글에서는 HTTP 기초부터 Spring Boot에서 Accept-Language를 활용한 다국어 서비스 구현까지 알아보겠습니다.

이 글에서 사용한 예제 코드는 GitHub 레포지토리에 정리해 두었습니다.
자세한 내용은 글 하단의 링크를 참고해주세요.

HTTP 기초 이해하기

HTTP란?

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버 간의 통신을 위한 프로토콜입니다. 요청-응답(Request-Response) 모델을 기반으로 하며, 클라이언트가 서버에 요청을 보내면 서버가 응답을 반환하는 방식으로 작동합니다.

HTTP 헤더의 역할

HTTP 헤더는 요청과 응답에 대한 메타데이터를 전달합니다. 헤더는 다음과 같은 정보를 포함할 수 있습니다:

컨텐츠 타입 및 인코딩 정보
인증 및 권한 정보
캐싱 정책
클라이언트의 언어 선호도

Accept-Language 헤더 알아보기

Accept-Language란?

Accept-Language 헤더는 클라이언트가 선호하는 언어를 서버에 알려주는 HTTP 요청 헤더입니다. 브라우저는 사용자의 언어 설정을 기반으로 이 헤더를 자동으로 설정합니다.

Accept-Language 헤더 구조

Accept-Language: ko-KR,ko;q=0.9,en;q=0.8,en-US;q=0.7

이 헤더는 다음과 같이 해석됩니다:

ko-KR: 한국어(대한민국) - 우선순위 1.0 (기본값)
ko: 한국어(일반) - 우선순위 0.9
en: 영어(일반) - 우선순위 0.8
en-US: 영어(미국) - 우선순위 0.7

언어 태그 형식

언어 태그는 다음과 같은 형식을 따릅니다:

ko: 언어 코드만
ko-KR: 언어-국가 코드 -> en-US(미국 영어)와 en-GB(영국 영어), zh-CN(중국 간체)와 zh-TW(대만 번체) 등
zh-Hans-CN: 언어-문자체계-국가 코드

품질 값(q-value)

품질 값은 0.0부터 1.0까지의 값으로, 클라이언트의 언어 선호도를 나타냅니다:

1.0: 가장 선호 (기본값, 생략 가능)
0.8: 높은 선호도
0.5: 보통 선호도
0.0: 허용하지 않음

Spring Boot에서 다국어 서비스 구현하기

국제화 하는 두 가지의 방법

구분	messages.properties	DB 방식
구현 복잡도	간단(스프링 기본 기능)	복잡(테이블 설계)
성능	빠름(메모리 로드)	느림(DB 조회 필요)
관리 편의성	파일 수정 후 재배포 해야하므로 개발자만 수정 가능	실시간 수정 가능
버전 관리	쉬움	어려움

1. 국제화 설정

@Configuration
class LocaleConfig {

    @Bean
    fun localeResolver(): LocaleResolver {
        val resolver = AcceptHeaderLocaleResolver().apply {
            //  ️ 보안 & 성능 - DB에 있는 언어만 처리
            setSupportedLocales(
                listOf(
                    Locale.ENGLISH,    // "en"
                    Locale.KOREAN,     // "ko"
                    Locale.JAPANESE,   // "ja"
                    Locale.CHINESE     // "zh"
                )
            )
            //   예측 가능한 기본값 - 매우 중요!
            setDefaultLocale(Locale.ENGLISH)
        }

        return resolver
    }
}

2. 메시지 파일 생성

src/main/resources/ 디렉토리에 언어별 메시지 파일을 생성합니다:

messages.properties (기본)

hello=안녕하세요
welcome=환영합니다
user.name=사용자 이름
user.email=이메일
button.save=저장
button.cancel=취소

messages_en.properties

hello=Hello
welcome=Welcome
user.name=User Name
user.email=Email
button.save=Save
button.cancel=Cancel

messages_ja.properties

hello=こんにちは
welcome=ようこそ
user.name=ユーザー名
user.email=メール
button.save=保存
button.cancel=キャンセル

3. 컨트롤러 구현

@RestController
class HelloController(
    private val messageSource: MessageSource
) {

    @GetMapping("/hello", produces = ["text/plain;charset=UTF-8"])
    fun hello(locale: Locale): String {
        val locale = LocaleContextHolder.getLocale()
        val text = messageSource.getMessage("hello", null, locale)
        return text
    }

}

4. MessageSourceConfig

/**
 * DB에서 데이터를 가져오는 방법이 아니라면 필요
 */
@Configuration
class MessageSourceConfig {
    @Bean
    fun messageSource(): MessageSource =
        ReloadableResourceBundleMessageSource().apply {
            setBasenames("classpath:messages")
            setDefaultEncoding("UTF-8")
            setCacheSeconds(1) // 1초마다 파일 변경 확인
        }
}

messages.properties 파일을 서버 재시작 하지 않고 1초에 한번씩 파일 변경 확인
명시적인 UTF-8 인코딩으로 한글 등 다국어 문자가 깨지지 않도록 보장

5. 엔티티 클래스 만들기

@Entity
@Table(name = "products")
class Product(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,

    @Column(nullable = false, length = 255)
    var sku: String,             // 비즈니스용 코드(선택)

    @Column(nullable = false, length = 255)
    var defaultTitle: String = "",

    @Column(columnDefinition = "TEXT")
    var defaultDescription: String? = null,
) {
    // JPA용 기본 생성자
    constructor() : this(null, "", "", null)

}

@Entity
@Table(
    name = "product_localization",
    uniqueConstraints = [UniqueConstraint(columnNames = ["product_id", "locale"])]
)
class ProductLocalization(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "product_id", nullable = false)
    @OnDelete(action = OnDeleteAction.CASCADE)
    var product: Product? = null,

    @Column(nullable = false, length = 10)
    var locale: String,    // "en", "ko", "ja", "en-US" 등

    @Column(nullable = false, length = 255)
    var title: String,

    @Column(columnDefinition = "TEXT")
    var description: String? = null,
) {
    // JPA용 기본 생성자
    constructor() : this(null, null, "", "", null)
}

6. DB 사용해서 다국어 처리하기

Locale 클래스 사용

@RestController
@RequestMapping("/api/products")
class ProductController(
    private val productReadService: ProductReadService,
) {

    @GetMapping("/{id}")
    fun getProduct(
        @PathVariable id: Long,
        locale: Locale, // Spring이 자동으로 http 헤더의 locale 설정을 주입해줌
    ): ResponseEntity<ProductDto> {

        val languageCode = locale.language.ifBlank { "en" }
        val dto = productReadService.get(productId = id, locale = languageCode)

        return ResponseEntity.ok()
            .header(HttpHeaders.CONTENT_LANGUAGE, languageCode)
            .body(dto)
    }
}

6. ProductService

@Service
class ProductReadService(
    private val productRepository: ProductRepository,
    private val productLocRepo: ProductLocRepository,
) {
    fun get(productId: Long, locale: String): ProductDto {
        val product = productRepository.findById(productId).orElseThrow {
            ResponseStatusException(HttpStatus.NOT_FOUND, "product not found")
        }

        val loc = productLocRepo.findFirstByProduct_IdAndLocale(productId, locale)

        return if (loc != null) {
            ProductDto(product.id!!, loc.title, loc.description)
        } else {
            // 번역이 한 건도 없으면 기본값 사용
            ProductDto(product.id!!, product.defaultTitle, product.defaultDescription)
        }
    }
}

data class ProductDto(
    val id: Long,
    val title: String,
    val description: String?
)

7. 웹 설정

@Configuration
class WebConfig : WebMvcConfigurer {
    @Bean
    fun stringHttpMessageConverter() =
        StringHttpMessageConverter(StandardCharsets.UTF_8)
}

1. cURL을 사용한 테스트

지원되지 않는 경우나 헤더를 사용하지 않을 경우 기본 값인 영어로 출력되는 모습

해당 코드들을 참고 할 수 있는 레포지토리를 공유해드립니다.

https://github.com/HongYeseul/spring-boot-locale-demo

GitHub - HongYeseul/spring-boot-locale-demo

Contribute to HongYeseul/spring-boot-locale-demo development by creating an account on GitHub.

github.com

Kind를 이용하여 멀티 노드 Kubernetes 클러스터를 구성하고 삭제하는 방법

예슬 — Wed, 6 Aug 2025 12:52:49 +0900

쿠버네티스를 간단히 실습할 수 있는 환경인 kind를 활용하는 방법을 소개합니다.

kind란?

kind (Kubernetes IN Docker)는 Docker 컨테이너 기반으로 쿠버네티스 클러스터를 구성할 수 있게 해주는 도구입니다.

테스트, CI/CD, 경량 개발 환경에 적합
VM 없이 컨테이너로만 클러스터 구성
매우 빠르고 가벼움

구성 예시

kind-multinode/
├── kind-cluster.yaml        # 클러스터 노드 설정 파일
└── create-cluster.sh        # 클러스터 생성 스크립트

kind-cluster.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

위 설정은 컨트롤 플레인 1개 + 워커 노드 2개 구성입니다.

create-cluster.sh

#!/bin/bash

CLUSTER_NAME="multi-node-cluster"

echo "  기존 클러스터 삭제 중..."
kind delete cluster --name "$CLUSTER_NAME"

echo "  클러스터 생성 중..."
kind create cluster --name "$CLUSTER_NAME" --config kind-cluster.yaml

echo "✅ 클러스터 생성 완료!"
kubectl cluster-info --context kind-$CLUSTER_NAME

echo "  노드 리스트:"
kubectl get nodes

실행 권한 부여: chmod +x create-cluster.sh

클러스터 실행

./create-cluster.sh

결과 예시

$ kubectl get nodes
NAME                             STATUS   ROLES           AGE     VERSION
multi-node-cluster-control-plane   Ready    control-plane   1m      v1.29.x
multi-node-cluster-worker          Ready    <none>          1m      v1.29.x
multi-node-cluster-worker2         Ready    <none>          1m      v1.29.x

클러스터 삭제

kind delete cluster --name multi-node-cluster

관련 Docker 컨테이너들도 자동 삭제됨
kubectl config에서도 context 사라짐

참고 사항

kind는 Docker 이미지를 자동으로 사용하므로 별도의 Dockerfile이 필요 없음

[KSUG] 기초 지식 스터디 2회차 요약

예슬 — Sun, 3 Aug 2025 12:46:53 +0900

25년 KSUG에서 주니어 및 취준생 분들과 함께한 스터디 진행 기록입니다.
스프링 프레임워크 혹은 데이터베이스에 대한 스터디를 진행 했고, 저는 스프링 프레임워크를 선택했습니다.

*스프링 프레임워크 가이드 책: 스프링 부트3 핵심 가이드
*데이터 베이스 가이드 책: 새로 쓴 대용량 데이터베이스 솔루션 1

기여해주시는 멘토 분들께 항상 감사드립니다.

이번 시간에는

Spring Boot - 제2장: 개발에 앞서 알면 좋은 지식
데이터 베이스 - 1.3장: SQL의 실행 계획

부분을 정리해오기로 했다.

오늘은 스터디 시작 전에 발표를 자원해주신 분들이 계셔서, 비교적 원활하게 진행할 수 있었다.

오늘은 특별히 게스트로 '김근수'님께서 참석해 주셨는데, 발표 내용이 특히 인상 깊었다.

Spring Camp에서도 연사로 발표하셨다고 들었지만, 내가 참석했던 세션은 아니어서 직접 들을 수 없었던 점이 아쉬웠다.

근수님은 평소 마인드맵 형식으로 모든 내용을 정리하신다고 한다. 마인드맵 프로그램을 이용하면 단순히 생각나는 대로 적어도 마우스를 이용해 자유롭게 구조를 바꿀 수 있어 생각을 체계화하는 데에 매우 유용한 툴이라고 느꼈다.

근수님께서는 EdrawMind라는 툴을 쓰신다고 했는데, 유료 서비스라 예전부터 알고 있던 무료 툴인 XMind가 떠올랐다. 일단은 XMind로 시작해보고, 나중에 익숙해지면 블랙프라이데이 때 EdrawMind를 한번 사볼까 한다.

다음 날 바로 실무에 적용해보자는 마음으로, 현재 작업 중인 mevu 서비스 관련 내용을 XMind로 정리하고 앱팀과 회의를 진행했는데, 기획자분도 보기 좋고 회의도 수월하다고 칭찬해 주셔서 뿌듯했다. 아직은 정리 중이지만 마인드맵 가지가 점점 늘어나는 걸 보면서 잘 정리해보고 싶다는 의욕도 생겼다.

또 하나 인상 깊었던 점은 근수님이 모든 책을 이북으로 보신다는 점이다. 이북은 마인드맵으로의 전환이나 복사-붙여넣기가 쉬워 정리에 더 적합해 보였다. 나는 그동안 전공 서적은 종이책으로만 봤는데, 책이 집에 쌓이면서 점점 부담이 되었던 터라 이북 활용도 진지하게 고려해봐야겠다는 생각이 들었다.

이처럼 유용한 팁을 많이 얻을 수 있었던 뜻깊은 스터디 2회차 시간이었다.

아래는 GPT를 이용한 키워드 중심 스터디 요약본이다.

아키텍처 및 계층 구조

3계층 구조 (Layered Architecture)
- Presentation Layer (프레젠테이션 계층): 클라이언트와의 접점, 요청 및 응답 처리
- Business Layer (비즈니스 계층): 비즈니스 로직, 트랜잭션, 유효성 검사
- Persistence Layer (데이터 접근 계층): DB 접근, Repository 사용
마이크로서비스 아키텍처(MSA)
- 모놀리식과 비교
- 단순히 서비스 쪼개는 게 아닌 "사상"이 중요
DTO, Entity, VO 구분
- 레이어 간 데이터 이동을 위한 역할

디자인 패턴

생성 패턴: Abstract Factory, Builder, Factory Method, Singleton 등
구조 패턴: Adapter, Composite, Decorator, Facade 등
행위 패턴: Chain of Responsibility, Command, Interpreter, Mediator 등

REST 아키텍처

REST 특성
- 유니폼 인터페이스
- 무상태성 (Stateless)
- 캐시 가능성
- 클라이언트-서버 구조
- 계층 구조
RESTful URL 설계 규칙
- /로 끝나지 않음
- 하이픈(-) 사용, 언더바(_) 지양
- 명사 사용 (동사 대신 HTTP 메서드로 행위 표현)
- 소문자 사용
- 확장자 지양
URI vs URL
- URI: 자원의 고유 식별자
- URL: 위치 및 접근 방식 포함한 URI

인증 및 인가

Authentication: 사용자 판별 (로그인 등)
Authorization: 자원 접근 권한 확인

HTTP 및 HTTPS

HTTP: 보안 없음
HTTPS: TLS 기반 보안 제공
- SSL (구버전), TLS (현재 주 사용)
- 포트: HTTP(80), HTTPS(443)

DispatcherServlet 흐름

요청 → DispatcherServlet
HandlerMapping → Controller
Service → Repository → DB
Controller → ViewResolver
View 반환

DB 저장 구조 및 최적화

분리형 테이블 구조
- 논리적 구조와 물리적 저장 분리
- RowID 활용: 인덱스와 실제 데이터 연결
IOT (Index Organized Table)
- 인덱스와 데이터를 함께 저장 → 빠른 조회
- 수정 시 데이터 재배치 필요 → 성능 저하
클러스터링 테이블
- 데이터 물리적 정렬 (예: 저자명 기준)
- IO 최소화, 조회 성능 향상
- 단점: 쓰기/수정 비용 큼
해시 클러스터
- 조회 속도 빠름 (O(1))
- 단점: 레인지 조회 불가, 충돌 발생 가능
클러스터링 팩터 (Clustering Factor)
- 인덱스와 실제 데이터의 물리적 거리 척도
- 공간 지역성 높을수록 성능 우수

이번 2회차는 내가 많이 준비하지 못해서 아쉬움이 남는다. 열심히 공부해야지...

이 스터디는 내가 집중해서 공부하고 있는 분야뿐만 아니라, DB를 공부하고 계신 분들도 계셔서 완전히 알지는 못해도 자연스럽게 DB에 대한 내용도 함께 접할 수 있다는 점이 좋은 것 같다.

그럼 이제 3회차 준비하러 가야지... 다음주도 파이팅

스프링 부트에 대한 간단한 고찰 - 2

예슬 — Thu, 31 Jul 2025 17:40:49 +0900

25년 KSUG에서 주니어 및 취준생 분들과 함께한 스터디 진행 기록입니다.
스프링 프레임워크 혹은 데이터베이스에 대한 스터디를 진행 했고, 저는 스프링 프레임워크를 선택했습니다.

기여해주시는 멘토님들께 항상 감사드립니다.

2회차

스터디에서 메인으로 사용하는 책은 '스프링 부트 3 핵심 가이드'라는 책이다.

2회차에는 2장부터 정리를 하면 되고, 3장은 개발 환경 구성 하는 챕터여서 생략했다.

원래는 이번 시간에 2장만 하면 되는 것이었는데 읽는 김에 금방 읽을 수 있을 것 같아 5장까지 읽고 정리해보았다.

2장(개발에 앞서 알면 좋은 기초 지식)

4장(스프링부트 애플리케이션 개발하기), 5장(API를 작성하는 다양한 방법)

이번에는 책을 읽으면서 필요한 전공 지식을 질문 형태로 정리하고, 그에 대한 답을 찾아보는 방식으로 공부해보기로 했다.

기도님께서 참고하라고 공유해주신 리포지토리가 있었는데, 그 방식처럼 나도 질문지를 먼저 만들고 해답을 정리해보려고 했다.

아래는 새로 만든 리포지토리.

https://github.com/HongYeseul/cs-for-interview

GitHub - HongYeseul/cs-for-interview

Contribute to HongYeseul/cs-for-interview development by creating an account on GitHub.

github.com

해당 리포지토리에 질문들과 답변을 적어내려가려 했는데 ...

이번주는 시간이 부족해서 조금밖에 채워 넣지 못했다.....

이번에 5장까지 정리했으니, 다음 진도보다는 빨라서 시간이 좀 더 남지않을까.....라고 생각하며

다음주에는 꼭 ... 많이 채워와야겠다고 다짐했다.

3회차

스터디 진도는 4장이었으나, 4장 5장을 정리했었기 때문에 xmind로 옮기는 작업을 진행했다.

옮기면서 더 조사한 내용은 붙여넣기도 했다.

그리고 저번주에 만들어둔 리포지토리에 하나씩 채워 넣는중...

https://github.com/HongYeseul/cs-for-interview/tree/springboot/mechanism

GitHub - HongYeseul/cs-for-interview

Contribute to HongYeseul/cs-for-interview development by creating an account on GitHub.

github.com

브랜치에다 푸시 해뒀는데 마음에 드는 만큼 채우면 squash - push 하려고 대기중이다.

5회차

주제는 6장 - 데이터베이스 연동

JPA는 한 장으로 끝나는 그런 지식이 아니기 때문에 양이 확실히 많았다

독서(공부?) 인증용으로 이정도만...

6회차

6회차 주제는 7장. 테스트 코드 작성하기