이 기사는 X의 원문 기사를 Zenn용으로 재게재한 것입니다.

요약 (TL;DR)

모델이 한 번에 내보내는 양은 계속해서 늘어나고 있지만, 읽는 쪽의 처리 능력은 변하지 않습니다.

이 차이를 어디까지 메울 수 있느냐에 따라 AI와의 협업 질이 결정됩니다.

인지 부하(Cognitive Load) 연구를 토대로, Claude Code 표준인 Artifact tool이 어디까지 대응하고 있으며 어디가 부족한지를 정리하고, 그 부족함을 채워줄 RHW https://github.com/u-ichi/reviewable-html-workbench 를 소개합니다.

서론

Claude Code에는 Artifact tool이 표준으로 포함되어 있습니다. HTML을 작성하면 보기 좋은 페이지가 되고, 디자인 지침을 가진 skill이 붙으며, Mermaid와 syntax highlight도 동봉되어 있습니다. 한 번 만들고 읽고 끝나는 자료라면 일정 수준의 니즈를 충족합니다.

이 기사에서 다루는 Reviewable HTML Workbench (RHW)는 동일한 'HTML을 결과물로 만든다'는 과제를 다루지만, 결과물을 만들고 자료에 지적·코멘트를 넣어 수정하는 생성형 AI와의 협업 과정에서 발생하는 왕복 작업 중 부족한 부분을 채우기 위해 만들어졌습니다.

또 하나, 기밀을 다루는 환경에서는 운용상의 주의점도 있습니다. Artifact의 생성물이 Google 검색 결과에 대량으로 노출되고 있었다는 사실이 2026-07에 밝혀졌고, Anthropic이 이에 대한 대처를 진행했습니다. 이 경위는 'Artifact에 부족한 점'의 한 항목으로 언급하고 왜 그렇게 되었는지를 이어지는 절에서 다루겠지만, 개발 측면에서 Artifact를 사용하기 어려운 시기는 앞으로도 계속될 것이라 생각하기에, 그 사이의 대안으로서 RHW를 제안하고자 합니다.

왜 HTML을 결과물로 만드는가

모델이 한 번에 내보내는 양은 계속해서 늘어나고 있지만, 읽는 쪽의 처리 능력은 변하지 않습니다. 이 차이를 어디까지 메울 수 있느냐에 따라 AI와의 협업 질이 결정됩니다. RHW를 만드는 이유는 여기에 있습니다. 오해를 피하기 위해 덧붙이자면, 문제는 '읽지 않는 것'이 아닙니다. 읽습니다. 다만, 읽었는데도 이해에 이르지 못하거나, 이해하기 위한 부하가 너무 높아서 본래 그곳에 써야 할 주의력을 소모해 버리는 것이 문제입니다. 인지 부하 연구에서는 이 두 가지를 별개의 것으로 취급합니다.

부하의 종류를 나누기

이번에 해결하고자 하는 것은 중간 단계인 외재적 부하 (extraneous load)를 낮추는 것입니다. 낮춘 만큼 문제 그 자체를 생각하는 부하 (germane load)로 전환되어 판단의 질이 올라갑니다. 내재적 부하 (intrinsic load)는 대상의 복잡성 그 자체이므로 줄어들지 않습니다. 이를 줄이려 하면 내용을 깎아내거나 단순화하게 되는데, 이는 또 다른 문제를 야기합니다.

표 1: 3가지 종류의 인지 부하와 agent의 출력을 읽을 때의 대응

출력량이 늘어나면 어떤 일이 발생하는가

2026년 4월 CHI 워크숍에서 발표된 연구가 이 부하의 분포를 실제로 관찰하고 있습니다 (Catalan et al.). Samsung R&D Institute Philippines와 York University 그룹이 경력 1년 미만부터 10년 초과까지 4명의 소프트웨어 엔지니어에게 Cline으로 코드 생성 태스크를 수행하게 하고, Bloom's Taxonomy (회상·이해·분석·평가 단계로 이해의 깊이를 측정하는 프레임워크)를 통해 인지적 관여 수준을 측정한 것입니다.

