권동하

Backend Developer

안녕하세요, 측정하고 개선하는 신입 개발자 권동하입니다.

Contact & Channels

• Email|ansqhrl3037@gmail.com

• Github|https://github.com/ssyy3034

• Blog|https://velog.io/@ansqhrl3037

• Portfolio|https://www.ssyy3034.dev/

문제의 원인을 끝까지 파고듭니다

문제를 만나면 로그와 지표를 통해 원인을 추적합니다. 아직 배워야 할 것이 많지만, 원인을 찾고 해결한 경험이 가장 확실한 배움으로 이어진다고 생각합니다.

학습한 내용을 실제 프로젝트에 적용하고, 개선 결과를 수치로 확인하며 배워가고 있습니다.

탄탄한 기본기 위에서 문제를 풉니다

크래프톤 정글에서 OS 커널(Pintos)을 직접 구현하며 시스템 동작 원리를 공부했습니다.

이 경험 덕분에 커넥션 풀이 왜 고갈되는지, 락이 어떤 상황에서 필요한지를 원리부터 접근할 수 있었고, 실제 프로젝트에서 장애 원인을 파악하는 데 도움이 됐습니다.

같이 일하는 경험을 더 좋게 만들고 싶습니다

3년간 서비스직 아르바이트에서 팀리더로서 다양한 팀원들과 일하며, 불편함이 보이면 먼저 개선 방법을 찾아 제안하는 습관이 생겼습니다.

개발 팀에서도 같은 태도로, 커밋·PR 작성이 팀 병목임을 파악하고 Antigravity의 커스텀 커맨드를 활용해 Git 컨벤션 자동화를 구축하고, 과정 내 타 팀까지 확산시켰습니다.

기술적인 내용도 듣는 사람이 이해하기 쉽도록 맥락을 함께 전달하려고 합니다.

StoLink

Cascading Failure 해결 · N+1 최적화 · 결제 동시성 제어

2025.12 - 2026.02

Fullstack Developer · 5인 팀

웹소설 작가를 위한 세컨드 브레인 서비스입니다. 에디터에서 집필하면 AI가 글을 분석하고, 월드 페이지에서 인물·관계·사건을 시각화합니다. 독자는 StoRead에서 관계도와 함께 작품을 열람할 수 있습니다.

크래프톤 정글 최종 프로젝트 (5인 팀). OAuth2 인증, 토스페이먼츠 결제 연동, 문서 CRUD 등 백엔드와 Canvas 관계도, Tiptap 에디터, 폴더 트리 사이드바 등 프론트엔드를 담당했습니다. SVG → Canvas 전환으로 관계도 INP를 420ms에서 64ms로 개선하고, 외부 API 타임아웃 누락으로 인한 Cascading Failure를 쓰레드 덤프 분석으로 추적하여 해결했으며, 결제 동시성 제어는 Testcontainers로 100스레드 환경에서 정합성을 검증했습니다.

Architecture

450ms → 25ms

문서 조회 API

100스레드 / 100%

결제 잔액 정합성

420ms → 64ms

인물 관계도

1,000줄 → 150줄

AI 컨텍스트 최적화

Backend

계층형 문서 조회 N+1 → Fetch Join + In-Memory 트리

450ms → 25ms (18배)

PROBLEM

사이드바 문서 목록 조회에서 쿼리가 대량 발생하고, 응답시간이 450ms까지 느려졌습니다.문서 30개를 조회할 때 각 문서의 부모(parent) 관계를 Lazy Loading으로 개별 SELECT하는 구조여서, 문서 수에 비례해 쿼리가 늘어나는 N+1 문제가 발생했습니다.

•실측 응답시간 450ms, 사이드바 열 때 뚜렷한 지연 체감
•쿼리 로그 확인 후 원인 특정

APPROACH

Fetch Join으로 1쿼리 로드 후, HashMap O(n) 트리 조립으로 해결했습니다.@BatchSize도 검토했지만, 사이드바 트리는 전체 문서가 항상 필요해 부분 로딩의 이점이 없었습니다. Fetch Join으로 전체 로드 후 DocumentTreeResponse.from()으로 필요 필드만 DTO에 매핑해 엔티티 그래프 탐색을 차단했습니다.스크리브닝 모드(무한 스크롤)는 Pageable이 필요해 Fetch Join 시 메모리 경고가 발생, 네이밍 쿼리로 분리해 해결했습니다.

RESULT

