AI 코딩 에이전트가 열어둔 보안 사각지대, 지금 당장 확인해야 할 세 가지

Claude Code, Cursor, GitHub Copilot처럼 코드를 직접 실행하고 파일을 읽고 쓰는 AI 에이전트를 이미 사용하고 있다면, 이 글은 당신 프로젝트에 지금 바로 해당되는 이야기다. 에이전트가 편리한 만큼, 기존 보안 체계가 커버하지 못하는 구간이 생겼다는 점을 구체적으로 짚는다.

---

1. 왜 지금 이걸 봐야 하나

예전에는 개발자가 코드를 짜고, 리뷰하고, 커밋하는 흐름 안에서 사람의 눈이 최소 세 번 지나갔다. 각 단계마다 실수를 잡을 기회가 있었다.

지금은 다르다. AI 에이전트는 이 흐름을 건너뛴다. 파일을 읽고, 외부 URL을 호출하고, 쉘 명령을 실행하는 일을 사람 확인 없이 처리한다. 문제는 이 동작이 버그가 아니라는 점이다. '의도된 기능'으로 설계된 자동화가 보안 구멍이 된다.

Security Boulevard가 최근 정리한 분석은 단순한 우려가 아니다. 업계가 "에이전트 시대의 보안 공백"을 공식 의제로 다루기 시작했다는 신호다. 같은 날 Snyk도 Anthropic Claude Enterprise 통합을 발표하며 에이전트 개발 흐름 안에 보안 스캔을 직접 끼워 넣는 방식을 선보였다. 우연이 아니다. 생태계 전체가 같은 문제를 인식하고 있다는 뜻이다.

독자 입장에서 솔직하게 말하면, 에이전트가 대신 짜준 코드의 품질보다 에이전트가 움직이는 범위 자체가 더 큰 리스크가 될 수 있다.

---

2. 핵심 아이디어

에이전트에게 넘긴 권한의 경계가 곧 보안의 경계다.

비유로 풀면 이렇다. 예전 보안 검사는 현관문 하나를 잠갔다. 지금 AI 에이전트는 창문, 환풍구, 다용도실 문을 동시에 열 수 있는 열쇠를 들고 집 안을 돌아다닌다. 현관문만 잠가서는 부족하다.

실제로 문제가 되는 지점은 세 가지로 정리된다.

취약 구간	구체적인 상황	위험도
파일 시스템 권한	에이전트 권한이 프로젝트 폴더 밖까지 열려 있음	높음
외부 의존성 자동 설치	npm 패키지, API 엔드포인트를 검증 없이 불러옴	높음
실행 로그 부재	에이전트가 무엇을 했는지 사후 추적 불가	중간~높음

세 번째가 특히 간과되는 경우가 많다. 권한을 잘 설정해도, 무슨 일이 있었는지 기록이 없으면 침해 발생 후 원인 파악 자체가 불가능해진다.

---

3. 바로 따라하는 방법

Claude Code 기준으로 권한 범위와 로그 위치를 확인하는 방법이다. 다른 에이전트도 개념은 동일하다.

① 에이전트 권한 범위 확인

.claude/settings.json 또는 settings.local.json을 열어 허용된 도구 목록을 직접 확인한다.

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "WebFetch(*)"
    ]
  }
}

allow 목록에 Bash(*)처럼 와일드카드로 열려 있다면 즉시 범위를 좁혀야 한다. 프로젝트 외부 경로 접근이 허용돼 있는지 특히 확인한다.

② 외부 의존성 자동 설치 차단

에이전트가 npm install 또는 pip install을 승인 없이 실행하도록 돼 있는지 확인한다. 아래처럼 허용 명령을 명시적 스크립트로만 제한한다.

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ]
  }
}

npm install *, pip install * 형태는 deny 목록에 올리거나 허용 목록에서 제외한다.

③ 실행 로그 위치 확인

Claude Code 실행 로그는 기본적으로 아래 경로에 쌓인다.

# macOS / Linux
ls ~/.claude/logs/

# 최근 세션 로그 확인
ls -lt ~/.claude/logs/ | head -10

로그 파일이 없거나 경로가 다르다면 다음 명령으로 현재 설정을 확인한다.

cat ~/.claude/settings.json | grep -i log

로그가 어디에도 남지 않는 상태라면, 에이전트가 무엇을 실행했는지 기록부터 활성화하는 것이 우선이다.

④ 검증 명령 — 현재 권한 요약 출력

# 프로젝트 설정과 글로벌 설정을 함께 확인
cat .claude/settings.json 2>/dev/null || echo "프로젝트 설정 없음"
cat ~/.claude/settings.json 2>/dev/null || echo "글로벌 설정 없음"

두 파일을 나란히 놓고, allow 항목이 실제 작업 범위보다 넓게 열려 있지 않은지 대조한다.

---

4. 운영할 때 조심할 점

최소 권한 원칙은 에이전트에도 그대로 적용된다. 처음 설정할 때는 편의를 위해 넓게 열어두는 경우가 많다. 그 상태로 몇 달이 지나는 게 진짜 문제다. 분기에 한 번이라도 settings.json을 열어 필요 없어진 권한이 남아 있는지 점검하는 루틴을 만들어야 한다.

CI/CD 파이프라인과 에이전트 권한을 분리한다. 로컬에서 에이전트를 돌릴 때 열어둔 권한이 CI 환경에서도 그대로 적용되는 경우가 있다. CI 환경의 settings.json은 별도로 관리하고, 쉘 명령 실행 범위를 더 좁게 유지한다.

외부 패키지 공급망 공격(supply chain attack)에 주의한다. 에이전트가 자동으로 패키지를 설치할 수 있다면, 타이포스쿼팅(오탈자 패키지)이나 악성 업데이트가 검증 없이 프로젝트에 들어올 수 있다. 패키지 설치는 반드시 사람이 승인하는 단계를 남긴다.

Mac과 Linux 환경의 파일 권한 차이를 확인한다. macOS에서 개발하고 Linux 서버에 배포하는 경우, 에이전트가 macOS에서 접근하던 경로 구조가 서버에서 다르게 동작할 수 있다. 특히 홈 디렉터리 기반 경로(~/)를 사용하는 설정은 환경마다 결과가 달라진다.

---

마무리

에이전트 권한 경계를 모르는 채 코드만 빠르게 만드는 건, 자물쇠 없는 금고에 돈을 쌓는 것과 같다.

오늘 확인할 항목은 딱 세 줄이다. 에이전트 권한이 프로젝트 폴더 밖으로 나가는가. 외부 패키지를 자동 설치하도록 허용돼 있는가. 실행 로그가 어디에 남는가. 이 세 가지 중 하나라도 모른다면 지금 바로 settings.json을 열어보는 것이 시작이다.

다음 글에서는 Claude Code의 settings.json 권한 설정을 실제 프로젝트 유형별로 정리하고, CI 환경과 로컬 환경을 어떻게 분리해서 관리하는지 다룰 예정이다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: AI 인사이트
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독