AI가 긴 답을 줬는데, 끝까지 읽지 않습니다. 처음 세 줄만 보고 "대충 맞네" 하고 닫아요. 문제는 내용이 없어서가 아닙니다. 너무 평평해서예요. 제목, 목록, 굵은 글씨, 코드 블록. 전부 맞는데 어디부터 봐야 할지 몸이 먼저 포기합니다. HTML로 받으면 달라집니다. 중요한 숫자는 카드로 튀어나오고, 위험한 항목은 빨갛게 표시되고, 후보들은 나란히 놓입니다. 버튼을 누르면 정렬되고, 마지막에는 copy as markdown 으로 다시 문서에 붙일 수 있어요. 정보는 그대로인데 하나는 읽어야 하는 문서고, 하나는 판단할 수 있는 화면입니다. 차이는 "마크다운으로 정리해줘"와 "HTML로 만들어줘" 사이에 있었어요. 지금 AI 산출물에 일어나는 변화도 여기서 시작합니다. 개발자 세계에서는 이 차이가 더 선명합니다. Django 공동 창시자 Simon Willison은 보안 취약점 코드를 LLM에 넘기면서 "HTML로 설명해줘"를 붙였어요. 결과는 200줄짜리 텍스트가 아니라, 브라우저에서 바로 열리는 한 페이지짜리 해설서였습니다. 어두운 배경의 코드 블록, 노란 Safety note 박스, 숫자 카드로 펼쳐지는 단계별 설명까지 들어간 페이지였죠. Simon Willison이 LLM으로 만든 익스플로잇 해설 페이지. 출처: https://simonwillison.net/2026/May/8/unreasonable-effectiveness-of-html/ 비슷한 시점에 Anthropic Claude Code 팀의 Thariq Shihipar가 X에 'The Unreasonable Effectiveness of HTML'을 올렸어요. 게시물은 AI 코딩 도구 사용자들 사이에서 빠르게 공유됐습니다. 200줄짜리 plan.md 를 받고, 스크롤 한 번 하고, 닫고, 사흘 뒤에 같은 걸 또 물어보는 경험이 낯설지 않았기 때문이죠. AI는 일을 끝냈는데 결과물이 길고 빽빽한 텍스트라 읽히지 않았던 겁니다. 흩어져 있던 불편함을 누군가 문장으로 정리하자, 많은 사람이 고개를 끄덕인 셈이에요. Thariq Shihipar의 'The Unreasonable Effectiveness of HTML'. 출처: X(@trq212) 조회수가 높다고 주장이 곧바로 맞다는 뜻은 아닙니다. 다만 여러 곳에서 비슷한 결론이 나왔다는 점은 따로 볼 만해요. 마크다운이 기본값이었던 이유 포맷이 왜 바뀌는지 보려면, 먼저 마크다운이 오래 첫 선택지로 남아 있던 이유를 봐야 합니다. 한 번 굳어진 선택은 오래 가요. 이유가 약해져도 습관은 남거든요. 이사를 가도 옛 동네 카페만 찾아가는 사람처럼요. 마크다운이 딱 그랬어요. 토큰이 비쌌던 시절 GPT-4 초기 컨텍스트 윈도우는 8,192 토큰이었어요. <div class="card">...</div> 같은 HTML 태그는 같은 내용을 쓰더라도 마크다운보다 토큰을 더 많이 썼습니다. 그래서 짧고, 사람이 읽기 쉽고, 손으로 고칠 수 있는 마크다운이 자연스럽게 기본 출력 형식이 됐죠. 그 습관이 도구 안에 쌓였어요. Claude Code 설정은 CLAUDE.md , 작업 지시는 AGENTS.md , 스킬 정의는 SKILL.md . 프로젝트 폴더가 .md 로 도배됐고, AI 산출물까지 마크다운으로 나오기 시작했습니다. 산출물이 너무 길어졌습니다 컨텍스트 윈도우가 백만 토큰 규모로 커지면서, AI 답변도 10줄짜리 메모에서 천 줄짜리 구현 계획, 복잡한 플로우차트, 긴 코드 리뷰로 확장됐어요. 마크다운으로 받으면 제목과 목록이 이어진 긴 문서가 됩니다. 읽기 전에 지쳐요. 입력 규모와 산출물의 복잡도는 달라졌지만, 결과물을 담는 형식은 예전의 마크다운 관성에 묶여 있었죠. 안 읽히면 안 쓰이는 거다 문제는 예쁘냐가 아니라 실제로 읽히고 쓰이느냐입니다. 안 읽히는 산출물은 책장에 꽂힌 채 한 번도 펴지지 않는 책과 비슷해요. 내용이 있어도 실제 판단에는 쓰이지 않습니다. 마크다운이 못하는 것 마크다운이 잘하는 일은 제목, 목록, 강조, 코드 블록, 링크처럼 문서를 구조화하는 일입니다. 색, 배치, 상호작용은 마크다운 혼자서는 어렵죠. Claude Code가 마크다운 안에서 색을 보여주려다 유니코드 이모지로 색 박스를 그린 스크린샷이 있어요. 색을 보여줘야 하는데 색을 쓸 수 없으니, 결국 이모지 블록으로 색상표를 흉내 냅니다. 정보는 있는데 표현할 수단이 없을 때. 출처: Thariq Shihipar HTML에서는 같은 정보를 표로 정렬하고, 색으로 구분하고, 다이어그램으로 묶고, 클릭했을 때 반응하게 만들 수 있어요. 읽는 문서에서 조작하는 UI로 차이는 문서를 읽을 때보다 화면에서 직접 고칠 때 더 커집니다. 마크다운은 결과를 보여주지만, HTML은 입력칸, 드래그 앤 드롭, 미리보기, 내보내기를 갖춘 작업 화면이 돼요. 예를 들어 할 일 30개를 이번 주 / 다음 주 / 나중에 / 제외로 나눈다고 해볼게요. 마크다운이라면 네 목록을 오가며 복사하고 지워야 합니다. HTML이라면 브라우저에서 카드를 끌어 옮기면 끝나죠. 팀 설정도 마찬가지예요. 설정표를 읽는 대신 입력칸에서 값을 바꾸고, 충돌이 생기면 화면에서 바로 경고를 띄울 수 있습니다. 여기서 빠지면 안 되는 건 내보내기 버튼입니다. copy as JSON , copy as markdown 같은 버튼을 붙이면, 화면에서 정리한 결과를 회의록, 업무 목록, 다음 요청문으로 바로 옮길 수 있어요. 사람이 브라우저에서 정리하고, AI가 그 결과를 다음 입력으로 받습니다. 업무 카드를 브라우저에서 직접 분류하고, 끝나면 'copy as markdown'으로 결과를 뽑습니다. 출처: Thariq Shihipar 의사결정 문서도 같은 방식으로 바뀝니다. 후보 여섯 개를 긴 문단으로 늘어놓는 대신, 비용, 위험, 걸리는 시간, 되돌리기 쉬운 정도를 카드로 나란히 놓을 수 있어요. 독자는 긴 문단을 순서대로 읽지 않아도 됩니다. 한 화면에서 비교하고, 하나를 고르면 되죠. 같은 문제의 여섯 가지 접근을 카드로 비교합니다. 출처: Thariq Shihipar 개발자 예시로 가면 코드 변경 검토에서도 차이가 큽니다. 마크다운 리뷰는 파일명, 바뀐 코드, 코멘트가 위에서 아래로 이어져요. HTML 리뷰는 변경 전후를 나란히 보여주고, 위험한 변경은 빨간색으로 표시하고, 서로 관련된 부분끼리 링크로 묶을 수 있습니다. 바뀐 파일들이 서로 어떻게 연결되는지도 그림으로 보여줄 수 있고요. 코드 변경마다 HTML 설명 페이지를 붙이면, 리뷰어는 변경 이유와 위험 지점을 한 화면에서 확인할 수 있습니다. 코드 변경 화면 안에 메모, 심각도별 색 표시, 관련 위치로 이동하는 링크가 한 페이지에 들어갑니다. 출처: Thariq Shihipar 디자인을 정할 때도 마찬가지예요. 버튼 애니메이션의 속도와 색 변화를 슬라이더로 바꿔 보다가, 마음에 드는 값을 뽑아 최종 작업에 넘길 수 있습니다. 먼저 브라우저에서 만져보고, 확정된 값만 코드로 옮기면 되죠. AI 디자인 도구가 HTML 화면을 먼저 내놓는 이유도 여기 있어요. 기술 리포트도 단순한 설명문에서 벗어납니다. 예를 들어 "예약이 몰릴 때 요청을 어떻게 제한하는지 설명해달라"고 요청하면, 시간에 따라 빈자리가 차고 빠지는 흐름을 애니메이션으로 보여줄 수 있어요. 변경 전후 코드를 나란히 두고, 줄 위에 마우스를 올리면 주석을 띄울 수도 있습니다. 같은 내용을 마크다운으로 받으면 긴 설명 문서가 됩니다. HTML로 받으면 동작을 보면서 확인하는 화면이 되죠. 그래서 차이는 "보기 좋다"가 아닙니다. HTML로 만들면 AI가 준 결과를 읽는 데서 끝내지 않고, 그 자리에서 비교하고 고치고 다시 꺼내 쓸 수 있어요. 독자가 사람만은 아니다 HTML 파일을 만들었으면, 누가 읽을까요? 검증 단계에서는 사람만 보는 게 아니라 다른 AI에게도 같은 HTML 파일을 읽혀 오류를 찾게 합니다. 처음엔 평범하게 들리지만, 한 번 더 읽어볼 가치가 있어요. 사람이 프롬프트를 치고, AI 하나가 HTML을 만들고, 사람이 확인하고, 다른 AI가 같은 HTML을 다시 읽습니다. 산출물이 다음 작업자에게 입력으로 들어가는 거죠. 혼자 보던 메모가 이어받을 수 있는 공유 작업물이 된 셈이에요. 'HTML이냐 마크다운이냐' 논쟁이 어디서 엇나갔는지 여기서 보입니다. 포맷 싸움을 하는 동안 독자가 바뀐 거예요. 사람만 읽던 산출물을 이제 다른 AI도 읽습니다. HTML은 단순한 문서가 아니라 구조와 동작을 가진 입력이 될 수 있어요. 마크다운 최강 강점이 사라졌습니다 마크다운의 약점은 단순합니다. 파일이 길어지면 끝까지 읽기 어렵고, 실제로는 사람이 직접 고치지도 않는다는 거예요. 수정이 필요하면 다시 Claude에게 시키는 경우가 많아졌다는 겁니다. 마크다운 최고 강점은 "사람이 손으로 고칠 수 있다"였는데, AI 도구를 쓰는 환경에서는 그 강점이 약해진 거죠. 한쪽에서만 나온 얘기가 아니었습니다 한 사람의 글이었다면 바이럴로 끝났을 수도 있어요. 그런데 타이밍이 묘했습니다. 서로 다른 세 곳이 거의 동시에 HTML을 전면에 세웠어요. 분야도 동기도 달랐죠. HeyGen: "에이전트는 이미 HTML을 말한다" HeyGen은 AI 아바타 영상 회사예요. HyperFrames를 Apache 2.0으로 공개했습니다. HTML과 CSS로 영상 장면을 만들면 브라우저 엔진이 화면을 캡처해 MP4로 렌더링하는 원리예요. GitHub 스타는 5월 중순 기준 1만 개대 후반까지 올라왔습니다. GitHub 소개 문구가 직설적이에요. "Write HTML. Render video. Built for agents." 프레임워크 설계부터 AI가 직접 영상 장면을 작성하는 걸 전제로 깔았어요. 설계 설명에는 "agents already speak HTML"이 명시돼 있고, Claude Code, Cursor, Gemini CLI, Codex를 공식 지원합니다. AI에게 프레임워크 쓰는 법을 가르치는 "skills" 시스템까지 따로 제공해요. HeyGen 공동창업자·CEO Joshua Xu도 공개 자료에서 같은 이유를 들었어요. HTML+CSS는 웹의 기본 언어예요. React 코드는 그 위에 올라간 특정 개발 방식에 가깝고요. 관건은 사용자 친숙도가 아니라 모델이 얼마나 안정적으로 만들어내느냐입니다. AI에게 더 익숙한 쪽은 React 방식이 아니라 HTML이죠. Remotion: HTML을 영상 캔버스에 얹다 Remotion은 영상을 React 코드로 만드는 프레임워크예요. 메인 레포 GitHub 스타가 5월 중순 기준 4만7천 개대인 곳이죠. 5월 초에는 <HtmlInCanvas> 라는 기능을 추가했습니다. 이름 그대로 HTML을 영상 캔버스에 그대로 합성하는 기능이에요. 보통 SDK는 언어별로 라이브러리를 배포하잖아요. 자바스크립트용, 파이썬용. Remotion은 AI 도구별 설정을 따로 깔았어요. 쓰는 쪽이 사람만은 아니라는 뜻입니다. 스타터 프롬프트도 처음부터 Claude Code 호출을 가정하고 짜여 있습니다. HeyGen 쪽이 더 직접적인 증거예요. "에이전트는 이미 HTML을 말한다"고 선언했으니까요. Remotion은 AI 도구가 바로 쓸 수 있는 설정을 깐 것이고 선언까지는 안 갔습니다. 둘 다 사람이 직접 조작하는 도구보다 AI가 만들고, 다시 읽고, 이어받기 쉬운 HTML 기반 작업 흐름을 택했다는 점은 같아요. 브라우저, 링크, 학습 데이터가 모두 HTML 쪽입니다 Anthropic, HeyGen, Remotion. 개발 도구, 영상 아바타, 영상 프레임워크. 분야도 동기도 다릅니다. 다만 HeyGen과 Remotion은 모두 영상 회사이고, 브라우저 렌더링은 원래 이들의 기술 기반과 가깝습니다. 그래서 HTML 선택 자체보다 중요한 점은 따로 있어요. 두 회사가 HTML을 사람이 손으로 쓰는 문서가 아니라 AI가 만들고 이어받기 쉬운 작업물로 내세웠다는 점입니다. 이유가 하나만 있는 건 아닙니다. HTML은 브라우저에서 바로 열 수 있어요. 링크 한 줄로 보낼 수도 있습니다. LLM 학습 데이터에도 HTML 예제가 많습니다. 그래서 최소한 AI가 만들고, 검증하고, 이어받는 산출물에서는 HTML이 더 자주 선택되고 있습니다. Karpathy는 텍스트 다음을 봤습니다 Andrej Karpathy도 거의 같은 방향을 짚었습니다. OpenAI 초기 멤버이자 Tesla AI 디렉터를 지낸 사람이에요. 그는 X에서 AI 답변이 담기는 형식의 변화를 이렇게 요약했어요. 그냥 텍스트에서 마크다운으로, 마크다운에서 HTML로, 그다음은 신경망이 직접 만드는 인터랙티브 영상. AI가 답을 내놓는 기본 화면이 텍스트에서 마크다운으로, 다시 HTML로 옮겨가고 있다는 뜻이죠. 마크다운이 사라진다는 얘기가 아닙니다. 지금도 많이 쓰고, 앞으로도 쓸 거예요. 다만 첫 선택지는 바뀔 수 있습니다. 짧은 기간에 Anthropic, HeyGen, Remotion의 흐름이 HTML 쪽으로 겹쳤다는 점이 그 신호예요. Karpathy는 사람이 정보를 받아들이는 방식도 근거로 들었습니다. 우리는 긴 텍스트보다 화면, 배치, 움직임을 더 빨리 읽죠. 그래서 AI 출력도 점점 읽는 문서보다 보는 화면에 가까워진다는 얘기입니다. HTML은 보안과 리뷰 비용이 듭니다 하지만 HTML을 첫 선택지로 두는 데는 비용이 있습니다. 이 반론을 빼면 글이 너무 낙관적으로 보이죠. HTML을 미는 쪽도 약점을 인정합니다. 토큰을 두세 배 더 쓴다는 점, 깃에서 변경 내역을 보면 노이즈가 많다는 점. 토큰 쪽에는 우회로가 있습니다. CSS를 외부 파일로 빼면 토큰을 크게 줄일 수 있어요. 그래도 HTML은 마크다운보다 비쌉니다. 다만 모델의 컨텍스트가 커지면서, 토큰 두세 배 차이가 모든 작업을 막는 수준은 아니게 됐죠. 외부 비판은 더 날카로웠어요. Kurtis Redux가 Medium에 'The Unreasonable Ineffectiveness of HTML'을 올렸습니다. 개발자가 검토해야 하는 것은 예쁜 결과물이 아니라 변경된 코드, 실행 위험, 유지보수 비용이라는 지적이죠. Redux의 반론은 네 가지입니다. 원본 HTML은 브라우저 없이는 읽기 어렵고, JavaScript는 보안 위험을 만들 수 있고, 변경 내역은 태그와 스타일에 묻히고, 토큰 비용도 커집니다. 비판을 한 문장으로 줄이면 이겁니다. 마크다운은 열어도 실행되지 않습니다. HTML은 다르죠. JavaScript가 돌고, 외부 리소스를 부르고, 브라우저 권한을 건드릴 수 있습니다. 그래서 HTML 산출물은 문서라기보다 작은 웹앱에 가깝게 다뤄야 해요. 격리된 화면에서 띄우고, 외부 호출을 차단하고, 미심쩍은 산출물은 인터넷을 끊고 열어야 합니다. 다만 "한 줄 명령으로 받아서 더블클릭"이라는 쉬운 경험이 사라지면, HTML의 매력 절반이 같이 깎입니다. 변경 내역 문제도 비슷해요. HTML 파일만 PR에 붙이면 리뷰가 어렵습니다. 렌더링 화면 캡처, 변경 요약, 주요 DOM 변경 설명을 같이 붙이는 쪽이 지금은 더 현실적이죠. 업무별로 나누면 선이 분명합니다. 보고 만지고 비교해야 하는 결과물은 HTML이 낫습니다. 절차, 결정, 체크리스트처럼 텍스트가 중심인 작업은 마크다운이 낫고요. 마크다운이 사라지는 게 아니라, 마크다운이 모든 걸 받아내던 시대가 끝나는 거죠. 프롬프트 한 줄로 작동하긴 하지만, HTML을 제대로 띄우는 환경을 갖춘 도구가 아직 일부 제품에 몰려 있다는 비판도 있어요. HeyGen과 Remotion은 원래 Chromium 렌더링에 가까운 회사라 예외로 볼 여지도 있습니다. 그래도 두 회사가 비슷한 타이밍에 사람용 UI가 아니라 AI 도구용 SDK를 냈다는 점은 우연으로 넘기기 어렵죠. 그래서 당장은 이렇게 나누는 편이 맞습니다. 산출물은 HTML로, 설정과 입력은 마크다운으로. 마크다운을 버리자는 얘기가 아닙니다. 자리를 나누자는 거예요. HTML 산출물이 늘수록 샌드박스 실행, 외부 호출 차단, 렌더링 diff 같은 리뷰 도구도 같이 필요해집니다. 읽히면 사람이 다시 판단한다 결국 남는 질문은 이거예요. 사람이 판단 과정에 남아 있느냐. 마크다운 계획서를 깊이 읽지 않게 되면 Claude의 결정을 그냥 받아들이게 됩니다. HTML로 바꾸면 달라져요. 스크롤하다 닫던 계획서가 정렬하고 비교하는 화면이 되면, 사람은 다시 멈춰서 판단합니다. Redux의 경고는 맞습니다. 보이는 화면이 판단을 대신하면 안 됩니다. 다만 안 읽히는 문서를 고집하는 것도 판단을 포기하는 다른 방식이죠. AI한테 질문하고 답을 받던 시절에는 텍스트로 충분했어요. 이제 AI 산출물은 30초짜리 메모가 아니라 한 시간 동안 만지고 판단하는 화면까지 커졌습니다. 결과물이 달라졌으니 파일 형식도 같이 바뀌는 겁니다. 오늘 한번 해보세요 엔지니어만의 얘기가 아니에요. Claude Artifacts, ChatGPT Canvas, Gemini Canvas. 주요 챗봇 대부분에 이미 같은 능력이 들어와 있어요. 이번 주 회의록이나 KPI 표 하나만 골라 이렇게 물어보세요. "정렬 가능한 HTML 대시보드로 만들어줘. 목표 대비 달성률은 색으로 보여주고, 마지막에 copy as markdown 버튼을 넣어줘." 30초면 클릭 가능한 대시보드가 옵니다. 헤더를 누르면 정렬이 바뀌고, 달성률 80% 이하는 빨간색으로 뜨고, 버튼 한 번이면 마크다운으로 뽑혀요. CommonMark 스펙은 이미 마크다운 안에 HTML 삽입을 허용하고 있어요. 전부 바꿀 필요는 없습니다. 읽기만 할 문서는 마크다운으로 두고, 비교하고 판단해야 할 부분만 HTML로 올리면 됩니다. 마크다운은 기록에 남기고, 판단해야 할 부분은 화면으로 올리세요. 구독자분들을 위해 작은 선물을 준비했습니다. SaaS를 6개 만들고, 출시했습니다. 그리고 제 모든 업무 중심이 Claude Code로 돌아갑니다. 시중에 무작위로 배포되는 단순 기술을 정리한 게 아닌, 실전 중심의 활용법과 경험을 녹여냈습니다. 아래 링크에서 확인 하실 수 있습니다. 앞으로도 계속 유익한 정보를 전달드리겠습니다. 📌오픈채팅방 : https://open.kakao.com/o/gtzeeMji ✅ 엉클잡스 스레드 : https://www.threads.net/@unclejobs.ai 📖 무료 전자책 링크 : https://www.latpeed.com/products/k9vwB Powered by beehiiv
