몇 달 전, 저는 저의 첫 번째 "프로덕션 준비 완료(production-ready)" AI 애플리케이션을 출시했습니다.
그것은 아름답게 작동했습니다 — 실제 사용자들이 나타나기 전까지는 말이죠.
모델이 문제는 아니었습니다. 답변은 좋았고, 검색 (retrieval)은 견고했으며, 프롬프트 (prompts)는 정교했습니다. 하지만 앱은 느리고, 불안정하며, 비용이 많이 드는 것처럼 느껴졌습니다. 어떤 요청은 15초가 걸렸습니다. 다른 요청들은 그냥 타임아웃 (timeout)이 되었습니다. 약간의 트래픽 급증이 발생하자 몇 개의 오래 걸리는 호출 (calls) 뒤로 모든 것이 밀려버렸습니다. 설명할 수 없는 이유로 비용이 서서히 올라갔습니다.
저의 첫 번째 본능은 LLM을 탓하는 것이었습니다.

제가 틀렸습니다.

진짜 문제는 제가 분산 시스템 (distributed system)을 구축해야 했을 때 AI 프로젝트를 구축하고 있었다는 점이었습니다.
그 관점의 변화가 제가 현재 AI 애플리케이션을 구축하는 방식의 모든 것을 바꾸어 놓았습니다.

대부분의 AI 튜토리얼은 잘못된 문제를 해결하고 있습니다

YouTube나 X를 스크롤하다 보면 다음과 같은 끝없는 콘텐츠를 발견할 것입니다:

• 더 나은 프롬프트 (prompts)
• 더 나은 모델 (models)
• 더 나은 임베딩 (embeddings)
• 더 나은 RAG 파이프라인 (RAG pipelines)

모두 유용합니다. 하지만 실제 사용자가 나타나면 그 중 어느 것도 중요하지 않게 됩니다.
왜냐하면 사용자들은 당신이 GPT-4, Claude, 또는 어떤 미세 조정된 (fine-tuned) 오픈 소스 모델을 실행하고 있는지에 관심이 없기 때문입니다. 그들은 정확히 세 가지에만 관심이 있습니다:

• 빠른가?
• 항상 작동하는가?
• 신뢰할 수 있다고 느껴지는가?

이 중 그 어느 것도 프롬프트 엔지니어링 (prompt engineering) 문제가 아닙니다. 그것들은 백엔드 엔지니어링 (backend engineering) 문제입니다.

LLM은 훨씬 더 큰 시스템 내의 단 하나의 노드 (node)일 뿐입니다

대부분의 사람들은 AI 앱을 단순한 직선으로 상상합니다: 사용자가 메시지를 보내면, LLM이 응답합니다. 실제로 그 요청은 API 게이트웨이 (API gateway), 인증 (authentication), 요청 큐 (request queue), 병렬로 실행되는 검색 엔진 (retrieval engine) 및 캐시 확인 (cache check), 프롬프트 빌더 (prompt builder), LLM 자체, 후처리 (post-processing), 그리고 마지막으로 사용자에게 돌아가는 스트리밍 응답 (streamed response)을 거칩니다. 모델은 훨씬 더 긴 파이프라인 (pipeline) 속의 단 하나의 박스일 뿐이며 — 그 체인의 나머지 모든 것들이 실제로 당신의 앱이 프로덕션 등급 (production-grade)으로 느껴질지 여부를 결정합니다.

큐 (Queues)가 당신의 시스템을 유지시킵니다

500명의 사용자가 동시에 "제출" 버튼을 누르는 상황을 상상해 보세요. 만약 모든 요청이 LLM API로 직접 발사된다면, 당신은 아침 식사로 Rate Limits (속도 제한)를 먹게 될 것입니다.

해결책: 요청을 큐 (Queue)에 넣고, 제어된 워커 (Worker) 풀이 이를 처리하도록 하세요.

요청 (Requests) → 큐 (Queue) → 워커 (Workers) → LLM

큐를 사용하면 다음과 같은 이점을 얻을 수 있습니다:

1. 트래픽 급증 시의 회복 탄력성 (Resilience)
2. 실패한 작업에 대한 용이한 재시도 (Retries)
3. 오래 걸리는 작업 (Long-running tasks)의 합리적인 처리
4. 의존하고 있는 외부 API에 대한 보호

큐를 건너뛴다면, 당신의 시스템은 단 한 번의 좋지 않은 오후만으로도 무너질 수 있습니다.

캐싱 (Caching)은 작은 모델을 쓰는 것보다 더 많은 돈을 아껴줍니다

대부분의 AI 앱은 똑같은 몇 가지 질문에 반복해서 답변합니다:

"이 문서를 요약해 줘."
"우리의 환불 정책은 뭐야?"
"면접 질문을 생성해 줘."

매번 LLM을 새로 호출하는 것은 그저 돈을 태우는 것과 같습니다.

요청 (Request) → 캐시 히트 (Cache hit)? → 예: 즉시 반환
→ 아니오: LLM 호출 → 결과 저장

단 20%의 캐시 히트율만으로도 비용과 지연 시간 (Latency)을 유의미하게 줄일 수 있습니다. 이는 화려하지는 않습니다. 하지만 동일한 API 호출에 대해 만 번의 비용을 지불하는 것 또한 화려하지는 않습니다.

스트리밍 (Streaming)은 느린 모델을 즉각적인 것처럼 느끼게 합니다

