Claude Cowork interactive connectors는 대시보드를 어디까지 맡겨도 될까 2026 — MCP 앱·권한·sandbox 체크표

Posted on by

2026년 4월 22일 기준으로 Claude Help Center 문서를 다시 읽다가 이 질문이 계속 머리에 남았다.

대시보드까지 Claude에게 맡겨도 되나.

보는 건 괜찮고, 누르는 건 좀 불안하고, 저장되는 순간부터는 더 불안해진다.

이 느낌이 꽤 정확하다.

interactive connectors, custom connectors using remote MCP, artifacts의 MCP 연동은 겉으로 보기엔 다 비슷해 보여도 권한이 흐르는 방향이 다르다.

어떤 건 화면 안에서 살아 움직이는 대시보드고, 어떤 건 외부 시스템에 붙는 연결선이고, 어떤 건 대화에서 나온 결과물을 앱처럼 굴리는 층이다.

그래서 이 글은 “Claude Cowork가 좋다”는 얘기를 또 하지 않는다.

대신 아주 실무적으로 묻는다.

대시보드를 어디까지 맡겨도 되는가.

그리고 어디부터는 사람이 꼭 봐야 하는가.

나는 이걸 세 층으로 나눠 보는 편이 제일 덜 헷갈린다고 본다.

  1. 보여주는 대시보드
  2. 바꾸는 대시보드
  3. 바뀌면 사고가 나는 대시보드

이 셋은 같은 화면처럼 보이지만 운영 기준은 완전히 다르다.

문서만 보면 쉽다.

그런데 실제 운영은 늘 문서보다 한 칸 더 복잡하다.

특히 “Allow always”를 누를 수 있는 순간, “이 대시보드는 읽기 전용이야”라고 믿는 순간, 그리고 “research가 알아서 해주겠지”라고 생각하는 순간이 위험하다.

이 글은 그런 순간들을 사람 검수 지점으로 다시 되돌리는 체크표다.

1. 이 질문이 왜 갑자기 중요해졌나

대시보드는 원래 사람이 눈으로 보고 판단하는 화면이었다.

그런데 이제는 아니다.

대시보드가 단순한 시각화가 아니라 작업 보드, 승인 화면, 설정 패널, 문서 편집기, 앱 런타임이 되어가고 있다.

Claude Help Center가 interactive connectors를 설명할 때 바로 그 지점을 짚는다.

대화 안에서 살아 있는 인터페이스를 띄우고, 필터를 바꾸고, 체크를 넣고, 설정을 조정할 수 있다는 것이다.

이건 단순한 텍스트 응답이 아니다.

사용자는 보고 끝나는 게 아니라 행동할 수 있다.

그 말은 곧 권한도 같이 움직인다는 뜻이다.

문제는 여기서 생긴다.

대시보드라고 하면 보통 읽기 전용처럼 느껴진다.

하지만 실제로는 보기, 필터, 정렬, 저장, 동기화, 공유, 배포, 권한 변경이 한 화면에 섞여 있다.

이 중 하나만 섞여도 사람 검수의 무게가 달라진다.

내 기준은 단순하다.

읽기만 하면 Claude가 꽤 넓게 맡아도 된다.

쓰기나 배포가 섞이면 사람이 중간에 끼어야 한다.

권한 자체를 바꾸면 사람이 마지막에 아니라 처음부터 봐야 한다.

대시보드를 맡기는 기준은 화면이 예쁘냐가 아니라 무엇이 영속적으로 바뀌느냐로 잡아야 한다.

이 차이를 놓치면 “대시보드 자동화”가 어느 순간 “운영 자동화 사고”가 된다.

2. 공식 문서가 말하는 세 층

2.1 interactive connectors

Claude Help Center의 interactive connectors 설명은 아주 중요한 힌트를 준다.

이 커넥터들은 대화창 안에 대시보드, 작업 보드, 디자인 도구 같은 인터페이스를 띄울 수 있다.

즉, 단순히 텍스트를 돌려주는 도구가 아니다.

화면 자체가 작업 공간이 된다.

여기서 핵심은 인터랙션이 곧 권한이라는 점이다.

필터를 바꾸는 행동도 같은 권한 경로를 탄다.

체크박스를 눌러 상태를 바꾸는 행동도 같은 권한 경로를 탄다.

문서상으로는 인라인 카드와 풀스크린 뷰 두 방식이 나온다.

