HTML로 출력하는 프롬프트: 답변을 작은 인터페이스로 바꾸는 법

LLM에게 “HTML로 출력해줘”라고 말하면 생각보다 그럴듯한 결과가 나온다. 카드가 있고, 색이 있고, 표가 있고, 버튼처럼 보이는 것도 있다. 처음에는 이것만으로 충분해 보인다.

그런데 실제로 써 보려 하면 문제가 드러난다. 어떤 결과물은 브라우저에서 깨진다. 어떤 결과물은 CSS가 다른 페이지와 충돌한다. 어떤 결과물은 모바일에서 글자가 넘친다. 어떤 결과물은 링크가 죽어 있고, 어떤 결과물은 예쁘지만 다시 쓰기 어렵다. 결국 “HTML로 출력”은 형식 지시가 아니라 작은 인터페이스를 만드는 일이라는 사실을 받아들여야 한다.

그래서 HTML 출력 프롬프트는 예쁜 답변을 요구하는 프롬프트가 아니다. 그것은 렌더 계약이다. 모델에게 어떤 구조로, 어떤 제약 안에서, 어떤 검증 기준을 통과하는 HTML을 만들라고 요구하는 작업 명세다.

HTML은 답변이 아니라 실행되는 문서다

마크다운 답변은 읽히면 끝난다. HTML은 다르다. 브라우저가 해석하고, 화면 크기에 따라 다시 배치되고, 링크와 버튼과 이미지와 스크립트가 실제로 작동해야 한다.

그래서 HTML 출력 프롬프트에는 최소한 네 가지 질문이 들어가야 한다.

질문	왜 필요한가
어디에서 열릴 것인가	블로그 본문, iframe, 단독 파일, LMS, 노션 임베드마다 제약이 다르다
누가 볼 것인가	개발자, 학생, 학부모, 독자에 따라 밀도와 언어가 달라진다
무엇을 조작할 수 있어야 하는가	단순 문서인지, 필터와 탭이 있는 도구인지가 달라진다
무엇으로 검증할 것인가	브라우저 렌더링, 모바일 폭, 접근성, 링크, 보안 기준이 필요하다

이 질문이 없으면 모델은 “보기 좋은 HTML”을 만든다. 질문이 있으면 모델은 “쓸 수 있는 HTML”을 만들 가능성이 커진다.

좋은 HTML 출력 프롬프트의 다섯 층

HTML 출력 프롬프트를 나는 다섯 층으로 나눈다.

층	역할	프롬프트에 들어갈 내용
목적	왜 이 HTML이 필요한가	학습 카드, 보고서, 랜딩, 대시보드, 비교표
정보 구조	무엇을 어떤 순서로 보여줄 것인가	섹션, 카드, 표, 탭, 필터
렌더 계약	브라우저에서 지켜야 할 조건	단일 HTML, 반응형, 외부 의존성 제한
상호작용	사용자가 무엇을 할 수 있는가	검색, 접기, 탭 전환, 복사, 퀴즈
검증	무엇을 통과해야 완료인가	모바일 폭, 텍스트 넘침, 링크, 콘솔 오류

이 구조를 넣으면 “HTML로 만들어줘”라는 요청이 “작은 앱을 설계해줘”로 바뀐다.

여기서 중요한 점은 HTML을 코드로만 보지 않는 것이다. HTML은 정보 구조와 시각 구조와 사용 흐름이 만나는 지점이다. 그래서 프롬프트도 디자인 명세와 개발 명세 사이에 있어야 한다.

자급식 HTML이라는 기본값

LLM에게 HTML을 맡길 때 기본값은 자급식 HTML이 좋다. 하나의 파일 안에 HTML, CSS, 필요한 JavaScript가 들어 있는 형태다.

물론 실제 서비스에서는 React, Vite, Next.js 같은 구조가 더 적절할 때가 많다. 하지만 블로그 실험, 수업 자료, 워크시트 미리보기, 아이디어 검증 단계에서는 자급식 HTML이 훨씬 빠르다. 파일 하나만 열어도 결과를 볼 수 있고, 배포 전에 브라우저에서 바로 검증할 수 있기 때문이다.

