[멘토링]LLM 서비스에서 메시지 큐 도입 시점과 기술 선택 기준이 궁금합니다. (답변 희망 멘토: charlotte.chk)

[WAFriend3416]

🙋 질문자: 판교 3기 / 14조(나춘식과 집사들) - waf.jung(정승환) / Cloud

🙋 답변 희망 멘토: charlotte.chk(김채현) / @cohys7

🔍 궁금한 내용

LLM 서비스에서 메시지 큐 도입 시점과 기술 선택 기준이 궁금합니다.

저희 서비스는 계약서 이미지 → OCR → LLM 해설 파이프라인을 자체 GPU 서버에서 운영할 예정입니다. 모델 응답이 1분 이상 걸릴 것으로 예상되어, 동시 요청 처리와 장애 시 재시도를 위해 메시지 큐 도입을 검토하고 있습니다.

현재는 초기 단계라 실트래픽은 크지 않지만, 장시간 추론(1분+)과 GPU 병목 특성상 재시도/중복 처리 방지/관측 같은 운영 이슈를 초기부터 설계에 반영하는 게 맞는지 판단이 필요합니다. 또한 팀 차원에서 운영 경험을 갖추기 위해 큐잉 시스템 도입을 검토하고 있으나, 현재 단계의 트래픽 대비 과도한 복잡도가 되지 않도록 도입의 적정선을 조언 받고 싶습니다.

---

🛠 시도한 방식

프로젝트 구조를 구현 가능성과 운영 경험을 염두에 두고 설계했습니다.

현재 아키텍처

[WAS - Spring Boot] → [AI 서버 - FastAPI] → [자체 GPU 모델 서빙]

• 모델 서빙 프레임워크(vLLM, TGI)의 내부 배칭/큐잉 활용 가능성을 확인
• 초기에는 별도 메시지 큐 없이 시작하는 구성을 고려 중
• GPU 1장당 동시 처리 1~2건으로 가정 (사용할 OSS LLM 미정, 모델 확정 후 벤치마크 예정)

검토한 내용

• 모델 서빙 프레임워크가 내부적으로 요청 배칭/큐잉을 제공함을 확인
• 별도 메시지 큐는 "재시도 + 중복 처리 방지 + 스케일 아웃"이 필요해질 때 도입하려고 함
• 1분+ 응답 시간에서 동기 HTTP 호출이 적절한지 불확실
• 실트래픽이 없더라도 부하 테스트로 문제 상황을 재현하려는 접근이 유효한지 판단이 필요

---

📋 이제 어떻게 하려고 하는지

메시지 큐 도입 관련해서 다음 세 가지를 고민 중입니다.

A. 초기에는 큐 없이, 문제 발생 시 도입

• 동기 HTTP + 긴 타임아웃(2분+)으로 시작
• 모니터링하다가 타임아웃/재시도 필요성 발생 시 큐 도입

B. 처음부터 비동기 패턴 적용 (큐 없이)

• 요청 → 작업ID 반환 → 폴링으로 결과 조회
• 메시지 큐 없이 DB에 작업 상태 저장

C. 운영 경험 확보를 위해 처음부터 메시지 큐 도입

• 가정 기반 부하 테스트로 문제 상황 재현 후, 큐 도입으로 해결
• 문제 → 해결 과정을 경험하고 문서화

추가) 가정 기반 부하 테스트 계획 (성장기 트래픽 가정)

• 테스트 시나리오: 동시 10~15건 AI 요청
• 도구: Locust, k6 등으로 동시 요청 발생
• 측정 항목: 타임아웃 발생률, 재시도 필요 여부, 평균/p95 응답 시간
• 목표: 큐 없이 → 문제 발생 확인 → 큐 도입 → 개선 효과 측정

---

🙏 질문 정리

도입 계기/경험

1. 실제 AI 서비스 운영 시 큐잉을 도입하게 된 계기가 있었나요? (어떤 문제가 발생해서?)

기술 선택
2. 다양한 큐 기술 스택 중에서 AI 서비스에 더 적합한 선택 기준이 있을까요?

설계 판단
3. A/B/C 중 어떤 접근을 권장하시는지, 그 판단 기준이 궁금합니다

포트폴리오 관점
4. 포트폴리오 관점에서 운영 경험을 추가하려면 어떤 부분을 신경 써야 할까요?
(예: 재시도 정책, DLQ, 중복 처리 방지(idempotency), 관측/알람, timeout 등)

[cohys7]

@WAFriend3416 안녕하세요.
멘토링에서 답변 드렸던 부분 정리해서 답변 남깁니다.

1. 실제 AI 서비스 운영 큐 도입 계기
실제 AI 모델을 직접 운영하는 서비스 경험은 없어서, 유사한 운영 사례로 설명드립니다.
콘텐츠 파이프라인을 개발하면서 전사 콘텐츠를 수집·가공·유통하는 API를 운영했고,
여러 조직의 콘텐츠를 수집하거나, 다른 조직에서 발굴한 콘텐츠의 메타데이터를 동기화하는 과정에서 메시지 큐를 사용했습니다.
저희는 Kafka를 사용했었는데,
여러 조직에서 만든 콘텐츠를 한 곳에 모아 처리하고,
파티션 키로 사용해 동일 엔티티 단위의 순서를 보장하기 위해 카프카를 이용했습니다.

2. 다양한 큐 기술 스택 중 AI 서비스에 더 적합한 선택 기준
AI 서비스 보다, 지금 만드는 서비스가 어떤 특성을 가지는지 고려하는 것이 좋을 것 같습니다.
다양한 큐 기술마다, 각 기술의 장/단점이 존재할텐데요. 해당 장단점을 가지고 내가 만드는 서비스에 어떤 기술이 더 도움이 되는지 비교해서 생각해보면 좋을 것 같습니다.

3. A/B/C 중 권장하는 접근과 판단 기준
말씀 주신 것 처럼 A -> B -> C 순서대로 진행해도 큰 문제 없을 것 같습니다.
다만, 이미 응답시간이 오래 걸릴 것을 예상할 수 있고, 동기/비동기에 따라 프론트 작업이 달라진다면
A는 생략하고 B -> C 순서로 진행하는 것이 더 좋을 것 같습니다.

5. 포트폴리오에서 운영 경험을 어필하는 방법
출시 이전에 예측 가능한 부분에 대해서는 미리 작업할 수 있겠지만,
사전에 모든 이슈를 찾아내서 대응하기 어려우니
빠르게 만들고 출시한 후 운영하면서 대응한 경험을 만드는 것이 좋을 것 같습니다.