Markdown vs HTML — AI 주도 개발 5가지 배치 장소의 활용 구분

「AI에게 전달하는 문서는 Markdown이 유일한 선택지다」라는 논의가 확산되고 있습니다. AGENTS.md는 60,000개 이상의 OSS 프로젝트에 채택되었으며[1], Cursor도 Zed도 Claude Code도 Markdown을 채택했습니다. 하지만 현장에서 운용하다 보면 「테이블이 깨진다」, 「Markdown 프롬프트가 Markdown 출력을 유발한다」, 「RAG에서 정밀도가 떨어진다」와 같은 보고가 차례로 나오고 있습니다. 본 기사에서는 **배치 장소 × 태스크 (Task)**에 따라 형식을 구분하여 선택하기 위한, 5가지 배치 장소 × 4가지 판단 축의 매트릭스를 제시합니다.

「일단 Markdown」에서 멈춰버린 현장

「일단 CLAUDE.md는 Markdown으로 써 둬」, 「지식 베이스(Knowledge Base)는 HTML에서 Markdown으로 변환하자」. AI 주도 개발 현장에서 이런 구호가 울려 퍼지고 있습니다. 틀린 말은 아니지만, 판단 정지 상태에 빠져 있는 것은 아닐까요?

왜 「Markdown 유일론」이 확산되었는가

이유는 3가지가 있습니다.

AGENTS.md 규격의 급격한 확대: Linux Foundation 산하의 Agentic AI Foundation이 관리하는 AGENTS.md는 OpenAI Codex / GitHub Copilot / Google Jules / Gemini CLI / Claude Code / Cursor / Zed / JetBrains Junie / Aider / Factory / Devin / Warp / VS Code 등 20개 이상의 도구가 대응하고 있습니다[1:1]. 형식은 표준 Markdown입니다. -
CLAUDE.md / .cursorrules의 Markdown 채택: Anthropic도 Cursor도, 인간이 작성하는 지시 파일로서 Markdown을 선택했습니다. -
토큰 효율의 단순화: HTML은 태그로 인해 토큰이 불어나기 때문에 「Markdown이 더 가볍다」라는 직관이 퍼졌습니다. Cloudflare Markdown for Agents는 자사 블로그 1페이지 기준 HTML 16,180 tokens → Markdown 3,150 tokens (80% 절감)라는 실측치를 공개했습니다[4].

「Markdown 유일론」이 무너지는 3가지 장면

하지만 현장에서는 다음과 같은 상황에서 위화감이 나타나기 시작합니다.

rowspan/colspan을 포함하는 테이블이 깨짐: 사양서의 기능 목록표를 Markdown화했더니, 병합된 셀을 표현할 수 없어 별도의 표로 분할할 수밖에 없었다. -
Markdown 프롬프트가 Markdown 출력을 유발함: API를 통해 「Slack용 짧은 문장으로 답해줘」라고 요청해도, 왠지 모르게 불렛 포인트(Bullet point)와 헤더(Heading)가 섞여서 돌아온다. Anthropic 공식 측은 「프롬프트에서 Markdown을 제거하면 출력되는 Markdown의 양을 줄일 수 있다」라고 명시하고 있습니다[5]. -
RAG에서 검색 정밀도가 저하됨: 웹 페이지를 변환하여 인덱싱했더니, 테이블이 포함된 페이지의 히트(Hit)율이 떨어졌다.

이것들은 모두 「Markdown 유일론」이라는 판단 정지가 불러일으키는 전형적인 증상입니다. 다음 절부터는 배치 장소별로 최적의 형식을 나누어 생각하겠습니다.

5가지 배치 장소 × 4가지 판단 축의 전체 매트릭스

판단의 프레임워크를 먼저 제시합니다.

5가지 배치 장소의 정의

#	배치 장소	예시	주요 독자
1	CLAUDE.md / AGENTS.md (인간 → AI 지시 파일)	리포지토리 직하의 지시서	인간이 작성, AI가 읽음
2	시스템 프롬프트 (System Prompt)	API의 system 파라미터	개발자가 작성, AI가 읽음
3	사용자 프롬프트 (User Prompt)	채팅창, 태스크 지시	엔드 유저가 작성, AI가 읽음
4	RAG 컨텍스트 (Context)	검색 결과로 주입되는 문서	검색 계층이 선택, AI가 읽음
5	AI 출력 (Output)	API 응답, UI 표시	AI가 작성, 인간/프로그램이 읽음

