시작은 자제력 문제였습니다

빗썸 계좌는 원래 장기투자용이었습니다. 그런데 계속 들여다보게 되더군요. 오르면 팔고 싶고 내리면 더 사고 싶고. 그럴 거면 차라리 규칙을 정해서 코드에 박아놓고 손을 떼자 — 그게 이 봇의 출발점이었습니다. 봇을 만들면 돈을 벌 것 같아서가 아니라, 제가 저를 못 믿어서 시작한 겁니다.

이 동기가 왜 중요하냐면, 이후 461개 버전의 방향을 전부 결정했기 때문입니다. 돈을 더 벌려고 시작했다면 아마 신호를 더 빨리 잡는 쪽으로 갔을 겁니다. 그런데 출발점이 자제력이었으니, 개발의 대부분이 하지 말아야 할 것을 정하는 일이 됐어요. 지금 봇의 규칙 목록을 보면 절반이 “이럴 땐 안 산다"입니다. 그 성격은 첫날에 이미 정해져 있었습니다.

남아 있는 가장 오래된 파일은 코드가 아니라 메모입니다. Futuring Request.txt, 2026년 5월 25일. 열어보면 그냥 하고 싶은 것들을 나열한 요구사항 목록이에요. 트레일링 스톱을 넣고 싶다, 창이 두 개 뜨면 안 된다, 같은 것들. 그중 “2중 실행 방지"라는 한 줄은 며칠 뒤 v1.04 코드 맨 위에 주석으로 그대로 올라갑니다. 같은 날 만든 RunTrader.bat도 남아 있습니다. 윈도우 배치 파일이죠.

메모에서 눈에 띄는 건 비율입니다. 열 줄 남짓 중 대부분이 화면 이야기예요. 색을 통일해달라, 버튼을 나눠달라, 글자를 키워달라. 매매에 관한 건 두 줄뿐입니다. 목표 수익률에서 절반을 익절하고 나머지는 추세를 끝까지 따라가겠다는 것. 그때는 화면이 봇의 전부였으니 당연한 비율이었는데, 지금 보면 그 두 줄이 나머지를 다 합친 것보다 오래 살아남았습니다.

뼈대는 첫 주에 이미 완성돼 있었습니다

기술 구성은 단순했습니다. 빗썸 공개 API에서 분봉을 REST로 긁어오고, 조건을 검사하고, tkinter 창에 상태를 그리는 구조. 시세를 읽고 → 판단하고 → 주문한다는 뼈대는 사실 이때 이미 완성돼 있었고, 그 뒤 두 달은 이 뼈대에 살을 붙이는 과정이었습니다.

통신에서 한 가지 선택을 했는데, 지금까지 유지되고 있습니다. 시세나 분봉처럼 인증이 필요 없는 데이터는 공개 라이브러리를 그대로 썼고, 잔고 조회와 주문처럼 돈이 움직이는 구간만 직접 짰어요. 서명을 만들고 헤더에 싣는 부분을 손으로 구현한 겁니다. 이유는 단순했습니다. 틀렸을 때 어디서 틀렸는지 알고 싶었거든요. 시세를 잘못 읽으면 안 사면 그만이지만, 주문이 잘못 나가면 돈이 나갑니다.

문제는 GUI였습니다. 이벤트 루프랑 tkinter 루프가 한 프로세스에서 경합하니까 창이 자주 멈췄어요. 멈출 때마다 스레드를 하나씩 붙여가며 때웠습니다. 지금 보면 아키텍처라고 부르기 민망한 수준인데, 그때는 그게 최선이었습니다.

이 시대의 구조
  [ 빗썸 공개 API ] ──REST 폴링──▶ [ 조건 검사 ] ──▶ [ 주문 ]
                                        │
                                        ▼
                                 [ tkinter 창 ]  ← 자주 멈춤
  파일: 단일 .py · 168줄(v1.0f) → 1,047줄(v1.34) → 이후 계속 증가
  없는 것: 재진입 통제 · 일일 손실 한도 · 시장 상황 판단 · 매매 기록 저장

없는 것 목록이 더 중요합니다. 손절은 있었어요. 그런데 같은 종목을 몇 번까지 살지, 하루에 얼마까지 잃으면 멈출지, 시장 전체가 빠지는 날엔 어떻게 할지에 대한 규칙이 하나도 없었습니다. 전략은 있는데 리스크 관리가 없는 구조였던 겁니다. 이후 개발사 전체를 한 줄로 줄이면, 이 빈칸을 하나씩 채워온 과정입니다.

