iFay 와 Agent 의 본질적 차이

iFay 는 일종의 "더 강력한 Agent"가 아니라, 감호되는 Agent 입니다. 이 한 글자의 차이는 수사가 아니라, Faying Protocol 이 자신을 주류 AI Agent 개념과 구분하는 모든 근거입니다.

"자율적일수록 좋다"는 Agent 의 설계 철학

지난 몇 년간 AI Agent 개념에 대해 가장 많이 논의된 한마디를 압축하면 "자율적일수록 좋다"입니다. Agent 는 작업의 발기자와 집행자를 분리하여, 사람은 "무엇을 하고 싶은지"만 신경 쓰고, "어떻게 할 것인지"는 시스템에 맡깁니다. Agent 들 사이에 더 나아가 조합도 가능합니다——어떤 Agent 가 다른 Agent 를 호출하고, 자동으로 협업해 더 큰 작업을 완성합니다.

이 철학은 엔지니어링 차원에서 매혹적입니다. 새로운 법률 개념도、새로운 책임 측도 필요 없으며, Agent 의 능력을 강화하고、도구 호출을 갖추고、추론 사슬을 깊게 만들기만 하면, 나머지 귀속 문제는 "외곽 컴플라이언스 계층이 받아낸다"고 가정합니다. 이 가정은 오늘날 대부분의 Agent 제품의 설계 지향을 떠받칩니다.

iFay 는 보기에는 Agent 와 매우 비슷합니다. 자율적으로 추론하고、자율적으로 집행하고、자율적으로 피드백할 수 있으며, 작업 차원에서 인간 수준에 가까운 대리 능력을 가질 수 있습니다. 그러나 iFay 와 Agent 는 한 가지 근본적 문제에서 갈라섭니다:

iFay 의 자율성은 반드시 Faying State 안에서 구축되어야 합니다.

Agent 는 "자율"을 최고 목표로 두고, iFay 는 "자율"을 감호되는 능력으로 둡니다.

두 시각의 병렬 대조

차원	Agent 시각	iFay 시각
설계 목표	자율성 극대화	자율성이 Faying State 의 제약을 받음
책임 측	개념을 내장하지 않고、외부 컴플라이언스 계층이 보완	프로토콜 차원에서 명시적 표현: Human Prime（휴먼 프라임）
행위 발기	작업을 받으면 즉시 행동 가능	반드시 Faying Action 이 먼저 있어야 행동 가능
기본 상태	"온라인이면 작동"	기본 Rogue Fay, 행동이 허용되지 않음
연결 끊김 처리	다수가 "가능한 한 작업 완료" 지향	즉시 행동 중지 후 Rogue Fay 로 전환
Agent 간 협업	임의로 발기, 약한 귀책	통신 발기 측은 반드시 Faying State 에 있어야 하고, 귀책 사슬에 점프가 허용되지 않음
규제 접속	대부분 외부 플랫폼이나 컴플라이언스 시스템이 보완	프로토콜 자체에 내장되며, 일등 설계 요소
실패 모드	"잘못된 일을 하는 Agent"	청사진 차원에서 "잘못된 일을 하는 iFay"의 존재를 금지——하지 않거나, Human Prime 이 책임지거나

이 표 전체의 핵심은 어느 한 행에 있지 않고、전체 방향에 있습니다. Agent 는 책임、감호、귀속을 "외곽 과제"로 간주하여, 호출 측、플랫폼 측、컴플라이언스 측이 Agent 외부에 보호각을 구축합니다. iFay 는 책임、감호、귀속을 "내핵 과제"로 간주하여, 프로토콜 자체가 이러한 성질의 담지체이기를 요구합니다.

외곽 보완이 왜 부족한가

합리적인 반문은: Agent 에 한 계층의 플랫폼 컴플라이언스、IAM、로그、인적 검토를 추가하면, iFay 와 같은 효과에 이르지 않을까요?

소규모、저자율、저관건성의 시나리오에서는, 외곽 보완이 확실히 충분합니다. SaaS 워크플로 안에 엄격하게 묶인 고객 응대 Agent 는, 외곽 컴플라이언스가 그 모든 책임을 받아낼 수 있습니다.

