에이전트가 코드를 직접 실행한다는 말이 더 이상 SF가 아니다. dev.to에 공개된 'Self improving code using the agentic evaluator workflow' 실험은 이를 간결하게 증명한다. Agent 1이 코드를 생성하고, 스코어러가 구조화된 피드백을 돌려주고, 리파이너가 그걸 반영해 코드를 개선한다. 점수가 임계값(9.6/10)을 넘으면 Agent 1이 그 코드를 임시 파일로 쓰고 서브프로세스로 직접 실행한다. 사람이 개입하는 구간은 없다.
이 패턴이 흥미로운 이유는 작동한다는 것 자체가 아니다. 루프를 안정적으로 만드는 설계 결정 세 가지가 명확하게 드러난다는 점이다. 첫째, 스코어러에게 전체 시도 이력을 넘긴다. 이력 없이 돌리면 스코어가 회귀한다—이전 턴에서 높이 평가한 코드를 다음 턴에서 다시 깎는다. 둘째, 피드백 형식을 REMOVE/ADD 쌍으로 강제한다. "에러 핸들링을 개선하라"는 지시는 리파이너에게 쓸모없다. "이 줄을 이 블록으로 교체하라"는 지시는 결정론적으로 적용된다. 셋째, 모델 역할을 분리한다. 생성과 개선은 추론 용량이 필요하므로 claude-opus를, 스코어링은 빠르고 저렴한 claude-haiku를 쓴다. 역할마다 모델을 다르게 쓰는 것은 비용 최적화이기도 하지만, 루프 전체의 속도와 품질 균형을 잡는 아키텍처 결정이기도 하다.
그런데 이 루프가 실제로 코드를 실행하는 순간, 문제의 축이 바뀐다. 코드를 생성하고 평가하는 것과 생성된 코드를 직접 서브프로세스로 실행하는 것은 전혀 다른 리스크 레벨이다. 에이전트가 파일 시스템에 쓰고, 프로세스를 띄우고, 외부 API를 호출한다면—그 경계를 팀이 명시적으로 설계해두지 않으면 에이전트는 팀이 의도하지 않은 작업을 조용히 수행할 수 있다.
같은 날 dev.to에 올라온 또 다른 글이 이 지점을 정면으로 다룬다. MCP 서버를 통해 데이터베이스, 파일시스템, 셸에 연결된 에이전트는 단 하나의 환각이나 프롬프트 인젝션으로 DROP TABLE을 실행할 수 있다. 그리고 그 실행은 모델이 "위험한 호출"임을 인식하기 전에 이미 완료된다. agentx-mcp가 제안하는 접근은 단순하다. MCP 서버와 에이전트 사이에 결정론적 필터를 하나 끼운다. DROP TABLE, 비범위 DELETE, SSRF 패턴, rm -rf—이것들은 LLM 추론 없이 규칙 기반으로 차단된다. API 키도 없고, 외부 게이트웨이도 없다. mcp.json 한 줄이면 기존 스택을 그대로 유지하면서 이 레이어를 추가할 수 있다.
더 중요한 설계 포인트는 차단 이후다. 에이전트를 죽이는 것과 에이전트를 교정하는 것은 다르다. 단순히 에러를 리턴하면 에이전트가 멈춘다. 작업이 완료되지 않는다. agentx-mcp가 "코칭 에러"를 돌려주는 이유가 여기 있다—무엇이 막혔는지, 왜 막혔는지, 어떤 안전한 경로가 있는지를 에러 메시지에 담아 에이전트가 다음 턴에서 수정할 수 있게 한다. SELECT COUNT(*) FROM users로 수정한 쿼리가 성공적으로 실행되는 것, 그게 목표다. 차단은 수단이고 복구가 목적이다.
두 실험을 나란히 놓으면 에이전트 실전 도입의 두 가지 설계 과제가 선명해진다. 첫째, 품질 임계값 설계. 에이전트가 생성한 결과물을 언제 수용하고 언제 재시도할지를 팀이 먼저 정의해야 한다. 스코어 기준, 최대 반복 횟수, 실패 시 동작(종료 vs. 폴백)—이것들은 에이전트를 도입하기 전에 팀이 명시적으로 설계해야 할 임계값이다. GBSA의 2026 Device AX 교육 커리큘럼이 Claude Code와 AI Agent 워크플로우를 실무 중심으로 다루는 것도 이 맥락과 맞닿아 있다. 에이전트를 쓰는 법보다 에이전트가 작동하는 루프를 설계하는 법을 배우는 것이 진짜 실무 역량이다.
둘째, 실행 경계 설계. 에이전트가 외부 시스템(DB, 파일시스템, 셸, API)에 연결되는 순간, 그 연결의 범위와 허용 동작을 팀이 명시적으로 정의해야 한다. "에이전트가 알아서 잘 하겠지"는 설계가 아니다. 결정론적 차단 레이어, 차단 이후 복구 경로, 실행 타임아웃, 생성된 파일의 정리 정책—이것들이 없으면 에이전트는 작업을 완수하는 도구가 아니라 조용히 사이드 이펙트를 쌓는 프로세스가 된다.
에이전트가 자율적으로 동작하는 루프는 분명히 효과적이다. 하지만 그 루프를 팀의 프로덕션 환경에서 돌리는 것은 다른 얘기다. 품질 임계값과 실행 경계, 이 두 설계가 먼저 있어야 에이전트는 팀의 생산성 도구가 된다. 그 설계 없이 도입 속도를 높이는 것은—에이전트가 얼마나 잘 만들어졌든—팀이 통제할 수 없는 실행자를 하나 더 추가하는 것에 가깝다.