부제: 챗봇 서버를 프론트엔드에서 직접 호출할 것인가, 백엔드 프록시를 거칠 것인가

요약

Kubernetes 환경에서 프론트엔드, 백엔드, 챗봇 에이전트 서버를 함께 운영할 때 자주 나오는 고민이 있다.

“프론트엔드에서 챗봇 서버를 직접 호출하는 것이 좋을까, 아니면 백엔드 서버를 프록시처럼 거쳐서 챗봇 서버를 호출하는 것이 좋을까?”

이 질문은 단순히 네트워크 경로의 문제가 아니다. 특히 챗봇 서버는 일반 API와 달리 응답 시간이 길 수 있다. LLM 추론, RAG 검색, 외부 도구 호출, 에이전트 실행 등이 포함되면 하나의 요청이 수 초에서 수십 초 이상 유지될 수 있다.

따라서 이 구조를 결정할 때는 다음 세 가지를 함께 봐야 한다.

• 응답 속도
• 서버 리소스 사용량
• 인증, 권한, 운영 안정성

결론부터 말하면, 일반적인 K8s 기반 업무 서비스에서는 다음 구조가 가장 균형이 좋다.

Browser
  ↓
Internal DNS / Ingress / Gateway
  ├── /api/*  → Backend Service
  └── /chat/* → Chatbot Agent Service

Backend
  └── 인증, 권한 확인, 사용자 정보, 짧은 수명의 chat token 발급

Chatbot Agent Server
  └── 긴 처리, LLM/RAG/Agent 실행, streaming 응답

핵심은 이것이다.

“백엔드는 긴 챗봇 응답을 끝까지 기다리는 프록시가 아니라, 인증과 권한을 통제하는 control path 역할을 맡는 것이 좋다.”

1. 문제 상황

K8s 클러스터 안에 다음 세 종류의 서버가 있다고 가정해보자.

- Frontend server
- Backend API server
- Chatbot Agent server

프론트엔드와 백엔드는 이미 내부 DNS 또는 Ingress를 통해 접근 가능하다. 챗봇 에이전트 서버도 내부 DNS나 Ingress/Gateway를 통해 접근할 수 있도록 구성할 수 있다.

이때 선택지는 크게 두 가지다.

첫 번째는 프론트엔드에서 챗봇 서버를 직접 호출하는 구조다.

Browser → Internal DNS / Ingress / Gateway → Chatbot Agent Server

두 번째는 프론트엔드가 백엔드 서버를 호출하고, 백엔드 서버가 다시 클러스터 내부의 챗봇 서버를 호출하는 구조다.

Browser → Backend Server → Chatbot Agent Server

표면적으로 보면 두 번째 구조가 더 좋아 보일 수 있다. 백엔드 서버와 챗봇 서버가 같은 K8s 클러스터 안에 있기 때문에 내부 Service DNS로 바로 연결할 수 있기 때문이다.

예를 들면 다음과 같은 주소를 사용할 수 있다.

http://chatbot-service.namespace.svc.cluster.local:8000

또는 같은 namespace라면 다음처럼 짧게 쓸 수도 있다.

http://chatbot-service:8000

하지만 실제 판단은 그렇게 단순하지 않다.

2. 먼저 오해를 풀어야 한다: “frontend에서 호출”의 의미

React, Vue, Angular 같은 SPA 기반 프론트엔드에서는 중요한 구분이 있다.

프론트엔드 화면에서 API를 호출한다고 해서, 반드시 프론트엔드 서버 pod가 API를 호출하는 것은 아니다.

대부분의 경우 실제 요청 주체는 다음과 같다.

사용자 브라우저

즉, 프론트엔드 코드에서 다음과 같이 호출한다고 해보자.

fetch("https://chatbot.company.internal/chat")

이 요청은 K8s 내부의 frontend pod에서 나가는 것이 아니라, 사용자의 브라우저에서 나간다.

따라서 다음 두 구조는 완전히 다르다.

[오해하기 쉬운 구조]
Frontend Pod → Chatbot Pod

[실제 브라우저 기반 구조]
User Browser → DNS / Ingress / Gateway → Chatbot Service → Chatbot Pod

이 차이를 이해해야 전체 구조를 올바르게 판단할 수 있다.

3. 구조 A: 브라우저가 챗봇 서버를 직접 호출하는 방식

첫 번째 구조는 다음과 같다.

graph TD
    U[User Browser] --> D[Internal DNS]
    D --> G[Ingress / Gateway]
    G --> C[Chatbot Service]
    C --> P[Chatbot Agent Pod]

이 구조에서는 브라우저가 챗봇 서버의 API를 직접 호출한다. 물론 실제로 pod IP를 직접 호출하는 것은 아니다. 일반적으로는 내부 DNS, Ingress, Gateway, LoadBalancer 등을 통해 챗봇 Service로 연결한다.

장점

이 구조의 가장 큰 장점은 경로가 짧다는 것이다.

Browser → Chatbot

백엔드 서버를 거치지 않으므로 불필요한 hop이 줄어든다. 특히 챗봇 응답이 streaming 방식이라면 브라우저와 챗봇 서버 사이에서 바로 SSE 또는 chunked response를 주고받을 수 있다.

또 하나의 큰 장점은 백엔드 서버가 긴 챗봇 요청을 붙잡고 있지 않아도 된다는 점이다.

챗봇 요청은 일반 API와 성격이 다르다.

일반 API:
짧은 요청, 빠른 응답, 수십~수백 ms 또는 1~2초 이내

챗봇 API:
긴 요청, streaming 응답, 수 초~수십 초 이상

브라우저가 챗봇 서버를 직접 호출하면, 긴 요청으로 인한 부담은 chatbot 계층과 gateway 계층에서 처리된다. 기존 backend API 서버는 영향을 덜 받는다.

단점

하지만 이 구조에는 반드시 해결해야 할 문제가 있다.

- 챗봇 API가 브라우저에 직접 노출된다.
- 인증과 권한 검증을 챗봇 서버 또는 Gateway에서 처리해야 한다.
- CORS 설정이 필요할 수 있다.
- 사용자 정보 전달 방식을 별도로 설계해야 한다.
- 요청 제한, 감사 로그, 접근 제어를 어디서 할지 정해야 한다.

즉, 직접 호출 구조는 속도와 리소스 측면에서는 유리할 수 있지만, 인증과 운영 통제 설계를 소홀히 하면 위험해질 수 있다.

4. 구조 B: 백엔드 서버가 챗봇 서버를 프록시하는 방식

두 번째 구조는 다음과 같다.

graph TD
    U[User Browser] --> D[Internal DNS]
    D --> G[Ingress / Gateway]
    G --> B[Backend Service]
    B --> BP[Backend Pod]
    BP --> S[Chatbot Service: ClusterIP]
    S --> CP[Chatbot Agent Pod]

이 구조에서는 브라우저가 백엔드 API를 호출하고, 백엔드가 내부 Service DNS를 이용해 챗봇 서버를 호출한다.

예를 들어 백엔드 서버는 다음 주소로 챗봇 서버를 호출할 수 있다.

http://chatbot-service.namespace.svc.cluster.local:8000

장점

이 방식의 장점은 명확하다.

- 프론트엔드는 백엔드 API만 호출하면 된다.
- 인증, 권한, 세션 처리를 백엔드에서 일원화할 수 있다.
- 챗봇 서버의 내부 주소를 브라우저에 노출하지 않아도 된다.
- 감사 로그와 사용자 접근 제어를 백엔드 중심으로 관리하기 쉽다.
- 챗봇 서버를 외부에 직접 노출하지 않아도 된다.

업무 시스템에서는 이 장점이 매우 크다. 특히 사용자 권한, 조직 권한, 메뉴 권한, 데이터 접근 권한이 복잡한 사내 시스템에서는 백엔드가 중앙 통제 지점이 되는 구조가 자연스럽다.

단점

하지만 챗봇 서버의 응답 시간이 긴 경우에는 문제가 생긴다.

백엔드가 챗봇 서버의 응답을 기다리는 동안, 백엔드에도 긴 요청이 계속 살아 있게 된다.

Browser → Backend 연결 유지
Backend → Chatbot 연결 유지
Backend request context 유지
Backend worker/thread/coroutine 점유
Backend HTTP client connection pool 점유
Backend timeout 관리 필요

즉, 백엔드 서버는 단순히 요청을 전달하는 것처럼 보이지만 실제로는 긴 요청을 같이 떠안게 된다.

이것이 이 구조의 가장 큰 리스크다.

5. 응답 속도 관점에서의 비교

응답 속도만 놓고 보면, 브라우저가 챗봇 서버를 직접 호출하는 구조가 일반적으로 더 유리하다.

직접 호출 구조는 다음과 같다.

Browser → Chatbot

백엔드 프록시 구조는 다음과 같다.

Browser → Backend → Chatbot

백엔드와 챗봇이 같은 K8s 클러스터 안에 있고 내부 Service DNS로 통신한다고 하더라도, 전체 경로에서 백엔드라는 중간 지점이 추가된다.

따라서 백엔드 프록시 구조가 “클러스터 내부 통신을 쓰니까 더 빠르다”고 단정하기는 어렵다.

정확히는 다음과 같이 보는 것이 맞다.

브라우저 직접 호출:
외부 또는 내부 사용자망 → Ingress/Gateway → Chatbot

백엔드 프록시 호출:
외부 또는 내부 사용자망 → Ingress/Gateway → Backend → K8s 내부 Service → Chatbot

백엔드에서 챗봇으로 가는 구간은 빠를 수 있다. 하지만 그 앞에 백엔드 hop이 추가된다.

따라서 순수 latency 관점에서는 직접 호출이 더 유리할 가능성이 높다.

다만 챗봇 처리 시간이 20초, 30초, 1분 이상이라면 네트워크 hop 차이는 전체 응답 시간에서 상대적으로 작아질 수 있다.

그럼에도 불구하고 백엔드 프록시 구조가 더 빠르다고 보기는 어렵다.

6. 서버 리소스 관점에서의 비교

챗봇 서버의 응답 시간이 길다면 리소스 관점이 더 중요해진다.

하나의 챗봇 요청이 평균 30초 걸린다고 가정해보자.

초당 1개의 요청이 들어오면 동시에 살아 있는 요청 수는 대략 다음과 같다.

동시 요청 수 ≈ 초당 요청 수 × 평균 처리 시간

1 req/sec × 30 sec = 30 concurrent requests

초당 5개의 요청이 들어오면 다음과 같다.

5 req/sec × 30 sec = 150 concurrent requests

직접 호출 구조에서는 이 동시 요청을 chatbot 서버와 gateway 계층이 감당한다.

Browser → Chatbot

Chatbot 계층에 long-running request 발생
Backend 부담 없음

반면 백엔드 프록시 구조에서는 backend도 같은 수의 요청을 같이 붙잡는다.

Browser → Backend → Chatbot

Backend에도 long-running request 발생
Chatbot에도 long-running request 발생

이 차이는 작지 않다.

백엔드 프록시 구조에서는 다음 리소스가 추가로 사용된다.

- client → backend connection
- backend request handler
- backend → chatbot outbound connection
- backend HTTP client connection pool
- backend memory buffer
- backend timeout context
- backend logging/tracing context

특히 backend가 기존 업무 API도 함께 처리한다면 문제가 더 커진다.

일반 업무 API:
빠르고 짧은 요청

챗봇 API:
느리고 긴 요청

이 둘을 같은 backend worker pool에서 처리하면, 챗봇 요청이 몰릴 때 일반 API까지 느려질 수 있다.

7. blocking 방식이면 특히 위험하다

백엔드 프록시 구조가 반드시 나쁜 것은 아니다. 문제는 구현 방식이다.

가장 위험한 형태는 blocking 방식이다.

1. backend가 요청을 받는다.
2. backend가 blocking HTTP client로 chatbot을 호출한다.
3. chatbot 응답이 끝날 때까지 backend thread가 대기한다.
4. 요청이 많아지면 backend thread pool이 고갈된다.
5. 일반 API까지 응답이 느려진다.

예를 들어 Java/Kotlin 기반 백엔드에서 blocking HTTP client를 사용하거나, Python FastAPI에서 async 함수 안에 blocking 호출을 넣는 경우 이런 문제가 발생할 수 있다.

반대로 상대적으로 안전한 형태는 다음과 같다.

- async/non-blocking HTTP client 사용
- streaming pass-through 사용
- 응답 전체를 backend 메모리에 buffering하지 않음
- chatbot 요청용 endpoint와 일반 API endpoint를 분리
- timeout, connection pool, worker 수를 별도 조정

하지만 async 방식이라고 해도 리소스 부담이 완전히 사라지는 것은 아니다.

- socket
- file descriptor
- coroutine/task
- connection pool
- memory
- tracing context

긴 요청이 많아지면 이 리소스들도 실제 부담이 된다.

8. Streaming을 사용하는 경우

챗봇 서비스는 일반적으로 streaming 응답이 잘 맞는다.

사용자가 질문을 입력하면 전체 답변이 완성될 때까지 기다리는 것이 아니라, 답변이 생성되는 대로 조금씩 내려주는 방식이다.

질문 입력
  ↓
첫 token 또는 첫 문장 반환
  ↓
나머지 답변을 순차적으로 전송

이 방식은 사용자 경험 측면에서 매우 중요하다. 특히 챗봇 처리 시간이 긴 경우에는 streaming이 사실상 필수에 가깝다.

하지만 백엔드가 streaming proxy 역할을 하면 다음과 같은 구조가 된다.

Browser
  ↓ streaming
Backend
  ↓ streaming
Chatbot

이 경우 백엔드는 전체 응답을 메모리에 쌓지 않아도 되지만, 연결 자체는 계속 유지해야 한다.

따라서 백엔드 프록시 구조에서는 다음 설정을 반드시 검토해야 한다.

- backend의 read timeout
- backend의 write timeout
- backend HTTP client timeout
- Ingress/Gateway proxy timeout
- proxy buffering 여부
- SSE heartbeat 또는 progress event
- connection pool 크기

챗봇 서버가 60초 동안 아무 데이터도 보내지 않다가 마지막에 한 번에 응답하면 중간 프록시에서 timeout이 발생할 수 있다.

따라서 긴 챗봇 응답에서는 중간중간 데이터를 내려주는 구조가 더 안정적이다.

9. 가장 권장하는 구조: Gateway path routing + backend control path

가장 균형 잡힌 구조는 다음이다.

graph TD
    U[User Browser] --> G[Internal DNS / Ingress / Gateway]
    G -->|/api/*| B[Backend Service]
    G -->|/chat/*| C[Chatbot Agent Service]
    B -->|short-lived chat token 발급| U
    C --> CP[Chatbot Agent Pod]

이 구조에서는 외부 또는 사내 사용자에게 하나의 도메인만 제공한다.

https://app.company.internal

그리고 path에 따라 내부 서비스를 나눈다.

/api/*  → backend-service
/chat/* → chatbot-service

이 구조의 장점은 다음과 같다.

- 프론트엔드는 하나의 도메인만 사용한다.
- CORS 문제가 줄어든다.
- backend가 긴 챗봇 응답을 기다리지 않는다.
- chatbot은 직접 streaming 응답을 처리할 수 있다.
- 인증과 권한은 backend가 통제할 수 있다.
- chatbot은 Service 뒤에서 운영할 수 있다.
- 일반 업무 API와 챗봇 long-running request를 분리할 수 있다.

이 방식에서 backend는 data path가 아니라 control path 역할을 한다.

Data path:
Browser → Chatbot

Control path:
Browser → Backend → 인증/권한 확인 → chat token 발급

즉, 백엔드가 모든 챗봇 응답을 중계하는 것이 아니라, 사용자가 챗봇을 사용할 수 있는 권한이 있는지만 확인하고 짧은 수명의 토큰을 발급한다.

10. 인증과 권한은 어떻게 처리할까?

직접 호출 구조에서 가장 중요한 문제는 인증과 권한이다.

이를 해결하는 좋은 방식은 짧은 수명의 chat token을 사용하는 것이다.

sequenceDiagram
    participant Browser
    participant Backend
    participant Chatbot

    Browser->>Backend: 로그인 / 세션 확인
    Backend-->>Browser: access token 또는 session 발급

    Browser->>Backend: chat token 요청
    Backend->>Backend: 사용자 권한 확인
    Backend-->>Browser: short-lived chat token 발급

    Browser->>Chatbot: chat token과 함께 질문 전송
    Chatbot->>Chatbot: token 검증
    Chatbot-->>Browser: streaming 응답

이 구조의 핵심은 다음이다.

- backend는 사용자의 인증과 권한을 확인한다.
- backend는 짧은 수명의 chat token을 발급한다.
- chatbot은 이 token을 검증한다.
- chatbot은 긴 응답과 streaming을 직접 처리한다.

chat token에는 다음 정보를 포함할 수 있다.

{
  "sub": "user-id",
  "tenant": "company-or-org-id",
  "roles": ["chat_user"],
  "scope": ["chat:ask"],
  "exp": 1710000000
}

중요한 것은 token의 수명을 짧게 가져가는 것이다.

예: 5분, 10분, 15분

이렇게 하면 챗봇 API가 브라우저에서 직접 호출되더라도 무제한 접근을 막을 수 있다.

11. 예시 K8s 구성

아래는 개념적인 예시다. 실제 환경에서는 namespace, 인증서, ingress class, gateway controller, 보안 정책에 맞게 조정해야 한다.

Chatbot Service

apiVersion: v1
kind: Service
metadata:
  name: chatbot-service
  namespace: app
spec:
  type: ClusterIP
  selector:
    app: chatbot
  ports:
    - name: http
      port: 8000
      targetPort: 8000

Backend Service

apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: app
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - name: http
      port: 8080
      targetPort: 8080

Ingress path routing 예시

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: app
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
spec:
  rules:
    - host: app.company.internal
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 8080
          - path: /chat
            pathType: Prefix
            backend:
              service:
                name: chatbot-service
                port:
                  number: 8000

이 구조에서는 브라우저가 다음처럼 호출한다.

https://app.company.internal/api/*
https://app.company.internal/chat/*

프론트엔드 입장에서는 같은 도메인이기 때문에 운영이 단순해진다.

12. 백엔드 프록시가 꼭 필요한 경우

회사 보안 정책이나 기존 인증 구조 때문에 모든 요청이 반드시 backend를 거쳐야 하는 경우도 있다.

이 경우에는 백엔드 프록시 구조를 사용할 수 있다.

다만 다음 조건을 지키는 것이 좋다.

- blocking proxy 금지
- async/non-blocking HTTP client 사용
- streaming pass-through 사용
- chatbot 응답 전체를 backend 메모리에 적재하지 않음
- 일반 업무 API와 chatbot proxy endpoint 분리
- chatbot proxy 전용 Deployment 또는 BFF 분리 검토
- timeout, retry, circuit breaker 설정
- backend worker/thread/connection pool 별도 튜닝
- HPA 기준을 CPU뿐 아니라 active request, latency, connection 수까지 고려

특히 기존 backend 서버가 업무 API를 처리하고 있다면, 챗봇 프록시 기능을 같은 서버에 단순히 추가하는 것은 위험할 수 있다.

더 안전한 구조는 다음과 같다.

graph TD
    U[User Browser] --> G[Ingress / Gateway]
    G --> A[Backend API Service]
    G --> P[Chat Proxy Service]
    P --> C[Chatbot Agent Service]

즉, 프록시가 꼭 필요하다면 기존 backend에 붙이기보다 chat proxy 전용 서비스를 별도로 두는 편이 낫다.

이렇게 하면 일반 API와 챗봇 long-running request를 분리할 수 있다.

13. 비교표

14. 실무 의사결정 기준

다음 기준으로 판단하면 된다.

1. 챗봇 응답 시간이 짧고 요청량도 적다

이 경우에는 백엔드 프록시 구조도 큰 문제가 없을 수 있다.

Browser → Backend → Chatbot

다만 향후 사용량이 증가할 가능성이 있다면 처음부터 async streaming 구조를 고려하는 것이 좋다.

2. 챗봇 응답 시간이 길다

이 경우에는 backend가 긴 요청을 계속 붙잡는 구조는 피하는 것이 좋다.

권장 구조는 다음이다.

Browser → Gateway → Chatbot
Backend → 인증/권한/token 발급

3. 보안상 챗봇 API를 절대 직접 노출할 수 없다

이 경우에는 백엔드 또는 chat proxy를 거쳐야 한다.

하지만 기존 backend에 그냥 붙이지 말고, 가능하면 다음처럼 분리한다.

Browser → Chat Proxy Service → Chatbot

chat proxy는 long-running request 전용으로 설계한다.

4. 하나의 도메인으로 운영하고 싶다

이 경우에는 Ingress/Gateway의 path routing이 가장 적합하다.

https://app.company.internal/api/*  → backend
https://app.company.internal/chat/* → chatbot

15. 권장 아키텍처 최종안

최종적으로 권장하는 구조는 다음과 같다.

graph TD
    U[User Browser] --> D[Internal DNS: app.company.internal]
    D --> G[Ingress / API Gateway]

    G -->|/api/*| B[Backend Service]
    G -->|/chat/*| C[Chatbot Agent Service]

    B --> DB[(Database)]
    B --> AUTH[Auth / Permission]

    C --> LLM[LLM / RAG / Agent Runtime]
    C --> VDB[(Vector DB / Search Index)]

    B -. short-lived chat token .-> U
    U -. token 포함 질문 .-> C

이 구조에서 역할은 다음과 같이 나뉜다.

Frontend:
사용자 화면, 챗봇 UI, streaming 표시

Backend:
로그인, 인증, 권한, 사용자 정보, chat token 발급, 감사 로그

Chatbot Agent Server:
질문 처리, RAG 검색, LLM 호출, tool calling, streaming 응답

Ingress / Gateway:
단일 도메인 진입점, path routing, TLS, timeout, rate limit

이렇게 구성하면 세 가지 균형을 맞출 수 있다.

응답 속도:
챗봇 응답은 backend를 거치지 않고 직접 streaming 가능

서버 리소스:
backend가 long-running request를 떠안지 않음

운영 안정성:
인증과 권한은 backend 또는 gateway에서 통제 가능

16. 운영 체크리스트

실제 운영 전에 다음 항목을 점검하는 것이 좋다.

네트워크

- chatbot은 pod IP가 아니라 Service로 노출되어 있는가?
- /api와 /chat path routing이 명확한가?
- 내부 DNS가 Ingress/Gateway를 올바르게 가리키는가?
- 같은 도메인을 사용하는 경우 CORS가 불필요한 구조인가?

인증/권한

- chatbot 요청에 사용자 식별 정보가 안전하게 전달되는가?
- chat token의 만료 시간이 짧은가?
- chatbot 서버가 token을 검증하는가?
- 사용자별 접근 가능한 데이터 범위가 반영되는가?

리소스

- chatbot 서버의 동시 요청 수를 예측했는가?
- 평균 응답 시간과 RPS로 concurrent request를 계산했는가?
- backend가 long-running request를 처리하지 않도록 설계했는가?
- proxy가 필요하다면 전용 chat proxy를 분리했는가?

Streaming

- SSE 또는 streaming 응답을 사용하는가?
- 중간 프록시 timeout이 충분한가?
- 장시간 무응답 상태를 막기 위해 heartbeat를 보내는가?
- proxy buffering이 streaming을 방해하지 않는가?

장애 대응

- chatbot 서버 장애 시 frontend에 적절한 오류 메시지가 표시되는가?
- backend와 chatbot의 장애가 서로 전파되지 않도록 분리되어 있는가?
- rate limit 또는 circuit breaker가 있는가?
- 로그와 trace에서 사용자 요청 흐름을 추적할 수 있는가?

결론

K8s 환경에서 프론트엔드, 백엔드, 챗봇 에이전트 서버를 구성할 때 가장 중요한 질문은 이것이다.

“긴 챗봇 요청을 누가 붙잡고 있을 것인가?”

백엔드 서버가 모든 챗봇 요청을 프록시하면 인증과 권한 통제는 쉬워진다. 하지만 챗봇 응답이 길어질수록 백엔드 서버의 connection, worker, thread, coroutine, memory, timeout 부담이 커진다.

반대로 브라우저가 챗봇 서버를 직접 호출하면 응답 경로가 짧아지고 backend 부담은 줄어든다. 하지만 인증, 권한, 감사, rate limit을 별도로 설계해야 한다.

따라서 가장 균형 잡힌 구조는 다음이다.

Browser
  ↓
Ingress / Gateway
  ├── /api/*  → Backend
  └── /chat/* → Chatbot Agent Server

Backend:
인증, 권한, chat token 발급

Chatbot:
긴 처리, LLM/RAG/Agent 실행, streaming 응답

정리하면 다음과 같다.

“백엔드는 챗봇 응답을 대신 기다리는 서버가 아니라, 챗봇 사용 권한을 통제하는 서버가 되어야 한다.”

이렇게 구성하면 응답 속도, 서버 리소스, 보안, 운영 안정성 사이에서 가장 현실적인 균형점을 만들 수 있다.