Skip to content

From Bugs to Insights

장애 복구부터 운영 자동화까지,
바로 써먹을 수 있는 백엔드 생존 인사이트를 정리합니다.

캐시 테이블 불일치로 인한 전자계약 발송 실패 - Spring Cache의 숨겨진 함정 썸네일
Spring
📖 2분

캐시 테이블 불일치로 인한 전자계약 발송 실패 - Spring Cache의 숨겨진 함정

TL;DR 증상: 전자계약 발송 시 간헐적 NPE, DB에는 데이터 존재 원인: 동일 도메인 데이터를 4개 캐시 이름으로 분산 + Repository/Entity 테이블 불일치 해결: 단일 캐시로 통합, 올바른 서비스 주입, 레거시 @Deprecated 후 삭제 계획 효과: NPE 재현 불가, 캐시 히트율 정상화, 모니터링 지표 확보 한계: 로컬 캐시는 중앙 관리 불가 → 네이밍 사고에 여전히 취약

  • #Spring
  • #Cache
  • #Local Cache
스케줄러 배치가 어쩔 땐 성공하고 어쩔 땐 실패한 이유 - 데드락 해결기 썸네일
Spring
📖 3분

스케줄러 배치가 어쩔 땐 성공하고 어쩔 땐 실패한 이유 - 데드락 해결기

TL;DR 증상: 10분마다 실행되는 스케줄러가 간헐적으로 데드락 발생 (시간당 3회) 원인: 약 20초간 긴 트랜잭션으로 전체 테이블 Lock 유지, API 서버와 Lock 경합 해결: 4가지 방법 적용 (필터링, 트랜잭션 분리, REQUIRES_NEW, 500개 Chunking) 효과: 데드락 발생 주 3~4회 → 0회, Lock 유지 시간 99.9% 감소 (20초 → 1ms) 한계: Chunking으로 처리 시간 증가…

  • #Spring Batch
  • #Deadlock
  • #Transaction
MCP 서버 실전 운영 (2편) - Private Git 연동과 자동화 썸네일
AI
📖 4분

MCP 서버 실전 운영 (2편) - Private Git 연동과 자동화

TL;DR 문제: 로컬 MCP 서버는 Claude Desktop에서만 사용 가능, 어디서든 접근 불가 원인: Stdio 프로토콜은 로컬 전용, Private Git 저장소 동기화 필요 해결: Cloud Run 배포 + GitHub Webhook + PAT 인증 효과: Cursor, 웹 Claude에서 접근 가능, Push 후 5초 이내 자동 동기화 한계: 배포 복잡도 증가, Cold Start 2~3초, 월 $0.10~$1…

  • #MCP
  • #Model Context Protocol
  • #Cloud Run
백엔드 개발자의 첫 MCP 서버 만들기 (1편) - AI와 데이터 연결하기 썸네일
AI
📖 4분

백엔드 개발자의 첫 MCP 서버 만들기 (1편) - AI와 데이터 연결하기

TL;DR 문제: AI가 외부 데이터(DB, API, 파일)를 직접 읽을 수 없어서 수동으로 복사/붙여넣기 필요 원인: Claude, ChatGPT는 인터넷에 연결되지 않음, 실시간 데이터 접근 불가 해결: MCP(Model Context Protocol) - AI가 외부 데이터를 읽을 수 있는 표준 프로토콜 효과: 수동 작업 제로, AI가 직접 검색, 백엔드 개발자 친화적 (REST API와 유사) 한계: Python…

  • #MCP
  • #Model Context Protocol
  • #Spring Boot
thumbnail
AI
📖 5분

AI 드리븐 코드베이스 문서화 (3편) - 실제 효과와 운영 가이드

TL;DR 증상: 문서 시스템을 만들었지만 실제 효과가 얼마나 있는지 불명확, 투자 대비 효과 판단 불가 원인: 정량적 지표 없이는 개선 여부 증명 어려움, Before/After 비교 데이터 부재, 주관적 체감만으로 판단 해결: 토큰 사용량, 응답 시간, 정확도, 개발 속도를 측정하여 효과 검증, 트리거 기반 문서 선택 자동화, PR 템플릿에 문서 체크리스트 추가 효과: 토큰 85% 절약 (13,000 → 2,000),…

  • #AI
  • #Documentation
  • #DX
