장애가 나면 AI 에이전트가 달려들어 로그를 뒤지고 원인을 찾아주는 시대가 됐습니다. 그러면 다음 질문이 따라옵니다. "그 조사 보고서, 믿고 조치해도 되는 거야?"

AWS가 10월 9일에 내놓은 답이 Review입니다. 완료된 장애 조사에 대해 품질 평가를 매기는 기능입니다. 전체 유용성 판정 하나와 기준별 세부 평가를 돌려줍니다. 같은 날 서울을 포함한 4개 리전으로 서비스 지역도 넓어졌습니다. 조사하는 에이전트 위에 평가하는 에이전트를 얹은 셈인데, 구조를 뜯어보면 배울 점이 많습니다.

Review란 무엇인가: 조사를 다시 돌리지 않고 채점한다

공식 문서의 정의를 먼저 가져오겠습니다. Review는 완료된 조사의 기록(주어진 문제·수집한 근거·내린 결론)을 읽고 그 조사가 일을 얼마나 잘했는지를 재는 주문형 품질 평가입니다.

Review의 입력:  완료된 investigation 1건 (문제·근거·결론 기록)
Review의 출력:  ① 전체 판정 helpful / not helpful
               ② 기준별 판정 pass / fail / not applicable + 근거
Review가 하지 않는 일: 조사를 다시 실행하거나 원래 조사를 고치지 않음

"다시 돌리지 않는다"는 대목이 핵심입니다. Review는 조사를 고치는 게 아니라 조사 옆에 성적표를 붙이는 일입니다. 원본은 그대로 두고 평가만 나란히 놓으니, 나중에 "그때 조사가 왜 그렇게 판단했는지"를 감사(audit)할 때도 기록이 깨끗하게 남습니다.

언제 쓰냐고요? 문서가 꼽는 장면은 세 가지입니다. 근본 원인을 보고 조치할지 말지를 정할 때, 여러 조사를 비교할 때, 조사 결과를 믿고 의지하기 전에 빠르게 신뢰를 확인할 때. 즉 Review는 "읽을 것인가 말 것인가"가 아니라 "행동할 것인가 말 것인가"의 앞에서 쓰는 도구입니다.

5개 평가 기준: 무엇을 재는가

Review가 매기는 기준은 다섯 가지입니다. 표로 정리하면 이렇습니다.

기준 묻는 질문 판정
Scope alignment 보고된 문제에 집중했는가 pass / fail / na
Evidence grounding 결론이 수집한 근거에 뒷받침되는가 pass / fail / na
Completeness 관련 영역을 다루고 결론에 도달했는가 pass / fail / na
Environment impact 환경에 미치는 영향을 고려했는가 pass / fail / na
Accuracy 근본 원인이 연결된 티켓·인시던트의 기록과 맞는가 pass / fail / na

각 기준은 통과·실패·해당 없음 중 하나와 그 이유를 함께 내놓습니다. "해당 없음" 조건도 문서에 적혀 있습니다. 예를 들어 연결된 티켓이 없거나 티켓에 근본 원인이 기록돼 있지 않으면 Accuracy는 평가 불가입니다. 평가할 수 없는 걸 억지로 매기지 않고 비워두는 설계가 오히려 신뢰를 줍니다.

이 다섯 기준을 가만히 보면 AI 평가 체크리스트 글에서 다룬 구조와 겹칩니다. 근거의 정확성, 원인 분석의 타당성, 조치 가능성. 브리핑이 실무 액션으로 "근거·원인·조치 기준을 추가하라"고 한 것도 같은 맥락입니다. AWS가 기본값으로 깔아준 다섯 기준은 그대로 쓰고, 우리 팀 사정은 맞춤 설정으로 얹으면 됩니다.

Custom reviews: 채점 기준을 팀 입맛대로 바꾸기

기본 다섯 기준이 입에 안 맞으면 바꿀 수 있습니다. Grader 에이전트에 대한 에이전트 지시(agent instructions)를 Knowledge 페이지에서 정해주면 Review가 그 지시를 먼저 읽고 평가합니다. 고정된 스키마나 특수 문법은 없고, 평소 말로 "무엇을 검사할지"를 적으면 됩니다.

기본 동작: 지시에 적은 것만 기본값 위에 얹음 (안 적은 기준은 그대로)
  → Adjust: 기존 기준의 검사 포인트를 팀 기준으로 조정
  → Add:    새 기준을 기본 5개 위에 추가
  → Drop:   안 맞는 기본 기준은 빼기
깨끗이 시작: "처음부터 내 기준만 쓰라"고 명시하면 지시한 기준만 사용

적용한 뒤에 실행하는 Review부터 새 기준이 적용되고, 맞춤 기준도 기본 기준과 똑같은 형식(기준별 판정 + 전체 판정)으로 보고됩니다. 형식이 일정하니 대시보드에 쌓기도 쉽습니다.

