Tag: AI보안

클로드 코드든 커서든 코덱스든, 보안 검토를 맡으면 대부분 “AI가 짠 코드가 안전한가”부터 봅니다.

그건 결과물 검토입니다. 도구 검토가 아닙니다.

이 도구들은 로컬 파일을 읽고, 셸을 띄우고, 외부 서버에 붙습니다. 사내에 들일지 정하는 자리에서 봐야 할 건 그쪽입니다.

아래는 클로드 코드의 공개 기록으로 방법을 보여주는 것이고, 확인하는 순서 자체는 어느 도구에나 그대로 적용됩니다.

검토 요청은 보통 이렇게 들어옵니다

실제 도입 검토 자리에서 보안 담당자가 처음 물은 것은 모델 정확도가 아니었습니다. “어느 폴더까지 읽고, 어떤 명령을 실행하며, 그 기록은 어디에 남느냐”였습니다.

개발팀은 소스 코드 전송 여부는 준비해 왔지만 클립보드, 백그라운드 프로세스, 로컬 로그, 자동 업데이트까지는 답을 바로 못했습니다.

그때부터 저는 기능 설명보다 접근 경로를 먼저 목록으로 만듭니다.

릴리스 노트를 거꾸로 읽으면 됩니다

무엇에 접근하는지는 공식 소개 페이지가 아니라 버그 수정 목록에 적혀 있습니다. 고쳤다는 건 건드리고 있다는 뜻이니까요.

검토 대상 도구의 릴리스 노트를 열고 최근 몇 개만 훑으면 됩니다. 아래는 클로드 코드에서 뽑은 예시입니다.

최근 수정 항목 하나를 그대로 옮기면 이렇습니다. 세션을 시작한 디렉터리가 삭제된 뒤에 클립보드 복사, 백그라운드 정리 작업, 백그라운드 세션, 로컬 MCP 로그가 함께 깨지던 문제가 고쳐졌습니다 (출처: gh_cc, 2026-08-23).

한 줄에 네 가지가 들어 있습니다

클립보드를 읽고, 백그라운드에서 도는 세션이 따로 있고, 로컬에 로그를 남깁니다. 그리고 이 셋 다 작업 디렉터리에 묶여 있습니다.

넷 다 보안 부서가 묻는 항목입니다. 개발팀이 “그냥 코딩 도구”라고 설명하는 사이에 검토 대상이 넷 늘어난 겁니다.

셸도 띄웁니다

WSL에서 윈도우 연동을 끈 상태로 powershell.exe 같은 하위 프로세스를 실행하려다 실패하던 문제도 같은 목록에 있습니다 (출처: gh_cc, 2026-08-23).

하위 프로세스를 실행한다는 건 도구의 권한이 곧 실행되는 명령의 권한이라는 뜻입니다. 터미널에서 도는 코딩 도구는 대체로 이렇습니다. 클로드 코드만의 얘기가 아닙니다.

권한을 어디까지 열지 정한 기준

제가 선을 긋는 기준은 “업무에 필요한 최소 범위인가”였습니다. 처음에는 지정한 저장소와 빌드·테스트 명령만 열고, 홈 디렉터리·환경 변수 파일·인증 정보·운영 시스템 접근은 막았습니다. 추가 권한은 편의가 아니라 구체적인 작업 근거가 있을 때 하나씩 열었고, 삭제·배포처럼 되돌리기 어려운 명령은 사람이 확인하게 했습니다.

MCP 연결은 따로 봐야 합니다

MCP로 외부 도구를 붙이면 검토할 것이 한 겹 늘어납니다. 도구가 제공하는 기능이 아니라 별개의 연결이니까요.

인증이 엄격한 서버에서 OAuth가 실패하던 문제를 리디렉트 주소를 localhost 대신 127.0.0.1로 바꿔 해결한 기록이 있습니다 (출처: gh_cc, 2026-08-23).

주소 한 줄이 인증을 가릅니다