4가지 판단 축

토큰 효율성 (Token Efficiency): 동일한 의미를 전달하는 데 몇 토큰이 필요한가 -
태스크 정확도 (Task Accuracy): 해당 태스크에서 accuracy / pass@1이 높은 형식은 무엇인가 -
구조 유지 (Structure Preservation): 중첩(Nest), 속성, 관계를 잃지 않고 표현할 수 있는가 -
유지보수성 (Maintainability): 인간이 편집하기 쉬운가, 도구 간 호환성이 있는가

전체 매트릭스

배치 장소	기본 형식	예외	주요 근거
CLAUDE.md / AGENTS.md	Markdown	없음	인간 가독성 + 도구 간 호환성 [1:2]
시스템 프롬프트 (Claude)	XML 태그	Markdown 출력을 의도적으로 유도하고 싶은 경우	Anthropic 공식 권장 [3:1]
사용자 프롬프트 (코드 생성)	Markdown	NER / 지식 추론 태스크	arXiv 2411.10541 [2:1]
RAG 컨텍스트	태스크에 따라 다름 (단문 → Markdown / 구조 중시 → HTML)	테이블 중심은 HTML	HtmlRAG WWW 2025 [6] / Cloudflare 80% 절감 [4:1]
AI 출력	배치 장소에 따라 다름 (Web → HTML / API → Markdown or JSON)	프로그램 연동은 구조화된 출력	Simon Willison (2026-05-08) [7]

이 매트릭스를 "일단 Markdown"이라는 생각보다 상위에 두는 것이 본 기사의 주장입니다. 다음 절부터는 배치 장소별로 상세히 살펴보겠습니다.

배치 장소별 처방전

CLAUDE.md / AGENTS.md (인간 → AI 지시 파일)

이 계층은 Markdown이 사실상의 유일한 해답입니다.

이는 형식 선택의 논쟁이 아니라 에코시스템(Ecosystem)의 선택입니다. AGENTS.md는 60,000개 이상의 OSS 프로젝트에서 채택되었으며, 20개 이상의 에이전트 도구가 표준으로 읽어들입니다 [1:3]. GitHub Copilot은 .github/copilot-instructions.md에도 대응하고 있으며, 공식 docs에서는 AGENTS.md를 포함한 여러 지시 파일이 우선순위 계층으로서 읽히는 구성이 명시되어 있습니다 [8].

여기서 XML이나 YAML을 채택할 이점은 없습니다. 이점이 있다면 "자사 전용 도구만 사용하는" 경우뿐이며, 그러한 판단은 향후 락인(Lock-in)을 증가시킵니다.

CLAUDE.md 설계의 실무적인 지침으로는 HumanLayer가 공개한 베스트 프랙티스(Best Practice)가 참고가 됩니다. 그들은 "150~200개를 초과하는 지시는 관리 불가능해진다", "300행 이하를 권장한다"라고 밝히고 있습니다 [9]. 형식은 Markdown일지라도 구조는 깨질 수 있습니다.

시스템 프롬프트 (Claude API 호출)

Claude를 사용한다면 XML 태그가 기본입니다. OpenAI / Gemini를 사용하는 경우는 다음 절의 보충 설명을 참조하십시오.

Anthropic 공식 docs는 다음과 같이 명시하고 있습니다.

"XML 태그는 특히 프롬프트에 지시 사항, 컨텍스트(Context), 예시, 가변 입력이 혼합되어 있을 때 Claude가 복잡한 프롬프트를 모호함 없이 파싱(Parse)하도록 돕습니다. 각 유형의 콘텐츠를 고유한 태그(예: <instructions>, <context>, <input>)로 감싸면 오해를 줄일 수 있습니다." [3:2]

이는 "Markdown이 나쁘다"는 이야기가 아니라, Claude의 훈련 데이터에 XML 태그가 포함되어 있다는 사실에 근거합니다. <instructions>, <context>, <example>과 같이 내용을 명시적으로 래핑(Wrapping)하면, Claude가 명령문과 참조문, 그리고 입력 데이터를 혼동하기 어려워집니다.

