Whitepaper,미분류

Anthropic 은 2025-10-16 Agent Skills 사양을 공개하였고 (백서 §1.2.1), 2025-12-18 agentskills.io 에서 오픈 표준으로 발표하였습니다 [S9]. AGENTS.md 는 같은 2025-12 시점에 Linux Foundation 산하 Agentic AI Foundation (AAIF) 으로 거버넌스가 이관되었습니다 [S8]. 2026-06-07 기준 23 개 이상 도구가 동일 파일을 그대로 인식하며, GitHub 검색 기준 60,000 개 이상 오픈소스 프로젝트가 이 파일을 두고 있습니다 [S8][S12]. 사내 문서 표준 결정은 도구 선택이 아니라 인프라 결정 문제입니다.

CommonMark v0.31.2 (2024-01-28 게시, CC BY-SA 4.0) 가 사양 기준선입니다 (백서 §2.1.1). LlamaIndex Jerry Liu 는 2026-01-15 글 “Files Are All You Need” 에서 에이전트 설계가 파일시스템 + 5~10 개 핵심 도구로 회귀한다고 정리하였습니다 [S2]. LangChain Nick Huang 은 2025-11-21 글에서 파일시스템을 “에이전트가 무한한 컨텍스트를 유연하게 저장·검색·갱신할 수 있는 단일 인터페이스” 로 정의하였습니다 [S3]. 두 자료의 공통 메시지는 파일 포맷 자체가 도구 사이의 공통 인터페이스 역할을 한다는 점입니다 [S1]. 사내 문서 자산이 어떤 포맷에 있느냐가 곧 사내 에이전트 운영 효율을 결정합니다.

CNCF 는 2026-06-02 공식 블로그에서 “Cloud Native is now AI-Native” 명제를 제시하며 그 토대를 “open, interoperable, and vendor-neutral cloud native standards” 로 정리하였습니다 [S7]. CNCF 가 제시한 세 가지 평가 — Platform Maturity, Security by Design, Active Community Contribution — 은 인프라 평가표로 사용 가능하며, 동일 평가표가 문서 표준 선택에도 그대로 적용됩니다 (백서 §4.1.1). 인프라 계층에서 Kubernetes · OpenTelemetry · Backstage · Prometheus 같은 graduated 프로젝트를 vendor-neutral 기준으로 채택한 조직이 문서 계층에서 특정 SaaS 독점 포맷에 의존하면 정책 일관성이 훼손됩니다.

☁️ Cloud Native 사례
Argo CD GitOps 워크플로우와 OpenTelemetry 사양 관리가 모두 마크다운 파일 위에서 운영됩니다. Git 저장소의 desired state 가 마크다운 · YAML 평문으로 두어지고, 실제 운영 상태와의 차이가 자동 수렴됩니다 (백서 §4.2).

Backstage TechDocs 는 CNCF incubating 단계의 개발자 포털 컴포넌트이며 마크다운을 1차 입력으로 사용합니다 (백서 §4.2.1). 저장소 안의 마크다운 본문과 mkdocs.yml 구성 파일을 입력으로 받아 사내 기술 문서 사이트를 빌드합니다. MkDocs 는 같은 입력 사양을 따르는 오픈소스 도구이며 다수의 사내 문서 사이트가 이를 채택하였습니다. 두 도구의 공통점은 입력이 CommonMark 평문이라는 점입니다. 입력 사양이 공개 표준이므로 다른 마크다운 처리기로 교체하여도 본문 자산이 유지됩니다 [S5].

Docs-as-Code 패턴은 문서를 코드와 동일한 저장소 · 변경 추적 · 검증 단계로 운영합니다 [S7]. CI 파이프라인의 lint · 테스트 단계에 마크다운 문서 검증을 통합하면 헤더 라벨 일관성, 인용 형식, 표 형식, 링크 유효성을 자동으로 점검할 수 있습니다 (백서 §4.2.2). 8 종 코딩 에이전트 (Codex · Copilot · Cursor · Claude Code · Gemini CLI · Jules · Aider · Devin) 의 호환 매트릭스에서 AGENTS.md 는 7 개 도구에서 공식 지원되며, 마크다운 RAG 색인 경로는 8 개 도구 모두에서 지원됩니다 [S8][S12].

사내 문서 표준 정책 수립 시 세 가지 기준으로 평가할 것을 권장합니다. 첫째, 자산 재활용 — 한 번 작성한 정의 파일이 도구 전환 시 재가공 없이 그대로 인식되는가입니다 (백서 §5.1.1). 둘째, 표준 인터페이스 — 사양의 공개성과 거버넌스의 중립성이 동시에 충족되는가입니다 (백서 §5.1.2). 셋째, AI 효율 — 호출당 입력 토큰 소비가 누적적으로 절감되는가입니다 (백서 §5.1.3). 인프라 계층의 vendor-neutral 선택과 문서 계층의 일관성이 분리될 합리적 근거는 더 이상 존재하지 않습니다 [S7].

