AI가 개입하기 시작하면 규칙만으로는 충분하지 않습니다

상상해 보세요. 새벽 3시입니다. 카메라가 침실에서 노인이 쓰러진 것을 감지합니다. AI 에이전트(AI agent)가 ensure_safety [emergency]를 실행합니다. 실행 계획에는 응급 구조대가 들어올 수 있도록 현관문을 여는 동작이 포함되어 있습니다.

하지만 누군가 3개월 전에 규칙(rule)을 하나 작성해 두었습니다: 자정 이후에는 절대 문을 열지 말 것.

규칙이 승리합니다. 문은 잠긴 상태로 유지됩니다. 구급대원들이 도착했지만 들어올 수 없습니다.

이것은 AI의 버그가 아닙니다. 규칙의 버그도 아닙니다. 다른 맥락에서 밤에 문을 잠그는 것은 정확히 옳은 행동입니다. 이것은 설계 문제(design problem)입니다. 그리고 이는 AI가 실행하도록 설계되지 않은 자동화 로직(automation logic) 위에 물리적 AI 시스템(physical AI systems)을 구축할 때 발생하는 바로 그 문제입니다.

규칙(rule)과 정책(policy)의 차이는 멀리서 보면 작아 보입니다. 둘 다 행동을 제약합니다. 둘 다 "상황 Y에서 X를 하지 마라"라고 말합니다. 하지만 이들은 시스템의 서로 다른 수준에서 작동하며, 물리적 환경에서 이 차이를 잘못 이해하는 것은 실제적인 결과를 초래합니다.

규칙(rule)이란 무엇인가

규칙은 조건과 동작을 매핑하는 정적이고 미리 작성된 지침입니다.

if time > 22:00:
    lock.lock()

...

규칙(Rules)은 자동화 계층(automation layer)에 존재합니다. 규칙은 사람이 구성 시점(configuration time)에 미리 예상된 특정 시나리오를 위해 작성합니다. 적절한 상황에서는 결정론적(deterministic)입니다. 즉, 동일한 입력이 주어지면 항상 동일한 출력을 생성합니다.

규칙은 세상이 예측 가능하고, 장치 세트가 안정적이며, 무엇을 할지 결정하는 주체가 항상 사람일 때 잘 작동합니다. 바로 이러한 이유로 규칙은 지난 15년 동안 홈 자동화(home automation)의 근간이 되어 왔습니다. 이 글에서 규칙이 잘못되었다거나 교체되어야 한다고 주장하는 것이 아닙니다. 규칙은 사람이 의도적으로 구성한 스케줄링, 임계값(thresholds), 그리고 단순한 자동화에 적합한 도구입니다. 일몰 시 현관등을 켜는 규칙에는 정책(policy)이 필요하지 않습니다. 그 규칙은 안전에 영향을 미치지 않으며, 예외 상황(edge cases)도 없고, 그 위에서 작동하는 AI도 없기 때문입니다. 규칙이 실패하는 이유는 그것이 나쁜 아이디어여서가 아니라, 임의의 시간에 임의의 의도(intents)를 실행할 수 있는 자율 에이전트(autonomous agent)와 결합하도록 설계되지 않았기 때문입니다.

하지만 규칙에는 구조적인 약점이 있습니다. 규칙은 작성될 당시 예상되었던 상황에만 대응할 수 있다는 점입니다. 그리고 AI 에이전트가 의도(intents)를 실행하기 시작하면, 발생 가능한 상황의 범위는 그 누구도 규칙을 작성할 수 있는 속도보다 더 빠르게 확장됩니다.

AI가 등장할 때 무엇이 깨지는가

AI 에이전트는 규칙을 작성하지 않습니다. 대신 의도 (intents)를 발생시킵니다.
비전 모델 (vision model)이 쓰러진 사람을 감지했을 때, 모델은 alarm.activate()나 phone.call("911")을 실행하는 것이 아니라 ensure_safety [emergency]를 발생시킵니다. 모델이 집에 아무도 없다고 추론할 때, 장치 목록을 순회하며 하나씩 전원을 끄는 것이 아니라 save_energy [info]를 발생시킵니다.
의도 (intent)는 목표를 표현합니다. 프로토콜 (protocol)은 그 목표를 달성하는 방법을 찾아냅니다.
하지만 여기에 문제가 있습니다. AI 에이전트가 의도를 발생시키기 시작하면, 가능한 모든 시나리오에 대해 규칙을 작성하지 않고도 에이전트가 할 수 있는 일과 할 수 없는 일을 제한할 방법이 필요합니다. 특정 상황을 위해 미리 작성된 것이 아니라, 런타임 (runtime)에 문맥 (context)에 따라 의도를 평가할 수 있는 무언가가 필요합니다.
당신에게는 정책 엔진 (policy engine)이 필요합니다.

