scalalang2

멀티-에이전트 LLM 코인 투자 팀 만들기

세계 각지의 연구자 및 공학자들이 LLM을 활용해 다양한 시도를 하고 있습니다. 우리는, 인류는 이 기술로 무엇을 어디까지 할 수 있을까요? 이제는 ChatGPT를 통해 궁금증을 풀고, 창작의 영역까지 맡기는 일이 일상이 되었습니다. 그리고 최근, LLM에게 도구를 쥐어주고 직접 업무를 지시하는 에이전트 분야가 새로운 가능성을 제시하면서 많은 사람들의 시선이 모이고 있습니다.

Pangyoalto님의 글[1]을 통해 LLM 활용 분야 중 하나인 멀티-에이전트 LLM 패러다임을 접하게 되었습니다. 몇몇 논문과 정보를 살펴보면서 이를 직접 활용해보고자 암호화폐 투자 팀(crypto-ai-hedge-fund / Github)을 만드는 개인 프로젝트를 시작했는데요. 이 글에서는 프로젝트를 진행하며 참고했던 논문(Trading Agent AAAI’25)[2]와 실제 개발한 내용에 대해 간단히 공유하고자 합니다.

INDEX

멀티-에이전트 LLM의 등장

지난 몇 년간 대규모 언어 모델(LLM)은 추론, 생성, 질의응답 등 다양한 태스크를 훌륭하게 수행했습니다. 하지만 컨텍스트가 긴 태스크에 대해서는 대표적으로 두 가지 한계점이 있습니다.

① Context-Window

Context-Window란 LLM의 입력 토큰의 길이 제한 입니다. GPT-4o 모델은 최대 125,000개의 토큰을 처리할 수 있고, API로만 접근 가능한 GPT-4.1 모델과 Gemini 2.5 Pro는 8x 높은 100만 자의 토큰을 처리할 수 있습니다.

문장 생성 과정 중에 컨텍스트 길이를 초과하면 에러를 반환하거나 윈도우 내에서 앞의 문장을 지워야 하는데요. 보통 유저가 사용하는 애플리케이션은 후자를 채택해서 윈도우 앞단의 토큰을 지웁니다. 하지만, 이 방식은 LLM이 과거 정보를 유실하기 때문에 정확한 답변을 하지 못하게 되는 문제가 있습니다.

② Lost-in-the-middle

스탠포드 및 UC 버클리 공동 연구진은 긴 컨텍스트(longer-context) 환경에서 LLM의 성능을 평가하는 실험을 진행했습니다. 연구팀은 GPT 모델에 질문을 제시하고 정답을 맞히는지 측정하는데요. 이때, 답변 도출에 필요한 문서와 관련 없는 문서를 함께 배열한 뒤, 정답 문서의 위치를 바꿔가며 GPT의 성능 변화를 관찰했습니다.

실험 결과, 정답 문서가 입력 정보의 처음이나 마지막 부분에 위치할 때 정확도가 높게 나타났습니다. 반면, 정답 문서가 중간 부분에 있을 경우에는 정확한 답변을 하지 못하는 경향을 보였습니다. 이러한 현상을 Lost-in-the-middle[3] 문제 라고 합니다.

GPT의 컨텍스트 윈도우가 무제한이여도 세상 모든 정보를 전달하고 답변을 요청하면 제대로 수행하지 못하겠죠. 이러한 한계 때문에 최근에는 사용자 입력이 들어왔을 때, 관련 문서를 검색 엔진에서 찾아 컨텍스트에 추가하여 처리하는 검색 증강 생성(RAG, Retrieval Augmented Generation) 방식이 많이 활용되고 있습니다

③ Masked Attention 구조의 특성

이 문제는 ② 번의 현상과도 연관성이 있습니다. Transformer(e.g. GPT, Gemini) 기반 LLM은 문장을 순차적으로 생성하는 자기회귀구조를 사용합니다. 이때 Masked Attention은 특성상 앞서 등장한 토큰들에만 어텐션을 할 수 있고 미래의 정보를 참조하지 못하게 제한해서 문장의 일관성과 흐름은 유지했지만, 앞서 등장한 정보와 뒤에 등장한 정보 간의 연결성은 제한되는 구조적 한계를 있습니다.