게다가 Markdown 프롬프트에는 부작용이 있습니다. Anthropic 공식 측은 다음과 같이 언급하고 있습니다.

"출력 형식의 제어력 (steerability) 문제로 어려움을 겪고 있다면, 프롬프트 스타일을 원하는 출력 스타일과 최대한 가깝게 맞춰보십시오. 예를 들어, 프롬프트에서 Markdown을 제거하면 출력물 내의 Markdown 양을 줄일 수 있습니다."

[5:1]

즉, "프롬프트에 Markdown을 많이 사용하면 출력에도 Markdown이 늘어나기 쉽다"는 뜻입니다. Slack 연동처럼 불렛 포인트(bullet points)나 헤딩(heading)을 억제하고 싶은 경우, 시스템 프롬프트(system prompt)를 Markdown이 아닌 XML 태그 + 평문(plain text)으로 작성하면 출력을 제어하기 쉬워집니다.

여기서 자주 인용되는 "XML 태그 사용 시 지시 준수율이 12% 향상된다"는 수치는 본 기사에서 사용하지 않습니다. Anthropic 공식 문서(docs)에서 그대로(verbatim) 확인할 수 없었기 때문입니다. 인용을 하려면 자사에서 A/B 테스트를 수행하여, 자사 프롬프트에서의 효과량을 직접 측정하십시오.

보충: Tool Use와 기타 형식

XML 태그는 어디까지나 "지시, 참조, 입력의 경계를 모호함 없이 나타내기" 위한 구분자입니다. **Tool 정의는 JSON Schema, tool_result는 구조화된 블록(structured block)**이며, 이는 XML 태그 논의와는 별개의 레이어입니다. OpenAI를 사용하는 경우에는 Structured Outputs (JSON Schema)로 출력을 강제하는 흐름이 주류이며 [10], Gemini도 Function Declarations를 통해 유사하게 처리합니다. "XML이 만능"인 것이 아니라, "Claude의 시스템 프롬프트 내 자유 기술 부분에서는 XML 태그가 효과적이기 쉽다"라고 한정적으로 해석해야 합니다.

참고로 arXiv 2411.10541에서는 MMLU에서 GPT-3.5-turbo가 YAML 56.36% / JSON 59.71%를 기록하며 Markdown 50.02%를 상회하는 태스크도 있습니다 [2:2]. "Plain vs Markdown"으로 논의를 끝내지 말고, YAML / JSON / XML을 포함한 5가지 형식으로 비교하는 것이 본래의 선택지입니다.

사용자 프롬프트 (태스크 지시)

이 계층은 태스크 의존적입니다. 판단을 멈추지 말고, 자신의 태스크에서 효과가 있는지 확인하십시오.

arXiv 2411.10541 (Microsoft + MIT, 2024-11-15)은 MMLU / HumanEval / CODEXGLUE / NER Finance의 4가지 벤치마크에서 Plain / Markdown / YAML / JSON의 4가지 형식을 비교한 논문입니다 [2:3]. 중요한 수치만 발췌합니다.

태스크	모델	Plain	Markdown	차이
HumanEval (pass@1)	GPT-3.5-turbo-0613	40.24%	54.27%	+14.03pt
...

코드 생성에서는 Markdown이 크게 우세하며, 지식 추론이나 개체명 인식(NER)에서는 Markdown이 뒤처집니다. GPT-4 계열에서는 차이가 좁혀지지만, 그럼에도 모든 태스크에서 일관되게 Markdown이 승리하는 것은 아닙니다.

실무적인 지침: 코드를 생성하게 하는 태스크는 Markdown에 가깝게, 자연어 지식 추론이나 정보 추출은 Plain에 가깝게 설정하십시오. 단, 모델이 바뀌면 경향도 바뀌므로, 신규 모델 도입 시에는 자사의 프롬프트로 재검증한다는 전제하에 운용하십시오.

RAG 컨텍스트

결론: 변환 비용과 정확도의 트레이드오프 (trade-off). 판단 기준은 3가지가 있습니다.

