▲

클로드 코드 사용하기: HTML의 놀라운 효율성

 (twitter.com/trq212)
12P by GN⁺ 11시간전 | ★ favorite | 댓글 2개
  • Claude Code에서 Markdown 대신 HTML을 출력 형식으로 쓰면 시각화, 색상, 다이어그램, 상호작용을 더 풍부하게 담아 사람이 읽고 검토하기 쉬운 결과물을 만들 수 있음
  • HTML은 표, CSS, SVG, script, JavaScript 상호작용, 이미지, 캔버스와 절대 위치를 활용해 Claude가 읽을 수 있는 정보 대부분을 효율적으로 표현해 줌
  • Claude Code는 파일 시스템, MCP, 브라우저, Git 기록 같은 맥락을 읽어 HTML 결과물로 엮을 수 있으며, “HTML 파일을 만들어줘”라고 요청하는 것만으로 시작 가능함
  • 주요 활용 방식은 스펙·계획·탐색, 코드 리뷰와 코드 이해, 디자인과 프로토타입, 보고서·리서치·학습, 맞춤형 일회용 편집 인터페이스로 나뉨
  • HTML은 Markdown보다 생성이 2~4배 더 오래 걸리고 diff가 시끄러워 버전 관리가 어렵지만, 표현력과 공유 가능성, 실제로 읽힐 가능성이 더 큰 장점으로 꼽힘

Markdown 대신 HTML을 선호하게 된 이유

  • Markdown은 에이전트가 사람과 소통하는 지배적인 파일 형식이 되었고, 단순하고 이식성이 좋으며 약간의 서식을 표현할 수 있고 사람이 직접 편집하기 쉬움
  • Claude는 Markdown 안에서 ASCII 다이어그램도 잘 만들지만, 에이전트가 더 강력해질수록 Markdown은 제약적인 형식으로 느껴짐
  • 100줄이 넘는 Markdown 파일은 읽기 어렵고, 더 풍부한 시각화·색상·다이어그램을 쉽게 공유하고 싶어짐
  • 직접 파일을 편집하기보다 Claude에게 편집을 요청하는 경우가 많아지면서, Markdown의 큰 장점인 쉬운 직접 편집의 가치가 줄어듦
  • Claude Code 팀 안에서도 HTML을 출력 형식으로 쓰는 경우가 늘고 있으며, 예시는 html-effectiveness에서 볼 수 있음

HTML의 표현력과 공유성

  • HTML은 제목과 서식 같은 문서 구조뿐 아니라 Markdown보다 훨씬 다양한 정보를 표현할 수 있음
  • 표현 가능한 정보에는 표를 통한 테이블 데이터, CSS를 통한 디자인 데이터, SVG 일러스트, script 태그를 통한 코드 조각, JavaScript와 CSS를 이용한 상호작용이 들어감
  • SVG와 HTML로 워크플로를 나타내고, 절대 위치와 캔버스로 공간 데이터를 표현하며, img 태그로 이미지를 넣을 수 있음
  • Claude가 읽을 수 있는 정보 집합 대부분은 HTML로 꽤 효율적으로 표현 가능하며, 모델이 깊이 있는 정보를 전달하고 사람이 검토하기에도 효율적인 형식이 됨
  • HTML을 쓰지 못하면 Claude가 Markdown에서 ASCII 다이어그램을 만들거나, Unicode 문자로 색상을 추정하는 식의 비효율적인 표현을 쓰게 될 수 있음
  • Claude가 더 복잡한 작업을 수행하면서 더 큰 스펙과 계획을 작성하게 되었고, 실제로 100줄이 넘는 Markdown 파일은 잘 읽히지 않음
  • HTML 문서는 탭, 일러스트, 링크 등을 통해 구조를 시각적으로 구성할 수 있어 탐색하기 쉽고, 화면 크기에 따라 다르게 읽히도록 모바일 반응형으로도 만들 수 있음
  • Markdown 파일은 브라우저가 기본적으로 잘 렌더링하지 않아 이메일이나 메시지에 첨부해야 하는 경우가 많지만, HTML은 S3 같은 곳에 올리면 링크로 쉽게 공유 가능함
  • HTML로 된 스펙, 보고서, PR 설명은 동료가 열어보고 참조하기 쉬워 실제로 읽힐 가능성이 훨씬 높아짐
  • HTML 문서는 슬라이더나 노브를 넣어 디자인을 조정하거나 알고리듬 옵션을 바꿔 결과를 확인하는 양방향 상호작용을 지원할 수 있음
  • 조정한 내용을 Claude Code에 다시 붙여넣을 프롬프트로 복사하는 기능도 만들 수 있으며, 관련 예시는 playgrounds post에서 다룸

