Context Layer: 에이전트의 쓰기를 실행 직전 잠금·한도·승인으로 거르는 계층

에이전트를 ERP·청구·구매 시스템에 붙일 때 사고는 모델이 틀려서보다, 맞는 계산을 잘못된 순간에 써서 납니다. 모델과 기록 시스템 사이에 모든 쓰기를 가로채는 Context Layer를 두고 실행 직전에 스키마·잠금·한도를 코드로 검사하고 승인은 만료되는 상태로 다뤄야 합니다. 시작하려면 대상 업무의 배치 작업 목록과 쓰기 경로부터 확보해야 합니다.

요약

Suhas Dhekane는 2026년 9월 23일 The Autonomous Enterprise(서브스택)에 실은 글에서, 운영에 올린 에이전트가 왜 조용히 실패하는지를 한 사고로 시작합니다. 고성장 B2B SaaS 회사가 1차 고객지원 일부를 에이전트에 맡겼습니다. 수주 동안 스테이징에서 eval을 돌렸습니다. 기준 금액을 넘는 잔액 조정에는 사람 승인(HITL, human-in-the-loop)을 걸었고 프롬프트 가드레일도 여럿 두었습니다. 그런데도 승인된 크레딧 쓰기가 백그라운드 ERP 작업과 부딪혀 청구 동기화가 망가졌습니다. 저자의 진단은 아키텍처입니다. 동시에 움직이는 기업 상태의 조정을 대화형 모델에 기대한 데서 실패가 나왔다고 봅니다. 그래서 모델과 인프라 사이에 Context Layer(모델의 행동을 실행 전에 가로채는 중간 계층)를 두자고 제안합니다.

저자가 말하는 효과는 동시성에서 버틴다는 점입니다. spec(OpenAPI 같은 계약)은 무엇을 호출할 수 있는지만 말하고 지금 그 레코드에 잠금이 걸려 있는지, 정산 작업이 먼저인지는 모릅니다. Context Layer가 이 빈자리를 맡아 호출이 언제, 왜, 어떤 권한으로 실행되는지를 다스립니다. 의도별 도구는 잘못된 인자를 DB에 닿기 전에 걸러 내고 ERP 동기화 중이면 쓰기를 막고 끝나면 반영된다고 사용자에게 알립니다. 격리 수준이나 동기화 규칙을 프롬프트에 적지 않으니 컨텍스트 창도 가벼워집니다. 아래에서는 여섯 가지 구성 요소를 풀고 국내 대기업 ERP·청구·구매 업무에 옮길 때의 점검 목록과 4주 파일럿을 덧붙였습니다.

핵심 메커니즘

Context Layer: 에이전트 행동을 가로채는 operational interceptor

무엇인가. LLM이 제안한 모든 행동을 신뢰하지 않는 입력으로 받아, 실제 시스템에 쓰기 전에 검사하는 중간 계층입니다. 어떻게 작동하나. LLM은 자연어로 다음 단계를 제안하고 도구 하나를 고릅니다. Context Layer는 그 호출을 받아 실시간 잠금, 스키마, 진행 중인 백그라운드 작업을 확인합니다. 통과하면 뒤쪽 서비스를 부르고 막히면 사유를 돌려주고 기준을 넘으면 승인 대기로 보냅니다. 저자는 관제탑에 빗댑니다. 오토파일럿과 기장(사람 승인)이 비행기 한 대를 몰지만 활주로 교통과 지상 대기, 윈드시어처럼 공역 전체를 보는 쪽은 관제탑입니다. 언제 쓰나. 에이전트가 기록 시스템에 쓰는 모든 경우입니다. 조회만 하는 에이전트라면 이 계층의 무게가 훨씬 가볍습니다. 작은 예시(가상 예시). 구매 에이전트가 발주 수량 변경을 제안했는데 같은 시각 MRP(자재 소요 계획) 배치가 돌고 있다고 합시다. Context Layer는 호출을 멈추고 배치가 끝난 뒤 다시 시도하게 합니다.

Semantic Contract: 넓은 CRUD 대신 의도별 MCP 도구

