2026년 나의 DeepSeek 에이전트 스택: 자유를 우선하는 가이드

지난해 대부분의 시간을 좌절감 속에서 보냈습니다. 큰 이름의 AI 제공업체들로 진지한 무언가를 만들려고 할 때마다, 마치 내 자신의 두뇌를 누군가에게서 임대하는 기분이 들었습니다. 하룻밤 사이에 부과되는 사용량 제한(Rate limits). 경고 없이 폐기되는 모델(Deprecated models). 항공권 요금표처럼 보이는 가격 책정 시트. 모든 경험에서 _독점적(proprietary)_이고 _폐쇄형 소스(closed source)_라는 느낌이 강하게 들었습니다.

그래서 저는 처음부터 다시 시작했습니다. 이번에는 제가 실제로 소유할 수 있는 도구들을 선택했습니다. 새 스택의 핵심은 무엇일까요? DeepSeek의 모델들, 특히 deepseek-v4-flash와 deepseek-reasoner입니다. 이 모델들은 Global API를 통해 라우팅되므로, 저는 누구의 울타리 안에도 갇히지 않습니다. 본 게시물에서는 제가 이 설정을 사용하여 프로덕션 AI 에이전트를 정확히 어떻게 구축하는지, 그리고 왜 여러분도 똑같이 하고 싶을지 설명해 드리겠습니다.

이것은 과장된 글이 아닙니다. 수개월 동안 에이전트 기반 시스템을 실제 환경에 배포한 개발자의 실질적인 기록입니다.

제가 울타리 안의 시스템(Walled Gardens)을 신뢰하는 것을 멈춘 이유

코드 한 줄을 만지기 전에, 여기서의 철학을 설명하고 싶습니다. 왜냐하면 이것이 모든 후속 결정들을 형성하기 때문입니다.

대형 AI 공급업체들은 '생태계(ecosystems)'에 대해 이야기하는 것을 좋아합니다. 그들이 의미하는 바는 다음과 같습니다: 우리의 SDK를 사용하고, 우리의 런타임에서 호스팅하며, 우리의 결제 포털을 통해 비용을 지불하고, 여러분의 대화 기록 한 바이트도 절대 외부로 내보내지 마십시오. 만약 이들 플랫폼 중 하나에서 프로젝트를 이전하려고 시도해 본 적이 있다면 그 고통을 알고 있을 것입니다. 엔드포인트가 변경됩니다. 응답 형식이 바뀌고(shift). 인증 방식이 재작성됩니다(rewritten). 여러분의 코드는 — 여러분이 직접 작성하고 엔지니어에게 비용을 지불하여 만든 코드 — 갑자기 다른 누군가의 로드맵에 속하게 됩니다.

저는 그런 것을 원하지 않습니다. 저는 MIT 라이선스가 적용된 라이브러리와 Apache 2.0 서버 스택을 원합니다. 애플리케이션을 재설계할 필요 없이 새벽 2시에 모델을 교체할 수 있기를 바랍니다. 제 자신의 왕국에 대한 열쇠를 갖고 싶습니다.

그러한 본능이 저를 DeepSeek과 Global API로 이끌었습니다. DeepSeek의 두 모델 모두 대부분의 변체(variants)에 대해 가중치(weights)에 대한 허용적인 라이선스(permissive licensing)를 제공합니다. Global API는 https://global-apis.com/v1을 가리키는 안정적인 OpenAI 호환 엔드포인트(endpoint)를 제공하므로, 제 클라이언트 코드는 이식성(portable)을 유지합니다. 나중에 기반 제공자(provider)를 바꾸고 싶다면, 문자열 하나만 변경하면 됩니다. 그것이 바로 꿈꾸던 모습입니다.

AI 에이전트란 실제로 무엇인가 (그리고 왜 내가 신경 쓰는가)

2026년의 모든 블로그 포스트는 "AI 에이전트"를 조금씩 다르게 정의합니다. 그러니 제가 실제 운영 환경(production)에서 다듬어 온 저만의 정의를 말씀드리겠습니다.

AI 에이전트는 루프(loop)입니다. 당신은 목표를 전달합니다. 에이전트는 생각합니다. 도구(tool)를 선택합니다. 도구를 호출합니다. 결과를 읽습니다. 다시 생각합니다. 승리를 선언하거나 다시 루프로 돌아갑니다. LLM(대규모 언어 모델)은 뇌이고, 루프는 몸이며, 도구는 손입니다.

