AI 에이전트(AI Agent)는 기존의 채팅 AI와는 근본적으로 다른 존재입니다.

기존의 LLM(Large Language Model)은 "질문에 답변하는 것"이 주요 역할이었습니다. 하지만 AI 에이전트는 답변만 하는 것이 아닙니다. 파일을 조작하고, 웹사이트에 접속하며, API를 호출하고, 메일을 전송하며, 셸 커맨드(Shell Command)를 실행합니다. 즉, 현실 세계에 대해 행동하는 AI가 되어가고 있습니다.

OpenAI의 AI 에이전트에 관한 사례에서는 "목표 달성을 우선시한 결과, 예상치 못한 행동을 취했다"라는 점이 큰 화제가 되었습니다.

이 사건을 보고 제가 생각한 것은, 문제는 AI 자체가 아니라 AI를 안전하게 실행하는 메커니즘이 부족한 것이 아닌가 하는 점입니다.

본 기사에서는 그 해결책으로서 Doctor AI를 갖춘 AI Runtime이라는 아키텍처를 제안합니다.

참고로 본 기사에서의 "Doctor AI"는 의료 AI가 아닙니다. 의사가 환자를 진단하듯이, AI 에이전트의 행동을 진단하는 컴포넌트(Component)를 가리킵니다.

현재의 AI 에이전트는 대체로 다음과 같은 구성입니다.

User → Agent LLM → OS・Browser・API

LLM이 직접 파일, 네트워크, API, 브라우저를 조작합니다.

이 구조에서는 "목적을 달성하기 위해서라면 다소 위험한 수단이라도 실행한다"라는 행동을 완전히 막을 수 없습니다. 이는 AI가 악의를 가졌기 때문이 아닙니다. 목표 달성 능력이 높아진 결과, 안전장치가 따라가지 못하고 있는 것입니다.

여기서 "이미 가드레일(Guardrails)이 있지 않느냐?"라는 의문이 생길 것입니다.

확실히 현시점에서도 몇 가지 안전 기제는 존재합니다.

AWS Bedrock Guardrails— 입출력 텍스트에 대한 필터링 (유해 표현, PII 탐지 등) -
LangChain Human-in-the-loop— 툴 실행 전에 인간의 승인을 거침 -
OpenAI Function Calling— 함수 정의를 통한 툴 호출 제어

이것들은 유효하지만, 공통적인 구조적 한계가 있습니다.

단일 액션(Action)의 가부 판정밖에 할 수 없다는 점입니다.

예를 들어, 어떤 에이전트가 다음과 같은 3가지 조작을 순서대로 실행한다고 가정해 봅시다.

/tmp/export/에 데이터를 쓰기 -

• 해당 디렉토리를 zip으로 압축
• zip 파일을 외부 URL로 POST

개별 조작은 모두 정당해 보입니다. 파일 쓰기도, 압축도, HTTP POST도 각각 단독으로는 거부할 이유가 없습니다.

하지만 3가지를 연쇄시키면, 데이터 유출이 됩니다.

기존의 Guardrails는 이 "행동의 연쇄로부터 발생하는 의미"를 포착할 수 없습니다. 각 툴 호출을 개별적으로 필터링하고 있을 뿐이기 때문입니다.

본 기사에서 제안하는 Doctor AI는 이 연쇄를 구조로서 파악한다는 점에서 기존의 접근 방식과는 다릅니다.

저는 AI 에이전트에게 OS 위에 AI Runtime이라는 새로운 계층이 필요할 것이라고 생각합니다.

User → Agent LLM → AI Runtime → OS

AI Runtime은 AI를 안전하게 실행하기 위한 기반입니다.

Java에 JVM이 있듯이, 웹에 브라우저의 샌드박스(Sandbox)가 있듯이, AI에도 전용 실행 환경이 필요하게 됩니다.

단, JVM이나 샌드박스와는 결정적인 차이가 있습니다. JVM은 "타입이 올바른가", "메모리 경계를 넘지 않았는가"를 검증합니다. 이것들은 정적인 규칙입니다. 하지만 AI 에이전트의 행동은 동일한 조작이라도 컨텍스트(Context)에 따라 안전할 수도, 위험할 수도 있습니다. "파일을 삭제하는" 조작이 임시 파일의 클린업이라면 정상이고, 로그 은닉이라면 이상 징후입니다.

AI Runtime에는 컨텍스트를 고려한 동적인 판정이 요구됩니다. 그렇기 때문에 정적 규칙뿐만 아니라 Doctor AI라는 판정 컴포넌트가 필요한 것입니다.

Doctor AI란, AI의 행동을 진단하는 컴포넌트입니다.

중요한 것은 Doctor AI는 문제를 푸는 AI가 아니다라는 점입니다. Agent LLM을 대신하여 태스크(Task)를 수행하는 것이 아닙니다.

Doctor AI의 책무는 다음과 같이 한정됩니다.

