자동매매 봇 배포 후 첫 30일 — 납품이 끝이 아니라 시작인 이유

맞춤 자동매매 봇을 받아 든 순간, 많은 분이 이렇게 생각합니다 — "드디어 끝났다. 이제 돌리기만 하면 된다." 그런데 실제로는 정반대입니다. 봇을 넘겨받은 그날은 결승선이 아니라 출발선입니다. 아무리 잘 검증한 봇이라도, 실전 계좌에서 진짜 체결·진짜 수수료·진짜 새벽 장애를 처음 마주하는 것은 납품 직후이기 때문입니다. 자동차로 치면 출고 직후의 길들이기 기간, 새 집으로 치면 입주 초기 하자 점검 기간에 해당합니다. 이 글은 그 첫 30일을 어떻게 넘기면 봇이 안전하게 자리를 잡는지 — 인수인계에서 무엇을 받고, 언제 무엇을 보고, 자본을 어떻게 늘리고, 어디까지가 무상 하자보수이고 어디부터가 유상 유지보수인지 — 를 비개발자 눈높이에서 정리합니다. 미리 밝혀둘 것 하나. 이 글은 어느 방향으로 시장이 갈지도, 얼마를 벌지도 예측하지 않습니다. 첫 30일의 목표는 '수익'이 아니라 '봇이 설계대로 안전하게 작동하는지 확인하는 것'입니다.

1. 왜 첫 30일이 봇의 운명을 가르나

먼저 오해 하나를 풀어야 합니다. "검증까지 다 하고 납품받았는데 왜 또 조심하나?" 좋은 질문입니다. 그리고 그 답이 이 글의 핵심입니다. 실전 투입 전 검증 3단계에서 다뤘듯, 제작 과정의 검증은 대부분 과거 데이터(백테스트)와 모의·소액 환경에서 이뤄집니다. 아무리 꼼꼼해도 이 검증에는 실전과 다른 부분이 남습니다. 실제 호가창의 체결·슬리피지, 실제 수수료, 실제 새벽 시간대의 네트워크·거래소 상태, 그리고 내 계좌 규모에서만 나타나는 상황들. 이것들은 실전 계좌에 붙는 순간 처음 드러납니다.

그래서 첫 30일은 검증의 마지막 단계이자 진짜 첫 단계입니다. 이 기간의 성패는 봇이 얼마를 버느냐가 아니라, 실전 환경에서 명세대로 작동하는지, 예상 못한 상황에서 안전하게 멈추는지, 그리고 내가 그것을 읽고 통제할 수 있는지로 갈립니다. 여기서 헐겁게 넘어가면, 훗날 새벽에 벌어질 사고의 씨앗을 그대로 심는 셈입니다. 반대로 이 30일을 제대로 통과하면, 봇은 '내가 상태를 아는 봇'이 되어 오래 안심하고 돌릴 수 있습니다.

한 가지 더. 첫 30일의 문제는 대개 큰 사고가 아니라 작은 어긋남의 모습으로 옵니다. 주문이 한 번 이상하게 나가고, 알림이 한 번 늦게 오고, 체결가가 생각보다 조금 나빴던 정도죠. 그래서 무심코 넘기기 쉽습니다. 하지만 이런 작은 어긋남이야말로 아직 실전에 맞춰지지 않은 부분을 알려주는 신호입니다. 안정화 기간에 이 신호를 하나씩 붙잡아 원인을 밝혀두면, 나중에 그것이 자본이 커진 상태에서 큰 사고로 자라는 것을 막을 수 있습니다. 반대로 "그럴 수도 있지" 하고 넘긴 작은 어긋남은, 시간이 지나 잊힌 채 남아 있다가 가장 나쁜 순간에 되살아나곤 합니다. 첫 30일을 '문제를 찾아내는 기간'으로 여기면, 문제가 보이는 것은 실패가 아니라 오히려 안정화가 제대로 되고 있다는 증거입니다.

2. 인수인계 — 받는 그날 반드시 챙길 다섯 가지

안정화는 제대로 된 인수인계에서 시작됩니다. 봇이 돌아가는 걸 눈으로 보는 것과, 그 봇을 내가 통제할 수 있는 상태로 넘겨받는 것은 전혀 다릅니다. 받는 날 최소한 다음 다섯 가지를 확인하세요. 하나라도 비면, 문제가 생겼을 때 손을 쓸 수 없는 처지가 됩니다.

다섯 가지 중에서도 ①과 ⑤가 특히 자주 소홀히 다뤄집니다. 소스코드 소유권과 이전 조건이 애매하면 나중에 다른 곳에 맡기거나 직접 손볼 때 발이 묶입니다 — 이 문제는 소스코드 소유권·에스크로·독소조항 가이드에서 자세히 다뤘습니다. 그리고 장애 연락 체계가 없으면, 새벽에 봇이 멈췄을 때 '누구에게 연락해야 하나'부터 막힙니다. 인수인계는 파일을 받는 행위가 아니라 통제권을 넘겨받는 절차임을 기억하세요.

