윈도우 업데이트 재부팅, 자동매매 봇 지키는 설정 5가지

자동매매 상담에서 "봇이 밤사이 꺼져 있었다"는 말을 들으면 원인을 가장 먼저 의심하는 곳이 윈도우 업데이트입니다. 코드 버그도, 증권사 API 장애도 아닌데 아침에 보면 PC가 로그인 화면에 멈춰 있습니다. 이 글은 24시간 봇 운영 가이드(VPS 허브)에서 한 줄로만 짚었던 이 문제 하나를 떼어, 마이크로소프트 공식 문서(Manage device restarts after updates, learn.microsoft.com)의 정책 이름과 레지스트리 값을 그대로 써서 정리합니다.

1. 왜 '가장 흔한 중단 원인'인가

윈도우 업데이트 재부팅이 무서운 이유는 예고가 사람에게만 가고 봇에게는 가지 않기 때문입니다. 알림은 화면 구석에 뜨는데, 봇 PC 앞에는 아무도 없습니다. 재부팅이 끝나면 윈도우는 로그인 화면에서 멈추고, 파이썬 봇·키움 OpenAPI+ 같은 프로그램은 누가 다시 켜 주지 않는 한 일어나지 않습니다.

그래서 대책은 두 방향입니다. 재부팅을 장 밖으로 밀어내는 것(설정 ①~③)과 재부팅이 와도 봇이 혼자 복구하는 것(설정 ④~⑤). 앞의 것만 하면 언젠가 막히고, 뒤의 것만 하면 장중에 몇 분씩 끊깁니다. 둘 다 필요합니다.

2. 설정 ① 활성 시간 — 장 시간대별 권장값

'활성 시간(Active hours)'은 윈도우에게 "이 시간에는 내가 쓰고 있으니 재부팅하지 마라"고 알려 주는 값입니다. 공식 문서 기준 업데이트 후 자동 재부팅은 활성 시간 밖에서 일어나고, 기본값은 오전 8시~오후 5시, 최대 길이는 18시간(윈도우 10 1607 이전은 12시간)입니다. 경로는 설정 → Windows 업데이트 → 고급 옵션 → 사용 시간입니다.

NXT 거래 시간은 NXT·KRX 주문 라우팅 글에서 다뤘습니다. 미국주식은 서머타임 여부에 따라 KST 시각이 1시간씩 움직이므로 고정값을 적지 않았습니다 — 거래소 공식 시간표로 확인하십시오. 핵심은 24시간 봇에게 활성 시간은 '줄이는 장치'일 뿐 '막는 장치'가 아니라는 것입니다.

3. 설정 ② 정책 — 로그인 중이면 재부팅 안 함

활성 시간으로 부족하면 그룹 정책을 씁니다. 윈도우 Pro 이상에서 gpedit.msc → 컴퓨터 구성\관리 템플릿\Windows 구성 요소\Windows 업데이트로 들어가 두 가지를 켭니다.

1. 자동 업데이트 구성(Configure Automatic Updates) → 사용, 옵션 4 - 자동 다운로드 및 설치 예약
2. 예약된 자동 업데이트 설치 시 로그온한 사용자가 있을 경우 자동 다시 시작 사용 안 함(No auto-restart with logged on users) → 사용

Home 에디션처럼 gpedit.msc가 없으면 같은 값을 레지스트리에 넣습니다. 공식 문서가 밝힌 조합은 아래와 같습니다(관리자 권한 명령 프롬프트).

:: 1) 자동 업데이트를 '옵션 4'로 — 이 값이 4가 아니면 아래 정책이 적용되지 않는다
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 4 /f

:: 2) 로그인한 사용자가 있으면 업데이트 후 자동 재부팅하지 않음
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoRebootWithLoggedOnUsers /t REG_DWORD /d 1 /f

:: 확인
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"

잠깐만 피하고 싶다면 설정 → Windows 업데이트 → 업데이트 일시 중지가 가장 간단합니다. 윈도우 11 일반 빌드는 1~5주 단위로 멈출 수 있고, Microsoft Defender 정의 업데이트는 일시 중지 중에도 계속 설치됩니다. FOMC·실적 시즌처럼 이벤트가 몰린 주에 한해 쓰는 단기 수단으로 보십시오.

