Microsoft가 자체 AI 전환에서 배운 것, 111개 에이전트가 보여준 조건

AI를 활용하여 생성한 이미지입니다.

에이전트를 몇 개 만들었는지가 AI 전환의 성패를 바로 보여 주지는 않습니다. Microsoft가 2026년 9월 17일 공개한 글은 새 모델 발표라기보다, 회사 내부 업무에 AI를 적용한 뒤 남은 운영 원칙을 정리한 회고에 가깝습니다.[1] 가장 많이 인용되는 숫자는 클라우드 공급망 업무에 배치한 111개 이상의 에이전트지만, 글의 핵심은 개수가 아니라 업무 결과와 통제 경계입니다.

확인된 사례와 숫자의 범위

Microsoft는 2026년 9월 기준 클라우드 공급망 업무에 111개 이상의 에이전트를 배치했다고 밝혔습니다. 이 결과를 만든 내부 분석에는 2025년 9월부터 2026년 8월까지 150명 이상으로 구성된 여러 분야 팀이 참여했다고 설명합니다.[1] 다만 원문은 각 에이전트의 정확도, 비용, 실패율, 사람의 검토 시간을 모두 공개한 성능 보고서는 아닙니다. 그러므로 111이라는 숫자를 다른 기업의 성과와 곧바로 비교하거나, 같은 수를 도입하면 같은 결과가 나온다고 해석해서는 안 됩니다.

기술보다 먼저 업무 결과를 정하기

Microsoft가 제시한 첫 순서는 “기술이 무엇을 할 수 있는가”보다 “사업에서 어떤 결과가 필요한가”를 먼저 묻는 것입니다.[1] 이 순서를 거꾸로 잡으면 챗봇이나 에이전트를 만든 뒤 사용처를 억지로 찾게 됩니다. 그때는 응답 속도, 사용량, 생성 토큰처럼 측정하기 쉬운 값이 목표가 되기 쉽습니다.

공급망이라면 납기 지연 가능성을 얼마나 일찍 찾는지, 담당자가 확인해야 할 건수가 줄었는지를 먼저 봐야 합니다. 사내 IT라면 문의 처리 시간, 개발팀이라면 배포 전 결함을 발견하는 시점을 기준으로 삼을 수 있습니다. 에이전트 개수는 결과를 만든 뒤 기록할 운영 지표이지, 시작 목표가 아닙니다.

에이전트마다 권한과 중단 조건을 적기

에이전트가 많아진다고 조직이 자동으로 똑똑해지는 것은 아닙니다. 어떤 데이터를 읽고, 무엇을 바꾸며, 오류가 났을 때 누가 중지할 수 있는지가 더 중요합니다.[1] 주문·재고·납기·협력사 정보가 연결된 업무에서는 작은 오류가 다음 시스템으로 전파될 수 있습니다. 추천만 하는 에이전트와 재고나 주문 값을 직접 바꾸는 에이전트는 같은 모델을 써도 위험도가 다릅니다.

• 읽을 수 있는 데이터와 변경할 수 있는 데이터를 구분합니다.
• 자동 실행 조건과 사람 승인이 필요한 조건을 나눕니다.
• 실패했을 때 되돌릴 수 있는 지점과 수동 처리 절차를 적습니다.
• 결과를 검토할 담당자와 검토 기한을 정합니다.
• 성능 점수보다 실제 업무 결과로 확인할 지표를 정합니다.

처음에는 읽기 전용으로 추천 결과만 만들고, 누락과 오탐 사례를 확인한 뒤 제한된 쓰기 권한을 검토하는 편이 안전합니다. 중단 조건도 미리 정해야 합니다. 평소 범위를 벗어난 금액이나 수량에 접근하거나, 근거 링크가 없거나, 같은 오류가 반복되면 자동 실행을 멈추고 사람이 이어받게 하세요.

사람은 마지막 승인자 이상이어야 합니다

Microsoft의 회고에서 사람과 AI의 결합은 사람이 마지막 버튼만 누르는 구조가 아닙니다.[1] 현장에서 반복되는 예외를 찾아내고, AI가 놓친 조건을 데이터·규칙·권한 중 어디에 반영할지 결정하는 역할까지 포함합니다. 예를 들어 운송 지연을 잘 찾던 에이전트가 특정 협력사의 휴무일을 계속 잘못 읽는다면, 매번 수동 수정만 할 것이 아니라 원인과 재발 방지책을 기록해야 합니다.

반대로 사람이 결과를 처음부터 끝까지 다시 입력한다면 자동화의 이점이 사라집니다. 자료 수집, 분류, 초안 작성, 반복 확인은 AI가 맡고, 금액 변경이나 계약상 예외처럼 되돌리기 어려운 결정은 사람이 맡는 식으로 경계를 설계해야 합니다. 업무를 두 번 실행해도 결과가 중복되지 않는 멱등성과 재시도 기준은 모델 성능과 별개로 필요하므로 AI 에이전트 도구 호출의 멱등성과 재시도 기준도 함께 참고할 수 있습니다.