이 말은 곧 대시보드를 사람이 대화창에서 바로 만질 수 있다는 뜻이다.

그래서 interactive connectors는 읽기 전용 시각화보다 한 단계 더 위에 있다.

대시보드를 “보여주는” 수준이면 비교적 넓게 맡길 수 있다.

대시보드를 “움직이게” 하면 그때부터 사람 검수가 필요해진다.

문서가 주는 운영 신호는 분명하다.

  • 대시보드 안에서 할 수 있는 행동이 많을수록 사람이 봐야 한다
  • 도구 호출이 실제 앱 행동으로 이어질수록 사람이 더 좁게 승인해야 한다
  • 조직 관리자는 특정 tool call 렌더링을 꺼둘 수 있다

이건 그냥 UI 기능 설명이 아니다.

운영에서 보면 렌더링 가능 여부가 곧 정책 버튼이다.

2.2 custom connectors using remote MCP

custom connectors using remote MCP는 대시보드보다 한 층 더 아래를 건드린다.

이건 화면이 아니라 외부 도구와 데이터 소스를 연결하는 통로다.

Claude Help Center는 Claude가 Anthropic 클라우드 인프라에서 remote MCP 서버에 접속한다고 설명한다.

이게 중요하다.

Cowork가 로컬 앱처럼 보이더라도 원격 커넥터의 연결은 사실상 클라우드에서 중계된다.

즉, 네트워크 경계와 권한 경계가 사람이 눈으로 보는 앱 경계와 일치하지 않는다.

이건 운영자 입장에서 꽤 큰 차이다.

로컬 앱만 생각하면 “내 컴퓨터 안에서 끝나겠지”라고 착각하기 쉽다.

그런데 remote MCP는 공개 인터넷에서 접근 가능해야 하고, 사설망이나 VPN 뒤에 있으면 안 붙을 수 있다.

문서가 강조하는 또 하나는 OAuth와 스코프다.

Claude는 비밀번호를 직접 보는 게 아니라 권한 부여 흐름을 통해 접근한다.

그래서 사람 검수는 단순히 “연결한다/안 한다”가 아니라 무슨 스코프를 주느냐까지 들어가야 한다.

여기서 운영 기준은 아주 단단해야 한다.

  • trusted server만 연결한다
  • unnecessary scope는 거절한다
  • write action tool은 필요할 때만 둔다
  • research와 같이 쓸 때는 write tool을 꺼둔다
  • approval request를 꼼꼼히 본다

이건 대시보드보다 더 위험한 층이다.

왜냐하면 대시보드는 보이는 화면이지만 remote MCP는 그 뒤의 외부 시스템을 건드리기 때문이다.

2.3 artifacts와 MCP 연동

artifacts는 본질적으로 대화에서 나오는 독립적인 결과물이다.

문서, 코드, 웹사이트, 다이어그램, React 컴포넌트 같은 것들이 대표적인 artifact다.

여기까지만 보면 그냥 생성 결과물처럼 보인다.

그런데 artifacts 문서에는 MCP와 연결되는 흐름이 나온다.

즉, artifact가 단순 출력물이 아니라 외부 서비스와 상호작용하는 인터랙티브 앱이 될 수 있다는 뜻이다.

이건 특히 대시보드와 닮았다.

대시보드는 한 번 만들고 끝나는 정적 페이지가 아니라 상태를 바꾸고 다음 상태를 저장하고 다른 사용자와 공유하는 화면일 때가 많다.

artifacts의 MCP 연동도 비슷하다.

처음엔 “멋진 미리보기”처럼 시작하지만 어느 순간부터는 데이터를 읽고, 툴을 호출하고, 상태를 저장하는 앱이 된다.

내가 이 글에서 artifacts를 따로 보는 이유가 여기다.

interactive connectors는 화면 안의 도구고, remote MCP는 외부 연결선이고, artifacts with MCP는 그 둘이 만나서 만들어지는 작업 결과물에 가깝다.

셋을 같은 범주로 대충 묶으면 권한 판단이 흐려진다.

문서에서 읽히는 운영 함의는 이렇다.

  • artifacts는 사람이 계속 만질 수 있는 작업물이다
  • MCP가 붙으면 그 작업물은 외부 시스템과 이어진다
  • Team/Enterprise 환경에서는 조직 단위 제어가 개입할 수 있다
  • 다만 사용자별 인증과 승인 흐름은 여전히 중요하다

