# 도구 권한 점검해보기
> **이 장에서 배우는 것**
> 읽는 장이 아니라 **하는 장**입니다. 지금 켜져 있는 도구를 전부 적고, 세
> 갈래로 나누고, 위험한 조합이 있는지 직접 찾습니다.
## 준비물
```
□ 30분
□ 워크스페이스 관리 권한 (admin 이상)
□ 아직 도구를 붙이지 않았다면 — 아래 예시 목록으로 연습해도 됩니다
```
---
## 1단계 — 전부 적기 (5분)
[도구 켜고 끄기](/guide/cn-tool-settings) 화면을 열고 **켜져 있는 것을 하나도
빼지 말고** 적으세요. 내장 도구도 포함입니다.
| 도구 | 무엇을 하나 | 누가 켰나 | 마지막으로 쓴 때 |
|---|---|---|---|
| | | | |
**마지막 칸을 꼭 채우세요.** 여기서 "모르겠다"가 절반을 넘으면 그 자체가
결과입니다.
> 연습용 예시: `파일읽기` · `웹검색` · `사내문서검색` · `메일발송` ·
> `캘린더등록` · `저장소쓰기` · `고객DB조회` · `슬랙게시`
>
> [데이터베이스를 붙였다면](/guide/cn-database) 이것도 함께 적으세요 —
> `db_select` · `db_query` · `db_insert` · `db_update` · `db_delete`
---
## 2단계 — 세 갈래로 나누기 (10분)
각 도구를 **되돌릴 수 있는가**로만 판정하세요. 유용한지 여부는 지금 묻지
않습니다.
| 갈래 | 판정 기준 | 우리 도구 |
|---|---|---|
| **읽기** | 아무것도 안 바꿈 | |
| **되돌릴 수 있는 쓰기** | 지우거나 되돌릴 수 있음 | |
| **되돌릴 수 없음** | 보낸 뒤 취소 불가 | |
헷갈리는 것들의 정답입니다.
```
캘린더등록 → 되돌릴 수 있는 쓰기 (지울 수 있음)
단, 참석자에게 알림이 나갔다면 → 되돌릴 수 없음
슬랙게시 → 되돌릴 수 없음 (지워도 본 사람은 이미 봤습니다)
저장소쓰기 → 되돌릴 수 있는 쓰기 (되돌리기가 있는 경우)
고객DB조회 → 읽기. 하지만 아래 3단계를 보세요
```
**두 번째 줄이 요령입니다.** "지울 수 있는가"가 아니라 **"누군가 이미 봤는가"**로
판단하세요.
---
## 3단계 — 읽기 도구를 다시 보기 (5분)
읽기라고 다 안전하지 않습니다. **읽는 대상**으로 한 번 더 나눕니다.
| 읽는 대상 | 예 | 취급 |
|---|---|---|
| 공개·일반 | 웹검색, 공개문서 | 그대로 |
| **사내 기밀** | 계약서, 인사 파일 | 접근 범위를 좁힐 것 |
| **개인정보** | 고객DB, 연락처 | 보관 근거와 기간 확인 |
```
□ 굵은 두 줄에 해당하는 도구가 있나?
□ 있다면 그 도구가 켜져 있는 워크스페이스에 외부 입력 경로
(위젯·채널·메일)가 함께 있나?
```
**두 질문 모두 예라면 지금 바로 나눠야 합니다.**
---
## 4단계 — 조합 찾기 (10분)
이게 이 실습의 핵심입니다. 각 도구는 안전한데 **둘을 이으면** 경로가 생깁니다.
```
[민감한 것을 읽는 도구] + [밖으로 나가는 도구] = 유출 경로
```
목록에서 실제로 이어 보세요.
| 읽는 쪽 | 나가는 쪽 | 생기는 경로 | 승인 있나 |
|---|---|---|---|
| 사내문서검색 | 메일발송 | 사내 문서를 외부로 | □ |
| 고객DB조회 | 슬랙게시 | 개인정보를 채널로 | □ |
| | | | □ |
**빈 칸을 채우면서 세 개 이상 나오면 정상입니다.** 조합은 도구 수의 제곱으로
늘어나기 때문에, 도구를 줄이는 것이 가장 강력한 통제입니다.
### 여기서 나오는 결론은 둘 중 하나입니다
```
1. 나가는 쪽에 사람 승인을 건다 ← 대부분 이쪽
2. 두 도구를 다른 워크스페이스로 나눈다 ← 승인 지점이 없을 때
```
---
## 5단계 — 정리 목록 만들기 (5분)
```
[즉시]
□ 3개월간 안 쓴 도구 끄기
□ 되돌릴 수 없는 도구 중 승인이 없는 것 — 승인을 걸거나 끄기
[이번 주]
□ 굵은 조합 경로에 승인 배치
□ 외부 입력 경로와 사내 자료가 같은 워크스페이스면 분리 계획
[분기]
□ 이 표를 다시 채우기 — 도구는 늘어나기만 합니다
```
---
## 흔한 결과 세 가지
### "켜져 있는 줄도 몰랐던 도구가 있습니다"
가장 흔합니다. 붙일 때는 필요했고, 필요가 없어진 뒤에 아무도 안 껐습니다.
**끄는 절차가 없는 것이 진짜 문제**이므로 분기 점검을 달력에 넣으세요.
### "승인 지점이 아예 없습니다"
그렇다면 되돌릴 수 없는 도구는 **붙이지 않는 것이 맞습니다.** 승인 없이
메일발송을 켜두는 것보다 초안까지만 만들고 사람이 보내는 편이 낫습니다.
### "조합이 열 개 넘게 나옵니다"
도구가 너무 많습니다. [도구가 많아질 때](/guide/mcp-too-many-tools)에서 본
대로 선택 정확도도 같이 떨어지고 있을 것입니다. **안 쓰는 것부터 끄세요.**
---
## 확인
**1. 도구를 세 갈래로 나눌 때 판정 기준은 무엇입니까?**
답
**되돌릴 수 있는가**입니다. 유용한지, 자주 쓰는지는 지금 묻지 않습니다. 그리고
"지울 수 있는가"보다 **"누군가 이미 봤는가"**로 보는 편이 정확합니다 — 슬랙
게시는 지워도 본 사람은 이미 봤습니다.
**2. 개별 도구가 다 안전한데도 조합을 따로 점검하는 이유는?**
답
**민감한 것을 읽는 도구와 밖으로 나가는 도구가 이어지면 유출 경로가 되기
때문**입니다. 그래서 승인은 개별 도구가 아니라 "밖으로 나가는 동작"에 걸어야
하고, 도구 수를 줄이는 것이 가장 강력한 통제입니다.
**3. 승인 지점이 없는 조직이라면 어떻게 해야 합니까?**
답
**되돌릴 수 없는 도구를 붙이지 않는 것이 맞습니다.** 초안까지만 만들고 발송은
사람이 하는 구성이 낫습니다. 승인 없이 되돌릴 수 없는 도구를 켜두는 것이 가장
나쁜 조합입니다.
---
파트가 끝났습니다. 이제 이 모든 것을 **매일 일하는 방식**으로 만드는
방법론입니다 → [애자일이 풀었던 문제와 남은 병목](/guide/ha-agile-limits)