베팅 봇과 API: 계정이 잠기지 않는 자동화

이 규칙이 실제로 나누는 것

자동화는 이 사이트가 다루는 더 넓은 전문 베팅 기법들 안에 있는 여러 선 중 하나이며, 여기 규칙이 "샤프 베터는 소프트웨어를 쓴다"보다 훨씬 구체적이기 때문에 따로 페이지를 둡니다. 포럼에서는 "봇"을 한 가지로 뭉뚱그립니다. 베팅을 넣는 소프트웨어라는 것입니다. Betfair 약관은 더 정밀합니다. 12.1.4조는 의심스러운 것으로 간주하는 행위 중에 "계정 소유자가 각 베팅을 직접 수동으로 넣는 것 외의 방식"으로 넣은 베팅을 올리는데, 이것만 따로 읽으면 지금까지 작성된 모든 스크립트가 걸려들 것입니다. 하지만 따로 읽을 수 없습니다. 같은 조항이 의심의 여지를 없애기 위해, "API(Application Programming Interface)를 통해" 넣은 베팅은 포함되지 않는다는 예외를 스스로 담고 있습니다. 두 조각을 합치면 그 선은 정확합니다. 일반 웹사이트를 클릭해 들어가는 스크립트가 이 조항이 겨냥하는 대상이고, API에 말을 거는 스크립트는 이 조항이 스스로 이름 붙인 예외입니다.

참고로, "봇"이라는 말은 저 문장에서 많은 일을 하고 있지만, 그 단어는 실제 조항에는 전혀 나오지 않습니다. Betfair의 법무팀은 대신 "계정 소유자가 각 베팅을 직접 수동으로 넣는 것 외의 방식"이라고 썼는데, 같은 말을 길게 돌려 쓴 것이지만 잘못 인용하기는 훨씬 어려운 문장입니다. 어쨌든, 이것이 당신에게 어떤 의미인지로 돌아가겠습니다.

그러니 이 규칙은 "봇은 금지"도 아니고 "봇은 괜찮음"도 아닙니다. 더 좁습니다. 아주 빠른 두 손처럼 웹사이트를 조작하는 비공식 스크립트는 의심스러운 행위를 다루는 조항 안에 들어가고, 같은 로직이 공식 API에 연결되면 그 예외 안에 들어갑니다. 사다리를 직접 손으로 트레이딩하는 사람과 API를 통해 같은 일을 하는 스크립트는 같은 문서 안에서 다르게 취급되며, 그 차이는 전략이 아니라 문이 어느 쪽이냐입니다.

Live 키에 돈을 넣기 전에 테스트해야 할 것

봇을 만드는 사람은 누구나 곧바로 베팅을 넣는 단계로 건너뛰고 싶어 합니다. 정직한 순서는 그 반대입니다. 유료 키나 진짜 뱅크롤이 근처에 오기 전에, 일부러 실시간보다 느린 데이터를 상대로 로직을 증명하고, 그 장소가 허용하는 가장 작은 스테이크로 시작해야 합니다.

최선일 때 1초, 최악일 때 3분에 이르는 이 범위는 그냥 넘길 만한 오차가 아닙니다. 스크립트가 마지막으로 합리적이라고 본 가격은, 스크립트가 실제로 움직일 때쯔음에는 이미 한참 지나가 있을 수 있으며, 이를 완화해 줄 샌드박스도 없습니다. Betfair 자체 문서는 실제 자금을 쓰지 않고 테스트할 수 있는 테스트베드는 존재하지 않는다고 밝힙니다. Delayed 키가 넣는 모든 베팅은 실제 결과가 따르는 실제 베팅이며, 그래서 이 단계를 실행하는 유일하게 합리적인 방법은 그 장소가 허용하는 가장 작은 스테이크입니다.

가상의 예시이며, 모든 숫자는 산술을 위해서만 지어낸 것입니다. 스크립트가 2.10에 있는 가격을 지켜보다가 백하기로 결정했는데, 바로 그 순간 API가 180초 묵은 스냅샷을 돌려준다고 해봅시다. 골이나 레드카드, 늦은 출전 취소는 3분 안에 일어날 수 있으므로, 스크립트가 백한다고 생각하는 가격과 주문이 실제로 도착했을 때 제시되어 있는 가격은 서로 다른 두 숫자일 수 있습니다. 상류에 아무리 정교한 로직을 둬도 낡은 정보 위에 세워진 결정은 고쳐지지 않습니다. 그 위의 전략이 아니라 지연 그 자체가, 가장 먼저 테스트할 가치가 있는 것입니다.

장소는 그림의 절반일 뿐입니다. 나머지 절반은 봇이 실제로 반응하는 피드이며, 얕은 이력 위에 세워진 스크립트는 어떤 키로 돌리든 오작동합니다. 스크립트 자체의 숫자를 믿기 전에 계산기로 직접 산술을 확인하고, 거래 수수료는 이기는 베팅에서도 여전히 빠져나간다는 것을 기억하십시오. 그것이 봇의 순수치에 어떤 영향을 주는지는 전략이 서류상 성공으로 판정되기 전에 읽어볼 가치가 있습니다.

스크립트가 맞춰 설계해야 하는 한도

지금부터는 자동화가 허용되는지의 문제가 아닙니다. API 자체가 스크립트의 동작에 두는 한계, 추측에 맡기지 않고 분명한 숫자로 정해 둔 한계에 관한 것입니다. 스크립트가 아직 설계 단계에 있을 때 가장 중요한 것은 그중 네 가지이며, 위에서 다룬 Delayed 키 자체의 지연 구간과 더불어, 이는 Betfair가 바꿀 수 있는 숫자들입니다. 이 중 무엇에 맞춰 실제 운영 코드를 설계하기 전에 현재 약관을 확인하십시오.

• 마켓 데이터 요청에 대한 200포인트 한도. 비용은 요청한 마켓과 데이터 종류 전체에 걸쳐 합산되며, 총합을 넘기면 데이터 대신 오류가 돌아옵니다.
• 주문 및 포지션 조회에 대한 동시 3건 한도. 이전 요청이 아직 처리 중인 상태에서 현재 주문, 손익, 또는 정산된 주문을 세 번 넘게 동시에 확인하면, 대기열에 들어가는 것이 아니라 거부됩니다.
• 주문 생성·취소·수정·교체에 대한 초당 1,000건 한도. 이는 하나의 스크립트만이 아니라, 열려 있는 모든 연결에 걸친 계정 전체에 적용됩니다.
• 로그인 실패가 쌓이면 20분간 잠깁니다. 그 기간 동안은 앞선 실패의 원인이 무엇이었든, 이후의 모든 로그인 시도가 자동으로 거부됩니다.

두 번째 가상의 예시이며, 실제로 사람들을 걸려들게 하는 쪽입니다. 로그인 처리에 버그가 있는 스크립트가 세션을 제때 갱신하지 못하고, 물러서는 대신 촘촘한 루프로 재시도합니다. 20분은 대략 축구 전반전 하나입니다. 킥오프 때 이 잠금에 걸리면 스크립트는 잡아낸 것보다 더 많은 경기를 놓칩니다. 해법은 이야기보다 훨씬 단조롭습니다. 세션을 유지하고, 로그인 실패를 즉시 재시도할 이유가 아니라 멈출 이유로 다루십시오.