AI DevEx Conference 2026 강연 리포트

연사: Sehr Moosabhoy 님 (Sentry / AI·머신러닝 팀 소프트웨어 엔지니어)

• 상류(GCP)의 매우 작은 장애가, Sentry 스스로 쌓아온 레질리언스(Resilience) 메커니즘에 의해 증폭되어, EU 리전 전체의 서비스 중단으로 발전했다. - 원인은 "블록리스트의 임계값 판정이 성공률을 보지 않고 생(raw) 실패 건수만으로 발화했기" 때문이었다.
  수정은 단 3줄이었다. - 기존의 모니터링 툴로는 "이용 가능한 리전이 없다"는 결과만 알 수 있었지만, 코드베이스와 텔레메트리(Telemetry) 모두에 연결된 AI 에이전트가 약 3분 만에 근본 원인에 도달했다.

현대의 시스템은 DB 계층, 영속화 계층, 네트워크 계층 중 어느 하나라도 반드시 외부 서비스에 의존하고 있다. 단독으로 완결된 프로덕트를 만드는 것은 사실상 불가능하며, 상류 프로바이더의 품질은 그대로 자사 서비스의 품질이 된다. 클라우드 스토리지가 다운되면 자사 프로덕트도 다운된다.

LLM 또한 이 "관리해야 할 연결" 중 하나에 불과하다. 다만 변화의 속도가 결정적으로 다르다.

이러한 불안정성이 이번 장애의 토양이 되었다.

대상: issue summary 엔드포인트 (Sentry로 들어오는 모든 에러에 요약을 부여하는 기능) -
증상: EU 리전에서 모든 호출이 실패 -
반환 에러: "해당 모델을 이용할 수 있는 리전이 없습니다"

먼저 확인한 것은 "해당 코드에 최근 변경 사항이 없다"는 점이었다. 그렇다면 상류의 문제라고 생각하는 것이 자연스럽다. 하지만 여기서 모순이 발생한다.

만약 Gemini의 모든 리전이 정말로 다운되었다면, 자사뿐만 아니라 업계 전체에서 알람이 울리고 있어야 한다.

즉, 상류의 문제를 자사 코드 어딘가가 증폭하고 있다. 문제는 어디서부터 찾을 것인가였다.

처음 봐야 할 파일은 하나로 좁혀졌다. 모든 프로덕트의 하루 100만 건 이상의 LLM 호출을 일괄 처리하는, 3,000행 이상의 클라이언트 파일이다.

• 수십 개의 모델 × 여러 프로바이더
• 모델별 파라미터, A/B 테스트, 프롬프트 엔지니어링 (Prompt Engineering)
• 인프라 관련해서만 월 평균 약 14번의 커밋 (가격 개정, 리전 변경, 레질리언스, 프로바이더 고유 파라미터)

유지보수량이 많기 때문에, 편집할 때마다 "복잡성이 증가하는 가운데 어떻게 확실성을 담보할 것인가"가 논점이 되어 왔다.

1회의 LLM 호출에 대해 3계층의 재시도(Retry) 경로를 가진다.

모델 A (글로벌) 실패
→ 모델 A (US) ← ① 다른 리전을 시도
→ 위 과정을 최대 재시도 횟수만큼 반복 ← ② 리트라이 (Retry)
...

모두 실패해야 비로소 호출이 실패로 처리된다. 결과적으로, 1회의 논리적인 호출이 6회 이상의 실제 호출로 부풀어 오른다.

짧은 시간에 동일 리전으로 트래픽이 집중되지 않도록, 이용 가능한 리전으로부터 쿼터(Quota)를 가중치로 하여 랜덤하게 선택한다. 단, 사용자 대상의 저지연(Low Latency)이 필요한 요청에서는 빠른 리전을 우선한다.

리전은 일시적인 장애로 다운될 수 있다. 그래서 리전별로 1분당 에러 수를 추적하여, 임계값을 초과하면 60초간 쿨다운(Cooldown) 시킨 후 재투입한다.

중요한 점은, 이 세 가지가 동시에 설계된 것이 아니라는 점이다.

• 특정 모델의 일시적 장애를 겪고 → 리트라이(Retry)를 추가
• 계속 다운되는 리전을 계속 호출하고 있었기에 → 블록리스트를 추가