3. Day 0 인수인계 체크리스트

받는 날, 아래 항목을 하나씩 눈으로 확인하고 표시하세요. '된다고 들었다'가 아니라 '내가 확인했다'가 되어야 합니다.

특히 '규칙' 항목은 명세서와 나란히 놓고 대조하세요. 명세서에 적힌 규칙과 실제 봇의 설정값이 일치하는지 확인하는 것이 납품 검수의 핵심입니다. '안전' 항목의 손실 한도·킬 스위치가 실제로 켜져 있는지도 반드시 눈으로 확인하세요 — 이것들이 첫 30일 사고를 막는 안전벨트입니다(안전 정지장치 정리).

4. 첫 30일 안정화 타임라인 — 4주로 나눠 보기

첫 30일을 한 덩어리로 보면 막막합니다. 4주로 나누면, 주마다 '이번 주엔 무엇을 확인하는가'가 분명해집니다. 아래 타임라인은 하나의 표준 틀이며, 시장·전략·자본에 따라 기간과 강도는 조정됩니다. 핵심은 '왼쪽(관찰·소액)에서 오른쪽(정상 운영)으로 천천히 이동한다'는 방향입니다.

1주차 · 관찰 — 손익이 아니라 작동을 본다

첫 주의 임무는 단 하나입니다. "봇이 명세대로 작동하는가." 최소 자본으로 돌리면서, 주문이 의도한 조건에서 나갔는지, 체결·잔고·포지션이 봇의 기록과 실제 계좌에서 일치하는지, 알림이 제때 오는지를 봅니다. 이 주에 손익 숫자를 들여다보는 것은 오히려 방해가 됩니다. 며칠 치 손익은 표본이 너무 적어 아무것도 말해주지 않으면서, 정상 작동 확인이라는 진짜 임무에서 눈을 떼게 만들기 때문입니다. 첫 주는 회계 감사에 가깝습니다 — 돈을 얼마 벌었나가 아니라, 장부와 실물이 맞는가.

2주차 · 단계적 증액 — 이상 없을 때만 한 계단

1주차에 작동이 확인됐다면, 이제 자본을 한 번에가 아니라 한 계단씩 올립니다. 자본이 커지면 체결·시장 영향·심리가 미묘하게 달라지므로, 각 계단마다 다시 '이상 없음'을 확인하고 다음으로 넘어갑니다. 이 시기에 첫 손절이 나오는 경우가 많은데, 손절이 규칙대로 났다면 그것은 실패가 아니라 안전장치가 작동했다는 증거입니다. 문제가 보이면 주저 없이 한 계단 되돌리세요 — 안정화 기간의 특권은 '언제든 뒤로 갈 수 있음'입니다.

3주차 · 패턴 파악 — 평시의 리듬을 익힌다

3주쯤 되면 봇의 '평상시 모습'이 보이기 시작합니다. 하루에 대략 몇 번 매매하는지, 조용한 장에서는 어떻게 행동하는지, 어떤 상황에서 거래를 거르는지. 이 평시 리듬을 알아두면, 나중에 '뭔가 이상하다'를 빨리 감지할 수 있습니다. 정상을 알아야 비정상이 눈에 띕니다. 동시에 매일 손으로 확인하던 것들을 알림·자동 점검으로 옮겨, 감시 부담을 줄여갑니다. 24시간 무중단 운영의 기반은 VPS 운영 가이드에서 다뤘습니다.

4주차 · 안정화 판정 — 넘길까, 더 볼까

마지막 주는 판정의 시간입니다. 뒤의 9장에서 다룰 세 가지 질문으로 봇이 자리를 잡았는지 확인하고, 통과하면 정상 운영으로 넘기되 정기 점검 루틴을 확정합니다. 하나라도 걸리면 안정화를 연장합니다. 여기서 서두르지 않는 것이 중요합니다. 30일은 목표 기간일 뿐, 봇이 준비되지 않았는데 날짜를 채웠다고 넘기는 것은 안정화의 취지에 어긋납니다.

5. 무엇을 언제 보나 — 모니터링 3층

"매일 봐야 한다는데, 대체 뭘 보라는 건가요?" 가장 자주 나오는 질문입니다. 모든 것을 다 보려 하면 지쳐서 아무것도 안 보게 됩니다. 그래서 우선순위를 세 개의 층으로 나눕니다. 아래에서 위로 — 생존이 먼저, 성과는 맨 나중입니다.

1층 · 생존 — 봇이 살아 있는가

