동블

그래프 뷰

24. AI LLM 서버 연동 지도 - Prompt, Context, LLM API, Worker, Queue

9 min read

이 지도를 통해 아래 질문들에 답할 수 있게 됩니다.

  • AI/LLM 기능은 웹 백엔드 시스템 안에서 어느 위치에 붙는가?
  • Prompt, Context, RAG, Vector DB, Tool Calling은 서로 어떻게 연결되는가?
  • LLM API 호출은 왜 Queue, Worker, Timeout, Observability와 함께 설계해야 하는가?
  • AI 기능 장애가 났을 때 품질, 비용, 지연, 보안 중 무엇을 먼저 확인해야 하는가?
flowchart TB

subgraph USER_FLOW["User Request"]
direction TB
CLIENT["[Client]<br/>AI 기능 요청<br/>예: summarize, chat"]
API["[BackendAPI]<br/>권한·요청 검증<br/>예: prompt request"]
AI_SERVICE["[AIService]<br/>AI 작업 오케스트레이션<br/>예: use case"]
end

subgraph CONTEXT_FLOW["Prompt / Context"]
direction TB
PROMPT["[PromptTemplate]<br/>지시문과 변수 구조<br/>예: system, user"]
CONTEXT["[ContextBuilder]<br/>사용자·도메인 정보 조립<br/>예: profile, policy"]
RAG["[RAGRetriever]<br/>관련 문서 검색<br/>예: topK"]
VECTOR[("[VectorDB]<br/>임베딩 검색 저장소<br/>예: chunk, metadata")]
end

subgraph EXECUTION["LLM Execution"]
direction TB
QUEUE[["[Queue]<br/>긴 AI 작업 분리<br/>예: report generation"]]
WORKER["[AIWorker]<br/>비동기 AI 작업 수행<br/>예: retry, stream"]
LLM(("[LLMAPI]<br/>외부 모델 호출<br/>예: chat, embedding"))
TOOL{"[ToolCalling]<br/>서버 기능 실행 경계<br/>예: search, db action"}
end

subgraph GOVERNANCE["Quality / Ops / Security"]
direction TB
EVAL[["[Evaluation]<br/>품질 회귀 확인<br/>예: dataset, score"]]
OBS[["[Observability]<br/>비용·지연·품질 추적<br/>예: token, latency"]]
GUARD{"[Guardrail]<br/>개인정보·프롬프트 공격 방어<br/>예: PII mask, jailbreak"}
RESULT["[AIResponse]<br/>응답·근거·오류 상태<br/>예: answer, citation"]
end

CLIENT -->|AI request| API
API -->|auth / validate| AI_SERVICE
AI_SERVICE -->|render prompt| PROMPT
AI_SERVICE -->|build context| CONTEXT
CONTEXT -.->|retrieve docs| RAG
RAG ==>|vector search| VECTOR
PROMPT -->|prompt messages| LLM
CONTEXT -->|context payload| LLM
AI_SERVICE -.->|offload long job| QUEUE
QUEUE -.->|consume job| WORKER
WORKER -->|call model| LLM
LLM -->|structured tool request| TOOL
TOOL -->|safe server action| AI_SERVICE
LLM -->|model output| RESULT
RESULT -->|return response| CLIENT
LLM -.->|token / latency / error| OBS
PROMPT -.->|regression target| EVAL
RESULT -.->|quality sample| EVAL
API -->|privacy / policy check| GUARD
GUARD -->|blocked or masked| RESULT

classDef client fill:#E3F2FD,stroke:#1565C0,color:#0D47A1;
classDef server fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20;
classDef data fill:#FFF3E0,stroke:#EF6C00,color:#E65100;
classDef event fill:#F3E5F5,stroke:#6A1B9A,color:#4A148C;
classDef ops fill:#ECEFF1,stroke:#455A64,color:#263238;
classDef security fill:#FFEBEE,stroke:#C62828,color:#B71C1C;

class CLIENT,RESULT client;
class API,AI_SERVICE,PROMPT,CONTEXT,RAG,WORKER server;
class VECTOR data;
class QUEUE,LLM event;
class EVAL,OBS ops;
class TOOL,GUARD security;

linkStyle 0,13,14 stroke:#1565C0,stroke-width:2px;
linkStyle 1,2,3 stroke:#2E7D32,stroke-width:2px;
linkStyle 4,8,9 stroke:#6A1B9A,stroke-width:2px,stroke-dasharray:5 5;
linkStyle 5 stroke:#EF6C00,stroke-width:3px;
linkStyle 6,7,10 stroke:#6A1B9A,stroke-width:2px;
linkStyle 11,12,18,19 stroke:#C62828,stroke-width:2px;
linkStyle 15,16,17 stroke:#455A64,stroke-width:2px,stroke-dasharray:5 5;

