코인 자동매매 프로그램 제작 — 업비트 vs 바이낸스 7기준

30초 판단표 — 7기준 한눈에

코인 자동매매 프로그램 제작 문의에서 가장 자주 나오는 질문이 “업비트로 할까요, 바이낸스로 할까요”입니다. 수수료율부터 비교하는 분이 많은데, 실제로 제작 기간과 견적을 벌리는 건 수수료가 아니라 아래 일곱 줄입니다. 각 항목의 근거는 뒤에서 하나씩 공식 문서와 대조합니다.

기준① 원화가 들어가는 경로

코인 자동매매 프로그램에서 가장 먼저 갈리는 건 코드가 아니라 돈이 들어가는 길입니다.

업비트는 원화 입금이 거래소 안에서 끝납니다. 실명확인 입출금 계좌를 연결해 두면 원화가 들어오고, 봇은 KRW-BTC처럼 원화 마켓 심볼로 바로 주문을 냅니다. 즉 “돈을 넣는다 → 봇이 산다”가 한 계좌 안에서 완결됩니다.

바이낸스는 다릅니다. 원화를 직접 꽂아 넣는 경로가 사실상 없어서, 국내 거래소(업비트·빗썸·코인원 등)에서 코인을 산 뒤 바이낸스 지갑 주소로 전송하는 단계가 하나 더 붙습니다. 여기에서 실무적으로 걸리는 게 셋입니다.

• 전송 네트워크 선택 — 같은 코인도 네트워크를 잘못 고르면 자산이 사라집니다. 봇 이야기가 아니라 사람이 하는 일인데, 여기서 사고가 제일 많이 납니다.
• 출금 정책 — 국내 거래소마다 출금 조건과 대기 시간이 다릅니다. 봇의 리밸런싱 주기를 여기에 맞춰야 합니다.
• 정산과 세무 — 거래소가 둘이면 기록도 둘로 흩어집니다. 봇이 남기는 체결 로그를 처음부터 CSV로 떨궈 두는 편이 낫습니다.

결론은 단순합니다. “원화만 넣고 돌릴 거다”면 업비트가 구조적으로 짧습니다. 제작 견적에서도 거래소가 하나면 지갑 이동 로직·이중 정산이 통째로 빠집니다.

기준② API 키 발급 조건 — 여기서 제일 많이 막힌다

제작을 의뢰하고 나서 “프로그램은 다 됐는데 키가 안 나와요”로 며칠 날리는 경우가 흔합니다. 업비트 공식 API Key 발급 가이드 기준으로 조건은 이렇습니다.

• API Key 발급은 PC 웹 환경에서만 가능합니다. 모바일 앱에서는 발급이 안 됩니다.
• 회원가입 후 고객 확인과 2채널 인증(2FA)을 완료해야 발급할 수 있습니다.
• 발급 가능한 개수는 메인포켓 최대 10개, 서브포켓당 최대 5개입니다.
• 키를 만들 때 허용 IP 주소를 등록해야 하고, API Key 하나당 최대 10개 IP를 넣을 수 있습니다.
• Secret Key는 최초 발급 화면에서만 보입니다. 못 받아 적었으면 삭제하고 다시 발급하는 수밖에 없습니다.

바이낸스는 웹에서 API Key를 만들고 X-MBX-APIKEY 헤더에 실어 씁니다. 여기서도 실무 원칙은 같습니다. 주문·조회 권한만 켜고 출금 권한은 끄고, IP 화이트리스트를 서버 IP로 고정합니다. 키 보관 원칙은 API 키 보안과 계좌 보호에 정리해 뒀습니다.

기준③ 인증 코드 난이도 (실물 비교)

“직접 만들어 볼까” 하는 분이 가장 먼저 부딪히는 지점입니다. 두 거래소의 인증 방식은 실물로 보면 차이가 분명합니다.

업비트 — JWT 토큰 + query_hash

업비트는 Access Key와 Secret Key로 JWT를 만들어 Authorization: Bearer 헤더에 실습니다. 파라미터가 있는 요청은 쿼리 문자열을 SHA512로 해시해 query_hash에 넣어야 합니다. 이 한 줄을 빼먹어 인증이 계속 실패하는 사례가 많습니다.

# 업비트 인증 토큰 생성 (파라미터 없는 잔고 조회)
import jwt, uuid, requests

ACCESS_KEY = "환경변수로 넣으세요"
SECRET_KEY = "환경변수로 넣으세요"

payload = {
    "access_key": ACCESS_KEY,
    "nonce": str(uuid.uuid4()),
}
token = jwt.encode(payload, SECRET_KEY)

res = requests.get(
    "https://api.upbit.com/v1/accounts",
    headers={"Authorization": f"Bearer {token}", "accept": "application/json"},
    timeout=10,
)
print(res.status_code, res.headers.get("Remaining-Req"))
print(res.json())

