ai context 공유 정책의 잠수함 패치 — 내 코드를 노출시킬 수 있다

TL;DR

Android Studio와 Firebase Studio에서 사용하는 .aiexclude 파일의 빈 파일 동작이 두 공식 문서 간에 다르게 서술되어 있다. Firebase Studio 문서는 "빈 파일 = 전체 차단"이라고 명시하는 반면, Android Studio 문서는 이 동작에 대해 완전히 침묵한다. 더 중요한 건, 과거 문서에는 "곧 변경될 예정"이라는 언급이 있었다는 점이다. 이 조용한 행동 변경은 개발자가 의도치 않게 전체 코드베이스를 AI에 공유하는 보안 사고로 이어질 수 있다.

배경: `.aiexclude`가 뭔데?

Android Studio에 Gemini가 통합되면서 Google은 .gitignore와 유사한 .aiexclude 파일을 도입했다. 이 파일을 프로젝트 루트나 특정 폴더에 두면, 해당 파일/폴더가 Gemini의 컨텍스트에서 제외된다. 코드 자동완성, 채팅 기반 질의, Codebase Indexing 등 모든 AI 기능에 적용된다.

개념은 단순하다. local.properties에 API 키가 있다면? .aiexclude에 추가해라. 특정 내부 서비스의 엔드포인트 목록이 있다면? 역시 마찬가지다. 이 파일을 Git에 커밋해두면 팀 전체에 적용되는 소스코드 레벨의 AI 접근 제어가 된다.

처음 이 기능을 접했을 때 나름 잘 설계되었다고 생각했다. .gitignore와 유사한 문법, 익숙한 패턴 매칭, 빈 파일일 때의 명확한 의미. 특히 그 마지막 항목—빈 파일 = 전체 차단—은 보안을 기본값으로 삼는 훌륭한 설계 원칙처럼 보였다.

그런데 최근 두 개의 공식 문서를 나란히 놓고 읽다가 뭔가 이상한 걸 발견했다.

두 문서, 두 개의 이야기

Firebase Studio 문서는 이렇게 명시한다:

"An empty .aiexclude file blocks all files in its directory and all sub-directories. This is the same as a file that contains **/*."

명확하다. 빈 파일 = 전체 차단.

Android Studio 문서는? 빈 파일 동작에 대한 언급이 아예 없다.

대신 이런 설명이 있다:

"Much like a .gitignore file, an .aiexclude file tracks files that shouldn't be shared with Gemini in Android Studio."

문제는 이 비유다. .gitignore에서 빈 파일은 아무것도 무시하지 않는다. "이것과 비슷하다"고만 해놓고 핵심 차이점을 설명하지 않으면, 개발자는 자연스럽게 .gitignore 멘탈 모델을 그대로 적용하게 된다.

즉, "빈 .aiexclude는 아무것도 안 하겠구나" 라고 잘못 이해할 수 있는 것이다.

문서에서 발견한 섬뜩한 한 줄

더 깊이 파고들다 보니 이런 문장을 발견했다:

"The .aiexclude file usage will soon change so that instead of an empty file to exclude all files, the .aiexclude file should just contain a *."

번역하면: "앞으로 빈 파일로 전체를 차단하는 동작이 바뀔 예정이며, 대신 *를 명시적으로 써야 한다."

이게 무슨 의미인지 생각해보자. 지금까지 빈 파일 = 전체 차단이라는 동작에 의존해서 .aiexclude를 프로젝트에 체크인해 놓은 팀들이 있을 것이다. 실제로 많은 튜토리얼 블로그들이 "빈 파일을 루트에 두면 전체 프로젝트를 AI에서 차단할 수 있다"고 안내했다.

만약 이 동작이 조용히 변경되어 빈 파일이 더 이상 아무것도 차단하지 않게 된다면? 개발자들은 자신이 보호받고 있다고 믿겠지만, 실제로는 전체 코드베이스가 AI에 공개되어 있는 상황이 된다.

실제 위협 시나리오

이게 단순한 이론적 불일치가 아닌 이유를 보여주는 시나리오들이다.

시나리오 1 — 팀 프로젝트의 API 키 노출