계획 단계에서는 4명 모두 충분한 인지 자원을 사용하고 있었습니다. 프롬프트의 의도를 확인하고, 작업 디렉토리의 파일을 검증하며, "이것은 어떤 문맥인가"라고 소리 내어 되묻는 사람도 있었습니다. 이 단락을 읽고 있는 분들이 느끼는 실감과도 비슷할 것입니다. 이 단계는 문제 그 자체를 생각하는 부하 (germane load)가 작동하고 있는 상태입니다.

변화는 agent가 실행을 시작하면서부터 일어납니다. 참가자들은 이 상태를 "정보 던져주기 (information dump)"라고 표현했으며, 연구자들은 그것이 외재적 인지 부하 (extraneous cognitive load)로 처리되었다고 기록하고 있습니다. 내용이 어려웠던 것이 아니라, 전달되는 방식 때문에 소모되었다는 분류입니다. 그 원인에 대한 기술이 이 기사의 주제로 직접 연결됩니다.

Cline의 text-only communication(텍스트 전용 통신)에 대한 의존은 추가적인 시각적 또는 상호작용적 지원 없이 사용자가 밀도 높고 구조화되지 않은 정보를 파싱(parse)하도록 요구함으로써 이러한 외재적 부하를 더욱 증폭시켰을 수 있습니다.

텍스트로만 전달되면, 밀도가 높고 구조가 없는 정보를 사람이 스스로 풀어내는 과정이 끼어듭니다. 어디가 결론이고 어디가 근거인지, 제시된 세 가지 선택지 중 무엇이 권장되는지, 이 표와 저 표의 어느 열이 대응하는지 등을 머릿속에서 재구성하는 동안, 내용 그 자체를 생각할 여력은 깎여 나갑니다.

이는 읽을 의지가 있는지 여부와는 무관하게 발생합니다. 동일한 종류의 부하가 지적 사항을 돌려줄 때도 발생합니다. 자료를 읽고 "이 부분은 다르다"라고 깨달았다고 가정했을 때, 이를 전달하려면 자료에서 눈을 떼고 "3장의 후반부쯤, 근거가 부족하다고 느낀 부분"과 같이 위치를 말로 다시 만들어내야 합니다.

읽어서 깨달은 것을 읽은 장소로부터 분리하여 운반하는 작업입니다. 왕복이 늘어날수록 이 작업은 매번 누적됩니다. 부하가 높으면 "뭐, 괜찮겠지"라며 흘려보내는 방향으로 작용합니다. 깨달았음에도 전달하지 않는, 일종의 놓침(drop)입니다.

읽었음에도 남지 않는 것

동일한 연구는 읽은 후에 무엇이 남았는지도 측정하고 있습니다. 태스크 종료 직후의 질문에서, 생성된 스크립트에 함수가 몇 개 있었는지 정확히 대답한 사람은 4명 중 0명이었습니다. 첫 번째 함수의 요약을 확실히 제시할 수 있다고 답한 사람은 절반이었습니다. 입력 파일이 하나도 없는 경우를 적절히 분석할 수 있는지 분석하고 자신 있다고 답한 사람도 절반뿐이었습니다.

그럼에도 4명 전원이 "변경은 불필요하다"라고 판단했습니다. "원하는 출력이 나왔다", "Cline을 신뢰한다", "작동한다", "잘 작성되어 읽기 편해 보이므로 변경이 필요하다고 생각하지 않았다". 연구자들은 이를 **greedy allocation strategy (탐욕적 할당 전략)**라고 부릅니다. 완료를 확인할 수 있는 최소 비용의 검사로 끝내고, 표면적인 검증이 실패했을 때만 깊게 읽는 것입니다. 4명이 파악하고 있었던 것은 happy path — 정답에 이르는 단 하나의 경로뿐이었습니다.

이 지점이 협업의 질과 직결됩니다. agent의 출력을 검증할 수 없다면, agent가 틀렸을 때 알아차릴 사람이 없습니다. 출력량이 늘어날수록 이 상태에 빠지기 쉬워집니다.

연구가 보여주는 방향

