스테이징에선 완벽했던 AI 에이전트, 실전 투입 이틀 만에 터진 이유

스테이징 환경에서 가동률 99.2%.

응답 속도는 첫 토큰까지 280ms 아래. 눈 깜짝하는 게 150ms 정도거든요. 거의 그 속도예요. 테스트도 1,400개 케이스를 돌렸고요. 숫자만 보면 나무랄 데가 없죠.

근데 실제 고객사에 넣자마자, 이틀 만에 첫 사고가 터졌어요.

이게 참 묘한 지점이에요. 모델 성능은 멀쩡했거든요. 문제는 전혀 다른 데서 나왔어요. 오늘은 어떤 해외 엔지니어가 겪은 AI 에이전트 장애 회고를 풀어볼게요. AI 서비스를 실서비스에 올려본 사람이라면 남 얘기 같지 않을 거예요.

AI 에이전트 게이트웨이가 뭐길래

먼저 상황부터. 고객은 자산운용사였어요. 소속 어드바이저들이 음성 에이전트한테 "이 고객 포트폴리오 좀 불러줘", "자산 배분 어떻게 되지?" 물어보고 후속 미팅도 잡는 구조였죠.

여기서 잠깐. "게이트웨이"라는 말부터 짚고 갈게요.

게이트웨이(Gateway)를 이 엔지니어도 처음엔 그냥 "요청 배달부" 정도로 생각했대요. 사용자 질문이 오면 OpenAI든 Anthropic이든 어느 AI한테 넘겨주고, 실패하면 다시 시도하고, 끝. 딱 그 정도요.

건물 1층 안내데스크를 떠올리면 쉬워요. 손님이 오면 몇 층으로 가라고 알려주는 역할. 딱 그거라고 생각한 거죠.

근데 이게 완전히 틀린 생각이었어요.

기업용 서비스에서 게이트웨이는 안내데스크가 아니라 경비실 겸 관제실이거든요. 누가 들어왔는지, 몇 번 방문했는지, 뭘 하고 나갔는지 다 기록하고 통제하는 자리. 이게 포인트예요.

LLM API gateway architecture diagram

이틀 만에, 그리고 3주에 걸쳐 터진 4개의 사고

사고가 하나씩 터진 과정이 진짜 교과서 같아요.

첫날. 한 베테랑 어드바이저가 큰 금액 포트폴리오를 세 번 연달아 조회했어요. 하필 저녁 6시, 어드바이저들이 제일 몰리는 시간. 여기서 OpenAI 요청 한도(Rate Limit)에 걸렸죠. 한도 넘긴 요청은 전부 429 에러. 근데 에이전트가 쓸 만한 로그 하나 안 남겼어요. 결국 어드바이저의 고객이 4분간 전화를 붙잡고 있었죠.

한도 초과가 뭐냐고요? 놀이공원 인기 놀이기구에 시간당 태울 수 있는 인원이 정해진 거랑 똑같아요. 그 인원 넘으면 "죄송합니다 지금은 안 됩니다" 하고 돌려보내는 거죠. 근데 문제는, 몇 명이 돌아갔는지 아무도 안 세고 있었다는 거예요.

둘째 날. 컴플라이언스 담당자가 어제 그 사고 감사 로그를 뽑아달래요. 근데 없었어요. 추적용 흔적(trace)은 있는데, "누가 / 어떤 고객 정보로 / 무슨 요청을 / 에이전트가 뭐라 답했는지" 이걸 요청 단위로 남긴 로그가 없었던 거죠.

이게 왜 심각하냐. 금융권에서 감사 로그는 "있으면 좋은 것"이 아니라 법으로 있어야 하는 거거든요. 모니터링 부족이 아니라 규정 위반이에요. 성격이 완전히 다르죠.

둘째 주. 이번엔 운영 부사장이 "팀별로 비용 좀 나눠서 보여줘" 해요. 근데 뽑을 수 있는 게 달랑 전체 합계 숫자 하나. 어드바이저별로 누가 얼마 썼는지 태그를 안 달아놨거든요. 식당에서 다 같이 밥 먹고 "각자 얼마 나왔지?" 물었는데 총액만 찍힌 영수증 한 장 있는 격이에요.

셋째 주. 운영팀이 말투 좀 고치려고 프롬프트를 새 버전으로 바꿨어요. 3시간 뒤, 에이전트가 멀쩡히 답하던 질문을 거부하기 시작했죠. 근데 어느 시점부터 어떤 요청이 망가진 건지 알 수가 없었어요. 그 순간 어떤 프롬프트 버전이 돌고 있었는지 기록을 안 남겼거든요.

