코딩 에이전트 백테스트 이해력, Backtrader-Bench MCQ로 검증해보니

코딩 에이전트한테 backtrader 전략 코드를 짜달라고 하면 금방 그럴듯한 결과가 나옵니다. 문제는 그 다음이에요. 왜 이렇게 동작하는지, 손절 조건을 바꾸면 결과가 어떻게 달라지는지 캐물으면 대답이 흔들리거든요. Backtrader-Bench 논문이 이 흔들림을 숫자로 못박았습니다. 도구 없이 지식만으로 풀게 하면 정확도가 뚝 떨어지고, 절반 가까운 모델이 찍기 수준인 25%까지 붕괴했어요. 코드 생성 능력과 백테스트 이해력은 다른 지표로 따로 봐야 한다는 뜻입니다. 자동화 파이프라인에 코딩 에이전트를 물릴 계획이라면, 도구를 끊고 이해력을 따로 테스트해보는 편이 안전합니다.

무엇을 기준으로 이 벤치마크를 뜯어봤나?

제가 이 논문을 읽으며 세운 기준은 세 가지였어요. 첫째는 도구 사용 여부에 따른 정확도 격차, 둘째는 난이도별 문항에서 성능이 얼마나 무너지는지, 셋째는 채점 방식 자체의 신뢰도입니다. Backtrader-Bench는 두 개의 파이프라인으로 문항을 만들어요. 하나는 결정론적 방식으로, 다섯 가지 트레이딩 전략과 서른세 개 템플릿, 세 단계 난이도를 조합해 객관식 문제를 뽑고 독립 검증기가 정답을 다시 계산합니다. 다른 하나는 생성-풀이 필터링 방식인데, 생성기가 실행 가능한 코드로 검증된 문제를 만들고 도구 없는 풀이기가 맞히면 너무 쉬우면 버려요. 이 구조 덕분에 겉핥기로도 맞힐 수 있는 문항이 애초에 걸러진다는 점이 코딩 에이전트 자동화 검증에서 중요한 포인트입니다.

도구 없이 풀면 왜 무너질까?

논문은 11개 모델을 도구 없이 각 10회씩 돌리고, 네 가지 도구 사용 구성을 서른 개짜리 큐레이션 세트에 돌렸습니다. 도구를 쓴 에이전트는 한 번 시도에서 90.0%를 찍었어요. GPT-5.5와 Opus 4.7이 이 상위권을 차지했습니다. 반면 도구 없이 지식만으로 푼 최고 성능 모델의 평균은 73.0%였고요, 격차가 17퍼센트포인트나 벌어졌습니다. 저도 비슷하게 Claude Code로 흉내내 봤는데요, 코드 실행 없이 손절 조건을 바꾸면 몇 번째 거래에서 청산되는지 캐물으면 숫자를 얼버무리는 경우가 있더라고요. 도구 접근이 막힌 순간, 코딩 에이전트가 기대던 실행해서 확인이라는 버팀목이 사라지는 셈입니다.

채굴된 문항에서 벌어진 일

여기서 진짜 반전이 나옵니다. 연구팀이 표준 문항 말고 따로 서른여덟 개짜리 채굴 세트를 만들었어요. 이 문항들은 생성기가 실행 코드로 검증한 뒤, 도구 없는 풀이기가 못 맞히는 것만 걸러서 남긴 것들입니다. 이 세트에서 도구 없이 푼 정확도는 더 떨어졌고, 절반 가까운 모델이 무작위 추측 수준인 25%까지 주저앉았습니다. 다섯 개 전략 코드를 뚝딱 짜는 것과, 커미션 0.001·초기자본 50000 같은 파라미터 조합이 실제로 어떤 청산 시점을 만드는지 이해하는 건 완전히 다른 능력이라는 뜻이죠. 자동화 워크플로우에서 흔히 저지르는 실수가 여기 있습니다 — 코드가 한 번에 돌아가면 이해했다고 판단해버리는 거예요. 표준 벤치마크 점수만 보고 안심하면, 실전 튜닝 단계에서 근거가 엉뚱한 걸 뒤늦게 발견합니다.

