내 집은 어디에

Project

전국 아파트 실거래가 1,055만 건을 수집·최적화해 단지·지역으로 조회하는 서비스입니다.
부하 테스트로 병목을 실측한 뒤 인덱스·캐시·Materialized View로 개선하였습니다.

기간 2026. 6 ~ 2026. 7 | 인원 1명 (개인)

핵심 구현

01Trigram 인덱스로 단지명 부분검색 최적화
→ DB 84.2% · 응답 53.7% 개선

02Materialized View로 월별 시세 집계 최적화
→ 88.9% 개선 (집계 쿼리)

03Redis 대신 Caffeine 로컬 캐시 선택
→ 76% 개선 (응답시간)

사용 기술

Java 21

Spring Boot Spring Batch

React

PostgreSQL Caffeine(로컬캐시)

Railway

Docker

k6

프로젝트 링크

Featured Projects

프로젝트 핵심 사항

프로젝트 안에서 어떤 문제를 어떻게 해결, 대비했는지 가장 중요한 사례만 정리하였습니다.

01

Trigram 인덱스로 LIKE 부분검색 최적화

인덱스가 있는데도 느린 이유를 EXPLAIN으로 진단하고 Trigram 인덱스로 교체했습니다.

PostgreSQL Trigram GIN Index

SITUATION상황

B-Tree 인덱스(idx_complexes_name)가 이미 걸려 있었지만, LIKE '%힐스테이트%' 패턴에선 인덱스를 타지 않아 43,360건 전체를 Seq Scan하고 있었다 (13.183ms).

TASK과제

인덱스가 있는데도 Seq Scan이 나는 원인 진단
부분 문자열 검색(%x% 패턴)을 인덱스로 가속

ACTION실행

기존 B-Tree 인덱스 — 접두어(x%)만 지원, %x% 패턴엔 무용지물임을 EXPLAIN으로 확인 → 한계 확인
Trigram(GIN) 인덱스 — 문자열을 trigram으로 분해해 역인덱스 구성, %x%도 교집합 매칭으로 지원. 1~2글자는 UI 입력 제한으로 대응 → 선택

RESULT결과

DB 쿼리 — 84.2% 단축 (13.183ms → 2.088ms)

k6 p95 — 53.7% 단축 (29.38ms → 13.58ms)

💡 배운 점: DB 레벨 개선폭과 HTTP 전체 구간 개선폭은 다르다. 커넥션 풀 대기·네트워크가 그대로 남아있기 때문에 쿼리 하나가 빨라졌다고 전체 응답시간이 비례해서 빨라지지 않는다.

포스팅 보기

02

Materialized View로 월별 시세 집계 사전계산

매 요청마다 반복되는 집계 연산을 사전 계산된 테이블로 대체했습니다.

PostgreSQL Materialized View REFRESH CONCURRENTLY

SITUATION상황

단지 상세 페이지의 월별 시세 차트 API가 매 요청마다 연도별 파티션을 순회하며 그 자리에서 GROUP BY 집계를 수행하고 있었다. 실행시간 3.344ms.

TASK과제

조회 성능을 개선하되 매월 새로 들어오는 배치 데이터와의 정합성 유지
갱신 중에도 서비스 중단 없이(무중단) 최신화

ACTION실행

요청 시 DB 직접 집계 유지 — 데이터가 늘수록 스캔 대상 파티션도 늘어나고, 매 요청마다 집계 쿼리를 그 자리에서 실행하는 구조라 성능이 구조적으로 저하 → 제외
일반 VIEW — 쿼리에 별칭만 붙인 것이라 조회할 때마다 원본을 그대로 다시 스캔, 성능 이점 없음 → 제외
Materialized View + REFRESH CONCURRENTLY — 결과를 실제 테이블처럼 디스크에 저장해 인덱스도 가능. UNIQUE INDEX로 갱신 시 변경분만 diff-apply해 읽기 잠금 없이 무중단 갱신 → 선택

RESULT결과

DB 쿼리 — 88.9% 단축 (3.344ms → 0.373ms)

파티션 4개 스캔 → MV Index Scan

배치 완료 직후 자동 REFRESH

💡 배운 점: 읽기 위주 데이터는 "쓰기 시점 비용"과 "읽기 시점 성능"을 트레이드오프할 수 있다. CONCURRENTLY 갱신은 UNIQUE KEY가 old/new 행을 매칭해 diff를 낼 수 있어야만 작동한다.

포스팅 보기

03

Redis 대신 Caffeine 로컬 캐시로 전환

"캐시 = 무조건 빠름"이 아니라는 걸 실측으로 확인하고 구조를 바꿨습니다.

Spring Cache

Redis Caffeine

SITUATION상황

시도/시군구 지역 목록을 매 요청마다 DB에서 반복 조회하고 있었다 (7.13ms).

TASK과제

