원문 정보

Oliver Aleksander Larsen, Mahyar T. Moghaddam, "The Agentic Company OS: Substrate Inversion for Sustained Enterprise Agent Deployment", arXiv:2609.13334 [cs.SE], 2026-09-11 제출, DOI 10.48550/arXiv.2609.13334. 소속: 남덴마크대학교(University of Southern Denmark) 소프트웨어공학과.

동료심사를 거치지 않은 프리프린트이자, 저자들이 스스로 "포지션 페이퍼"라고 규정한 글입니다 — 새 실험 결과가 아니라 아키텍처 주장을 제시하고 그 주장을 검증할 벤치마크 설계를 제안하는 형식입니다. 자금 출처·이해상충 공개 섹션은 원문에 없습니다(References 앞뒤로 Acknowledgments·Funding·Conflict 키워드를 확인했으나 미검출 — arXiv 사이트 자체의 후원 안내 문구만 있고 논문 본문의 공개는 없습니다). 원문 전문은 2026-09-15T23:32:58Z 기준 GitHub Actions 스냅숏(arXiv HTML 전문 사본)으로 대조했습니다 — 이번 실행의 세션 egress가 대조군 example.com까지 10분 간격 3회 모두 차단됐고, 스냅숏 수집 워크플로 수동 재발화 2회도 모두 arXiv API HTTP 406으로 실패해, 확보 가능한 가장 최근 스냅숏(수집일 기준 3일 전)을 썼습니다.

연구 개요

연구 질문은 "왜 기업 AI 에이전트는 데모에서는 성공하고 실제 운영에서는 멈추는가"입니다. 저자들은 이를 다섯 가지 실패 유형(거버넌스 공백·투명성 공백·조정 공백·안전 공백·개선 정체)으로 분해하고, 그 공통 원인을 "에이전트가 사람과 기존 애플리케이션을 위해 설계된 스키마 위에서 추론하기 때문"이라고 진단합니다. 처방은 "서브스트레이트 역전(substrate inversion)" — CRM·원장·이메일 같은 기존 시스템의 스키마를 그대로 물려받는 대신, 에이전트가 읽는 작업 컨텍스트(서브스트레이트) 자체를 LLM의 추론 방식에 맞춰 다시 짓자는 주장입니다. 오늘 시점의 구현체는 마크다운이라고 못박되, 마크다운이 검증된 최적 표현이라고는 주장하지 않습니다.

주장의 근거는 두 메커니즘입니다. 첫째는 "컨텍스트 대역폭 비대칭" — 연결된 산문은 한 번에 읽지만 타이핑된 API·스키마는 필드 단위로 관계를 잘라내 매 호출마다 에이전트가 관계를 재조립해야 한다는 것이고, 이 재조립 비용이 과제가 깊어질수록 커진다는 가설(H1)입니다. 둘째는 "교차 루프 결합" — 초 단위의 행동 루프, 일 단위의 스킬 루프, 주~월 단위의 정책 루프가 하나의 서브스트레이트를 공유해야만 개선이 누적되고, 나뉘어 있으면 잡음 수준으로 수렴한다는 가설(H2)입니다. 두 가설 모두 저자들이 직접 제안하되 아직 실행하지 않은 벤치마크(7절)로만 검증 가능합니다.

핵심 주장과 설계

이 논문에는 실증 벤치마크 표가 없습니다 — 문헌 성격이 실험 논문이 아니라 포지션 페이퍼이기 때문에, 이 리뷰는 §01 문서의 "핵심 결과" 대신 저자들이 원문에서 직접 제시한 아키텍처 표와 설계 결정을 그대로 옮깁니다.

	RAG 에이전트	타입 도구 에이전트	버티컬 앱	서브스트레이트 역전
