itsdev의 IT Blog

WithBuddy 연재 10편이자 시즌 3의 마지막 글이다. LLM 대화가 길어질수록 프롬프트에 포함되는 히스토리와 토큰 비용도 함께 증가한다. WithBuddy에서는 Redis List의 RPUSH + LTRIM을 이용해 최근 5턴만 유지하고, EXPIRE로 오래된 세션까지 자동 정리했다. 별도의 이력 정리 배치나 삭제 대상 탐색 없이 대화 맥락을 일정한 크기로 제한한 방법을 정리한다.이 글에서 다루는 내용전체 대화 이력을 매번 LLM에 전달하면 비용이 커지는 이유RPUSH + LTRIM으로 최근 N개의 메시지만 유지하는 원리별도의 조회·삭제 로직보다 Redis List를 활용한 이유TTL 30분으로 유휴 세션을 자동 정리하는 방법턴 기반 슬라이딩 윈도우의 한계와 보완 방법문제 — 대화가 길어질수록 L..

WithBuddy 연재 9편. 여러 회사가 함께 사용하는 RAG 서비스에서 회사별 문서를 ChromaDB 컬렉션 단위로 어떻게 격리했는지, 그리고 정책 문서가 변경됐을 때 Redis의 구버전 캐시를 일괄 삭제하지 않고 activeVersion 하나만 변경해 자연스럽게 무효화한 전략을 정리한다. 이 글에서 다루는 내용여러 회사의 문서가 검색 과정에서 섞이지 않도록 만든 ChromaDB 컬렉션 네이밍 규칙컬렉션 이름을 애플리케이션에서 정규화해야 하는 이유정책 문서가 변경됐을 때 기존 캐시를 무효화하는 두 가지 방법SCAN + DEL 방식 대신 버전 기반 캐시 무효화를 선택한 이유formVersion을 캐시 키에 포함해 삭제 없이 구버전 캐시를 자연 소멸시키는 방법 문제는 두 가지였다 — 격리와 갱신8편에서는..

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만으로는 부족했던..

WithBuddy 연재 5편, 시즌 2의 시작. SSE 채팅 부하테스트에서 실패율 65%가 나왔는데 CPU는 놀고 있었다. 이 모순을 추적해 HikariCP 커넥션 풀 고갈을 범인으로 특정하고, p95를 67초에서 9.94초로 되돌린 진단 과정을 처음부터 끝까지 기록한다. 이 글에서 다루는 것"CPU가 낮은데 요청이 실패한다"는 모순을 어떻게 추적했는지HikariCP 지표(active/idle/waiting)로 커넥션 풀 고갈을 특정하는 법SSE + 비동기 AI 응답이 왜 커넥션을 오래 점유하는지풀 크기를 키우되 그것을 Golden Image에 영구 반영해야 하는 이유시작은 오토스케일링 검증이었다4편에서 온디맨드 오토스케일링을 붙였다. 이제 이게 실제로 부하를 견디는지 검증할 차례였다. k6로 SSE..

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