최근에는 확산 모델 LLM 이나 혹은 어텐션 매커니즘 자체를 보완하는 Multi-Token Attention (Meta) 연구들이 있긴 하지만 당장 현시점에서는 아직 연구단계로 보여집니다.

멀티-에이전트 LLM의 등장

이런 문제를 해결하기 위해 멀티-에이전트 LLM을 활용할 수 있습니다. 구글의 한 연구진은 Chain-of-Agent [4]를 통해 매니저가 여러 작업자(Worker)들에게 문서의 해석을 요청하고 본인이 내용을 취합해서 답변하면 앞서 서술한 문제점을 많이 완화할 수 있다는 것을 밝혀냈습니다.

Large-Context 문제가 아니더라도, 여러 명의 LLM 에이전트가 토론, 정보 공유, 반성, 협상을 통해 문제를 해결하도록 하는 접근법은 그 자체로 매우 흥미로운 아이디어입니다. 스탠포드 연구진은 Smallvile이라는 가상의 마을에 에이전트를 배치해서 각각 일상생활을 영위하고, 서로 대화하며, 새로운 관계를 형성하는 가상의 인공사회를 만들었습니다[5].

Generative Agents: Interactive Simulacra of Human Behavior

MetaGPT[6]는 실제 소프트웨어 개발 집단의 구성원들(e.g. PM, 아키텍트, 엔지니어, QA) 구현해서 이를 상호작용 시킴으로써 다양한 소프트웨어를 만들 수 있음을 보여줬습니다.

에이전트 간의 협력적 추론 과정은 단일 LLM이 가질 수 있는 편향을 줄이고,견고한 해결책을 도출하는 데 기여합니다. 여러 에이전트가 각자의 관점에서 정보를 분석하고 의견을 교환함으로써 마치 현실 세계의 전문가 팀처럼 집단 지성을 발휘하여 더 나은 의사결정을 내릴 수 있을지도 모릅니다.

아직 멀티-에이전트가 단일 LLM보다 더 좋다고 최종 결론을 내릴 수 있을만한 사항은 아닌 것 같아서 마지막 문장을 애매하게 적었습니다.

트레이딩 팀 만들기

이처럼 LLM의 가능성과 한계를 살펴본 후, 실제로 이를 활용해보고 싶다는 생각이 들었습니다. 현업은 평범한 서버 개발자이기 때문에 개인적으로 기본 지식을 공부하면서 멀티-에이전트 LLM 암호화폐 투자 팀(crypto-ai-hedge-fund) 개발을 시작했습니다.

처음에는 ai-hedge-fund 프로젝트의 구조를 참고해서 각 전문가 에이전트의 의견을 모아서 최종 결정을 하는 방식으로 구현을 시작했고, 실제 구현한 뒤 2–3주 정도 100만원 정도를 운용했습니다.

https://github.com/virattt/ai-hedge-fund

트레이딩 봇 동작 결과

때마침 시장 상황이 좋아 수익을 올릴 수 있었지만, 암호화폐의 경우 뉴스나 기술적 분석 외에는 가치를 평가할 수 있는 데이터가 부족하다고 느껴 전문가 에이전트의 확장에 한계를 경험했습니다. 게다가 저 역시 암호화폐 도메인에 대한 지식이 부족한 점도 영향을 미쳤습니다.

이에 대한 대안으로 참고할 만한 자료를 찾던 중 TradingAgents(AAAI’25) 논문을 발견했고, 이를 바탕으로 구조를 다음과 같이 변경하게 되었습니다.

TradingAgents는 UCLA와 MIT 소속 연구자들이 공동으로 진행한 연구입니다. 실제로 학술적 가치가 높다고 보기는 어렵지만, 참고할 만한 자료가 많지 않았고 정량 평가 결과도 함께 제공되어 있어서 구조를 그대로 활용했습니다.