이를 기존의 챗봇(chatbot) 모델과 비교해 보십시오:

기존 방식: 내가 질문하면 당신이 답하고, 그것으로 끝납니다.
에이전트 방식: 내가 목표를 주면, 당신은 무엇을 물어야 할지, 누구에게 물어야 할지, 그리고 답변들을 어떻게 하나로 엮을지를 스스로 결정합니다.

실질적인 차이는 엄청납니다. 일반적인 챗봇의 경우, 사용자가 "다음 주 화요일에 800달러 미만으로 도쿄행 항공권을 예약해 줘"라고 요청하면, 파서(parser), 항공사 API 연동, 날짜 계산, 가격 필터, 예약 로직을 직접 작성해야 합니다. 하지만 에이전트의 경우, LLM에 사용 가능한 도구 목록 — search_flights, get_price, book_seat — 을 전달하기만 하면 에이전트가 스스로 오케스트레이션(orchestration)을 수행합니다.

이것이 제가 이 패턴에 집착하게 된 이유입니다. 이것은 마법이 아닙니다. 그저 매우 훌륭한 추상화 계층(abstraction layer)일 뿐입니다.

내가 사용하는 모델들

두 가지 DeepSeek 모델이 제 에이전트 작업의 거의 전부를 수행합니다:

deepseek-v4-flash — 저의 기본 모델입니다. 빠르고 저렴하며, 분류(classification), 라우팅(routing), 단순한 도구 선택의 대부분을 처리합니다. 일상적인 작업을 위해 에이전트 루프가 가동될 때 실행되는 모델입니다.

deepseek-reasoner — 저의 강력한 해결사입니다. 작업이 진정으로 사고의 사슬(chain-of-thought)을 필요로 할 때 이 모델을 꺼냅니다. 다단계 연구 워크플로우(workflow)를 계획하나요? 모순되는 제약 조건들을 추론해야 하나요? 그것이 바로 reasoner의 영역입니다.

두 방식 모두 동일한 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)를 통해 작동합니다. 이는 제가 flash를 호출하든 reasoner를 호출하든 Python 및 JavaScript 클라이언트가 동일하게 보인다는 것을 의미합니다. 저는 그저 model 문자열만 바꾸면 됩니다.

클라이언트 설정 (올바른 방법)

단 하나의 에이전트 루프(agent loop)를 작성하기 전에, 작동하는 클라이언트가 필요합니다. 대부분의 튜토리얼이 저를 놓치는 지점이 바로 여기입니다. 그들은 지루한 인프라 부분을 대충 넘어가며, 여러분이 이미 어딘가에 키(key)를 연결해 두었을 것이라고 가정합니다. 제가 실제로 무엇을 하는지 보여드리겠습니다.

먼저, Global API에서 키를 가져오세요. 키는 단순한 32자리의 16진수(hexadecimal) 문자열입니다. sk- 접두사도 없고, 특수 문자도 없습니다. 그저 깔끔한 16진수 덩어리(hex blob)일 뿐입니다. 저는 그 점이 마음에 듭니다. 덕분에 제 .env 파일이 깔끔하게 유지되고, grep으로 쉽게 찾을 수 있기 때문입니다.

Python 설정

저는 OpenAI SDK를 직접 설치합니다. 네, 이름에 "OpenAI"라고 적혀 있긴 하지만, 이 인터페이스는 LLM API의 비공식 표준이 되었으며, DeepSeek(Global API를 통해)도 이 표준을 유창하게 구사합니다.

pip install openai httpx

다음은 저의 agent_client.py입니다:

from openai import OpenAI
import os

...

저 파일 전체에서 base_url 라인이 가장 중요한 부분입니다. 그 단 하나의 문자열이 저를 이식성(portable) 있게 만들어 줍니다. 그것을 바꾸면 저는 다른 제공업체와 통신하게 됩니다. 그대로 두면, 제 코드는 서버를 누가 운영하는지 신경 쓰지 않습니다.

JavaScript 설정

Node.js도 동일하게 처리합니다:

npm install openai

// agent_client.js
import OpenAI from 'openai';

...

