증권사 API가 불안정할 때, 자동매매는 어떻게 대응해야 할까

Q: API 호출 한도를 넘으면 어떻게 해야 하나요?

먼저 호출 사이에 짧은 대기를 두어 한도를 넘지 않게 하고, 그래도 한도 초과로 거절되면 대기 시간을 점점 늘려가며 정해진 횟수만 다시 시도합니다. 재시도 시점이 한꺼번에 겹치지 않도록 무작위 지연을 조금 더하면 다시 몰리는 것을 줄일 수 있습니다. 한도는 증권사마다, API마다 다르니 공식 문서를 확인하세요.

Q: 주문 요청도 오류가 나면 자동으로 다시 보내도 되나요?

조심해야 합니다. 한도 초과로 거절돼 처리되지 않은 요청은 다시 보내도 중복 주문이 되지 않지만, 응답이 오지 않아 주문이 접수됐는지 알 수 없는 경우(응답 대기 시간 초과)에 무조건 재전송하면 같은 주문이 두 번 나갈 수 있습니다. 그런 경우에는 자동 재전송 대신 주문 목록·체결 내역을 조회해 확인하는 편이 안전합니다. 판단 기준은 증권사별로 다르므로 공식 문서와 함께 확인하세요.

증권사 API는 요청이 올바르더라도 일시적으로 오류를 내거나 응답하지 않을 수 있습니다. 이때 잠시 기다렸다가 다시 시도하는 기능이 없으면 자동매매 로직이 예상치 못한 지점에서 끊겨 곤란해지는데, 이는 실전에서 겪어 보기 전에는 알기 어렵습니다. 게만아 공통모듈은 이런 대응을 API 호출 계층에 넣어 둡니다.

쉽게 말하면 · 증권사 서버는 가끔 “지금은 바쁘니 잠시 뒤에 다시 오세요”라고 답하거나 아예 대답하지 않습니다. 이때 잠깐 기다렸다가 다시 시도하는 기능이 없으면 자동매매 프로그램이 그 자리에서 멈춰 버립니다.

어떤 일이 생기나요?

AI·바이브코딩으로 증권사 API를 쓰는 사람이 늘면서 서버가 붐비거나 불안정해지는 순간이 생길 수 있습니다. 게만아 운용 경험에서는 올바른 요청을 보냈는데도 제대로 된 결과가 돌아오지 않는 경우가 있었습니다. 대표적인 모습은 다음과 같습니다.

초당 호출 한도를 넘었다며 요청이 거절된다
서버가 응답하지 않아 프로그램이 끝없이 기다린다
연결이 중간에 끊긴다(Connection reset 등)
토큰이 갑자기 무효·만료로 거절된다

이런 오류를 그냥 두면 잔고 조회나 주문 같은 중요한 단계에서 봇이 중단될 수 있습니다.

자동매매 코드에 꼭 필요한 6가지 대응

상황	대응	이유
호출이 너무 빠를 때	호출 사이에 짧은 대기를 둡니다.	증권사는 초당 호출 한도를 두는 경우가 많습니다. 처음부터 한도를 넘지 않게 속도를 조절하면 거절 자체를 줄일 수 있습니다.
서버가 응답하지 않을 때	모든 요청에 응답 대기 제한(타임아웃)을 겁니다.	서버가 대답하지 않을 때 프로그램이 끝없이 기다리며 멈추는 일을 막습니다.
호출 한도 초과로 거절될 때	대기 시간을 점점 늘려가며(+무작위 지연) 정해진 횟수만 다시 시도합니다.	한도 초과는 잠시 뒤에 풀리는 경우가 많습니다. 횟수를 제한해야 무한 반복을 막고, 무작위 지연을 더하면 재시도가 한꺼번에 몰리지 않습니다.
연결이 잠깐 끊겼을 때	연결 끊김(Connection reset 등)에 한해 짧게 몇 번 다시 시도합니다.	일시적인 네트워크 단절은 다시 연결하면 되는 경우가 많습니다. 단, 응답 대기 시간 초과는 이 재시도에서 제외합니다.
토큰이 무효·만료로 거절될 때	토큰을 다시 발급받은 뒤 한 번만 다시 보냅니다.	저장된 만료 시각이 남아 있어도 서버가 먼저 거절할 수 있습니다. 한 번만 재시도해야 계속 반복되는 것을 막습니다.
주문을 낼 때	재시도 조건을 더 엄격하게 둡니다.	주문은 같은 요청이 두 번 처리되면 안 됩니다. 처리되지 않았다고 확신할 수 있을 때만 다시 보내고, 불확실하면 조회로 확인합니다.

