삼태연구소
SAMTAELABS삼태연구소
가이드2026년 10월 18일·11분 읽기

AI 코딩 에이전트 도입 전에 '파일 접근 권한의 범위'를 요구사항으로 먼저 정해야 하는 이유

AI 코딩 에이전트파일 접근 권한보안 요구사항벤더 선정Claude CodeElectron 보안개발 환경 보안
AI 코딩 에이전트 도입 전에 '파일 접근 권한의 범위'를 요구사항으로 먼저 정해야 하는 이유
목차(5)

Claude Code Desktop에서 발견된 취약점이 공개됐을 때, 많은 팀의 첫 반응은 "패치 버전이 나오면 업데이트하자"였다. 그 반응 자체가 문제다. 취약점이 패치됐더라도, 그 에이전트가 개발자 로컬 환경의 파일 시스템에 얼마나 깊이 접근할 수 있는지를 도입 전에 한 번도 검토하지 않았다면, 같은 종류의 리스크는 다음 릴리스에서 다른 방식으로 돌아온다.

이 글은 특정 취약점의 기술적 세부사항을 분석하는 글이 아니다. 그 취약점이 드러낸 구조적 질문, 즉 AI 코딩 에이전트를 도입할 때 팀이 요구사항 단계에서 먼저 정해야 할 파일 접근 권한의 범위와 격리 조건이 무엇인지를 다룬다.

취약점이 아니라 아키텍처 결정을 먼저 봐야 한다

Claude Code Desktop에서 확인된 공격 경로는 에이전트가 코드를 읽고 편집하는 과정에서 자동으로 렌더링되는 미리보기 기능을 경유했다. 핵심은 Electron 기반 앱이 로컬 파일을 특정 조건에서 file:// URL로 로드하고, 그 경로에서는 샌드박스의 스크립트 차단 정책이 적용되지 않았다는 점이다. 그 결과, 악의적으로 조작된 HTML 파일이 렌더링될 때 스크립트가 제한 없이 실행되면서 개발자 로컬 환경의 SSH 키, AWS 자격증명, OAuth 토큰 같은 파일을 외부 서버로 전송할 수 있었다.

Anthropic은 이 취약점을 CVSS 8.7(High)로 평가했고, 영향 범위를 호스트에서 코드를 직접 실행하는 것과 동등한 수준으로 봤다. 패치가 배포됐지만, 연구진은 초기 패치 이후에도 Web Worker를 활용한 우회 경로를 별도로 확인했다. 이 사실이 시사하는 건 간단하다. 에이전트가 로컬 파일 시스템에 광범위하게 접근할 수 있는 구조 자체가 유지되는 한, 방어의 충분성은 항상 불확실하다.

여기서 판단의 출발점이 달라진다. "이 에이전트가 안전한가"가 아니라, "이 에이전트가 우리 환경에서 어디까지 접근할 수 있고, 그 범위를 우리가 통제하고 있는가"를 먼저 물어야 한다.

요구사항 단계에서 정해야 할 세 가지 축

AI 코딩 에이전트의 파일 접근 권한은 크게 세 가지 축에서 요구사항으로 명시할 수 있다.

첫째, 접근 허용 경로의 범위. 에이전트가 읽고 쓸 수 있는 디렉터리를 프로젝트 저장소 내부로 제한할지, 아니면 홈 디렉터리 전체에 접근할 수 있는지를 명시해야 한다. 이 범위가 넓을수록 에이전트는 더 많은 컨텍스트를 활용해 작업할 수 있지만, 자격증명 파일이나 환경 변수 파일이 같은 접근 범위 안에 놓인다. 범위를 좁히면 에이전트의 작업 유연성이 줄어드는 대신, 사고가 발생했을 때 노출되는 파일의 종류와 수가 제한된다. 어느 쪽을 선택하든 그 선택의 근거를 요구사항에 남겨야 한다. 그래야 나중에 트레이드오프를 객관적으로 검토할 수 있다.