동일한 형태, 동일한 동작, 동일한 OpenAI 호환 계약(contract)을 따릅니다. 저는 이 점이 정말 좋습니다. 배워야 할 특정 벤더 전용 SDK도 없고, 암기해야 할 커스텀 요청 형식도 없습니다.

함수 호출 (Function Calling): 진정한 마법

이제 에이전트를 가능하게 만드는 부분에 도달했습니다. 함수 호출(Function calling) — 때로는 도구 사용(tool use)이라고도 불리는 — 은 LLM이 "이봐, 이 함수를 실행하고 결과를 나에게 알려줘"라고 말할 수 있게 해주는 프로토콜입니다.

함수 호출 (function calling)이 없다면, LLM은 단순한 텍스트 생성기에 불과합니다. 하지만 함수 호출이 있다면, LLM은 데이터를 요청하고, 데이터를 기다리며, 당신이 다시 제공한 데이터를 바탕으로 추론할 수 있는 존재가 됩니다. 이것이 챗봇 (chatbot)과 에이전트 (agent)의 차이입니다.

사용자가 "비트코인의 현재 가격은 얼마인가요?"라고 물었을 때의 개념적 흐름은 다음과 같습니다:

메시지가 에이전트 루프 (agent loop)에 도달합니다.
루프는 사용 가능한 도구 (tools) 목록과 함께 메시지를 deepseek-v4-flash로 보냅니다.
모델은 텍스트로 응답하지 않습니다. 대신 구조화된 객체(structured object)로 응답합니다: "인자(arguments) 없이 get_bitcoin_price를 호출하고 싶습니다."
제 코드가 get_bitcoin_price를 실행하며, 이는 가격 피드 (price feed)를 호출하여 "$67,420"을 반환합니다.
저는 그 결과를 새로운 메시지로 모델에 다시 전달합니다.
이제 모델은 최종 답변을 작성할 수 있는 충분한 정보를 갖게 됩니다: "비트코인은 현재 $67,420에 거래되고 있습니다."

모델이 도구를 요청하고, 코드가 도구를 실행하며, 결과가 다시 돌아오는 이 왕복 과정(round trip)은 당신이 만들 모든 에이전트의 심장 박동과 같습니다.

나의 첫 번째 실제 에이전트 루프 작성하기

제가 실제로 배포한 루프를 보여드리겠습니다. 이 코드는 작고, 읽기 쉬우며, 포크 (fork)하기 쉽습니다. 핵심은 추상화 (abstraction)를 긴밀하게 유지하여, 전체를 다시 작성하지 않고도 구성 요소들을 자유롭게 교체할 수 있도록 하는 것입니다.

# simple_agent.py
import json
from openai import OpenAI
...

이것이 뼈대입니다. 이 코드는 도구 호출 (tool calls)을 처리하고, 결과를 다시 전달하며, 루프의 범위를 제한합니다. 여기서부터 다음과 같은 기능들을 추가할 수 있습니다: 영구 메모리 (persistent memory, 타인의 벡터 DB가 아닌 직접 소유한 SQLite 파일), 에러 핸들링 (error handling), 로깅 (logging), 그리고 작업이 까다로워질 때 deepseek-v4-flash를 deepseek-reasoner로 교체할 수 있는 방법 등입니다.

비용 방정식 (그리고 비용을 낮게 유지하는 방법)

제가 처음에 DeepSeek를 선택하게 된 이유 중 하나는 바로 수학적 계산 때문이었습니다. 프런티어 폐쇄형 모델 (frontier closed model)로 에이전트 루프를 실행하면 현금이 빠르게 소진될 수 있습니다. 모든 반복 (iteration)은 전체 프롬프트 + 응답을 수반하며, 만약 에이전트가 5단계를 거친다면 호출당 비용이 5배로 늘어나기 때문입니다.

DeepSeek의 가격 책정은 진정으로 경쟁력이 있으며, deepseek-v4-flash는 제 청구서가 감당 가능한 수준을 유지해 주는 일꾼 역할을 합니다. 정말로 추론의 깊이 (reasoning depth)가 필요할 때만, 해당 단계에서 deepseek-reasoner로 격상하여 사용합니다. 나머지 루프 (loop)는 flash 모델로 유지합니다.

