Agent Control Plane의 ‘Kernel’ 릴리스가 마침내 출시되었습니다.
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 (excluding the source line you already provided) here? Once I have it, I’ll translate it into Korean while preserving the formatting and technical terms.
소개
제 원본 글에서 저는 거버넌스 없는 인텔리전스는 버그라고 주장했습니다. 우리는 LLM을 마법 상자처럼 다루는 것을 멈추고, 권한, 자원, 안전을 관리할 커널이 필요한 순수 연산 컴포넌트로 취급해야 합니다.
오늘은 이론에서 코딩으로 옮깁니다.
Agent Control Plane v0.1을 출시했으며, 이번 글에서는 그 아키텍처 개념을 실질적인 현실로 바꾸는 세 가지 기능인 Async Support, ABAC, 그리고 Flight Recorder를 자세히 살펴보겠습니다.
문제: 단일 스레드, 안전하지 않은 에이전트
대부분의 에이전트 데모는 간단한 루프입니다: User Input → LLM → Tool Call → Output. 이는 챗봇에는 잘 작동하지만 실제 운영 환경에서는 문제가 발생합니다. 여러 에이전트가 동일한 데이터베이스에 접근하려 하면 어떻게 될까요? “지원 에이전트”가 승인 없이 $10,000을 환불하려 하면 어떻게 될까요?
우리는 에이전트와 세계 사이에 위치하는 레이어가 필요합니다—Kernel.
기능 1: 비동기 지원 (논블로킹 작업)
실제 프로덕션 환경은 동시성을 갖습니다. 하나의 에이전트가 도구가 끝나기를 기다리는 동안 시스템 전체가 멈춰서는 안 됩니다.
v0.1에서 완전한 비동기 지원을 도입했습니다. 커널은 메인 이벤트 루프를 차단하지 않고 여러 에이전트의 도구 실행을 동시에 가로채고 중재할 수 있습니다.
# Multiple agents can operate concurrently
results = await asyncio.gather(
kernel.intercept_tool_execution_async("agent-1", "read_data", {}),
kernel.intercept_tool_execution_async("agent-2", "write_report", {}),
kernel.intercept_tool_execution_async("agent-1", "analyze", {}),
)이것은 단순히 속도 문제만이 아니라 처리량에 관한 것입니다. 스웜이나 멀티 에이전트 시스템을 구축하고 있다면, 블로킹 호출이 적입니다.
기능 2: ABAC (컨텍스트 인식 권한)
표준 “가드레일”은 보통 텍스트 출력만을 확인합니다 (예: “에이전트가 무례한 말을 했나요?”). 기업 환경에서는 논리를 중시합니다.
**속성 기반 접근 제어 (ABAC)**는 에이전트의 역할뿐만 아니라 세계의 상태에 기반해 권한을 정의할 수 있게 합니다.
# Setup: Finance agent can refund IF:
# 1. User is verified, AND
# 2. Amount is under $1000
conditions = [
Condition("user_status", "eq", "verified"),
Condition("args.amount", "lt", 1000)
]
permission = ConditionalPermission("refund_user", conditions, require_all=True)
policy.add_conditional_permission("finance-agent", permission)데모를 실행했을 때 결과는 결정적이었습니다:
- Verified user, $500 refund: ✅ 허용
- Verified user, $1500 refund: ❌ 차단
- Unverified user, $500 refund: ❌ 차단
이는 안전성을 “프롬프트 엔지니어링”(모델이 올바르게 동작하도록 요청)에서 “정책 엔지니어링”(코드로 규칙을 강제)으로 옮깁니다.
기능 3: 플라이트 레코더 (감사 로깅)
에이전트가 파일을 삭제하거나 데이터를 유출하면, 정확히 왜 그런 일이 발생했는지 알아야 합니다. 프롬프트 인젝션이었나요? 환각이었나요? 정책 설정 오류였나요?
Flight Recorder는 커널이 내린 모든 결정을 캡처하는 블랙박스 감사 로거입니다. 정책 판정, 도구 인수, 위반 사유를 기록합니다.
# Action: Blocked write (protected path)
kernel.intercept_tool_execution(
"audit-agent",
"write_file",
{"path": "/etc/passwd"},
input_prompt="User: Update system file"
)
# Result: ❌ Logged as BLOCKED데모에는 get_statistics() 메서드가 포함되어 있어 에이전트의 컴플라이언스 상태를 즉시 확인할 수 있습니다:
- 총 작업 수: 3
- 허용됨: 1
- 차단됨: 2
내가 놓친 것: “섀도우 모드”
이 데모를 만들면서, 이 특정 파일에는 포함되지 않았지만 전체 아키텍처의 일부인 중요한 조각, 섀도우 모드가 있다는 것을 깨달았습니다.
에이전트를 배포할 때 가장 큰 위험 중 하나는 두려움입니다: “데이터베이스를 삭제하면 어떡하지?” Kernel 아키텍처는 “섀도우 모드”를 제공하여, 프로덕션 입력에 대해 에이전트를 실행하고, Kernel이 툴 호출을 가로채어 ABAC 정책에 따라 검증하고, 결과(성공/차단)를 로그에 기록하지만 툴을 실제로 실행하지는 않습니다.
이를 통해 위험 없이 프로덕션에서 에이전트를 “레드‑팀”할 수 있습니다. “에이전트가 이 $5,000 환불을 처리했을 것이지만, 정책이 차단했을 것”이라는 것을 확인할 수 있습니다.
코드 가용성
데모의 전체 소스 코드와 AgentKernel 및 PolicyEngine 클래스를 포함한 내용을 저장소에서 확인할 수 있습니다: