1인 개발자 규모에서의 휴대 가능한 에이전트 거버넌스: 4개 도메인 사례 연구

요약 (Summary)

이것은 4개의 독립적인 실제 운영 프로젝트(암호화폐 트레이딩 시스템, 이커머스 웹 앱, AI 의사결정 시스템, 에이전트 인프라 계층) 전반에 걸쳐 수동으로 유지 관리되는 파일 기반 실행 프로토콜에 관한 것입니다. 이를 구축한 사람은 단 한 줄의 코드도 작성하지 않습니다. 그들은 아키텍처를 설계하고, 규칙 계층 구조를 설정하며, 규율을 강제합니다. 코드는 AI가 작성하고 기술적으로 실행합니다. 이러한 분리는 여기에서 주의 사항으로 제시되는 것이 아니라, 시스템의 실제 본질입니다. 즉, 코드 프로젝트가 아니라 **의사결정 및 감독 프로토콜 (decision-making and oversight protocol)**입니다. 그 품질은 설계자가 코드를 작성하는지 여부와 독립적으로 판단될 수 있습니다.

엔터프라이즈 AI 에이전트 거버넌스 (MI9, Microsoft Agent 365, JFrog AI Catalog)는 규모와 자동화에 최적화된 시스템, 즉 중앙 집중식 텔레메트리 (telemetry), 코드로서의 정책 (policy-as-code), 런타임 강제 (runtime enforcement)를 제공합니다. 하지만 그들의 문헌조차도 두 가지 사실을 인정합니다: (1) 프레임워크에 따라 커버리지가 다르며, (2) 설정 및 유지 관리 비용이 1인 또는 소규모 사용에는 불균형적으로 높다는 점입니다.

여기에서 설명하는 프로토콜 제품군 (CORE.md / AGENT.md / SESSION_INDEX.md 및 그 파생물들)은 다른 가정을 바탕으로 작동합니다: 정적인 템플릿이 아니라 시간이 지남에 따라 스스로를 수정하는 시스템입니다. 한 프로젝트에서의 구체적인 실패 사례는 날짜와 정당한 근거가 포함된 규칙으로 파일에 기록되며, 해당 규칙은 다른 도메인의 완전히 다른 프로젝트로 상속됩니다.

1. 엔터프라이즈 거버넌스가 스스로 인정하는 한계

에이전트형 AI 거버넌스에 대한 기업의 투자는 빠르게 성장하고 있습니다. IDC에 따르면, 조직들은 현재 전체 계획된 AI 지출의 평균 16.7%를 AI/에이전트 보안 및 거버넌스에 할당하고 있습니다. 그러나 동일한 출처는 구현이 의도에 훨씬 뒤처져 있음을 보여줍니다:

• 76%가 최고 AI 책임자 (Chief AI Officer)를 보유하고 있음에도 불구하고, 적절한 AI 거버넌스 (AI governance)를 갖추고 있다고 믿는 비율은 13%에 불과합니다.
• 235명의 대기업 보안 리더를 대상으로 조사한 결과, 92%가 자신의 AI 아이덴티티 (AI identities)에 대한 완전한 가시성 (visibility)이 부족하다고 답했으며, 82%는 네트워크상에서 존재를 알지 못했던 AI 에이전트 (AI agents)를 발견했습니다.
• 에이전트형 AI (agentic AI) 프로젝트의 40% 이상이 부적절한 통제 (controls)로 인해 2027년까지 취소될 것으로 예상됩니다.

MI9와 같은 학술적/기업용 런타임 거버넌스 프레임워크 (runtime governance frameworks)들도 암묵적으로 동일한 문제를 인정하고 있습니다. MI9의 자체 논문에는 다음과 같이 명시되어 있습니다: "커버리지 (Coverage)는 각 프레임워크의 계측 (instrumentation) 능력에 따라 달라집니다. 콜백 (callback)이 활성화된 프레임워크는 포괄적인 행동 모니터링 (behavioral monitoring)을 지원하는 반면, API 래퍼 (API-wrapper) 아키텍처는 주로 액션 이벤트 (action events)만을 노출합니다." 즉, 설계 목표는 프레임워크에 구애받지 않지만(framework-agnostic), 실제 환경에서의 커버리지는 그렇지 않다는 의미입니다.

결론적으로, 대규모 환경에서는 기업형 거버넌스가 필수적이지만, 소규모에서 중규모 규모에서는 거버넌스가 무겁고 불완전합니다.

2. 대안 모델: 단일 의사결정자 하의 살아있는 프로토콜

네 개의 독립적인 프로젝트가 동일한 세 개의 파일 골격을 공유하고 있습니다:

• CORE.md — 고정된 원칙, 필수 시작 시퀀스 (startup sequence), 규칙 우선순위 계층 (보안 (Security) > 무결성 (Integrity) > 품질 (Quality) > 효율성 (Efficiency))
• AGENT.md — 실행 동작 (execution behavior), 필수 의사결정 문구 (decision statements), 자기 모니터링/편차 탐지 (self-monitoring/deviation-detection) 테이블
• SESSION_INDEX.md — 누적 세션 메모리 (cumulative session memory), 시간이 지남에 따라 버전 관리 및 압축되며 원본 아카이브는 보존됨

이 세 개의 파일 형식 자체가 새로운 것은 아닙니다. AGENTS.md 패턴은 이제 GitHub 전반에서 흔히 볼 수 있는 업계 표준입니다. 차이점은 이 파일들이 진화하는 방식에 있습니다.

증거: 실패 → 규칙 → 도메인 간 상속

한 프로젝트(이커머스 웹 앱)에서 2026-07-20에 구체적인 사고가 발생했습니다: 세션 로그 압축 과정에서 7개의 오픈 이슈 (open issues)와 2개의 의사결정 사항이 조용히 누락되었습니다. 이 내용은 CORE.md에 직접 기록되었습니다:

"v1.2 — §7.1 1단계에 '400행 임계값 (400-line threshold)' 규칙 추가... 근거: 2026-07-20에 항목이 정당한 이유 없이 누락됨 (오픈 이슈 7개 + 의사결정 사항 2개)""

동일한 규칙이 네 번째 프로젝트의 CORE.md에서도 나타납니다. 이는 완전히 다른 도메인(AI 의사결정 시스템 / n8n 오케스트레이션 레이어 (orchestration layer))입니다:

"[이전 프로젝트]의 2026-07-20 위반 사항... 이 프로젝트는 해당 실패를 상속받지 않음."

이는 단일 저장소(repo)나 프레임워크 내에 머무르는 '자기 수정 메모리 (self-correcting memory)' 사례(예: GitHub의 pro-workflow 또는 AGENTS.md의 '로컬 규범 (local norms)' 패턴)와 구조적으로 다릅니다. 여기서의 학습은 프로젝트와 도메인의 경계를 넘나듭니다.

규모에 맞춘 가지치기 (Pruned to scale)

이 형식은 맹목적인 템플릿이 아닙니다. 동일한 골격이 대규모 고위험 프로젝트(트레이딩 시스템)에서는 약 480행의 CORE.md를 생성하지만, 소규모 프로젝트(AI 의사결정 시스템)에서는 의도적으로 97행으로 축소됩니다. 불필요한 무게(8단계 보안 자가 점검, 코드 품질 점수 시스템 등)는 그대로 가져오지 않습니다. 이는 JFrog가 기업 문헌에서 주장한 '비례적 거버넌스 (proportional governance)' 원칙을 반영합니다: "저위험, 생산성 중심의 에이전트에게 고위험 시스템을 위해 설계된 컴플라이언스 체크리스트를 강요하는 것은 운영 마비 (operational paralysis)를 초래한다." 차이점이라면, JFrog는 이를 플랫폼 제품으로 판매하지만, 여기서는 추가적인 인프라 비용 없이 인간의 판단을 통해 적용된다는 점입니다.

3. 프로젝트 세부 사항을 노출하지 않고도 시스템이 "살아있음"을 보여주는 구조적 증거

위의 세 가지 파일 골격(CORE/AGENT/SESSION_INDEX)은 사실 훨씬 더 큰 파일 제품군(file family)의 가시적인 척추에 불과합니다. 한 프로젝트에서 이 제품군은 20개 이상의 파일(ARCHITECTURE, ROADMAP, ROLLBACK, PHASE_TRACKER, FAILURE_PATTERNS, TEST_MATRIX, CONFIG_SCHEMA, DEPENDENCIES, 그리고 여러 버전의 SESSION_INDEX 하위 파일들)로 확장됩니다. 프로젝트별 콘텐츠를 노출하지 않고도, 이 제품군이 정적인 템플릿이 아닌 살아있는 시스템임을 보여주는 네 가지 메커니즘 유형은 다음과 같습니다:

1. 자기 불일치 탐지 및 플래깅 (Self-inconsistency detection and flagging). 시스템은 자신의 파일 중 하나가 오래되었음을 감지하면, 드리프트(drift)가 발견된 세션 번호를 해당 파일에 표시하고 어떤 소스를 최신으로 취급해야 하는지 명시합니다. 정적인 문서 파일은 스스로의 무효성을 선언하지 못합니다.

