pandaterry's 개발로그

웹 백엔드를 운영하다 보면 캐시는 거의 본능처럼 사용하게 됩니다. 대부분은 Redis나 Memcached에 “정확히 일치하는” 키를 기반으로 결과를 저장하곤 합니다. 예를 들어, product:summary:2024-05 같은 키는 5월 상품 요약 데이터를 조회할 때 잘 맞는 구조입니다. 이렇게 명확히 정해진 키로 식별할 수 있는 요청은 캐시하기가 쉽습니다. 그런데 최근에는 자연어 기반 인터페이스가 많아지고 있습니다. LLM을 활용해 데이터를 조회하거나, 자연어로 분석 보고서를 생성하는 시스템이 점점 늘어나고 있습니다. 문제는 이런 자연어 요청은 매번 다르다는 점입니다. 예를 들어 사용자가 이런 식으로 요청할 수 있습니다.“5월 매출 요약 보여줘”“지난달 실적 정리해줘”“이번 분기 매출 추이는?”이 요..

이전 글(https://pandaterry.tistory.com/9)에서는 Redis Pub/Sub과 Kafka를 비교하며 메시지 유실·재처리 이슈를 검증했습니다. 이번 글에서는 “Redis만으로도 신뢰형 메시지 큐를 구현할 수 있지 않을까?”라는 의문으로 다음 방식으로 직접 비교·실험해보겠습니다. 왜 Pub/Sub만으로는 부족했을까?현재 개발중인 SaaS 서비스는 “사용자의 Saas 기능 사용 -> 사용량 측정”이라는 흐름을 비동기로 처리합니다. 이 구조에서 가장 먼저 선택한 메시지 브로커는 Redis Pub/Sub이었습니다. 설정이 간단하고, 즉각적인 전달이 가능했기 때문입니다.하지만 곧 문제를 마주하게 됩니다."만약 메시지를 구독 중이던 서버가 죽는다면?""그 사이에 발행된 메시지는 어떻게 되는가..

Kafka로 전환하기 전, 직접 실험해봤습니다 SaaS에서 비동기 메시지는 선택이 아니라 필수입니다제가 구축하고 있는 SaaS 시스템은 마케팅/비즈니스 부서가 자연어로 데이터를 요청하면, 그 요청을 백엔드에서 SQL로 변환하고 엑셀로 응답해주는 플랫폼입니다. 문제는 여기서 끝나지 않았습니다. 사용자의 요청은 내부 시스템에서 백엔드 작업자에게 전송돼야 하고동시에 로그로 남겨져야 하며실패 시 재시도도 가능해야 합니다 처음엔 Redis Pub/Sub으로 충분하다고 생각했습니다.하지만 “요청이 처리됐는지 안 됐는지조차 확인할 수 없다면, 그건 SaaS가 아니라 알 수 없는 상자”가 되어버리더군요. 그래서 Kafka를 검토하게 되었고, “진짜로 필요한가?”라는 의문에 답하기 위해 직접 실험을 진행했습니다...