이 차이를 조금 더 풀어서 설명하면 이렇습니다. 개별 손절만 있는 봇은 시장이 통째로 빠지는 날에 가장 나쁘게 행동합니다. 조건이 서니까 사고, 빠지니까 잘리고, 또 조건이 서니까 또 삽니다. 봇은 규칙대로 완벽하게 동작하는데 계좌만 녹아요. 손절이 잘 작동할수록 손실이 규칙적으로 쌓입니다. 이 장면을 실제로 겪기 전까지는 “안 사는 규칙"의 필요성을 머리로만 알았습니다.

창이 곧 프로세스였습니다

이 시절 운영 방식은 배치 파일 네 줄에 다 들어 있습니다. 폴더로 들어가서 파이썬을 띄우고, 마지막에 pause. 더블클릭으로 봇을 켜고 검은 창을 들여다보다가 아무 키나 눌러 닫는 구조였어요.

더블클릭으로 켜는 봇의 사망 원인
  · 창을 실수로 닫으면 죽는다
  · PC가 절전으로 들어가면 죽는다
  · 윈도우 자동 업데이트가 재부팅하면 죽는다
  · 죽었다는 사실을 아무도 안 알려준다
  --------------------------------------------------
  포지션을 들고 있는 상태에서 봇이 죽으면
  손절도 익절도 아무도 안 한다

자동매매에서 제일 무서운 건 잘못 사는 게 아니라 들고 있는데 아무도 안 지켜보는 상태입니다. 손절선을 아무리 잘 정해놔도 프로세스가 죽어 있으면 그 값은 없는 것과 같습니다. 이 불안이 이 시대 내내 깔려 있었고, 결국 시대를 끝내는 이유 중 하나가 됩니다.

그래서 이 시기 중반부터 알림을 붙이기 시작했습니다. 매수했는지, 손절했는지, 죽었는지를 밖에서 알 수 있게 하는 작업이었어요. 성능 개선이 아니라 운영 형태의 변경이었는데, 지나고 보면 이게 GUI를 버리는 결정의 예고편이었습니다. 화면 없이도 봇이 뭘 하는지 알 수 있게 되자, 화면이 없어도 되는 상태가 된 거죠.

하루에 열 개씩 버전이 나왔습니다

이 시기 버전 번호가 어떻게 움직였는지 보면 좀 웃깁니다.

열흘간의 버전 (보존 95개)
  5/25   v1.04     첫 코드 — 메모의 "2중 실행 방지" 가 주석으로 올라감
  5/26   v1.05 ~ v1.15
  5/29   v1.31 ~ v1.90    하루에만 스무 개 넘게
  5/30   v2.x
  6/01   v3.39     3회 재시도 통신 로직
  6/02   v4.66     무결성 점검의 원형
  6/02   v4.73     EC2 세션 풀링
  6/03   v83 ~ v90 → 같은 날 upbit_v091 시작
  마지막 빗썸 버전 바로 다음 번호로 업비트 봇이 시작된다 — 번호가 거래소를 넘는다

지금 보면 무모했지만, 그 속도가 아니었으면 구조의 문제를 몸으로 배우지 못했을 겁니다. 하루에 열 번 고치다 보면 어디가 약한지 손끝으로 알게 되거든요.

그렇게 빨리 돌 수 있었던 이유는 검증 절차가 없었기 때문입니다. 고치고, 돌리고, 눈으로 보고, 다음. 시뮬레이션도 백테스트도 없으니 배포까지 몇 분이면 됐어요. 지금은 파라미터 하나 바꾸는 데 매매기록 시뮬레이션을 돌리고 근거 수치를 커밋에 적습니다. 훨씬 느립니다. 어느 쪽이 나으냐고 물으면, 초기엔 속도가 맞았고 지금은 규율이 맞다고 답하겠습니다. 순서를 바꿨으면 둘 다 못 얻었을 것 같아요.

다만 이 속도에는 대가가 있었습니다. 어떤 변경이 어떤 결과를 냈는지 짝을 지을 수 없다는 것. 30분 사이에 세 군데를 고치면, 그중 무엇이 효과였는지 알 방법이 없습니다. 지금 파라미터를 한 번에 하나씩만 바꾸는 규칙은 정확히 이 답답함의 반작용입니다.

