AI의 숨겨진 비용: 튜토리얼 코드에서 프로덕션 코드로의 전환

지난 1년 동안 웹 개발 튜토리얼을 시청했다면, 누군가가 "AI 기반" 앱을 만드는 것을 보았을 가능성이 높습니다. 강사는 환경 변수 파일에 자신의 OpenAI API 키를 붙여넣고, 간단한 fetch 요청을 작성하며, 10분 만에 앱이 마법처럼 텍스트를 생성해냅니다.

그것은 믿을 수 없을 정도로 쉬워 보입니다. 그래서 당신도 자신만의 버전을 만듭니다. localhost:3000에서 완벽하게 작동합니다. 이제 배포하여 세상과 공유할 준비가 되었습니다.

그때, 공포가 엄습합니다.

누군가 당신의 링크를 Reddit에 공유하면 어떻게 될까요? 사용자가 부주의하게 "생성(Generate)" 버튼을 50번 클릭하면 어떻게 될까요? 악의적인 봇이 당신의 공개된 엔드포인트(endpoint)를 찾아낸다면 어떻게 될까요?

AI API는 "토큰(token)"(처리된 텍스트의 양) 단위로 비용을 청구하기 때문에, 보호되지 않은 엔드포인트는 단순한 버그가 아니라 재정적 부채(financial liability)가 됩니다.

다음은 튜토리얼이 알려주지 않는 내용이며, 제가 AI 기능을 안전하게 배포하기 위해 백엔드 아키텍처(backend architecture)를 어떻게 조정해야 했는지에 대한 내용입니다.

문제점: 보호되지 않은 래퍼(Unprotected Wrapper)
표준적인 튜토리얼 구현은 본질적으로 보호되지 않은 래퍼입니다. 프론트엔드(frontend)가 Next.js/Node.js 백엔드(backend)와 통신하면, 백엔드는 요청을 LLM(대규모 언어 모델)으로 맹목적으로 전달합니다.

// ❌ 튜토리얼 방식 (프로덕션 환경에서 위험함)
export async function POST(req) {
  const { prompt } = await req.json();
...

해결책: 방어 계층 구축하기
이를 프로덕션(production)으로 옮기기 위해, 저는 AI API를 표준 데이터베이스 쿼리(database query)처럼 취급하는 것을 멈추고 귀중한 자원으로 취급하기 시작해야 했습니다. 제가 구현한 프로덕션 AI 아키텍처의 세 가지 기둥은 다음과 같습니다.

1. 엄격한 속도 제한 (Strict Rate Limiting)
요청이 애플리케이션의 로직에 닿기도 전에 속도 제한기(rate limiter)를 통과해야 합니다. Redis(또는 Upstash)와 같은 도구를 사용하면 특정 IP 주소나 사용자 ID(User ID)가 주어진 시간 범위 내에서 얼마나 많은 요청을 보냈는지 추적할 수 있습니다.

만약 사용자가 10초 안에 10개의 응답을 생성하려고 시도하면, 서버는 429 Too Many Requests 에러를 발생시키고 AI와의 통신을 거부합니다. 이는 봇과 버튼을 마구 누르는 사용자들을 즉각적으로 차단합니다.

2. 토큰 추적 및 할당량 (Token Tracking and Quotas)
속도 제한(Rate limiting)은 갑작스러운 사용량을 막아주지만, 한 달 동안 천천히 API 크레딧을 소진하는 사용자에게는 어떻게 대응할까요?

이를 해결하기 위해 저는 데이터베이스 스키마를 업데이트하여 모든 사용자에게 tokens_used 열을 포함시켰습니다. 성공적인 AI 요청이 완료될 때마다 API는 사용량 객체(usage object)를 반환합니다. 저는 이 객체에서 total_tokens를 추출하여 데이터베이스의 사용자 프로필에 추가합니다.

만약 그들의 사용량이 등급(예: 무료 등급 대 프리미엄)을 초과하면, 업그레이드하거나 월이 초기화될 때까지 접근이 차단됩니다.

3. 캐싱 (Caching) (같은 답변에 두 번 돈 내지 않기)
이것이 가장 큰 '아하!' 순간이었습니다. 어제 다른 사용자가