가장 위험한 테스트용 DeepSeek 키는 해킹당한 키가 아니라, 단순히 테스트 기간을 넘어 살아남은 키입니다. 실험은 종료되었지만 유료 API (API) 액세스는 여전히 유효한 상태인 경우를 말합니다. 이 키는 환경 변수 (environment variable)에 잠자고 있으며, 누군가 오래된 커밋 (commit)에서 이를 발견하여 계정 예산이 타인의 요청으로 소진되기 전까지는 아무런 문제도 일으키지 않고 아무도 깨우지 않습니다.

이 분석의 논지를 검증해 보겠습니다: 테스트 키가 첫 실행 전부터 소유자와 종료 날짜가 기록된 레코드가 존재한다면, 해당 키는 관리 가능한 상태로 남습니다. 이러한 기록이 없다면, 아무리 주의 깊게 암호화하더라도 키는 관리 가능한 상태가 되지 않습니다.

이제 저는 키의 보관 (storage)과 액세스 관리 (access management)의 차이점, 액세스 패스포트 (access passport)의 어떤 필드들이 이러한 허점을 메우는지, 그리고 검증 가능한 사실이 어디서 끝나고 DeepSeek API 자체의 동작에 대한 저의 추측이 어디서 시작되는지를 보여드리겠습니다.

키 보관은 액세스 관리와 같지 않다

비밀 값을 비밀번호 관리자나 암호화된 .env 파일에 숨기는 것은 값의 기밀성 (confidentiality) 문제를 해결합니다. 액세스 관리는 다른 질문에 답합니다: 누가 키에 책임을 지는가, 어떤 환경에서 살아있는가, 그리고 언제 이를 취소해야 하는가. 전자는 "누가 이 문자열을 읽을 수 있는가"라는 질문에 답하고, 후자는 "이 문자열이 왜 지금 이 순간 존재해야 하는가"라는 질문에 답합니다.

흔하지만 논란의 여지가 있는 기본 설정은 다음과 같습니다: 테스트 키는 단순히 안전하게 저장하기만 하면 되며, 값이 유출되지 않았다면 위험은 없다는 것입니다. 이는 명확하지 않은 이유로 틀린 생각입니다. 안전하게 저장된 키라도 왜 발급되었는지, 언제 종료해야 하는지를 아무도 모른다면 여전히 위험 요소로 남습니다. 소유자가 퇴사하고, 실험이 종료되며, 리포지토리 (repository)가 아카이브 (archive)되어도 유료 API 액세스는 계속 유효하기 때문입니다.

여기서 두 가지 수준을 구분해야 합니다. 키의 값은 비밀 (secret)이며, 암호화와 액세스 권한으로 보호됩니다. 키의 수명 주기 (lifecycle)는 프로세스이며, 기록과 검토 날짜로 보호됩니다. DeepSeek 플랫폼은 두 번째 수준을 관리하지 않으므로, 외부에서 이를 관리해야 합니다.

DeepSeek API 키를 발급하는 방법

DeepSeek API를 호출하려면 개발자는 먼저 DeepSeek Platform의 platform.deepseek.com/api_keys 페이지에서 deepseek api key를 발급받아야 하며, 이를 Authorization 헤더에 HTTP Bearer 토큰으로 전달해야 합니다 (DeepSeek API Docs, 2026-07-18 접속). 때때로 deepseek api 개인 계정(deepseek api личный кабинет) 또는 deepseek platform api key라고 불리는 섹션을 포함한 키 발급은 계정 내에서의 별도 작업이며, 선언된 목적이나 책임자에게 자동으로 연결되는 것이 아닙니다.

인터페이스상에서는 그 결과물을 deepseek key라고 부르며, 문서상에서는 deepseek api key라고 합니다. 러시아어로는 이를 '딥식 키(дипсик ключ)' 또는 'deepseek 키(deepseek ключ)'라고 부르는 경우가 많으며, 표기 방식에 따라 본질이 변하지는 않습니다. deepseek api keys, api ключи deepseek 또는 апи ключи deepseek와 같은 복수형 표현은 오해를 불러일으킬 수 있습니다. DeepSeek는 계정 요청마다 하나씩 독립적인 키를 발급하며 패키지 형태로 제공하지 않으므로, 각각의 deepseek api key와 deepseek ключ api는 액세스 패스포트(passport of access) 내에서 각기 별도의 행을 차지하게 됩니다.

