AI 에이전트 팀은 모델 성능에 집중합니다. 더 좋은 모델, 더 정교한 프롬프트, 더 촘촘한 평가. 그런데 정작 에이전트가 실제로 동작하는 환경은 거의 아무도 다루지 않습니다.
2015년 구글 연구자들은 “ML 코드”라고 쓰인 작은 상자가 데이터 수집, 피처 추출, 모니터링, 서빙 인프라 같은 훨씬 큰 상자들에 둘러싸인 다이어그램을 그렸습니다. 실제 기술 부채는 모델 바깥에 쌓인다는 것이었죠. AI 에이전트 시대에도 이 그림이 다시 그려지고 있습니다. 이번엔 작은 상자의 이름이 바뀌었을 뿐입니다.
AI 엔지니어 Hanchung Lee가 자신의 블로그에서 에이전트 시스템의 숨겨진 기술 부채를 분석했습니다. 모델 호출 자체는 여전히 작은 상자이고, 진짜 문제는 그 모델이 실제로 동작하는 환경, 즉 에이전트 런타임에 있다는 주장입니다.
출처: Hidden Technical Debt of AI Systems: Agent Runtime – Han, Not Solo
에이전트 런타임이란 무엇인가
많은 사람들이 에이전트를 모델과 동일하게 생각합니다. 하지만 정확히는 다릅니다. 에이전트는 모델에 하네스(harness)를 감싸서 실제 행동을 취하고, 결과를 관찰하고, 그 관찰을 다음 모델 호출에 넣어주는 전체 구조입니다. 그리고 이 모든 게 실행되는 환경이 런타임입니다.
런타임은 단순한 서버가 아닙니다. 코드가 실행되는 컨테이너나 가상머신, 에이전트가 읽고 쓸 수 있는 파일시스템, 브라우저·코드 인터프리터·파일 편집기 같은 툴, 외부 네트워크 경계, 세션 간 상태 유지 방식, 그리고 환경을 시작하고 일시정지하고 복구하는 생명주기 컨트롤러까지 모두 포함됩니다. 에이전트가 8초 만에 작업을 끝내는지, 8분이 걸리는지, 두 사용자가 환경을 안전하게 공유할 수 있는지는 모두 런타임이 결정합니다.
샌드박스가 선택이 아닌 이유
에이전트에게 도구 접근권을 주면 어떤 일이 생길까요? 모델은 잘못된 코드를 실행하고, rm -rf를 돌리고, 자격증명을 curl 커맨드에 붙여넣고, 신뢰할 수 없는 문서에 삽입된 지시를 그대로 따릅니다. 이건 특수한 엣지 케이스가 아니라, 제한 없는 도구 접근권을 가진 능력 있는 모델의 전형적인 행동 패턴입니다.
이런 상황에서 샌드박스(격리 실행 환경)가 필수인 이유는 네 가지입니다.
- 모델 실수 격리: 에이전트가 레포지토리를 마운트하고 쉘 접근권이 있으면, 언젠가 반드시 잘못된 디렉토리를 삭제합니다. 파일시스템 격리와 스냅샷이 파괴적 행동을 복구 가능한 사건으로 바꿔줍니다.
- 프롬프트 인젝션 차단: 에이전트는 툴의 출력값을 읽습니다. 그 출력값은 에이전트가 웹페이지를 방문하거나 PDF를 열거나 이메일을 처리하는 순간부터 공격자가 제어할 수 있습니다. 샌드박스가 없다면 삽입된 악성 명령이 프로덕션 데이터베이스로 직행할 수 있습니다. SQL 인젝션이 2003년에 가르쳐준 교훈을 에이전트 시스템이 지금 다시 배우는 중입니다.
- 멀티테넌시: RL 훈련은 수천 개의 롤아웃을 동시에 돌립니다. 격리가 없으면 한 롤아웃의 쉘 오류가 이웃 훈련 스텝을 망가뜨립니다.
- 재현성: 스냅샷할 수 있는 샌드박스는 재실행할 수 있는 샌드박스입니다. 6시간짜리 에이전트 경로를 처음부터 다시 돌리지 않고도 디버깅할 수 있고, 프로덕션 장애를 회귀 테스트로 전환할 수 있습니다.
Devin을 만든 Cognition 팀은 자신들의 경험을 구체적으로 공유했습니다. 컨테이너화된 에이전트는 커널을 공유하기 때문에, 세션 하나가 침해되면 다른 모든 컨테이너의 파일시스템과 자격증명에 접근할 수 있습니다. 에이전트는 스스로 코드를 생성하고 임의의 커맨드를 실행하기 때문에, 커널 탈출은 이론적 위험이 아니라 기본 가정으로 다뤄야 합니다. 그들의 결론은 명확했습니다. 각 세션이 독립된 커널을 갖는 VM 수준 격리가 필수라는 것. 그리고 이 인프라를 구축하는 데 1년 이상이 걸렸습니다.
격리 기술의 선택지
샌드박스 기술은 크게 다섯 가지 프리미티브로 나뉩니다. 컨테이너(runc, Podman), Firecracker 마이크로VM, gVisor, Kata Containers, V8 아이솔레이트입니다.
여기서 중요한 사실 하나. 컨테이너는 에이전트 코드의 샌드박스가 아닙니다. 공유 커널을 쓰기 때문에 커널 익스플로잇이나 잘못 설정된 권한 하나가 격리 경계를 무너뜨립니다. 에이전트가 웹페이지에서 읽어온 공격자의 지시를 실행할 수도 있는 환경에서는 적합하지 않습니다.
사실상 업계 표준으로 자리잡은 건 Firecracker입니다. AWS가 2018년 Lambda와 Fargate를 위해 오픈소스로 공개한 마이크로VM으로, E2B·Fly.io·Vercel Sandbox 등 에이전트 샌드박스 스타트업 대부분이 이 위에 구축됩니다. 약 125밀리초의 부팅 시간과 VMM 자체가 5MB 수준의 메모리를 쓰면서도 강한 격리를 제공합니다. 수천 개의 동시 롤아웃을 경제적으로 실행할 수 있게 해주는 조합입니다.
훈련 환경과 프로덕션 환경의 불일치
가장 날카로운 통찰은 여기서 나옵니다. 저자는 이를 런타임 시프트(runtime shift)라고 부릅니다.
에이전트는 런타임을 학습합니다. 툴의 지연시간, 실패 패턴, 쉘의 미묘한 동작 방식, 파일시스템 구조, ls 명령이 출력을 포맷하는 방식, 브라우저가 리다이렉트를 처리하는 방식. 모델은 훈련 중에 이 모든 것을 흡수하고 정책(policy)에 새깁니다. 그 환경을 바꾸면 행동이 달라집니다. 이전엔 같은 작업을 반복해도 안정적으로 동작하던 툴이 불안정해지고, 빠르던 커맨드가 블로킹됩니다. 에이전트에게 “쉘”의 추상적 개념은 없습니다. “내가 훈련받은 그 쉘”만 있을 뿐입니다.
이건 MLOps 커뮤니티가 10년 동안 걱정해온 데이터 분포 이동(distributional shift)과는 다릅니다. 어떤 eval도 잡아내지 못하는 조용한 품질 저하로 나타납니다. eval 자체가 훈련 런타임에서 돌아가기 때문입니다.
저자가 제시하는 현실적인 해법은 세 가지입니다. 훈련과 프로덕션을 같은 런타임 위에서 돌리거나, 양쪽이 따라야 할 런타임 계약(contract)을 명시적으로 정의하거나, 훈련 중에 의도적으로 지연·오류·툴 실패를 주입해 에이전트 정책 자체를 런타임 변동성에 강하게 만드는 것입니다. Step-DeepResearch 연구에 따르면 훈련 중 5~10%의 툴 오류를 주입했을 때 실제 성능 향상이 있었다고 합니다.
지금 쌓이는 부채
Sculley의 원래 논문이 지적한 것처럼, 기술 부채는 눈에 안 보이는 곳에서 쌓입니다. 에이전트 팀 대부분은 프로토타입 단계에서 가장 쉽게 연동되는 샌드박스를 선택합니다. 프로덕션에서 다른 실패 패턴이 나타나면 재시도와 타임아웃과 프롬프트로 패치합니다. 1년 후엔 런타임을 바꾸는 게 6개월짜리 마이그레이션이 됩니다. 어떤 동작이 바뀔지 아무도 예측할 수 없기 때문입니다.
에이전트는 런타임 위에서 삽니다. 이 사실을 일찍 내면화한 팀과 그렇지 않은 팀의 격차는, 지금부터 2년 동안 벌어질 겁니다.
참고자료:
- What We Learned Building Cloud Agents – Cognition
- How Ramp built a full-context background coding agent on Modal – Modal Blog
- Hidden Technical Debt in Machine Learning Systems – NeurIPS 2015
답글 남기기