thumbnail
AI
📖 5분

AI 드리븐 코드베이스 문서화 (2편) - 4계층 정보 구조 설계

TL;DR 증상: AI가 전체 코드베이스를 탐색하면서 토큰 폭탄 (5,000+ 토큰), 관련 없는 파일도 읽고, 응답 시간 30초+ 원인: 22만 줄 코드를 한 번에 이해할 수 없음, 필요한 정보만 선별적으로 읽을 구조 없음, 단계적 정보 제공 메커니즘 부재 해결: 4계층 정보 구조 설계 (오케스트레이션 → 요약 → 인덱스 → 상세), Progressive Disclosure 패턴, YAML 메타데이터 스키마, 트리거…

  • #AI
  • #Documentation
  • #DX
로그 한 줄 없이 서버가 멈췄다 - Virtual Thread와 커넥션 풀 Starvation 썸네일
Infra
📖 9분

로그 한 줄 없이 서버가 멈췄다 - Virtual Thread와 커넥션 풀 Starvation

TL;DR 증상: 개발 서버가 완전히 멈춤, ALB 헬스체크도 응답 없음, 로그 한 줄도 없음 원인: Virtual Thread 100개가 병렬 DB 조회, HikariCP 커넥션 10개 (개발 환경) → 커넥션 풀 고갈로 Deadlock 발생 해결: 개발 환경 커넥션 풀 10 → 50 증가, 병렬 조회 수 10개로 제한, 타임아웃 설정 효과: 커넥션 풀 Starvation 해결, 서버 먹통 현상 사라짐, 모니터링…

  • #Spring
  • #Java
  • #Virtual Thread
블로그에 AI 기능 붙이기 (2편) - MCP 서버로 Claude 교육시키기 썸네일
AI
📖 8분

블로그에 AI 기능 붙이기 (2편) - MCP 서버로 Claude 교육시키기

TL;DR 문제: 50개 블로그 포스팅에서 특정 주제 찾으려면 파일 탐색기 + 검색 5~10분 소요 원인: Claude가 내 블로그 내용을 모름, 매번 수동으로 복사/붙여넣기 필요 해결: MCP 서버 (Python FastAPI) + Private Git 웹훅 + GCP Cloud Run 배포 효과: “Spring Batch 글 있어?” 한 마디로 즉시 검색, 5~10분 → 5초, 블로그가 AI의 개인 아카이브 한계:…

  • #MCP
  • #Python
  • #FastAPI
thumbnail
AI
📖 4분

AI 드리븐 코드베이스 문서화 (1편) - 22만 줄 코드를 AI가 읽게 만들어야 했던 이유

TL;DR 증상: 22만 줄 코드베이스에서 AI가 관련 파일을 못 찾고 토큰만 소진 (한 번에 5,000 토큰+), 엉뚱한 레거시 파일 수정 시도 원인: AI가 프로젝트 구조, 도메인 경계, 비즈니스 규칙을 모르고 전체 탐색, 컨텍스트 윈도우 제한으로 부분적 이해 해결: 4계층 문서 시스템 구축 (오케스트레이션 → 요약 → 인덱스 → 상세), 트리거 기반 문서 선택, YAML 메타데이터 스키마 효과: 토큰 90% 절약…

  • #AI
  • #Documentation
  • #DX
AI 시대에 TDD가 더 중요해진 이유 - Mock과 레이어드 아키텍처 관점에서 썸네일
Java
📖 6분

AI 시대에 TDD가 더 중요해진 이유 - Mock과 레이어드 아키텍처 관점에서

TL;DR 증상: AI가 생성한 코드가 컴파일은 되는데 로직이 틀린 경우가 많다 원인: AI는 비즈니스 로직의 맥락을 모르고, 사람이 일일이 검증하기 힘들다 해결: TDD로 테스트를 먼저 작성하면 AI 코드를 빠르게 검증할 수 있다 효과: 코드 품질 향상, 리팩토링 안정성 확보, AI와의 협업 효율 상승 한계: 초기 학습 곡선, 테스트 작성 시간 투자 필요 왜 갑자기 TDD 글을 쓰게 됐을까요? 솔직히 말하면…

  • #TDD
  • #Mock
  • #TestCode
