코딩 AI가 자신 있어도 실행은 따로 확인해야 한다

AI가 코드를 제안하는 일과 그 코드가 실제 파일을 바꾸거나 도구를 실행하도록 허용하는 일은 다르다. 제안만 받는다면 사용자는 내용을 읽고 고치거나 무시할 수 있다. 실행 권한까지 주면 AI의 판단이 작업 환경에 영향을 미치고, 잘못된 행동은 설명을 읽는 동안이 아니라 실행된 뒤에 드러날 수 있다. 그때는 파일을 복구하거나 작업을 다시 해야 할 수 있고, 영향이 처음 요청한 범위를 넘어갈 수도 있다.

그래서 실행 권한을 고민하는 사람에게 필요한 질문은 단순히 AI의 답이 맞는지 확인하는 데 그치지 않는다. AI가 지금 하려는 행동이 요청한 일과 맞는지, 어떤 파일이나 도구에 어떤 방식으로 영향을 주는지, 잘못됐을 때 실행 전에 알아차릴 절차가 있는지를 살펴야 한다. AI가 자신 있게 말한다는 사실은 이 질문들에 대한 답이 아니다.

이 글이 다루는 대상은 코드 추천만 하는 자동완성이나 실행 권한이 없는 대화형 AI 전체가 아니다. AI 에이전트가 코드를 쓰거나 도구를 호출하고, 사람이나 운영자가 그 행동을 통과시킬지 결정하는 상황이다. 실행할 권한을 주지 않는 독자에게까지 같은 위험을 일반화할 이유는 없다. 여기서 중요한 선택은 답변을 믿을지보다, 그 답변이 실제 행동이 되도록 허용할지다.

문법이 맞아도 요청에 맞는 행동은 아닐 수 있다

설명을 위한 가상 상황을 하나 떠올려 보자. 작은 팀에서 설정 파일을 정리해 달라고 AI에 요청했다. AI는 파일을 살펴보고 정리 명령을 제안한다. 명령의 형식은 맞고, 설명도 그럴듯하다. 하지만 실제 대상이 작업용 복사본이 아니라 운영 중인 파일이라면 어떨까. 또는 정리 과정에서 오래된 설정뿐 아니라 되돌릴 때 필요한 파일까지 함께 없어질 수 있다면 어떨까.

이때 확인할 것은 명령어가 실행되는지 하나만이 아니다. 요청한 작업이 무엇이었는지, 제안된 행동이 어느 대상을 건드리는지, 그 결과가 요청의 범위에 들어가는지, 변경 뒤에 복구할 수 있는지를 각각 살펴야 한다. 코드가 문법적으로 올바르다는 점은 실행 가능성을 보여줄 뿐이다. 작업의 목적과 범위에 맞는지까지 보증하지 않는다.

AI의 설명이 매끄럽고 확신에 차 있어도 마찬가지다. 그 말은 AI가 자신의 답을 어떻게 평가하는지 보여줄 수 있지만, 실행하려는 행동을 요청과 대조해 확인했다는 뜻은 아니다. 특히 요청의 일부를 잘못 이해한 채 행동을 만들었다면, 그 오해가 설명에도 자연스럽게 반영될 수 있다. 그러면 자신감 있는 말은 검증의 대체물이 되기보다 잘못된 행동을 더 믿음직하게 보이게 할 수도 있다.

같은 행동을 여러 번 받았다는 사실도 독립적인 확인으로 볼 수는 없다. 서로 다른 사람이 각자 근거를 확인하고 같은 결론을 내리는 것과, 같은 AI가 같은 입력에 거의 같은 행동을 반복하는 것은 다르다. 이번 연구에서 다룬 에이전트 가운데는 같은 입력에서 비슷한 행동을 되풀이하는 경우가 많았다. 연구진은 이런 조건에서는 답을 여러 번 생성해 일치 여부를 보는 방법이 유용한 신호를 주기 어렵다고 설명한다. 이 결과를 모든 모델에 넓혀 말할 수는 없지만, 반복 횟수만 세어 검증을 대신할 수 없다는 점은 드러난다.

별도 점검은 행동을 검토할 순서를 정하는 신호다

2026년 10월 초 공개된 연구에서 연구진은 에이전트가 제안한 행동을 다른 모델이 살펴보고 점수를 매기는 방식을 시험했다. 점검 모델은 사용자의 요청과 작업 맥락, 도구가 요구하는 항목과 형식, 실행하려는 행동을 함께 읽는다. 이때 실제 작업 환경에서 행동이 맞는지 실행해 확인하는 것은 아니다. 주어진 자료를 읽었을 때 행동의 입력값이나 도구 선택이 얼마나 그럴듯하게 이어지는지, 행동 전체가 조건에 맞는지를 여러 방식으로 평가해 신호를 만든다. 그중에는 점검 모델이 해당 입력값을 생성할 가능성을 읽는 방식도 있다. 이미 일어난 일을 측정하는 검사와, 문맥에 맞는 행동인지를 추정하는 점수는 다르다. 연구 원문