버전 관리가 파일 복사였습니다

이때는 git이 없었습니다. 버전 관리라는 게 파일을 복사해서 번호를 하나 올리는 것이었어요. 되돌리고 싶으면 예전 파일을 열면 되고, 그게 전부였습니다.

git 없이 461개를 남긴 방식
  저장       파일 복사 → 번호 +1
  되돌리기   예전 파일을 연다
  변경 이력   파일 헤더 주석에 한 줄
  브랜치     폴더를 하나 더 판다
  --------------------------------------------------
  장점  되돌아갈 지점이 촘촘하다
  단점  왜 바꿨는지가 대부분 안 남는다
        폴더 이름이 사람 손을 타서 어긋난다

실제로 이 시대 파일 중에는 폴더 이름과 파일 헤더의 버전 번호가 어긋난 것들이 있습니다. 나중에 아카이브를 정리하면서 전부 파일 시각 기준으로 재정렬해야 했어요. 폴더 이름은 사람이 붙인 것이고 파일 시각은 시스템이 남긴 것이라, 둘이 다투면 시스템 쪽을 믿는 게 맞더군요.

재밌는 건 코드가 한 줄도 안 바뀐 버전도 남아 있다는 점입니다. 파일명만 올라가고 내용은 동일한 버전이요. 큰 걸 건드리기 직전에 복사부터 해둔 흔적입니다. git이 없던 시절에도 “망하면 돌아갈 자리"를 먼저 만드는 본능은 있었던 셈이에요. 지금의 배포 규율은 그 본능이 도구를 만난 결과라고 생각합니다.

여기서 태어나 지금까지 살아남은 것들

이 시대에 만들어져 461개 버전을 지나 현행까지 이어진 개념이 몇 개 있습니다.

빗썸 기원기의 유산
  v1.09  눌림목 대기    조건이 서도 바로 안 산다
                          -0.5% 더 빠지면 산다
                          → 현행 과매도 눌림목 전략의 원형
  v1.31  슬롯          동시에 몇 개까지 들고 갈지
                          → 현행 4슬롯 운용
  v1.34  RSI 도입      과매도를 숫자로 정의
                          → 문턱값 확정까지 두 달 더 걸림
  v3.39  3회 재시도    통신 실패를 정상 상황으로 취급
  v4.66  무결성 점검   봇의 기억을 의심하기 시작
  --------------------------------------------------
  다섯 개 전부 "더 잘 사는 법" 이 아니라 "덜 틀리는 법" 이다

특히 v1.09가 이 시대의 분수령입니다. 그전까지 봇이 판단하는 건 “살까 말까” 하나였는데, 여기서 “얼마에 살까"가 추가됐어요. 조건이 서도 가격이 안 맞으면 안 삽니다. 신호와 체결 사이에 조건이 하나 더 끼어든 거죠.

같은 버전에서 손절선도 함께 넓혔습니다. 더 낮게 사니까 더 넓게 버틸 수 있게 된 겁니다. 여기서 배운 게 하나 있는데, 진입가와 손절 폭은 따로 정하는 값이 아니라는 것입니다. 하나를 바꾸면 다른 하나도 다시 봐야 해요. 지금 파라미터를 바꿀 때마다 전체를 다시 시뮬레이션하는 이유가 이겁니다. 값 하나가 독립적으로 존재하지 않습니다.

v4.66의 무결성 점검도 짚어둘 만합니다. 봇이 자기가 계산한 보유 현황을 의심하고 거래소에 다시 물어보는 로직인데, 이게 나중에 “거래소 잔고와 원 단위로 일치하지 않으면 배포 금지"라는 규칙으로 자랍니다. 자기 기억을 안 믿기로 한 첫 순간이 이 시대에 있었습니다.

화면이 곧 전략이었습니다

이 시대의 코드를 열어보면 화면 그리는 코드와 매매 판단하는 코드가 한 클래스 안에 섞여 있습니다. 창을 그리는 객체가 시세 폴링도 하고 손절 판정도 해요.

당시엔 그게 자연스러웠습니다. 봇의 상태를 알 수 있는 유일한 창구가 화면이었으니, 화면을 중심으로 코드를 짠 거죠. 그런데 이 구조에는 치명적인 부작용이 있었습니다. 전략을 검증할 방법이 없어집니다.