1. 문서 타입이 구조 중시형인가 문장 중시형인가

HtmlRAG (WWW 2025)는 HTML이 plain text를 통계적으로 유의미하게 상회한다는 결과를 5개의 데이터셋에서 보여주었습니다 [6:1].

Dataset	Metric	Plain	HtmlRAG
ASQA	Hit@1	68.50%	71.75%†
...

†: p<0.05로 통계적 유의미 (Llama-3.1-8B, Short-Context 4K tokens 설정)

다만 중요한 주의사항이 있습니다. HtmlRAG는 HTML 클리닝 + 2단계 pruning (가지치기)을 통해 원본 HTML의 약 6%까지 압축한 후 사용하고 있습니다[6:2]. raw HTML을 그대로 던지는 구성이 아닙니다.

2. 토큰 소비의 현실

raw HTML은 Markdown 대비 3~5배의 토큰을 소비합니다. Cloudflare Markdown for Agents는 Accept: text/markdown 헤더를 보내면 HTML을 Markdown으로 변환하여 반환하는 기능으로, Cloudflare 자사 블로그 1페이지 기준 HTML 16,180 tokens → Markdown 3,150 tokens (80% 절감)라는 실측치를 공개하고 있습니다[4:2]. Cloudflare 블로그에는 "Claude Code나 OpenCode가 이미 이 헤더를 보내오는 구성이 관측되고 있다"라고 기재되어 있습니다[4:3].

단, 80%는 1페이지의 실측치이며 범용적인 절감률은 아닙니다. 테이블 중심의 페이지나 SVG / 이미지가 많은 페이지에서는 절감률이 달라집니다. 사내에 도입하기 전에 자사의 주요 페이지에서 샘플 측정을 진행하십시오.

3. チャンキング (Chunking) 경계

Markdown으로 변환하면 제목 / 리스트 / 테이블을 チャンキング (Chunking)하기 쉬워지지만, 긴 테이블이 チャンキング 경계에서 분단되면 hit(적중)율이 떨어집니다. チャンキング (Chunking) 전략은 테이블을 하나의 단위로 유지하도록 설계해야 합니다 (테이블 전체를 1개 チャンク (Chunk)에 담거나, Markdown이 아닌 semantic-aware (의미 인식형) チャンカー (Chunker)를 사용).

AI 출력

배치 장소에서 결정하는 것이 원칙입니다.

Web 렌더링: HTML (또는 HTML을 생성하는 Markdown 렌더러 경유) -
API 파이프라인: Markdown 혹은 JSON / 구조화된 출력 (Structured Output) -
단말기 (CLI / Slack): 용도에 따라 다름. Slack이라면 mrkdwn, CLI라면 ANSI

Simon Willison은 2026-05-08 블로그에서 "GPT-4 시대에는 8,192 토큰 상한 제약으로 인해 Markdown 출력이 사실상의 기본(Default)이었으나, 128K 토큰 시대에는 HTML을 직접 출력하게 하는 선택지가 현실적이 되었다"라고 언급했습니다[7:1]. SVG 도표, 인터랙티브 요소, 내부 네비게이션이 필요한 경우에는 HTML을 직접 출력하게 하는 것이 번거로움을 줄이는 길입니다.

다만, 이는 개인 블로그의 견해이며 자사 벤치마크가 아니라는 점에 주의하십시오. 프로그램 연동이 전제라면 JSON / OpenAI Structured Outputs를 사용하는 것이 더 reliable (신뢰할 수 있는) 합니다[10:1].

HTML이 승리하는 3가지 케이스

"Markdown이 더 가볍다"라는 직관은 대체로 맞지만, HTML이 정답이 되는 국면이 분명히 존재합니다. 3가지로 정리합니다.

케이스 1: rowspan/colspan을 포함한 복잡한 중첩 테이블 (Nested Table)

Markdown에는 rowspan / colspan의 표준 표기법이 없습니다. 사양서, 요금표, 기능 비교표에서 셀 병합이 필요한 경우, Markdown으로 변환하면 정보가 누락됩니다. HTML 상태로 유지하거나, 표를 이미지화하거나, 별도의 표로 분할하는 방법 중 하나를 선택해야 합니다.