주문처럼 파라미터가 붙는 요청에서는 query_hash와 query_hash_alg를 payload에 함께 넣습니다. 업비트 공식 인증 문서에 언어별 예제가 정리돼 있으니 그대로 옮기는 편이 안전합니다.

바이낸스 — HMAC SHA256 서명

# 바이낸스 서명 요청 (계정 조회)
import time, hmac, hashlib, requests
from urllib.parse import urlencode

API_KEY    = "환경변수로 넣으세요"
API_SECRET = "환경변수로 넣으세요"

params = {"timestamp": int(time.time() * 1000), "recvWindow": 5000}
qs = urlencode(params)
sig = hmac.new(API_SECRET.encode(), qs.encode(), hashlib.sha256).hexdigest()

res = requests.get(
    "https://api.binance.com/api/v3/account?" + qs + "&signature=" + sig,
    headers={"X-MBX-APIKEY": API_KEY},
    timeout=10,
)
print(res.status_code, res.headers.get("X-MBX-USED-WEIGHT-1m"))

바이낸스는 timestamp가 서버 시간과 recvWindow 이상 벌어지면 요청을 거부합니다. 서버 시계가 틀어져 있으면 코드가 멀쩡해도 전부 실패하므로, 클라우드 서버에 올릴 때 NTP 동기화를 확인해야 합니다. 이건 업비트에는 없는 장애 유형입니다.

난이도만 놓고 보면 둘 다 “라이브러리 없이 맨손으로 짜면 반나절” 수준입니다. 다만 실패했을 때 원인을 찾는 난이도는 다릅니다. 업비트는 인증 실패가 query_hash 한 곳에 몰려 있고, 바이낸스는 서명·시계·가중치 셋으로 흩어집니다.

기준④ 요청 수 제한 — 포켓이냐 IP냐

봇이 죽는 가장 흔한 이유가 요청 수 제한입니다. 두 거래소는 세는 단위 자체가 다릅니다.

업비트에서 눈여겨볼 건 포켓 단위라는 점입니다. 같은 포켓 안의 여러 API Key는 한도를 같이 씁니다. 반대로 포켓이 다르면 한도가 독립적이라, 업비트 공식 문서는 메인포켓 1개와 서브포켓 5개가 각각 exchange.default(초당 30회)를 쓰면 계정 전체로는 초당 최대 180회까지 처리할 수 있다고 설명합니다. 개별 포켓 한도는 그대로 30회입니다.

바이낸스 쪽 함정은 418입니다. 429를 무시하고 계속 때리면 IP 밴으로 넘어가고, 응답에 Retry-After가 실려 옵니다. 밴이 걸리면 그 서버의 봇 전체가 멈추므로 재시도 로직에 지수 백오프가 반드시 필요합니다. 자세한 계산법은 바이낸스 API 요청 제한과 IP 밴에 정리해 뒀습니다.

기준⑤ 연습할 서버가 있는가

이 항목은 “처음 만드는 사람”에게 생각보다 크게 작용합니다.

바이낸스는 testnet.binance.vision이라는 스팟 테스트넷을 별도 운영합니다. 별도 키를 발급받아 가짜 잔고로 실제 주문 흐름을 끝까지 돌려볼 수 있습니다. 봇 개발에서 가장 무서운 구간이 “주문이 진짜 나가는 첫 순간”인데, 그걸 돈 없이 통과할 수 있습니다. 발급 절차와 선물 쪽 Demo Mode 차이는 바이낸스 테스트넷 API 발급에 정리해 뒀습니다.

업비트에는 이에 해당하는 모의투자 서버가 없습니다. 그래서 실무에서는 이렇게 갑니다.

1. 페이퍼 모드를 직접 만든다 — 주문 함수만 “로그만 남기고 실제로는 안 보냄” 모드로 스위치. 견적서에 한 줄 넣으면 되는 정도의 작업입니다.
2. 최소 주문 금액으로 실계좌 검증 — 업비트 원화 마켓의 최소 주문 금액 수준으로 며칠 돌려 체결·잔고·재시도 경로를 확인합니다.
3. 그다음 금액을 올린다 — 단계 구성은 주식 봇과 다르지 않습니다.

기준⑥ 선물·레버리지를 다룰 것인가

바이낸스를 고르는 이유의 상당수가 선물입니다. 그런데 코인 자동매매 프로그램 제작 관점에서 선물은 같은 봇의 확장이 아니라 다른 봇에 가깝습니다. 붙어야 할 게 이만큼 늘어납니다.

• 포지션 조회와 청산가 계산 — 현물에는 아예 없는 개념입니다
• 레버리지·마진 모드 설정 API
• 펀딩비 수취/지급 반영
• 강제 청산 시 알림과 비상 정지(킬 스위치)