이 방식에서 중요한 변화는 점검의 대상이다. 에이전트에게 자기 행동이 맞는지 다시 묻는 대신, 실제 실행될 행동을 다른 모델이 읽는다. 연구진은 이 점검 모델이 에이전트의 내부 정보에 접근하거나 추가 학습을 하지 않고도 작동하도록 설계했다고 설명한다. 그렇다고 점검 모델이 현실의 파일 상태나 사용자가 말하지 않은 업무 규칙까지 저절로 아는 것은 아니다. 입력에 담긴 요청과 조건, 제안된 행동을 살펴보는 점검이다.

연구진은 어려운 코딩 과제에서 맞는 행동과 틀린 행동을 구분해 순위를 매기는 성능을 비교했다. 그 지표인 AUROC는 별도 점검 모델에서 0.825, 에이전트가 직접 밝힌 자신감에서는 약 0.598이었다고 보고했다. 값이 높을수록 맞는 행동을 틀린 행동보다 위에 놓는 경향이 강하다는 뜻이며, 이 시험에서는 별도 신호가 더 유용했다. 0.825를 행동의 82.5%가 안전하다거나 개별 행동이 맞을 확률이 82.5%라는 뜻으로 읽을 수는 없다. 여기서 점수의 역할을 정확히 이해할 필요가 있다. 점수는 개별 행동이 맞을 확률을 그대로 알려주는 숫자도, 작업이 안전하다는 인증도 아니다. 여러 행동을 비교할 때 어떤 행동을 먼저 다시 살펴야 할지 가늠하도록 돕는 순위 신호에 가깝다.

그 구분은 운영 방식에도 영향을 준다. 점검 모델이 행동을 평가해도 모든 행동을 자동으로 중단할 필요는 없다. 연구진은 점수가 낮은 행동을 사람 검토로 넘기는 방식도 시험했고, 그대로 통과시키도록 고른 행동들의 정확도가 높아졌다고 보고했다. 이는 사람이 모든 행동을 같은 정도로 확인하기 어려울 때 검토할 순서를 좁히는 방법이 될 수 있음을 보여준다. 점수는 안전 허가증이 아니라, 사람이 먼저 살펴볼 대상을 고르는 데 쓰는 신호다.

물론 검토할 행동을 더 많이 사람에게 보내면 확인 부담이 커진다. 반대로 적은 행동만 검토하도록 하면 시간은 아낄 수 있지만, 놓치는 행동이 생길 가능성도 함께 고려해야 한다. 이 균형은 점수 하나만으로 정해지지 않는다. 어떤 오류가 발생했을 때의 피해가 큰지, 사람이 검토할 여력이 있는지, 작업을 되돌릴 수 있는지에 따라 적절한 운영 방식이 달라진다. 연구 결과는 점수로 검토 대상을 고를 수 있음을 보여줬지만, 모든 업무에 통용되는 점수 기준을 제시하지는 않는다.

실행 전 확인과 다음 행동 수정은 다른 역할을 한다

연구진은 점수와 도구 실행 결과를 에이전트에 함께 돌려주는 방식도 평가했다. 점검 신호는 실행 전 사람 검토를 돕는 데만 쓰인 것이 아니다. AI가 도구의 결과와 자신이 받은 점수를 보고 다음 행동을 조정하도록 한 시험 환경에서, 도구를 실제로 실행하는 두 시험 환경에서 과제를 더 잘 마쳤다고 연구진은 보고했다. 점검 결과가 다음 단계에서 행동을 수정하는 데 도움이 될 가능성을 보여주는 결과다.

이 방식은 실행을 멈추고 사람에게 넘기는 절차와 구분할 필요가 있다. 사람 검토는 실행 전에 위험하거나 어울리지 않는 행동을 살펴보는 관문이다. 실행 결과와 점수를 되돌려주는 방식은 이미 한 행동 뒤에 얻은 정보를 다음 판단에 쓰도록 돕는다. 후자는 AI가 오류를 알아차리고 수정할 기회를 넓힐 수 있지만, 처음 실행한 행동을 되돌리거나 그 영향이 사라지게 해주지는 않는다.

또한 시험에서 과제를 더 잘 마쳤다는 결과를 실제 업무의 오류가 같은 정도로 줄었다는 뜻으로 바꿔 읽어서는 안 된다. 과제의 성공 지표는 시험한 환경에서 목표를 달성했는지를 나타낸다. 현실에서는 데이터의 중요도, 작업 권한, 실패 뒤 복구 절차처럼 실험과 다를 수 있는 조건이 결과에 영향을 준다. 연구 결과는 점검 신호를 활용할 두 가지 방향을 보여주지만, 두 방식 가운데 무엇을 어떤 일에 적용할지는 별도의 판단으로 남는다.

