터미널 명령 하나가 잘못 나가면 폴더 하나가 통째로 사라질 수 있습니다. 그래서 클로드코드에 터미널 명령을 맡기면서 삭제 명령과 유료 API 호출을 막는 가드 두 개를 걸어 두었습니다. 최근 30일 동안 실행된 명령 3,702회 가운데 이 가드가 멈춰 세운 것은 삭제 명령 39회, 유료 API 관련 명령 3회였습니다.
숫자를 하나씩 뜯어 보니 결과가 예상과 달랐습니다. 삭제 차단 39회 중 10회는 막을 필요가 없는 차단이었고, 따로 만든 테스트에서는 삭제 경로 3종을 그대로 통과시켰습니다. AI 코딩 도구에 건 안전장치가 실제로 무엇을 막고 무엇을 놓치는지, 제가 직접 점검한 순서대로 정리했습니다.
저는 확인창 없이 명령이 바로 실행되는 자동 승인 모드로 클로드코드를 씁니다. 편하지만 늘 마음 한쪽이 불안했습니다. 이번 점검은 그 불안에 근거가 있었는지, 걸어 둔 가드가 제 역할을 하는지 명령 기록을 전수 확인한 작업입니다. 클로드코드를 아직 설치하기 전이라면 클로드코드 설치, 앱과 CLI 중 무엇을 고를지부터 보시면 됩니다.
클로드코드 훅 가드가 하는 일
클로드코드 훅 공식 문서에 따르면 훅은 도구를 실행하기 직전에 사용자가 만든 스크립트를 돌려 통과할지 막을지 정하는 기능입니다. 스크립트가 종료 코드 2를 돌려주면 명령은 실행되지 않고, 클로드코드에는 차단 사유만 전달됩니다.
제가 이 PC에 건 가드는 두 가지입니다. 삭제 가드는 rm -rf, Remove-Item, git clean 같은 문자열 패턴으로 삭제 명령을 찾아 막습니다. 캐시나 임시 폴더처럼 삭제해도 되는 경로는 예외로 두었습니다. 유료 API 가드는 유료 API 주소나 키 이름이 들어간 명령을 찾아 막습니다.
유료 API 가드를 지금 방식으로 바꾼 계기가 있습니다. 처음에는 유료 호출이 감지되면 확인창으로 물어보는 방식이었습니다. 그런데 자동 승인 모드 세션에서는 확인창이 무력화되면서 유료 음성 API 호출이 그대로 통과된 적이 있습니다. 그 뒤로는 명령을 일단 막고, 제가 대화에서 말한 숫자와 명령에 붙은 승인 숫자가 일치할 때만 통과시킵니다.
명령 34개를 가드에만 넣어 본 결과
먼저 가드가 얼마나 정확한지 보려고 명령 34개를 직접 준비했습니다. 삭제로 이어지는 명령 17개, 유료 API를 부르는 명령 13개, 승인 숫자를 달리 준 대화 4개입니다. 명령을 실제로 실행하지는 않고, 가드 스크립트에 판정 재료만 넣어 통과·차단 결과를 받았습니다. 같은 명령을 3번씩 넣었고 판정이 흔들린 경우는 없었습니다.
| 가드 | 테스트 건수 | 예상대로 | 놓침 |
|---|---|---|---|
| 삭제 가드 | 17 | 14 | 3 |
| 유료 API 가드 | 13 | 13 | 0 |
| 승인 숫자 대조 | 4 | 4 | 0 |
| 합계 | 34 | 31 | 3 |
놓친 3건은 전부 삭제 가드 쪽이었습니다. 덜 알려진 삭제 명령, 파이썬 삭제 함수, 파일을 지우는 대신 널 장치로 옮기는 방식입니다. 세 경우 모두 가드가 아는 명령어 문자열이 없어서 그대로 지나갔습니다. 문자열 패턴으로 검사하는 방식의 한계입니다.
유료 API 가드는 13건 모두 예상대로 판정했습니다. 유료 주소를 직접 부르는 명령은 물론, 키 값을 일부만 출력하거나 출력 명령 안에 유료 호출을 숨겨 넣은 경우도 잡았습니다. 키 이름만 찾는 조회나 구독형 도구 호출처럼 과금이 없는 명령은 통과시켰습니다.
승인 숫자 대조도 4건 모두 맞았습니다. 대화에서 “이미지 3장 만들어줘”라고 했다면 숫자 3이 붙은 명령은 통과하고, 5가 붙은 명령은 막힙니다. “계속해”처럼 숫자가 없는 대화 뒤의 명령도 막혔습니다.
30일 실제 기록, 차단 42회의 정체
테스트는 제가 만든 명령이었으니, 이번에는 30일 동안 실제로 쌓인 세션 기록을 세어 봤습니다. 세션 파일 수정 시각 기준으로 최근 30일치를 모았고, 같은 호출이 두 파일에 겹쳐 기록된 것은 하나로 셌습니다. 이 PC 한 대에서 저 혼자 쓴 기록입니다.
이 기간 Bash·PowerShell 명령은 3,702회 실행됐고, 그중 삭제 가드가 39회, 유료 API 가드가 3회를 막았습니다. 전체 호출의 약 1.1%입니다.
| 삭제 차단 39회 분류 | 건수 |
|---|---|
| 실제 삭제 시도, 승인 표식 없음 | 28 |
| 승인 표식은 붙였지만 위치 때문에 인식 안 됨 | 8 |
| 삭제 함수 이름이 든 스크립트를 파일로 작성 | 1 |
| 파이썬 코드의 삭제 구문 오탐 | 2 |
유료 API 가드가 막은 3회는 전부 키 이름이나 인증 파일 구조를 확인하는 조회였습니다. 규칙상 막는 게 맞지만 조회 작업이 그때마다 멈췄습니다. 막힌 3회 가운데 실제로 유료 API를 부르려던 명령은 없었습니다.
속도 비용도 확인했습니다. 이 PC에 걸린 훅 5개를 순서대로 돌리면 명령 1회당 판정 시간은 중앙값 776밀리초, 약 0.8초였습니다. 그중 삭제 가드가 410밀리초로 가장 오래 걸렸습니다. 세션을 가볍게 만드는 다른 방법은 클로드코드 시작 토큰 27~29% 줄인 방법에 정리해 두었습니다.
복사본으로 고쳐 본 결과
분류표에서 표식 위치 8회와 파이썬 오탐 2회는 고칠 수 있는 문제로 보였습니다. 운영 중인 삭제 가드는 그대로 두고, 복사본을 만들어 세 가지를 수정했습니다. 승인 표식이 둘째 줄이나 조건문 안쪽에 있어도 표식이 붙은 그 구간만 인정하게 했고, 놓쳤던 삭제 경로 3종을 검사에 추가했고, 파이썬의 목록·사전 항목 삭제 구문은 파일 삭제가 아니므로 뺐습니다.
이 과정에서 실수를 한 번 했습니다. 첫 수정에서 정규식 문법이 틀려 검사할 문자열이 빈 값이 됐는데, 그러자 가드가 삭제 명령을 모두 통과시켰습니다.
테스트 22건 중 13건만 맞았고, 원래 막던 삭제 명령 8건이 통과로 바뀌어 있었습니다. 가드 자체에 오류가 나면 삭제를 막지 못하고 그대로 통과시킨다는 뜻입니다. 테스트 목록이 없었다면 모르고 넘어갔을 겁니다.
문법을 바로잡은 뒤에는 원본이 22건 중 16건, 수정본이 22건 모두 맞았습니다. 22건은 앞의 삭제 테스트 17건에 5건을 더한 것으로, 표식 위치 2건, 표식 붙은 줄과 표식 없는 삭제 줄을 섞은 1건, 파이썬 삭제 구문 1건, 윈도우 삭제 명령 1건입니다.
여기서 원본의 구멍이 하나 더 드러났습니다. 첫 줄에 표식을 붙이면 원본은 명령 전체를 통과시켜서, 둘째 줄에 있는 표식 없는 강제 삭제까지 함께 통과했습니다. 수정본은 그 줄을 막았습니다.
마지막으로 30일 동안 실제로 막혔던 39건을 수정본에 다시 넣어 판정만 받았습니다.
실제 삭제 시도 28건 중 27건은 수정본에서도 막혔고, 나머지 1건은 지금은 원본도 허용하는 임시 폴더 삭제였습니다. 표식 위치 8건과 파이썬 오탐 2건은 모두 통과했습니다. 스크립트 파일을 작성하던 1건은 여전히 막혔습니다.
대가도 있었습니다. 판정 시간이 0.43~0.44초에서 0.59초로, 명령 1회당 약 0.15초 늘었습니다.
여기까지는 복사본에서 확인한 결과이고, 운영 중인 가드에 적용할지는 아직 정하지 않았습니다. 같은 엑셀 정리, 코덱스 198초 vs 클로드코드 131초를 쓸 때도 그랬듯, 판단은 숫자를 다시 확인한 다음에 할 생각입니다.
AI 도구에 가드를 걸 때 먼저 할 일
가드를 직접 만들거나 고칠 계획이라면 이 순서를 권합니다.
- 가드를 수정하기 전에 “반드시 막아야 할 명령”과 “반드시 통과해야 할 명령” 목록부터 만듭니다. 이번에 놓친 3건도 이 목록으로 찾았습니다.
- 실제 세션 기록에서 차단 건수를 세고, 필요한 차단과 오탐을 나눕니다. 세어 보기 전에는 39건 중 10건이 불필요했다는 사실을 몰랐습니다.
- 가드는 결국 문자열 검사라 빠져나갈 길이 남습니다. 삭제 대신 보관 폴더로 옮기는 규칙, 편집 전 자동 백업처럼 가드 하나에 기대지 않는 장치를 함께 둡니다.
- 가드를 고친 뒤에는 일부러 오류를 내 보고, 그 상태에서 명령이 통과하는지 막히는지 확인합니다.
이 기록은 PC 한 대에서 30일 동안 쌓인 것이라 다른 환경에서도 같은 비율이 나온다고 말할 수는 없습니다. 다만 가드는 걸어 두는 것으로 끝나지 않았습니다. 실제 기록을 열어 볼 때마다 고칠 곳이 하나씩 나왔습니다.
