WithBuddy 12

Redis RPUSH + LTRIM으로 LLM 대화 이력 관리하기 — 별도 삭제 로직 없이 최근 5턴만 유지하는 슬라이딩 윈도우

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

IT 개발 2026.08.30

정책 문서 변경에 대응하는 캐시 무효화 전략 — ChromaDB 멀티테넌시 네이밍과 formVersion 자연 소멸

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

IT 개발 2026.08.26

LangGraph로 온보딩 RAG 에이전트 만들기 — SCOPE 라우팅부터 3단 가드레일까지

WithBuddy 연재 8편이자 시즌 3의 시작이다. FastAPI + LangGraph 위에서 사내 문서를 기반으로 답변하는 온보딩 RAG 에이전트를 어떻게 구성했는지 정리한다. 사용자의 질문이 SCOPE 판정, ChromaDB 검색, Claude 답변 생성, 가드레일을 거쳐 최종 응답이 되기까지의 전체 흐름을 살펴본다.이 글에서 다루는 내용단일 LLM 호출이 아니라 노드 그래프로 RAG 파이프라인을 구성한 이유회사 업무 범위를 벗어난 질문을 걸러내는 SCOPE 라우터ChromaDB 컬렉션 단위로 멀티테넌트 데이터를 격리한 방법잘못된 정책 답변과 과도한 확정 표현을 줄이는 3단 가드레일검색에 실패했을 때 추측하지 않고 안전하게 폴백하는 방식왜 단순 챗봇이 아니라 에이전트였나WithBuddy가 해결하려는..

IT 개발 2026.08.24

RabbitMQ로 AI 응답을 비동기 전환하고 DLQ로 메시지 유실 막기 — Spring Boot 메시징 신뢰성 설계

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

IT 개발 2026.08.22

CPU는 멀쩡한데 SSE 실패율이 65%였다 — HikariCP 커넥션 풀 고갈 진단기

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

IT 개발 2026.08.19

클라우드플레어(Cloudflare) Tunnel로 SSH 22포트 완전 차단하기 — Zero Open Ports 배포 아키텍처 3단계

WithBuddy 연재 2편. CI/CD 배포를 위해 열어둔 SSH 22번 포트를 단계적으로 없애고, 최종적으로 SSH 키까지 제거한 과정을 실제 설정과 함께 정리한다. 이 글에서 다루는 것GitHub Actions 배포에서 SSH 22포트가 왜 공격 표면이 되는지Cloudflare Tunnel로 인바운드 포트를 0개로 만드는 구체적 설정GitHub OIDC로 SSH 개인키를 Secrets에서 완전히 없애는 방법실무에서 놓치면 다시 Permission Denied / Timeout을 만나는 3가지 함정왜 22포트를 닫아야 했나WithBuddy는 OCI Free Tier 서버 위에서 돌아간다(1편 참고). 배포는 GitHub Actions에서 SSH/SCP로 JAR을 밀어넣는 방식이었다. 그런데 GitHu..

서버 개발 2026.08.13

인프라 비용 0원으로 프로덕션을 배포한 이야기 — OCI Free Tier가 만든 아키텍처

WithBuddy 연재를 시작한다. 첫 편은 아키텍처 다이어그램이 아니라, 그 다이어그램이 왜 그 모양이 될 수밖에 없었는지에 대한 이야기다.발표 자료에는 "의도적으로 설계된 Modular Monolith"라고 적혀 있었다. 틀린 말은 아니지만, 정확한 말도 아니다. 실제로는 예산이 없어서 시작된 구조였다. 그리고 나는 그 사실을 숨기는 것보다 그대로 쓰는 편이 더 설득력 있다고 생각한다.50만 원을 어디에 쓸 것인가팀 자체 예산은 0원이었다. 빌더스리그에서 지원되는 50만 원이 우리가 쓸 수 있는 전부였다.이 돈을 어디에 쓸지가 첫 번째 의사결정이었다. 팀원 전체가 Claude, ChatGPT 같은 AI 개발 도구를 구독하면 생산성이 확실히 올라간다. 하지만 인프라에 돈이 나가기 시작하면 그만큼 구독 ..

IT 개발 2026.08.13