두 모델이 같은 자료를 보면 같은 빈칸도 남는다

앞서 설정 파일을 정리하는 상황으로 돌아가보자. 요청에는 오래된 항목을 치워 달라는 말만 있고 어떤 파일은 복구에 필요하다는 조건이 빠졌을 수 있다. 점검 모델도 그 요청과 제안된 삭제 목록만 받으면, 삭제해도 되는 파일과 남겨야 할 파일을 구분할 정보를 갖지 못한다. 서로 다른 모델이 읽었다는 이유만으로 새로운 사실이 생기는 것은 아니다. 점수의 값보다 먼저 어떤 자료를 보고 판단했는지 살펴야 하는 이유다.

이때 실제로 필요한 확인은 같은 행동을 다시 말하게 하는 것이 아니라, 그 목록이 현재 파일 상태와 맞는지, 업무 담당자가 정한 보존 조건이 포함됐는지를 대조하는 일이다. 필요한 정보가 확보되면 점검 신호도 그 조건을 바탕으로 평가할 수 있다. 정보가 빠져 있는데도 높은 점수를 받았다면, 그 점수는 생략된 조건까지 확인한 근거가 될 수 없다. 이는 연구가 실제 팀의 파일 정리를 입증했다는 주장이 아니라, 제안된 점검 방식이 어떤 입력을 읽는지에 따라 남는 한계를 설명한 것이다.

작업의 영향에 따라 검토 수준을 달리해야 한다

실제 업무에 적용할 때 먼저 확인할 것은 점검 모델의 점수만이 아니다. AI가 어떤 대상을 바꾸려는지, 실행할 행동이 요청의 범위 안에 있는지, 어떤 조건을 근거로 그렇게 판단했는지 검토할 수 있어야 한다. 점검 모델이 읽는 정보에 실제 작업 환경이나 최신 파일 상태가 빠져 있다면, 점수도 그 빠진 정보를 대신 확인할 수 없다. 별도 모델이 같은 자료를 읽었다는 사실과 실제 환경을 별도로 검증했다는 사실은 다르다.

그다음에는 잘못됐을 때의 영향을 따져야 한다. 복사본에서 쉽게 되돌릴 수 있는 변경과 실제 운영 자료에 영향을 주는 행동은 같은 수준으로 다룰 이유가 없다. 적용 원칙으로는 영향이 작고 복구가 쉬운 작업부터 범위를 제한해 자동 실행을 검토하고, 데이터 삭제나 외부 시스템 변경처럼 결과가 크거나 되돌리기 어려운 행동에는 사람 확인을 두는 편이 합리적이다. 이는 연구진이 정한 규칙이 아니라, 점수의 쓰임과 작업의 피해를 함께 고려해 운영자가 세워야 할 기준이다.

사람이 검토하는 화면이나 절차를 마련한다면 점수만 보여주기보다 사용자의 요청과 실행할 행동을 나란히 확인할 수 있어야 한다. 어떤 파일이 바뀌는지, 어떤 도구에 무엇을 전달하는지, 요청에서 벗어난 부분은 없는지 비교해야 이유 있는 판단을 내릴 수 있다. 점수는 주의를 기울일 이유를 제공하지만, 무엇이 잘못됐는지 밝히는 설명은 아니다. 실제 검토에는 행동의 내용과 그 행동이 놓인 맥락이 필요하다.

점수 기준을 실제 업무에 가져오기 전에 해당 작업에서 어떤 행동을 잘 구분하는지 살펴보는 과정도 필요하다. 연구진의 결과는 특정 모델과 코딩 과제, 도구 사용 환경에서 나왔다. 다른 팀의 저장소나 다른 종류의 도구에서도 같은 신호가 유용한지는 별개의 문제다. 운영자가 점검을 도입한다면, 자신의 작업에서 정답 행동과 문제가 있는 행동을 구분하는지, 사람이 검토할 정도로 잘못된 행동을 걸러내는지 확인해야 한다. 높은 점수만 보고 자동 실행 범위를 넓힐 근거는 이 연구만으로 마련되지 않는다.

따라서 코딩 AI에 실행을 맡기기 전에는 자신감의 크기보다 행동의 범위와 확인 절차를 살펴야 한다. 무엇을 바꾸려는지, 요청과 맞는지, 점검에 필요한 조건이 주어졌는지, 잘못됐을 때 얼마나 복구하기 어려운지를 확인하는 것이다. 연구가 보여준 것은 별도 점검이 자체 자신감보다 행동을 가려내는 데 유용할 수 있고, 사람 검토와 다음 행동 수정에 도움을 줄 가능성이다. 실행을 맡길 만한지는 그 신호 하나가 아니라 작업의 영향, 검토 가능성, 되돌릴 방법을 함께 따져 결정해야 한다.