Polymarket Bot Tutorial · 32개 중 31장

Polymarket bot을 실전에 투입하기: 첫 입금 25-50 USD, take-profit 및 stop-loss 규칙, alert 임계값(Telegram/email), reconciliation 주기, 그리고 첫 주 scaling 계획.

Polymarkets.co.il의 수석 작가 Harley Young 작성. 최종 검토: 2026년 5월.

이 장에서 다루는 내용

paper에서 live로 전환하는 순간이야말로 대부분의 builder가 실수로 첫 입금을 날리는 구간입니다. 이 장은 pre-flight checklist와, 손실로 번지기 전에 bug를 잡아내는 첫 주 discipline을 다룹니다.

  • Pre-flight checklist
  • 첫 입금: 25-50 USD
  • production에서 가져온 TP/SL rules
  • Monitoring: Telegram, email, dashboards
  • Reconcile 주기: 매 fire_exits cycle마다
  • 첫 주: 가까이서 보고, 작게 시작하기
  • Scaling: 언제 더 입금할 것인가

Pre-flight checklist

bot을 paper에서 live로 바꾸기 전에, 정확히 이 순서대로 확인하세요.

  1. 30건의 paper trade 종료. 작성된 success criteria 충족 또는 초과.
  2. Diary format이 paper와 live에서 동일함. 같은 JSONL schema.
  3. VPS 배포 완료. bot은 유일한 process이며, systemd unit이 구성되어 있음.
  4. HALT file mechanism 테스트 완료. touch /opt/pmt/HALT가 30초 이내에 bot을 멈춤.
  5. Telegram alerts 설정 완료. 테스트 alert가 성공적으로 전송됨.
  6. Daily-loss kill switch 테스트 완료. 10% drawdown을 시뮬레이션하고 halt가 발동하는지 확인.
  7. On-chain reconciliation 테스트 완료. diary를 수동으로 불일치시키고 halt가 발동하는지 확인.
  8. 입금 address는 Polymarket이 당신을 대신해 거래하는 스마트 컨트랙트 지갑인 proxy wallet(POLY_FUNDER_ADDRESS)이며, 당신의 개인 계정 즉 externally-owned account(EOA)가 아닙니다. SDK wallet show로 검증.
  9. USDC/pUSD approvals 설정 완료. standard exchange와 NegRisk exchange 모두.
  10. 초기 입금액을 서면으로 합의함: smoke test용 $25-50.

어떤 항목이라도 미완료라면 live로 가지 마세요. 과거 production 사례에서 각 항목은 실제 돈 손실로 이어진 적이 있습니다.

첫 입금: 25-50 USD

smoke-test 입금액은 의도적으로 작습니다. 목표는 수익을 내는 것이 아니라 live 경로가 제대로 동작하는지 확인하는 것입니다.

테스트하는 것: bot의 order placement가 Polymarket의 trade 관점과 일치하는지. diary가 올바르게 기록되는지. take-profit GTC가 실제로 게시되는지. 일시적인 API error에서 bot이 복구하는지. daily-loss halt를 시뮬레이션했을 때 제대로 발동하는지.

예상 결과: paper diary를 대략적으로 따라가는 5-15개의 작은 trade. 어떤 차이도 "live가 paper보다 noisy해서 그렇다"는 특징이 아니라 bug로 간주하세요.

만약 이 $25-50을 실제 전략 손실로 모두 잃는다면, 그 전략은 더 많은 paper run이 필요합니다. bug 때문에 날렸다면, scaling 전에 bug를 먼저 고치세요.

production에서 가져온 TP/SL rules

먼저 이 섹션이 전제로 하는 두 용어를 짧게 정의합니다. take-profit(TP)은 가격이 목표치까지 오르면 이익을 확정하도록 미리 설정해 둔 매도 주문이고, stop-loss(SL)은 가격이 한계선 아래로 떨어지면 포지션을 매도해 한 번의 나쁜 trade가 걷잡을 수 없이 커지지 않게 합니다. 아래에서 사용하는 주문 유형은 두 가지로, GTC(Good-Til-Cancelled - 체결되거나 당신이 취소할 때까지 호가창에 남아 대기하는 주문)와 FOK(Fill-Or-Kill - 주문 전체를 즉시 체결하거나 전부 취소)입니다. 한 가지 더 보게 될 용어인 mark는 주문 유형이 전혀 아니며, 포지션을 평가하는 기준이 되는 현재 mid-price를 뜻할 뿐입니다. 아래는 우리 trader의 production 기본값으로, 수천 건의 trade에서도 잘 유지되어 왔습니다.

  • Buy: FOK를 ask + best ask보다 1c 위에서 실행. ask > 0.85이면 건너뜀(0.99 trap).
  • Take-profit: GTC sell을 entry + 4-6c에 게시, buy fill + 5초 settlement wait 직후.
  • Stop-loss via mark: mid를 모니터링; mid가 entry - 8c까지 떨어지면 best bid에서 FOK sell(대기 주문 없음; mid blow-through는 매우 빠름).
  • Time exit: position이 X시간 내에 닫히지 않았고 PnL이 -2c와 +2c 사이면, market에서 FOK exit.

숫자는 strategy마다 달라지지만, 패턴은 일관됩니다. take-profit은 항상 GTC, stop-loss는 보통 FOK(왜냐하면 mid가 급격히 내려갈 때 GTC stop은 체결되지 않기 때문), time exit은 오래된 signal을 계속 타지 않도록 설정합니다.

Monitoring: Telegram, email, dashboards

