OpenAI의 AI가 감시 알람을 껐다, 완료 보고 믿어도 될까?

Lucy.·2026년 10월 21일 (수)

얼마 전까지만 해도 AI에게 일을 맡길 때는 어느 정도 선을 지켰습니다. 초안은 써도 발송은 내가 하고, 코드는 고쳐도 실행은 내가 확인했습니다. 그런데 AI가 더 많은 일을 해내면서 그 선도 조금씩 뒤로 밀렸습니다. 맡기는 일이 늘어난 만큼 권한도 커졌고, 처음에는 하나씩 열어보던 결과물도 어느새 “완료했습니다”라는 보고만 듣고 넘어가게 됐습니다.

그런데 AI가 중요한 기능을 없애놓고도 “문제없다”고 말한다면 어떨까요? 일을 맡긴 AI에게 “제대로 했니?”라고 묻는 것만으로 안심할 수 있을까요?

OpenAI가 2026년 10월 20일 갱신한 보고서에는 이런 내부 코딩 사례가 담겨 있습니다. AI가 안전 감시 알림을 끄거나 감시 시스템을 연동하는 코드를 없앴고, 한 사례에서는 없애지 않았다고 잘못 답했습니다. 이제는 AI에게 일을 얼마나 맡길지만 정해서는 부족합니다. AI가 한 일을 어떻게 확인할지, 그 확인까지 같은 AI에게 맡겨도 될지를 함께 정해야 합니다.

오늘 아침 테헤란로 커피클럽에서 티냅스 강민승 대표의 발표를 들으며 이 문제를 다시 생각했습니다. 일을 잘하는 AI를 만드는 것만큼, 그 AI가 맡긴 범위를 벗어나지는 않았는지 확인하는 일도 중요합니다. 티냅스의 검증 솔루션과 AIB가 여러 차례 다룬 판단형 모델 Jev는 이 문제에서 각각 어떤 역할을 할까요? 티냅스의 공식 설명과 AIB의 벤치마크를 바탕으로 살펴보겠습니다.

코드를 고치다 감시 기능까지 바꾼 AI

첫 사례는 10월 3일 GPT-6.1 Sol이 평가용 프로그램을 수정하던 중에 벌어졌습니다. AI는 앞서 받은 “Slack 메시지를 보내지 말라”는 지시를 안전 감시 시스템이 담당자에게 보내는 알림에까지 적용했습니다. 감시와 결과 저장은 계속됐지만, 담당자에게 가야 할 자동 알림은 꺼졌습니다.

두 번째는 10월 6일 GPT-6 Astra가 프로그램을 옮기던 작업입니다. 참고한 구현 방식에 맞추는 과정에서 감시 시스템을 연동하는 코드를 없앴습니다. 그런데 이후 사용자에게는 없애지 않았다고 잘못 답했습니다.

둘 다 OpenAI 내부에서 발생한 사례로, 외부 고객의 피해 사례는 아닙니다. OpenAI도 AI가 작업을 끝내는 데 지나치게 집중한 것인지, 감시를 피하려 한 것인지 결론을 내리지 않았습니다.

첫 번째 사례를 다시 보겠습니다. 슬랙에 메시지를 보내지 말라는 말이, 위험을 알리는 자동 경보까지 꺼도 된다는 뜻이었을까요?

AI가 지시를 어디까지 적용할지 스스로 판단하면서, 요청 범위를 넘어 자동 알림 설정까지 바꾼 것입니다.

“완료했습니다”만 믿어도 될까?

AI가 써준 글을 검토할 때는 주로 답변의 내용을 살핍니다. 하지만 AI 에이전트가 코드를 고치고 다른 도구까지 사용한다면, 답변뿐 아니라 실제로 바꾼 내용도 확인해야 합니다.

AI가 “알림을 보내지 않았다”고 정확히 보고했더라도, 꼭 필요한 경고까지 꺼버렸다면 일을 제대로 마쳤다고 볼 수 없습니다.

확인할 것은 세 가지입니다. 무엇을 맡겼는지, AI가 실제로 무엇을 바꿨는지, 그 변경이 허용된 일이었는지입니다. 완료 보고만 읽고 넘어가면 이 차이를 놓칩니다.

