AI 에이전트가 원하는 형식은 HTML입니다

2026년 5월 8일, Anthropic에서 Claude Code를 개발하는 엔지니어 Thariq Shihipar는 에이전트가 9가지 지식 작업 범주에서 만든 HTML 산출물 20개를 모은 개인 사이트를 공개했습니다. 그의 주장은 하나입니다. 답이 공간 구조, 상호작용, 시각적 증거를 담고 있다면 HTML은 Markdown보다 낫습니다.¹²

에이전트 출력에서는 HTML이 Markdown보다 낫습니다. 공간 구조, 상호작용, 시각적 증거는 산문이 평면화해 버리는 정보를 담기 때문입니다. 에이전트가 내보내는 형식은 사람이 살펴보는 제어 표면이지, 그 위를 감싸는 껍데기가 아닙니다.

이 글은 5월 14일 arXiv 논문이 에이전트 검색 품질은 검색기보다 실행 환경에 달려 있음을 보이기 6일 전에 나왔습니다.³ 같은 패턴이 여기에도 보입니다. 형식과 실행 환경은 포장이 아니라 기반입니다. 그 주변 표면이 모델 출력을 사람이 검증할 수 있는 형태로 바꾼 뒤에야 구성 요소가 중요해집니다.

요약

Thariq Shihipar는 코드 리뷰, 디자인 시스템, 프로토타이핑, 탐색, 다이어그램, 리서치, 보고서, 편집기 표면을 아우르는 HTML 예시 20개를 담은 동반 사이트를 공개했습니다.¹ 핵심은 Markdown이 공간적으로 들어오는 정보를 일렬로 펴 버린다는 점입니다. 차이 비교, 호출 그래프, 나란히 놓은 비교, 인터랙티브 프로토타입은 산문이 평면화해 버리는 의미를 담고 있습니다. 8K 토큰 GPT-4 출시 시기에는 Markdown이 토큰 효율적인 기본값으로 밀려났지만, 현재 Claude 컨텍스트 창 문서에는 200K 토큰 모델과 1M 토큰 모델이 올라와 있어 많은 산출물 크기에서 계산이 달라졌습니다.⁴⁵ FastAPI와 HTMX처럼 서버 렌더링 기반의 빌드 없는 웹 스택에는 이 글이 에이전트 쪽 근거를 제공합니다. HTML은 모델이 만들고 싶어 하는 형식이자 브라우저가 이미 렌더링하는 형식입니다. Markdown을 거치면 양쪽 끝에서 충실도를 떨어뜨리는 번역 단계가 하나 더 생깁니다.⁶

핵심 정리

에이전트 빌더에게: - 답이 비교, 차이 비교, 순서도, 탐색 가능한 구조라면 에이전트 출력의 기본값을 Markdown으로 두지 마세요. HTML을 요청하고 에이전트가 공간 레이아웃에 책임지게 하세요.¹ - 모델의 출력 형식을 도구 표면의 일부로 다루세요. 렌더링된 하나의 산출물은 지나가 버리는 대화 기록보다 훨씬 살펴보기 쉽습니다.⁷

인터페이스 디자이너에게: - HTML은 디자인 시스템이 이미 배포되는 매체입니다. Markdown을 거치면 충실도를 잃는 번역 단계가 생기고, 렌더링할 때 또 한 번의 번역 단계를 거치게 됩니다.¹ - 제어 표면은 에이전트가 만들어 내는 바로 그것입니다. 사람이 에이전트가 본 것을 볼 수 없다면 그 표면은 망가진 것입니다.⁷

서버 렌더링 기반 빌드 없는 스택을 운영하는 팀에게: - 빌드 파이프라인보다 HTML을 택하는 선택에는 이제 에이전트 쪽 검증도 붙었습니다. 모델이 만들고 싶어 하는 형식과 브라우저가 이미 렌더링하는 형식이 같습니다.⁶ - 서버 렌더링 사이트는 번역 계층을 두 번 제거합니다. 한 번은 빌드 단계에서, 또 한 번은 에이전트 출력 단계에서입니다. 두 제거 효과는 서로 겹쳐 커집니다.

Thariq가 실제로 주장한 것

Shihipar는 Anthropic에서 Claude Code를 개발합니다. 다만 이 글은 Anthropic 공식 블로그가 아니라 그의 개인 사이트에 올라온 글입니다.² 동반 갤러리에는 에이전트가 만든 독립형 HTML 파일 20개가 있으며, Markdown보다 HTML이 구조적으로 더 나은 9가지 작업 범주로 묶여 있습니다.¹

그의 핵심 주장은 다음과 같습니다.

웹 인프라를 만드는 사람에게는 두 번째 주장이 핵심입니다. 디자인 시스템이 HTML로 배포된다면 에이전트도 HTML을 만들어야 합니다. 그 밖의 선택은 손실이 생기는 왕복 과정을 추가합니다.