가장 먼저, 그리고 가장 자주 확인할 것은 "봇이 지금 살아서 돌고 있는가"입니다. 봇이 멈췄는데 그 사실을 모르면, 포지션을 든 채 손절도 청산도 안 되는 최악의 상황이 벌어집니다. 무서운 점은 죽은 봇은 스스로 부고를 보내지 못한다는 것입니다. 그래서 '살아 있다는 신호(하트비트)'를 주기적으로 보내게 하고, 그 신호가 끊기면 외부에서 알려주는 이중 감시가 필요합니다. 이 '침묵의 실패'를 잡는 방법은 텔레그램 감시·원격 제어와 장애 복구 플레이북에서 다뤘습니다.

2층 · 정상성 — 의도대로 행동하는가

살아 있다면, 다음은 "의도한 대로 행동하는가"입니다. 주문이 규칙에 맞는 조건·수량으로 나갔는지, 체결 결과가 봇의 기록과 실제 계좌에서 일치하는지, 중복 주문이나 유령 포지션은 없는지. 여기서 어긋남이 발견되면 손익과 무관하게 즉시 점검해야 합니다. 봇이 기록과 다르게 행동하고 있다는 것은, 언제 폭주해도 이상하지 않다는 뜻이기 때문입니다.

3층 · 성과 — 맨 마지막에, 그것도 조심스럽게

1·2층이 튼튼할 때 비로소 성과를 봅니다. 그런데 첫 30일의 성과는 '수익이 났나'가 아니라 '설계 범위 안에서 움직이나'로 읽어야 합니다. 짧은 기간의 손익은 표본이 적어 실력인지 운인지 가릴 수 없습니다. 대신 최악 낙폭이 예상 범위를 벗어나지 않았는지, 손절이 규칙대로 났는지를 봅니다. 손실이 사전에 정한 중단 한도를 넘으면 그때는 성과가 아니라 작동·설계의 문제로 다뤄야 하며, 끄기·참기·고치기의 판단은 드로다운 중단 규칙 가이드에서 별도로 정리했습니다.

6. 자본을 한 번에 넣지 않는 이유 — 단계적 증액

첫 30일에 가장 자주, 가장 크게 후회하는 실수가 "검증 끝났으니 바로 전액 투입"입니다. 왜 위험할까요? 실전 계좌에서만 드러나는 변수들 — 실제 체결 품질, 수수료의 누적, 자본 규모에 따른 시장 영향, 그리고 무엇보다 아직 발견되지 않은 엣지 케이스 — 이 있기 때문입니다. 소액에서 문제가 터지면 배움의 비용으로 끝나지만, 전액에서 같은 문제가 터지면 회복하기 어려운 타격이 됩니다.

그래서 자본은 계단으로 올립니다. 각 계단에서 '이상 없음'을 확인한 뒤에만 다음 계단으로 갑니다. 계단의 개수나 폭에 정답은 없지만, 원리는 하나입니다 — 새로 노출하는 금액은, 그 단계에서 문제가 생겨도 감당할 수 있는 크기여야 한다. 이는 사전 검증 3단계의 마지막(소액 실계좌)을 실전에서 자연스럽게 이어받는 흐름이기도 합니다.

7. 하자보수(무상)와 유지보수(유상)의 경계

첫 30일에 문제가 발견되면 누구나 궁금해합니다 — "이건 무료로 고쳐주나요, 돈을 더 내야 하나요?" 결론부터 말하면, 대체로 '납품물이 합의한 명세대로 작동하지 않는 것'을 바로잡는 것은 하자보수로 무상, '명세는 맞지만 새 기능을 더하거나 외부 변화에 맞춰 계속 손보는 것'은 유지보수로 유상인 경우가 많습니다. 다만 이 경계는 계약마다 다르므로, 미리 문서로 합의하는 것이 분쟁을 줄이는 최선입니다.

핵심은 안정화(무상 하자보수) 기간과 그 범위를 계약서에 못 박아 두는 것입니다. 기간이 며칠·몇 주인지, 무엇이 하자이고 무엇이 신규 요청인지를 미리 정하면, 첫 30일에 문제가 생겨도 감정 싸움 없이 처리됩니다. 회색지대가 걱정된다면, 안정화 기간에 포함할 '미세 조정' 범위를 처음부터 넓게 합의하고 사양을 동결하는 방식도 좋습니다. 비용의 큰 그림은 유지보수 비용의 현실과 제작 비용·견적 가이드에서, 계약 항목 전반은 외주 27체크리스트에서 다뤘습니다.

8. 첫 30일에 자주 터지는 사건 5가지

안정화 기간이 존재하는 이유는, 실전에서만 드러나는 문제가 실제로 있기 때문입니다. 대표적인 다섯 가지를 알아두면 놀라지 않고 대응할 수 있습니다.