🎯 결정 포인트
1. 자산 재활용 — 23 개 이상의 도구가 동일한 AGENTS.md 파일을 그대로 인식합니다 (백서 §5.1.1, [S8]).
2. 표준 인터페이스 — CommonMark v0.31.2 와 YAML frontmatter 의 분리 설계가 vendor 중립성을 보장합니다 (백서 §5.1.2, [S5]).
3. AI 효율 — 마크다운은 영문 합성 데이터 1,000 문항 벤치마크에서 JSON 대비 34~38%, YAML 대비 10~12% 적은 토큰을 사용하였고 XML 은 마크다운 대비 80% 더 많은 토큰을 사용하였습니다 [S10] (백서 §5.1.3).

Q1. AI 에이전트 시대에 왜 마크다운이 표준입니까?

LLM 의 컨텍스트 윈도우는 한 번의 추론이 끝나면 휘발됩니다. 영속성은 외부 매체가 담당해야 하며, 파일시스템이 사람의 직접 편집과 에이전트의 grep · read 동작을 동시에 수용하는 매체입니다 [S3]. 그 파일이 마크다운일 때 사람과 에이전트 양쪽의 가독성이 동시에 충족됩니다 (백서 §2.1).

Q2. CNCF 와 마크다운은 어떻게 정합됩니까?

CNCF 는 2026-06-02 공식 블로그에서 “open, interoperable, and vendor-neutral cloud native standards” 원칙을 제시하며, community-driven controls 의 일환으로 “open standards like llms.txt and standardized schema markups” 의 채택을 권고하였습니다 [S7]. llms.txt 는 마크다운 형식의 공개 사양이며, CommonMark 와 함께 사내 문서 계층에 적용됩니다 (백서 §4.1.2).

Q3. 도입 ROI 는 얼마나 됩니까?

영문 합성 데이터 1,000 문항 벤치마크에서 마크다운은 GPT-5 Nano 기준 JSON 대비 34% 적은 토큰, Gemini 2.5 Flash Lite 기준 JSON 대비 38% 적은 토큰을 사용하였습니다 [S10] (백서 §3.1.1). 이 절감은 호출당 누적되므로 사내 LLM 활용도가 높을수록 회수 시점이 빨라집니다. 한국어 환경의 재현은 사내 표본 측정으로 별도 검증할 것을 권장합니다 (백서 §3.1.3).

Q4. 무엇부터 시작해야 합니까?

CommonMark v0.31.2 사양 채택과 YAML frontmatter 키 표준화부터 시작하는 것을 권장합니다 (백서 §2.1). 사내 저장소 한 곳을 Docs-as-Code 패턴으로 운영하며 CI 단계에 문서 lint 를 통합하면 운영 효율의 누적 효과를 1 분기 안에 측정할 수 있습니다 (백서 §4.2.2).

사내 문서 표준 결정은 인프라 거버넌스 결정의 연장선입니다. CommonMark v0.31.2 사양의 안정성, AGENTS.md 의 23 개 이상 도구 호환과 AAIF 거버넌스 중립성, 그리고 영문 한정 벤치마크의 34~38% 토큰 절감이 자산 재활용 · 표준 인터페이스 · AI 효율 세 가지 기준에서 동시에 성립합니다 [S5][S7][S8][S10]. 인프라 계층에서 vendor-neutral 선택을 채택한 조직이 문서 계층까지 동일한 원칙을 일관되게 적용할 때, CNCF 가 정의한 AI-Native 전환의 토대가 비로소 확보됩니다.

CNCF Landscape 의 graduated 프로젝트 다수가 이미 마크다운을 1차 입력으로 사용하고 있으며, Backstage TechDocs · MkDocs · Argo CD 워크플로우 운영이 그 대표 사례입니다 (백서 §4.2.1). 사내 도입 결정은 두 단계로 분리하는 것을 권장합니다. 1 단계는 CommonMark v0.31.2 사양 채택과 frontmatter 키 표준화이며, 2 단계는 Docs-as-Code 패턴으로 CI 단계에 문서 lint 를 통합하는 작업입니다 (백서 §2.1, §4.2.2). 두 단계 모두 도구 종속 없이 진행 가능하며, 첫 분기에 호출당 입력 토큰 변화를 측정해 사내 LLM 비용 모델에 반영하면 됩니다 (백서 §3.1.3).