화면과 판단이 붙어 있으면
  전략을 시험하려면
    → 창을 띄워야 하고
    → 창을 띄우면 사람이 앉아 있어야 하고
    → 실시간으로만 확인 가능하고
    → 과거 데이터로 돌려볼 수 없다
  --------------------------------------------------
  결과: 파라미터를 "느낌" 으로 정하게 된다
  현행: 판단 로직이 화면과 분리 → 매매기록으로 재현 가능

이 구조 때문에 이 시대의 파라미터는 전부 감으로 정해졌습니다. 손절 몇 퍼센트, 익절 몇 퍼센트, RSI 몇 이하 — 근거가 “이게 나을 것 같다"였어요. 그리고 며칠 돌려보고 느낌이 안 좋으면 되돌립니다. 며칠은 표본이 아닌데도 그게 유일한 판단 근거였습니다.

지금 봇이 매매기록 전수 시뮬레이션으로 파라미터를 정할 수 있는 건 판단 로직이 화면에서 완전히 분리돼 있기 때문입니다. 같은 로직에 과거 기록을 넣어 다시 돌릴 수 있으니까요. 그 구조를 얻기까지 시대가 다섯 개 더 걸렸습니다.

실패 목록을 남겨둡니다

이 시대에 겪은 실패를 성격별로 나눠보면 이렇습니다. 이후 개발의 방향이 여기서 다 나왔어요.

빗썸 기원기 실패 유형
  [1] 시끄러운 실패   실행이 안 된다 · 창이 안 뜬다
                     즉시 발견 · 제일 싸다
  [2] 에러 실패     주문 거부 · 인증 실패
                     로그를 보면 안다
  [3] 조용한 실패   요청이 거부됐는데 그냥 다음 루프로
                     모른다 · 제일 비싸다
  [4] 화면 거짓말   숫자가 잘려 보인다 · 낡은 값이 남아 있다
                     사람이 잘못된 판단을 한다
  [5] 죽은 봇       프로세스가 종료됐는데 포지션은 그대로
                     손절도 익절도 아무도 안 한다
  --------------------------------------------------
  이후 개발의 목표: 3·4·5 를 1로 끌어올리기

3번이 제일 무섭습니다. 봇이 멈추면 알아채고, 에러 창이 뜨면 알아채는데, 평소처럼 돌아가면서 아무것도 안 하는 상태는 구분할 방법이 없어요. 시장이 조용한 건지 봇이 고장 난 건지 모릅니다.

지금 봇이 로그를 그렇게 많이 찍는 이유가 이겁니다. 게이트를 통과하지 못한 종목에 대해서도 어느 게이트에서 왜 떨어졌는지를 남깁니다. “안 샀다"와 “못 샀다"를 구분할 수 있어야 하니까요. 조용한 실패를 시끄러운 실패로 바꾸는 게 자동매매 개발의 절반이라고 생각합니다.

통신이 끊긴다는 걸 배운 시기

6월 1일 v3.39에 “3회 재시도” 로직이 들어갑니다. 별것 아닌 것처럼 보이지만, 봇을 대하는 태도가 바뀐 지점이에요.

그전까지 저는 통신 실패를 예외 상황으로 취급했습니다. 요청을 보내면 응답이 오는 게 정상이고, 안 오면 뭔가 잘못된 거라고 생각했죠. 그런데 실제로 며칠 돌려보면 통신은 그냥 끊깁니다. 거래소가 잠깐 느려지고, 와이파이가 몇 초 흔들리고, 응답이 늦게 옵니다. 이건 사고가 아니라 날씨예요.

통신 실패를 대하는 두 가지 태도
  [ 예외로 취급 ]
    실패 → 로그 남기고 다음 루프
    → 그 틱의 판단이 통째로 사라진다
    → 손절 확인도 같이 사라진다

  [ 정상 상황으로 취급 ]
실패 → 잠깐 쉬고 재시도 → 재시도 → 그래도 실패면 보고
→ 대부분은 2회 안에 복구된다
  ————————————————–
  자동매매에서 “가끔 실패한다” 는 설계 조건이지 버그가 아니다

특히 위험한 건 청산 경로의 통신 실패입니다. 매수는 실패해도 안 사면 그만인데, 손절 확인 요청이 실패하면 봇은 그 종목이 손절선을 넘었는지 모르는 채로 넘어갑니다. 사는 쪽의 실패는 기회비용이지만 파는 쪽의 실패는 실제 손실이에요. 지금 봇에서 청산 관련 통신에 더 엄격한 재시도와 검증이 붙어 있는 이유가 여기 있습니다.

