AI 에이전트를 프로젝트에 연결하고 나면 이상하게 안심이 된다. CI 배지는 초록, 에이전트는 열심히 응답하고, 인프라 대시보드도 에이전트에게 물어보면 된다. 그런데 그 안심이 실제 검증에서 온 건지, 아니면 '작동하는 것처럼 보이는 것'에서 온 건지—실전에 붙이기 전에 딱 세 가지만 확인하면 그 차이가 드러난다.
1. 초록 테스트가 실제로 무엇을 지키고 있는가
Safari MCP를 개발한 Achiya의 회고는 꽤 불편한 진실로 시작한다. 32개 테스트가 전부 통과했고, CI 배지는 늘 초록이었다. 그런데 리팩토링을 앞두고 스스로에게 물어봤다. "이 중 하나라도 보안 경계가 무너지면 빨개지는 테스트가 있나?" 대답은 '없다'였다.
실제로 테스트 스위트의 대부분은 두 가지 질문에만 답하고 있었다. 도구가 존재하는가, 스키마 형태가 맞는가. Safari MCP에서 가장 중요한 보안 로직—에이전트가 자신이 연 탭만 제어해야 한다는 탭 소유권 규칙—은 단 한 줄도 검증되지 않았다. /org와 /org-evil을 같은 탭으로 잘못 판단하는 버그가 있었어도, CI는 초록을 유지했을 것이다.
이건 테스트 커버리지 숫자의 문제가 아니다. "도구의 형태"를 검증하는 테스트와 "도구의 행동"을 검증하는 테스트는 완전히 다른 신뢰를 제공한다. 에이전트 기반 시스템에서는 특히 그렇다. 에이전트가 실제로 호출하는 로직—경계 판단, 상태 전이, 사이드 이펙트—이 테스트되지 않으면, 초록 배지는 거짓말이 아니라 그냥 다른 질문에 대한 올바른 답일 뿐이다. 지금 당신의 에이전트 코드에서, 가장 잘못되면 안 되는 한 가지 로직이 테스트에서 실제로 호출되고 있는지 확인해보자.
2. 에이전트에게 스크린샷을 넘기고 있다면, 이미 비싼 선택을 한 것이다
dev.to의 Bickov이 공유한 경험은 단순하지만 꽤 날카롭다. Claude Code에 스크린샷을 붙여넣었더니 에이전트가 의도한 버튼이 아닌 다른 요소를 수정했다. 크래시도 없고, 에러도 없었다. 그냥 틀린 것을 고쳤다.
문제는 에이전트의 이해력이 아니다. 스크린샷은 구조가 없는 픽셀 덩어리다. 에이전트는 매 턴마다 그 이미지 전체를 다시 읽고, 당신이 '명백히' 가리켰다고 생각한 요소를 추론으로 찾아낸다. Sonnet 기준 약 1,500토큰, Opus 기준 최대 4,784토큰—매 대화 턴마다 청구된다.
같은 정보를 구조화된 JSON으로 넘기면 약 700토큰이다. 절반 이하다. 그리고 더 중요한 건, 추론이 필요 없어진다는 점이다. 어떤 요소인지, 어디 있는지, 어떤 의도인지를 명시적으로 전달하면 에이전트는 '맞추는' 대신 '실행'한다. 프론트엔드 개발자 입장에서 보면, UI 자동화 워크플로우에서 스크린샷을 기본 입력으로 쓰는 건 컴포넌트에 any 타입을 쓰는 것과 비슷하다. 동작은 하지만, 당신이 원하는 방식으로 동작한다는 보장이 없다.
3. 에이전트가 IDE 밖을 오가게 두고 있다면, MCP를 아직 제대로 안 쓴 것이다
Renato Marinho의 글은 조금 다른 각도에서 실전 워크플로우를 건드린다. GPU 잡이 실행 중인데 멈춘 건지 느린 건지 모르겠을 때, 기존 루틴은 IDE를 떠나 브라우저를 열고 대시보드를 뒤지고 로그를 찾는 것이었다. 집중이 끊기는 마이크로 컨텍스트 스위칭이, 매주 몇 시간씩 누적된다.
Modal의 MCP 서버를 Cursor 에이전트에 연결하자 그 루틴이 사라졌다. list_apps로 현재 실행 중인 앱을 확인하고, 이상한 것을 발견하면 stop_app으로 종료한다. 자연어 한 줄이면 된다. 대시보드를 없앤 게 아니라, 대시보드에 갈 필요를 없앤 것이다.
다만 Renato 본인도 강조하듯, 이건 MCP를 '읽기 전용 조회 도구'로 쓰는 것과 다르다. 에이전트가 stop_app을 실행할 수 있다는 것은 프로덕션 워크로드를 종료할 수 있다는 뜻이다. 감사 체인과 실행 경계 없이 LLM에게 그 권한을 주는 건 실용적 자동화가 아니라 조용한 리스크다. MCP의 가치는 '에이전트가 할 수 있는 것'을 넓히는 데 있지만, 그 경계를 어디서 닫을지는 여전히 사람이 설계해야 한다.
세 가지가 가리키는 하나의 패턴
세 기사가 각각 다른 문제를 다루는 것 같지만, 결국 같은 구조적 함정을 보여준다. 시스템이 조용히 덜 하는데, 신호는 계속 '괜찮다'고 말한다. 테스트는 초록, 에이전트는 뭔가를 고쳤다고 하고, 인프라는 응답 중이다. 그런데 실제로 검증된 건 없고, 잘못된 요소가 수정됐고, 실행 경계는 설계되지 않았다.
'프로토타입 → 검증 → 고도화' 흐름에서 에이전트를 실전에 붙이는 타이밍은 검증 이전이 아니라 이후여야 한다. 에이전트가 실제로 호출하는 로직을 테스트가 커버하는지, 에이전트에게 넘기는 입력이 추론이 아닌 실행을 유도하는지, MCP로 확장한 에이전트의 행동 경계가 명시적으로 설계되어 있는지. 이 세 가지를 먼저 닫고 붙이는 것—그게 에이전트를 워크플로우의 동반자로 만드는 첫 번째 조건이다.