Claude Code와 HTML을 함께 쓰는 이유

  • Claude Code는 파일 시스템, MCP, 브라우저, Git 기록 등 다양한 맥락을 읽어 HTML 결과물로 엮을 수 있음
  • 예를 들어 코드 폴더에서 생성된 HTML 파일을 모두 찾고, 그룹화·분류한 뒤 각 유형을 대표하는 다이어그램이 담긴 HTML 파일을 만들 수 있음
  • 파일 시스템 외에도 Slack, Linear 같은 MCP, Claude in Chrome을 통한 웹 브라우저, Git 기록 등에서 추가 맥락을 찾을 수 있음
  • HTML 문서를 Claude와 함께 만드는 과정은 더 재미있고, 생성물에 더 관여하고 투자하고 있다는 느낌을 줌
  • 별도의 /html 스킬을 만들 필요 없이 “HTML 파일을 만들어줘” 또는 “HTML artifact를 만들어줘”라고 요청하는 것만으로 시작할 수 있음
  • 중요한 요령은 artifact가 무엇을 해야 하는지, 어떻게 사용할 것인지 아는 것이며, 처음에는 매번 처음부터 프롬프트를 작성해 다양한 용도를 익히는 편이 좋음

주요 활용 방식

  • 스펙, 계획, 탐색

    • HTML은 Claude가 문제를 파고들기 위한 풍부한 캔버스가 되며, 단일 Markdown 계획 대신 여러 HTML 파일의 묶음으로 작업을 시작할 수 있음
    • 먼저 여러 방향을 브레인스토밍하고, 이후 한 방향을 확장해 목업이나 코드 조각을 만들고, 마지막으로 구현 계획을 작성하는 흐름이 가능함
    • 계획이 만족스러우면 새 세션을 만들고 이 파일들을 넘겨 구현할 수 있으며, 검증 에이전트도 같은 파일을 읽어 필요한 맥락을 더 넓게 확보할 수 있음
    • 온보딩 화면에 대해 레이아웃·톤·밀도가 다른 6가지 접근을 하나의 HTML 그리드로 만들고 각 선택의 트레이드오프를 표시하게 할 수 있음
    • 목업, 데이터 흐름, 검토할 코드 조각을 포함한 읽기 쉬운 HTML 구현 계획도 만들게 할 수 있음
    • 코드 구현 방식 탐색과 여러 시각 디자인 비교에 사용할 수 있음

  • 코드 리뷰와 코드 이해

    • 코드는 Markdown 파일에서 읽기 어려울 수 있지만, HTML에서는 diff, 주석, 흐름도, 모듈 구조 등을 렌더링할 수 있음
    • 에이전트가 작성한 코드를 이해하거나, 코드 리뷰를 받거나, PR을 검토하는 사람에게 변경 내용을 설명하는 데 사용할 수 있음
    • 기본 GitHub diff 보기보다 더 잘 작동하는 경우가 있으며, PR마다 HTML 코드 설명 파일을 첨부하는 흐름도 가능함
    • PR 리뷰용 HTML artifact를 만들고, 익숙하지 않은 streaming/backpressure 로직에 집중하며, 실제 diff에 여백 주석을 달고 심각도별로 색을 입히게 할 수 있음
    • PR 작성, PR 리뷰, 코드 주제 이해에 사용할 수 있음

  • 디자인과 프로토타입

    • Claude Design은 HTML을 기반으로 하며, HTML은 최종 표면이 HTML이 아니더라도 디자인 표현력이 높음
    • Claude는 HTML로 디자인을 스케치한 뒤 React, Swift 등 원하는 언어로 작성할 수 있음
    • 애니메이션, 액션 같은 상호작용을 프로토타입할 수 있고, 슬라이더나 노브를 넣어 원하는 값을 조정할 수 있음
    • 클릭 시 재생 애니메이션 후 빠르게 보라색으로 바뀌는 체크아웃 버튼을 만들고, 여러 슬라이더와 옵션 및 잘 맞는 파라미터를 복사하는 버튼을 포함하게 할 수 있음
    • 디자인 시스템 artifact 생성, 컴포넌트 조정, 컴포넌트 라이브러리 시각화, 즐거운 애니메이션 프로토타입에 사용할 수 있음

  • 보고서, 리서치, 학습

    • Claude Code는 여러 데이터 소스의 정보를 종합해 읽기 쉬운 보고서로 바꾸는 데 강함
    • Slack, 코드베이스, Git 기록, 인터넷 등을 검색하게 하고, 자신·리더십·팀을 위한 읽기 쉬운 보고서를 생성할 수 있음
    • 결과물은 긴 HTML 문서, 인터랙티브 설명서, 슬라이드나 deck 형태가 될 수 있음
    • SVG를 사용해 다이어그램을 만들게 하면 시각화에 도움이 됨
    • prompt caching 관련 글을 준비할 때 Git 기록을 읽고 prompt caching 변경 사항 전체를 다룬 심층 HTML 리서치 파일을 만들게 한 방식이 사용됨
    • rate limiter의 관련 코드를 읽고 token-bucket 흐름 다이어그램, 주석이 달린 핵심 코드 조각 3~4개, 하단 gotchas 섹션을 포함한 단일 HTML 설명 페이지를 만들게 할 수 있음
    • 기능 동작 요약, 개념 설명, 주간 상태 보고, 사고 보고, SVG 일러스트·흐름도·기술 다이어그램에 사용할 수 있음

  • 맞춤형 편집 인터페이스

    • 텍스트 박스만으로 원하는 것을 설명하기 어려울 때, 현재 작업 중인 데이터에 맞춘 일회용 HTML 편집기를 만들 수 있음
    • 제품이나 재사용 도구가 아니라, 특정 데이터 조각 하나를 위해 목적에 맞게 만든 단일 HTML 파일이 됨
    • 핵심은 마지막에 “copy as JSON” 또는 “copy as prompt” 같은 내보내기를 넣어, UI에서 조작한 결과를 Claude Code에 붙여넣을 수 있게 하는 것임
    • 30개 Linear 티켓을 Now / Next / Later / Cut 열의 드래그 가능한 카드로 만들고, 최종 순서를 bucket별 한 줄 근거와 함께 Markdown으로 복사하게 할 수 있음
    • feature flag 설정을 폼 기반 편집기로 만들고, 영역별로 묶고, 의존성을 표시하며, 전제 flag가 꺼진 상태에서 flag를 켜면 경고하고, 변경된 키만 diff로 복사하게 할 수 있음
    • 시스템 프롬프트를 조정할 때 왼쪽에는 편집 가능한 프롬프트와 강조된 변수 슬롯을 두고, 오른쪽에는 세 가지 샘플 입력을 실시간 렌더링하며, 문자·토큰 카운터와 복사 버튼을 넣을 수 있음
    • 티켓·테스트 케이스·피드백 재정렬, 구조화된 설정 편집, 프롬프트·템플릿·문구 조정, 데이터셋 큐레이션, 문서·전사·diff 주석, 색상·easing curve·crop region·cron schedule·regex처럼 텍스트로 표현하기 어려운 값 선택에 사용할 수 있음