"deepseek api получить(deepseek api 받기)"라는 질문과 "deepseek получить api(deepseek api 얻기)"라는 질문은 동일한 동작, 즉 기존 액세스를 활성화하는 것이 아니라 새로운 독립적인 항목을 발급하는 것을 의미합니다 (DeepSeek API Docs, 2026-07-18 접속). "api deepseek как получить(api deepseek 어떻게 받나)" 또는 "как получить deepseek api(deepseek api 어떻게 받나)"와 같이 단어의 순서를 바꾸어도 결과에는 영향을 미치지 않으며, 두 표현 모두 동일한 API keys 섹션을 열어줍니다. 요컨대 "deepseek получить ключ(deepseek 키 받기)", "deepseek get api" 또는 "deepseek get api key"라고 묻는 것도 같은 맥락입니다. 계정 내의 발급 버튼은 하나이며, 테스트 키와 운영 키의 차이는 개발자가 직접 생성하는 액세스 패스포트 내에서만 나타납니다.

러시아어에서도 동일한 단계를 "апи ключ дипсик" 또는 "ключ апи дипсик"라고 설명하는데, 두 표현 모두 별도의 "테스트용" 대시보드 없이 동일한 페이지를 가리킵니다. "дипсик апи ключ"나 "api ключ дипсик"와 같이 순서가 바뀐 경우도 나타나며, 이는 앞서 언급한 DeepSeek 키와 동일한 것을 의미합니다. 고객 지원 티켓에서도 "дипсик api ключ"와 "api key дипсик"가 모두 등장하는데, 이는 소유자 및 만료일과 함께 액세스 패스포트 (access passport)에 입력해야 하는 키를 어디서 가져오는지에 대한 동일한 질문입니다. "deepseek api key как получить"라는 검색어 조합도 결국 같은 곳으로 연결되며, 대화 중 등장하는 "дипсик api key" 역시 같은 의미입니다. 즉, 발급 페이지에서는 키의 용도를 묻지 않으며, 이 필드는 외부의 액세스 패스포트에서만 작성됩니다.

DeepSeek은 키의 수명 주기를 대신 관리해주지 않습니다

DeepSeek의 공개 API 레퍼런스 (API reference), 퀵 스타트 (quick-start), 그리고 한도 (limits) 페이지에는 키의 유효 기간, 범위 태그 (scope tags), 용도 필드 (purpose field)에 대한 문서화된 기능이 없습니다. DeepSeek 콘솔은 수명 주기 메타데이터(소유자, 용도, 예정된 폐기 날짜)를 사용자를 대신해 기록하지 않습니다 (DeepSeek API Docs, 2026-07-18 접속).

혼란은 명칭 때문에 더욱 가중됩니다. "deepseeker"는 별도의 제품이나 브랜드가 아니라 흔히 발생하는 오타입니다. "ключ api deepseeker" 및 "api key deepseeker"와 같은 변형 키워드들은 위에서 설명한 API keys 섹션과 동일한 내용을 담고 있습니다. "api key for deepseeker"라는 질문과 그 러시아어 대응 표현인 "api ключ для deepseeker"는 두 언어로 동일한 것을 묻는 것이며, 요청 언어에 따른 답변도 변하지 않습니다. "api ключ от deepseeker" 및 "ключ от api deepseeker"라는 표현은 전치사의 위치만 바꿀 뿐, 키는 여전히 일반적인 deepseek key와 동일한 페이지에서 발급됩니다. "где взять api deepseeker" 및 "где взять api ключ deepseeker"에 대한 답변 역시 섹션 시작 부분에 언급된 것과 동일한 주소입니다. 또한 "как получить api deepseeker", "как получить api ключ deepseeker", "как получить api key deepseeker"를 검색해도 새로운 정보는 나오지 않습니다. 회사에는 별도의 deepseeker 브랜드가 없으며, 이 이름 주변을 맴도는 불필요한 경로는 이미 발급된 실제 키를 잊어버릴 위험만 높일 뿐입니다.

