모델보다 먼저 정해야 할 것
퀀트 리서치에 AI를 도입할 때 흔히 시작하는 질문은 “어느 모델이 가장 좋은가”입니다. 그러나 실제 시스템에서는 모델 이름보다 데이터가 어디에 머무는지, 작업 경로가 얼마나 예측 가능한지, 결과를 어떻게 검증할지가 더 오래가는 결정입니다.
하나의 LLM에 뉴스 수집, 문서 검색, 코드 작성, 백테스트 해석, 주문 판단까지 모두 맡기면 편해 보입니다. 대신 비용과 권한, 장애 원인도 한곳에 얽힙니다. 더 현실적인 구조는 기능을 다섯 층으로 나누는 것입니다.
- Data: 시장 데이터, 문서, 코드와 로그를 수집하고 정규화합니다.
- Retrieval: 필요한 근거를 검색해 모델에 전달합니다.
- Model: 작업에 맞춰 클라우드 또는 로컬 모델을 선택합니다.
- Workflow: 도구 호출 순서와 권한, 상태를 통제합니다.
- Evidence: 스키마, 평가 세트, 사람의 검토로 결과를 확인합니다.
핵심은 최고 성능의 모델 하나를 고르는 것이 아니라, 각 작업을 적절한 경로로 라우팅하는 것입니다.
전체 구조: 입력부터 검증까지
Market data ─┐
Documents ─┼─> Normalize ─> Retrieve ─> Route model ─> Run tools ─> Verify
Code & logs ─┘ │ │ │
hybrid search cloud / local approval gate이 구조에서는 LLM이 데이터베이스나 주문 시스템을 직접 지배하지 않습니다. 검색기는 근거를 제공하고, 모델은 해석과 초안을 만들며, 워크플로는 실행 범위를 제한합니다. 마지막 단계에서는 기계적으로 확인할 수 있는 결과와 사람의 판단이 필요한 결과를 분리합니다.
| 판단 기준 | 낮을 때 | 높을 때 |
|---|---|---|
| 데이터 민감도 | 관리형 클라우드 API 검토 | 로컬·사설 환경 우선 |
| 작업 불확실성 | 고정 워크플로 | 제한된 에이전트 루프 |
| 반복 빈도 | 대화형 클라우드 사용 | 배치 비용·처리량 최적화 |
| 실행 위험 | 자동 처리 가능 | 승인 단계와 권한 분리 |
Cloud LLM: 복잡하고 비정형적인 작업
클라우드 LLM은 인프라를 직접 관리하지 않고도 긴 문서 분석, 코드 리뷰, 구조화된 출력, 도구 호출 같은 기능을 빠르게 시험할 수 있다는 장점이 있습니다. 모델 교체와 확장도 비교적 쉽기 때문에 사람과 대화하면서 방향이 자주 바뀌는 리서치에 적합합니다.
예를 들면 다음과 같습니다.
- 논문 여러 편의 가정과 방법론 비교
- 데이터 파이프라인 코드의 오류 가능성 검토
- 백테스트 로그에서 조사할 구간 후보 추출
- 리서치 노트의 구조와 반론 초안 작성
다만 “API 데이터는 학습에 쓰이지 않는다”와 “데이터가 저장되지 않는다”는 같은 말이 아닙니다. 공급자와 엔드포인트에 따라 악용 모니터링 로그, 애플리케이션 상태, 파일의 보존 조건이 다를 수 있습니다. 예를 들어 OpenAI는 API 입력을 기본적으로 모델 학습에 사용하지 않는다고 설명하지만, 기본 악용 모니터링 로그는 일정 기간 보존될 수 있다고 명시합니다. 민감한 전략 코드나 포지션을 전송하기 전에는 현재 계약과 데이터 통제 옵션을 다시 확인해야 합니다.
Local LLM: 데이터 경계와 반복 작업
로컬 LLM의 가장 큰 장점은 모델 자체보다 실행 경계를 직접 소유한다는 것입니다. 사내 문서, 미공개 팩터 정의, 주문 로그처럼 외부 전송이 곤란한 자료를 내부 네트워크에서 처리할 수 있습니다. 짧은 분류나 정해진 형식의 요약을 대량 반복할 때도 후보가 됩니다.
Ollama 같은 런타임은 로컬 API를 제공하므로 기존 애플리케이션과 연결하기 쉽습니다. 그러나 로컬 실행이 자동으로 안전하거나 저렴해지는 것은 아닙니다.
- 모델 파일과 임베딩 저장소도 접근 통제가 필요합니다.
- 로컬 API를 외부 네트워크에 노출할 때는 인증과 방화벽을 별도로 설계해야 합니다.
- 긴 컨텍스트는 메모리 사용량과 응답 지연을 크게 늘릴 수 있습니다.
- GPU 구입비뿐 아니라 유휴 시간, 전력, 운영 시간을 함께 계산해야 합니다.
따라서 “민감하면 로컬, 어렵다면 클라우드” 정도로 시작하되, 실제 품질과 처리량은 동일한 평가 세트로 비교하는 편이 낫습니다.
RAG: 모델을 똑똑하게 만드는 것이 아니라 근거를 공급하는 층
RAG(Retrieval-Augmented Generation)는 모델의 기억을 믿는 대신, 질문과 관련된 문서를 검색해 요청 시점에 컨텍스트로 제공합니다. 퀀트 리서치에서는 논문, 전략 명세, 데이터 사전, 과거 실험 로그를 연결할 때 유용합니다.
기본 흐름은 다음과 같습니다.
Document → Chunk → Embedding → Index
Question → Retrieve → Rerank → Prompt → Answer + Source벡터 검색은 의미가 비슷한 문서를 찾는 데 강하지만 티커, 함수명, 오류 코드 같은 정확한 문자열을 놓칠 수 있습니다. Qdrant 문서도 dense vector의 의미 검색과 sparse vector의 어휘 일치를 결합한 하이브리드 검색을 설명합니다. 금융·코드 문서라면 벡터 검색만 사용하기보다 키워드 검색과 메타데이터 필터를 같이 두는 편이 안전합니다.
평가 순서도 중요합니다. 답변 문장부터 채점하면 검색 오류와 생성 오류가 섞입니다. 먼저 다음을 따로 측정해야 합니다.
- 정답 근거 문서가 상위 검색 결과에 포함되는가
- 날짜, 시장, 자산, 문서 버전 필터가 지켜지는가
- 최종 답변이 검색된 근거와 일치하는가
- 출처가 없을 때 모델이 추측하지 않고 중단하는가
Agent: 반복문이 아니라 통제된 의사결정 층
워크플로와 에이전트는 구분해야 합니다. LangGraph 문서는 워크플로를 미리 정한 코드 경로, 에이전트를 모델이 과정과 도구 사용을 동적으로 정하는 구조로 설명합니다.
일일 데이터 적재처럼 순서가 고정된 작업은 일반 코드가 더 단순하고 재현 가능할 때가 많습니다.
fetch → validate → transform → store → report반면 “이 오류를 조사하고 필요한 로그를 선택해 원인 후보를 정리하라”처럼 다음 단계가 입력마다 달라지는 작업에는 제한된 에이전트가 유용할 수 있습니다. 이때도 모델에 모든 권한을 주는 대신 다음 경계를 둡니다.
- 읽기 도구와 쓰기 도구를 분리합니다.
- 주문, 삭제, 외부 게시에는 사람의 승인을 요구합니다.
- 최대 반복 횟수와 비용 한도를 둡니다.
- 모든 도구 입력과 결과를 추적 가능하게 남깁니다.
- 실패 시 재시도보다 중단을 우선하는 조건을 정합니다.
에이전트의 목표는 자율성을 최대화하는 것이 아니라, 불확실한 작업을 관찰 가능한 범위 안에서 처리하는 것입니다.
GPU: 소유와 임대보다 가동률을 먼저 본다
로컬 모델을 선택했다고 반드시 GPU를 구매해야 하는 것은 아닙니다. 반대로 클라우드 GPU를 빌린다고 운영 부담이 모두 사라지는 것도 아닙니다. 판단 기준은 작업의 가동률과 중단 허용도입니다.
| 작업 유형 | 우선 검토할 방식 |
|---|---|
| 가끔 실행하는 대형 모델 실험 | 시간 단위 GPU 임대 |
| 짧은 병렬 배치 | 여러 임대 인스턴스 + 작업 큐 |
| 매일 반복되는 일정한 추론 | 보유 장비와 API 총비용 비교 |
| 중단되면 안 되는 장기 작업 | 안정형 인스턴스 + 체크포인트 |
| 민감 데이터의 상시 처리 | 내부 GPU 또는 사설 배포 |
비용 비교에는 시간당 가격만 넣으면 안 됩니다. 모델 로딩 시간, 데이터 전송, 볼륨 보관, 실패한 작업의 재실행, 운영자의 관리 시간까지 포함해야 합니다.
검증: 자연어 평가만으로 끝내지 않는다
생성 결과가 그럴듯하다는 것은 검증이 아닙니다. NIST의 생성형 AI 위험관리 프로필은 신뢰성 고려를 설계, 개발, 사용, 평가 전 과정에 포함하는 접근을 제시합니다. 퀀트 환경에서는 결과의 위험도에 따라 검증 강도를 달리하는 것이 현실적입니다.
자동 검증 가능한 항목
- JSON 스키마와 필수 필드
- 숫자 범위와 단위
- 티커와 날짜 형식
- SQL 읽기 전용 여부
- 인용된 문서 ID의 실제 존재 여부
평가 세트가 필요한 항목
- 검색 결과의 recall@k
- 분류 정확도와 클래스별 오류
- 답변의 근거 일치도
- 동일 입력을 반복했을 때의 변동성
- 모델 또는 프롬프트 변경 전후 회귀
사람의 승인이 필요한 항목
- 실거래 주문과 포지션 변경
- 외부 공개 리포트
- 전략 규칙이나 리스크 한도 수정
- 민감 데이터의 외부 전송
특히 LLM이 만든 시장 해석은 트레이딩 신호가 아니라 추가 조사가 필요한 가설로 다루는 편이 맞습니다.
최소 구성으로 시작하는 순서
처음부터 에이전트 플랫폼 전체를 구축할 필요는 없습니다. 다음 순서면 각 단계의 효과를 분리해 확인할 수 있습니다.
- 반복 빈도가 높고 정답을 판정할 수 있는 작업 하나를 고릅니다.
- 모델 없이 실행되는 기존 규칙 기반 기준선을 만듭니다.
- 클라우드 모델로 품질 기준선을 측정합니다.
- 민감도나 비용 문제가 확인되면 로컬 모델을 같은 평가 세트로 비교합니다.
- 최신 문서가 필요할 때만 RAG를 추가하고 검색 품질을 먼저 측정합니다.
- 작업 경로를 미리 정할 수 없을 때만 에이전트 루프를 도입합니다.
- 쓰기 작업 앞에는 승인 단계를 둡니다.
이 순서를 지키면 모델, 검색, 오케스트레이션 문제를 한꺼번에 디버깅하는 상황을 피할 수 있습니다.
정리
AI 리서치 스택의 중심은 특정 모델이 아닙니다. 데이터 경계, 검색 근거, 모델 라우팅, 도구 권한, 검증 절차를 분리하는 구조가 중심입니다.
- Cloud LLM은 복잡하고 비정형적인 대화형 작업에 배치합니다.
- Local LLM은 민감 데이터와 반복 배치의 후보로 둡니다.
- RAG는 최신성과 출처가 필요한 질문에만 붙입니다.
- Agent는 경로가 정말 동적인 작업에 제한적으로 사용합니다.
- GPU는 소유 여부보다 가동률과 운영비로 판단합니다.
- Evidence layer는 결과가 실제 행동으로 넘어가기 전에 오류를 걸러냅니다.
최종 목표는 AI가 모든 판단을 대신하는 시스템이 아니라, 리서처가 더 빠르게 조사하면서도 어떤 데이터와 근거로 결론에 도달했는지 되짚을 수 있는 시스템입니다.
참고 자료
- OpenAI API 데이터 통제 안내
- Ollama API 소개
- Qdrant 검색 및 배포 구조 개요
- LangGraph 워크플로와 에이전트 패턴
- NIST AI RMF: Generative AI Profile
같이 보면 좋은 글
로컬 LLM과 클라우드 모델, 퀀트 리서치 환경에서는 무엇이 더 유리한가
