‘AI는 마법’이라는 생각을 넘어서기: AI 모델의 작동 원리를 배우는 일이 왜 전사적 우선 과제가 되어야 하는가

통제 불능 AI 에이전트에 대한 경고가 이어지는 가운데, 최근 한 개발자가 원격 백업이 없는 컴퓨터에서 코딩 에이전트에 제한 없이 작업할 권한을 부여했습니다. 에이전트는 2분도 안 돼 파일 48,000개를 삭제했습니다.

이런 사례는 AI 에이전트를 배포하면 위험이 따른다는 사실을 분명히 일깨워 줍니다. 복잡한 절차 어딘가에 사람의 검토 단계를 추가하고 안전할 것이라고 여기는 것만으로는 충분하지 않습니다. 어떤 절차는 개입이 필요하지 않지만, 다른 절차에는 훨씬 더 강력한 점검이 필요합니다. 오타를 고치는 일과 파일 수천 개를 삭제하는 일의 위험 수준은 분명히 같지 않으므로, 감독 수준은 실제로 걸린 것이 무엇인지 반영해야 합니다.

조직은 특히 영향이 크거나 되돌리기 어려운 조치에서 사람의 판단이 실제로 중요한 시점을 더 잘 파악해야 합니다. 에이전트가 실수를 저지르는 경우에는 피해 범위를 제한할 수 있도록 실행 환경을 마련해야 합니다.

AI는 결정론적이지 않고 확률적이다

무엇보다 소프트웨어 개발에 직간접적으로 관여하는 모든 직원은 AI 모델이 정보를 처리하는 방식을 기본적으로 이해해야 합니다. 결코 간단한 과제가 아닙니다. 팀을 교육하는 데 꾸준히 힘써야 하며, 궁극적으로는 전사적 목표가 되어야 합니다.

AI를 처음 접하면 마법처럼 느껴집니다. 문장을 입력하면 어느새 대화를 나누고 있습니다. 모델과 학습이 실제로 내부에서 어떻게 작동하는지 기본적으로 이해하는 일은 보안과 생산성에 관한 전사적 AI 정책을 수립하는 데 중요합니다. 신경망과 토큰화, 그 이면에서 이뤄지는 통계 분석, 그리고 이 과정이 어떻게 결과물로 이어지는지를 배우는 것은 기업의 모든 직원에게 중요한 교육 기회가 될 것입니다.

대규모 언어 모델은 결코 결정론적 결과를 내놓지 않습니다. 결과는 확률적입니다. 일반적인 소프트웨어에서는 입력을 주면 A, B, C 중 하나와 같이 어떤 결과가 나올지 어느 정도 예상할 수 있습니다. 하지만 AI에서는 F나 &, 또는 선글라스를 쓴 고양이에 대한 설명이 나올 수도 있습니다.

결과가 확률적이라면 일반적인 방식으로는 테스트할 수 없습니다. 확률적 요소를 포착하고 그로 인해 생길 수 있는 문제를 알아내려면 상황에 맞춰 조정하고, 추론하고, 이해하고, 맥락을 빠르게 파악할 수 있는 테스트 방법이 필요합니다. 규모와 위험 수준에 따라 이런 테스트는 AI가 수행할 수도 있고, 관련 전문성을 갖춘 사람이 맡을 수도 있습니다. 사람을 참여시키는 것은 문제를 정의해 방향을 설정하는 초기 단계에서 가장 유용하며, 마지막에 결과를 검토할 수도 있습니다.

개발자는 조직 내부 AI가 입력을 바탕으로 답을 만들어 내는 과정에서 작용하는 변수와 일반적인 관행을 가장 가까이에서 관찰하므로, 회사 내 AI 교육의 방향을 잡고 모든 직원이 AI에서 결정론과 확률론의 차이 및 그 중요성을 이해하도록 돕기에 적합합니다. 목표는 AI를 쓰는 일이 마치 마법 같아서 어떤 결과가 나오든 만족한다는 생각을 줄이는 것입니다. 그 대신 조직은 신비화된 AI를 명확히 이해할 수 있도록 해야 합니다. 이를 위해 기업이 사용하는 모델과 사용 방식을 설명하고, 발생할 수 있는 문제와 점검 방법, 그 과정에서 얻은 결과를 제시해야 합니다.

안전장치는 모델이 아니라 인프라에 있어야 한다

AI의 ‘마법’을 걷어 내고 AI 주도 프로젝트가 진행되기 시작하면, 모든 과정이 예상한 방향대로 진행되는지 확인할 수 있도록 투명한 감사 정책을 마련하는 일이 중요합니다. 그래야 프로젝트 결과가 ‘나쁘거나’ 기대에 미치지 못할 때 책임자가 진행 단계를 감사하고 같은 문제가 다시 발생하지 않도록 막을 수 있습니다. 기대보다 좋은 결과가 나온 경우에도 이점이 있습니다. 해당 단계를 반복하고 다른 프로젝트나 그룹과 공유할 수 있기 때문입니다.