출처에 별도의 문구가 있으므로 따로 언급합니다. 키 발급 페이지인 platform.deepseek.com/api_keys에 직접 접속했을 때 HTTP 403 오류가 반환되었으며, 이는 아마도 인증된 세션이 필요하기 때문일 것입니다. 따라서 "한 번만 표시된다"는 인터페이스의 정확한 문구, 키의 명명 방식, 또는 삭제 확인 대화 상자 등은 1차 출처를 통해 확인하지 않았으며, 이를 플랫폼의 확인된 동작으로 제시하지 않습니다. 문서가 없다는 것 또한 사실이지만, 이를 "DeepSeek에는 피드백이 없다"가 아니라 "검토한 페이지에는 설명되어 있지 않다"라고 표현해야 합니다.

실질적인 결론은 하나입니다. 대시보드가 키의 컨텍스트(Context)를 저장하지 않으므로, 컨텍스트는 외부에서 저장해야 합니다. 이 경우 코드 자체는 평범하게 유지되지만, 모든 책임은 호출 범위를 벗어나게 됩니다.

from openai import OpenAI

# DeepSeek: 키는 platform.deepseek.com/api_keys에서 발급됨
...

코드 내의 주석은 우연이 아닙니다. 비밀값(Secret)은 레지스트리로 이전되지 않습니다. 이는 누군가의 망각으로 인한 결과가 아니라, 프로세스 자체가 그렇게 설계되어 있기 때문입니다.

액세스 여권: 어떤 필드가 허점을 메우는가

플랫폼이 수명 주기 (Lifecycle)를 관리하지 않기 때문에, 개발자가 직접 관리해야 합니다. 이를 위한 유효한 도구인 '테스트 액세스 여권 (Test Access Passport)'은 사고가 발생한 후가 아니라, 첫 실행 전부터 작성하는 짧은 기록입니다. 도구의 상태를 먼저 말씀드리자면, 이는 저자의 독자적인 방법이며 DeepSeek에는 이러한 기능이 없습니다. 출처들은 이를 확인해주지도, 금지하지도 않으며, 단지 플랫폼이 당신을 대신해 이 작업을 수행하지 않을 뿐입니다.

검증된 출처 중 어느 것도 대시보드의 러시아어 현지화 (Localization)에 대해 설명하지 않으므로, "DeepSeek 키 발급 방법"이나 "DeepSeek API 키 어디서 가져오나"와 같은 질문들은 모두 동일한 영어 페이지인 platform.deepseek.com/api_keys로 연결됩니다. "DeepSeek API 키 발급 방법"과 "DeepSeek api 키 발급 방법"의 차이는 단지 'api'를 키릴 문자로 쓰느냐 영문으로 쓰느냐의 차이일 뿐이며, 대시보드의 해당 섹션은 변하지 않습니다. "DeepSeek API 얻기"와 "DeepSeek API 발급 방법"은 모두 위에서 설명한 첫 번째 단계, 즉 DeepSeek 대시보드에서의 키 발급에 관한 질문입니다. "DeepSeek API 키 어떻게 받나요"나 "DeepSeek API 키 발급"은 단순히 단어의 순서만 바꾼 것이며, "아이피 키 딥시크", "딥시크 아이피 키", "딥시크 에이피아이 키"와 같은 음성적 변형은 다른 제품을 언급하지 않고 영어 용어를 들리는 대로 표기한 것입니다. 이러한 변형 중 그 어떤 것도 여권에 실제로 기록해야 할 사항을 바꾸지는 않습니다. 즉, 검색어의 발음이 아니라 목적, 소유자, 환경(Environment), 그리고 만료 기간을 기록해야 합니다.