4. 설정 ③ VPS·윈도우 서버는 따로 본다

봇을 클라우드 VPS에 올렸다면 여기서 가장 많이 틀립니다. 공식 문서의 문장 그대로, 원격 데스크톱(RDP) 연결에서는 '활성 상태인' RDP 세션만 로그인한 사용자로 친다고 되어 있고, 로컬 로그인 사용자도 활성 RDP 세션도 없는 장치는 재부팅된다고 되어 있습니다.

즉, 봇을 켜 놓고 RDP 창의 X 버튼을 눌러 '연결 끊김' 상태로 두는 흔한 운영 방식에서는 NoAutoRebootWithLoggedOnUsers가 보호해 주지 않을 수 있습니다. 사람이 접속해 있지 않은 시간이 대부분인 VPS에서는 설정 ②를 믿으면 안 되는 이유입니다.

VPS 이미지가 Windows Server 2016 이상이면 길이 하나 더 있습니다. 같은 문서는 서버 장치에 Configure Automatic Updates의 옵션 7(설치 알림 + 재부팅 알림)을 쓰라고 권합니다. 업데이트는 내려받되 설치와 재부팅을 사람이 고르는 방식이라, 주말에 직접 접속해 처리하는 운영과 맞습니다.

:: Windows Server 2016 이상 — 설치·재부팅을 알림만 하고 사람이 실행
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v AUOptions /t REG_DWORD /d 7 /f

참고로 리눅스 VPS(우분투)에서 파이썬 봇을 돌린다면 사정이 다릅니다. unattended-upgrades의 Automatic-Reboot는 기본이 꺼져 있어 보안 패치는 깔려도 저절로 재부팅되지는 않습니다. 다만 배포판·이미지마다 설정이 바뀌어 있을 수 있으니 /etc/apt/apt.conf.d/50unattended-upgrades를 직접 열어 확인하십시오.

5. 설정 ④ 재부팅되면 봇이 혼자 켜지게

재부팅을 장 밖으로 밀어도 정전·블루스크린·강제 패치는 남습니다. 그래서 '켜지면 봇이 자동으로 뜬다'를 반드시 만듭니다. 여기서 봇의 종류가 길을 가릅니다.

REST·웹소켓 봇(KIS·키움 REST API·업비트·바이낸스 파이썬)

화면이 필요 없는 파이썬 봇은 로그인 없이 부팅만 되면 뜨게 만들 수 있습니다. 윈도우 기본 작업 스케줄러로 충분합니다.

:: 부팅 2분 뒤(네트워크가 잡힐 시간) 봇 실행 — 로그인하지 않아도 실행된다
schtasks /Create /TN "AlgoBot" /TR "C:\bot\run_bot.bat" /SC ONSTART /DELAY 0002:00 /RU SYSTEM /RL HIGHEST /F

:: run_bot.bat 예시
cd /d C:\bot
C:\bot\.venv\Scripts\python.exe main.py >> logs\bot.log 2>&1

프로세스가 죽었을 때 다시 띄우는 것까지 원하면 NSSM 같은 서비스 래퍼로 등록하는 방법도 있습니다(nssm install AlgoBot 후 AppExit Default Restart). 어느 쪽이든 앱키·시크릿을 배치 파일에 적지 말고 환경 변수나 별도 파일로 분리하십시오 — API 키 보안 글 참고.

키움 OpenAPI+ 봇(OCX·로그인 창 방식)

키움 OpenAPI+는 로그인 창을 띄우는 COM/OCX 컨트롤이라, 화면이 없는 서비스 세션에서 돌리는 구성은 현실적으로 쓰기 어렵습니다. 그래서 순서가 하나 더 붙습니다 — ① 윈도우 자동 로그온 → ② '로그온할 때' 트리거로 봇 실행 → ③ 키움 자동로그인(계좌 비밀번호 저장). 이 세 번째 단계에서 자동로그인과 버전처리가 충돌하는 함정은 키움 OpenAPI+ 자동로그인 — 무인 운영 함정 6가지에 정리했습니다.

