생성형 AI가 실제로 어떤 방향으로 가고 있는지 알고 싶다면, 업체의 보도자료가 아니라 실제 현장에서 개발자가 무엇을 만들고 있는지 봐야 한다. 오픈소스 데이터 퍼블리싱 프로젝트인 데이터셋(Datasette)의 설립자 사이먼 윌리슨은 그 ‘현실에 가장 가까운’ 대표적인 인물이다.

블로그를 통해 오랜 시간 AI 개발의 흐름을 기록하고 있는 윌리슨은 우리가 지금 AI를 다루며 저지르는 근본적 실수가 과거 웹 2.0 시대의 그것과 같다고 지적한다. 데이터와 명령어를 동일하게 취급한다는 이야기다. 이 착각이 과거에는 SQL 인젝션이라는 취약점을 낳았다면, 지금은 프롬프트 인젝션, 데이터 탈취, 그리고 ‘자신만만하게’ 잘못된 일을 대규모로 수행하는 AI 에이전트를 만들어내고 있다.

윌리슨이 관찰한 현장을 바탕으로 보면, 현재 AI 에이전트 전략 대부분은 ‘보안 악몽’에 가깝다. 하지만 약간의 지루하고 기본적인 엔지니어링으로 이를 해결할 방법은 분명히 존재한다.

프롬프트 인젝션은 새로운 SQL 인젝션

윌리슨은 지난 10월 ‘클로드 코드를 위험하게 실행하기(Running Claude Code Dangerously)’라는 강연을 진행했다. 이 강연은 왜 AI 에이전트가 동시에 ‘흥미롭고도 두려운 존재’인지를 잘 보여주는 사례로 꼽힌다.

윌리슨은 이른바 ‘YOLO 모드’라 부르는 개발 방식이 가져오는 폭발적인 생산성 향상을 설명하면서도, 곧장 그만큼의 위험성을 지적했다. “프롬프트 인젝션은 여전히 믿기 어려울 만큼 흔한 취약점”이라는 것이다. 윌리슨은 프롬프트 인젝션을 “오늘날의 SQL 인젝션”이라고 표현하며 AI 에이전트 보안의 핵심 약점을 ‘치명적 3요소(lethal trifecta)’이라 부른다.

윌리슨의 설명에 따르면, 시스템이 다음 3가지 조건을 모두 갖추고 있다면 이미 공격 노출 상태에 있다고 봐야 한다.

• 이메일, 문서, 고객 기록 등 개인 데이터에 접근할 수 있는 권한
• 웹이나 수신 이메일, 로그 등 신뢰할 수 없는 콘텐츠에 접근하는 경로
• 이메일 전송, 코드 실행 등 해당 데이터를 기반으로 행동을 수행할 수 있는 능력

이 문제는 이론이 아니라 현실이다. 심지어 그리 특별한 상황도 아니다. 만약 당신의 에이전트가 파일을 읽거나, 웹페이지를 스크래핑하거나, 티켓을 열거나, 이메일을 전송하거나, 웹훅을 호출하거나, 깃허브에 커밋을 푸시할 수 있다면, 이미 신뢰할 수 없는 입력 채널을 통해 명령 주입 공격에 취약한 자동화 시스템을 운영하고 있는 셈이다. 이것을 ‘프롬프트 인젝션’이라 부르든, ‘간접 프롬프트 인젝션’이라 하든, 혹은 ‘혼란스러운 대리인(confused deputy)’이라 칭하든 명칭은 중요하지 않다. 중요한 것은 그 구조다.

AI로 AI 공격을 탐지하겠다는 시도는 겉보기엔 그럴듯하지만, 실제로는 일종의 ‘마법적 사고’에 불과하다고 여러 보안 전문가는 지적한다. 보안 커뮤니티는 이미 1년 전부터 “이런 방어책 상당수가 적응형 공격 앞에서는 무력화된다”라고 경고했다.

2025년 6월 발표된 한 연구 논문은 이 사실을 더욱 분명히 드러냈다. 연구진이 공격 방식을 방어 시스템에 맞춰 조정하자, 최근 제안된 여러 방어 기법이 대부분 무력화됐고, 공격 성공률이 90%를 넘는 경우도 다수였다.

