「AI 가독성」은 편리한 용어이지만, 그대로 두면 **측정할 수 없는 버즈워드 (Buzzword)**가 되기 쉽다. 본 기사는 5개 축으로 분해하여, 4개 축을 실측했다 (시드 고정·재현 가능·가공의 더미 데이터).

• 표 형식 데이터의 토큰 효율은 CSV가 압승 (x1.00). Markdown 표는 x1.22로 선전, JSON(min)은 x1.48, 「AI에게 친숙하다」고 흔히 말하는 정렬된 JSON은 x2.4, XML은 x2.8~3.3. 3가지 토크나이저 (o200k / cl100k / Gemini)에서 순위는 일치했다.
• 「YAML은 AI가 생성할 때 실수하기 쉽다」는 가설은 기각되었다. 일반 데이터와 악의적인 데이터 모두, 총 6개 형식에서 구문 성공 10/10 (gemini-3.6-flash, N=10). 현대 생성 모델의 위험은 구문 에러가 아니라, Markdown 표가 줄바꿈을 <br>로 조용히 바꿔버리는 종류의 「검지할 수 없는 내용 변조」로 이동해 있었다.
• diff는 1행 1레코드 형식 (CSV / JSONL / md 표)이 가설대로 우수했다. 다만 minified JSON의 「±2행이지만 변경 행 4,349자」라는 실측 결과는, 행수와 리뷰 가능성은 별개라는 점을 가르쳐 주었다.
• 50% 지점에서 절단하면, 행 지향 형식은 약 절반을 복원할 수 있지만, JSON / XML은 0 레코드. 0이냐 절반이냐의 격차는 측정하기 전까지 알 수 없었다.
• 파일 크기는 비용과 직결되는 실무 문제이기도 하다. 「AI 가독성」은 미학이 아니라 비용 최적화의 문제다.
• 타입 주석이 AI를 돕는다고 하더라도, 「AI가 읽기 쉬우니까」라는 이유로 기술 선정을 왜곡하는 것은 본말전도라는 입장을 취한다.
• 결론: 「Markdown이 최적」이라는 결론에는 도달하지 못했다. 용도에 따라 답이 달라진다. 동일한 CSV가 「읽히는 것」의 왕이면서 「쓰게 하여 기계가 받는 것」에는 비권장이라는 실측 결과가 이를 상징한다.
• 미측정 잔여 요소 (Claude의 Token Counting API 실측·깊은 중첩·다중 모델 비교)는 명기하였다. 재현을 위한 비판(마사카리)을 환영한다.

「AI에게 읽히는 파일은 Markdown이 최적이다」라는 설을 지난 1년간 도대체 몇 번이나 보았을까. 필자 자신도 사내용 AI 주도 개발 자료에 「AI 가독성이 높은 데이터 파일」이라는 항목을 만든 적이 있다. 쓰면서 문득 깨달았다. 그 「가독성」이란 구체적으로 무엇을 가리키는 것인가, 스스로도 설명할 수 없었다.

토큰이 적게 든다는 이야기인가. 구조를 오해하기 어렵다는 이야기인가. 아니면 AI가 생성할 때 에러를 일으키기 어렵다는 이야기인가. 세 가지 모두 다른 성질임에도 「AI 가독성」이라는 한 단어로 묶여 이야기되는 경우가 많다. 한데 묶여 불리는 순간, 그것은 검증 불가능한 슬로건이 된다.

자매 기사(도시 전설 성불 가이드)의 「전설 그 다섯 번째」에서, 필자는 자신의 자료에 적힌 「Markdown = AI 가독성이 높다」라는 문장에 스스로 태클을 걸었다. 「그래서, 측정해 봤어?」라고. 본 기사는 그 숙제를 회수하는 기사이다. 측정했다. 결과에는 가설대로인 것과, 가설이 기분 좋게 배신당한 것 양쪽이 모두 존재한다.

