대부분의 AI 애플리케이션은 남용을 방지하기 위해 오로지 **IP 기반 속도 제한 (IP-based rate limiting)**에만 의존합니다. 불행히도, 그것은 단지 첫 번째 방어선일 뿐입니다.

이 글에서는 FastAPI, MongoDB, 그리고 Beanie를 사용하여 지문(fingerprints)을 통해 방문자를 추적하고, 일일 사용 제한을 적용하며, 향후 인증을 준비하고, 확장 가능한 AI SaaS를 위한 토대를 마련하는 프로덕션 스타일의 **익명 신원 시스템 (anonymous identity system)**을 구축할 것입니다.

또한, 비즈니스 로직을 오염시키지 않고 다중 제공자 LLM 라우터 (LLM Router)와 어떻게 깔끔하게 통합되는지도 살펴볼 것입니다.

👋 서론 (Introduction)

AI 제품을 만들 때, 대부분의 개발자는 프롬프트 (prompts), LLM, 그리고 화려한 프론트엔드 인터페이스에 집중합니다.

AI가 호출되기도 전에 어떤 일이 일어나는지에 대해 고민하며 시간을 보내는 사람은 거의 없습니다.

그 요청은 식별되어야 합니다.
검증되어야 합니다.
보호되어야 합니다.
추적되어야 합니다.

그리고 결국 분석되어야 합니다.

AI 기반 이력서 맞춤화 플랫폼인 CVForbes를 작업하면서, 저는 **IP 기반 속도 제한 (IP-based rate limiting)**에만 의존하는 것으로는 충분하지 않다는 것을 깨달았습니다.

저는 다음과 같은 기능을 수행할 수 있는 무언가를 원했습니다:

• 익명 방문자 추적
• 무료 사용 제한
• 남용하는 클라이언트 탐지
• 향후 인증을 위한 준비
• API 경로를 완전히 깨끗하게 유지

그래서 엔드포인트 곳곳에 체크 로직을 뿌리는 대신, 전용 신원 및 남용 방지 계층 (identity and abuse protection layer)을 구축했습니다.

🤔 왜 단순히 IP 속도 제한만 사용하지 않나요?

전통적인 속도 제한은 다음과 같은 형태입니다:

@limiter.limit("3/minute")

그것은 좋은 시작입니다.

하지만 사용자는 다음과 같은 방법으로 이를 쉽게 우회할 수 있습니다:

• 네트워크 변경
• VPN 사용
• 기기 교체
• 브라우저 상태 초기화

모든 요청에 비용이 발생하는 AI 제품의 경우, 그것만으로는 충분하지 않습니다.

우리에게는 또 다른 계층이 필요했습니다.

💡 아이디어 (The Idea)

IP 주소만을 사용하여 요청을 식별하는 대신, 모든 요청은 먼저 클라이언트 신원 (Client Identity)이 됩니다.

Client Request
        │
        ▼
...

그 **지문 (fingerprint)**이 애플리케이션 전반에 걸쳐 사용자의 익명 신원이 됩니다.

🏗 아키텍처 (Architecture)

                Client Request
                      │
                      ▼
...

무언가 눈치채셨나요?

라우트 (route)는 사용자에 대해 전혀 알지 못합니다.

미들웨어 (middleware)가 요청이 비즈니스 로직 (business logic)에 도달하기 전에 모든 것을 처리합니다.

📂 백엔드 구성 (Organizing the Backend)

모든 것을 라우트 내부에 넣는 대신, 책임을 분리했습니다.

app/

├── middleware/
...

각 계층은 단 하나의 책임만을 가집니다.

🗄 익명 사용자 설계 (Designing the Anonymous User)

IP 주소만 저장하는 대신, 각 익명 방문자에게 유용한 분석 정보를 저장합니다.

class AnonymousUser(Document):
    fingerprint: str
    ip: str
...

이제 우리는 가입을 요구하지 않고도 다음 사항을 알 수 있습니다:

• 누가 방문했는지
• 얼마나 자주 방문했는지
• 언제 방문했는지
• 남용 (abusive) 행위를 했는지

🧠 비대한 라우트 대신 서비스 사용 (Services Instead of Fat Routes)

라우트는 더 이상 카운터를 증가시키지 않습니다.

대신 다음과 같이 수행합니다:

await anonymous_service.register_request(user)

이 단 한 줄의 코드 뒤에서는 다음과 같은 일들이 일어납니다:

• 일일 제한 (daily limit) 초기화
• 사용량 검증 (validate usage)
• 타임스탬프 (timestamps) 업데이트
• 카운터 증가
• MongoDB에 저장

엔드포인트 (endpoint)는 매우 작게 유지됩니다.

🛡 미들웨어 (Middleware)가 핵심 작업을 수행합니다

미들웨어 (middleware)가 전체 보안 파이프라인 (security pipeline)을 수행합니다.

identity = identity_service.resolve(request)

user = await anonymous_service.get_or_create(identity)
...

이제 모든 엔드포인트 (endpoint)는 검증된 익명 사용자 (anonymous user)를 자동으로 전달받습니다.

중복된 로직이 없습니다.

🚫 차단을 위한 준비

남용 (abuse)은 또 다른 서비스에서 처리합니다.

if await abuse_service.is_banned(identity.fingerprint):
    raise HTTPException(
        status_code=403,
...

나중에 이는 다음과 같이 확장될 수 있습니다:

• 관리자에 의한 수동 차단 (manual admin bans)
• 자동 차단 (automatic bans)
• 영구 차단 (permanent bans)
• 일시적 차단 (temporary bans)
• 남용 점수 임계값 (abuse score thresholds)

미들웨어 (middleware)를 변경하지 않고도 가능합니다.

🤝 LLM 라우터 (Router)와의 통합

제가 가장 좋아하는 부분 중 하나는 보호 계층 (protection layer)이 AI 제공업체 (AI providers)와 아무런 관련이 없다는 점입니다.

라우터 (router)가 다음 중 무엇을 선택하든:

• Groq
• OpenRouter
• Ollama
• Gemini

보안 계층 (security layer)은 정확히 동일하게 동작합니다.
그러한 분리가 아키텍처 (architecture)를 유연하게 유지해 줍니다.

📈 현재 흐름 (Current Flow)

이제 요청 (request)은 다음 경로를 따릅니다:

Request
    ↓
Identity
...

단순합니다.

예측 가능합니다.

확장하기 쉽습니다.

🎯 마치며

AI 애플리케이션을 구축하는 것은 프롬프트 (prompts)를 작성하거나 가장 빠른 LLM을 선택하는 것만이 아닙니다. 진정한 엔지니어링 과제는 제품이 성장함에 따라 유지보수가 가능한 백엔드 (backend)를 설계하는 것입니다.

익명 신원 계층 (anonymous identity layer)을 도입하고, 책임을 미들웨어 (middleware), 서비스 (services), 리포지토리 (repositories)로 분리하며, LLM 라우터 (LLM Router)를 완전히 독립적으로 유지함으로써, CVForbes는 이제 인증 (authentication), 구독 (subscriptions), 분석 (analytics), 그리고 향후의 AI 제공업체 (AI providers)들로 쉽게 확장할 수 있는 기반을 갖추게 되었습니다.

때때로 가장 훌륭한 기능은 사용자가 눈으로 보는 기능이 아닙니다. 보이지 않는 곳에서 모든 것을 안전하고, 확장 가능하며, 이해하기 쉽게 조용히 유지해 주는 아키텍처 (architecture)입니다.

공급업체에 종속되지 않는 (provider-agnostic) AI 아키텍처에 대한 저의 심층 분석을 놓치셨나요? 바로 여기서 확인하실 수 있습니다:
Groq, OpenRouter, Ollama, Gemini 사이를 자동으로 전환하는 공급업체에 종속되지 않는 AI 아키텍처를 구축한 방법.