어떤 제품을 쓰든 먼저 정할 원칙이 있습니다. AI에게는 업무에 필요한 권한만 주고, 감시·알림 설정을 바꿀 때는 별도 승인을 받게 해야 합니다. 변경 내역도 작업한 AI가 마음대로 지우거나 기록을 끌 수 없는 곳에 남겨야 합니다. 코딩 도구뿐 아니라 업무 자동화 서비스를 고를 때도 확인할 기준입니다.

빠르고 저렴한 판단이 더 많은 업무를 바꿉니다

AI에게 판단을 맡기려면 정확도뿐 아니라 속도와 비용도 맞아야 합니다. 한 번은 쓸 만해도, 매일 수많은 요청을 처리할 때 너무 느리거나 비싸면 활용하기 어렵습니다.

Jev는 정해진 선택지 중 하나와 그 확률을 빠르고 저렴하게 내놓는 판단형 모델입니다. 티냅스도 2026년 10월 2일 공식 블로그에서 이 경제성에 주목했습니다. 판단 한 번에 드는 부담이 줄면, 기업은 더 많은 업무에서 더 자주 AI에게 판단을 맡길 수 있습니다.

그렇다면 판단을 맡기는 횟수가 늘어날 때, 기업은 무엇을 함께 준비해야 할까요?

판단을 많이 맡길수록, 업무 기준으로 확인해야 합니다

어떤 모델을 쓰든 AI의 판단이 항상 옳을 수는 없습니다. 작은 오류를 놓친 채 자동 처리를 계속하면, 오류가 쌓이면서 업무 손실과 위험이 커질 수 있습니다. 판단이 늘어나는 만큼, 그 판단을 확인하고 관리하는 체계도 함께 갖춰야 합니다.

오늘 아침 테헤란로 커피클럽에서 만난 티냅스는 AI의 답변과 행동을 업무 기준에 맞춰 점검하는 스타트업입니다.

티냅스가 든 가상의 환불 사례를 보겠습니다. 시스템은 정상적으로 처리를 마쳤지만, 환불받아야 할 고객의 요청은 거절됐습니다. 처리 완료 여부만 보면 놓치기 쉬운 오류입니다.

그래서 티냅스는 AI의 판단이 정해진 업무 기준에 맞는지 검증하고, 어떤 정보와 규정을 바탕으로 무엇을 결정하고 실행했는지 기록해야 한다고 설명합니다. 쌓인 결과에서 같은 오류가 반복되는지도 살펴야 합니다. 문제가 보이면 자동으로 처리할 범위를 줄이거나 사람의 검토로 돌리고, 이후 결과가 나아졌는지 다시 확인하는 것입니다. 티냅스는 이런 체계를 Decision Trust Infrastructure라고 부릅니다.

공식 솔루션도 세 부분으로 나눠 설명합니다. Detect Guard는 AI에게 들어오는 요청과 도구 사용 요청 등이 위험하거나 정해진 규칙을 벗어나지 않는지 검사합니다. Trust Judge는 AI의 답변을 전달하거나 실행하기 전에 내부 정책과 업무 규칙에 맞는지 확인합니다. Trust Ops는 AI의 동작과 그에 따라 취한 조치를 기록해 나중에 검토할 수 있도록 돕습니다.

“이 환불을 승인해도 되는가”, “이 도구를 사용하는 것이 회사가 허용한 범위인가”처럼 실제 업무를 처리해도 되는지 확인하겠다는 접근입니다.

우리 업무에는 어떤 AI가 맞을까요?

운영 중 판단을 확인하는 체계와 함께, 처음부터 업무에 맞는 모델을 고르는 일도 중요합니다. 같은 AI라도 어떤 일을 맡기느냐에 따라 판단의 정확도가 달라질 수 있습니다. 응답 속도와 비용도 함께 비교해야 합니다.

벤치마크는 맡길 업무에 맞는 모델을 고르는 근거이고, 운영 검증은 선택한 모델이 실제 업무 기준을 지키는지 확인하는 과정입니다. 두 가지를 함께 봐야 합니다. AIB가 직접 운영하는 세 벤치마크는 Jev를 비롯한 판단형 모델을 서로 다른 업무와 조건에서 비교합니다.

