[LLM]???: 누가 바이브 코딩으로 코인 자동화 같은 거 만드냐...

그래서 제가 한 번 해봤습니다

개요

지난 5월, CursorAI를 활용한 '바이브 코딩'으로 비트코인 자동매매 시스템을 만들어 3개월간 운영해 본 경험담과 수익률을 공유하고자 합니다.

프로젝트 배경

올해 초, 여러 개인적인 문제들이 해결되며 투자에 관심을 가지고 있었습니다. 때마침 구독하던 '조코딩' 님의 강의를 듣게 되었고, 이를 제 방식으로 발전시켜볼 수 있겠다는 생각이 들었습니다. 특히 당시 Cursor를 활용한 '바이브 코딩'과 데이터 파이프라인 공부를 위해 Airflow에 관심이 있었기에 개발과 학습을 병행할 수 있는 좋은 기회라고 생각해 프로젝트를 진행하게 되었습니다.

프로젝트 목표

해당 프로젝트의 목표는 다음과 같았습니다

1. LLM을 이용해서 코인 투자 자동화 시스템 구축
2. LangGraph나 FastAPI 등 실무에서 활용해본 기술로 아키텍처를 직접 설계하고 운영
3. '바이브 코딩'이 실제 개발 생산성에 어떤 영향을 미치는지 직접 경험
4. 새로운 기술(Airflow, Docker)에 대한 이해를 넓힌다.

사용 기술

가장 먼저 '어떤 기술로 시스템을 구성할 것인가'를 고민했습니다. 프로젝트에 앞서 시스템 아키텍처를 구상했으며, 구축에 사용한 도구와 아키텍처는 다음과 같습니다. 외부 API 호출 서비스를 제외한 모든 서비스는 Docker 컨테이너로 관리하도록 구성했습니다.

기술 스택

• Docker, Airflow, FastAPI, Postgres, LangGraph, Streamlit

아키텍처

1. [Cron + Airflow]: 정해진 시간마다 스케줄에 맞춰 데이터 수집 및 거래 판단 프로세스를 트리거
2. [Naver & Bithumb API]: Airflow를 활용해 실시간 뉴스 데이터와 코인 시세 정보를 수집
3. [Postgres DB]: 수집된 데이터와 과거 거래 기록, LLM의 판단 결과 등을 기록
4. [FastAPI]: LangGraph Agent를 호출하고, 실제 거래소에 주문을 넣는 API 서버입니다. Airflow로부터 추론 요청을 받고, DB에서 필요한 정보를 조회
5. [LangGraph + ChatGPT]: FastAPI를 통해 전달받은 뉴스, 시세, 과거 기록 등을 종합하여 '매수', '매도', '보류'를 결정하고 그 이유를 생성
6. [Streamlit]: DB에 기록된 모든 거래 과정과 수익률, LLM의 판단 근거를 시각적으로 보여주는 '웹 대시보드'
7. [Docker]: 해당 서비스들을 컨테이너로 관리해 서버 내 자원 독립성을 확보했습니다.

개발 과정

아키텍처 설계 이후, 개발에 앞서 크게 3가지인 서버, 아키텍처, LLM Agent를 고려했습니다.

서버

서버의 경우, 라즈베리 파이를 사용해 서버를 구성했습니다. 초기에는 AWS EC2와 같은 인스턴스를 활용해 서버를 구성하려고 했습니다. 그러나 제가 생각한 최소 스펙의 인스턴스의 경우, 월 14만원의 비용이 나왔습니다. 그래서 추가적으로 조사한 결과 라즈베리 파이로 서버를 구성할 수 있다는 것을 알게 됐고, 이를 활용해 서버를 구성했습니다. (이와 관련된 내용은 다음 포스팅[[RBP] EC2, VM 대신 16만원으로 개인 서버 구축하기]을 참고해주세요)

아키텍처

해당 프로젝트에서는 아키텍처 및 파이프라인 구성에 있어서 상당 부분 Cursor의 도움을 받아 진행했습니다.
 
데이터를 추출하고, API를 트리거 하기 위해 Airflow를 사용하기로 했습니다. Airflow라는 기술의 사용 이유와 배경 정도는 이해하고 있었지만, 실제 사용 경험이 없어 초기 코드 작성에 어려움이 있을 것이라고 생각했습니다. 그러나 Cursor의 도움으로 초기 docker 기반 서버 관리부터 보일러플레이트 코드까지 무척 쉽게 구성할 수 있었습니다.
 