이 마지막 문장은 특히 중요하다.

공유 artifact라고 해서 권한 책임까지 사라지는 건 아니다.

3. 대시보드를 어디까지 맡겨도 되나

이제 실무 기준으로 내려오자.

나는 대시보드를 세 구역으로 나눈다.

3.1 초록 구역

여긴 꽤 넓게 맡겨도 된다.

  • 읽기 전용 대시보드 보기
  • 필터 바꿔서 범위 좁히기
  • 정렬 기준 바꿔서 보기
  • 차트 종류 바꿔서 비교하기
  • 요약 문장 생성하기
  • 표를 리포트 초안으로 옮기기
  • 눈에 띄는 이상치 표시하기
  • 다음 검토 대상 후보 뽑기

이 구역의 공통점은 단순하다.

원본 데이터나 권한을 바꾸지 않는다.

결과물은 초안일 뿐이고, 사람이 나중에 판단하면 된다.

초록 구역은 “Claude가 먼저 보고 정리” 까지만 허용하는 편이 좋다.

3.2 노랑 구역

여긴 맡기되, 사람이 중간에 한 번 봐야 한다.

  • 대시보드 설정 저장
  • 개인 보기 프리셋 만들기
  • 공유 가능한 차트 초안 생성
  • 작업 보드에서 상태 이동 제안
  • 여러 소스의 값을 합쳐 중간 테이블 만들기
  • 이미 있는 데이터에 주석 추가
  • 내보내기용 CSV나 MD 초안 만들기
  • 임시 링크나 임시 뷰 생성

이 구역은 편리하지만 되돌리는 비용이 올라간다.

특히 저장이 들어가면 나중에 누가 언제 무엇을 바꿨는지 추적할 필요가 생긴다.

그래서 노랑 구역은 “Claude가 만들고 사람은 승인” 이 규칙이 맞는다.

여기서 특히 조심해야 할 건 기본값 저장이다.

사용자가 나중에 다시 보게 되는 설정은 대부분 실제 운영 설정처럼 작동한다.

단순한 보기 옵션 같아도 사실상 작업 방식이 바뀐다.

3.3 빨강 구역

여긴 사람이 반드시 봐야 한다.

  • 삭제
  • 배포
  • 공개 공유
  • 권한 변경
  • 관리자 설정 변경
  • 보안 정책 변경
  • 외부 시스템 write action 실행
  • 결제나 청구 정보 접속
  • 실데이터의 대량 수정
  • 환불, 승인, 승인 취소

빨강 구역은 단순히 위험한 게 아니다.

사고가 나면 회수 비용이 높다.

그래서 이 영역은 대시보드를 Claude에게 “맡긴다”가 아니라 Claude가 “제안”하고 사람이 “실행”하는 구조가 맞다.

이 기준을 흐리면 대시보드는 금방 운영 도구가 아니라 사고 도구가 된다.

4. 사람 검수 지점은 어디인가

4.1 연결 직후

처음 연결할 때 봐야 한다.

  • 서버가 trusted source인가
  • 공개 인터넷에서 접근 가능한가
  • OAuth 스코프가 과한가
  • admin-level 권한을 요구하는가
  • write tool이 꼭 필요한가

연결 직후는 제일 좋은 검수 타이밍이다.

왜냐하면 이때는 아직 습관이 안 붙었기 때문이다.

한 번 습관이 되면 사람은 점점 덜 본다.

4.2 도구 승인 요청이 뜰 때

Claude는 tool approval을 요청할 수 있다.

이 순간이 두 번째 검수 지점이다.

  • 지금 요청이 읽기인가 쓰기인가
  • 이 동작이 되돌릴 수 있는가
  • 실행 빈도가 높은가
  • 다른 도구로 우회할 수 있는가
  • 진짜 이 세션에 필요한가

여기서 “Allow always”는 생각보다 무거운 버튼이다.

자주 쓰는 편의 버튼처럼 보이지만 사실상 자동 승인 루프다.

4.3 Research가 붙을 때

문서상 research는 connector tools를 자동으로 호출할 수 있다.

여기서 조심해야 한다.

자동 호출이 가능하다는 건 반복 호출이 가능하다는 뜻이기도 하다.

그리고 반복 호출은 많은 경우 생각보다 빠르게 광범위한 접근으로 변한다.