2. 밀집된 상호 참조 (Dense cross-referencing). 파일들은 고립되어 있지 않습니다. 각 파일은 섹션 번호 단위까지 서로를 참조하며 단일한 지식 그래프 (knowledge graph)를 형성합니다. 이는 고립된 단일 파일 형태인 AGENTS.md 패턴과는 구조적으로 다릅니다.

3. 경험에 의해 보정된 규칙 (Experience-calibrated rules). 실패 패턴 로그 (failure-pattern log)에는 가공되지 않은 이론적인 규칙이 들어있지 않습니다. 대신 실제 사건(오탐, 실제 장애)에서 추출된 임계값과 구분이 포함되어 있습니다. "언제 이것이 실제 문제이고 언제 노이즈인가"와 같은 구분은 축적된 경험 없이는 이토록 정밀하게 작성될 수 없습니다.

4. 유기적인 파일 분할 (Organic file splitting). 메모리 파일들은 사전에 계획되지 않은 성장 패턴을 보여줍니다. 즉, 미리 정해진 구조에 따르는 것이 아니라 시간이 흐르며 필요에 따라 하위 버전으로 분할됩니다.

이 네 가지 메커니즘은 종합적으로 이 프로토콜이 단순히 "인간이 쓰고 AI가 읽는" 모델 그 이상임을 보여줍니다. 파일이 AI의 출력을 형성하고, AI의 출력(실패 로그, 불일치 플래그)이 다시 파일을 형성하는 상호적이고 누적적인 루프 (reciprocal, cumulative loop)입니다. 이 루프는 설계자가 코드를 한 줄씩 읽고 검증할 수 없기 때문에 특히 중요합니다. 따라서 시스템의 신뢰성은 이러한 자기 일관성 메커니즘(2번 항목의 상호 참조, 1번 항목의 자기 불일치 탐지)이 얼마나 견고한지에 크게 의존합니다. 코드는 인간에 의해 한 줄씩 검토되지 않지만, 프로토콜 수준에서 다층적인 교차 검증이 이루어집니다.

4. 엔드 투 엔드 에이전트 구조의 일관성: 동일한 프로토콜, 다른 에이전트 아키텍처

지금까지 설명한 CORE/AGENT/SESSION_INDEX 패밀리는 네 가지 프로젝트 모두에 걸쳐 공유되는 공통 "골격 레이어 (skeleton layer)"입니다. 하지만 이 골격이 모든 곳에 동일한 종류의 에이전트 구조를 강제하는 것은 아닙니다. 각 프로젝트는 실제 리스크 표면 (risk surface)에 따라 해당 골격 내부에서 자신만의 에이전트 아키텍처 (agent architecture)를 정의합니다. 이는 일관성이 유지되는 지점과 의도적으로 유지되지 않는 지점을 보여준다는 점에서 중요합니다.

고정되는 요소 (프로토콜 레이어): 시작 시퀀스 (startup sequence), 필수 결정 문구 (mandatory decision statements), 자기 모니터링/편차 테이블 (self-monitoring/deviation table), 규칙 우선순위 계층 (rule-priority hierarchy), 세션 메모리의 버전 관리 로직 — 이들은 네 가지 프로젝트 모두에서 구조적으로 동일합니다.

프로젝트별로 달라지는 요소 (실행/에이전트 레이어):

• PUSULA는 가장 명시적인 멀티 에이전트 (multi-agent) 아키텍처를 가지고 있습니다: 실행자 (Executor)와 비판자 (Critic) 역할이 의도적으로 분리되어 있으며, 이들은 "절대 동일한 모델 패밀리에서 나와서는 안 된다"는 규칙에 의해 결합됩니다. 즉, 제안하는 에이전트와 검토하는 에이전트가 구조적으로 독립되어 있음을 의미합니다. 이에 더해, 결정 사항이 결정론적 코드 (deterministic code)에 의해서만 실행될 수 있는 별도의 정책 엔진 (Policy Engine) 레이어가 존재하며, 이곳에는 어떠한 AI 호출도 허용되지 않습니다. 프롬프트 인젝션 (prompt injection)에 대응하기 위해, 이들은 이중 LLM / 격리 (dual-LLM / quarantine) 패턴을 사용합니다: 외부에서 유입된 텍스트는 시스템 지침 (system instructions)과 분리된 컨텍스트에서 처리됩니다.

