브레이크를 풀고 빠르게 나아가기: AI 에이전트의 가속도와 안전성 균형 맞추기

John Feminella 작성

우리는 이제 에이전트가 실시간 운영 환경에서 빛의 속도로 작업을 수행할 수 있는 세상에 살고 있습니다. 많은 사람들이 지금 고민하는 질문은 이것입니다. 강력한 작업에 접근할 수 있는 에이전트 시스템의 안전성을 어떻게 보장하면서, 그들이 달성할 수 있는 것을 제약하지 않을 수 있을까요?

문제점

저는 Two Sigma에서 에이전트로부터 위험을 제한하기 위해 도입한 통제 장치와 관련하여 이 점에 대해 많이 생각합니다. 규제를 받는 회사에서는 안전성이 너무 부족하면 실존적 위험이며, 혁신이 너무 부족하면 느린 죽음입니다.

우리가 에이전트의 혜택을 누리고 싶다면, 안전성과 혁신의 자유를 모두 제공하는 방식으로 해야 합니다. John Shedd가 썼듯이, “항구에 있는 배는 안전하지만, 그것이 배의 목적은 아니다.”

저희의 경우, 다섯 가지 필수 요소로 시작했습니다. 무엇이 귀사의 기업에 적합한지는 위험 노출 정도와 에이전트에게 허용하고 싶은 작업에 따라 달라질 것입니다.

1. 에이전트 등록(Registering agents)

우리 팀들이 혁신할 수 있는 방대한 잠재력을 활용하려면, 그들이 서로 아이디어를 공유하고 그들의 에이전트가 소통하고 함께 작업할 수 있는 방법이 필요합니다. 서로 연결할 수 있게 해주는 에이전트 레지스트리는 첫 번째이자 가장 중요한 단계입니다. 에이전트(및 인간)가 무엇이 이미 작성되었는지 이해할 방법이 없다면, 많은 중복된 시간, 에너지, 토큰을 낭비할 위험에 처합니다.

저희의 경우, 이 레지스트리는 각 에이전트의 도구(tools), 엔드포인트(endpoints), 소유자(owner) 및 관련 제품을 기록합니다. 저희 목표 중 하나는 최소한의 간섭입니다. 저희는 승인된 템플릿으로 구축된 에이전트는 스스로 등록하도록 설계했고, 맞춤형 에이전트(bespoke ones)는 휴리스틱하게 감지하여 소유자에게 알림과 함께 자동 등록되도록 했습니다.

2. 위험 점수화 (Risk scoring)

일반적인 에이전트 하네스(agentic harnesses)는 대부분 배포되는 엔터프라이즈 에이전트가 작동하는 방식과 다르게 작동합니다. 일반적으로 Claude Code, Codex 또는 Pi와 같은 하네스와 상호 작용을 시작할 때, 그것은 어떤 종류의 요청을 받을지, 혹은 어떤 목적으로 사용될지 알지 못합니다. 이는 설계상 개방적(open-ended)이기 때문입니다. 이 점은 위험 평가에 어려움을 제기하는데, 왜냐하면 그것이 실제로 무엇이든 할 수 있기 때문입니다.

이는 항상 특정하고 전용적인 목적을 가진 엔터프라이즈 에이전트와는 대조적입니다. 이는 우리가 이러한 에이전트를 어떻게 평가하고 이해할지 훨씬 명확하다는 것을 의미합니다. 예를 들어, 티켓 요약기는 생산 시장 신호를 읽는 에이전트와 다릅니다.

레지스트리(registry)는 모든 업데이트마다 선언된 도구(tools), 목적(purpose), 시스템을 기반으로 각 에이전트의 위험 프로필을 점수화합니다. 만약 에이전트가 사용 승인을 받으면, 그 선언은 또한 정책을 통해 에이전트가 할 수 있는 것을 제한함으로써 에이전트를 구속합니다. 위험 점수는 에이전트가 사용하는 도구와 같은 관찰 가능한 요인뿐만 아니라, 에이전트 목적의 성격과 같은 정성적(qualitative) 요소에 기반합니다.

