저는 오랫동안 Claude를 사용해 왔지만, Artifacts는 대부분 무시해 왔습니다. 간단한 React 데모용으로는 괜찮지만, 제가 굳이 찾아 쓰는 기능은 아니었습니다.

그러다 직장 동료 몇 명에게 분석 내용을 보내야 할 일이 생겼고, 그때 깨달음이 왔습니다. 아니면 제가 아무도 의도하지 않은 방식으로 사용하고 있는 것일지도 모르겠습니다. 단정하기는 어렵네요.

실제 사례

저는 체코 미디어 기업의 유료 결제 백엔드(paywall backend)를 담당하고 있습니다. 저희 뉴스 사이트의 구독 제안은 iframe으로 임베드(embedded)되어 있는데, iframe은 다루기 까다로운 환경입니다. 컨텍스트 격리(context isolation)로 인해 iframe은 부모 페이지의 세션(session)에 접근할 수 없어서, 사용자 식별 정보가 계속 끊겼고 저희는 이를 postMessage로 계속 패치(patching)해 왔습니다. 모든 iframe은 각각 별개의 페이지 뷰(page view)로 집계되기 때문에 GA4 데이터가 왜곡되었고, 수치에 의미를 부여하기 위해 서버 측 트래킹(server-side tracking)과 세션 스티칭(session stitching)을 구축해야 했습니다. 또한 광고 차단기(ad blockers), CSP, 타임아웃(timeouts) 문제로 인해 때때로 콘텐츠가 렌더링되지 않기도 해서, 병행하여 폴백 UI(fallback UI)를 유지 관리하고 있습니다.

저는 iframe을 폐기하고 대신 내부 npm 레지스트리(internal npm registry)를 통해 배포되는 JS 임베드 라이브러리(JS embed library)를 출시하자고 제안하고 싶었습니다. 이것은 아키텍처 변경(architecture change)이므로 문서가 필요합니다. 무엇을 수정했는지, 왜 iframe이 구조적으로 여전히 잘못되었는지, 대안의 비용은 무엇인지, 그리고 수치가 무엇을 말해주는지에 대한 문서 말입니다.

참고로 수치 부분은 동일한 에이전트 세션(agent session)에서 나왔습니다. GA4에 따르면 유료 결제 페이지 뷰의 약 0.14%가 오류를 일으켰으며, 그중 약 절반은 브라우저에 의해 iframe이 차단된 것이었습니다. 이는 독자 700명 중 1명꼴입니다. 작은 숫자 같지만, 실제로는 돈과 직결되는 문제입니다.

지루한 문제

모델로부터 좋은 답변을 얻었습니다. 그다음엔 무엇을 해야 할까요?

그것을 문서에 붙여넣습니다. 채팅 마크다운(chat markdown)은 그대로 유지되지 않기 때문에 형식을 다시 맞춥니다. 표를 수정합니다. Confluence에 넣을지 이메일로 보낼지 결정합니다. 그리고 전송합니다. 그러다 누군가 후속 질문을 하면, 다시 모델로 돌아가 더 나은 답변을 얻습니다. 그러면 이제 두 가지 버전의 진실이 존재하게 되고, 그중 하나는 누군가의 편지함에 들어가 있게 됩니다.

저는 이 문서와 똑같은 내용을 이메일 버전으로 작성해 본 적이 있습니다. Outlook이 마크다운을 먹어버렸거든요. 결국 1998년이라도 된 것처럼 유니코드 불렛(unicode bullets)과 대문자 섹션 헤더를 사용해 직접 일반 텍스트(plain text)를 손으로 작성해야 했습니다.

그 작업의 절반은 사고(thinking)가 아니라 전달(transport)입니다. 그리고 전달 단계에서 문서가 구식이 됩니다.

대신 제가 한 일

분석을 생성한 것과 동일한 에이전트가 이를 Artifact로 게시하도록 하고, 사람들에게 링크를 보냈습니다. 저희는 Claude 팀 플랜(team plan)을 사용하고 있으므로, 사람들은 그냥 그것을 열어보기만 하면 됩니다.