논문의 마지막에 설계에 대한 두 가지 제안이 올라와 있습니다. 둘 다 이 기사에서 HTML을 결과물로 만드는 이유 그 자체입니다.

첫 번째: 문자로만 전달하는 것을 그만둘 것

계획이나 판단의 논거를 도표나 표를 통해 알아볼 수 있는 형태로 전달합니다. 논문은 플로우차트, 그래프, 마인드맵을 예로 들고 있습니다. 근거로 인용된 것은 학습 현장에서의 연구입니다. 설명 수단을 복합적으로 조합하면 학습자가 느끼는 부하가 명확히 낮아지며, 내용이 기억에 남는 정도와 나중에 떠올릴 수 있는 정도가 모두 개선되었다는 결과가 나왔습니다. 앞 절에서 나눈 세 가지 종류 중, 제시 방식의 미흡함에서 발생하는 부하를 낮추는 방향입니다.

두 번째: 읽는 쪽의 손을 멈추고 생각하게 할 것

agent가 답을 다 내놓기 전에 흐름을 한 번 멈추고, 읽는 쪽이 스스로 판단하게 합니다. 동일한 저자의 다른 연구에서는 AI의 제안을 먼저 보여주지 않고 사용자가 자신의 판단을 내린 후에 보여주는 방식을 취했을 때, 평가의 정확도가 높아졌다고 보고되었습니다. 답을 먼저 보면 그에 끌려가 스스로 생각하지 않게 되기 때문입니다.

이것은 문제 그 자체를 생각하는 데 향하는 부하를 늘리는 방향입니다. 부하를 늘린다고 하면 역설적으로 들리겠지만, 늘리고 싶은 것은 바로 이 종류뿐입니다. 제시 방식의 미흡함에서 오는 부하를 낮추면, 그만큼이 이쪽으로 돌아옵니다.

HTML을 결과물로 만드는 이유

첫 번째 논점에 해당하는 것이 표, 도표, 색상, 제목을 통한 구조화입니다. 어디가 결론이고 어디가 근거인지를 재구성하는 작업을 agent 측에서 미리 끝내버리는 것입니다. Claude Code는 Artifact tool을 통해 이에 응답하고 있습니다.

두 번째 논점은 읽는 사람이 직접 움직이게 만드는 메커니즘입니다. 코멘트를 달기 위해서는 본문의 어딘가를 선택해야만 합니다. 이는 "대충 알겠다"며 그냥 읽고 지나칠 수 없게 만듭니다. RHW가 추가한 기능이 바로 이 지점이며, 설계 단계에서 읽고 지나치는 행위를 멈추게 합니다.

이 메커니즘에는 또 다른 효과가 있습니다. 지적 사항을 적는 위치가 자료 내부에 있다면, "3장의 후반부쯤에 있는..."과 같이 위치를 말로 다시 설명하는 작업이 필요 없습니다. 생각하게 만드는 측면뿐만 아니라, 불필요한 부하를 줄이는 측면에서도 동시에 효과가 있습니다. 자료가 단순히 읽기 위한 용도인 한, 읽는 사람은 그곳에서 생각한 내용을 매번 어딘가로 옮겨야만 하기 때문입니다.

Artifact의 편리한 점

Artifact가 해결하고 있는 것은 "만든 것을 사람에게 보여주는" 과정의 번거로움입니다. 공식 문서(docs)와 이용자들의 글 모두 이 점을 공통적으로 언급하고 있습니다. 사용하는 입장에서 본 강점은 4가지가 있습니다.

1. "이것 좀 봐"로 끝나는 작업에서 왕복 과정이 사라짐

터미널(terminal) 출력을 Slack에 붙여넣거나, 스크린샷을 찍어 보내거나, 리뷰어에게 브랜치(branch)를 클론(clone)하게 하는 등의 왕복 과정이 링크 하나로 대체됩니다. 실제로 운용 중인 사람의 글에 따르면, PR 리뷰가 "차이점(diff)·판단 근거·직접 만져보며 확인할 수 있는 부분이 한 페이지에 담겨 있어, 리뷰어가 클론하지 않고도 전체를 파악할 수 있는" 형태가 되었다고 합니다. 아침 회의의 진척 공유도 모두가 동일한 URL을 보고 있는 상태에서 해결됩니다. 시간이 오래 걸리는 작업이라면, 에이전트(agent)가 진척 상황을 계속 기록하는 페이지를 북마크해 두면 터미널을 들여다보지 않고도 상황을 파악할 수 있습니다.

