장애 조사 AI 에이전트, 운영에 넣기 전 정할 6가지

핵심 요약

• 오픈AI가 9월 10일 에이전트 API(Agents API) 를 공개 베타로 냈어요. 대표 시연은 운영 장애를 조사하는 에이전트였어요.
• 에이전트가 MCP로 도구에 붙어 런북(대응 절차서)을 따라 원인을 뒤지고, 증거와 권장 조치를 담은 보고서를 올려요. 공식 문서 예시에서 복구 조치는 승인을 요청해요.
• 그래서 도입 질문은 “에이전트가 고칠 수 있나”보다 “어디까지 맡기고 어디서 멈추게 하나” 예요.
• 자체 SaaS 4종을 운영하는 개발사 관점으로 사내 AI 에이전트를 장애 대응에 넣기 전 정할 6가지를 정리했어요.

📰 2026년 9월 16일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“새벽에 장애 나면 에이전트가 먼저 들여다보게 할 수 있을까요?”

에이전트 API가 나온 뒤로 운영팀에서 나오는 질문이에요. 할 수는 있어요. 다만 막상 붙여 보면 모델보다 우리 쪽 준비물이 먼저 모자라요. AI 에이전트 도입을 운영 업무부터 시작하려는 분들을 위해 그 준비물을 순서대로 적었어요.

발주 범위(무엇이 오픈AI 몫이고 무엇이 남는지)는 지난 글 오픈AI 에이전트 API, 발주 범위에서 무엇이 빠질까요에 정리했으니, 이번 글은 장애 대응이라는 한 업무에 좁혀서 봐요.

---

1. 오픈AI가 보여준 장애 조사 에이전트는 무엇을 하나요

에이전트 API는 코덱스(Codex)를 돌리던 실행 구조를 관리형 서비스로 연 거예요. 긴 세션, 맥락 자동 압축, 하위 에이전트 분업, 코드 실행 샌드박스를 오픈AI가 맡아요.

공개된 소개 영상과 문서에서 확인되는 장애 조사 흐름은 이래요.

단계	에이전트가 하는 일	확인된 출처
연결	MCP로 모니터링·배포 도구에 붙어요	오픈AI 소개 영상
조사	런북을 따라 원인을 찾아요	오픈AI 소개 영상
분업	배포·오류·의존성 분석을 하위 에이전트에 나눠요	소개 기사들이 옮긴 예시 코드
보고	증거와 권장 조치를 담은 공유용 보고서를 만들어요	오픈AI 소개 영상
복구	복구 조치는 승인을 요청해요	오픈AI 개발자 문서 예시

공식 외부 기준 — 위 내용은 오픈AI 개발자 문서와 9월 10일 공개 영상, 이를 보도한 MarkTechPost 기사(2026년 9월)를 기준으로 했어요. 하위 에이전트 구성은 문서 예시 코드라 실제 권장 설정인지는 확인되지 않았어요.

같은 날 GitHub도 4시간짜리 Copilot Day 라이브 영상을 올렸는데, 공개된 세션 목록에 에이전트 런타임과 SDK, 여러 모델을 골라 쓰는 BYOK(자체 키 연결) 주제가 들어 있었어요. 에이전트를 돌리는 바탕은 여러 회사가 앞다퉈 내놓는 중이에요. 달라지는 건 그 위에 우리 업무를 어떻게 얹느냐예요.

2. 첫째, 에이전트에게 맡길 단계를 정해요

장애 대응은 보통 네 토막으로 나뉘어요. 처음부터 네 토막을 다 맡기면 사고가 났을 때 누구 판단이었는지 흐려져요.

단계	처음 3개월 권장	이유
감지	기존 모니터링 그대로	이미 잘 도는 경보를 바꿀 이유가 없어요
조사	에이전트에게 맡김	로그·배포 이력 뒤지기는 시간이 들고 되돌릴 게 없어요
제안	에이전트가 초안, 사람이 확정	원인 판단이 틀려도 실행 전에 걸러져요
실행	사람 승인 필수	재시작·롤백은 서비스에 바로 영향이 가요

오픈AI 문서 예시가 복구 조치 앞에서 승인을 요청하는 것도 같은 선이에요. 조사는 맡기고, 손대는 일은 한 가지씩 풀어주세요.

3. 둘째, 런북을 에이전트가 읽을 수 있게 옮겨요

