How to be awesome

AWS Lightsail 최소 사양에서 Spring Boot는 어디까지 견디는가

siyoon210 — Fri, 14 Aug 2026 21:16:29 +0900

월 $3.5짜리 Lightsail 인스턴스에 Spring Boot 서버를 올릴 수 있는지 알고 싶었다. 512MB 램에 2 vCPU, 스토리지 20GB짜리다. 검색으로도 LLM에 물어봐도 답은 대체로 "안 된다"였고, 이유는 한결같이 512MB에 JVM이 안 들어간다는 것이었다. 근거로 제시되는 숫자를 본 적이 없어서 직접 측정해봤다.

결론부터 적으면 이렇다.

512MB라는 메모리에도 스프링부트 운영이 가능하다. OS와 Litestream까지 올린 전체 스택이 419MB 중 256MB를 쓰고 147MB가 남았다
요청수가 초당 30건 이하로 유지된다면 $3.5짜리 Lightsail 인스턴스에서 운영이 가능하다. (일반적인 HTML 페이지 호출 기준. 자세한 사항은 아래 설명)
(순간 피크 기준) 요청수 초당 120건까지 성능저하 없이 처리한다. (일반적인 HTML 페이지 호출 기준. 자세한 사항은 아래 설명)

측정 조건

실제 Lightsail 인스턴스($3.5, 512MB, Amazon Linux 2023, x86_64)에서 쟀다. 요청 하나의 비용을 성분별로 나누는 부분만 Docker 컨테이너를 따로 썼다. 조건을 하나씩 고정해야 하는 측정이라 그렇다.

구성 요소	버전
JDK	Eclipse Temurin 25.0.4
Spring Boot	4.1.0
Spring Framework	7.0.8
서블릿 컨테이너	Tomcat Embed 11.0.22
템플릿 엔진	Thymeleaf 3.1.5
DB	SQLite (WAL) + sqlite-jdbc 3.51.0.0
커넥션 풀	HikariCP 7.0.2
복제	Litestream 0.5.16
부하 생성기	k6 v2.2.0

spring.threads.virtual.enabled=true
spring.datasource.hikari.maximum-pool-size=8
spring.datasource.hikari.data-source-properties.journal_mode=WAL
server.compression.enabled=false
spring.thymeleaf.cache=true

JVM 플래그는 하나도 주지 않았다. 힙을 지정하지 않으면 JVM이 시스템 메모리를 읽어 그 25%로 잡는다. 이 인스턴스에서는 126MB다.

가상스레드는 사용했다.

SQLite와 Litestream을 쓰는 이유

비용 때문이다. 관리형 데이터베이스는 이 가격대에서 인스턴스 값보다 비싸고, DB용 인스턴스를 하나 더 띄우면 최소 비용으로 서버를 올린다는 전제가 무너진다. SQLite는 별도 서버 프로세스 없이 애플리케이션 안에서 도는 파일 기반 데이터베이스라 추가 비용이 붙지 않는다.

대신 데이터가 인스턴스 디스크의 파일 하나에 들어 있다. 인스턴스가 사라지면 데이터도 사라진다.

Litestream이 그 문제를 메운다. SQLite의 변경 기록(WAL)을 계속 읽어 S3나 R2 같은 오브젝트 스토리지로 복제하는 별도 프로세스다. 애플리케이션은 평소처럼 SQLite를 쓰고, 복제는 뒤에서 알아서 돌아간다. 인스턴스를 잃어도 마지막 시점의 데이터베이스를 다시 받아올 수 있다.

이 조합이면 데이터베이스 몫으로 나가는 돈이 오브젝트 스토리지 요금만 남는다. 대신 인스턴스의 CPU와 메모리를 애플리케이션과 나눠 쓰게 되므로, 이 글의 측정에는 Litestream도 함께 올려서 그 몫까지 포함했다.

데이터와 시나리오

데이터 수는 운영 중인 커뮤니티 사이트의 규모에 맞췄다. 글 4,684건, 댓글 17,645건, 글당 평균 댓글 3.8개.

시나리오	엔드포인트	응답	하는 일
`page`	`GET /page/post/{id}`	HTML 102 KB	쿼리 5회 + Thymeleaf 렌더링
`json`	`GET /json/post/{id}`	JSON 12 KB	같은 쿼리 5회, 템플릿 없음
`blob`	`GET /static/blob`	102 KB	미리 만들어둔 문자열 반환
`db`	`GET /db/user/{id}`	JSON 380 B	인덱스 조회 1회

page가 주력이다. 글 상세 페이지 하나에 쿼리 5개가 나간다. (본문, 댓글 목록, 최근글, 인기글, 게시판 목록...) 나머지 셋은 비용을 성분별로 나누기 위한 것이다.

gzip 같은 압축은 껐다. Cloudflare를 앞에 두면 엣지에서 압축하므로 원본 CPU를 아낄 수 있다. 참고로 gzip을 켜도 CPU 비용은 전체의 5%뿐이라, 직접 서빙한다면 켜는 편이 낫다.

1. 메모리 512MB도 충분히 운영 가능

전체 스택을 단계별로 올리며 잰 값이다.

단계	used	available
OS	110 MB	298 MB
OS + Spring Boot	232 MB	176 MB
OS + Spring Boot + Litestream	240 MB	168 MB
OS + Spring Boot + Litestream + 부하	256 MB	147 MB

프로세스별로는 java 161MB, litestream 13MB다. OOM 0건, 여유 147MB.

명목 512MB 중 실제로 보이는 것은 419MB였다. 커널 예약 영역과 펌웨어가 먼저 가져간다. "512MB에 들어가는가"를 따질 때 기준은 512가 아니라 419다.

free를 볼 때는 free 열이 아니라 available 을 봐야 한다. 리눅스는 남는 메모리를 전부 캐시로 쓰기 때문에 free는 항상 작게 나온다. available이 새 프로세스에 내줄 수 있는 실제 여유다.

2. Lightsail에서 반드시 알아야하는 '베이스라인'

Lightsail 인스턴스는 버스트형이다. "2 vCPU"는 순간 최대치이지 계속 쓸 수 있는 양이 아니다.

vCPU보다 베이스라인이 더 중요한데, 한줄로 요약하면 평균적으로 쓸수있는 CPU 성능 한계다.

순간 5%를 넘어가는 작업도 가능하지만 평균 5%를 넘기다 보면 크레딧이 고갈되어 인스턴스 성능이 저하된다.

문서에 플랜별 성능 베이스라인이 명시돼 있다.

플랜	vCPU	메모리	성능 베이스라인
Linux $3.5	2	512 MB	5%
Linux $5	2	1 GB	10%
Linux $10	2	2 GB	20%

가격은 IPv6 전용 번들 기준이다. Lightsail은 IPv4 주소를 함께 주는 번들(듀얼스택)과 IPv6 주소만 주는 번들을 따로 파는데, 후자가 더 싸다. 같은 사양이 듀얼스택으로는 $5 / $7 / $12다. 성능 베이스라인은 둘이 동일하다.

(IPv6 전용은 IPv4 클라이언트가 서버에 직접 접속하지 못한다는 제약이 있지만, Cloudflare를 앞에 두면 해결된다. 클라이언트는 Cloudflare에 IPv4로 붙고 Cloudflare가 원본에 IPv6로 접속한다.)

문서에 단서가 하나 붙어 있다. *"These performance baselines are per vCPU."* vCPU당 값이라는 뜻이고, 콘솔 그래프는 두 vCPU를 평균 내서 보여준다.

