AI 에이전트의 두뇌는 모래상자 밖에 있어야 한다

요즘 AI 에이전트를 직접 돌려보는 분들이라면 한 번쯤 마주쳤을 질문이 있습니다. “이놈이 내 컴퓨터에서 무슨 짓을 할지 어떻게 믿지?” 4월 말 ScaleUp Sage 채널에 올라온 “Why We Can’t Trust AI Agents Yet” 영상이 16,000회 넘는 조회수를 기록하며 화제가 된 것도 같은 맥락인데요. 단순히 “에이전트가 똑똑하냐"가 아니라, “에이전트를 어떻게 가둬둘 것이냐"는 아키텍처 논쟁이 본격적으로 시작됐습니다.

하네스 엔지니어링이라는 새로운 분야

에이전트 업계에서 하네스(harness)라는 용어가 자리 잡고 있습니다. 모델 자체가 아니라, 모델을 감싸서 도구를 호출하고 권한을 통제하고 결과를 검증하는 바깥 껍데기를 가리키는데요. 영상 제목 그대로 “Harness Engineering Explained"라는 표현이 등장할 정도로, 이제 에이전트의 신뢰성은 모델 성능보다 하네스 설계에 달렸다는 인식이 확산되고 있습니다.

쉽게 말하면 이렇습니다. 모델은 운전수, 하네스는 차량과 도로 시스템. 운전수가 아무리 똑똑해도 브레이크가 없거나 차선이 그어져 있지 않으면 사고가 납니다. AI 에이전트도 마찬가지여서, 파일을 읽고 명령어를 실행하고 외부 API를 호출하는 모든 동작은 하네스가 통제해야 한다는 거죠.

모델을 샌드박스 안에 넣어야 할까, 밖에 둬야 할까

여기서 논쟁이 갈립니다. 전통적인 보안 관점에서는 “위험한 것은 안에 가둬라”입니다. 모델 추론과 도구 실행을 통째로 컨테이너나 가상머신 안에 넣고, 바깥세상과는 좁은 통로로만 통신하게 하는 방식이죠. 클라우드 코딩 도구들이 흔히 쓰는 접근입니다.

반대 진영의 주장은 정반대입니다. 두뇌는 밖, 손발만 안이라는 거죠. 모델 추론은 호스트 측에서 돌리고, 코드 실행이나 파일 시스템 접근 같은 위험한 액션만 샌드박스 안에서 수행시킨다는 발상입니다. 이렇게 하면 모델이 프롬프트 인젝션 공격으로 오염된 출력을 받더라도, 그 출력으로 할 수 있는 일이 좁은 도구 인터페이스로 제한됩니다.

왜 이 구분이 중요한가

핵심은 신뢰 경계(trust boundary)를 어디에 긋느냐입니다. 모델을 샌드박스 안에 넣으면, 샌드박스 내부의 모든 것이 한꺼번에 오염될 수 있습니다. 악성 웹페이지를 읽은 모델이 곧바로 같은 샌드박스 안의 셸을 호출해 데이터를 탈취하는 시나리오가 가능하다는 거죠.

반대로 모델을 바깥에 두면, 모델이 어떤 의도를 가지든 결국 하네스가 정의한 도구 호출만 가능합니다. 호스트가 “이 명령어는 허용, 저 명령어는 거부” 같은 정책을 강제할 수 있고요. 4월 10일자 The Automated Daily의 “Agent benchmarks get stricter” 보도에서도 이런 흐름이 감지됩니다. 평가 기준 자체가 “에이전트가 작업을 잘하는가"에서 “에이전트가 의도된 권한 안에서만 움직이는가"로 옮겨가고 있다는 뜻이죠.

프롬프트 인젝션이라는 영원한 숙제

같은 영상에서 흥미롭게 다뤄진 또 다른 사례가 있습니다. 가짜 질병으로 AI 챗봇을 속인 실험인데요. 존재하지 않는 의학 용어를 그럴듯하게 제시하자 챗봇이 자신 있게 잘못된 처방을 늘어놓더라는 겁니다. 이게 그냥 챗봇 단계라면 농담거리지만, 같은 모델이 처방전을 자동으로 약국에 전송하는 에이전트라면 사고로 직결됩니다.

여기서 다시 아키텍처 질문이 돌아옵니다. 모델 출력이 곧바로 행동으로 이어지는 구조라면, 샌드박스 위치와 무관하게 위험합니다. 결국 “행동을 일으키는 출력은 항상 하네스의 검증을 통과해야 한다”는 원칙이 더 본질적인 셈이죠.

정리하자면

AI 에이전트의 안전은 모델 성능 문제가 아니라 시스템 디자인 문제로 넘어왔습니다. 두뇌를 어디에 둘지, 손발에 어떤 권한을 줄지, 출력을 어떻게 검증할지가 핵심 설계 변수가 됐고요. 한동안은 두 진영이 팽팽할 겁니다.

여러분이 에이전트를 직접 만들고 있다면 한 가지만 자문해보시죠. “내 에이전트가 가장 똑똑한 적의 손에 들어간다면, 무엇까지 할 수 있을까?” 이 질문에 답이 떠오르지 않는다면, 하네스부터 다시 그릴 때입니다.