출처 https://youtu.be/IlqJqcl8ONE · 채널 Claude (Anthropic) · 길이 00:31:43 포맷 “Code with Claude” 컨퍼런스의 실습 워크숍. Anthropic Applied AI팀 아키텍트 Arnaud Doko가 진행자로, 동료 Tariq의 블로그 글 “The Unreasonable Effectiveness of HTML files”를 바탕으로 청중이 직접 저장소를 클론해 코드를 따라 치는 라이브 데모다. 원본 자막:
raw/transcripts/2026-07-11-how-we-claude-code.en.srt
한눈에 보는 요약
- 모델이 강해질수록 사람이 앞서서 제약을 걸기보다 모델이 요구사항을 캐묻게 두는 편이 낫다. Richard Sutton의 “bitter lesson”을 인용하며, 사용자가 원하는 걸 미리 정확히 말로 옮기기보다 Claude가
AskUserQuestion툴로 인터뷰하며 뽑아내는 쪽이 결과가 좋다고 말한다. - 장기 실행 에이전트를 다루는 세 가지 도구 — 모호함 제거, 이해&계획, 통합 검증. 에이전트가 오래 돌수록 스펙이 부실하면 토큰을 많이 태우고 엉뚱한 방향으로 갈 위험이 커지므로, 이 세 가지를 앞단에 배치해야 한다는 게 이 워크숍 전체의 뼈대다.
- 계획 문서를 Markdown 대신 HTML로 쓴다. 200줄 넘는 Markdown 플랜은 사람도 동료도 잘 안 읽지만, HTML은 정보 밀도가 높고 스크린샷·Playwright MCP로 상호작용하며 검토하기 쉽다. 한 프롬프트로 네 가지 디자인 방향(영수증풍·에디토리얼·브루탈리즘·도쿄 핀테크)을 HTML로 뽑아 나란히 비교하는 실제 사례를 보여준다.
- “검증(verification)“은 테스트가 아니라 에이전트가 스스로 확인할 수 있게 만드는 설계다. 컴포넌트가
data-verify-*DOM 속성으로 자기 상태를 내보내고, 스키마·인버리언트·probe로 구성된 검증 매트릭스를 사람용 대시보드·브라우저 에이전트·헤드리스 CI 세 가지 표면에서 똑같이 돌린다. - 일부러 검증을 깨뜨린 뒤 Claude가 원인을 진단하게 하는 라이브 데모.
3 + 4 ≠ 10처럼 상태를 조작해 검증이 실패하게 만들고, Playwright MCP를 연결한 Claude가 브라우저에서 직접 원인을 찾아내는 과정을 보여준다. 이 검증 실행은 클립으로 녹화되어 팀에 공유하는 증거 자료가 된다. - 결론: Opus 4.7 + fast 모드를 권장하며, “HTML 스펙이 토큰을 더 쓰지 않냐”는 질문에는 장기적으로 반복 횟수가 줄어 오히려 이득이라고 답한다.
장면별 상세 설명
[00:20] 1. 오프닝 — Arnaud Doko, “How we Claude Code”
Anthropic Applied AI팀 소속 Arnaud Doko가 진행을 맡는다(자동 자막은 이름을 “Arno”로 잘못 인식했다). 만석인 워크숍에 감사를 표하며 시작한다. 참가자에게 QR 코드로 저장소를 클론해 코드를 따라 칠 것을 권하고, 기술적 문제가 있으면 도와줄 스태프가 돌아다닌다고 안내한다. 저장소에는 세 단계(phase)가 들어 있고, 그중 검증(verification) 설정은 꽤 상세해서 나중에 직접 더 파봐야 할 거라고 미리 언급한다.
오늘 다루는 내용은 동료 Tariq이 약 열흘 전 샌프란시스코에서 발표하고 블로그 글 “The Unreasonable Effectiveness of HTML files”로 정리한 내용을 바탕으로 한다 — Markdown 파일 대신 HTML 파일로 넘어가자는 주장이다.
[03:59] 2. 세 가지 도구 — 모호함 제거, 이해&계획, 통합 검증
에이전트가 점점 더 유능해지는 이유는 모델 자체가 유능해지고 있기 때문이고, 그래서 에이전트를 더 오래, 더 복잡한 작업에 풀어놓을 수 있게 됐다. 하지만 그만큼 일하는 방식과 습관도 바꿔야 한다. 에이전트를 오래 돌릴수록 초반에 방향을 잘못 잡으면 토큰을 대량으로 낭비하므로, 사람이 원래 스펙 단계에서 하던 검증을 최대한 앞으로 당겨야 한다는 것이 이 슬라이드의 핵심이다.
Richard Sutton의 “bitter lesson”(사람이 아무리 규칙을 정교하게 하드코딩해도 결국 더 많은 데이터·연산을 쏟아부은 쪽이 이긴다는 강화학습의 통찰)을 인용하며, 모델이 사용자보다 요구사항을 더 잘 뽑아낼 수 있다는 유추로 이어진다. 사용자가 원하는 걸 보면 알아도 말로 명확히 설명하는 데는 서툰 것처럼, Claude에게 모든 걸 미리 정의해 넘기기보다 Claude가 되물으며 뽑아내게 하는 편이 낫다는 것. 오늘 다룰 세 가지 도구가 여기서 정리된다: ①모호함 제거 — 에이전트가 커밋하기 전에 사용자를 인터뷰하게 만들기, ②이해와 계획 — 실제로 읽을 수 있는 플랜(Markdown이 아니라 HTML로), ③통합 검증 — 끝에 덧붙이지 않고 처음부터 검증을 내장하기.
[07:07] 3. 좋은 프롬프트 vs 나쁜 프롬프트 — 첫 한 시간이 갈린다
나쁜 프롬프트의 전형은 “그냥 더 낫게 만들어줘(Just make it better)“처럼 사람들이 실제로 흔히 치는 문장이다. 슬라이드는 구체적으로 대비한다 — 나쁜 프롬프트 “친구들끼리 쓸 정산 앱 만들어줘”는 **미지정(under-specified)**이라 에이전트가 알아서 방향을 정하고, 사람은 한 시간 뒤에나 그 결과를 본다. 반면 좋은 프롬프트 “정산 앱을 사람들이 쓰고 싶어할 만하게 만들고 싶은데, 타겟이 누군지 잘 모르겠어. 어떤 방향이 있을지 브레인스토밍 도와줄래?”는 결과(outcome)를 미리 정하지 않고 **관심 영역(domain)**만 던진다 — 그러면 에이전트가 코드를 한 줄도 쓰기 전에 엣지 케이스·타겟층·모르는 것들을 먼저 표면화한다.
핵심은 결과를 과도하게 특정하지 말고 관심 영역을 알려주는 것, 그리고 청중(audience)에 집중하거나 개방형으로 질문을 던져서 Claude가 반복적으로 인터뷰하도록 유도하는 것이다.
[07:52] 4. 실습 준비 — /model, /effort, /fast, 오토 모드
두 개의 Claude Code 세션을 열어두고 청중에게 손을 들어보라며 확인한다 — fast 모드를 써본 사람은 적었고, auto 모드는 다들 쓰고 있어 다행이라며 “auto 모드를 안 쓰고 있다면 지금부터 써야 한다”고 강조한다. 이어서 effort 파라미터를 물어보고, 팀의 추천값은 xhigh이며 자신은 이번 데모에서 xhigh로 맞췄다고 밝힌다(max effort도 선택 가능하다고 언급). 화면에서 /effort(xhigh — high보다 깊은 추론, max 바로 아래 단계, Opus 4.7 전용), /fast(Fast mode ON, 150 per Mtok), 그리고 Shift+Tab으로 순환하는 auto 모드를 차례로 보여준다.
[09:01] 5. 라이브 인터뷰 — AskUserQuestion 툴로 정산 앱 스펙 뽑기
저장소에 들어 있는 프롬프트를 그대로 복사해 붙여넣고, “친구끼리 쓸 정산 앱”이라는 소재로 실제 인터뷰가 시작되는 걸 보여준다. 프롬프트 안에 명시적으로 AskUserQuestion 툴을 언급해 이 워크플로를 트리거했다고 짚는다 — 프롬프트에서 이 툴을 얼마나 구체적으로 지시하느냐가 결과 품질을 가른다는 것. 화면에는 “1차 타겟이 누구인가?”라는 질문에 친구 모임/룸메이트/여행 그룹/이벤트 주최자 같은 선택지가 뜨고, “2차 타겟은 없음”으로 답하는 장면이 이어진다. 이렇게 답을 모으면 스펙 문서가 생성되고, 그 스펙을 바탕으로 서로 다른 여러 구현 방향을 만들 수 있다.
[10:53] 6. Markdown 어제, HTML 오늘 — 플랜의 정보 밀도 차이
Markdown 플랜이 200줄을 넘기기 시작하면 작성자 본인도, 하물며 동료도 잘 읽지 않게 된다. HTML은 같은 정보를 훨씬 밀도 있게, 사람이 다루기 편한(ergonomic) 형태로 담을 수 있고 스크린샷을 찍어 다시 Claude에 피드백으로 먹이거나 나중에 Playwright MCP로 상호작용할 수도 있다는 게 핵심 주장이다. 워크숍 시작 전에 Opus 4.7로 미리 생성해둔 정산 앱 예시들을 이제부터 함께 살펴본다고 예고한다.
[11:20] 7. 네 가지 디자인 방향 — 영수증·에디토리얼·브루탈리즘·도쿄 핀테크
“네 가지 다른 디자인 방향을 뽑아 HTML로 만들고, 서로 비교하면서 설명해줘”라는 한 프롬프트로 Claude가 뽑아낸 결과다. ①Receipt — 옛날 금전 등록기 영수증 느낌, 모노스페이스와 점선, 천공 가장자리. ②Editorial — 주말 특집 매거진 지면풍, Fraunces 세리프와 드롭캡. ③Brutalist Arcade — 거의 검정에 라임그린, 두꺼운 오프셋 그림자, 오버플로우되는 대형 숫자. ④Tokyo Fintech — 부드러운 일본식 모더니즘, 본색 캔버스에 얇은 룰과 넉넉한 여백. 각 카드에서 Overview·Create·Expense·Settle 화면을 하나씩 열어 나란히 비교할 수 있게 되어 있다.
이렇게 완전히 다른 미학을 눈으로 클릭해 보며 피드백을 주는 게, Markdown 파일에서 결과물을 유추하려 애쓰는 것보다 훨씬 낫다고 말한다. 특히 프런트엔드 작업에서는 “여기가 살짝 어긋났다”는 걸 말로 설명하기 어려운데, 스크린샷을 찍어 Claude에 물어보면 (특히 비전 모델이 크게 개선된 Opus 4.7의 경우) 문제를 훨씬 잘 짚어낸다고 강조한다.
[13:01] 8. 세 번째 도구 — “검증은 테스트가 아니다”
지금까지 다룬 것 — Claude가 사용자를 인터뷰하듯 정보를 추출하게 하고, 그 결과를 HTML이라는 더 밀도 높은 폼팩터로 다루는 것 — 을 정리한 뒤, 진짜 핵심은 Claude가 한 일을 어떻게 검증하고, 그걸 에이전트 네이티브하게 만드느냐라고 짚는다. 저장소에는 cwc-workshops 하위에 오늘 세션(“how we Claude Code”)이 있고, phase 1(요구사항 인터뷰)·phase 2(HTML 디자인 방향 4종)·phase 3(검증 프레임워크)로 구성돼 있다고 소개한다. Phase 3는 정산 앱이 아니라 별도의 작은 React 투두 앱을 대상으로 하며, 자세한 내용은 저장소 README와 검증 상세 문서에 있다고 안내한다.
[16:10] 9. Verifiable React — 투두 앱과 DOM 계약
작은 투두 리스트 앱을 라이브로 조작한다 — 항목을 추가하고(“test”), 체크하고, 완료 항목을 지운다. 이렇게 상태가 바뀔 때마다 내부적으로 여러 가지가 함께 움직이는데, 이걸 이미 정의된 테스트와 나란히 검증하고 싶고, 그 검증을 에이전트가 직접 주도하게 만들고 싶다는 게 목표다. 화면 하단 설명에는 “모든 컴포넌트는 data-verify-* DOM 계약을 내보내고, 각 단위는 /verify/:unit/:fixture에 독립된 픽스처를 가지며, 에이전트는 window.__verify를 읽어 구조화된 결과를 얻을 수 있다”고 적혀 있다. 검증은 세 가지 표면에서 똑같이 돌아간다 — 사람이 읽는 대시보드, 에이전트(브라우저·Claude Code)가 직접 주도하는 방식, 그리고 CI에서 돌리는 헤드리스 방식(bun verify 한 줄).
[17:31] 10. DevTools로 DOM 계약 들여다보기
DevTools를 열어 실제 DOM을 살펴본다. todo-app 섹션이 data-verify-total, data-verify-active, data-verify-filter 같은 속성으로 완료/활성 개수, 현재 필터 등의 상태를 직접 내보내고 있다. 항목을 추가하거나 지우면 이 속성값이 즉시 갱신되는 걸 보여준다. 핵심은 컴포넌트가 React 내부 상태와 별도로 이 상태를 DOM에 “발행(publish)“해두면, 에이전트가 React 내부를 스크래핑할 필요 없이 앱이 어떤 상태이든 독립적으로 검증을 돌릴 수 있다는 점이다.
[19:11] 11. 검증 대시보드 — pluggable verifier·스키마·인버리언트
검증 대시보드는 pluggable verifier 네 가지로 구성된다 — schema(픽스처 props를 유닛의 Zod 스키마로 검증), invariants(유닛이 선언한 조건을 DOM에 대해 실행), dom-contract(유닛이 data-verify-* 계약을 제대로 내보내는지 확인), a11y(라벨·role·alt 텍스트 같은 기본 접근성 체크). 각 컴포넌트(TodoItem, TodoInput 등)마다 여러 fixture — 활성 항목, 완료 항목, 빈 텍스트, 긴 텍스트 같은 “probe” — 가 정의돼 있고, 하나씩 개별 실행하거나 “Run all”로 전부 돌릴 수 있다. 이 중 하나는 일부러 실패하도록 심어뒀다고 예고한다.
[22:19] 12. 리플레이 — 일부러 심은 실패(3+4≠10)를 잡아내다
Run all로 전체를 돌리면 미리 심어둔 하나가 의도대로 실패한다 — TodoStats의 inconsistent-counts 픽스처로, “완료 3 + 활성 4가 합계 10과 맞지 않아야 한다”는 걸 일부러 깨뜨려 프레임워크가 실제로 잡아내는지 보여주기 위한 것이다. 콘솔에는 __verify.manifest() 호출 결과로 유닛·fixture·verifier 목록이 트리 구조로 출력된다. 이어서 todo-app의 total/stats 코드를 직접 지워 계약(contract) 자체를 깨는 실험도 한다 — 앱은 멀쩡히 동작하지만 계약이 깨졌으니 그 계약에 의존하는 모든 검증이 줄줄이 실패하는 걸 보여주며, 이건 “앱이 고장 나서”가 아니라 “계약이 고장 나서”라는 점을 강조한다.
[25:23] 13. 코드로 보는 verifyAttrs — TodoApp.tsx
계약이 실제로 어디서 발행되는지 코드 레벨에서 보여준다. TodoApp 컴포넌트는 <section className="todo-app" {...verifyAttrs({ unit: "TodoApp", done: t.stats.done, active: t.stats.active, filter: t.filter, visible: t.visible.length })}>처럼 verifyAttrs 헬퍼를 스프레드해 DOM 속성을 자동 생성한다. 이런 식으로 컴포넌트마다 스키마·픽스처·알려진 상태·인버리언트가 한 세트로 따라붙는 구조라, 이후 Claude가 Playwright MCP를 통해 이 계약을 읽고 왜 특정 검증이 실패했는지(“스키마 거부됨, 4+3이 10과 같지 않음”) 스스로 진단하는 헤드리스 실행으로 이어진다. 발표자는 bun verify를 그대로 돌리면 (일부러 검증만 깨뜨렸을 뿐 로직은 멀쩡하므로) 테스트 자체는 통과한다는 점도 짚는다.
[28:56] 14. 검증을 클립으로 녹화 — 팀에 공유하는 증거
검증을 그냥 통과/실패로만 보는 게 아니라, 각 실행을 짧은 클립(webm)으로 녹화해 “검증이 실제로 통과했다”는 증거로 남길 수 있다는 걸 보여준다. 전체 21개 fixture를 한 번에 다운로드하거나 개별로 받을 수 있고, S3 같은 곳에 올려 동료와 공유하는 식이다. 발표자는 Claude Code 팀이 실제로 거의 모든 프런트엔드 변경에 대해 이런 방식으로 (얼마나 오래 보관하는지는 확실치 않지만) 정기적으로 녹화를 남긴다고 언급한다 — 지금 같은 출시 속도에서는 특히 그렇다고.
[31:33] 15. 마무리 — Thank you
오늘 새로 나온 건 새로운 프리미티브가 아니라, 이미 익숙한 요소들(DOM 속성, 스키마, Playwright MCP 등)을 에이전트가 먼저 쓸 수 있도록 재배열한 것뿐이라고 정리한다. 저장소에 문서가 잘 갖춰져 있으니 시간을 들여 직접 파보라고 권하며, Opus 4.7 + fast 모드를 추천한다(Sonnet은 권하지 않는다고 명시). “HTML 스펙이 토큰을 더 비효율적으로 쓰는 것 아니냐”는 흔한 질문에는, 한 번 생성할 때 토큰을 더 쓰더라도 좋고 풍부한 HTML 스펙 덕분에 장기적으로 반복(iteration) 횟수가 줄어드니 답은 “아니다(no)“라고 답하며 발표를 마친다.
핵심 개념·용어 메모
- Bitter lesson (Richard Sutton) — 사람이 규칙을 정교하게 하드코딩하는 것보다 더 많은 데이터·연산을 투입하는 쪽이 결국 이긴다는 강화학습의 통찰. 이 발표에서는 “모델이 사용자보다 요구사항을 더 잘 추출한다”는 유추로 확장된다.
- AskUserQuestion 툴 — 프롬프트에서 명시적으로 지시해야 트리거되는 인터뷰 워크플로. 선택지형 질문을 반복해 스펙의 모호함을 줄인다.
- HTML 플랜 — Markdown 대신 HTML로 작성하는 계획 문서. 정보 밀도가 높고 스크린샷·Playwright MCP로 상호작용 검토가 쉬워, 200줄 넘는 Markdown보다 실제로 읽힌다.
- DOM 계약(
data-verify-*) — 컴포넌트가 자기 상태(완료/활성 개수, 필터 등)를 DOM 속성으로 직접 발행하는 패턴. React 내부를 스크래핑하지 않고도 에이전트가 상태를 독립적으로 읽을 수 있게 한다. window.__verify— 브라우저 콘솔에서__verify.manifest()(유닛·픽스처·verifier 목록 조회)와__verify.runAll()(전체 검증 실행) 같은 구조화된 핸들을 제공하는 전역 객체.- Pluggable verifier 4종 —
schema(Zod props 검증),invariants(DOM 대상 조건 실행),dom-contract(계약 발행 여부 확인),a11y(기본 접근성 체크). - 검증의 3표면 — 사람이 읽는 대시보드, 에이전트(브라우저 MCP)가 주도하는 실행, CI에서 도는 헤드리스(
bun verify) 실행. 셋이 같은 검증 매트릭스를 공유한다. - 검증 클립 녹화 — 각 fixture 실행을 webm 클립으로 남겨 “검증이 통과했다”는 증거로 팀과 공유. Claude Code 팀이 실제 운영에서 쓰는 방식이라고 언급된다.
등장한 사람·조직·키워드
Arnaud Doko(Anthropic Applied AI팀, Member of Technical Staff), Tariq(Claude Code팀, 블로그 글 “The Unreasonable Effectiveness of HTML files” 저자), Anthropic, Claude Code, Opus 4.7, Richard Sutton(“bitter lesson”), Playwright MCP, Zod, React, Vite, Ghostty, Code with Claude(컨퍼런스).
원문 인용 모음
- [00:49] “I’m here today to tell you how we Claude Code at Anthropic.”
- [04:08] “You should accept that the model is probably better at extracting requirements from you than you are at defining your requirements.”
- [05:34] “The Markdown file is the lingua franca of the AI native software development life cycle.” — 발표자 동료가 한 말이라고 인용.
- [07:03] “Bad prompting is when you say, ‘Just make it better.’ … That’s not good prompting.”
- [10:44] “Especially if the markdown files get more than about 200 lines long, it’s unlikely you’re going to read it, and certainly unlikely that your colleagues are going to read them.”
- [13:05] “The more important part from all of this is how to verify what Claude has done and how to make it agent native.”
- [17:58] “This is what the agent can read later as opposed to having to scrape the DOM.”
- [22:14] “3 + 4 does not equal 10 in this case.”
- [22:48] “The idea is to let something agent native be read as the DOM contract here.”
- [28:05] “The Claude code team records basically all the code changes that they do like this. … especially on the run there at the pace of the shipping that we have at the moment.”
- [30:50] “People will sometimes ask, ‘Well, isn’t a HTML spec more token inefficient?’ And the answer tends to be no … in the long term you iterate less if you have a good and rich HTML spec.”
관련 노트
- moc-claude-code
- 2026-07-10-agent-battle-mine-most-diamonds
- 2026-07-10-ship-your-first-managed-agent
- 2026-07-10-tool-skill-or-subagent
- 2026-07-11-building-the-future-of-agentic-infrastructure — 같은 컨퍼런스, Managed Agents/하네스 철학 좌담
- 2026-07-10-agents-that-remember — 같은 컨퍼런스, Managed Agents 메모리 라이브 데모
- 2026-07-11-evals-for-taste-slide-generation-agent — 같은 컨퍼런스, evals 기반 hill climbing 워크숍(이 노트의 “검증은 테스트가 아니다” 3단계 워크플로우와 짝을 이룸)