Claude Code 상세 사용법 24: Channels 보안 정책과 장애 대응 루프 | DAKER 커뮤니티

Claude Code 상세 사용법 24: Channels 보안 정책과 장애 대응 루프

Channels를 팀에서 쓰려면 “메시지가 들어온다”보다 “누가 어떤 세션을 깨울 수 있는가”가 먼저다. 공식 문서는 Channels를 research preview로 두고, Team과 Enterprise에서는 관리자가 channelsEnabled와 allowedChannelPlugins로 사용 가능 범위를 통제한다고 설명한다.

1. 조직 정책을 먼저 설계한다

개인 Pro/Max 사용자는 세션마다 --channels로 opt-in한다. Team과 Enterprise는 기본적으로 막혀 있을 수 있으므로 관리자가 켜야 한다. 허용 플러그인을 명시하면 그 목록이 기본 허용 목록을 대체한다.

{
  "channelsEnabled": true,
  "allowedChannelPlugins": [
    { "marketplace": "claude-plugins-official", "plugin": "telegram" },
    { "marketplace": "claude-plugins-official", "plugin": "discord" }   3. permission relay를 과신하지 않는다  일부 채널은 권한 프롬프트를 원격으로 전달할 수 있다. 이 기능은 편하지만, allowlist에 있는 사람이 도구 승인권을 갖는다는 뜻이다. 코드 리뷰, 배포, 비밀값 접근, 데이터 삭제가 섞인 세션에서는 allowlist를 최소화하고, 위험 명령은 Claude Code 권한 설정과 hook으로 한 번 더 막는다.  좋은 기본값은 세션별 목적을 나누는 것이다. 장애 관찰 세션은 읽기와 테스트 중심, 코드 수정 세션은 작은 브랜치와 worktree 중심, 배포 세션은 별도 승인 중심으로 둔다. 이렇게 나누면 agentic coding이 “항상 켜진 자동화”가 아니라 추적 가능한 운영 루프가 된다.  4. 실패 모드와 점검 순서  이벤트가 안 오면 세션이 살아 있는지, 시작 명령에 `--channels`가 있는지, 플러그인이 실제로 승인됐는지 확인한다. Team/Enterprise에서는 MCP 서버가 연결되고 도구가 보여도 채널 메시지는 정책 때문에 막힐 수 있다. startup notice를 읽고 관리자 설정을 확인한다.  메시지는 들어오지만 Claude가 멈추면 권한 프롬프트에서 대기 중일 가능성이 있다. 비대화형 `-p` 실행은 터미널 입력이 필요한 도구를 비활성화하므로 장시간 자동화에는 좋지만, 플랜 승인 같은 상호작용은 설계에서 빼야 한다.  Senior takeaway: Channels의 생산성은 채팅 UI가 아니라 책임 경계에서 나온다. 클로드 코드로 AI 코딩 운영을 만들 때는 “누가 깨우는가, 어디까지 수정하는가, 어떤 증거를 답하는가, 실패하면 누가 이어받는가”를 문서화해야 테스트 자동화와 코드 리뷰 루프가 팀 자산이 된다. 
  ]
}

빈 배열은 허용 목록의 채널 플러그인을 모두 막는 의미로 쓰일 수 있다. 개발 중인 자체 채널을 테스트할 때의 위험 플래그는 운영 정책과 분리한다. 팀 표준은 “승인된 marketplace, 승인된 plugin, 승인된 sender” 세 단계로 잡는다.

2. 장애 대응 루프를 작게 시작한다

처음부터 자동 수정까지 맡기면 위험하다. 첫 루프는 알림 요약과 근거 수집으로 제한한다.

새 CI 실패 알림이 오면 실패한 job, 최근 커밋, 의심 파일을 요약해줘.
파일 수정은 하지 말고, 재현 명령과 다음 확인 순서만 답해줘.

그 다음 단계에서만 수정 권한을 준다.

재현 명령이 통과하지 않으면 테스트 파일과 관련 구현 파일만 수정해줘.
수정 후 같은 명령을 다시 실행하고, 실패하면 원인 후보를 2개로 줄여줘.