제가 크게 의존하는 또 다른 기술은 Global API를 통한 **GA Fusion 라우팅 (routing)**입니다. 제 에이전트가 특히 까다로운 요청을 받으면, GA Fusion은 제가 제공자 로직을 하드코딩하지 않아도 가장 적절한 백엔드로 동적 라우팅을 수행할 수 있습니다. 제 클라이언트는 여전히 https://global-apis.com/v1을 호출하지만, 내부적으로는 Global API가 그 안무 (choreography)를 처리합니다. 저는 라우팅 코드를 직접 작성하지 않고도 모델 차익 거래 (model arbitrage)의 비용 이점을 얻습니다.

이것은 마법이 아닙니다. 그저 합리적인 관심사 분리 (separation of concerns)일 뿐입니다. 제 코드는 OpenAI 호환 엔드포인트 (endpoint)와 통신하는 방법을 알고, 엔드포인트는 해당 작업에 가장 적합한 모델이 무엇인지 알고 통신하는 법을 압니다.

제가 고생하며 배운 패턴들

이러한 시스템들을 몇 개 프로덕션 (production)에 배포한 후, 제 팔뚝에 문신으로 새기고 싶을 만큼 중요한 패턴들은 다음과 같습니다:

루프 (loop)에 제한을 두세요. 항상 그래야 합니다. 영원히 실행될 수 있는 에이전트는 정말로 영원히 실행될 것이며, 여러분의 청구서도 그와 함께 영원히 늘어날 것입니다. 저는 기본 상한선을 10으로 설정하고 거기서부터 조정합니다.

모든 단계를 로그 (log)로 남기세요. 저는 단계마다 타임스탬프, 사용된 모델, 입력 토큰 (tokens in), 출력 토큰 (tokens out), 호출된 도구 (tool called), 도구 결과 (tool result)를 포함한 JSON 라인을 작성합니다. 새벽 3시에 무언가 잘못되었을 때, 이 로그는 20분 만에 해결하느냐 4시간 동안 디버깅을 하느냐의 차이를 만듭니다.

도구를 무상태 (stateless)로 만드세요. 만약 도구가 숨겨진 전역 상태 (global state)에 의존한다면, 디버깅은 악몽이 됩니다. 모든 것을 입력으로 전달하고, 모든 것을 출력으로 반환하세요. 이것이 도구를 테스트 가능하게 유지하는 방법이기도 합니다.

도구 인자 (arguments)를 검증하세요. LLM이 delete_user(id=42)를 호출하고 싶다고 말한다고 해서 그대로 허용해서는 안 됩니다. 검증(Validate)하고, 화이트리스트(Whitelist)를 적용하며, 샌드박스(Sandbox) 환경을 구축하세요.

reasoner를 아껴서 사용하세요. 출력 결과가 더 좋기 때문에 모든 것에 deepseek-reasoner를 던져주고 싶은 유혹이 생깁니다. 하지만 비용도 더 많이 듭니다. 라우팅에는 flash를, 실제 추론에는 reasoner를 사용하세요.

제가 절대 돌아가지 않을 이유

2026년에 에이전트 (Agents)를 구축하는 것은 2009년에 웹 앱 (Web apps)을 구축하던 느낌과 매우 비슷합니다. 패턴은 결정화되고 있고, 툴링 (Tooling)은 성숙해지고 있으며, 올바른 기반을 구축하는 사람들이 향후 10년의 흐름을 정의할 수 있는 짧은 기회의 창이 열려 있습니다.

저는 그 기회의 창에서 오픈 소스 (Open side) 쪽에 있고 싶습니다. MIT 라이선스 클라이언트 (MIT-licensed clients). Apache 라이선스 서버 (Apache-licensed servers). 오픈 웨이트 모델 (Open-weight models). 제가 제어할 수 있는 단일 베이스 URL (Base URL). 저를 가두는 독점적 SDK (Proprietary SDK) 없음. 예측 불가능한 속도 제한 (Rate limits) 없음.

그것이 제가 오늘 실행하고 있는 스택 (Stack)이며, 앞으로도 계속 실행할 스택입니다.

이 설정을 직접 시도해보고 싶다면, Global API에서 키를 가져와서 귀하의 OpenAI 클라이언트를 https://global-apis.com/v1으로 지정하세요. 위 코드의 처음 10줄이 시작하는 데 필요한 전부입니다. 나머지는 그저 반복 (Iteration)일 뿐입니다.

진정으로 당신이 소유할 수 있는 무언가를 만드세요.