"[260824] 07:30 리포트 안전장치 정리 + 그래픽카드 반품 결정 번복"

겹쳐 있던 방어장치를 하나로 정리하고, 지난주 반품하기로 했던 카드를 다시 쓰기로 했습니다

아침 리포트가 조용히 안 나갔던 이유

며칠 전 실험을 돌리던 중, 매일 아침 나가는 리포트가 한 번 발송되지 않은 적이 있었습니다.

원인을 다시 파보니 안전장치가 두 겹으로 걸려 있었습니다. 하나는 "실험이 그래픽카드를 쓰고 있으면 리포트도 막는다"는 오래된 규칙이었고, 다른 하나는 리포트 생성 코드 안쪽에 이미 있던 "그래픽카드가 필요하면 자동으로 CPU로 돌린다"는 별도 방어였습니다.

뒤쪽 방어가 이미 제 역할을 하고 있어서 앞쪽 규칙은 사실상 목적을 잃은 채 남아 있었던 겁니다. 심지어 수동 실험과 실제 운영을 구분하지도 않아서, 실험 한 번 돌렸다고 운영 리포트까지 막히는 부작용까지 있었습니다.

낡은 규칙을 걷어내고, 그래픽카드 접촉을 막는 시점도 더 앞으로 당겼습니다. 데이터를 불러오는 순간이 아니라 그 이전 단계에서부터 CPU로 강제하도록 고쳐서, 나중에 계산 환경이 바뀌어도 같은 문제가 재발하지 않게 만들었습니다.

같은 김에, 캐시가 오래됐는데도 정해진 시간표만 믿고 갱신을 미루는 경우를 잡아내는 감시 장치도 새로 붙였습니다. 재시작 직후 시간표가 어긋나면서 리포트가 밀리는 게 이번 사고의 근본 원인이었는데, 원인이 뭐든 상관없이 캐시가 오래됐으면 즉시 갱신하도록 만들어서 같은 사고 유형 전체를 덮게 했습니다.

리포트 해설을 AI 구독 서비스로 정식 전환

지난주 시험 삼아 붙여봤던 것을 오늘 정식으로 편입했습니다.

매일 아침 코스닥 리포트에 붙는 짧은 해설을 로컬 그래픽카드 대신, 이미 쓰고 있는 AI 구독 서비스로 생성하도록 바꿨습니다. 그래픽카드를 전혀 안 쓰기 때문에 다른 실험과 부딪힐 일이 없다는 게 가장 큰 이유였습니다.

다만 예전 로컬 방식으로 즉시 되돌릴 수 있는 경로는 그대로 남겨뒀습니다. 종목 하나에서 해설 생성이 실패해도 그 종목만 해설이 빈 채로 넘어가고 리포트 본문은 정상 발송되도록 만들어서, 무슨 일이 있어도 리포트 자체가 막히지는 않게 했습니다.

사용량 한도를 다른 용도와 나눠 써야 한다는 문제는 오늘 판정을 내렸습니다. 설령 한도가 부족해져도 잃는 건 기사 해설 몇 줄뿐이고 순위표 본문은 영향이 없으니, 감수하고 그대로 쓰기로 했습니다. 이용정책상 이런 용도로 써도 되는지는 아직 확인이 덜 됐는데, 문제가 생기면 로컬 방식으로 바로 되돌릴 수 있어서 일단 관찰 항목으로만 남겨뒀습니다.

반품하기로 했던 그래픽카드, 다시 개봉하기로

지난주 정리에서 반품하기로 결론 냈던 새 그래픽카드를 오늘 다시 개봉하기로 했습니다.

계기는 다른 걸 조사하다가 나온 곁가지 질문이었습니다. "계속 고민할 바엔 일단 써보고 정 필요 없으면 그때 차액을 돌려받자"는 쪽으로 마음이 기울었고, 이번엔 목적 자체를 예전과 다르게 잡았습니다.

예전엔 이 카드 한 장으로 기존 카드를 완전히 대체할 수 있는지를 따졌다면, 이번엔 "실험용 카드를 하나 더 두고 기존 카드와 나눠 쓰자"는 쪽입니다.

제조사 생태계가 서로 다른 카드 두 장을 나눠 쓰면, 한쪽에서 무거운 실험을 돌리는 동안 다른 쪽으로 운영을 계속 돌릴 수 있습니다. 지금처럼 카드 한 장에 실험과 운영이 몰려서 서로 순서를 기다리는 병목이 줄어드는 셈입니다.

"이 카드가 기존 카드보다 실제로 더 나은 성과를 낸다"는 판정은 여전히 미확정 상태입니다. 이번 결정은 그 판정을 뒤집은 게 아니라, 성과와 무관한 별개의 이유(실험 병렬화)가 우선한 것이라 두 이야기를 섞지 않으려고 합니다.

장착 직후 가장 먼저 할 일은 전력 제한을 거는 것입니다. 카드 두 장을 제한 없이 장시간 동시에 최대로 돌리면 전원 공급 장치 여유가 많이 남지 않는다는 걸 지난주 실측으로 이미 확인해뒀기 때문에, 캡을 걸어도 속도 손해가 거의 없는 지점을 찾아 그 값으로 자동 적용되게 부팅 스크립트부터 손봤습니다.

블로그 자동화를 점검하다 발견한 유출 위험

이 블로그의 리포트 자동 발행 코드를 다른 AI에게 검토받다가, 뜻밖의 문제를 하나 발견했습니다.

종목별 보유 수량을 그대로 공개 항목에 내보내는 구조였는데, 종목 코드는 이미 공개돼 있고 시장가도 누구나 조회할 수 있다 보니, 수량과 시세를 곱하면 포지션의 절대 금액이 그대로 역산되는 문제였습니다. 비중 변화까지 함께 보면 전체 자산 규모까지 추정할 수 있는 상황이었습니다.

절대 금액은 공개하지 않는다는 원칙을 이미 세워뒀는데, 스키마 설계 단계에서 그 원칙이 무력화돼 있었던 셈입니다. 다행히 아직 이 자동 발행 경로가 실제로 배선되기 전이라 실제 유출은 없었습니다.

수량 필드를 아예 빼고 비중(%)과 비중 변화, 진입·청산 여부만 공개하도록 스키마를 고치고, 이런 항목이 다시 섞여 들어오지 못하게 막는 테스트도 함께 걸기로 했습니다.

오늘은 방어장치가 겹쳐서 오히려 구멍이 생기는 경우, 그리고 공개해도 되는 정보처럼 보였던 값이 다른 값과 결합하면 위험해지는 경우를 둘 다 만났습니다. 둘 다 코드 자체는 틀리지 않았는데, 여러 장치가 만나는 지점에서 문제가 생겼다는 공통점이 있습니다.