AI가 코드를 짜는 게 위험한 게 아니다. AI에게 권한을 주는 게 위험하다

AI 코딩 도구를 쓰다 보면 가끔 이런 생각이 듭니다.

"이제 AI가 코드까지 알아서 고쳐주는데, 개발자는 점점 필요 없어지는 것 아닐까?"

그런데 최근 보안 사례들을 보면 저는 오히려 다른 문제가 더 중요해지고 있다고 생각합니다. AI가 코드를 얼마나 잘 짜느냐가 아닙니다. 우리가 AI에게 어디까지 할 수 있도록 허용할 것이냐의 문제입니다.

AI가 실수하는 것은 새로운 문제가 아니다

개발자는 원래 실수합니다. 잘못된 코드를 작성하기도 하고 설정값을 잘못 넣기도 하고 운영 환경에 문제가 있는 코드를 배포하기도 합니다.

그래서 소프트웨어 개발에는 안전장치가 여러 겹 만들어졌습니다. 개발자가 코드를 작성합니다. 그리고 리뷰합니다. 테스트합니다. CI/CD를 통과합니다. 승인합니다. 마지막으로 운영에 배포합니다.

왜 이렇게 귀찮게 만들었을까요? 사람이 실수한다는 것을 전제로 시스템을 만들었기 때문입니다.

그래서 저는 AI가 잘못된 코드를 만든다는 사실 자체는 그렇게 놀라운 문제가 아니라고 생각합니다. AI 역시 실수할 수 있습니다.

문제는 그다음입니다.

AI에게 '손'이 생기기 시작했다

초기 생성형 AI는 사실 그렇게 위험하지 않았습니다. 우리가 질문하면 답변을 만들어주는 정도였습니다. AI가 틀린 답을 하더라도 사람이 복사하지 않으면 그만이었습니다.

즉, AI → 사람 → 시스템 구조였습니다. 사람이 중간에 있었습니다.

그런데 AI Agent 시대가 되면서 구조가 달라지고 있습니다. AI가 문제를 발견하고 코드를 분석하고 수정안을 만들고 PR을 생성하고 테스트를 실행하고, 경우에 따라 배포 파이프라인까지 연결됩니다.

이제 구조가 점점 AI → 시스템으로 바뀌고 있습니다. AI에게 단순히 '머리'만 있는 것이 아니라 손이 생긴 것입니다.

여기서부터 보안 문제가 완전히 달라집니다.

최근 Autofix 사례가 흥미로운 이유

최근 Wiz 연구팀은 Snowflake의 공개 GitHub 저장소에서 스크립트 인젝션 취약점을 자율 AI 에이전트로 찾아내 시연했습니다. Wiz는 이 취약점이 GitHub Copilot Autofix 흐름과 연결된 수정에서 비롯됐다고 봤고, GitHub은 해당 기여가 사람의 작성이었다고 반박했습니다. 귀책이 어느 쪽이든, AI 생성 수정 흐름이 CI/CD 및 외부 시스템과 결합될 때 어떤 보안 위험이 생기는지 보여준 사례였습니다.

이 사례에서 제가 흥미롭게 본 것은 단순히 "AI가 잘못된 코드를 만들었다"가 아닙니다.

AI가 읽을 수 있는 정보, AI가 생성할 수 있는 변경 사항, 그리고 그 뒤에 연결된 자동화 시스템. 이 셋 사이의 신뢰 경계(Trust Boundary)가 새로운 공격 지점이 될 수 있다는 것입니다.

이건 앞으로 점점 더 중요해질 문제입니다. 왜냐하면 기업들은 지금 AI에게 점점 더 많은 일을 시키려고 하기 때문입니다.

개발자에게 root 권한을 주는 것과 비슷하다

인프라를 운영해 본 사람이라면 이 문제를 쉽게 이해할 수 있습니다. 아무리 뛰어난 개발자라도 운영 서버의 root 권한을 무조건 주지는 않습니다. 그 개발자를 믿지 못해서가 아닙니다. 사람은 실수할 수 있기 때문입니다.

그래서 RBAC을 만들고 ServiceAccount를 분리하고 Secret 접근을 제한하고 NetworkPolicy를 적용하고 배포 권한을 나눕니다.

Kubernetes가 대표적입니다. Pod 하나가 문제가 생겼다고 클러스터 전체를 마음대로 건드릴 수 있도록 만들지는 않습니다.

왜일까요? 문제 하나가 전체 시스템으로 퍼지는 Blast Radius, 즉 장애 반경을 줄이기 위해서입니다.

그런데 이상하게도 AI에는 반대로 접근하는 경우가 있습니다.