반복 조회되는 정적 데이터의 응답속도 개선
서비스 특성(단일 인스턴스, 변경 빈도가 낮은 참조 데이터)에 맞는 캐시 전략 선택

ACTION실행

DB 직접 조회 유지 — 반복 호출로 불필요한 DB 부하 발생 → 제외
Redis 캐시 — 별도 프로세스라 네트워크 왕복이 발생하고, 객체를 JSON으로 직렬화/역직렬화하는 비용이 DB 조회 절감분을 상당 부분 상쇄. 실측 결과 7.13ms → 5.41ms (24% 개선에 그침) → 폐기
Caffeine 로컬 캐시 — 같은 JVM 힙 메모리를 그대로 참조하므로 네트워크·직렬화 비용이 0에 가까움. @Cacheable 어노테이션으로 비즈니스 로직 변경 없이 Spring Cache 추상화를 통해 캐시 적용 → 선택

RESULT결과

응답시간 — 76% 단축 (7.13ms → 1.71ms)

Redis 대비 3배 이상 빠름

💡 배운 점: 캐시를 붙이기 전에 데이터 특성(단일 인스턴스 여부, 데이터 크기, 조회 빈도)을 먼저 따져야 한다. Redis의 장점이 필요 없는 상황에서는 오히려 오버헤드만 늘어난다.

포스팅 보기

TroubleShooting

트러블 슈팅

문제를 발견했을 때 증상만 막는 대신, 원인이 된 구조를 추적하고 운영 중 다시 터지지 않도록 설계까지 바꾼 사례를 담았습니다.

데이터 수집 중 실패 한 건이 전체 재수집을 유발하던 문제

Spring Batch Chunk 기반으로 트랜잭션을 분리하고 재시작 가능한 구조를 적용해, Tasklet 단일 트랜잭션에서 중간 실패 시 전체를 처음부터 재수집해야 했던 문제를 해결했습니다.

포스팅 보기

문제 요약

국토부 API로 전국 250개 시군구 데이터를 수집하는 배치가 전체를 단일 트랜잭션으로 처리하고 있었다. 수집 중 API 타임아웃이나 순간 장애 하나가 발생하면 그 시점까지의 작업이 전부 롤백되고, 처음부터 다시 데이터를 수집해야 했다.

Before Tasklet 단일 트랜잭션으로 전체 수집

250개 시군구 수집이 하나의 트랜잭션 단위

중간 실패 시 처리 여부와 무관하게 전체 재실행 필요

중복 수집 방지 로직 없음

→

After Chunk + Skip/Retry + 재시작 가능한 구조

500건 단위 Chunk로 트랜잭션 분리, 중복 데이터는 skip 후 진행

PipelineLog에 완료된 시군구를 기록해, 재실행 시 이미 처리된 시군구는 건너뛰고 실패 지점부터 재개

ON CONFLICT DO NOTHING으로 중복 INSERT 방지(멱등성 확보)

핵심 정리

대량 외부 API 연동 배치는 "전부 성공 아니면 전부 실패"가 아니라, 실패 단위를 최소화하고 실행 이력을 남겨 재시작 가능하게 설계해야 한다. 멱등성까지 갖추면 재시도해도 데이터가 꼬이지 않는다.

API 대량 호출의 복합 문제 해결 — 봇 차단, 버퍼 초과, 속도 제한

국토부 실거래가 API를 대량 호출하는 과정에서 연달아 발생한 요청 차단·응답 처리·속도 제한 문제를, WebClient 설정과 RateLimiter 도입으로 해결했습니다.

문제 요약

전국 시군구를 순회하며 국토부 API를 호출하는 초기 구현에서 세 가지 문제가 연달아 발생했다. WebClient 기본 설정으로 요청 시 일부가 차단되었고(User-Agent 미지정), 한 번에 수천 건이 오는 대량 응답이 기본 메모리 버퍼(256KB)를 초과해 예외가 발생했으며, 호출 속도가 빨라 국토부 서버로부터 429 Too Many Requests 응답을 받았다.

Before WebClient 기본 설정, 무제한 연속 호출

User-Agent 미지정 → 일부 요청이 봇으로 간주되어 차단

기본 버퍼 256KB → 대량 응답 시 DataBufferLimitException 발생

속도 제어 없이 연속 호출 → 429 Too Many Requests 반복 발생

→

After WebClient 커스터마이징 + RateLimiter 도입

defaultHeader로 User-Agent 지정해 브라우저 요청처럼 처리

maxInMemorySize를 10MB로 상향해 대량 XML 응답 처리

Resilience4j RateLimiter로 초당 5건 제한, 초과 호출은 자동 대기

핵심 정리

공공 API는 문서화되지 않은 방어 로직(봇 차단, 속도 제한)이 있는 경우가 많아, 실제로 호출해보며 원인을 하나씩 역추적해야 한다. 프레임워크 기본값(버퍼 크기 등)도 항상 우리 데이터 규모에 맞는 건 아니다.