어느 날 AI 에이전트가 인프라 시크릿을 삭제하는 Terraform 명령을 직접 실행했다. 그런데 아무 일도 일어나지 않았다. 에이전트가 마음을 바꿔서가 아니라, 구조적으로 그 명령이 실행될 수 없는 환경이었기 때문이다. dev.to에 공개된 Jules Robineau의 사례가 보여주는 핵심 교훈은 하나다. 에이전트의 판단을 믿는 것이 아니라, 에이전트가 실수해도 시스템이 버티도록 설계하는 것.
2025년 현재, Cursor나 Claude Code 같은 AI 코딩 에이전트는 이미 많은 팀의 일상 도구가 됐다. 문제는 '쓰느냐 마느냐'가 아니라 '어떻게 운영하느냐'다. 그런데 실제 운영 경험담을 보면 두 가지 실패 패턴이 반복된다. 하나는 권한을 너무 많이 준 것, 다른 하나는 에이전트가 생성한 내용을 검증 없이 믿은 것. 이 두 실패는 겉으로 달라 보이지만, 본질적으로 같은 문제다. 에이전트를 신뢰의 대상으로 설정한 것.
첫 번째 축: 권한 설계는 환경별 매트릭스로
Robineau가 제시하는 프레임은 명확하다. AI 에이전트를 신입 개발자 온보딩처럼 다루되, 그보다 훨씬 빠르고 피로도 없으며 판단력이 없는 존재로 가정한다. 그래서 로컬 개발 환경에서는 전권을 주고, 스테이징·프로덕션으로 갈수록 권한을 극단적으로 줄인다. 핵심은 환경별 권한 매트릭스다.
| 환경 | 셸 명령 | 시크릿 읽기 | Terraform 실행 | main 머지 |
|---|---|---|---|---|
| dev | 전체 허용 | 허용 | 파이프라인만 | PR + 리뷰 |
| staging | allowlist | 불가 | 파이프라인만 | PR + 리뷰 |
| prod | 불가 | 불가 | 파이프라인만 | PR + 리뷰 |
이 매트릭스를 실제로 강제하는 장치가 중요하다. Robineau가 설계한 네 겹의 가드레일은 각각 다른 레이어에서 동작한다. 허용 명령 allowlist(에이전트 설정 파일), 위험 명령 감지 훅(PreToolUse 훅, 차단이 아닌 인간 확인 요청), pre-commit 검사(gitleaks + 린터 + 테스트), GitHub 브랜치 보호 룰셋(서버 사이드, 에이전트가 손댈 수 없는 곳). 앞 세 개는 로컬에 있어서 우회 가능성이 있지만, 마지막 하나는 완전히 에이전트의 통제 밖이다. 이 구조가 핵심이다.
특히 주목할 점은 훅이 "차단"이 아닌 "질문"으로 설계됐다는 것이다. rm -rf나 curl | bash 같은 위험 패턴을 감지했을 때 에이전트를 멈추는 게 아니라 인간에게 판단을 넘긴다. 의도를 믿지 않고 결과를 검사한다는 결정론적 보안 원칙이 여기서 구현된다. 모델이 무슨 생각을 했는지는 중요하지 않다. 무엇을 하려 하는지만 보면 된다.
두 번째 축: 에이전트 출력의 사실 검증 루프
권한 설계가 "에이전트가 뭔가 잘못 실행하는 것"을 막는다면, 검증 루프는 "에이전트가 틀린 내용을 자신 있게 생성하는 것"을 막는다. dev.to의 또 다른 사례, 비개발자 PM이 Claude Code로 게임 위키를 구축한 경험담은 이 문제를 적나라하게 드러낸다.
AI가 게임 내 Burn 데미지 메커니즘을 설명하는 글을 완벽하게 작성했다. 구체적인 수치, 스택 룰, 특정 오르가넬까지. 읽으면 신뢰가 갈 만한 문장들이었다. 그런데 전부 허구였다. AI가 의학 논문과 동명의 보드게임 자료를 섞어서 그럴듯하게 조합한 것이었다. 이게 AI 할루시네이션의 가장 위험한 형태다. 틀렸는데 틀린 티가 나지 않는 것.
이 PM이 구축한 검증 워크플로우는 단순하지만 엄격하다. 모든 사실 주장에는 반드시 출처를 연결한다. 공식 패치노트, 개발자 코멘트, 실제 플레이 영상. 출처를 찾을 수 없으면 발행하지 않는다. 플레이어 댓글 하나를 받았을 때도 즉시 반영하지 않고 독립적인 확인 과정을 거쳤다. 확인되지 않았을 때는 중립적인 표현으로 교체했다. "Brain 구역에 상점이 없다"가 아니라 "Brain 진입 전 빌드를 완성하라"로.
그가 실제 시간을 쓰는 곳을 보면 AI 에이전트 활용의 실상이 드러난다. 에이전트에게 지시하는 시간 20%, 결과물 리뷰 30%, 사실 검증 30%, 톤 조율 20%. 코드와 배포는 에이전트가 거의 자동으로 처리했다. 인간의 시간은 대부분 "이게 실제로 맞는가"를 확인하는 데 쓰였다.
두 축의 공통 설계 원칙
권한 매트릭스와 사실 검증 루프는 다른 레이어의 문제처럼 보이지만, 같은 설계 원칙을 공유한다. 에이전트의 선의나 정확성을 전제하지 않는 것. Zero Trust가 "기본적으로 아무것도 신뢰하지 않는다"는 원칙을 네트워크 경계가 아닌 모든 주체에 적용하듯, AI 에이전트도 같은 기준으로 다뤄야 한다. OWASP가 발표한 에이전틱 애플리케이션 Top 10 리스크, NIST의 Zero Trust 가이드라인, Cloud Security Alliance의 에이전트 프레임워크가 모두 같은 방향을 가리키고 있다.
프론트엔드 개발자 관점에서 이 두 사례는 실질적인 체크리스트를 제공한다. 로컬 개발에서는 에이전트에게 전권을 주되, CI/CD 파이프라인과 브랜치 보호 룰은 에이전트가 절대 건드릴 수 없는 위치에 둔다. 에이전트가 생성한 코드나 콘텐츠는 "그럴듯해 보임"이 아니라 "확인 가능한 근거가 있음"을 기준으로 검증한다. Cursor나 Claude Code가 만든 컴포넌트든, 자동 생성된 API 문서든, 검증의 책임은 항상 사람에게 있다.
앞으로 에이전트는 더 빨라지고 더 자율적으로 행동할 것이다. 그게 에이전트 설계에서 권한과 검증이 더 중요해지는 이유이기도 하다. 더 강한 모델이 더 큰 신뢰를 의미하지 않는다. 더 강한 모델일수록, 잘못 실행했을 때 파급 범위도 커진다. 결국 남는 질문은 단순하다. 에이전트가 실수해도 시스템이 버틸 수 있는가. 그 답이 설계에 이미 있어야 한다.