요즘 AI 기능을 붙인 서비스가 무너지는 방식은 비슷하다. 출시 초반에는 "생성 품질"로 박수를 받다가, 트래픽이 붙는 순간 지연과 비용이 동시에 폭주한다. 팀은 늦은 밤마다 모델을 바꿔 보고 프롬프트를 줄여 보지만, 다음 주면 같은 문제가 다시 온다. 문제의 본질은 모델 하나가 아니라 라우팅 정책 부재다.
작은 팀이 대형 플랫폼처럼 모든 요청을 정교하게 분류할 필요는 없다. 대신 요청의 성격에 따라 경로를 최소 세 갈래로 나누는 구조만 고정해도 운영 체감이 완전히 달라진다. 첫째는 즉시 응답이 필요한 실시간 요청, 둘째는 비용 민감한 대량 요청, 셋째는 품질 우선의 고부가 요청이다. 이 세 갈래를 구분하지 않으면, 긴 입력과 높은 추론 비용이 실시간 트래픽에 섞여 전체 지연을 끌어올리고, 결국 가장 중요한 사용자 경험이 무너진다.
1. "모든 요청 동일 처리"를 버리고, 라우팅 기준을 먼저 선언한다
많은 팀이 라우팅을 구현보다 나중 문제로 밀어둔다. 하지만 실제 운영에서 먼저 결정해야 하는 건 코드가 아니라 기준이다. "어떤 요청을 어떤 경로로 보내는가"가 문서로 고정되지 않으면, 팀원마다 임시 조건을 붙이고 지우는 식으로 정책이 붕괴한다. 라우팅 기준은 복잡할 필요 없다. 예를 들어 다음 네 가지 신호만으로도 충분하다.
- 입력 토큰 길이(짧음/중간/김)
- 사용자 등급(무료/유료/엔터프라이즈)
- 응답 지연 허용치(실시간/수 분 허용)
- 작업 유형(요약·분류/생성·기획/분석·추론)
이 기준의 목적은 "정확한 분류"가 아니라 "예측 가능한 자원 사용"이다. 즉, 95%의 요청을 빠르게 안정 경로로 보내고, 나머지 고비용 요청만 통제된 고성능 경로로 분리하는 구조가 핵심이다. 작은 팀이 감당 가능한 운영은 늘 예외를 줄이는 방향에서 나온다.
여기서 자주 놓치는 포인트가 하나 있다. 라우팅은 한 번 정하면 끝나는 룰셋이 아니라, 제품의 성장 단계와 함께 재조정되는 계약에 가깝다. 초기에는 "무료 사용자 긴 입력 제한"이 강하게 필요할 수 있지만, 유료 전환이 안정된 뒤에는 고부가 워크플로에 문을 넓혀야 한다. 그래서 라우팅 정책은 코드 주석이 아니라 운영 문서 + 버전 관리 대상이어야 한다. 언제, 왜, 어떤 기준을 바꿨는지 남겨야 다음 장애 때 원인을 되짚을 수 있다.
2. 토큰 예산은 기능별이 아니라 "요청 생애주기" 기준으로 쪼갠다
비용을 줄이기 위해 팀이 가장 먼저 하는 일은 출력 길이를 줄이는 것이다. 물론 즉각적인 효과는 있다. 하지만 진짜 비용 누수는 출력보다 입력과 재시도, 그리고 후처리 체인에서 더 크게 발생한다. 그래서 토큰 예산은 "기능" 단위가 아니라 "요청 생애주기" 단위로 설계해야 한다.
실무에서 유용한 방식은 요청 한 건을 네 개의 예산 버킷으로 나누는 것이다.
- 입력 정제 예산: 원문 축약, 중복 제거, 불필요 문맥 절단
- 1차 생성 예산: 기본 모델 응답 생성
- 재시도/복구 예산: 타임아웃·필터 차단 시 대체 경로 실행
- 후처리 예산: 포맷 정렬, 안전성 점검, 요약본 생성
이렇게 나누면 "왜 오늘 비용이 튀었는가"를 기능 이름이 아니라 단계별로 추적할 수 있다. 예를 들어 생성 예산은 안정적인데 재시도 예산만 급등하면, 모델 성능보다 네트워크 지연이나 타임아웃 설정을 먼저 의심해야 한다. 반대로 입력 정제 예산이 급증하면 업로드 형식 변화, 클라이언트 버전 배포, 외부 연동 포맷 깨짐 같은 원인을 빠르게 잡아낼 수 있다.
또 하나 중요한 건 "요청당 상한"과 "시간창 상한"을 동시에 두는 것이다. 요청당 상한만 있으면 대량 트래픽에서 누적 비용이 터지고, 시간창 상한만 있으면 소수 고비용 요청이 핵심 사용자 경험을 갉아먹는다. 보통은 사용자 등급별로 상한을 다르게 두되, 서비스 전체 비용 방어선(예: 10분 단위 총 예산)을 별도로 두는 이중 방어가 현실적이다. 작은 팀에게 운영 안정성은 정교함보다, 명확한 상한선에서 나온다.
3. 장애 시에는 "모델 교체"보다 "경로 축소"가 먼저다
야간 장애가 터지면 본능적으로 더 강한 모델, 더 큰 컨텍스트로 문제를 덮고 싶어진다. 하지만 실제로 서비스를 살리는 첫 대응은 반대 방향이다. 경로를 줄이고, 처리 단계를 단순화하고, 안정 구간으로 빠르게 수렴시키는 것이다. 이를 위해 평소에 페일오버 프로토콜을 짧게 정리해 두어야 한다.
예시로 쓸 수 있는 5단계는 아래와 같다.
- Detect: P95 지연, 재시도율, 에러코드 급등 감지
- Throttle: 저우선 트래픽 제한, 긴 입력 임시 제한
- Reroute: 고비용 경로 비중 축소, 저지연 모델로 우회
- Stabilize: 캐시 TTL 확장, 후처리 단계 간소화
- Recover: 트래픽 정상화 후 정책을 단계적으로 원복
핵심은 "완전 정상"을 한 번에 복원하려는 욕심을 버리는 데 있다. 먼저 핵심 기능만 지키고, 나머지는 임시 모드로 내려 사용자 체감 장애를 멈추는 것이 우선이다. 특히 구독형 제품에서는 몇 시간의 느린 복구보다 10분의 예측 가능한 성능이 이탈을 훨씬 적게 만든다.
그리고 복구 단계에는 반드시 기록 포맷을 포함해야 한다. 어떤 조건에서 스로틀을 걸었고, 어떤 지표를 보고 원복했는지 남기지 않으면 다음 장애 때 다시 감으로 대응하게 된다. 작은 팀의 경쟁력은 사람 수가 아니라 반복 가능한 운영 기억이다. 페일오버 로그가 쌓일수록 팀은 "당황해서 모델 바꾸는 조직"에서 "근거로 경로를 조정하는 조직"으로 바뀐다.
4. 다음 분기까지 바로 적용할 최소 운영 체크리스트
글로벌 빅테크의 운영 체계를 그대로 복제할 필요는 없다. 오히려 작은 팀에게 필요한 건 "오늘 적용 가능한 최소 체크리스트"다. 다음 네 가지를 고정하면, 지연과 비용이 동시에 흔들릴 때 버티는 힘이 빠르게 올라간다.
- 라우팅 기준 문서 1장: 입력 길이·등급·지연 허용치·작업 유형
- 요청 생애주기 예산표: 입력/생성/재시도/후처리 버킷 상한
- 페일오버 5단계 카드: 감지→스로틀→우회→안정화→원복
- 장애 회고 템플릿: 변경 시각, 영향 범위, 원복 조건, 재발 방지
결국 AI 운영의 본질은 놀라운 데모가 아니라 예측 가능한 시스템 행동이다. 사용자 입장에서 좋은 서비스는 "가끔 천재적인 답변"을 주는 서비스보다, "언제 써도 크게 무너지지 않는 서비스"다. 모델 혁신 속도는 계속 빨라지겠지만, 운영 원칙은 오히려 단순해질수록 강해진다. 지금 필요한 건 더 화려한 스택이 아니라, 경로를 나누고 예산을 지키고 복구를 반복하는 기본기다. 그리고 그 기본기는 작은 팀이 가장 먼저 가져갈 수 있는 경쟁력이다.