[구름부트캠프] 빌더스리그 Final Expo 후기 — 최우수상 수상, 그리고 '상용화 SaaS'를 위한 마지막 교훈

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.1. ZEP과 Zoom을 넘나들었던 파이널 엑스포의 열기2026년 7월 14일부터 16일까지, 5개월간의 결실을 맺는 BUILDERS LEAGUE Final Round: Final Expo가 열렸다. 총 17개 팀이 배정된 ZEP 메타버스 공간에서 결과물을 게시하고, 자유 관람과 함께 강사님 및 심사위원들의 질의응답이 이어졌다.우리 3팀 일단모여(WithBuddy) 부스에도 수많은 훈련생과 심사위원들이 찾아왔다. 신입사원 온보딩 AI 코치 서비스로서 그동안 구축해 온 LangGraph 기반 RAG 파이프라인, Claude Haiku 비용 최적화, Redis/RabbitMQ/SSE 스트리밍 기반의 백엔드 아키텍처를 가감 없..

IT 개발 2026.07.26

[구름부트캠프] 빌더스리그 9회차 Round 2 후기, 두 번째 수상과 시장성을 배운 WithBuddy 피벗 데이

본 콘텐츠는 구름 서포터즈 활동의 지원을 받아 작성된 교육생의 실제 경험 후기입니다.구름 부트캠프 빌더스리그 9회차에 참여하며 약 3개월 동안 팀 프로젝트를 진행했다. 우리 팀 이름은 ‘일단모여’이고, 프로젝트 이름은 ‘WithBuddy’이다.WithBuddy는 신입 사원이 입사 초기에 반복적으로 묻게 되는 질문을 사내 문서를 기반으로 답변해 주는 AI 온보딩 서비스이다.처음에는 신입 사원이 사수의 눈치를 보지 않고 편하게 질문할 수 있도록 돕는 서비스로 시작했다. 그러나 MVP 개발, 사용자 인터뷰, Round 2 고도화, 6월 26일 피벗 데이 발표를 거치면서 우리가 해결해야 할 문제와 서비스의 방향도 조금씩 달라졌다.이번 글에서는 빌더스리그를 진행하며 경험한 개발 과정과 협업, Round 2 심사 ..

IT 개발 2026.06.29

[구름부트캠프] MVP 중간 점검 이후, WithBuddy 팀이 실제로 달라진 것들

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

IT 개발 2026.05.26

[구름부트캠프] MVP Checkpoint Day - 가볍게, 핵심만, 확실하게

본 콘텐츠는 구름(goorm) 서포터즈 활동 지원을 받아 작성된 실제 참여 후기입니다 솔직히 말하면, 체크포인트 당일 아침은 긴장을 했다.지금까지 쌓아온 것들이 강사님들의 눈앞에 펼쳐지는 순간이었으니까. '우리가 방향을 제대로 잡고 있는 걸까?' 그 질문이 머릿속을 계속 맴돌았다. 하지만 ZEP 구름스퀘어에 접속하는 순간, 그 긴장감은 에너지로 바뀌었다. 화면 너머로 분주하게 움직이는 15개 팀의 아바타들을 보는 것만으로도, 이게 단순한 수업이 아니라는 걸 다시 한번 실감했다. 01. ZEP 구름스퀘어에서 펼쳐진 온택트 열기비대면 메타버스 플랫폼 ZEP 구름스퀘어 JOBS 룸. 오전 9시, Sprint Time이 시작되자마자 각 팀의 분위기가 달라졌다.발표 자료를 마지막으로 점검하는 팀, 시뮬레이션을..

IT 개발 2026.04.28

[구름부트캠프] 빌더스리그 시작 후기

본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.3월 오프닝 세레모니부터 느낀 생생한 첫인상구름이 만든 몰입 경험2026년 3월 17일, 구름이 주최한 빌더스리그 9회차 오프닝 세레모니가 비대면으로 진행되었다.각자의 공간에서 줌(Zoom)에 접속하는 방식이었지만, 막상 참여해보니 일반적인 온라인 행사와는 확연히 다른 분위기였다.접속과 동시에 수많은 팀들이 채팅창을 통해 서로를 응원하기 시작했고,화면에는 완성도 높은 오프닝 연출이 이어졌다.단순히 ‘접속해서 보는 행사’가 아니라, 처음부터 끝까지 참여하게 만드는 구조였다.비대면임에도 불구하고 현장감이 살아 있었고,오히려 더 많은 팀과 동시에 연결되어 있다는 점에서 색다른 긴장감과 설렘을 느낄 수 있었다.이 경험을 통해 ..

IT 개발 2026.03.27
728x90
반응형