자동매매 봇, 만들고 끝이 아니다 — 유지보수 비용의 현실

"봇 제작비는 알겠는데, 그거 한 번 만들면 그다음엔 공짜로 계속 돌아가는 거죠?" — 상담에서 가장 자주 나오는 오해입니다. 자동매매 봇은 다 지은 뒤 그냥 서 있는 건물이 아니라, 매일 변하는 거래소·시장·서버 위에서 살아 움직이는 소프트웨어입니다. 그래서 '완성'은 끝이 아니라 운영의 시작점입니다. 이 글은 납품 이후에 왜, 어떤, 얼마짜리 비용이 생기는지를 코딩을 몰라도 이해하도록 정리하고, 그 비용을 미리 예측하고 줄이는 방법까지 안내합니다. 특정 금액은 상황마다 다르므로, 숫자는 범위·개념으로만 보시고 실제 견적은 요건별로 확인하세요.

1. '완성 = 끝'이라는 착각

일반적인 소프트웨어를 살 때 우리는 은연중에 '완제품'을 산다고 생각합니다. 냉장고를 사면 그걸로 끝이듯이요. 그런데 자동매매 봇은 성격이 다릅니다. 봇은 혼자 완결된 물건이 아니라, 바깥의 여러 시스템에 계속 손을 뻗어 붙어 있는 프로그램이기 때문입니다.

봇이 정상 작동하려면 최소한 이 네 가지가 매 순간 맞물려야 합니다. ① 거래소가 정한 주문 규격(API)이 그대로일 것, ② 봇을 올려둔 서버가 안 꺼질 것, ③ 시세·데이터가 제때 흐를 것, ④ 인증(로그인·키)이 만료되지 않을 것. 이 중 하나만 어긋나도 봇은 주문을 거부당하거나 조용히 멈춥니다. 문제는 이 네 가지가 내 의지와 상관없이 바깥에서 계속 바뀐다는 데 있습니다.

더 까다로운 점은 자동매매의 고장이 '조용하다'는 것입니다. 웹사이트라면 안 열릴 때 방문자가 바로 항의하지만, 자동매매 봇은 멈춰도, 심지어 잘못된 주문을 넣어도 사람이 즉시 알아채기 어렵습니다. 밤사이 봇이 멈춘 걸 아침에야 발견하거나, 며칠 뒤 잔고를 보고 이상을 깨닫는 식입니다. 그래서 자동매매에서 유지보수는 '선택적 사치'가 아니라 사고를 조용히 키우지 않기 위한 최소한의 안전장치에 가깝습니다.

2. 유지보수가 반드시 생기는 5가지 이유

유지보수는 '개발자가 대충 만들어서' 생기는 게 아닙니다. 아무리 잘 만든 봇도 아래 다섯 가지 바깥의 변화 때문에 손이 갑니다. 하나씩 쉬운 말로 풀어보겠습니다.

① 거래소가 API(주문 규격)를 바꾼다

봇은 거래소가 정해둔 주문 규격에 맞춰 "사라 / 팔아 / 잔고 알려줘"를 전달합니다. 그런데 거래소는 보안 강화나 시스템 개편을 이유로 이 규격을 종종 바꿉니다. 옛 접속 방식을 종료하고 새 방식으로 갈아타게 하거나, 로그인(인증) 절차를 바꾸거나, 응답 형식을 손봅니다. 국내 증권사 쪽에서도 예전 설치형 접속 방식에서 REST 방식으로 옮겨가는 흐름이 있었습니다(구체 시점·대상은 각 증권사 공지 확인). 이런 변경이 오면, 기존 규격으로 짜인 봇은 어느 날 갑자기 주문이 거부되거나 로그인이 안 됩니다. 이때 봇을 새 규격에 맞춰 고치는 작업이 대표적인 유지보수입니다.

② 거래소 정책·수수료·상장폐지가 바뀐다

