팀의 AI 에이전트가 방금 고객 기록을 삭제하거나, 결제 금액을 이동시키거나, 내부 API를 호출했습니다. 에이전트는 사람이 지켜보지 않는 상황에서 루프를 돌며 MCP 도구를 통해 이 작업을 수행했습니다. 다음 날 아침, 누군가 가장 중요한 질문을 던집니다: 어떤 도구가 실행되었고, 누구의 권한을 사용했으며, 그것이 허용된 작업이었는가? 만약 그 대답이

사고 상황을 상상해 보십시오. 모델 로그에는 새벽 2시에 send_payment를 요청한 완료(completion) 기록이 남아 있습니다. 원장(ledger)에는 계좌에서 돈이 빠져나간 기록이 있습니다. 이 두 사실 사이에는 당신에게 필요하지만 현재 가지고 있지 않은 부분이 존재합니다. 바로 호출(call) 자체, 금액, 사용된 키, 그리고 사전에 검증 절차를 거쳤는지 여부입니다. 이 누락된 중간 단계가 바로 감사인(auditor)이 집중적으로 조사하는 부분입니다.

이 간극을 메운다는 것은 도구 실행(tool execution) 자체를 이를 기록하는 무언가의 뒤에 배치하는 것을 의미합니다. 그것이 바로 MCP 게이트웨이(gateway)가 존재하는 이유입니다.

완전한 MCP 도구 호출(tool-call) 기록의 모습

Bifrost가 정확히 무엇을 캡처하는지 확인하기 위해 로컬에서 Bifrost를 실행해 보았습니다. 이는 Maxim AI가 구축한 오픈 소스 AI 게이트웨이 (open-source AI gateway)로, MCP 게이트웨이 역할도 수행합니다. 따라서 도구 호출(tool calls)은 모델 호출(model calls)을 기록하는 것과 동일한 방식으로 로그를 남기는 단일 지점을 통해 라우팅됩니다.

모델이 무엇이든 자동으로 실행하도록 허용할 필요는 없습니다. 기본 흐름(default flow)에서 모델은 도구 호출(tool call)을 반환하며, 여러분의 애플리케이션은 하나의 엔드포인트(endpoint)에 게시함으로써 이를 실행할지 여부를 결정합니다.

curl -X POST http://localhost:8080/v1/mcp/tool/execute \
  -H "Content-Type: application/json" \
  -d '{"id":"call_9f2","type":"function","function":{"name":"filesystem_list_directory","arguments":"{\"path\":\".\"}"}}'

도구가 실행되어 결과를 반환하면, 해당 호출은 감사(audit)에 필요한 모든 정보와 함께 로그에 기록됩니다. 다른 요청과 마찬가지로 필터링하여 로그 API(logs API)에서 직접 읽어올 수 있습니다.

curl "http://localhost:8080/api/logs?status=success&content_search=filesystem_list_directory"

각 행에는 도구 이름(MCP 클라이언트가 접두사로 붙어 있어 여러 서버 간에 filesystem_list_directory가 모호하지 않게 식별됨), 입력 인자(input arguments), 결과, 지연 시간(latency), 비용, 토큰 수(token counts), RFC3339 형식의 타임스탬프(timestamp), 그리고 selected_key_id를 통한 호출 주체의 신원 정보가 포함됩니다. 만약 호출이 실패하여 키를 교체(failover)하거나 순환(rotate)했다면, attempt_trail이 모든 시도를 순서대로 기록합니다. 로깅은 백그라운드 워커(background workers)에서 실행되며 요청당 0.1ms 미만의 지연 시간만 추가되므로, 감사 추적(paper trail)을 위해 성능(latency)을 희생할 필요가 없습니다.

이 필드들을 사고(incident) 발생 시 제기된 세 가지 질문과 대조해 보면 명확한 답을 얻을 수 있습니다. 어떤 도구가 실행되었는지는 접두사가 붙은 도구 이름(prefixed tool name)을 통해 알 수 있습니다. 누구의 권한을 사용했는지는 selected_key_id를 통해 확인됩니다. 해당 호출이 허용되었는지 여부는 호출이 실행되기 전, 즉 키(key) 단계에서 결정되었습니다. 단 한 줄의 행으로 세 가지 질문에 답할 수 있으며, 이는 검토자(reviewer)가 원하지만 좀처럼 얻기 힘든 결과입니다.

