Codex 민감 파일 제외, 에이전트 보안의 빈틈

.gitignore는 보안 정책이 아니다

OpenAI Codex 이슈 #2847은 단순한 기능 요청처럼 보이지만, 코딩 에이전트 도입의 핵심 리스크를 찌른다. 요청자는 저장소 단위 .codexignore와 전역 ignore 파일을 통해 .env, .pem, id_, .aws, .ssh 같은 민감 경로를 에이전트가 읽거나 모델로 보내지 못하게 하는 메커니즘을 제안했다. 이 이슈는 2025년 8월 28일 열렸고, 민감 파일과 샌드박싱 관련 라벨이 붙어 있다.

핵심은 .gitignore와 보안 ignore의 목적이 다르다는 점이다. .gitignore는 버전 관리 제외 규칙이다. 하지만 에이전트는 로컬 작업을 위해 git에 없는 파일도 읽을 수 있다. 빌드 실패를 고치려면 .env.local의 변수명을 보고 싶어질 수 있고, 배포 오류를 보면 클라우드 credential 위치를 찾으려 할 수 있다. 그래서 "커밋되지 않는다"는 사실은 "모델에 노출되지 않는다"를 보장하지 않는다.

Claude Code 사고 로그, 감사 추적의 착시에서 본 것처럼 에이전트는 파일 읽기와 도구 실행의 흔적을 남기지만, 사후 로그보다 사전 차단이 더 중요하다.

샌드박스와 파일 접근은 별개의 층이다

Codex Security 공식 문서는 저장소 문맥을 활용해 취약점을 찾고, 격리 환경에서 검증하는 보안 기능을 설명한다. Codex Configuration Reference는 사용자 수준 ~/.codex/config.toml과 프로젝트 수준 .codex/config.toml의 역할을 설명한다. 그러나 #2847이 요구하는 것은 설정 편의가 아니라 "이 파일은 절대 읽지 말라"는 강제적 경계다.

비슷한 요구는 이슈 #205와 이슈 #1397에서도 반복됐다. 사용자들은 민감 데이터가 포함된 테스트 파일, 키, 인증서, 클라우드 설정을 에이전트 컨텍스트에서 제외하고 싶어 한다. 이 반복은 시장 신호다. 코딩 에이전트가 장난감에서 업무 도구로 넘어가면 ignore 정책은 선택 기능이 아니라 조달 체크리스트가 된다.

팀 단위 도입의 최소 기준

한국 기업이 Codex, Claude Code, Cursor, Gemini CLI 같은 도구를 도입할 때 가장 먼저 정해야 할 것은 모델이 아니라 데이터 경계다. 사내 저장소에는 .env, service-account.json, kubeconfig, 고객 샘플 데이터, 운영 DB 덤프, SAML 인증서가 섞여 있을 수 있다. 에이전트가 이를 읽지 않도록 보장하지 못하면, 생산성 실험은 보안팀의 반대로 멈춘다.

Newcore, AI 에이전트 신원 보안의 새 범주는 에이전트가 별도 신원과 권한을 가져야 한다는 흐름을 다뤘다. 파일 접근도 마찬가지다. 사람 개발자는 볼 수 있지만 에이전트는 볼 수 없는 파일, 에이전트는 읽을 수 있지만 편집할 수 없는 파일, 자동 모드에서는 금지되는 파일을 나눠야 한다.

실무적으로는 세 가지가 필요하다. 첫째, 저장소에 보안 ignore 파일을 둔다. 둘째, 전역 ignore로 개인 키와 클라우드 자격증명을 막는다. 셋째, CI에서 금지 파일 패턴이 누락됐는지 검사한다. 에이전트가 "읽지 않았다"고 믿는 것이 아니라, 읽을 수 없게 만들어야 한다.

개발자 경험도 보안의 일부다

강한 차단은 개발자 경험을 해칠 수 있다. 에이전트가 .env.example까지 못 읽으면 설정 오류를 고치기 어렵고, node_modules 전체를 숨기면 라이브러리 타입 확인이 불편하다. #2847의 예시가 좋은 이유는 node_modules는 검색 가능하게 두되 .env, 키, 클라우드 계정 폴더는 제외하자는 식으로 목적을 나누기 때문이다.

Daybreak 확장, 보안 AI의 병목은 패치다에서처럼 보안 자동화는 실제 개발 흐름 안에 들어와야 한다. 에이전트가 금지 파일을 요청했을 때는 "접근 거부"만 반환하는 것이 아니라, 대체로 볼 수 있는 .env.example이나 설정 문서를 안내해야 한다. 그래야 보안 정책이 생산성의 적이 아니라 작업 설계가 된다.

자주 묻는 질문

Q1: .gitignore에 넣으면 충분하지 않나요?

A: 충분하지 않다. .gitignore는 커밋 제외 규칙이고, 로컬 파일을 에이전트가 읽는 것을 원천적으로 막는 정책은 아니다.

Q2: 샌드박스가 있으면 민감 파일 노출이 막히나요?

A: 샌드박스는 실행과 네트워크 같은 층을 다룬다. 파일을 읽어 모델 컨텍스트에 포함하는 문제는 별도 접근 정책이 필요하다.

Q3: 어떤 파일을 먼저 막아야 하나요?

A: .env, .env.*, 개인 키, 인증서, 클라우드 credential, SSH와 AWS 폴더, 운영 DB 덤프, 고객 데이터 샘플부터 막아야 한다.

Q4: 팀 정책과 개인 정책 중 무엇이 우선인가요?

A: 둘 다 필요하다. 팀 정책은 저장소 공통 위험을 막고, 개인 전역 정책은 개인 키와 로컬 계정 정보를 보호한다.

Q5: 이 기능이 왜 제품 채택에 중요한가요?

A: 보안팀이 파일 접근 경계를 검증할 수 있어야 코딩 에이전트를 실험 도구가 아니라 업무 도구로 승인할 수 있기 때문이다.