화면을 읽고 스스로 작업을 실행하는 AI 에이전트를 도입하는 기업이 늘고 있습니다.
시스코가 자사 고객사의 정보기술·보안 임원을 대상으로 조사한 결과, 응답한 조직의 85%가 에이전트를 시험하거나 PoC로 돌리고 있었습니다. 그런데 실제 업무에 넓게 올린 곳은 5%였습니다.
이 격차의 원인이 성능이라면 모델이 좋아질수록 줄어들어야 합니다. 그런데 줄지 않고 있습니다.
PoC에서 잘 돌아간 에이전트가 실제 업무에 올라간 뒤에도 계속 잘 돌아가리라는 보장이 없기 때문입니다. 한 회사에서 실제로 벌어진 일을 먼저 보겠습니다. 그다음에 도입을 결정하는 입장에서 무엇을 확인해야 하는지 정리하겠습니다.
AI 에이전트가 두 달 뒤에 틀리기 시작했습니다
아마존에서 AI 에이전트를 연구하는 임원이 소개한 사례가 있습니다. 어느 고객사가 소프트웨어를 검사하는 일에 에이전트를 투입했습니다. 화면에 뜬 일련번호를 읽어내는 작업이었습니다.
에이전트는 두 달 동안 문제없이 돌아갔습니다. 그러다 번호를 간헐적으로 잘못 읽기 시작했습니다.
담당자가 원인을 찾아보니 두 가지가 겹쳐 있었습니다. 하나는 일련번호가 화면 어느 자리에 나타나느냐에 따라 에이전트의 인식 결과가 달라진다는 점이었습니다. 다른 하나는 사람 눈으로는 알아채기 어려운 소프트웨어 변경이 있었고, 그 변경이 번호가 나타나는 자리를 건드렸다는 점이었습니다.
이 회사는 도입할 때 검증을 통과했고 두 달 동안 아무 문제가 없었습니다. 그리고 어느 시점부터 틀리기 시작했습니다.
이 사례에서 에이전트는 오류를 내지 않았습니다. 화면을 읽고 값을 넘기는 일을 계속했고, 그 값이 틀렸을 뿐입니다. 시스템이 멈추지 않았으니 담당자가 곧바로 알아채기도 어려웠습니다. 잘못된 값은 그동안 다음 단계로 넘어갔습니다.
PoC 단계에서는 왜 안 보였을까요?
PoC 단계에서 문제가 드러나지 않는 데는 이유가 있습니다. 미국 국립표준기술연구소는 AI 위험 관리 지침에서 이 현상을 다루고 있습니다. 배포되어 운영에 들어간 뒤에 시스템의 성능과 신뢰성이 달라질 수 있다는 것입니다.
예외적인 사고가 아니라 배포된 AI 시스템에서 예상되는 일이라는 뜻입니다.
회사가 시험할 때는 조건이 고정돼 있습니다. 준비한 자료로, 정해진 화면에서, 정해진 순서대로 돌려봅니다. 실제 운영은 다릅니다. 화면 배치가 바뀌고, 들어오는 자료의 모양이 바뀌고, 연결된 다른 시스템이 업데이트됩니다. 이런 변화는 하나하나가 사소해 보이고 대부분은 실제로 사소합니다. 그런데 그중 하나가 에이전트가 의존하던 조건을 건드리면 결과가 달라집니다.
그래서 회사가 도입 전에 아무리 꼼꼼히 검증해도, 배포한 뒤에 결과가 달라지는 것까지 막지는 못합니다. 검증을 덜 해도 된다는 뜻이 아닙니다. 검증을 한 번 하고 끝낼 수 없다는 뜻입니다.
PoC에서 실제 운영으로 넘어가지 못하는 조직이 많은 이유도 여기에 있습니다. 몇 주 동안 돌려보고 결과가 좋으면 다음 단계로 가는데, 막상 넓게 올리면 조건이 다양해지면서 예상하지 못한 결과가 나옵니다. 그러면 다시 파일럿 단계로 돌아갑니다.
AI 에이전트 도입은 도구를 고르는 문제가 아닙니다
AI 에이전트 도입을 어떤 제품을 고르느냐로 접근하면 이 문제가 보이지 않습니다. 성능이 가장 좋은 것을 고르면 해결된다고 여기게 됩니다.
실제 문제는 고른 다음에 있습니다. 도입한 에이전트를 어떻게 운영하고 무엇을 확인하느냐입니다. 이건 제품을 비교하는 일이 아니라 관리하는 일에 가깝습니다.
회사가 정해둬야 할 것이 세 가지입니다.
무엇이 잘못될 수 있는가, 잘못됐을 때 되돌릴 수 있는가, 그리고 어디까지는 감수할 것인가입니다.
세 번째가 특히 중요합니다. 모든 오류를 막으려 하면 확인 절차가 너무 무거워져서 에이전트를 쓰는 의미가 사라집니다. 반대로 아무것도 감수하지 않겠다고 하면 애초에 도입하지 않는 편이 낫습니다. 어느 정도까지는 받아들이고 어느 선을 넘으면 멈출지를 정하는 것이 실제 결정입니다.
미국 국립표준기술연구소가 배포 후 관리에 대해 제시한 항목 중 이 세 질문에 답이 되는 것들을 정리했습니다. 아래 항목의 주체는 모두 도입한 회사입니다.
항목이 아홉 개인데 한꺼번에 다 하기는 어렵습니다. 아직 아무것도 정해두지 않았다면 세 가지부터 시작하면 됩니다. 정기 확인 절차를 넣는 것, 어떤 상황이면 멈출지 정하는 것, 그리고 변경 기록을 남기는 것입니다. 나머지는 이 셋이 자리를 잡은 뒤에 붙여도 늦지 않습니다.
AI 에이전트 운영에서 무엇이 잘못될 수 있는가
1. 실제 쓰이는 조건과 비슷한 환경에서 확인합니다 회사가 준비한 깨끗한 자료로만 시험하면 시험 결과도 그 조건에서만 맞습니다. 실제로 들어오는 자료가 어떤 모양인지, 화면이 어떤 상태인지를 반영해야 합니다.
2. 정기적으로 확인하는 절차를 만듭니다 도입할 때 한 번 검증하고 끝내면, 결과가 달라져도 담당자가 알아채는 시점이 늦어집니다. 일련번호 사례에서도 두 달이 지난 뒤에야 문제가 드러났습니다.
3. 시스템을 바꿀 때 에이전트도 함께 봅니다 지침은 새 기술을 도입하거나 시스템을 바꾸는 일이 눈에 띄지 않는 영향을 만들 수 있다고 지적합니다. 화면 배치를 바꾸거나 다른 시스템을 업데이트할 때, 그 변경이 에이전트가 하는 일에 영향을 주는지 확인해야 합니다.
4. 담당자가 이상을 알릴 곳을 정해둡니다 실제로 결과를 받아보는 사람이 가장 먼저 이상을 느낍니다. 그 사람이 누구에게 알려야 하는지 모르면 문제가 쌓입니다. 지침에도 운영 중에 사용자로부터 의견을 받는 경로를 두라는 항목이 있습니다.
AI 에이전트를 멈출 수 있어야 합니다
1. 어떤 상황이면 멈출지 기준을 미리 정합니다 오류가 몇 건 나오면 멈출 것인지, 어떤 종류의 오류면 즉시 멈출 것인지를 정해두지 않으면 판단이 늦어집니다.
2. 멈추는 절차가 실제로 작동하는지 확인해둡니다 중단 기능이 설명서에만 있고 한 번도 눌러본 적이 없다면, 필요한 순간에 작동할지 알 수 없습니다.
3. 멈춘 뒤에는 원인을 찾습니다 지침은 에이전트를 우회하거나 정지시킨 일에 대해 내부에서 근본 원인을 분석하도록 권합니다. 원인을 모르면 같은 일이 다시 일어납니다.
4. 고친 뒤 다시 쓸 조건도 정해둡니다 멈춘 에이전트를 언제 다시 돌릴지 기준이 없으면, 급한 마음에 원인을 덜 확인한 채 재개하게 됩니다.
5. 업무마다 확인 강도를 다르게 정합니다 모든 작업에 같은 수준으로 확인을 붙이면 담당자가 감당하지 못합니다. 되돌리기 어려운 작업일수록 결과를 더 자주, 더 깊게 확인합니다.
AI 에이전트 운영에서 무엇을 기록할 것인가
앞의 두 가지를 정해도 기록이 없으면 원인을 찾을 수 없습니다. 지침은 두 가지를 따로 남기라고 제시합니다.
하나는 문제 기록입니다. 언제 어떤 문제가 있었고, 얼마나 심각했고, 어떻게 대응했는지를 남깁니다. 아직 사고로 이어지지 않은 아차 사고도 함께 남깁니다.
다른 하나는 변경 기록입니다. 시스템을 언제 왜 바꿨고, 어떻게 바꿔서 어떻게 시험하고 배포했는지를 남깁니다.
이 둘이 함께 있어야 연결이 보입니다. 일련번호 사례로 돌아가 보면, 오늘 나온 오류의 원인은 얼마 전의 소프트웨어 변경이었습니다. 문제 기록만 있으면 언제부터 틀렸는지까지는 알 수 있어도 왜 틀렸는지는 알 수 없습니다. 변경 기록이 함께 있어야 두 시점을 맞춰볼 수 있습니다.
기록을 남기는 일은 사고가 났을 때만 쓰이는 것이 아닙니다. 같은 조건에서 같은 문제가 반복되는지, 특정 종류의 변경이 유독 문제를 자주 만드는지를 확인하는 데도 쓰입니다. 몇 달치가 쌓이면 어디를 먼저 손봐야 하는지가 보입니다.
AI 에이전트 도입, 한 번이 아니라 계속
에이전트를 검토할 때 회사가 보는 것은 대개 시연 결과입니다. 준비된 조건에서 한 번 돌려보고 판단합니다.
회사가 물어야 할 질문은 다릅니다. 이 에이전트가 한 번 제대로 해내느냐가 아니라, 같은 일을 계속 제대로 해내느냐입니다.
85%와 5%를 가르는 것도 여기에 있습니다. 성능이 좋은 에이전트를 고른 조직이 아니라, 배포한 뒤에도 계속 확인한 조직이 실제 운영까지 갔습니다.
지금 PoC로 돌리고 있는 에이전트가 있다면, 다음 회의에서 두 가지를 물어보시면 됩니다. 마지막으로 결과를 확인한 것이 언제인지, 그리고 그 확인을 다음에 언제 또 할 것인지입니다. 두 번째 질문에 날짜가 나오지 않으면 아직 정기 확인 절차가 없는 것입니다.
디피니트 블로그를 구독하세요
디피니트는 제조 기업의 원가와 손익을 설명 가능하게 만드는 회사입니다. ERP 숫자와 현장 인식이 다를 때 근거를 대지 못하는 상황을, AI가 원인을 항목 단위로 분해해 조치 방향까지 보여주도록 바꿉니다.
그 과정에서 알게 된 것들을 블로그에 정리하고 있습니다. AI를 어디까지 맡기고 어디서 사람이 판단할지 고민하고 계신다면, 디피니트 블로그를 구독하고 새 글을 먼저 받아보세요