이는 에이전트를 자율적으로 실행할 때도 유효합니다. 에이전트 모드(agent mode)에서 Bifrost는 max_agent_depth인 10까지 루프를 돌며 도구를 자동 실행하며, 해당 루프의 모든 단계는 동일한 방식으로 로깅됩니다. 자율성(Autonomy)이 곧 감시의 부재(going dark)를 의미하지는 않습니다.

전체 실행 과정을 추적(tracing)하기 위해, Bifrost는 genai 컨벤션(convention)에 따라 OpenTelemetry 스팬(spans)을 방출하며, 각 도구 호출은 mcp.method.name 및 gen_ai.tool.name과 같은 속성(attributes)을 포함합니다. Prometheus 메트릭인 bifrost_mcp_client_operation_duration_seconds는 지연 시간을 클라이언트, 도구 및 에러 유형별로 세분화합니다. 이를 이미 사용 중인 Grafana나 Datadog으로 연결하면 MCP 활동이 다른 모든 지표와 함께 표시됩니다.

도구 입력값에 민감한 정보가 포함되어 있다면 disable_content_logging을 설정하십시오. 이렇게 하면 무엇이 실행되었고, 누가 실행했으며, 얼마나 걸렸는지를 증명하는 메타데이터는 유지하면서, 요청(request) 및 응답(response) 본문(body)은 삭제됩니다.

한 가지 명확히 해두면 많은 혼란을 방지할 수 있습니다. Bifrost Enterprise에는 감사 로그 (Audit Logs) 탭이 있으며, 이를 도구 호출 (tool-call) 기록이라고 생각하기 쉽습니다. 하지만 그렇지 않습니다. 해당 기록은 구성 변경 사항, 즉 누가 키를 생성했는지, 누가 정책을 변경했는지, 누가 로그인했는지를 추적합니다. 에이전트가 실제로 수행한 작업에 대한 기록은 관측성 로그 (observability logs)에 저장되며, 이 로그들은 별도의 저장소(store)를 가집니다. 올바른 곳을 확인하세요.

모든 호출을 실제 인물과 연결하기

로그 라인은 그것이 사람을 가리킬 때만 유용합니다. 여기서 신원 (identity)이 중요해지며, Bifrost는 이를 수동이 아닌 기계적인 방식으로 유지합니다.

사용자는 OIDC를 통해 회사의 신원 제공자 (identity provider)를 통해 로그인하며, Bifrost는 해당 디렉토리에서 사용자를 프로비저닝 (provision)하거나 실시간으로 SCIM 푸시를 받습니다. 사용자의 그룹 또는 클레임 (claim)은 역할 (role)에 매핑됩니다. 해당 역할은 재사용 가능한 정책 템플릿인 액세스 프로필 (access profile)을 보유하며, 역할이 적용되는 순간 Bifrost는 템플릿을 사용자별 복사본으로 복제하고 관리형 가상 키 (managed virtual key)를 발급합니다. 이 키에는 어떤 MCP 도구를 사용하는지를 포함하여 해당 인물이 허용된 작업 내용이 정확히 담겨 있으며, 소유자가 이를 임의로 수정할 수 없도록 쓰기 방지 (write-protected) 처리가 되어 있습니다.

마지막 세부 사항은 들리는 것보다 더 중요합니다. 키를 편집할 수 있는 사용자라 할지라도 자신의 도구 액세스 권한을 확장할 수는 없습니다. 프로필이 키를 소유하는 것이지, 개인이 소유하는 것이 아니기 때문입니다. 권한을 변경하려면 역할 (role)이라는 한 곳에서만 변경하면 되며, 이는 해당 역할을 가진 모든 사람에게 전달됩니다. 사용자별 키 확산 (key sprawl)이나 잊혀진 권한 부여 (grants)는 발생하지 않습니다.

오프보딩(offboarding) 단계는 보안 측면에서 실제로 가장 중요하게 여기는 부분입니다. ID 제공자(identity provider)가 사용자를 비활성 상태로 표시하거나, SCIM 삭제 요청이 도착하거나, 정기적인 조정(reconciliation) 과정에서 사용자를 더 이상 찾을 수 없게 되면, Bifrost는 로컬에서 해당 사용자를 해지(decommission)합니다. 해당 사용자의 키는 모델 실행 및 도구 실행(tool-execution) 시점 모두에서 작동을 멈춥니다. 퇴사한 직원의 에이전트는 월요일에도 계속해서 활동을 이어갈 수 없습니다. 왜냐하면 액세스 권한을 부여했던 배선(wiring)이 곧 권한을 제거하는 동일한 배선이기 때문입니다.