중요한 차이점

규칙 (rule)은 다음과 같이 답합니다: X가 발생하면 무엇이 일어나야 하는가?
정책 (policy)은 다음과 같이 답합니다: 누가 요청하는지, 무엇을 하고 싶은지, 그리고 언제인지에 따라 이 동작이 허용되는가?
이 구분은 단순히 외관상의 차이가 아닙니다. 이는 물리적 시스템 (physical system)에서 안전을 생각하는 방식의 구조 전체를 바꿉니다.
현관문 잠금장치를 예로 들어보겠습니다. 규칙을 사용한다면:

# 규칙 1: 자정에 잠금
if time == 00:00:
    lock.lock()
...

이러한 규칙들은 작성된 시나리오에 대해서는 처리할 수 있습니다. 하지만 AI 에이전트가 침입자를 감지하여 새벽 03:00에 control_access [emergency]를 발생시킨다면 어떻게 될까요? 다른 AI 에이전트가 잠금 해제 동작을 포함하는 away_mode를 발생시킨다면 어떻게 될까요? 두 개의 의도가 동시에 발생하여 둘 다 잠금장치에 작용하려 한다면 어떻게 될까요?
규칙은 조합 (compose)되지 않습니다. 각 규칙은 다른 규칙에 대한 지식 없이 고립된 상태로 작성되었습니다. AI가 임의의 시간에 임의의 의도를 발생시킬 수 있는 시스템에서, 규칙의 표면은 무한히 확장되며, 규칙 사이의 간극이 바로 사고가 발생하는 지점입니다.
정책은 다릅니다:

NeverAfterHoursPolicy(
    actuator="unlock",
    device_ids=["lock-frontdoor-01"],
...

이 정책은 어떤 AI가 실행했는지, 어떤 시나리오가 이를 트리거했는지와 관계없이 현관문을 열려고 하는 모든 의도(intent)에 적용됩니다. 이는 한 번만 선언하면 됩니다. 런타임(runtime)에 평가되며, 다른 정책들과 자동으로 결합(compose)됩니다.

또한 명시적인 긴급 예외 사항을 포함하고 있습니다. 물리적 시스템에서는 "자정 이후에는 절대 열지 마라"라는 규칙이 실제 긴급 상황에서는 깨질 수 있어야 하기 때문입니다. 규칙(rules)은 이러한 미묘한 차이를 깔끔하게 표현할 수 없지만, 정책(policies)은 가능합니다.

정책 엔진(policy engine)이 실제로 하는 일

DoSync에서 모든 의도(intent)는 실행되기 전에 정책 엔진(PolicyEngine)을 통과합니다. 엔진은 구성된 모든 정책에 따라 실행 계획을 평가하고 다음 네 가지 판결 중 하나를 반환합니다.

ALLOW — 계획대로 진행
BLOCK — 의도를 완전히 거부
CONFIRM — 실행을 보류하고 인간의 확인을 요청
MODIFY — 실행은 허용하되 특정 동작을 제거하거나 조정

이 과정은 리졸버(resolver, 무엇을 할지 결정하는 단계)와 실행기(executor, 실제로 동작을 수행하는 단계) 사이에서 일어납니다. AI는 이 계층을 절대 우회할 수 없습니다. 긴급 의도(emergency intents)라 할지라도 엔진 자체를 완전히 건너뛰는 것이 아니라, 긴급성 수준(urgency level)에서 정책 제약 조건을 우회하는 방식입니다.

DoSync에서는 다음과 같이 작동합니다:

# AI가 02:00에 save_energy를 실행함
intent = Intent(
    intent=IntentClass.SAVE_ENERGY,
...

AI는 목표를 표현했습니다. 프로토콜은 그 목표를 달성하는 방법을 결정했습니다. 정책 엔진은 AI가 복도 조명 정책이나 시간 기반 가중치, 또는 어떤 장치가 어떤 의도에서 제외되는지에 대해 전혀 알 필요 없이, 결과가 안전한지 보장했습니다.

이것이 가정용을 넘어 중요한 이유

규모가 커지고 규제가 있는 환경에서는 규칙(rule)과 정책(policy)의 구분이 결정적인 차이를 만듭니다.

호텔의 경우, "방에 아무도 없으면 불을 꺼라"라는 규칙은 투숙객이 노트북을 충전 중인데 시스템이 방이 비어 있다고 판단하는 순간 문제가 발생합니다. 반면, "점유 추론(occupancy inference) 결과와 관계없이, 사람이 있는 방의 콘센트 회로 전원은 절대 차단하지 않는다"라는 정책은 모든 가능한 장치 상태에 대한 규칙을 일일이 만들 필요 없이 이러한 예외 상황(edge case)을 처리합니다.

병원에서는 "22:00에 모든 문을 잠근다"라는 규칙이 응급 카트(crash cart)를 층간 이동시켜야 하는 순간 무너집니다. 하지만 "일정(schedule)과 관계없이, 비상 대응 가능 오버라이드(emergency_capable override) 시 문 잠금은 해제 상태로 복구된다"라는 정책은 가장 중요한 시나리오, 즉 설정 단계에서 아무도 고려하고 싶지 않았던 시나리오에 대해 견고하게 작동합니다.

공장에서는 "온도가 임계값을 초과하면 B 라인을 중단하라"라는 규칙이 "교대 근무 인수인계 중에는 B 라인을 절대 중단하지 마라"라는 규칙과 충돌하여 결합되지 못합니다. 의도(intent)에 우선순위를 부여하고 충돌을 명시적으로 해결하는 ConflictResolutionPolicy가 올바른 추상화(abstraction)입니다. 예측 불가능한 방식으로 상호작용하며 계속 늘어나는 조건부 규칙 세트가 아닙니다.

패턴은 항상 동일합니다. 규칙은 예상된 시나리오 사이의 경계에서 무너집니다. 정책은 그 모든 시나리오를 관통하며 결합됩니다.

감사(audit)에 미치는 영향

규제 환경에서 중요한 차이점이 하나 더 있습니다. 바로 감사 가능성 (auditability)입니다.

동작을 실행하는 규칙 (rule)은 흔적을 남기지만, 그 추론 과정은 암묵적입니다. 즉, 조건을 평가한 자동화 로직 속에 파묻혀 있습니다. 무언가 잘못되었을 때 무엇이 일어났는지는 확인할 수 있지만, 왜 그랬는지를 재구성하려면 규칙 코드를 읽어야 합니다.

정책 (policy)의 판결은 명시적입니다. DoSync의 감사 로그 (audit log)에 기록된 모든 의도 실행 (intent execution)은 무엇이 일어났는지, 해결사 (resolver)가 무엇을 결정했는지, 그리고 실행자 (executor)가 무엇을 했는지를 위변조 방지 기능이 있는 SHA-256 체인 기록으로 남깁니다. 추론 과정은 사후에 역공학 (reverse-engineering)을 해야 하는 조건부 로직 속에 파묻혀 있는 것이 아니라, 시스템의 설정 (어떤 정책이 활성화되어 있는지, 어떤 파라미터로 작동하는지) 안에 들어 있습니다.

json{
  "type": "intent_executed",
  "intent": "save_energy",
...

이는 사고 후 분석 (post-incident analysis)에 중요합니다. 규제 준수 (regulatory compliance)에도 중요합니다. 그리고 AI가 증강된 모든 물리적 시스템의 근본적인 책임 (accountability) 문제, 즉 무언가 잘못되었을 때 시스템이 정확히 무엇을 왜 결정했는지 재구성할 수 있는가라는 질문에도 매우 중요합니다.

규칙의 경우, 대답은 대개 "대체로 그렇다"입니다. 정책의 경우, 대답은 "네, 완벽하게 그렇습니다"입니다.

더 깊은 핵심

규칙은 무엇을 해야 하는지를 인코딩합니다. 정책은 무엇이 허용되는지를 인코딩합니다.

인간이 항상 루프 안에 (in the loop) 있을 때는 규칙만으로 충분합니다. 인간의 판단이 규칙이 말하는 것과 실제로 일어나야 하는 것 사이의 간극을 메워주기 때문입니다. 하지만 AI 에이전트가 루프 안에 있을 때는, 그 판단의 간극을 인프라가 메워야 합니다.

그것이 바로 정책 엔진 (policy engine)의 존재 이유입니다. AI를 임의로 제약하기 위해서가 아니라, 시스템의 안전 모델 (safety model)을 명시적이고, 설정 가능하며, 감사 가능하게 만들기 위해서입니다. 이를 통해 AI가 인간이 의도적으로 정의한 경계 내에서 자율적으로 행동할 수 있게 합니다.

AI는 목표를 표현합니다. 프로토콜은 이를 실행합니다. 정책 엔진은 그 결과가 안전한지 보장합니다.

이것이 바로 물리적 AI 시스템에 필요한 계약 (contract)입니다.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
라이선스: Apache 2.0