$3.5   버스트 상한 2.00 vCPU   /   지속 보장 0.10 vCPU  (2 x 5%)

베이스라인은 상한이 아니라 크레딧이 늘지도 줄지도 않는 경계다. 언제든 100%까지 쓸 수 있고, 그 위로 쓰면 burst capacity가 줄고 아래로 쓰면 쌓인다.

burst capacity 계산

문서에 공식이 있다.

burst capacity는 "CPU를 100%로 쓸 수 있는 시간" 을 분 단위로 센다. 한 시간(60분) 가운데 베이스라인 비율만큼이 쌓이고, 실제로 쓴 비율만큼이 빠진다.

시간당 적립 (분)  =  베이스라인%  × 60분
시간당 소모 (분)  =  실제 CPU%    × 60분
최대 적립량 (분)  =  시간당 적립  × 24시간

$3.5 플랜이면 5% × 60분 = 시간당 3분이 쌓이고, 24시간이 지나면 72분에서 멈춘다.

CPU를 20%로 쓰면 20% × 60분 = 시간당 12분이 나간다. 버는 3분을 빼면 순소모가 9분이고, 72분을 8시간에 다 쓴다.

사용률	소진까지
5%	줄지 않음
10%	24시간
20%	8시간
50%	2.7시간
100%	1.3시간

burst capacity가 바닥나도 추가 과금은 없다. 최악의 경우가 요금 폭탄이 아니라 성능 저하라는 뜻이다.

이 측정에서 page 요청은 초당 120건에 CPU 20%를 썼다. 역산하면 크레딧이 줄기 시작하는 지점은 초당 약 30건이다. 그 아래로 운영하면 잔량이 마르지 않는다.

3. 실제로 어디까지 견디는가

앞의 표대로면 초당 30건을 넘는 순간부터 크레딧이 줄고, 다 쓰면 성능이 떨어져야 한다. 그래서 크레딧을 0까지 소진시킨 상태에서 요청률을 올려가며 쟀다.

page 시나리오(102 KB HTML, 쿼리 5회).

목표 rps	실제 처리 rps	실패율	p95 레이턴시	인스턴스 CPU
8	8.0	0%	44 ms	—
16	16.0	0%	42 ms	—
24	24.0	0%	41 ms	—
40	40.0	0%	39 ms	—
60	60.0	0%	38 ms	약 10%
90	90.0	0%	37 ms	—
120	119.9	0%	43 ms	약 20%
150	—	—	JVM 힙 부족으로 프로세스 사망	—

CPU는 인스턴스 안에서 vmstat으로 관측한 사용자·시스템 시간의 합이고, 두 지점에서만 쟀다.

크레딧이 하나도 없는 상태에서 초당 120건을 p95 43ms에 처리한다.

초당 150건에서 프로세스가 죽었다. 로그에 남은 것은 CPU 관련 오류가 아니었다.

Exception in thread "tomcat-handler-20963" java.lang.OutOfMemoryError: Java heap space

스레드 번호가 2만 번대까지 갔다. 처리 속도보다 요청이 빨리 들어오면서 가상 스레드가 계속 생성됐고, 각각이 102KB 응답 버퍼를 들고 있으니 126MB 힙이 버티지 못했다.

4. 운영중 크레딧 알람은 필수로 설정

크레딧 소진 자체는 이번 측정에서 큰 성능 저하로 이어지지 않았지만, 그 상태를 알고 있느냐는 별개 문제다. 이 상태에는 흔적이 거의 없다.

요금이 늘지 않는다. Lightsail은 CPU 초과분을 과금하지 않는다
CPU 그래프만 봐서는 구분이 안 된다. 정상적으로 버스트 중인지 잔량을 태우는 중인지 같은 그래프로 보인다
헬스체크를 통과한다. 가벼운 엔드포인트는 계속 200을 반환한다

Lightsail은 세 가지 CPU 지표에 알람을 걸 수 있다.

지표	의미
`CPUUtilization`	CPU 사용률 (두 vCPU 평균)
`BurstCapacityPercentage`	남은 burst capacity 비율
`BurstCapacityTime`	남은 burst capacity를 분으로 환산

걸어야 할 대상은 CPUUtilization이 아니라 BurstCapacityPercentage다. 40%라는 CPU 값 하나로는 "지금 트래픽이 많다"와 "잔량이 곧 바닥난다"를 가릴 수 없다.

5. CPU는 어떤 과정에서 많이 쓸까

page 요청의 비용을 성분별로 나누기 위해 조각을 하나씩 뺀 엔드포인트를 비교했다. 이 부분은 조건을 정확히 고정해야 해서 컨테이너에서 쟀다.

엔드포인트	응답크기	DB 쿼리 요청수	렌더링	100 rps 콘솔 CPU
`/static/blob`	102 KB	0회	없음	5.24%
`/json/post/{id}`	12 KB	5회	Jackson	8.50%
`/page/post/{id}`	102 KB	5회	Thymeleaf	12.12%

여기서 성분이 분리된다.

DB가 가장 큰 몫이다. 템플릿 렌더링은 15%뿐이고, 102KB를 그냥 내보내는 것도 24%에 그친다.

응답 크기의 영향도 생각보다 작다. 240KB짜리 페이지를 따로 쟀는데 크기가 2.3배인데 비용은 13%만 늘었다. 바이트 수보다 요청당 고정 작업이 비용을 지배한다.

VPS 하나를 최대한 쓴다는 것은 DB도 같은 인스턴스에 둔다는 뜻이고, 그러면 쿼리 CPU가 애플리케이션과 같은 예산에서 나간다. 위 비중이 그 크기를 보여준다. 저사양 인스턴스에서 EXPLAIN QUERY PLAN을 확인하는 것이 다른 어떤 최적화보다 효과가 크다.

DB Write와 Litestream은 영향이 크지 않음

조회할 때마다 조회수를 올리는 패턴, 그리고 SQLite를 복제하는 Litestream을 차례로 얹고 7 rps에서 쟀다.

구성	콘솔 CPU
읽기 전용	1.99%
+ 조회수 UPDATE	1.85%
+ Litestream	2.20%

셋 다 노이즈 범위 안이다. WAL 모드에서 인덱스 단건 UPDATE를 초당 몇 건 하는 것은 SQLite에 부담이 아니고, 그 정도 쓰기가 만드는 WAL은 몇 KB라 Litestream이 읽어 올릴 것도 거의 없다.

메모리는 다르다. Litestream은 실제 인스턴스에서 13MB를 상주 사용했다. CPU는 무시할 수 있지만 메모리는 여유 147MB의 9%다.

이 수치는 로컬 파일로 복제하고 쓰기가 초당 몇 건일 때 그렇다는 뜻이다. S3나 R2로 올리면 네트워크와 TLS 비용이 붙고, 쓰기가 많아지면 WAL도 그만큼 커진다. 전체 테이블 COUNT를 쓰기 락 안에서 재계산하는 패턴처럼 무거운 쓰기는 비용 구조가 다르고 여기서 재지 않았다.

6. 정리

월 $3.5짜리 Lightsail 인스턴스에서 Spring Boot + SQLite + Litestream을 돌린 결과다.

메모리	419MB 중 256MB 사용, 147MB 여유. OOM 없음
지속 가능한 평균	초당 약 30건 (이 아래면 크레딧이 쌓인다)
크레딧 소진 상태 처리량	초당 120건, p95 43ms
붕괴 지점	초당 150건, JVM 힙 부족

