업비트 서브포켓 써보니 꽤 쓸 만하다 — 투자 계좌 분리부터 API 자동매매까지

업비트 서브포켓 써보니 꽤 쓸 만하다 — 투자 계좌 분리부터 API 자동매매까지

업비트에 최근 포켓(Pocket) 기능이 생겼다.

처음에는 단순히 자산을 화면상으로 구분해 놓는 기능 정도로 생각할 수도 있는데, 직접 API까지 붙여서 사용해보니 생각보다 활용 범위가 넓다.

업비트의 포켓은 하나의 계정 안에 기본 메인포켓 1개가 있고, 별도로 서브포켓을 최대 5개까지 만들 수 있는 구조다. 서브포켓은 자체 잔고를 가지고 있으며 별도의 API Key도 발급할 수 있다.

내가 관심을 가진 이유는 크게 세 가지였다.

투자 목적별 자산 분리, 자동매매 시스템 분리, API Rate Limit 분리다.

 

---

1. 중기·장기 투자와 단기매매 자금을 실제로 나눌 수 있다

예를 들어 메인포켓에서는 평소 단기매매와 자동매매를 하고 있다고 해보자.

그런데 별도로 몇 달 이상 가져갈 중기 포지션이나 장기투자 물량이 생기면 문제가 하나 생긴다.

같은 잔고에 전부 섞여 있으니 프로그램을 만들 때도 항상

“이 코인은 자동매매 물량인가?”
“장기 보유 물량인가?”
“이 수량은 건드리면 안 되는 수량인가?”

를 코드에서 구분해야 한다.

서브포켓으로 보내버리면 이야기가 단순해진다.

메인포켓 = 단기/자동매매
서브포켓 1 = 중기투자
서브포켓 2 = 장기투자
서브포켓 3 = 특정 자동매매 전략

같은 식으로 실제 자산 자체를 나눌 수 있다.

단순히 엑셀에서 장부를 나누는 게 아니라 포켓별 잔고가 실제로 분리된다는 점이 핵심이다. 업비트도 포켓을 “계정 안에서 자산을 목적별로 나누어 투자하고 관리하는 기능”으로 설명하고 있다.

---

2. 박성현 투자자의 ‘세븐 스플릿’ 같은 계좌분할 아이디어에도 응용할 수 있다

여기서 떠오른 게 박성현 투자자의 환 트레이딩에서 알려진 세븐 스플릿식 계좌 분할 아이디어다.

핵심 아이디어만 가져오면 하나의 거대한 포지션으로 생각하지 않고 자금을 여러 운용 단위로 나눠 각각 다른 진입가격과 역할을 부여하는 방식이다.

업비트 포켓에서는 이것을 가상자산 쪽에서도 응용해볼 수 있다.

가령 테더(USDT)를 운용한다면 포켓별로 자금을 나눠 놓고 각 포켓에 서로 다른 매입 구간이나 운용 규칙을 적용하는 식이다.

중요한 것은 이것이 수익을 보장하는 전략이라는 의미가 아니라 자금관리 구조를 물리적으로 분리할 수 있다는 것이다. 분할한다고 시장위험이 사라지는 것도 아니고, USDT 역시 원/달러 환율과 거래소 가격, 가상자산 특유의 위험을 함께 고려해야 한다.

그럼에도 장부상으로만 “1번 계좌, 2번 계좌”라고 적는 것보다 실제 잔고가 분리되어 있다는 것은 자동화할 때 상당히 편하다.

---

 

3. 자동매매를 한다면 더 재미있는 부분은 API Rate Limit이다

내가 포켓 기능을 눈여겨본 가장 큰 이유 중 하나다.

2026년 6월 25일부터 업비트의 거래·자산 관리 Exchange API Rate Limit 측정 단위가 계정 단위에서 포켓 단위로 변경됐다.

즉 서로 다른 포켓은 API 요청 한도가 독립적이다.

현재 공식 문서 기준으로 일반 Exchange default 그룹은 포켓당 초당 최대 30회이고, 주문 생성 order 그룹은 포켓당 초당 최대 12회다. 반면 시세 조회 REST API는 여전히 IP 단위다.

이 차이가 중요하다.

예를 들어 메인포켓에서 여러 자동매매 프로그램이 주문조회, 잔고조회, 주문취소 등을 계속 하고 있다면 같은 포켓의 API Key를 여러 개 발급한다고 한도가 늘어나는 게 아니다.

같은 포켓의 여러 API Key는 한도를 공유한다.

반면 별도 서브포켓은 독립된 한도를 갖는다. 업비트도 처리량을 늘리려면 API Key만 추가하지 말고 포켓을 분리해야 한다고 명시하고 있다.

자동매매를 여러 개 돌리는 사람에게는 꽤 큰 변화다.