6월 2일 v4.73의 EC2 세션 풀링도 같은 계열입니다. 매번 새로 연결을 여는 대신 연결을 재사용하는 방식이죠. 표면적으로는 속도 개선이지만, 실제 효과는 연결 수립 단계에서 실패할 기회 자체를 줄이는 것이었습니다. 안 하는 일은 실패하지 않는다는 게 안정성의 기본이더군요.

슬롯과 RSI, 두 개의 씨앗

5월 29일 v1.31에 슬롯 개념이 들어갑니다. 동시에 몇 종목까지 들고 갈지를 숫자로 정한 겁니다.

지금 보면 당연한 장치인데, 이게 없으면 어떻게 되는지 생각해보면 필요성이 분명해집니다. 조건이 서는 종목이 열 개면 열 개를 다 삽니다. 현금이 허락하는 한 계속 사요. 그러면 시장이 통째로 좋을 때는 좋은데, 통째로 나쁠 때는 전 재산이 한 방향에 걸립니다. 슬롯은 수익을 위한 장치가 아니라 노출을 고정하는 장치입니다.

슬롯이 하는 일
  슬롯 없음   조건 성립 종목 = 매수 종목
              시장이 좋은 날 → 전액 노출
              시장이 나쁜 날 → 전액 노출 (같음)

  슬롯 있음   동시 보유 상한 고정
최악의 날에 잃을 수 있는 금액이 계산 가능해진다
  ————————————————–
  현행 4슬롯 · 슬롯당 예산은 가용 현금의 고정 비중

5월 29일 v1.34에는 RSI가 처음 들어갑니다. 과매도를 감이 아니라 숫자로 정의하려는 첫 시도였어요. 다만 이때 쓴 문턱값은 교과서에 나오는 값 그대로였고, 그게 실제 계좌에서 맞는 값인지는 확인할 방법이 없었습니다. 매매 기록을 체계적으로 안 남기던 시절이니까요.

이 문턱값이 실측 데이터로 확정되기까지 두 달이 더 걸립니다. 지표를 넣는 것과 그 지표의 값을 정하는 건 전혀 다른 작업이라는 걸 이때는 몰랐어요. 지표는 하루면 붙이는데, 그 지표를 신뢰할 수 있는 숫자로 만드는 데는 두 달이 걸립니다.

무엇이 끝을 냈나

두 가지였습니다.

첫째, 윈도우에서 봇을 24시간 돌리는 게 계속 불안했습니다. 자동 업데이트 한 번, 재부팅 한 번에 포지션이 방치되니까요. 이 불안이 결국 맥북 구매로 이어지고, 맥으로 옮기면서 창 형태 GUI는 사라지고 터미널 모니터링만 남게 됩니다.

둘째, 단타의 수수료를 계좌로 배웠습니다. 처음에 초단타로 시작한 건 순전히 호기심이었어요. 왕복 0.1%가 숫자로는 별거 아닌데, 하루에 수십 번 돌리면 그게 전부 나갑니다.

회전율이 만드는 벽 (개념 계산)
  왕복 수수료가 a 일 때, 회전 n 회의 누적 비용 = a × n
  --------------------------------------------------
  단타  회전 많음 · 회당 목표 작음
        → 비용이 목표를 잠식한다
        → 승률이 높아도 계좌는 준다
  눌림목 회전 적음 · 회당 목표 큼
        → 같은 비용이 훨씬 덜 아프다
  --------------------------------------------------
  ※ 실제 요율은 거래소·등급별로 다릅니다
  요점은 숫자가 아니라 구조 — 회전율은 비용을 곱한다

이 감각이 이후 모든 전략 선택에 영향을 줬습니다. 회전이 많은 전략은 신호가 아무리 좋아도 비용에서 집니다. 지금 봇이 15분봉 기준으로 판단하고 하루에 몇 번만 진입하는 구조인 것도, 밀리초 싸움에 관심이 없는 것도 전부 이 시기의 학습에서 나왔어요. 속도가 아니라 회전율이 진짜 비용이라는 걸 계좌로 배웠습니다.

단타를 해봐야 알게 되는 것들

초단타로 시작했다는 얘기를 조금 더 하겠습니다. 수수료 말고도 배운 게 있었거든요.

