게임 점수가 높은 AI 에이전트, 실무 의사결정에서도 믿을 수 있는가
벤더가 보내온 벤치마크 자료를 처음 열었을 때, 숫자가 인상적으로 보이는 것은 자연스러운 반응이다. 평균 점수, 응답 지연시간, 게임당 비용이 모델별로 나란히 정렬되어 있으면 비교가 쉬워 보인다. 그런데 그 숫자가 팩맨 게임판에서 만들어졌다면, 우리 팀의 의사결정 업무에 그대로 적용해도 좋은 근거가 되는가.
이 질문이 실제 벤더 선정 회의에서 한 번도 제기되지 않는 경우가 많다. 게임 벤치마크가 측정하는 것과 실무 의사결정 시스템이 요구하는 것 사이에는 생각보다 넓은 간극이 있다.
게임 벤치마크가 실제로 측정하는 것
팩맨 형태의 벤치마크가 AI 의사결정 모델을 평가하는 방식은 이렇다. 매 분기점마다 현재 미로 상태, 남은 알약 위치, 유령의 좌표를 JSON으로 모델에 전달하고, 모델은 이동 방향과 각 방향의 확률을 반환한다. 답변이 2초 안에 오지 않으면 단순 백업 규칙이 대신 작동한다. 각 모델은 100게임을 진행하고, 평균 점수와 신뢰구간, 응답 지연시간, 게임당 비용이 기록된다.
이 설계가 측정하는 능력은 명확하다. 구조화된 상태 정보를 바탕으로 빠르게 선택지를 고르는 능력, 반복적이고 규칙이 고정된 환경에서 일관성을 유지하는 능력, 그리고 단위 처리당 비용이다.
유령의 행동 패턴은 사전에 알 수 있는 스크립트 방식이다. 게임 규칙은 변하지 않는다. 판단의 결과가 틀려도 목숨 세 개 안에서 다시 시도할 수 있다. 그리고 한 번의 판단이 이후 수십 개의 판단에 어떤 연쇄 영향을 미치는지는 점수에 반영되지 않는다.
실무 의사결정이 요구하는 것과 다른 이유
오해: 응답 지연시간이 짧고 평균 점수가 높은 모델은 실무에서도 신뢰도가 높다.
실제 조건은 다르다. 실무 의사결정 시스템에서 모델이 마주치는 입력은 대부분 완전하지 않다. 필요한 데이터가 빠져 있거나, 두 부서에서 온 정보가 서로 충돌하거나, 과거에 없던 예외 상황이 끼어든다. 이런 상황에서 모델이 어떻게 반응하는지를 팩맨 점수는 보여주지 않는다.
구체적으로 세 가지 능력이 빠져 있다.
맥락 이해력. 팩맨의 입력은 숫자 좌표와 상태 플래그로 구성된 정형 JSON이다. 실무 시스템의 입력에는 모호한 자연어 지시, 이전 결정의 맥락, 조직 내 암묵적 규칙이 섞인다. 정형 데이터에서 빠른 판단을 내리는 능력과, 비정형 맥락에서 의도를 파악하는 능력은 별개의 문제다.
오류 인식과 복구. 게임에서는 모델이 잘못된 방향을 선택하면 캐릭터가 죽는다. 점수가 자동으로 그 결과를 반영한다. 하지만 실무에서는 모델이 틀린 판단을 내렸다는 사실을 모델 자신이 먼저 인식해야 한다. 오류가 생겼을 때 멈추고 이유를 설명하는 능력, 또는 자신이 없을 때 "이 판단은 사람이 확인해야 한다"고 신호를 보내는 능력은 벤치마크 리더보드 어디에도 나타나지 않는다.
사람 개입 시점의 설계. 백업 규칙이 작동한 비율이 리더보드에 기록되어 있기는 하다. 하지만 그 숫자는 "2초 타임아웃을 넘긴 비율"이지, "모델 스스로 불확실하다고 판단해 사람에게 넘긴 비율"이 아니다. 실무에서는 이 두 가지가 완전히 다른 의미를 갖는다. 전자는 처리 속도 문제이고, 후자는 시스템이 설계한 안전 장치다.
벤치마크 숫자를 어떻게 읽을 것인가
그렇다고 게임 벤치마크가 쓸모없다는 뜻은 아니다. 응답 지연시간과 게임당 비용은 실무 시스템의 처리 규모와 운영 비용을 추정하는 데 유효한 기준이 된다. 100게임에 걸친 평균 점수와 95% 신뢰구간은 모델의 일관성을 보여준다. 고점수 단발 성과가 아니라 평균 분포를 보는 접근은 올바른 방향이다.
문제는 이 숫자를 그 자체로 충분한 검증으로 받아들이는 것이다. 벤더가 게임 벤치마크를 제시할 때, 다음 세 가지를 함께 확인할 필요가 있다.
첫째, 입력 조건을 복잡하게 만들었을 때 모델이 어떻게 반응하는가. 정보 일부가 누락된 상태, 모순된 데이터가 포함된 상태, 이전 맥락이 전제된 상태에서 각각 어떤 출력이 나오는지 직접 시험해 봐야 한다. 이것은 별도의 테스트 없이 리더보드에서 읽어낼 수 없다.
둘째, 모델이 자신의 판단에 불확실성을 어떻게 표현하는가. 단순히 방향을 결정하는 것이 아니라, 확률 분포가 넓게 퍼져 있을 때 그 불확실성을 출력에 담아 전달하는지 확인해야 한다. 팩맨 벤치마크에서 방향별 확률을 반환하도록 설계된 것은 이 점에서 좋은 구조지만, 실무 시스템에서 그 확률이 어떻게 해석되고 활용되는지는 별도로 설계해야 한다.
셋째, 사람이 개입해야 하는 조건을 시스템이 어떻게 다루는가. 벤더에게 이렇게 물어볼 수 있다. "모델이 답을 내리지 말아야 하는 상황을 어떻게 정의하는가. 그 조건을 우리가 설정할 수 있는가. 그리고 그 결정의 기록은 어디에 남는가."
벤더 선정 전에 실제로 확인해야 할 항목
게임 벤치마크 점수를 첫 번째 필터로 사용하는 것은 괜찮다. 지연시간이 업무 요건을 충족하는지, 비용이 예산 범위 안인지, 평균 성능이 최소 기준을 넘는지 확인하는 데 쓸 수 있다.
그 다음 단계가 중요하다. 이 단계에서 다음 네 가지를 직접 확인하지 않고 벤더를 선정하는 것은 벤치마크만 보고 팀원을 채용하는 것과 비슷하다.
도메인 맥락 테스트. 실제 업무에서 발생한 애매한 입력 사례를 세 가지 이상 준비하고 모델에 직접 넣어본다. 벤더가 이 테스트를 거부하거나 데모 시나리오로만 대체하려 한다면, 그 자체가 신호다.
오류 처리 흐름 확인. 모델이 잘못된 판단을 내렸을 때 시스템이 어떻게 반응하는지 설계 문서로 확인한다. 오류를 감지하는 주체, 오류를 기록하는 방식, 오류가 이후 판단에 미치는 영향을 구체적으로 물어야 한다.
인간 개입 구조 검토. 어떤 조건에서 사람에게 판단을 넘기도록 설계되어 있는가. 그 임계값을 우리 팀이 조정할 수 있는가. 조정 이력이 감사 가능한 형태로 남는가.
운영 중 성능 추적 방식. 배포 이후 실제 업무 환경에서 성능이 어떻게 모니터링되는가. 게임 환경과 달리 실무에서는 "점수"가 자동으로 계산되지 않는다. 어떤 지표를, 누가, 어떤 주기로 확인하는지 명확하지 않으면 배포 이후 성능 저하를 늦게 알게 된다.
점수판이 없는 곳에서 판단하는 AI
팩맨에는 점수판이 있다. 규칙이 고정되어 있고, 결과가 즉시 수치로 나타나고, 게임이 끝나면 다음 게임이 새로 시작된다.
실무 의사결정 시스템에는 이 세 가지가 없다. 옳고 그름을 자동으로 알려주는 점수판이 없고, 규칙은 조직 상황에 따라 달라지고, 한 번의 판단은 다음 판단의 입력이 된다. 이 환경에서 필요한 것은 빠른 선택이 아니라, 틀릴 수 있다는 것을 인식하고 사람과 함께 작동하는 구조다.
벤더가 제시하는 리더보드는 출발점이다. 하지만 그 다음 검증을 어떻게 설계하느냐가 실제 도입 결과를 가른다. 검증 항목을 RFP 단계에서 명문화하고, 개념 증명(PoC) 단계에서 직접 테스트하는 순서를 미리 팀 내에서 합의해두는 것이 첫 번째 행동이다.