:: 키움 OpenAPI+ 봇 — 사용자 로그온 시 실행(화면 세션 필요)
schtasks /Create /TN "KiwoomBot" /TR "C:\bot\kiwoom_bot.bat" /SC ONLOGON /RU %USERNAME% /DELAY 0001:00 /IT /F

장기적으로는 화면이 필요 없는 키움 REST API로 옮기는 것이 무인 운영에는 훨씬 단순합니다.

6. 설정 ⑤ 다시 켜진 봇은 '상태부터' 맞춘다

자동 기동만 하고 끝내면 두 번째 사고가 납니다. 재부팅 전에 낸 주문이 그사이 체결됐는데 봇은 '아직 미보유'로 알고 같은 신호에 또 매수하는 경우입니다. 그래서 봇은 시작할 때마다 메모리 상태를 버리고 증권사 서버를 정답으로 삼아 잔고·미체결을 다시 읽어야 합니다. 아래는 재부팅을 감지해 텔레그램으로 알리고, 상태를 맞춘 뒤에만 매매 루프로 들어가는 시작 루틴의 뼈대입니다.

import os, datetime, pathlib, psutil, requests

BOOT_FILE = pathlib.Path("state/last_boot.txt")

def notify(msg):
    # 토큰·채팅 ID는 환경 변수로만 — 코드에 적지 않는다
    requests.post(f"https://api.telegram.org/bot{os.environ['TG_TOKEN']}/sendMessage",
                  json={"chat_id": os.environ["TG_CHAT"], "text": msg}, timeout=5)

def check_reboot():
    boot = datetime.datetime.fromtimestamp(psutil.boot_time()).isoformat(timespec="minutes")
    prev = BOOT_FILE.read_text() if BOOT_FILE.exists() else ""
    if prev != boot:
        notify(f"[봇] 재부팅 감지 — 부팅 시각 {boot}. 상태 재조회 후 재개합니다.")
        BOOT_FILE.parent.mkdir(exist_ok=True)
        BOOT_FILE.write_text(boot)

def reconcile(broker):
    positions = broker.get_balance()       # KIS: TTTC8434R(모의 VTTC8434R) hldg_qty·ord_psbl_qty
    open_orders = broker.get_open_orders() # 키움 REST: ka10075 미체결 / 업비트: GET /v1/orders/open
    broker.save_snapshot(positions, open_orders)
    return positions, open_orders

if __name__ == "__main__":
    check_reboot()
    broker.refresh_token()                 # 재부팅 사이에 접근 토큰이 만료됐을 수 있다
    reconcile(broker)
    run_trading_loop()

각 증권사별 조회 방법은 KIS 잔고조회 연속조회, 키움 REST 미체결 ka10075에 있습니다. KIS 접근 토큰은 발급 후 일정 시간이 지나면 만료되므로 재기동 시 새로 받는 처리가 필요합니다(KIS 토큰 만료·재발급). 같은 이유로, 시작 직후 장 운영일인지도 먼저 확인해야 휴장일 새벽 재부팅 뒤 엉뚱한 주문을 내지 않습니다(KRX 휴장일 체크).

7. 사후 확인 — 언제, 왜 꺼졌나

"봇이 멈췄다"가 업데이트 때문인지 정전·하드웨어 때문인지는 윈도우 이벤트 로그로 가릅니다. PowerShell 한 줄이면 됩니다.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074,6008,41} -MaxEvents 10 |
  Format-Table TimeCreated, Id, ProviderName -AutoSize

원인이 매번 1074라면 설정 ①~③이 안 먹고 있는 것이고, 6008·41이라면 설정을 아무리 바꿔도 소용없으니 VPS로 옮기는 쪽을 검토할 차례입니다. 장애 유형별 대응 전반은 봇 장애·복구 플레이북에 있습니다.

8. 자주 묻는 질문