쿼리 61개 → 1개, 응답 450ms → 25ms로 18배 개선.Chrome DevTools Network 탭에서 응답 시간을 측정해 확인.

외부 API 타임아웃 누락 → 톰캣 쓰레드풀·HikariCP 커넥션풀 연쇄 고갈

외부 서버 장애 → 전체 서비스 마비 전파 차단

PROBLEM

프로덕션 서버가 간헐적으로 모든 API 요청에 응답하지 못하고 멈추는 장애가 발생했습니다.크롬 개발자 도구에서 API 요청이 타임아웃으로 실패하는 것을 확인했으나, 서버의 CPU·메모리는 정상이었습니다. 쓰레드 덤프를 떠서 분석한 결과, 다수의 톰캣 쓰레드가 AI 이미지 서버 헬스체크용 RestTemplate.getForObject()에서 Socket Read(RUNNABLE) 상태로 블로킹되어 있었습니다. 이 호출이 @TransactionalEventListener 내부에서 @Transactional(propagation = REQUIRES_NEW)로 별도 트랜잭션을 할당받은 상태에서 실행되고 있어, 외부 서버 무응답 시 쓰레드가 DB 커넥션을 점유한 채 무한정 대기했습니다.

•대기 쓰레드가 누적되며 HikariCP 커넥션 풀 고갈
•후속 요청이 커넥션을 획득하지 못하고 WAITING 상태로 전이
•최종적으로 톰캣 메인 쓰레드 풀 전체가 마비되는 Cascading Failure

APPROACH

쓰레드 덤프를 분석해 원인 추적에 들어갔습니다.추적해보니 해당 RestTemplate의 Timeout을 @Value 필드 주입으로 설정했으나, 빈 라이프사이클상 필드 주입은 생성자 이후에 이루어지므로 RestTemplate 생성 시점에는 값이 0인 채로 남아 기본값(무한 대기)으로 동작하고 있었습니다.

•필드 주입이 빈 라이프사이클 문제의 근본 원인임을 파악하고, 해당 서비스의 설정 주입 방식을 생성자 주입으로 리팩토링
•빈 생성 시점에 Timeout이 확실히 반영되도록 수정
•외부 서버 미응답 시 5초 후 ImageServerNotHealthyException을 던지고 즉각 DB 커넥션과 쓰레드를 반환

RESULT

이전에는 대기 요청 20건만으로 서버 전체가 마비되었으나, 수정 후에는 외부 서버가 완전히 다운된 상황에서도 코어 서비스 응답이 정상 유지되었습니다. 잦았던 수동 컨테이너 재시작 운영 이슈가 해소되었고, 외부 시스템 장애가 내부로 전파되는 Cascading Failure를 구조적으로 격리했습니다.

sequenceDiagram participant C as Client participant T as Tomcat Thread Pool participant H as HikariCP (max 20) participant HC as HealthChecker participant AI as AI Image Server (Down) rect rgb(254, 226, 226) Note over T,AI: Before — @Value 필드 주입 → Timeout 미적용 → Cascading Failure C->>+T: API 요청 T->>+H: REQUIRES_NEW → 커넥션 획득 H->>+HC: RestTemplate.getForObject() HC->>AI: GET /health (timeout = ∞) Note over HC,AI: ⚠️ Socket Read(RUNNABLE) 상태로 블로킹 Note over H: ⚠️ DB 커넥션 점유 (반환 불가) Note over T,H: 풀 고갈 → 후속 요청 WAITING 전이 → 전 API 마비 end rect rgb(220, 252, 231) Note over T,AI: After — 생성자 주입으로 Timeout 확실히 반영 C->>+T: API 요청 T->>+H: REQUIRES_NEW → 커넥션 획득 H->>+HC: RestTemplate.getForObject() HC->>AI: GET /health (timeout = 5s) Note over HC,AI: 5초 후 SocketTimeoutException HC-->>-H: throw ImageServerNotHealthyException H-->>-T: 커넥션 즉시 반환 ✓ T-->>-C: 에러 응답 (장애 격리 성공) end

Cascading Failure 발생 메커니즘과 Fail-Fast 타임아웃 적용 후 격리

결제 PG 외부 API 호출에 의한 DB 커넥션 풀 고갈 방지

결제 장애 → 전체 서비스 전파 차단

PROBLEM