애초에 이 파일은 "프로덕트에서 LLM을 테스트하는 실험"으로 시작되었고, 용도 확대에 맞춰 레질리언스를 사후에 강화해 왔다. 개별적인 판단은 모두 타당했지만, 추가된 한 줄 한 줄이 새로운 분기점이 되었고, 아직 보지 못한 케이스에 대비한 메커니즘이 층층이 쌓여갔다.

외부 서비스의 장애는 로컬에서 재현할 수 없다. 그래서 엔지니어가 취하는 수단은 "옵저버빌리티(Observability) 툴을 추가하는 것"이 된다.

도입되어 있던 것은 다음 세 가지다:

LangFuse: AI 호출의 상세 트레이스 (현재는 Sentry Observations로 대체) -
Sentry: 알람, 영향 범위, 에러, 메트릭스 (Metrics) -
Datadog: 인프라 레벨의 메트릭스 (Metrics)

하지만 장애 당일, 어떤 대시보드를 열어도 표시되는 것은 동일한 "사용 가능한 리전이 없음"뿐이었다. 알고 싶은 것은 "왜 그렇게 되었는가"였음에도 불구하고 말이다.

여기서 사내에서 개발 중이던 새로운 종류의 옵저버빌리티 (Observability) 툴인 Seer Agent를 도그푸딩 (Dogfooding)하기로 했다.

Seer Agent =

코드베이스에 대한 읽기 액세스와 모든 텔레메트리 (Telemetry)에 대한 연결성을 모두 갖춘 대화형 플랫폼. 에러, 알람, 수신 데이터를 하나의 창구에서 다룰 수 있다.

당시의 작업 가설은 "단순하게 레이트 리미트 (Rate Limit)가 걸려 있다"는 것이었다. 에이전트의 움직임은 다음과 같다.

• 지난 24시간 동안의 주요 에러를 취득하여 컨텍스트 (Context) 구축
• 레이트 리미트 및 쿼터 (Quota)를 언급하는 에러를 탐색 (가설 검증)
• 당초에는 지적되지 않았던 별도의 이슈 (Issue)까지 거슬러 올라가 조사
• 몇 분 만에 전체 상을 제시

판명된 영향 범위는 "EU 리전에서 Gemini 2.5 Flash API의 모든 호출이 레이트 리미트 상태"였다. 하지만 에이전트는 거기서 멈추지 않고, 여러 이슈를 시계열로 연결하여 진정한 근본 원인과, 그 판정을 수행하고 있는 해당 코드 라인까지 특정했다.

[상류] GCP의 소규모 인시던트 (Incident)
└ europe-west1 (PT 리전)이 504 Deadline Exceeded를 반환
↓ 1분 이내에 6건의 실패
...

※ PT = Provisioned Throughput (프로비저닝된 스루풋). europe-west1은 이 모델에서 보증 상한이 가장 높고, 서비스 레벨도 최상위인 리전이었다.

차단된 europe-west1으로의 호출 중 98%는 정상적으로 성공하고 있었다. 프로비저닝된 스루풋은 설계대로 트래픽을 흡수하고 있었던 것이다.

그럼에도 불구하고, 차단 목록 (Blocklist) 로직은 성공률은 전혀 보지 않고, 가공되지 않은 실패 건수만으로 발화하는 구현 방식이었다. 결과적으로 트래픽의 대부분을 건전하게 처리하던 가장 중요한 리전이 스스로 격리되면서 전체 시스템이 무너졌다. 타사에서 알람이 울리지 않았던 것도 당연한데, 상류의 장애 자체는 매우 소규모였기 때문이다.

단 3줄. "프로비저닝된 스루풋의 리전은 차단 목록에 등록하지 않는다".

엔지니어가 수동으로 찾아낼 수 없는 문제는 아니다. 충분한 문맥과 시간이 있다면 차단 목록 로직을 거슬러 올라가 성공률과 대조하고, GCP의 인시던트 타임라인과 수동으로 연결할 수 있었을 것이다. 그 "충분한 시간"이 약 3분으로 압축되었다는 것이 이번 사례의 핵심이다.

이 모두 온콜 (On-call) 엔지니어가 현재의 툴로 수행하고 있는 일이기는 하다. 다만 통상적으로는 방대한 상호 참조와 이를 연결할 도메인 지식 (Domain Knowledge)을 가진 인간이 필요하다.

덧붙여 강연자는 "Seer Agent만이 유일한 선택지다"라고 주장하는 것이 아니다. 요점은 AI를 코드 생성에만 집중시키느라, 옵저버빌리티라는 개발 프로세스의 핵심을 간과하고 있다는 지적에 있다.