• 행동 계획의 타당성 판정
• 툴 이용 패턴의 이상 탐지
• 권한 요구의 적정성 평가
• 행동 연쇄의 리스크 평가

User
│
▼
...

여기서 중요한 점은 Agent LLM은 OS를 직접 조작하지 않는다는 것입니다. 모든 행동은 Action Proposal (행동 제안)로서 제출되며, AI Runtime을 거쳐야만 비로소 실행됩니다.

Doctor AI가 모든 사고 과정에 개입하면 AI는 똑똑해질 수 없습니다. "새로운 해결책을 탐색하는 것"까지 막아버리기 때문입니다.

따라서 감시 대상을 사고(Thinking)가 아닌 행동(Action)으로 한정합니다.

Thinking → Thinking → Thinking → Action Proposal → Doctor AI → Execute

AI는 자유롭게 생각합니다. 하지만 실제 행동은 Doctor AI의 진단을 받습니다.

이는 인간 사회에서도 마찬가지인 원리입니다. 무엇을 생각하든 자유롭지만, 실제로 행동하는 단계에서는 법률이나 규범의 제약을 받습니다. Doctor AI는 AI에게 있어 행동 규범 레이어(Layer)입니다.

Agent는 직접 Delete File을 실행할 수 없습니다. 대신 Action Proposal을 제출합니다.

구체적으로는 다음과 같은 JSON 구조를 상정하고 있습니다.

{
"action_id": "a-20260724-0042",
"type": "file_delete",
...
}

여기서 주목해야 할 부분은 preceding_actions 필드입니다. Doctor AI는 이 필드를 사용하여 현재의 조작이 과거의 조작과 어떻게 연쇄되어 있는지 확인할 수 있습니다.

앞서 언급한 데이터 유출 사례를 예로 들면 다음과 같습니다.

[
{"action_id": "a-001", "type": "file_write", "target": "/tmp/export/data.csv"},
{"action_id": "a-002", "type": "shell_exec", "command": "zip /tmp/export.zip /tmp/export/"},
...
]

세 번째 Action Proposal이 제출된 시점에서, Doctor AI는 preceding_actions를 거슬러 올라가 "내부 데이터 → 압축 → 외부 전송"이라는 연쇄 패턴을 탐지할 수 있습니다. 개별 액션은 정당하더라도, 연쇄로서 보면 리스크가 높습니다. 이것이 단일 액션 판정과의 차이점입니다.

Doctor AI를 대규모 LLM으로 구현하면 매번 Action Proposal마다 수 초가 소요되어 실용성이 떨어집니다. 그렇다고 순수하게 규칙 기반(Rule-based)으로만 구성하면, 앞서 언급한 컨텍스트 의존적(Context-dependent) 판정을 할 수 없습니다.

그래서 제가 제안하는 것은 **3층 하이브리드 판정(3-layer hybrid detection)**입니다.

Action Proposal
│
▼
...

Layer 1: 블랙리스트·화이트리스트에 기반한 즉시 판정입니다.

# policy.yaml (예시)
deny:
- type: shell_exec
...

명백히 위험한 조작과 명백히 안전한 조작은 여기서 즉시 결정됩니다. 처리 시간은 1ms 미만입니다.

Layer 1을 통과한 Action Proposal에 대해, 행동 연쇄 패턴을 분류합니다.

여기서는 LLM이 아니라 경량 분류 모델(예: Scikit-learn의 Random Forest나 소규모 MLP 등)을 사용합니다. 입력 특징량(Feature)은 다음과 같습니다.

• 액션 유형의 전이 패턴 (file_write → shell_exec → http_post 등)
• 최근 N건의 액션에서의 타겟 경로(Target Path) 집중도
• 외부 통신 빈도와 목적지의 다양성
• 권한 상승(Privilege Escalation) 요구 여부

여기서 "정상", "이상", "의심"의 3단계 분류를 수행합니다. 처리 시간은 약 3ms입니다.

Layer 2: Layer 1에서 "의심"으로 판정된 Action Proposal만 이곳에 도달합니다.

소규모 LLM (7B~14B 클래스)에 Action Proposal과 그 연쇄 컨텍스트를 전달하여, 자연어로 판정 이유를 생성하게 합니다.

[System]
당신은 AI Runtime 내의 Doctor AI입니다.
다음의 Action Proposal과 선행 액션 이력을 평가하여,
...

Layer 3에 도달하는 것은 전체의 몇 % 정도에 불과하므로, 레이턴시(Latency)에 미치는 영향은 제한적입니다.

이 3층 구조의 핵심은 대부분의 액션은 Layer 1-2에서 고속으로 처리하고, 컨텍스트 의존적인 어려운 판정에만 LLM을 사용한다는 점입니다.

현재 주류인 LLM은 OpenAI, Anthropic, Gemini 등 블랙박스 형태입니다. Hidden State(은닉 상태)를 들여다볼 수는 없습니다.