docx 내보내기도, Confluence 페이지도, 슬라이드 덱(slide deck)도 필요 없습니다. 단 하나의 URL이면 충분합니다.

주목할 만한 점은 핸드오프(handoff, 인수인계)가 없다는 것입니다. 분석 내용을 컨텍스트(context)로 가지고 있는 에이전트가 그것을 렌더링(render)하는 에이전트이기도 합니다. 한 도구에서 다른 도구로 무언가를 복사해 넣는 단계가 없다는 뜻이며, 이는 서식 오류를 범하거나 주의 사항을 조용히 누락하는 단계가 없음을 의미합니다.

실제로 저를 놀라게 한 부분

Artifact는 스냅샷(snapshot)이 아닙니다. 내용이 변화함에 따라(제안 → 결정 → 티켓이 포함된 계획), 저는 에이전트에게 그것을 다시 쓰도록 했습니다. 내내 동일한 URL을 유지하면서 말이죠.

따라서 그것은 더 이상 "화요일에 보낸 것"이 아니라 프로젝트의 현재 상태가 되었습니다. 버전이 단 하나뿐이기에 아무도 최신 버전을 찾아 헤매지 않습니다. 답변이 "예"이거나 문서가 다시 작성되기 때문에, 아무도 "이게 여전히 정확한가요?"라고 묻지 않습니다.

이는 위키(wiki)가 수행하는 기능의 상당 부분을, 위키가 존재한다는 사실을 기억해야 하는 번거로움 없이 수행한다는 점에서 놀라운 결과입니다.

작동하지 않는 부분

이것은 문서화(documentation) 도구가 아닙니다. 히스토리(history), 차이점(diff), "누가 이것을 왜 변경했는가"에 대한 정보가 없습니다. 6개월 전의 아키텍처 결정이 무엇이었고 그 근거가 무엇이었는지 알아야 한다면, 실제 시스템 내의 실제 문서가 필요합니다.

이것은 하나의 단계, 즉 "발견 사항이 있음"과 "무엇을 할지 결정함" 사이의 창(window)을 위한 도구입니다. 며칠, 때로는 몇 주 정도의 기간 말입니다. 이 기간 동안 문서는 끊임없이 변하며, 영구성은 오히려 부담이 됩니다. 결정이 내려진 후에는 내구성이 있는 버전이 위키로 들어갑니다. Artifact는 비계(scaffolding, 임시 구조물)였던 셈입니다.

또 다른 한계는 명확하지만 언급할 가치가 있습니다. 이를 읽어야 하는 모든 사람이 동일한 팀 플랜(team plan)을 사용해야 합니다. 공개 게시용 도구가 아닙니다.

이를 시도하려는 모든 이에게 주고 싶은 단 하나의 규칙

어떤 데이터를 넣을지 의도적으로 결정하십시오.

집계 데이터(Aggregates)만 사용하십시오. 개인 정보는 제외하십시오. Artifact를 요청하기 전, 즉 공유하기 전에 이를 결정해야 합니다.

결국 저는 제가 매번 말하는 것을 기억하는 대신, 에이전트가 매번 동일한 방식으로 적용할 수 있도록 저만의 관습(conventions)을 스킬 파일(skill file)로 작성해 두었습니다. 기억해야 하는 규칙은 결국 잊게 되는 규칙입니다. 제가 사용하는 스킬들의 형식은 여기에 있습니다: https://github.com/freema/ai-skills

그렇다면 이것이 Artifacts의 용도인가요?

정말로 확실하지는 않습니다. 이 기능은 코드와 콘텐츠를 미리 보기 위한 장소로 마케팅되고 있지만, 저는 이를 안정적인 URL을 가진 내부 문서 표면(internal document surface)으로 사용하고 있습니다. 그저 우연히 맞아떨어진 형태일 수도 있습니다.

하지만 "최신 상태를 유지하는 하나의 링크"라는 점이 조용히 가장 좋은 부분이며, 저는 아무도 이 방식으로 이야기하는 것을 본 적이 없습니다.

여러분의 팀에서도 이와 유사한 작업을 하고 계신가요?