소프트웨어 라이프사이클 (개발→디버깅→유지보수) 자체는 변하지 않는다. 변한 것은 루프의 속도와 형태이다.

• 구문적으로 올바른 코드 생성 비용이 급감 → 새로운 모델, 새로운 라이브러리, 새로운 툴 그룹의 채택 속도가 전례 없는 수준으로 상승
• 반면, AI 인프라 (모델 프로바이더, GPU 용량, 추론 엔드포인트)에 대한 부하는 지수 함수적으로 증가
• 최근 1년간 주요 프로바이더의 스테이터스 페이지 (Status Page)를 보면 신뢰성은 약간 하락하는 추세에 있음

새롭고 끊임없이 변화하는 에러 모드와 포맷 + 다소 신뢰성이 떨어진, 사전에 대비할 수 없는 상류 = 이번 사례와 같이 "상류의 에러가 내부의 문제를 증폭시키는" 장애의 상시화.

각 프로바이더(Provider)로의 호출마다 개별적인 페일오버(Failover) 로직을 갖는 것을 중단하고, 자사 호스트형 프록시 계층(Proxy Layer)으로 집약한다. 라우팅(Routing), 재시도(Retry), 폴백(Fallback), 차단 목록(Blocklist), 비용 추적, 인증을 프록시가 일원 관리한다.

본래 실험용으로 설계된 클라이언트에 신뢰성 로직을 사내에 계속 안고 있을 필요는 없다. 외부로 내보냄으로써, 유지보수에 사용하던 비용을 제품 개발로 돌릴 수 있다. 리팩터링(Refactoring)은 단기적으로는 비용이지만, 단순화는 장기적으로 보상받는다.

시스템 전체의 컨텍스트(Context)를 사전 계산하여, Seer Agent의 모든 대화에 주입하는 데이터 계층.

Knowledge Index: 사내 고유 용어를 이해시킴 (예: "attributes"는 일반 영단어가 아니라 제품 내의 개념)
Project Index: 서비스 의존 관계 그래프 + 텔레메트리(Telemetry) 인덱스. "왜 이 검색 도구의 호출이 느린가"에 대해 서비스의 연쇄를 따라 추론 가능
Repo Index: 어떤 정보가 어디에 있는지(피처 플래그와 코드는 다른 곳에 있다 등)를 요약

목표는 "질문의 위치를 파악하기 위한 쿼리"를 최소화하고, 답변 품질을 높이는 것.

사람이 이상 증가를 알아차리고, 대시보드를 열고, 이슈(Issue)를 보고 조사를 시작하기를 기다리지 않는다. 지속적으로 실행되는 자동 경로(Automated path)가 이미 깊은 문맥을 가진 패턴이나 에러 유형을 찾아내어, 사람이 가장 먼저 확인하기 전에 수정안을 제시한다.

목표는 우선순위 지정과 선제적 대응이다. 현재 인시던트(Incident)에 대한 대응 속도뿐만 아니라, 다음 인시던트를 어떻게 미연에 방지할 것인가.

레질리언스(Resilience)를 위한 코드도 역시 코드이다. 복잡성의 비용을 수반한다. 아무리 상류 장애에 대비해도 예상치 못한 일은 발생하며, 보호 계층을 한 층 추가하는 것이 장기적으로는 오히려 혼란을 초래할 수도 있다. 레질리언트한 시스템은 필요하지만, "코드를 추가하는 것이 최선책인가, 아니면 단순히 가장 손쉬운 방법일 뿐인가"를 유지보수 비용과 복잡성의 관점에서 계속해서 재평가해야 한다.
옵저버빌리티(Observability)에는 컨텍스트가 필요하다. 메트릭(Metrics), 로그(Logs), 알람(Alerts), 이슈(Issues)는 유용하지만, 통상 이들을 하나로 묶으려면 "무엇을 하고 있는지 아는 사람"이 필요하다. 시스템 전체의 컨텍스트, 코드, 텔레메트리를 실제로 파악한 연계 도구야말로 가치를 창출한다.
(Stretch Goal) 옵저버빌리티를 개발 사이클에 깊이 통합하여, 문제가 심각해지기 전에 그 자리에서 저지한다. 보아야 할 것은 즉각적인 대응 속도뿐만 아니라, 인시던트 건수 자체를 줄이는 것이다.