"AI가 일을 잘하려면 이것도 접근해야지."

"GitHub도 연결하자." "Jira도 연결하자." "Slack도 읽게 하자." "CI/CD도 실행하게 하자." "Cloud에도 연결하자."

AI가 유능해질수록 권한도 계속 커집니다. 이렇게 되면 어느 순간 매우 똑똑하지만 수많은 시스템에 접근할 수 있는 초대형 Privileged Account 하나를 만드는 것과 비슷해집니다.

그래서 AI 보안의 핵심은 정확도가 아닐 수 있다

많은 사람이 AI 모델의 정확도를 중요하게 봅니다. 95% 정확한 모델. 99% 정확한 모델.

하지만 운영 시스템에서는 이야기가 다릅니다. 99.9% 정확하더라도 1년에 수백만 번 작업하면 실패는 반드시 나옵니다.

엔터프라이즈 시스템은 원래 이렇게 설계합니다. "실패하지 않는 시스템"이 아니라 "실패해도 망하지 않는 시스템".

AI도 똑같아야 합니다. AI가 실수하지 않기를 기대하는 것이 아니라, AI가 실수해도 피해 범위가 제한되도록 만들어야 합니다.

저는 이것이 앞으로 AI Agent 아키텍처에서 굉장히 중요한 원칙이 될 것이라고 봅니다.

AI Agent에도 최소 권한 원칙이 필요하다

예를 들어 AI가 코드 취약점을 자동으로 발견했다고 해보겠습니다. 여기에는 권한을 여러 단계로 나눠 줄 수 있습니다.

Level 1

AI가 취약점을 발견하고 사람에게 알려준다.

Level 2

AI가 수정 코드를 제안한다.

Level 3

AI가 자동으로 PR을 생성한다.

Level 4

AI가 테스트까지 실행한다.

Level 5

AI가 승인 없이 운영에 배포한다.

기술적으로는 Level 5가 가장 멋져 보입니다. 완전 자동화니까요. 하지만 기업 시스템에서 Level 5가 반드시 가장 좋은 구조인 것은 아닙니다.

오히려 업무의 위험도에 따라 AI가 멈춰야 하는 지점을 설계해야 합니다. 결제 시스템이라면 PR 생성까지만 허용할 수도 있고, 사내 테스트 시스템이라면 자동 배포까지 허용할 수도 있습니다.

중요한 것은 AI의 능력이 아닙니다. AI의 권한과 책임 범위를 시스템이 결정해야 합니다.

앞으로 개발자의 역할도 여기에서 달라질 수 있다

AI 시대가 오면 개발자가 필요 없어질 것이라는 이야기가 많습니다. 일부 코딩 업무는 실제로 크게 줄어들 가능성이 있습니다.

하지만 반대로 더 중요해지는 역할도 있습니다. AI에게 무엇을 시킬 것인가. 어떤 데이터까지 보여줄 것인가. 어떤 시스템에 접근하게 할 것인가. 어디까지 자동화할 것인가. 어느 순간 사람의 승인을 요구할 것인가. 실패했을 때 어디까지 영향을 미치게 할 것인가.

이것들은 코딩의 문제가 아닙니다. 아키텍처의 문제입니다.

어쩌면 AI 시대의 좋은 개발자는 코드를 가장 빨리 작성하는 사람이 아니라, AI가 안전하게 일할 수 있는 시스템을 설계하는 사람이 될지도 모릅니다.

자동화의 끝에는 항상 권한 설계가 있다

우리는 오랫동안 자동화를 발전시켜 왔습니다. Shell Script에서 시작해서 CI/CD가 등장했고 Infrastructure as Code가 등장했고 Kubernetes가 등장했습니다. 그리고 이제 AI Agent가 등장하고 있습니다.

그런데 자동화가 강력해질수록 항상 같은 문제가 따라왔습니다. "이 자동화에게 어디까지 권한을 줄 것인가?"

AI라고 다르지 않습니다. 오히려 AI는 스스로 판단까지 하기 때문에 기존 자동화보다 이 문제가 더 중요합니다.

그래서 저는 앞으로 기업 AI 시스템의 경쟁력이 단순히 "어떤 AI 모델을 사용하느냐"에서 결정되지는 않을 것이라고 생각합니다. 더 중요한 질문은 이것일 수 있습니다. "그 AI를 어떤 권한 구조 안에서 움직이게 만들었는가?"

AI가 코드를 짜는 것은 무섭지 않습니다. AI가 가끔 틀리는 것도 예상 가능한 일입니다.

정말 위험한 것은, 틀릴 수 있는 AI에게 너무 많은 권한을 주고도 우리가 그것을 자동화라고 부르는 것입니다.