암호화폐 투자 팀 구성

위 그림에서 묘사된 팀 구성은 논문에서 제시한 구조와 동일합니다.

백본 모델은 처음에는 GPT-4o를 사용했었는데요. 환각증세가 너무 심해서 프롬프트를 이리저리 바꿔보다가 잘 해결이 안되더라구요. 그러다, 한 달 전에 출시된 GPT-4.1 모델로 변경했더니 환각 증세의 많은 부분이 저절로 해결되었습니다.

구현하기

① 한 달 예산 책정

저는 개인 프로젝트의 운영 비용을 반드시 월 10만 원 이하로 유지하는 것을 목표로 삼았습니다. 평범한 회사원으로서, 이 프로젝트는 취미이자 리서치 목적으로 시작한 것이기 때문에 수익에는 큰 기대를 두지 않고 있습니다.

서버는 구글 클라우드(GCP)의 us-central 리전에서 e2-micro 인스턴스를 무료로 사용할 수 있기 때문에, IP 대여 및 네트워크 비용만 부담하면 운영비를 크게 절약할 수 있습니다. 어차피 API 호출만 주로 이루어지기 때문에 고성능 인스턴스가 필요하지도 않습니다.

문제는 API 비용인데요. 현재 GPT-4.1 모델의 사용 요금은 100만 토큰당 $2.00로 책정되어 있습니다. 100만 토큰이 책 5~6권 분량이라고 해서 처음에는 비용이 크게 들지 않을 것이라 생각했지만, 매일 운영하다 보니 금세 월 10만 원 예산을 초과하게 되었습니다.

https://openai.com/api/pricing/

그래서 실제 에이전트의 대화는 마지막 거래 이후 가격 변동이 2% 이상 발생했을 때만 실행되도록 규칙을 추가해, 불필요한 API 호출을 줄였습니다. 또한 JSON 데이터를 표 형태로 바꿔 입력 토큰 수를 줄이려 노력했습니다. 입력 토큰을 줄이는 것은 단순히 비용 절감뿐 아니라, 답변 품질에도 긍정적인 영향을 미칩니다.

② 사용한 API

뉴스 정보는 텔레그램 뉴스 채널들에서 수집합니다. 감정 분석에는 X(트위터)도 고려했는데요. X에는 프로젝트에 지나치게 유리하게 올라오는 글이 많아 서 실제 시장 감정과는 차이가 있다고 판단해 일단 보류했습니다.

텔레그램 채널들

거래는 업비트 API를 이용했습니다. 마지막으로, OpenAI 모델을 사용하긴 했지만, AutoGen은 OpenAI뿐만 아니라 Gemini, Ollama 등 다양한 모델도 지원하므로 필요에 따라 쉽게 변경할 수 있습니다.

③ 구현 언어

AutoGen이 .NET 버전을 지원하기 때문에, 익숙한 C#을 사용해 구현했습니다. 처음에는 Python으로도 시도했는데 제가 Python의 타입 시스템을 제대로 활용하지 못해서 코드를 C#으로 다시 작성했습니다.

논문과의 차이점

제 구현이 논문과 다른 중요한 차이점은 ReAct[7] 프롬프트를 사용하지 않았다는 점입니다. ReAct는 LLM이 문제를 해결할 때 추론과 행동을 번갈아 수행하도록 유도하는 프롬프트 기법입니다.

논문에서는 모든 에이전트가 ReAct 프롬프트를 사용한다고 명시되어 있습니다. 하지만 실제로 구현해보니, 에이전트에게 “데이터를 조회”하는 행동을 부여하면 항상 사전에 데이터를 조회하는 행동을 반복했습니다. 아마도 정보가 없는 것보다 많은 것이 무조건 유리하다는 판단 때문이겠죠. 그래서 데이터를 미리 조회해서 입력 프롬프트로 넣어주는 방식과 실질적인 차이가 없다고 느껴, ReAct를 사용하는 것이 의미가 없다고 판단했습니다.