자급식 HTML의 장점은 세 가지다.

장점	설명
이동성	파일 하나로 공유하고 백업할 수 있다
검증성	브라우저에서 바로 깨지는 부분을 확인할 수 있다
재사용성	나중에 React 컴포넌트나 Hexo 페이지로 옮기기 쉽다

단, 자급식 HTML은 아무렇게나 만들면 안 된다. 외부 CDN을 과하게 쓰면 오프라인에서 깨지고, 전역 CSS를 함부로 쓰면 블로그 테마와 충돌하며, 인라인 스크립트가 많아지면 유지보수가 어려워진다.

그래서 프롬프트에는 이런 제약을 명시해야 한다.

하나의 self-contained HTML 파일로 작성하라.
외부 CDN은 사용하지 말고, 필요한 CSS와 JavaScript는 파일 안에 포함하라.
모든 스타일은 컴포넌트 루트 클래스 아래에 제한하라.
모바일 360px 폭에서도 텍스트가 컨테이너 밖으로 넘치지 않게 하라.
콘솔 오류 없이 작동해야 한다.

이 정도만 넣어도 결과가 달라진다. 모델은 이제 예쁜 조각을 만드는 것이 아니라, 제한된 실행 환경 안에서 견디는 문서를 만들어야 한다.

HTML 출력 프롬프트 템플릿

내가 반복해서 쓰고 싶은 기본형은 다음과 같다.

당신은 HTML 인터페이스 설계자다.
아래 내용을 하나의 self-contained HTML 파일로 만들어라.

목적:
- [이 HTML이 해결해야 할 일]

독자 / 사용자:
- [누가 보는가]

정보 구조:
- [섹션, 카드, 표, 탭, 필터, 타임라인 등]

렌더 계약:
- HTML, CSS, JavaScript를 한 파일에 포함한다.
- 외부 CDN과 외부 폰트에 의존하지 않는다.
- 전체 UI는 하나의 루트 클래스 아래에 스코프를 둔다.
- 모바일 360px, 태블릿 768px, 데스크톱 1200px에서 읽을 수 있어야 한다.
- 텍스트가 버튼, 카드, 표 밖으로 넘치지 않아야 한다.

상호작용:
- [검색, 접기, 탭, 복사, 퀴즈 등 필요한 기능]

접근성:
- 의미 있는 heading 구조를 사용한다.
- 버튼에는 명확한 aria-label 또는 텍스트를 둔다.
- 색 대비가 낮지 않게 한다.

검증 기준:
- 브라우저 콘솔 오류가 없어야 한다.
- 모든 링크와 버튼이 의도대로 동작해야 한다.
- 인쇄하거나 PDF로 저장해도 핵심 정보가 사라지지 않아야 한다.

출력:
- 설명 없이 HTML 코드만 출력한다.

이 템플릿의 핵심은 “HTML 코드만 출력하라”가 아니다. 그 앞에 있는 렌더 계약과 검증 기준이 핵심이다. 출력 형식만 정하면 모델은 포장에 집중한다. 계약을 정하면 구조를 생각한다.

블로그에서는 HTML을 어떻게 다뤄야 할까

블로그 글 안에 HTML을 넣는 방식은 두 가지다.

첫째, 본문 안에 짧은 HTML 조각을 직접 넣는 방식이다. 버튼, 작은 표, 강조 박스 정도라면 가능하다. 하지만 CSS 충돌과 모바일 깨짐을 주의해야 한다.

둘째, 별도 파일로 만들고 iframe으로 임베드하는 방식이다. 단어 암기 카드를 인터랙티브 HTML로 만들면 무엇이 달라질까에서 쓴 방식이 여기에 가깝다. 학습 카드처럼 상호작용이 있는 자료는 본문에 다 끼워 넣기보다, /files/.../index.html 같은 별도 경로로 두고 블로그에서 보여주는 편이 안정적이다.