참고로, arXiv 2305.13062 (Microsoft Research, WSDM 2024)의 Table QA 벤치마크에서 GPT-3.5의 스코어는 다음과 같습니다[11].

형식	Cell Lookup	Column Retrieval	Size Detection
HTML	44.00%	63.33%	67.00%
Markdown	43.33%	35.33%	40.67%

Cell Lookup은 근소한 차이지만, Column Retrieval (28pt 차이)와 Size Detection (26pt 차이)에서는 HTML이 크게 우세합니다. 모든 테이블에서 HTML이 우세한 것은 아니라는 점에 주의하십시오. 태스크에 따라 차이는 달라집니다.

케이스 2: 커스텀 속성이 필요한 메타데이터

data-* 속성, itemprop, aria-label

요소에 추가 정보를 매달고 싶을 때와 같이, Markdown으로는 표현할 수 없습니다. RAG (Retrieval-Augmented Generation) 청크에 「문서 ID / 취득일 / 신뢰도」와 같은 메타데이터를 태그로 삽입하고 싶을 경우, HTML (또는 XML)이 선택지가 됩니다.

케이스 3: Web 렌더링과 AI 컨텍스트를 겸하는 경우

GitHub Issue 본문, 제품 문서 사이트, 사내 Wiki와 같이 사람이 Web에서 읽고, AI도 그대로 읽는 용도에서는 HTML을 이중으로 보유할 필요가 없습니다. Markdown으로 변환하는 파이프라인을 한 단계 추가하는 비용과, HTML을 직접 입력하여 3~5배의 토큰 비용을 지불하는 비용을 비교하여 결정하십시오.

128K context 시대에는 후자의 비용이 허용 범위 내에 들어오는 국면이 늘어나고 있습니다.

Anthropic 공식의 「모순」을 어떻게 해석할 것인가

여기까지 읽고 「Anthropic은 CLAUDE.md는 Markdown이라고 말하면서, 시스템 프롬프트(System Prompt)에서는 XML을 권장하고 있다. 모순된 것 아닌가?」라고 느낀 분도 계실 것입니다. 이것은 모순이 아니라 배치 장소에 따른 역할 분담입니다.

다시 정리하겠습니다.

문서	주요 작성자	Anthropic의 권장 사항	이유
CLAUDE.md / AGENTS.md	사람 (유지보수자)	Markdown	사람이 읽고 씀 / 도구 간 호환성
시스템 프롬프트	개발자	XML 태그	구조를 모호함 없이 Claude에게 전달
AI 출력 (프롬프트로 유도)	Claude	프롬프트 형식에 동조	프롬프트 형식을 출력 형식과 일치시킴

즉, 「사람이 쓰는 문서」는 Markdown / 「AI를 향한 기계적 지시」는 XML / 「AI 출력」은 프롬프트에 동조한다는 3층 구조입니다. CLAUDE.md 안에서 Claude에게 절차를 지시할 때는, Markdown 파일 내에 <instructions>, <example>와 같은 XML 태그를 혼재시켜도 문제없습니다. 오히려 Anthropic 공식 docs는 그러한 구성 사례를 보여주고 있습니다.

Hacker News에서는 「XML 권장은 실증적 근거가 아니라, 명확성이 본질이 아닌가」라는 논의도 있습니다. 태그의 형식 (XML / 커스텀 / Markdown 헤더)보다 「내용의 경계가 모호해지지 않았는가」가 본질이라는 관점입니다. 이는 설득력 있는 반론이며, 자사의 운영에서는 XML 태그에 집착하기보다 「지시와 참조, 예시를 명확하게 나누고 있는가」를 우선하는 것이 더 합리적인 경우가 있습니다.

하지 말아야 할 판단 3가지

1. HTML → Markdown의 반사적 변환을 하지 말 것

「AI에게 전달할 것이니 Markdown화 하자」라고 기계적으로 변환하기 전에, 비용을 산정하십시오.

• 변환 비용: 파이프라인 구현 및 유지보수
• 구조 손실: 중첩 테이블, 커스텀 속성, 양방향 링크
• 정확도 저하: 태스크에 따라 Markdown화로 인해 hit rate가 떨어짐 (HtmlRAG 결과) [6:3]

