자동매매 봇을 만들다 보면, 어느 순간 이런 생각이 든다.

“내가 만든 이 코드… 대체 어떤 구조로 돌아가고 있는 거지?”

진입 조건 짜고, 청산 로직 붙이고, 백테스트 돌리는 건 재밌다. 그런데 그 위아래로 감싸고 있는 것들 — 실행 루프, 배포, 모니터링 — 이런 걸 뭐라 불러야 하는지, 어떻게 바라봐야 하는지는 막상 정리해본 적이 없었다.

그래서 한번 정리해봤다. 같은 시스템을 다른 각도로 바라보는 렌즈들을.

프레임워크 — “네 코드를 내가 호출해줄게”

처음엔 프레임워크가 뭔지 감이 안 왔다. 라이브러리랑 뭐가 다른 건데?

레고로 비유하니까 바로 이해됐다.

핵심 차이는 주도권이다. 이걸 멋있는 말로 IoC(Inversion of Control, 제어의 역전)라고 부른다.

트레이딩 봇에서 프레임워크란 뭘까? 바로 이런 거다:

이 실행 루프 자체가 프레임워크다. 전략 로직(언제 사고 팔지)은 이 뼈대 안에 끼워 넣는 블록일 뿐이다. 새로운 진입 필터를 추가하고 싶으면? 프레임워크가 정해둔 자리에 블록 하나 끼우면 된다.

하네스 — 엔진을 감싸는 운전석

프레임워크가 자동차 엔진이라면, 하네스는 운전석 + 계기판 + 안전벨트다.

엔진이 아무리 좋아도 운전석이 없으면 차를 몰 수 없다. 마찬가지로, 전략 로직이 아무리 훌륭해도 이걸 서버에 올리고, 죽으면 재시작하고, 상태를 모니터링하는 장치가 없으면 실전에서 쓸 수가 없다.

봇을 만들 때 전략에만 집중하기 쉽다. 그런데 실전에서는 하네스의 완성도가 안정성을 결정한다. 봇이 조용히 죽어있는데 알림이 안 온다면? 배포했는데 문제가 생겨서 되돌리고 싶은데 방법이 없다면? 이런 게 전부 하네스 영역이다.

에이전트 관점 — 내 봇은 얼마나 똑똑한가

요즘 AI 에이전트가 화두인데, 가만 생각해보면 트레이딩 봇도 에이전트다. 환경을 관찰하고(시세 데이터), 판단하고(시그널 계산), 자율적으로 행동하니까(주문 실행).

에이전트의 자율성에는 단계가 있다:

대부분의 퀀트 트레이딩 봇은 L1~L2 수준이다. 그리고 이건 의도적인 선택이다.

왜? 트레이딩에서는 “똑똑한 봇”보다 “예측 가능한 봇”이 더 안전하기 때문이다. L3 이상으로 올라가면 봇이 스스로 전략을 바꿔버릴 수 있고, 그 순간 개발자도 봇이 왜 그런 결정을 했는지 설명하기 어려워진다. 자는 동안 봇이 전략을 바꿔서 계좌를 날렸다면? 끔찍한 시나리오다.

프론트엔드 / 백엔드 — 식당의 홀과 주방

웹 개발에서 익숙한 이 구분, 트레이딩 봇에도 적용된다.

트레이딩 봇의 특징은 백엔드 비중이 99%라는 점이다. 웹 서비스처럼 화려한 UI가 필요 없다. 텔레그램으로 /status 치면 상태 나오고, 스프레드시트에서 거래 기록 보면 그걸로 충분하다. 주방이 핵심인 집밥 같은 거다.

전체 그림 — 같은 시스템, 다른 렌즈

여기까지 정리하고 보니, 결국 이 개념들은 전부 같은 시스템을 다른 각도에서 바라보는 렌즈였다.

전략 로직에만 집중하면 나무만 보게 된다. 이런 렌즈들을 갖고 있으면 숲 전체를 조망할 수 있고, 어디가 취약하고 어디를 개선해야 하는지 체계적으로 파악할 수 있다.

공유의 경계 — 어디까지 열고, 어디까지 닫을까

마지막으로, 한 가지 더 생각해봤다. 이런 아키텍처를 공유해도 될까?

소프트웨어 아키텍처를 GitHub에 올려 공유하는 이유는 단순하다. 바퀴를 매번 새로 만들 필요가 없으니까. 거래소 API 연동 라이브러리(ccxt), 데이터 처리(pandas) 같은 건 이미 잘 만들어진 바퀴를 가져다 쓰는 거다.

하지만 트레이딩 전략은 얘기가 다르다. 전략이 공개되면 같은 시그널로 같은 타이밍에 진입하는 사람이 많아지고, 결국 알파(edge)가 사라진다.

그래서 나는 이런 경계를 두기로 했다:

개발기를 공유하면서 신뢰를 쌓고, 핵심 엣지는 지킨다. 이 균형이 퀀트 개발자에게 가장 현실적인 전략이 아닐까.