위 Cascading Failure를 겪은 뒤, 결제 플로우에도 동일한 구조적 위험이 있음을 인지했습니다.결제 승인 로직이 하나의 트랜잭션 안에서 토스페이먼츠 API를 동기 호출하고 있었습니다. HikariCP 기본 풀은 10개인데 PG 응답이 1~2초 소요되므로, 동시 결제 10건이면 일반 API(문서 조회, 에디터 저장)까지 커넥션 부족 오류가 발생할 수 있는 구조였습니다.

APPROACH

네트워크 I/O와 DB 트랜잭션을 분리했습니다.첫 번째 트랜잭션에서 결제 검증과 상태 전환(IN_PROGRESS)만 수행하고 즉시 커밋하여 커넥션을 반환합니다. 이후 트랜잭션 밖에서 토스페이먼츠 API를 호출하므로, PG 응답을 1~2초 기다리는 동안에도 DB 커넥션을 점유하지 않습니다. PG 승인이 완료되면 두 번째 트랜잭션에서 크레딧 차감과 결제 완료 처리만 수행합니다.트랜잭션을 분리하면 PG는 승인했는데 두 번째 트랜잭션이 실패하는 데이터 불일치가 발생할 수 있습니다. 이때 즉시 PG 취소를 호출하면 사용자 입장에서는 결제가 실패한 경험이 됩니다. 대신 토스페이먼츠가 발송하는 웹훅을 백업 경로로 활용하여, 웹훅 수신 시 누락된 내부 트랜잭션을 다시 시도하는 최종적 일관성(Eventual Consistency) 전략을 택했습니다.웹훅으로도 해결되지 않는 경우를 대비해 PaymentScheduler가 주기적으로 실패 건을 재처리합니다. 웹훅 재시도는 최대 3회(5분 × 재시도 횟수 간격), 보상 트랜잭션 재시도는 최대 5회(10분 간격)로 구성했습니다. 최대 재시도를 초과하면 REQUIRES_MANUAL 상태로 전환하여 수동 처리 대상으로 분류합니다.

RESULT

PG 응답 지연이 DB 커넥션 풀에 영향을 주지 않는 구조로 전환되었습니다.결제 API에 의도적으로 지연을 주입한 상태에서도 문서 조회·에디터 저장 등 일반 API가 정상 응답하는 것을 직접 확인했습니다. 장애가 결제 기능에만 격리되어, Cascading Failure에서 경험한 '하나의 외부 호출이 전체 서비스를 마비시키는' 문제를 결제 플로우에서도 구조적으로 방지했습니다.

sequenceDiagram participant C as Client participant W as WAS (Spring Boot) participant PG as 토스페이먼츠 API participant DB as DB (PostgreSQL) rect rgb(254, 226, 226) Note over W,DB: Before — 트랜잭션 안에서 PG 호출 C->>+W: POST /payments/confirm W->>+DB: BEGIN TX + SELECT FOR UPDATE W->>+PG: confirmPayment (1~2s 대기) Note over DB: ⚠️ 커넥션 점유 중 PG-->>-W: 승인 결과 W->>DB: credit.charge() + COMMIT DB-->>-W: OK W-->>-C: 200 OK end rect rgb(220, 252, 231) Note over W,DB: After — 트랜잭션 밖에서 PG 호출 C->>+W: POST /payments/confirm W->>+DB: TX1: 검증 + 상태 IN_PROGRESS DB-->>-W: COMMIT (즉시 반환) W->>+PG: confirmPayment (커넥션 미점유) PG-->>-W: 승인 결과 W->>+DB: TX2: credit.charge() + 완료 처리 DB-->>-W: COMMIT W-->>-C: 200 OK Note over W: PG 실패 시 TX2에서 fail 처리 end

트랜잭션-외부 API 분리 — PG 응답 대기 중 DB 커넥션을 점유하지 않음

크레딧 결제 동시성 제어와 멱등성 보장

100 스레드 동시 / 잔액 정합성 100%

PROBLEM

AI 코드 리뷰를 통해 트랜잭션 경합 시 발생하는 갱신 손실(Lost Update)과 이중 차감 취약점을 인지하게 되었습니다.동일 계정에 동시 결제가 들어오면, 양쪽 트랜잭션이 차감 전 잔액을 읽고 각자 차감한 결과를 기록해 한쪽 차감이 사라지는 문제가 있었습니다. 또한 네트워크 타임아웃으로 클라이언트가 결제를 재시도할 경우, 이미 처리된 요청인지 판별하지 못해 같은 금액이 이중 차감되는 위험도 있었습니다.Testcontainers로 실제 DB를 띄우고 100개 스레드가 동시에 같은 계정에 결제를 보내는 테스트를 구축했고, 락 없이 실행하자 잔액이 예상보다 높게 남는 갱신 손실을 재현하며 결함을 확인했습니다.