자, 여기서 반전. 이 사고 4개, 하나도 모델이 멍청해서 터진 게 아니에요.

전부 게이트웨이를 제대로 안 만들어서 생긴 일이었어요. 모델은 죄가 없었던 거죠.

429 too many requests error rate limit

그래서 게이트웨이는 뭘 해야 하나

이 엔지니어가 정리한 걸 보니, 기업용 AI 게이트웨이가 해야 할 일이 최소 다섯 가지예요.

첫째, 테넌트(tenant, 서비스를 쓰는 개별 고객·조직 단위)별 요청 한도 관리. 한 명이 폭주한다고 전체 서비스가 막히면 안 되잖아요. 둘째, 비용을 조직·팀·사용자 단위로 태깅. 두 달째면 반드시 "누가 얼마 썼냐" 질문이 들어오거든요. 셋째, 가드레일(guardrail, 위험한 답변을 걸러내는 안전장치). 금융권이면 "이거 사세요" 같은 특정 투자 권유는 매 응답마다 걸러야 하고요. 넷째, 요청 단위 감사 로그. 다섯째, 한 곳이 429 뜨면 자동으로 다른 AI로 넘기는 이중화. 첫날 4분 사고, 이것만 있었으면 안 터졌어요.

한마디로 게이트웨이는 "AI를 잘 부르는 법"이 아니라 "AI를 안전하게 운영하는 법"이었던 거예요.

도구는 뭘 골랐을까 — 상황별 선택 기준

이 엔지니어는 주말 하나를 통째로 갈아서 게이트웨이 도구들을 비교했어요. 솔직히 이 비교가 이 글에서 제일 실용적인 부분이에요.

직접 다 통제하고 싶다면 → LiteLLM. 오픈소스에 기능이 제일 완전해요. 테넌트별 한도, 비용 태깅, 장애 시 다른 모델로 넘기기까지 다 되죠. 대신 직접 서버 관리하고, Redis 붙이고, 감사 로그 구조도 손수 짜야 해요. 쿠버네티스 인프라가 이미 있는 팀한테 맞아요.

빨리 세팅하고 싶다면 → Portkey. 관리형이라 세팅이 빨라요. 가드레일이 설정 없이 바로 되고, 프롬프트 버전 관리에 되돌리기 UI까지 있죠. 이 엔지니어도 결국 시간에 쫓겨서 여기로 갔어요. 대신 규모 커지면 비용이 만만찮고요.

비용 분석이 핵심이면 → Helicone. 비용을 사용자별로 쪼개 보는 게 제일 강해요. 대시보드도 읽기 편하고. 대신 가드레일은 약한 편이라 그 부분은 따로 챙겨야 해요.

그냥 라우팅만 필요하면 → OpenRouter. 여러 모델로 넘기는 것만 깔끔하게 해요. 근데 테넌트별 한도도, 가드레일도 없어서 규제 산업엔 안 맞아요.

정리하면 이래요. 통제권이 중요하면 LiteLLM, 속도가 급하면 Portkey, 돈 추적이 우선이면 Helicone. "뭐가 제일 좋냐"가 아니라 "지금 내 상황에 뭐가 맞냐"로 골라야 하는 거죠.

솔직한 마무리 — 결국 발목 잡는 건 모델이 아니었다

이 회고에서 제일 와닿은 문장이 있어요.

"고객이 첫 달에 묻는 건 딱 네 가지다. 누가 / 언제 / 뭘 하면서 / 얼마를 썼는가."

게이트웨이가 이 네 질문에 답을 못 하면, 아직 실전 투입 준비가 안 된 거래요. 모델 성능은 대체로 멀쩡해요. 발목 잡는 건 늘 그 주변 인프라거든요.

저도 개인 서버에서 자동화 파이프라인 돌려보면서 비슷하게 느낀 게 있어요. 뭔가 만드는 것보다, "터졌을 때 뭐가 터졌는지 알 수 있게 해두는 것"이 훨씬 어렵고 훨씬 중요하더라고요. 로그 안 남겨두면 나중에 진짜 눈물 나거든요.

혹시 지금 AI 서비스를 실서비스에 올릴 계획이라면, 게이트웨이부터 설계하세요. 고객 만나고 나서가 아니라, 만나기 전에요. 다음 편에서는 이 감사 로그를 실제로 어떻게 남기는지, 요청 단위 추적 구조를 직접 짜보는 얘기로 이어가 볼게요.