지시는 했다.
그런데 막지는
않았다 2025년 7월, 한 코딩 에이전트가 '코드 동결 중'이라는 지시를 받고도 운영 데이터베이스를 지웠다. 동결은 대화창 안에만 있었고, 실행 경로에는 아무 장치도 없었다.

Section Ⅰ · Words Are Not Walls말은 벽이 아니다

'하지 마'라고 적어 두면
막힌 것일까

AI 에이전트는 답을 써 주는 데서 멈추지 않는다. 스스로 도구를 불러 파일을 고치고, 명령을 실행하고, 데이터베이스에 쓴다. 이 차이가 중요하다. 챗봇이 틀리면 틀린 문장이 남지만, 에이전트가 틀리면 바뀐 시스템이 남는다. 그래서 '하지 말라'고 적어 두는 것과 '할 수 없게' 만들어 두는 것은 전혀 다른 일이 된다.

2025년 7월에 있었던 일이 이 차이를 분명하게 보여 준다. 소프트웨어 회사 리플릿의 코딩 에이전트를 열이틀 동안 시험해 보던 이용자가, 아흐레째 되는 날 코드 동결을 선언했다. 동결이란 정해진 기간에 아무것도 바꾸지 말라는 뜻이다. 그는 허락 없이 코드를 고치지 말라고 분명히 적어 두었다.

그런데 에이전트는 운영 중인 데이터베이스를 지웠다. 임원 1,206명과 기업 1,196곳의 기록이 사라졌다. 여기서 끝이 아니었다. 에이전트는 빈 데이터를 문제로 판단해 가짜 기록 4,000여 건을 만들어 채웠고, 사람이 사고를 확인하자 되돌릴 방법이 없다고 보고했다. 실제로는 복구가 가능했고, 데이터는 백업에서 되살아났다. 회사 대표는 공개적으로 사과했다.

이 사건에서 눈여겨볼 대목은 모델의 성능이 아니다. 동결이라는 지시가 대화창 안에만 있었다는 점이다. 에이전트는 그 문장을 읽을 수 있었고, 동의한다고 답할 수도 있었다. 그러나 실행 경로 어디에도 그 문장을 강제하는 장치가 없었다. 운영 데이터베이스에 접근할 자격이 그대로 열려 있었기 때문이다. 말로 한 금지는 요청일 뿐이고, 요청은 벽이 되지 못한다.

회사의 대응이 이 점을 그대로 보여 준다. 며칠 안에 내놓은 수정은 네 가지였다. 개발용과 운영용 데이터베이스를 자동으로 분리했고, 실행 없이 계획만 세우는 모드를 만들었고, 문서 확인을 의무로 걸었고, 한 번에 백업을 되돌리는 기능을 손봤다. 모두 말이 아니라 구조를 바꾸는 조치다. Vol. 44에서 본 바사호에서도 문제는 비슷했다. 기울기 시험의 결과를 모두가 알았지만, 그 결과가 출항을 멈추는 장치에 닿지 못했다.

Section Ⅱ · Ability vs Access능력과 권한은 다르다

할 수 있는 일과
해도 되는 일을 나눈다

에이전트를 도입하는 조직이 가장 자주 섞어 쓰는 두 가지가 있다. 하나는 에이전트가 할 수 있는 일이고, 다른 하나는 에이전트에게 열어 준 범위다. 앞의 것은 모델의 능력이고, 뒤의 것은 우리가 준 자격이다. 사고는 대개 뒤의 것이 앞의 것보다 넓을 때 일어난다.

이 구분이 왜 중요한지는 수치가 말해 준다. 가트너는 2025년 6월 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 내다봤다. 이유로는 비용 상승, 불분명한 사업 가치, 그리고 부실한 위험 통제를 들었다. 같은 발표에서 시장의 과장도 지적했다. 에이전트를 내세우는 수천 곳의 공급업체 가운데 실제로 그 기능을 갖춘 곳은 130곳 남짓이라는 것이다. 그러면서도 가트너는 2028년까지 일상 업무 결정의 15%가 자율적으로 내려지고, 기업용 소프트웨어의 33%에 에이전트 기능이 들어갈 것으로 봤다. 쓰임은 늘어나는데 통제는 그만큼 늘지 않는 구간이 온다는 뜻이다.