나는 두 번째 방식을 더 좋아한다. 글은 해설을 맡고, HTML은 체험을 맡는다. 이렇게 나누면 독자는 글을 읽다가 바로 실험해 볼 수 있고, 나중에 HTML 파일만 따로 개선하기도 쉽다.

HTML 출력 프롬프트를 하네스로 바꾸기

HTML 출력 프롬프트가 반복 작업이 되려면 다음 흐름이 필요하다.

단계	작업	산출물
1. 입력 정리	원자료, 독자, 사용 상황을 정한다	입력 계약
2. 구조 설계	섹션, 카드, 표, 상호작용을 나눈다	정보 구조
3. HTML 생성	자급식 HTML 또는 임베드 파일로 출력한다	HTML 초안
4. 브라우저 검증	화면 폭, 링크, 콘솔, 텍스트 넘침을 본다	수정 목록
5. 재생성 / 수동 수정	깨진 부분만 좁혀서 고친다	안정화 버전
6. 블로그 연결	글, 데모, 다운로드 링크를 연결한다	공개 글

이 루프가 없으면 HTML 프롬프트는 일회성 장난감이 된다. 루프가 있으면 프롬프트는 작은 제작 시스템이 된다.

이 구조는 스토리보드 생성기는 이미지 생성기가 아니다: Story Graph로 창작 하네스를 만드는 법과도 닮았다. 스토리보드에서 이미지보다 컷 계획이 먼저이듯, HTML에서도 코드보다 렌더 계약이 먼저다. 또 베이지안 동적 번역기: 번역 프롬프트를 하네스로 묶는 법에서 번역 전략을 기록했듯, HTML 출력도 렌더 조건과 검증 기준을 기록해야 반복 가능해진다.

조심해야 할 실패 패턴

HTML 출력 프롬프트에서 자주 보는 실패는 비슷하다.

실패 패턴	증상	해결
예쁜데 못 쓰는 HTML	장식은 많지만 정보 구조가 약하다	정보 구조를 먼저 요구한다
전역 CSS 오염	블로그 테마나 다른 컴포넌트와 충돌한다	루트 클래스 아래로 스타일을 제한한다
모바일 붕괴	카드, 버튼, 표의 텍스트가 넘친다	최소 폭과 줄바꿈 규칙을 명시한다
과한 의존성	CDN, 외부 폰트, 이미지가 없으면 깨진다	self-contained 기본값을 둔다
검증 없는 출력	보기에는 되지만 버튼과 링크가 죽어 있다	콘솔 오류와 링크 검증을 요구한다

이 표를 프롬프트 뒤에 붙여도 좋다. 모델에게 “이런 실패를 피하라”고 말하는 것보다, 실패 유형과 해결 기준을 같이 주면 결과가 더 안정된다.

HTML 출력은 글쓰기와 개발 사이에 있다

HTML 출력 프롬프트가 재미있는 이유는 글쓰기와 개발 사이에 있기 때문이다. 글처럼 빠르게 만들 수 있지만, 개발처럼 실행된다. 설명처럼 보이지만, 실제 사용자가 클릭하고 읽고 반응한다.

그래서 이 작업은 프롬프트 엔지니어링만으로 끝나지 않는다. 컨텍스트 엔지니어링이 필요하고, 하네스 엔지니어링이 필요하고, 루프 엔지니어링이 필요하다. 무엇을 넣을지, 어떤 구조로 보여줄지, 어떻게 검증할지, 다음 버전에서 무엇을 고칠지까지 포함해야 한다.

내가 앞으로 만들고 싶은 흐름은 단순하다.

아이디어가 생기면 글로 설명한다. 글 안에서 바로 체험할 수 있는 HTML 데모를 붙인다. 데모는 하나의 파일로 검증 가능하게 만든다. 그 HTML은 다시 블로그 글, 수업 자료, 워크시트, 앱 프로토타입으로 확장된다.

이렇게 보면 “HTML로 출력해줘”는 작은 명령이 아니다. 그것은 생각을 화면에 올리고, 화면을 검증하고, 검증된 화면을 다시 지식 노드로 저장하는 루프의 시작점이다.