서버 퇴화 감지부터 GPU 죽은 슬롯 감지까지 안전장치를 여러 겹 쌓았고, 그 사이사이 "고친 게 정말 원했던 걸 이뤘나"를 다시 검증해 틀린 전제를 찾아냈습니다.
이번 주는 두 가지 흐름이 번갈아 나타났습니다.
하나는 안전장치를 계속 새로 쌓는 흐름이었습니다. 서버 퇴화 감지, GPU 카드별 잠금, 죽은 슬롯 감지기, 테스트 격리까지 여러 층이 이번 주에 새로 생겼습니다.
다른 하나는 "고쳤다"와 "원했던 걸 이뤘다"가 다르다는 걸 반복해서 확인하는 흐름이었습니다. 코드 수정과 테스트 통과까지 끝내고도, 한 번 더 추적해보니 전제가 틀려 있던 경우가 여러 번 나왔습니다.
월요일, 사고 마무리와 그날 바로 만든 안전장치
지난주 발견된 뉴스 입력 결손 사고가 이날 아침 수선 완주로 마무리됐습니다. 다만 결손이 있던 날들이 이동평균에 며칠 더 남아 판정에 영향을 주는 부분은, 판정문에 병기해두고 다음 휴장기 이후로 근본 개선을 미뤘습니다.
그 직후 별개의 문제가 또 터졌습니다. 로컬 추론 서버가 오래 켜져 있다가 같은 글자만 반복 출력하는 "퇴화" 상태에 빠지면서, 정상 등급이 나와야 할 종목이 벤더 기본값인 "보류"로 찍혔습니다.
그날 안에 감지-격리-복구 체계를 만들어 배포했습니다. 퇴화 패턴이 감지되면 그 결과를 점수에서 빼고, 서버를 자동 재기동한 뒤 해당 종목만 재시도하는 구조입니다. 과거 사고 로그 수천 건으로 오탐 없음도 미리 확인했습니다.
같은 날 성격이 다른 결정도 하나 있었습니다. 실계좌에서 이미 제외한 실험용 전략의 관측 기간이 60거래일 중 49일째였는데, 중간 결과를 엿보고 조기 판정하지 않고 정해둔 기간을 끝까지 지키기로 했습니다. 중간에 멈출지 정하는 방식 자체가 통계적으로 함정이 있기 때문입니다.
화요일, 틀렸던 전제 두 개를 걷어냈다
이 봇은 한 계좌 아래 여러 전략이 동시에 주문을 낼 수 있어서, 체결 결과가 들어올 때마다 "이게 내 주문인가"를 가려내는 로직이 필요합니다. 이 부분은 주문 실행/안전장치 재설계(새 창) 당시 "증권사 쪽 조회 방식이 먼저 바뀌어야 한다"며 미뤄둔 채였습니다.
다시 들여다보니 그 전제 자체가 틀려 있었습니다. 조회 방식을 바꿀 필요 없이 이미 알고 있는 날짜 정보만 붙이면 되는 문제였고, 판별 기준을 주문번호 하나에서 (거래일, 주문번호) 쌍으로 바꿔 간단히 마무리했습니다.
같은 날 진행 중 작업을 전부 하나에 기록하던 문서가 며칠 사이 4천 줄을 넘어 있던 것도 정리했습니다. 완료된 기록은 아카이브로, "하지 않기로 했다"류 판단 근거는 전용 문서로 옮겨 열 배 넘게 줄였습니다.
과거에도 한 번 정리했다가 규칙 없이 방치해 한 달 안에 다시 불어난 전례가 있어서, 이번엔 문서가 다시 일정 길이를 넘거나 항목이 오래 방치되면 스스로 경고하는 점검 스크립트도 같이 만들었습니다.
수요일, 고쳤지만 목적을 달성 못 했다는 걸 알았다
야간 실행 시각을 "다음 거래일 전날 저녁"으로 옮기는 작업을 했습니다. 휴장일에 나온 뉴스가 다음 분석에 반영되지 않는 문제를 풀려는 목적이었고, 코드 수정과 테스트, 커밋까지 마쳤습니다.
그런데 외부 자문을 받아 다시 추적해보니, 뉴스를 모으는 쪽 로직이 애초에 수집 범위를 "마지막 거래일까지"로 딱 고정해두고 있었습니다. 실행 시각을 옮겨도 휴장일 뉴스는 여전히 수집 범위 밖이었던 겁니다. 이날 커밋으로 얻은 건 GPU 점유 시각이 밀린 것 정도였고, 원래 목적을 이루려면 수집 범위를 거래일 기준에서 떼어내는 별도 작업이 필요하다는 게 확인됐습니다.
보조 GPU 카드를 상시로도 굴리려는 설계도 이날 자문을 받았습니다. 지금은 카드 전체를 하나로 묶어 잠그는 방식이라, 메인 카드가 바쁘면 보조 카드 작업도 막힌다는 문제와 함께, "메모리 부족 시 관련 프로세스를 넓게 정리한다"는 기존 코드가 자칫 보조 카드 프로세스까지 함께 죽일 수 있다는 위험도 발견됐습니다.
보조 카드 서빙 설정 쪽에서는 예전에 참고했던 성능 수치가 전혀 다른 상황을 잰 것이었다는 것도 드러났습니다. 그래서 그 설정을 서두르기보다, 두 달 넘게 업데이트를 안 받은 빌드를 최신화하는 게 먼저라는 우선순위로 정리됐습니다.
목요일, 어제 못 푼 문제를 근본적으로 풀었다
뉴스 수집 범위를 거래일 기준에서 떼어내는 작업을 실제로 했습니다. 창의 끝을 "마지막 거래일"이 아니라 "실행 시각 그 자체"로 잡도록 구조를 바꿨고, 구현과 테스트, 오프라인 사전 실행까지 마쳤습니다. 실전 배포는 다른 재시작 작업과 묶어 진행할 계획입니다.
보조 카드 안전장치도 이날 실제로 배포됐습니다. 어제 발견한 위험(메모리 정리가 보조 카드까지 함께 죽일 수 있는 지점)을 카드별로 독립 잠금하는 구조로 고쳐 상주 서비스에 올렸습니다.
이날 진행한 외부 코드 리뷰에서는 더 심각한 문제가 하나 나왔습니다. 보조 카드 이상 동작 시 작동하는 안전장치가, 특정 조건에서 메인 카드의 정상 작업까지 함께 정지시킬 수 있는 지점이었습니다. 실전에서 터지기 전에 발견해 바로 고쳤고, 중요도가 낮은 문제 십여 건도 같은 리뷰에서 함께 찾아 반영했습니다.
미국장이 열리는 시간대 국내 부분 시세도 이날 검증했는데, 통계적으로 유의미한 신호를 찾지 못해 당장 분석에 넣지 않고 계속 기록만 해두기로 했습니다.
금요일, 낭비를 끄고 오염을 찾았다
같은 모델을 같은 입력으로 재현해 안정성을 재던 self-ρ 측정을 전면 퇴역시켰습니다. 샘플링 온도 자체가 결과를 흔든다는 걸 다시 확인하고 나니, 같은 자리에서 반복 측정을 자동으로 도는 게 자원 낭비라는 결론이 나왔습니다. 코드는 남기고 스위치 파일로 모든 자동 진입점을 한꺼번에 끄는 구조로 바꿔 배포했습니다.
코드 리뷰 후속 작업 중에는 더 무거운 문제를 찾았습니다. 특정 테스트들이 실제 거래 기록 파일에 가짜 행을 쓰고 있었고, 그동안 테스트 종료 시 나던 오류를 "동시 쓰기 충돌" 정도로 오인하고 넘어갔던 것이었습니다. 이 파일의 최근 기록으로 "정상 생존"을 판단하는 감시 장치가 따로 있어서, 가짜 행이 그 판단을 흐릴 수 있는 문제였습니다. 테스트를 격리된 임시 위치에 쓰도록 고치고, 섞여 있던 가짜 행은 백업 후 제거했습니다.
개장 전 시간대 시세를 새 경로로 기록만 해두는 기능도 이날 새로 붙였습니다. 아직 관측 단계이고, 다음 주 며칠간 안정성과 실제 개장 시세와의 근접도를 보고 다음 단계를 판단할 예정입니다.
토요일, GPU 병목의 진짜 원인과 죽은 슬롯
며칠 전 백업 GPU에서 동시 요청을 4개까지만 올려야 이득이라고 정리했는데, 더 큰 규모로 재보니 동시 요청 6~8개 구간에서 종목이 통째로 사라지는 현상이 나왔습니다. 이날은 이 두 가지 원인을 각각 끝까지 파고들었습니다.
처리량이 어느 지점부터 안 오르는 이유는 슬롯 수가 아니라, 이 모델이 쓰는 여러 전문가 네트워크 중 활성화된 것들의 가중치를 매번 새로 읽어와야 하는 구조 때문이었습니다. 동시 요청이 늘수록 가중치를 읽어오는 시간도 같이 늘어나 상쇄된 것이었습니다. 밀집 구조 모델과는 다른 물리라는 게 확인돼, 동시 요청을 더 올리는 시도는 접고 다른 축(양자화, 커널 효율)을 다음 순서로 올렸습니다.
종목이 사라지는 원인은 슬롯 하나가 한 번 비정상적으로 늘어지면 그 뒤로 계속 죽은 채로 남는 현상이었습니다. 이전 실거래 경로에서도 같은 종류를 관측했지만 원인을 못 찾았던 것이 이번에 재현 조건을 좁혀 잡혔습니다. 감지 로직만 만들어 커밋했고, 실제 재기동 조치는 이번 주말이 지난 뒤 붙일 계획입니다. 실측으로는 손상된 런 두 개를 정확히 잡아냈습니다.
같은 진단 과정에서, 과거 데이터로 돌리는 재생 실험에도 실거래용 이상 감시가 그대로 켜져 있어 매번 실험 프로세스를 강제로 죽이던 오작동도 발견해 껐습니다.
이번 주를 관통한 건 "그 자리에서 고치기보다 원인과 전제를 다시 확인한다"는 순서였습니다. 야간 실행 시각 조정이 목적을 달성 못 했다는 걸 알아챈 것도, 주문 판별 로직의 전제가 틀렸다는 걸 걷어낸 것도, GPU 병목의 진짜 원인을 슬롯 수가 아니라 가중치 로딩에서 찾아낸 것도 같은 패턴입니다.
동시에 감지-격리-복구, 카드별 잠금, 죽은 슬롯 감지, 테스트 격리처럼 사람이 매번 지켜보지 않아도 되게 하는 안전장치가 이번 주 곳곳에 새로 생겼습니다. 다음 주엔 뉴스 수집 구조 변경의 실전 배포, 죽은 슬롯 감지기에 재기동 조치 연결, 커널 프로파일링 결과 확인이 이어질 예정입니다.
Top comments (0)