Claude Code Artifacts MCP connectors, 팀 라이브 대시보드 공유 전에 정리할 기준 | DAKER 커뮤니티
정적 보고서는 공유가 쉽지만, 시간이 지나면 숫자와 맥락이 빠르게 낡습니다. 반대로 라이브 대시보드는 최신 상태를 보여줄 수 있지만, 누가 어떤 권한으로 무엇을 보게 되는지 설명하지 않으면 오해가 생기기 쉽습니다.
Claude Code Artifacts MCP connectors는 이 경계에 있는 기능입니다. artifact를 열 때마다 viewer의 연결 계정으로 데이터를 다시 불러오는 방식이기 때문에, 단순히 도구 이름만 아는 것보다 팀의 확인 기준을 함께 정리해 두는 것이 더 중요합니다.
Artifacts MCP connectors란, Claude Code가 게시한 artifact가 열릴 때 viewer의 연결 계정으로 필요한 데이터를 다시 불러오는 공유 방식입니다.
Claude Code Artifacts MCP connectors에서 달라진 점
2026년 7월 공식 업데이트에서 artifact가 MCP connector를 호출할 수 있게 되었고, viewer 승인과 viewer 계정 기준 실행이 함께 강조됐습니다. 이 변화로 artifact는 정적 보고서에 머무르지 않고, 열 때마다 확인 가능한 팀용 라이브 페이지로 활용될 수 있게 됐습니다.
핵심은 작성자가 모아 둔 스냅샷을 보여주는 것이 아니라, viewer가 열 때 승인한 연결 계정 기준으로 데이터를 다시 불러온다는 점입니다.
작성 기준일 현재 기능 사실은 공식 문서와 changelog로 확인했지만, 공개 본문에는 DAKER 정책에 맞는 내부 링크만 남깁니다. 그래서 이 글도 기능 소개 자체보다 팀이 바로 적용할 수 있는 검증 루틴에 초점을 둡니다.
왜 지금 팀 루틴으로 정리해야 하나요?
새 기능을 도입할 때 흔한 실수는 도구 이름만 공유하고 완료 기준은 공유하지 않는 일입니다. 특히 connector-backed artifact는 viewer별 권한 차이, 승인 흐름, fallback 문구, 공유 범위를 함께 설명해야 실제 업무에서 혼선이 줄어듭니다.
오늘 정리해야 할 것은 기능 목록이 아니라 같은 문장 안에 들어가야 할 기준입니다. 어떤 화면을 보여줄지, 어떤 산출물을 남길지, 어떤 로그를 확인할지, 어디까지가 한계인지가 함께 묶여야 합니다.
라이브 artifact를 팀에 도입할 때는 무엇을 보여줄지보다 무엇을 확인한 상태를 완료로 볼지 먼저 정하는 편이 좋습니다.
처음 도입할 때의 최소 사용 루틴
아래 순서는 도구 설명이 아니라 팀 작업의 확인 기준으로 쓰기 좋은 최소 루틴입니다.
- 먼저 artifact가 보여줄 결정을 한 문장으로 정합니다.
- GitHub, Slack, Drive처럼 필요한 connector 이름과 읽을 데이터 범위를 prompt에 명시합니다.
- viewer가 connector를 연결하지 않았거나 승인을 거절했을 때 보일 fallback 문구를 함께 요청합니다.
- 공유 전에 public link가 필요한 자료인지, 조직 내부에서만 볼 자료인지 구분합니다.
- 게시 후에는 화면에 나온 수치가 누구의 connector 권한으로 보이는지 팀에 설명합니다.
작업 요청은 어떻게 쓰면 좋을까요?
짧은 요청이라도 구조가 있으면 결과 보고가 훨씬 선명해집니다. 먼저 목표 화면이나 산출물을 쓰고, 다음 줄에 확인 기준을 적고, 마지막 줄에 아직 확인하지 못한 범위를 남기면 됩니다.
목표, 확인 기준, 남은 한계를 세 줄로 나누는 것만으로도 Claude Code 세션의 결과가 덜 흐려집니다.
정적 artifact와 connector-backed artifact의 차이
| 구분 | 정적 artifact | connector-backed artifact |
|---|---|---|
| 데이터 기준 | 작성 세션이 모은 스냅샷 | viewer가 열 때 승인한 connector 결과 |
| 공유 범위 | public link 검토 가능 | 조직 내부 또는 private 공유 중심 |
| 실수 포인트 | 오래된 수치를 최신처럼 말함 | viewer별 권한 차이를 설명하지 않음 |
이미지 워크플로가 보여주는 것
이 워크플로의 핵심은 선택과 설명입니다. 팀원이 정적 보고서와 라이브 대시보드 중 무엇이 필요한지 먼저 고르고, Claude Code artifact 카드에 GitHub connector와 Slack connector 이름이 붙습니다. viewer가 처음 열 때는 connector 접근 승인을 확인하고, 권한이 없는 경우에는 빈 표 대신 연결 안내 문구가 보입니다. 마지막으로 팀은 수치 기준, viewer 권한, 공유 범위를 함께 기록합니다.
팀 적용 전에 확인할 체크포인트
체크리스트의 목적은 더 많은 자동화를 켜는 것이 아니라, 작업이 끝났다고 말할 수 있는 증거를 남기는 데 있습니다.
- 라이브 데이터가 필요한 영역과 고정 설명 영역을 분리했나요?
- viewer 계정 권한에 따라 결과가 달라질 수 있다는 문장을 남겼나요?
- side effect가 있는 connector action은 viewer 승인 흐름을 따로 확인했나요?
- connector가 없을 때 빈 화면 대신 연결 안내가 나오게 했나요?
자주 나오는 질문
Artifacts MCP connectors는 기존 dashboard와 무엇이 다른가요?
viewer가 열 때 connector를 통해 최신 데이터를 불러올 수 있다는 점이 다릅니다.
viewer의 비밀값이 artifact 작성자에게 보이나요?
공식 설명 기준으로 connector 호출은 viewer 계정의 연결을 통해 처리되며, 공개 본문에서는 권한 차이와 승인 흐름을 먼저 설명하는 편이 안전합니다.
public link로 공유해도 되나요?
connector-backed artifact는 조직 정책과 plan 조건을 먼저 확인해야 하며, 민감한 데이터는 내부 공유로 제한하는 편이 좋습니다.
첫 prompt에는 무엇을 써야 하나요?
connector 이름, 필요한 데이터, 새로고침 방식, connector가 없을 때 보여줄 fallback 문구를 함께 쓰면 됩니다.
참고 자료
DAKER 클로드 코드 디렉터리
WebSearch와 WebFetch 역할 구분
MCP 프롬프트 커맨드 실무
Claude in Chrome 브라우저 검증 루틴
여러분의 팀에서는 정적 artifact와 라이브 artifact 중 어떤 기준으로 나눠 쓰고 있는지 궁금합니다.