bot은 실시간으로 관찰 가능해야 합니다. 세 가지 layer가 있습니다.

  • Telegram alerts: 모든 fill, 모든 halt, threshold를 넘는 모든 error. 개인 메시지와 섞이지 않도록 전용 channel이나 group을 사용하세요.
  • Daily summary email: 하루 종료 시 total trades, win rate, PnL, trigger된 halt 목록. 매일 아침 읽으세요.
  • Dashboard: 선택 사항이지만 유용합니다. diary를 읽고 open position + 최근 fills + 누적 PnL을 렌더링하는 간단한 HTTP endpoint.

패턴은 이렇습니다: 알아둘 가치가 있는 상태 변화 → Telegram. 하루 끝 요약 → email. 실시간 탐색 → dashboard.

Reconcile 주기: 매 fire_exits cycle마다

reconciliation은 drift가 다음 trade에서 복리처럼 커지기 전에 잡아낼 수 있을 만큼 자주 실행되어야 합니다. 주기는 trade frequency에 따라 달라집니다.

  • 하루 10건 미만의 strategy: 매시간 reconcile.
  • 하루 10-100건의 strategy: 15분마다 reconcile.
  • HFT strategy(하루 100건 이상): exit-firing loop의 매 cycle마다 reconcile.

reconciliation 비용은 보유 token당 chain read 1회입니다. token이 20개라면 RPC call 20회인데, free-tier RPC 기준으로도 충분히 감당 가능합니다. 이 부분은 과도하게 최적화하지 마세요.

첫 주: 가까이서 보고, 작게 시작하기

live deployment의 첫 주는 가장 위험합니다. paper run이 놓친 live-path bug를 발견하는 시기이기 때문입니다. discipline은 다음과 같습니다.

  • 가까이서 보기-깨어 있는 시간에는 매시간 Telegram channel을 확인하세요.
  • 작게 시작하기-position size를 최소(5 shares)로 유지하세요. bug가 수백 달러가 아니라 몇 달러만 손해를 내야 합니다.
  • 첫 3-5일 동안은 하루 끝에 수동으로 reconcile하세요. diary와 Polymarket UI를 직접 비교하세요.
  • 놀라운 점은 모두 기록하세요. 작은 혼란도 결국 bug가 됩니다.

첫 주가 끝났을 때 bug가 없고 diary가 현실과 일치한다면, 정상 size로 확대하세요. bug가 나타났다면 먼저 고치고, smoke-test 주를 한 번 더 돌리세요.

Scaling: 언제 더 입금할 것인가

자본을 추가하는 트리거는 각각 다른 threshold를 가집니다.

  • +50% 입금: live trade 30건, win rate가 paper rate와 5pt 이내, bug로 인한 production halt 없음.
  • +100-200% 입금: live trade 100건 이상, 샘플 전반에 걸쳐 일관된 수익성, 최소 한 번의 작은 outage까지 검증된 infrastructure.
  • +500% 이상 입금: 6개월 이상 일관된 live 수익성이 확인된 후에만. 자본 확대는 성공보다 느려야 합니다. edge가 진짜인지, 곧 사라질 regime가 아닌지 확실히 해야 합니다.

너무 일찍 scaling할 때 가장 큰 단일 위험은, 한 시장 regime에서 수익이 나던 strategy가 다음 regime에서 손실로 바뀌는 것입니다. size를 키운다고 그 문제가 해결되지는 않습니다. patience가 해결합니다.

자주 묻는 질문

첫 live deposit는 얼마로 해야 하나요?
25-50 USD입니다. 실제 fill, 실제 fee, 실제 reconciliation을 테스트하기에 충분하고, 전액 손실이 삶에 영향을 주지 않을 만큼 작습니다. 우리가 아는 대부분의 disciplined trader들은 bankroll이 훨씬 더 허용하더라도 이 정도 크기로 시작합니다. 작은 손실의 ego cost가 큰 손실의 ego cost보다 훨씬 낮기 때문입니다.
TP/SL은 어떻게 설정해야 하나요?
자신의 edge에 대칭적으로 설정하세요. strategy가 winning trade당 +5%를 기대한다면 take-profit은 +5-7%, stop-loss는 -3-4%로 설정합니다. 비대칭(작은 TP, 큰 SL)은 trading이 아니라 gambling입니다. 우리 production trader는 대부분의 strategy에서 TP+6% / SL-4%(FAK exits)를 사용합니다.
bot을 live에서 어떻게 모니터링해야 하나요?
세 가지 channel입니다: (1) closed-trade outcome이 $0.30 PnL을 넘을 때 Telegram bot으로 실시간 alert. (2) cash + open positions + MtM의 hourly dashboard view. (3) email로 받는 daily PnL summary. 이 셋 중 하나라도 실패하면 blind 상태로 운영하는 것입니다.
무엇이 emergency stop을 트리거해야 하나요?
다음 중 하나라도 해당하면 됩니다: daily loss가 bankroll의 5% 초과, fill rate 30% 미만(wedged orders 시사), 5연속 이상 손실 trade, market data feed가 30초 이상 무음, 또는 diary와 on-chain 간 reconciliation mismatch. 이 모든 것은 자동 halt-sentinel touch로 코드화할 수 있습니다.
live bankroll은 언제 늘릴 수 있나요?
최소 50건의 closed live trade가 있고, live win rate가 paper와 10% 이내로 일치하며, 2주 이상 reconciliation incident가 없을 때입니다. checkpoint당 최대 2배까지만 확대하세요-25 USD -> 50 -> 100 -> 200 -> 500, 며칠이 아니라 몇 달에 걸쳐서요.
여러 strategy를 동시에 live로 돌려도 되나요?
처음에는 안 됩니다. 하나의 strategy를 2-4주 동안 live로 돌려 검증하세요. 그런 다음 두 번째를 추가하세요. 첫 몇 주 동안 두 strategy를 동시에 모니터링하는 것은 strategy 1을 죽이는 bug를 놓치기 쉬운 방법입니다.