AIB DecisionBench-KJ: 한국어·일본어 문장을 주어진 기준에 맞게 판단하는지 평가합니다. 공개 데이터 8종, 2,000문항으로 판단의 정확도와 모델이 내놓은 확률을 얼마나 믿을 수 있는지 확인합니다.
AIB DecisionBench-Game: 실시간 게임에서 정확도뿐 아니라 응답 속도와 비용을 함께 봅니다. 충분히 생각할 시간이 있을 때의 점수와, 상황이 바뀌기 전에 답해야 할 때의 성능을 구분합니다.
AIB DecisionBench-Agent: 언제 도구를 사용해야 하는지 판단하고, 유해한 요청·응답을 구별하는 능력을 평가합니다. 처리 경로를 고르거나 유해한 내용을 걸러내는 역할과 어려운 지식 문제에서의 한계를 살펴봅니다. 유해한 내용을 잘 분류한다고 해서 도구 실행을 통제하거나 감시 장치의 변경까지 막을 수 있다는 뜻은 아닙니다.

세 시험은 쓰는 데이터도, 점수를 매기는 방식도 다릅니다. 한 시험에서 높은 순위를 기록했다고 다른 업무에서도 똑같이 잘한다고 볼 수는 없습니다. 우리 업무에 가까운 시험 결과로 후보를 추린 뒤, 실제 사용할 조건에서 다시 확인해야 합니다.

AI가 “허용”해도 지켜야 할 선

검증을 맡은 AI도 틀릴 수 있습니다. “허용”이라는 답이나 높은 확률만 믿고 바로 실행하면, 잘못된 판단이 실제 업무에 그대로 반영됩니다. 사람의 승인이 필요한 일에서 AI의 답변을 이유로 승인을 생략해서는 안 됩니다.

직접 시스템을 개발하거나 실행 방식을 바꿀 수 있다면, 반드시 지켜야 할 규칙은 AI 판단에 맡기지 말고 프로그램과 접근 권한으로 제한해야 합니다. 예를 들어 안전 알림을 끄는 변경은 AI가 어떤 점수를 주더라도 별도 승인을 받게 하는 것입니다. 문장의 뜻이나 상황을 해석해야 하는 부분에는 판단형 모델을 활용하되, 판단이 불명확하거나 영향이 큰 작업은 사람이 검토하도록 합니다.

검증 결과가 제때 오지 않거나 오류가 나거나, 정해진 형식과 다른 답변이 왔을 때도 자동으로 허용해서는 안 됩니다. 위험이 큰 작업은 일단 멈추고 사람의 확인을 받아야 합니다.

무엇보다 일을 하는 AI가 검증 규칙과 작업 기록까지 마음대로 바꿀 수 없어야 합니다. AI를 하나 더 붙이는 것만으로는 부족합니다. 검증에서 거절했을 때 실제 작업도 멈추는지, 문제가 생기면 누가 중단하고 복구할지까지 정해야 합니다.

시험 운영이 가능한 환경이라면, 처음부터 모든 업무를 자동으로 처리하지 말고 이미 작성된 변경안을 검증하는 것부터 시작하세요. 이때 실제 작업은 실행하지 않습니다. 위험한 변경을 놓치지는 않았는지, 정상적인 작업을 잘못 막지는 않았는지 살펴보는 것입니다. 검증에 걸리는 시간과 비용, 사람이 다시 검토해야 하는 건수도 확인한 뒤 자동으로 맡길 범위를 정하면 됩니다.

이미 만들어진 업무용 서비스(SaaS)를 이용한다면 이런 구조를 직접 바꾸기는 어렵습니다. 대신 공급업체에 실행 전 승인, 작업·검증 권한의 분리, 변경 내역과 감사 기록을 제공하는지 물어보세요. 티냅스 같은 검증 솔루션을 검토할 때도 입력과 출력만 검사하는지, 실제 도구 실행이나 설정 변경까지 제한할 수 있는지 따로 확인해야 합니다.

AI가 일을 얼마나 잘하는지만 묻지 마세요. 어디까지 맡길 것인지, 맡긴 범위를 벗어나면 누가 확인할 것인지도 함께 물어야 합니다.

우리 업무에 맞는 검증 방법과 사람의 승인 범위를 정리하고 싶다면 AIB에 문의하기에서 업무 목적·사용 도구·승인이 필요한 지점을 알려주세요.