다섯 가지 모두 '봇이 나빠서'가 아니라 '실전이 처음이라서' 생기는 일입니다. 그래서 첫 30일에 이런 일이 한두 번 생기는 것은 실패가 아니라 예상된 과정입니다. 중요한 건 각 사건이 파악되고 해결됐는가입니다. 발견 → 원인 규명 → 수정 → 재확인의 사이클을 한 번씩 돌고 나면, 봇은 그만큼 단단해집니다. ①·②는 체결의 원리, ③은 장애 복구, ④·⑤는 안전 정지장치 글과 이어집니다.

9. 30일 뒤 — 안정화 판정과 그다음

30일이 다가오면, 봇이 정말 자리를 잡았는지 판정해야 합니다. 날짜를 채웠다고 자동으로 넘어가는 게 아니라, 세 가지 질문에 모두 '예'라고 답할 수 있어야 합니다.

셋 다 '예'라면 정상 운영으로 넘어갑니다. 다만 '넘어간다'가 '방치한다'는 뜻은 아닙니다. 봇은 계속 돌보는 대상입니다. 거래소가 API 규격을 바꾸고, 인증서가 만료되고, 서버가 노후하고, 시장 구조가 변합니다(유지보수 비용의 현실). 그래서 안정화 이후에는 정기 점검 루틴 — 주기적인 생존·정상성 확인, 변경 사항 모니터링 — 을 가볍게 유지합니다.

스스로 돌볼지, 함께 돌볼지

여기서 갈림길이 하나 있습니다. 이 지속 관리를 직접 할지, 맡길지입니다. 규격 변화 대응·인증 갱신·서버 관리 같은 일은 비개발자에게는 부담일 수 있습니다. 스스로 하기 어렵다면 사후관리(유지보수) 형태로 이어가는 선택지가 있습니다 — 봇이 계속 건강하게 돌도록 정기 점검·업데이트·장애 대응을 위탁하는 방식입니다. 어느 쪽을 택하든, 핵심 메시지는 같습니다. 자동매매 봇은 '만들고 끝'이 아니라 '만들고 시작'이며, 첫 30일은 그 긴 여정의 첫 장입니다.

10. 첫 30일 흔한 실수 6가지

11. 시나리오 3 — 첫 30일을 지나는 세 사람

시나리오 A · "첫날 전액 넣은 사람"

검증까지 마쳤다는 말에 안심한 A는 납품 첫날 전 자본을 투입했습니다. 3일째, 얇은 시장에서 큰 주문이 예상보다 나쁘게 체결되는 슬리피지 문제가 처음 드러났습니다(사건 ②). 소액이었다면 배움으로 끝났을 일이, 전액이라 뼈아픈 손실이 됐습니다. A는 이후 자본을 줄여 단계적 증액으로 되돌렸습니다. 교훈 — 안정화 기간의 자본은 '문제가 생겨도 감당할 크기'여야 합니다.

시나리오 B · "손익만 본 사람"

B는 매일 손익만 확인했습니다. 첫 주 수익이 나자 "역시 잘 만들었다"며 안심했는데, 2주차에 봇이 새벽에 조용히 멈춘 걸 다음 날 오후에야 발견했습니다(사건 ⑤, 침묵의 실패). 다행히 큰 손실은 없었지만, 포지션을 든 채 반나절 방치됐던 것입니다. B는 손익 대신 생존(하트비트)을 1순위로 바꾸고, 봇이 멈추면 외부에서 알려주는 감시를 붙였습니다. 교훈 — 죽은 봇의 손익은 허수입니다.

시나리오 C · "범위를 안 정한 사람"

C는 계약서에 안정화 기간이나 하자/유지보수 경계를 적지 않았습니다. 2주차에 "이 조건도 추가해 달라"는 요청과 "손절이 이상하게 걸린다"는 문제가 동시에 생기자, 무엇이 무상이고 무엇이 유상인지를 두고 얼굴을 붉혔습니다. 문제의 진짜 원인은 기술이 아니라 적어두지 않음이었습니다. C는 남은 기간의 범위를 문서로 다시 합의하고 사양을 동결해 마무리했습니다. 교훈 — 다툼은 대개 합의의 공백에서 자랍니다.

12. 자주 오해하는 5가지

13. 첫 30일 온보딩 한 장 요약

받아 갈 것은 결국 한 문장입니다 — 봇을 받은 날은 끝이 아니라 시작이고, 첫 30일은 '얼마 벌었나'가 아니라 '안전하게 자리 잡았나'로 판정한다. 이 30일을 제대로 통과한 봇은, 그 뒤로 오래 안심하고 함께 갈 수 있습니다.

14. 자주 묻는 질문 (FAQ)