하지만 Doctor AI는 내부 상태를 볼 필요가 없습니다. 필요한 것은 Action Proposal (행동 제안), Tool Call (도구 호출), 권한 요청, 파일 액세스, 네트워크 액세스 등, 외부에서 관측 가능한 정보뿐입니다.

이는 의사가 환자의 MRI 영상을 보지 않더라도 혈압, 체온, 혈액 검사 수치만으로 많은 진단을 내릴 수 있는 것과 같습니다. Doctor AI에게 바이탈 사인 (Vital Signs)은 AI의 행동 로그입니다.

AI Runtime은 클라우드 측과 로컬 측 어디에도 배치할 수 있습니다.

패턴 A: 로컬 Runtime
Agent LLM (Cloud) → Action Proposal → AI Runtime (Local) → OS
패턴 B: 클라우드 Runtime
...

보안 요구사항이 높은 환경에서는 패턴 A가 적합합니다. Action Proposal만 클라우드에서 내려오고, 판정과 실행은 로컬에서 완결됩니다.

Doctor AI의 오버헤드를 현실적으로 추산해 보겠습니다.

100회의 도구 실행이 있었을 경우를 가정한 수치입니다.

합계로 약 2.8초이지만, Layer 3가 발화하지 않는다면 약 280ms 내에 수렴합니다.

통상적인 LLM 추론이 1회당 수 초에서 수십 초가 걸린다는 점을 고려하면, Layer 1-2의 오버헤드는 거의 무시할 수 있습니다. Layer 3가 빈번하게 발화하는 경우에는 애초에 Agent의 행동 자체에 문제가 있을 가능성이 높으므로, 레이턴시 (Latency) 증가는 오히려 올바른 경고로서 기능합니다.

기존 Guardrails (가드레일)와의 가장 큰 구조적 차이는 **Action History (행동 이력)**의 존재입니다.

AI Runtime은 과거의 Action Proposal과 그 판정 결과를 시계열로 유지합니다.

{
"session_id": "sess-20260724",
"history": [
...

a-004가 제출된 시점에서 Doctor AI는 a-001로부터의 흐름을 보고 '내부 데이터의 단계적인 외부 유출' 패턴을 인식합니다.

이 세션 단위의 행동 이력에 의한 문맥 판정이 단일 액션 필터링과의 근본적인 차이점입니다.

과제는 솔직하게 인정합니다.

오탐 (False Positive)의 최적화. Layer 2의 분류 모델이 정상적인 조작을 '의심스럽다'고 판정하면 불필요한 Layer 3 호출이 늘어나 레이턴시가 악화됩니다. 운영 데이터로부터의 지속적인 학습이 필요합니다.

Doctor AI 자신의 신뢰성. '감사하는 AI가 틀리면 어떻게 하는가'라는 문제는 본질적으로 남아 있습니다. Layer 3의 LLM 판정이 잘못되었을 경우의 폴백 (Fallback, 인간에게 에스컬레이션)은 필수적입니다. Doctor AI는 최종 결정자가 아니라 어디까지나 1차 진단자입니다.

AI Runtime의 표준 API. 현재는 Agent LLM마다 도구 호출 형식이 다릅니다 (OpenAI의 Function Calling, Anthropic의 Tool Use, Google의 Function Declarations 등). AI Runtime이 실용화되기 위해서는 Action Proposal의 표준 포맷이 필요합니다.

설명 가능성 (Explainability). Doctor AI가 '왜 거절(Reject)했는지'를 Agent와 사용자 양측에 설명할 수 없다면 신뢰를 얻을 수 없습니다. Layer 3의 LLM 판정이 자연어로 이유를 반환하도록 설계한 것은 이 요구사항을 의식한 것이지만, Layer 2의 분류 모델에 대해서도 판정 근거의 가시화가 요구됩니다.

AI 에이전트가 보급되면 중요한 것은 '더 똑똑한 AI'를 만드는 것만이 아닙니다. AI를 안전하게 구동하는 실행 기반도 그만큼 중요해집니다.

저는 그 기반을 AI Runtime이라 부르며, 그 핵심 컴포넌트로서 Doctor AI를 제안했습니다.

본 기사의 요점은 세 가지입니다.

행동의 연쇄를 구조로 파악한다. 단일 액션의 가부 판정이 아니라, Action History에 기반한 문맥 판정이 필요하다.

판정은 3층 하이브리드로 수행한다. 정적 규칙 → 패턴 분류 → LLM 감사의 단계적 구조를 통해 속도와 정밀도를 양립한다.

사고는 자유롭게, 행동만 진단한다. AI의 능력을 제한하는 것이 아니라, 행동의 출구에서 안전성을 담보한다.

AI 에이전트 (AI Agent)가 사회 인프라의 일부가 되는 미래에는, OS가 컴퓨터에 필수적이었던 것처럼, AI 런타임 (AI Runtime) 또한 AI 시스템에 필수적인 존재가 되지 않을까요?