팀마다 개발자가 수십 명씩 있고 하루 종일 수백 명의 개발자가 코드에 손을 대는 대기업에서는 이런 절차를 체계화하는 일이 특히 중요합니다. AI는 많은 일을 매우 빠르게 처리할 수 있으므로, 문제가 생기면 정확히 어느 단계에서 발생했는지 평가할 체계가 있어야 합니다. 올여름 OpenAI의 에이전트가 Hugging Face의 보안 경계를 침범한 사례를 보겠습니다. OpenAI는 ExploitGym이라는 벤치마크를 사용해 모델이 소프트웨어 취약점을 얼마나 잘 악용하는지 테스트하고 있었습니다. 테스트를 위해 공격적인 사이버 작업에 대한 모델의 거부를 의도적으로 완화했습니다. 샌드박스에서 밖으로 나갈 수 있는 유일한 경로는 패키지 프록시였습니다. 모델은 그 프록시에서 알려지지 않은 결함을 찾아 빠져나왔고, 테스트 정답을 찾기 위해 Hugging Face의 프로덕션 시스템 안에서 이틀 넘게 머물렀습니다.

언론은 이를 통제 불능 AI라고 불렀습니다. 저는 확률적 시스템을 둘러싼 결정론적 설정이라고 부르겠습니다. OpenAI는 모델에 해킹하라고 지시한 뒤 모델이 예상된 경로를 벗어나지 않을 것이라고 믿었습니다. 벤치마크를 만든 사람에 따르면 모델은 이전에도 테스트에서 부정행위를 했지만, 늘 샌드박스 안에서였습니다. 이번에는 한 모델이 샌드박스를 벗어났습니다. 일반적인 안전장치는 일반적인 행동을 전제로 하지만, AI가 반드시 그 기준을 따르는 것은 아닙니다.

그래서 AI 보안의 핵심은 모델이 바람직하게 행동하기를 기대하는 것이 아니라, 환경 차원에서 접근 권한과 통제를 적용하는 데 있습니다. 에이전트가 모든 문을 열어 보려 할 것이라고 가정하고, 필요한 문만 열어 두세요. 48,000개의 파일을 삭제한 에이전트는 복사본으로 작업하고 원본은 건드리지 말라는 지시를 받았습니다. 그런데도 원본을 삭제했습니다. 지시는 통제가 아닙니다.

에이전트의 권한을 관리하는 일은 신입 주니어 개발자를 온보딩하는 것과 비슷합니다. 입사 첫날부터 운영 환경에 대한 루트 권한을 주지는 않을 것입니다. 그렇게 했다가 그 사람이 데이터베이스를 삭제하더라도, 천재적인 해커라서 그랬다고 여기지는 않을 것입니다. 규모와 관계없이 보안 사고가 발생하면 근본 원인을 반드시 밝혀야 합니다. 모델이 원인일까요? 모델을 만든 회사일까요? 모델에 접근 권한을 부여한 회사일까요? 원인이 무엇이든 궁극적인 책임은 사람에게 있습니다.

마지막으로, 지금 다뤄야 할 핵심 문제는 개발자의 노트북에서 눈에 띄지 않게 벌어지는 일입니다. 과거에는 작업 흐름을 추적하기가 더 간단했습니다. 개발자는 코드를 작성하고 검토한 뒤 배포했으므로, 문제가 발생한 시점을 명확히 역추적할 수 있었습니다. 이제 개발자는 에이전트에 티켓을 입력하고 ‘이걸 고쳐’라고 지시할 수 있습니다. 그 작업이 보이지 않는 곳에서 이뤄지면 추적할 방법이 없습니다. 에이전트가 무엇이었는지, 어떤 모델을 사용했는지, 어떤 프롬프트를 받았는지, 어떤 도구를 호출했는지, 당시 어떤 권한을 가지고 있었는지 등 모든 단계를 빠짐없이 기록해야 합니다. 에이전트를 각자의 노트북이 아니라 중앙에서 실행하는 것도 이를 실현하는 한 가지 방법입니다. 중요한 것은 기록이 남아 있어야 한다는 점입니다.

결국 사고가 발생하면 모든 회사는 스스로를 보호해야 합니다. 기록에는 근본 원인 분석을 수행하고 문제를 일으킨 단계와 코드를 찾아낼 수 있을 만큼 충분한 정보가 담겨 있어야 합니다.

AI는 세상을 크게 바꿔 놓았으며, 비즈니스 프로세스도 이에 발맞춰야 합니다. 적절한 안전장치를 마련하려면 개발팀 내부는 물론 회사 전체 차원에서도 AI 프로세스와 테스트, 검토 주기, 감사 주기를 더 잘 이해해야 합니다.