와이프를 위한 강사 수입 관리 시스템 만들기 썸네일
Etc
📖 4분

와이프를 위한 강사 수입 관리 시스템 만들기

TL;DR 문제: 온라인 교육 플랫폼의 대시보드가 빈약해서 일일 수입 파악이 어려웠음 해결: Gmail + Google Calendar API를 연동하여 수입 자동 계산 시스템 구축 효과: 매일 밤 자동으로 수입 요약 메일 발송, 통화별 환율 변환까지 지원 기술: Spring Boot, Gmail IMAP, Google Calendar API, Supabase, GCP Cloud Run 한계: 특정 플랫폼의 메일…

  • #Spring Boot
  • #Gmail API
  • #Google Calendar API
thumbnail
AI
📖 7분

블로그에 AI 기능 붙이기 (3편) - 영구 캐싱으로 비용 99% 줄이기

TL;DR 문제: 로컬 스토리지 TTL 캐싱으로 같은 코드 설명을 매달 반복 생성 (불필요한 API 비용) 원인: 코드는 안 바뀌는데 캐시에 30일 TTL을 걸어서 매달 새로 생성 해결: Supabase 영구 캐싱 + hit_count 기반 스마트 정리 시스템 효과: API 호출 75% 감소, 응답 속도 10배 향상, 연간 약 $5 절감 한계: DB 용량 계속 증가 (6개월마다 수동 정리 필요), Supabase 무료…

  • #AI
  • #Supabase
  • #Cache
thumbnail
AI
📖 7분

블로그에 AI 기능 붙이기 (1편) - 월 35원으로 OpenAI + Netlify Functions

TL;DR 문제: 코드 블록이 많은 기술 블로그, 독자가 코드만 보고 이해하기 어려워 이탈 원인: 수동으로 모든 코드에 주석 달기는 시간 부족, 함수형 프로그래밍 등 낯선 패러다임은 특히 어려움 해결: OpenAI API + Netlify Functions로 “AI 설명” 버튼 구현, 클릭하면 자동으로 설명 생성 효과: 독자 편의성 ↑, 코드 이해도 ↑, 월 35원 비용으로 AI 기능 추가 한계: API 키 노출 위험…

  • #AI
  • #OpenAI
  • #Netlify Functions
멀티 벤더 IoT 연동 설계하기 (2편) - Event-Driven Architecture로 확장하기 썸네일
Architecture
📖 8분

멀티 벤더 IoT 연동 설계하기 (2편) - Event-Driven Architecture로 확장하기

TL;DR 문제: 기기 제어 성공 시 푸시 알림, 로그 저장, 통계, 슬랙 알림 등이 한 메서드에 몰려서 결합도 급증 원인: Service 클래스가 너무 많은 책임을 가짐 (단일 책임 원칙 위반) 해결: Event-Driven Architecture - 기기 제어 성공 시 이벤트 발행, 각 기능은 리스너로 독립 처리 효과: 결합도 낮아짐, 새 기능 추가 쉬움 (리스너만 추가), 테스트 독립적 한계: 디버깅 어려움…

  • #Spring
  • #Event-Driven Architecture
  • #IoT
우리 팀은 왜 JDK 21을 선택했나 - 작은 서비스의 관점 썸네일
Java
📖 7분

우리 팀은 왜 JDK 21을 선택했나 - 작은 서비스의 관점

TL;DR 문제: JDK 11을 쓰고 있는데 17로 갈지 21로 갈지 결정 필요 (작은 규모 B2B 서비스, TPS 10-20) 원인: 대용량 서비스는 성능 중심 선택하면 되는데, 작은 서비스는 “우리에게 필요한가?” 고민 해결: 스테이징 3개월 테스트 → JDK 21 선택 (Virtual Thread, Pattern Matching, Record 등) 효과: 개발 생산성 ↑ (Record), 코드 가독성 ↑…

  • #Java
  • #JDK 17
  • #JDK 21
멀티 벤더 IoT 연동 설계하기 (1편) - Adapter 패턴으로 통합하기 썸네일
Architecture
📖 8분

