KRX 접속 차단 - 라이브러리 임포트 크래시를 로그인 실패로 강등
거래소 접속이 막히자 데이터 라이브러리를 불러오는 순간 프로세스가 통째로 죽는 버그가 터졌고, 같은 날 새 리서치 가설 하나를 사전등록부터 병합까지 끝냈습니다.
거래소 접속이 막히자 생긴 일
오늘 정오쯔음, 매매 라운드 하나가 갑자기 크래시했습니다.
원인을 추적해보니 한국거래소(KRX) 쪽에서 접속 IP를 막은 상태였습니다. 그런데 문제는 매매 로직이 아니라, 거래소 데이터를 가져오는 외부 라이브러리 자체에 있었습니다.
이 라이브러리는 불러오는 시점에 거래소에 로그인을 시도합니다. 평소엔 정상 응답(JSON)이 와서 문제가 없는데, 접속이 막히면 로그인 페이지로 리다이렉트되는 HTML이 돌아옵니다.
라이브러리는 그 응답을 JSON으로 파싱하려다 그대로 예외를 던졌고, 이게 라이브러리를 불러오는 코드 전체를 끌고 내려가면서 매매 라운드가 통째로 죽어버린 겁니다.
원인 추정과 수선
같은 날 오전에 외국인 수급 데이터를 백필하면서 거래소에 로그인을 여러 차례 반복한 일이 있었는데, 이게 접속 차단을 유발했을 가능성이 있어 보입니다.
다만 이건 시간상 겹친다는 정도의 추정이고, 확실한 인과관계까지는 확인하지 못했습니다.
수선 방향은 명확했습니다. 라이브러리의 로그인 함수를 감싸서, 어떤 예외가 나든(비정상 응답이든 타임아웃이든) "로그인 실패"라는 정상적인 실패 상태로만 처리하게 바꿨습니다.
그러면 크래시 대신 그 날짜의 거래소 데이터만 조용히 비게 되고, 나머지 매매 로직은 멈추지 않습니다. 다행히 사고 시점엔 실거래 계좌가 이미 다른 안전장치(새 창)로 매수가 묶여 있던 상태라 실제 손실로 이어지진 않았습니다.
차단은 하루가 지나도 완전히 풀리지 않아서, 거래소 재시도는 차단이 더 길어질 위험이 있어 보류하고 내일 아침에 한 번만 더 확인해보기로 했습니다.
같은 날, 새 리서치 가설 하나를 사전등록부터 병합까지
오후에는 전혀 다른 일을 했습니다. 외국인 수급 데이터를 활용하는 새 리서치 가설을 하나 세웠습니다.
문제는 이 데이터의 과거 구간을 이미 다른 분석에서 한 번 들여다본 적이 있다는 점이었습니다. 같은 데이터를 다시 보고 "맞았다"고 말하면 통계적으로 신뢰할 수 없습니다.
그래서 가설을 먼저 문서로 고정해두고(사전등록), 통계적으로 의미 있는 차이를 검출할 수 있는 최소 표본 조건을 미리 못 박아서, 그 기준을 못 넘기면 판정 자체를 열지 않기로 했습니다. 결과를 보고 기준을 바꾸는 건 금지입니다.
이 가설 코드는 AI에게 구현을 맡기고 외부 AI에게 독립 코드리뷰도 받았습니다.
리뷰에서 지적이 몇 건 나왔는데, 전부 같은 날 안에 반영해서 병합까지 끝냈습니다. 다만 이 코드는 아직 테스트 데이터로만 돌려본 단계고, 실제 데이터로 검증하는 건 다음 달로 미뤄뒀습니다. 어떤 상주 프로세스도 이 코드를 아직 가져다 쓰지 않아서, 오늘 병합 자체가 실거래에 영향을 준 건 없습니다.
그 외: 월요일 오탐과 상주 프로세스 재시작
기술적 분석 쪽 모니터링에서, 금요일 밤부터 갱신이 멈춰 있다가 월요일 아침이면 "오래 갱신이 안 됐다"는 경보가 반복해서 뜨는 문제가 있었습니다.
고정된 시간 기준이 주말과 휴장일을 고려하지 않아서 생긴 오탐이었습니다. 쉬는 날 수만큼 기준 시간을 늘리는 방식으로 고쳤고, 다음 주 월요일에 재발하는지로 완료 여부를 판단할 예정입니다.
장 마감 뒤에는 오늘 수선한 코드를 반영하기 위해 상주 중인 프로세스 여섯 개를 한꺼번에 재시작했습니다. 실행 스크립트를 미리 준비해둔 덕에 재시작 자체는 매끄럽게 끝났습니다.