제한된 기능과 접근성을 가진 저위험 에이전트는 인간 개입 없이 게시되며, 고위험 에이전트는 플래그가 지정됩니다. 이러한 식별 과정은 우리가 가장 중요하게 생각하는 곳에 검토 노력을 집중할 수 있게 해줍니다.

3. 이그레스 제어(Egress controls)

에이전트는 출력물을 생성하기 위해 정보를 결합하고 리믹스하는 방식에서 일부 가치를 얻습니다. 그러나 기본적으로 에이전트 프로세스가 실행되는 환경은 에이전트를 신뢰하지 않습니다. 대신, 에이전트는 승인된 목적지(destination)만 허용하는 프록시(proxy) 뒤에서 실행됩니다. 이 프록시는 에이전트 코드를 신뢰하지 않으며, 실패 시 폐쇄(fails closed)하고, 각 에이전트에 대한 정책을 레지스트리에서 직접 가져옵니다. 아무도 방화벽 티켓을 제출하거나 취약한 설정을 유지할 필요가 없습니다.

4. 평가(Evaluations)

일관된 평가 방식이 없다면, 팀들은 자신들의 에이전트에 대한 모델 성능을 이해하기 위해 맞춤형 접근 방식을 구축해야 할 것입니다. 저희에게 이것은 각 팀에게 자체 단위 테스트 프레임워크를 만들라고 요구하는 것과 같습니다. 이는 낭비스럽고 불필요한 산만함이며, 필요할 수는 있지만 궁극적으로는 그들의 혁신 능력에서 벗어나게 만듭니다.

각 팀마다 맞춤형 접근 방식을 사용하는 대신, 저희는 공유된 평가를 목표로 합니다. 따라서 에이전트를 작성하는 각 팀은 성능을 비교할 수 있는 일관된 방법을 갖게 됩니다. 이렇게 개별적인 성능들을 여러 팀에 걸쳐 집계하여 회사 맥락에서의 모델 성능을 이해할 수 있습니다. 이것이 없다면, 저희는 단지 공개 벤치마크 점수만 가지게 될 것이고, 저희의 경험상 공개 벤치마크가 개별적이고 특정 기업과 크게 일치하지 않는다는 것을 배웠습니다.

저희의 공유 프레임워크는 트레이스 수집 및 파이프라인 작업도 처리하므로, 작성자들은 평소처럼 에이전트 로직과 테스트 케이스만 작성하면 됩니다. 이는 평가가 CI/CD 파이프라인처럼 모든 변경 사항에 대해 실행된다는 것을 의미합니다.

5. Auto-mode 분류기 (Auto-mode classifiers)

사람들이 모든 에이전트 행동을 수동으로 검토하고 승인해야 한다면, 이는 에이전트를 느리게 만들 뿐만 아니라 인간을 안일함과 경고 피로(alert fatigue)를 통해 부주의하게 만듭니다. 이를 방지하기 위해, 저희는 에이전트 하네스(agentic harnesses)를 사용하는 분들에게 익숙한 모델인 '자동 모드(auto mode)' 분류기를 구현합니다.

에이전트가 명시적으로 금지되지 않은 무언가를 하고 싶어 한다면, 2단계 분류기가 무엇이 되어야 할지 결정합니다. 즉, 차단 쪽으로 기울어진 빠른 분류를 거친 후, 불분명한 경우에 대해 더 깊은 검토를 수행하는 것입니다.

결론

종합적으로 볼 때, 이 다섯 가지는 저희 플랫폼과 에이전트 워크로드를 위해 마련한 통제 장치들입니다. 이 분야는 끊임없이 변화하고 있기 때문에 오늘 맞는 것이 6개월 후에는 아닐 수 있습니다. 따라서 저희는 내부 수요에 맞춰 이러한 기능을 제공하기 위해 항상 플랫폼을 선제적으로 설계하고 개선하고 있습니다. 저희 에이전트들은 제어 장치가 작동하든 안 하든 기계 속도로 실행될 것입니다. 성공적인 기업들은 아무도 속도를 늦출 필요가 없도록 따라잡아 주는 통제 장치를 구축합니다.