버즈워드를 해체하려면 먼저 축을 세울 필요가 있다. 본 기사에서는 다음과 같은 5개 축으로 분해하여 다룬다.

• 토큰 효율 (Token Efficiency) — 동일한 정보량을 표현하는 데 몇 토큰이 필요한가
• 구조의 모호성 내성 (Structural Ambiguity Tolerance) — AI가 해당 포맷을 생성할 때 구문 에러나 의미의 붕괴가 얼마나 일어나기 어려운가
• diff 친화성 (diff Affinity) — 변경된 부분만 명확하게 diff에 반영할 수 있는가
• 부분 읽기 가능성 (Partial Readability) — 파일의 파편만 읽어도 의미가 통하는가
• 언어 선정에 미치는 파급 (Impact on Language Selection) — 타입 시스템이나 명명 규칙의 일관성이 코드 이해·생성 정밀도에 어떻게 영향을 주는가

이 5개 축을 관통하는 원칙이 하나 있다. 「AI」라고만 쓰고 끝내지 않는 것이다. Claude·GPT·Gemini는 토크나이저가 다르다. 같은 텍스트라도 모델에 따라 토큰 수가 달라진다. 이후 수치를 제시하는 장면에서는 반드시 어떤 모델의 측정인지를 명시한다.

축 1, 토큰 효율. 측정했다.

측정 조건 (시드 고정·완전한 가공의 더미 데이터·재현 가능):

• 데이터 A: 표 형식 50레코드 × 6필드 (id/이름/카테고리/가격/재고/비고)를 일본어·영어 2개 로케일로 준비
• 데이터 B: 중첩 설정 파일 (3계층·리프 30키 상당)
• 토크나이저: tiktoken o200k_base (GPT-4o 계열) / cl100k_base

(GPT-4 계열)은 로컬 측정, Gemini는 countTokens API (gemini-3.6-flash)를 실측 -
Claude는 미측정. 로컬에서 완결되는 공식 토크나이저 (Tokenizer)가 공개되지 않아 Token Counting API를 호출해야 하지만, 집필 환경에 API 키를 보유하고 있지 않기 때문임. 재시험할 경우 Anthropic의 count_tokens 엔드포인트로 동일한 텍스트를 전송하면 됨 (본 기사의 수치 표는 그대로 비교 대상으로 사용할 수 있음)

영어 로케일 (Locale)에서도 순위는 거의 동일함 (CSV x1.00 → XML x3.26). 3가지 토크나이저 모두 순위가 일치했다.

• "CSV는 열 이름의 반복이 없는 만큼 효율적이다" →
  확인됨. 표 형식에서는 압승 (키 이름을 50회 반복하는 JSON 계열에 비해, CSV는 헤더 1행으로 충분함. JSONL과 CSV의 차이인 +52%가 바로 "키 이름 반복의 비용" 그 자체임) - "중첩(Nest)이 깊은 JSON은 괄호로 인해 토큰을 낭비한다" →
  절반만 맞음. 낭비되고 있는 것은 괄호가 아니라 **들여쓰기 (Indent)**였음. JSON-pretty는 JSON-min의 약 1.6배임. 중첩 설정에서는 minified JSON이 최소이며, YAML보다 효율적이라는 가설 역전이 일어남 - "Markdown은 AI에게 친화적이다" → 표 형식의 토큰 효율에서는
  CSV에 패배 (하지만 x1.22로 선전함. 인간 가독성과의 양립을 고려하면 나쁘지 않음) - 덤: 일본어 데이터는 cl100k에서 +45% 늘어나지만 o200k에서는 +26%로 개선됨.
  토크나이저 세대에 따라 로케일 페널티 (Locale Penalty)가 다름

이 부분이 본 기사에서 가장 말하고 싶은 점이다. 세상의 "AI 가독성" 담론은 거의 전부 "AI에게 읽히는" 관점에서 쓰여 있다. 하지만 실무에서는 "AI에게 쓰게 하고, 그것을 인간이나 다른 시스템이 읽는" 상황이 그만큼 많다. 이 두 가지는 요건이 반대 방향이 될 수 있다.