20개 예시가 곧 논증입니다

Shihipar의 갤러리 범주는 지금 많은 사람이 코딩 에이전트에게 맡기는 작업을 다룹니다.¹

• 코드 리뷰: 심각도별 인라인 노트가 붙은 주석 달린 차이 비교, 강조된 호출 경로가 있는 모듈 지도.
• 탐색: 나란히 놓은 코드 접근법, 순서대로 읽는 대신 선택할 수 있게 배치된 시각적 디자인 옵션.
• 디자인: 살아 있는 디자인 시스템 페이지, 변형을 실제로 렌더링하는 컴포넌트 변형 시트.
• 프로토타이핑: 실제 이징 곡선이 있는 애니메이션 샌드박스, 클릭에 반응하는 인터랙티브 흐름.
• 다이어그램: 인라인 SVG 그림, 주석 달린 순서도, 박스와 화살표로 그린 아키텍처 스케치.
• 리서치: 접을 수 있는 섹션, 실제 데모가 붙은 인터랙티브 개념 설명.
• 보고서: 구조 자체가 의미를 전달하는 형식화된 타임라인과 차트.
• 편집기: 내보내기 기능이 산출물 안에 포함된 맞춤 인터페이스.

각각은 모델이 한 번에 만든 HTML 페이지입니다. 공통 패턴은 분명합니다. 답이 공간적이거나 상호작용적이며, 렌더링된 산출물이 Markdown 응답이라면 산문으로 설명해야 했을 내용을 그대로 보존합니다.

기본값은 왜 Markdown이었나

Markdown이 에이전트 출력의 기본값이 된 데에는 이제 더 이상 그대로 적용되지 않는 이유가 2가지 있었습니다.

첫째, 채팅 출력 관례가 굳어지던 시기에는 GPT-3.5와 GPT-4 세대가 4K에서 8K 범위의 컨텍스트 창에 부딪혔습니다.⁴ Markdown의 간결함은 실제 제약이었습니다. <div class="...">에 쓰는 토큰은 분석에 쓸 수 없는 토큰이었습니다. 현재 Claude 컨텍스트 창 문서에는 여러 모델의 200K 토큰 컨텍스트와 Opus 4.1 및 Sonnet 4.6의 1M 토큰 컨텍스트가 나와 있습니다.⁵ 많은 검사용 산출물에서는 토큰 효율성 논리가 약해졌습니다.

둘째, 터미널 렌더러와 채팅 창은 Markdown을 아주 쉽게 렌더링하지만, HTML에는 웹뷰나 브라우저 탭이 필요합니다. 표면의 편의성은 토큰 논리가 힘을 잃은 뒤에도 Markdown을 가장 저항이 적은 경로로 남겨 두었습니다.

Shihipar의 글이 무게를 갖는 이유는 작성자가 Anthropic에서 Claude Code를 개발하기 때문입니다. 20개 예시는 추상적 주장이 아니라 구체적 산출물입니다.² 같은 날 Simon Willison의 글도 Linux 보안 취약점 설명을 Markdown 글이 아니라 인터랙티브 HTML 페이지로 렌더링하며 같은 패턴을 재현했습니다.⁸

HTML이 보존하고 Markdown이 떨어뜨리는 것

이 논증을 떠받치는 속성은 4가지입니다.

각 속성은 출력을 산문으로 평면화할 때 더 어려워지는 에이전트 작업의 한 부류와 연결됩니다. 차이 비교는 공간적 비교이고, 순서도는 그래프이며, 디자인 시스템 리뷰는 시각적 판단입니다. 이것들을 Markdown으로 밀어 넣으면 렌더러가 보여 줄 수 있었던 것을 독자가 다시 머릿속에서 재구성해야 합니다.

실행 환경과의 연결

에이전트 검색 품질은 검색기가 아니라 실행 환경에 달려 있습니다. 그 글은 검색 방법보다 그 주변의 실행 틀이 더 중요하다고 주장했습니다. 프롬프트 형태, 도구 표면, 대화 기록 형식, 결과 전달, 재시도 동작이 모두 여기에 포함됩니다.³

HTML 논증은 같은 틀을 출력으로 확장합니다. 모델은 어떤 형식으로든 올바른 답을 만들 수 있습니다. 그러나 어떤 형식을 요청하느냐는 실행 계약의 일부입니다. 형식이 달라지면 검증 가능한 표면도 달라집니다.

• Markdown 전달: 사용자가 위에서 아래로 읽고, 무엇이 중요한지 판단하며, 구조를 머릿속에서 재구성합니다.
• HTML 전달: 모델이 구조에 책임지고, 렌더러가 그 구조를 훑어볼 수 있게 만들며, 사용자는 읽기보다 살펴봅니다.

