업비트 API 한도 풀렸다…법인·운용사 큰손 노린 '포켓' 개편인가

[경제일보] 업비트가 거래소 API의 요청 제한 기준을 계정 단위에서 포켓 단위로 바꿨다. 개발자 정책 변경처럼 보이지만 배경에는 자동매매, 자산관리, 법인·기관 고객의 대용량 API 수요를 흡수하려는 인프라 전략이 깔려 있다는 분석이 나온다.

업비트 개발자센터는 25일부터 거래·자산 관리 API의 Rate Limit 측정 단위를 계정에서 포켓으로 변경한다고 공지했다. 변경 이후 각 포켓은 독립된 요청 한도를 갖는다. 한 포켓의 사용량이 다른 포켓에 영향을 주지 않는다.

기존에는 하나의 계정에서 여러 API Key를 발급해도 같은 계정 한도를 공유했다. 특정 전략이나 서비스가 요청 한도를 많이 쓰면 같은 계정 안의 다른 전략도 영향을 받을 수 있었다. 주문, 잔고 조회, 출금 조회, 입출금 상태 확인 같은 거래·자산관리 API가 서로 간섭하는 구조였다.

새 방식에서는 포켓별로 한도가 분리된다. 업비트 문서에 따르면 거래·자산 관리 REST API는 포켓 단위로 측정되고 같은 포켓의 여러 API Key는 한도를 공유한다. 서로 다른 포켓은 독립 한도를 갖는다. 예를 들어 메인포켓 1개와 서브포켓 5개가 각각 `exchange.default` 초당 30회 한도를 쓰면 계정 전체로는 최대 초당 180회까지 처리할 수 있다.

이 변화는 개인 개발자보다 대용량 API 사용 주체에게 더 크게 다가온다. 여러 전략을 동시에 운용하는 법인, 자산운용사, 마켓메이킹 업체, 알고리즘 트레이딩 기업, 커스터디·회계·리포팅 시스템을 운영하는 사업자는 주문과 잔고 조회, 자산 이동, 리스크 점검 요청이 많다. 계정 단위 한도는 이런 수요를 처리하는 데 제약이 됐다.

포켓 단위 한도는 자산 구획과 시스템 운영을 함께 분리할 수 있게 한다. 법인 계정이 전략별 포켓, 펀드별 포켓, 고객 자산별 포켓, 운용 목적별 포켓을 나눠 쓰면 각 포켓의 API 사용량도 따로 관리할 수 있다. 한 전략에서 요청이 몰리거나 차단이 발생해도 다른 포켓의 주문과 조회는 영향을 덜 받는다.

자산운용사 관점에서는 리스크 관리 측면도 있다. 포켓별로 권한과 자산 범위를 분리하면 운용 전략별 손익과 잔고, 거래 내역을 구분하기 쉽다. API Rate Limit까지 포켓 단위로 나뉘면 운용 시스템이 포켓별로 독립된 작업 큐를 구성할 수 있다. 이는 기관형 포트폴리오 관리와 내부통제에 유리한 구조다.

업비트가 API Key 추가 발급보다 포켓 분리 운영을 권고한 점도 중요하다. 같은 포켓의 여러 API Key는 하나의 한도를 공유한다. 처리량을 늘리려면 키를 늘리는 방식이 아니라 포켓을 분리해야 한다. 이는 단순 접속 키 남발보다 자산 단위와 권한 단위를 명확히 나누게 하려는 방향이다.

물론 업비트 공지에는 법인이나 자산운용사를 직접 겨냥했다는 표현은 없다. 따라서 이번 개편을 기관 고객 전용 정책으로 단정하기는 어렵다. 다만 계정 전체 처리량을 포켓 수만큼 확장할 수 있도록 설계한 점은 소규모 개인 이용자보다 대량 요청을 처리하는 사업자에게 실질적 효용이 크다.

영향 범위는 거래·자산 관리 API와 인증 포함 WebSocket 연결이다. 시세 조회 REST API는 기존처럼 IP 단위 제한을 유지한다. 인증 미포함 WebSocket 연결도 IP 단위다. WebSocket 데이터 요청은 커넥션 단위 제한을 유지한다.

이번 개편은 국내 거래소 API가 개인 투자자 중심에서 법인·기관형 운용 환경으로 이동하는 흐름과 맞물린다. 디지털자산 시장이 제도권 금융과 연결될수록 거래소에는 단순 매매 화면보다 안정적인 API, 자산 분리, 권한 관리, 대량 처리 능력이 더 중요해진다.

법인과 자산운용사, 대형 거래 시스템을 품으려면 거래소는 주문 처리 속도뿐 아니라 자산 분리와 권한 통제, 대용량 API 안정성을 갖춰야 한다. 이번 변화는 업비트가 기관형 디지털자산 인프라로 이동하기 위한 사전 정비로 전망된다.