코딩 에이전트 텔레메트리 데이터 전송 범위 및 차단 방법

코딩 에이전트 텔레메트리가 실제로 다루는 범위

코딩 에이전트 텔레메트리는 하나의 용어로 묶이지만 실제로는 네 가지 별도의 데이터 흐름으로 구성되며, 각 흐름은 개별적으로 제어할 수 있습니다. 모델 추론(Model inference)은 사용자의 프롬프트와 코드를 모델 제공자에게 전송하며, 이를 차단하는 설정은 존재하지 않습니다. 제품 분석 데이터와 충돌 보고서는 공급업체로 전송되며, 종종 공급업체가 비용을 지불하는 로깅 업체로도 전달됩니다. 학습을 위한 데이터 보존은 네트워크 설정의 문제가 아니라 계약상의 문제입니다. 네 번째 흐름은 사용자가 간과하기 쉬운 부분입니다. 사용자가 추가하는 모든 통합 기능은 사용자가 선택하지 않은 호스트로 연결을 생성할 수 있습니다.

현재 공급업체의 기본 설정 목록은 이 주제에서 가장 빠르게 구식 정보가 되는 부분입니다. 릴리스 한 번으로 기본값이 바뀔 수 있고, 새로운 기능이 추가되면 기존 스위치로는 제어할 수 없는 목적지가 생길 수 있습니다. 따라서 가장 유용한 기술은 어떤 에이전트에도 적용할 수 있는 반복 가능한 감사 절차를 익히는 것입니다. 공급업체의 문서를 읽고, 현재 시스템에 실제로 적용된 설정을 확인하고, 시스템 자체에서 프로세스를 모니터링한 다음, 감수할 수 있는 제어 수준을 선택하십시오. 아래의 모든 명령어는 사용자의 시스템에서 직접 실행하여 자신의 트래픽을 확인하는 용도입니다.

네 가지 범주와 각기 다른 제어가 필요한 이유

모델 추론 트래픽은 피할 수 없습니다. 에이전트는 사용자의 프롬프트, 읽어 들인 파일, 실행한 명령어의 출력 결과, 그리고 모델이 생성한 텍스트를 모델 엔드포인트로 전송합니다. 이는 제품이 작동하는 방식 그 자체입니다. 유일한 결정 사항은 이를 누가 수신하느냐입니다. 타인이 운영하는 API를 이용할지, 아니면 직접 모델을 실행할지 선택해야 합니다. 기업용 클라우드 계정(Bedrock, Vertex, Foundry)을 사용하면 수신자는 바뀌지만, 데이터 흐름 자체가 사라지는 것은 아닙니다. 이 글의 나머지 부분에서 다루는 내용은 추론 트래픽을 줄이는 것과는 무관하므로, 다른 세 가지 범주와는 별개로 생각해야 합니다.

제품 분석 및 충돌 보고는 다른 호스트로 향하는 별도의 흐름입니다. 사용량 카운터, 지연 시간 수치, 기능 플래그 조회, 스택 트레이스는 일반적으로 모델 API와는 전혀 관계없는 호스트명으로 전송되며, 종종 제3자 오류 추적 서비스로 전달됩니다. 공급업체는 이를 보통 "메트릭" 및 "오류 보고"로 문서화하며, 범주별로 하나의 환경 변수를 제공하는 경우가 많습니다. 데이터 양이 매우 적기 때문에 바이트 수만으로는 이를 찾아낼 수 없습니다. 대역폭이 아니라 호스트명을 추적해야 합니다.

보존 및 학습은 패킷이 아닌 정책의 문제입니다. 공급업체가 사용자의 프롬프트를 보관하는지, 얼마나 오래 보관하는지, 그리고 향후 모델 학습에 사용하는지 여부는 플랜에 첨부된 약관에 명시되어 있습니다. 소비자용 플랜과 기업용 플랜은 보통 차이가 있으며, 데이터 보존을 하지 않는 계약은 일반적으로 별도의 합의가 필요합니다. 패킷의 형태는 어느 쪽이든 동일하게 보이기 때문에 tcpdump로는 이를 확인할 수 없습니다. 약관을 읽어보고, 고용주에게 중요한 사안이라면 서면으로 확답을 받아야 합니다.

