코딩과 그 밖의 작업에서 생산성을 최대한 끌어올리려면 에이전트에는 적절한 수준의 자율성이 필요합니다. 즉, 에이전트는 독립적으로 작동하고, 창의적으로 대응하며, 허가를 받기 위해 너무 자주 멈추지 않고 일을 해낼 수 있어야 합니다.

하지만 에이전트가 의도하지 않은 동작을 수행하면 자율성이 커질수록 보안 위험도 함께 커집니다. 이는 특히 로컬 에이전트에서 더 그렇습니다. 로컬 에이전트는 파일, 자격 증명, 환경 변수, MCP 도구 가까이에서 실행되는 경우가 많고, 프로덕션 시스템에 접근할 수도 있기 때문입니다.

가장 쉬운 해법은 어떤 동작이 일어나기 전에 항상 사용자에게 확인을 구하는 것이지만, 너무 자주 허가를 요청하면 그 자체로 또 다른 안전 문제가 생깁니다. 같은 프롬프트가 충분히 반복되면 사람들은 꼼꼼히 읽지 않게 되고, 승인 흐름도 점점 의미를 잃게 됩니다.

이번 주에 저희는 에이전트 자율성에 대한 판단이 스위치보다 다이얼처럼 작동하도록 만드는 Auto-review를 출시했습니다. 핵심 아이디어는 부담이 낮을 때는 에이전트가 자유롭게 움직일 수 있어야 하지만, 다음 동작이 중요한 경계를 넘으려 할 때는 속도를 늦춰야 한다는 것입니다.

저희는 실행 전에 맥락 속에서 동작을 검토하는 특화된 분류기 에이전트를 통해, 각 동작이 그 연속선상에서 어디에 놓이는지 판단합니다. 이를 만들기 위해서는 에이전트 자율성을 어떻게 관리해야 하는지에 대한 저희의 직관을, 실제 에이전트 동작을 바탕으로 검증할 수 있는 결과, 의도, 피드백의 작동 모델로 바꿔야 했습니다.

#맥락 속에서 위험 판단하기

에이전트의 동작이 위험한지는 상황에 따라 달라집니다. 같은 명령도 어떤 워크플로우에서는 무해할 수 있지만, 다른 워크플로우에서는 용납할 수 없을 수 있습니다. 중요한 것은 그 동작과 사용자의 요청, 그리고 잘못 판단했을 때 초래되는 결과 사이의 관계입니다.

이러한 인식은 전체적인 에이전트 자율성을 관리할 "분류기" 에이전트를 개발하는 방향으로 우리를 이끌었습니다. 우리는 이것이 작은 모델이기를 원했습니다. 그래야 실행이 빠르고 비용도 적게 들면서, 다음 동작이 사용자의 의도와 일치하는지에 대해서도 섬세하게 판단할 수 있기 때문입니다.

우리가 분류기에 부여한 핵심 규칙은 보안상 위험 부담이 낮을 때는 더 관대하게, 높을 때는 더 신중하게 판단해야 한다는 것이었습니다. 이러한 큰 원칙을 바탕으로, 우리는 분류기를 에이전트의 실행 경로에 직접 들어가 맥락에 맞게 검토할 수 있는 빠른 검토기로 만들기 시작했습니다.

#분류기 구축하기

첫 번째 기술적 결정은 어떤 모델을 선택할지였습니다. 분류기는 도구 호출이 실행되기 전에 동작하므로 에이전트 루프에 직접 들어가며, 정확할 뿐 아니라 빨라야 합니다. 여러 모델을 다루는 기업이라는 점도 여기서 도움이 되었습니다. 다양한 모델과 추론 모드를 폭넓게 시험해 본 뒤, 속도와 판단력 사이에서 가장 적절한 지점에 있는 모델을 고를 수 있었기 때문입니다.

초기에 의외였던 점 중 하나는 추론 수준이 낮은 모델이 항상 더 빠르지는 않다는 사실이었습니다. 모델이 정책이나 도구 호출을 이해하는 데 어려움을 겪으면, 결국 더 좋지 않은 답을 내놓으면서도 그 답을 찾는 데 더 많은 시간과 토큰을 쓸 수 있었습니다. 더 나은 절충안은 결정을 깔끔하게 내릴 만큼의 추론 능력을 갖춘 작은 모델이었습니다.

또한 일부 동작은 명령만으로는 판단할 수 없기 때문에 분류기를 에이전트형으로 구현했습니다. python script.py 같은 명령은 파일 안에 무엇이 들어 있는지에 따라 안전할 수도, 안전하지 않을 수도 있으므로, 분류기는 결정을 내리기 전에 ReadFile, Grep, Glob, ListDir 같은 도구로 워크스페이스를 살펴볼 수 있습니다.

별도의 분류 엔드포인트는 두지 않았습니다. 추가 왕복이 검토되는 모든 도구 호출 직전에 지연 시간을 그대로 더하게 되기 때문입니다. 대신 분류기는 상위 에이전트와 동일한 RPC 스트림에서, 하위 에이전트와 유사한 아키텍처를 사용해 실행됩니다.

#피드백 루프 설계하기

다음으로 결정한 것은 차단이 어떤 역할을 해야 하는지였습니다. 우리는 분류기가 또 다른 승인 프롬프트 생성기가 되는 것을 원하지 않았습니다. 분류기가 어떤 동작을 차단하면 상위 에이전트에 그 이유를 설명과 함께 반환하고, 상위 에이전트는 그 피드백을 바탕으로 사용자를 방해하지 않으면서 더 안전한 경로를 선택할 수 있는 경우가 많습니다.

