장애와 삽질이 가르쳐 준 것들
실무에서 만난 문제들을 기록합니다.
Spring 장애
JPA N+1, 배치 지연, 스케줄러 데드락 — 실전 트러블슈팅 모음
아키텍처
SAGA, 분산락, 데이터 정합성 — 설계 원칙부터 분산 시스템까지
AI/DX
Claude Code, MCP, AI 에이전트 — 백엔드 개발자의 AI 전환 가이드
멀티 벤더 IoT 연동 설계하기 (2편) - Event-Driven Architecture로 확장하기
TL;DR 문제: 기기 제어 성공 시 푸시 알림, 로그 저장, 통계, 슬랙 알림 등이 한 메서드에 몰려서 결합도 급증 원인: Service 클래스가 너무 많은 책임을 가짐 (단일 책임 원칙 위반) 해결: Event-Driven Architecture - 기기 제어 성공 시 이벤트 발행, 각 기능은 리스너로 독립 처리 효과: 결합도 낮아짐, 새 기능 추가 쉬움 (리스너만 추가), 테스트 독립적 한계: 디버깅 어려움…
멀티 벤더 IoT 연동 설계하기 (1편) - Adapter 패턴으로 통합하기
TL;DR 문제: 제조사마다 IoT API가 완전히 달라서 분기 처리하면 유지보수 지옥 원인: A사는 , B사는 등 엔드포인트, 인증, 응답 포맷이 전부 제각각 해결: Adapter 패턴으로 공통 인터페이스 정의, 제조사별 Adapter가 변환 담당 효과: 제조사 추가 시간 2주 → 2일로 단축, 비즈니스 로직은 제조사 몰라도 됨 한계: 초기 개발 시간 증가 (1주 추가), 공통 인터페이스 한계, 팀 학습 곡선…
토이프로젝트로 시작하는 DDD - 도메인 주도 설계 첫걸음
TL;DR 문제: 클린 아키텍처를 적용했지만 “도메인 로직과 애플리케이션 로직의 경계”가 모호해서 Service에 다 몰림 원인: 구조는 좋은데 비즈니스 도메인 정의가 불명확, “주문”이 뭔지 “결제”가 뭔지 명확한 정의 없음 해결: DDD (Domain-Driven Design) - 비즈니스 도메인부터 정의, 유비쿼터스 언어, Aggregate 패턴 효과: 도메인 경계 명확, 비즈니스 로직이 Entity에 응집, 팀…
클린 아키텍처, "노트북과 여행용 어댑터"로 이해하기
TL;DR 문제: 비즈니스 로직이 DB나 프레임워크에 강하게 의존해서 변경이 어렵고 테스트도 느림 원인: 레이어드 아키텍처(Controller-Service-Repository)는 외부 환경과 도메인이 너무 가까움 해결: 클린 아키텍처 - 도메인을 중심에 두고, 외부(DB, 웹)는 어댑터로 감싸기 효과: DB 교체 쉬움, 테스트 빠름 (외부 의존 없이), 비즈니스 로직 명확해짐 한계: 보일러플레이트 증가 (인터페이스,…
정적 블로그에서 백엔드 통신하기 - 일반 웹과의 결정적 차이
TL;DR 문제: 정적 블로그에서 API 키를 프론트엔드에 넣으면 개발자 도구에 그대로 노출됨 원인: 로그인이 없으니 사용자 인증(JWT)이 불가능, 백엔드 서버도 없음 해결: Netlify Functions로 API 키를 환경변수에 숨기고 서버리스 백엔드 구축 효과: API 키 보호 + 서버 운영 부담 제로 + 월 100원 미만 비용 한계: 콜드 스타트(최대 2초), Netlify 종속성, 복잡한 로직엔 부적합…
GraphQL vs REST, 실무에서의 선택 - 언제 뭘 써야 할까?
TL;DR 문제: REST API로 필드 많은 응답 → 불필요한 데이터까지 전송, 엔드포인트 20~30개 폭발, DTO 클래스 남발 원인: Over-fetching (필요한 것만 받을 수 없음), Under-fetching (여러 API 호출 필요) 해결: GraphQL 도입 - 클라이언트가 필요한 필드만 요청, 하나의 엔드포인트로 통합 효과: API 엔드포인트 감소, 데이터 전송량 50% 감소, 프론트 개발 속도 ↑…