이것은 다섯 가지 결정 중 다섯 번째인 가시성입니다. 여러분은 롤아웃 비용을 설정했습니다. 이 레슨에서는 가시성, 즉 세 가지 요소(Compliance API, OpenTelemetry, 보존 기간)와 그중 되돌리기 어려운 한 가지 결정을 다룹니다.
가시성의 목적
여러분이 내린 처음 네 가지 결정은 Claude가 수행하는 작업을 구성합니다. 가시성은 그것이 제대로 작동하는지 판단하는 방법입니다. 가시성은 또한 사후에 구체적인 질문에 증거로 답할 수 있게 해줍니다. 어떤 구성원이 특정 계정에 접근했는가? 민감한 대화에서 Claude가 무엇을 생성했는가? 그 대화는 얼마나 오래 보관되는가? 이러한 답변은 오직 이미 보관하고 있던 기록에서만 나올 수 있습니다.
그렇기 때문에 가시성은 구성원이 접근 권한을 얻은 후가 아니라 그 전에 설정해야 합니다. 최초 접근과 기록을 켜는 날 사이의 기간은 나중에 채울 수 없는 기록의 공백을 남깁니다. 세 가지 요소가 이러한 범위를 제공합니다: Compliance API(대화 콘텐츠와 감사 로그 이벤트), OpenTelemetry(서피스가 어떻게 작동하는지), 그리고 보존 기간(콘텐츠가 얼마나 오래 보관되는지)입니다. 이러한 기록 중 일부는 Compliance API가 켜져 있을 때만 캡처됩니다: 활동 피드 이벤트, 그리고 Cowork와 Claude Code 같은 구성원의 기기에서 이루어진 세션의 트랜스크립트입니다.
Compliance API: 대화 콘텐츠 기록
Compliance API는 콘텐츠를 포함하는 기록입니다. Claude 채팅을 포괄하며, 조직의 기존 Compliance Access Key와 설정을 기반으로 Cowork 및 Claude Code 세션까지 확장되므로 추가로 통합할 것이 없습니다. 어떤 플랜에서 제공되는지는 지원 센터의 Compliance API 문서(새 탭에서 열림)에서, 어떤 앱의 세션을 기록하는지는 Claude Platform Docs의 세션 트랜스크립트 가져오기(새 탭에서 열림)에서 확인하세요. 이 기록에는 활동 피드 이벤트, 채팅 데이터, 파일 콘텐츠가 포함되므로 "누가 언제 로그인했는가"뿐만 아니라 "무엇이 말해졌는가"와 "무엇이 공유되었는가"에도 답할 수 있습니다. 특정 법적 또는 규제 요건을 충족하는지 여부는 법무 및 컴플라이언스 담당자가 판단할 사항입니다. 이미 운영 중인 CASB, DLP, eDiscovery, SIEM 도구와 통합하세요. 이러한 공급업체 중 다수가 Compliance API를 기반으로 통합을 구축했으며, Claude Compliance API 통합 시작하기(새 탭에서 열림)에 나열되어 있습니다.
Compliance API는 다른 두 가지 기록과 혼동하기 쉽습니다:
- 감사 로그는 메타데이터만 포함합니다. 감사 로그는 이벤트(누가 언제 무엇을 했는지: 관리자 및 구성원 작업)를 기록하며, 프롬프트나 완성 결과는 포함하지 않습니다. Compliance API는 감사 로그 이벤트도 포함하므로 하나의 기록이 둘 다를 담고 있지만, 그 구분은 여전히 중요합니다. 누군가 콘텐츠를 요청할 때 메타데이터만으로는 잘못된 답이 됩니다.
- 전체 데이터 내보내기는 별도의 Primary Owner 기능으로, 사례별로 검토하는 대신 조직의 데이터를 일괄적으로 가져오기 위한 것입니다.
Primary Owner가 Compliance API를 활성화합니다. 액세스 키는 생성 시점에 범위가 지정됩니다: Primary Owner 키는 상위 조직 아래의 모든 조직을 포괄할 수 있는 반면, Owner 키는 해당 Owner의 조직만 포괄합니다. Primary Owner는 상위 조직 전체를 포괄하는 키뿐만 아니라 단일 조직(상위 조직의 하위 조직)으로 범위가 지정된 키도 생성할 수 있습니다. 범위는 역할에 의해 고정되는 것이 아니라 생성 시점에 키별로 선택하는 사항입니다. 그 이후에 중요한 결정은 누가 그것을 읽는가입니다: 아무도 검토하지 않는 기록은 실제로는 통제 수단이 아닙니다. 많은 회사에는 이미 보안 로그가 모이는 곳(SIEM 또는 보안 도구의 중앙 수집 지점)과 이를 검토하는 담당자가 있습니다. Compliance API를 그곳으로 라우팅하면 Claude는 이미 존재하는 검토 프로세스에 추가되는 또 하나의 소스가 됩니다.
OpenTelemetry: 서피스가 어떻게 작동하는지
OpenTelemetry 내보내기는 운영 텔레메트리를 관측 가능성 스택으로 전송합니다: 사용 패턴과 성능, 그리고 일부 서피스에서는 대화 콘텐츠까지 포함됩니다. Claude Code에는 엔지니어링 팀이 켤 경우 프롬프트를 로깅하는 문서화된 옵트인 기능이 있습니다. 기본적으로 텔레메트리는 운영 데이터입니다. 현재 버전의 Claude Desktop에서 Cowork의 내보내기는 메타데이터만 포함합니다: 프롬프트 텍스트, Claude의 응답, 도구 입력은 기본적으로 꺼져 있으며, otlpContentCapture 기기 정책이 이를 켭니다. 일부 이전 버전은 정책이 메타데이터 전용으로 설정되지 않는 한 해당 콘텐츠를 전송하며(방법은 Cowork 모니터링(새 탭에서 열림) 참조), 메타데이터에는 항상 구성원의 이메일 주소와 연결한 폴더의 경로가 포함되므로, 조직에서 요구하는 경우 수집기에서 이를 필터링하세요. OpenTelemetry는 Compliance API의 "무엇이 말해졌는가"를 보완하는 "어떻게 작동하고 있는가"로 취급하고, 선택 사항으로 다루세요: 콘텐츠에 대해 의존해야 할 기록은 텔레메트리가 아니라 Compliance API입니다. 플랫폼 팀이 이미 관측 가능성 스택을 운영하고 있다면, 이는 그들에게 라우팅 작업일 뿐입니다.
보존 기간: 콘텐츠가 얼마나 오래 보관되는지
보존 기간은 대화 콘텐츠가 삭제되기 전까지 보관되는 기간입니다. 기본값으로 두면 콘텐츠는 여러분이나 구성원이 삭제할 때까지 무기한 보관됩니다. 대신 사용자 지정 보존 기간을 설정하면 콘텐츠는 설정한 일정에 따라 자동으로 삭제되며, 프로젝트 안에 보관된 채팅의 경우 채팅의 기간이 아니라 프로젝트의 기간이 적용됩니다. 보존 기간이 언제부터 계산되는지와 사용자 지정 기간이 적용되지 않는 항목은 사용자 지정 데이터 보존(새 탭에서 열림)과, 조직에서 통합 Claude 경험을 사용하는 경우 해당 설정 문서(새 탭에서 열림)를 참고하세요. 가장 짧은 사용자 지정 기간은 30일입니다. 이 설정에는 보존 기간 0 옵션이 없습니다.
Compliance API를 통해 접근하는 활동 피드 이벤트와 세션 트랜스크립트는 자체적인 보존 모델을 따릅니다:
- 활동 피드: 설정한 기간과 관계없이 6년.
- 원격 세션 트랜스크립트(웹 또는 모바일의 claude.ai에서 시작되어 Anthropic이 관리하는 환경의 클라우드에서 실행되는 Cowork 세션, 그리고 클라우드에서 실행되는 Cowork 예약 작업의 각 실행): 구성원이 더 일찍 세션을 삭제하지 않는 한 6년.
- Cowork와 Claude Code의 로컬 세션 트랜스크립트: 유한한 사용자 지정 기간을 설정한 경우 그 기간, 설정하지 않은 경우 6년. HIPAA 준비 기능이 활성화된 조직에서는 사용자 지정 기간이 더 길더라도 캡처 시점부터 30일.
채팅, 파일, 프로젝트 콘텐츠는 설정한 기간을 따르므로, 짧은 기간은 구성원이 보관할 수 있는 것과 Compliance API가 반환할 수 있는 것을 제한합니다.
보존 기간은 조직 전체에 적용되는 설정이므로, 회사가 이미 이러한 유형의 콘텐츠에 대해 가지고 있는 데이터 거버넌스 정책에 맞춰 선택하고, 설정하기 전에 해당 정책을 소유한 담당자를 참여시켜 숫자가 승인되도록 하세요. 규제 대상 기능이 조직의 나머지 부분이 원하는 것보다 더 짧은 기간을 필요로 한다면, 모두가 그 더 짧은 기간을 적용받게 되므로, 영향을 받는 팀들이 이를 인지할 수 있도록 그 트레이드오프를 명확히 알리세요.
그 논의에 가져갈 만한 한 가지 제안은 추론 후크입니다: Claude 채팅, Cowork, Claude Code에서 보내는 모든 프롬프트는 Claude가 답변하기 전에 허용 또는 거부 결정을 내리기 위해 보안 팀이나 그들의 공급업체가 운영하는 서버로 전달되므로, Claude에 전혀 도달해서는 안 되는 콘텐츠는 사후에 보존 기간으로 통제되는 대신 입구에서 차단됩니다. 지원 센터의 추론 후크 개요(새 탭에서 열림)에서 추론 후크가 무엇인지와 누가 이를 켤 수 있는지 다룹니다.
아래의 인터랙티브 위젯은 이러한 각 결정이 사후에 데이터에 관한 질문에 답할 수 있는 능력에 어떤 영향을 미치는지 보여줍니다.
Pluto의 가시성
Pluto의 Primary Owner는 전체 롤아웃 전에 Compliance API를 활성화하고, 이를 Pluto가 이미 운영하는 보안 검토 프로세스에 연결하여 지정된 검토자가 기존 프로세스의 일부로 이를 읽도록 했습니다. Cowork와 Claude Code 세션은 Compliance API의 적용 범위에 포함되며, 이들의 운영 텔레메트리는 Platform이 이미 운영하는 관측 가능성 스택으로 내보내집니다. 그리고 Payments & Trust가 다른 부서들이 선택했을 기간보다 더 짧은 기간을 요구했기 때문에, 리스크 담당자는 조직 전체의 보존 기간을 그 더 짧은 숫자로 설정했습니다. 검토자는 Compliance API가 보존 기간에 의해 삭제된 채팅, 파일, 로컬 세션 트랜스크립트를 반환할 수 없기 때문에, Pluto가 그 기간을 넘어 보관해야 하는 모든 것을 삭제되기 전에 Pluto 자체 아카이브로 가져옵니다.
1 · 여러분의 결정
어떤 보존 기간을 설정하며, Compliance API는 켜져 있고 검토자에게 라우팅되어 있습니까?
2 · 선택할 수 있는 옵션
| 선택지 | 선택하는 경우 | 의미와 영향 |
|---|---|---|
| 기존 데이터 정책에 맞추고 Compliance API 켜기 | 기본값입니다. 이러한 유형의 콘텐츠에 대한 데이터 거버넌스 정책이 있고, 지정된 검토자가 이미 운영하는 보안/컴플라이언스 검토 프로세스가 있습니다. | 보존 기간은 이러한 유형의 콘텐츠에 대해 데이터 거버넌스 정책이 이미 명시한 대로 설정됩니다. Compliance API는 켜져 있고 이미 운영 중인 검토 프로세스로 라우팅됩니다. |
| 규제 대상 태세, Compliance API 기대됨 | 규제 대상 데이터를 다루는 경우입니다. | Compliance API는 선택 사항에서 기대되는 사항으로 바뀝니다. 보존 기간은 일반적으로 일반 데이터 정책이 아니라 규제 및 계약상 의무에 맞춰 조직 전체에 설정됩니다. 이 판단은 리스크 담당자의 몫입니다. 조직 전체가 규제 대상 그룹의 숫자를 적용받습니다. |
| Compliance API 끄기, 조건 문서화 | 검토 프로세스가 존재하지 않고 계획도 없는 경우입니다. | 지금은 Compliance API를 꺼두고, 이를 켜게 될 조건을 기록해 두세요. 켜지기 전까지는 해당 기간에 대한 질문에 참고할 활동 피드 이벤트나 로컬 세션 트랜스크립트가 없다는 점에 유의하세요. |
회사 데이터의 일부가 나머지와 완전히 분리되어야 한다면, 이는 보존 기간 설정의 문제가 아닙니다: 이는 레슨 4에서 다룬 별도 조직 문제이므로, 여기서 해결하려 하지 말고 그쪽으로 다시 보내세요.
3 · 나중에 이를 변경한다면
Compliance API와 OpenTelemetry는 언제든지 변경할 수 있는 토글과 대상이지만, Compliance API가 꺼져 있는 기간은 늦게 켜는 것과 동일한 공백을 남깁니다. 보존 기간은 성격이 다릅니다: 설정은 자유롭게 바꿀 수 있지만, 삭제된 콘텐츠는 되돌아오지 않습니다. 나중에 기간을 단축하면 구성원이 이전 기간 동안 쌓아온 기록이 지워집니다. 그러므로 구성원이 나중에 바꾸고 싶어질 숫자 아래에서 작업을 쌓아가기 전에, 기간을 한 번에 합의하세요.
리소스 설정
결정을 내렸다면, 보존 기간과 Compliance API는 Organization settings에서 설정하며, Primary Owner가 Compliance API를 켭니다.
- Enterprise Plan의 사용자 지정 데이터 보존 제어 구성(새 탭에서 열림): 조직 전체의 보존 기간을 설정합니다.
- Compliance API 접근(새 탭에서 열림): 기록을 활성화하고 이미 운영 중인 검토 프로세스로 라우팅합니다.
- 감사 로그 접근(새 탭에서 열림): 관리자 및 구성원 작업 기록으로, 대화 기록과 함께 Compliance API를 통해 가져옵니다.
- Team 및 Enterprise Plan의 사용 분석 보기(새 탭에서 열림): 도입 현황 파악(레슨 12).
- Cowork 모니터링(새 탭에서 열림): Cowork의 내보내기가 포함하는 내용과, 프롬프트·응답·도구 입력 포함 여부를 결정하는 기기 설정입니다.
- 모니터링(새 탭에서 열림): Claude Code의 OpenTelemetry 내보내기를 활성화하고 구성합니다.
- 추론 후크 개요(새 탭에서 열림): Claude에 전혀 도달해서는 안 되는 콘텐츠를 위한 답변 전 허용/거부 게이트를 제안합니다.
- Claude Compliance API 통합 시작하기(새 탭에서 열림): 공급업체들이 Compliance API를 기반으로 구축한 CASB, DLP, eDiscovery, SIEM 통합입니다.
레슨 활동
이것은 일반적으로 상위로 에스컬레이션되는 두 가지 결정 중 하나이므로, 컴패니언 섹션은 레슨 2에서 지정한 가시성 담당자에게 전달할 브리핑 역할도 겸합니다. 이 결정은 리스크 리드가 내립니다. 다음 네 부분으로 구성하세요:
- 세 가지 요소(대화 콘텐츠, 운영 텔레메트리, 보존 기간), 이것이 연결되는 회사 내 프로세스, 그리고 그 프로세스를 소유한 담당자. 기존 프로세스가 없는 요소는 처음부터 검토 프로세스를 구축해야 하는 요소입니다. 이런 요소는 구축하는 데 가장 오래 걸리므로 롤아웃 전에 표시해 두세요.
- 권장하는 보존 기간과 그에 부합하는 기존 정책.
- Compliance API에 대한 권장 사항과, 이를 읽을 담당자의 이름.
- 텔레메트리가 도달하는 위치.
가시성 담당자에게 가져갈 것: 세 가지 요소, 보존 기간 권장 사항, Compliance API 권장 사항과 이를 읽을 담당자, 그리고 텔레메트리가 도달하는 위치입니다. 레슨 2에서 지정한 가시성 담당자에게 전달하고, 그들의 결정이 돌아오면 기록하세요.
→ 워크얼롱 컴패니언의 레슨 11 섹션에 이를 기록하세요.
다운로드
다음 단계
이제 여러분은 무슨 일이 있었는지 증명할 수 있습니다. 롤아웃이 제대로 작동하고 있는지는 다른 질문이며 다른 답을 가지고 있습니다: 분석 보고서가 보여주는 도입 신호를, 레슨 1에서 설정한 롤아웃 목표에 비추어 읽는 것입니다. 다음 레슨에서는 이를 읽는 방법, 이것이 오해를 불러일으킬 수 있는 지점, 그리고 목표에 일정을 부여하는 속도 목표를 설정하는 방법을 보여줍니다.