규격(기술)이 아니라 규칙(정책)이 바뀌는 경우입니다. 수수료율이 바뀌면 손익분기 계산이 달라지고, 최소 주문 금액·주문 단위(호가 단위)가 바뀌면 봇의 주문 로직을 손봐야 합니다. 봇이 거래하던 코인·종목이 상장폐지되면 그 종목을 다루는 부분을 교체해야 하고, 특정 상품(예: 일부 레버리지 상품)에 대한 제한이 생기면 전략 자체를 조정해야 합니다. 이런 정책 변화는 기술 변경만큼 자주는 아니어도, 한 번 오면 실제 손익에 직접 영향을 줍니다.

③ 인증·보안이 만료되거나 갱신된다

봇이 거래소에 접속할 때 쓰는 API 키(일종의 전용 열쇠)는 유효기간이 있거나, 보안상 주기적으로 재발급이 권장됩니다. 키가 만료되면 봇은 그 순간 남의 집 앞에서 열쇠가 안 맞는 상태가 됩니다. 또 계정 비밀번호·2차 인증 정책이 바뀌면 접속 설정을 손봐야 할 수 있습니다. 키 자체를 안전하게 다루는 원칙은 → API 키를 넘겨도 될까 — 계좌를 지키는 5가지 안전장치에서 자세히 다뤘습니다.

④ 서버·환경이 낡는다

봇이 사는 집, 즉 서버(VPS)와 그 위의 운영체제·프로그램 부품(라이브러리)도 시간이 지나면 낡습니다. 오래된 버전은 보안 취약점이 생기거나, 거래소가 새로 요구하는 최신 방식과 안 맞을 수 있습니다. 그래서 가끔 부품 교체(업데이트)가 필요하고, 이때 봇이 그 변화와 충돌하지 않는지 점검·수정하는 작업이 따라옵니다. 서버 운영 자체의 개념은 → VPS 24시간 봇 운영 가이드를 참고하세요.

⑤ 시장이 변하고, 사람 욕심이 는다

마지막은 바깥이 아니라 안에서 오는 변화입니다. 잘 돌던 전략도 시장 국면이 바뀌면(예: 추세장 → 횡보장) 성과가 달라져 파라미터를 조정하고 싶어집니다. 또 봇을 써보면 "여기에 손절을 더 촘촘히", "종목을 하나 더", "텔레그램 알림을 추가"처럼 기능을 더하고 싶은 욕심이 자연스럽게 생깁니다. 이건 결함이 아니라 개선·확장이며, 대부분 유상 유지보수(추가 개발)로 처리됩니다. 참고로 "시장이 바뀌었으니 전략을 바꾸면 무조건 낫다"는 보장은 없습니다. 조정은 신중히, 검증을 거쳐야 합니다. → 백테스트와 실전의 괴리

3. 매달 나가는 고정비 — 운영 3종 세트

유지보수 이야기 전에, 봇을 '켜두기만 해도' 나가는 기본 운영비부터 정리하겠습니다. 규모가 작으면 소소하지만, 0원은 아닙니다. 크게 세 가지입니다.

여기에 유상 유지보수 계약을 맺으면 '월 정액 관리비'가 추가될 수 있습니다. 다만 이건 모든 봇에 필수는 아니고, 봇의 중요도·규모·본인의 대응 역량에 따라 선택합니다. 소액·단순 봇을 스스로 감시할 수 있다면 고정비는 서버비 정도로 최소화되고, 규모가 크거나 본업이 바빠 손 못 대는 경우 관리비를 얹어 안심을 사는 구조입니다.

4. 불규칙하게 튀는 변동비

고정비가 '매달 비슷하게 나가는 돈'이라면, 변동비는 사건이 터질 때 튀는 돈입니다. 예측이 어려워서 오히려 더 신경 써야 하는 항목입니다. 아래 그림처럼, 제작비는 초반에 한 번 크게 나가고 끝나지만, 운영·유지보수비는 낮게 깔리다가 사건 때 솟구치는 모양을 그립니다.

장애 대응 — 봇이 멈추거나 오작동할 때

서버가 다운되거나, 네트워크가 끊기거나, 거래소가 일시적으로 응답을 안 하거나, 예상 못 한 입력에 봇이 걸려 넘어질 때가 있습니다. 이때 원인을 찾아 되살리는 작업이 필요합니다. 잘 만든 봇은 이런 상황의 상당수를 스스로 재시작·재접속하도록 설계돼 사람 손을 덜지만, 그래도 '사람이 개입해야 하는 장애'는 남습니다. 장애를 유형별로 나눠 감지→복구→호출하는 체계는 → 봇 장애·복구 플레이북에서 자세히 다뤘습니다.

여기서 꼭 짚을 점은, 장애의 진짜 비용을 결정하는 건 '수리 시간'이 아니라 '발견 시간'이라는 것입니다. 봇이 멈춘 것을 5분 만에 알면 손실 없이 재시작하면 그만이지만, 하루 뒤에 알면 그사이 놓친 매매·잘못된 포지션이 실제 돈으로 번집니다. 그래서 자가 복구와 즉시 알림이 없는 봇은 '수리비는 같아도 사고 규모가 훨씬 커지는' 구조입니다. 유지보수 비용을 이야기할 때 사람들은 '고치는 값'만 생각하지만, 자동매매에서 더 중요한 건 고장을 얼마나 빨리 아느냐입니다. 이 감지 체계 자체가 가장 값싼 보험인 셈입니다.

긴급 패치 — 시간이 촉박한 수정

거래소 규격이 특정 날짜에 바뀌어 그날까지 대응해야 하거나, 보안 문제가 발견돼 즉시 고쳐야 할 때가 있습니다. 일반 유지보수와 달리 기한 압박이 있어 우선순위가 높고, 그만큼 대응 체계(누가, 얼마나 빨리 붙는가)가 중요합니다. 계약서의 '응답 시간' 조항이 여기서 힘을 발휘합니다(7장 참고).

기능 추가·개선 — 결함이 아닌 확장

"종목을 더", "손절 로직을 정교하게", "리포트를 붙여달라" 같은 요청은 원래 봇의 결함이 아니라 새 작업입니다. 그래서 대개 별도 견적으로 진행합니다. 규모가 작으면 소액, 전략 구조를 바꿀 정도면 사실상 부분 재제작에 가까워질 수 있습니다. 확장을 염두에 둔다면, 처음 제작할 때 "나중에 기능을 붙이기 쉬운 구조"로 만들어 달라고 요청하는 것이 장기적으로 저렴합니다.

5. '무상 하자보수'와 '유상 유지보수'는 다르다

여기서 많은 분쟁이 생깁니다. 고객은 "고쳐주는 게 당연"이라 생각하고, 제작자는 "그건 추가 작업"이라 생각하는 지점이 어긋나기 때문입니다. 개념부터 정리하면 이렇습니다.

정리하면, "만들 때 잘못한 것" = 무상, "만든 뒤 세상이 바뀌어서 생긴 것" = 유상이 일반적인 경계입니다. 하지만 이 경계는 법으로 딱 정해진 게 아니라 계약서 정의에 달려 있습니다. 그래서 계약 전에 "하자보수 기간이 얼마인지", "무엇이 하자이고 무엇이 유지보수인지"를 문서로 못 박는 것이 핵심입니다. 이 부분은 소유권·독소조항과도 얽혀 있어 → 소스코드 소유권·에스크로·독소조항 가이드와 함께 보면 좋습니다.

유상 유지보수의 흔한 3가지 형태

어느 방식이든 "무엇이 포함이고 무엇이 별도인지"가 관건입니다. 예컨대 월 정액에 'API 변경 대응'이 포함인지, '기능 추가'는 별도인지가 명확해야 나중에 얼굴 붉힐 일이 없습니다. 구체 금액은 봇 복잡도·대응 범위·응답 속도 요구에 따라 크게 달라지므로 요건별로 견적을 받는 것이 정확합니다.

납품 직후 '안정화 기간'을 그냥 흘려보내지 마라

유지보수 이야기에서 가장 저평가되는 구간이 납품 직후 첫 1~2주입니다. 봇은 실제 돈·실제 시장에 붙어 돌기 시작할 때 비로소 백테스트나 모의에서 안 보이던 자잘한 문제가 드러납니다. 특정 시간대에만 나오는 오류, 예상 못 한 시장 상황에서의 반응, 알림 누락 같은 것들이죠. 그래서 좋은 계약은 이 기간을 '안정화 기간'으로 정해, 이때 발견되는 초기 결함을 무상 하자보수로 잡아줍니다.

고객 입장에서 이 기간에 해야 할 일은 분명합니다. ① 처음엔 잃어도 괜찮은 소액으로 돌려 실거래 검증을 하고, ② 알림·로그를 평소보다 더 자주 들여다보며, ③ 이상한 점은 사소해 보여도 기록해 바로 공유하는 것입니다. 이 2주를 성실히 보내면 이후 몇 달의 운영이 훨씬 안정됩니다. 반대로 "완성됐으니 됐다"며 바로 큰 금액을 넣고 방치하면, 하자보수로 무료로 잡을 수 있었던 문제를 나중에 유상으로, 그것도 손실과 함께 마주할 수 있습니다. 실거래 전환 시 왜 소액 검증이 중요한지는 → 백테스트와 실전의 괴리에서 더 다룹니다.

6. 셀프 운영 vs 위탁 운영 — 시간이라는 숨은 비용

유지보수를 직접 하느냐, 맡기느냐도 큰 비용 갈림길입니다. 돈만 보면 셀프가 싸 보이지만, 여기엔 눈에 안 보이는 시간·기회비용이 숨어 있습니다.

여기서 자주 간과되는 게 '감시 노동'입니다. 자동매매는 '자동'이라는 말 때문에 손이 아예 안 갈 것 같지만, 최소한 봇이 살아 있는지, 이상 주문은 없는지 매일 잠깐이라도 확인하는 습관이 필요합니다. 이 일을 스스로 감당할 수 있으면 셀프가 합리적이고, "그럴 시간에 본업을 하는 게 낫다"면 위탁의 월 관리비가 오히려 기회비용을 아끼는 선택이 됩니다. 정답은 없고, 본인의 시간 가치로 계산해야 합니다.

그래서 실제로 얼마나 자주 손이 갈까

가장 궁금한 건 결국 "자주 고장 나나요?"일 겁니다. 정직하게 답하면 봇마다, 시기마다 다릅니다. 다만 경험적으로 패턴은 있습니다. 잘 만들고 자가 복구를 넣은 단순한 봇은 몇 달에 한 번 큰 대응이 있을까 말까 하고, 나머지는 평소 알림을 힐끗 보는 정도로 흘러갑니다. 반대로 여러 거래소에 걸쳐 있고 전략이 복잡한 봇은 손이 더 자주 갑니다. 거래소 규격 변경은 예고 없이 몰려올 때도, 반년 넘게 조용할 때도 있어 '평균'보다 '분산'이 큰 항목이라고 이해하는 편이 정확합니다.

그래서 유지보수 예산은 '매달 정확히 얼마'가 아니라 '1년에 몇 번의 큰 대응 + 상시 소액 운영비'라는 틀로 잡는 게 현실적입니다. 각 대응의 단가와 연간 예상 횟수는 봇 구조에 따라 크게 달라지므로, 제작 단계에서 "이 봇은 대략 어떤 유지보수가 얼마나 자주 예상되는지"를 미리 물어보고 문서로 남기는 것을 권합니다. 이렇게 하면 '깜짝 청구'가 '예상된 관리'로 바뀝니다. 참고로 어떤 개발자도 유지보수 빈도를 정확히 보장할 수는 없습니다 — 바깥 변화는 통제 밖이기 때문입니다. "절대 손 갈 일 없다"는 말이 오히려 위험신호입니다(10장 참고).

7. 계약서에서 반드시 확인할 유지보수 조항

유지보수 비용의 '예측 가능성'은 대부분 계약 시점에 결정됩니다. 아래 항목이 문서에 없으면, 나중에 해석 차이로 비용과 감정이 함께 샙니다. 제작을 맡기기 전에 이 목록을 체크리스트처럼 확인하세요.

1. 무상 하자보수 기간 — 며칠/몇 주/몇 개월인지, 그 안에 무엇이 '하자'로 인정되는지.
2. 하자와 유지보수의 경계 정의 — 거래소 변경 대응이 무상인지 유상인지 명시.
3. 응답·대응 시간 — 장애 신고 시 며칠 안에 붙는지(SLA). 긴급 대응 기준.
4. 유지보수 과금 방식 — 건별/월정액/연간 중 무엇이며, 포함·제외 범위.
5. 소스코드·문서 인도 — 코드와 설명서를 받는지. 안 받으면 다른 곳에 못 맡겨 종속됩니다.
6. 연락·인수인계 — 담당자가 바뀌거나 연락이 끊길 때의 처리.
7. 재제작에 가까운 변경의 기준 — 어느 정도부터 신규 견적으로 넘어가는지.

8. 유지보수비를 줄이는 현실적인 방법

유지보수를 '피하는' 건 불가능하지만, 줄이고 예측 가능하게 만드는 방법은 있습니다. 대부분 제작 단계에서 결정됩니다.

요약하면, 유지보수비는 납품 후에 관리하는 게 아니라 제작 전에 설계로 줄이는 것입니다. "싸게 만들어 달라"만이 아니라 "고장이 적고, 고치기 쉽고, 남에게도 맡길 수 있게 만들어 달라"를 함께 요청하는 것이 진짜 절약입니다. 규칙과 요구를 미리 정리하는 틀은 → 자동매매 명세서 작성 가이드를 참고하세요.

한 가지 관점을 더 얹자면, 봇을 고를 때 '제작비'만 비교하는 것은 반쪽짜리 계산입니다. 제작비 50만 원이 싸 보여도, 코드도 문서도 안 주고 사소한 변경마다 부르는 게 값인 봇이라면 1년 뒤 총비용은 훨씬 커질 수 있습니다. 반대로 제작비가 조금 더 들어도 코드·문서를 넘겨받아 유지보수를 경쟁시킬 수 있는 봇이라면, 시간이 갈수록 오히려 저렴합니다. 자동차를 살 때 '차값'만 보지 않고 연비·정비·부품값까지 보는 것과 같은 이치입니다. 자동매매에서 이 총소유비용(구입 후 유지까지 합친 비용)의 관점을 갖는 순간, 견적서를 보는 눈이 달라집니다. 값이 아니라 구조와 계약을 보게 되는 것이죠.

9. 실전 시나리오 — 유지보수는 이렇게 온다

개념만으로는 감이 잘 안 옵니다. 알고랩 상담·운영에서 실제로 자주 마주치는 상황을 세 가지 시나리오로 재구성했습니다(특정 고객 사례가 아닌 전형적 패턴을 각색한 것입니다). 각 상황에서 어떤 대응이 필요하고, 그것이 하자보수인지 유지보수인지 보면 경계가 훨씬 또렷해집니다.

시나리오 A — "어제까지 잘 되던 봇이 오늘 아침 주문을 안 넣어요"

원인을 열어보니 거래소가 구버전 접속 방식을 종료하고 새 인증 방식으로 바꾼 날이었습니다. 봇은 옛 방식으로 로그인을 시도하다 거부당해 조용히 멈춰 있었습니다. 다행히 거래소는 몇 주 전 공지를 냈지만, 고객은 그 메일을 놓쳤습니다. 대응은 '새 인증 방식에 맞춰 접속 부분을 교체'하는 작업 — 이는 거래소 변경 대응이므로 유상 유지보수에 해당합니다. 교훈은 두 가지입니다. ① 거래소 공지를 챙기는 것 자체가 관리의 일부다. ② 봇이 멈췄을 때 즉시 알려주는 알림이 있었다면 며칠을 허비하지 않았을 것이다.

