Jev 생태계 관찰 (2): 에이전트 가드레일 프로젝트 30개는 무엇을 막고 무엇을 통과시켰나

이전 글에서는 Jev 생태계의 4일간 전체 상황을 정리했습니다. 이번 글에서는 핵심 사용 사례인 에이전트 감독을 깊이 다룹니다. TypeSafe가 Jev를 출시한 지 72시간 만에 "에이전트 안전/감독" 범주에서만 30개 이상의 프로젝트가 생겨났습니다. 4일째에는 범용화가 진행되어 실무자들이 "레드오션"이라고 부를 정도였고, 이는 실제 수요가 있음을 보여 줍니다. 이 글에서는 이들을 네 가지 형태로 분류하고, 수치가 제시된 사례를 통해 비교한 뒤, 실무적인 질문에 답합니다. 여러분의 에이전트에는 어떤 가드레일을 써야 할까요?

먼저 근거 기준입니다. 아래 프로젝트 수치는 작성자 자체 보고이며(증거 강도에 따라 A/B/C 등급), 지연 시간과 비용은 프로젝트 단위로 측정되었습니다. 전체 사례 저장소는 jev-radar에서 볼 수 있으며, 항목마다 1차 출처가 있습니다.

가드레일이 갑자기 통하게 된 이유

에이전트 가드레일은 새로운 아이디어가 아닙니다. 예전에는 경제성 때문에 실패했습니다. 도구 호출이 위험한지 LLM에게 판단시키면 추론 한 번에 몇 초가 걸리고 몇 센트가 들었습니다. 이를 에이전트 루프의 모든 단계에 넣으면 그대로 타임아웃이 났습니다. pi-warden README에는 새로운 비용 계산이 제시되어 있습니다. 검사 1회당 입력 토큰 약 1,000개, 약 $0.00004, 약 0.3초입니다(작성자 자체 보고). 처음으로 모든 가드 호출마다 검사를 실행하는 것이 현실적이 되었습니다. 가드레일이 가장 대표적인 사용 사례가 된 이유가 여기에 있습니다. 지연 시간과 단가가 바뀌면서 단계별 감독이 사치에서 기본 설정이 되었습니다.

네 가지 가드레일 아키텍처

30개 이상의 프로젝트를 무엇을 판단하는지와 실제로 차단하는지 여부에 따라 분류하면 네 가지 접근 방식으로 나뉩니다:

• 섀도 감독: 규칙 준수, 노이즈, 작업 정체, 테스트 없는 완료 주장을 판단합니다. 차단하지 않고, 판단 결과를 컨텍스트에 주입해 자기 교정을 유도합니다. 예: pi-warden, Foreman.
• 하드 경계 + 회색 지대 판단: 화이트리스트 밖의 호출을 판단합니다. 차단하지만 하드 규칙이 우선하고, Jev는 회색 지대만 평가합니다. 예: jevgate, rh-guard.
• 승인 게이트: 비용이 크거나 위험한 단계 앞의 마지막 관문 역할을 하며, 사람의 검토를 위해 차단하거나 다운그레이드합니다. 예: toolgate, noulgate, hermes-approvals.
• 선언 대조: 에이전트의 주장과 실제로 일어난 일을 대조합니다. 실시간으로 차단하지 않고 실행 후 불일치를 드러냅니다. 예: clear-head.

섀도 감독은 증거 기반이 가장 탄탄합니다. pi-warden은 Jev로 쓰기 작업을 프로젝트 규칙 파일에 비추어 평가하고, 위반한 규칙을 에이전트 컨텍스트에 다시 제시합니다. 사용자가 개입하지 않아도 에이전트가 교정을 받습니다. 작성자가 자체 보고한 두 가지 지표가 주목할 만합니다. 짝지은 헤드리스 실행 150회에서 가드레일을 끄면 규칙 위반이 6회, 켜면 0회였습니다. 실제 세션 321개, 가드 호출 17,160회 중 실행이 보류된 것은 42회뿐이었습니다(5회는 작성자의 다음 메시지로 해제되고, 37회는 보류 상태가 유지됨). 효과적인 가드레일은 모든 것을 막지 않고 드물게 개입합니다. 또 하나의 디테일로, 작성자의 평가에서 성능이 낮았던 작업 이탈(off-task) 판단 기능은 삭제되지 않고 넛지로 강등되었습니다.