즉, 지금 우리가 구축하고 있는 자율형 AI 시스템은 본질적으로 ‘혼란스러운 대리인’이 될 준비가 된 상태다. 기업이 해야 할 일은 더 정교한 프롬프트 설계가 아니다. 네트워크 격리, 샌드박싱, 그리고 “모델은 이미 침해됐다”라는 가정 하에서의 방어 전략이 진짜 해법이다.

중요한 것은 새로운 기술이 아니라 우리가 잘 알고 있던 기본적인 보안 위생으로 돌아가는 일이다. AI가 환상을 만들어냈을 뿐, 보안의 원칙은 예전과 다르지 않다.

컨텍스트는 기능이 아니라 버그다

개발자 사이에는 컨텍스트가 많을수록 좋다는 안이한 전제가 자리 잡고 있다. 구글의 제미나이나 앤트로픽의 클로드가 200만 토큰짜리 컨텍스트 창을 지원한다고 발표하면 사람들은 환호한다. 이제 코드베이스 전체를 프롬프트에 넣을 수 있게 됐다는 이유에서다.

멋지지 않은가? 사실, 그렇지 않다.

필자가 여러 차례 지적했듯이 컨텍스트는 마법 같은 기억력이 아니다. 일종의 의존성이다. 컨텍스트 창에 토큰을 하나 더 추가할 때마다 혼란, 환각, 인젝션 공격의 가능성은 커진다. 윌리슨은 컨텍스트는 공짜가 아니며, 오염 벡터라고 말한다.

최근 등장하는 베스트 프랙티스는 더 큰 프롬프트가 아니라 더 나은 아키텍처를 다루는 데 초점을 맞춘다. 범위가 명확히 정의된 도구, 작고 명시적인 컨텍스트, 격리된 워크스페이스, 그리고 지속성이 필요한 데이터를 저장할 수 있는 별도의 공간이 필요하다. 다시 말해, 컨텍스트를 다루는 규율이란 모델이 볼 수 있는 정보를 적극적으로 잘라내는 시스템을 구축하는 것이다. 토큰은 필요하지만 대량으로 저장할 때 위험하다는 점을 인식해야 한다.

메모리는 결국 데이터베이스 문제

윌리슨은 이를 ‘컨텍스트 오프로딩(context offloading)’이라고 부른다. 이는 AI의 메모리는 결국 데이터 엔지니어링 문제라는 필자의 주장과도 맞닿는다. 윌리슨에게 컨텍스트 오프로딩이란, 예측 불가능한 프롬프트에서 상태(state)를 제거해 안정적이고 영속적인 저장소로 옮기는 과정이다. 하지만 현재 많은 팀이 이 과정을 그저 ‘바이브’에 의존해 처리한다. JSON 데이터를 벡터 스토어에 던져 넣고 그것을 메모리라고 부르는 식이다.

이 두 가지 흐름을 결합해보면 다음과 같은 결과가 나온다.

• 컨텍스트는 공짜가 아니기 때문에 상태를 외부로 오프로딩해야 한다.
• 상태를 외부로 옮긴다는 것은 곧 메모리 저장소를 구축하는 일이다. 이는 보통 벡터 스토어지만, 때로는 하이브리드 스토어나 임베딩과 메타데이터를 포함한 관계형 데이터베이스일 수도 있다.
• 그 저장소는 에이전트의 ‘뇌’이자 동시에 공격자의 주요 표적이 된다.

에이전트에 메모리를 추가하는 현재의 방식은 초기 웹 애플리케이션이 SQL을 폼(form)에 덧붙이던 시절과 다르지 않다. 빠르고 낙관적이지만, 입력 검증(input sanitization)은 거의 이뤄지지 않는다. 메모리는 또 하나의 데이터베이스 문제일 뿐이다. 데이터베이스는 수십 년간 수많은 보안 교훈을 쌓아왔다. 최소 권한 원칙, 행 단위 접근 제어, 감사, 암호화, 보존 정책, 백업 및 복구, 데이터 출처, 거버넌스 등 말이다.