통합 기능은 조용히 경유지를 추가합니다. MCP(Model Context Protocol) 서버, 플러그인 마켓플레이스, 자동 업데이트 확인, 웹 검색 도구, URL을 가져오기 전에 해결하는 보안 검사 등 각각은 모델 엔드포인트가 아닌 다른 호스트로 향하는 요청입니다. 예상치 못한 동작은 바로 여기서 발생합니다. 로컬에서 처리된다고 생각했던 작업이 하네스를 통해 자체 서비스로 라우팅될 수 있으며, 설정 파일을 한 줄도 수정하지 않아도 업데이트를 통해 이러한 동작이 시작될 수 있습니다. 네트워크상에서 직접 확인하기 전까지는, 추가하는 모든 도구를 새로운 목적지로 간주하십시오.

1단계: 벤더 문서 확인하기

에이전트의 설정 참조 문서와 데이터 사용 페이지를 열고 다음 단어들을 확인하며 읽어 보십시오: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. 이 단어들은 대개 각각 별도의 스위치로 존재합니다. 2단계에서 grep 명령어로 검색해야 하므로 정확한 변수 이름을 기록해 두십시오.

주의해야 할 단어가 하나 있습니다. 여러 에이전트 문서에서 "telemetry"는 사용자가 직접 운영하는 수집기로 메트릭을 전송하도록 설정하는 OpenTelemetry 내보내기를 의미하며, 이는 벤더로 데이터가 전송되는 것과는 정반대의 개념입니다. Claude Code가 이러한 경우에 해당합니다. CLAUDE_CODE_ENABLE_TELEMETRY=1를 설정하면 OTEL_EXPORTER_OTLP_ENDPOINT에 지정한 엔드포인트로 데이터 내보내기가 시작되는데, 이는 별도의 옵트아웃 설정이 필요한 벤더 자체 분석 기능과는 무관합니다. 설정을 변경하기 전에 데이터가 어느 방향으로 흐르는지 파악하십시오.

마스터 스위치가 존재할 것이며, 그 스위치에 허점이 있을 수 있음을 예상해야 합니다. 2026년 8월 기준으로 Claude Code의 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC는 메트릭, 오류 보고, 피드백 명령, 세션 설문을 한꺼번에 비활성화합니다. 하지만 동일한 문서에 따르면 이 설정은 WebFetch 도메인 안전성 검사에는 적용되지 않으며, 이는 가져오려는 호스트 이름을 벤더 API로 전송하므로 별도의 설정이 필요합니다. 이는 특정 제품에 대한 불만이 아닙니다. 모든 곳에서 나타나는 공통적인 문제입니다. 마스터 스위치는 해당 기능이 처음 작성되었을 당시 존재하던 범주만 다루기 때문입니다.

옵트아웃 설정으로 인해 기능이 제한될 수 있음을 감안해야 합니다. 동일한 문서에는 원격 측정을 비활성화하면 일부 기능이 의존하는 기능 플래그 평가도 함께 비활성화된다고 명시되어 있습니다. 따라서 개인정보 보호를 위해 스위치를 끄면 사용 중인 기능이 작동하지 않을 수 있으며, 이 둘 사이의 연관성을 알려주는 오류 메시지도 표시되지 않습니다. 플래그 이름만 보지 말고 플래그 옆에 적힌 문장까지 읽어 보십시오.

2단계: 실제로 적용된 설정 확인하기

작성한 설정이 실제로 적용되지 않을 수 있습니다. 에이전트는 여러 파일의 설정을 병합하며, 그중 하나는 방금 다른 사람의 저장소에서 복제한 파일일 수 있습니다. 우선 본인의 셸 환경부터 확인하십시오.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

그다음 문서에 명시된 순서대로 도구가 읽어 들이는 모든 설정 파일을 출력하십시오. 2026년 8월 기준, Claude Code는 사용자 파일, 두 개의 프로젝트 파일, 그리고 Linux의 관리형 정책 디렉터리를 읽습니다.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

