AI 에이전트 모니터링은 대시보드 숫자를 늘리는 일이 아닙니다. 이상 실행 한 건이 생겼을 때 입력, 도구 호출, 결과, 사람 판정, 다음 조치를 같은 실행 ID로 다시 설명할 수 있게 만드는 일입니다. Microsoft는 생성형 AI와 에이전트 시스템이 확률적으로 행동하므로 기존 관측 방식을 로그·메트릭·트레이스와 평가·거버넌스 신호까지 확장해야 한다고 설명합니다. S1 Morrow의 해석으로는 작은 B2B 파일럿에서 먼저 필요한 것은 거대한 관측성 플랫폼이 아니라, 한 건의 문제가 생겼을 때 팀이 추측 없이 같은 사건을 확인할 수 있는 최소 기록입니다.
예를 들어 견적 문의를 분류하는 자동화가 “긴급” 태그를 잘못 붙였다고 하겠습니다. 담당자는 결과만 보면 모델이 틀렸다고 말하기 쉽습니다. 그러나 실제 원인은 다를 수 있습니다. 입력 PDF가 불완전했을 수 있고, 검색 도구가 오래된 가격표를 가져왔을 수 있으며, 지시문이 새 분류 기준으로 바뀌었을 수 있고, 사람이 승인 단계에서 잘못된 상태를 선택했을 수도 있습니다. 결과 하나만 저장하면 이 경로를 다시 확인할 수 없습니다. 반대로 실행 ID가 연결된 최소 기록이 있으면 “어느 단계에서 무엇이 달라졌는가”를 조사할 수 있습니다.
먼저 답: 실행 한 건을 다시 설명할 수 있어야 합니다
모니터링에서 가장 먼저 정할 것은 지표 이름이 아니라 조사 질문입니다. “왜 이 고객에게 잘못된 답변이 나갔는가?”, “왜 승인 대기열이 어제부터 길어졌는가?”, “왜 같은 입력에서 다른 결과가 나왔는가?” 같은 질문입니다. 이 질문에 답하려면 한 건의 실행을 복원할 수 있어야 합니다. Microsoft는 AI 시스템 관측에 토큰 사용량, 지연 시간, 오류율, 도구 호출량 같은 신호와 평가·보안 시나리오의 원격 측정을 연결할 수 있다고 설명합니다. S1 하지만 이 글은 특정 수치의 목표나 도구 도입을 권하지 않습니다.
Morrow의 해석: 초기 운영 기록은 아래 여섯 칸이면 시작할 수 있습니다. 한 칸은 실행을 묶고, 두 칸은 입력과 도구를 설명하며, 나머지 세 칸은 결과와 사람의 결정을 연결합니다. 모든 원문을 저장하는 것이 아니라, 조사에 필요한 최소 맥락을 남기는 것이 핵심입니다.
| 최소 기록 | 적을 내용 | 조사 때 답하는 질문 |
|---|---|---|
| 실행 ID와 시각 | 한 요청의 고유 번호, 시작·종료 시각 | 어떤 사건을 다시 보는가? |
| 입력 분류 | 업무 유형, 자료 출처, 민감도 표지 | 어떤 종류의 요청이었는가? |
| 사용한 구성 | 모델·지시문·도구 버전 식별자 | 어느 설정에서 일어났는가? |
| 도구 사건 | 호출 성공·실패, 대상 유형, 반환 상태 | 어느 외부 단계가 달라졌는가? |
| 결과와 상태 | 초안·승인 대기·중단·완료 | 결과가 어디까지 진행됐는가? |
| 사람 판정·다음 조치 | 승인·수정·인계·중단, 담당자 | 누가 어떤 이유로 이어받았는가? |
이 표는 개인 정보나 고객 문서 원문을 무제한 수집하라는 지침이 아닙니다. 기록 보존 범위, 접근 권한, 마스킹, 보존 기간은 조직 정책과 실제 위험에 맞게 정해야 합니다. NIST의 생성형 AI 프로필은 위험 관리가 조직의 목표, 위험 허용도, 자원과 맞아야 한다고 설명합니다. S3 “나중에 필요할 수 있으니 모두 저장하자”는 판단은 오히려 새 위험을 만들 수 있습니다.
결과가 아니라 실행 경로를 봅니다
AI 에이전트는 한 번의 문장 출력보다 여러 단계의 행동으로 업무를 마칠 수 있습니다. 문서를 읽고, 검색을 하고, 도구를 호출하고, 중간 결과를 바꾸고, 사람에게 넘길 수 있습니다. Anthropic은 에이전트 평가가 입력에 대한 출력에 판정 로직을 적용하는 시험이며, 실행 기록이나 결과에 코드·모델·사람 기반 판정을 조합할 수 있다고 설명합니다. S2 이 설명은 운영자가 “최종 답변이 좋아 보이는가”만 보지 말고, 업무 결과에 이르는 경로를 확인해야 한다는 실무적 이유가 됩니다.
조사는 사건의 실행 ID와 원래 요청을 찾는 데서 시작합니다. 이어 입력의 출처와 유형, 실제 도구 호출의 성공·실패·시간 초과, 당시 모델·지시문·도구 버전, 결과가 멈춘 상태와 사람 판정을 차례로 봅니다. 이 순서는 원인을 단정하는 알고리즘이 아니라, 팀이 같은 증거를 보고 이야기하는 순서입니다.
예를 들어 고객 문의 분류가 잘못된 한 건을 조사한다고 가정해 보겠습니다. run-2026-08-01-0142라는 실행 ID에서 첨부 PDF의 표 추출이 실패했고, 분류 도구는 성공을 반환했지만 사람은 “견적 항목 누락”으로 승인 대기에 돌려보냈다고 기록합니다. 이때 팀은 모델 전체의 문제라고 결론 내리기보다, 같은 입력 유형의 추출 상태와 그 도구 버전을 먼저 표본으로 확인합니다. 원문을 로그에 복사하지 않아도 실행 ID, 입력 유형, 실패 상태, 사람 판정으로 다음 수용 사례를 만들 수 있습니다. 이는 설명을 위한 예시이며 실제 고객 사례나 성과 주장은 아닙니다.
이 표의 목적은 책임을 특정 사람이나 모델에 돌리는 것이 아닙니다. 재현 가능한 사건 기록을 만들고, 다음 수정의 가설을 하나로 좁히는 것입니다. 같은 유형의 사건이 반복되면 정상·예외·금지 사례를 추가할 수 있습니다. 한 번의 특이 사례를 보고 모든 자동화를 넓게 바꾸면, 무엇이 좋아졌거나 나빠졌는지 알기 어렵습니다.
로그에는 원문보다 업무 맥락이 먼저입니다
“AI 에이전트 로그를 남긴다”는 말은 종종 대화와 문서를 전부 저장하는 일로 오해됩니다. 하지만 운영에 필요한 정보와 보관하면 안 되는 정보는 다릅니다. 담당자는 보통 “어떤 업무였는가”, “어떤 출처였는가”, “어떤 도구가 어떤 상태를 돌려줬는가”, “사람이 왜 수정했는가”를 알아야 합니다. 이 정보를 구조화하면, 민감한 원문을 복사하지 않고도 많은 조사를 시작할 수 있습니다.
예를 들어 고객 문의 자동화에서는 ‘고객 A의 전체 이메일’을 남기기보다 문의-견적, 외부 첨부 있음, 개인정보 포함 가능, CRM 조회 성공, 답변 초안→승인 대기, 승인자가 가격 조건 누락으로 수정 같은 사건 표지가 더 유용할 수 있습니다. 필요한 원문은 권한이 있는 시스템에서 참조하도록 하고, 운영 로그에는 링크 또는 제한된 식별자를 남기는 방식을 검토할 수 있습니다. 이 선택은 조직의 데이터 정책과 시스템 구조에 따라 달라집니다.
Microsoft는 관측성 자료의 보존·접근 통제가 개인정보 최소화, 보존 요구, 접근 통제, 암호화와 위험 평가에 맞아야 한다고 설명합니다. S1 따라서 파일럿의 기록 설계는 운영 책임자, 보안·개인정보 담당자, 실제 업무 담당자가 함께 확인해야 합니다. 이 글은 그 결정을 대신하지 않습니다. 다만 ‘조사 가능성’과 ‘불필요한 수집’ 사이의 선택을 드러내는 데 목적이 있습니다.
알림은 즉시 조치가 아니라 검토 시작 신호입니다
오류율, 지연 시간, 도구 실패, 승인 대기 시간 같은 신호를 관찰할 수 있습니다. 그러나 신호가 하나 올랐다고 자동으로 모델을 바꾸거나 권한을 넓히는 것은 바람직하지 않습니다. 알림은 “무엇을 조사할지”를 알려 주는 시작점입니다. 운영자가 먼저 확인할 항목은 업무 영향입니다. 실제 고객·계약·금전·기한에 영향을 주었는지, 또는 내부 초안 단계에서 멈췄는지에 따라 대응의 우선순위가 달라집니다.
Morrow의 해석으로 주간 검토에서는 네 가지 질문만 먼저 볼 수 있습니다. 첫째, 같은 실행 유형에서 반복된 중단 사유가 있는가? 둘째, 사람이 자주 고치는 결과가 특정 입력·도구·버전과 연결되는가? 셋째, 승인 대기 시간이 길어진 구간이 있는가? 넷째, 수기 대기열이 실제로 소유자에게 인계되고 닫히는가? 이 질문은 성과를 보장하는 KPI가 아니라, 다음 평가 사례와 변경 가설을 고르는 자료입니다.
| 관찰 신호 | 처음 할 일 | 피해야 할 반응 |
|---|---|---|
| 도구 실패 증가 | 실행 ID를 표본으로 묶어 대상·상태 확인 | 전체 자동화를 즉시 재시도 |
| 승인 대기 증가 | 담당자·업무 시간·필요 맥락 확인 | 승인 단계를 삭제 |
| 수정 사유 반복 | 동일 유형 사례를 평가 세트에 추가 | 프롬프트를 여러 줄 동시에 수정 |
| 예외 인계 증가 | 입력 분류·권한·중단 기준 확인 | 대기열을 자동 완료 처리 |
모니터링과 평가는 같은 일을 하지 않습니다
모니터링은 운영 중 실제로 무슨 일이 일어났는지 보게 하고, 평가는 변경 전후에 정한 사례에서 어떤 결과가 나오는지 보게 합니다. 둘은 경쟁하지 않습니다. Anthropic은 실제 운영에서만 문제를 잡으면 반응적인 순환에 빠질 수 있고, 평가는 문제가 사용자에게 영향을 주기 전에 행동 변화를 보이게 할 수 있다고 설명합니다. S2 Morrow의 해석으로는 운영에서 발견된 사건을 익명화하고 업무 규칙에 맞게 정리해 다음 수용 사례로 넣는 연결이 중요합니다.
예를 들어 일주일 동안 ‘외부 첨부가 있는 문의’에서만 분류 오류가 반복됐다면, 그것을 무조건 모델 결함으로 부르지 않습니다. 첨부 형식, 추출 도구 상태, 입력 분류, 사람이 기대한 결과를 나눠 보고, 한 가지 가설을 세웁니다. 그 뒤 해당 조건의 사례를 평가표에 넣어 다음 변경 전후에 다시 확인합니다. AI 에이전트 평가 방법은 이 수용 사례를 만드는 방법을, AI 자동화 파일럿 KPI은 처리시간·수정·오류·승인 지연·예외를 업무 단위로 보는 법을 다룹니다.
첫 주 최소 운영 체크리스트
- 한 업무 실행을 구분하는 실행 ID를 정했는가?
- 입력 원문이 아니라 업무 유형·출처·민감도 표지를 남길 수 있는가?
- 모델, 지시문, 도구 연결의 식별자를 실행과 연결하는가?
- 도구 호출의 성공·실패·시간 초과 상태를 확인할 수 있는가?
- 결과가 초안, 승인 대기, 수기 인계, 완료 중 어디에 있는지 보이는가?
- 사람이 수정하거나 중단한 이유를 짧은 업무 언어로 남기는가?
- 로그 접근 권한·보존 기간·원문 참조 방식을 담당자와 확인했는가?
- 반복 사건을 다음 평가 사례에 반영할 검토 주기가 있는가?
이 체크리스트를 충족했다고 해서 관측성이 완성됐다고 말할 수는 없습니다. 운영 범위가 넓어지고 도구가 늘어나면 조사·보안·비용·보존의 요구도 달라집니다. 그러나 작은 파일럿에서 최소 기록을 운영해 보지 않고 대시보드만 크게 만들면, 실제 조사 흐름이 맞는지 알기 어렵습니다.
Morrow의 관점: 관찰 가능한 자동화만 넓힙니다
Morrow는 자율 실행의 양을 약속하지 않습니다. 승인과 복구를 포함한 제한된 운영 흐름을 먼저 검증하는 접근을 택합니다. AI 에이전트 운영 체계가 책임자·변경·인계를 다룬다면, 이 글은 그 체계에서 실제 사건을 어떻게 다시 설명할지를 다룹니다. 관측성은 누군가를 감시하는 장치가 아니라, 의심스러운 결과를 사람에게 정확한 맥락과 함께 인계하고 다음 변경을 작게 만드는 운영 기반입니다.
FAQ
작은 팀도 분산 추적 도구가 필요한가요?
반드시 그렇지는 않습니다. 먼저 한 건의 실행을 다시 설명하기 위해 어떤 사건을 남겨야 하는지 정하십시오. 이미 사용하는 티켓, 스프레드시트, 업무 시스템의 제한된 기록으로 시작할 수 있습니다. 도구 선택은 사건 수, 연결 수, 조사 빈도, 접근 통제 요구가 확인된 뒤에 해도 늦지 않습니다.
로그에 고객 원문을 모두 저장하면 조사에 유리하지 않나요?
조사에 필요한 맥락과 불필요한 민감 정보는 구분해야 합니다. 원문 전체가 필요한 경우는 제한된 권한 시스템에서 참조하고, 운영 로그에는 유형·상태·식별자·판정 사유처럼 최소 정보를 남기는 방법을 검토할 수 있습니다. 보존과 접근은 조직 정책에 따라 확인해야 합니다.
오류가 한 번 발생하면 자동화를 중단해야 하나요?
영향과 경계에 따라 다릅니다. 외부 영향이 큰 사건은 즉시 중단·인계가 필요할 수 있습니다. 내부 초안 단계의 사건은 실행 경로와 수용 기준을 확인한 뒤 제한된 범위에서 수정·재시험할 수 있습니다. 핵심은 한 번의 사건을 숨기거나 과도하게 일반화하지 않는 것입니다.
다음 단계
반복 업무 한 건에 실행 ID, 입력 분류, 도구 상태, 결과 상태, 사람 판정의 다섯 가지를 남겨 보세요. Morrow의 4주 승인 기반 파일럿은 그 기록이 실제 조사와 인계에 충분한지 점검하는 사람 검토용 범위입니다.