이 결과를 보고 제 워크플로우를 바꾼 지점

제가 실제로 태도를 바꾼 계기는 채굴 세트의 25%라는 숫자였어요. 그전까지는 llm 코딩 에이전트가 backtrader 같은 프레임워크의 API를 잘 짜면 그 안의 로직도 어느 정도 파악하고 있다고 믿었거든요. 그런데 도구를 끄고 지식만으로 풀게 했을 때 결과가 찍기 수준으로 떨어진다는 건, 코드 생성과 개념 이해가 별도의 능력이라는 뜻입니다. 그래서 요즘은 백테스트 자동화 파이프라인에 에이전트를 투입할 때 두 단계로 나눠요. 먼저 도구를 허용한 상태에서 전략 코드를 짜게 하고, 그 다음 도구를 끈 채로 같은 전략에 대한 개념 질문을 따로 던져봅니다. 슬리피지를 늘리면 왜 특정 거래가 사라지는가 같은 걸 물어보는 식이에요. 두 번째 단계에서 막히면, 그 에이전트가 만든 코드는 검토를 한 번 더 거치게 하고요. 대안으로 논문의 독립 검증기 아이디어를 응용해 출력값을 별도 스크립트로 재계산하는 방법도 있습니다. 다만 이건 검증 코드를 따로 짜야 하는 비용이 드니, 소규모 개인 프로젝트라면 과할 수도 있어요. 결국 제가 좁힌 기준은 도구 없이도 설명이 되는가 하나였습니다.

마무리

정리하면, 도구를 쥔 코딩 에이전트는 백테스트 코드를 짜는 데는 확실히 강합니다. 90.0%라는 수치가 그걸 보여주죠. 하지만 도구를 떼고 개념만 물었을 때 절반 가까운 모델이 25% 근처까지 무너진다는 결과는, 자동화에 에이전트를 물릴 때 코드 실행 성공률만 보고 판단하면 안 된다는 경고로 읽어야 합니다. 저는 이 논문을 계기로 backtrader 자동화 스크립트를 검토할 때 왜 이렇게 나왔는지를 도구 없이 설명시키는 절차를 하나 추가했어요. arXiv 2608.11232, FinLLM 워크숍(IJCAI 2026) 발표본 기준이고, 코드와 데이터셋은 계속 갱신될 수 있어 추후 업데이트할 예정입니다.

자주 묻는 질문

Q. Backtrader-Bench는 어떤 언어·프레임워크를 대상으로 하나요? A. 파이썬 백테스트 라이브러리인 backtrader 패키지를 대상으로 합니다. 다섯 가지 트레이딩 전략(예: sma_crossover 등)을 기반으로 문항을 생성합니다.

Q. 30문항 세트와 38문항 채굴 세트는 뭐가 다른가요? A. 30문항은 균형 잡힌 큐레이션 세트로 도구 유무 비교에 쓰였고, 38문항은 생성기가 도구 없는 풀이기가 못 맞히는 것만 골라 별도로 채굴한 고난도 세트예요.

Q. 어떤 모델이 도구 사용 시 가장 높은 점수를 받았나요? A. GPT-5.5와 Opus 4.7이 도구 사용 구성에서 90.0% 정확도로 상위권을 차지했습니다.

Q. 이 벤치마크 결과를 실제 트레이딩 자동화에 그대로 적용해도 되나요? A. 이 벤치마크는 이해력 측정용 문항 풀이 실험이라 특정 종목의 매수·매도 신호를 검증한 것은 아닙니다. 실거래 자동화에 쓰려면 별도로 기간·수수료·슬리피지를 명시한 백테스트 검증이 필요해요.