매매봇 성과를 한 화면에 모으자 운영 화면이 됐다

자동매매 봇은 주식과 가상화폐를 대상으로 서로 다른 전략을 시험했다. 각 전략은 모의매매를 거쳐 실거래로 순차 전환하려 했기 때문에 모의 단계에 있는 봇과 실거래 중인 봇이 함께 있었다.

각 봇은 정해진 시간에 실행됐지만 결과를 확인하려면 기록을 하나씩 따로 살펴봐야 했다. 텔레그램으로 매수와 매도, 성과까지 받아볼 수 있게 만들었어도 메시지 하나에는 해당 봇의 결과만 담겼다. 전체 자산과 손익을 종합해서 보거나, 어느 봇에 오류가 생겼는지 한 번에 파악하기는 어려웠다.

이번에는 AI가 만든 이야기를 쌓는 대신 이미 존재하는 프로젝트의 데이터를 보여주고 싶었다. 여러 봇의 매매 결과를 한 화면에 모으면 무엇이 정상적으로 움직이고 있는지, 자산과 손익이 어떻게 달라지는지 더 쉽게 확인할 수 있을 것 같았다. 처음부터 홈페이지 연동을 계획했던 것은 아니지만, 이전에 홈페이지를 만들어본 경험이 자연스럽게 대시보드 구상으로 이어졌다. 그렇게 2026년 3월, 두 번째 홈페이지로 자동매매 성과 대시보드를 만들기 시작했다.

여러 봇을 통합한 뒤의 화면에서 가상화폐 전략만 선택한 상태로, 각 봇의 결과를 따로 확인하던 방식을 보여준다.

봇을 하나씩 붙이자 공통 규격이 필요해졌다

성과 대시보드는 각 봇이 하루의 결과를 같은 규격으로 정리해 보내면, 이를 저장한 뒤 전략별 화면에 표시하는 구조였다.

배당주 투자 봇을 처음 연동한 이후 가상화폐 투자 봇, 단기 변동성 투자 봇, 강화학습 매매 봇과 상한가 투자 봇 등 총 6개의 자동매매 봇을 차례로 연결했다. 봇을 붙일수록 공통 규격이 필요하다는 사실이 분명해졌다. 각 봇은 투자 대상과 매매 기간이 달랐다. 특히 가상화폐 봇은 달러를 기준으로 계산한 결과를 보내기 때문에 주식 봇의 원화 자산과 합쳐 보여주려면 환산 기준도 필요했다. 또한 누적 수익과 평균 성과, 종목명, 적용 전략과 거래별 지표 등이 추가됐다. 이후에는 모의매매인지 실거래인지 구분하고, 초기 자본·현금·보유 자산·현재 잔액까지 계속 통합해 나갔다.

숫자를 보여주는 화면에서 운영하는 통합 화면으로 커졌다

각 봇은 정해진 시각에 그날의 기록을 모아 일일 보고를 만들어 대시보드로 보냈다. 대시보드는 받은 내용을 데이터베이스에 저장했고, 사용자가 전략 화면을 열었을 때 일별 결과와 거래 내역을 표로 보여줬다.

화면에 무엇을 추가할지 결정할 때마다 봇이 보내는 데이터도 달라졌다. 대시보드가 요구하는 형식이 바뀌면 봇의 보고 생성 코드까지 함께 수정해야 했다. 필드 이름과 계산 기준을 맞췄다고 생각하면 오류가 났고, 하나를 고치고 나면 다른 곳에서 다시 문제가 생기기 일쑤였다.

단순한 손익 숫자만으로는 봇의 상태를 판단할 수도 없었다. 그 숫자가 모의 환경에서 나온 것인지 실제 계좌에서 나온 것인지 구분해야 했다. 거래가 없던 날에도 봇은 정상적으로 실행됐을 수 있었고, 반대로 보고가 도착하지 않았다면 매매 기회가 없었던 것인지 전송 과정에 문제가 생긴 것인지 확인해야 했다. 그래서 일일 보고에 운용 모드와 자본 상태를 함께 담고, 데이터가 없을 때의 처리와 전송 실패를 구분하는 기능도 만들었다.