둘째, 렌더링과 실행 환경의 격리 수준. 에이전트가 파일을 읽는 것과, 그 파일의 내용을 화면에 렌더링하거나 실행하는 것은 다른 작업이다. 위에서 언급한 취약점은 바로 이 둘이 같은 권한 맥락에서 처리됐기 때문에 발생했다. 에이전트 도구가 파일 내용을 렌더링하거나 미리보기하는 기능을 제공한다면, 그 렌더링 환경이 파일 시스템 접근 권한으로부터 격리되어 있는지를 검토해야 한다. 격리 여부를 벤더에게 직접 물어야 하고, 답변이 애매하면 구체적으로 재질문해야 한다.

셋째, 자격증명 파일의 물리적 분리. SSH 키, 클라우드 접근 키, 패키지 레지스트리 토큰 같은 자격증명 파일이 에이전트의 접근 범위 안에 있는지를 점검해야 한다. 개발자 로컬 환경은 편의를 위해 많은 자격증명을 홈 디렉터리에 평문으로 저장하는 경향이 있다. 에이전트가 그 환경에서 동작한다면, 에이전트의 파일 접근 범위와 자격증명의 물리적 위치 사이의 관계를 사전에 정리해두지 않으면 리스크 평가 자체가 불가능하다.

벤더에게 물어야 할 구체적인 질문

에이전트 도구를 선정하거나 평가할 때, 아래 질문들은 벤더의 답변 수준을 통해 해당 도구의 보안 설계 성숙도를 간접적으로 판단하는 데 도움이 된다.

파일 시스템 접근 범위와 관련해서: 에이전트가 기본 설정에서 접근할 수 있는 경로가 프로젝트 디렉터리로 한정되는지, 아니면 운영체제의 사용자 홈 디렉터리 전체인지를 묻는다. 이를 설정으로 제한할 수 있는지, 그 제한이 에이전트 프로세스 수준에서 적용되는지 아니면 단순히 UI 레벨의 경고인지를 확인한다.

렌더링 환경의 격리와 관련해서: 에이전트가 파일 내용을 미리보기하거나 렌더링하는 기능이 있다면, 그 렌더링 컨텍스트가 파일 시스템 접근 API와 분리되어 있는지를 묻는다. Content Security Policy 같은 표준 웹 보안 정책이 렌더링 경로 전체에 일관되게 적용되는지도 확인한다.

자격증명 처리와 관련해서: 에이전트가 작업 중에 자격증명 파일을 직접 읽거나 참조하는 경우가 있는지, 있다면 그 파일이 외부 네트워크 요청 경로에 노출될 가능성이 있는지를 확인한다. 에이전트가 Electron 기반인 경우, Chromium 렌더러에서 발생하는 네트워크 요청을 감사할 수 있는 로그가 제공되는지도 물어볼 만하다.

이 질문들에 대한 답변이 문서화되어 있지 않거나, "현재 패치됐습니다"처럼 특정 이슈에 대한 대응으로만 답변이 돌아온다면, 그 벤더는 파일 접근 권한의 구조적 설계에 대한 명확한 정책을 아직 갖추지 못한 것으로 봐야 한다.

격리 수준을 검증하는 순서

요구사항을 정한 뒤에는 실제 환경에서 그 조건이 충족되는지를 순서대로 확인해야 한다. 단계를 건너뛰면 요구사항은 문서 위에만 남는다.

1단계: 접근 경로 매핑. 에이전트를 설치하고 실행할 때, 프로세스가 실제로 어떤 파일 경로에 접근하는지를 운영체제의 파일 접근 감사 도구로 확인한다. macOS라면 Endpoint Security Framework나 fs_usage, Linux라면 auditd 또는 strace를 활용할 수 있다. 에이전트가 사용자 홈 디렉터리의 .ssh, .aws, .config 같은 경로에 접근하는 이벤트가 포착되면, 그 경로가 요구사항에서 허용한 범위인지를 확인한다.

2단계: 렌더링 컨텍스트 격리 확인. 에이전트가 HTML이나 마크다운 파일을 렌더링하는 기능을 사용한다면, 테스트 파일에 외부 요청을 시도하는 단순한 스크립트를 삽입하고, 그 요청이 실제로 차단되는지를 네트워크 레벨에서 확인한다. UI에서 아무 반응이 없더라도 네트워크 요청이 발생할 수 있으므로, 프록시 도구를 통해 실제 트래픽을 확인하는 것이 중요하다.