같은 데이터라도 제어 표면은 달라집니다. 에이전트형 디자인은 제어 표면 디자인입니다. 에이전트가 내보내는 형식은 그 표면의 일부이지, 포장이 아닙니다.⁷

빌드 없는 스택에는 어떤 의미인가

이 사이트의 FastAPI와 HTMX 가이드는 JavaScript 빌드 파이프라인보다 서버 렌더링 HTML을 선택해야 하는 이유를 설명합니다.⁶ Shihipar의 글은 여기에 에이전트 쪽 근거를 더합니다.

• 모델은 HTML을 만들고 싶어 합니다.
• 브라우저는 HTML을 렌더링하고 싶어 합니다.
• 그 사이에 Markdown이나 JSX를 끼워 넣으면 손실이 생기는 번역 단계가 2개 추가됩니다.

빌드 없는 서버 렌더링 사이트는 빌드 시점의 번역을 제거합니다. 에이전트가 HTML을 직접 만들게 하면 출력 시점의 번역도 제거됩니다. 누적 효과는 분명합니다. 같은 형식이 모델에서 라우트를 거쳐 브라우저까지 중간 형식 없이 이어집니다.

이 말은 React나 Markdown이 어디서나 틀렸다는 뜻이 아닙니다. 이제 번역 단계의 비용이 양쪽 끝에서 모두 보이기 시작했고, 양쪽을 모두 피하는 스택은 그만큼 단순해진다는 뜻입니다.

형식이 중요합니다. 실행 환경도 중요합니다. 둘 다 기반입니다.

에이전트 검색 논문과 HTML 글은 8일 간격으로 나왔고, 같은 형태의 주장을 펼칩니다.¹³

• 검색기는 구성 요소입니다. 실행 환경이 기반입니다.
• 모델은 구성 요소입니다. 출력 형식이 기반입니다.

구성 요소 중심 사고는 계속 지역적 업그레이드를 제안합니다. 검색기를 바꾸고, 메모리를 추가하고, 모델을 교체하고, 프롬프트를 다듬자는 식입니다. 기반 중심 사고는 사용자가 보는 표면과 에이전트가 만들어 내는 표면을 바꿉니다. 이번 주에 나온 두 발견은 모두 작업의 무게중심을 두 번째 틀로 옮깁니다.

실천은 간단합니다. 에이전트의 답이 공간 정보를 담는다면 HTML을 요청하세요. 에이전트가 실행 틀 안에서 움직인다면 모델보다 먼저 그 실행 틀을 계측하세요. 두 움직임은 서로 강화됩니다. 어느 쪽도 혼자서 만능 해결책은 아닙니다.

FAQ

Anthropic이 이 글을 발표했나요?

아니요. Thariq Shihipar가 개인 사이트인 thariqs.github.io/html-effectiveness/에 게시했습니다.¹ 그는 Anthropic에서 Claude Code를 개발하므로 권위 신호는 강하지만, 이 글은 Anthropic의 공식 발행물이 아닙니다.²

이 주장은 모든 에이전트 작업에 적용되나요?

아니요. 이 글은 공간 구조, 상호작용, 시각적 증거가 의미를 전달하는 작업을 명확히 겨냥합니다. 짧은 사실 답변이나 터미널에 묶인 출력에는 Markdown이 여전히 괜찮은 기본값입니다.¹

토큰 비용은 어떻게 보아야 하나요?

Markdown의 비용상 이점은 작은 컨텍스트 창에 묶여 있었습니다. 현재 Claude 컨텍스트 창 문서에는 200K 토큰 및 1M 토큰 모델이 올라와 있으며, 이 때문에 글에서 보여 주는 산출물 크기에서는 HTML의 장황함에 대한 계산이 달라집니다.⁵

이것이 Claude Code의 기존 Markdown 기본값을 깨나요?

아니요. 이 주장은 대화 기록이나 터미널 출력이 아니라, 검사용으로 모델에게 그때그때 만들어 달라고 요청하는 출력에 관한 것입니다. 여전히 단일 프롬프트로 HTML을 요청해 독립형 산출물을 받을 수 있습니다.¹

이것은 에이전트 검색 실행 환경 논문과 어떻게 연결되나요?

두 주장은 모두 모델 자체보다 모델 주변의 기반을 가리킵니다. 검색 품질은 실행 틀에 달려 있고, 출력 품질은 형식에 달려 있습니다. 구성 요소는 필요합니다. 하지만 그 구성 요소를 믿을 수 있게 만드는 것은 기반입니다.³

FastAPI와 HTMX 팀은 이것을 어떻게 활용해야 하나요?

배포하는 모든 AI 기능에서 HTML을 1급 출력 대상으로 다루세요. 같은 형식이 모델에서 라우트를 거쳐 브라우저까지 이어지고, 빌드 없는 스택은 이미 그 경로에 맞게 최적화되어 있습니다.⁶

참고 문헌