무엇인가. 에이전트에게 무엇이든 고칠 수 있는 범용 엔드포인트를 주지 않고 업무 의도 하나만 수행하는 도구를 주는 계약입니다. 어떻게 작동하나. 원문의 예로 PUT /api/v2/accounts/{id} 대신 apply_seat_downgrade_credit 같은 도구를 Anthropic의 MCP(Model Context Protocol, 모델이 외부 도구를 부르는 표준 규약)로 노출합니다. 모델이 도구를 부르면 계층이 인자를 검증하고 스키마를 확인한 뒤 직렬화해 마이크로서비스를 호출합니다. 도구 이름에 의도가 들어 있으니 검증 규칙을 좁게 걸 수 있고 로그에 남은 이름만 봐도 무엇을 하려 했는지 보입니다. 언제 안 쓰나. 탐색용 조회처럼 의도를 미리 정하기 어려운 읽기 작업은 넓은 조회 도구로 둬도 됩니다. 쓰기만큼은 의도별로 쪼갭니다.

Dynamic Knowledge Graph: 상태는 테이블, 규칙은 그래프

무엇인가. 기업의 사실을 둘로 나눠 두는 방식입니다. 관계형 테이블은 상태를 담고(Account #402는 Enterprise Plan), 지식 그래프는 그 상태에 걸리는 규칙을 담습니다(Enterprise 계정은 맞춤 MSA가 있어 청구 워크플로를 자동으로 멈출 수 없음). 어떻게 작동하나. 에이전트가 행동을 제안하면 Context Layer가 대상 엔터티의 상태를 테이블에서 읽고 그 엔터티에 연결된 규칙만 그래프에서 꺼내 모델에 건넵니다. 모든 정책 문서를 프롬프트에 붓지 않으니 컨텍스트가 가볍고 규칙이 바뀌면 그래프만 고칩니다. 작은 예시(가상 예시). 협력사 지급 보류를 제안받으면 그 협력사가 하도급법 적용 대상이라 지급 기일 조정에 법무 확인이 필요하다는 규칙 한 줄만 붙여 줍니다.

Working Memory와 Canonical State: 메모장과 기록 시스템을 섞지 않기

무엇인가. 에이전트의 기억을 두 종류로 나눕니다. Working Memory는 한 세션의 추론과 중간 계산을 적는 메모장이고 세션이 끝나면 버립니다. 다른 세션으로 맥락이 새는 context bleed를 막으려는 장치입니다. Canonical entity memory(기록 시스템의 엔터티 값)는 구독, 송장, 재고의 진짜 값입니다. 어떻게 작동하나. 기록 시스템의 변경은 모델 메모리를 거치지 않고 관계형 DB의 ACID 트랜잭션(원자성·일관성·격리·지속성을 보장하는 트랜잭션)으로 커밋합니다. 모델이 메모장에 적어 둔 금액이 그대로 원장에 들어가는 길은 없습니다. 커밋 직전에 계층이 기록 시스템의 현재 값을 다시 읽고 그 값으로 실행합니다. 언제 쓰나. 같은 고객이나 같은 발주를 여러 세션이 다루는 업무라면 처음부터 이렇게 나눕니다.

Pre-Flight State Verification: 도구 호출 전 세 가지 결정론적 검사

무엇인가. 도구 호출이 실제 시스템에 닿기 전에 코드로 도는 검사 세 가지입니다. 어떻게 작동하나. 첫째는 스키마 검증입니다. Pydantic이나 Zod로 인자의 타입과 허용값을 확인해 모델이 지어낸 인자를 막습니다. 둘째는 분산 상태 잠금입니다. Redis나 Postgres(SELECT FOR UPDATE 포함)로 대상 레코드에 걸린 잠금과 진행 중인 배치·트랜잭션을 찾습니다. 셋째는 정책 한도입니다. 프롬프트가 무엇이라 하든 애플리케이션 코드가 실행당 상한(원문 예: 100.00달러)을 집행합니다. 세 검사 모두 모델 판단과 무관하게 같은 입력에 같은 결과를 냅니다. 원문의 예. 잘못된 사유 코드(GOODWILL_GESTURE)는 검증기가 거절하고 수정 피드백은 DB를 건드리지 않고 메모장으로 돌아갑니다. ERP 동기화 중이면 RESOURCE_LOCKED를 돌려주고 에이전트는 업데이트가 끝나면 크레딧이 반영된다고 고객에게 안내합니다.

Human Approval States: 만료되고 무효가 되는 승인

무엇인가. 사람 승인을 “승인 버튼을 누르면 실행”이라는 스크립트가 아니라, 엄격한 만료가 있는 명시적 상태 전이로 다루는 방식입니다. 어떻게 작동하나. 원문 예에서 크레딧 적용은 100달러 이하면 에이전트가 자율로 실행합니다. 넘으면 Finance_L1 역할의 승인이 필요합니다. 시간 안에 승인이 없으면 중단한 뒤 사용자에게 알립니다. 기준을 넘으면 계층이 그 사실을 표시하고 암호 서명된 승인 티켓을 발급한 뒤 멈춥니다. 승인 전에 계정 상태가 바뀌면 티켓은 무효가 됩니다. 사고 사례의 승인은 그 순간의 계정 상태와 묶여 있지 않았습니다. 이 구조에서는 티켓이 레코드 상태에 묶이고 커밋 직전에 다시 검사하므로, 진행 중인 원장 이전 잠금에서 쓰기가 멈춥니다. 함께 볼 노트. 실행 전 계약 검사를 거버넌스 쪽에서 다룬 Inventory, Contracts, Maintained Context와 짝을 이룹니다.

통념과 다른 주장

저자가 든 사례

좌석 축소 크레딧: 승인된 쓰기가 ERP 이전 작업과 부딪힌 4시간

구분	내용
상황	고성장 B2B SaaS 회사의 PM이 1차 지원 자동화를 맡았습니다. 대상은 좌석 일할 크레딧, 청구 주기 변경, 프로비저닝 한도 초기화. 안전장치로 수주간 스테이징 eval, 기준 금액 초과 잔액 조정의 사람 승인, 프롬프트 가드레일을 두었습니다.
한 일	연간 플랜 고객이 개발자 좌석 3개를 줄이고 잔액을 계정 크레딧으로 옮겨 달라고 요청했습니다. 에이전트가 금액을 계산해 Slack에 올렸고 지원 리드가 승인했습니다.
결과	40분 전 고객이 엔터프라이즈 업그레이드를 시작했고 백그라운드 NetSuite ERP 작업이 원장 테이블을 옮기는 중이었습니다. 쓰기가 처리 중인 송장 ID에 닿아 마이그레이션 잠금과 충돌했습니다. 청구 동기화 상태가 망가지고 fraud hold(사기 방지 보류)가 걸려 엔지니어 약 200명이 목요일 오후 4시간 동안 잠겼습니다.
연결	Pre-Flight의 분산 상태 잠금, 승인 뒤 상태가 바뀌면 무효가 되는 Human Approval States의 사례입니다. 저자는 모델과 승인자 모두 제 몫을 했다고 보고 원인을 아키텍처에서 찾습니다.

샌드박스를 통과한 뒤 운영에서 드러난 세 실패 유형

구분	내용
상황	샌드박스 파일럿은 탄탄해 보였지만 엣지 케이스가 적고 단일 테넌트 eval이라 위험이 드러나지 않았습니다.
한 일	저자가 운영에서 나타나는 실패를 세 유형으로 정리했습니다. 두 에이전트가 같은 레코드를 갱신해 서로 덮어쓰는 경우, Slack으로 승인된 환불이 그사이 열린 Stripe chargeback과 부딪히는 경우, 상류 동기화 중 약 90초 전의 낡은 캐시 값으로 도구를 부르는 경우입니다.
결과	세 유형 모두 모델의 추론 오류가 아니라 실행 시점의 상태 문제입니다. 개별 회사·수치는 원문에서 밝히지 않았습니다.
연결	Working Memory와 Canonical State 분리, Pre-Flight 잠금 검사, 승인 티켓 무효화가 각각 막는 실패입니다.

기술 디테일: 우리 ERP·청구·구매에 Context Layer를 세우려면

아래는 원문의 구조를 국내 대기업의 SAP·사내 ERP 환경에 대입할 때 필요한 설계로, AX Review가 새로 작성했습니다. 도구 이름, 필드, 반환 코드, 숫자는 가상 예시입니다.

의도별 도구(Semantic Contract)를 정의하려면 현업이 화면에서 하는 쓰기 동작을 하나씩 적고 동작마다 도구 하나를 만듭니다. 이름은 업무 동사와 대상으로 짓고 사유 코드는 자유 문자열이 아니라 enum으로 받습니다. 도구 정의에는 이 도구가 쓰는 ERP 객체와 잠금 키, 연결된 정책을 함께 적어 둡니다. 그래야 검증기와 잠금 검사를 도구 단위로 붙일 수 있습니다. 모델에는 name, description, input_schema만 보이고 나머지 필드는 Context Layer만 읽습니다.

{
  "name": "apply_billing_credit",
  "description": "고객 송장 한 건에 크레딧을 적용한다. 송장 금액 변경이나 취소에는 쓰지 않는다.",
  "input_schema": {
    "customer_id": { "type": "string", "pattern": "^C[0-9]{8}$" },
    "invoice_no":  { "type": "string" },
    "amount_krw":  { "type": "integer", "minimum": 1 },
    "reason_code": { "type": "string", "enum": ["SEAT_REDUCTION", "BILLING_ERROR", "SLA_PENALTY"] }
  },
  "x-context-layer": {
    "target_object": "FI_AR_INVOICE",
    "lock_keys": ["customer_id", "invoice_no"],
    "blocking_jobs": ["AR_MONTH_END_CLOSE", "BILLING_SYNC", "LEDGER_MIGRATION"],
    "policy": "credit_policy_v3",
    "write_path": "BAPI 또는 사내 청구 API (직접 UPDATE 금지)"
  }
}

지식 그래프의 규칙 조각을 꺼내려면 엔터티 유형(고객, 계약, 송장, 협력사, 발주)마다 걸리는 규칙을 그래프의 관계로 적습니다. 예를 들어 “고객 → 계약 유형: 맞춤 MSA → 금지: 청구 자동 정지” 같은 형태입니다. 도구가 호출되면 대상 엔터티에서 2단계 안의 규칙만 조회해 최대 5~10줄로 모델에 붙입니다. 규칙마다 rule_id, source_doc(근거 문서), owner(규칙 담당 부서), valid_from을 달아 두면, 규칙이 바뀔 때 어느 도구의 동작이 달라지는지 추적할 수 있습니다. 그래프에 담긴 규칙의 근거를 남기는 방식은 Cross-Cutting Context Objects의 근거 기록 설계와 함께 쓰기 좋습니다.

Pre-Flight 세 검사를 ERP에 붙이려면 검사 순서를 싼 것부터 둡니다. 스키마 검증은 수 밀리초면 끝나니 맨 앞에 둡니다. 잠금 검사는 세 곳을 봅니다. SAP라면 대상 객체의 잠금 항목(SM12에서 보는 enqueue 잠금)과 진행 중 백그라운드 작업(SM37), 사내 ERP라면 배치 작업 상태 테이블과 DB 행 잠금입니다. 여기에 Context Layer 자체의 분산 잠금(Redis 키 lock:invoice:{invoice_no}, TTL 30초)을 걸어 두 에이전트가 같은 송장을 동시에 쓰지 못하게 합니다. 한도 검사는 정책 파일의 상한을 코드로 비교합니다. 프롬프트에 한도를 적어 두더라도 집행은 코드만 합니다. 막힌 호출은 {"status": "RESOURCE_LOCKED", "retry_after_sec": 600, "user_message": "정산 작업이 끝나면 반영됩니다"}처럼 모델이 고객에게 설명할 수 있는 형태로 돌려줍니다.

낡은 상태로 쓰지 않으려면 제안 시점에 읽은 레코드 버전(최종 변경 일시나 변경 번호)을 Working Memory에 적어 두고 커밋 직전에 다시 읽어 비교합니다. 버전이 다르면 STALE_STATE를 돌려주고 최신 값으로 다시 계산하게 합니다. 승인 대기 건이었다면 티켓도 함께 무효로 돌립니다. 원문이 든 약 90초 전 캐시로 쓰는 실패를 이 검사로 막을 수 있습니다.

승인 상태를 정의하려면 정책 파일에 도구마다 자율 한도, 승인자 역할, 만료 시간, 무효 조건을 적습니다. 아래는 원문의 필드 구조를 참고해 새로 쓴 가상 예시입니다. 서명은 action, 인자 해시, record_version, expires_at을 묶어 HMAC-SHA256으로 만들고 실행 시점에 서명과 버전을 함께 검증합니다. 서명이 맞아도 버전이 다르면 실행하지 않습니다. 실행 호출에는 티켓 ID를 idempotency_key로 붙여, 재시도 때문에 같은 크레딧이 두 번 들어가는 일을 막습니다.

policy: credit_policy_v3
tool: apply_billing_credit
auto_execute:
  max_amount_krw: 100000        # 이하면 승인 없이 실행
approval:
  required_role: AR_TEAM_LEAD   # 초과 시 승인자 역할
  second_role_above_krw: 5000000
  ttl_minutes: 30               # 지나면 EXPIRED
  on_expire: cancel_and_notify_requester
invalidate_when:
  - record_version_changed
  - blocking_job_started
  - approver_role_revoked
ticket:
  sign: hmac-sha256
  bind: [tool, args_hash, record_version, expires_at]

spec을 가드레일로 컴파일하려면 OpenAPI 스키마, 정책 파일, 그래프 규칙을 저장소 한 곳에서 관리합니다. 바뀔 때마다 CI가 검증기 코드와 도구 설명(enum 포함)을 다시 만들고 회귀 시험을 돌린 뒤 배포합니다. 회귀 시험에는 지난 사고와 같은 시나리오(배치 중 쓰기, 승인 뒤 상태 변경, 같은 레코드 동시 요청)를 고정으로 넣습니다. 한도를 바꾸는 일은 프롬프트 수정이 아니라 정책 파일의 변경 요청이 되고 그 이력이 내부통제의 근거가 됩니다.

실패하는 경우와 대응. 아래 표는 반환 코드를 정해 두고 모델이 각 코드에서 무엇을 할지(재시도, 재계산, 사용자 안내, 중단)를 도구 설명에 적어 두는 방식입니다. 모델이 막힌 이유를 모른 채 같은 호출을 반복하는 것이 가장 흔한 2차 실패이므로, retry_after_sec과 최대 재시도 횟수(예: 3회)를 계층이 강제합니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	4주 동안 하는 일
스폰서	재무 또는 IT 담당 임원	대상 업무와 자율 한도 승인, 판정 회의 주재
ERP 기술 담당	SAP Basis·운영 또는 사내 ERP 운영 1명	배치 작업 목록, 잠금 조회 수단, 쓰기 API 확인
엔지니어	백엔드 2명	MCP 서버, 검증기, 잠금·버전 검사, 승인 티켓
업무 담당	청구 또는 구매 실무자 2명	쓰기 동작 목록, 사유 코드, 예외 사례 정리
내부통제	재무 통제 1명	자율 한도, 승인자 역할, 직무 분리 확인
보안	1명	서명 키 관리, 에이전트 계정 권한 범위

시작 전 준비물: 대상 업무 1개의 쓰기 동작 목록과 화면 경로, 대상 테이블·객체를 건드리는 배치 작업 목록(작업명, 주기, 평균 소요 시간, 담당), 월마감·분기마감 일정, 지난 6개월 수정·환불·발주 변경 로그 표본 200건, 현재 승인 규정(금액 구간별 승인자), 최근 1년의 관련 장애 보고서.

SAP·사내 ERP 배치 충돌 사전 점검 목록(가상 예시). 파일럿 첫 주에 ERP 기술 담당과 함께 아래를 하나씩 확인하고 “아니오”인 항목은 2주차 전에 해결합니다.

번호	확인할 것	어떻게 확인하나	막는 실패
1	대상 객체를 쓰는 배치 작업을 모두 아는가	SAP SM37 작업 목록, 사내 스케줄러 목록에서 대상 테이블 기준으로 추림	배치 중 쓰기
2	배치가 도는지 실시간으로 물어볼 수 있는가	작업 상태 조회 API 또는 상태 테이블 읽기 권한	배치 중 쓰기
3	레코드 잠금을 쓰기 전에 알 수 있는가	SAP enqueue 잠금 조회(SM12와 같은 정보), 사내 ERP는 행 잠금 조회	잠금 충돌
4	마감·이전·업그레이드 기간을 기계가 읽을 수 있는가	동결 기간 캘린더를 JSON으로 제공	마감 중 수정
5	레코드 버전 값이 있는가	최종 변경 일시, 변경 번호 필드 확인	낡은 상태 쓰기
6	쓰기가 표준 경로로만 가능한가	BAPI·사내 API만 허용, 에이전트 계정의 직접 테이블 쓰기 권한 회수	검사 우회
7	잘못된 쓰기를 되돌릴 절차가 있는가	역분개·취소 전표 절차와 담당자	복구 지연
8	EDI·은행·결제 연계가 같은 레코드를 바꾸는가	인터페이스 목록과 처리 시각	외부 동기화와 충돌

의도별 도구 설계 표(가상 예시). 쓰기 도구는 처음 3개 안팎으로 시작합니다.

도구	하는 일	필수 인자	사전 검사	자율 한도	승인자
apply_billing_credit	송장 한 건에 크레딧 적용	고객, 송장, 금액, 사유 코드	송장 잠금, 매출채권 마감, 버전	10만 원	채권팀장
change_billing_cycle	청구 주기 변경	고객, 계약, 새 주기, 적용일	계약 규칙(그래프), 청구 배치	없음	영업관리 담당
request_po_qty_change	발주 품목 수량 변경 요청	발주, 품목, 수량, 사유 코드	MRP 배치, 입고 진행, 버전	금액 변화 50만 원	구매 파트장
hold_vendor_payment	협력사 지급 보류	협력사, 송장, 사유 코드	지급 배치, 하도급 규칙(그래프)	없음	재무팀장 + 법무 확인
get_order_status	주문·발주 상태 조회	문서 번호	스키마만	해당 없음	없음

승인 상태 기계(가상 예시). 상태마다 들어가는 조건, 머무는 시간, 빠져나가는 조건을 표로 합의하고 정책 파일로 옮깁니다.

상태	들어가는 조건	만료	무효가 되는 조건	다음 상태
PROPOSED	에이전트가 도구 호출	즉시 판정	스키마 검증 실패	자율 실행, PENDING, 거절
PENDING	금액이 자율 한도 초과	30분	레코드 버전 변경, 차단 배치 시작	APPROVED, EXPIRED, INVALIDATED
APPROVED	승인자 서명	10분 안에 실행	버전 변경, 승인자 권한 회수	재검사 후 COMMITTED
COMMITTED	재검사 통과, 트랜잭션 성공	없음	없음	감사 로그 기록
EXPIRED · INVALIDATED	시간 초과 또는 상태 변경	없음	없음	요청자 알림, 새로 제안

4주 파일럿. 대상은 업무 하나(예: 청구 크레딧 조정)로 좁힙니다.

주차	할 일	산출물
1주	점검 목록 8항 확인, 쓰기 동작 정리, 의도별 도구 3개와 정책 파일 초안	점검 결과표, 도구 정의서, 정책 파일
2주	그림자 운영. 에이전트는 제안만 하고 Context Layer는 판정만 기록, 실제 쓰기는 사람이 기존대로. 과거 로그 200건 재생	판정 로그, 차단 사유 분포
3주	제한 쓰기. 자율 한도 소액, 근무 시간, 차단 배치가 없는 시간대만. 승인 티켓·만료·무효 시험	실제 처리 건 기록, 승인 소요 시간
4주	동시성 시험. 시험 환경에서 배치와 일부러 겹치기, 같은 레코드 동시 요청, 승인 뒤 상태 바꾸기. 판정 회의	동시성 시험 결과, 확대 여부 결정

담당자 인터뷰 질문. 이 업무에서 화면으로 하는 쓰기 동작은 몇 가지이고 그중 금액이 바뀌는 것은 무엇입니까? 그 데이터를 밤이나 마감 때 건드리는 배치는 무엇이고 몇 시간 걸립니까? 승인을 받은 뒤 실제 처리까지 보통 얼마나 걸리고 그사이 고객이나 협력사 상태가 바뀐 적이 있습니까? 잘못 처리했을 때 되돌리는 방법은 무엇이고 누가 합니까? 사유 코드 목록이 있습니까, 아니면 자유 입력입니까?

진행 판정 기준(가상 예시). 4주차 시험에서는 세 가지를 봅니다. 차단 배치 중 쓰기 시도가 모두 RESOURCE_LOCKED로 막히는지, 낡은 상태로 커밋된 건이 0건인지, 승인 뒤 상태가 바뀐 건의 티켓이 모두 무효가 되는지입니다. 셋을 모두 지키면 두 번째 업무로 넓힙니다. 자율 처리 비율이 한도 이하 건의 60%에 못 미치면 사유 코드나 한도 설계를 고쳐 3주차를 다시 돌립니다. 앞의 세 기준 가운데 하나라도 어기면 확대하지 않고 원인을 고칩니다.

AX 적용 제언. 국내 대기업에서 에이전트 파일럿이 막히는 지점은 대개 모델 성능이 아니라 ERP 쓰기 권한을 주느냐입니다. Context Layer는 그 질문을 “어떤 쓰기를, 어떤 상태에서, 누구 승인으로 허용하나”로 바꿔 IT와 재무 통제가 같은 표를 놓고 합의하게 해 줍니다. 순서는 조회 에이전트 → 그림자 운영 → 소액 자율 쓰기 → 승인 상태 기계 → 업무 확대가 무난합니다. 첫 대상으로는 건수가 많고 금액이 작으며 되돌리기 쉬운 청구 크레딧 조정이나 발주 수량 변경 요청이 맞습니다. 지급 보류나 원장 전표처럼 되돌리기 어려운 쓰기는 마지막에 둡니다. 맥락 계층을 플랫폼 투자 관점에서 본 AI Context Platforms, 에이전트를 직원처럼 권한과 kill switch로 관리하는 Digital Teammates와 함께 보면, 이 노트는 그 가운데 실행 직전 한 지점의 설계에 해당합니다.

원문 사례

항목	내용
발표처	The Autonomous Enterprise(서브스택), Suhas Dhekane, 2026.09.23. 부제는 spec 기반 시스템이 자율 에이전트와 실제로 소통하는 방식
출발점	Product Management Accelerate 온라인 세션에서 들은 이야기
핵심 주장	시스템 프롬프트, 날것의 DB 도구, 기본 사람 승인에 기대면 동시성·경쟁 조건·낡은 상태로 조용히 실패. 모델과 인프라 사이에 Context Layer를 둬야 함
사고 사례	B2B SaaS 1차 지원 자동화. 좌석 3개 축소 크레딧이 승인 후 NetSuite 원장 이전 작업(40분 전 시작)과 충돌. 청구 동기화 손상, fraud hold, 엔지니어 약 200명 4시간 잠김
실패 유형	두 에이전트 덮어쓰기, 승인된 환불과 Stripe chargeback 충돌, 약 90초 전 낡은 캐시로 도구 호출
구성 요소	Semantic Contract(MCP 의도별 도구), Dynamic Knowledge Graph, Working Memory 대 Canonical State, Pre-Flight State Verification
3검사	스키마 검증(Pydantic · Zod), 분산 상태 잠금(Redis · Postgres, SELECT FOR UPDATE), 결정론적 한도(실행당 100.00달러 예)
승인	100달러 이하 자율, 초과 시 Finance_L1 승인, 시간 초과 시 중단·알림. 암호 서명 티켓, 승인 전 계정 상태가 바뀌면 무효
동시성	잘못된 사유 코드(GOODWILL_GESTURE) 거절, ERP 동기화 중 RESOURCE_LOCKED 반환, 격리·동기화 규칙은 미들웨어에
비유	관제탑. 오토파일럿·기장과 달리 공역 전체를 봄

핵심 개념

Spec-Driven Development(SDD)

spec을 실행 가능한 진실 원천 계약으로 두고 개발하는 방식. 원문은 Evaluation-Driven Development(EDD)와 함께 언급한다.

Interface Impedance Mismatch

API 스키마는 무엇을 호출할 수 있는지만 말하고 지금 호출해도 되는지는 말하지 못하는 어긋남.

SELECT FOR UPDATE

읽은 행에 잠금을 걸어 트랜잭션이 끝날 때까지 다른 쓰기를 막는 SQL 구문.

context bleed

한 세션의 맥락이 다른 세션으로 새어 들어가 엉뚱한 판단을 낳는 현상.

fraud hold

결제·청구 시스템이 이상 거래를 의심해 계정이나 거래를 묶어 두는 보류.

chargeback

카드 소지자가 결제에 이의를 제기해 카드사가 대금을 되돌리는 절차.

낙관적 잠금

미리 잠그지 않고 쓰기 직전에 레코드 버전이 그대로인지 확인해 충돌을 잡는 방식.

내 메모

TODO: 내 생각 추가

원문: Suhas Dhekane, “Architecting the Context Layer for Autonomous Agents”(The Autonomous Enterprise, 2026.09.23). 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 글에서 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON·YAML 예시, 반환 코드 이름(RESOURCE_LOCKED 제외), SAP·사내 ERP 점검 목록, 도구 설계 표, 승인 상태 기계, 일정과 판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. SAP의 SM12·SM37은 SAP 표준 트랜잭션입니다. 원문 전체는 The Autonomous Enterprise에서 볼 수 있습니다.