에이전트가 코드를 생성하는 건 이제 일상이 됐다. 진짜 문제는 그 다음이다. 생성된 코드를 어디서 실행할 것인가, 실행 전에 무엇을 검증할 것인가, 그리고 실패했을 때 에이전트가 스스로 수정할 수 있는 피드백을 어떻게 줄 것인가. 이 세 가지를 설계하지 않은 팀은 지금 이 순간에도 LLM이 생성한 코드를 별다른 격리 없이 프로덕션 근처에서 돌리고 있다. 그리고 그 리스크를 애써 모른 척하거나, 느리고 비싼 VM으로 틀어막고 있다.
실행 환경 문제: 빠르거나 안전하거나, 이제 둘 다 가능하다
모든 에이전트 튜토리얼은 비슷한 방식으로 끝난다. 에이전트가 추론하고, 코드를 쓰고, exec()으로 실행한다. 대부분 앱이 돌아가는 바로 그 머신에서. Google Cloud NEXT '26에서 가장 주목받은 건 Gemini Enterprise Agent Platform이었지만, dev.to의 한 개발자가 정확하게 짚었듯 실질적으로 가장 중요한 발표는 GKE Agent Sandbox의 GA였다.
기존 선택지들의 문제는 명확했다. 인간 리뷰 게이트는 자동화의 의미를 지운다. 출력 파서는 모델 업데이트마다 깨진다. VM은 콜드 스타트에 10~30초가 걸린다. 도커 컨테이너는 호스트 커널을 공유한다. 결국 대부분의 팀은 리스크를 감수하고 빠르게 움직이는 쪽을 택했다. 잘 돌아가다가 한 번 크게 터지기 전까지는.
GKE Agent Sandbox는 이 트레이드오프를 없앤다. gVisor를 통한 커널 수준 격리, 서브세컨드 첫 명령 실행, 클러스터당 초당 300개 샌드박스 프로비저닝. 격리가 빠르면 모든 에이전트 툴 호출마다 샌드박스를 쓸 수 있다. 사용자가 느끼기 전에 격리가 완료된다는 뜻이다. 설계도 깔끔하다. 각 샌드박스는 Kubernetes CRD로 표현되고, Claim Model을 통해 애플리케이션은 샌드박스의 Pod IP를 직접 추적할 필요 없이 안정적인 엔드포인트만 받아간다. PersistentVolumeClaim이 스토리지를 추상화한 것과 같은 패턴이다.
여기서 솔직하게 짚을 것이 있다. gVisor는 시스콜을 격리하지, 에이전트의 의도를 격리하지 않는다. HTTPS로 데이터를 외부로 내보내는 건 유효한 시스콜이다. 외부 API에 파괴적인 요청을 보내는 것도 마찬가지다. 샌드박스는 호스트 커널을 보호하지, 에이전트를 신뢰할 수 있게 만들지는 않는다. 네트워크 정책, 이그레스 컨트롤, Agent Gateway와의 통합이 별도로 필요하다. 이 부분의 문서가 아직 얇다는 건 인정해야 한다. 그래도 Lovable이 하루 20만 개의 프로젝트를 이미 이 위에서 돌리고 있다는 사실은, 프로덕션 레디 신호로 충분하다.
컨텍스트 문제: 에이전트가 '건망증'을 갖는 이유
실행 환경을 격리했다고 끝이 아니다. 에이전트가 생성하는 코드의 품질 자체가 흔들린다. dev.to에 소개된 Harness Engineering 개념은 이 문제를 정면으로 다룬다. OpenAI의 한 팀이 100만 줄 코드를 1,500개 PR로, 인간이 한 줄도 직접 쓰지 않고 완성한 방법의 핵심은 모델을 더 똑똑하게 만든 게 아니었다. 모델이 작동하기 좋은 환경을 설계한 것이다.
핵심 개념은 세 가지다. 첫째, Progressive Disclosure. 거대한 AGENTS.md 하나에 모든 걸 집어넣으면 LLM의 주의가 분산된다. 컨텍스트에서 모든 게 '중요하고 긴급'해 보이면 정작 지금 해야 할 태스크를 놓친다. 레스토랑 메뉴처럼 설계해야 한다. 상위 맵은 최소화하고, 에이전트가 필요할 때 관련 폴더를 동적으로 탐색하게 한다. 둘째, 레포지토리를 단일 진실 공급원으로. 아키텍처 규칙, 기술 부채 문서, 피처 목록이 코드베이스 안에 텍스트로 존재하지 않으면 에이전트는 추측으로 채운다. Slack 히스토리와 애자일 스프레드시트는 에이전트가 읽지 못한다. 셋째, 자동 수정 루프. 에이전트는 반드시 실수한다. Harness Engineering은 실수를 막는 게 아니라, 린터와 구조 테스트가 오류를 자동으로 에이전트에게 돌려보내 스스로 고치게 한다. 인간 개입 없이.
테스트 피드백 문제: 에이전트는 산문이 아니라 데이터가 필요하다
격리된 환경에서 좋은 컨텍스트로 코드를 생성했다면, 이제 테스트 루프를 닫아야 한다. 여기서 또 하나의 현실적인 벽이 있다. Claude Code 같은 코딩 에이전트에게 API 테스트를 맡기면 작성은 잘 한다. 실행도 괜찮다. 문제는 실패했을 때다.
Jest가 뱉는 AssertionError: expected 200 to equal 404는 에이전트에게 쓸모가 없다. 서버가 꺼져 있는 건지, 응답 스키마가 바뀐 건지, JSONPath가 틀린 건지, 타임아웃이 터진 건지—전부 같은 오류처럼 보인다. 에이전트는 경험상 가장 흔한 수정(URL 변경)을 시도하고, 약 30% 확률로 맞는다. 이 수준으로는 루프를 혼자 돌릴 수 없다.
Tarn은 이 문제를 구조로 푼다. Rust로 만든 CLI 테스트 도구로, 모든 실패를 failure_category, 안정적인 error_code, hints가 포함된 JSON으로 반환한다. connection_error면 서버를 확인하고 테스트는 건드리지 않는다. assertion_failed에 TARN-A-BODY-SHAPE이면 JSONPath를 수정하고 URL은 그대로 둔다. 6개짜리 enum으로 브랜치하는 건 쉽다. 자연어 문장으로 브랜치하는 건 불가능하다. 테스트 포맷도 YAML이다. 모델이 Jest DSL보다 YAML을 훨씬 잘 생성한다—첫 번째 시도 정확도가 60%에서 90%로 올라갔다는 게 실제 사용 결과다. MCP 서버(tarn-mcp)도 제공해서 Claude Code, Cursor, Windsurf 같은 에이전트가 tarn_run, tarn_fix_plan, tarn_rerun_failed 같은 도구를 직접 호출할 수 있다.
세 레이어를 연결하면
지금까지 나온 세 가지—GKE Agent Sandbox, Harness Engineering, Tarn—는 각각 독립된 도구이지만, 에이전트 코드의 생애주기에서 명확하게 다른 레이어를 담당한다.
- 실행 격리: LLM이 생성한 코드는 기본적으로 신뢰할 수 없다. 서브세컨드 커널 격리로 모든 에이전트 툴 호출을 샌드박스에서 실행한다.
- 컨텍스트 품질: 에이전트가 아키텍처를 잊거나 라이브러리를 무시하는 건 모델 문제가 아니라 환경 설계 문제다. Progressive Disclosure와 레포 기반 단일 진실 공급원으로 해결한다.
- 테스트 피드백 루프: 에이전트가 테스트 실패를 스스로 수정하려면 산문이 아니라 구조화된 데이터가 필요하다. 카테고리화된 에러 코드와 힌트가 루프를 닫는다.
이 세 레이어 중 하나라도 빠지면 균열이 생긴다. 격리 없이 빠르게 배포하면 언젠가 한 번 터진다. 컨텍스트 설계 없이 에이전트에게 큰 코드베이스를 맡기면 10번째 인터랙션쯤에 아키텍처가 망가지기 시작한다. 테스트 피드백이 구조화되지 않으면 에이전트가 루프를 스스로 수렴시킬 수 없어 결국 인간이 개입해야 한다.
테크 리드가 지금 당장 점검해야 할 것
이론적으로 좋은 이야기를 하고 싶은 게 아니다. 내일 팀에서 쓸 수 있냐가 기준이다. 체크리스트로 정리하면 이렇다.
격리: 지금 에이전트가 생성한 코드를 어디서 실행하고 있나? 호스트 프로세스에서 직접 돌리고 있다면 GKE Agent Sandbox가 실질적인 선택지다. GKE를 쓰지 않는다면 gVisor 기반 대안이나 Firecracker 같은 마이크로VM을 검토할 시점이다.
컨텍스트: AGENTS.md 혹은 CLAUDE.md가 단일 거대 파일로 관리되고 있다면, Progressive Disclosure 구조로 리팩터링해야 한다. 규칙이 코드베이스 밖 Notion이나 Confluence에만 있다면 에이전트는 그걸 읽지 못한다.
테스트 피드백: 에이전트가 테스트 실패를 받아서 수정하는 루프를 돌고 있다면, 실패 메시지가 구조화된 데이터인지 확인하라. 산문 오류 메시지로는 에이전트가 일관되게 수렴하지 못한다. Tarn처럼 카테고리화된 에러 코드를 돌려주는 도구를 쓰거나, 직접 만들어야 한다.
전망: 인프라 프리미티브는 플랫폼보다 오래 산다
Gemini Enterprise Agent Platform은 제품이다. 리브랜딩되고, 기능이 추가되고, 로드맵이 바뀐다. GKE Agent Sandbox는 프리미티브다. Kubernetes PersistentVolume이 처음 나왔을 때 스테이트풀 워크로드가 이렇게까지 쓰일 거라 아무도 예측 못 했던 것처럼, 서브세컨드 gVisor 격리 환경은 AI 에이전트 이외의 쓰임새도 만들어낼 것이다. 사용자별 노트북 자동 프로비저닝, CI 파이프라인의 안전한 eval 샌드박스, 멀티테넌트 개발 도구의 요청별 격리.
Harness Engineering과 구조화된 테스트 피드백도 마찬가지다. 지금은 AI 코딩 에이전트를 위한 설계처럼 보이지만, 실제로는 어떤 자동화 시스템이든 신뢰할 수 있게 만드는 원칙이다. 에이전트가 코드를 더 많이 생성할수록, 이 세 레이어를 설계한 팀과 그렇지 않은 팀의 격차는 벌어진다. 속도는 AI가 만들지만, 그 속도가 프로덕션에서 살아남는 건 인프라와 피드백 루프를 설계한 사람의 몫이다.