git clone와 함께 전달된 프로젝트 파일은 타인이 작성한 설정이며, 사용자의 파일에서 비활성화한 기능을 다시 켤 수 있습니다. 에이전트에 로드된 소스를 나열하는 상태 명령어가 있다면 그것이 가장 확실한 진실입니다. Claude Code는 /status에서 로드된 설정 소스를 출력합니다.

가장 확실한 확인 방법은 파일이 아닌 실행 중인 프로세스를 직접 읽는 것입니다. 먼저 에이전트에 전용 Linux 사용자 계정을 부여하십시오. 이렇게 하면 이 게시물의 모든 명령어가 짧아지며, 프로세스가 시작될 때 사용된 환경 변수를 읽을 수 있습니다.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ은 프로세스가 실행될 당시의 변수를 보여줍니다. 따라서 .bashrc export 명령이 systemd로 시작된 서비스에 전달되지 않은 경우를 찾아낼 수 있습니다. 설정한 변수가 여기에 없다면, dotfile의 내용과 관계없이 해당 변수는 적용된 적이 없는 것입니다.

3단계: 어떤 호스트에 연결하는가?

에이전트가 실행되는 계정으로 필터링하여 열린 소켓부터 확인합니다.

sudo ss -tnpe state established

-e는 각 행에 uid: 필드를 추가하므로, 프로세스 이름을 일일이 읽지 않고도 에이전트의 연결과 브라우저의 연결을 구분할 수 있습니다. 원격 주소를 기록한 뒤 그 뒤에 숨겨진 이름을 확인하십시오. 이름을 확인하는 가장 깔끔한 방법은 TLS(transport layer security) 핸드셰이크를 이용하는 것입니다. 모든 새로운 연결은 클라이언트가 요청한 호스트 이름인 SNI(server name indication) 필드가 포함된 ClientHello로 시작하기 때문입니다.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

새로운 연결마다 한 줄씩 결과가 출력되며, 이는 모델 API, 업데이트 서버, 분석 호스트, 오류 추적기, 그리고 통합 기능이 추가한 모든 항목을 포함하는 정확한 목록이 됩니다. 이름 열이 비어 있다면 해당 클라이언트가 ECH(encrypted client hello)를 사용한 것이므로 네트워크상에서 호스트 이름을 볼 수 없습니다. 이 경우 대상 IP 주소, 역방향 조회 또는 4단계의 프록시를 통해 확인해야 합니다.

DNS(domain name system) 보기는 유용한 교차 검증 수단입니다. 연결을 완료하지 않은 경우라도 에이전트가 조회한 이름을 보여주기 때문입니다.

sudo tcpdump -ni any -l 'udp port 53'

각 쿼리 행은 A? host.example.net. (39) 형식으로 레코드 유형과 이름으로 끝납니다. 외부 인터페이스가 아닌 any에서 캡처하십시오. systemd-resolved을 사용하면 애플리케이션은 127.0.0.53의 로컬 스텁 리스너와 통신하고 스텁만이 외부와 통신하기 때문입니다. 에이전트가 정상 작동 중임에도 DNS 트래픽이 전혀 보이지 않는다면, 해당 런타임이 자체적으로 DNS over HTTPS를 수행하는 것이며 4단계를 통해서만 이름을 확인할 수 있습니다.

에이전트가 실제 작업을 수행하는 동안 캡처하십시오. 세션을 시작하고, 파일을 읽게 하고, 명령을 실행하고, 무언가 실패하게 만드십시오. 시작 시 한 번 발생하거나 예외가 발생할 때만 나타나는 트래픽은 유휴 상태 캡처에서는 절대 나타나지 않습니다. 유휴 상태 캡처는 감사가 잘못된 결론에 도달하게 만드는 가장 흔한 원인입니다.

단계 4: 요청 내부에는 무엇이 있는가?

호스트 이름은 대상을 알려줍니다. 무엇이 포함되어 있는지 확인하려면, 제어 가능한 프록시를 에이전트 앞에 배치하고 해당 런타임에 대해서만 프록시의 인증 기관(CA)을 신뢰하도록 설정하십시오. mitmproxy가 주로 사용되는 도구입니다. 프로젝트에서는 mitmproxy.org에서 제공하는 독립형 바이너리를 권장하며, Python 패키지 경로로 uv tool install mitmproxy를 문서화하고 있습니다.

