가장 편리한 에이전트 버튼은 당신의 리포지토리(repository)와 팀 메시지에 대해 가장 광범위한 접근 권한을 가질 수 있습니다. 당신은 5분 만에 연결을 추가하고, 에이전트는 즉시 코드를 읽고 커밋(commit)을 작성합니다. 하지만 그와 동시에, 당신이 누구에게도 명시적으로 부여하지 않았던 파일, 셸(shell), 네트워크에 대한 권한이 스택(stack)에 함께 들어오게 됩니다.

이 글은 키를 안전하게 보관하는 방법에 관한 것이 아닙니다. 에이전트의 리스크는 모델 자체에 있는 것이 아니라, 모델 주변 도구들의 권한에 존재한다는 것에 관한 것입니다. IDE, 워크플로우 엔진(workflow engine), Telegram 브리지 및 외부 중개자를 연결하는 테크 리드(tech lead)의 경우, 접근 권한 세트는 스스로 인지하기도 전에 빠르게 축적됩니다. 아래에서는 이를 매트릭스로 분류하고 안전한 연결을 위한 우선순위를 정하는 방법을 설명합니다. 미리 말씀드리자면, 이 매트릭스는 제가 작업하며 만든 구조일 뿐이며 벤더(vendor)에서 발행한 문서가 아닙니다. DeepSeek, n8n, Cline, Telegram 그 어디도 복합적인 에이전트 스택에 대한 완성된 "위협 모델(threat model)"을 공개하지 않습니다.

왜 버튼은 편리하고 접근 권한은 광범위한가?

놓치기 쉬운 메커니즘부터 시작하겠습니다. DeepSeek의 Function Calling(함수 호출) 문서에는 모델 자체가 함수를 실행하지 않는다고 명시되어 있습니다. 모델은 호출을 제안할 뿐이며, 도구의 실제 코드—파일 읽기, 명령 실행, 네트워크 요청 등—는 당신이 통합한 애플리케이션, 즉 IDE, 워크플로우 엔진, 봇이 실행합니다. 즉, 파일 시스템, 터미널 및 네트워크에 대한 모든 실제 권한은 DeepSeek가 아니라 통합 애플리케이션에 있습니다.

여기서 리스크를 평가하는 사람에게 불쾌한 결론이 도출됩니다. 당신이 "DeepSeek 에이전트"를 작업 환경에 연결할 때, 당신은 언어 모델(LLM)의 보안을 평가하는 것이 아닙니다. 당신은 특정 래퍼(wrapper)가 어떤 권한을 갖게 되는지, 그리고 그 권한을 얼마나 좁게 제한할 수 있는지를 평가하는 것입니다. 모델은 무엇이든 될 수 있지만, 공격 표면(attack surface)을 결정하는 것은 그 주변의 애플리케이션입니다.

DeepSeek의 공식 코드 에이전트 가이드도 이를 간접적으로 확인해 줍니다. 이 가이드는 Claude Code, OpenCode, OpenClaw라는 정확히 세 가지 경로를 설명하며, 각 경로는 설치 단계 외에 눈에 띄는 보안 권장 사항 없이 DeepSeek Platform의 로우 키(raw key)를 환경 변수(environment variable)나 설정 마스터에 삽입할 것을 요구합니다. 즉, 기본 설정인 "편리한 버튼"은 라이브 API 키를 제3자 에이전트 런타임(runtime)에 전달하는 것을 의미합니다. 이 경로를 부르는 명칭은 제각각입니다: 어떤 이들은 deepseek code agent, deepseek coding agent라고 부르고, 어떤 이들은 deepseek api claude code, 또 다른 이들은 openclaw deepseek api라고 부릅니다. hermes agent deepseek라는 명칭도 발견되는데, 이 경우 공식 가이드가 전혀 제공되지 않으며, 이는 이미 하나의 신호입니다: 만약 벤더(vendor)가 연결 경로를 설명하지 않았다면, 위협 모델(threat model)은 전적으로 스스로 구축해야 한다는 것입니다.