멀티 벤더 IoT 연동 설계하기 (1편) - Adapter 패턴으로 통합하기

TL;DR 문제: 제조사마다 IoT API가 완전히 달라서 분기 처리하면 유지보수 지옥 원인: A사는 , B사는 등 엔드포인트, 인증, 응답 포맷이 전부 제각각 해결: Adapter 패턴으로 공통 인터페이스 정의, 제조사별 Adapter가 변환 담당 효과: 제조사 추가 시간 2주 → 2일로 단축, 비즈니스 로직은 제조사 몰라도 됨 한계: 초기 개발 시간 증가 (1주 추가), 공통 인터페이스 한계, 팀 학습 곡선…

  • #Spring
  • #IoT
  • #Design Pattern
200줄 메서드를 파사드 패턴으로 정복하기 썸네일
Spring
📖 8분

200줄 메서드를 파사드 패턴으로 정복하기

TL;DR 문제: 200줄짜리 메서드, 스크롤 끝이 안 보임, 수정할 때마다 겁남, 6개월 후 이해하는 데 30분 소요 원인: 외부 API 호출 + 검증 + 변환 + 저장 + 예외 처리가 한 메서드에 몰려 있음 해결: 파사드 패턴 - 큰 메서드를 작은 서비스로 쪼개고, Facade가 조합 담당 효과: 200줄 → 30줄, 읽는 시간 30분 → 5분, 테스트 쉬움 (각 서비스 독립) 한계: 초기 분리 시간 (1주…

  • #Refactoring
  • #Clean Code
  • #Facade Pattern
AWS Lambda + AOP로 분산 캐시 무효화하기 썸네일
Infra
📖 5분

AWS Lambda + AOP로 분산 캐시 무효화하기

서론 “관리자가 건물 정보를 수정했는데, 앱에서는 왜 이전 정보가 계속 보이나요?” 고객센터에서 이런 문의가 들어왔을 때, 처음엔 DB 반영 문제인 줄 알았습니다. 그런데 확인해보니 DB에는 최신 데이터가 있었거든요. 원인을 추적해보니 캐시 문제였습니다. 그것도 로컬 캐시요. 저희 서비스는 2대의 API 서버가 로드밸런서 뒤에서 돌아갑니다. 각 서버가 로컬 메모리에 캐시를 들고 있는데, 문제는 이 캐시가 서로 동기화되지…

  • #Spring
  • #AWS Lambda
  • #AOP
토이프로젝트로 시작하는 DDD - 도메인 주도 설계 첫걸음 썸네일
Architecture
📖 7분

토이프로젝트로 시작하는 DDD - 도메인 주도 설계 첫걸음

TL;DR 문제: 클린 아키텍처를 적용했지만 “도메인 로직과 애플리케이션 로직의 경계”가 모호해서 Service에 다 몰림 원인: 구조는 좋은데 비즈니스 도메인 정의가 불명확, “주문”이 뭔지 “결제”가 뭔지 명확한 정의 없음 해결: DDD (Domain-Driven Design) - 비즈니스 도메인부터 정의, 유비쿼터스 언어, Aggregate 패턴 효과: 도메인 경계 명확, 비즈니스 로직이 Entity에 응집, 팀…

  • #DDD
  • #Domain-Driven Design
  • #Architecture
클린 아키텍처, "노트북과 여행용 어댑터"로 이해하기 썸네일
Architecture
📖 6분

클린 아키텍처, "노트북과 여행용 어댑터"로 이해하기

TL;DR 문제: 비즈니스 로직이 DB나 프레임워크에 강하게 의존해서 변경이 어렵고 테스트도 느림 원인: 레이어드 아키텍처(Controller-Service-Repository)는 외부 환경과 도메인이 너무 가까움 해결: 클린 아키텍처 - 도메인을 중심에 두고, 외부(DB, 웹)는 어댑터로 감싸기 효과: DB 교체 쉬움, 테스트 빠름 (외부 의존 없이), 비즈니스 로직 명확해짐 한계: 보일러플레이트 증가 (인터페이스,…

  • #Architecture
  • #Clean Architecture
  • #Hexagonal Architecture