Anthropic Claude Code 팀의 글 한 편이 X에서 800만 뷰를 찍으며 'Markdown은 끝났는가'라는 논쟁에 불을 붙였습니다. 제목의 계보(Wigner의 수학 → Halevy의 데이터 → 2026의 HTML)부터, 왜 에이전트 시대에 Markdown이 족쇄가 됐는지, 왜 LLM은 HTML을 '비합리적으로' 잘 만드는지, 그리고 그대로 써먹는 5가지 프롬프트까지 — 인터랙티브 데모와 일러스트로 쉽게 풀었습니다.
2026년 5월, Anthropic Claude Code 팀의 Thariq Shihipar가 쓴 글 한 편이 X(트위터)에서 800만 뷰를 넘기며 개발자 타임라인을 뒤덮었습니다. 제목은 Using Claude Code: The Unreasonable Effectiveness of HTML. 한 줄로 요약하면 이렇습니다.
"AI에게 결과물을 받을 때, 이제 Markdown 말고 HTML로 받아라."
별것 아닌 팁처럼 들리죠. 그런데 반응은 격렬했습니다. "Markdown은 죽었다(Markdown is dead)" 같은 제목의 후속 글이 쏟아졌고, Hacker News에선 찬반이 팽팽하게 갈렸습니다. Markdown의 오랜 옹호자였던 Simon Willison조차 "내 생각을 바꿔야 할 것 같다"고 공개적으로 전향을 선언했고요.
왜 'AI 출력 포맷을 바꾸자'는 이야기가 이렇게까지 화제가 됐을까요? 그건 이 글이 단순한 팁이 아니라, "사람과 AI는 앞으로 어떤 형식으로 대화할 것인가"라는 더 큰 질문을 건드렸기 때문입니다. 이번 특집에서는 그 질문을 역사·논문·실무 세 갈래로 천천히 풀어보겠습니다.
이 글에서 다루는 것 · ① 제목의 계보(왜 "비합리적인 효과"인가) · ② 왜 하필 지금 Markdown이 족쇄가 됐나 · ③ 핵심 주장과 5가지 강점 · ④ 왜 LLM은 HTML을 그토록 잘 만드나 · ⑤ 그대로 써먹는 실전 프롬프트 5종 · ⑥ 반론과 트레이드오프 · ⑦ 코어닷의 실무 적용 가이드
먼저 제목을 뜯어봐야 합니다. "The Unreasonable Effectiveness of ___" 라는 표현은 2026년에 갑자기 튀어나온 게 아닙니다. 과학·AI 역사에서 "설명하기 어려울 만큼 잘 통하는 것"을 가리킬 때 60년 넘게 변주되어 온, 일종의 밈(meme)이자 헌사입니다.
물리학자이자 노벨상 수상자인 유진 위그너(Eugene Wigner)는 1960년 논문 "The Unreasonable Effectiveness of Mathematics in the Natural Sciences"에서 이렇게 물었습니다. "인간 머릿속의 추상적 기호놀음에 불과한 수학이, 어째서 우주의 물리 현상을 이토록 정확히 기술하는가?" 그는 이걸 "우리가 이해하지도, 받을 자격도 없는 놀라운 선물"이라고 불렀습니다. 이게 모든 변주의 원형입니다.
세월이 흘러 2009년, Google의 Alon Halevy, Peter Norvig, Fernando Pereira가 위그너를 오마주해 "The Unreasonable Effectiveness of Data"를 발표합니다. 핵심 주장은 충격적이었습니다.
"언어 이해처럼 인간이 얽힌 복잡한 문제는
F=ma같은 간결한 공식으로 풀리지 않는다. 영리한 알고리즘보다, 엄청난 양의 데이터가 이긴다."
이 한 편이 사실상 오늘날 딥러닝·LLM 시대의 사상적 출발점이 됐습니다. 모델 구조를 정교하게 깎는 것보다 데이터를 쏟아붓는 쪽이 낫다는 이 직관은, 이후 GPT와 Claude로 이어지는 스케일링의 시대 그 자체였죠.
2015년엔 Andrej Karpathy가 "The Unreasonable Effectiveness of Recurrent Neural Networks"에서, 단순한 글자 단위 신경망에 텍스트를 잔뜩 먹였더니 셰익스피어 문체부터 코드, 심지어 HTML 마크업 구조까지 스스로 지켜가며 생성하는 걸 보여줬습니다. (괄호를 열면 닫고, 태그를 열면 닫는 식으로요.) 돌이켜보면 11년 뒤 이야기의 복선이었던 셈입니다.
그리고 2026년, HTML 차례가 왔습니다. 이 계보에 올라탔다는 건, 저자가 단순한 팁이 아니라 "이론보다 풍부한 매체가 이긴다"는 같은 메시지의 새 변주를 던지고 있다는 뜻입니다. 아래에서 직접 눌러가며 흐름을 따라가 보세요.
여기서 자연스러운 의문. "Markdown도 충분히 좋잖아? 왜 갑자기 버리자는 거지?"
핵심은 "Markdown이 나빠진 게 아니라, AI가 너무 좋아졌다"는 데 있습니다.
Markdown은 2004년 존 그루버가 "사람이 읽고 쓰기 쉬운 최소한의 서식"으로 만든 포맷입니다. 가볍고, 깔끔하고, 어디서나 통하죠. AI가 등장한 뒤에도 Markdown은 자연스러운 기본값이 됐습니다. 이유가 있었습니다.
Markdown의 오랜 옹호자 Simon Willison은 솔직하게 고백합니다. 자신이 Markdown을 기본으로 삼았던 건 GPT-4 시절 토큰이 비쌌기 때문이라고요. 같은 내용을 표현할 때 HTML은 <div class="..."> 같은 태그 때문에 토큰을 훨씬 많이 먹습니다. 출력이 길어지면 그게 곧 돈이고 속도였죠. 그래서 "간결한 Markdown"이 합리적이었습니다.
그런데 2026년의 상황은 다릅니다. 모델은 더 싸지고 빨라졌으며, 무엇보다 컨텍스트가 폭발적으로 늘었습니다. Claude Code 같은 에이전트는 이제 단순히 질문에 답하는 게 아니라, 파일시스템·git 히스토리·Slack·Linear·브라우저 기록·MCP까지 훑어서 방대한 정보를 종합합니다.
이 풍부한 결과물을 Markdown 한 장에 쏟아부으면 어떻게 될까요? 저자의 표현을 빌리면, 100줄이 넘어가는 순간 읽기가 괴로워집니다. 표·그래프·다이어그램·인터랙션을 표현할 수 없으니, AI는 어쩔 수 없이 ASCII 아트로 박스를 그리거나 유니코드로 색을 흉내 내는 눈물겨운 우회를 하게 되죠.
정리하면, 문제는 포맷의 우열이 아니라 시대의 변화입니다.
말보다 직접 보는 게 빠릅니다. 똑같은 요청 "랜딩 페이지 디자인을 확연히 다른 6가지로 만들어서 한눈에 비교하게 해줘"에 대해, Claude가 Markdown으로 답할 때와 HTML로 답할 때가 어떻게 다른지 토글해 보세요.
정보의 양은 똑같습니다. 그런데 의사결정에 걸리는 시간이 완전히 다르죠. Markdown은 위아래로 스크롤하며 숫자를 직접 읽어야 하지만, HTML은 6개가 grid로 펼쳐지고 막대 길이로 점수가 한눈에 들어옵니다. 저자가 강조하는 한 문장이 바로 이 지점을 찌릅니다.
"Claude가 읽을 수 있는 정보 중에서, HTML로 효율적으로 표현하지 못할 것은 거의 없다."
저자는 HTML의 우위를 다섯 갈래로 정리합니다.
| 관점 | Markdown | HTML |
|---|---|---|
| 정보 밀도 | 표·줄글 위주. 다이어그램은 ASCII 아트로 우회 | 표·CSS·SVG 도식·인터랙션·이미지·공간 배치까지 |
| 시각적 가독성 | 100줄 넘으면 읽기 어려움 | 탭·목차·색·레이아웃으로 구조화, 모바일 대응 |
| 공유성 | 보통 첨부파일로 보내야 함 | 파일 업로드 → 링크 한 줄로 공유 |
| 양방향 인터랙션 | 읽기 전용 | 슬라이더·토글로 조정 → 복사 버튼으로 다시 AI에게 |
| 컨텍스트 | 웹 Claude는 입력에 갇힘 | Code는 파일·git·Slack·MCP까지 읽어 더 깊은 결과 |
특히 4번 "양방향 인터랙션"이 핵심적인 전환점입니다. 지금까지 AI의 결과물은 읽고 끝이었습니다. 그런데 HTML이면 사용자가 슬라이더를 돌려 애니메이션 속도를 직접 맞춰보고, 마음에 든 값을 복사 버튼으로 다시 Claude에게 던질 수 있습니다. 결과물이 대화의 한 장면이 되는 거죠.
여기서 한 단계 더 깊이 들어가 봅시다. 단순히 "HTML이 더 표현력이 좋다"가 전부가 아닙니다. 언어모델이 HTML을 유독 잘 생성한다는, 기술적으로 운 좋은 사실이 깔려 있습니다.
LLM은 인터넷 텍스트로 학습됩니다. 그 인터넷의 골격이 바로 HTML이죠. Hacker News의 한 댓글이 정곡을 찔렀습니다.
"HTML은 수십 년 동안 극도로 헌신적인 사람들이 정성껏 다듬어 온 포맷이다. 웹으로 학습한 모델에게 이건 가장 자연스러운 출력 형식이다."
즉 HTML은 모델에게 외국어가 아니라 모국어에 가깝습니다. 태그를 열면 닫고, 중첩 구조를 지키고, CSS·SVG·JS를 섞는 패턴을 어마어마하게 많이 봤기 때문에, 시키면 그냥 잘합니다. (앞서 본 2015년 Karpathy의 관찰이 바로 이 능력의 초기 신호였습니다.)
HTML은 CSS·JavaScript·SVG·데이터를 하나의 .html 파일 안에 모두 담을 수 있습니다. 빌드 도구도, 의존성 설치도, 서버도 필요 없죠. 그냥 더블클릭하면 열립니다.
생성된 HTML을 실행할 환경이 이미 모든 기기에 깔려 있습니다. 맥이든 윈도든 아이폰이든, 브라우저만 있으면 열립니다. AI가 만든 결과물을 동료에게 보낼 때 "이거 실행하려면 뭐 설치해야 해?"라는 마찰이 0이라는 뜻입니다. 이 보편성이 HTML 출력을 공유 가능한 산출물로 만들어 줍니다.
정리: 모델이 잘 만들고(①) + 실행에 아무것도 필요 없고(②) + 어디서나 열린다(③). 이 세 박자가 맞아떨어져 "비합리적일 만큼" 잘 통하는 겁니다.
이제 가장 실무적인 부분입니다. 저자는 HTML 출력이 빛나는 다섯 가지 상황을 제시합니다. 좋은 소식은, 복잡한 지시가 필요 없다는 것입니다. 저자의 말마따나 "그냥 'HTML 파일로 만들어줘'라고 하고, 무엇을 원하는지만 명확히" 하면 됩니다.
아래 탐색기에서 상황별 예시 프롬프트를 확인하고 복사 버튼으로 바로 가져가 보세요.
각 활용처를 문제 → HTML이 주는 해결 → 결과 로 다시 정리하면 이렇습니다.
나머지 둘도 강력합니다. ④ 리포트·학습 — Slack·코드베이스·git 히스토리·웹검색을 한 편의 읽기 좋은 HTML 설명서로 합치되, SVG 다이어그램 + 주석 달린 핵심 코드 + "흔한 함정(gotchas)" 섹션까지. 실제로 Simon Willison은 이 방식으로 리눅스 보안 익스플로잇을 "헷갈리는 부분은 풀어서, HTML·CSS·JS로 인터랙티브하게" 설명하게 시켰더니 훌륭하게 동작했다고 합니다.
⑤ 커스텀 편집 인터페이스 — 특정 작업 전용 미니 에디터를 그때그때 만들어 씁니다. 티켓을 드래그 앤 드롭으로 우선순위 버킷에 정렬하고 JSON으로 내보내기, 피처 플래그를 의존성 경고와 함께 편집하기, 시스템 프롬프트를 토큰 카운터와 나란히 튜닝하기 — 모두 단일 HTML 한 장으로요.
💡 프롬프트의 정석은 의외로 단순합니다. "~를 하는 단일 HTML 파일로 만들어줘" + "무엇이 보이길 원하는지" + (필요하면) "조정한 값을 복사하는 버튼". 기술적 복잡성이 아니라 원하는 기능을 명확히 아는 것이 전부입니다.
화제가 된 만큼, 날카로운 반론도 많았습니다. 균형을 위해 꼭 짚고 갑니다. Hacker News에서 가장 많은 공감을 받은 비판들입니다.
그래서 커뮤니티가 제시한 절충안도 많습니다. Markdown + 필요할 때만 HTML 임베드, Mermaid 다이어그램을 곁들인 GFM, 로컬 빌드로 Markdown→스타일 HTML 변환 등. 결론은 "무조건 HTML"이 아니라 상황에 맞게입니다.
| 이럴 땐 Markdown | 이럴 땐 HTML |
|---|---|
| 버전 관리(git diff)·코드 주석·README | 여러 안을 나란히 비교·시각 대시보드 |
| 사람이 자주 직접 손대는 살아있는 문서 | 동료에게 링크로 공유할 리포트·스펙 |
| 짧고 단순한 답변·메모 | 슬라이더·토글이 필요한 양방향 탐색 |
| 토큰·비용에 민감한 대량 출력 | 100줄 넘는 풍부한 설명·학습 자료 |
이 개념을 실제 일에 녹이려면 어떻게 해야 할까요? 코어닷이 제안하는 실천법입니다.
새 라이브러리나 사내 시스템을 파악할 때, 긴 Markdown 대신 단일 HTML 설명서를 요청하세요.
기획·디자인 단계에서 하나의 정답을 받지 마세요. 여러 안을 한 화면에 펼쳐 비교 속도를 높이는 게 핵심입니다.
애니메이션·차트·파라미터 튜닝은 읽기 전용 결과로 받지 말고, 조정 가능한 인터페이스로 받으세요. 그래야 사람의 감각이 결과에 반영됩니다.
마지막으로 한 발 물러서서 보겠습니다. 저자는 글 끝에서, HTML을 쓰는 진짜 이유를 의외의 곳에서 찾습니다.
"내가 Markdown 대신 HTML을 쓰는 진짜 이유는, 그것이 나를 Claude와 함께 '루프 안에(in the loop)' 있게 해주기 때문이다."
여기에 이 논쟁의 본질이 있습니다. AI가 점점 더 많은 일을 대신할수록, 위험한 미래는 사람이 결과만 받아드는 시나리오입니다. 텍스트 덩어리를 그냥 수락/거절하는 관계 말이죠. 인터랙티브한 HTML은 사람을 다시 운전석에 앉힙니다. 직접 만져보고, 비교하고, 조정한 값을 되돌려주며 함께 만드는 관계로요.
이건 사실 더 넓은 흐름의 한 조각입니다. AI가 화면(UI) 자체를 그때그때 생성하는 제너레이티브 UI(generative UI), 단일 파일로 살아 움직이는 아티팩트(artifacts), 그리고 "사람과 AI의 인터페이스를 어떻게 설계할 것인가"라는 질문. HTML 논쟁은 그 큰 질문이 가장 구체적이고 실용적인 형태로 터져 나온 사건입니다.
그리고 그 답이 완전히 새로운 무언가가 아니라, 30년간 우리가 써온 가장 오래되고 보편적인 웹 기술이라는 점 — 그게 이 이야기에서 가장 "비합리적인" 부분일지도 모릅니다.
에이전트가 강력해지면서 AI의 출력은 100줄을 우습게 넘기게 됐고, Markdown은 그 풍부함을 담기엔 좁아졌다. LLM이 모국어처럼 잘 만들고(웹으로 학습) · 아무것도 설치할 필요 없이 실행되며(단일 파일) · 어디서나 열리는(브라우저) HTML은, 정보 밀도·가독성·공유성·양방향성에서 압도한다. 단, 공동 편집·토큰 비용·보안이라는 대가가 있으니 "무조건 HTML"이 아니라 "제 자리에 맞는 포맷"으로. 핵심은 결과만 받지 말고 'AI와 같은 루프 안에' 머무는 것.
오늘 당장 해볼 수 있는 가장 작은 실험: 다음에 Claude에게 무언가 설명을 부탁할 때, 끝에 한 마디만 붙여보세요 — "이걸 인터랙티브한 단일 HTML 파일로 만들어줘."