이 지도는 AI/LLM 기능을 별도 장난감 기능이 아니라 웹 백엔드 시스템에 붙는 하나의 실행 흐름으로 설명한다. 클라이언트가 AI 기능을 요청하면 Backend API는 인증, 권한, 입력 검증을 수행하고 AIService가 prompt, context, retrieval, model call을 조립한다.

PromptTemplate은 모델에게 줄 지시와 변수 구조를 담고, ContextBuilder는 사용자 정보와 업무 규칙을 조립한다. RAG가 필요하면 VectorDB에서 관련 문서를 찾아 context에 붙인다. 이때 권한이 없는 문서가 context에 들어가지 않도록 보안 경계를 함께 봐야 한다.

LLM API 호출은 지연시간, 비용, rate limit, provider 장애의 영향을 크게 받는다. 짧은 요청은 동기로 처리할 수 있지만, 긴 리포트 생성이나 대량 작업은 Queue와 Worker로 분리하는 편이 안전하다. 품질은 Evaluation으로, 운영은 Observability로 추적해야 한다.

장애가 났을 때 먼저 확인할 것

  • LLM API timeout, 429, 5xx, provider 장애 여부를 확인한다.
  • token 사용량과 비용이 평소보다 급증했는지 확인한다.
  • RAG 검색 결과가 비어 있거나 권한 없는 문서를 포함했는지 확인한다.
  • Queue 기반 작업이면 queue depth, worker retry, DLQ를 확인한다.
  • 품질 문제가 있으면 prompt version, context source, evaluation regression을 확인한다.

설계할 때 선택 기준

  • 짧고 즉시 필요한 답변은 동기 API로 시작할 수 있다.
  • 오래 걸리거나 비용이 큰 작업은 Queue와 Worker로 분리한다.
  • 도메인 문서 기반 답변이 필요하면 RAG와 VectorDB를 검토한다.
  • 서버 기능을 실행해야 하면 Tool Calling 경계에 권한, validation, audit log를 둔다.
  • 품질이 중요한 기능은 prompt 변경을 코드 변경처럼 versioning하고 evaluation을 붙인다.

운영 중 볼 지표

  • LLM latency, timeout count, provider error rate, 429 rate
  • prompt token, completion token, cost per request, cache hit ratio
  • RAG retrieval hit rate, no-context rate, source freshness
  • queue depth, worker retry count, AI DLQ count
  • evaluation score, hallucination report, human review rate, policy block count

흔한 오해

  • LLM API를 호출하는 것만으로 AI 기능 설계가 끝나지 않는다.
  • Prompt는 문장 조각이 아니라 versioning, test, rollback 대상이다.
  • RAG를 붙이면 항상 정확해지는 것이 아니라 검색 품질과 권한 경계가 중요해진다.
  • Tool Calling은 모델이 서버 기능을 실행하게 하는 경계라 보안 검증이 필요하다.
  • AI 기능의 장애는 500 오류뿐 아니라 품질 저하, 비용 폭증, 지연 증가로도 나타난다.

실전 체크리스트

  • AI 요청에 인증, 권한, 입력 검증이 적용되는가?
  • prompt와 model 설정이 versioning되고 rollback 가능한가?
  • RAG source, chunk, metadata, 권한 필터가 관리되는가?
  • LLM API timeout, retry, rate limit, fallback 기준이 있는가?
  • 비용, 지연, 품질, 보안 이벤트를 함께 관측하는가?

질문에 대한 답변

  1. AI/LLM 기능은 웹 백엔드 시스템 안에서 어느 위치에 붙는가?

    AI 기능은 Backend API 뒤의 AIService에 붙는다. AIService는 prompt와 context를 조립하고, 필요하면 RAG 검색과 Queue/Worker를 거쳐 LLM API를 호출한다.

  2. Prompt, Context, RAG, Vector DB, Tool Calling은 서로 어떻게 연결되는가?

    PromptTemplate은 지시 구조를 만들고, ContextBuilder는 사용자와 도메인 정보를 붙인다. RAG는 VectorDB에서 관련 문서를 찾아 context를 보강한다. Tool Calling은 모델 출력이 서버 기능 실행으로 이어지는 별도 보안 경계다.

  3. LLM API 호출은 왜 Queue, Worker, Timeout, Observability와 함께 설계해야 하는가?

    LLM 호출은 느릴 수 있고, 비용이 크며, provider 장애와 rate limit의 영향을 받는다. 긴 작업은 Queue/Worker로 분리하고, timeout과 retry를 둔 뒤 token, latency, error, quality를 관측해야 한다.

  4. AI 기능 장애가 났을 때 품질, 비용, 지연, 보안 중 무엇을 먼저 확인해야 하는가?

    증상에 따라 나눈다. 응답 실패는 provider error와 timeout, 느림은 latency와 queue depth, 비용은 token usage, 품질은 prompt/context/eval, 보안은 policy block과 tool 실행 로그를 먼저 본다.

관련 상세 문서

참고한 자료

관련 문서

백링크