"512MB에 JVM이 안 들어간다"는 말은 사실이 아니었다. 플래그를 주지 않으면 JVM이 시스템 메모리의 25%로 힙을 잡기 때문에 오히려 작게 시작한다. 부하가 몰려 프로세스가 죽은 순간에도 인스턴스에는 78MB가 남아 있었다.

CPU 베이스라인은 알아둬야 하지만 두려워할 것은 아니다. $3.5 인스턴스 베이스라인 5%라면 평균 CPU 사용량이 5%로 지속되면 된다.

GC 튜닝이나 네이티브 이미지 (GraalVm)는 이 규모에서 필요 없다. 기본 설정으로 충분했고, 별도로 잰 튜닝 구성은 저부하에서 기본값과 차이가 없거나 오히려 메모리를 더 썼다.

한계

관측 구간이 짧다. 요청률당 1분씩 쟀다. 크레딧 초과 상태를 수 시간 지속했을 때도 같은 성능이 나오는지는 확인하지 않았다
비용 분해는 컨테이너 기준이다. 성분별 비중은 상대값이라 그대로 옮겨가지만, 절대 CPU 수치는 인스턴스와 다르다
무거운 쓰기 패턴을 안 쟀다. 단건 UPDATE는 측정되지 않았지만, 전체 테이블 COUNT나 같은 행에 쓰기가 몰리는 경우는 비용 구조가 다르다

참고

AI 바이브코딩과 함께 사라진 '테스트의 고통'

siyoon210 — Wed, 29 Jul 2026 08:31:13 +0900

AI 바이브코딩 시대가 오면서 테스트 코드 작성이 압도적으로 쉬워졌다. 딸깍 한 번이면 몇 백 줄짜리 테스트 코드가 쏟아져 나온다. 주변에서는 커버리지가 올랐다고 기뻐하지만, 쏟아지는 테스트 코드를 볼 때마다 묘한 위기감을 느낀다.

"테스트는 통과하는데, 왜 시스템은 점점 더 구려지는 걸까?"

1. 원래 '높은 결합도'의 가장 큰 벌칙은 '테스트의 불가능'이었다

굳이 객체지향을 고민하고, 결합도를 낮추려 애썼던 가장 현실적인 이유는 고상한 철학 때문이 아니었다. 결합도가 높은 나쁜 구조를 만들면 당장 테스트 코드를 작성하는 것 자체가 고문이었기 때문이다.

어떤 클래스가 내부 세부 구현에 강하게 얽혀 있거나 온갖 상태에 의존하고 있으면 테스트 코드를 짜다가 화가 난다. "아, 도저히 테스트를 못 짜겠다. 구조를 쪼개야지."

즉, '테스트 작성의 괴로움'은 나쁜 아키텍처와 높은 결합도를 막아주는 가장 강력한 즉각적 피드백 장치(억제기)였다.

2. AI라는 깡패가 억제기를 부숴버렸다

하지만 요즘 AI는 완전히 다르다.

심하게 꼬인 결합도와 내부 상태, 엉망인 의존 관계를 가져다줘도 AI는 불평 한마디 하지 않는다. 무지막지한 깡생산성(체급)으로 밀어붙여 어떻게든 작동하는 200줄짜리 테스트 코드를 3초 만에 뱉어낸다.

나쁜 구조가 마땅히 받아야 할 페널티(테스트 작성 불가능)를 AI가 무력으로 대신 막아주는 셈이다. 결합도가 높든 말든 AI가 뚫어버리니 개발자는 착각에 빠진다.

"테스트가 통과하네? 내 코드 구조에 문제없나 보다."

그렇게 AI의 압도적 생산성 뒤로, 시한폭탄 같은 높은 결합도의 코드들이 차곡차곡 쌓여간다.

3. AI가 짠 테스트 코드도 결국 '사람이 평생 고쳐야 할 코드'다

여기서 간과하는 사실이 있다. AI가 3초 만에 짠 테스트 코드도 결국 프로덕션 코드의 연장선이며, 사람이 계속 읽고 유지보수해야 할 부채라는 점이다.

높은 결합도를 AI가 억지로 뚫어낸 테스트는 당연히 그 나쁜 구조의 세부 구현을 그대로 캡처하고 있다. 프로덕션 로직을 조금만 바꿔도 AI가 깡으로 뚫어둔 테스트 수십 개가 모조리 터져나간다.

생성 비용은 0원에 수렴할지 몰라도, 읽고, 이해하고, 유지보수하는 비용은 폭발한다. 나쁜 결합도를 AI의 힘으로 덮어두었더니, 그 결과물이 오히려 나쁜 구조를 영원히 고치지 못하게 만드는 벽이 되어 돌아온다.

(이렇게 '배설'된 코드들을 테스트코드라는 이유만으로 동료 개발자에게 코드리뷰로 들이미는것이 과연 정당한가? 너무 괴롭다.)

4. 그렇다면 우리는 무엇을 해야 하는가?

팀원들에게 "AI 쓰지 말고 아키텍처를 고민하면서 직접 테스트 코드를 짭시다" 라고 말하는 건 비현실적이다. AI의 생산성을 포기하자는 주장은 아무도 듣지 않는다.

대신 내가 선택한 액션 아이템은 "테스트 코드 작성 시 아키텍처와 스킬을 선언하게 만드는 것"이다.

AI가 테스트 코드를 대신 작성해 줄 수는 있지만, 그 코드가 품고 있는 아키텍처적 부채를 설명하고 선언하는 건 오직 개발자 자신만 가능하다.

결합도 및 픽스처 자진 신고: 이 테스트를 돌리기 위해 무리하게 무거운 픽스처(Fixture) 객체나 장황한 전/후처리를 몰아넣고 있진 않은가?
코드 스멜 선언: AI가 만들어준 테스트 코드가 지나치게 길거나 세부 구현을 흉내 내고 있다면, 단순히 PR에 올리는 게 아니라 "현재 프로덕션 코드가 결합도가 높아 테스트가 장황함"을 명시하기.
아키텍처 의도 말하기: AI가 뱉은 코드를 그대로 제출하지 말고, 이 테스트가 어떤 스킬(상태 검증, 행위 검증 등)을 사용했고 왜 이런 구조를 선택했는지 동료들에게 설명하기.

AI 시대에 좋은 개발자의 진짜 역량은 테스트 코드를 쳐내는 속도가 아니라고 생각한다. AI가 무식한 깡생산성으로 결합도를 뚫어버렸을 때, 그 장황한 테스트 코드 뒤에 숨은 '나쁜 구조의 경고 신호'를 알아채고 프로덕션 코드를 리팩토링할 수 있는 안목이 진짜 역량이다.

AI가 내 테스트 코드를 대신 짜줄 수는 있어도, 내 시스템의 아키텍처까지 책임져주진 않는다.

디아2 하다가 갑자기 OCR 공부

siyoon210 — Thu, 5 Mar 2026 08:17:32 +0900

디아블로2를 다시 시작했다. 예전이나 지금이나 이 게임의 진입장벽은 역시 '아이템 가치'를 아는 것에서 시작된다. 초보자 입장에서는 줍는 족족 커뮤니티나 거래 사이트를 뒤져야 하는데, 이게 여간 번거로운 게 아니다.

"그냥 화면을 찍으면 거래사이트 정보와 AI가 바로 가치를 알려줄 순 없을까?"

단순한 호기심에서 시작된 이 고민이 생각보다 깊은 삽질의 시작이 될 줄은 몰랐다.

기존 OCR과 비전 모델의 한계

