Claude Code를 혼자 쓸 땐 “조심해서 쓰면 되지”가 어느 정도 통한다. 팀으로 넘어가면 그 말이 급격히 약해진다.
왜냐면 팀에선 문제의 단위가 달라지기 때문이다.
- 누가 승인했는지
- 누가 로그를 봤는지
- 누가 비밀정보를 읽을 수 있었는지
- 누가 외부 시스템을 건드릴 수 있었는지
이게 흐려지면 도구가 아니라 운영이 무너진다.
Quick Answer
- 팀에서 Claude Code를 굴릴 때 제일 먼저 세워야 할 건
승인 루프,로그,비밀정보 경계선이다. - 메인 세션이 다 보고 다 쓰는 구조보다, 역할별로 문맥과 권한을 나누는 게 훨씬 안전하다.
- 비밀정보는 “필요할 때만 짧게 노출”이 원칙이고, 발행/배포 같은 외부 write는 별도 승인 lane으로 빼는 게 좋다.
팀 보안 운영의 핵심은 AI를 못 믿는 게 아니라, 사람이 나중에 추적 가능한 구조를 만드는 거다.
이 글이 필요한 사람
- Claude Code를 팀 공용 워크플로에 넣으려는 사람
- 승인 모드가 귀찮아서 자꾸 넓게 열고 싶은 사람
- 비밀정보, 로그, 외부 발행 권한을 어떻게 나눌지 고민하는 사람
지금 결론
| 항목 | 기본 원칙 |
|---|---|
| 승인 루프 | 외부 write와 destructive action엔 유지 |
| 로그 | 누가, 언제, 무엇을 했는지 남김 |
| 비밀정보 | 세션 상시 노출 금지 |
| 역할 분리 | 조사, 수정, 발행을 다르게 둠 |
| 회고 가능성 | 사고 뒤 재구성이 가능해야 함 |
승인 루프는 왜 남겨야 하나
승인 루프를 없애고 싶은 마음은 이해된다. 계속 팝업 뜨면 귀찮거든.
근데 팀에선 그 귀찮음이 두 가지 역할을 한다.
1. 실수 속도를 늦춘다
바로 실행되지 않으니 한 번 더 본다.
2. 책임 경계를 남긴다
누가 승인했는지, 어느 지점에서 외부 행동이 나갔는지 설명할 수 있다.
팀 운영에서 중요한 건 단지 안전만이 아니다. 설명 가능성도 중요하다.
로그는 감시가 아니라 회복 장치다
로그를 싫어하는 팀도 있다. 괜히 감시처럼 느껴져서다.
근데 Claude Code 같은 도구에선 로그를 그렇게만 보면 손해다.
좋은 로그는 이런 질문에 답하게 해준다.
- 어느 세션이었나
- 어떤 파일을 건드렸나
- 외부 write가 있었나
- 누가 승인했나
- 실패 후 어디서부터 복구하면 되나
로그가 있으면 사고 뒤에 시스템을 고칠 수 있다. 로그가 없으면 사람 기억과 감정만 남는다.
비밀정보는 왜 “짧게, 좁게”가 원칙인가
가장 흔한 실수는 이거다.
어차피 개발 도구인데 토큰 정도는 세션이 보면 되지 않나?
짧은 실험에선 그럴 수 있다. 근데 팀 세션, 긴 세션, 복수 에이전트 구조에선 위험도가 확 달라진다.
그래서 비밀정보는 보통 이렇게 다루는 게 낫다.
- 상시 노출하지 않는다
- 필요한 세션에만 좁게 준다
- 조사 세션과 발행 세션을 분리한다
- 로그에 비밀값 자체가 남지 않게 한다
즉 비밀정보는 가지고 있는가보다 얼마나 오래, 얼마나 넓게 노출되나가 더 중요하다.
팀에서 바로 쓸 수 있는 운영 룰 5개
1. 조사 lane과 발행 lane을 분리한다
조사 세션은 넓게 읽고, 발행 세션은 좁게 쓰게 한다.
2. 외부 write는 항상 승인 루프를 남긴다
워드프레스, 배포, 시트 수정, 원격 API 변경은 같은 급이 아니다.
3. 비밀정보는 세션 기본값으로 안 준다
필요한 작업에서만 짧게 노출한다.
4. 로그엔 행동과 승인 사실을 남기고 비밀값은 남기지 않는다
이게 팀 운영에선 꽤 중요하다.
5. subagent는 좁은 책임으로 자른다
리서치, 리뷰, 수정, 발행을 한 에이전트에 다 넣지 않는다.
예시: 팀 운영 표준을 이렇게 적을 수 있다
| 역할 | read | write | external | secrets |
|---|---|---|---|---|
| researcher | 넓게 | 없음 | 없음 | 없음 |
| editor | 지정 범위 | 로컬만 | 없음 | 없음 |
| publisher | 제한적 | 있음 | 있음 | 필요 시 짧게 |
| ops reviewer | 로그/상태 | 제한적 | 승인 중심 | 최소 |
이런 표 하나가 생각보다 강하다. 회의 한 시간보다 잘 버틸 때가 많다.
보안 운영이 무너지는 순간
아래 중 하나가 보이면 노란불이다.
1. 승인 루프가 “귀찮은 팝업”으로만 불리기 시작할 때
그건 곧 사라질 준비를 한다는 뜻이다.
2. 로그가 너무 많아서 안 본다는 핑계가 생길 때
그럼 로그 설계를 다시 해야지, 버리면 안 된다.
3. 비밀정보가 여러 세션에 상시 노출될 때
이건 사고 범위 확장이다.
4. 조사원과 발행자가 같은 몸일 때
책임 분리가 흐려진다.
실수 TOP 5
1. 팀 운영도 결국 개인 습관의 확장이라고 믿는 실수
팀은 추적 가능성과 설명 가능성이 더 중요하다.
2. 로그를 감시 장치로만 보는 실수
회복 장치로 보면 설계가 달라진다.
3. 비밀정보를 편의 때문에 세션 기본값으로 주는 실수
짧게, 좁게가 원칙이다.
4. 승인 루프를 생산성 저하 요소로만 보는 실수
그건 안전장치이자 책임 장치다.
5. 에이전트 역할을 안 나누고 다 시키는 실수
작은 팀장 백 명 생긴다. 시끄럽기만 하다.
FAQ
Q. 팀에서 Claude Code 자동화 범위를 어디까지 여는 게 좋나
로컬 수정까지는 넓게, 외부 write와 destructive는 보수적으로.
Q. 비밀정보가 꼭 필요한 작업은 어떻게 하나
필요한 세션에만 짧게 열고, 끝나면 닫는 쪽이 좋다.
Q. 승인 루프는 언제 줄여도 되나
읽기 전용, 로컬 검증, 비외부 부작용 구간부터다.
다음에 읽을 글
- Claude Code 권한 설계 체크리스트 2026 — hooks·subagents·세션 분리 어디서부터 막아야 하나
- How Claude Code works 2026 – 터미널 UI, 승인 루프, hooks, subagents를 이해하면 운영이 쉬워지는 이유
- Claude Code 소스맵 유출에서 개발자가 진짜 배워야 할 것 2026 — 2.1.88·kairos·buddy보다 중요한 운영 체크리스트
출처와 전제
- 이 글은 Claude Code의 capability/permission/lifecycle 관찰을 팀 보안 운영 규칙으로 재구성한 후속이다.
- 보안 인증 기준서가 아니라 팀 실행 규칙 초안에 가깝다.