아무도 감시하지 않는 AI 에이전트의 보안 위기
기업 AI의 현실, 즉 AI가 마침내 프로덕션 시스템에 도달하는 상황에 대해 많은 이야기가 오가고 있다. 아직 인식하지 못하는 사람도 있지만 이 현실(또는 악몽)은 이미 진행되는 중이다.
모두 시작은 “파일럿”, “프로토타입”, 또는 “사이드 프로젝트”다. 누군가 에이전트로 내부 대시보드를 구축한다. 이 대시보드가 빠르게 필수적인 도구로 퍼지면서 실험이었던 것이 갑자기 프로덕션이 된다. 이 과정에서 누구도 재미없고 불편한 질문, “npm, PyPI, 또는 도커 허브에서 정확히 무엇을 가져왔는가? 인증은 어떻게 구성되는가(또는 구성돼 있었는가)? 에이전트가 선택하는 툴과 라이브러리를 대상으로 한 공급망 공격을 감시하는 사람이 있는가?”를 묻지 않는다.
게다가 일회성 프로젝트나 한두 개의 애플리케이션에 그치는 사안이 아니다. AI는 기업이 전보다 더 많은 코드를 생성하고 더 많은 제품과 프로젝트를 더 빠르게 출시할 수 있게 해준다. 보안 팀이 주의를 기울일 때쯤이면 사업부는 이미 AI에 묶여 되돌아갈 수 없는 상태다. 진짜 악몽이 시작된 것이다.
악몽을 현실화하는 중대한 문제는 세 가지로나눌 수 있다.
명시적으로 선택하지 않은 구성요소
AI 에이전트에 앱 빌드를 요청하면 에이전트는 단순히 하나의 스크립트만 내놓는 것이 아니다. 사용자가 기술한 문제를 중심으로 하나의 온전한 생태계를 소리없이 구성한다. 웹 프레임워크를 끌어오고 이런저런 라이브러리를 가져오고 데이터베이스를 설정하고, 이후 모든 것을 여러 컨테이너 이미지의 종속 항목을 기반으로 빌드한다.
생산성 관점에서는 훌륭하다. 그러나 보안 관점에서는 아무리 긍정적으로 말해도 걱정스럽다. 필자 스스로 이런 방식으로 앱을 빌드한 적이 있는데, 사용되는 모든 구성요소를 누군가에게 말해주려면 다시 돌아가 에이전트에 일일이 물어봐야 했다.
지금은 누구나 npm이나 PyPI에 게시할 수 있는 세상이다. 그리고 알려진 바와 같이 공격자는 이런 생태계에 악성 패키지를 슬쩍 집어넣거나 널리 사용되는 패키지를 침해하곤 한다. 최근 발생한 몇몇 사고를 보면 보안 및 데브옵스 툴 자체가 침해된 종속 항목을 가져와서 승격된 권한으로 CI/CD 파이프라인에서 실행해 조용히 기밀을 탈취하거나 빌드를 변조했다. 필자는 몇 달 전 이와 같은 종류의 침해를 직접 경험했고 그 여파로 깃허브의 모든 자격증명을 업데이트해야 했다.
검증되지 않은 코드를 끌어오는 것도 나쁜데, 이제 그 위에 AI 에이전트까지 얹혀 있다. 에이전트는 가장 쉽게 발견하고 통합할 수 있는 것을 기본값으로 설정한다. 또한 어떤 패키지가 직면한 문제를 해결한다면 에이전트는 그 패키지를 추가한다. “인터넷에서 무작위 라이브러리를 다운로드하는” 문제는 예전부터 있었지만 이제는 자동으로, 그리고 대규모로, 이전까지 본 적 없는 속도로 이뤄진다.
이 문제를 해결하려면 에이전트에 위험 용인 성향, 승인된 구성요소 목록, 로깅에 대한 요구 사항 등에 대한 감각을 제공해야 한다. 스펙 파일과 업계 모범 관행을 사용하면 된다. 통칭 하네스 엔지니어링이라고 하는 이 부분에 대해서는 뒤에서 추가로 다룰 것이다.
코드에서 아키텍처로의 역량 전환
초급 개발자가 할 만한 코딩을 AI가 모두 해준다면 초급 개발자가 과연 코딩을 배우기는 할 것인지에 대해 많은 우려가 있다.
필자의 걱정은 다르다.
필자는 에이전트가 코드를 출력하도록 하는 것은 괜찮다고 생각한다. 에이전트가 정말 잘 하는 일이기 때문이다. 에이전트가 잘 못하는 일은 코드 내의 문제를 파악하고 피하는 것이다.
필자는 한동안 코드를 작성하지 않았다. 할 수는 있지만 직접 코딩은 합리적이지 않다. 시간을 들일 가치가 있는 일은 에이전트가 바보같은, 심지어 위험한(또는 둘 다에 해당하는) 제안을 할 때 그 위험 신호를 알아채는 일이다.
예를 들어 최근 한 개인적인 프로젝트 작업에서 에이전트는 필자에게 메모리 서버를 인증 없는 공용 인터넷에 노출할 것을 제안했다. 에이전트가 아주 매끄럽게 이런저런 요소를 연결해 두었기 때문에 얼핏 모든 것이 괜찮고 잘 작동하는 것처럼 보였다. 그러다가 문득 생각이 나서 작업을 멈추고 물었다. “잠깐, 이게 인증이 실제로 어떻게 이뤄지는 거지? 이 흐름의 어느 위치에서 비밀번호, 비밀 토큰, 또는 OAuth가 사용되지?” 알고 보니 인증이 이뤄지지 않고 있었고 비밀번호도 없었다. 필자가 잠시 멈추고 에이전트와 한동안 이 부분에 대해 논쟁하지 않았다면 문제의 앱은 아무런 보호 장치 없이 라이브로 실행됐을 것이다.
결국 스킬을 둘러싼 관건은 우리가 코딩 능력을 잃게 되는지 여부가 아니라, 질문을 던지고 포착할 능력이 있는지, 그리고 뭔가 잘못된 것처럼 보이거나 느껴질 때 그 사실을 감지할 이해력을 갖췄는지 여부다. 에이전트가 위험한 소프트웨어 패턴을 제안할 때 그 패턴을 알아챌 사람이 기업에 있는가? 인증 흐름이 지나치게 느슨할 때, 데이터 저장소가 특정 경계 너머로 노출되면 안 될 때, 그리고 아키텍처가 기술 부채 더미가 되어 전체 레이어를 버리고 다시 빌드하는 것이 정답일 때를 인지할 수 있는 사람이 필요하다.
“잘 작동한다”가 “안전하다” 또는 “바람직하다”와 동의어가 아님을 알고 이 둘이 상충할 때 에이전트에 맞서 반박할 수 있는 사람이 필요하다.
결국 핵심은 구문의 문제가 아니라 아키텍처, 공급망 인식, 그리고 프로토타입이 표면적으로 괜찮아 보이는 상황에서도 “다 부수고 제대로 다시 하겠다”고 말할 수 있는 의지에 관한 문제다. AI를 보조로 활용하는 코더에게 기본적인 보안 원칙과 아키텍처 패턴을 가르쳐야 한다. 코더가 AI에 질문을 계속 던져야만 AI는 코더에게 더 높은 수준의 내용을 가르쳐주게 된다.
하네스가 없는 에이전트
세 번째 문제는 매우 강력한 힘을 가진 몇몇 에이전트를 개발 워크플로우에 자유롭게 풀어놓으면서 이런 에이전트를 거버넌스가 필요한 주요 행위자로 취급하지 않았다는 점이다.
많은 기업이 리포지토리나 IDE에 AI 어시스턴트를 연결해서 AI 어시스턴트가 프로젝트와 파이프라인의 구조를 설계하도록 한다. 여기에 보안 스캐너를 덧붙이고 “AI 도입 완료”를 선언하는 경우도 있다. 그러나 이런 방식은 거버넌스 모델이 아니라 낙관주의이며, 심지어 조심스러운 낙관주의도 아니다.
실제로 리포지토리, CI/CD 파이프라인, 아티팩트 레지스트리에 광범위하게 접근할 수 있는 코드 생성 에이전트는 비유하자면 인터넷에 접근할 수 있고 기업 정책에 대한 감각이 없으며 매우 생산적이지만 교육을 제대로 받지 못한 초급 개발자와 같다. 코드 생성 에이전트는 여러분의 검토 프로세스에서 처리할 수 있는 속도보다 더 빠르게 새로운 툴, 새로운 종속성, 새로운 패턴을 끌어들일 수 있다.
필자는 개인 프로젝트를 진행하면서 이 문제를 AI 코더가 말하는 하네스 엔지니어링 문제로 생각하기 시작했다. 코드를 빌드하거나 연결하는 역할을 담당하는 모든 에이전트에 대해 필자는 적어도 개념적으로는 빌드 결과를 검토하고 해체하는 역할을 담당하는 다른 에이전트도 함께 루프 안에 두려고 노력한다. 예를 들어 한 에이전트는 보안에 집중하면서 명백한 취약점과 잘못된 관행을 찾는다. 또 다른 에이전트는 아키텍처를 살펴보고 앱 설계가 유지관리가 불가능한 영역으로 이탈할 때 지적한다. 세 번째 에이전트는 성능과 신뢰성 문제를 살펴보는데, 서비스 거부나 리소스 고갈 등의 상황을 생각해 보면 그 자체도 일종의 보안 문제라고 할 수 있다. 이것을 에이전트에 아키텍처, 보안, 설계에 대한 제1 원칙을 제공하는 규칙과 결합하면 더 이상 바이브 코딩이 아니라 모든 프로젝트를 위한 대규모 하네스 엔지니어링이 된다.
필자가 하는 방식이 완벽하지는 않다. 이 분야에는 애초에 완벽이 존재하지 않는다. 비결정론적이고 통계적인 툴이기 때문이다. 그러나 많은 기업은 그조차 하지 않고 있다. 사실상 이런 기업의 에이전트는 프리랜서로 움직인다. 또한 바이브 코딩을 하며, 신뢰할 수 있는 레지스트리나 강화된 기본 이미지에 얽매이지도 않는다. 보안 팀이 감사할 수 있도록 자신의 의사결정을 기록할 의무도 없다. 누구도 하네스를 소유하지 않는다. 즉, 원래 인간이 했던 많은 구현 의사결정이 아무도 감시하지 않는 시스템으로 완전히 옮겨갔다.
기업 AI 보안에 요구되는 새로운 사고방식
기업 AI에서 상상할 수 있는 최악의 시나리오는 사람을 해치는 로봇이 아니라, 속도가 폭발적으로 증가하는 그 순간 스스로의 환경에서 어떤 일이 일어나고 있는지 보고 통제하는 능력을 상실하는 것이다. 위험은 자기 결정권을 양도하는 데 있고, 기업 내외부 고객이 좋아하고 계속 사용하고 싶어하지만 본질적으로 안전하지는 않은 애플리케이션을 그대로 내보내는 데 있다. 지금 이 순간에도 여러분 기업의 누군가는 AI를 사용해 강력한 앱을 빌드하면서 알 수 없는 곳에서 알 수 없는 뭔가를 가져와 인프라에 덧붙이고 있을 것이다.
다행히 이런 문제는 포착이 가능하다. 해결도 가능하다. 다만 그러기 위해서는 기존 문제를 해결하던 방식과는 다른 새로운 형태의 사고가 필요하다. 통계적으로 사고해야 하며, 가장 중요한 원칙이 포함된 규칙을 선언해야 한다. 신뢰할 수 있는 스택과 레지스트리를 표준화하고, 단순히 “안전한 코딩”이 아닌 아키텍처 보안을 중심으로 사람들을 재교육하고, 에이전트 하네스를 설계 검토와 편집이 필요한 시스템으로 취급할 수 있다.