여권은 키를 발급하기 전 반드시 답해야 하는 다섯 가지 질문에 답합니다.

키 발급 결정 로직은 간단합니다: 소유자가 있고, 만료 기간이 있거나 명시적인 폐기 결정이 있다면 발급합니다. 소유자가 없다면 발급하지 않습니다. 만료 기간도 없고 폐기 결정도 없다면, 이 또한 발급하지 않습니다. 이 접근 방식의 대가는 정직합니다: 여권을 관리해야 하고 프로세스에 시간을 할애해야 합니다. 제가 의도적으로 거부한 대안들(만료 기간 없이 키를 보관하다가 사고가 발생한 후에만 회수하는 방식)은 모두 잊혀진 활성 액세스 권한을 남겨두며, 바로 이것이 우리가 배제해야 할 대상입니다.

실패 조건은 정확히 두 가지입니다: 재검토 날짜(Review date)가 없거나, 키가 여권에 명시된 환경(Environment) 이외의 곳에서 사용되는 경우입니다. 이 중 하나라도 발생하면 레코드는 형식적으로는 채워져 있으나, 더 이상 통제되지 않는 상태가 됩니다. 통제되는 액세스는 다섯 가지 필드가 모두 동시에 채워졌을 때만 인정됩니다.

잊혀진 키가 보안뿐만 아니라 예산에 타격을 주는 이유

DeepSeek의 병렬 요청 제한(Parallel request limits)은 문서에 따르면 어떤 키를 사용하느냐와 관계없이 계정 수준에서 계산됩니다. 유일하게 더 세밀한 격리 방법은 선택적 요청 파라미터인 user_id를 사용하는 것입니다 (DeepSeek API Docs, 2026-07-18 접근). 즉, 관리되지 않는 테스트 키는 user_id를 통해 트래픽을 수동으로 분리하기 전까지 기본적으로 프로덕션(Production)과 동일한 할당량(Quota) 풀을 사용하게 됩니다.

공백을 포함해 "deep seek api key"라고 입력하거나 "deepseeek api key"와 같이 철자를 틀리게 입력하더라도 별도의 요금제가 생성되지는 않습니다. 두 방식 모두 동일한 키 발급 페이지로 연결되며, 계정 수준에서 동일한 한도(Limit)를 공유합니다. "deep seek api ключ"나 "deepseek ai key" 역시 마찬가지입니다. 이는 공식 문서에서 단순히 "deepseek api key"라고 명시된 것과 동일한 키입니다. "api deepseek com api key"라는 검색어는 대부분 위 코드 예제에 이미 명시된 작업 엔드포인트인 https://api.deepseek.com을 의미하며, 이름이 유사한 별도의 서비스를 의미하는 것이 아닙니다.

DeepSeek의 빌링(Billing) 방식은 선불제입니다. 비용은 충전된 잔액 또는 제공된 체험용(Trial) 잔액에서 차감되며, 제공된 잔액이 먼저 소진됩니다 (DeepSeek API Docs, 2026-07-18 접속). 공식 가격 페이지에는 잔액이 0에 도달했을 때 활성화된 키에 어떤 일이 발생하는지 명시되어 있지 않으므로, "잔액 소진"과 "키 작동 중지"를 당연한 인과관계로 단정 지을 수는 없습니다.

이러한 시나리오에 대한 책임은 윤리적 문제가 아닌 문서에 규정되어 있습니다. DeepSeek Open Platform 이용 약관 제2.2절에 따라, 사용자는 발급된 API 키를 안전하게 보관해야 하며, 제3자에게 전달하거나 클라이언트 사이드(Client-side) 코드에 노출해서는 안 됩니다. 키의 전달 또는 유출로 인해 발생하는 모든 비용과 손실에 대한 책임은 사용자에게 있습니다 (DeepSeek Open Platform Terms of Service, 제2.2절, 2026-07-18 접속). 즉, 관리 소홀로 키가 유출될 경우, 타인의 요청으로 발생한 비용은 플랫폼이 아닌 계정 소유자에게 청구됩니다.