이런 오랜 경험의 ‘흉터’가 바로 오늘날 AI 메모리 설계에 가장 먼저 적용돼야 할 원칙이다.

메모리는 단순히 “지난번에 우리가 무슨 대화를 나눴는가?”를 기억하는 기능만이 아니다. 그것은 정체성, 권한, 워크플로우 상태, 도구 사용 기록, 그리고 시스템이 무엇을, 왜 했는지에 대한 지속적인 기록까지 모두 포함한다. 에이전트가 왜 환각을 일으켰는지를 디버깅하기 위해 메모리 상태를 재현할 수 없다면, 그것은 ‘시스템’이 아니라 ‘카지노’에 불과하다.

‘바이브’로 만든 결과를 진짜 작동하게 만들기

윌리슨은 종종 AI 낙관론자로 묘사된다. AI 툴을 활용해 코드를 작성하는 과정을 즐기기 때문이다. 하지만 윌리슨은 ‘바이브 코딩’과 ‘바이브 엔지니어링’을 분명히 구분한다. 차이는 하나, 엔지니어링이다.

윌리슨의 ‘저스트HTML(JustHTML)’ 프로젝트가 좋은 예다. 윌리슨은 LLM이 무작위로 코드를 뱉게 내버려두지 않았다. 그 대신 AI를 테스트, 벤치마크, 제약 조건의 하네스 안에 묶었다. 구현은 AI에 맡겼지만, 동작의 검증은 코드로 수행했다.

이는 최근 METR 연구 결과와도 맞닿아 있다. AI 코딩 도구를 사용한 개발자가 오히려 작업을 완료하는 데 더 오래 걸렸다는 것이다. AI가 만든 코드의 오류를 디버깅하는 데 너무 많은 시간을 쏟았기 때문이다. AI가 생성한 코드는 대부분 “거의 맞는” 상태이지만, 그 ‘거의’를 바로잡는 데 드는 시간은 오류의 크기에 걸맞지 않게 지나치게 오래 걸린다.

기업이 여기서 얻을 교훈은 명확하다. AI는 ‘작성–테스트–디버그’라는 개발의 순환 과정을 대체하지 않는다. 작성 단계만 가속화할 뿐이며, 그렇기 때문에 테스트 단계에 더 많은 노력을 기울여야 한다.

지루하지만 피할 수 없는 것

“API를 감싸서 바로 배포하던” 손쉬운 시절은 끝났다. 애초에 그런 시절이 존재했는지도 의문이다. 우리는 이제 AI의 데모 단계에서 산업 단계로 넘어가고 있다. 개발자가 진짜 일, 즉 유닛 테스트 같은 평가에 훨씬 더 많은 노력을 들여야 한다는 의미다. 해멀 후세인은 전체 개발 시간의 60%를 평가 작업에 써야 한다고 한다. 또한 개발자는 프롬프트 기술을 다듬는 것보다 아키텍처를 제대로 설계하는 데 훨씬 더 많은 시간을 들여야 한다.

아이러니하게도 생성형 AI가 당면한 가장 시급한 문제는 새로운 게 아니다. 오히려 오래된 문제이다. 우리는 지금 ‘컴파일러가 가끔 사실을 지어내고’, ‘마크다운 파일로 코드가 소셜 엔지니어링 공격을 받을 수 있으며’, ‘애플리케이션의 상태가 단순한 토큰 묶음으로 존재하는’ 세계 속에서, 소프트웨어 엔지니어링과 보안의 기본을 다시 배우는 중이다.

AI 모델이 놀라운 것은 사실이다. 그러나 기업 환경에서 고객 데이터베이스를 무심코 노출하지 않고 AI를 활용하려면 더 이상 그것을 마법처럼 다루어서는 안 된다. AI를 신뢰할 수 없고, 잠재적으로 위험한 구성 요소로 취급해야 한다.

윌리슨이 강조하듯, 지루하고 철저한 엔지니어링이 없다면 ‘바이브 엔지니어링’은 멋있고 감각적인 개발이 될 수 없다.
dl-itworldkorea@foundryco.com