이름으로 도는 주소와 숫자로 박힌 주소를 인증 서버가 다르게 취급한다는 뜻입니다. 사내 인증 서버가 엄격한 편이라면 붙는 과정 자체를 확인해야 합니다.

MCP를 몇 개 붙였고 각각이 무엇에 접근하는지는 목록으로 관리해야 합니다. 도구 하나를 승인하고 끝나는 성격의 일이 아닙니다.

컨텍스트에 무엇이 실리는지는 안 보입니다

내장된 claude-api 스킬 하나가 불러오는 컨텍스트 비용이 200k 토큰 이상에서 25k 수준으로 줄었습니다. 참조 문서를 필요할 때만 읽도록 바꾼 결과입니다 (출처: gh_cc, 2026-08-23).

줄었다는 것보다 중요한 사실

줄기 전에는 스킬 하나가 200k 토큰을 먹고 있었다는 뜻이기도 합니다. 그리고 쓰는 사람은 그걸 몰랐습니다.

무엇이 컨텍스트에 실려 외부로 나가는지 사용자가 직접 확인할 수 없다면, 그건 성능 문제가 아니라 검토 항목입니다.

스킬은 계속 늘어납니다. 앤트로픽 엔지니어가 22일 X에 사내에서 특정 스킬을 많이 쓴다고 소개할 만큼 확산 속도가 빠릅니다 (출처: aitimes, 2026-08-23).

한도와 비용도 보안 검토에 들어갑니다

지금 보고 있는 한도가 상시 조건이라는 보장이 없습니다.

앤트로픽은 클로드 코드의 주간 사용 한도를 50% 올리는 한시 프로모션을 진행 중이고, 기간은 2026년 5월 13일부터 8월 31일까지입니다 (출처: anthropic, 2026-08-23). 이 인상은 CLI와 IDE 확장, 데스크톱, 웹 어디서 쓰든 클로드 코드에만 적용됩니다 (출처: anthropic, 2026-08-23).

이번 주가 마지막입니다

지금 한도를 기준으로 도입 규모를 잡으면 다음 주에 계산이 어긋납니다. 파일럿을 8월에 돌리고 9월에 확대하는 일정이라면 특히 그렇습니다.

팀과 엔터프라이즈 사용자는 /usage에서 사용 크레딧 지출 항목을 볼 수 있고, 쓰기 전에는 0%로 표시됩니다 (출처: gh_cc, 2026-08-23).

한도가 운영에 걸렸던 지점

긴 리팩터링과 반복 테스트를 한꺼번에 돌리던 날 사용 한도가 예상보다 빨리 소진돼, 남은 작업을 수작업으로 넘긴 적이 있습니다. 이후에는 파일럿 단계에서 작업 유형별 사용량을 따로 기록하고, 큰 작업은 나누고, 한도가 끊겨도 사람이 이어받을 절차를 남겼습니다. 프로모션 한도나 초기 할인 가격은 정규 운영 용량을 계산할 때 제외합니다.

같은 이름인데 동작이 갈립니다

앤트로픽이 2.1.236 이상 버전의 특정 세션을 노력 수준을 축소하는 실험군에 편입시켰고, 이전 버전은 기존 방식을 유지한다는 내용입니다 (출처: anthropic, 2026-08-23).

팀원마다 다른 도구를 쓰는 셈입니다

같은 이름의 도구를 쓰는데 버전에 따라 내부 동작이 갈립니다. 검토서에 “클로드 코드 도입”이라고만 적으면 이 차이가 안 보입니다.

사내 표준 버전을 정하고 자동 업데이트를 어떻게 다룰지가 검토 항목에 들어가야 합니다.

두 가지 검토를 구분하면 이렇습니다

항목	결과물 검토	도구 검토
보는 대상	AI가 만든 코드	도구 자체의 접근 범위
주체	개발팀·리뷰어	보안·인프라
시점	배포 전	도입 전
놓치면	취약한 코드가 나감	통제 밖 경로가 생김
재발	리뷰로 잡힘	승인 뒤에는 안 잡힘