시연의 에이전트가 따른 건 런북이었어요. 이 문서가 없거나 담당자 머릿속에만 있으면 에이전트는 매번 다른 순서로 조사해요. 결과가 맞아도 다음번과 비교가 안 되고요.

사람용 런북을 에이전트용으로 옮길 때 저희가 확인하는 항목은 네 가지예요.

1. 확인 순서 — “배포 이력 → 오류 로그 → 외부 API 상태”처럼 순서를 번호로 적어요.
2. 판단 기준 — “오류율이 평소의 몇 배면 배포 원인 의심”처럼 숫자로 적어요. “많으면”은 에이전트가 해석을 못 해요.
3. 멈출 조건 — 결제·개인정보 테이블이 걸리면 조사를 멈추고 사람을 부른다는 식이에요.
4. 보고 양식 — 원인 가설, 근거 로그 위치, 확신 정도, 권장 조치를 칸으로 정해둬요.

런북이 없다면 최근 장애 3～5건을 되짚어 “그때 실제로 무엇부터 봤는지”를 적는 것부터 시작하면 돼요. 장애 대응 원칙 자체는 SaaS 운영하며 배운 장애 대응 3원칙에 따로 적어뒀어요.

4. 셋째, 권한은 읽기부터 열어요

조사 에이전트에 필요한 건 대부분 읽기 권한이에요. 로그, 지표, 배포 기록을 보는 데 쓰기 권한은 필요 없어요.

마침 9월 15일 Cloudflare가 비슷한 고민에서 나온 기능을 냈어요. 서버리스 앱(Workers)마다 따로 권한을 줄 수 있게 하면서 역할을 네 개로 나눴어요.

역할	할 수 있는 일
메타데이터 읽기 전용	지표·로그·트레이스만 봐요(코드는 못 봐요)
콘텐츠 읽기 전용	코드를 읽을 수만 있어요
편집자	배포와 설정 변경은 되지만 삭제는 안 돼요
관리자	생성·삭제·권한 관리까지 전부 돼요

Cloudflare는 발표에서 “에이전트가 필요 이상의 권한을 받았다는 이유만으로 운영 환경을 바꾸는 일은 원하지 않을 것”이라고 적었어요. 장애 조사 에이전트라면 첫 번째 역할이면 충분해요. 에이전트 전용 계정을 따로 두는 법은 AI 에이전트 계정 접근 범위를 참고해 주세요.

5. 넷째, 보고서가 무엇을 담아야 통과인지 정해요

“보고서를 올렸다”와 “보고서가 맞았다”는 달라요. 시험 기간에는 에이전트 보고서를 사람이 쓴 사후 분석과 나란히 놓고 이렇게 채점해 보세요.

• 원인 일치 — 사람이 최종 확정한 원인과 같았나요?
• 근거 추적 — 보고서에 적힌 로그 위치를 열었을 때 그 내용이 실제로 있었나요?
• 조사 시간 — 경보부터 보고서까지 몇 분 걸렸나요? 사람이 첫 원인 가설을 세운 시간과 비교해요.
• 헛짚기 — 무관한 원인을 확신 있게 적은 건수는 몇 건인가요?

두 번째 항목이 특히 중요해요. 근거가 열리지 않는 보고서는 새벽 3시에 믿고 움직일 수가 없거든요.

운영사 Tip — 저희도 자체 서비스 운영 자동화를 돌리면서 “상태가 확정된 실패에만 다시 실행한다”를 규칙으로 둬요. 성공인지 실패인지 모르는 상태에서 한 번 더 돌리면 같은 작업이 두 번 나가더라고요. 에이전트의 권장 조치도 같아요. “모름”을 “실패”로 읽고 복구를 실행하지 않도록 보고서에 확신 정도를 칸으로 받아두세요.

6. 다섯째, 비용과 데이터 조건을 확인해요

에이전트 API는 별도 이용료가 없고 모델 토큰, 도구 호출, 컨테이너 사용 시간만큼 내요. 편해 보이지만 장애 조사처럼 로그를 많이 읽는 일은 토큰이 쉽게 불어나요. 공식 발표에 장애 1건당 평균 비용은 나와 있지 않아서 직접 재야 해요.

확인할 것	정하는 방법
장애 1건 조사 비용	시험 기간 10건 안팎의 실제 청구액 평균
월 상한	1건 비용 × 월 평균 장애·경보 건수 × 여유분
세션 시간 상한	조사가 일정 시간 넘으면 멈추고 사람 호출
데이터 위치	공개 베타 기준 미국 데이터 저장만 지원, 데이터 무보관(ZDR) 미지원