처음엔 요즘 잘나가는 일반 OCR 모델과 비전(Vision) 모델에 냅다 스크린샷을 던져봤다. 결과는 참담했다. 그나마 비전 모델이 맥락을 짚어내긴 하지만, 실사용하기엔 정확도가 턱없이 낮았다.

디아블로2 특유의 반투명한 툴팁 배경과 독특한 폰트가 문제였다. 인간의 눈에는 명확해 보여도, 기계 입장에서는 배경 노이즈와 글자가 뒤섞인 지옥도였을 테니까. 결국 일반적으로 튜닝된 OCR로는 답이 없다는 결론에 도달했다.

나는 OCR(광학 문자 인식)에 대해 무지하다. 어떤 단계로 처리해야 효율적인지, 요즘 트렌드는 뭔지 하나도 모르는 상태에서 무작정 리서치에 뛰어들었다.

가장 먼저 눈에 들어온 건 PaddleOCR이었다. 커스텀 학습이 가능하다기에 덤벼봤는데, 아이템 문자를 제대로 인식시키려면 텍스트 라인을 한 줄씩 잘라서 학습시켜야 한다는 사실을 알게 됐다.

노가다로 일단 테스트

샘플로 120개 정도의 툴팁 라인을 확보했다. 한땀 한땀 이미지를 수정하며 학습 데이터를 만들었다. 진짜 못할 짓이다 싶었지만, 결과가 궁금해서 돌려봤다.

이렇게 하나씩 잘라서 훈련시켜야함..

결과: 학습 데이터 내에서는 꽤 정확하게 맞춘다. 과적합(Overfitting)일지도 모르겠지만, 어쨌든 '학습시키면 된다'는 희망은 봤다.
문제: 제대로 된 성능을 내려면 최소 1,000개 이상의 데이터가 필요하다는데, 120개 만드는 데도 진이 다 빠졌다. 자동화가 절실했다.

리서치를 좀더 해보니 YOLO와 OpenCV라는 도구를 알게되었다. 이걸 활용하면 내 노가다를 획기적으로 줄일 수 있을 것 같다.

YOLO: 전체 화면에서 아이템 툴팁 박스가 어디 있는지 영역을 찾아내는 데 사용.
OpenCV: 찾아낸 툴팁 박스 안에서 글자 라인별로 이미지를 정교하게 크롭(Crop)하는 데 사용.

이 과정은 단순히 학습 데이터를 만들 때뿐만 아니라, 실제 프로그램이 동작하는 '추론' 단계에서도 필수적이라는 걸 깨달았다. 아직 OpenCV가 내 생각만큼 깔끔하게 라인을 따줄지는 테스트해봐야겠지만, 적어도 '무식한 노가다'에서 '공학적인 접근'으로 한 걸음 나아간 기분이다.

유닛 테스트에서 '비즈니스 Fixture 객체'를 버려야 하는 이유

siyoon210 — Sun, 25 Jan 2026 09:51:19 +0900

유닛테스트 코드를 짜다 보면 어느덧 검증 로직보다 '테스트를 위한 준비 과정'이 더 길어지는 순간을 마주한다. 특히 특정 비즈니스 상태를 재현하기 위해 여러 도메인 모델을 조합하고 상태를 주입한 픽스처(Fixture) 객체를 공용으로 만들어 쓰기 시작할 때, 불행은 시작된다.

흔히 픽스처라고 하면 데이터베이스 연결 상태나 환경 변수 같은 인프라적 설정도 있지만 내가 경계하는 것은 비즈니스 상태를 미리 정의해둔 객체 덩어리다. 편리할 것 같지만 사실 이것은 테스트 코드의 건강을 해치는 독이 될 때가 많다.

1. 픽스처 객체는 테스트 코드의 의도를 알기 어렵게 만든다.

공용 픽스처 객체를 사용하는 테스트는 불투명하다. 테스트 코드를 읽을 때, `setupUser()`가 반환하는 픽스처 객체의 어떤 필드가 이 테스트의 성공과 실패를 결정하는지 한눈에 들어오지 않는다. 유저는 VIP 등급인가? 연령이 만 19세 미만인가? 아니면 단순히 이름이 비어 있는 상태인가?

테스트는 그 자체로 명세서가 되어야 하지만 상세한 상태가 픽스처 객체 내부에 숨겨지는 순간 테스트 코드는 해석이 필요한 암호문으로 변질된다.

2. 픽스처 객체는 필연적으로 여러 테스트가 의존한다.

비즈니스 요구사항은 끊임없이 변한다. 공용 픽스처 객체에 의존하는 테스트가 100개라고 가정해 보자. 비즈니스 규칙이 바뀌어 픽스처 객체의 기본 생성 로직이나 상태 값을 하나 수정하는 순간, 관련 없는 100개의 테스트가 도미노처럼 무너진다.

이때부터 개발자는 테스트 코드를 '신뢰'하는 것이 아니라 '수발'들게 된다. 테스트를 고치는 시간이 프로덕션 코드를 짜는 시간보다 길어진다면 그 테스트는 이미 자산을 넘어 부채가 된 것이다.

픽스처 객체는 생성되는 순간부터 엄연한 관리의 대상이다. 프로덕션 코드의 도메인 모델이 변경될 때마다 픽스처도 동기화해줘야 한다. 다양한 비즈니스 케이스를 대응하기 위해 FixtureA, FixtureB, ComplexFixtureC가 늘어나기 시작하면, 정작 중요한 비즈니스 로직보다 픽스처의 계보를 파악하는 데 더 많은 에너지를 쏟게 된다. 관리 비용이 기하급수적으로 비싸지는 기법인 셈이다.

3. 그럼에도 불구하고 유닛테스트에 픽스처를 써야한다면.. 프로덕션 코드를 의심해보자

복잡한 비즈니스 상태를 굳이 객체로 만들어 주입할 필요가 있을까? 유닛 테스트의 본질은 '격리'에 있다. 복잡한 연관 관계나 비즈니스 상태를 가진 객체가 필요하다면, 실제 객체를 생성할 것이 아니라 모킹(Mocking)을 활용해야 한다.

모킹을 사용하면 테스트가 검증하고자 하는 특정 상태만 명시적으로 드러낼 수 있다. 테스트 가독성은 올라가고, 실제 객체의 내부 구현 변경으로부터 테스트를 보호할 수 있다.

만약 모킹을 하기에 너무 힘들다라는 생각이 든다면, 그것은 픽스처 객체가 필요한 게 아니라 프로덕션 코드가 설계적으로 실패했다는 신호다.

지나친 역할 분담 실패: 하나의 클래스가 너무 많은 비즈니스 규칙을 품고 있어 테스트 준비가 복잡한 것일 수 있다.
낮은 격리 수준: 코드가 유닛 테스트를 할 수 없을 정도로 외부 의존성과 강하게 결합되어 있다는 뜻이다.

반복적인 설정과 복잡한 픽스처가 필요하다는 사실은 역설적으로 코드를 분리하라는 시스템의 신호이다. 픽스처 객체로 이 신호을 덮지 말고, 프로덕션 코드를 격리하고 분리하는 리팩토링을 시작해야 한다.

결론

픽스처 객체는 편리해 보이지만 장기적으로는 테스트의 가독성을 해치고 관리 비용을 폭증시킨다. 통합 테스트처럼 반드시 실제 객체 간의 흐름을 봐야 하는 경우가 아니라면 비즈니스 상태는 모킹으로 대체하자. 그리고 모킹조차 힘들 만큼 코드가 꼬여 있다면 픽스처를 만들지 말고 코드를 쪼개자. 그것이 테스트 코드와 프로덕션 코드 모두를 살리는 길이다.