ReAct ReAct 논문에서는 요리 레시피를 수행하는 에이전트를 예시로 들었습니다. 예를 들어, 가상 요리 에이전트에게 레시피에 필요한 재료 중 하나가 없다는 상황을 주면, 에이전트는 스스로 선반을 “열어” 대체 재료를 찾는 등의 행동을 선택합니다.

이처럼 ReAct 방식은 단순히 데이터를 조회하는 것과 달리, 에이전트가 상황에 따라 다양한 행동을 자율적으로 선택하고, 그 과정에서 창의적인 문제 해결을 시도한다는 점에서 차별성이 있습니다.

이것 외에는 논문에서 주장한 내용을 수용했는데요. 예를 들어 LLM들이 서로 대화할 때는 순수 자연어 대신 구조화된 포맷(e.g. Markdown, JSON)을 사용해야 효율이 좋다고 합니다. 이건 MetaGPT 에서도 동일하게 주장합니다.

평가

에이전트의 수행 능력을 측정하는 메트릭은 다음 4가지를 사용했습니다.

  1. 누적 수익율 (CR, Cumulative Return)
  2. 연간 수익율 (AR, Annual Returns)
  3. 샤프 비율 (SR, Sharpe Ratio) : (자산 수익률 — 무위험 수익률)의 기댓값을 자산 수익율의 표준편차로 나눈 값입니다. 샤프비율이 높다는 것은 투자에서 “위험 대비 수익 효율이 좋다”는 의미를 가집니다. 즉, 동일한 변동성을 감수할 때 더 높은 초과수익을 얻고 있다는 뜻이며, Risk Manager가 포트폴리오를 배분할 때 이용할 수 있습니다. 무위험 수익율에는 일반적으로 국고채금리나 예금금리를 이용할 수 있는데요. 저는 암호화폐를 거래 대상으로 삼았기 때문에 비트코인의 수익율을 이용하기로 했습니다.
  4. 최대 낙폭 지수 (MDD, Maximum Draw Down) : 내가 가진 포지션에서 전고점 대비 하락율을 나타내는 지표입니다. MDD가 적을수록 안정적인 투자를 하고 있다고 볼 수 있습니다.

저는 운용 기간이 짧아 자체 데이터로서의 가치가 없기 때문에, 논문에서 제시한 평가 자료를 소개합니다. 논문에서는 기술적 분석이나 Buy&Hold 전략보다 모든 성과 지표에서 좋은 결과를 얻었다고 주장하지만

사실상 엔비디아를 대상으로 평가했다면 Buy&Hold 전략이 세상 모든 퀀트 투자 및 AI 트레이딩 전략을 가볍게 넘었을 거라서, 아래 데이터가 실제 투자 성과를 객관적으로 보여주는 자료는 아니라고 생각합니다.

https://arxiv.org/pdf/2412.20138

마무리

제가 구현하면서 가장 어려웠던 부분은 프롬프트를 작성하는 일이었습니다. 특히 해당 분야에 대한 도메인 지식이 부족하면 프롬프트를 제대로 만드는 것 자체가 쉽지 않다고 느낍니다. GPT의 도움을 받아 어떻게든 동작하도록 만들긴 했지만, 이 프롬프트가 정말 좋은지, 혹시 잘못된 부분은 부분은 없는지 판단하려면 트레이딩에 이해가 필요합니다. 그래서 투자 자체에 대해서 조금 공부할 필요성을 느끼고 있습니다.

이후에는 실제 운용을 해보면서 조금씩 고쳐보려고 하는데요. 최근에 구글의 Lee Boonstra가 발간한 66페이지의 짧은 프롬프트 엔지니어링 책이 화제였습니다. 해당 글을 참고하면서 다듬을 부분은 없는지 찾아보고 발전시켜 볼 생각입니다.

레퍼런스