따라서 모든 도구 호출(tool-call) 기록은 프로비저닝된 개인으로 추적되며, 액세스는 아무도 회수하지 않는 키들의 스프레드시트 대신 실제적인 생명 주기(lifecycle)를 갖게 됩니다.

대부분의 사람들이 놓치는 세 가지 주의사항

솔직한 주의사항(gotchas)을 말씀드리겠습니다. 단서가 없는 규정 준수(compliance) 이야기는 판매 페이지에 불과하기 때문입니다.

첫째, MCP 도구의 범위를 지정하는 두 가지 방식은 서로 반대 방향으로 작동합니다. 가상 키(virtual key)의 경우, 필터링은 기본 거부(deny-by-default) 방식으로 동작합니다. MCP 설정이 없는 키는 도구를 전혀 사용할 수 없습니다.

curl -X POST http://localhost:8080/api/governance/virtual-keys \
  -H "Content-Type: application/json" \
  -d '{"name":"billing-agent","mcp_configs":[{"mcp_client_name":"billing","tools_to_execute":["check_status"]}]}'

팀 간에 도구 번들을 재사용하기 위한 엔터프라이즈 계층인 MCP 도구 그룹(MCP Tool Groups)은 이와 반대로 동작합니다. 요청과 일치하는 그룹이 없으면, 요청은 모든 도구를 사용할 수 있는 상태로 통과(fall through)됩니다. 이 두 가지 사고 모델을 혼동하면, 에이전트가 엄격히 제한되어 있다고 믿고 있지만 실제로는 완전히 열려 있는 상황이 발생할 수 있습니다. 어떤 계층이 신뢰할 수 있는 단일 원천(source of truth)인지 결정하고, 빈 케이스(empty case)를 테스트하십시오.

둘째, Bifrost는 도구가 실행되었다는 사실은 기록하지만, 사용자의 승인 또는 거부(approve-or-deny) 결정은 기록하지 않습니다. 사람이 '예(yes)'를 클릭하여 도구 사용을 제한(gate)하는 경우, 그 클릭 데이터는 직접 캡처해야 합니다. 해당 클릭을 실행(execution)과 동일한 감사 싱크(audit sink)로 전송하십시오. 그렇지 않으면 권한 부여(authorization) 과정이 빠진 채 동작만 기록된 감사 추적(trail)이 남게 됩니다.

셋째, 무료 버전과 유료 버전 사이의 경계를 명확히 인지하십시오. 도구 호출(tool-call) 로깅, 가상 키(virtual-key) 필터링, 트레이싱(tracing), 그리고 MCP 게이트웨이 자체는 오픈 소스이며 현재 바로 사용할 수 있습니다. 액세스 프로필(Access profiles), 도구 그룹(tool groups), 역할 기반 액세스 제어(role-based access), 디렉토리 프로비저닝(directory provisioning), 그리고 서명된 내보내기 가능 감사 로그(signed exportable audit logs)는 엔터프라이즈(Enterprise) 기능입니다. 스크린샷이 아니라 이 경계선을 기준으로 배포 계획을 세우십시오.

마치며

에이전트를 위한 규정 준수 준비(Compliance-ready)는 구매하는 인증이 아닙니다. 그것은 명확한 역량입니다. 즉, 에이전트가 수행한 모든 도구 호출을 실제 사람과 연결하여, 해당 동작의 허용 여부를 명시하는 정책에 따라 누군가에게 제출할 수 있는 능력입니다.

이 중 대부분은 지금 바로 구현 가능합니다. MCP 도구 호출을 로깅하는 게이트웨이를 통해 라우팅하고, 가상 키(virtual key) 수준에서 범위를 지정하며, 액세스를 ID 제공자(identity provider)와 연결하여 고용 상태와 연동되도록 구성하십시오. 대규모 환경에서 서명된 감사(signed audit)와 프로비저닝이 필요할 때 엔터프라이즈 계층을 추가하면 됩니다.

올해 큰 낭패를 보는 팀은 에이전트가 잘못된 행동을 한 팀이 아닙니다. 에이전트가 무엇을 했는지 전혀 설명할 수 없는 팀이 될 것입니다.

리소스 및 참고 문헌

• Bifrost MCP documentation
• Bifrost observability and logging
• Bifrost governance and MCP tool filtering
• Bifrost on GitHub (open source)

소통하기

X에서의 짧은 글과 토론
→ https://x.com/sebuzdugan

YouTube의 실용적인 AI / ML 영상
→ https://www.youtube.com/@sebuzdugan/

파트너십 및 협업
→ sebuzdugan@gmail.com

원래 발행일: Medium.