Orbit · 가이드 · Chapter 10
Protocol
AI는 계약 없이 움직이지 않습니다
Protocol은 AI가 무엇을 읽고, 어떤 형식으로 답하고, 어디까지 실행할 수 있는지를 정하는 런타임 계약입니다. 방화벽이 아니라, 맥락에 따라 달라지는 운영 경계.
읽기 9분 · 마지막 업데이트 2026-04-28
Section 01
한 장면 — AI가 세무 자료를 열려 했을 때
개념 설명 전에 장면부터 봅니다. 재무팀 민지가 AI 에이전트에게 세금 질문을 합니다. 에이전트는 답을 완성하기 위해 HR 급여 데이터를 참조하려 합니다. 이 순간, Protocol이 개입합니다.
민지: "Q1 매출 기준으로 부가세 예상 금액 계산해줘."
에이전트가 Tax Field 내 ERP 매출 데이터를 읽습니다. Read: allowed
에이전트가 더 정확한 답을 위해 HR 급여 데이터를 참조하려 합니다.
Protocol이 차단합니다: "HR 급여 데이터는 현재 Tax Field read scope 밖입니다." Read: blocked
에이전트가 Tax Field 내 자료만으로 답변을 완성합니다. 차단된 시도는 Evidence에 기록됩니다.
에이전트가 틀린 답을 준 것이 아닙니다. 더 나은 답을 찾으려다가 경계를 넘으려 한 것입니다. Protocol이 없으면 이 시도는 성공했을 것이고, 민지는 자신의 세금 질문에 대한 답이 다른 팀의 급여 정보를 참조했다는 사실을 모릅니다.
Protocol은 AI를 "약하게" 만드는 것이 아닙니다. AI가 해도 되는 일의 경계를 명확히 해서 신뢰할 수 있는 결과를 만드는 장치입니다. 차단 기록이 남기 때문에 나중에 "왜 이 자료를 안 썼지?"라는 질문에도 답이 있습니다.
Section 02
Protocol이 무엇인가
Protocol은 AI 에이전트와 자동화 시스템이 운영 환경 안에서 지켜야 하는 런타임 계약입니다. 방화벽이 네트워크 패킷을 차단하듯 Protocol이 모든 요청을 걸러내는 것이 아닙니다. 대신, 에이전트가 실행되는 맥락에 따라 읽기 범위, 답변 형식, 실행 가능 동작을 동적으로 정합니다.
비유하면 이렇습니다. 같은 의사라도 수술실에서는 수술 동의서에 서명된 부위만 절개합니다. 외래 진료실에서는 환자의 호소를 듣고 처방전을 씁니다. 의사의 능력은 같지만, 어디에 서 있느냐에 따라 할 수 있는 행동이 달라집니다. Protocol이 정하는 것이 바로 이 경계입니다.
| 구분 | 방화벽 / ACL | Protocol |
|---|---|---|
| 작동 시점 | 요청 도착 시 일괄 필터 | 에이전트 실행 중 매 단계마다 |
| 기준 | IP, 포트, 사용자 역할 | 현재 Field, 업무 맥락, 단계 |
| 판단 방식 | 허용 / 차단 이진 판단 | 읽기 · 답변 · 실행 3축 독립 판단 |
| 결과 기록 | 접근 로그 | Evidence로 근거 추적 가능 |
| 변경 주기 | 인프라팀이 수동 변경 | Field 전환 시 자동 적용 |
핵심 구분. 방화벽은 "이 자원에 접근할 수 있는가?"를 묻습니다. Protocol은 "접근할 수 있더라도, 지금 이 맥락에서 이 업무를 위해 써야 하는가?"를 묻습니다. 할 수 있는 것과 해야 하는 것은 다릅니다.
Section 03
세 가지 경계 — Read · Answer · Execute
Protocol은 단일 on/off 스위치가 아닙니다. 세 축이 독립적으로 작동합니다. 읽기는 허용되지만 실행은 차단될 수 있고, 읽기와 실행이 모두 허용되어도 답변 형식이 제한될 수 있습니다.
Read Scope — 무엇을 읽을 수 있는가
에이전트가 참조할 수 있는 데이터의 경계입니다. 현재 Field에 연결된 자료, verified Dictionary에 등록된 항목, 해당 업무 건의 Evidence만 읽을 수 있습니다. 같은 에이전트라도 Tax Field에서는 매출 원장을 읽고, HR Field에서는 급여 내역을 읽습니다.
Answer Contract — 어떤 형식으로 답하는가
답변의 형식과 깊이를 정합니다. 추천, 경고, 요약, 실행 후보는 서로 다른 책임을 갖습니다. "이 계약서에 리스크가 있습니다"(경고)와 "계약서를 수정했습니다"(실행)는 같은 문장에 섞이면 안 됩니다. Answer Contract는 각 유형이 분리되어 전달되도록 강제합니다.
Execution Gate — 어디까지 실행할 수 있는가
에이전트가 데이터를 변경하거나 외부 시스템에 쓰는 행위의 경계입니다. 초안 생성은 허용하되 최종 제출은 사람 승인을 요구하거나, 특정 금액 이상의 변경은 차단하는 식입니다. 실행 게이트가 열리지 않으면 에이전트는 읽고 분석할 수 있지만 아무것도 바꿀 수 없습니다.
Read: O · Answer: O · Execute: X — 데이터를 읽고 분석 보고서를 작성하지만, ERP에 값을 쓰지는 못합니다.
Read: O · Answer: X · Execute: O — 정해진 규칙에 따라 자동 실행하지만, 사람에게 설명하는 답변은 생성하지 않습니다 (배치 자동화).
Read: X · Answer: O · Execute: X — 외부 데이터 없이 일반 지식만으로 답변합니다. 회사 자료를 참조하지 않으므로 범용 조언만 가능합니다.
왜 세 축인가. 읽기만 허용하는 것은 '열람'이고, 실행까지 허용하는 것은 '위임'입니다. 같은 에이전트에게 언제 열람만 시키고 언제 위임할지를 결정하려면, 읽기와 실행이 독립적으로 조절되어야 합니다. 답변 형식까지 분리한 이유는 같은 분석이라도 경고와 추천은 다른 무게를 갖기 때문입니다.
Section 04
Protocol vs Permission
Protocol과 Permission(권한)은 자주 혼동됩니다. 둘 다 "할 수 있느냐"를 판단하는 것처럼 보이지만, 묻는 질문이 다릅니다.
Permission은 "이 사용자(또는 시스템)가 이 자원에 접근할 자격이 있는가?"를 묻습니다. IT 관리자가 역할 기반으로 설정하고, 한번 부여되면 맥락과 무관하게 유지됩니다.
Protocol은 "접근 자격이 있더라도, 지금 이 업무, 이 단계에서 이 자원을 써야 하는가?"를 묻습니다. 같은 사람, 같은 에이전트라도 업무 맥락이 바뀌면 Protocol 경계가 달라집니다.
| 구분 | Permission | Protocol |
|---|---|---|
| 질문 | "접근할 수 있는가?" | "지금 이 맥락에서 써야 하는가?" |
| 설정 주체 | IT 관리자 / 시스템 관리자 | Authority (업무 책임자) |
| 변경 시점 | 역할 변경 시 수동 갱신 | Field 전환 시 자동 적용 |
| 판단 단위 | 자원 단위 (파일, API, DB) | 업무 맥락 단위 (Field + 단계) |
| 기록 | 접근 로그 | Evidence (근거 추적 가능) |
재무팀 에이전트는 Permission 상 ERP 전체 매출 데이터에 접근 가능합니다.
Protocol: Q1 해당 법인의 매출만 Read scope에 포함. 다른 법인·기간 데이터는 차단.
Protocol: 감사 대상 기간 전체 매출이 Read scope에 포함. 단, 답변에 개인정보는 마스킹 필수.
같은 에이전트, 같은 Permission, 하지만 어떤 Field에 있느냐에 따라 볼 수 있는 것이 달라집니다.
Permission만으로 충분하지 않은 이유. 대부분의 보안 사고는 "접근할 수 없는 자원에 접근"해서 생기는 게 아니라, "접근할 수 있는 자원을 부적절한 맥락에서 사용"해서 생깁니다. Protocol은 이 두 번째 종류의 위험을 막습니다.
Section 05
맥락이 바뀌면 경계도 바뀐다
Protocol의 핵심은 맥락 의존성입니다. 고정된 규칙 목록이 아니라, 에이전트가 어떤 Field에서 어떤 단계의 어떤 업무를 수행하고 있느냐에 따라 경계가 실시간으로 결정됩니다.
같은 "계약서 분석" 에이전트가 세 가지 Field에서 완전히 다른 경계로 작동하는 모습을 봅니다.
Tax Field
Read: 매출 원장, 세금계산서
Answer: 세액 계산 근거 필수
Execute: 초안만, 제출 차단
HR Field
Read: 급여·근로 데이터
Answer: 개인정보 마스킹 필수
Execute: 전면 차단
Contract Field
Read: 계약 조건, 이행 기록
Answer: 리스크 분류 형식 필수
Execute: 알림 발송만 허용
Audit Field
Read: 전 기간 데이터 열람
Answer: 감사 증적 형식 필수
Execute: 완전 차단 (읽기만)
Onboarding Field
Read: 신규 입사자 정보
Answer: 체크리스트 형식
Execute: 문서 생성만 허용
에이전트 자체는 동일합니다. 코드, 모델, 학습 데이터가 같습니다. 하지만 Tax Field에서 "계약서를 검토해줘"라고 하면 세금 관련 조항만 분석하고, Contract Field에서 같은 요청을 하면 이행 조건과 위약 조항을 분석합니다.
Protocol이 없는 세계. 범용 에이전트에게 "알아서 해"라고 하면 에이전트는 가능한 모든 자원을 동원합니다. 때로는 좋은 결과를 만들지만, 한 번의 실수로 다른 팀의 민감 정보가 보고서에 포함되거나, 사람의 확인 없이 외부 시스템에 데이터가 전송됩니다. Protocol은 "알아서 해"를 "이 범위 안에서 알아서 해"로 바꿉니다.
Section 06
Protocol이 연결하는 네 가지 층
Protocol은 Orbit의 다른 개념들과 어떻게 맞물리는가. Protocol은 단독으로 존재하지 않습니다. 네 가지 층의 결정이 합쳐져서 하나의 런타임 계약이 만들어집니다.
Authority — 누가 Protocol을 정하는가
Protocol의 경계는 Authority(업무 책임자)가 설정합니다. IT팀이 아니라 업무를 아는 사람이 "이 에이전트는 이 Field에서 여기까지만 읽어도 된다"를 정합니다. Authority가 명확하지 않으면 Protocol도 모호해집니다.
Field — 맥락이 경계를 결정한다
Protocol의 Read scope, Answer contract, Execution gate는 현재 Field에서 파생됩니다. Tax Field에서 열리는 Protocol과 HR Field에서 열리는 Protocol은 다릅니다. Field가 바뀌면 Protocol도 자동으로 바뀝니다.
Agent Studio — Protocol이 에이전트를 묶는다
Agent Studio에서 만든 에이전트는 Protocol 없이 실행되지 않습니다. 에이전트가 배포되려면 어떤 Field에서 어떤 경계로 작동하는지가 먼저 정의되어야 합니다. Protocol은 에이전트의 능력이 아니라 책임의 범위를 정합니다.
Evidence — Protocol 결정은 추적 가능하다
Protocol이 허용한 것, 차단한 것, 차단된 이유가 모두 Evidence로 남습니다. 감사 시점에 "이 에이전트가 왜 이 자료를 참조했는가" 또는 "왜 참조하지 않았는가"에 대한 답이 항상 존재합니다.
| 층 | Protocol과의 관계 | 없으면 생기는 문제 |
|---|---|---|
| Authority | 경계를 설정하는 주체 | 누가 정했는지 모르는 규칙이 됨 |
| Field | 경계를 결정하는 맥락 | 모든 맥락에서 동일한 경계 적용 |
| Agent Studio | 경계가 적용되는 대상 | 에이전트가 제한 없이 작동 |
| Evidence | 경계 결정의 추적 기록 | 차단 이유를 소급할 수 없음 |
Protocol은 신뢰의 인프라입니다. AI가 업무에 깊이 들어올수록 "이 결과를 믿어도 되는가?"라는 질문이 중요해집니다. Protocol은 이 질문에 답하는 구조입니다 — 어떤 자료를 읽었고, 어떤 자료를 읽지 않았으며, 어떤 형식으로 답했고, 어디까지 실행했는지가 항상 투명합니다.