첫째, 회전이 빠른 전략은 사람이 못 검증합니다. 하루에 수십 번 매매하면 로그가 화면을 순식간에 지나갑니다. 뭐가 잘 됐고 뭐가 잘못됐는지 눈으로는 못 따라가요. 기록을 남기지 않던 시절이라 그날 성적이 왜 그랬는지 설명할 수가 없었습니다. 전략의 회전율은 검증 난이도와 직결됩니다.

둘째, 빠른 전략일수록 인프라 문제가 성적으로 직결됩니다. 응답이 0.5초 늦으면 15분봉 전략에서는 아무 일도 안 일어나지만, 초 단위 전략에서는 그게 손실입니다. 그러면 전략을 개선하는 대신 인프라를 개선하는 데 시간을 쓰게 돼요. 혼자 만드는 봇에서 그 방향은 밑 빠진 독입니다.

전략 주기가 결정하는 것들
              초 단위            15분봉
  비용        회전 × 수수료 (큼)   회전 적음
  검증        사람이 못 따라감     건별로 확인 가능
  인프라      지연이 곧 손실       몇 초 늦어도 무관
  개발 초점   속도                판단
  --------------------------------------------------
  혼자 만드는 봇이 이길 수 있는 쪽은 오른쪽이었다

셋째, 이게 제일 중요한데 — 단타는 제가 원래 고치려던 문제를 오히려 키웠습니다. 시작이 자제력 문제였잖아요. 그런데 초단타 봇은 화면을 계속 보게 만듭니다. 로그가 끊임없이 올라가니까요. 자제력 때문에 만든 봇 앞에 하루 종일 앉아 있게 된 겁니다.

이 자각이 이후 방향을 완전히 바꿨습니다. 좋은 자동매매는 성적이 좋은 게 아니라 안 봐도 되는 것이라는 기준이 생겼어요. 지금 봇이 하루에 몇 번만 진입하고, 알림이 상태 변화 때만 오고, 터미널 대시보드 한 장으로 끝나는 것도 전부 그 기준에서 나왔습니다.

번호가 거래소를 넘어갑니다

6월 3일, 빗썸 v90 다음 번호로 업비트 v091이 시작됩니다. 거래소는 바뀌었는데 버전 번호는 이어졌어요.

그 연속성이 이 봇의 정체성이라고 생각합니다. 새로 만든 게 아니라, 하던 걸 계속한 겁니다. 거래소를 옮기는 건 보통 프로젝트를 새로 시작할 명분이 되는데, 그때 저는 번호를 이어 붙였어요. 지금 돌아보면 그게 좋은 선택이었습니다. 처음부터 다시 시작했다면 빗썸에서 배운 것들 — 슬롯, 재시도, 무결성, 수수료 감각 — 을 절반쯤 흘렸을 겁니다.

열흘, 95개 버전. 코드는 대부분 버려졌지만 이유는 하나도 안 버렸습니다.

열흘의 타임라인, 다시 한 번

이 시대를 밀도로 보면 이렇게 됩니다.

2026-05-25 ~ 06-03 · 무엇이 언제 생겼나
  5/25  메모 한 장            코드 없음. 요구사항만
  5/26  첫 코드 · 인증 통과    주문이 나가기 시작
  5/28  눌림목 · 알림          전략과 운영이 동시에
  5/29  슬롯 · RSI             노출 통제와 지표
  6/01  재시도 로직            통신을 날씨로 인정
  6/02  무결성 · 세션 풀링      자기 기억을 의심
  6/03  업비트로 이관          번호는 이어짐
  --------------------------------------------------
  9일 · 95개 버전 · 그중 지금까지 살아남은 개념 5개

95개를 만들어 5개가 남았습니다. 비율로 보면 5%예요. 낭비처럼 보이지만 그렇게 생각하지 않습니다. 남은 5개가 무엇인지는 90개를 만들어보기 전엔 알 수 없었으니까요.

그리고 이 열흘의 진짜 산출물은 코드가 아니라 판단 기준이었습니다. 무엇이 위험한지, 무엇이 조용히 실패하는지, 어떤 전략이 나한테 안 맞는지. 그 기준이 있으니 다음 시대에는 같은 실수를 안 하게 됩니다. 두 번째 시대가 일주일 만에 지나간 것도 그래서예요.

이 시대를 다시 읽는 방법

마지막으로, 이 아카이브를 어떻게 복원했는지 적어둡니다. 같은 처지에 놓인 분이 있을 수 있으니까요.