Схема потока вызова инструмента: модель предлагает, приложение исполняет

"연결-액세스-리스크-제어" 매트릭스는 어떻게 구성되는가?

다음으로 저는 실무적인 도구로서, 각 통합(integration)을 연결(связка), 액세스(доступ), 리스크(риск), 그리고 해당 리스크를 제한하는 제어(контроль)라는 네 가지 열로 설명하는 매트릭스를 제안합니다. 각 열의 권한 메커니즘은 문서(documentation)에서 가져왔습니다. 우선순위 연결 순서에 대한 결론은 저의 의견이며, 실무에서 검증된 것은 아닙니다.

이 매트릭스는 한 가지 사실을 확실히 기록합니다: 모든 연결에는 구체적인 액세스가 있고, 구체적인 리스크가 있으며, 그 액세스를 제한하는 구체적인 제어가 존재한다는 점입니다. 안전한 활성화 순서는 이보다 덜 확신을 가지고 제시합니다. 또한, 당신이 이를 활성화하는 시점에 특정 버전의 통합, 미들웨어(middleware) 또는 애플리케이션이 가진 실제 권한과 동작은 매트릭스가 전혀 알 수 없는 영역입니다. 따라서 "제어" 열은 보증이 아니라, 당신이 반드시 수동으로 권한을 확인해야 하는 지점입니다.

테크 리드(tech lead)의 스택에 구성되는 네 가지 전형적인 연결 사례를 가져와 문서화된 메커니즘에 따라 분석해 보겠습니다.

처음 세 줄은 문서화된 내용에 근거합니다. Cline의 경우, 키는 "더 이상 볼 수 없는" 값으로 입력되며, 제공자 페이지 자체에는 파일이나 터미널 권한에 대한 지침이 포함되어 있지 않습니다. 대신 별도의 공통 시스템인 Auto Approve가 이를 관리합니다. n8n의 경우, DeepSeek 자격 증명(credentials) 설명에는 스코프(scopes) 없이 API 키만 요구되며, n8n이 이 계정을 어떻게 저장하는지 또는 키가 워크플로우(workflow) 내에서 어떤 권한을 부여하는지에 대해서는 명시되어 있지 않습니다. 따라서 최소 권한 원칙(principle of least privilege)을 준수해야 하는 모든 부담은 사용자의 키 관리 관행에 달려 있습니다. Telegram의 경우, Bot API 문서에 따르면 토큰은 "누구나 사용할 수 있음"이라고 명시되어 있으며, 그룹 내 관리자 봇은 프라이버시 모드(Privacy Mode)를 우회하여 모든 메시지에 대한 무제한 접근 권한을 갖게 됩니다.

Матрица связка-доступ-риск-контроль по четырём интеграциям

표의 행들이 공유하는 점에 주목하십시오. 살아있는 비밀(live secret), 즉 플랫폼 키(platform key)나 봇 토큰(bot token)은 물리적으로 각 통합(integration) 내부에 존재합니다. 확장 프로그램 설정, 워크플로우(workflow) 계정, 봇 설정(config) 등에 말이죠. 이미 여러 곳에 존재하고 서로 다른 사람들에 의해 생성되었기 때문에, 단 한 번의 동작으로 이를 취소(revoke)하는 것은 불가능합니다. 여기서 도움이 되는 것이 키를 중앙 집중식으로 발급하고 취소할 수 있는 계층입니다. provod.ai (OpenRouter의 러시아 대안)의 경우, 액세스 관리, 비용 제어 및 조직의 공통 잔액을 관리하는 워크스페이스(workspace)를 사용합니다. 이렇게 하면 플랫폼의 원시 키(raw key) 대신 워크스페이스 키가 결합됩니다. 반드시 짚고 넘어가야 할 점은, 키의 분산은 줄어들지만 권한이 축소되는 것은 아니라는 점입니다. 모든 파일에 쓸 수 있고 어떤 명령이든 실행할 수 있는 키는, 누가 발급하든 여전히 광범위한 권한(broad access)을 유지합니다.