재시도는 횟수를 정해 두고 하는 것이 중요합니다. 끝없이 다시 시도하면 서버를 더 바쁘게 만들고, 문제를 알아채는 시점도 늦어집니다.

주문 재시도는 더 조심해야 합니다

한도 초과로 거절된 요청은 증권사 게이트웨이에서 처리되지 않은 것이므로 다시 보내도 주문이 중복되지 않습니다(증권사 공식 문서로 함께 확인하세요).
응답 대기 시간 초과는 주문이 접수됐는지 알 수 없습니다. 이때 자동으로 다시 보내면 같은 주문이 두 번 나갈 수 있어 재시도 대상에서 제외하고, 주문 목록·체결 내역으로 확인합니다.
시장가 주문도 체결이 지연될 수 있으므로, 주문 직후 곧바로 후속 주문을 내는 로직은 주의해야 합니다.

증권사마다 다른 오류 신호는 공통 기준으로 바꿔서 처리합니다

오류를 알리는 방식, 호출 한도, 토큰 무효·만료를 알리는 신호는 증권사마다 다릅니다. 어떤 증권사는 HTTP 429 같은 표준 상태코드로 알려주고, 어떤 증권사는 응답 본문의 코드로 구분합니다. 그래서 “429가 오면 재시도”처럼 한 증권사의 규칙을 다른 증권사에 그대로 쓰면 안 됩니다.

게만아 공통모듈은 이 차이를 공통 기준으로 추상화합니다. 증권사가 보낸 신호를 아래 분류로 바꿔 놓으면, 재시도 로직은 증권사와 무관하게 같은 방식으로 동작합니다.

공통 분류	증권사에서 오는 신호	처리
호출 한도 초과	HTTP 429 또는 응답 본문의 한도 초과 코드 등, 증권사마다 다름	대기 시간을 늘려가며 횟수를 제한해 다시 시도
토큰 무효·만료	응답 본문의 토큰 오류 코드 등, 증권사마다 다름	토큰 재발급 후 한 번만 다시 시도
일시적 연결 오류	연결 끊김(Connection reset 등)	짧게 몇 번 다시 시도
응답 대기 시간 초과	요청 후 정해진 시간 안에 응답 없음	오류로 처리하고 다음 흐름으로 이동(주문은 자동 재전송하지 않음)
그 외 오류	잘못된 요청·잔고 부족 등 재시도로 해결되지 않는 오류	재시도하지 않고 호출한 쪽에 그대로 전달

증권사의 응답 코드와 호출 한도는 바뀔 수 있으니 직접 구현할 때는 증권사 공식 문서를 기준으로 하세요.

게만아 공통모듈에서는

게만아 증권사 공통모듈은 위 대응을 API 호출 계층에 모아 두었습니다. 전략과 봇 코드는 잔고 조회·주문 함수를 부르기만 하면 되고, 호출 간 대기·응답 대기 제한·한도 초과 시 재시도·네트워크 단절 재시도·토큰 재발급은 공통모듈이 처리합니다. 이 구조는 모든 증권사가 함께 쓰는 공용 구조이고, 증권사마다 다른 응답 코드는 위의 공통 분류로 추상화해 처리합니다. 재시도가 일어나면 이유와 횟수를 로그로 남겨 어떤 일이 있었는지 확인할 수 있습니다.

구체적인 구현과 설정값은 패키지 콘텐츠에서 제공합니다. 대응이 들어 있다고 해서 모든 장애가 해결되는 것은 아니며, 증권사 서버가 장시간 불안정하면 요청이 끝내 실패할 수 있으므로 실전에서는 로그와 계좌 상태를 확인하는 습관이 필요합니다.

멀티 증권사 API 구조 → · 게만아 패키지 →

AI로 직접 만든다면, 이렇게 요청하세요

바이브코딩으로 증권사 API 코드를 만들 때는 기능이 돌아가는 것만 확인하고 끝내기 쉽습니다. 아래 항목을 함께 요구하면 실전에서 끊기는 일을 줄일 수 있습니다.