뉴스 데이터나 거래 내역 관련 데이터 구성하기 위해 PostgreSQL을 DB로 사용하기로 결정했습니다. PostgreSQL 또한 Docker를 활용해 DB 서버를 구성했고, 이를 Docker 네트워크 환경 내에서 다른 서버와 연결할 수 있게 설정했습니다. 이때도 Docker 파일을 구성하는 데 Cursor의 도움을 받을 수 있었습니다.
 
실제 LLM Agent를 호출하거나 코인 주문을 진행하기 위한 API 서버로 FastAPI를 채택했고, 추론 결과 및 주문 내역을 확인하고 싶고, 실시간 현황을 확인하고 싶어 Streamlit을 활용해 대시보드를 구성했습니다. 해당 기술들은 실제 현업에서 사용하고 있는 기술들이라 비교적 쉽게 구현을 했습니다. 초기 베이스 코드를 Cursor에게 작성해서 구현하고, 추가적인 기능은 파이프라인을 구성하면서 구체화를 진행했습니다.

LLM Agent

기초적인 서비스 아키텍처를 구성하고 LangGraph로 Agent를 만들었습니다. 뉴스나 코인 정보를 호출하는 부분을 MCP로 구성하려고 기획했습니다. 그러나 토큰 계산을 해보니 비효율적이라고 판단했고, 뉴스 결과와 코인 정보는 Airflow로 API를 호출해 DB에 미리 저장해 놓도록 설정했습니다.
그리고 input 토큰 양을 줄이기 위해, 뉴스 정보를 요약해서 별도의 요약 DB에 저장했고, 실제 모델은 이를 활용해서 프롬프트를 구성해 LLM을 호출하도록 설정했습니다. 그래서 크게 두 개의 Agent로 구성했으며 이는 다음과 같은 workflow를 가지게 됩니다.

1. Airflow로 오늘 주요 뉴스와 코인 관련 API를 호출해서 DB에 저장
2. API로 호출한 뉴스 정보를 요약하는 Agent를 호출해 DB에 저장
3. 뉴스 요약 정보와 코인 관련 정보를 프롬프트에 추가해 LLM Agent APi 호출

후기

이렇게 기본적인 아키텍처와 LLM Agent 설계를 주말 이틀 만에 진행했습니다. 그 이후, LLM 모델을 변경하거나, 주문 전략을 바꾸기 위해 프롬프트를 수정하거나, 대시보드를 추가하는 등의 업데이트를 진행하며 3개월 정도 서버를 운영했습니다. 그리고 초기에 언급드렸던 3개월 동안 운영헀을 때의 수익률은 다음과 같습니다.

9월 3개월 운영한 이후 시점

 
물론 당시 시장 상황에 큰 영향을 받았기 때문에 LLM만의 성능이라고 단정하기는 어렵습니다. 참고로 블로그 작성 시점에는 수익률이 20%로 떨어지기도 했습니다. (그럼에도 서버 구축비나 전기비 정도는 벌었습니다)
 
이번 프로젝트를 통해서 수익화를 할 수 있는 서비스를 했다는 점도 좋았지만, 이와 함께 크게 세 가지의 "바이브 코딩 경험", "Airflow 사용 경험", "아키텍처 설계 경험"을 할 수 있던 점도 매우 좋았습니다.

우선, 바이브 코딩으로 새로운 기술에 대한 접근성이 매우 좋아졌다는 부분을 느낄 수 있었습니다. 저 역시 처음 접하는 Airflow를 사용해 서버를 구축하고 동작 가능한 수준까지 구현하는 데 오랜 시간이 걸리지 않았습니다. 그리고 기술에 접근성이 높아지면서, 상황에 맞는 아키텍처를 어떻게 구성하고, 어떤 기술을 활용할 것인지 이해하고 설계하는 능력이 더욱 중요해지겠구나 생각이 들었습니다.

좋은 재료와 칼이 있더라도 결국 요리를 해야 의미가 생기고, 좋은 요리를 만들기 위해서는 다양한 요리를 접하고 만들어 봐야 한다고 생각합니다. 저 또한 지금과 같이 LLM이라는 좋은 도구를 쉽게 접할 수 있는 환경에서 다양한 기술을 익히고, 다양한 서비스를 만들어보면서 경쟁력을 키워야겠다는 생각을 하며 마무리 하겠습니다.