주식과 코인은 API 구조를 다르게 구현합니다
게만아 자동매매 코드는 주식과 코인 모두 “전략과 API 연결을 분리한다”는 원칙은 같지만 실제 구현 방식은 다릅니다. 주식은 멀티브로커 전환 구조, 코인은 거래소별 별도 공통모듈 구조를 사용합니다.
주식: 같은 전략을 여러 증권사·시장·계좌에 연결
공통 인터페이스로 작성된 주식 봇은 전략 코드에서 증권사별 API를 직접 호출하지 않습니다. 먼저 Broker, Market, accountMode를 정한 뒤 해당 모듈을 불러옵니다.
Broker = "KIS" # KIS / DBI / LS / KIW / TOSS / KB / NH / MR
Market = "KR" # KR / US
accountMode = "REAL" # REAL / REAL2 / VIRTUAL 등
Common = importlib.import_module(f"{Broker}_Common")
Helper = importlib.import_module(f"{Broker}_API_Helper_{Market}")
Common.SetChangeMode(accountMode)전략은 그 다음부터 Helper.GetBalance(), GetCurrentPrice(), MakeBuyMarketOrder() 같은 공통 함수를 사용합니다. 즉 전략의 투자 규칙은 유지하고 증권사별 차이는 공통모듈이 담당합니다.
멀티브로커 구조를 그림으로 보면
같은 주식 전략 로직
↓
Broker / Market / accountMode 선택
↓
Common + API_Helper 동적 import
↓
KIS / LS / KIW / TOSS / KB / NH / MR / DBI ...
↓
각 증권사 Open API새 증권사가 추가될 때도 가능하면 전략 파일마다 증권사 전용 코드를 덧붙이는 대신, 기존 공통 함수 규격을 만족하는 Common/Helper 레이어를 추가하는 방향으로 확장합니다.
계좌까지 분리하는 이유
accountMode는 단순 실전/모의 구분뿐 아니라 설정파일에 정의한 추가 계좌를 선택하는 데 활용할 수 있습니다. 같은 증권사에서도 전략별·계좌별로 설정을 나눌 수 있어 한 실행환경(PC 또는 서버)에서 여러 시스템을 운용할 때 관리가 편해집니다.
실제로 사용할 수 있는 모드와 계좌 종류는 각 공통모듈과 사용자의 설정파일 구성에 따라 달라집니다.
코인: 업비트·빗썸·코인원·바이낸스를 각각 별도 구현
코인은 현재 주식처럼 한 파일에서 Exchange 값 하나만 바꾸는 구조가 아닙니다. 업비트, 빗썸, 코인원, 바이낸스 각각의 API 특성에 맞춘 공통모듈과 연결 코드를 따로 둡니다.
업비트 전략/봇 → 공통모듈 → 업비트 API
빗썸 전략/봇 → 공통모듈 → 빗썸 API
코인원 전략/봇 → 공통모듈 → 코인원 API
바이낸스 전략/봇 → 공통모듈 → 바이낸스 API
공통모듈의 실제 파일명은 변경될 수 있으므로 문서에서는 특정 파일명보다 전략·봇 → 공통모듈 → 거래소 API라는 구조를 기준으로 설명합니다.
전략·API 구조와 실행 환경은 서로 분리해서 생각합니다
주식이 멀티브로커인지, 코인이 거래소별 공통모듈인지와 그 Python 파일을 어디서 반복 실행할지는 별개의 문제입니다.
전략 / 봇
↓
공통모듈 + 증권사·거래소 API
↓
실행 환경 선택
├─ Windows / Mac → GMA Runner
└─ AWS / VPS → crontab 등 스케줄러게만아 코드는 한 번 실행해 필요한 작업을 처리하고 종료하는 구조를 많이 사용하므로, 같은 전략을 내 PC의 GMA Runner에서도, 개인 서버의 스케줄러에서도 운용할 수 있습니다. 24시간 안정성·고정 IP가 중요하면 서버가 유리하고, 서버가 진입장벽이라면 PC에서 먼저 시작할 수 있습니다.
왜 코인을 억지로 하나로 합치지 않았나?
| 구분 | 주식 | 코인 |
|---|---|---|
| 지원 구조 | Broker·Market·계좌 선택으로 공통화 | 거래소별 별도 구현 |
| 현재 대상 | 한국투자·LS·키움·토스·KB·NH·메리츠·DB | 업비트·빗썸·코인원·바이낸스 |
| 공통화 | 증권사별 API 차이를 Common/Helper에서 흡수 | 거래소별 공통모듈을 각각 유지 |
| 이유 | 주식의 계좌·시세·주문 공통분모를 활용하기 쉬움 | 인증·symbol·최소주문·정밀도·현물/선물 규칙 차이가 큼 |
좋은 공통화의 목적은 파일 수를 줄이는 것이 아닙니다
좋은 아키텍처의 목적은 무조건 하나로 합치는 것이 아니라 전략의 의도와 API 차이를 안전하게 관리하는 것입니다. 공통화했을 때 단순해지는 영역은 공통화하고, 시장별 차이가 큰 부분은 분리합니다.
이 구조가 게만아 콘텐츠의 확장성을 만듭니다
공통모듈뿐 아니라 전략·백테스트·자동매매 봇·보조시스템까지 서로 역할이 나뉘어 있기 때문에, 완전히 빈 코드에서 다시 시작하지 않고 가장 가까운 기존 코드를 AI와 함께 수정·확장하기 쉽습니다. 새 증권사나 새 API 기능이 필요한 경우에도 기존 공통 함수 규격을 기준점으로 삼을 수 있습니다.
문서 업데이트: 2026-10-13