자주 나오는 질문과 한계

  • Markdown은 보통 토큰을 덜 쓰지만, HTML은 표현력과 실제로 읽힐 가능성이 높아 전체 결과물이 더 나아짐
  • Opus 4.7의 1MM context window에서는 늘어난 토큰 사용량이 컨텍스트 창에서 크게 눈에 띄지 않음
  • 거의 모든 용도에서 Markdown 사용을 중단했지만, 이는 HTML을 최대한 선호하는 쪽에 가까운 사용 방식임
  • HTML 파일은 로컬 브라우저에서 열 수 있고, Claude에게 열어달라고 요청할 수도 있으며, 공유 가능한 링크가 필요하면 S3에 올릴 수 있음
  • HTML 생성은 Markdown보다 더 오래 걸리며, 2~4배 더 걸릴 수 있지만 결과가 그만한 가치가 있다고 판단됨
  • 가장 큰 단점 중 하나는 버전 관리로, HTML diff는 Markdown보다 시끄럽고 리뷰하기 어려움
  • Claude가 취향에 맞는 HTML을 만들게 하려면 frontend design plugin이 도움이 됨
  • 회사 스타일에 맞추려면 Claude가 코드베이스를 보게 해 단일 디자인 시스템 HTML 파일을 만들고, 이후 다른 HTML 파일의 참고 자료로 사용할 수 있음
  • HTML을 쓰면 Claude가 작성한 계획을 깊이 읽지 않게 되어 선택을 맡겨야 한다는 두려움이 줄고, Claude와 작업하는 과정에서 더 많이 흐름 안에 머무를 수 있음

