지난 글에서 에이전트에게 브라우저를 쥐여 줄 때의 이야기를 했다. 그 글의 마지막 절에서 「API가 있으면 API를 쓴다」고 했는데, 그 말을 끝까지 밀면 결국 에이전트에게 코드를 짜서 돌리게 하는 자리에 닿는다. 화면을 스무 번 누를 일을 열 줄짜리 스크립트 하나가 끝내기 때문이다.
그리고 그 순간 문제의 성격이 바뀐다. 모델이 잘못 판단해서 엉뚱한 버튼을 누르는 것과, 모델이 짠 코드가 우리 서버에서 아무 제약 없이 도는 것은 위험의 크기가 다르다. 이 글은 그 코드를 어디서 돌릴 것인가에 대한 이야기다.
왜 「모델이 조심하면 된다」가 답이 아닌가
먼저 짚어 둘 것이 있다. 프롬프트에 「위험한 명령은 실행하지 마세요」라고 적는 것은 방어가 아니다. 이유가 셋이다.
첫째, 모델은 악의 없이도 지운다. 임시 파일을 정리하라는 지시에 상위 폴더를 지우는 코드를 쓰는 일은 사람도 한다. 나쁜 뜻이 있어야 사고가 나는 것이 아니다.
둘째, 지시가 밖에서 들어온다. 지난 글에서 본 간접 프롬프트 주입은 여기서 훨씬 세게 작동한다. 웹 페이지나 내려받은 문서에 심긴 글자가 모델의 문맥에 들어오고, 모델은 그 글자대로 코드를 짤 수 있다. 브라우저 에이전트에서는 잘못 눌린 버튼 하나였지만, 코드 실행에서는 임의의 명령이 된다.
셋째, 프롬프트는 실행 시점의 방어가 아니다. 모델이 아무리 얌전해도, 코드가 실제로 도는 자리에서 파일을 지울 수 있으면 지워진다. 막는 것은 프롬프트가 아니라 그 코드가 도는 환경이다.
격리를 어디까지 세울 것인가
격리에는 단계가 있고, 세워 갈수록 막히는 것이 늘고 띄우는 시간도 는다.
같은 프로세스는 우리 서비스 안에서 exec로 바로 돌리는 것이다. 편하고 빠르지만 막히는 것이 하나도 없다 — 우리 프로세스의 변수, 열려 있는 DB 연결, 환경 변수의 키가 전부 그 코드의 손 안에 있다. 모델이 만든 코드에는 쓰지 않는다.
별도 프로세스는 권한이 낮은 사용자로 자식 프로세스를 띄우는 것이다. 우리 메모리는 분리되지만 디스크와 네트워크는 같이 쓴다. 언어 런타임 안의 「제한된 실행 모드」도 여기에 속하는데, 파이썬이든 자바스크립트든 같은 런타임 안에서 자기를 가두는 시도는 반복해서 뚫려 왔다. 신뢰 경계로 삼지 않는다.
컨테이너가 실무의 기본값이다. 파일 시스템·네트워크·프로세스 목록이 따로 파이고, 0.1~1초면 뜨고, 다 쓰면 통째로 버린다. 남는 위험은 커널을 공유한다는 점이라 커널 취약점이 있으면 뚫릴 수 있다.
가상 머신은 커널까지 분리한다. 요즘은 수 초가 아니라 100밀리초 안팎에 뜨는 가벼운 가상 머신(microVM)이 있어서 예전만큼 비싸지 않다. 모르는 사람이 준 코드를 돌린다면, 즉 남의 입력이 그대로 코드가 되는 서비스라면 여기까지 온다.
고르는 기준은 누가 그 코드에 영향을 줄 수 있는가다. 우리 팀이 쓰는 내부 도구면 컨테이너로 충분하고, 바깥 사용자의 입력이 코드로 흘러 들어가는 구조면 가상 머신을 본다.
나가는 길은 넷이다
「샌드박스에 넣었다」는 말이 실제로 뜻하는 것은 이 넷을 각각 닫았다는 것이다.
파일. 컨테이너를 띄우면서 소스 폴더를 통째로 붙여 버리면 격리가 무의미해진다. 필요한 것만 읽기 전용으로 붙이고, 쓸 수 있는 곳은 그 작업만을 위한 폴더 하나로 둔다. 그 폴더는 작업이 끝나면 버린다.
네트워크. 가장 자주 열려 있는 문이다. 컨테이너의 기본 설정은 밖으로 나가는 연결을 다 열어 주고, 그러면 사내망의 관리 화면·데이터베이스·클라우드 메타데이터 주소가 전부 사정권에 든다. 기본은 전부 막고 필요한 주소만 하나씩 여는 쪽이어야 한다. 패키지를 받아야 하면 사내 미러 하나만 열면 된다.
자격 증명. 환경 변수에 API 키를 넣어 두는 습관이 여기서 문제가 된다. 샌드박스 안의 코드는 환경 변수를 그대로 읽는다. 키는 밖에 두고, 안에는 범위가 좁고 짧게 사는 토큰만 넣는다. 더 나은 방법은 아예 넣지 않고 바깥의 프록시가 요청에 자격 증명을 붙여 주는 것이다 — 안에서는 키를 본 적이 없으니 새어 나갈 것도 없다.
자원과 시간. 무한 루프나 메모리를 끝없이 먹는 코드는 악의가 아니라 그냥 자주 나온다. CPU·메모리·실행 시간에 상한을 걸고 넘으면 끝낸다. 상한이 없으면 사고 하나가 서비스 전체를 세운다.
넷의 규칙이 사실 하나다. 기본은 막고 필요한 것만 연다. 반대로 「위험한 것만 막는다」로 접근하면 빠뜨린 자리가 그대로 구멍이 된다. 무엇이 위험한지 다 적을 수 있다는 가정이 틀렸기 때문이다.
무엇을 돌려받을 것인가
격리 이야기가 나가는 길에 집중되다 보니 돌아오는 길을 놓치기 쉽다. 샌드박스에서 실행한 결과는 다시 모델의 문맥으로 들어간다.
여기서 두 가지를 한다. 하나는 크기를 자르는 것이다. 10만 줄짜리 로그가 그대로 문맥에 들어오면 그 자리에서 예산이 끝난다. 앞뒤 몇십 줄만 남기고 「중간 9만 줄 생략」이라 적는 편이 낫다 — 문맥 예산 세우기에서 다룬 이야기가 여기서도 그대로다.
다른 하나는 그 출력이 지시가 아니라 자료임을 표시하는 것이다. 실행 결과에도 남이 심어 둔 글자가 섞여 들어올 수 있다. 파일 목록에 README_먼저_읽으세요.txt 같은 이름이 있고 그 안에 지시가 적혀 있는 식이다. 결과는 결과라고 표시해 넣는다.
샌드박스가 막아 주지 않는 것
가장 흔한 오해를 마지막에 짚어 둔다. 샌드박스는 「그 코드가 밖을 부수지 못하게」 하는 장치이지, 「그 코드가 하는 일이 옳은지」를 보는 장치가 아니다.
우리가 도구로 열어 준 것은 샌드박스 안에서도 그대로 된다. 이메일을 보내는 도구를 줬으면 이메일이 나가고, DB에 쓰는 권한을 줬으면 데이터가 바뀐다. 격리는 그것을 막지 않는다 — 막으라고 만든 것이 아니다.
| 샌드박스가 막는 것 | 막지 않는 것 |
|---|---|
| 우리 서버의 파일을 지우는 것 | 우리가 준 도구로 파일을 지우는 것 |
| 사내망을 훑는 것 | 우리가 열어 준 주소를 부르는 것 |
| 환경 변수의 키를 읽는 것 | 우리가 넣어 준 토큰을 쓰는 것 |
| 서버 자원을 다 먹는 것 | 상한 안에서 비싼 일을 반복하는 것 |
그래서 격리와 별개로 권한을 좁히는 일이 항상 함께 간다. 도구를 몇 개 줄 것인가, 그 도구의 계정에 어떤 권한이 붙어 있는가, 되돌릴 수 없는 동작 앞에 사람이 서는가. 이 부분은 에이전트 아키텍처와 가드레일 출력 검증 쪽에서 다뤘다.
실무에서 자주 놓치는 자리
정리 대신 마지막으로, 구축해 놓고도 새는 자리들을 적어 둔다.
- 샌드박스를 재사용한다. 앞 작업이 남긴 파일과 상태가 다음 작업에 보인다. 작업마다 새로 띄우고 끝나면 버린다
- 로그를 밖에 그대로 쌓는다. 안에서 나온 출력에 남의 데이터가 섞여 있을 수 있다. 로그도 다루는 대상이다
- 패키지 설치를 열어 둔다. 임의의 패키지를 받을 수 있으면 네트워크를 막은 의미가 절반 사라진다. 미리 담긴 이미지를 쓰거나 사내 미러만 연다
- 시간 상한만 걸고 호출 횟수를 안 센다. 1초짜리 API 호출을 10분 동안 부르면 상한 안에서 요금이 쌓인다
- 개발 환경에서만 켠다. 격리는 운영에서 더 필요하다. 「일단 로컬에서는 그냥 돌리자」가 그대로 배포된다
읽어주셔서 감사합니다. 😊