2. 대화가 흘러가도 결과물이 남고, 버전이 쌓임

채팅이 길어지면 중간에 만든 것이 어디에 있는지 알 수 없게 됩니다. Artifact는 대화와는 별도의 장소에 결과물을 보관하며, 업데이트를 해도 동일한 URL을 유지합니다. 게시(publish)할 때마다 버전이 하나씩 쌓이며, 보여줄 버전을 선택할 수 있습니다. 이용자는 "끝이 없는 스레드 속에서 진척 상황을 놓치지 않고, 몇 번이고 손을 댈 수 있다"는 점을 장점으로 꼽았습니다.

3. 직접 만져보며 테스트하고, 결과를 세션으로 되돌릴 수 있음

단순히 읽기만 하는 페이지로 끝나지 않습니다. 값을 조절하는 슬라이더, 전환 토글(toggle), 정렬 가능한 카드 등을 배치할 수 있습니다. 문서(docs)에 있는 예시에서는 이슈(issue)를 드래그하여 정렬하는 트리아지 보드(triage board)를 만들고, 마지막에 "Copy as prompt" 버튼으로 정렬 순서를 추출하여 그대로 Claude Code에 다시 붙여넣습니다. 직접 만져보며 결정한 사항이 다시 작업으로 돌아오는 형태입니다. MCP 커넥터(connector)를 연결하면, 페이지를 연 사람의 계정으로 최신 데이터를 가져오는 대시보드(dashboard)로도 만들 수 있습니다.

4. 외관을 지시하지 않아도 읽기 좋은 형태로 반환됨

내용만 전달하면 색상·글자 크기·여백·표의 표현 방식은 Artifact 측에서 결정합니다. "AI스러운 모습으로 만들지 마"라고 매번 쓸 필요가 없습니다. 나아가 프로젝트의 CLAUDE.md에 회사의 색상·폰트·여백 값을 적어두면, 이를 우선적으로 따릅니다. 제품의 브랜드에 맞춘 페이지가 별도의 지시 없이도 생성됩니다. "내용뿐만 아니라 내용의 정돈 상태가 좋다"라는 이용자의 감상은 바로 이 부분을 의미합니다.

Artifact에 부족한 점

한 번 만들어 읽는 자료로서는 충분하지만, 그 자료에 지적 사항을 넣어 수정본을 만드는 왕복 과정에는 적합하지 않습니다.

부족한 점은 다음 3가지입니다. 마지막 한 가지는 왕복의 용이함이 아니라, 기밀을 다루는 환경에서의 안전성에 관한 이야기입니다.

