50여 개 외부 웹의 장애를 복구하는 AI 에이전트의 단계 설계와 방어 장치 (2026-07)

외부 웹 50여 곳에 걸린 할인 적용 배치

모두의주차장에서 주차권을 결제하면, 백엔드는 주차장 정산 장비 업체(장비사)의 관리자 웹에 로그인해 차량번호에 할인권을 입력해야 합니다. 약 10년 전에는 사람이 했고, 스크립트를 거쳐 지금은 배치가 맡습니다. 문제는 장비사가 50여 곳이고 웹마다 생김새가 다르며, 직접 유지보수하는 사이트가 아니라 예고 없이 바뀐다는 점입니다.

2025년 한 해에 할인권 적용이 약 30만 건 실패했고 그중 16.5만 건이 환불로 이어졌습니다. 인지, 화면 확인, 코드 수정, 배포까지 평균 4시간이 걸렸습니다. 룰 베이스 자동화는 웹이 늘 같다는 전제에서만 성립하는데, AI는 스냅샷을 보고 어디를 눌러야 할지 그 자리에서 판단할 수 있어 런타임 판단이 필요한 이 일에 맞다고 보았습니다.

원인이 아니라 대응 순서로 나눈 에이전트

프레임워크는 LangGraph이고 StateGraph로 전체 흐름을 코드가 고정합니다. 브라우저 조작은 접근성 트리 기반 스냅샷을 주는 Playwright MCP로 붙였고 모델은 Gemini 3.1 Pro입니다. 복구 한 건의 LLM 비용은 몇백 원 수준이라고 합니다.

첫 설계는 DOM, Network, Policy처럼 장애 원인별로 에이전트를 나눈 것이었으나 실패했습니다. 원인을 알려면 이미 분석이 끝나 있어야 하므로 라우팅용 분류기가 따로 필요했고, 분류가 틀리면 엉뚱한 에이전트가 일했기 때문입니다. 최종안은 운영자가 실제로 밟는 순서를 옮겼습니다. login, search, discount, check, compare 에이전트가 이어지고, 단계가 실패하면 analyze 에이전트가 원인을 분석하며, 변경이 확정되면 마지막에 PR을 만듭니다. 정상일 때의 화면 구조와 API를 담은 장비사별 기준선 스키마 JSON이 compare의 기준이고, 브라우저 경로와 API 경로 중 어느 쪽을 탈지도 이 파일의 systemType이 정합니다. 분석 루프는 시도 3회, 누적 3분, 분류 확정(confidence 0.5 초과) 중 하나를 만족하면 멈춥니다.

LLM을 믿지 않는 세 축의 방어

원문은 LLM의 실수를 Action, Behavior, Context 세 축으로 나누고 축마다 코드 장치를 두었습니다.

Action은 못 하게 만드는 방식입니다. login 도구는 입력창과 버튼의 ref 세 개만 LLM에게 받고 아이디와 비밀번호는 클로저로 도구 안에서만 주입하므로, LLM은 비밀번호를 끝까지 모릅니다. check 에이전트에게는 읽기 전용 browser_snapshot 도구만 줍니다. 팝업은 wrapper가 자동 확인하되 재시도는 읽기 도구에만 허용해, 클릭 재시도로 할인권이 두 번 적용되는 사고를 막습니다.

Behavior는 자기 보고를 믿지 않는 방식입니다. discount의 성공은 별도의 check가 다시 확인하고, 선택한 차량번호는 코드가 요청 번호와 비교합니다. 근거가 부족한 분석은 일시적 오류로 분류하며, MCP 연결 끊김이나 재귀 한도 같은 에이전트 자신의 고장은 사이트 변경으로 보고하지 못하게 걸러냅니다. 응답은 Zod 스키마로 강제해 라우팅을 불리언과 숫자 비교로 처리하고, 테스트에서는 LLM을 스키마 형태의 mock으로 바꿉니다. Few-shot 예시에는 변경이 없는 경우를 반드시 넣고, confidence 값(0.95, 0.85, 0.75)으로 눈금을 새깁니다.

Context는 필요한 만큼만 보여 주는 방식입니다. 단계 에이전트는 매번 새로 만들어 이전 대화를 물려받지 않고, 로그는 단계별로 태깅하며, API 응답은 값을 지우고 구조만 비교합니다. 장비사 고유의 지식은 프롬프트가 아니라 기준선 스키마의 힌트에 두었습니다. 마지막 방어선은 사람입니다. 에이전트는 코드를 배포하지 않고 PR을 Draft로만 만듭니다. 할인권 재적용은 즉시 자동으로, 코드 수정은 사람 리뷰를 거치는 구성입니다.

PoC 결과와 운영에서 드러난 것

2주 PoC는 판매량이 가장 큰 장비사 한 곳에서 진행했고, Datadog에서 뽑은 실제 장애 186건을 저자 두 명이 라벨링해 대조했습니다. 원인 분류는 186건 모두 일치했고 고객 영향 차단 시간은 약 4시간에서 5분 이내로 줄었습니다. 5분은 할인권 재적용 기준이며, 장비사 한 곳과 표본 186건 안의 수치라고 원문이 밝혔습니다. 확대 배포 뒤 두 달여 동안 7,267건을 복구했습니다.

운영하며 보인 것도 있습니다. 이미 적용된 할인권에 다시 적용해 실패로 기록되는 “실패가 아닌 실패"처럼 배치 코드의 문제가 먼저 드러났고, 분류 정확도를 올리는 가장 빠른 길이 배치의 에러 메시지를 고치는 일인 적도 많았습니다. 장애가 없던 날에 compare가 대형 장비사의 실제 웹은 이미 v2 API를 쓰는데 배치는 v1에 머물러 있다는 사실을 찾아낸 일도 있었는데, 이 변경은 에이전트가 올린 Draft PR을 사람이 확인해 머지했습니다. 동시 장애에는 브라우저 수에 상한을 두는 세마포어로 OOM을 막고, 티켓당 시도를 1시간에 1회, 현장 단위로 1시간 cooldown을 걸었습니다. 원문의 결론은 코드로 풀 수 있는 일은 코드로 풀고 AI에는 AI만 할 수 있는 일을 맡기라는 것입니다.