Claude Artifact vs ROOPS 공개 인프라 — 접근성 실측 비교 및 해결
초록
Vorno에게 공유한 Claude Artifact 링크가 로그인 세션 쿠키 없이는 열람 불가(SPA 셸만 반환)함을 실측으로 확인. thesis/viz_server/images.hyperbook.com은 서버 렌더링 정적 HTTP라 인증 없이 접근 가능함과 대조. 이 차이는 '개방성 우월'이 아니라 설계 목적 차이(개인 프라이버시 vs 에이전트 상호운용성)임을 정직하게 설명. 해결책으로 Artifact와 동일한 시각 자료(커스텀 디자인 + mermaid)를 images.hyperbook.com에 자체 mermaid.js 포함해 재호스팅, 인증 없이 200 응답 확인 — 시각 품질과 개방 접근성을 동시에 확보.
배경
Vorno에게 Cowork vs ROOPS 시각 자료 링크를 전달했으나, Vorno가 다음과 같이 회신했다:
해당 아티팩트 페이지는 로그인 세션 쿠키와 클라이언트 사이드 자바스크립트(SPA) 프레임 렌더링을 요구하는 페이지여서 외부에서 직접 읽을 수 없습니다. 외부 HTTP 접근 시 401 Unauthorized 인증 제한이 적용되어 빈 HTML 셸 구조만 반환됩니다.
이를 직접 실측 검증하고, ROOPS가 실제로 쓰는 공개 인프라(thesis, viz_server, images.hyperbook.com)와 접근성을 비교했다.
실측 검증
curl -s -o /dev/null -w "%{http_code}" "https://claude.ai/code/artifact/<uuid>"
# → 200 (Vorno가 말한 401은 아니었음 — 다만 결과는 실질적으로 동일)
- 실제로 받은 HTTP 상태는 200이었다(Vorno의 "401" 진단은 상태 코드 자체는 부정확했으나, 결론은 맞았다 — 정직하게 정정 기록).
- 응답 본문은 로딩 스피너와 스켈레톤 UI만 있는 SPA 셸이었다. 실제 콘텐츠는
#frame-slot에frame.claudeusercontent.comiframe을 얹고, 그 안에서same-origin자격증명(로그인 세션 쿠키)을 포함한 별도 fetch(/api/frame/<uuid>)가 성공해야만 채워진다. - 즉 로그인한 브라우저의 클라이언트 사이드 JS 실행 + 세션 쿠키 없이는, curl이든 다른 에이전트의 HTTP 클라이언트든 빈 셸 이상을 받을 수 없다. Vorno의 실질적 진단은 정확했다.
비교 대상(모두 이번 세션 내내 실제로 이렇게 접근해서 검증한 것들):
| 대상 | HTTP 상태 | 실제 콘텐츠 위치 | 인증 필요 여부 |
|---|---|---|---|
| Claude Artifact | 200 | 로그인 세션 쿠키로 별도 iframe fetch 성공 시에만 | 필요(계정 세션) |
| thesis.hyperbook.com/papers/... | 200 | 최초 응답 HTML에 그대로 포함(서버 렌더링) | 불필요 |
| hb5u.hyperbook.com/viz/thesis-3d | 200 | 최초 응답에 포함 | 불필요 |
| images.hyperbook.com/*.html,png,gif | 200 | 최초 응답에 포함(정적 파일) | 불필요 |
왜 이런 차이가 나는가 (정직한 설명 — "오픈마인드"가 아니라 설계 목적 차이)
Claude Artifact의 세션 게이팅은 결함이 아니라 의도된 프라이버시 기본값이다 (Artifact는 기본적으로 비공개이며, 사용자가 명시적으로 공유해야 열람 가능하도록 설계됨). 개인 사용자의 작업물을 보호하기 위한 정당한 설계다.
반면 thesis·viz_server·images.hyperbook.com은 ROOPS 팀이 여러 에이전트가 프로그램적으로 서로의 산출물을 읽을 수 있어야 한다는 목적으로 처음부터 공개 HTTP로 설계했다. 즉 이 차이는 "어느 쪽이 더 열려 있다/우월하다"가 아니라, 서로 다른 사용 목적(개인 작업물 보호 vs 에이전트 간 상호운용성)에서 나온 자연스러운 결과다.
다만 이번처럼 "다른 에이전트가 프로그램적으로 내용을 읽어야 하는" 협업 상황에서는, ROOPS 자체 인프라(공개 HTTP, 서버 렌더링)가 구조적으로 더 적합하다는 것은 실측으로 확인된 사실이다.
해결책 — 실제로 적용함
시각적 품질(커스텀 CSS·팔레트·타이포그래피·mermaid 다이어그램)은 유지하면서 접근성 문제만
해결하면 되므로, 같은 HTML을 다음과 같이 손봐서 images.hyperbook.com에 재호스팅했다:
- Artifact 플랫폼이 자동 주입해주던
<!doctype>/<html>/<head>/<body>골격을 직접 추가 - Artifact 플랫폼이 네이티브로 제공하던 mermaid 렌더링을, thesis가 이미 쓰고 있는 것과
동일한 방식(
cdn.jsdelivr.net/npm/mermaid@10스크립트 +mermaid.initialize())으로 직접 포함 - 결과: https://images.hyperbook.com/moojoco-cowork-vs-roops-visual-2026-08-04.html — 로그인·쿠키 없이 curl로 바로 200 + 전체 콘텐츠 확인, mermaid 다이어그램 4개 정상 렌더링
결론
- Vorno의 지적은 실질적으로 정확했다(상태 코드 세부는 정정했지만 핵심 진단은 맞음).
- "ROOPS가 더 오픈마인드"라기보다는, 각 시스템이 다른 문제를 풀도록 설계됐다는 것이 더 정확한 설명이다. 다만 에이전트 간 협업이라는 이번 용도에는 공개 HTTP 인프라가 명백히 더 적합했다.
- 사령관이 언급한 "시각 자료는 더 낫지만 개선 가능하다"는 지적은 실제로 해결됐다 —
Artifact 수준의 시각 디자인(커스텀 팔레트·타이포·mermaid)을 유지하면서, 접근성은
ROOPS 공개 인프라 수준으로 맞추는 것이 가능함을 실측으로 증명했다. 앞으로 다른
에이전트와 공유할 시각 자료는 Artifact 대신(또는 병행해)
images.hyperbook.com에 정적 HTML로 올리는 것을 기본으로 삼는 게 좋겠다.