다만 이것 역시 무작정 API를 많이 호출해도 된다는 뜻은 아니다. Remaining-Req를 확인하고 429 발생 시 호출을 중단한 뒤 재시도하는 등의 Rate Limit 관리가 필요하다.

---

직접 만들어본 메인 ↔ 서브포켓 자산이동 GUI

실제로 테스트하기 위해 간단한 Python GUI를 하나 만들었다.

 

화면을 보면 현재

메인 KRW: 215,596원
서브 KRW: 100,000원
서브 코인 평가: 0원
서브 총자산: 100,000원

처럼 메인과 서브포켓의 자산을 동시에 확인할 수 있다.

아래에서 자산과 금액을 입력하고 **메인 → 서브 보내기**를 누르면 선택한 서브포켓으로 자산을 옮기고, **서브 → 메인 반납**을 누르면 다시 가져올 수 있게 만들었다.

업비트가 공식적으로 포켓 간 자산이전 API를 제공하기 때문에 가능한 구조다. 메인포켓 API에서는 메인↔서브뿐 아니라 서로 다른 서브포켓 사이의 자산이전도 지원한다.

API 권한도 분리되어 있다.

메인포켓에는 포켓관리, 서브포켓에는 자산이전 권한이 있고, 각 포켓에서 잔고조회나 매매를 하려면 각각 자산조회, 주문조회, 주문하기 같은 필요한 권한을 선택할 수 있다.

---

실제 사용한 Python 코드 공개

아래는 내가 테스트한 자산조회 + 메인→서브 + 서브→메인의 핵심 코드다.

API 키는 절대로 블로그에 같이 올리면 안 된다. 아래 빈칸에 각자 발급받은 키를 사용하거나, 실제 운영에서는 환경변수로 분리하는 것을 권한다. 업비트 역시 API 인증정보가 노출되지 않도록 관리할 것을 안내하고 있다.

 

# -*- coding: utf-8 -*-

import uuid
import hashlib
import requests
import jwt
from urllib.parse import urlencode

BASE_URL = "https://api.upbit.com"

# 메인포켓 API
# 필요 권한: 포켓관리
MAIN_ACCESS_KEY = ""
MAIN_SECRET_KEY = ""

# 서브포켓 API
# 필요 권한: 자산조회 + 자산이전
SUB_ACCESS_KEY = ""
SUB_SECRET_KEY = ""


def make_headers(access_key, secret_key, params=None):
    payload = {
        "access_key": access_key,
        "nonce": str(uuid.uuid4())
    }

    if params:
        query_string = urlencode(params, doseq=True)

        h = hashlib.sha512()
        h.update(query_string.encode())

        payload["query_hash"] = h.hexdigest()
        payload["query_hash_alg"] = "SHA512"

    token = jwt.encode(payload, secret_key)

    return {
        "Authorization": f"Bearer {token}"
    }


def api_json(method, path, access, secret, params=None):
    url = BASE_URL + path

    headers = make_headers(access, secret, params)
    headers["Accept"] = "application/json"
    headers["Content-Type"] = "application/json"

    if method == "GET":
        r = requests.get(
            url,
            headers=headers,
            params=params,
            timeout=5
        )

    elif method == "POST":
        r = requests.post(
            url,
            headers=headers,
            json=params or {},
            timeout=5
        )

    else:
        raise ValueError(method)

    data = r.json()

    if r.status_code >= 400:
        raise RuntimeError(
            f"HTTP {r.status_code}: {data}"
        )

    return data


# ---------------------------------------
# 1. 포켓 목록
# ---------------------------------------

def get_pockets():
    return api_json(
        "GET",
        "/v1/pockets",
        MAIN_ACCESS_KEY,
        MAIN_SECRET_KEY
    )


# ---------------------------------------
# 2. 현재 포켓 잔고
# ---------------------------------------

def get_accounts(access, secret):
    return api_json(
        "GET",
        "/v1/accounts",
        access,
        secret
    )


# ---------------------------------------
# 3. 메인 → 서브
# ---------------------------------------

def main_to_sub(sub_uuid, currency, amount):

    body = {
        "to": sub_uuid,
        "currency": currency.upper(),
        "amount": str(amount),

        # identifier는 매 요청마다 새 값 사용
        "identifier": "m2s_" + uuid.uuid4().hex,
    }

    return api_json(
        "POST",
        "/v1/pockets/universal_transfers",
        MAIN_ACCESS_KEY,
        MAIN_SECRET_KEY,
        body
    )


# ---------------------------------------
# 4. 서브 → 메인
# ---------------------------------------

def sub_to_main(currency, amount):

    body = {
        "currency": currency.upper(),
        "amount": str(amount),
        "identifier": "s2m_" + uuid.uuid4().hex,
    }

    return api_json(
        "POST",
        "/v1/pockets/transfers",
        SUB_ACCESS_KEY,
        SUB_SECRET_KEY,
        body
    )

 