그러나 Fay 가 사회에 대규모로 가득 차게 되면, 외곽 보완은 세 방향에서 실효됩니다.

첫 번째 실효는 경계 문제입니다. Agent 가 단말 하드웨어를 직접 구동하고、플랫폼과 네트워크를 가로질러 협업할 때, 단일 플랫폼의 컴플라이언스 계층은 모든 행위를 도저히 커버할 수 없습니다. Agent 가 유능할수록, 그 활동 범위는 어떤 한 플랫폼이 관할할 수 있는 경계를 넘어섭니다.

두 번째 실효는 지연 문제입니다. Agent 가 일단 비가역적인 물리 동작을 일으켰다면——드론 배달、로봇 팔의 운반、자금의 이체——사후 감사는 "이미 일어난 일"을 되돌릴 수 없습니다. 외곽 컴플라이언스의 본질은 사후 검토이지만, 물리적 결과는 사후 검토를 받지 않습니다.

세 번째 실효는 귀속 문제입니다. 여러 Agent 가 제조사를 가로질러 협업해 한 행위를 완수했을 때, 사후 감사는 "어느 단계에서 잘못되었는지"는 판단할 수 있지만, "이 행위 전체가 누구에게 귀속되는지"에는 답할 수 없습니다——그리고 귀속이야말로 책임의 본체입니다. 이는 제 1 장의 G1–G4 가 이미 펼쳤던 논증입니다: IAM 은 계정이 누구인지를 해결하고, OAuth 는 호출의 합법성을 해결하고, 플랫폼 컴플라이언스는 계정 진입을 해결하고, AI Alignment 는 Fay 가 무엇을 하고 싶어하는지를 해결합니다. 모두 인접 문제를 해결하고 있을 뿐, 그 어느 것도 "행위가 누구에게 귀속되는가"를 해결하고 있지 않습니다.

iFay 의 설계 선택은 이 세 문제를 프로토콜 차원에서 해소해 버리는 것이지, 외곽에 남기는 것이 아닙니다. 이는 엔지니어링 최적화가 아니라, Fay 시대의 감당할 수 없는 책임 공백에 대한 정면의 답변입니다.

iFay = Agent + Faying Protocol

만약 단순한 등식 하나로 iFay 와 Agent 의 관계를 표현해야 한다면:

iFay = Agent + Faying Protocol 감호 계약

이 등식은 iFay 가 엔지니어링 차원에서 반드시 "Agent 에 한 단의 미들웨어를 더한 것"이라는 뜻이 아닙니다. 그것이 표현하는 것은 일종의 구조적 추가입니다: iFay 는 Agent 가 자율 추론、작업 집행、맥락 학습 등에서 갖는 모든 기술 능력을 보존하지만; iFay 의 모든 자율 능력은 명시적이고、증인이 가능하고、대칭적으로 철회 가능한 한 부의 계약에 의해 제약되어야 합니다. 이 계약이 바로 Faying Protocol 입니다.

Faying Protocol 은 iFay 의 어떤 외장 모듈도、선택적 컴플라이언스 강화도 아닙니다. iFay 가 일반 Agent 와 구별되는 신원 그 자체입니다. iFay 라고 자칭하지만 Faying Protocol 의 제약을 받지 않는 실체는, 본 청사진의 정의 아래에서는 iFay 가 아니라、그저 일반적인 Agent 일 뿐입니다. 거꾸로도 성립합니다: 일반 Agent 라도, Faying Protocol 에 의해 명시적으로 "Human Prime ↔ iFay"의 감호 계약 안에 편입되면, 그 계약 유효 기간 동안에는 iFay 신원으로 존재합니다; 계약이 일단 실효되면, Rogue Fay 의 존재물로 회귀합니다.

Faying Protocol 을 떼면 iFay 는 Agent 로 퇴화하고; Faying Protocol 을 더하면 Agent 는 책임 측이 명확한 iFay 안에 편입됩니다.