어떻게 에이전트를 IDE에 연결하면서 디스크 전체를 노출하지 않을 수 있을까?

IDE는 가장 먼저 손이 가는 결합 방식입니다. 사람들은 모두 거의 동일한 방식으로 과제를 정의합니다. vscode에 deepseek을 연결하는 방법이라고 하거나, vs code에 deepseek을 연결하는 방법, deepseek ide 또는 deepseek 플러그인이라고 작성합니다. 기계적으로는 프로바이더(provider) 확장 프로그램을 설치하고 키를 입력하는 과정입니다. 리스크는 키를 입력한 직후부터 시작됩니다.

Cline에서 이 점이 명확하게 드러납니다. DeepSeek 프로바이더 설정 페이지는 키를 붙여넣으라고 요청하며

이는 순서를 명확히 제시합니다. 어떤 IDE 에이전트든 첫 번째 단계는 프로젝트를 '읽기 전용'으로 사용하는 것입니다. 프로젝트 파일 수정은 해당 연결이 예측 가능한 방식으로 동작하는지 확인한 후 다음 단계로 진행하십시오. 명령 실행 및 '모든 파일' 접근은 가장 마지막 단계에서 의식적으로 수행해야 합니다. 팀 공용 머신에서의 YOLO Mode 사용은 '방해되지 않도록' 설정하는 체크박스 수준이 아니라, 명확한 책임자와 명확한 사유가 있어야 하는 결정입니다.

데이터는 어디로 가며, 어디서 문제가 발생했는가?

파일 권한은 전체 그림의 절반에 불과합니다. 나머지 절반은 요청(request)의 내용이 어디로 가느냐 하는 문제입니다. DeepSeek의 개인정보 보호정책(Privacy Policy)은 서비스가 텍스트, 음성, 프롬프트(prompts), 업로드된 파일, 사진, 채팅 기록 등 전체 입력 데이터를 수집하며, 개인 데이터를 중화인민공화국(PRC) 내 서버에 저장한다고 명시하고 있습니다. 또한 데이터는 저장, 보안 및 모델 학습을 위해 '기업 그룹 구조(corporate group structures)'로 전송되며, 법적 요청에 따라 법 집행 기관에 공개될 수 있습니다.

서비스는 정상적으로 작동하며 많은 이들이 사용하고 있습니다. 이는 "DeepSeek을 연결하지 마라"는 논거가 될 수 없습니다. 논거는 달라야 합니다. 데이터 경로(data route) 또한 권한의 문제이며, IDE 설정만으로는 이를 제한할 수 없습니다. 만약 모델로 연결되는 과정에서 고객의 코드나 대화 내용이 전송된다면, 이는 쉘(shell) 권한을 부여한 것만큼이나 실질적으로 해당 데이터에 대한 접근 권한을 외부 측에 넘겨준 것과 같습니다.

이 위험이 가설이 아님은 기록된 사례가 증명합니다. 2025년 1월~2월 사이, Wiz의 독립 보안 연구원들은 공개적으로 접근 가능한 인증되지 않은 DeepSeek의 ClickHouse 데이터베이스를 발견했습니다. 여기에는 채팅 기록, API 키, 서비스 운영 메타데이터를 포함하여 100만 개 이상의 로그 행이 평문(plain text) 형태로 들어 있었습니다. 중요한 경계선은 이것이 DeepSeek 자체 인프라에서 발생한 사고였으며 Wiz의 데이터에 따르면 이미 해결되었다는 점이지, 특정 IDE, n8n 또는 Telegram과의 서드파티 통합 보안에 대한 증거는 아니라는 점입니다. 하지만 하나의 사실로서 이는 시사하는 바가 큽니다. DeepSeek과 관련된 데이터 저장소는 키(key) 및 내용과 함께 유출될 가능성이 있다는 것입니다.