APPROACH

정합성이 금전과 직결되는 결제 도메인 특성을 고려해, 재시도 비용이 큰 낙관적 락 대신 비관적 락을 선택하고 멱등키를 병행했습니다.낙관적 락은 충돌 시 애플리케이션이 재시도해야 하는데, 결제에서는 재시도 자체가 PG 이중 승인을 유발할 수 있어 부적합하다고 판단했습니다.

•동시성 제어: 비관적 락으로 트랜잭션을 직렬화하되, 테이블 락이 아닌 인덱스 기반의 행 단위 락으로 점유 범위를 좁혀 서로 다른 유저의 결제는 병렬 처리되도록 설계했습니다.
•멱등성 보장: 멱등키를 도입하여 DB UNIQUE 제약으로 내부 중복을 차단하고, 동일한 키를 토스페이먼츠 API 헤더에도 전달하여 PG 통신 구간까지 이중 승인을 방지했습니다.

RESULT

100스레드 동시 경합에서 단 한 건의 오차 없이 잔액 정합성 100%를 통과했습니다.동일 멱등키로 들어온 중복 결제 요청도 트랜잭션 진입 전에 즉시 차단됨을 확인했습니다. 현재 이 동시성 검증 테스트는 CI 파이프라인에 통합되어, 결제 로직 수정 시 회귀 오류를 자동으로 감지하고 있습니다.

AI 컨텍스트 오염 → 계층형 문서 + 멀티 에이전트 파이프라인

토큰 효율 2배+ / 교대 개발 맥락 무결성

PROBLEM

AI가 폐기된 API를 참조해 존재하지 않는 코드를 생성하는 일이 반복됐습니다.Claude Code의 Skills·Custom Commands로 반복 작업을 자동화하고 있었지만, CLAUDE.md가 1,000줄을 넘어가면서 기본 기능만으로는 해결할 수 없는 문제가 드러났습니다.

•1,000줄 문서를 매번 전부 로딩 → 토큰의 절반 이상이 규칙 읽기에 소모
•새 규칙과 폐기된 규칙이 뒤섞여 AI가 outdated 정보를 참조
•팀원 교대 시 문서 갱신 누락 → 다음 사람의 AI가 틀린 코드 생성
•간단한 작업에도 7단계 PRD를 거치는 프로세스 과잉

APPROACH

1,000줄 문서를 3-Layer로 분리하고, 작업 규모에 따라 필요한 문서만 로딩하는 구조로 변경했습니다.

•Core (~150줄, 항상 로딩): 핵심 규칙·아키텍처 원칙만
•Appendix (작업별 선택): tech-stack, design-system, api-reference 등
•Spec (L 작업만): API_SPEC, DATA_MODEL 전체 명세

Supervisor 에이전트가 요청을 S/M/L로 분류해 문서 참조량과 프로세스를 결정하고, 역할별 전문 에이전트가 순차적으로 작업합니다.

•Architect → 구조·로직 구현 / Stylist → 디자인 시스템 적용
•Auditor → 품질 검증 / Librarian → 코드 변경 시 문서 자동 동기화

RESULT

3-Layer 모델 전환으로 토큰 소모를 극적으로 줄여 AI 가용 시간을 2배 이상 연장했습니다. 무엇보다 outdated 문서 참조로 인한 할루시네이션(잘못된 코드 생성)을 없앴고, 단순 작업(S) 프로세스를 7단계에서 2단계로 단축했습니다. 또한 교대 개발 시 맥락 단절을 막기 위해 Librarian 에이전트 기반의 자동 문서 동기화 파이프라인을 구축, 팀 전체의 생산성을 크게 높였습니다.

flowchart TD REQ["작업 요청"] --> SUP{"Supervisor (S/M/L 분류)"} SUP -- "S: Core만" --> ARC["Architect 구조·로직"] SUP -- "M: Core+Appendix" --> ARC SUP -- "L: 전체" --> ARC ARC --> STY["Stylist 디자인 적용"] STY --> AUD["Auditor 품질 검증"] AUD --> LIB["Librarian 문서 동기화"] LIB --> DONE["완료"] style SUP fill:#f59e0b,stroke:#d97706,color:#fff style ARC fill:#3b82f6,stroke:#2563eb,color:#fff style STY fill:#8b5cf6,stroke:#7c3aed,color:#fff style AUD fill:#ef4444,stroke:#dc2626,color:#fff style LIB fill:#10b981,stroke:#059669,color:#fff