시나리오 B — "며칠째 이상하게 주문이 자꾸 실패해요"

로그를 보니 특정 종목에서만 주문이 반려되고 있었습니다. 알고 보니 그 종목의 최소 주문 수량·호가 단위가 거래소 정책으로 바뀌었는데, 봇은 옛 기준으로 주문을 넣고 있었습니다. 이건 봇이 처음부터 틀린 게 아니라 세상이 바뀐 경우라 유상 유지보수입니다. 다만 만약 봇이 처음부터 그 종목의 호가 단위를 잘못 계산했다면 그건 하자보수(무상)가 됐을 겁니다. 같은 증상이라도 '원래 틀렸나 / 나중에 바뀌었나'에 따라 성격이 갈린다는 걸 보여주는 사례입니다.

시나리오 C — "봇은 멀쩡한데, 기능을 더 넣고 싶어요"

몇 달 잘 운영한 뒤 "종목을 3개 더 추가하고, 손실이 일정 수준을 넘으면 그날은 매매를 멈추는 안전장치를 넣고 싶다"는 요청이 왔습니다. 봇에 결함은 없습니다. 이건 명백한 기능 추가(유상)이며, 작업량에 따라 별도 견적으로 진행합니다. 여기서 처음 제작할 때 '확장 쉬운 구조'로 만들어 뒀다면 추가 비용이 작고, 반대로 급하게 얽어 만든 봇이면 손대는 김에 여기저기 고쳐야 해 비용이 커집니다. 미래의 유지보수비는 과거의 설계가 결정한다는 점이 잘 드러나는 경우입니다.

세 시나리오의 공통 교훈은 분명합니다. ① 조용한 고장을 빨리 알아채는 알림, ② 하자·유지보수 경계의 사전 합의, ③ 확장을 견디는 초기 설계 — 이 셋이 유지보수 경험의 질과 비용을 좌우합니다. 세 가지 모두 사고가 난 뒤가 아니라 만들기 전에 챙겨야 하는 것들입니다. 체결 관련 증상을 더 깊이 이해하려면 → 주문 체결의 진짜 원리(슬리피지·미체결)도 함께 보세요.

10. 이런 유지보수는 피하라 — 위험신호

마지막으로, 유지보수를 둘러싼 위험신호입니다. 아래에 해당하면 계약 전에 다시 따져봐야 합니다. 이는 사기 예방과도 이어지는 지점입니다. → 자동매매 사기·허위광고 피하는 법

특히 마지막 항목을 기억하세요. 유지보수는 봇이 기술적으로 잘 작동하도록 지키는 일이지, 수익을 만들어주는 일이 아닙니다. 봇이 완벽히 유지보수돼도 전략이 시장과 안 맞으면 손실이 날 수 있습니다. 기술 안정성과 투자 성과는 다른 층위의 문제라는 점을 분명히 구분해야 건강한 기대치를 가질 수 있습니다. 리스크 관점의 전체 그림은 → 자동매매 리스크 관리 완전 가이드에서 보완하세요.

반대로 믿을 만한 유지보수 파트너의 특징은 단순합니다. 계약 전에 하자·유지보수의 경계와 비용을 스스로 먼저 설명하고, 코드·문서를 넘겨주는 데 거리낌이 없으며, "손 갈 일이 아예 없다"고 장담하는 대신 "이런 상황에선 이렇게 대응한다"고 현실적으로 말합니다. 좋은 봇을 만드는 능력만큼이나, 만든 뒤를 정직하게 다루는 태도가 오래 함께 갈 파트너인지를 가릅니다. 유지보수는 결국 기술 문제이자 신뢰 문제이기 때문입니다.

자주 묻는 질문