거래소 접속차단부터 GPU 제거까지 - 장애 원인을 끝까지 추적한 한 주
거래소 접속 차단으로 생긴 크래시를 조용한 실패로 낮추고, 수동 주문으로 1주 실거래 매수팔기 테스트를 마쳤습니다. 반복되던 토큰 폐기 버그는 재시작 순서 어긋남이 원인이었고, 보조 그래픽카드 정리는 절반에서 멈추지 않고 끝까지 밀어붙였습니다.
거래소 접속 차단, 크래시 대신 조용한 실패로
주초에 거래소 접속이 막히면서 매매 라운드 하나가 통째로 크래시했습니다.
원인은 매매 로직이 아니라, 거래소 데이터를 가져오는 외부 라이브러리가 불러오는 시점에 로그인을 시도하는 구조였습니다. 접속이 막히면 비정상 응답이 돌아왔고, 라이브러리는 이를 파싱하다 예외를 던지며 전체를 끌고 내려갔습니다.
수선 방향은 "어떤 예외든 로그인 실패라는 정상적인 실패 상태로만 처리"였습니다. 이러면 크래시 대신 그 날짜 데이터만 조용히 비고, 나머지 매매 로직은 멈추지 않습니다.
같은 날 오후에는 전혀 다른 작업으로, 외국인 수급 데이터를 쓰는 새 리서치 가설을 사전등록부터 외부 AI 코드리뷰·병합까지 하루 안에 끝냈습니다. 과거에 한 번 들여다본 데이터라 사전에 가설과 최소 표본 조건을 먼저 못 박아두는 방식으로 신뢰성을 지켰습니다.
매도 기준을 느슨하게, 모의계좌도 함께 정리
며칠 전부터 진행하던 리서치가 결론을 봤습니다. 보유 종목 순위가 조금 밀려났다고 바로 정리하던 기존 방식 대신, 더 오래 들고 가도록 기준을 조정하고 보유 기간 강제 청산 장치는 폐기했습니다.
이 결론은 백테스트로 방향을 먼저 확인하고, 실제 체결 데이터로 다시 맞추는 두 단계를 거쳤습니다. 실제 매수 마찰이 시뮬레이션보다 컸다는 걸 확인하고 이를 감시하는 점검 장치를 추가로 걸어둔 뒤에야 적용을 확정했습니다.
같은 날 모의 계좌 쪽 개선(휴장일 처리, 재연결 시 주문번호 중복 처리, 주식 분할 처리)도 함께 병합했습니다. 이 코드는 외부 AI에게 독립 리뷰를 두 차례 받았고, 두 번째 리뷰에서 나온 추가 지적까지 반영한 뒤에야 올라갔습니다.
재시작 뒤 전체 테스트 스위트에서 실패와 오류가 꽤 나왔지만, 병합 전 상태로 되돌린 작업 공간에서 같은 테스트를 다시 돌려 같은 실패가 재현되는 걸 확인했습니다. 즉 이번 병합과는 무관한, 원래 있던 문제였습니다. 결과를 보고 바로 되돌리지 않고 원인을 먼저 가려낸 덕에 병합은 그대로 유지됐습니다.
수동 주문으로 끝낸 1주 실거래 테스트
실거래 계좌에서 주문이 장부에 제대로 반영되는지 끝까지 확인해본 적이 없었습니다. 그래서 1주를 사고파는 작은 테스트를 계획했습니다.
경로는 두 가지였습니다. 예전에 퇴역시킨 자동 매도 점검 경로를 되살리거나, 직접 앱에서 주문을 넣고 결과만 시스템에 기록시키는 방식이었습니다.
퇴역 경로를 되살리려면 자금 이체 같은 절차가 더 필요해서, 수동 주문 쪽으로 정했습니다. 이 방식은 자동매매 엔진의 판단 로직과는 무관한, 주문 기록·대조 계층(새 창)의 이야기입니다.
테스트는 다음 날 장중에 무사히 체결됐습니다. 정확한 수수료·세금 확인은 입금이 들어온 뒤 장부 대조를 거쳐야 가능해서, 마침 밀려 있던 다른 소액 테스트의 대조와 함께 다음 입금일에 처리하기로 했습니다.
같은 주 보유 기간을 늘리는 실험의 첫 거래일 지표는 미체결 비율·매도 뒤 유휴 현금 비율 같은 보조 지표가 기존보다 나은 방향으로 나왔습니다. 본격 판정은 20거래일 뒤로 미뤄뒀습니다.
반복되던 토큰 폐기, 원인은 재시작 순서였다
상주 프로세스를 재시작할 때마다 시세 API 인증 토큰이 서로 무효화되는 현상이 며칠째 간헐적으로 재발하고 있었습니다.
전에 있었던 재발과 이번 재발의 공통점을 맞춰보니, 두 상주 프로세스 중 하나만 재시작하고 다른 하나는 그대로 둔 시점과 겹쳤습니다. 두 프로세스가 각자 토큰을 새로 발급받는 구조라, 한쪽만 새 세대로 올라가면 서로가 상대방이 방금 발급한 토큰을 계속 무효화하게 됩니다.
뒤처진 프로세스를 재시작해 세대를 맞추자 폐기 로그가 멈췄습니다. 실거래 주문 경로가 아니라 시세 조회용이라 실제 영향은 없었지만, 두 상주를 따로 건드리면 안 된다는 걸 명확히 확인했습니다.
새로 열린 거래소 진입 실험은 중간 점검에서 유동성 기준 하나를 되돌릴 수 없이 탈락했습니다. 바로 실험을 접을지 최종 판정일까지 기다릴지를 다른 AI에게 물었고, 이 실험이 다른 질문의 답도 같이 모으고 있다는 이유로 "기다리는 게 맞다"는 답을 받아들여 예정대로 다음 판정일까지 기다리기로 했습니다.
보조 그래픽카드, 절반이 아니라 끝까지 정리
판매를 염두에 두고 일주일 관찰하던 보조 그래픽카드를, 주말 동안 시스템을 꺼둔 채로 물리적으로 제거했습니다.
재부팅 즉시 부팅 점검 유닛과 전력 제한 유닛 두 개가 적색 경보로 바뀌었는데, 둘 다 "등록된 카드 목록과 실제 하드웨어가 다르면 조용히 넘어가지 않는다"는 설계대로 작동한 결과였습니다. 의도한 동작이 그대로 확인된 셈입니다.
메인 매매 경로와 장중 보조 분석 경로가 이미 메인 그래픽카드만 쓰고 있다는 판단을 다른 AI에게 실측 기반으로 검증을 맡겼고, 맞다는 확인을 받았습니다. 다만 당장 쓰이지 않는 대기 상태 기능 몇 개는 보조 카드 없이는 기동을 거부하도록 짜여 있다는 점도 함께 짚었습니다.
처음에는 등록 목록에서 한 줄만 빼는 최소 정리로 시작했는데, 예상(2건)보다 훨씬 많은 테스트(10건)가 깨지면서 일단 되돌렸습니다. 그런데 같은 날 저녁, 절반만 걸쳐두지 말고 이번에 제대로 정리하자는 쪽으로 방향을 바꿨습니다.
등록 목록에서 보조 카드를 완전히 빼고, 깨지는 테스트는 "그 테스트 안에서만 보조 카드가 있는 것처럼" 흉내 내는 전용 장치로 고쳤습니다. 관련 상주 프로세스 네 개를 재시작해 깨끗하게 올라오는 걸 확인했고, 관련 테스트 400여 건이 전부 통과했습니다.
왜 중요한가
이번 주를 관통한 건 "애매하게 반만 고치고 넘어가지 않는다"는 공통점입니다.
거래소 접속 차단은 크래시를 그대로 두지 않고 조용한 실패로 낮췄고, 토큰 폐기는 증상만 가라앉히지 않고 두 상주의 세대 불일치라는 근본 원인까지 추적했습니다.
GPU 정리도 마찬가지였습니다. 테스트가 예상보다 많이 깨지자 일단 되돌렸지만, 거기서 멈추지 않고 그날 안에 다시 방향을 정해 끝까지 밀어붙였습니다.
실거래 1주 테스트처럼 작은 결정에서도 자동화를 되살리는 대신 손이 더 가는 수동 경로를 택한 것 역시, 하루 안에 끝낼 수 있는 확실한 방법을 고른 선택이었습니다.