• 자료 위에서 대화할 수 없습니다. 생성된 Artifact에 "이 단락의 3행째, 근거가 부족함"이라고 포스트잇을 붙일 수 있는 수단이 없습니다. 피드백은 채팅 본문으로 되돌릴 수밖에 없으며, 읽는 사람은 지적할 때마다 "3장의 후반부쯤의..."와 같이 위치를 말로 다시 설명해야 합니다. 에이전트 (agent) 측에도 "문서의 어느 부분에 대한 지적인지"가 전달되지 않습니다. 이로 인한 폐해는 3가지가 있습니다. (1) 위치를 다시 설명하는 수고가 왕복할 때마다 쌓이며, 번거로우면 그냥 넘겨버리기 때문에 발견된 문제가 전달되지 않은 채 남게 됩니다. (2) 지적 사항과 그에 대한 답변이 채팅 이력에 흩어져서, 왜 이런 기술이 되었는지 나중에 추적할 수 없습니다. (3) 자료를 보고 있는 사람이 여러 명일 경우, 누가 어디를 지적했는지를 사람이 직접 대조해야 합니다. -
  생성물이 로컬에 남지 않습니다. Artifact는 claude.ai 상의 URL로 만들어집니다. 수중에 있는 리포지토리 (repository)에 커밋 (commit) 하여 차분을 추적하거나, 사내 위키 (wiki)에 삽입하는 등의 취급이 불가능합니다. 자료의 버전을 추적할 수 있는 것은 claude.ai 상의 버전 이력뿐이며, 코드의 변경과 자료의 변경을 동일한 커밋 (commit)에 묶을 수도 없습니다. -
  의도치 않은 공개가 발생한 사례가 있습니다. 생성물이 claude.ai 상에 놓이는 이상, URL이 외부로 유출되면 내용도 외부에서 읽을 수 있습니다. 2026-07-25, Artifact의 URL이 Google 검색 결과에 대량으로 노출되고 있다는 사실이 Reddit에서 발견되었습니다. 색인화 (indexing)된 내용에는 의료 기록, 임상 시험 결과, 급여표, CRM export, 미발표 로드맵, 암호화 월렛 (crypto wallet)의 시드 구절 (seed phrase), 아이의 이름과 전화번호 등이 포함되어 있었습니다. Anthropic은 다음 날인 07-26에 조치를 취했고, 07-28에는 검색 결과에서 사라졌습니다. 다만 2025년에도 Forbes가 유사한 사례를 약 600건 보도한 바 있으며, 이번이 두 번째 사례입니다.

왜 의도치 않게 공개되었는지는 다음 절에서 다룹니다.

왜 의도치 않게 공개되었는가

전 절 마지막에 언급한 색인화 (indexing)는 하나의 버그가 아니라, 세 가지 문제가 겹친 결과입니다. 이를 단순히 버그라고 치부하면 재발 방지 논의를 할 수 없으므로, 차례대로 살펴보겠습니다.

1 (tool description): 에이전트 (agent)가 자신의 판단으로 게시 (publish) 해도 되는 것으로 되어 있음

Claude Code 2.1.220 바이너리 (binary)에서 추출한 Artifact 도구 (tool)의 설명 (description)에는 다음과 같은 구절이 있습니다 (원문 인용).

Render an HTML or Markdown file to an Artifact — a default-private web page hosted on
claude.ai that the user can later choose to share with their teammates. (중략)
Publishing proactively is fine for your own work-product — artifacts start private.
...

두 번째 문장인 Publishing proactively is fine for your own work-product에 의해, 에이전트 (agent)는 "이것은 자신의 작업 결과물이다"라고 판단할 수 있다면 게시 (publish)를 먼저 완료해도 된다는 의미가 됩니다. 첫 번째 게시 (publish)에는 승인이 필요하며, 공식 문서 (docs)에 따르면 Claude는 "Deploy failures by service" (deploy-failures.html)와 같은 문구를 claude.ai의 비공개 페이지에 게시하고자 한다고 되어 있습니다. 다만 문서 (docs) 자체에 "동일한 artifact의 재게시 (re-publish) 시에는 두 번째 확인이 나타나지 않는다"라고 적혀 있어, 한 번 통과하면 그 이후에는 에이전트 (agent)의 판단에 따라 업데이트가 계속됩니다. "기밀이라면 파일 (file)로 하라"는 예외는 있지만, 기밀인지 여부를 판단하는 것은 에이전트 (agent) 측입니다.

2 (공유 수단): Pro / Max 플랜에서는 공개 링크가 유일한 공유 방법