그래서 research와 custom connectors를 같이 쓸 때는 다음 원칙을 둬야 한다.

  • write tool은 꺼둔다
  • 필요 없는 tool은 비활성화한다
  • 민감한 데이터 소스는 분리한다
  • 결과를 바로 반영하지 말고 초안으로 본다

4.4 org settings를 건드릴 때

Team이나 Enterprise 환경에서는 소유자나 관리자 역할이 추가된다.

여기서는 개인 편의보다 정책이 우선이다.

  • 어떤 connector를 올릴지
  • 어떤 tool call을 막을지
  • artifacts MCP access를 켤지
  • 사용자별 enable/disable을 어떻게 둘지

이건 대시보드 운영자가 아니라 조직 운영자의 문제다.

그래서 사람 검수도 개인 검수와 조직 검수로 나눠야 한다.

개인 검수는 “내가 이 화면을 써도 되나”이고, 조직 검수는 “우리 조직이 이 도구를 열어도 되나”다.

두 질문은 비슷해 보여도 답이 완전히 다를 수 있다.

4.5 artifacts가 실행형이 될 때

artifact가 그냥 결과물일 때는 비교적 단순하다.

하지만 MCP를 붙여 살아 있는 앱처럼 돌리면 얘기가 달라진다.

이때 사람 검수는 보기 좋게 나왔는지가 아니라 데이터 경계가 맞는지를 봐야 한다.

  • 이 artifact가 읽는 데이터는 무엇인가
  • 이 artifact가 쓰는 데이터는 무엇인가
  • 사용자별 인증이 필요한가
  • 조직 전체 공유가 가능한가
  • 저장된 상태가 남아도 되는가

여기서 한번만 삐끗해도 대시보드가 아니라 운영 상태 저장소가 된다.

5. 권한과 sandbox 체크표

아래 표는 내가 실제로 쓸 생각으로 정리한 판정표다.

항목 Claude가 해도 되는 일 사람 검수 지점 기본 판단
읽기 전용 대시보드 조회, 요약, 비교, 초안 작성 결과 해석 직전 맡겨도 됨
필터/정렬 범위 좁히기, 뷰 전환 저장 전 조건부 허용
차트 생성 시각화 초안 만들기 배포 전 조건부 허용
공유 링크 초안 생성 공개 직전 사람 승인 필요
상태 변경 카드 이동, 태스크 상태 제안 저장 전 사람 승인 필요
데이터 내보내기 CSV, MD, 리포트 초안 외부 전달 전 사람 승인 필요
비밀정보 접근 제한된 범위 읽기 연결 직후 기본 차단
write tool 외부 앱에 쓰기 tool approval 매우 제한
delete tool 삭제, 취소, 해제 항상 기본 금지
admin settings 권한/정책 변경 항상 사람이 직접
research + connector 다중 호출, 자동 조사 호출 전 write 차단
artifact + MCP 인터랙티브 앱, 상태 저장 인증/공유 전 조건부 허용

이 표의 핵심은 간단하다.

읽기는 넓게, 쓰기는 좁게, 권한 변경은 사람이, 삭제는 거의 안 된다고 보면 된다.

5.1 sandbox라는 말을 너무 넓게 쓰지 말기

여기서 sandbox는 하나의 벽이 아니다.

로컬 실행 격리, 네트워크 경계, OAuth 권한, tool approval, 조직 정책이 다 따로 있다.

그래서 “sandbox가 있으니 안전하다”는 말은 반만 맞다.

진짜 질문은 이거다.

  • 로컬에서 막히는가
  • 네트워크에서 막히는가
  • 도구 승인에서 막히는가
  • 조직 정책에서 막히는가

이 네 개가 따로 돌아가야 한다.

5.2 대시보드 사고는 보통 여기서 난다

대시보드 사고는 대개 큰 이벤트가 아니라 작은 허용이 쌓이면서 난다.

  • 초안이 실수로 저장됨
  • 저장된 뷰가 공유됨
  • 공유된 뷰가 쓰기 권한을 가짐
  • 쓰기 권한이 다른 connector로 이어짐
  • research가 그것을 재호출함

이건 기술 문제이기도 하지만 운영 습관 문제이기도 하다.

그래서 체크표가 필요하다.

6. 세 가지 문서의 운영 차이

6.1 interactive connectors는 “보여주고 만지는” 층

이 층은 화면에 가깝다.