mitmdump -w /tmp/agent-flows.mitm

첫 실행 시 CA가 ~/.mitmproxy/에 기록되며, mitmproxy-ca-cert.pem은 인증서 자체를 의미합니다. 에이전트를 실행할 셸에서 클라이언트가 해당 프록시와 인증서를 가리키도록 설정하십시오.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

많은 에이전트 CLI는 Node 프로그램이며, Node는 프로세스 시작 시 NODE_EXTRA_CA_CERTS을 읽습니다. 따라서 에이전트를 실행하기 전에 환경 변수를 export 하십시오. 다른 터미널에서 실행하면 적용되지 않습니다. Python 클라이언트는 REQUESTS_CA_BUNDLE 또는 SSL_CERT_FILE을 읽으며, Linux에서 표준 라이브러리를 사용하는 Go 바이너리는 SSL_CERT_FILE을 읽습니다. 에이전트를 탓하기 전에 curl를 사용하여 경로가 정상적으로 작동하는지 확인하십시오.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

프록시가 정상 작동하면 200이 출력되며, mitmdump 결과에 요청이 나타납니다. 신뢰할 수 없는 CA를 사용하면 curl: (60) SSL certificate problem: self-signed certificate in certificate chain가 발생하며, Node 에이전트의 경우 SELF_SIGNED_CERT_IN_CHAIN 코드가 포함된 오류가 발생합니다. 이후 콘솔 뷰어로 저장된 흐름(flow)을 읽어보십시오. 요청 하나를 열어 헤더와 본문을 확인할 수 있습니다.

mitmproxy -r /tmp/agent-flows.mitm

네 가지 결과를 주목할 필요가 있습니다. 첫째, 요청이 보인다면 내용을 읽고 판단하십시오. 둘째, 인증서 오류로 에이전트가 시작되지 않는다면 이는 해당 런타임의 신뢰 문제이며 벤더에 대한 발견 사항이 아닙니다. 셋째, 모델 API만 보인다면 다른 카테고리가 꺼져 있거나, 트리거하지 않은 이벤트에서 발생한 것입니다. 넷째, 에이전트는 정상 작동하는데 아무것도 보이지 않는다면, 클라이언트가 프록시 환경 변수를 무시하거나 인증서를 고정(pinning)한 것입니다. 이 경우 애플리케이션 설정은 신뢰할 수 없습니다. 마지막 결과가 가장 중요하며, 패킷 캡처는 연결을 숨길 수 없으므로 다시 3단계로 돌아가야 합니다.

제어 방식: 약한 것부터 강한 것 순으로

옵트아웃 설정. 가장 저렴하지만 가장 약한 방식입니다. 벤더가 이를 준수해야 하며, 이미 존재하는 범주를 다루는 방식이기 때문입니다. 재부팅이나 새 터미널 세션에서도 유지되도록 사용자 설정 파일이나 셸 프로필에 적용하십시오. 설정하는 김에 DO_NOT_TRACK=1도 추가하십시오. 이는 일부 에이전트를 포함한 많은 명령줄 도구가 따르는 관례이며, 추가 비용이 들지 않습니다. 업데이트 직후에는 적용 범위가 변경될 수 있으므로 3단계를 다시 실행하십시오.

송신(Egress) 제한. 요청하는 단계를 넘어 강제하는 단계입니다. 에이전트를 별도의 전용 사용자로 실행한 뒤, 해당 사용자에게는 루프백과 DNS만 허용하고 나머지는 모두 차단하십시오. 이 방식은 자체 테이블을 추가하므로 기존 방화벽 규칙에 영향을 주지 않습니다.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