마지막 줄은 국내 기업이라면 꼭 짚어야 해요. 로그에 고객 이메일이나 주문 정보가 섞여 있다면 에이전트에 넘기기 전에 가리는 단계가 필요해요. 오픈 뒤 AI 기능 비용이 어디서 늘어나는지는 AI 기능 운영 비용에 항목별로 정리했어요.

7. 여섯째, 직접 할 일과 맡길 일을 나눠요

앞의 다섯 가지 중 런북과 판단 기준은 발주사가 가장 잘 알아요. 우리 서비스에서 무엇이 평소와 다른지는 운영해온 사람만 적을 수 있거든요.

반대로 개발 범위로 넘어가는 지점도 분명해요. 모니터링·배포·DB 같은 사내 시스템마다 MCP 연결 서버와 인증을 만들고, 에이전트 전용 계정과 승인 흐름을 붙이고, 누가 시켰고 에이전트가 무엇을 봤는지 감사 로그를 남기는 일이에요. 연결할 시스템이 두세 개를 넘으면 공수가 빠르게 커져요. 사내 AI 에이전트를 여러 시스템에 붙이는 단계라면 이 구간을 운영 경험이 있는 쪽과 나눠 맡는 편이 빨라요.

에이전트가 들여다볼 운영 시스템부터 정리가 필요하다면, 장애 대응 흐름부터 같이 그려볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 만들고, 자체 SaaS 4종을 지금도 직접 운영하는 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔어요. 장애가 나면 새벽에 로그를 여는 쪽도 저희라서, 에이전트에게 무엇을 맡기고 무엇을 남길지 현장 기준으로 말씀드릴 수 있어요.

8. 자주 묻는 질문

장애 조사 AI 에이전트에게 복구까지 맡겨도 되나요?

처음에는 조사와 보고서까지만 맡기는 편이 안전해요. 오픈AI 공식 문서의 장애 대응 예시도 에이전트가 경보를 조사한 뒤 복구 조치는 승인을 요청하는 구조예요. 서버 재시작처럼 되돌리기 쉬운 조치부터 한 가지씩 승인 없이 넘기는 순서를 권해요.

사내 AI 에이전트를 붙이려면 런북이 꼭 있어야 하나요?

있어야 해요. 에이전트는 따를 절차가 흐릿하면 매번 다른 경로로 조사해서 결과를 비교하기 어려워요. 기존 대응 문서가 담당자 머릿속에만 있다면 최근 장애 3～5건을 되짚어 확인 순서와 판단 기준부터 글로 옮기는 게 첫 작업이에요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

호스팅 에이전트에 모니터링 도구 하나를 읽기 권한으로 붙여 보는 시험은 내부 인력으로도 시작할 수 있어요. 여러 사내 시스템을 MCP로 연결하고 권한 분리·승인 흐름·감사 로그를 갖춰 매일 돌리는 단계부터는 개발 범위가 커지니, 운영 경험이 있는 개발사와 나눠 맡는 쪽이 시행착오를 줄여줘요.

에이전트 API 비용은 어떻게 예상하나요?

API 자체 이용료는 없고 모델 토큰, 도구 호출, 컨테이너 사용 시간만큼 과금돼요. 장애 1건 조사에 드는 비용을 시험 기간에 재고, 월 장애 건수를 곱해 상한을 정해두세요. 공식 발표에 건당 평균 비용은 나와 있지 않아서 직접 재는 수밖에 없어요.

9. 마무리

에이전트 API 덕분에 장애를 조사하는 에이전트를 만드는 일은 훨씬 가벼워졌어요. 무거운 쪽은 여전히 우리 몫이에요. 어느 단계까지 맡길지, 무엇을 읽게 할지, 어떤 보고서를 믿을지요.

다음 장애가 나기 전에 한 가지만 해두세요. 지난 장애 한 건을 골라 “무엇부터 봤는지”를 번호로 적어보는 것. 그 한 장이 에이전트 런북의 첫 페이지가 돼요.

함께 보면 좋은 글

• 오픈AI 에이전트 API, 발주 범위에서 무엇이 빠질까요
• 장애 대응·모니터링, 발주 전에 숫자로 정할 6가지
• 기업 AI, 데이터는 어디에 두나