ORM은 레거시가 될까?

siyoon210 — Sat, 27 Dec 2025 04:42:54 +0900

어느덧 개발자들 사이에서 JPA같은 ORM 기술은 언어를 가리지 않고 선택이 아닌 필수 교양이 되었다. 개발자 면접에서도 영속성 컨텍스트의 원리나 N+1 문제의 해결책을 묻는 것이 당연한 코스가 되었다. 하지만 문득 의문이 들었다. 당연하게 믿고 있는 이 도구가 사실은 레거시가 되어가지 않을까?

1. ORM은 왜 대세가 되었을까?

ORM을 배우는 이유는 명확했다. 지루하고 반복적인 CRUD 쿼리 작성을 자동화하여 개발 효율을 높이고, 테이블 중심이 아닌 객체지향적인 사고로 비즈니스 로직을 구현하기 위함이다.

하지만 지금은 AI가 코딩하는 시대다. 과거에는 수십 개의 컬럼을 매핑하고 쿼리를 짜는 것이 '고비용 작업'이었지만, 이제는 AI에게 스키마만 던져주면 최적화된 SQL과 DTO 매핑 코드를 1초 만에 뱉어낸다. 반복적인 코드 작성이 더 이상 개발자의 발목을 잡는 '비용'이 아니게 된 것이다.

객체지향적인 사고? 내가 본 실무를 기반으로 얘기해보자면 판타지에 가깝다. 우리가 만드는 대부분의 엔티티(Entity)는 결국 DB 테이블과 1:1로 매핑되어 사용된다. 이름만 엔티티일 뿐, 사실상 DB의 데이터를 담아 나르는 DTO 역할에 그친다. 누군가는 DTO가 아니라고 말하며 엔티티내에 캡슐화된 메서드 몇개 넣었다고 그것을 객체지향프로그래밍이라고 부를지 모르겠지만 나는 아니라고 본다. 이미 테이블 주도 개발을 한뒤에 객체지향 특성을 일부 넣는다고 그것이 객체지향 프로그래밍이라고 하기 어렵다. ORM으로 객체지향프로그래밍이 불가능하다고 말하는것이 아니다. 현실적으로 엔티티를 정말 객체지향적으로 설계하기 어렵다는 말이다.

엔티티와 도메인 객체를 완벽히 분리하여 순수한 도메인 주도 설계(DDD)를 실천하는 프로젝트는 너무 드물다. 만약 그 정도로 철저히 분리할 수 있는 구조라면, 역설적으로 그 매핑의 브릿지 역할을 굳이 무거운 ORM이 맡을 필요도 없다.

2. 편의를 가장한 문제 발생기, 그리고 비정상적인 학습 비용

ORM은 개발을 편하게 해준다고 약속하지만, 그 대가로 개발자의 머릿속을 복잡하게 만든다. 단순히 쿼리 몇 줄 안 쓰는 대가로 우리가 지불해야 하는 학습 비용은 과연 정당한가?

JPA를 제대로 쓰기 위해 우리는 '영속성 컨텍스트'라는 거대한 블랙박스를 공부해야 한다.

N+1문제, OSIV(Open Session In View), 더티 체킹, 1차 캐시.. 이름만 들어도 머리 아픈 이 개념들은 사실 DB의 기본 동작과는 거리가 먼, ORM이라는 도구가 만들어낸 인위적인 규칙들이다.

이렇게 JPA를 열심히 학습한 다음에 시니어들은 뭐라고 말하는가?

'결국 DB를 잘 알아야지..'

DB에 대한 학습도 추가적으로 해야한다. 그것도 ORM 이전시대와 다를바 없는 수준으로..

ORM이 뒤에서 어떤 쿼리를 생성하고 있는지 로그를 뒤져보며 성능을 튜닝하고, 영속성 컨텍스트의 복잡한 생명주기를 공부할 시간에 차라리 AI를 활용해 명시적인 SQL을 작성하는 것이 훨씬 생산적이지 않을까?

AI는 SQL뿐만 아니라 그 SQL을 담을 매핑 코드까지 완벽하게 짜준다. JPA 구현을 학습할 필요가 없어진 것이다. 예측 가능성은 개발자를 학습의 굴레에서 해방시키고 코드를 가볍게 만든다. 내가 쓴 쿼리만 나간다는 확신, 그것이 주는 심리적 안정감은 ORM의 마법보다 훨씬 값질수 있다.

대충 마무리 하자면..

기술은 시대의 요구에 따라 변한다. 한때 SQL의 지옥에서 우리를 구원해준 ORM은 분명 고마운 존재였다. 하지만 AI가 SQL을 대신 써주고, 도구의 복잡도가 본질인 비즈니스 로직을 압도하는 지금, 우리는 다시 단순함과 명확함으로 회귀해야 할 때가 아닐까.

마법 뒤에 숨어 ORM 철학을 공부하기보다, 투명한 코드로 시스템을 완전히 장악하는 것. 그것이 AI 시대를 살아가는 백엔드 개발자의 경쟁력이 되지 않을까 조심히 예측해본다.

다음 프로젝트에 JPA를 과감히 버리고 Spring JDBC를 사용해보고 싶다. 이에 대한 회고를 할수 있으면 좋겠다.

Next.js와 Supabase를 접고 다시 스프링으로

siyoon210 — Tue, 18 Nov 2025 08:30:22 +0900

나는 회사에서는 자바와 스프링을 주로 쓰는 백엔드 개발자로 일하지만, 개인적인 사이드 프로젝트에 대한 관심이 꾸준히 있었다. 그래서 개발 속도가 빠르고 유지보수가 편한 기술 스택을 따로 알아보고 공부하기 시작했다. 그러다가 Supabase와 Next.js로 프로젝트들을 만들기 시작했고, 개발 속도 측면에서는 꽤 만족스러웠다.

Supabase와 Vercel을 사용하면 서버비용 0원으로 시작할 수 있었고 서버 관리 부담도 거의 없어서 꽤 괜찮다고 생각했다. 프리티어를 넘는 트래픽이 오면 25달러와 20달러 정도는 충분히 낼 만한 프로젝트가 되리라 착각하기도 했다.

하지만 현실은 달랐다.
프리티어를 겨우 넘었을 뿐인데 매달 약 50달러의 비용이 발생했고, MAU가 크게 늘지 않으면서 이 고정비가 계속 유지되었다. 광고 수익은 5~10달러 수준이었기 때문에 사이드 프로젝트에 매달 40~50달러를 지출하는 구조는 지속 가능하지 않다는 결론에 도달했다. 게다가 Supabase 스토리지 비용은 특히나 사악하게 비쌌다. 비싼 걸 알면서도 귀찮아서 도입한 내 잘못이 맞지만, 그래도 너무 비싸다는 생각을 하지 않을 수 없었다. (혹여나 Supabase를 쓰려거든 반드시 스토리지는 반드시 S3를 붙여야한다.)

리액트와 Next.js에 대한 개인적인 회고도 만족스럽지 않았다. 리액트보다는 Next.js에 대한 불만족이 더 큰데 하이드레이션을 사용해서 프론트와 백엔드코드가 난잡하게 얽히기 시작한다. 물론 내가 메이저하게 사용하지 않고 경험과 지식이 모자라서 그럴수도 있다. ㅠㅠ..