조직들은 이미 이를 자신들의 위협 모델 (threat models)에 반영하고 있습니다. 2025년, 앱 스토어 차단을 시작한 이탈리아 규제 기관, 대만, 대한민국, 체코, 그리고 미국의 NASA, 미 해군(US Navy), 미국 하원을 포함한 여러 국가와 기관들은 불투명한 데이터 처리 및 중국(PRC)에서의 데이터 접근 위험을 직접적으로 언급하며 업무용 기기 및 네트워크에서 DeepSeek 사용을 제한하거나 금지했습니다. 이러한 금지 조치의 근거는 정치적 및 관할권 측면에서 논쟁의 여지가 있으며 변화하고 있습니다. 이를 특정 통합 방식에 대한 판결로 해석하기보다는, 실제 조직들이 중국으로의 데이터 유출 위험을 바탕으로 행동하고 있다는 증거로 해석해야 합니다.

Крупный показатель утечки: более миллиона строк логов в открытом доступе

이 섹션의 결론은 불편합니다. 데이터 경로 (data route)는 통합 설정만으로는 고칠 수 없는 매트릭스의 유일한 열입니다. 특정 리포지토리(repository)에 대해 중국으로 향하는 경로가 허용되지 않는다면, 이는 Cline의 체크박스를 조절하는 것이 아니라 모델을 교체함으로써 해결해야 합니다. 바로 이 지점에서 각 연결의 base_url이 무엇을 가리키는지에 대한 중요성이 나타납니다. 네 가지 통합 방식이 모두 하나의 OpenAI 호환 엔드포인트(endpoint) — 예를 들어 provod.ai — 로 접속한다면, 그 아래의 모델을 변경하는 것은 확장 프로그램, 워크플로우 (workflow), 봇을 각각 다시 구축하는 것이 아니라 키(key)와 base_url을 수정하는 것만으로 충분합니다. 이것이 모델 자체를 "안전"하게 만들거나 통합 권한을 축소하는 것은 아닙니다. 하지만 민감한 회로(sensitive contour)를 다른 모델로 옮기는 작업이 네 가지 통합 방식 전체를 건드려야 하는 프로젝트가 아니게 됩니다.

프록시와 중개자: 왜 여기서 "무료"가 가장 비싼 대가를 치르는가

매트릭스의 별도 항목은 외부 중개자입니다. 플랫폼에 직접 접근하는 것이 불편할 때, 팀은 우회로를 찾으며, 그 우회로들은 익숙한 방식으로 설명되곤 합니다. 대략 다음과 같이 묘사됩니다:

• deepseek proxy 및 러시아어 표기인 deepseek прокси;
• прокси для дипсика 및 "как подключить прокси дипсик"(DeepSeek 프록시 연결 방법) 지침;
• deepseek proxy api 및 deepseek proxy url;
• 특히 위험한 deepseek free proxy 및 free deepseek proxy;
• 그리고 매우 우려스러운 api key proxy deepseeker.

이 모든 표현 뒤에 숨겨진 질문은 단 하나입니다: 당신의 키가 누구의 인프라를 통과하는가? 어떤 "무료 프록시"나 타인의 proxy url도 이 질문에 동일하게 답합니다. 바로 당신이 통제할 수 없는 타인의 인프라라는 것입니다. 그리고 api key proxy deepseeker는 문자 그대로 해서는 안 될 행동을 설명하고 있습니다: 활성 키(live key)를 제3의 중개인에게 넘겨주는 것입니다. 여기서 통제 원칙은 단순하고 엄격합니다: 알 수 없는 중개인에게 활성 키를 전달해서는 안 된다는 것입니다. 데이터 경로가 프록시를 통해 어떻게 흐르는지 불분명하다면, 해당 스택과의 결합은 허용되지 않습니다. 이는 통합을 아예 포함해서는 안 되는 두 가지 조건 중 하나입니다(두 번째 조건은 권한 제한이 불가능한 경우입니다).