AI-어시스턴트가 외부로 전송하는 것: mitmproxy 트래픽 감사

```html

2026년 8월 11일, Hacker News에 올라온 분석 기사는 AI 어시스턴트를 작업 IDE에서 사용하는 모든 사람이 읽어야 할 내용입니다: 연구자가 GitHub Copilot과 함께 VS Code를 가로채는 프록시를 설정하고 어떤 데이터가 서버로 전송되는지 살펴보았습니다. 그 결과, 요청에는 작성 중인 문자열보다 훨씬 더 많은 내용이 포함되어 있으며, 열린 .env 파일의 내용이 그대로 전송된다는 사실이 밝혀졌습니다.

좋은 소식은: 이를 확인할 수 있는 방법은 누구에게나 있으며, Copilot에 국한되지 않습니다. 아래는 20-30분 안에 자신의 어시스턴트 트래픽을 감사하는 방법, 가로채진 요청에서 무엇을 찾아야 하는지, 그리고 기본 파일 제외 메커니즘의 제한 사항에 대한 작업 지침입니다.

왜 직접 해야 하는가

벤더의 문서는 정책을 설명할 뿐, 클라이언트의 실제 동작을 설명하지 않습니다. "우리는 귀하의 코드를 학습에 사용하지 않습니다"와 "클라이언트는 귀하의 코드를 서버로 전송하지 않습니다" 사이에는 큰 간극이 있습니다: 모델이 힌트를 생성하려면 컨텍스트를 받아야 하며, 문제는 클라이언트가 이 컨텍스트를 얼마나 넓게 수집하는가입니다.

감사가 필요한 경우는 다음과 같습니다:

NDA를 체결했거나 고객의 개인 데이터를 다루고 있어, 어떤 데이터가 경계를 넘어가는지 알아야 하는 경우;
저장소에 비밀, 스탠드 구성, 내부 주소 및 토큰을 보관하고 있는 경우;
팀의 컴플라이언스를 책임지고 있으며, 설정의 스크린샷이 아닌 실제 요청 로그가 필요한 경우;
어시스턴트가 열지 않은 파일에 대해 갑자기 "알고 있다"고 생각하는 이유를 이해하고 싶은 경우.

Copilot 트래픽에서 발견한 것들

이 분석은 전통적인 mitmproxy를 기반으로 하였습니다: VS Code를 로컬 프록시(포트 8080)로 설정하고 엄격한 인증서 검사를 비활성화했습니다. 주요 발견 사항은 다음과 같습니다:

컨텍스트는 하나의 파일보다 넓습니다. 인라인 보완 시 클라이언트는 최대 20개의 파일, 최근 수정 사항 8개의 요약, 각 변경 사항 주위의 3줄의 컨텍스트, 현재 파일의 전체 텍스트 및 최근 수정된 파일의 차이를 수집합니다.
비밀은 마스킹되지 않습니다. 요청 본문에서 prompt 필드는 TEST_ENV_VAR_SECRET="mysecretenvvar" 형식의 문자열을 포함하고 있었습니다. 즉, 열린 파일의 환경 변수들이 일반 텍스트로 전송되었습니다.
로컬 데이터베이스도 열려 있습니다. session-store.db 파일은 user_message와 assistant_response를 암호화나 편집 없이 저장합니다: 이 파일에는 토큰, 클라우드 제공자의 키 및 예전 채팅에 붙여넣은 연결 문자열의 비밀번호가 포함되어 있습니다.
서비스 호출. 보완 외에도 클라이언트는 /models, /agents/swe/models, /models/session/intent 및 GitHub의 OAuth 엔드포인트를 호출합니다. 이를 통해 어시스턴트가 응답을 생성하기 전에 요청을 어떻게 분류하는지 잘 알 수 있습니다.

별도로 기억해야 할 점은: 클라이언트가 현재 저장소의 URL을 서버로 전송하여 적용 가능한 제외 정책을 받는다는 것입니다. 이 사실 자체는 해롭지 않지만, 작업 트리의 구성도 신호가 됩니다.

단계별: 가로채기 설정하기

mitmproxy를 설치하고 실행하세요. 웹 인터페이스인 mitmweb로 충분합니다. 기본적으로 프록시는 포트 8080에서 수신 대기하며, 콘솔은 브라우저에서 열립니다. CI 및 긴 세션의 경우 mitmdump가 더 편리합니다.
루트 인증서를 설치하세요. mitmproxy를 처음 실행하면 ~/.mitmproxy 디렉토리에 CA를 생성합니다(파일 mitmproxy-ca-cert.cer). 이를 신뢰할 수 있는 인증서에 추가해야 합니다. 그렇지 않으면 클라이언트가 TLS 연결을 끊습니다. 감사 기간 동안 사용자 수준의 신뢰만으로 충분하며, 이후에는 인증서를 삭제하고 "만일의 경우"로 타인의 CA를 시스템에 남기지 마세요.
가로채기 모드를 선택하세요. 세 가지가 있으며, 올바른 선택은 시간을 절약합니다:
- regular — 일반 프록시로, 클라이언트가 명시적으로 설정됩니다. 가장 예측 가능한 옵션입니다.
- local — 이 머신에서 애플리케이션의 투명한 가로채기, 프로그램 설정을 수정하지 않고: mitmproxy --mode local:Code는 VS Code 프로세스만 가로채고, --mode local:42는 지정된 PID의 프로세스를, --mode local:!curl는 curl을 제외한 모든 것을 가로챕니다. 이는 프록시 설정이 없는 어시스턴트를 듣는 가장 좋은 방법입니다.
- upstream — mitmproxy 뒤에 자신의 프록시가 있는 체인: mitmdump --mode upstream:http://host:8081, 로그인과 비밀번호는 --set upstream_auth=user:pass 옵션으로 설정됩니다.
IDE를 프록시로 설정하세요(regular 모드의 경우). VS Code의 settings.json에서:
- "http.proxy": "http://127.0.0.1:8080"
- "http.proxySupport": "override"
- "http.proxyStrictSSL": false — 감사 기간 동안만. 이 플래그는 인증서 검사를 완전히 비활성화하며, 작업 구성에 남겨두어서는 안 됩니다.
성숙하게 인증서 문제를 해결하세요. Copilot 확장은 Node에서 작동하므로, 올바른 방법은 검사를 비활성화하는 것이 아니라 루트 CA와 mitmproxy 인증서를 포함한 PEM을 수집하고 이를 환경 변수 NODE_EXTRA_CA_CERTS를 통해 지정하는 것입니다. IDE를 재시작해야 합니다: 이 변수는 프로세스 시작 시 읽힙니다.
스트림을 파일로 기록하세요. 실시간으로 눈으로 보는 것은 무의미합니다 — 요청이 분당 수십 개 발생합니다. --set save_stream_file=flows.dump를 활성화하고, 모든 것을 수집하지 않도록 --set save_stream_filter=...를 통해 샘플링을 제한하세요. 이후 파일은 오프라인에서 편안하게 분석할 수 있습니다.
URL이 아닌 요청 본문에서 검색하세요. 실용적인 방법: 테스트 저장소에 고유한 문자열이 포함된 카나리아 파일(예: CANARY_9f3c_DO_NOT_SEND)을 추가하고, 편집기에서 열어 이웃 파일에서 작업한 후 — 가로채진 본문에서 카나리아를 검색하세요. 이렇게 하면 클라이언트의 실제 버전에서 컨텍스트 수집의 이론적 범위가 아닌 실제 범위를 확인할 수 있습니다.

주의사항

라이센스가 가로채기를 차단할 수 있습니다. 기업 플랜에서 Copilot은 "현재 Copilot 라이센스는 자가 서명된 인증서로 프록시 연결을 지원하지 않습니다"라는 오류를 반환합니다. 이는 프록시의 버그가 아니라 클라이언트가 의도적으로 자가 서명된 CA를 통해 작동하기를 거부하는 것입니다. 시스템 수준에서 신뢰할 수 있는 인증서로 해결하거나 Node용 PEM을 생성해야 하며, 조직의 정책이 이를 금지하는 경우 감사는 관리자와 조율해야 하며 우회할 수 없습니다.

핀닝 및 QUIC. 일부 클라이언트는 QUIC 위에서 HTTP/3를 사용하며, 일반 프록시는 이를 볼 수 없습니다. 가로채기를 활성화한 후 애플리케이션이 "작동하지만 로그가 비어 있다면" — 거의 항상 그 이유는 이 때문입니다: 테스트 프로세스를 위해 UDP/443을 차단하면 클라이언트는 HTTP/2로 롤백합니다.

텔레메트리와 페이로드는 다른 경로로 간다. 하나의 엔드포인트만으로 "아무것도 전송되지 않는다"는 결론을 내리지 마세요: 프로세스가 접근하는 모든 호스트 목록을 살펴보세요, 문서에 언급된 것만 보지 마세요.

법적 프레임워크. 자신의 머신과 계정에서 트래픽을 가로채는 것은 가능합니다. 다른 사람의 작업 노트북을 소유자의 동의 없이 듣는 것은 전혀 다른 이야기이며, 어떤 "보안"도 이를 정당화하지 않습니다.

결과에 대한 조치

감사 결과 요청에 불필요한 파일이 포함되어 있음을 보여준 경우, 기본 도구는 다음과 같이 보이며, 각 도구는 눈에 띄는 제한이 있습니다.

컨텐츠 제외. GitHub의 공식 메커니즘으로, Copilot이 지정된 경로를 사용하는 것을 금지합니다. Business 및 Enterprise 플랜에서만 사용할 수 있으며, Copilot 설정에서 관리자가 설정합니다. VS Code, Visual Studio 및 JetBrains에서 지원되며, Xcode, Eclipse 및 Vim/Neovim에서는 인라인 힌트에 대해서만 지원됩니다.
주요 구멍 — 에이전트 모드. 문서에서는 Copilot Chat의 Edit 및 Agent 모드, 그리고 Copilot CLI에서 제외가 지원되지 않는다고 명시하고 있습니다. 즉, 어시스턴트가 파일을 탐색하고 구성 파일을 읽고 명령을 실행하는 곳에서는 플랫폼 필터링이 적용되지 않습니다. content exclusion을 유일한 장벽으로 의존한다면 — 에이전트 모드에서는 장벽이 없습니다.
.gitignore는 보호하지 않습니다. 일반적인 오해: Git 인덱스에서 제외된다고 해서 어시스턴트의 컨텍스트에서 제외되는 것은 아닙니다.
조직의 최소 기준. 비밀은 코드 옆의 .env가 아니라 비밀 관리자로 관리해야 하며; 어시스턴트의 채팅은 연결 문자열을 삽입할 장소가 아닙니다; 로컬 기록 데이터베이스는 셸 기록을 정리하는 것처럼 정리해야 합니다.

여기서 프록시는 무엇이며 왜 필요한가

가로채기에는 응용 프로그램적 연장이 있습니다. 첫째, upstream 모드는 어시스턴트의 모든 트래픽을 제어된 출력 노드를 통해 통과시킬 수 있습니다: 요청을 동시에 보고, 어떤 주소에서 전송되는지를 관리할 수 있습니다. 이는 어시스턴트 API가 귀하의 지역에서 접근할 수 없거나 기업 정책이 고정된 출발 IP를 요구할 때 필요합니다 — 이러한 시나리오에는 고정 주소를 가진 안정적인 데이터 센터 프록시가 적합합니다.

둘째, 동일한 스탠드는 자동화 디버깅에 유용합니다: AI 에이전트가 스스로 웹사이트를 탐색할 때, 가로채기는 실제로 어떤 헤더를 전송하고 방어 시스템이 무엇에 의해 감지되는지를 보여줍니다. 우리는 Playwright 및 MCP에서 AI 에이전트를 위한 프록시에 대한 자료에서 이 조합을 다루었습니다 — 에이전트 시나리오에 적합한 주소 유형 선택에 대해 설명하며, 여기서 주거 IP가 필요합니다.

mitmproxy를 이전에 설정하지 않았다면, HTTPS 가로채기의 기본 설정부터 시작하세요 — 이는 우리의 mitmproxy를 통한 트래픽 가로채기 가이드에서 자세히 설명되어 있으며, 그 위에 local 및 upstream 모드를 추가하세요.

결론

AI 어시스턴트의 트래픽 감사는 편집증이 아니라 정상적인 엔지니어링 위생이며, 한 저녁과 한 번의 작업으로 가능합니다. Copilot 분석은 명확한 그림을 보여주었습니다: 클라이언트는 넓은 범위의 컨텍스트를 수집하고, 비밀은 코드와 함께 이 컨텍스트에 포함되며, 로컬 기록은 일반 텍스트로 저장되고, 기본 제외는 가장 위험한 모드인 에이전트 모드에서는 작동하지 않습니다.

문서가 아닌 트래픽을 확인하세요. local 모드에서 mitmproxy를 설정하고, 저장소에 카나리아를 추가하고, 스트림을 파일로 수집하여 귀하의 머신에서 어떤 데이터가 전송되는지 직접 확인하세요. 이후의 결정은 간단합니다: 이 전송량을 의도적으로 수용하거나, 다른 서버가 보지 않도록 비밀을 작업 트리 밖으로 이동시키는 것입니다.