사이드 프로젝트에서는 메인 기술스택과 다른 언어나 프레임워크를 사용하면 개발적인 견문이 넓어질 것이라는 기대가 있었다. 실제로 구현 과정에서 새로운 경험을 쌓기는 했지만, 어느 순간부터는 깊이 있는 공부보다는 구현 자체에만 집중하게 되었고, 그 과정에서 더 깊은 학습이 이뤄지지 않는 한계를 느끼게 되었다. 어찌보면 당연할수도 있다. 빠르게 개발하려고 고른 스택이니 공부할 시간이 있겠는가?

이런 고민들이 쌓이던 시점에 Supabase와 Vercel을 벗어나기 위해 마이그레이션을 고민하게 되었고, 그 과정에서 루비 온 레일즈에 자연스럽게 관심이 생겼다. 언어도 프레임워크도 익숙하지 않았지만, 레일즈의 빠른 개발 속도는 상당히 매력적으로 다가왔다. 게다가 hotwired 기술을 활용하면 리액트 없이도 SPA 같은 웹앱을 만들 수 있다는 점이 신선하게 느껴졌다.

개발속도가 빠른 웹프레임워크 레일즈, 라라벨 등등을 고민하던 중, 유지보수성과 개발 편의성을 일정 부분 내려놓게 만든 원인은 AI를 활용한 코딩 만족도가 너무 높아졌다는 점이었다. 마이그레이션 비용도 줄었고, 코드 작성 시간도 크게 단축되면서 굳이 익숙하지 않은 Next.js나 레일즈를 개발 편의를 위해 도입할 필요가 없다는 결론에 이르렀다.

결국 현재 진행 중인 프로젝트는 스프링부트로 마이그레이션하기로 결정했다. 서버도 DigitalOcean이나 AWS Lightsail로 옮기기로 했다. 이렇게 하면 순수 서버비는 월 5~10달러 정도로 예상되었고, 그러면 광고 수익과 거의 비슷해져 개인 비용 부담이 거의 사라지게 된다.

(참고로 레일즈의 hotwired 기술도 스프링부트에서 사용할수 있다.) https://docs.spring.io/spring-framework/reference/web/webmvc-view/mvc-fragments.html

서버 유지보수에 일정한 리소스가 들어가겠지만, 익숙한 기술 스택이고 회사에서는 담당하지 않는 부분(배포과정, 스프링시큐리티 등)까지 직접 다루게 되기 때문에 오히려 메인 스택과의 시너지도 기대된다.

회사의 마이크로서비스 환경에서는 안정적인 서버 자원을 기반으로 일하다 보니 어떤 부분에서는 안일해지기도 했는데, 사이드 프로젝트에서는 낮은 서버 자원을 다뤄야 하기 때문에 메모리 관리와 성능에 대한 고민도 다시 하게 되었다. (회사에서는 기본 힙 사이즈가 2~4GB였지만, 라이트세일에서는 256MB의 힙사이즈도 운영이 어느정도 가능한지 고민해본다..ㅋㅋ)

결국 이번 경험을 통해 깨달은 점은, 사이드 프로젝트는 새로운 기술을 배우는 재미도 중요하지만 지속 가능하고 효율적인 개발 환경도 중요하다는 것이었다. 익숙하지 않은 기술로 속도를 내기보다, 익숙한 스프링부트와 저렴한 서버 환경으로 안정적인 개발과 운영을 병행하는 것이 장기적으로 훨씬 현실적이고 만족스러운 선택이길 기대한다.

Exception throw를 두려워하지 말자.

siyoon210 — Sun, 2 Nov 2025 12:23:08 +0900

최근 코드를 보다 보니 문득 드는 생각이 하나 있었다.
“왜 이렇게 Exception catch가 숨어있지?”

백엔드 코드를 짜다 보면, 서비스 로직이라는 게 있고, 그 외의 ‘도구적인 작업’들이 있다.
DB를 쓰거나, 외부 API를 호출하거나, 캐시를 쓰거나, 이벤트를 전송하는 그런 것들.
근데 문제는... 이런 도구적인 부분에서 너무 과도한 예외 처리를 해버린다는 거였다.

물론 의도는 좋았다. 장애가 안 나게 막으려는 거니까.
근데 이게 꼭 좋은 건 아니라는 생각이 들었다.
왜냐면 예외를 그 자리에서 catch하고, 자체적으로 fallback을 처리해버리면
그건 서비스 로직 바깥에서 서비스 로직을 대신 결정해버리는 셈이었으니까.

예를 들어보자.
DB 저장이 실패했을 때, 외부 API 호출이 실패했을 때
그 상황에서 “fallback으로 빈값을 반환한다”거나 “그냥 로그만 찍고 무시한다”는 결정은,
사실 도메인 관점에서 굉장히 중요한 로직이었다.
어떤 경우에는 진짜 API 실패로 이어져야 했고,
어떤 경우에는 “괜찮아, 다음 단계로 진행해도 돼”라고 판단해야 했다.
그 판단은 결국 서비스 로직의 몫이지, DB나 API 호출 함수 내부의 몫이 아니었다.

그래서 오히려 throw를 더 적극적으로 고민해야 한다고 봤다.
“여기서 뭘 막을까?”보다 “이 실패를 위로 올렸을 때 서비스가 뭘 해야 하지?”를 고민하는 게 맞다고 생각했다.
그게 올바른 서비스 설계라는 생각을 했다.

그런데 코드를 보면 Output port (Repository, API Client..)쪽에 catch가 너무 많았다.
마치 “예외는 절대 밖으로 보내선 안 돼!” 라고 느껴졌다.

근데 그건 기계적인 방어 코드일 뿐, 서비스의 의미를 담은 로직은 아니었다.
catch의 남발은 오히려 코드의 구조를 이해하기 흐리게 만드는 것 같았다.

더 나아가 Checked Exception도 한 번쯤은 생각해봐야 하지 않을까.
실패 가능성이 명확하고, 호출자가 그걸 반드시 처리해야 하는 경우라면.
하지만 또 이걸 너무 남용하면 오히려 코드가 복잡해지고, Checked Exception을 안티패턴처럼 보는 분위기도 있으니까
이건 조심스럽게 접근해야 했다.

결론적으로 하고싶은말은, 도구는 도구일 뿐이다.
DB, API, 캐시, 이벤트 - 이런 건 서비스 로직을 구현하기 위한 수단이었고,
그 실패를 어떻게 다룰지는 온전히 서비스의 결정이 되어야 했다.
그래서 catch를 줄이고, throw를 고민해야 한다.
예외는 막는 게 아니라, 의미 있게 다루어져야 한다.

Spring Batch에서 JSON 형식 JobParameter 전달하기

siyoon210 — Sat, 1 Nov 2025 13:24:05 +0900

개발 환경

Spring Boot: 3.5.0

Spring Batch: 5.2.2

Java: 21

문제 상황

Spring Batch Job을 실행할 때 아래와 같은 JSON 문자열을 파라미터로 전달하고 싶었습니다.

{
  "myType": "MY_TYPE_VALUE",
  "myArray": [
    {
      "key": {"id": "001", "category": "MY_CATEGORY_VALUE"},
      "param": {"foo": "002", "bar": "sampleValue"}
    }
  ]
}

하지만 일반적인 방식으로 전달하면 다음과 같은 에러가 발생했습니다:

JobParametersConversionException: Unable to parse job parameter

왜 JSON 전달이 안 될까?

DefaultJobParametersConverter의 한계