그 피드백을 유용하게 만드는 것은 사용자 의도입니다. 중요한 것은 어떤 동작이 그 자체로 위험해 보이느냐가 아닙니다. 중요한 것은 그 동작이 사용자가 에이전트에게 요청한 작업에 비추어 정당화되는지입니다. 그래야 일반적인 개발 작업은 계속 진행되고, 더 큰 영향을 초래할 수 있는 동작에는 사용자로부터 더 분명한 신호가 필요하게 됩니다.

이 설계가 제대로 동작하려면 분류기가 통과시켜야 할 동작과 막아야 할 동작에 맞게 조정되어 있어야 했기 때문에, 우리는 두 경우를 모두 포괄하는 evals가 필요했습니다.

#분류기 테스트

첫 번째 eval 세트는 에이전트 작업이 평소에 어떤 형태로 이뤄지는지 파악하기 위해 내부 사용 데이터에서 만들었습니다. 분류기는 일상적인 개발 작업은 막지 않으면서도 위험한 동작은 잡아내야 했고, 그 기준선을 확인하기에는 내부 세션이 가장 적합했습니다. 처음에는 내부 개발자 세션 약 12시간 분량으로 시작한 뒤, 이를 추리고 일반적인 동작의 중복을 제거해 레이블이 지정된 6,122개 행으로 정리했습니다.

일반적인 사용에서는 최악의 사례가 충분히 자주 나타나지 않기 때문에 합성 데이터도 필요했습니다. 에이전트가 시크릿을 읽거나, 프로덕션 데이터를 건드리거나, 신뢰할 수 없는 지시를 따르거나, 부작용이 큰 동작을 수행할 수 있는 사례를 생성했습니다. 이런 예시 덕분에 분류기가 특히 잡아내야 하는 실패 사례까지 폭넓게 포함할 수 있었습니다.

학습이 진행되면서 정책도 바뀌었고, 그 때문에 데이터 작업은 더 복잡해졌습니다. 분류기가 인식해야 하는 동작 범주를 바꿀 때마다 eval 세트에 다시 레이블을 붙이거나 새로 구성해야 했습니다. 그렇지 않으면 현재 분류기를 이미 낡은 문제 이해를 기준으로 테스트하게 됩니다.

우리는 eval을 프로덕션에서 사용하는 것과 동일한 백엔드 분류기 루프로 실행했습니다. 덕분에 도구 사용, 최종 분류, 모델 오버라이드, 파싱 실패를 포함한 전체 경로를 테스트할 수 있었습니다. eval은 최종 허용 또는 차단 결정뿐 아니라, 결정을 내리기 전에 워크스페이스를 검사해야 할 때 분류기가 사용한 컨텍스트도 함께 점검했습니다.

플래핑도 살펴보았습니다. 같은 사례가 여섯 번은 허용되고 네 번은 차단된다면, 대개 정책이나 프롬프트가 충분히 구체적이지 않다는 뜻이었습니다. 반복 실행을 통해 이런 불안정한 사례를 찾아내고, 분류기의 동작이 더 일관되도록 다듬을 수 있었습니다.

#직접적인 차단 최소화

실제로는 에이전트 동작 중 분류기의 검토가 필요한 경우는 극히 일부에 불과합니다. 많은 명령어가 이미 허용 목록이나 샌드박싱으로 처리되므로, 분류기는 주로 해당 동작에 맥락에 따른 판단이 필요할 때 실행됩니다.

분류기가 실제로 실행되면 현재 전체 동작의 약 4%를 차단하지만, 차단이 곧바로 사용자 확인 요청으로 이어지지는 않습니다. 분류기는 설명을 상위 에이전트에 다시 전달하고, 상위 에이전트는 이를 바탕으로 동작 범위를 더 좁히거나, 다른 도구를 선택하거나, 위험한 단계를 아예 피하는 경우가 많습니다.

분류기의 일부 차단은 사용자 인터럽션으로 이어지지만, 전체적으로 보면 Auto-review 모드에서는 전체 대화 중 약 7%만이 한 번 이상의 인터럽션으로 이어지고 있습니다. 참고로, 현재 저희가 협업 중인 일부 기업 고객은 이전에 조직 내에서 동작의 약 40%가 차단되는 상황을 겪었습니다.

이 초기 데이터는 저희가 의도했던 핵심 제품 동작과 일치합니다. 분류기가 사용자를 직접 인터럽트하는 경우는 드물고, 대부분의 차단 사례에서는 상위 에이전트가 그 피드백을 활용해 더 안전하고 범위를 좁힌 방식으로 계속 진행할 수 있습니다.

#에이전트 자율성 개선하기

Auto-review는 아직 초기 단계이며, 에이전트의 성능이 높아질수록 자율성의 연속선에 대한 우리의 이해도 계속 달라질 것입니다. 현재는 데스크톱 앱의 로컬 에이전트에 초점을 맞추고 있지만, 앞으로는 같은 개념이 더 많은 환경에서 에이전트 자율성을 관리하는 방식에도 적용될 것으로 기대합니다.

우리는 에이전트가 진정한 자율성을 갖기를 바라며, 에이전트의 속도를 늦출지 여부도 하나의 전역 권한 설정이 아니라 맥락에 따라 결정되도록 하고자 합니다. 분류기는 자율성을 다시 승인 요청 프롬프트의 연속으로 되돌리지 않으면서도 안전성을 높일 수 있게 해줍니다. 더 면밀한 검토가 필요한 동작을 잡아내고, 상위 에이전트에 피드백을 제공하며, 더 안전하게 진행할 방법이 있을 때는 에이전트가 계속 작업할 수 있게 합니다.

Auto-review는 이제 신규 사용자의 기본값입니다. 기존 사용자는 설정 > 에이전트에서 활성화할 수 있습니다.