업비트는 현물 중심이라 이 갈래가 통째로 없습니다. 견적이 낮게 나오는 이유이기도 하고, 사고 규모가 구조적으로 작은 이유이기도 합니다.

기준⑦ 만들어 줄 사람을 구하기 쉬운가

비개발자에게는 이게 은근히 중요합니다. 라이브러리와 자료가 두꺼울수록 제작 기간이 짧고, 나중에 다른 사람에게 유지보수를 넘기기도 쉽습니다.

업비트 개발자 센터는 문서 색인을 llms.txt로도 공개하고 있어서, 스펙을 대조할 때 사람이든 도구든 원문을 바로 가져올 수 있습니다. 이건 “블로그 글을 보고 짐작해서 만드는” 상황을 줄여 줍니다. 제작 의뢰 시 “스펙은 공식 문서 원문으로 대조한다”는 조건을 넣을 수 있다는 뜻이기도 합니다.

바이낸스는 영어 문서가 방대하고 정확하지만 스팟·선물·마진이 체계부터 갈라져 있어 처음에는 길을 잃기 쉽습니다.

그래서 어떻게 정하나 — 시나리오 3개

시나리오 A — 코인 자동매매가 처음이고, 원화만 넣을 계획

업비트 현물. 원화 마켓에서 KRW-BTC 같은 심볼로 시작하고, 출금 권한 없는 API Key를 발급합니다. 페이퍼 모드를 명세서에 넣고, 최소 주문 금액으로 2주 이상 돌린 다음 금액을 올립니다. 첫 전략은 복잡할 필요가 없습니다. 규칙이 단순해야 로그를 보고 뭐가 틀렸는지 알 수 있습니다.

시나리오 B — 이미 코인을 들고 있고, 넣기 전에 충분히 리허설하고 싶다

바이낸스 스팟 + 테스트넷. testnet.binance.vision에서 주문·체결·재시도까지 전부 통과시킨 뒤 실계좌 키로 바꿉니다. 이때 요청 가중치 로깅(X-MBX-USED-WEIGHT-1m)을 처음부터 남겨 두면 나중에 418을 피할 수 있습니다. 선물은 이 단계에서 붙이지 않습니다.

시나리오 C — 국내와 해외를 둘 다 쓸 계획

거래소 어댑터를 나누는 구조. 시세 조회와 공통 흐름은 ccxt로 묶되, 주문·잔고·요청 제한은 거래소별로 분기합니다. 업비트는 포켓 단위 초당 제한, 바이낸스는 IP 단위 분당 가중치라 스로틀러를 하나로 쓸 수 없기 때문입니다. 이 구조는 제작 비용이 1.5배 이상 늘어나므로, 정말 둘 다 필요한지부터 확인하십시오. 대부분은 아닙니다.

제작을 맡길 때 명세서에 적을 7줄

견적이 두 배씩 벌어지는 건 대개 아래가 비어 있어서입니다. 이 일곱 줄만 채워 보내도 비교 가능한 견적이 돌아옵니다.

1. 거래소 — 업비트인지 바이낸스인지, 둘 다인지
2. 상품 범위 — 현물만인지 선물까지인지 (선물이면 청산·레버리지 처리 포함 여부 명시)
3. 실행 위치 — 내 PC인지 클라우드 서버인지, 허용 IP를 어디로 고정할지
4. 대상 종목 — 고정 몇 개인지, 거래대금 기준으로 자동 선정인지 (유니버스 필터 참고)
5. 페이퍼 모드 — 실제 주문을 내지 않는 검증 모드 포함 여부
6. 알림과 안전장치 — 텔레그램 알림, 일일 손실 한도, 킬 스위치
7. 키 관리 — 앱키·시크릿을 누가 보관하고 어떻게 전달할지 (개발은 권한 최소 키로)

견적이 어떻게 산출되는지는 자동매매 제작 비용·견적 가이드에, 직접 만들지 맡길지의 판단 기준은 직접 개발 vs 외주 제작에 정리해 뒀습니다. 코인과 주식 중 어디서 시작할지 아직 안 정했다면 주식 vs 코인 자동매매 입문을 먼저 보십시오.

정리

코인 자동매매 프로그램 제작에서 업비트와 바이낸스를 가르는 건 수수료가 아니라 원화 경로 · 키 발급 조건 · 인증 방식 · 요청 제한 단위 · 연습 서버 · 선물 취급 · 자료의 두께 일곱 가지입니다. 첫 봇이고 원화만 쓴다면 업비트, 실계좌 전에 끝까지 리허설하고 싶다면 바이낸스가 기본값이고, 둘 다는 정말 필요할 때만입니다.

어느 쪽이든 공통 원칙 셋은 같습니다. 출금 권한은 넣지 않는다. 허용 IP를 고정한다. 소액으로 먼저 돌린다.