itsdev의 IT Blog

WithBuddy 연재 11편이자 시즌 4의 시작이다. 지금까지는 성능 개선과 아키텍처 설계를 중심으로 정리했다. 이번 편에서는 방향을 바꿔 실제 운영 과정에서 겪었던 장애 세 가지를 다룬다. Anthropic API의 529 과부하, Grafana 알림 오탐, 그리고 Blue/Green 배포 과정에서 발생한 트래픽 불일치를 어떻게 발견하고 원인을 추적했는지 정리한다.이 글에서 다루는 내용HTTP 200 뒤에 숨어 있던 SSE 스트리밍 오류를 추적한 과정RabbitMQ 장애처럼 보였지만 실제로는 알림 규칙이 잘못됐던 Grafana 오탐Nginx는 Green을 가리키는데 일부 트래픽은 Blue로 유입됐던 배포 문제세 장애를 겪으며 운영 방식에서 바꾼 것들이번에는 잘된 것보다 잘못된 것을 기록해보려 한다지금..

WithBuddy 연재 7편이자 시즌 2의 마지막 글이다. 반복적인 폴링 구조를 걷어내고 RabbitMQ 기반 비동기 처리 구조로 전환한 과정, 그리고 실패한 메시지가 유실되지 않도록 DLQ(Dead Letter Queue), 멱등성, 재시도 정책을 설계한 과정을 실제 설정과 검증 결과를 바탕으로 정리한다. 이 글에서 다루는 내용왜 Redis 기반 폴링 구조를 줄이고 RabbitMQ 비동기 처리로 전환했는지알림 큐와 분석 큐의 TTL·prefetch를 다르게 설정한 이유실패한 메시지를 유실하지 않는 DLQ 격리 구조와 적용 방법Redis SETNX + DB UNIQUE 제약으로 중복 처리를 막는 방법1,000건 부하 검증 결과와 DRY_RUN 테스트가 가진 한계왜 비동기였나 — 폴링에서 발생하는 불필요..

WithBuddy 연재 6편. L1(Caffeine) + L2(Redis) 하이브리드 캐시를 적용해 캐시 히트 경로의 p95를 1,643ms에서 263ms까지 줄였다. 이번 글에서는 왜 Redis 단독 구성이 아니라 2단 캐시를 선택했는지, 캐시에서 발생할 수 있는 장애를 어떻게 방어했는지, 그리고 “6.2배 빨라졌다”는 결과를 어디까지 신뢰할 수 있는지 함께 정리한다. 이 글에서 다루는 내용Redis 단독 대신 Caffeine + Redis 2단 캐시를 선택한 이유Cache Stampede, Penetration, 연쇄 장애와 이를 막기 위한 방어 장치캐시 히트 경로 p95를 약 84% 단축한 측정 결과“6.2배 개선”이라는 수치를 해석할 때 반드시 함께 봐야 할 검증의 한계 Redis만으로는 부족했던..

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.1. 탄탄한 기술 베이스 위에 '진짜 에이전트'의 조건을 더하다MVP 중간 점검이 끝난 뒤, 우리 팀이 받아든 피드백은 예상보다 구체적이었다. 기능 자체에 대한 지적은 거의 없었다. 심사위원들이 주목한 건 그 기능들이 얼마나 에이전트답게, 비즈니스 흐름 위에서 작동하느냐였다."리서치부터 가설 검증까지 이어지는 개연성과 논리성이 탄탄하다." 당시 WithBuddy는 문서 업로드, 한국어 특화 임베딩 모델(jhgan/ko-sroberta-multitask)과 Kiwi 형태소 분석기를 활용한 쿼리 확장까지 핵심 RAG 파이프라인이 이미 안정적으로 올라와 있는 상태였다. 기술 이해도와 문서 완성도에서 좋은 평가를 받은 건 그 결..