업비트의 포켓 목록 API에서는 각 포켓의 UUID를 조회할 수 있고, 이 UUID를 자산이전 대상 식별자로 사용할 수 있다.

실전에서는 위 코드에 Tkinter를 붙여서 포켓 선택 → 잔고조회 → 금액 입력 → 확인창 → 이전 순서로 만들면 내가 올린 화면처럼 사용할 수 있다.

---

그런데 직접 써보니 한 가지 불편하다 — 내 주문이 어디에 걸려 있지?

서브포켓 자동매매까지 연결하면서 바로 불편한 점이 하나 생겼다.

자산은 깔끔하게 분리됐는데 프로그램만 보고 있으면,

“내 서브포켓 매수 주문이 지금 몇 호가에 있지?”

“매도 주문은 어느 가격에 얼마나 걸려 있지?”

를 즉각 파악하기가 답답했다.

그래서 이것도 별도의 모니터를 만들었다.

공개 호가 데이터에 서브포켓 API로 조회한 내 미체결 주문을 가격별로 대조해서 표시하는 방식이다.

내가 만든 화면에서는 매수와 매도를 각각 1~5호가까지 보여준다.

해당 가격에 내 주문이 있으면 화면에서 바로 구분되고,

• BUY 호가 더블클릭 → 주문이 없으면 매수 / 있으면 취소
• SELL 호가 더블클릭 → 주문이 없으면 매도 / 있으면 취소
• 신규 매도금액을 원화로 직접 설정
• 현재 코인 보유평가액
• 현재 SELL 주문으로 묶여 있는 평가액
• 아직 SELL하지 않은 물량의 원화 환산액

까지 한 화면에서 볼 수 있도록 했다.

그리고 현재 5호가 화면 밖으로 밀려난 주문도 생길 수 있으므로 티커별로 5호가 밖 BUY 취소 / 5호가 밖 SELL 취소 기능을 추가했다.

덕분에 실제 업비트 호가창을 계속 열어놓지 않아도 서브포켓의 주문 상태를 상당 부분 관리할 수 있게 됐다.

이 호가 모니터링·주문관리 코드는 이번 글에서는 공개하지 않는다.

구조 자체는 단순하다. 공개 호가 + 서브포켓 미체결 주문 조회 결과를 가격 기준으로 합쳐서 시각화하는 방식이다.

---

포켓을 써보니 자동매매에서 의미가 더 크다

처음에는 단순한 ‘계좌 나누기’ 기능으로 봤다.

그런데 실제 API 프로그램을 붙여보니 오히려 자동매매를 하는 사람에게 활용도가 더 높아 보인다.

자금도 분리되고, 주문도 분리되고, API Key도 분리되고, Exchange API Rate Limit까지 포켓 단위로 독립적이기 때문이다.

따라서 하나의 업비트 계정을 가지고도,

메인포켓 — 일반 매매
서브포켓 A — 중장기 투자
서브포켓 B — 스프레드 자동매매
서브포켓 C — USDT 분할 운용
서브포켓 D — 새로운 전략 소액 실험

처럼 목적을 명확하게 나누는 구성이 가능하다.

특히 새로운 자동매매 코드를 처음 실계좌에서 테스트할 때도 전체 메인잔고에 접근시키는 대신 서브포켓에 10만원만 옮겨놓고 그 포켓의 API Key만 프로그램에 넣는 방식으로 테스트 범위를 물리적으로 제한할 수 있다는 점이 마음에 든다.

물론 프로그램 버그에 대한 손실 방지책이 완벽해지는 것은 아니다. 주문 로직, 최소 주문금액, API 오류, 중복주문, Rate Limit, 네트워크 장애 등의 보호 로직은 별도로 필요하다.

그래도 “전략별로 자금을 실제 분리한다”는 것은 자동매매 시스템을 운영할 때 꽤 유용한 안전장치가 될 수 있다.

---

참고

업비트 공식 문서 기준 포켓 기능은 2026년 6월 1일 출시됐고, Exchange API Rate Limit의 포켓 단위 적용은 2026년 6월 25일부터 시행됐다. API 정책은 이후 변경될 수 있으므로 실제 코드를 사용할 때는 최신 개발자 문서를 확인하는 것이 좋다.

업비트 포켓 공식 문서
업비트 API Rate Limit 공식 문서

※ 이 글은 포켓/API 기능을 직접 활용해본 기록이며 특정 가상자산의 매수·매도를 권유하는 글이 아닙니다. API를 통한 실제 주문 및 자산이전은 반드시 소액으로 충분히 테스트한 뒤 사용하시기 바랍니다.