이것이 색인화(indexing)의 구조적인 원인입니다. 공식 문서(docs)는 공유 대상을 플랜별로 구분하고 있습니다. Team / Enterprise 플랜이라면 조직 내의 특정 인원이나 전원에게만 보여줄 수 있으며, 외부 공개는 조직의 소유자(Owner)가 명시적으로 활성화하기 전까지는 사용할 수 없습니다. 반면 Pro / Max 플랜에서는, **"a public link is the only way to share an artifact" (공개 링크가 아티팩트를 공유하는 유일한 방법이다)**라고 명시되어 있습니다. 개인 플랜 이용자가 "동료에게 보여주고 싶다"고 생각하는 시점에서, 인터넷 전체에 공개하는 것 외에는 다른 선택지가 없습니다. 의료 기록이나 급여 명세서가 색인에 올라온 것은 기밀을 가볍게 다루었기 때문이 아니라, 보여주기 위한 수단이 공개뿐이었기 때문이라고 읽을 수 있습니다. 게다가, 승인 시점에 외부 전송이 충분히 전달되지 않는다는 지적도 있습니다. GitHub issue #74928은, artifact가 영어로 '성과물'을 의미하는 일반 명사이기 때문에, 승인 화면의 문구가 "파일을 만든다"로 읽혀 승인을 오유도(misleading)한다고 언급하고 있습니다.

3 (index 제어): robots.txt의 Disallow를 noindex 대신 사용하고 있었다

문제가 발견된 시점에 Anthropic 사이트의 /robots.txt는 Artifact URL의 일부를 Disallow 하고 있었습니다. 하지만 이 Disallow는 공개되어 있는 /public/artifacts/ 경로에는 적용되지 않았습니다. 게다가 Disallow는 "크롤러가 읽지 못하게 하는 것"이지 "검색 결과에 나오지 않게 하는 것"이 아닙니다. Google 측에도 x-robots-tag: none은 반환되고 있었으나, Disallow로 인해 읽을 수 없는 URL의 x-robots-tag는 Googlebot이 확인할 수 없었고, 결과적으로 외부 링크를 통해 URL만 색인(index)에 올라가는 상태가 되었습니다. Google Search Central의 John Mueller는 이러한 오용을 오랫동안 반복해서 주의시켜 왔습니다.

"Block search indexing with noindex"에서도 "Disallow는 index 제어가 아니며, noindex 메타태그 또는 HTTP 헤더를 사용하라"고 명시되어 있습니다.

연표

2026-07-25 Reddit에서 "Google 검색에 내 Artifact가 나왔다"는 발견이 게시됨

2026-07-26 Anthropic이 조치를 취함 (noindex 추가)

2026-07-27 The Verge / Ars Technica가 보도

2026-07-28 검색 결과에서 Artifact URL이 사라짐

수정된 것은 index 제어 (3) 부분입니다. proactive publish를 허용하는 tool description은 이 글을 쓰고 있는 2.1.220 버전에서도 동일한 문구이며, Pro / Max의 공유 수단이 공개 링크뿐이라는 점도 문서(docs)의 기술 내용과 일치합니다. 즉, "공개하면 검색에 노출되는" 경로는 차단되었지만, "보여주려면 공개할 수밖에 없는" 구조는 남아 있습니다. 현재로서는 기밀을 다루는 환경에서는 사용을 중단할 수밖에 없습니다.

Claude Code의 Artifact tool을 사용할 수 없는 조건

문서(docs)에서 언급한 조건 중, 기밀을 다루는 조직과 관련된 것은 다음과 같습니다.

API 키, LLM gateway token, 클라우드 사업자의 자격 증명(credentials)으로 구동 중인 세션에서는 publish 할 수 없습니다 (/login을 통한 claude.ai 계정 로그인이 필요합니다)

Amazon Bedrock, Google Cloud의 Agent Platform, Microsoft Foundry를 통해서는 사용할 수 없습니다

Agent SDK, GitHub Action, MCP 서버 문맥에서는 기본적으로 꺼져(off) 있습니다

이 경우에 해당하면, Claude는 로컬 HTML 파일을 작성하거나 publish 할 수 없다고 답변합니다. 그러한 상황에서는 RHW와 같이 로컬에서 완결되는 메커니즘이 처음부터 더 잘 맞습니다.

RHW가 제공하는 것