역할별 멀티 에이전트 파이프라인 — 각 에이전트가 한 가지 역할에만 집중

Frontend

인물 관계도 시각화 성능 최적화 (SVG → Canvas)

빈번한 Style Recalculation/Layout/Paint 방지 / 대규모 스케일에서 60fps 유지

PROBLEM

개별 노드와 엣지에 클릭 이벤트를 달기 위해 SVG DOM 요소를 사용하다 보니, 데이터 수에 비례해 렌더링 부하가 커지는 문제가 있었습니다.초기에는 직관적인 이벤트 처리를 위해 각 요소를 <svg><g> 형태로 그렸습니다. 하지만 600명이 넘는 인물과 복잡한 관계선이 모이자 수천 개의 DOM 트리가 생성되었고, 이로 인해 마우스를 가볍게 움직이기만 해도 브라우저의 Style Recalculation → Layout → Paint가 연쇄적으로 발생하며 메인 스레드에 병목이 생겨 프레임이 떨어졌습니다.

APPROACH

DOM 조작을 최소화할 수 있는 단일 `<canvas>` 픽셀 렌더링으로 전환하고, 이벤트 처리를 중앙화했습니다.React DOM 기반 렌더링을 걷어내고 react-force-graph-2d를 통해 Canvas Context 위에 노드를 그렸습니다. 커스텀 nodeCanvasObject로 노드 외형을 직접 렌더링하고, nodePointerAreaPaint로 클릭 영역을 확장하여 라이브러리의 이벤트 위임(Event Delegation) 구조 위에서 클릭/호버 인터랙션을 처리했습니다.

RESULT

수천 개의 DOM 노드 유지 비용과 이벤트 리스너 오버헤드를 덜어내어, 600명 이상의 인물 관계망에서도 60fps를 안정적으로 방어할 수 있었습니다.메모리 사용량이 크게 줄고 줌/팬 상호작용이 한층 부드러워졌습니다.

Vite 로드 전략 개편 및 번들 분할

초기 용량 gzip 기준 60% 절감 / 배포 시 캐시 무효화 범위 축소

PROBLEM

html2pdf 등 무거운 외부 라이브러리로 인해 초기 진입 속도가 저하되는 문제가 있었습니다.사용자가 처음 접속하는 서재(랜딩) 페이지에서 불필요하게 3.8MB의 전체 번들을 내려받고 있었습니다. 특히 특정 Export 페이지에서만 쓰이는 라이브러리(738KB)까지 초기 로드에 포함되어 로딩 병목의 원인이 되었습니다.

APPROACH

Vite Bundle Analyzer로 로드 패턴을 분석하고, manualChunks 11개 + 페이지별 React.lazy 코드 분할로 번들을 세분화했습니다.랜딩 페이지에서 사용하지 않는 vendor-graph (62KB)와 html2pdf(730KB)를 동적 임포트(Lazy Load)로 분리했습니다. 또한 통합되어 있던 거대한 vendor-editor를 변동이 적은 코어 로직과 수정이 잦은 확장 기능으로 세분화하여, 실제 브라우저가 필요한 자원만 선별적으로 다운로드하도록 전략을 개편했습니다.

RESULT

초기 내려받는 JS 크기를 gzip 기준 450KB에서 187KB(최대 60% ↓)로 줄였습니다.특히 코드를 배포할 때마다 전체 벤더를 다시 다운로드해야 했던 기존과 달리, 변경된 작은 청크(예: 확장 기능 33KB)만 새로 다운로드하도록 구조를 개선하여 재방문 사용자의 캐시 무효화 범위를 축소했습니다.

Aidiary

RabbitMQ 비동기 전환 · 컨텍스트 해시 캐시로 API 비용 최소화

2025.04 - 2025.06 (개인 개선 2026.02)

Fullstack Developer · 2인 팀

산모가 일기를 쓰면 AI가 감정을 분석해 피드백을 제공하는 서비스입니다. 부모 사진으로 아기 캐릭터를 생성하는 기능도 함께 제공합니다.