추론 표면	검색된 조각	타입 결과	버티컬 스키마	컴파일된 코퍼스
스키마 변환 위치	검색 파이프라인	매 호출	앱 어댑터	액션 경계 1곳
감사 흔적 위치	소스 로그	API 로그	벤더 로그	버전 관리
거버넌스 위치	외부 엔진	외부 엔진	벤더 통제	서브스트레이트 자체

네 층 구조(Data·Knowledge·Intelligence·Governance) 중 Data 층은 CRM·원장 등 기존 시스템을 그대로 두고, Knowledge 층은 사람과 에이전트가 함께 읽는 마크다운 위키(하나의 Git 저장소)입니다. 외부 시스템 호출 권한은 Sync Agent 하나에만 집중되고(액션 경계), 신뢰 등급은 에이전트가 아니라 스킬 단위로 매겨집니다 — shadow(초안만 작성)→assist(매 실행 사람 승인)→autonomous-sampled(표본 감사)→full(사후 감사) 4단계이며, 등급을 올리는 권한은 사람에게만 있고 내리는 권한은 결정론적 컨트롤러에도 있습니다. 세 개선 루프(행동·스킬·정책)는 이 표에서 보듯 하나의 서브스트레이트를 공유해야만 교차 결합이 일어난다는 것이 논문의 핵심 설계 논리입니다.

루프	시간 단위	닫히는 방식
행동(Action)	초	결과를 로그 파일에 추가
스킬(Skill)	일	플레이북 개정(신뢰 필드는 예외)
정책(Policy)	주~월	사람 또는 거버넌스 검토로 정책 파일 갱신

신뢰도 평가

이 리뷰에서 가장 먼저 밝혀야 할 것은 이 논문이 스스로 밝힌 한계입니다 — 8절 "다섯 가지 열린 질문" 중 다섯 번째가 "실증 검증: 이 포지션은 아직 5절의 대안들과 벤치마크되지 않았다"입니다. H1·H2는 저자 스스로 제안한 실험(7절)으로만 참·거짓이 갈리는 가설이며, 그 실험은 아직 수행되지 않았습니다. 동료심사도 거치지 않았습니다. 이해상충은 원문에서 확인되지 않았습니다(위 원문 정보 참고) — 확인되지 않았다는 것이 곧 없다는 뜻은 아니라는 점을 밝혀 둡니다.

반대로 신뢰를 더하는 지점도 있습니다. 저자들은 5절 전체를 "가장 강한 반론 세 가지(검색 고도화로 충분하다, 타입 도구로 충분하다, 버티컬 앱으로 충분하다)"에 할애하고 각각에서 "낮은 합성 깊이에서는 경쟁력이 있다는 점을 인정한다"고 스스로 양보합니다. 자기 주장의 반증 조건(H1·H2가 거짓이 되는 구체적 관측)을 명시한 것도 전형적 마케팅성 발표문과는 다른 지점입니다. 상반 증거로는 원문이 인용한 GAIA·AgentBench의 "과제 깊이가 늘수록 성능이 떨어진다"는 관측이 있는데, 이는 이 논문의 가설(H1)과 방향이 일치하는 정황일 뿐 서브스트레이트 구조 자체를 분리해 검증한 결과는 아니라고 원문 스스로 명시합니다(2절).

리뷰어 판단

첫째, 이 논문에서 가장 실무적으로 값진 대목은 "서브스트레이트 역전"이라는 큰 주장이 아니라 6.1절의 위험 분석이라고 판단합니다. 컴파일 경로가 신뢰되지 않는 외부 콘텐츠를 신뢰된 에이전트 컨텍스트로 바꾸는 지점이라는 지적, 그리고 "한 번 오염된 파일이 그것을 읽는 모든 에이전트에 영구적으로 재노출된다"는 지속적 서브스트레이트 오염 위험은 저자들 스스로 "신뢰 등급은 스킬을 게이팅할 뿐 페이로드는 게이팅하지 않는다"고 인정한 미해결 구멍입니다. 아키텍처를 채택하지 않더라도, "공유 컨텍스트에 쓰기 권한을 가진 컴포넌트가 동시에 모든 외부 자격증명을 쥔다"는 이 위험 패턴 자체는 마크다운이 아닌 다른 공유 컨텍스트 설계에도 그대로 적용된다고 봅니다.

