[260707] 앙상블의 한 축이 6개월 넘게 완전히 비어있었다

어제는 유독 일이 많았습니다. 하나는 밤사이 발견한 꽤 심각한 사고 복구였고, 나머지는 그 김에 진행한 인프라 개선이었습니다.

리서치 파이프라인이 완전히 무근거로 동작하고 있었다

멀티에이전트 리서치 파이프라인(여러 로컬 LLM 에이전트가 분석/반박/최종판단을 나눠 맡는 구조)에서, 실제 데이터를 조회해야 하는 단계가 아예 도구 호출 자체를 못 하고 있었습니다. 모델이 "조회하겠습니다"라는 의도만 텍스트로 남기고, 실제로는 아무 데이터도 안 가져온 채 그걸 근거로 리포트를 쓰고 있었던 겁니다. 지난번에 로컬 LLM 3종을 정식 비교했을 때 "이 모델이 제일 깨끗하다"고 결론 냈던 게, 사실은 "실패율/등급분포만 봤지 리포트 안에 실제 데이터가 있는지는 확인 안 했던" 맹점 때문이었다는 게 뒤늦게 드러났습니다.

모델을 바꿔서 도구 호출 문제는 해결했는데, 그 다음에도 리포트의 절반 이상이 여전히 이상했습니다. 다른 AI에게 원인 진단을 도와달라고 부탁해서 로그를 더 깊이 파본 결과, 더 근본적인 원인이 나왔습니다 — 로컬 LLM 서버의 컨텍스트 윈도우(모델이 한 번에 읽을 수 있는 입력 길이)가 조용히 기본값으로 방치돼 있어서, 실제로 필요한 입력의 상당 부분이 잘려나가고 있었던 겁니다. 시스템 프롬프트나 종목 관련 맥락이 통째로 날아가면서 모델이 엉뚱한 소리를 하거나 자기가 만든 숫자를 스스로 잘못 읽는 일까지 벌어졌습니다.

이 프로젝트에서 "조용한 기본값" 때문에 사고가 난 게 이번이 처음이 아니라서, 원인을 찾고 나니 오히려 익숙한 패턴이었습니다. 컨텍스트 윈도우를 넉넉하게 늘리고, 실제로 잘림이 없는지 스모크테스트로 확인한 뒤에야 전체를 다시 돌렸습니다.

덤으로 하나 더 발견한 게 있는데, 가격 목표치를 산출하는 단계가 정량적인 계산 근거 없이 정성적인 서술만 하고 있었습니다. 실제 사례에서 이 파이프라인이 낸 목표가가 실제 시장 컨센서스보다 상당히 낮게 나온 적이 있었는데, 원인은 "정보가 부족해서"가 아니라 "애초에 숫자를 계산하는 공식 자체가 없어서"였습니다. 지금은 "계산 근거를 명시 못 하면 목표가를 비워두라"는 원칙을 추가해뒀고, 이건 아직 검증 중입니다.

교훈: 모델이나 프레임워크 문서에 "이 기능을 지원한다"고 적혀 있어도 절대 그대로 못 믿습니다. 항상 실제로 호출해서 눈으로 확인해야 합니다.

밤샘 복구 중 저지른 소소한 실수들

근본 원인 진단 자체는 잘 됐지만, 복구 과정에서 운영 실수도 몇 가지 했습니다. 기록 삼아 남겨둡니다.

• 어떤 조건이면 자동 스케줄러가 멈추도록 코드를 짜놓고, 정작 그 조건을 실제로 만드는 걸(파일 하나 생성) 깜빡해서 자동 작업과 수동 작업이 충돌한 일이 있었습니다. "코드를 추가했다"와 "그 코드가 전제하는 상태를 실제로 만들었다"는 별개라는 걸 다시 배웠습니다.
• 정리 목적으로 어떤 프로세스를 대상 특정 없이 종료하는 명령을 돌렸다가, 하필 그 시점에 다른 정상 작업이 쓰고 있던 걸 같이 끊어버린 적도 있습니다. 다행히 자동으로 다시 살아나서 재로딩 시간 정도만 손해봤습니다.
• 계속 이어붙는 로그 파일을 "마지막 줄"만 보고 지금 상태라고 착각한 것도 두 번 정도 있었습니다. 여러 번의 실행 기록이 한 파일에 섞여 있으면, 마지막 줄이 방금 것이라는 보장이 없다는 걸 놓쳤습니다.

셋 다 근본 원인과는 무관한, 여러 프로세스를 빠르게 켜고 끄는 와중에 생긴 절차적 실수라 따로 적어둡니다.

서빙 엔진을 하나 더 붙여봤다

로컬 LLM을 돌리는 서버 소프트웨어를 하나 더 구축해서 비교해봤습니다. 같은 모델, 같은 GPU인데도 서버 계층의 오버헤드가 줄어서 실측으로 1.5배 정도 빨라졌습니다. 이 정도면 그래픽카드를 하나 더 살까 고민하던 계획을 급하게 진행 안 해도 되겠다 싶어서, 하드웨어 업그레이드 결정을 보류했습니다. 이 참에 더 큰 모델(현재보다 훨씬 큰 파라미터 수)도 테스트해봤는데, 지금 GPU 메모리로는 초당 처리량이 실용 수준에 한참 못 미쳐서 이쪽도 당분간은 보류입니다.

새 엔진은 아직 기본값은 아니고, 옵션으로 켜서 쓰는 상태입니다. 전체 코스피 50종목 야간 프로덕션을 이걸로 한 번 끝까지 돌려봤는데 깨끗하게 완주했습니다 — 실제 운영 규모에서도 되는지 확인한 것.

야간 프로덕션 재설계

위 작업들을 하다 보니 야간 자동 분석 스케줄 자체도 다시 짰습니다.

• 분석 대상 종목 수를 늘리고, 시작 시각을 장 마감 이후로 앞당겼습니다(전체를 하룻밤 안에 끝내려면 필요한 조정).
• 감정/뉴스 관련 리포트가 6개월 가까이 계속 비어있었던 버그를 찾았습니다. 원인은 어려운 게 아니라, 그 분석 역할 자체가 애초에 파이프라인 구성에서 빠져 있었던 단순한 누락이었습니다.
• 데이터 갱신 과정에서 외부 조회 하나가 타임아웃 없이 걸려 있으면 전체 갱신이 몇 시간씩 멈추는 구멍도 있었어서, 타임아웃과 회로차단 로직을 추가했습니다.
• GPU 하나를 여러 작업이 나눠 써야 하는 구조라, 다른 AI와 함께 자원 배분 원칙을 다시 정리했습니다. 무거운 작업이 GPU를 쓰고 있는지 감지하는 로직에 새 엔진 쪽이 안 잡히던 구멍을 메웠고, 종목 하나가 계속 빠르게 실패하면 그걸 "정상 완료"로 착각하지 않도록 안전장치를 넣었고, 관련 시각 설정값들이 여기저기 흩어져 있던 걸 한 곳으로 모았습니다.

아직 남은 일도 있습니다 — 새 자동 스케줄을 실제로 켜기 전에 안전장치 하나를 더 추가하기로 해서, 지금은 일시정지 상태로 다음 작업을 기다리고 있습니다.

---

하루치고는 꽤 많이 건드렸습니다. 특히 첫 번째 사고는 "지표가 깨끗해 보인다고 안심하면 안 된다"는 걸 다시 한번 확인한 계기였습니다.

#퀀트, #AI개발일지, #인시던트, #트레이딩봇, #LLM