HN이 짚은 Vercel plugin telemetry, Vercel 밖 프로젝트까지 닿는다

무슨 일이 있었나

2026년 4월 9일 Akshay Chugh의 글을 계기로 HN에서 vercel-plugin 공개 codebase를 둘러싼 토론이 형성됐다. 핵심 쟁점은 Vercel이 telemetry를 넣었다는 사실 자체라기보다, deployment helper로 기대되는 범위를 넘어 consent flow와 수집 scope가 더 넓고 덜 명시적하다는 점이었다.

공개 repo는 이 비판의 상당 부분을 뒷받침한다. hooks/user-prompt-submit-telemetry.mjs 에서 plugin은 asked marker를 쓰고, Claude가 telemetry 질문을 AskUserQuestion 으로 묻도록 하는 additionalContext 를 내보낸 뒤, 응답에 따라 shell command로 ~/.claude/vercel-plugin-telemetry-preference 에 enabled 또는 disabled 를 기록하게 한다. hooks/posttooluse-telemetry.mjs 에서는 Bash invocation이 bash:command 로 기록된다. hooks/telemetry.mjs 는 event를 https://telemetry.vercel.com/api/vercel-plugin/v1/events 로 보내고, persistent device ID를 ~/.claude/vercel-plugin-device-id 에 저장한다.

왜 중요하나

핵심은 scope와 attribution 문제다. 사용자에게 보이는 문구는 이 선택이 “prompt telemetry만” 제어한다고 설명한다. 즉 더 기본적인 event stream은 별도 계층이라는 뜻이다. GitHub issue #34도 같은 지점을 지적한다. consent가 plugin 소유 UI가 아니라 model context 안에서 전달되기 때문에, 사용자는 정상 plugin 동작과 instruction injection을 시각적으로 구분하기 어렵다.

• 이 코드는 confirmed breach나 exploit 사례를 보여주는 것은 아니다.
• repo에는 project profiling logic도 있지만, 비판은 telemetry가 Vercel 작업으로만 gating되지 않는다고 본다.
• HN 댓글은 결국 이 문제를 agent tool 전반의 plugin permission 모델로 확장했다.

이 지점 때문에 이야기가 더 넓게 퍼졌다. agent ecosystem이 커질수록 prompt, tool trace, shell command, device-level identifier는 단순 analytics가 아니라 product trust model의 일부가 된다. Vercel plugin은 그 한 사례일 뿐이고, HN이 붙잡은 더 큰 질문은 따로 있다. 누가 agent session을 볼 수 있는가, 어떤 disclosure 기준으로 보는가, 그리고 project boundary는 어디에서 그어지는가라는 문제다.

또 하나 중요한 점은 repo에 이미 project profiling code가 들어 있다는 사실이다. 즉 논란은 plugin이 기술적 문맥을 전혀 모르기 때문이 아니라, 그 문맥을 어디에 쓰는지, 사용자에게 무엇을 보여주는지, 그리고 consent 순간에 plugin의 행동이 얼마나 명확하게 귀속되는지에 관한 문제다. 원문: Akshay Chugh, GitHub issue #34, 공개 vercel-plugin repo, Hacker News.