작은 범위에서 비용과 데이터 품질을 확인하기

에이전트 비용은 모델 사용료만으로 끝나지 않습니다. 데이터 연결, 권한 정리, 예외 사례 수집, 사람의 검토 시간도 포함해야 합니다. 기존 시스템이 여러 개로 나뉜 공급망 업무에서는 모델보다 연결부와 데이터 정합성을 정리하는 일이 더 클 수 있습니다.

처음부터 모든 시스템을 연결하지 말고 입력 하나와 결과 하나로 범위를 줄이세요. 예를 들어 매일 지연 가능성이 높은 주문을 분류하고 사람이 결과를 확인하는 흐름이라면, 누락률·오탐 사례·검토 시간을 실제 업무에서 기록할 수 있습니다. 오래된 재고 수량이나 서로 충돌하는 납기 정보가 입력되면 더 좋은 모델을 붙여도 결과는 개선되지 않습니다. 데이터 갱신 시각과 충돌 시 우선순위, 근거가 없을 때 멈추는 규칙을 먼저 정해야 합니다.

자동화 단계를 나누면 위험을 관리하기 쉽습니다

에이전트를 한 번에 업무의 끝까지 보내기보다 수집, 분류, 추천, 실행의 단계를 나누어 권한을 다르게 주는 방법이 현실적입니다. 수집 단계는 원본을 읽기만 하고, 분류 단계는 근거와 함께 목록을 만들며, 추천 단계는 사람이 승인할 후보만 제시하게 합니다. 시스템 값을 변경하는 실행 단계는 승인된 항목과 범위를 다시 확인한 뒤에만 호출하도록 분리하세요. 이 구조라면 어느 단계에서 오류가 생겼는지 로그를 따라가기 쉽습니다.

업무 결과 지표의 기준선도 먼저 남겨야 합니다. 자동화 전의 평균 처리 시간이나 사람이 검토하던 예외 건수를 기록하지 않으면 도입 후 개선을 판단하기 어렵습니다. 모델 응답이 빨라졌지만 사람이 확인해야 할 건수가 늘었다면 성공으로 보기 어렵습니다. 반대로 처리 시간이 그대로여도 누락되던 위험 주문을 더 일찍 발견했다면 업무상 의미가 있을 수 있으므로, 한 가지 점수로 결론내리지 마세요.

데이터 접근 권한은 개인 계정에 몰아주지 말고 업무별 서비스 계정과 최소 권한으로 나누는 편이 좋습니다. 누가 어떤 에이전트를 언제 실행했는지, 어떤 원본 시각을 읽었는지, 사람이 어떤 결과를 승인했는지를 남겨야 사고 뒤에 원인을 설명할 수 있습니다. 로그에는 필요 이상의 개인정보를 복사하지 말고 보존 기간도 정하세요.

도입 전 체크리스트

1. 업무의 시작 조건과 완료 조건을 한 문장으로 씁니다.
2. 1~2주 읽기 전용으로 운영하며 누락·오탐을 모읍니다.
3. 승인 필요 행동과 자동 실행 행동을 분리합니다.
4. 결과에 근거 링크와 원본 데이터 시각을 남깁니다.
5. 중단 뒤 수동 처리로 돌아가는 절차를 준비합니다.

첫 단계의 종료 조건도 정해 두세요. 업무 담당자가 결과를 검토할 수 있고, 실패한 건을 수동으로 처리할 수 있으며, 원본 데이터와 판단 근거를 다시 열어 볼 수 있어야 다음 권한 확대를 논의할 수 있습니다. 이 조건이 없으면 시범 운영이 끝나도 무엇을 배웠는지 남지 않습니다.

자주 묻는 질문

111개를 목표로 삼아야 하나요?

아닙니다. 원문이 보여 주는 것은 한 기업의 내부 적용 사례입니다. 조직의 업무 결과와 권한 구조에 맞는 최소 범위부터 정해야 합니다.[1]

모든 에이전트에 쓰기 권한을 줘도 되나요?

권장하기 어렵습니다. 읽기 전용과 승인 단계를 먼저 두고, 되돌릴 수 있는 범위에서 제한적으로 확대하세요.

성과는 무엇으로 판단하나요?

에이전트 수보다 목표 업무의 처리 시간, 누락·오탐, 사람의 검토량처럼 실제 결과와 연결된 지표를 봐야 합니다.

Sources

1. [1] Microsoft, What we’ve learned from Microsoft’s own AI transformation