DeepWrap 제작기: DeepSeek Chat을 위한 Python SDK 및 CLI

DeepSeek Chat은 브라우저에서는 무료였습니다.
하지만 제가 개발자처럼 사용하고 싶어지는 순간, 이야기는 달라졌습니다.

그 점은 제가 생각했던 것보다 훨씬 더 짜증스러운 일이었습니다.

브라우저에서 사용 가능한 기능이라면, 왜 Python에서 호출하거나, 터미널에서 호출하거나, 혹은 자신만의 로컬 도구에서 호출하려고 하는 순간 갑자기 차단된 것처럼 느껴지거나, 어색하거나, 인위적으로 비싸게 느껴져야 하는 걸까요?

그러한 불일치가 제가 DeepWrap을 만든 이유 전부였습니다.

"요청 몇 개를 조사해서 이게 얼마나 어려운지 한번 보자"로 시작했던 일이 하나의 완전한 프로젝트로 발전했습니다. 바로 DeepSeek Chat을 위한 Python SDK, 터미널 CLI, 그리고 **로컬 HTTP API 래퍼 (wrapper)**입니다.

제작 이유

진짜 동기는 단순했습니다:

DeepSeek는 브라우저에서는 무료였지만, 개발자들이 실제로 사용하고 싶어 하는 방식으로는 무료가 아니었습니다.

그리고 그것은 황당하게 느껴졌습니다.

저는 다음과 같은 실제 워크플로우 (workflows)에서 이를 사용하고 싶었습니다:

Python 스크립트 (scripts)
터미널 세션 (terminal sessions)
재사용 가능한 채팅 세션 (reusable chat sessions)
스트리밍 응답 (streaming responses)
로컬 도구 (local tools)
로컬 HTTP 통합 (local HTTP integrations)

모델을 개발자 친화적인 방식으로 사용하기 위해 영원히 브라우저 탭을 지켜보고 싶지는 않았습니다.

그래서 DeepWrap의 아이디어는 기본적으로 다음과 같았습니다:

브라우저 경험을 가져와서 코드에서 사용할 수 있게 만드는 것.

제작 과정

처음에는 진심으로 이것이 쉬울 것이라고 생각했습니다.

개발자 도구 (DevTools)를 열고, 네트워크 (Network) 탭으로 가서, XHR 요청들을 살펴보기 시작했을 때 저의 첫 생각은 이랬습니다:

"좋아, 이건 아마도 적절한 헤더 (headers)와 함께 올바른 요청들을 다시 재생하는 문제일 뿐일 거야."

그 낙관주의는 그리 오래가지 못했습니다.

1. 브라우저 요청 조사

첫 번째 단계는 단순히 흐름을 관찰하는 것이었습니다:

채팅 세션이 어떻게 생성되는지
어떤 헤더 (headers)가 전송되는지
프롬프트 페이로드 (prompt payload)가 어떻게 생겼는지
응답 스트림 (response stream)이 어떻게 돌아오는지

언뜻 보기에 흐름은 단순해 보였습니다:

세션 생성 (create a session)
프롬프트 전송 (send a prompt)
스트림 읽기 (read the stream)

그것만으로도 기본적인 클라이언트 구조를 스케치하기에는 충분했습니다.

2. 첫 번째 벽에 부딪히다: PoW + WASM

그다음 첫 번째 진짜 문제가 나타났습니다: 바로 작업 증명 (proof-of-work, PoW) 이었습니다.

일부 요청은 단순한 일반 인증 호출이 아니었습니다. 브라우저는 PoW 챌린지 (challenge)를 해결해야 했고, 그 로직은 WASM (WebAssembly) 으로 구현되어 있었습니다.

덕분에 프로젝트는 즉시 더 흥미로워졌습니다.

단순히 요청을 재현하는 대신, 저는 다음과 같은 작업을 수행해야 했습니다:

챌린지가 어떻게 가져와지는지 조사 (inspect)
챌린지 페이로드 (payload)를 이해
브라우저가 어디에서 이를 해결하는지 확인
WASM의 입출력 (input/output) 동작을 역공학 (reverse engineer)
Python에서 해결 단계를 복제 (replicate)

이 지점이 바로 이 프로젝트가 단순한 "빠른 래퍼 (quick wrapper)"가 아니게 된 순간이었습니다.

3. 사용 가능한 수준의 인증 추가

또한 전체 과정이 단순히 베어러 토큰 (bearer token)을 수동으로 붙여넣는 것에만 의존하는 것을 원치 않았습니다.

네, 그렇게 작동은 합니다.
하지만, 그렇게 하는 것은 기분이 좋지 않습니다.

그래서 브라우저 기반 인증 (browser-based auth) 도 추가했습니다.

이는 다음과 같은 흐름을 구축해야 함을 의미했습니다:

브라우저 실행
DevTools / 원격 디버깅 (remote debugging)을 통한 연결
인증된 트래픽 관찰
베어러 토큰 추출
토큰 정규화 (normalize)
SDK 및 CLI에서 재사용

그 부분은 복잡했지만, 프로젝트가 실용적으로 느껴지게 하려면 반드시 필요한 작업이었습니다.

4. 스트림을 제대로 파싱하기

인증과 PoW가 작동하게 된 후에도, 실제 채팅 스트림 (chat stream)을 처리해야 했습니다.

그리고 그것은 단순히 "텍스트 입력, 텍스트 출력"이 아니었습니다.

스트림에는 다음과 같은 것들이 포함되어 있었습니다:

사고 파편 (thinking fragments)
응답 파편 (response fragments)
부분 업데이트 (partial updates)
메타데이터 이벤트 (metadata events)
종료 이벤트 (close events)

그래서 저는 다음과 같은 기능을 갖춘 파서 (parser)를 구축했습니다:

멀티턴 상태 (multi-turn state) 보존
parent_message_id 추적
스트리밍 및 비스트리밍 방식 모두 지원
선택적으로 사고 과정(thinking)과 최종 출력 분리

이를 통해 내부 구현이 복잡하더라도 공개 API (public API)는 단순하게 유지될 수 있었습니다.

5. 진짜 도구로 만들기

Python API가 안정적이라고 느껴졌을 때, 저는 한 단계 더 나아갔습니다:

대화형 CLI (interactive CLI)
로컬 FastAPI 서버

그렇게 DeepWrap은 점차 세 가지 요소가 되었습니다:

Python SDK (Python SDK)
터미널 채팅 인터페이스 (terminal chat interface)
로컬 HTTP API 래퍼 (local HTTP API wrapper)

그 시점부터 이것은 단순한 해킹(hack)이 아닌, 하나의 제품(product)처럼 느껴지기 시작했습니다.

사용 모습

단순히 사용해보고 싶다면, 과정은 간단합니다.

설치

pip install deepwrap

클라이언트 생성

from deepwrap import Client

client = Client()

이미 토큰이 설정되어 있다면, 그것으로 충분합니다.

채팅 세션 생성

chat = client.chats.create_session(model="expert")

일반 응답 보내기

response = chat.respond(
    "Explain quantum computing in one short sentence.",
    thinking=True,
...

출력 스트리밍

for chunk in chat.respond(
    "Write a short explanation of black holes.",
    thinking=True,
...

대화 간 문맥 유지

print(chat.respond("My name is Nika.", stream=False))
print(chat.respond("What is my name?", stream=False))

세션이 내부적으로 대화 상태(conversation state)를 추적하기 때문에 이것이 가능합니다.

CLI 사용법

저는 터미널에서도 사용감이 좋기를 원했습니다.

다음 명령어로 대화형 인터페이스를 시작할 수 있습니다:

deepwrap

또는 단발성 터미널 호출을 사용할 수 있습니다:

deepwrap chat "Explain recursion in one sentence."

때로는 스크립트가 아니라 그저 빠른 터미널 워크플로(workflow)가 필요할 때가 있기 때문에, 저에게 이 기능은 중요했습니다.

God Mode

또한 God Mode라고 불리는 실험적인 기능을 추가했습니다.

이것은 어떤 마법 같은 숨겨진 모델이 아닙니다. **첫 번째 사용자 턴에서의 프롬프트 주입 (prompt injection on the first user turn)**을 통해 구현된 세션 수준의 동작 오버라이드(behavior override)입니다.

실제로 이는 다음을 의미합니다:

해당 세션 동안 모델의 동작 방식을 변경합니다.
의도적으로 침해적(intrusive)입니다.
예측 불가능한 방식으로 일반적인 동작에서 벗어날 수 있습니다.

저는 이것을 일상적인 사용을 위한 일반 모드가 아니라, 주로 개발자/테스트용 기능으로 추가했습니다.

따라서 저는 이것을 있는 그대로 취급합니다:
일반적인 용도가 아닌, 통제된 테스트를 위한 실험적 오버라이드입니다.

보안 참고 사항

몇 가지 중요한 참고 사항:

Bearer token(Bearer token)을 커밋하지 마세요
비밀 정보(Secrets)를 하드코딩하는 대신 환경 변수(Environment variables)나 로컬에 저장된 설정(Config)을 사용하세요
DeepWrap에 의해 저장된 토큰은 사용자의 설정 디렉토리(User config directory)에 로컬로 저장됩니다
브라우저 인증(Browser auth)은 신뢰할 수 있는 환경에서만 사용해야 합니다
God Mode와 같은 실험적 기능은 개발 전용 동작 수정자(Development-only behavior modifiers)로 취급해야 합니다

DeepWrap은 비공식 래퍼(Unofficial wrapper)이므로 책임감 있게 사용하십시오.

GitHub

프로젝트는 여기서 오픈 소스로 공개되어 있습니다:

GitHub: https://github.com/Kuduxaaa/deepwrap

Feedback

이 프로젝트 전체는 매우 단순한 좌절감에서 시작되었습니다:

“왜 브라우저에서는 무료인데, 개발자처럼 사용하려고 하는 순간 이렇게 불편할까?”

그 후 이 프로젝트는 제가 예상했던 것보다 훨씬 더 큰 프로젝트로 변했습니다:
요청(Requests) 역공학(Reverse-engineering), PoW WASM 처리, 브라우저 인증(Browser auth), 세션 관리(Session handling), 스트리밍(Streaming), CLI UX, 그리고 로컬 API 설계까지 말이죠.

만약 이 프로젝트를 살펴보신다면, 다음 사항들에 대해 진심 어린 피드백을 받고 싶습니다:

API 설계 (API design)
CLI UX
인증 흐름 (Auth flow)
아키텍처 (Architecture)
문서 (Docs)
기능 아이디어 (Feature ideas)

무언가 어색하거나, 과하게 만들어졌거나(Overbuilt), 부족하거나(Underbuilt), 혹은 그냥 이상하게 느껴진다면 저에게 말씀해 주세요.

그런 종류의 피드백이 가장 유용합니다.