• NEXUS는 단일 에이전트 (single-agent)이지만 계층화된 검증 체인에 의존합니다: 신호 생성 (signal generation), 백테스팅 (backtesting, CPCV/DSR 검증), 그리고 섀도우/페이퍼 모드 (shadow/paper-mode) 관찰 레이어는 서로를 무시할 수 없는 별개의 단계들입니다. "에이전트"는 하나이지만, 결정 프로세스는 다단계로 이루어져 있으며 각 단계는 이전 단계를 검증(challenge)할 수 있습니다.

• Bowlera는 고객 접점의 단일 실행 에이전트를 중심으로 구축되었습니다. 여기서의 차이점은 에이전트의 수가 아니라 규칙의 유형에 있습니다. 디자인/브랜드 무결성 규칙 (motion preferences, 절대 숨길 수 없는 칼로리 정보 등)이 기술적/보안적 규칙보다 더 지배적입니다.

• Sovereign Engine OS는 인프라 계층(infrastructure layer)으로서, 에이전트 아키텍처를 "권한 라우팅 (authorization routing)" 중심으로 구성합니다. 즉, githubTokenRouter.ts와 같은 컴포넌트들이 코드 수준에서 에이전트가 어떤 권한 하에 어떤 작업을 수행할 수 있는지 제한합니다.

이러한 구조를 통해 확인할 수 있는 진정한 가치는 다음과 같습니다. 프로토콜 계층(의사결정이 내려지는 방식, 실패가 기록되는 방식, 작업이 인계되는 방식)은 네 가지 프로젝트 모두에 직접적으로 이식(portable) 가능한 반면, 에이전트 아키텍처(에이전트의 수, 역할, 분리 원칙 등)는 프로젝트의 실제 리스크 표면(risk surface)에 따라 매번 재설계된다는 점입니다. 여기서 계승되는 것은 템플릿이 아니라, 바로 **의사결정 규율 (decision-making discipline)**입니다. 에이전트의 수와 역할은 이 규율의 입력값이 아니라, 그 규율로부터 도출되는 결과물입니다.

5. GitHub에서 발견된 가장 유사한 사례들 — 그리고 구조적으로 더 좁은 이유

공정한 검색을 통해 발견된 가장 유사한 비교 사례는 다음과 같습니다:

이 표에 추가되는 모든 새로운 사례에 대한 비교 기준은 동일하게 유지됩니다: 학습 내용이 단일 프로젝트/레포지토리/프레임워크의 경계를 넘어 다른 문제 도메인으로 넘어가며, 날짜와 근거(rationale)가 포함된 파일에 기록되는가? 지금까지 발견된 사례 중 어느 것도 이를 수행하지 않습니다.

6. 한계 — 명확하게 기술함

• 이것은 통제된 실험이 아닌 사례 연구 (case study)입니다. 이와 유사한 것을 구축한 개발자가 얼마나 되는지는 측정되지 않았습니다. 따라서 "이것은 증명되었다"가 아니라 "공개된 사례를 찾지 못했다"라는 수준으로 주장해야 합니다.
• 강제성 (Enforcement)은 기술적인 것이 아니라 행동적인 것입니다. 이미 하드코딩되어 있는 임계/고위험 지점(예: 킬 스위치 (kill-switch))을 제외하고는 코드 레벨에서의 물리적인 차단은 존재하지 않습니다.
• 이 시스템은 한 개인의 규율 (discipline)에 의존합니다. 만약 이를 중심으로 팀이 성장하거나 인수인계가 필요해진다면, 엔터프라이즈 모델이 제공하는 것과 같은 자동화/강제화된 계층 (layer)이 필요할 가능성이 높습니다.
• 코드의 기술적 정확성 (technical correctness)은 설계자가 한 줄씩 읽으며 검증하는 것이 아닙니다. 검증은 AI 자체의 테스트, 셀프 오딧 (self-audit) 출력물, 그리고 (임계 지점에서의) 실행 중인 프로덕션 시스템의 관찰된 동작에 의존합니다. 이 프로토콜은 "의사결정 및 규율 계층 (decision and discipline layer)"에서는 인간이 설계하고 감독하지만, "라인 레벨 코드 정확성 (line-level code correctness)" 계층에서는 AI에 의존합니다. 이는 이 시스템이 실제로 무엇인지 이해하는 데 있어 중요한 차이점입니다. 즉, 이 시스템은 코드 리뷰 규율 (code-review discipline)이 아니라 의사결정 규율 (decision-making discipline)입니다.

결론