호출 사이 대기 시간을 코드 맨 위 설정값으로 분리해 증권사 한도에 맞게 조절할 수 있게 해 주세요.
모든 HTTP 요청에 응답 대기 제한(timeout)을 걸어 주세요.
호출 한도 초과 응답이 오면 대기 시간을 점점 늘려가며 횟수를 제한해 다시 시도하게 해 주세요. 어떤 응답이 “한도 초과”인지는 증권사 공식 문서를 기준으로 하세요.
네트워크 연결 끊김만 짧게 재시도하고, 응답 대기 시간 초과는 주문 요청에서 자동 재전송하지 않게 해 주세요.
토큰이 무효·만료로 거절되면 재발급 후 한 번만 다시 보내게 해 주세요.
재시도가 일어날 때마다 이유와 횟수를 로그로 남겨 주세요.
주문 직후에는 주문 목록이나 잔고를 조회해 실제로 접수·체결됐는지 확인하게 해 주세요.

AI로 코드 확장하는 방법 →

자주 묻는 질문

증권사 API는 요청이 올바른데도 왜 오류를 주나요?

호출이 한꺼번에 몰려 초당 호출 한도를 넘었거나, 증권사 서버가 일시적으로 불안정하거나, 네트워크 연결이 잠깐 끊겼거나, 토큰이 서버 쪽에서 먼저 무효·만료 처리된 경우가 대표적입니다. 이런 오류는 코드가 틀려서가 아니라 일시적인 상태인 경우가 많아, 잠시 기다린 뒤 다시 시도하면 정상 응답을 받기도 합니다.

API 호출 한도를 넘으면 어떻게 해야 하나요?

먼저 호출 사이에 짧은 대기를 두어 한도를 넘지 않게 하고, 그래도 한도 초과로 거절되면 대기 시간을 점점 늘려가며 정해진 횟수만 다시 시도합니다. 재시도 시점이 한꺼번에 겹치지 않도록 무작위 지연을 조금 더하면 다시 몰리는 것을 줄일 수 있습니다. 한도는 증권사마다, API마다 다르니 공식 문서를 확인하세요.

주문 요청도 오류가 나면 자동으로 다시 보내도 되나요?

조심해야 합니다. 한도 초과로 거절돼 처리되지 않은 요청은 다시 보내도 중복 주문이 되지 않지만, 응답이 오지 않아 주문이 접수됐는지 알 수 없는 경우(응답 대기 시간 초과)에 무조건 재전송하면 같은 주문이 두 번 나갈 수 있습니다. 그런 경우에는 자동 재전송 대신 주문 목록·체결 내역을 조회해 확인하는 편이 안전합니다. 판단 기준은 증권사별로 다르므로 공식 문서와 함께 확인하세요.

서버가 아예 응답하지 않으면 프로그램이 멈추지 않나요?

응답 대기 제한(타임아웃)이 없으면 프로그램이 응답을 하염없이 기다리며 멈춰 버릴 수 있습니다. 모든 요청에 응답 대기 제한을 걸어 두면 일정 시간 뒤 오류로 처리하고 다음 흐름으로 넘어갈 수 있습니다.

증권사마다 오류 코드와 제한이 같은가요?

같지 않습니다. 어떤 증권사는 HTTP 429 같은 표준 상태코드로 알려주고, 어떤 증권사는 응답 본문의 코드로 구분하며, 호출 한도와 토큰 무효·만료를 알리는 방식도 제각각입니다. 그래서 게만아 공통모듈은 증권사마다 다른 신호를 호출 한도 초과·토큰 무효/만료·일시적 연결 오류 같은 공통 기준으로 분류한 뒤, 모든 증권사에서 같은 방식으로 처리합니다.

게만아 공통모듈에는 이런 처리가 들어 있나요?

네. 게만아 공통모듈은 호출 간 대기, 응답 대기 제한, 호출 제한 시 대기 후 재시도, 일시적 네트워크 단절 재시도, 토큰 무효·만료 시 재발급 같은 대응을 모든 증권사가 함께 쓰는 공용 구조의 API 호출 계층에 넣어 전략 코드가 신경 쓰지 않아도 되도록 구현합니다. 증권사마다 다른 응답 코드는 공통 기준으로 추상화해 처리합니다.

근거와 확인 시점

이 페이지는 게만아 공통모듈의 API 호출 계층을 구현·운용하며 겪은 경험을 2026년 10월 기준으로 정리한 것입니다. 증권사의 응답 코드·호출 한도·정책은 바뀔 수 있으므로 실제 구현 전에 각 증권사 공식 문서의 최신 내용을 확인하세요.

문서 업데이트: 2026-10-16 · 교육·기술 정보 제공 목적이며 투자 권유가 아닙니다. 재시도 처리가 있어도 모든 장애를 막을 수 없습니다.