3단계: 자격증명 노출 범위 점검. 에이전트의 접근 범위 안에 실제 자격증명 파일이 있는지를 목록화한다. 이 작업은 벤더 평가와 별개로, 개발자 로컬 환경의 자격증명 관리 정책을 점검하는 기회이기도 하다. 자격증명을 홈 디렉터리의 평문 파일로 관리하는 대신, 운영체제의 키체인이나 별도의 시크릿 관리 도구를 통해 접근하도록 환경을 정비하면, 에이전트의 접근 범위가 넓더라도 노출 위험을 줄일 수 있다.

4단계: 운영 중 변화 감지 설정. 에이전트 버전이 업데이트될 때마다 파일 접근 패턴이 변할 수 있다. 업데이트 이후 접근 경로 매핑을 반복하거나, CI 환경에서 에이전트를 실행할 때 허용되지 않은 경로 접근이 발생하면 경고하는 정책을 설정해두는 것이 좋다.

편리함과 리스크를 같은 기준으로 비교하려면

AI 코딩 에이전트가 로컬 파일 시스템에 광범위하게 접근할 수 있다는 사실은 그 자체로 문제가 아니다. 에이전트가 프로젝트 전체를 이해하고 유의미한 코드 변경을 제안하려면 어느 정도의 파일 접근 권한은 필요하다. 문제는 그 범위가 얼마나 넓어야 하는지, 그리고 넓어진 범위가 어떤 조건에서 리스크로 전환되는지를 팀이 처음부터 인지하고 있지 않을 때 발생한다.

패치가 나올 때마다 업데이트하는 방식은 개별 취약점에 대응하는 전술이다. 하지만 파일 접근 권한의 범위와 격리 조건을 요구사항으로 먼저 정해두면, 새로운 취약점이 발견됐을 때 "이게 우리 환경에서 실제로 문제가 되는가"를 즉각 판단할 수 있다. 범위를 좁게 설정해두지 않았다면, 그 판단 자체가 불가능해진다.

요구사항이 없으면 트레이드오프도 없다. 편리함의 크기를 모르는 상태에서는 리스크의 크기를 재는 것도 어렵다.

다음 단계로 해야 할 일이 있다면, 현재 팀에서 사용 중인 AI 코딩 에이전트가 개발자 로컬 환경에서 어느 경로까지 접근하는지를 지금 당장 파일 접근 감사 도구로 한 번 확인해보는 것이다. 그 결과가 요구사항 문서와 일치하는지 보는 것이 출발점이다.

자주 묻는 질문

Q.AI 코딩 에이전트를 개발자 로컬 환경이 아니라 격리된 컨테이너 환경에서만 실행하면 이 문제를 완전히 회피할 수 있나요?

격리된 컨테이너 환경은 파일 접근 범위를 물리적으로 제한할 수 있어서 리스크를 줄이는 데 효과적입니다. 다만 컨테이너 내부에도 자격증명이 마운트되어 있다면 그 범위 안에서는 동일한 리스크가 존재합니다. 컨테이너 환경을 선택하더라도, 컨테이너 안에서 에이전트가 접근할 수 있는 경로와 마운트된 자격증명의 범위를 별도로 검토해야 합니다.

Q.Electron 기반이 아닌 AI 코딩 에이전트는 이 종류의 취약점에서 구조적으로 안전한가요?

Electron 기반 앱은 Chromium 렌더러가 표준 웹 API 전체에 접근할 수 있다는 특성 때문에, 렌더링 격리가 불완전할 때 리스크가 커지는 경향이 있습니다. 그러나 다른 아키텍처의 에이전트도 파일 시스템 접근 권한을 갖는 방식과 범위가 다를 뿐, 구조적으로 무결하다고 단정할 수 없습니다. 아키텍처보다 "이 에이전트가 실제로 어떤 경로에 접근하고, 그 접근이 어떻게 격리되는가"라는 질문이 더 유효합니다.

직접 따라하기 어려우면, 대표 개발자가 1:1로 진행해드립니다

누적 매출 20억 / 1인 에이전시. 중간 과정 없이 의도 그대로.

관련 아티클

관련 사례

이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.