그래서 사람은 결과를 눈으로 빨리 확인할 수 있다.

하지만 만지는 순간 행동이 된다.

행동이 되면 검수 기준도 바뀐다.

6.2 custom connectors는 “외부 시스템과 연결되는” 층

이 층은 데이터와 권한에 가깝다.

그래서 화면보다 먼저 봐야 할 건 어떤 서버에 붙는지다.

trusted server인지, 스코프가 적절한지, public internet 접근이 가능한지, write가 필요한지.

이 네 개가 기본이다.

6.3 artifacts MCP는 “작업물이 앱이 되는” 층

이 층은 결과물과 런타임이 섞인다.

처음엔 문서처럼 시작하지만 나중에는 상태를 가진 도구가 된다.

그래서 여기서는 “예쁘다”보다 “지속적으로 안전한가”가 더 중요하다.

이 셋을 한 줄로 요약하면 이렇다.

  • connectors는 연결
  • interactive connectors는 조작
  • artifacts MCP는 실행 결과물

운영자는 이 차이를 구분해야 한다.

7. 실전 시나리오로 보면 더 선명하다

7.1 영업 대시보드

Claude에게 맡겨도 되는 것:

  • 주간 매출 추이 요약
  • 지역별 하락 구간 표시
  • 상위 고객군 초안 정리
  • 회의용 한 페이지 리포트 작성

사람이 봐야 하는 것:

  • 숫자 출처가 맞는지
  • 공유 범위가 맞는지
  • 매출 정의가 팀 기준과 같은지

7.2 프로젝트 보드

Claude에게 맡겨도 되는 것:

  • 카드 분류
  • 상태 후보 제안
  • 마감 임박 작업 표시
  • 중복 이슈 묶기

사람이 봐야 하는 것:

  • 상태 전환이 실제로 저장되는지
  • 우선순위 변경이 팀 합의와 맞는지
  • 잘못된 자동 이동이 없는지

7.3 운영 알림 대시보드

Claude에게 맡겨도 되는 것:

  • 알림 묶기
  • 이상치 요약
  • 지난 24시간 비교
  • 반복 경고 패턴 찾기

사람이 봐야 하는 것:

  • 알림을 끄는 행위가 없는지
  • 임계치가 바뀌지 않았는지
  • 생산 이슈를 실수로 묻지 않는지

7.4 문서 편집형 dashboard

Claude에게 맡겨도 되는 것:

  • 초안 작성
  • 항목 재배열
  • 표준 문구 삽입
  • 요약본 생성

사람이 봐야 하는 것:

  • 최종 배포
  • 외부 공유
  • 브랜드 문구의 정확성
  • 법무/보안 문구의 적합성

7.5 artifact 기반 인터랙티브 앱

Claude에게 맡겨도 되는 것:

  • 시나리오 프로토타입 작성
  • 보기 전용 샘플 데이터 연결
  • UI 흐름 초안 구성
  • 상태 전환 예시 만들기

사람이 봐야 하는 것:

  • 실제 데이터 연결 여부
  • 쓰기 권한 부여 여부
  • 사용자별 인증 흐름
  • 상태 저장 방식

이 시나리오들은 결국 같은 이야기를 반복한다.

읽는 일은 맡길 수 있다.

바꾸는 일은 줄여야 한다.

공유하는 일은 더 좁혀야 한다.

8. 운영자가 정해야 할 기본값

대시보드를 Claude에 맡길 때 기본값을 정해두면 훨씬 덜 흔들린다.

8.1 기본값 1

읽기 전용부터 시작한다.

8.2 기본값 2

write tool은 처음부터 켜지 않는다.

8.3 기본값 3

Allow always는 습관 버튼이 아니라 정책 버튼으로 본다.

8.4 기본값 4

research와 연결할 때는 자동 호출 범위를 먼저 줄인다.

8.5 기본값 5

공유 가능한 artifact는 초안과 배포본을 분리한다.

8.6 기본값 6

조직 관리자는 플랫폼 정책보다 자기 조직의 위협 모델을 먼저 쓴다.

8.7 기본값 7

사람이 검수할 포인트를 연결 직후, tool approval, 배포 직전으로 나눈다.

이렇게만 해도 대시보드 운영이 갑자기 덜 무섭다.

9. 자주 헷갈리는 경계

9.1 “보는 것”과 “쓰는 것”은 같은 화면이어도 다르다

