AI가 작성한 글이 너무 길어서 제대로 읽지도 않아요 😅
"월 15,000엄 이상 내고 Claude Code를 사용하는데, 제대로 효과를 보고 있다는 느낌이 안 들어요."
많은 사람들이 AI를 사용한다는 사실 자체에 만족하지만, 실제로 성과로 연결시키는 사람은 극소수에 불과합니다. 마치 "사용한 것 같은 느낌"에 그치는 상태죠.
Claude Code를 사용하면서 이런 경험을 해보셨나요?
- 월요일 아침에 "지난주 경쟁사 트렌드를 요약해줘"라고 요청했더니 긴 보고서가 나왔다. 대충 훑어보고 읽지 않은 채로 방치한다.
- AI가 생성한 자료를 내가 제대로 읽지 않는다면, 팀원들도 읽지 않을 거라는 생각이 든다.
- Claude Code에 월 3,000엔 이상을 지불하지만, 그 결과물이 회의나 제안서에 사용된 적이 없다.
- ChatGPT와 Claude.ai의 결과물은 예쁜데, 왜 Claude Code는 Markdown만 출력해서 읽기 너무 피곤할까?
이 글은 바로 그런 분들을 위한 것입니다.
이 글을 다 읽고 나면, 여러분과 다른 사람들이 실제로 읽게 되는 자료를 Claude Code로 자연스럽게 생성할 수 있게 됩니다.
또한 "Claude Code에 무엇을 요청하느냐"보다 "어떤 형식으로 출력하느냐"가 사용자 판단에 훨씬 더 큰 영향을 미친다는 관점을 얻게 될 것입니다.
Claude Code를 실제로 개발한 Anthropic의 개발자 Thariq Shihipar (@trq212) 님이 회사 내에서 퍼지고 있는 마인드셋에 대해 X에 글을 올렸고, 이는 Claude Code 커뮤니티에서 가장 많이 저장되고 공유된 게시물 중 하나가 되었습니다.
공개되자마자 엄청난 반응을 얻었습니다.
이것은 단순히 AI 괴짜들을 위한 사소한 팁이 아닙니다. AI 업계의 암묵적인 표준이었던 Markdown에 대해 "더 이상 그 방식은 아니다"라고 도전장을 내민 도구 제작자本人的 이야기이기 때문입니다.
이 내용이 중요하다고 생각해서, 일본어로 즉시 설명하기로 결정했습니다.
읽기 전에 두 가지를 먼저 해주세요:
- 북마크하세요. 이번 주에만이라도 시간을 내서 HTML로 출력해보세요.
- Claude Code를 사용하는 팀원이 있다면 이 글을 공유해주세요. 주간 보고서와 PR 리뷰가 "읽히는" 방식이 다음 주부터 눈에 띄게 달라질 것입니다.
일본 비즈니스 현장에서 어떻게 작동하는지 번역하면서 내용을 분석하고 설명하겠습니다 👇
원본 게시물:
https://x.com/trq212/status/2052809885763747935
Anthropic 개발자 본인도 더 이상 Markdown을 사용하지 않는다
이것이 출발점입니다. 원본 게시물을 작성한 Thariq Shihipar (@trq212) 님은 Anthropic에서 Claude Code를 구축하는 개발자입니다. "계획 모드"에서 Claude가 요구 사항을 구체화하기 위해 사용자에게 질문하는 동작은 그가 직접 구현한 기능입니다.
그는 자신이 만들고 있는 도구에서 Markdown을 더 이상 받아들이지 않는다고 말합니다. 그의 말에 따르면, Markdown은 그에게 제한적인 형식이 되었습니다.
이것은 단순한 개인적 취향이 아닙니다. Thariq 님은 Claude Code 팀 내에서도 HTML 채택이 확산되고 있다고 언급합니다. 도구를 만드는 사람들이 도구가 생성하는 Markdown을 버리고 HTML로 전환하고 있는 것입니다.
그리고 그 증거는 직접 확인할 수 있습니다. 데모 사이트 https://thariqs.github.io/html-effectiveness/https://thariqs.github.io/html-effectiveness/)에는 20개의 자체 포함 HTML 예제가 있습니다. 디바운스 검색에 대한 세 가지 접근 방식 비교, 작업 완료에 대한 성취감을 주는 마이크로 인터랙션, 디자인 시스템 토큰 목록, 코드 예제에 대한 탭 설명, 여백에 용어집이 있는 읽기 자료 등이 있습니다. 이 모든 것은 "그냥 훑어보는 문서"를 "끝까지 읽히는 문서"로 대체한 실제 사례입니다. 지금 바로 브라우저에서 열어볼 수 있습니다.
이것을 읽으면 한 가지 깨달음을 얻게 될 것입니다. ChatGPT나 Claude.ai에서 평소에 받는 Artifacts—"탭이 있는 UI", "색상이 있는 다이어그램", "인터랙티브 버튼"—은 실제로 HTML로 출력됩니다. 여기서 깨달아야 할 점은: "그것들이 그렇게 예뻐 보였던 이유는 형식 자체의 차이였다"는 것입니다. 이제 그 동일한 세계를 Claude Code에서도 손쉽게 사용할 수 있습니다.
지금까지 AI가 생성한 텍스트는 거의 전적으로 Markdown이었습니다. 도구를 만드는 사람이 조용히 "더 이상은 아니다"라고 반박하기 시작했습니다. 이것이 이 소식의 핵심입니다. 하지만 AI를 매일 사용하는 여러분에게는 월요일 아침부터 효과를 볼 수 있는 이야기입니다.
Markdown은 AI 업계의 암묵적인 표준이었다
당연하게 여겨졌던 전제를 확인해 봅시다. 이것 없이는 HTML로의 전환이 단순히 취향의 문제처럼 보일 수 있습니다.
지금까지 Markdown은 AI 출력의 사실상 표준이었습니다. 매일 보는 텍스트를 떠올려 보세요:
- 프로젝트 루트의 CLAUDE.md, 에이전트 정의용 *.md, Skills용 SKILL.md.
- Anthropic의 공식 문서, Claude.ai 도움말, 다양한 Claude Code 가이드.
- 경쟁 AI 개발 도구, Cursor 규칙, GitHub Copilot 지침, Cline 지침은 모두 .md 기반입니다.
- 내부 Wiki, GitHub README, Notion에서 내보낸 텍스트, Slack에 붙여넣은 회의록.
- ChatGPT 채팅에서 복사한 요약 텍스트.
모든 것이 Markdown을 전제로 구축되었습니다. AI를 다룰 때 접하는 텍스트 정보에서 Markdown 이외의 형식을 찾기가 더 어려울 정도입니다.
Karpathy의 CLAUDE.md 패턴이 GitHub에서 80,000개 이상의 스타를 받은 현상은 바로 Markdown이 업계의 공용어였기 때문에 발생했습니다.
Thariq의 말을 빌리자면, Markdown은 에이전트의 주류 형식이 되었습니다. 그는 오랫동안 Markdown을 전제로 도구를 구축해온 사람입니다.
그 사람이 이제 분명히 말했습니다: Markdown은 나에게 제한적인 형식이 되었다. 이것은 업계 전체가 타고 온 전제에 Anthropic 내부자가 돌을 던진 순간입니다.
쉽게 말하면: Claude Code에서 얻는 Markdown, Cursor가 읽는 규칙, 내부 Wiki의 AI 출력은 모두 동일한 "Markdown이면 괜찮다"는 흐름 안에 있었습니다. 그것을 만든 사람이 다른 채널을 그리기 시작한 것입니다.
여기서부터는 Markdown이 왜 사람들에게 읽히지 않는지, 그리고 무엇으로 대체할지에 대한 구체적인 내용을 다루겠습니다.
Markdown이 읽히지 않는 5가지 이유
Markdown의 한계를 정리해 봅시다. 이것은 기술 사양에 관한 것이 아니라 월요일부터 금요일까지의 일상적인 경험에 관한 것입니다. 원본 글에서 HTML의 장점을 나열한 것을 뒤집어 Markdown의 약점으로 제시했습니다.
① 100줄이 넘으면 당신조차 읽지 않는다
Thariq 본인도 Markdown 파일이 100줄을 넘으면 읽기를 중단한다고 썼습니다.
Claude Code에 "지난주 경쟁사 트렌드를 요약해줘"라고 요청했을 때, 120줄짜리 응답을 스크롤하지 않고 닫아버린 경험이 있을 것입니다. 생성한 사람이 읽지 않으면 팀원 중 누구도 읽지 않습니다. 작성자뿐만 아니라 조직의 다른 구성원들도 그냥 대충 훑어보고 있다는 것이 현실입니다.
② 공유해도 브라우저에서 예쁘게 열리지 않아 아무도 건드리지 않는다
Markdown은 브라우저에서 기본적으로 아름답게 렌더링되지 않습니다. Slack에서는 줄바꿈이 깨지고, 이메일에서는 서식이 망가지며, PDF로 변환하거나 제안서용 스크린샷을 찍는 데 수고가 필요합니다.
공유할 때마다 누군가가 "읽을 수 있는 형태"로 변환하는 작업을 해야 합니다. Markdown은 공유할 때마다 마찰을 일으켜 링크조차 클릭되지 않는 경우가 많을 정도인 형식입니다.
③ 색상이나 다이어그램이 없어 개요만 전달된다
숫자의 차이를 강조하거나, 경고를 빨간색으로 표시하거나, 화살표로 흐름을 보여주고 싶을 때가 있습니다. Markdown에서 이렇게 하려면 ASCII 문자로 다이어그램을 그리거나 유니코드 상자 그리기 문자로 색상을 표현해야 합니다.
아무도 그것을 해독하고 싶어하지 않으며, 작성자도 피곤해집니다. Claude가 열심히 다이어그램을 그리려고 해도 결국 대충 훑어보고 넘어가게 됩니다.
④ 만지거나 움직일 수 없어 읽는 것으로 끝난다
약간 더 차분한 색상을 시험해보거나, 애니메이션 속도를 테스트하거나, 값을 1.5배로 늘리면 어떻게 보일지 확인하고 싶을 때가 있습니다.
비즈니스에서는 "직접 시험해보고" 판단해야 하는 상황이 자주 발생합니다. Markdown으로는 그럴 수 없습니다. 읽고, 머릿속으로 시뮬레이션하고, 다시 텍스트로 지시를 보내는 비효율적인 루프가 반복됩니다.
⑤ 모바일에서 열면 깨진다
이동 중 Slack, 이메일, Notion 등. 일본 비즈니스 현장에서는 공유된 자료의 절반이 모바일에서 처음 열립니다.
Markdown 레이아웃은 화면 너비를 따르지 않습니다. 표는 가로로 넘치고, 코드 블록은 어색하게 줄바꿈되며, 제목 계층 구조는 보이지 않게 됩니다. 그 순간 읽고 싶은 마음이 사라집니다.
이것에 이름을 붙여 봅시다. 읽히지 않는 Markdown을 생성할 때마다 발신자와 수신자 모두에게 열기 전부터 피로가 쌓입니다. 100줄을 스크롤하는 비용, Slack에서 줄바꿈을 수정하는 비용, 다이어그램과 색상 부족으로 인한 전달 실패, 인터랙션이 불가능해 발생하는 판단 지연, 모바일에서의 깨짐 현상.
이 모든 것은 매일 지불하는 숨은 비용입니다. 이 글에서는 이것을 "포맷 세금(Format Tax)"이라고 부릅니다.
이것은 작은 세금이 아닙니다. Claude Code 가치의 절반 이상은 출력 내용이 아니라 "누구에게, 얼마나 전달되느냐"에 의해 결정됩니다. 사람들에게 전달되지 않는 형식으로 출력함으로써, 여러분은 구독료의 절반을 사실상 버리고 있는 것입니다.
전환 방법: "HTML 파일로 출력해줘" 한 줄만 추가하면 된다
지나치게 복잡하게 생각할 필요 없습니다. 생각보다 훨씬 간단합니다.
평소 Claude Code에 요청할 때 마지막에 한 줄만 추가하면 됩니다. 다음 세 가지는 모두 같은 의미입니다:
- "HTML 파일로 출력해줘"
- "단일 페이지 HTML로 출력해줘"
- "독자가 직접 열어볼 수 있도록 HTML로 만들어줘"
영어로 작성하는 것이 더 편하다면 "make a HTML file" 또는 "make a HTML artifact"라고 해도 됩니다. 결과는 동일합니다.
Claude Code는 MCP, 브라우저, git, 파일 시스템에서 컨텍스트를 가져올 수 있습니다. Claude Code의 강점은 ChatGPT나 Claude.ai의 웹 채팅 버전보다 훨씬 광범위한 정보 소스를 단일 HTML로 번들링할 수 있다는 점입니다.
이것은 앞서 논의한 내용과 연결됩니다. ChatGPT나 Claude.ai에서 받아 "예쁘다"고 생각했던 Artifacts는 HTML로 출력된 것이었습니다.
이제 Claude Code 쪽에서도 동일한 세계를 받을 수 있습니다. 어려운 기술 이야기가 아니라, 요청 방식 한 줄만 바꾸면 실제로 사람들에게 전달되는 자료가 나옵니다.
Thariq는 자신의 글에서 한 가지 점을 강조합니다: "이것을 아직 /html Skill로 만들지 않았으면 좋겠다. 사람들이 먼저 프롬프트를 통해 익숙해지길 바란다." Skills를 만드는 Claude Code 팀 개발자임에도 불구하고 말입니다.
그는 Skill로 만드는 것을 무시하는 것이 아닙니다. 그는 "사용법이 정착되기 전에 패키징하면 진정으로 효과적인 부분을 놓치게 된다"고 말하는 것입니다.
Anthropic 내부에서는 빈번해진 HTML 출력이 Playground 플러그인 같은 것으로 컴포넌트화되기 시작했습니다. 처음부터 완성된 제품을 기다리지 말고, 먼저 한 줄 프롬프트로 시도해보면서 자신의 업무에 맞는 패턴을 찾으세요. 그 지점에 도달한 후에 Skill로 만드는 것을 고려하세요.
모든 프롬프트에 "HTML로 출력해줘"라고 쓰는 것이 번거로워 보일 수 있지만, 형식 자체를 선택하는 것은 작업이 아닙니다. Claude가 Markdown을 출력하는 순간에서 Claude가 HTML을 출력하는 순간으로 전환하는 순간, 여러분은 "미리 디자인된 Skill을 기다리기보다 출력을 먼저 디자인하는" 사람으로 한 걸음 나아간 것입니다.
HTML로 전환만으로 달라지는 5가지 비즈니스 시나리오
이 장은 월요일부터 금요일까지 실제 업무에 효과적입니다. 원본 글의 다섯 가지 사용 사례를 일본 비즈니스 현장에서의 빈도 순서로 재정렬했습니다: 주간 보고서/리서치 요약, 제안서 병렬 비교, 디자인 조정, 의사 결정 편집 화면, PR/사양 리뷰.
각 시나리오는 현재 문제점, Before/After, 마지막으로 Claude Code에 제공할 샘플 지시문으로 요약됩니다.
[시나리오 1] 다이어그램이 포함된 주간 보고서 및 리서치 요약 전달
일본 비즈니스에서 흔히 발생하는 상황입니다. 월요일 아침, 상사가 "지난주 트렌드를 요약해줘"라고 요청합니다.
Before: 120줄의 Markdown을 Slack에 붙여넣습니다. 줄바꿈이 깨집니다. 상사는 열어보지 않습니다. 경영진 회의 자료에 포함되지 않습니다. 결국 "Claude가 한 건데요"라고 말로 설명하게 됩니다.
After: Slack 로그, Linear 또는 Notion 티켓 기록, git 로그, 내부 문서를 통합한 단일 HTML 페이지로 요약합니다. SVG를 사용한 간단한 비즈니스 흐름 다이어그램을 포함하고, 하단에 세 가지 핵심 포인트를 색상 블록으로 배치합니다.
이것을 내부 스토리지에 올리고 URL을 공유하면, 상사는 출근길에 모바일로 열어볼 수 있고, 경영진은 인용할 수 있으며, 회의록에 붙여넣을 수 있습니다.
여기서 핵심은 Claude Code가 MCP, 브라우저, git, 파일 시스템에서 컨텍스트를 가져올 수 있다는 점입니다. 웹 채팅에 "HTML을 만들어줘"라고 요청해도 이렇게 많은 정보 소스를 하나로 번들링하기는 어렵습니다. 이것은 Claude Code만이 만들 수 있는 주간 보고서입니다.
Thariq 본인도 자신의 기사용 다이어그램을 Claude Code가 코드 폴더의 모든 HTML을 읽고 한 페이지로 요약하게 해서 만들었다고 썼습니다. "읽히는 주간 보고서"와 "읽히는 설명 기사용 다이어그램"은 구조적으로 동일합니다.
▼ 샘플 지시문:
"지난주 모든 Slack 상호작용, Linear 티켓 완료, git 로그를 읽고, 상사가 1분 안에 파악할 수 있는 주간 보고서를 단일 HTML 페이지로 출력해줘. SVG로 간단한 비즈니스 흐름 다이어그램을 포함하고, 하단에 세 가지 핵심 포인트를 색상 블록으로 배치해줘. 스마트폰에서 열어도 깨지지 않도록 해줘."
[시나리오 2] 6가지 제안/리서치 옵션을 나란히 보여주기
다음 주 제안은 어떤 방향으로 가야 할까? 기획, 영업, 기획실에서 여러 옵션을 만들고 의사 결정자와 조율하는 흔한 상황입니다.
Before: 6가지 옵션을 6개의 개별 Markdown 파일로 보냅니다. 클라이언트는 하나씩 열어서 비교할 수 없습니다. "추천하는 것은 어느 것인가요?"라고 물어보고, 자신도 제대로 비교하지 않았다는 것을 깨닫게 됩니다.
After: 톤, 밀도, 타겟 대상이 다른 6가지 옵션을 단일 HTML 페이지의 그리드에 배열합니다. 각 옵션 아래에 한 줄짜리 트레이드오프를 추가합니다. 의사 결정자는 한 화면에서 모두 비교하고 즉시 "이것과 이것을 섞고 싶다" 또는 "#3의 타겟에 #1의 밀도를 적용하자"고 응답합니다. 병렬로 보여주는 순간 논의의 해결 속도가 달라집니다.
의사 결정자에게 6개의 파일을 받는 것과 6개의 옵션이 한 화면에 나란히 있는 것은 판단에 걸리는 시간이 천지 차이입니다. "읽게 하는 것"보다 "결정할 수 있게 하는 것"에 더 가깝습니다.
▼ 샘플 지시문:
"다음 주 프레젠테이션을 위한 6가지 제안 옵션을 톤, 밀도, 타겟 대상이 다르게 만들어서 단일 HTML 페이지의 그리드에 배열해줘. 각 옵션 아래에 한 줄짜리 트레이드오프를 작성해줘. 또한 결정이 내려지면 결과를 Markdown으로 복사할 수 있는 버튼을 하단에 추가해줘."
[시나리오 3] 디자인과 프로토타입을 직접 만져보며 결정하기
색상, 크기, 움직임을 결정할 때는 텍스트로 조율하는 것을 포기해야 합니다. 마케팅, 홍보, 기획 부서가 감사 이메일이나 랜딩 페이지 버튼을 두고 여러 번 왕복하는 상황입니다.
Before: "약간 더 차분한 파란색" 또는 "움직임을 부드럽게" 같은 말로 소통합니다. 받는 사람의 이미지는 매번 달라집니다. 한 차례 왕복 후 돌아온 버전을 보고 다시 말을 추가합니다: "아니, 그런 차분함이 아니라."
After: Claude Code가 색상과 애니메이션 속도를 조절할 수 있는 슬라이더가 있는 HTML을 만들게 합니다. 감사 이메일 버튼이나 LP CTA 버튼용 프로토타입을 단일 HTML 페이지로 만들어 URL을 이해관계자에게 보냅니다. 모두가 직접 만져보고 최적의 값을 결정한 후, 그 값을 Claude에 다시 복사합니다. 텍스트 왕복이 줄어들고 합의 시간이 단축됩니다.
이와 관련하여 Anthropic Labs는 이 "만져서 결정하고 조작 내용을 Claude에 다시 복사하는" 개념을 Playground 플러그인으로 공식화하기 시작했습니다. HTML 출력은 단순한 작은 트릭이 아니라 Anthropic 자체가 패턴으로 육성하고 있는 방향입니다.
▼ 샘플 지시문:
"감사 이메일의 버튼 색상과 애니메이션 속도를 세 가지 유형의 슬라이더로 결정할 수 있는 HTML을 만들어줘. 결정된 값을 복사할 수 있는 버튼을 하단에 추가해줘."
[시나리오 4] 3분 만에 의사 결정 화면 만들기
다음 분기에 어떤 대책을 Now, Next, Later, Cut에 할당할까? 30개의 티켓을 정렬하여 우선순위를 결정하는 것은 PdM, 기획자, 기획실에게 전형적인 "판단 작업"입니다.
Before: 30개 항목을 스프레드시트에 나열하고 우선순위 열을 하나씩 수동으로 채웁니다. 정렬하고, 다시 생각하고, 다른 시트로 옮기고, 다시 되돌립니다. 어떤 날은 30분을 써도 결론이 나지 않습니다.
After: Claude Code에 "Now, Next, Later, Cut의 네 개 열로 항목을 드래그 앤 드롭할 수 있는 HTML을 만들어줘"라고 요청합니다. 3분 만에 전용 편집 화면이 준비됩니다. 30개의 카드를 드래그하고, 완료되면 결과를 복사합니다. 판단 작업 시간이 한 자릿수로 줄어듭니다.
여기에는 간과하기 쉽지만 매우 효과적인 디자인 원칙이 있습니다. Thariq가 "항상 내보내기로 끝내라"고 쓴 문장입니다. 편집 화면을 만들 때는 항상 "JSON으로 복사", "프롬프트로 복사", "Markdown으로 복사" 버튼을 포함하세요.
이것이 없으면 정렬 결과를 Claude에 반환할 수 없어 단순한 작업 도구로 끝납니다. 편집 화면은 HTML에서 판단한 후 구조화된 텍스트 결과를 Claude에 반환하는 루프를 만들 때 비로소 판단 장치가 됩니다.
이 동일한 아이디어는 기능 플래그 편집, 병렬 시스템 프롬프트 편집기, 데이터셋 승인/거부/태깅에도 사용할 수 있습니다. "3분 만에 전용 일회용 UI를 만드는 것"이야말로 Claude Code의 진정한 가치가 가장 분명하게 드러나는 부분입니다.
▼ 샘플 지시문:
"다음 분기의 30개 대책을 Now, Next, Later, Cut의 네 개 열로 드래그 앤 드롭할 수 있는 HTML을 만들어줘. 마지막에 정렬 결과를 각 항목별 이유와 함께 출력할 수 있도록 'Markdown으로 복사' 버튼을 배치해줘."
[시나리오 5] 색상 코드로 차이점을 표시한 PR 리뷰 및 사양 공유 넘겨주기
마지막으로 엔지니어와 협업하는 시나리오입니다. 코드를 읽지 못하더라도 PdM, 디렉터, 편집자로서 PR 리뷰나 사양 확인에 참여해야 할 때가 있습니다.
Before: GitHub diff 화면을 열어보라는 요청을 받습니다. diff의 어느 부분이 중요하고 어느 부분을 무시해도 되는지 보기만으로는 알 수 없습니다. 스토리를 따라가려면 댓글을 읽어야 합니다. 코드를 읽지 못하는 사람들은 대부분 "문제 있으면 알려줘"라고 말하고 닫아버립니다.
After: Claude Code에 "이 PR을 코드를 읽지 못하는 사람도 30초 안에 파악할 수 있는 HTML 리뷰 문서로 만들어줘"라고 요청합니다. diff 옆에 댓글이 첨부되고, 영향 범위가 색상으로 구분되며, 마지막에 세 가지 우려 사항이 요약됩니다. 이것을 내부 스토리지에 업로드하고 URL을 공유하면 PdM과 디렉터가 한 번의 버튼으로 피드백을 제공할 수 있습니다. 엔지니어와 협업하는 사람들이 마침내 리뷰에 참여할 수 있게 됩니다.
HTML은 엔지니어를 위한 언어가 아니라 스토리를 전달하기 위한 도구입니다. diff의 의미, 위험, 영향 범위—이 "해독이 필요한 정보"가 주석, 색상, 레이아웃과 함께 전달됩니다. 이것이 HTML 변환의 의미입니다.
▼ 샘플 지시문:
"이 PR을 코드를 읽지 못하는 사람도 30초 안에 파악할 수 있는 HTML 리뷰 문서로 만들어줘. diff 옆에 댓글을 첨부하고, 영향 범위를 색상 코딩으로 표시하며, 마지막에 세 가지 우려 사항을 요약해줘."
이 다섯 가지 시나리오에서 계속 Markdown으로 출력하는 동안, 포맷 세금은 조용히 그러나 매일 누적됩니다. 알아차린 순간 멈추느냐 마느냐가 다음 주부터의 차이가 될 것입니다.
전환할 때 생기는 6가지 질문
이 글을 읽으면 몇 가지 질문이 떠오를 것입니다. 원본 글의 FAQ 섹션을 일본 비즈니스 독자들이 접할 법한 순서로 재정렬했습니다.
■ 토큰을 더 많이 사용하나요?
네, 그렇습니다. 원본 글에 따르면 Markdown보다 생성 시간이 2-4배 더 걸립니다. 그러나 Opus 4.7은 100만 토큰 컨텍스트를 가지고 있어 HTML을 반환함으로 인해 컨텍스트 제한으로 대화가 끊길 위험은 사실상 사라졌습니다.
Thariq의 결론은: "숫자는 늘어나지만, 읽히는 결과물을 선택한다면 전체 작업에 대해 이익이 된다"는 것입니다. 월 3,000엔 이상의 계약을 1,000줄의 읽히지 않는 Markdown에 사용할지, 열어보게 되는 HTML 한 페이지에 사용할지 선택하는 문제입니다.
■ 디자인이 예쁘지 않으면 어쩌죠?
타당한 우려이지만, 대책이 있습니다.
하나는 Claude Code의 프론트엔드 디자인 플러그인을 사용하는 것입니다. 또 다른 방법은 Claude에 회사 사이트나 기존 자료의 샘플 HTML을 제공하는 것입니다. 참조 파일을 제공하고 "이런 톤으로" 또는 "이 폰트와 팔레트로"라고 말하면 Claude가 회사 스타일에 맞는 HTML을 출력합니다. 코드베이스에 design-system.html 같은 파일을 보관해두면 매번 참조할 수 있습니다.
■ HTML 편집이 번거롭지 않나요?
직접 편집할 필요가 없습니다.
Thariq 본인도 HTML을 직접 건드리지 않는다고 씁니다. "이 색상을 약간 차분하게 해줘" 또는 "세 번째 섹션을 약간 작게 해줘"라고 Claude에 말하면 수정해줍니다. 사양, 브레인스토밍, 참고 자료용으로 사용하는 한 모든 편집은 Claude에 맡길 수 있습니다.
■ 어떻게 열고 공유하나요?
열기는 쉽습니다. Claude Code가 생성한 HTML 파일을 로컬에서 브라우저로 열기만 하면 됩니다.
Claude에 "이 파일을 열어줘"라고 요청하면 브라우저에서 열어줄 수도 있습니다. 공유할 때는 내부 스토리지나 S3에 업로드하고 URL을 제공하는 것이 가장 쉽습니다. Slack이나 이메일에 링크를 붙여넣으면 수신자가 브라우저에서 열어볼 수 있습니다. Markdown을 PDF로 변환하는 추가 단계가 완전히 사라집니다.
■ 버전 관리는 어떻게 하나요?
솔직히 말하면 HTML은 Git diff 관리에 매우 적합하지 않습니다. 한 줄을 수정하면 포맷터 설정으로 인해 diff가 다른 곳으로 이동할 수 있습니다. Thariq 본인도 HTML이 버전 관리의 가장 큰 약점이라고 씁니다.
그래서 실용적인 해결책은: "사람을 위한 전달물"은 HTML, "이력을 남기고 싶은 사양이나 기록"은 Markdown입니다. Markdown을 폐지하는 것이 아니라 출력 목적에 따라 형식을 선택하는 마인드셋으로 전환하는 것입니다.
■ Markdown을 완전히 사용하지 않아도 되나요?
아니요. 기록, 변경 이력, 리포지토리에 보관하고 싶은 구조화된 텍스트는 Markdown으로 유지해야 합니다.
CLAUDE.md와 SKILL.md는 Markdown으로 유지하는 것이 관리와 diff 추적에 더 쉽습니다. HTML은 "사람에게 전달", "사람이 만져보게 함", "여러 옵션을 나란히 보여줌", "색상으로 판단하게 함"에 적합합니다. "AI와 상호작용할 때는 Markdown, 사람에게 배포할 때는 HTML"이라고 크게 이해하면 헷갈리지 않을 것입니다.
이제 초기의 의문은 해소되었을 것입니다. 단점까지 포함된 기사가 더 신뢰할 만하다는 것이 저의 작가로서의 신념입니다.
포맷 세금을 계속 낼 것인가, 디자인 측면으로 이동할 것인가
마지막으로 시야를 넓혀 마무리하겠습니다.
우리는 이전에 'Prompt Tax'에 대해 논의했습니다—같은 전제를 Claude에 다시 입력하는 비용 말이죠. 그다음, .claude 폴더를 사용한 디자인 레이어로의 전환 이야기. 이 'Format Tax'는 그 시리즈의 세 번째 주제입니다. 대화 레이어와 디자인 레이어 이후, 이제 출력 레이어를 다루게 되었습니다.
'Format Tax'를 독자들과 공유할 수 있는 개념으로 정의해 보겠습니다:
읽히지 않는 출력 포맷을 계속 선택하면, 열기도 전에 당신과 다른 사람 모두에게 피로가 쌓입니다. Claude Code에 한 달에 3,000엔 이상을 지불하면서도 결과물이 회의에서 사용되지 않습니다. 그 느낌은 포맷 선택에 대한 판단을 하지 않았기 때문에 오는 것입니다. 이것이 Format Tax입니다.
Markdown으로 출력하는 것은 작업(task)입니다. HTML을 선택하는 것은 판단(judgment)입니다. 동일한 Claude Code를 사용하더라도, 포맷 선택이라는 하나의 판단이 결과물이 도달하는 거리를 크게 바꿉니다.
그리고 HTML은 엔지니어만을 위한 언어가 아닙니다. 읽히는 자료를 만드는 도구입니다. 웹사이트를 만든다는 생각은 잠시 접어두세요. 이번 주에 작성 중인 주간 보고서나 제안서, 검토 문서를 HTML로 출력해보세요. 그걸로 충분합니다.
더 큰 그림을 이야기해봅시다.
Markdown이 AI 업계의 암묵적 표준이었던 시대는 Anthropic 내부에서 조용히 끝나가고 있습니다. CLAUDE.md, SKILL.md, Cursor 규칙 모두 Markdown 기반으로 구축되었지만, 출력 포맷이 먼저 전환되기 시작했습니다. 표준이 바뀌는 순간을 목격한 독자는 반 걸음 앞서 나갈 수 있습니다.
물론, "매주 이걸 하고 있구나"라고 깨닫고 나면, 그걸 Skill로 발전시킬 수도 있습니다.
Anthropic 내부에서는 디자인 관련 Playgrounds와 같이 HTML 출력 빈도가 높은 패턴이 점차 컴포넌트로 육성되고 있습니다. 하지만 첫 주에는 한 줄 프롬프트면 충분합니다. 오늘 밤, 주간 보고서 하나만 HTML로 출력해보세요. 다음 주에는 6개의 제안 옵션을 하나의 그리드에 나열해보세요. 거기서 시작하면 Format Tax는 조용히 줄어들기 시작할 것입니다.
Thariq 자신은 기사 말미에 이렇게 썼습니다: "Markdown의 심층 독서를 중단하고 판단을 전적으로 Claude에 맡기는 것에 대한 두려움이 있었습니다. HTML로 전환한 후에는 Claude와 다시 순환에 참여하는 느낌이 들었고, 무엇보다도 만드는 것이 단순히 재미있습니다."
포맷을 선택하는 것은 AI와 작업할 때 주도권을 되찾는 스위치이며, 동시에 일상 업무에 약간의 열기를 되돌리는 스위치입니다.
읽히지 않는 Markdown을 계속 생산할 것인가요, 아니면 포맷을 선택하는 쪽으로 이동할 것인가요? 다음 주가 그 경계가 될 것입니다.
요약
- Anthropic에서 Claude Code를 개발하는 개발자가 더 이상 Markdown을 사용하지 않겠다고 선언했습니다. 내부 팀에서 HTML 도입이 확산되고 있습니다.
- 지금까지 Markdown은 AI의 암묵적 표준이었습니다—Claude Code, Cursor부터 GitHub Copilot, Cline, 내부 Wiki, ChatGPT 출력까지. 이제 그 창시자가 업계 표준에 도전했습니다.
- Markdown이 읽히지 않는 5가지 이유: 100줄이 넘으면 다시 읽기 어려움 / 공유 시 깨짐 / 색상이나 다이어그램 없음 / 만져서 판단할 수 없음 / 모바일에서 깨짐. 이러한 숨겨진 비용이 'Format Tax'입니다.
- 전환하려면 한 줄만 추가하세요: "HTML 파일로 출력하세요." Skill로 만드는 것은 사용이 확립될 때까지 기다려도 됩니다.
- 5가지 비즈니스 시나리오—주간 보고서, 병렬 제안, 디자인 수정, 판단 화면, PR 리뷰—가 HTML로 전환하기만 해도 열리고, 판단되고, 반환되는 자료로 변합니다.
- 포맷을 선택하는 것은 판단이지 작업이 아닙니다. Markdown으로 출력하는 것은 작업이고, HTML을 선택하는 것은 판단입니다. Claude Code 사용자 간의 차이가 여기서 벌어집니다.
이 글이 도움이 되셨다면:
도쿄대학 Claude Code Laboratory (@ClaudeCode_UT)는 도쿄대학 학생 팀이 진지하게 운영하는 계정입니다. 대기업과의 공동 Claude Code 비즈니스 개발도 진행 중이며, 현장에서 실제로 작동하는 디자인과 노하우만 공유하고 있습니다.
실무에 특화된 "진정으로 유용한" 정보와 노하우를 매일 전달합니다 👇
■ 실무에서 사용 가능한 Claude Code 스킬 무료 공개
■ 해외 주요 AI 정보를 일본 비즈니스 맥락에 맞게 번역 및 재구성
■ 도쿄대 팀이 진지하게 개발한 "진정으로 유용한" 스킬과 도구를 무료로 받을 수 있는 유일한 곳 ❗️
관심 있으시면 팔로우하고 확인해주세요.
LINE은 여기 ⇩