6개월 전, 팀 리드가 "AI에 코드 공유하지 않으려면 빈 .aiexclude를 루트에 두면 된다"는 튜토리얼을 보고 설정했다. 오늘 Android Studio를 업데이트했다. 빈 파일 동작이 변경되었지만 어떤 경고도, 마이그레이션 안내도 없었다. 이제 local.properties의 Maps API 키, Firebase 프로젝트 ID, 내부 API 엔드포인트 전부가 Gemini의 컨텍스트에 들어간다.

시나리오 2 — Firebase Studio vs Android Studio 혼용 팀

Firebase Studio에서 작업하는 팀원은 빈 .aiexclude = 전체 차단으로 알고 있다. Android Studio를 쓰는 다른 팀원은 문서를 읽고 "아무것도 안 하나?"라고 이해한다. 같은 파일, 같은 팀, 다른 이해.

시나리오 3 — 오픈소스 기여자

개발자가 오픈소스 프로젝트를 fork했다. 원본 프로젝트엔 빈 .aiexclude가 있었다. 이 파일이 "전체 차단"인지 "아무것도 안 함"인지에 따라 자신의 로컬 환경 설정 파일들이 AI에 노출될 수도, 안 될 수도 있다.

커뮤니티에서도 이미 문제가 제기됐다

Google의 Issue Tracker에는 이미 2024년 1월에 Issue #315250780 — "StudioBot empty aiexclude" 가 등록되어 있다. 빈 .aiexclude 파일의 동작이 명확하지 않다는 내용이다. 이 이슈는 2025년 1월 기준으로 여전히 해결되지 않은 상태다.

또한 Issue #321803298에서는 어떤 파일이 .aiexclude에 의해 실제로 차단되고 있는지 시각적으로 확인하는 기능 자체가 없다는 문제가 제기됐다. IDE 내에서 "이 파일이 AI에 공유되고 있나요?"를 확인할 방법이 없다.

보안 설정인데 결과를 확인할 수 없고, 동작도 문서마다 다르고, 변경 예고도 조용히 지나간다.

이게 버그인가, 정책 변경인가?

판단하기 어렵다. 가능한 해석은 세 가지다.

① 버그 수정: 빈 파일 = 전체 차단은 애초에 의도하지 않은 동작이었고, .gitignore 관례에 맞게 수정되는 것이다.

② 정책 변경: AI 기능의 유용성을 높이기 위해 opt-out을 더 명시적으로 만들려는 의도적 변경이다.

③ 플랫폼별 분기: Firebase Studio와 Android Studio가 서로 다른 컨텍스트를 갖다 보니 정책을 달리 적용하고 있다.

어느 쪽이든 문제는 같다: 사용자에게 충분히 고지되지 않았다.

지금 당장 확인해야 할 것

이 글을 읽는 Android 개발자라면:

.aiexclude가 비어있다면 * 하나를 추가해라. 어떤 버전, 어떤 플랫폼에서든 명시적으로 전체 차단 의도를 표현한다.
local.properties는 별도로 확인해라. .gitignore에 들어있더라도 .aiexclude 처리와는 별개 경로가 있을 수 있다.
Firebase Studio와 Android Studio를 동시에 사용하는 팀이라면, 양쪽 문서를 대조하며 동작을 실제로 테스트해봐야 한다.
Codebase Indexing이 켜져 있는지 확인해라. 이 기능이 활성화된 경우, .aiexclude로 제외하지 않은 파일 전부가 인덱싱된다.

마치며

이 글을 쓰는 이유는 Google을 비난하려는 게 아니다. AI 도구와 IDE의 통합이 워낙 빠르게 진행되다 보니 문서화가 따라가지 못하는 건 이해한다.

하지만 보안 관련 설정만큼은 달라야 한다. "빈 파일이 전체 차단이었는데 이제 아무것도 안 한다"는 변경이 조용히 일어나면, 그건 기능 변경이 아니라 **보안 회귀(security regression)**다. 사용자가 인지하지 못한 채 코드 공유 범위가 바뀌는 건, 개발자 생산성 도구가 넘어서는 안 될 선이라고 생각한다.

참고: Firebase Studio — exclude-files | Android Studio — aiexclude | Issue Tracker #315250780