둘째, 저자들이 H1·H2를 반증 가능한 형태로 명시하고 그 실험 설계까지 7절에 구체적으로 적어 둔 점은 정직하지만, 동시에 이 논문이 "아직 증명되지 않은 주장"이라는 사실을 가리지 않는다고 판단합니다. 트러스트 그레이디언트·4층 구조 같은 설계 요소들은 각각 타당해 보이지만, 그것들이 결합했을 때 타입 도구 에이전트나 RAG 대비 실제로 더 나은 결과를 낸다는 근거는 이 논문 안에 없습니다. "논리적으로 그럴듯하다"와 "측정으로 확인됐다"를 구분해서 읽어야 합니다.

실무 적용

회사 전체가 아니라 부서 하나로 시작 — 저자들이 제안한 도입 경로 그대로, 해석 비중이 높고 담당자가 명확한 워크플로(영업 자격 심사, 지원 트리아지 등) 하나만 먼저 마크다운 컨텍스트로 옮겨 봅니다.
신뢰 등급은 에이전트가 아니라 스킬 단위로 설계 — 같은 에이전트라도 스킬마다 다른 자동화 수준(초안만/사람 승인/표본 감사/완전 자동)을 두면, 위험이 큰 동작만 사람이 계속 볼 수 있습니다.
공유 컨텍스트 쓰기 권한을 단일 지점으로 좁히기 — 이 논문의 Sync Agent처럼 외부 시스템 호출·쓰기 권한을 한 컴포넌트에 몰아 감사·격리 지점을 하나로 만듭니다. 단, 그 지점이 곧 최대 공격 표면이 된다는 점(6.1절)을 함께 설계에 반영합니다.
도입 전 자체 비교 실험을 먼저 설계 — 이 논문이 제안한 7절의 벤치마크 골격(대상 표현·루프 결합 여부를 각각 변수로 둔 비교)을 참고해, 채택 전에 최소한의 내부 A/B를 직접 돌려 봅니다.
지속적 컴파일·재독해 비용을 별도로 계측 — 저자들은 일 단위 컴파일 비용은 작지만 매 행동마다 전체 코퍼스를 다시 읽는 비용은 클 수 있다고 경고합니다. 캐싱·선택적 읽기 정책 없이 그대로 확장하면 지연·비용이 예상보다 커질 수 있습니다.

결론

Agentic Company OS의 기여는 검증된 성능 개선이 아니라, 기업 에이전트가 반복해서 멈추는 이유를 하나의 구조적 원인(스키마를 사람에게서 물려받는다)으로 정리하고 그 원인을 검증할 구체적 실험 설계까지 내놓은 데 있습니다. 신뢰 등급·행동 경계·세 루프 결합 같은 개별 설계는 타당해 보이지만, 저자들 스스로 인정하듯 아직 대안 대비 벤치마크된 적이 없는 가설입니다. 이 리뷰는 그 가설을 검증된 결과처럼 읽지 않도록 경계하면서, 위험 분석과 도입 경로만은 지금 당장 참고할 가치가 있다고 판단합니다. 스킬 단위로 실행 권한을 나누는 설계는 에이전트 하네스 권한·샌드박스 게이팅 설계에서 실무 체크리스트로 이어집니다.

참고 링크

이 리뷰에 대해 AI와 대화하기

AI가 이 리뷰와 검증된 수치를 읽은 상태로 답합니다. 무엇이든 물어보세요 — 글에 없는 내용이면 없다고 먼저 알려줍니다.

대화창을 불러오는 중…

기업 에이전트는 왜 파일럿에서 멈추는가: Agentic Company OS의 '서브스트레이트 역전' 리뷰