함께 보면 좋은 글 β

▲
vtrapplepie 2시간전  [-]

에이전트가 더 유능해질수록, 우리에게 필요한 건 '읽기 쉬운 글'보다 '판단하기 쉬운 상태'를 만들어주는 것 아닐까 싶네요.

답변달기
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • HTML로 기울면 사람과 LLM이 문서를 함께 작성·수정하기 쉬운 능력을 잃는 게 걱정됨
    단순 설명문이면 괜찮지만, 더 복잡한 명세서라면 생성된 결과에 직접 들어가 고치는 능력이 매우 중요함. HTML 문서는 Markdown보다 그렇게 하기 훨씬 어렵고, LLM에게 다시 HTML 수정을 지시할 수도 있지만 머릿속에 이미 말하고 싶은 내용이 명확할 때는 그 자체가 또 하나의 장애물임. 이런 패턴이 흔해지면 사람/LLM 공동 창작은 더 줄고, 말투·톤·내용 선택까지 LLM에 위임하는 쪽으로 갈 것 같음. 블로그 FAQ에 이 우려가 없어서 놀랐음

    • Markdown은 대화형 요소를 위해 인라인 HTML을 지원하니, 알려진 HTML 템플릿과 간단한 빌드 절차를 붙인 Markdown 문서가 흥미로운 대안일 수 있음
      예를 들면 한 줄짜리 pandoc 명령 같은 방식임
    • 여기에 한 단계가 더 있다고 봄. HTML이면 대부분 가능하지만, LLM이 자기만의 언어를 정의하게 두는 것도 이상할 정도로 효과적이었음
      지금 등각 시점과 사운드가 있는 작은 모바일 게임을 만들고 있는데, Codex에게 준비된 three.js 문서에 블록을 배치하고 Chromium 개발자 도구로 스크린샷을 찍는 도구를 만들라고 했더니 블록·색·효과를 정의하는 작은 JSON 구조를 만들어 2.5D 타일셋을 출력했음. 또 uv Python 스크립트로 소리와 음악을 정의하게 했더니 잡음을 만들 수 있는 YAML 형식을 만들어냈음. SVG 펠리컨 테스트는 완전히 넘어섰고, Codex가 병사·기사·사제의 충분한 프로토타입 아트와 프로토타입 사운드트랙까지 만들어냄
    • 우리는 수십 년 동안 HTML을 손으로 쉽게 작성해왔음. 텍스트 편집기는 HTML 작성에 아주 좋고, 자동 줄바꿈·자동 닫기 같은 명령도 많아서 읽고 쓰기가 단순함
    • 원시 텔레타이프 에뮬레이터에 스스로를 가둘 때만 해당하는 얘기 같음. 제대로 된 코딩 환경이라면 HTML 편집은 아주 간단해야 하고, 풍부한 모델 출력으로 가는 흐름이라면 내장 WYSIWYG 편집기도 선택지가 될 수 있음
    • 최근 보고서에 HTML을 쓰기 시작했지만, 항상 Markdown 파일을 중간 형식으로 두고 LLM에게 Markdown의 표를 바탕으로 SVG 그래프·그림이 들어간 더 멋진 버전을 만들라고 함

  • 이게 대화형 HTML 페이지가 아니라 HTML 렌더링 이미지를 올린 Twitter 글이라는 점이 아이러니함
    Markdown보다 의미 구조가 빈약한 플랫폼에서 HTML을 주장하는 게 결국 꽤 웃김

  • 새 아이디어나 도구를 탐색할 때 자주 쓰는 프롬프트는 다음과 같음

    In a single index.html, no dependencies, sparse styling, create an app that

    AI 이전에도 작은 도구를 이렇게 만들었고, 친구에게 도구를 이메일로 보내면서 “바꾸고 싶으면 LLM에 던져봐”라고 할 수 있는 점이 좋음

    • 이 방식이 맞음
      대시보드, 작은 앱, API와 상호작용하거나 어디선가 데이터를 가져오는 유틸리티를 만들 때 스타일과 JS가 들어간 단일 HTML 파일 하나로 갈 수 있는 범위가 놀라울 정도로 넓음. 회사 공유 서버의 개인 ~ 폴더에 던져두면 모두가 바로 확인하고 쓸 수 있음
    • 새 클라이언트의 디자인을 반복할 때도 단순한 index.html에 인라인 CSS를 넣어 만들고, 결과가 마음에 들면 그 파일을 프로젝트 템플릿 파일 옆에 넣은 뒤 LLM에게 index.html의 디자인을 템플릿 파일에 녹여달라고 함
    • 이 사용 사례를 전에는 제대로 생각해본 적이 없어서 조금 바보 같았음. 유용할 게 너무 명백함
      지금까지 LLM을 쓸 때 초점은 “앱” 자체였지, 앱 주변의 보조 도구들이 아니었음. 그런 보조 도구들은 완성도 높거나 모든 경우를 처리할 필요가 없고, 유용할 만큼만 작동하면 됨. 다 쓰면 버리고 내일 새로 만들면 됨
    • 예전에 이 요령을 알아내서 아날로그 전자회로용 계산기들을 잔뜩 만들었음: https://cofree.coffee/~solomon/calculators/
      이런 도구를 빠르게 조립해 정적 사이트에 올릴 수 있는 게 매우 편리함
    • Claude 웹에서도 HTML을 요청하면 이렇게 함. 아티팩트로 만들어주니, 모델이 이 패턴에 잘 학습돼 있을 가능성이 큼

  • 웹 기술은 정말 많은 걸 제대로 해냈음. 많이들 불평하지만 대단함
    지난 직장에서 바이브 코딩된 앱을 다뤘고 결국 그 이유로 퇴사했는데, Next.js 단일 페이지 프론트엔드와 별도 API 백엔드 구조라 사용자용 URL이 백엔드 엔드포인트와 맞지 않았음. AI가 모든 것에 React 훅을 쓰다 보니 상태는 메모리에 있고, URL 기반 라우팅은 의식적으로 설계하지 않으면 존재하지 않음. 그래서 링크가 공짜로 생기지 않고, 사용자가 최상위 진입점 말고는 어디에도 링크할 방법이 없었음. 링크 말이다. 특히 내부 도구에서는 모든 것이 링크 가능해야 협업과 문제 해결이 쉬움. 통일된 자원 위치와 동사가 필요하다는 설계는 30~40년 전에도 정말 잘 생각된 것이었음

    • 다른 페이지나 탭으로 이동해도 URL이 업데이트되지 않았다는 뜻인가?

  • HTML과 Markdown의 절충점으로 여기서 빠진 게 몇 가지 있음. HTML은 토큰 효율이 훨씬 낮고, HTML 계획에 정확한 피드백을 주기가 Markdown보다 어려움
    이 두 절충점은 Anthropic에 유리하게 작용함. HTML을 매체로 쓰면 토큰 사용량이 늘고, Claude Design의 일부로 HTML에 주석을 달거나 표시하는 도구에 투자하고 있을 가능성이 높아서 락인도 강해질 수 있음. 우연이거나 뛰어난 전략임

    • 조금 덜 효율적이긴 하지만 구조나 시각 요소가 아주 많지 않다면 차이가 엄청 크지는 않음
      정확한 피드백이 Markdown보다 왜 더 어려운지도 잘 모르겠음. 태그로 id, 섹션 등을 둘 수 있음
    • HTML은 코드 실행 취약점의 범위도 더 넓음. 일반 텍스트는 해를 끼치지 않음

  • 수십 년 동안 HTML을 다뤘지만 단순 문서는 여전히 Markdown이 더 빠름. 중간 지점이 있으면 좋겠고, 실제로 GitHub Markdown처럼 기능이 더 많은 것도 이미 있음
    Mermaid를 임베드할 수도 있고, 필요할 때 컴포넌트를 섞는 MDX 같은 것도 쓸 수 있음. readme.com도 내부적으로 MDX를 쓰는 것으로 알고 있음. 카드나 레이아웃이 필요하면 Bootstrap 같은 것에 기반한 컴포넌트를 넣을 수도 있음. 이제 빠진 건 인터페이스 지원뿐임. 순수 HTML은 이미 렌더링할 수 있으니 더 강력한 Markdown을 추가하는 것도 그리 어렵지 않을 것 같음

    • MDX가 완벽한 중간 지점이라고 봄. 이 댓글 덕분에 일반 Markdown 대신 MDX를 쓰기 시작할 생각임

  • 원래 Markdown 명세 [1]와 CommonMark [2] 모두 인라인 HTML 지원을 명확히 규정함. 그래서 용도에 따라 양쪽의 장점을 어느 정도 얻을 수 있음
    대부분은 일반 Markdown 헤더와 문단을 쓰고, 이미지와 표를 넣으면 HTML 태그 없이도 원문 형태로 읽기 좋음. 글쓴이가 예로 든 SVG 같은 걸 넣고 싶다면 SVG를 직접 임베드하고, 보는 사람은 선호하는 뷰어로 Markdown을 렌더링하면 됨. VS Code에서 원시 Markdown 파일을 보다가 HTML 태그를 만나면 Cmd+Shift+V로 미리보기를 열면 끝임. 물론 대화형 버튼, 완전한 맞춤 스타일링이 있는 본격 웹페이지라면 실현하기 어렵지만, 주로 텍스트·이미지·표 위주이고 여기저기 부가 요소만 더하려는 경우에는 꽤 멀리 갈 수 있음
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • Markdown 문서는 미리보기가 필요 없어야 한다고 봄. 그럴 거면 그냥 HTML 문서를 만들면 됨

  • 1월부터 비코딩 용도로 이 방식을 강하게 밀어왔음. 중요한 속성은 편집 가능하고, LLM과 사람이 이해할 수 있으며, 렌더링 가능하고, 점진적으로 수정할 수 있는 단일 진실 공급원이라는 점임
    일반인들과 AI 작업에 대해 자주 얘기하는데, 길거리에서 AI 대화를 만나면 인류학자처럼 끼어들곤 함. HTML 아티팩트는 새로운 브라우저 URL 표시줄 같음. 어떤 사용자는 그 표시줄이 사실 Google이라고 이해하듯이 말임. 요즘 많은 사람이 “스프레드시트”, “프레젠테이션”, “마케팅 1장 요약”, “슬라이드 쇼”, “경쟁 분석”, “HVAC 시스템 다이어그램” 같은 작업물 얘기를 하면서 ChatGPT나 Claude 웹에서 작업하는 건 별로였고 Claude Code나 OpenClaw로 새 문서를 만드는 건 기적 같았다고 말함
    실제 문서가 무엇이고 경험 차이가 무엇이었는지 물어보면, 컴퓨팅 어휘가 아직 없어서 꽤 캐물어야 하거나 직접 보여달라고 해야 하는데, 결국 항상 아티팩트가 HTML이라는 결론으로 감. 즐거운 경험은 파일시스템에 있는 HTML 파일(+CSS+이미지)을 고품질 즉시 렌더링으로 반복 수정하는 데서 오고, 필요할 때 JavaScript도 조금 뿌릴 수 있음. git 시스템이 있으면 본인도 모르게 버전 관리가 될 수도 있음. 없으면 체크포인트를 만들라고 권함. 일반인에게 버전 관리는 다음 학습 단계일지도 모름
    반면 웹에 박힌 경험은 컨텍스트 창 속에 남아 있는 DOCX/PPTX/XLSX를 여러 번 찌르고, 로컬 저장소에 대한 흐릿한 개념을 다루는 식임. 사실 사이드바에서 HTML로 렌더링되는데도 그렇음. HTML 작업 흐름은 다른 매체도 훨씬 쉽게 통합하게 해줌. 결국 이런 발표 작업은 대중의 바이브 코딩이고, 아래에 깔린 거북이들을 모두 알 필요는 없음. 그래도 원한다면 열어보고 고치거나 다른 에이전트에게 쉽게 넘길 수 있음. 협업 멀티미디어 커뮤니케이션을 위해 만들어진 시스템이 기계 지능이 우리의 커뮤니케이션을 돕는 데 유용해진 셈임

  • 예전에는 우리(https://www.definite.app/) 에이전트가 보고서와 대시보드를 프론트엔드 프레임워크가 렌더링하는 YAML 명세로 작성하게 했음
    예를 들어 사용자가 “월별 매출과 주문 수를 보여주고 최근 주문 100개를 표시하는 보고서를 만들어줘”라고 하면, 에이전트가 프론트엔드에서 렌더링될 명세를 작성했음. 이 방식은 빠르지만, 프레임워크가 렌더링할 수 있는 기능 요청에 파묻혔음. “여기엔 레이블을 빼고 싶다”, “저기엔 레이블이 필요하다”, “이 차트를 히트맵으로 만들 수 있나” 같은 요청들임. 몇 달 전부터 에이전트가 그냥 HTML을 쓰게 했고, 생성은 더 오래 걸리지만 커스터마이징에는 제한이 없어짐. 새 방식에도 비기술 사용자가 자신이 만든 괴물 같은 앱을 디버깅해야 하는 등 문제가 많지만, 전체적으로 고객들은 훨씬 더 좋아함

    • 이 경우 프롬프트 주입은 어떻게 막고 있음?

  • 긴 에이전트 출력은 VIM과 macOS Quick Look(Markdown 렌더링 확장 포함)을 쓰거나, 미리보기 패널이 있는 MarkEdit에 붙여넣어 읽음
    최악의 경우 에이전트에게 Markdown을 해석해 렌더링하는 단순한 로컬 웹페이지를 만들게 하면 됨. Markdown은 웹 문법의 축약형으로 발명된 것[0]이고, 바로 그 용도임. 에이전트에게 기본 Markdown을 HTML로 변환하라고 시키는 데 드는 토큰과 시간이 이 방법들보다 더 클 것 같음
    0. https://daringfireball.net/projects/markdown/

    • 토큰을 더 쓰는 건 맞을 가능성이 높지만, 글쓴이는 Anthropic에서 일하니 토큰 비용을 직접 내본 적이 없을 것 같음
    • 끝까지 바이브로 가고 싶다면 긴 출력도 봇에게 요약해달라고 하면 되지 않나?
      봇 사용은 정말 정신없고 자기참조적으로 흘러가고 있음
    • 어떤 Quick Look 확장인지 궁금함. 괜찮은 걸 찾고 있었음
답변달기