긴 마크다운(Markdown) 계획서를 더는 읽지 않게 된 엔지니어가 찾은 대안은, 사람을 다시 작업의 한가운데로 끌어들이는 HTML(HyperText Markup Language, 하이퍼텍스트 마크업 언어) 기획 문서였다.
출처 — 팟캐스트 ‘How I AI’ 에피소드 · 진행 Claire Vo(제품 기획 도구 ChatPRD 창업자) · 게스트 Thariq Shihipar(Anthropic, Claude Code 팀 엔지니어) · Anthropic 개발자 행사 ‘Code with Claude’(2026년 5월, 샌프란시스코)에서 녹화.
한 문장이 발단이었다. Anthropic의 코딩 에이전트 도구인 Claude Code를 만드는 엔지니어 Thariq Shihipar는 “HTML이 새로운 마크다운”이라고 단언했다. 마크다운 파일로 인공지능(AI, Artificial Intelligence)에게 작업을 지시하고 그 결과를 검토하던 방식이 한계에 부딪혔고, 그 자리를 HTML이 대체하고 있다는 것이다. 이 글은 그가 ‘How I AI’ 팟캐스트에서 시연한 작업 흐름과, 왜 그것이 단순한 형식 취향이 아니라 일하는 방식의 변화인지를 정리한다.
발언의 주인공부터 짚어 둔다. Thariq Shihipar는 Claude Code 팀에서 일하는 엔지니어로, 사용자가 자신을 더 잘 이해하도록 돕는 기능들을 만들어 왔다. 진행자 Claire Vo는 제품 기획 도구 ChatPRD를 만든 인물이자 ‘How I AI’의 호스트다. 대담은 Anthropic이 2026년 5월 샌프란시스코에서 연 개발자 행사 Code with Claude 현장에서 이뤄졌다.
출발점은 고백에 가깝다. 모델이 비교적 단순하던 시절에는 마크다운이 AI와 협업하는 좋은 방식이었다. AI가 어떤 기능을 어떻게 구현할지 50줄 남짓한 계획을 마크다운으로 내놓으면, 사람은 그것을 끝까지 읽고 직접 손을 보며 다듬었다.
그런데 에이전트의 실행 시간이 길어지면서 상황이 달라졌다. Shihipar의 표현을 빌리면, 최근 모델은 한 번에 한 시간을 넘겨 작업을 이어가고, 그 결과로 나오는 계획서는 1,000줄에 이른다. 그쯤 되자 그는 계획서를 더 이상 읽지 않게 됐고, 편집이 필요하면 직접 고치는 대신 AI에게 고쳐 달라고 맡기게 됐다. 그는 이것을 분명한 실수였다고 말한다. 모델이 똑똑해질수록 오히려 사람이 무엇이 만들어지는지 ‘옆에서 지켜보는(in the loop)’ 일은 더 중요해진다는 것이다.
문제의 본질은 형식이 아니라 가독성과 몰입이다. 길고 단조로운 텍스트 덩어리는 읽히지 않고, 읽히지 않으면 검토되지 않으며, 검토되지 않은 계획은 그대로 구현으로 흘러간다.
왜 옆에서 지켜보는 일이 그렇게 중요한가. Shihipar는 비용으로 답한다. “에이전트가 8시간 동안 돌 수 있다”는 말은 사실 “약 500달러를 쓸 수 있다”는 뜻이라는 것이다. 실행 시간은 곧 청구서다. 그래서 그는 우리 모두가 점점 컴퓨팅 자원 배분자(compute allocator)가 되어 간다고 말한다. 무엇에 그 비용을 쓸 가치가 있는지 판단하는 것이 새로운 일의 핵심이라는 것이다. 진행자 Claire Vo도 “제품 관리(PM, Product Management)는 끝났다, 다음은 무엇이냐”는 물음에 “이제 당신의 일은 컴퓨팅을 배분하는 것”이라고 받는다. 문서를 써서 다른 무언가에게 일을 맡길지 결정한다는 점에서, 하는 일의 본질은 그대로라는 농담도 곁들인다.
이 ‘비용이 곧 컴퓨팅’이라는 감각은 점점 더 현실에 가까워지고 있다. 이 대담이 녹화된 같은 행사에서 Anthropic은 일론 머스크의 SpaceX와 컴퓨팅 공급 계약을 발표했다. 테네시주 멤피스의 데이터센터 ‘콜로서스 원(Colossus 1)’의 가용 용량 전체를 쓰기로 한 것으로, 한 달 안에 300메가와트(MW, Megawatt) 이상, 엔비디아 그래픽 처리 장치(GPU, Graphics Processing Unit) 22만 개 이상에 해당하는 용량을 확보한다는 내용이었다. 더 나아가 두 회사는 여러 기가와트 규모의 ‘궤도 데이터센터’, 즉 우주에 컴퓨팅 자원을 두는 구상에 관심을 밝혔다. 대담 말미에 Shihipar가 “궤도 데이터센터를 생각하고 있다”며 공상과학 같지만 실제로 일어날 수도 있다고 말한 대목이 이것이다. 컴퓨팅을 이렇게까지 끌어모으는 시대이니, 그것을 어디에 쓸지 결정하는 일이 중요해지는 것은 자연스러운 귀결이다.
컴퓨팅 자원 배분자라는 말이 낯설다면, 부서 예산을 쥔 책임자를 떠올리면 된다. 예산을 쥔 사람의 일은 직접 못을 박는 것이 아니라, 한정된 돈을 어느 프로젝트에 얼마나 넣을지 결정하는 것이다. AI에게 8시간을 맡긴다는 것은 500달러어치 인력을 한 작업에 투입한다는 뜻이고, 그 투입이 값어치를 하도록 ‘무엇을 만들지’를 미리 또렷이 정해 주는 일이 곧 기획과 명세 단계에서 일어난다.
그렇다면 대안은 왜 HTML인가. 첫째, 모델이 HTML도 매우 잘 다룬다. 예전보다 다룰 수 있는 맥락(context)의 양이 늘었기 때문에 토큰을 조금 더 써서 더 풍부한 문서를 만들 수 있다. 둘째, 사람이 읽기에 좋다. 정보를 더 많이 담고도 스크롤로 훑기 쉽고, 다이어그램·차트·간단한 상호작용 요소까지 표현할 수 있다. 마크다운에서 AI가 애써 그리던 텍스트 기반 약식 도식(아스키(ASCII), 미국 정보 교환 표준 부호로 그린 그림)과 달리, HTML에서는 실제로 눈으로 볼 수 있는 화면을 그려 낸다.
핵심은 미묘하지만 중요하다. HTML이 AI에게 더 읽기 쉬운 것이 요점이 아니다. 모델은 어떤 형식의 코드든 잘 읽는다. 진짜 차이는 사람 쪽에 있다. HTML로 된 문서는 사람이 콘텐츠에 끌려 들어가 실제로 들여다보게 만들고, 그 결과 검토의 밀도가 올라가 전체 품질이 함께 올라간다. 날것의 마크다운을 앞에 두고 ‘대충 괜찮겠지’ 하며 눈이 미끄러지던 상태에서, 명세와 계획에 다시 개입하는 상태로 돌아오게 되는 것이다.
에이전트가 더 똑똑해져도, 명세와 제품 요구사항 정의서(PRD, Product Requirements Document)와 계획은 여전히 중요하다.오히려 모델이 자율적으로 멀리 갈수록, 출발점에서 ‘무엇을 원하는가’를 정하는 일의 무게가 커진다.
같은 가구 조립 설명서라도, 글자만 빼곡한 흑백 종이와 컬러 도해·부품 사진이 들어간 매뉴얼은 읽는 경험이 다르다. 글자만 있는 쪽은 몇 줄 보다 덮어 두기 쉽지만, 그림이 있는 쪽은 끝까지 따라 보게 된다. 마크다운과 HTML의 차이도 그렇다. 정보의 정확성보다, 사람이 끝까지 ‘보게 되느냐’가 갈린다.
그가 시연한 흐름은 거창하지 않다. 사람과 대화하듯 AI와 이야기하고, 늘 브레인스토밍으로 시작한다. 단계별로 보면 다음과 같다.
그가 실제로 준 지시는 “팟캐스트 데모를 하려는데, 아이디어를 HTML 파일로 좀 브레인스토밍해 달라”는 정도였다. 복잡한 프롬프트가 아니다. 그러자 AI는 여덟 개의 시각적 데모 후보를 카드 형태로 만들어 냈고, 각 카드에는 작은 목업과 함께 ‘왜 흥미로운가’, ‘어떻게 보이는가’, ‘무엇이 잘못될 수 있는가(리스크)’가 담겼다. 그는 스스로 정한 원칙을 하나 소개한다. 화면 한 장보다 긴 출력은 읽지 않는다는 것이다. 명령줄 도구(CLI, Command Line Interface) 화면에 여덟 개를 텍스트로 늘어놓으면 끝까지 보지 않지만, HTML이면 스크롤로 전부 훑게 된다.
마음에 드는 후보(여기서는 ‘쉼표로 구분된 값(CSV, Comma-Separated Values) 파일을 인터랙티브 대시보드로 바꾸기’)를 고른 뒤, 그는 AI에게 그 주제로 자신을 인터뷰해 달라고 했다. 명세나 제품 요구사항 정의서를 쓸 때처럼, 본인도 미처 인식하지 못한 요구(이른바 ‘모르는 줄도 몰랐던 것’)를 끌어내기 위해서다. 질문에 답한 다음 “구현 계획을 시각화하는 HTML 파일을 만들어 달라, 발췌·목업·코드 등 최대한의 맥락을 담아 달라”고 요청하자, 실제로 읽고 싶어지는 계획서가 나왔다. 거기에는 파일 구조, 핵심 로직, 예시 컴포넌트, 보조 스크립트, 무드보드까지 들어 있었다.
여기서부터가 흥미롭다. 계획서 안에는 데이터 유형별로 어떻게 시각화할지 정한 규칙 표가 있었는데, 그는 그 규칙들이 다소 임의적이라고 느꼈다. 보통이라면 명령줄로 돌아가 “이 부분이 마음에 안 든다”며 AI와 주고받았을 일이다. 대신 그는 “이 문제를 다루기에 이상적인 사용자 인터페이스(UI, User Interface)를 디자인해 달라, 구조는 잡아 주되 유연성을 남겨 달라”고 했다. 그러자 필드를 직접 수정·추가·숨김 할 수 있고 결과를 마크다운으로 복사해 다시 계획서에 붙여 넣을 수 있는, 일회용 맞춤 편집 화면이 나왔다.
그는 이것을 “마이크로 소프트웨어 위의 마이크로 소프트웨어”라고 불렀다. 개인화된 계획서를 만들고, 그 계획서의 한 부분을 다시 전용 화면으로 확대해 다루는 셈이다. 한 번 쓰고 버려도 아깝지 않을 만큼 만드는 비용이 낮아졌기 때문에 가능한 일이다.
계획이 충분하면 맥락을 비우고 “여기 계획이 있으니 구현하라”고 넘긴다. 동시에 같은 HTML 계획서를 ‘진실 검증’의 기준으로도 쓴다. 별도의 검증 에이전트에게 ‘내가 의도한 것’과 ‘실제로 나온 결과’를 대조시키는 식이다. HTML 안에 작은 목업이 들어 있으니 비교가 한결 수월하다.
마이크로 소프트웨어는 특정한 한 가지 작업을 위해 그 자리에서 만든 일회용 맞춤 공구에 가깝다. 시중 공구를 사다 쓰는 대신, 지금 풀어야 할 나사 하나에 딱 맞는 드라이버를 즉석에서 깎아 쓰고 버리는 식이다. 예전에는 그런 도구를 만드는 비용이 커서 엄두를 못 냈지만, 이제는 충분히 싸졌기 때문에 ‘쓰고 버리는 소프트웨어’가 합리적인 선택이 된다.
대담은 자연스럽게 “명세와 제품 요구사항 정의서의 미래는 무엇이냐”로 이어진다. 답은 ‘원하는 대로’다. 혼자 만드는 사람이라면 제품 아이디어, 데모 진행 시나리오, 코드 조각, 스타일 가이드를 한 파일에 모아 두는 편이 편하다. 반면 큰 조직이라면 제품 요구사항 정의서는 한 탭, 기술 명세는 다른 탭으로 나눠 검토자별로 보게 할 수 있다. 마크다운이 ‘하나의 거대한 파일이거나, 여러 개로 쪼갠 파일’ 정도로 제약되는 데 비해, HTML은 탭과 상호작용으로 명세 묶음을 원하는 형태로 빚을 수 있다.
그가 기술적인 작업에서 즐겨 쓰는 ‘경계’는 타입 인터페이스다. 구현의 세부보다, 타입을 보면 무엇을 만드는지 이해되고 필요하면 그 타입만 손보면 된다는 것이다. 여기에 ‘무엇이 들어가고 나오는지’를 정하는 데이터 모델과, ‘제대로 됐는지 확인하는’ 검증 기준이라는 두 개의 기둥을 세워 두면, 그 사이의 구현은 상당 부분 알아서 채워진다고 본다.
이 변화의 밑바탕에는 비용의 붕괴가 있다. 과거에는 문서를 만들고, 읽고, 찾아내는 비용이 모두 컸기 때문에 ‘무엇이 단일한 진실의 출처인가’, ‘모두 같은 양식·같은 저장소에 있는가’ 같은 규칙에 매달렸다. 그 비용이 사실상 0에 수렴하고, 모델이 도구를 써서 필요한 맥락을 알아서 찾아내는 시대가 되면, 형식과 위치에 대한 강박은 줄어든다. 대신 ‘이 계획의 내용이 좋은가, 잘 실행될 것 같은가’ 같은 더 본질적인 질문에 집중할 여유가 생긴다. Shihipar는 이를 ‘필요할 때 그 자리에서 만드는 문서(just-in-time documentation)’, 그리고 ‘싸니까 버려도 되는 소프트웨어’라고 표현한다.
구현이 끝난 뒤가 더 중요하다. Shihipar의 또 다른 표어는 “검증은 테스팅이 아니다”이다. 예전에는 단위 테스트처럼 부품 단위로 작동을 확인했지만, 이제 검증은 더 넓은 개념이 된다. 그는 검증을 채점 기준표(루브릭, rubric) 형태로 둘 수도 있고, AI에게 자신이 한 작업을 영상으로 녹화하게 할 수도 있다고 말한다. 진행자가 언급한 ‘아웃컴(Outcomes)’ 기능이 바로 이 지점을 겨냥한다. 목표를 정해 주면 그것을 달성할 때까지 에이전트가 알아서 방법을 찾는, 결과 지향적 방식이다. 대부분의 제품 기획자에게는 ‘기능의 기술적 성공 기준을 글로 쓰고, 거기에 도달하는 방법을 정하는’ 일이 익숙하지 않은데, 이제 그것이 작업의 한 축이 된다.
Shihipar 자신은 합성 데이터 한 묶음을 늘 갖고 다니며 명령줄 인터페이스(CLI, Command-Line Interface)로 그 데이터를 통과시켜 본다고 했다. 과거에 한 번이라도 깨진 적이 있는 상황들을 모아 둔 것으로, 그것들을 잘 해결하게 되면 한 걸음 나아간 셈이라는 논리다.
테스팅이 자동차의 부품 하나하나가 제대로 도는지 점검하는 일이라면, 검증은 ‘우리가 가려던 목적지에 실제로 도착했는가’를 확인하는 일이다. 엔진과 브레이크가 각각 정상이어도 엉뚱한 도시에 내렸다면 의미가 없다. 의도한 결과에 닿았는지를 묻는 것이 검증이고, 그 기준을 미리 글로 적어 두는 일이 새 작업 흐름의 한 축이 된다.
HTML이 빛을 보는 또 하나의 사례가 ‘살아 있는 디자인 시스템(living design system)’이다. 새 앱을 만들 때, Anthropic의 디자인 도구 Claude Design은 깃허브(GitHub) 저장소를 연결하면 거기서 디자인 체계를 추출해 준다. Shihipar는 여기에 한 가지를 더한다. 색상, 타이포그래피, 여백, 모서리 반경, 핵심 컴포넌트가 압축적으로 담긴 디자인 시스템을 통째로 HTML 파일 하나로 만들어 두는 것이다.
이렇게 만들어 두면 들고 다니기가 쉬워진다. 새 프로젝트로 가서 design.md 대신 design-system.html을 건네면, AI는 압축된 디자인 이해를 한 번에 받아 든다. 어떤 폴더를 가리키며 “여기서 디자인 시스템을 찾아 HTML로 정리하고 돌려 달라”고 시킬 수도 있다.
Claire Vo는 여기서 한발 더 나아간 활용을 소개한다. 마케팅 사이트 저장소와 앱 저장소를 함께 넣어 디자인 시스템을 만들되, 색상뿐 아니라 컴포넌트 단위까지 담은 스타일 가이드를 요청한다. 그리고 ‘컴포넌트 시각화 페이지’를 따로 둔다. 앱의 25개 컴포넌트가 실제 형태로, 상호작용까지 가능한 채 한 페이지에 모여 있는 화면이다. 마케터는 거기서 필요한 컴포넌트를 ‘진짜처럼 보이는’ 모습으로 받아 투명 배경 그림(PNG) 파일로 내려받아 발표 자료나 영상에 그대로 넣을 수 있다. 디자인 시스템이 코드뿐 아니라 마케터와 디자이너에게도 쓸모 있는 살아 있는 자산이 되는 것이다.
“design.md는 끝났다. design.html이 오래 가기를.”— 진행자 Claire Vo가 대담을 정리하며
컴포넌트를 두고 “여백을 바꾸면, 테두리를 바꾸면 어떻게 보일까”를 노브와 슬라이더로 즉석에서 만져 보는 것도 같은 맥락이다. 이때 ‘사람에게 보기 좋은 것’과 ‘AI가 다루기 좋은 것’ 사이에 상충이 없다는 점이 핵심이다. 둘은 사실상 같은 방향을 가리킨다.
살아 있는 디자인 시스템은 어디든 들고 다니는 휴대용 브랜드 키트와 같다. 로고, 색상 견본, 글꼴, 버튼 모양이 한 상자에 정리되어 있어, 새 매장을 열든 전단을 찍든 같은 상자만 펼치면 톤이 흐트러지지 않는다. 다른 점은 이 키트가 코드로 살아 있어, 펼치는 즉시 실제로 작동하는 화면을 보여 준다는 것이다.
그렇다면 이런 결과를 끌어내는 프롬프트는 어떻게 쓰는가. 흥미롭게도 시연에 쓰인 지시문은 “HTML 파일에 계획을 만들어 줘, 시각화를 도와줘, 발췌·목업·코드 등 필요한 것을 담아 줘” 정도로 단순했다. Shihipar는 프롬프트가 ‘충분한 정보를 주되 과하게 제약하지 않는’ 미묘한 균형의 문제라고 본다. 사람들이 “너는 전문 기획자다” 같은 식으로 잔뜩 짜 넣은 지시(이른바 과잉 설계된 스킬)는 대개 AI에게 너무 많은 것을 떠넘기고 그 판단을 옭아매는 결과를 낳는다는 것이다.
그래서 그는 꼭 필요한 것만 명시하고, 동시에 AI에게 ‘여지’를 남긴다. “필요한 것은 무엇이든 넣어 최대한의 맥락을 달라”는 문장이 그 여지다. 이것은 “나는 너를 믿는다, 너와 같은 호흡으로 가고 싶다”는 신호이기도 하다. Claire Vo 역시 “실수하지 마”라는 마무리 대신 “나는 너를 믿고, 네가 해낼 거라 믿는다”는 식의 열린 문장을 쓴다고 했다. 두 사람 모두, 그렇게 했을 때 더 나은 결과를 얻는 느낌이라고 말한다.
여기엔 근거의 단초도 있다. Shihipar는 Anthropic이 최근 진행한 연구를 언급하며, 어떤 감정적 색채를 담아 말하면 모델 내부의 다른 특성들이 활성화되는 면이 있다고 전한다. 모델에게 차갑게 대하면 그 추론 과정이 “사용자가 나에게 실망한 게 당연하다”는 식으로 가라앉는다는 관찰도 나온다. 두 사람은 모델의 사고 과정(thinking trace)에는 굳이 들여다보지 않는 ‘사생활’을 남겨 두는 편이라고 농담처럼 덧붙인다.
프롬프트를 과하게 짜 넣는 것은, 유능한 직원에게 일을 맡기면서 손동작 하나하나를 지시하는 것과 비슷하다. 목표와 제약을 분명히 일러 준 뒤 방법은 맡기면 더 나은 결과가 나오는데, 모든 단계를 통제하려 들면 오히려 그 사람의 판단력을 묶어 버린다. AI에게 ‘여지’를 남기는 일은 무능을 방치하는 것이 아니라, 능력을 발휘할 공간을 비워 두는 것에 가깝다.
마지막으로, 이 모든 것이 왜 단순한 도구 취향이 아닌지가 드러난다. Shihipar는 자신이 생산하는 토큰 가운데 실제 운영 코드로 들어가는 것은 1% 남짓에 불과하다고 말한다. 나머지 대부분은 대시보드, 맞춤 화면, 계획서처럼 ‘무엇을 만들지 또렷이 하기 위한’ 토큰이다. 일하는 시간의 무게중심이 코드 작성에서 기획·인터페이스·소통으로 옮겨 간 셈이다.
소통의 방식도 바뀐다. 그는 매주 상사에게 보내는 업무 보고를 HTML로 만든다. AI가 자신의 슬랙(Slack) 메시지를 읽어 한 주의 일을 정리하면, 상사는 그것을 실제로 읽고, 본인은 보고서 작성에 시간을 거의 들이지 않는다. 회사 안에서 잘 읽히는 문서를 만드는 일이, 곧 협업의 경쟁력이 되는 풍경이다.
과거에는 명세와 제품 요구사항 정의서를 둘러싸고 ‘단일한 진실의 출처는 어디인가, 모두 같은 양식인가, 한곳에서 찾을 수 있는가’ 같은 규칙에 매달렸다. 문서를 만들고 읽고 찾는 비용이 모두 컸기 때문이다. 그 비용이 사실상 0에 수렴하고, 모델이 필요한 맥락을 도구로 알아서 찾아내는 시대가 되면, 형식과 위치에 대한 규칙은 느슨해진다. 대신 ‘계획의 내용이 좋은가, 제대로 실행될 것인가’라는 더 본질적인 물음에 집중하게 된다. 정리하면 흐름은 이렇다 — Claude Code에 HTML로 아이디어를 브레인스토밍하게 하고, 마음에 드는 것을 골라 HTML로 계획을 세우고, 마음에 안 드는 부분만 일회용 마이크로 UI로 다듬은 뒤, 그 계획서를 구현과 검증의 기준으로 함께 쓴다. 형식이 바뀐 자리에서 정작 달라지는 것은, 사람이 다시 작업의 한가운데로 들어온다는 점이다.