계좌 리팩토링

1. 고정된 파라미터(Static Parameter)의 한계안녕하세요! 내 계좌를 위한 완벽한 시스템 트레이딩 구축기, [계좌 리팩토링] 시리즈 21편입니다. 텔레그램 리모컨(20편)까지 달아주며 봇은 완벽하게 실전 궤도에 올랐습니다. 그런데 몇 주간 봇을 돌려보니 새로운 고민거리가 생겼습니다."지난주에는 EMA 9와 이격도 3% 설정으로 승률이 70%였는데, 이번 주 횡보장에서는 똑같은 설정으로 계속 휩쏘(거짓 신호)에 당하며 계좌가 녹아내리네?"시장은 살아있는 생물과 같습니다. 어제 통했던 파라미터(설정값)가 오늘은 최악의 독이 될 수 있습니다. 하지만 본업이 있는 직장인 개발자가 매일 퇴근 후 수만 개의 틱 데이터를 뜯어보며 내일 장에 맞게 파라미터를 미세 조정(Tuning)하는 것은 불가능에 가깝..

1. 왜 하필 텔레그램 '양방향' 리모컨인가?안녕하세요! 내 계좌를 위한 자동매매 시스템을 빚어가는 [계좌 리팩토링] 시리즈, 대망의 20편입니다. 지난 시간까지 우리는 봇의 뇌(로직)와 심장(웹소켓), 그리고 한정된 자원을 배분하는 혈관(슬롯 관리 알고리즘)까지 모두 완성했습니다.이제 봇은 클라우드 서버 위에서 24시간 돌아가기 시작했습니다. 하지만 실전 운영에 돌입하면 곧바로 현실적인 장벽에 부딪힙니다. 일반적인 기업 환경, 특히 내부 보안망이 엄격한 비IT 기업 사무실에서는 개인적인 터미널 창이나 화려한 트레이딩 대시보드를 모니터에 하루 종일 띄워두는 것이 현실적으로 불가능합니다.점심시간이나 회의 중간중간, 스마트폰으로 빠르게 봇의 상태를 확인하고 즉각적인 명령을 내릴 수 있는 '무선 리모컨'이 절..

1. 120개의 후보를 40개 슬롯에 욱여넣는 파이프라인안녕하세요! 한정된 자원 속에서 최적의 해답을 찾아가는 [계좌 리팩토링] 시리즈 19편입니다. 지난 18편에서는 증권사 API의 '웹소켓 40개 제한'이라는 거대한 벽을 넘기 위해, 무지성 구독 대신 '선필터링(Pre-filtering)'이라는 전략적 우회로를 기획했습니다.이번 편에서는 그 전략을 실제 코드로 구현하며, 트레이딩 봇의 파이프라인이 어떻게 백엔드 서버의 견고한 아키텍처로 진화하는지 살펴보겠습니다. 목표는 단순합니다. 120개의 방대한 예비 후보군(Pool)을 순회하며, 깐깐한 조건을 통과한 '진짜배기 종목'들만 골라 최대 40개의 VIP 웹소켓 슬롯에 차곡차곡 앉히는 것입니다.let activeWebSockets = 0;// KIS A..

1. 들어가며: 웹소켓의 축복, 그리고 40개의 장벽안녕하세요! 내 계좌를 지키는 견고한 자동매매 시스템, [계좌 리팩토링] 시리즈 18편입니다. 지난 17편에서는 1초의 지연도 허용하지 않기 위해 REST API 폴링 방식을 버리고, 시장의 숨결을 실시간으로 느끼는 웹소켓(WebSocket) 엔진을 도입했습니다.0.1초 단위로 쏟아지는 틱(Tick) 데이터를 보며 "이제 완벽하다!"라고 환호했던 것도 잠시, 저는 증권사(KIS) API가 가진 아주 냉혹하고 현실적인 물리적 제약에 부딪히게 되었습니다. 바로 '웹소켓 최대 연결 수 40개 제한'입니다."전 종목을 다 감시하면서 기회가 올 때마다 낚아채려고 했는데, 고작 40개 종목만 실시간으로 볼 수 있다고?"이 40개라는 숫자는 트레이딩 봇의 구조를 근..

1. 백테스트의 환상, 실전이라는 차가운 현실안녕하세요! 내 계좌를 지키고 불려주는 든든한 파트너, [계좌 리팩토링] 시리즈 17편입니다. 지난 시간까지 우리는 Parker Brooks의 뇌 구조를 시각화한 웹 HTS 시뮬레이터를 만들고, 과거 데이터를 통해 전략(VWAP + EMA 눌림목)을 완벽하게 검증했습니다.수익이 나는 파라미터를 찾았으니, 이제 진짜 돈을 넣고 봇을 돌릴 차례입니다. 그런데 막상 실전 스크립트를 가동하면 백테스트에서는 보지 못했던 치명적인 문제들이 터져 나옵니다. 그중 가장 개발자를 뼈아프게 하는 것은 바로 '데이터 수신 지연과 분봉 정렬의 어긋남'입니다.2. REST API 폴링(Polling) 방식의 치명적 한계초기 자동매매 봇을 만들 때 가장 흔히 하는 실수가 setInte..