캡스톤 디자인 (2인 팀)으로 시작해 수료 후 개인적으로 아키텍처 개선을 이어갔습니다. 인증, 일기 CRUD, AI 연동 등 Spring Boot + Flask 이중 서버 백엔드 전체와 Docker Compose 기반 인프라를 담당했습니다. AI 합성(~30초)의 동기 블로킹 문제를 @Async 시도 → 부하 테스트에서 메모리 고갈 확인 → RabbitMQ 전환으로 단계적으로 해결하여 TPS를 1.16에서 1,949까지 개선했으며, 도메인 카테고리 해시 기반 캐시로 반복 API 호출 비용을 줄였습니다.

Architecture

1.16 → 1,949 TPS

WAS 수용 처리량

487ms → 0.1ms

Gemini API 캐시 최적화

Backend

AI 이미지 합성 동기 블로킹 → RabbitMQ 비동기 전환

WAS 수용 처리량 1.16 → 1,949 TPS (큐 발행 기준)

PROBLEM

ML 이미지 합성(~30초) 작업이 Tomcat 스레드를 직접 점유하여, 동시 사용자 10~20명 수준에서도 전체 서비스가 마비되었습니다.Flask ML 서버에 동기 호출을 보내고 응답을 기다리는 구조여서, 한 요청이 30초씩 스레드를 점유하면 일기 작성·건강 기록 등 AI와 무관한 API까지 스레드를 할당받지 못해 전부 무응답 상태에 빠졌습니다.k6 부하 테스트 결과 최대 처리량이 1.16 TPS에 불과했습니다.

APPROACH

@Async로 먼저 시도한 뒤, 부하 테스트에서 한계를 확인하고 RabbitMQ로 전환했습니다.@Async로 톰캣 스레드를 즉시 반환하도록 전환하자 처리량은 개선됐으나, 부하가 몰리자 JVM 내부 큐가 포화되어 메모리 고갈이 발생했습니다. 서버 재배포 시 메모리 큐의 미처리 작업이 유실되는 구조적 한계도 확인했습니다.이에 RabbitMQ를 도입하여 메시지 영속성을 확보하고, AI 합성 처리를 WAS와 물리적으로 분리했습니다. WAS는 큐에 메시지를 발행하고 즉시 응답을 반환하며, Python Worker가 메시지를 소비해 ML 처리를 수행합니다. Worker 완료 시 Webhook으로 Spring Boot에 콜백하여 결과를 저장하고, 클라이언트는 폴링으로 완료 여부를 확인하는 구조로 설계했습니다.Worker 장애 시에는 DLQ로 메시지를 보존하고, 메시지 재전달에 대비한 멱등성 가드를 각 단계에 적용했습니다.

RESULT

WAS 처리량 1.16 → 1,949 TPS, 동기 대기 30초 → 비동기 즉시 응답(4.9ms)으로 개선했습니다.500 VU 부하에서 p95 318ms, 총 175,463건을 오류 없이 처리했습니다. Flask 서버를 의도적으로 중단시킨 상태에서도 코어 API는 정상 응답하는 장애 격리를 확인했고, 미처리 메시지는 큐에 보존되어 복구 후 자동으로 재처리되었습니다.

sequenceDiagram participant C as Client participant W as WAS (Spring Boot) participant Q as RabbitMQ participant P as Python Worker C->>+W: POST /api/images/analyze W->>Q: 작업 메시지 발행 W-->>-C: 202 Accepted (4.9ms) Q->>+P: 메시지 소비 (prefetch=1) Note over P: MediaPipe 특징 추출<br/>AI 이미지 생성 (~30s) P->>P: basic_ack() P->>-W: POST /api/images/webhook (완료 콜백) W->>C: 폴링으로 완료 알림

RabbitMQ 비동기 처리 흐름 — WAS와 AI 처리 분리

Gemini 반복 호출 제거 — 컨텍스트 해시 캐싱으로 호출 최소화

응답 487ms → 0.1ms / Gemini API 호출 최소화

PROBLEM

주차별 정보와 오늘의 질문 기능이 매 요청마다 Gemini API를 호출하고 있어, 응답 시간 평균 487ms에 API 비용이 요청 수에 비례해 증가하는 구조였습니다.성능 문제 외에 기능적 결함도 있었습니다. 주차별 정보는 주차 번호만으로 Gemini를 호출해 42주 고정 콘텐츠를 생성하고 있어, 같은 20주차라도 최근 감정이 불안한 산모와 안정적인 산모가 동일한 정보를 받았습니다. 오늘의 질문은 기획 의도상 하루 하나의 질문을 모든 산모가 공유해야 하는데, LLM 특성상 요청마다 다른 질문이 생성되는 결함이 있었습니다.