128K context가 전제된 모델이라면, HTML을 그대로 전달하여 토큰을 더 많이 사용하는 편이 총비용이 더 저렴한 경우가 있습니다.

2. 모든 배치 장소를 Markdown으로 통일하지 말 것

CLAUDE.md = Markdown, 시스템 프롬프트 = Markdown, RAG = Markdown, 출력 = Markdown 식의 통일은 겉보기에는 아름답지만, 각 배치 장소에서의 최적화를 놓치게 됩니다. 본 기사의 매트릭스에 따라 배치 장소별로 판단하십시오.

3. 벤더 블로그의 토큰 절감률을 일반화하지 말 것

Cloudflare 'Markdown for Agents'의 80% 절감은 Cloudflare 자사 블로그 1페이지의 실측값입니다. 테이블 중심의 페이지나 SVG가 많은 페이지에서는 절감률이 달라집니다. 「평균 80% 절감」이라고 사내에 설명하면, 나중에 실측값이 나왔을 때 신뢰를 잃게 됩니다. 필자의 환경에서도 테이블 비중이 높은 사내 Wiki에서는 50% 정도밖에 절감되지 않는 페이지가 드물지 않았습니다.

철수 비용의 기준

형식 선택은 「일단 채택」하기보다 「그만두기 어려움」으로 판단하는 것이 오해를 줄일 수 있습니다. 기준으로 삼을 만한 것은:

• HTML → Markdown 변환 파이프라인: 폐기 시 12인일 소요 (구현이 얕은 경우). 반대로 Markdown → HTML로 되돌리는 것은 수일1주일 소요 (CMS 또는 검색 인덱스 재구축이 수반되기 때문)
• 시스템 프롬프트의 XML → Markdown 전환: A/B 테스트 자체는 1일이면 충분하지만, 출력 포맷이 연쇄적으로 변하기 때문에 후속 단계인 Slack 연동·로그 정렬까지 포함하면 1개월(1 Man-month) 규모가 될 수 있음
• OpenAI Structured Outputs ↔ Anthropic Tool Use 간의 왕복: 스키마 표현 차이(JSON Schema의 subset 호환성, enum / oneOf 제약)로 인해 테스트가 필요함. 마이그레이션은 수일~1주일 소요

「맞지 않으면 되돌릴 수 있다」는 공수를 채택 판단 전에 미리 산정해 두면, 벤더 락인 (Vendor Lock-in)의 함정을 피하기 쉬워집니다.

현장에서 마주하는 함정과 한계

함정 1: RAG 청킹 (Chunking) 시 Markdown 테이블이 분단됨

Markdown의 테이블은 행 단위의 문자열입니다. 청크 경계에서 분단되면 절반밖에 가져올 수 없습니다. 테이블을 1개 청크에 들어갈 수 있는 단위로 설계하거나, 테이블 인지형 (Table-aware) 청커를 사용하십시오.

함정 2: 토큰 측정 도구 간의 차이

tiktoken으로 측정한 토큰 수와 Anthropic SDK가 보고하는 토큰 수는 일치하지 않습니다. 토크나이저 (Tokenizer)가 모델마다 다르기 때문에 당연한 결과이지만, 사내에서 「80% 절감」이라고 말할 때 어떤 모델의 어떤 토크나이저로 측정했는지를 명시하지 않으면 재현할 수 없습니다.

함정 3: 「최신 모델로 재검증」을 잊는 것

arXiv 2411.10541의 MMLU에서 GPT-3.5와 GPT-4의 경향이 역전된 것처럼, 모델 업데이트에 따라 포맷 민감도 (Format sensitivity) 경향이 변합니다 [2:4]. 실제로 GPT-4-32k에서는 HumanEval에서 Plain 76.22% / Markdown 75.61%로 거의 대등하며, GPT-3.5에서 보였던 +14pt 차이가 사라졌습니다 [2:5]. 반기마다 자사 프롬프트로 재벤치마크하는 운용을 포함하십시오.

함정 4: HTML을 직접 입력하면 프롬프트 인젝션 (Prompt Injection) 공격 면이 늘어남

