1. 서비스 요구사항

분리된 API 서버와 LLM 서버 환경

<aside>

현재 진행중인 프로젝트의 서비스는 기본적인 API 서버와 LLM 응답을 생성해주는 LLM 서버가 존재한다.

API 서버

LLM 기능을 제외한 모든 서비스를 가지고 있다.

LLM 서버

LLM과 통신하는 서버, 따라서 보안이 굉장히 중요 - 금액적인 부분이 관련되어 있기 때문

이처럼 회원 관련 로직이 API 서버에 있지만 LLM 서버는 특히 금액이 나가는 부분이기 때문에 인가 과정이 필수다. 하지만 API 서버와 LLM 서버가 서로 다른 인가 프로세스를 가지는 것은 서비스 운영 시 복잡해질 가능성이 있다.

요청은 LLM 서버에서, 인가는 API 서버에서

사용자가 LLM 서버요청을 보내면 LLM 서버는 요청을 판별하기 위해 API 서버로 요청을 보낸다. 이를 통해 인가 과정이 거쳐지고 사용자는 LLM 서버에서 응답을 받을 수 있을지 결정한다.

</aside>

비회원도 사용가능하다 : 비회원 엑세스 토큰 발급

<aside>

LLM은 비회원도 사용해야한다. 물론 횟수 제한이 있지만 비회원도 어느정도 사용은 가능하다.

즉 해당 회원에 대한 정확한 변별이 필요하다.

이에 비회원에게도 엑세스 토큰을 발급하여 해당 토큰을 통해 LLM 호출 수를 제한한다.

IP + USER AGENT는 왜 안될까?

서비스 요구사항은 해당 사용자에 대한 명확한 식별이 중요하다.

하지만 IP는 장소가 바뀔때마다 바뀔 수 있고, 여러 사람이 동일하게 겹칠 수 있다. 또한 USER AGENT는 임의로 값을 변경할 수 있기에 문제가 될 수 있음

물론 회원도 토큰이 발급된다.

물론 회원가입을 하면 토큰이 발급된다. 즉, 비회원에게는 비회원 엑세스 토큰을 제공하고 비회원으로 접근 가능한 서비스의 영역을 제한한다.

</aside>

2. 아키텍처

<aside>

해당 아키텍처 과정을 하나하나 살펴보자

</aside>

1️⃣ 사용자가 LLM 서버로 요청을 보낸다.

<aside>

1. 사용자가 LLM 서버로 요청을 보낸다.
2. 이때 사용자의 엑세스 토큰을 헤더에 담아서 보낸다. 기본적으로 비회원과 회원 둘 다 엑세스 토큰을 가지고 있다. </aside>

2️⃣ LLM 서버는 API 서버로 인가 요청을 보낸다.

<aside>

1. LLM 서버는 미들웨어에서 사용자의 요청에서 엑세스 토큰을 추출한다.
2. 만약 엑세스 토큰이 없을경우 요청을 바로 제한한다.
3. 엑세스 토큰이 있다면 이를 API 서버로 전송한다. </aside>

3️⃣ API 서버는 인가과정을 거치고 응답을 생성한다.