RHW(reviewable-html-workbench)는 Artifact가 제공하는 기능들을 전반적으로 충족합니다. 시각적인 지시를 내리지 않아도 읽을 수 있는 형태로 결과가 돌아옵니다. 직접 만져보고 작동하는 페이지를 만들 수 있습니다. Mermaid와 코드 하이라이팅(Code Coloring)이 포함되어 있습니다. 여기까지는 동일합니다. 그 위에 리뷰(Review)의 왕복 과정을 크게 개선하는 기능을 추가했습니다. 이름의 R은 Reviewable을 의미합니다. 리뷰할 수 있다는 것이 첫 번째 목적이며, 다른 기능들은 이를 위해 존재합니다. 아래에는 Artifact와의 차이점만을 나열합니다.

자료 위에서 agent와 대화할 수 있음

Artifact에는 지적 사항을 적을 공간이 없습니다. 신경 쓰이는 부분이 있다면 자료를 벗어나 채팅으로 돌아가서, "3장의 후반부쯤, 근거가 부족하다고 느껴지는 부분"과 같이 말로 위치를 다시 지정해야 합니다. 자료를 보며 생각한 것을 자료 밖으로 가지고 나와 다시 전달하는 공정이 필요합니다.

RHW에서는 특정 부분을 선택하여 코멘트(Comment)를 답니다. 코멘트는 스레드(Thread)가 되며, agent가 해당 위치에 답장합니다. "이 부분은 근거가 부족하다"라고 쓰면, agent가 동일한 단락 아래에서 답변합니다. 해결된 것은 resolved 상태로 만들어 자료 본체에 반영하는 운영이 가능합니다. 이 기사 또한 그러한 왕복 과정을 통해 다시 작성되었습니다. 바뀌는 점은 두 가지입니다.

하나는 위치를 말로 다시 지정하는 공정이 사라진다는 것입니다. 지적이 문서의 어느 부분을 향한 것인지가 agent 측에도 그대로 전달됩니다.

또 하나는 지적 사항과 그 답변이 자료 안에 남는다는 것입니다. 채팅 이력을 거슬러 올라가지 않아도, 왜 이러한 기술이 되었는지를 같은 장소에서 읽을 수 있습니다. 이 경로가 앞 절에서 언급한 germane을 늘리는 측면입니다. 코멘트를 달기 위해서는 본문의 어딘가를 선택해야만 합니다. "대충 알겠다"며 그냥 넘길 수 없게 됩니다.

액세스 제어를 할 수 있으면서 자료가 수중에 남음

Artifact는 claude.ai 상의 URL로 생성됩니다. RHW의 생성물은 자신의 디스크에 있는 파일입니다. 리포지토리(Repository)에 커밋(commit)하여 차이(diff)를 추적할 수 있습니다. 사내 위키(wiki)에 붙여넣을 수 있습니다. 외부 호스트에 URL이 발행되지 않습니다. 다른 사람에게 보여줄 때는 프리뷰(preview)를 실행합니다. 사내에서 보여주고 싶다면 Tailscale의 IP를, 개인적으로만 보고 싶다면 127.0.0.1에 바인드(bind)합니다. 네트워크 전체에 개방하는 설정은 금지되어 있습니다. 리뷰가 끝난 자료는 하나의 HTML 파일로 내보낼 수 있습니다. 그 파일을 전달하면 서버 없이도 그림 확대 기능은 작동합니다 (직접 만져보며 결정한 결과의 공유에만 서버가 필요합니다).

멀티 에이전트(Multi-agent)로 이용 가능

RHW는 현재 Claude Code뿐만 아니라 Codex에서도 이용 가능합니다. 생성형 AI의 상황이 변화하는 가운데 공통적으로 문서 출력을 가능하게 함으로써 플랫폼 의존성을 피할 수 있으며, 상황에 따라 그때그때 적합한 메커니즘을 기동적으로 이용할 수 있습니다.

요약

Artifact는 "한 번에 보기 쉬운 HTML을 만들기" 위해 설계되었으며, 그것 단독으로도 상당히 편리하게 사용할 수 있습니다.

읽고 끝나는 자료라면 이것으로 충분하지만, 설계 측면에서도 특히 액세스 권한 주변이 복잡하여 실수로 인한 사고가 발생하기 쉽다는 점과, 애초에 대화형 AI와의 협업 기능이 아직 없다는 점을 RHW로 메웠습니다.

Discussion