오픈소스 자동매매 봇 5종 비교 — 국내 주식이 안 되는 이유
ccxt에 맡기는 구조인데 ccxt 지원 목록에 키움증권·한국투자증권(KIS)·LS증권이 없기 때문입니다. 그래서 코인은 오픈소스로 바로 시작할 수 있지만, 국내 주식은 증권사 REST API를 직접 붙이거나 python-kis·mojito2 같은 별도 래퍼를 써야 합니다.
"자동매매 프로그램을 만들고 싶은데 오픈소스 중에 쓸 만한 게 있나요?" — 상담에서 자주 받는 질문입니다. 검색하면 GitHub 별 수천 개짜리 프로젝트가 줄줄이 나오고, 전부 무료라고 적혀 있습니다. 그런데 막상 받아서 열어 보면 대부분 며칠 안에 같은 벽에서 멈춥니다.
그 벽은 코드 실력도, 서버 비용도 아닙니다. 내가 거래하려는 시장이 그 프로그램의 지원 범위 밖이라는 것입니다. 이 글은 대표적인 오픈소스 트레이딩 봇 다섯 개를 언어·라이선스·지원 시장·전략 표현 방식으로 비교하고, 국내 주식을 하려는 분에게 실제로 남는 선택지가 무엇인지 정리합니다.
목차
- 왜 대부분 여기서 멈추나 — ccxt라는 경계선
- 오픈소스 봇 5종 한 표 비교
- Freqtrade — 가장 널리 쓰이는 표준
- Hummingbot·Jesse·OctoBot·NautilusTrader
- 국내 주식은 무엇을 쓰나 — 실제로 남는 3가지
- 라이선스 — GPL-3.0이 실제로 걸리는 지점
- 오픈소스로 갈까, 만들까 — 판단표
- 자주 묻는 질문
1. 왜 대부분 여기서 멈추나 — ccxt라는 경계선
오픈소스 트레이딩 봇의 구조는 거의 같습니다. 전략 계층(내 매매 규칙) → 봇 엔진(주문 관리·포지션 추적·백테스트) → 거래소 어댑터(실제 API 호출)의 3층입니다. 그리고 맨 아래 거래소 어댑터를 대부분 직접 만들지 않고 ccxt라는 공통 라이브러리에 위임합니다.
ccxt는 100개 이상의 암호화폐 거래소를 하나의 인터페이스로 묶은 라이브러리입니다. 바이낸스(Binance)·바이비트(Bybit)·업비트(Upbit)·빗썸(Bithumb)·OKX·HTX 모두 같은 함수 이름으로 부를 수 있습니다. 봇 입장에서는 거래소가 바뀌어도 설정 한 줄만 고치면 되니 대단히 편합니다.
문제는 ccxt가 다루는 대상이 "암호화폐 거래소"로 한정된다는 것입니다. 키움증권 OpenAPI·한국투자증권 KIS REST API·LS증권 xingAPI는 이 목록에 들어 있지 않습니다. 국내 증권사 API는 인증 방식(appkey/appsecret 발급 → access_token 캐싱), 요청 구분자(tr_id), 계좌 체계(CANO·ACNT_PRDT_CD), 장 운영 시간, 세금·수수료 처리가 암호화폐 거래소와 근본적으로 다르기 때문입니다.
실제로 ccxt가 어떤 거래소를 아는지는 코드 한 줄로 확인할 수 있습니다.
import ccxt
print(len(ccxt.exchanges)) # 100 이상
print('binance' in ccxt.exchanges) # True
print('upbit' in ccxt.exchanges) # True
print('bithumb' in ccxt.exchanges) # True
print('kiwoom' in ccxt.exchanges) # False ← 키움증권
print('kis' in ccxt.exchanges) # False ← 한국투자증권
여기서 갈립니다. 코인을 하려는 분에게 오픈소스 봇은 진짜로 쓸 만한 출발점입니다. 반대로 국내 주식을 하려는 분에게는 "좋은 프로그램을 고르는 문제"가 아니라 "어댑터를 누가 만드느냐의 문제"가 됩니다. 아래 비교표를 볼 때 이 구분을 먼저 정해 두시면 시간을 아낄 수 있습니다.
2. 오픈소스 봇 5종 한 표 비교
| 이름 | 언어 | 라이선스 | 지원 시장 | 강점 | 국내 주식 |
|---|---|---|---|---|---|
| Freqtrade | Python | GPL-3.0 | 암호화폐 (ccxt) | 사실상 표준. 백테스트·하이퍼옵트·텔레그램 제어 내장 | ✕ |
| Hummingbot | Python | Apache-2.0 | 암호화폐 CEX+DEX | 마켓메이킹 특화, 커넥터 수가 가장 많음 | ✕ |
| Jesse | Python | MIT | 암호화폐 | 백테스트 정확도 중시, 문법이 단순 | ✕ |
| OctoBot | Python | GPL-3.0 | 암호화폐 | 웹 UI 제공, 입문자 진입장벽 낮음 | ✕ |
| NautilusTrader | Rust + Python | 오픈소스(저장소 확인) | 암호화폐 중심, 어댑터 확장형 | 이벤트 기반·고성능, 어댑터를 직접 붙이는 설계 | △ |
표의 마지막 열이 이 글의 결론입니다. 다섯 중 넷은 국내 주식이 아예 대상이 아니고, NautilusTrader만 "어댑터를 직접 구현하면 가능한 설계"라서 세모입니다. 세모는 가능하다는 뜻이지 준비돼 있다는 뜻이 아닙니다 — 키움 REST API나 KIS용 어댑터를 직접 작성해야 하고, 그 작업량이 봇을 처음부터 만드는 것과 크게 다르지 않습니다.
수치 표기에 대해 — GitHub 별 개수, 지원 거래소 수, 버전은 자료마다 다르고 매달 바뀝니다. 이 글에서는 바뀌지 않는 구조적 특성(언어·라이선스·지원 시장·설계 방식)만 비교했습니다. 별 개수나 최신 버전이 필요하시면 각 프로젝트의 GitHub 저장소를 직접 확인하시기 바랍니다.
3. Freqtrade — 가장 널리 쓰이는 표준
다섯 중 하나만 본다면 Freqtrade입니다. 암호화폐 자동매매에서 사실상 공통 언어에 가깝고, 백테스트·파라미터 최적화·텔레그램 원격 제어가 하나의 도구 안에 다 들어 있습니다. Docker 기준 시작 흐름은 이렇습니다.
# 작업 디렉터리 + 사용자 데이터 구조 생성
docker compose run --rm freqtrade create-userdir --userdir user_data
# 설정 파일 대화형 생성 → user_data/config.json
docker compose run --rm freqtrade new-config --config user_data/config.json
# 과거 데이터 내려받기
docker compose run --rm freqtrade download-data \
--exchange binance --pairs BTC/USDT ETH/USDT -t 1h
# 백테스트
docker compose run --rm freqtrade backtesting \
--config user_data/config.json \
--strategy SampleStrategy -i 1h --export trades
설정은 user_data/config.json 한 파일에 모입니다. 거래소를 바꾸는 것이 정말로 값 몇 개를 고치는 일입니다.
{
"max_open_trades": 3,
"stake_currency": "USDT",
"stake_amount": 100,
"dry_run": true,
"exchange": {
"name": "binance",
"key": "",
"secret": "",
"pair_whitelist": ["BTC/USDT", "ETH/USDT"]
},
"telegram": { "enabled": false }
}
"dry_run": true를 절대 먼저 끄지 마십시오. Freqtrade의 dry-run은 실제 시세를 받되 주문만 모의로 처리하는 모드입니다. 알고랩이 제작 납품 시에도 모의 → 소액 실전 → 정상 운영의 3단계 검증을 그대로 밟습니다. 백테스트가 좋았다는 이유로 곧장 실계좌를 붙이는 것이 사고의 1순위 원인입니다.
전략은 user_data/strategies/ 아래에 파이썬 클래스로 넣습니다. pandas 데이터프레임을 받아 매수·매도 신호 컬럼을 채우는 방식이라, 지표 기반 전략이면 표현이 어렵지 않습니다.
from freqtrade.strategy import IStrategy
from pandas import DataFrame
import talib.abstract as ta
class MyRsiStrategy(IStrategy):
timeframe = '1h'
minimal_roi = {"0": 0.05}
stoploss = -0.10
def populate_indicators(self, dataframe: DataFrame, metadata: dict) -> DataFrame:
dataframe['rsi'] = ta.RSI(dataframe, timeperiod=14)
return dataframe
def populate_entry_trend(self, dataframe: DataFrame, metadata: dict) -> DataFrame:
dataframe.loc[dataframe['rsi'] < 30, 'enter_long'] = 1
return dataframe
여기서 오해가 자주 생깁니다. 이 구조가 잘 맞는 것은 "캔들 마감마다 지표를 보고 판단하는 전략"입니다. 호가창 잔량을 보고 반응하거나, 여러 종목을 실시간 순위로 갈아타거나, 체결 강도로 진입하는 전략은 이 틀에 잘 안 들어갑니다. 오픈소스 봇의 진짜 제약은 거래소 지원 범위와 전략을 표현할 수 있는 형태 두 가지입니다.
4. Hummingbot·Jesse·OctoBot·NautilusTrader
Hummingbot — 마켓메이킹이 목적이면
Apache-2.0 라이선스이고, 중앙화 거래소(CEX)와 탈중앙 거래소(DEX)를 아우르는 커넥터 수가 가장 많은 축입니다. 설계 목적이 호가를 양쪽에 걸어 스프레드를 먹는 마켓메이킹이라, 방향성 추세 전략을 넣으려면 Freqtrade보다 손이 더 갑니다. 반대로 호가·체결 단위의 집행 로직을 다루려는 분에게는 참고 가치가 큽니다.
Jesse — 백테스트를 신뢰하고 싶다면
MIT 라이선스라 라이선스 부담이 가장 적습니다. 전략 문법이 간결하고 백테스트 정확도(미래 데이터가 새어 들어가는 문제를 막는 것)를 강조하는 프로젝트입니다. 다만 백테스트 도구가 정확해도 파라미터를 반복해서 맞춘 결과는 여전히 과최적화입니다. 도구가 막아 주는 것은 구현 오류이지 방법론 오류가 아닙니다.
OctoBot — 코드를 덜 쓰고 싶다면
웹 UI가 있어 진입장벽이 가장 낮습니다. 다만 UI로 되는 범위를 넘어가면 결국 파이썬으로 내려가야 하고, 라이선스가 GPL-3.0입니다. UI 기반 도구 전반의 한계선은 노코드·GUI 자동매매가 어디까지 되는지에 정리해 두었습니다.
NautilusTrader — 성능과 확장성
Rust로 짠 코어에 파이썬 API를 얹은 이벤트 기반 플랫폼입니다. 다섯 중 유일하게 어댑터를 붙여 시장을 넓히는 것을 전제로 설계돼 있어, 이론상 국내 증권사도 붙일 수 있습니다. 그러나 그 어댑터에는 access_token 갱신, tr_id 분기, WebSocket 실시간 체결 수신, 호출 제한 대응이 전부 들어가야 합니다. 즉 가장 어려운 부분이 그대로 남습니다.
5. 국내 주식은 무엇을 쓰나 — 실제로 남는 3가지
코인이 아니라 국내 주식이라면 선택지는 오픈소스 "봇"이 아니라 오픈소스 "라이브러리"로 바뀝니다. 셋 중 하나입니다.
① 증권사 REST API를 직접 호출
가장 통제력이 높고, 스펙이 바뀌어도 내가 고칠 수 있습니다. KIS는 appkey·appsecret으로 access_token을 받고, 요청마다 tr_id로 무슨 거래인지 지정합니다.
import requests
BASE = "https://openapi.koreainvestment.com:9443" # 실전
res = requests.post(f"{BASE}/oauth2/tokenP", json={
"grant_type": "client_credentials",
"appkey": APP_KEY,
"appsecret": APP_SECRET,
})
token = res.json()["access_token"] # 유효기간 24시간 → 캐싱 필수
응답이 실패하면 아래처럼 rt_cd·msg_cd로 원인이 찍힙니다. 자동매매에서 가장 흔한 것이 호출 초과입니다.
{
"rt_cd": "1",
"msg_cd": "EGW00201",
"msg1": "초당 거래건수를 초과하였습니다."
}
이런 코드가 어디서 왜 나오는지는 KIS API 에러코드 11가지에, 애초에 한도 안에서 돌게 설계하는 방법은 API 호출 제한 설계에 정리돼 있습니다. 발급부터 첫 주문까지의 전체 흐름은 KIS API 발급 30분 완성을 보시면 됩니다.
② 국내 래퍼 라이브러리 사용
한국투자증권용으로는 python-kis, mojito2 같은 파이썬 래퍼가 공개돼 있습니다(설치 이름과 임포트 이름이 다른 경우가 있으니 저장소 안내를 확인하십시오). 암호화폐 쪽은 업비트용 pyupbit, 빗썸용 pybithumb이 널리 쓰입니다. 키움 REST API도 개인 개발자가 만든 래퍼가 여럿 있습니다.
래퍼는 개인·소규모 프로젝트라는 점을 감안하십시오. 증권사가 스펙을 바꾸면 래퍼 업데이트가 늦어질 수 있고, 그 사이 내 봇은 멈춥니다. 실계좌를 맡길 코드라면 래퍼가 최근에도 유지보수되고 있는지, 문제가 생겼을 때 원본 API로 내려가 직접 고칠 수 있는지를 먼저 확인해야 합니다.
③ 백테스트만 오픈소스로
실매매는 증권사 API로 직접 하고, 전략 검증만 오픈소스 도구를 쓰는 조합이 현실적으로 가장 많습니다. backtrader·vectorbt는 거래소와 무관하게 pandas 데이터프레임만 있으면 돌아가므로 국내 주식 데이터에도 그대로 쓸 수 있습니다. 어떤 걸 고를지는 백테스팅 파이썬 라이브러리 5종 비교에 정리해 두었습니다.
6. 라이선스 — GPL-3.0이 실제로 걸리는 지점
무료라는 말과 마음대로 써도 된다는 말은 다릅니다. 다섯 프로젝트의 라이선스가 갈리는 지점은 "고쳐서 남에게 주느냐" 하나입니다.
| 상황 | GPL-3.0 (Freqtrade·OctoBot) | Apache-2.0 / MIT (Hummingbot·Jesse) |
|---|---|---|
| 내 계좌로 내가 돌림 | 문제 없음 (배포가 아님) | 문제 없음 |
| 고쳐서 사내에서만 씀 | 문제 없음 | 문제 없음 |
| 고친 것을 배포·판매 | 파생물도 GPL-3.0으로 소스 공개 의무 | 고지 조건만 지키면 비공개 가능 |
개인이 자기 계좌를 돌리는 용도라면 GPL-3.0도 걸리지 않습니다. 반대로 "이 봇을 개조해서 남에게 팔아 보겠다"가 목적이라면 라이선스를 먼저 읽어야 합니다. 제작을 의뢰하는 경우에도 결과물의 권리 관계는 미리 정하는 편이 낫습니다(아래 관련 글의 소스코드 소유권·에스크로 편에 계약 관점으로 정리해 두었습니다).
라이선스 조건은 프로젝트가 변경할 수 있습니다. 실제 판단이 필요하면 해당 저장소의 LICENSE 원문을 직접 확인하시기 바랍니다.
7. 오픈소스로 갈까, 만들까 — 판단표
| 내 상황 | 권장 | 이유 |
|---|---|---|
| 바이낸스·바이비트에서 지표 기반 전략 | Freqtrade 직접 | 지원 범위 안. 배우는 시간이 곧 자산 |
| 업비트·빗썸 원화 마켓, 코드 경험 있음 | Freqtrade 또는 pyupbit 직접 | ccxt 지원. 다만 원화 마켓 특성 확인 필요 |
| 국내 주식(키움·KIS) | 증권사 API 직접 또는 제작 | 오픈소스 봇 지원 범위 밖 |
| 호가창·체결강도·실시간 순위 전략 | 제작 | 캔들 기반 전략 클래스로 표현이 안 됨 |
| 24시간 무중단·장애 알림이 필수 | 제작 또는 운영 대행 | 오픈소스는 프로그램만 줄 뿐 운영은 남음 |
정리하면 오픈소스가 무료로 주는 것은 "주문 실행과 백테스트의 골격"이고, 남는 것은 내 전략 로직·증권사 연동·24시간 운영·장애 복구입니다. 코인에서 표준 지표 전략을 돌린다면 남는 몫이 작아 직접 쓰는 게 낫고, 국내 주식이거나 전략이 표준에서 벗어나면 남는 몫이 대부분이라 판단이 달라집니다. 증권사별 API 비교와 키움 REST API 가이드를 먼저 훑어보시면 어느 쪽인지 금방 감이 옵니다.
8. 자주 묻는 질문
Freqtrade로 국내 주식 자동매매가 되나요?
되지 않습니다. Freqtrade는 거래소 연결을 ccxt에 위임하는데 ccxt는 암호화폐 거래소만 지원합니다. 키움증권·한국투자증권(KIS)·LS증권은 목록에 없습니다. 국내 주식은 증권사 REST API를 직접 붙이거나 python-kis·mojito2 같은 별도 래퍼를 써야 합니다.
오픈소스 자동매매 봇은 무료인데 왜 제작을 의뢰하나요?
프로그램 값이 아니라 붙이는 값이기 때문입니다. 오픈소스가 주는 것은 골격이고, 내 전략 로직·국내 증권사 연동·토큰 자동 갱신·호출 제한 대응·장애 복구·24시간 운영은 그대로 남습니다. 그 남는 몫이 작으면 직접 쓰는 게 맞고, 크면 의뢰가 빠릅니다.
GPL-3.0 라이선스 봇을 상업적으로 써도 되나요?
혼자 돌려서 매매하는 것은 배포가 아니므로 GPL-3.0에서도 문제되지 않습니다. 다만 고쳐 만든 프로그램을 남에게 배포·판매하면 파생물도 같은 GPL-3.0으로 소스를 공개해야 합니다. 실제 판단은 저장소의 LICENSE 원문을 확인하십시오.
오픈소스 봇을 쓰면 수익이 보장되나요?
아닙니다. 오픈소스가 제공하는 것은 주문 실행과 백테스트 도구일 뿐 전략의 성과가 아닙니다. 동봉된 예제 전략(SampleStrategy 등)은 동작 확인용이며 수익을 위해 설계된 것이 아닙니다. 백테스트 결과는 과거 데이터에 대한 기록이고 미래 성과를 보장하지 않습니다. 이 글의 도구·라이선스 정보는 작성 시점 기준이므로 각 프로젝트 공식 저장소에서 최신 내용을 확인하시기 바랍니다.
오픈소스 봇으로 시작하려면 무엇부터 확인해야 하나요?
순서대로 셋입니다. ① 내가 거래할 시장이 그 봇의 지원 범위 안인가(암호화폐인가 국내 주식인가). ② 내 전략을 그 봇의 전략 클래스 형식으로 표현할 수 있는가(캔들 신호인가, 호가창 기반인가). ③ 24시간 운영할 서버와 장애 알림을 감당할 수 있는가. 하나라도 아니면 오픈소스 도입 자체가 우회로가 됩니다.
오픈소스로 안 되는 부분만 맡기셔도 됩니다
국내 증권사 API 연동, 전략 로직, 24시간 운영까지 — 어디까지 직접 하시고 어디부터 맡길지부터 같이 정리해 드립니다.
24시간 빠른 답변 가능합니다.