하드 경계와 회색 지대 판단을 결합한 설계는 도입할 만합니다. rh-guard는 채점기 조작, 숨겨진 테스트 확인, 평가 프로세스 조작 같은 코딩 에이전트의 보상 해킹을 겨냥합니다. 아키텍처 원칙은 README에 문서화되어 있습니다. 구조화된 하드 규칙이 먼저 거부하고, 남은 회색 지대를 Jev가 평가합니다. 녹화된 데모에서는 sed로 assertion을 수정하는 시도는 차단되고 무해한 echo 명령은 통과합니다. 같은 계열의 설계자는 이 원칙을 더 직접적으로 표현합니다. jevgate는 실행 가능한 것을 증명하는 화이트리스트 역할을 하고, 목록 밖의 부분은 Jev가 판단하며, 소프트 판단은 결코 단독 거부권을 행사하지 않습니다(fail-open). 보정 확률은 틀릴 수 있으므로 유일한 관문이 될 수 없습니다. 이 계열은 언제 Jev를 쓰지 말아야 하는지를 다루는 설계 의사결정 계층(Augustus)까지 개발했습니다.

승인 게이트는 비용이 큰 단계 앞에 체크포인트를 둡니다. hermes-jev-approvals는 드물게 비교 수치를 제시하며, 기존 솔루션보다 8.7배 빠르고 비용은 4배 낮다고 자체 보고합니다. toolgate는 기본적으로 섀도 모드로 동작해, 신뢰가 쌓일 때까지 관찰과 로깅만 하다가 그 후에 게이트를 엽니다.

선언 대조는 가장 새롭고 가벼운 접근 방식입니다. clear-head는 에이전트가 완료를 보고할 때 읽었다고 주장한 항목을 실제 디스크 읽기 기록과 대조해, 실제로 읽지 않은 내용을 읽었다고 한 주장을 집중적으로 찾아냅니다.

반례

WebMCP 벤치마크(nekuda-ai, 오픈소스이며 재현 가능)는 가드레일 프로젝트에 유용한 현실 점검을 제공합니다. 브라우저 하네스에 연결한 순수 Jev는 웹 작업 49개 중 25개를 해결했지만, 클릭 시퀀스를 단일 도구 호출로 압축하는 WebMCP 계층을 추가하자 49/49로 올라갔습니다. 이 결론은 가드레일 설계에도 적용됩니다. 허용된 버튼을 올바르게 고르는 것이 올바른 다음 단계를 고르는 것과 같지는 않습니다. 판단 계층의 가치는 제공되는 상태 표현에 달려 있습니다. 가드레일도 마찬가지입니다. 질문이 좁고 상태가 정확해야 판단을 믿을 수 있습니다.

가드레일을 구현한다면

30개 이상의 프로젝트에서 정리한 다섯 가지 설계 원칙을 중요도 순으로 소개합니다:

1. 하드 규칙 우선, Jev는 회색 지대 판단: 화이트리스트와 구조화된 규칙으로 표현할 수 있는 작업은 확률적 판단에 의존해서는 안 됩니다. Jev는 규칙이 다루지 못하는 영역을 맡습니다.
2. fail-open, 소프트 판단은 단독 거부권 행사 금지: 보정 확률은 틀릴 수 있으므로, 실패 시에는 워크플로를 멈추기보다 사람의 확인을 요청해야 합니다.
3. 강제 적용 전 섀도 모드: 먼저 개입 없이 로그만 기록하고, 오탐률을 평가한 뒤 게이트를 엽니다(toolgate의 기본 동작과 같습니다).
4. 좁은 질문: 주관적인 품질 평가가 아니라 비가역성이나 의도 일치처럼 열거 가능한 좁은 질문을 평가합니다(Supercov의 교훈이 가드레일에도 그대로 적용됩니다).
5. 성능이 낮은 기능은 삭제 대신 강등: 권한을 제한한 채 기능을 유지하면 완전히 제거할 때보다 더 많은 신호를 보존할 수 있습니다(pi-warden이 작업 이탈을 처리한 방식과 비슷합니다).

레드오션 너머의 기회

10개 이상의 프로젝트가 같은 형태를 구현한 지금, 새 프로젝트의 차별화 경로는 분명합니다. 특화된 호스트를 겨냥하거나(Neovim용 jury.nvim, Emacs용 jev.el, GitHub Actions용 git-judge-jev, OpenCode 플러그인), 새로운 판단 유형을 탐색하거나(rh-guard의 평가 무결성, clear-head의 선언 대조), 설계 계층에 집중하는 것(언제 쓰지 말아야 하는지를 다루는 Augustus)입니다. 새로 진입하는 사람에게 주는 시사점은 이렇습니다. 범용 가드레일 자리는 이미 찼지만, 새로운 호스트와 경계 위반 유형이 생길 때마다 새로운 게이트 자리가 생깁니다.

판단 계층에 대한 논의는 여기까지입니다. 다음으로 이 생태계의 다른 측면인 실패 사례를 살펴봅니다. 판단 계층에 데이터를 공급해야 한다면, 리뷰, 감성, 가격 데이터를 안정적으로 수집하는 것이 EveryInfra의 핵심 역량입니다. 통합 데이터 API 가이드부터 시작해 보세요.