Spring Batch의 DefaultJobParametersConverter는 다음과 같은 형식으로 파라미터를 파싱합니다:

paramKey=value,type

예를 들어:

count=100,long
name=test,string

문제는 JSON에도 , (쉼표)가 있다는 것입니다!

{"name":"test","age":30}
        ↑ 이 쉼표를 타입 구분자로 인식!

Spring Batch의 JsonJobParametersConverter (이거 안씀 주의)

Spring Batch 5.x부터 org.springframework.batch.core.converter.JsonJobParametersConverter가 제공됩니다.하지만 이것은 제가 원하는 방식과 차이가 있었는데:

Spring Batch JsonJobParametersConverter는 JobParameters 전체를 JSON으로 직렬화/역직렬화하는 용도입니다.

{
  "paramName": {
    "value": "actualValue",
    "type": "java.lang.String",
    "identifying": true
  }
}

이를 위해서 기존 파라미터를 value, type을 명시하고, 다시 한번 이를 문자열 형식으로 escape 시켜야 하므로 파라미터 생김새가 지나치게 복잡한 문제가 있었습니다.

해결 방법: 커스텀 Converter

Json 형식의 파라미터를 구분하고 무조건 String 타입으로 처리하는, 즉 쉼표 파싱을 건너뛰는 커스텀 컨버터를 구현합니다.

예시 코드에서는 'JsonStr' 으로 끝나는 프로퍼티를 String 타입으로 판단하도록 했습니다.

import org.jspecify.annotations.NonNull;
import org.jspecify.annotations.Nullable;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersBuilder;
import org.springframework.batch.core.converter.DefaultJobParametersConverter;
import org.springframework.stereotype.Component;

import java.util.Properties;

/**
 * Json 형식 문자열 파라미터를 String으로 인식하기 위한 커스텀 JobParametersConverter
 * 
 * DefaultJobParametersConverter 구현상 ',' 로 value와 type을 구분하는데
 * JSON은 구조상 ','가 있어서 별도 처리가 필요함
 * 
 * JsonStr로 끝나는 모든 프로퍼티는 자동으로 String으로 등록됩니다.
 * 예: batchRequestJsonStr -> batchRequestJsonStr (String 타입)
 */
@Component
public class JsonStringAvailableJobParametersConverter extends DefaultJobParametersConverter {

    private static final String JSON_STR_SUFFIX = "JsonStr";

    @Override
    public @NonNull JobParameters getJobParameters(@Nullable Properties properties) {
        if (properties == null || properties.isEmpty()) {
            return super.getJobParameters(properties);
        }

        // JsonStr로 끝나는 프로퍼티와 아닌 프로퍼티 분리
        Properties jsonStrProperties = new Properties();
        Properties otherProperties = new Properties();
        
        for (String key : properties.stringPropertyNames()) {
            if (key.endsWith(JSON_STR_SUFFIX)) {
                jsonStrProperties.setProperty(key, properties.getProperty(key));
            } else {
                otherProperties.setProperty(key, properties.getProperty(key));
            }
        }

        // 다른 Properties는 DefaultJobParametersConverter에 위임
        JobParameters baseParams = super.getJobParameters(otherProperties);
        
        // JsonStr로 끝나는 프로퍼티들을 String으로 추가
        JobParametersBuilder builder = new JobParametersBuilder(baseParams);
        for (String key : jsonStrProperties.stringPropertyNames()) {
            String value = jsonStrProperties.getProperty(key);
            builder.addString(key, value);
        }

        return builder.toJobParameters();
    }
}

커스텀 Converter를 Bean으로 등록하고 사용처에서 아래와 같이 사용합니다.

@Value("#{jobParameters['batchRequestJsonStr']}")

배치 실행시 문자열 전송을 위해서 escape 처리는 필요합니다