대시보드가 같은 화면에 있어도 읽기와 쓰기는 전혀 다른 권한이다.

읽기는 초안으로 허용할 수 있지만 쓰기는 검수 포인트를 하나 더 넣어야 한다.

9.2 “내 컴퓨터에서 도니까 안전”은 아니다

remote MCP는 클라우드에서 중계된다.

즉, 앱이 로컬에 있더라도 연결은 로컬만의 문제가 아니다.

네트워크, 인증, 스코프가 함께 본다.

9.3 “artifact니까 가벼운 거겠지”는 아니다

artifact는 자주 가볍게 시작하지만 상태가 붙으면 무거워진다.

상태가 붙는 순간부터 검수 대상이 된다.

9.4 “조직이 허용했으니 끝”도 아니다

조직 설정은 시작점이지 끝이 아니다.

사용자별 승인, tool 범위, 실행 컨텍스트는 여전히 사람 손이 들어간다.

9.5 “Research가 알아서 안전하게 쓸 것”도 아니다

Research는 편리하지만 자동 호출이 늘수록 사람의 감시가 느슨해지기 쉽다.

그래서 이 기능은 편함보다 먼저 범위를 정해야 한다.

10. 바로 쓰는 검수 질문

대시보드를 Claude에게 넘기기 전에 나는 보통 이 질문부터 던진다.

  • 이건 읽기인가 쓰기인가
  • 저장이 남는가
  • 되돌리기 쉬운가
  • 외부 시스템이 붙는가
  • 원본 데이터가 건드려지는가
  • 다른 사람과 공유되는가
  • approval을 다시 볼 수 있는가
  • research가 이걸 자동 호출해도 되는가

여기서 하나라도 애매하면 노랑 구역으로 넣는 편이 낫다.

애매한 걸 초록 구역에 넣는 순간 운영은 금방 비싸진다.

FAQ

Q1. 읽기 전용 대시보드는 거의 다 맡겨도 되나

대체로 그렇다.

다만 “읽기 전용처럼 보이는 화면”이 정말 읽기 전용인지 확인해야 한다.

필터 저장, 개인화 저장, 공유 링크 생성이 섞이면 이미 순수 읽기 화면이 아니다.

Q2. interactive connectors에서 필터나 체크를 바꾸는 건 괜찮나

괜찮을 때가 많다.

하지만 그 변경이 세션 안의 임시 변화인지, 저장되는 상태인지 확인해야 한다.

임시 변화면 초록 구역이다.

저장되면 노랑 구역이다.

Q3. custom connectors는 왜 더 조심해야 하나

외부 도구와 데이터에 붙기 때문이다.

권한 부여, OAuth, 스코프, write tool이 같이 움직인다.

보이는 화면보다 보이지 않는 연결선이 더 중요하다.

Q4. artifacts MCP는 대시보드랑 같은 건가

완전히 같지는 않다.

하지만 운영 관점에서는 꽤 비슷하다.

둘 다 보여주고, 바꾸고, 상태를 남기고, 공유할 수 있기 때문이다.

Q5. Team이나 Enterprise에서는 관리자만 보면 되나

아니다.

관리자 설정은 조직 경계고, 사용자 승인과 tool approval은 개인 경계다.

둘 다 봐야 한다.

Q6. research와 커넥터를 같이 쓰면 뭐가 위험한가

자동 호출량이 늘 수 있다.

특히 write tool이 붙어 있으면 한 번의 조사 작업이 여러 외부 액션으로 번질 수 있다.

그래서 write tool은 꺼두는 쪽이 안전하다.

Q7. sandbox가 있으면 끝 아닌가

끝이 아니다.

sandbox는 한 겹의 보호막일 뿐이다.

권한, 네트워크, 조직 정책, 승인 루프가 따로 존재한다.

Q8. 결국 사람은 어디서 꼭 개입해야 하나

네 군데다.

연결 직후, write 승인, 공유 직전, 배포 직전.

이 네 지점은 자동화를 걸어도 사람이 남아 있어야 한다.

공식 출처

관련 글

메모

이 초안은 2026-04-22 기준 Claude Help Center 문서만 중심으로 잡았다.

interactive connectors, custom connectors using remote MCP, artifacts with MCP를 대시보드 운영 기준으로 다시 묶는 게 핵심이다.

문서가 바뀌면 이 체크표도 같이 다시 보는 편이 맞다.