오른쪽 칸을 건너뛰면 왼쪽 칸을 아무리 잘해도 소용이 없습니다. 검토 없이 승인된 경로는 나중에 발견되지 않습니다.

도입 전 확인할 것

☐ 1. 이 도구가 접근하는 대상을 목록으로 갖고 있나. 파일, 클립보드, 셸, 네트워크
☐ 2. 백그라운드에서 도는 세션과 로컬 로그의 위치를 아나
☐ 3. MCP를 붙인다면 각각이 무엇에 접근하는지 별도로 검토했나
☐ 4. 컨텍스트에 무엇이 실려 나가는지 확인할 방법이 있나
☐ 5. 지금 보고 있는 사용 한도가 상시 조건인가 한시 조건인가
☐ 6. 사내 표준 버전을 정했나. 자동 업데이트를 허용할 것인가

4번이 이 목록에서 제일 답하기 어렵습니다. 나머지는 설정으로 통제되지만 4번은 도구가 보여줘야 알 수 있습니다.

승인이 막혔던 지점

승인이 가장 오래 멈춘 곳도 코드 품질이 아니었습니다. “어떤 코드 조각과 설정값이 컨텍스트로 나갔는지 증명할 수 있느냐”는 질문이었습니다.

화면에서 확인할 방법이 없어 전체 사용을 밀어붙이지 않았습니다. 민감 정보가 없는 샘플 저장소에서 MCP와 불필요한 외부 연결을 끈 제한된 파일럿으로 범위를 줄였습니다.

접근 기록과 차단 기준을 확인한 뒤에만 대상 폴더와 사용자를 단계적으로 넓혔습니다.

정리

보안 검토를 요청받으면 결과물부터 보게 됩니다. 눈에 보이고, 평가 기준도 있으니까요.

그런데 결과물은 리뷰에서 다시 걸립니다. 도구가 열어놓은 경로는 승인이 나면 다시 안 걸립니다. 순서를 바꿔야 하는 이유가 이겁니다.

릴리스 노트를 읽는 게 제일 빠릅니다. 소개 페이지는 무엇을 할 수 있는지 적지만, 수정 목록은 무엇을 건드리는지 적습니다.

도구 이름이 무엇이든 이 순서는 같습니다. 클로드 코드를 예로 들었을 뿐, 커서나 코덱스를 검토할 때도 열어볼 문서는 릴리스 노트입니다.

정체를 모르는 도구를 검토 대상에 올릴지는 공짜로 뿌리는 AI 모델을 업무에 넣을 때에서 다뤘습니다.

입력한 데이터가 어디에 남는지는 기업 데이터가 AI 회사 서버에 며칠 남는가에 정리해뒀습니다.

제가 먼저 확인하는 순서

저는 새 도구를 보면 모델 성능보다 먼저 실행 위치와 권한을 확인합니다. 다음으로 외부 전송·보관 정책, 인증 방식과 MCP 연결, 로컬 로그 위치, 업데이트 정책을 보고, 그 뒤에 한도와 비용을 계산합니다. 코드 품질 평가는 맨 마지막입니다. 앞 단계에서 통제할 수 없는 경로가 하나라도 나오면 성능 테스트까지 가지 않습니다.

자주 묻는 질문

Q1. 개인이 쓰는 것도 검토 대상인가요? 개인 계정으로 회사 코드를 여는 순간 같은 문제가 됩니다. 도구를 회사가 승인했느냐와 무관하게 손대는 곳은 똑같습니다.

Q2. 릴리스 노트를 매번 읽어야 하나요? 도입 검토 시점에 최근 몇 개만 훑어도 윤곽은 잡힙니다. 도구를 바꾸거나 사내 표준 버전을 올릴 때 다시 보면 충분합니다.

Q3. MCP를 안 붙이면 검토가 간단해지나요? 외부 연결이 줄어드니 검토할 것도 줄어듭니다. 다만 파일 접근과 셸 실행은 그대로 남으니 1번과 2번은 여전히 확인해야 합니다.