461개 버전을 정리한 순서
  1. 폴더명과 버전 번호를 전부 무시한다
  2. 파일 시각으로 재정렬한다  ← 유일하게 못 속이는 값
  3. 인접 버전끼리 diff 를 돌려 변경량을 뽑는다
  4. 파일 헤더 주석에서 그날의 의도를 찾는다
  5. 없으면 "추정" 이라고 표시하고 근거를 같이 적는다
  6. 공개 전에 키·토큰·서버 주소를 먼저 지운다
  --------------------------------------------------
  6번이 1번보다 먼저입니다. 읽기 전에 지우세요.

이 글에 “추정"이라는 단어가 자주 나오는 이유가 5번입니다. 코드가 어떻게 바뀌었는지는 diff로 확실히 알 수 있지만, 왜 바꿨는지는 대부분 안 남아 있어요. 확실한 것과 추정한 것을 섞어 쓰면 기록으로서 가치가 없어지니 굳이 매번 표시했습니다.

6번은 실제로 제일 먼저 한 작업입니다. 이 시절 코드에는 인증 정보와 서버 주소가 파일에 그대로 박혀 있었어요. 설정 파일을 따로 만들 시간이 아까워서 그렇게 했던 건데, 그 편의의 대가가 두 달 뒤 아카이브를 공개하려 할 때 돌아왔습니다. 이 블로그의 어떤 화면에도 실제 값은 옮기지 않았습니다.

그때의 나에게 해주고 싶은 말

아카이브를 정리하다 보면 자연스럽게 이런 생각이 듭니다. 그때 뭘 다르게 했으면 좋았을까.

솔직히 대부분은 순서를 건너뛸 수 없었다고 생각합니다. 슬롯 제한의 필요성은 슬롯 없이 물려봐야 알고, 수수료의 무게는 수수료를 내봐야 압니다. “그때 리스크 관리부터 넣었어야지"라고 쓰는 건 지금이니까 쉬운 말이에요.

다만 세 가지는 순서와 상관없이 처음부터 할 수 있었습니다.

첫날부터 했어도 됐던 것들
  1. 매매 기록을 파일로 남기기
      전략이 뭐든 상관없다. 기록만 있으면 나중에 분석된다
      안 남긴 대가: 이 시대 파라미터는 전부 근거가 없다
  2. 키와 서버 주소를 설정 파일로 분리하기
      10분이면 되는 작업
      안 한 대가: 두 달 뒤 공개 정리에 훨씬 오래 걸림
  3. 변경 이유를 한 줄이라도 남기기
      주석이든 텍스트 파일이든
      안 남긴 대가: 461개 중 상당수가 "추정" 으로만 복원됨
  --------------------------------------------------
  셋 다 실력이 아니라 습관의 문제였다

1번이 특히 뼈아픕니다. 이 시기 봇은 실제로 돌면서 사고팔고 있었어요. 그 기록이 분석 가능한 형태로 쌓였다면 지금 두 달 치 데이터가 더 있었을 겁니다. 전략이 미숙했던 건 어쩔 수 없지만, 미숙한 전략의 기록도 데이터입니다. 그걸 안 남긴 건 실력 부족이 아니라 그냥 안 한 거예요.

그래서 자동매매를 시작하는 분께 하나만 권한다면 이겁니다. 전략보다 기록을 먼저 만드세요. 전략은 어차피 바뀝니다. 기록은 안 바뀌고 계속 쌓입니다.

남기고 싶은 문장

열흘을 한 문장으로 줄이면 이겁니다. 뼈대는 첫 주에 완성됐고, 그 뒤로 늘어난 건 전부 안 사는 이유였다.

읽고, 판단하고, 주문한다 — 이 세 단계는 615줄짜리 첫 코드에도 있었고 지금 여섯 개 모듈에도 있습니다. 461개 버전 동안 늘어난 코드의 대부분은 진입을 막는 조건이에요. 게이트 열 개, 슬롯 상한, 손절, 본전 사수, 일일 한도, 레짐 차단. 전부 “여기선 안 한다"를 정해둔 것들입니다.

자제력이 없어서 시작한 프로젝트가 결국 자제력을 코드로 구현하는 프로젝트가 됐습니다. 시작할 때 의도한 건 아닌데, 지나고 보니 그것 말고는 할 수 있는 게 없었더군요.