APPROACH

같은 주차·같은 건강 상태의 산모에게는 동일한 응답이 돌아오므로, 상태가 바뀌지 않은 요청은 캐싱할 수 있다고 판단했습니다.먼저 산모의 최근 7일 일기 감정 빈도와 최신 건강 기록을 수집해 Gemini 프롬프트에 주입하여 개인화했습니다. 그런데 개인화로 인해 상태 조합이 다양해지고 변화 시점도 불규칙하여, 고정 TTL 캐시로는 무효화 시점을 제어할 수 없었습니다.처음에는 원시 컨텍스트를 그대로 SHA-256으로 해싱했으나, 혈압이 1mmHg만 변해도 새 키가 생겨 캐시 히트율이 급락했습니다. 이에 감정(긍정/중립/부정)·혈압(정상/주의/위험)·태동(활발/보통/저조) 등 도메인 기준으로 카테고리화한 뒤 건강 상태와 주차정보를 조합해 해시 키로 사용하여, 의미 있는 상태 변화에서만 캐시가 무효화되는 구조를 설계했습니다. Caffeine 로컬 캐시를 선택해 네트워크 홉 없이 즉시 반환하도록 했습니다.오늘의 질문은 하루 1회 생성되는 공통 데이터이므로 캐싱 대상에서 분리하고, 날짜 키로 DB에 저장해 Gemini 호출을 일 1회로 고정했습니다.

RESULT

주차별 정보 응답 487ms → 0.1ms(Caffeine HIT), 42개 주차별 유저 분포 시뮬레이션에서 캐시 히트율 95.80%를 달성했습니다.오늘의 질문은 Gemini 호출이 일 1회로 고정되었고, 주차별 정보는 산모의 감정·건강 상태에 따라 다른 맞춤 응답을 제공하게 되어 개인화와 비용 절감을 동시에 달성했습니다.

Frontend

이미지 압축 메인 스레드 블로킹 → Web Worker 분리

UI Freezing 2초 → 0 / 병렬 압축으로 처리 시간 단축

PROBLEM

사진 2장을 Canvas API로 압축하는 동안 메인 스레드가 최대 2초간 블록되어, UI 전체가 멈추고 로딩 애니메이션도 정지했습니다.부모 사진 2장(각 3-5MB)을 AI 서버로 보내기 전에 리사이즈·압축하는 로직이 메인 스레드에서 동기로 실행되고 있었습니다. JavaScript는 싱글 스레드라 압축 중 이벤트 루프 전체가 블록됩니다. 로딩 애니메이션까지 멈추기 때문에 앱이 멈춘 것처럼 보이는 문제였고, 모바일에서는 더 심각했습니다.

APPROACH

Web Worker 2개로 사진을 병렬 압축하여 메인 스레드 블로킹을 제거했습니다.OffscreenCanvas + Worker 조합도 검토했지만, 이미지 리사이즈만 필요한 상황에서 createImageBitmap → Canvas drawImage 파이프라인이 더 단순했기 때문에 기각했습니다. Worker A(아빠 사진)와 Worker B(엄마 사진)를 동시에 돌려 병렬 압축하고, postMessage로 완료된 Blob을 메인 스레드로 전달합니다. Promise.all로 두 Worker 완료를 기다렸다가 AI 서버로 전송합니다.

RESULT

UI Freezing이 해소되고, 로딩 애니메이션이 정상 동작합니다.사진 처리 중에도 다른 UI 조작이 가능하고, 두 사진을 병렬 압축하기 때문에 순차 처리 대비 시간도 단축됐습니다. 모바일에서도 매끄럽게 동작합니다.

Software Engineer

I'm |, a
Software Engineer||

안녕하세요, 측정하고 개선하는 신입 개발자 권동하입니다.

Software Engineer

문제의 원인을 끝까지 파고듭니다

•문제를 만나면 로그와 지표를 통해 원인을 추적합니다. 아직 배워야 할 것이 많지만, 원인을 찾고 해결한 경험이 가장 확실한 배움으로 이어진다고 생각합니다.
•학습한 내용을 실제 프로젝트에 적용하고, 개선 결과를 수치로 확인하며 배워가고 있습니다.

