AI 에이전트가 아무도 감사할 수 없는 결정을 내리고 있다

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.

아무도 이야기하고 싶어 하지 않는 문제

AI 에이전트가 이제 어디에나 있습니다. 이들은 API를 호출하고, 데이터베이스를 쿼리하고, 코드를 실행하며, 경우에 따라 실제 돈을 쓰기도 합니다 — 모두 자동으로 이루어집니다. 이를 구축하기 위한 프레임워크는 놀라울 정도로 강력합니다. CrewAI, LangChain, AutoGen, OpenAI의 Agents SDK 등은 실제 작업을 수행할 수 있는 에이전트를 손쉽게 만들 수 있게 해줍니다.

하지만 이 프레임워크들이 제공하지 않는 것이 하나 있습니다: 에이전트가 실제로 무엇을 했는지에 대한 가시성.

• 감사 로그가 없습니다.
• 차단 스위치가 없습니다.
• 문제가 발생한 뒤에 무슨 일이 있었는지 재생할 방법이 없습니다.
• 위험한 행동이 실행되기 전에 정책을 강제할 수 없습니다.
• PII(개인식별정보) 삭제가 되지 않습니다 – 모든 프롬프트와 완성 결과가 고객 데이터, API 키, 내부 정보가 그대로 포함된 채로 관측 백엔드에 전송됩니다.

제가 이야기를 나눈 모든 팀은 이를 다르게 처리합니다. 대부분은 전혀 처리하지 못하고 있습니다.

Why this is an infrastructure problem, not an application problem

TLS를 생각해 보세요. 아무도 각 마이크로서비스마다 TLS를 다르게 구현하지 않습니다. TLS는 애플리케이션 코드 아래에 위치하는 표준화된 레이어로, 그 위에 있는 모든 것의 암호화를 처리합니다.

에이전트 안전도 같은 방식으로 작동해야 합니다.

각 팀이 자체 로그, 자체 킬 스위치, 자체 정책 검사를 구축한다면 — 일관성 부족, 빈틈, 그리고 위의 50,000 요청 사고를 초래한 “나중에 처리하자”는 접근 방식이 생깁니다.

안전 레이어는 다음과 같아야 합니다:

• Framework‑agnostic – CrewAI, LangChain, AutoGen 또는 맞춤형 솔루션을 사용하든 상관없이 작동합니다
• Infrastructure‑level – 에이전트 코드 내부가 아니라 네트워크 경로와 텔레메트리 파이프라인에서 동작합니다
• Standardized – OpenTelemetry를 사용하여 이미 보유하고 있는 관측 스택에 쉽게 연결됩니다

Source: …

내가 만든 것

저는 AIR Blackbox 라는 오픈소스 프로젝트를 작업하고 있습니다 — AI 에이전트를 위한 비행 기록 장치와 같은 개념입니다. 이 시스템은 에이전트와 LLM 제공자 사이에 위치해 모든 것을 캡처합니다.

아키텍처

Your Agent ──→ Gateway ──→ Policy Engine ──→ LLM Provider
                 │               │
                 ▼               ▼
           OTel Collector   Kill Switches
                 │          Trust Scoring
                 ▼          Risk Tiers
           Episode Store
           Jaeger · Prometheus

한 줄만 바꾸면 — base_url 을 교체하면 — 모든 에이전트 호출이 이를 통해 흐릅니다. SDK 변경 없이, 코드 리팩토링 없이 가능합니다.

구성 요소

• Gateway – Go 로 작성된 OpenAI 호환 역방향 프록시입니다. 모든 LLM 트래픽을 가로채고 구조화된 OpenTelemetry 트레이스를 방출하며, 요청을 전달하기 전에 정책을 확인합니다. OpenAI 호환 클라이언트라면 수정 없이 사용할 수 있습니다.
• Policy Engine – YAML 로 정의된 정책을 실시간으로 평가합니다. 위험 등급(낮음, 중간, 높음, 치명적), 신뢰 점수, 프로그래머블 킬 스위치, 고위험 작업을 위한 인간‑인‑루프 게이트를 지원합니다. 거버넌스는 동작 이전에 이루어집니다.
• OTel Collector – gen_ai 텔레메트리를 위한 맞춤형 프로세서입니다. 해시‑및‑프리뷰(48자 프리뷰 + 해시)를 이용한 PII 마스킹, 비용 메트릭, 50,000 요청 사고를 잡아낼 수 있었던 루프 탐지를 제공합니다.
• Episode Store – 개별 트레이스를 작업 수준 에피소드로 묶어 재생할 수 있게 합니다. 문제가 발생했을 때, 원시 로그를 뒤적이는 대신 테이프를 되감듯 에피소드를 재생할 수 있습니다.

예상치 못한 부분

제가 이것을 만들기 시작했을 때, 가장 어려운 문제는 기술 아키텍처라고 생각했습니다. 그렇지 않았습니다. OpenTelemetry는 탄탄한 기반을 제공합니다. Go는 프록시 구현에 뛰어납니다. 실제 배관 작업은 오히려 직관적인 부분이었습니다.

진짜 어려운 문제는 사고가 발생하기 전에 사람들에게 이것이 필요하다고 설득하는 일입니다.

제가 이야기하는 모든 팀은 다음과 같은 말을 합니다: “우리는 신중하게 행동하고 있다.” “우리 에이전트는 단순하다.” “모니터링은 나중에 추가하겠다.”
그런 다음 실제 사고가 발생하거나, API 키가 유출되거나, 아무도 대비하지 못한 질문을 하는 감사인이 나타납니다.

규제 산업(헬스케어, 금융 등)에서 에이전트를 배포하는 기업들은 이미 다음과 같은 질문에 답해야 한다는 것을 알고 있습니다:

• “우리 에이전트가 수행한 작업을 증명할 수 있나요?”
• “즉시 종료시킬 수 있나요?”
• “PII(개인 식별 정보)가 트레이스 백엔드로 유출되지 않도록 보장할 수 있나요?”

ISO 27001 감사인과 SOC 2 검토자는 이러한 질문을 점점 더 많이 하고 있습니다. CloudWatch에 로그만 남기는 것으로는 충분하지 않습니다.

What’s next

AIR Blackbox는 Apache 2.0 라이선스 하에 완전 오픈 소스이며, 21개의 리포지토리로 구성되어 있습니다. 완전히 모듈식이어서 전체 스택을 사용하거나 필요한 부분만 선택해서 사용할 수 있습니다.

• CrewAI, LangChain, AutoGen, 그리고 OpenAI’s Agents SDK용 Trust 플러그인.
• 5분짜리 퀵스타트로 make up 명령만으로 로컬에서 전체 스택을 실행할 수 있습니다.

프로덕션 환경에 AI 에이전트를 배포하고 있거나 배포를 계획하고 있다면, 여러분의 피드백을 진심으로 환영합니다. 어떤 부분이 부족하다고 느끼시나요? 어떤 점이 밤에 잠을 설치게 하나요?

GitHub:

설치를 하지 않고도 탐색하고 싶다면 README에 있는 인터랙티브 데모를 확인해 보세요.

저는 AIR Blackbox를 구축하고 있습니다. 에이전트 안전이 첫 사고 이후에 부착되는 사후 생각이 아니라, 인프라 차원에서—지루하고 신뢰할 수 있으며, 50,001번째 요청이 들어올 때 이미 가동 중이어야 한다고 믿기 때문입니다.