가트너는 뒤이어 거버넌스 자체의 함정도 짚었다. 자율성의 수준과 접근 범위가 서로 다른 에이전트들에게 같은 규칙을 일괄 적용하면 오히려 실패한다는 것이다. 사내 문서를 요약하는 에이전트와 고객 환불을 집행하는 에이전트에게 같은 승인 절차를 걸면, 앞의 것은 쓸모가 없어지고 뒤의 것은 여전히 위험하다.

그래서 권한은 행동의 성격에 따라 갈라야 한다. 기준은 Vol. 17에서 다룬 것과 같다. 되돌릴 수 있는 행동인가, 되돌릴 수 없는 행동인가. 문서 초안을 쓰는 일은 잘못돼도 지우면 그만이다. 운영 데이터를 지우거나, 돈을 보내거나, 고객에게 메일을 보내는 일은 되돌리기 어렵다. 앞의 것은 자동으로 맡기고, 뒤의 것에는 사람의 승인을 건다.

Section Ⅲ · Report and Recover사고를 말하고 되돌린다

사고는 숨기는 것이 아니라
기록하는 것이 된다

권한을 아무리 좁혀도 사고는 난다. 그래서 다음 질문은 사고가 났을 때 그 사실이 제때 올라오느냐다. 리플릿 사건에서 가장 불편한 대목도 여기에 있다. 에이전트는 사고를 낸 뒤 빈자리를 가짜 데이터로 채웠고, 복구가 불가능하다고 잘못 보고했다. 사람이 그 말을 그대로 믿었다면 복구는 더 늦어졌을 것이다.

이 문제는 곧 제도의 영역으로 들어온다. 유럽연합 AI법 제73조는 고위험 AI 시스템의 공급자에게 중대 사고를 감독 당국에 보고하도록 의무를 지운다. 원칙적으로 인지 후 15일 이내이고, 광범위한 침해에 해당하면 2일 이내, 사람이 사망한 경우에는 10일 이내다. 이 조항은 2026년 8월 2일부터 적용된다. 규제를 떠나서도 방향은 분명하다. 에이전트가 한 일은 기록으로 남고, 그 기록은 사고 뒤에 읽히게 된다.

조직 안에서 준비할 것은 세 가지다. 첫째, 에이전트의 행동 기록을 사람이 읽을 수 있는 형태로 남긴다. 무엇을 언제 어떤 권한으로 했는지가 남아야 원인을 찾을 수 있다. 둘째, 사고를 보고하는 경로를 미리 정한다. 누가 판단하고 누가 알리는지가 사고 당일에 정해지면 늦다. 셋째, 보고한 사람이 손해 보지 않게 한다. Vol. 13에서 본 것처럼, 실패를 가려내려면 실패가 먼저 말해져야 한다.

마지막으로 감독이 형식이 되지 않게 해야 한다. Vol. 41에서 본 것처럼 사람이 승인 버튼만 누르는 구조에서는 감독이라는 이름만 남는다. 승인을 요구할 행동을 적게 고르고, 그 적은 승인에 충분한 정보를 붙이는 편이 낫다. 승인 화면에 무엇을 바꾸려 하는지, 되돌릴 수 있는지, 영향 범위가 어디까지인지를 함께 보여 주는 식이다.

에이전트를 쓰지 말자는 이야기가 아니다. 가트너의 전망대로라면 몇 해 안에 일상 업무 결정의 상당 부분이 자동으로 내려진다. 그때 조직을 가르는 것은 도입의 속도보다 권한의 설계일 것이다. 넓게 열어 두고 조심하라고 당부하는 쪽과, 좁게 열어 두고 필요한 만큼 넓히는 쪽의 차이다.

리더가 물어야 할 질문은 하나로 줄어든다. 이 에이전트가 지금 할 수 있는 가장 나쁜 일은 무엇이고, 그 일이 일어나면 되돌릴 수 있는가. 답이 분명하지 않다면 권한이 이미 너무 넓은 것이다.