응답을 생성하는 데 12초가 걸린다면, 백엔드 표준으로는 12초가 괜찮을지 몰라도 사용자가 12초 동안 빈 화면을 응시하게 만드는 것은 시스템이 고장 난 것처럼 느껴지게 합니다.
대신 스트리밍 (Stream)을 사용하세요. 첫 번째 토큰 (Token)이 약 1초 안에 나오고, 나머지가 생성되는 것을 지켜보게 하는 것입니다.
전체 생성 시간은 변하지 않습니다. 하지만 인지된 속도 (Perceived speed)는 극적으로 변합니다. 때로는 UX가 원시 처리량 (Raw throughput)보다 중요합니다.

배치 (Batching)는 조용히 비용을 절감합니다

100개의 문서에 대해 임베딩 (Embeddings)을 하나씩 생성하는 것은 100번의 API 호출을 의미합니다. 대신 이를 하나의 요청으로 배치 (Batch) 처리하세요.
네트워크 오버헤드 (Network overhead)는 줄어들고 처리량 (Throughput)은 향상됩니다. 수년간 분산 시스템 (Distributed systems)을 지탱해 온 동일한 원리가 AI 워크로드 (Workloads)에서도 똑같이 작동합니다.

재시도 (Retries)는 단순히 끈질긴 것이 아니라 똑똑해야 합니다

API는 실패합니다. 네트워크는 깜빡거립니다. Rate Limits는 발생합니다. 즉시 재시도하는 것은 고전 중인 시스템을 더 세게 때리는 것과 같습니다.
대신 지수 백오프 (Exponential backoff) — 1초, 2초, 4초, 8초 —를 사용하세요. 그러면 당신의 시스템은 공짜로 훨씬 더 강력한 회복 탄력성을 얻게 됩니다.

로깅(Logging)보다 관측성(Observability)이 중요합니다

실패(Failures)만을 기록하는 것은 관측성(Observability)이 아닙니다. 당신이 실제로 답을 얻고자 하는 질문은 다음과 같습니다:
어떤 프롬프트(Prompts)가 가장 느린가?
어떤 모델이 비용을 가장 많이 발생시키는가?
실패율(Failure rate)은 얼마인가?
어떤 고객이 토큰(Tokens)을 가장 많이 소모하는가?
지연 시간(Latency) 중 검색(Retrieval)과 LLM 자체에서 발생하는 비중은 각각 얼마인가?
어떤 프롬프트 버전이 실제로 더 나은 성능을 보이는가?
관측성이 없다는 것은 추측만 하고 있다는 뜻입니다. 관측성이 있다면 최적화(Optimizing)를 할 수 있습니다.

결함 허용(Fault Tolerance)이 모델 정확도보다 중요합니다
만약 당신이 사용하는 주력 LLM 제공업체가 다운된다면, 당신의 앱도 함께 다운됩니까 — 아니면 조용히 다른 모델로 장애 조치(Failover)를 수행합니까?

GPT 호출 → 성공? → 예: 응답 반환
→ 아니오: 다른 모델로 폴백(Fall back) → 응답 반환

사용자는 좋은 답변을 얻는 것에 관심이 있습니다. 그들은 어떤 모델이 그 답변을 생성했는지 신경 쓰지 않으며 — 대부분 알지도 못합니다.

AI 엔지니어들은 조용히 백엔드 엔지니어(Backend Engineers)로 변모하고 있습니다
1년 전에는 프롬프트 엔지니어링(Prompt engineering)이 갖춰야 할 기술처럼 느껴졌습니다. 오늘날 실제 프로덕션 AI 시스템을 출시하는 팀들은 대부분의 시간을 다음 항목에 할애합니다:

• 지연 시간 (Latency)
• 동시성 (Concurrency)
• 캐싱 (Caching)
• 재시도 (Retries)
• 모니터링 (Monitoring)
• 속도 제한 (Rate limits)
• 확장 (Scaling)
• 분산 워커 (Distributed workers)

모델은 인프라(Infrastructure)가 되어가고 있습니다. 그 모델을 둘러싼 엔지니어링이 실제 차별화 요소가 되고 있습니다.

마지막 생각

이 교훈을 내면화하는 데 시간이 좀 걸렸지만, 원리는 간단합니다. AI 제품을 만드는 것은 가장 똑똑한 모델을 선택하는 것이 아닙니다. 수천 명의 실제 사용자가 의존할 때 빠르고, 신뢰할 수 있으며, 저렴하게 유지되는 시스템을 설계하는 것입니다.

프롬프트는 계속 개선될 것입니다. 모델은 계속 저렴해질 것입니다. 컨텍스트 윈도우(Context windows)는 계속 커질 것입니다.

하지만 큐(Queues), 캐싱(Caching), 재시도(Retries), 스트리밍(Streaming), 관측성(Observability), 그리고 결함 허용(Fault tolerance)은 수십 년 동안 분산 시스템(Distributed systems) 문제를 해결해 왔으며, 이제 조용히 모든 진지한 AI 애플리케이션의 실제 기반이 되고 있습니다.

지금 AI를 배우고 있다면, LLM만큼이나 백엔드 엔지니어링(Backend engineering)에도 많은 시간을 투자하세요. 장애(Outage)가 발생한 새벽 2시의 미래의 당신이 고마워할 것입니다.