여기서 보이는 패턴이 하나 있습니다. 평가 기준 자체를 코드가 아니라 자연어 지시로 관리한다는 것. 채점표가 바뀌면 배포가 아니라 문장 수정으로 대응합니다. Jev 글에서 다룬 "판단을 명시적으로 분리한다"는 아이디어가 운영 기능으로 굳어진 모양입니다.

품질 루프: 피드백·기억·Review가 맞물리는 구조

Review를 단독 기능으로만 보면 반쪽입니다. DevOps Agent에는 조사 품질을 다루는 장치들이 이미 몇 겹 깔려 있습니다.

과거 층: ① 조사 피드백 (6월) — 완료된 조사에 정확도 피드백 제출
        ② Reflections 기억 (9월) — 피드백에서 교훈을 기록해 같은 실수 방지
이번 층: ③ Review (10월) — 완료 조사의 시점별 품질 성적표

피드백과 Reflections가 "다음 조사를 낫게 만드는" 학습 루프라면, Review는 "이번 조사를 믿을지 정하는" 판정 루프입니다. 하나는 미래를 위한 기록이고, 하나는 현재의 행동 결정을 위한 것입니다. 두 루프가 맞물리면 운영 그림이 완성됩니다. 조치 전에 Review로 신뢰를 확인하고, 조치 후에 피드백으로 교훈을 남기는 것.

리전 확대: 서울이 들어왔고, 추론은 리전을 넘나든다

같은 날 발표된 다른 소식도 짚겠습니다. DevOps Agent가 미국 동부(오하이오), 아시아 태평양(서울), 유럽(파리), 유럽(스톡홀름) 4개 리전에 새로 들어왔습니다.

새 리전: Ohio · Seoul · Paris · Stockholm
주의: 서울의 Agent Space는 단일 지역이 아니라
      여러 AWS 리전에 걸쳐 추론을 라우팅
( 뭄바이·싱가포르·상파울루도 같은 패턴 — 6월 공지 )

서울 리전에서 쓸 수 있게 됐다는 소식과 "추론이 리전을 넘나든다"는 단서는 함께 읽어야 합니다. Agent Space를 서울에 둬도 모델 추론은 다른 리전에서 돌 수 있다는 뜻이라, 데이터가 어디서 처리되는지가 중요한 팀은 이 점을 확인하고 써야 합니다.

CodeBridge Mini Lab: 우리 팀의 조사 성적표 만들기

브리핑의 액션을 실험으로 바꿔보겠습니다. AI 장애 분석에 평가 기준을 붙이는 일입니다.

① 기본 Review 돌려보기:
   [ ] 완료된 조사 1건에 Review 실행
   [ ] 전체 판정(helpful/not helpful)과 5개 기준 판정 읽기
   [ ] fail이 나온 기준의 근거가 타당한지 사람 눈으로 확인
② Accuracy 연결 확인:
   [ ] 조사와 티켓·인시던트를 연결했는가 (연결 없으면 Accuracy는 na)
   [ ] 티켓의 근본 원인과 조사 결론이 일치하는가
③ 팀 맞춤 기준 얹기:
   [ ] Grader 지시에 팀 기준 1~2개 추가 (예: 조치 제안의 구체성)
   [ ] 안 맞는 기본 기준은 빼기 (drop)
   [ ] 다음 Review부터 새 기준이 적용되는지 확인
④ 루프 닫기:
   [ ] 조치 전 Review로 신뢰 확인 → 조치 후 피드백 제출
   [ ] 같은 알람의 다음 조사에서 Reflections가 반영됐는지 확인

이 표를 몇 주만 돌리면 "우리 팀 조사에서 자주 fail 나는 기준"이 보입니다. 그게 다음에 손봐야 할 runbook이자 스킬 문서입니다.

결론: 조사하는 에이전트만큼 채점하는 기준이 중요하다

한 줄로 정리합니다.

에이전트의 보고서를 그대로 믿는 팀과, 성적표를 붙여서 읽는 팀의 장애 대응은 다르게 쌓인다.

Review의 진짜 메시지는 "AI가 조사를 잘한다"가 아니라 "조사의 품질을 재는 일을 운영에 넣으라"는 것입니다. 기본 다섯 기준으로 시작하고, Grader 지시로 팀 기준을 얹고, 조치 전에는 Review로 확인하고 조치 후에는 피드백으로 남기는 것. 서울 리전 확대 소식과 함께 읽으면 마무리가 됩니다. 가까워진 인프라 위에서, 믿을 수 있는 조사만 골라 행동하는 운영을 만들 차례입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

반복되는 판단을 코드와 연결하고 자동 처리와 사람의 검토를 나누는 연습이 필요하다면, Laya 판단 모델과 Human-in-the-Loop 설계 과정이 이 글의 평가 기준 설계와 바로 이어집니다.