RAG 컨텍스트나 AI 출력에서 HTML을 다룰 경우, <instructions> 형태의 가짜 태그, data-* 속성, HTML 주석(<!-- -->)에 공격 문자열을 심어두면, Claude가 이를 「시스템으로부터의 새로운 지시」로 오해할 여지가 있습니다. XML 태그를 Claude가 신뢰하는 성질을 역이용하는 구도입니다.

대응 방향은 세 가지가 있습니다.

• 수집 시 새니타이즈 (Sanitize): 신뢰 경계를 넘어온 HTML은 태그 허용 목록 (Allowlist)을 통해 제거한 후 AI에게 전달
• XML 스타일 태그 제거: <instructions>, <system>과 같은 어휘를 포함하는 요소는 제거 또는 이스케이프 (Escape) 처리
• 권한 분리: 도구 호출 권한을 가진 컨텍스트 (Context)와 외부 획득 컨텍스트를 분리하고, 후자는 읽기 전용 (Read-only)으로 취급

「Markdown보다 HTML이 토큰 효율이 나쁘다」는 논의는 토큰 경제의 문제이지만, 공격 면의 문제는 별개의 축입니다. 양쪽을 모두 고려하여 채택을 판단하십시오.

한계 1: 프레임워크 자체가 판단 정지를 일으킬 수 있음

「일단 Markdown」을 비판하며 5가지 배치 장소 × 4가지 판단 축을 제시했지만, 본 기사의 매트릭스 자체가 암기용 템플릿이 되면 다른 레이어의 판단 정지가 발생합니다. 「우리 회사는 기사의 매트릭스대로 XML로 했다」며 사고를 멈추지 말고, 자사의 A/B 결과와 모순된다면 매트릭스 쪽을 의심하십시오. 프레임워크는 사고의 기점이지 종착점이 아닙니다.

한계 2: 본 기사의 데이터도 노후화됨

본 기사에서 인용한 수치는 2024-2026년의 논문·벤치마크입니다. 모델 업데이트로 인해 역전될 가능성이 항상 존재합니다. 「Markdown이 지식 추론에서 뒤처진다」거나 「HTML이 RAG에서 우위에 있다」는 것 모두 현시점의 스냅샷에 불과합니다. 판단 축(5가지 배치 장소 × 4가지 판단 축)의 프레임워크는 쉽게 노후화되지 않지만, 각 셀의 수치는 재검증하십시오.

요약 — 월요일부터 바로 쓸 수 있는 판단 절차 3단계

형식 선택으로 고민된다면 다음 순서로 생각하십시오.

• 배치 장소를 5가지로 분류하기: 인간 → AI 지시 파일 / 시스템 프롬프트 (System Prompt) / 사용자 프롬프트 (User Prompt) / RAG 컨텍스트 (Context) / AI 출력 (Output).
• 매트릭스 표로 기본 형식을 결정하기: CLAUDE.md는 Markdown, 시스템 프롬프트 (Claude)는 XML, 코드 생성 사용자 프롬프트는 Markdown, RAG는 태스크에 따라, AI 출력은 배치 장소에 따라 결정.
• HTML이 필수인 3가지 케이스에 해당하지 않는지 확인하기: rowspan/colspan을 포함하는 테이블 / 커스텀 속성 (Custom Attribute)이 필요한 경우 / Web 렌더링이 병존하는 경우.

판단을 멈추게 하는 "일단 Markdown"에서 벗어나, 배치 장소 × 태스크에 따라 형식을 구분하여 선택하는 운영으로 나아가십시오. 월요일 리뷰에서 바로 사용할 수 있는 심플한 프레임워크가 되기를 바랍니다.

AGENTS.md 공식 사양: https://agents.md/ — Linux Foundation 산하 Agentic AI Foundation 관리. 60,000개 이상의 OSS 프로젝트 채택, 20개 이상의 에이전트 도구 대응 (2026년 시점). ↩︎ ↩︎ ↩︎ ↩︎

Jia He et al., "Does Prompt Formatting Have Any Impact on LLM Performance?", arXiv:2411.10541, 2024-11-15. https://arxiv.org/abs/2411.10541 — Microsoft + MIT. MMLU / HumanEval / CODEXGLUE / NER Finance 4 벤치마크에서의 Plain / Markdown / YAML / JSON 비교. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