--spring.batch.job.name=myBatchJob
batchRequestJsonStr={\"myType\":\"MY_TYPE_VALUE\",\"myArray\":[{\"key\":{\"id\":\"001\",\"category\":\"MY_CATEGORY_VALUE\"},\"param\":{\"foo\":\"002\",\"bar\":\"sampleValue\"}}]}

장점

복잡한 JSON 객체를 파라미터로 전달 가능

기존 파라미터 처리 방식은 그대로 유지

확장 가능: 여러 JSON 파라미터 추가 가능

명시적: 'JsonStr' 접미사로 의도 표현

MSA에서 헥사고널 아키텍처가 적절하지 않은 이유

siyoon210 — Tue, 1 Jul 2025 07:36:11 +0900

의존 역전에 대한 고찰

객체지향의 가장 큰 장점은 의존 방향을 우리가 원하는 대로 제어하기 쉽다는 점이다. 예를 들어 A → B 구조에서 B의 변동 가능성이 클 경우, A → I ← B 형태로 구조를 바꿔서 A를 변화와 확장으로부터 보호하는 것, 그게 핵심이다. 여기서 중요한 건 A와 I가 같은 바운더리 안에 있어야 한다는 점이다. 왜냐하면 I는 A가 원하는 인터페이스이기 때문이다. 그런데 의존을 역전시켰다고 하면서 I와 B를 같은 바운더리에 위치시키는 경우가 종종 보이는데 이는 의존 역전에 대한 오해다.

의존 역전의 본질은 인터페이스를 사용했다는 것 자체가 아니라, 변동에 대한 제어 주도권을 역전시켜 가져왔다는 점이다.

마이크로서비스에서의 의존역전

MSA의 기술적 성장은 안정화되어 가고 있지만, 개발자들의 인식은 그에 미치지 못하는 경우가 많다. 대부분의 마이크로서비스는 원래 하나의 모놀리식 애플리케이션이었고, 결국 하나의 비즈니스 문제를 해결하기 위한 것이라는 사실을 잊어서는 안된다.

여기서 중요한 개념이 도메인이다. 도메인은 우리가 해결하고자 하는 비즈니스 문제이지, 특정 서버나 애플리케이션이 아니다. 그런데도 종종 개발자들은 도메인을 하나의 서버로 대입시키고 기술적 경계에만 집중한다. 이러다보면 실무에서 다른 마이크로서비스와의 협업이 어색해질수 있다. 도메인은 여러 마이크로서비스의 묶음으로 봐야 자연스럽다. 왜냐하면 우리가 해결해야 하는 비즈니스 문제는 특정 서비스 하나에 국한되지 않기 때문이다.

MSA를 다루는 개발자들이 도메인을 하나의 거시적인 비즈니스로 인식하지 못하고, 자신이 관리하는 서비스에서 다른 서비스와의 결합도를 낮추는 데에만 집중한다는 것이다. 그런데 인터페이스 하나 달랑 만든다고 해서 결합도가 낮아졌다고 생각하는 건 굉장한 착각이다. 실무 경험이 있다면 조금만 생각해보자 의존하는 다른 서버의 의존성을 떨어트린다고 해서 진짜 내가 관리하는 서버의 도메인 객체들은 보호받는가? 아닐 확률이 높다. 결국 하나의 거시적 도메인이라면 강결합을 받아드리는것이 자연스럽다.

진짜 의존 역전이라면, 내가 호출하는 외부 서비스의 변화와 확장에도 불구하고, 제어 주도권이 나의 서비스에 있어야 한다. 그런데 현실적으로 이는 거의 불가능하다. 왜냐하면 기획의 시선에서는 마이크로서비스 하나하나에 관심이 없고, 전체 비즈니스에 관심이 있기 때문이다. 그리고 그게 당연한 현실이다.

결국 의존 역전이 의미 있는 순간은 다음과 같다:

인프라스트럭처 혹은 온전한 외부 서비스(예: PG, 지도 API)
관리하는 서버가 의존하는 기능에 대해 온전히 제어권을 갖고 의존 역전이 가능할때
명백한 변화 가능성과 확장이 예측될 때

마이크로서비스에서 헥사고널 아키텍처가 어색한 이유

이제 본론이다. 왜 마이크로서비스 환경에서는 헥사고널 아키텍처가 어색할까?

하나의 서버가 하나의 도메인이 될 수 없기 때문이다. MSA는 의도적으로 서버를 쪼갠 것이고, 그 과정에서 도메인이 함께 쪼개졌다고 착각하는 경우가 많다. 하지만 도메인은 여전히 하나의 비즈니스 문제이고, 여러 서비스에 걸쳐 흩어져 있다. 하나의 서비스에 헥사고널 아키텍처를 적용하면 강제로 도메인을 분리한 듯한 어색함이 발생한다.

코드상으로는 보호된 것처럼 보여도, 실제론 그렇지 않다. 왜냐하면 기획자가 정의한 도메인은 하나의 서버나 하나의 코드베이스로 표현될 수 있는 개념이 아니기 때문이다.

헥사고널 아키텍처를 적용해서 나만의 완벽한 세상을 구축했다고 착각할 수도 있다. 어떤 확장이 와도 우아하게 대처할 수 있을 것처럼 느껴진다. 하지만 현실은 기획자의 피드백 한 마디에 그 세계는 쉽게 무너진다. 결국 그들이 상상한 ‘비즈니스 문제’가 개발지의 아키텍처 경계를 넘나들게 만들기 때문이다.

그리고 헥사고널 아키텍처는 비용이 많이 든다. 패키지 수만 봐도 일반적인 레이어드 아키텍처보다 4배 이상 많아진다. (https://youtu.be/g6Tg6_qpIVc?si=4O7tJRWnXaii1uQX&t=1823) 작은 팀, 빠른 개발, 빈번한 피드백 루프가 필요한 MSA 환경에서는 상당히 부담스러운 구조다. 외부 시스템에 대한 의존 영향을 줄이고 싶다면 꼭 헥사고널 아키텍처일 필요는 없다. Adapter나 ACL(anti-corruption layer)만으로도 충분히 해결 가능한 경우가 많다. 스프링 같은 DI 프레임워크를 사용해서 비즈니스 컴포넌트를 관리한다면 테스트 작성에도 어려움이 없다.

헥사고널 아키텍처는 훌륭한 개념이다. 하지만 모든 곳에 적용할 수 있는 만능 도구는 아니다. 특히 마이크로서비스 환경에서는, 아키텍처보다는 비즈니스 문제의 흐름과 현실적인 제어권 분포를 더 먼저 고민해야 한다. 진짜 의존 역전은 인터페이스 몇 개로 해결되지 않는다. 현실에 맞는 구조를 고민해야 한다.

Next.js + Vercel 환경에서 한글 검색 구현 삽질기록

siyoon210 — Sun, 4 May 2025 20:23:44 +0900

Next.js + Vercel 환경에서 한글 검색 구현기: 삽질기부터 직접 bigram 구현까지

Next.js + Vercel 환경에서 한글 검색 기능 구현이 의외로 골치 아픈 일이었고 이를 정리하기 위해서 공유합니다.

1) LIKE 검색? 간단하지만 성능에 불안 요소

처음엔 누구나 WHERE title LIKE '%검색어%'로 시작합니다.
간단하죠. 하지만 다음과 같은 문제가 있습니다:

인덱스를 타지 못해 데이터가 많아지면 검색 속도가 확 느려짐
전체 스캔이 발생해 비용이 비쌈
단순 포함 검색이라 의미 기반 검색 불가

그래서 바로 포기했습니다.

2) PostgreSQL tsvector? …한글 형태소 분석은 미지원

PostgreSQL의 tsvector + to_tsvector 조합은 풀텍스트 검색을 위해 매우 강력한 기능입니다.
예시:

SELECT * FROM posts WHERE to_tsvector('english', title) @@ plainto_tsquery('english', 'search');

하지만 문제는 한글입니다. PostgreSQL 기본 설정에선 영어, 프랑스어 등은 지원하지만 한국어는 형태소 분석기가 없어서 의미 단위로 쪼갤 수 없습니다.

그래서 tsvector를 그대로 쓸 수 없다는 한계가 있었죠.

tsvector?

간단히 말해 tsvector는 검색을 빠르게 하기 위한 텍스트 인덱스 포맷입니다.
단어 단위로 쪼개서 인덱싱하고, tsquery로 빠르게 검색할 수 있게 해줍니다.

3) 형태소 분석기 라이브러리 사용? → Vercel에서 막힘

여러 형태소 분석기를 활용하려 했지만, Vercel은 서버리스 환경이라:

별도 라이브러리를 설치하거나
자바나 C++ 기반으로 실행되는 것 자체가 불가능합니다.

Vercel은 무조건 빠르고 짧게 끝나는 함수 중심으로 돌아가기 때문에, 별도 형태소 분석기는 애초에 구조적으로 어렵습니다.

4) ETRI 형태소 분석기 사용? → IP 차단됨

다음 시도로 ETRI 공개 API를 활용했는데, 여기서도 문제가 발생합니다. (https://aiopen.etri.re.kr/)

서버리스는 호출할 때마다 서버 IP가 바뀌는 구조
일정 횟수 초과되면 "다중 IP 접근으로 인한 차단" 발생
결과적으로 ETRI API도 지속적으로 쓸 수 없음

5) pg_bigm 확장 모듈? → Supabase에서 미지원

PostgreSQL에는 pg_bigm이라는 강력한 Bigram 기반 검색 확장이 있습니다.
한글처럼 공백 없이 붙어 있는 언어에서 유용하죠.

하지만 Supabase에서는 아직 pg_bigm 확장을 공식 지원하지 않습니다.
설치하려면 커스텀 서버를 써야 하고, 그건 Supabase를 쓰는 이유 자체를 흐리게 만들죠.

Bigram?

Bigram은 문자열을 두 글자씩 끊어서 분석하는 방식

최종 해결책: 직접 Bigram + tsvector 조합 구현

결국 선택한 방법은 직접 Bigram으로 쪼개서 tsvector 형태로 저장하고, 이를 활용하는 방식이었습니다.

예시:

// 예: "한국어검색" → ["한국", "국어", "어검", "검색"]
function toBigram(str: string): string[] {
  const grams = [];
  for (let i = 0; i < str.length - 1; i++) {
    grams.push(str.slice(i, i + 2));
  }
  return grams;
}

그리고 이 결과를 미리 tsvector 타입 형태로 변환해서 별도 컬럼에 저장해두고, 검색 키워드도 bigram 형태로 만들어 tsquery를 수행합니다.

+ 컬럼은 tsvector 타입이어야 하고, gin 인덱스를 걸어야 성능상 이점이 있습니다.

마무리

Next.js + Vercel + Supabase 조합에서 한글 검색을 제대로 구현하기 위한 삽질기를 정리해봤습니다.

LIKE는 성능상 한계
PostgreSQL 기본 tsvector는 한글 미지원
외부 형태소 분석기/서비스는 서버리스에서 사용이 어려움
그래서 결국 Bigram + tsvector 방식으로 직접 해결

비슷한 환경에서 고민 중이라면, 이 글이 조금이나마 도움이 되었으면 좋겠습니다.