sudo nft -f /etc/nftables.d/agent.nft으로 규칙을 적용하고, sudo nft list table inet agentegress으로 카운터를 확인하며, sudo journalctl -k -g agent-egress-drop로 차단된 내역을 읽으십시오. 예상치 못한 호스트 이름으로 차단 카운터가 올라가는 것이 이 작업의 핵심입니다. 두 가지 정직한 한계가 있습니다. meta skuid은 소켓을 소유한 사용자와 일치하므로, 해당 계정이 다른 사용자로 전환될 수 없을 때만 유효합니다. 에이전트에 대해 비밀번호 없는 sudo을 설정하면 이 규칙은 제안 수준으로 전락합니다. 또한 UDP 53 포트를 모든 서버에 열어두면 쿼리 이름에 데이터를 실어 보낼 수 있는 통로가 되므로, 위협 모델상 필요하다면 이 역시 차단하고 에이전트의 리졸버를 직접 운영하는 호스트로 지정하십시오. 호스트 이름 허용 목록은 nftables보다는 프록시에서 관리해야 합니다. API 엔드포인트는 IP 주소가 수시로 바뀌는 콘텐츠 전송 네트워크(CDN) 뒤에 있기 때문입니다. 이 제어 방식의 비용은 서비스 중단과 유지보수입니다. 패키지 설치, SSH를 통한 git, 에이전트 자체 업데이트 확인 등이 모두 허용 목록에 추가될 때까지 실패하며, 이제 그 목록을 직접 관리해야 합니다. 노트북이 아닌 서버에 이 설정을 구축한다면, 동일한 계정과 방화벽 구성이 VPS에서 안전하게 Claude Code 실행하기의 기반이 됩니다.

일회용 머신. 에이전트에게 중요한 자격 증명이 없고 작업이 끝나면 파괴되는 가상 머신(VM)을 제공하십시오. 이는 에이전트가 전송하는 내용을 줄이는 것이 아니라, 에이전트가 전송할 수 있는 접근 범위를 줄이는 것이며, 보통 이것이 실제로 신경 써야 할 위험입니다. 위에서 언급한 송신 규칙과 결합하십시오. 인터넷 접근이 제한되지 않은 새 VM은 여전히 캡처 범위 내의 모든 호스트에 도달할 수 있기 때문입니다. 이 방법과 매번 재구축해야 하는 상태에 대해서는 일회용 VM에서 코딩 에이전트 실행하기에서, 규모 산정 문제는 VPS에서 코딩 에이전트 실행하기에서 다룹니다.

모델 자체 호스팅. 추론 흐름을 제거하는 유일한 제어 방식입니다. 프롬프트가 하드웨어를 벗어나지 않기 때문입니다. 비용은 현실적입니다. 폐쇄형 모델은 자체 호스팅할 수 없으므로, 오픈 웨이트 모델을 선택하고 어려운 작업에서 성능 격차를 감수해야 하며, 이를 구동할 하드웨어도 필요합니다. 이 절충안은 Claude를 자체 호스팅할 수 있는지 여부에서, 주요 에이전트 간의 성능 차이는 Claude Code, Cursor, Codex, Copilot의 차이점에서 다룹니다.

이 네 가지 제어 방식 중 어느 것도 에이전트가 디스크에서 읽을 수 있는 권한을 변경하지 않으며, 추론 트래픽은 에이전트가 읽은 모든 내용을 담고 있습니다. 작업 디렉터리에 .env 파일이 있다면, 에이전트가 변수 이름을 검색(grep)하는 순간 해당 파일의 내용은 모델로 전송됩니다. 이러한 자료가 노출되지 않도록 하는 것은 별도의 작업이며, AI 에이전트의 컨텍스트에서 비밀 정보 제외하기에서 다룹니다.

업데이트 후 확인해야 할 사항

1. 공급업체의 설정 및 데이터 사용량 페이지를 지난번에 기록한 내용과 비교하여 새로운 스위치나 명명된 서비스가 추가되었는지 확인합니다.
2. /proc/<pid>/environ에서 프로세스 환경을 다시 읽어, 설정에서 제외한 항목이 실행 중인 프로세스에 여전히 적용되고 있는지 확인합니다.
3. 프로젝트 설정 파일을 다시 출력합니다. git pull를 통해 동료가 변경한 설정 파일이 포함될 수 있기 때문입니다.
4. 실제 작업 한 세션 전체에 대해 SNI 캡처를 실행하고, 호스트 이름 목록을 이전 목록과 비교합니다.
5. 방화벽 드롭 카운터를 확인합니다. 새로운 대상은 보통 다른 곳에서 눈치채기 전에 이곳에 먼저 나타나기 때문입니다.

