[자동 매매] 프롤로그

왜 자동매매를 하려 하는가?

투자를 하다 보면 누구나 알게 됩니다. 인간은 나약한 존재라, 공포에 손절하고, 탐욕에 추격매수를 하며, 순간의 감정에 휘둘려 원래 세웠던 원칙조차 쉽게 무너뜨리곤 합니다. 

 

그래서 내린 결론은 하나였습니다. 감정을 배제하고, 오직 숫자와 지표만으로 매매하자. 하지만 주식 시장을 살펴보니 개인 투자자들이 활용할 수 있는 API 환경은 생각보다 열악했습니다. 실시간 데이터 접근은 제한적이고, 자동매매를 위한 인프라도 부족했죠. 반면, 코인 시장은 달랐습니다. 특히 업비트(Upbit)는 비교적 자유롭게 데이터를 다룰 수 있는 API를 제공해, 제가 추구하는 ‘지표 기반 자동매매’를 실험하기에 최적의 환경이었습니다.

 

 

개발 언어 선택

자동매매 시스템을 만들 때 가장 먼저 고민한 건 언어였습니다. Node.js나 Go 같은 대안도 있지만, 결국 Python을 선택했습니다. 이유는 간단합니다. 금융/투자 관련 라이브러리가 압도적으로 많고 (pandas, numpy, ta 등), 실제로 업비트 자동매매 예제나 레퍼런스도 대부분 Python 기반이며, 빠른 개발 속도와 커뮤니티 지원까지 고려하면 안정성과 생산성 모두 확보할 수 있기 때문입니다.

 

성능 면에서는 Go나 Rust 기반이 더 나을 수 있지만, 이번 프로젝트의 핵심은 초단타 HFT(high frequency trading)가 아니라 “안정적인 전략 실행”이기 때문에 Python이 가장 합리적이라고 생각했습니다. 

 

 

실행 방식 고민: exe vs 웹

처음엔 그냥 exe 프로그램으로 만들까 했습니다. 더블클릭으로 실행하면 끝이니까요. 그런데 생각해보니 걸리는 부분이 하나 있었습니다. 바로 UI(User Interface)였습니다. exe로 만들면 결국 내가 원하는 정보를 눈으로 보기 좋게 띄워야 하는데, 이게 의외로 일이 큽니다. 주문 현황, 지표 값, 수익률 로그 같은 걸 다 GUI로 표현하려면 PyQt나 Tkinter 같은 라이브러리를 붙여야 하고, 그 순간 개발 난이도가 확 올라갑니다.

 

반면, 웹으로 만들면 UI는 브라우저가 다 해결해줍니다. HTML/CSS만 얹어도 표, 그래프, 버튼 같은 것들을 훨씬 손쉽게 구현할 수 있고, 추가로 React 같은 프론트엔드를 붙이면 확장성도 좋아집니다. 결국 “내가 보기 편한 화면”을 만드는 데는 웹이 훨씬 낫다고 판단했습니다.

 

 

웹 프레임워크: FastAPI 선택

그렇다고 해서 이걸 거창하게 서버에 배포하겠다는 건 아닙니다. 사실상 로컬에서 돌리면서 제가 확인할 수 있는 수준이면 충분합니다. 다만 웹으로 만들어두면 UI 구현이 쉬워지고, 나중에 원한다면 서버로 배포하는 것도 어렵지 않다는 게 장점입니다.

 

또한, 업비트 API를 사용하기 위해서는 API Key가 필요하고, IP도 등록해놔야 하기 때문에 보안상 문제로라도 굳이 배포할 필요가 없을 것 같기두 하구요. 제공하는 기능인지는 모르겠지만, 입출금 API를 막아두면 보안 문제가 확 줄어들 수는 있긴 하지만 기본적으로 자산이 움직이는 거니까요. 

 

FastAPI를 선택 이유는 비동기(async) 지원(실시간 체결 데이터(WebSocket))와 경량 + 확장성에 있습니다. 즉, “exe로 가면 UI 구현 때문에 귀찮아진다 → 웹이 훨씬 간단하다 → 그중에서도 FastAPI가 제일 맞는다”라는 결론에 도달한 겁니다.

 

이번 프로젝트의 기간은 추석 연휴 전까지로 잡았습니다. 8~9월은 시장이 흔들리고 조정장이 자주 오는 시기라, 오히려 이때는 전략을 점검하고 시스템을 준비하기 좋습니다. 그리고 진짜 목적은 단순합니다. 10월, 시장이 다시 살아날 때 제대로 먹어보자는 겁니다.

 

다음 글에서는 개발 환경 세팅과 업비트 API 연동 과정을 정리할 예정입니다. 이번 글은 말 그대로 준비 단계였고, 이제부터 본격적으로 코드와 전략 이야기를 풀어나가겠습니다.