Problem Solver

탄탄한 기본기 위에서 문제를 풉니다

•크래프톤 정글에서 OS 커널(Pintos)을 직접 구현하며 시스템 동작 원리를 공부했습니다.
•이 경험 덕분에 커넥션 풀이 왜 고갈되는지, 락이 어떤 상황에서 필요한지를 원리부터 접근할 수 있었고, 실제 프로젝트에서 장애 원인을 파악하는 데 도움이 됐습니다.

Team Player

같이 일하는 경험을 더 좋게 만들고 싶습니다

•3년간 서비스직 아르바이트에서 팀리더로서 다양한 팀원들과 일하며, 불편함이 보이면 먼저 개선 방법을 찾아 제안하는 습관이 생겼습니다.
•개발 팀에서도 같은 태도로, 커밋·PR 작성이 팀 병목임을 파악하고 Antigravity의 커스텀 커맨드를 활용해 Git 컨벤션 자동화를 구축하고, 과정 내 타 팀까지 확산시켰습니다.
•기술적인 내용도 듣는 사람이 이해하기 쉽도록 맥락을 함께 전달하려고 합니다.

프로젝트 둘러보기 GitHub

👤

권동하

Software Engineer

최근 관심 분야

AI 활용 개발

Consistency is Key

Streak0일

보유 기술 스택

Backend

Java & Spring Boot

두 프로젝트에서 REST API와 인증을 설계하고, 토스페이먼츠 결제를 연동했습니다

NestJS

포트폴리오 챗봇 백엔드를 모듈·DI·인터셉터 기반으로 설계 및 구현했습니다

JPA / Hibernate

계층형 문서 조회의 N+1을 해결하고, Fetch Join으로 쿼리를 튜닝했습니다

RabbitMQ

AI 연산 같은 무거운 작업을 비동기 큐로 분리해 서버 부하를 줄였습니다

PostgreSQL / MariaDB

문서·결제 도메인의 스키마를 설계하고 운영했습니다

Neo4j

소설 속 인물 관계를 그래프로 모델링하고 Cypher로 탐색했습니다

Frontend & 기반 지식

React

컴포넌트 설계와 상태 관리, Canvas 기반 시각화에 활용했습니다

Zustand

도메인별 스토어를 분리해 전역 상태를 관리했습니다

TypeScript

프론트엔드 전반에서 타입을 정의해 런타임 오류를 줄였습니다

Pintos에서 스케줄러와 가상 메모리를 직접 구현했습니다

Infra

Docker

Compose로 Spring Boot, Flask, RabbitMQ 등 멀티 컨테이너 환경을 구성했습니다

AWS

EC2 배포부터 S3/CloudFront CDN, GitHub Actions CI/CD까지 구축했습니다

Tools

Git / GitHub

브랜치 전략을 수립하고 PR 기반 코드 리뷰로 협업했습니다

AI Agents

프롬프트를 설계하고 AI 에이전트 워크플로우를 구성했습니다

Projects

StoLink

Cascading Failure 해결 · N+1 최적화 · 결제 동시성 제어

Fullstack Developer2025.12 - 2026.025인 팀

웹소설 작가를 위한 지식 관리 플랫폼의 백엔드와 프론트엔드를 담당했습니다. 외부 API 타임아웃 누락으로 인한 Cascading Failure를 쓰레드 덤프 분석으로 추적하여 해결하고, SVG → Canvas 전환으로 관계도 INP를 420ms에서 64ms로 개선했습니다.

450ms → 25ms

문서 조회 API (18배 개선)

100스레드 / 100%

결제 잔액 정합성

Spring BootJPAPostgreSQLTestcontainers+3

Aidiary

RabbitMQ 비동기 전환 · 컨텍스트 해시 캐시로 API 비용 최소화

Fullstack Developer2025.04 - 2025.06 (개인 개선 2026.02)2인 팀

산모를 위한 AI 감정 일기 서비스의 백엔드·프론트엔드·인프라를 담당했습니다. AI 합성 동기 블로킹을 @Async 시도 → 부하 테스트 한계 확인 → RabbitMQ로 단계적으로 해결하고, 도메인 카테고리 해시 기반 캐시로 Gemini API 호출을 최소화했습니다.

1.16 → 1,949 TPS

처리량 (RabbitMQ 비동기 전환)

487ms → 0.1ms

API 캐싱 (컨텍스트 해시)

Spring BootRabbitMQCaffeineJPA+3