멀티 LLM 페이퍼 트레이딩 봇: Claude Opus 리드 엔지니어, Gemini 전략가 구조 분석

한 개발자가 알파카(Alpaca)에서 실행되는 자율 페이퍼 트레이딩 봇을 공유했습니다. 이 봇은 역할이 정해져 있고 문서화된 거부 프로세스를 가진 multi-LLM 아키텍처를 사용합니다. 프로젝트는 5개의 Python 모듈에 약 4,900줄의 코드로 구성되어 있으며 GitHub에서 완전히 오픈소스로 제공됩니다.

아키텍처: 세 가지 역할, 제한된 범위

• 사령관 (인간): 자본 권한과 투자 전략 승인. 돈과 관련된 모든 것은 인간의 승인이 필요합니다.
• 전략가 (제미니 Pro): 투자 전략 평가로만 범위가 제한됩니다. 구현 선택, 브로커 SDK 선택, 아키텍처 결정은 허용되지 않습니다.
• 수석 엔지니어 (클로드 오퍼스 4): 모든 코드를 작성합니다. 전략가의 지시를 감사하고, 엔지니어링 현실과 맞지 않는 지시에 대해 거부권을 행사합니다. 거부는 기록에 남습니다.

어느 주체도 자율적으로 배포할 수 없습니다. 모든 의견 불일치는 현재 270개 이상의 항목이 있는 "전략가 코덱스" 문서에 기록됩니다. 코덱스는 번복을 숨기지 않습니다. 나중에 원칙이 대체되면 두 버전 모두 날짜와 함께 유지됩니다.

여기서 Multi-LLM이 효과적인 이유

제작자는 단일 LLM은 스스로와 의견을 달리할 유인이 없다고 주장합니다. 서로 다른 공급업체의 두 LLM이 제한된 범위와 문서화된 거부 경로를 가질 때 실제 엔지니어링 검토 프로세스에 더 가까운 결과가 나옵니다. 이러한 마찰은 사후 분석(post-mortem)이 아닌 설계 단계에서 의견 불일치를 강제합니다.

실제 예: 브로커 SDK 필드 불일치

전략가 지시: 14일 포지션 감소 시계를 브로커 SDK의 Position.created_at에 고정하라. 클로드(엔지니어)가 라이브 알파카 SDK에 대해 dir(Position)을 확인한 결과 해당 필드가 존재하지 않음을 발견했습니다. 대신 상태 측 원장(state-side ledger)을 구현하고 근거와 함께 교리를 기록했습니다: "브로커가 원래 평가에서 가정한 필드를 실제로 제공하지 않았습니다." 아키텍처 검토 중 클로드는 첫 번째 패스가 N개의 브로커 호출에 걸쳐 상태 잠금을 유지했기 때문에 리팩터링했습니다. 두 패스 모두 코덱스에 기록됩니다.

대상

특히 금융 자동화 또는 감사 추적과 적대적 검토가 중요한 도메인에서 multi-LLM 에이전트 워크플로우를 구축하는 개발자. 또한 명시적 거부 로깅을 통한 조정된 다중 에이전트 시스템을 탐구하는 모든 사람에게 관련이 있습니다.

저장소 및 전체 9페이지 아키텍처 문서: https://github.com/ALGEM-hub/Whitepaper