이 과정은 약 10분 정도 소요되며, 전체 프로세스 중 유일하게 시간이 지나도 가치가 변하지 않는 부분입니다. 2026년 8월에 검증한 기본값은 2026년 8월에 대한 사실일 뿐입니다. 하지만 캡처 데이터는 오늘에 대한 사실입니다.

FAQ

코딩 에이전트가 코드를 모델로 전송하지 못하게 막을 수 있습니까?

아니요, 그렇게 할 수 있다고 주장하는 설정은 실제로는 다른 기능을 의미합니다. 프롬프트, 에이전트가 읽은 파일, 에이전트가 실행한 명령어의 출력 결과를 모델 엔드포인트로 전송하는 것은 추론 과정의 핵심입니다. 따라서 유일한 변수는 데이터를 수신하는 주체가 누구인가 하는 점입니다. 에이전트가 가리키는 대상을 회사 클라우드 계정이나 직접 호스팅하는 모델로 변경하여 수신자를 바꿀 수 있으며, 에이전트가 읽을 수 있는 범위를 제한하여 전송량을 줄일 수는 있습니다. 분석 및 오류 보고 기능을 끄는 것은 이 데이터 흐름에 전혀 영향을 주지 않습니다.

코딩 에이전트가 어떤 호스트에 연결하는지 확인하려면 어떻게 해야 합니까?

에이전트를 별도의 Linux 사용자로 실행한 다음, 에이전트를 사용하는 동안 모든 새 연결의 TLS ClientHello를 캡처하십시오: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. 연결당 한 줄씩 대상 주소와 요청된 호스트 이름이 표시됩니다. 127.0.0.53의 로컬 리졸버 스텁이 쿼리를 먼저 처리하므로, any에서 캡처하여 sudo tcpdump -ni any 'udp port 53'로 이름을 교차 검증하십시오. 시작 시 발생하는 핑이나 충돌 보고서는 유휴 상태 캡처에서는 나타나지 않으므로, 에이전트가 실제 작업을 수행하는 동안 캡처를 진행해야 합니다.

에이전트가 작동 중인데 프록시에 트래픽이 나타나지 않습니다. 무엇이 문제입니까?

클라이언트가 HTTP_PROXY 및 HTTPS_PROXY을 무시하거나, 인증서를 고정(pinning)하여 사용자의 CA를 거부하는 경우입니다. 먼저 curl로 경로를 테스트하십시오. 만약 curl이 프록시를 통해 인터넷에 연결되는데 에이전트가 흐름 목록에 나타나지 않는다면, 에이전트가 프록시 환경 변수를 사용하지 않는 것입니다. 일부 런타임은 CA를 특정 방식으로 제공해야 하며, 특히 Node는 프로세스 시작 시에만 NODE_EXTRA_CA_CERTS를 읽으므로 에이전트를 실행한 후에 환경 변수를 export해도 아무런 효과가 없습니다. 프록시가 트래픽을 볼 수 없을 때는 패킷 캡처를 사용하십시오. 이는 어떤 애플리케이션 설정으로도 우회할 수 없습니다.

텔레메트리를 끄면 내 코드가 학습에 사용되는 것을 막을 수 있습니까?

아니요. 분석 및 충돌 보고는 추론과는 다른 흐름입니다. 따라서 이를 비활성화하면 사용량 카운터와 스택 트레이스만 제거될 뿐, 모든 프롬프트는 이전과 동일하게 모델로 전송됩니다. 해당 프롬프트가 보관되는지, 그리고 향후 모델 학습에 사용되는지는 사용 중인 플랜의 약관에 따라 결정되며, 일반적으로 개인용 플랜과 상업용 플랜은 다릅니다. 이는 패킷 캡처로 확인할 수 있는 내용이 아니라 계약서의 영역이므로, 플랜의 데이터 사용 정책 페이지를 확인하십시오. 중요한 경우 첫 세션을 시작하기 전에 상업용 계약이나 데이터 보관 금지(zero-retention) 계약을 체결하십시오.