생각하지 못했던 예외 처리가 개발 중에 하나씩 추가되면서 처음 의도보다 구조가 훨씬 복잡해졌다. 단순히 성과를 보여주려던 대시보드는 어느새 성과뿐 아니라 운영 상태와 장애까지 확인하는 화면으로 변해갔다. 코드 변경이 잘못된 배포로 이어지지 않도록 자동 검사와 배포 흐름도 연결했다.

이후 추가된 전략까지 표시되도록 화면을 수정했다.

완성된 화면을 PC 밖으로 옮기기

이 작업을 하면서 대시보드의 역할도 분명해졌다. 대시보드는 매매를 실행하는 곳이 아니라 여러 전략의 상태를 한눈에 확인하는 곳이었다. 매매 판단과 주문은 각 봇이 담당하고, 대시보드는 그 결과를 받아 전략별 현황과 거래 기록으로 보여줬다.

모든 데이터가 한 화면에 요약되기 시작했을 때는 완성했다는 생각에 기분이 좋았다. PC에서만 보는 화면으로 남겨두고 싶지 않아 모바일에서도 확인할 수 있도록 다듬었다. 작은 화면에 정보가 자연스럽게 들어가도록 글자 크기와 배경, 카드 배치를 손보는 일까지 신경 쓸 것이 한두 가지가 아니었지만 계속 수정해 나갔다.

모바일에서도 현황을 볼 수 있도록 구성한 화면.

오류가 생길 때마다 수정하는 과정을 반복하면서 또 하나를 깨달았다. AI가 화면과 코드를 만들어줄 수 있어도 ‘무엇을, 어떻게, 왜 연동해야 하는가’를 먼저 정하지 않으면 처음 만드는 시간보다 오류를 고치는 시간이 더 길어질 수 있었다. 기능을 추가하는 것만큼 기획과 결과물의 품질을 점검하는 일이 중요했다.

그때 스스로 정한 원칙은 두 가지였다. 실행하기 전에 먼저 기획하고 계획할 것, 그리고 계획은 수정을 고려해 최대한 잘게 나눌 것. 그래서 이후에는 프로젝트를 시작하기 전에 AI와 계획을 더 구체적으로 정리하고, 개발 단계를 작게 나눈 뒤 단계마다 무엇을 확인할지 규격화하기 시작했다. 당시에는 Skill이라는 개념조차 몰랐지만, 지금 돌아보면 반복해서 사용할 작업 기준을 만들기 시작한 셈이었다.

이 과정을 거쳐 봇이 만든 일일 결과가 대시보드에 자동으로 나타났다. 전략별 화면에서 누적 자산과 최근 손익을 보고 필요하면 거래 기록까지 내려가 확인할 수 있었다. 자동화 블로그에서는 생성된 글이 나와 무관하다는 느낌이 문제였다면, 이 대시보드에 쌓이는 숫자는 내가 실제로 만들고 운영한 프로젝트에서 나온 결과였다.

데이터가 매일 오전 9시에 갱신되도록 해두고 아침마다 대시보드를 열었다. 종합 성과가 전날보다 올랐는지 내렸는지 먼저 보고, 각 봇의 보고가 정상적으로 들어왔는지 확인했다. 예전에는 텔레그램 메시지와 개별 기록을 하나씩 찾아봐야 했지만, 이제는 통합 화면에서 이상한 숫자나 누락된 보고를 발견한 뒤 해당 봇의 기록을 자세히 살펴보는 순서로 확인 방식이 바뀌었다.

이제 화면은 생겼고 데이터도 들어왔다. 다음 질문은 기능이 아니라 그 숫자를 어떻게 받아들여야 하는가에 가까웠다. 대시보드가 정상적으로 작동한다는 사실과 그 안에 표시되는 성과가 만족스럽다는 판단은 같은 일이 아니었다.