1. 텍스트 로그(CLI)가 가진 치명적인 한계안녕하세요! 내 계좌를 위한 자동매매 시스템을 빚어가는 [계좌 리팩토링] 시리즈 16편입니다. 지난 15편에서는 실전과 완벽하게 동일한 로직(evaluateTick)으로 돌아가는 강력한 CLI 기반의 백테스팅 엔진을 완성하고, VWAP와 EMA를 활용한 눌림목 전략을 테스트해 보았습니다.CLI에서 수백 일치의 과거 데이터를 돌리면 '총 거래수 50회, 승률 45%, 순수익 15%' 같은 결과가 터미널에 텍스트로 찍힙니다. 하지만 개발자이자 트레이더로서 우리는 곧 깊은 갈증을 느끼게 됩니다."도대체 이 매매는 왜 여기서 진입한 거지? 수익이 나긴 했는데, 정말 내가 의도한 예쁜 눌림목(Pullback) 자리였나? 아니면 운 좋게 반등한 휩쏘(거짓 신호)였나?"..

1. 봇에게 'Parker Brooks'라는 이름을 지어주다안녕하세요! 내 계좌와 코드를 튼튼하게 다지는 [계좌 리팩토링] 시리즈 15편입니다. 1편부터 지금까지 인프라와 배포 파이프라인을 구축하며 하드웨어적인 뼈대를 완성했다면, 이제는 봇에게 진정한 '두뇌'를 심어줄 차례입니다. 저는 이 고도화된 자동매매 봇 프로젝트에 'Parker Brooks'라는 이름을 붙였습니다.어떤 유튜브를 보다가 파커 브룩스라는 트레이더의 매매 방식을 알게되었습니다.자동매매를 개발하다 보면 필연적으로 이런 질문에 부딪힙니다. "내가 만든 이 매매 로직, 진짜로 돈을 벌어다 줄까?" 실전에서 내 피 같은 돈을 태우기 전에, 과거의 데이터로 수백, 수천 번의 모의고사를 치러보는 백테스팅(Backtesting)은 선택이 아닌 필수..

로컬에서의 성공, 서버에서도 보장할 수 있을까?안녕하세요! 내 계좌를 위한 견고한 시스템을 구축하는 [계좌 리팩토링] 시리즈 14편입니다. 지난 13편에서는 GitHub Actions를 통해 코드를 Push하기만 하면 VRT 테스트가 자동으로 수행되는 세련된 CI/CD 파이프라인을 구축했습니다.테스트도 통과했고, 이제 클라우드 서버(AWS EC2, Oracle Cloud 등)나 집에 있는 미니 PC에 봇을 올려서 24시간 돌릴 일만 남았습니다. 그런데 막상 서버에 접속해서 코드를 받고 실행해 보면, 당황스러운 에러들을 마주하게 됩니다."어? 내 맥북에서는 잘 되는데, 왜 우분투 서버에서는 에러가 나지?""Node.js 버전이 달라서 패키지 설치가 안 되네..."이러한 '내 PC에선 되는데 환경(It wo..

수동 테스트의 늪에서 벗어나, 완벽한 자동화의 세계로안녕하세요! 내 계좌와 코드를 튼튼하게 다지는 [계좌 리팩토링] 시리즈 13편입니다. 지난 12편에서 우리는 Playwright와 Storybook을 활용하여 대시보드 UI의 픽셀 하나까지 방어하는 든든한 VRT(시각적 회귀 테스트) 환경을 구축했습니다.하지만 "테스트 코드를 짜는 것"과 "테스트를 꾸준히 돌리는 것"은 전혀 다른 문제입니다. 바쁘게 기능을 개발하다 보면 깜빡하고 pnpm exec playwright test를 로컬에서 실행하지 않은 채 코드를 원격 저장소에 Push 해버리는 실수가 반드시 발생합니다.그래서 이번 시간에는 우리가 봇의 매매를 자동화했듯이, 테스트와 배포 과정마저 자동화(CI/CD) 해보겠습니다. GitHub 저장소에 코드..

기능이 추가될수록 불안해지는 화면, 어떻게 방어할까?안녕하세요! 내 계좌와 코드를 튼튼하게 다지는 [계좌 리팩토링] 시리즈 12편입니다. 지난 11편에서 우리는 Nuxt를 활용해 봇의 상태를 실시간으로 보여주는 멋진 웹 대시보드를 구축했습니다.앞으로 이 대시보드에는 10편에서 다룬 일목균형표 차트, 호가창 애니메이션, 매매 내역 검색 필터 등 수많은 기능이 추가될 것입니다. 그런데 기능이 늘어날수록 개발자에게는 새로운 두려움이 생깁니다. "새로운 CSS를 한 줄 추가했는데, 어제까지 잘 보이던 잔고 표시 카드 레이아웃이 엉뚱하게 깨지면 어떡하지?"이러한 불안감을 해소하고 UI의 무결성을 보장하기 위해, 이번 시간에는 Playwright와 Storybook을 결합한 시각적 회귀 테스트(VRT, Visual..