통설은 이렇다. "YAML은 들여쓰기에 의존하여 AI가 생성 시 실수하기 쉽다. JSON은 기호가 가득해 장황하지만, 그 기호가 구조의 경계를 명시하므로 잘 깨지지 않는다". 필자도 그렇게 쓰려 했다. 측정해 보니, 이야기가 달랐다.

측정 방법: 동일한 10개 레코드(시드 고정 더미 데이터)를 각 포맷으로 출력하게 하는 시도를 포맷별로 10회 수행 (모델: gemini-3.6-flash, temperature는 API 기본값). 판정은 "표준 파서 (Parser)로 그대로 파싱할 수 있는가 (구문)"와 "파싱 결과가 원본 데이터와 완전히 일치하는가 (내용)"의 2단계로 진행. 나아가, 이스케이프 지옥 데이터 (콜론+공백, 이중 인용부호, 줄바꿈 포함 값, 행 시작 #, 행 시작 -, 단독 no, 파이프 |, <tag>&, 백슬래시, 끝 공백 —— 각 포맷의 급소를 찌르는 10종)로도 동일한 시도를 수행했다.

먼저 일반 데이터다. 모든 포맷에서 구문(Syntax)과 내용 모두 만점이다. "YAML은 AI가 어려워한다"는 가설은 이 난이도와 이 모델에서는 관측되지 않았다. 가설은 기분 좋게 기각되었다. 현행 모델의 생성은 평이한 표 데이터 정도라면 구문적으로 견고하다.

흥미로운 것은 악의적인 데이터(Edge case data)다. 구문 수준에서는 여전히 모든 포맷이 만점이다. YAML은 콜론이 포함된 값을 올바르게 인용(Quote)했고, CSV는 이중 따옴표를 ""로 중첩했으며, Markdown 표는 파이프를 \|로 이스케이프(Escape)했다. 모델은 이스케이프 규칙을 알고 있다.

그럼에도 불구하고, CSV와 Markdown 표만 내용의 완전 일치도가 0/10이 되었다. 출력된 실물을 대조하여 원인을 특정했다.

Markdown 표는 줄바꿈을 표현할 수 없기 때문에, 모델이 값을 [IMG:1]로 바꾸었다. 구문 에러는 발생하지 않는다. 파싱(Parsing)도 통과한다. 하지만 데이터는 변해 있다. 표현력의 한계를 모델이 "눈치껏" 조용히(Silent) 메운 것이다. <br>로 바꾸어 표현한 것이다.

모델은 GFM(GitHub Flavored Markdown)을 준수하며 [IMG:2]로 동작했다. 둘 다 "올바르게" 행동한 결과, 사양(Specification)의 모호함이 툴체인(Toolchain)의 단절을 야기했다. \|로 이스케이프했음에도 불구하고, 받는 쪽의 단순한 파서(단순히 |로 split 하는 세상에 무수히 존재하는 구현체들)가 이를 해석하지 못해 레코드가 통째로 조용히 사라졌다.

CSV의 불일치는 끝부분 공백(Trailing whitespace)에 대한 단 한 번의 프로브(Probe)뿐이었다(모델의 출력은 RFC 4180을 준수했다). 필드 끝의 공백은 사양상 유지되어야 하지만, 현실의 수신 측은 종종 이를 trim(공백 제거)한다. 본 검증의 하네스(Harness) 자체가 바로 그 실수를 저질렀다.

즉, 이런 상황이다. 현대 모델에게 있어 생성의 위험은 구문 에러로부터 거의 사라졌다. 남은 위험은 "포맷의 표현력 부족을 메우기 위한 조용한 변형"과 "사양의 모호함으로 인한 송신자와 수신자 간의 해석 불일치"로 이동하고 있다. 구문 에러는 검출할 수 있다. 하지만 조용한 변형은 검출할 수 없다. JSON / YAML / TOML이 악의적인 값에서도 완전히 라운드트립(Round-trip)된 이유는, 이스케이프 체계가 사양으로서 유일하게 확정되어 있기 때문이다.

한계점도 명시한다. 단일 모델, N=10, 평이한 표 데이터에서의 결과이며, 깊은 중첩(Nested) 구조나 방대한 출력, 혹은 다른 모델에서는 차이가 발생할 가능성이 남아 있다. 또한 "단순한 파서" 역시 측정계의 변수다. 다만 그것은 현실의 파이프라인(Pipeline)에서도 변수로 작용한다.

읽히는 형식과 쓰게 하는 형식의 요구사항은 정반대일 때가 있다.

축 3, diff 친화성. 동일한 변경 작업을 각 포맷에 적용하고, unified diff(컨텍스트 0행)의 ±행 수와 변경 행의 최장 문자 수를 측정했다. "±행 수"는 구문 노이즈에 더해 "해당 포맷에서 1개 레코드가 차지하는 행 수"를 포함하는, 이른바 **diff의 풋프린트(Footprint)**다.

조작: (a) 50개 레코드 중 1개의 가격 변경 / (b) 끝에 1개 레코드 추가 (표 형식, 일본어 데이터)

숫자가 말해주듯, "±행 수"만 보면 JSON-min이 우수해 보이지만, 최장 4,349자에 달하는 1행 diff는 인간에게도 AI에게도 실질적으로 리뷰가 불가능하다. 행 수와 리뷰 가능성은 별개의 문제다. 이 또한 직접 측정해 보고 나서야 언어화할 수 있었다. 1행 1레코드 형식(CSV / JSONL / Markdown 표)은 가설대로 추가 시 순수한 1행으로 나타난다. JSON-pretty의 "1개 레코드를 추가했을 뿐인데 직전 행의 닫는 쉼표까지 diff에 포함되는" 현상도 실측을 통해 재현되었다.

축 4, 부분 읽기 가능성. 컨텍스트 길이와 비용의 제약으로 인해, 큰 파일은 분할하여 읽게 하는 경우가 있다. 여기서 중요한 것이 "중간에 끊어도 복구할 수 있는가"이다.

측정 방법: 각 파일을 파일 앞부분 50% 바이트 지점에서 기계적으로 절단하고, "끝부분의 불완전한 행을 한 줄씩 버리는" 방식의 복구만을 허용한 뒤 표준 파서 (Standard Parser) (json / yaml.safe_load / tomllib / csv / ElementTree)에 입력하여 복구된 레코드 수를 계산했다. 이는 LLM의 독해를 거치지 않는, 순수하게 기계적인 하한값이다.

중첩 설정 파일 (리프 30키)에서도 동일한 구도: YAML 14/30, TOML 13/30인 것에 반해, JSON과 XML은 0/30이었다.

가설대로이기는 하지만, 0인지 절반인지에 대한 격차의 심함은 측정하기 전까지는 알 수 없었다. 행 지향 포맷(Row-oriented format)은 "절단 지점까지의 정보가 전부 살아남는" 반면, 괄호나 태그로 전체를 감싸는 형식은 "1바이트만 어긋나도 전손"된다. 거대 파일을 분할하여 AI에게 흘려보내는 운용을 한다면, 이 차이는 컨텍스트 설계에 그대로 영향을 미친다.

참고로, 이는 표준 파서를 통한 기계적 복구율이다. LLM은 깨진 JSON으로부터도 내용물을 어느 정도 "독해"해 버리기 때문에, 실제 이용 시의 차이는 이보다 줄어들 가능성이 있다. 하지만 복구를 LLM의 호의에 의존하는 설계는 그 자체로 리스크라는 것이 필자의 입장이다.

축 5, 언어 선정으로의 파급. 정적 타이핑 (TypeScript vs JavaScript, 타입 주석이 있는 Python vs 순수 Python)이 AI의 코드 이해 및 생성을 돕는다는 가설은 자주 거론된다. 타입 정보는 일종의 "런타임에 의존하지 않는 문서"로서 기능할 수 있다는 논리 자체는 일리가 있다.

검증한다면, 동일한 태스크 (기존 코드에 기능 추가)를 타입 주석이 있는 코드와 타입 주석이 없는 코드로 AI에게 여러 번 실행하게 하여, 생성된 코드의 타입 불일치 에러율이나 리뷰 지적 수를 비교하는 설계가 될 것이다. 다만 샘플 사이즈와 재현성의 한계는 명시할 필요가 있다. 몇 번 시도해서 차이가 나타나더라도, 그것이 통계적으로 의미 있는 차이인지 아니면 우연인지는 신중하게 살펴봐야 한다.

그리고, 여기서부터가 본 기사에서 가장 강력하게 말하고 싶은 비판이다.

타입 주석이나 TypeScript가 AI의 이해를 돕는다고 하더라도, 그것을 주 목적으로 프로젝트의 언어 선정을 바꾸는 것은 순서가 틀렸다. 타입 시스템이나 프레임워크의 선정은 본래 유지보수성, 팀의 숙련도, 퍼포먼스, 채용의 용이성 같은 요인으로 결정해야 하는 것이지, "AI가 읽기 쉬우니까"를 주요 요인으로 삼는 것은 본말전도이다.

AI 가독성은 기술 선정의 가점 요소이지 결정 요인이 아니다. "AI가 코드를 이해하기 쉬워지니까 타입을 도입하자"라는 제안 자체는 나쁘지 않다. 하지만 그 제안이 "팀원 누구도 타입의 혜택을 실감하지 못하지만, 오직 AI를 위해서만 도입한다"라는 이야기로 뒤바뀌는 순간, 그것은 도구를 위해 인간의 작업을 희생시키는 전도된 상황이다. AI는 어디까지나 개발을 돕는 도구이며, 도구에 맞춰 설계 사상을 왜곡하는 것은 주객이 전도된 것이다.

지금까지의 5개 축은 파고들면 결국 하나의 실무 문제로 이어진다. 바로 비용이다.

토큰 효율이 나쁜 포맷은 동일한 정보를 전달하는 데 더 많은 토큰을 소비한다. 부분 읽기가 불가능한 형식은 파일 전체를 매번 읽어야 하므로, 컨텍스트 윈도우(Context Window)와 API 과금 양쪽 모두를 압박한다. 이는 지속적인 대화나 에이전트의 반복 실행에서 쌓이게 되면 무시할 수 없는 차이가 될 수 있다 (프롬프트 캐싱(Prompt Caching) 메커니즘에 의해 동일한 접두사(Prefix)의 재읽기 비용은 경감되지만, 캐시가 적용되지 않는 차이 부분에는 이 문제가 그대로 남는다).

즉 "AI 가독성"을 논하는 것은 미학의 문제도, 유행하는 버즈워드(Buzzword)의 문제도 아니며, 어떤 포맷을 선택해야 동일한 작업을 더 저렴하게 돌릴 수 있는가라는, 현실적인 비용 최적화의 문제이다. 지금까지의 장에서 다루어 온 토큰 효율, 구조 내성, diff 친화성, 부분 읽기 가능성은 모두 이 한 점으로 수렴한다.

지금까지의 실측을 통합하여 용도별 판단표를 채운다. 「Markdown이 만능이다」라는 단순한 결론에는 도달하지 못했다. 용도에 따라 답이 달라지는 것이 실측이 내놓은 답이다.

한 가지 강조하고 싶다. 같은 CSV가 「읽히는 용도」에서는 제1후보이지만, 「쓰게 하여 기계가 받는 용도」에서는 비권장이 된다. 서두에서 세운 「읽히는 형식과 쓰게 하는 형식은 요구사항이 다르다」라는 관점은 실측을 통해 이 정도로 구체적인 형태가 되었다.

또 하나, 솔직하게 적어둔다. 원본이 된 사내 자료에는 「Markdown은 타 형식(CSV·PowerPoint·SVG 등)으로의 변환이 용이하다」라는 기술이 있었다. 이 주장은 검증하지 않았다. 특히 Markdown에서 슬라이드 형식으로의 변환은 구조화되지 않은 정보원으로부터 생성되는 경향이 있어, 품질의 재현성이 낮지 않을까 하는 의구심을 갖고 있다. 이 점은 검증 과제로 남겨둔다. 단정 짓지는 않겠다.

5가지 평가 축으로 분해하여 실측한 뒤에 이야기한다는, 당연한 것을 당연하게 하는 글을 쓰고 싶었다. 다시 정리한다.

• 「AI 가독성」은 토큰 효율·구조의 모호함에 대한 내성·diff 친화성·부분 읽기 가능성·언어 선정에 미치는 파급효과의 5개 축으로 분해할 수 있으며, 그중 4개 축은 이번에 실측했다.
• 실측은 가설 3가지를 뒤엎었다:
  • YAML의 생성은 깨지지 않았다. JSON의 토큰 낭비의 정체는 괄호가 아니라 **인덴트(Indent, 들여쓰기)**였다. 그리고 구문이 통과하더라도 내용이 조용히 깨지는 포맷이 있었다.
  • 수치를 제시할 때는 반드시 모델명을 명시한다. Claude / GPT / Gemini마다 토크나이저(Tokenizer)가 다르므로 「AI 전반에서」라고 말할 수 없다 (이번에도 3개 계열로 측정하였으며, Claude만 미측정임을 명시했다).
• 「읽히는 형식」과 「쓰게 하는 형식」은 요구사항이 다르다. 같은 CSV가 용도에 따라 제1후보가 되기도, 비권장이 되기도 한다는 실측이 이 비대칭성의 실체다.
• AI 가독성은 기술 선정의 가점 요소이지 결정 요인이 아니다. 타입이나 프레임워크 선정을 오직 AI만을 위해 왜곡하는 것은 본말전도이다.
• 파일 형식 선정은 비용 최적화의 문제이기도 하다. 미학이 아니다.
• 그리고, 측정하지 않은 수치는 쓰지 않는다. 본 기사에 남은 미실측 항목(Claude 실측·깊은 중첩·다중 모델)은 미실측이라고 적었다. 재시험(Re-test)이야말로 최고의 마사카리(Masakari, 날카로운 비판/도구)이다.

문서의 단일 소스화(Single Source of Truth)라는 인접 영역에 대해서는, 「OpenAPI → markdown 단일화 의사결정 — Phase 1 의존성 정리 + Phase 2 물리적 삭제의 의사결정 프로세스」에서 다루고 있다. 그 글은 「문서를 어디로 일원화할 것인가」라는 의사결정 프로세스가 주제이며, 본 기사는 「왜 그 형식이 AI 가독성 관점에서 유리/불리한가」를 깊이 파고드는 위치에 있다. 함께 읽어준다면 이해가 깊어질 것이다.

중간에 끊겼을 때의 반응이 양자의 성격을 가장 잘 나타낸다.

• JSON: ECMA-404 / RFC 8259

• YAML: yaml.org 공식 사양

• TOML: 공식 GitHub 리포지토리의 사양서

• CSV: RFC 4180

• Anthropic의 Token Counting API 공식 문서 (로컬 완결형 공식 토크나이저(Tokenizer)는 비공개이므로, API 측정이 정답임)

• OpenAI tiktoken 공식 리포지토리

• 「완전히 이해했다」 예시 그래프, 원 논문에는 없다고 함 — 괴팍한 엔지니어를 위한 도시 전설 성불 가이드

• OpenAPI → Markdown 단일 소스화 의사결정 기사 (인접 영역, 공개 시 링크 확정)