AI가 나를 속인 이야기: AI 언어 모델을 믿고 자동매매를 만들었다가 깨달은 것들

AI 언어 모델을 활용해 주식 자동매매 봇 개발을 시작하는 것은 매력적인 아이디어였습니다. 초기 개발 시간을 크게 단축할 수 있을 것이라는 기대감은 현실의 복잡한 기술적, 시장적 변수 앞에서 중요한 교훈을 안겨주었습니다.

이 글은 키움증권 Open API+를 활용한 자동매매 봇 개발 과정에서 AI 언어 모델을 사용하며 겪었던 경험을 공유합니다. 이 글은 투자 손실 위험에 대한 면책 문구를 포함하며, 실제 투자 결과보다는 기술 구현 과정에 초점을 맞춥니다. 또한, 키움 API는 Windows 32bit 환경이 필수라는 점을 전제로 합니다.

목차

AI가 단축시킨 개발 초반

처음 자동매매 봇 개발을 구상했을 때, AI 언어 모델은 매력적인 출발점이었습니다. 기본적인 파이썬(Python) 코드 구조, 데이터베이스 연동(SQLite 또는 PostgreSQL), 스케줄링 로직 등 반복적인 초기 코드를 생성하는 데 많은 시간을 절약할 수 있었습니다. 특히, 기본적인 UI 구성(PyQt5)이나 웹 요청 처리 같은 일반적인 프로그래밍 패턴은 AI의 도움으로 빠르게 초안을 만들 수 있었습니다.

AI 언어 모델은 키움 API 연동 코드 초안을 생성하는 데도 기여했습니다. 키움 API의 기본적인 함수 호출 방식이나 이벤트 처리 구조에 대한 파이썬 스켈레톤 코드를 제시했습니다. 덕분에 API 문서를 처음부터 전부 읽고 이해하는 시간을 절약하고, 실제 구현에 빠르게 착수할 수 있었습니다.

현실과 부딪힌 AI 코드

그러나 AI가 생성한 키움 API 연동 코드는 실제 작동 가능한 수준까지 많은 수정이 필요했습니다. 키움 API는 윈도우(Windows) 전용 32비트 환경과 파이썬의 PyQt5를 통한 COM 객체 연동이라는 특수성을 가집니다. AI 언어 모델은 이러한 낮은 수준의 운영체제 및 COM 인터페이스의 세부 동작을 정확히 이해하고 반영하지 못했습니다.

결국, 개발자는 AI가 생성한 코드의 상당 부분을 직접 수정하고 보완해야 했습니다. 특히, 이벤트 루프 처리, 메모리 관리, 비동기 통신과 관련된 미묘한 버그들을 해결하는 데 많은 시간이 소요되었습니다. AI가 제시한 코드의 약 60~70%는 구조적 수정이나 기능 보강을 위해 직접 개입해야 하는 부분이었습니다. 개발 시간 단축 효과는 초반에만 유효했고, 실제 기능 구현에 들어서자 오히려 AI의 오류를 수정하는 데 상당한 비율의 개발 시간을 사용했습니다.

AI 전략과 현실 시장의 괴리

AI 언어 모델은 다양한 자동매매 전략이나 시장 분석 방법에 대한 아이디어를 제시하기도 했습니다. 이동평균선 교차, RSI, MACD 등 기술적 지표를 활용한 매매 전략을 설명하고, 이를 파이썬 코드로 구현하는 방법을 제안했습니다. 단순한 백테스트(Backtest) 로직까지는 어느 정도 구현 가능했습니다.

하지만 AI가 제시한 전략과 실제 시장 변수 사이에는 큰 간극이 있었습니다. 시장의 비효율성, 유동성 문제, 슬리피지(Slippage), 예상치 못한 뉴스나 거시 경제 변화 같은 현실적인 요소들은 AI 모델이 고려하기 어려운 영역이었습니다. AI가 제안한 전략은 대부분 이상적인 시장 환경을 가정하고 있었으며, 실제 환경에서의 투자 결과는 기대와 달리 크게 변동하거나 손실을 초래할 수 있음을 깨달았습니다.

결론 및 교훈

AI 언어 모델은 자동매매 봇 개발의 초기 단계에서 효율적인 보조 도구 역할을 할 수 있습니다. 그러나 키움 API처럼 특수한 환경에 의존하는 시스템이나, 투자 손실 위험이 있는 실전 영역에서는 개발자의 깊은 도메인 지식과 꼼꼼한 검토, 지속적인 수정이 필수적입니다. AI는 도구일 뿐, 시장의 복잡성과 예측 불가능성은 여전히 인간의 판단과 경험이 필요한 영역임을 다시 한번 확인했습니다.

--- 주의: 이 글에서 다루는 내용은 개인적인 개발 경험이며, 실제 투자에 적용할 경우 손실 위험이 따를 수 있습니다. 투자 결정은 반드시 본인의 판단과 책임 하에 이루어져야 합니다. ---

댓글

댓글 쓰기

이 블로그의 인기 게시물

UGREEN DXP4800PLUS NAS로 유튜브 쇼츠 자동화 시스템 구축기 (Docker · FastAPI · PostgreSQL · Edge-TTS)

이미지
 집에 NAS가 있다면 유튜브 쇼츠 자동화 시스템을 직접 구축할 수 있다. 이 글은 UGREEN DXP4800PLUS NAS 위에서 실제로 운영 중인 쇼츠 자동화 파이프라인 구축 과정을 기록한 실전 후기다. 현재 운영 현황 (2026년 6월 기준) 수집 영상: 676개 저장 스냅샷: 38,134개 성장률 계산 성공률: 95.1% 트렌드 클러스터: 10종 (IT_DEVICE, AI/자동화, 연예/엔터 등) 자동 영상 생성: Video Factory v2 개발 중 단순 성공 사례가 아니다. FastAPI 404 오류, 분류기 정확도 문제, 영상 생성 실패까지 실제 겪은 삽질과 해결 과정을 함께 담았다. 전체 파이프라인 구조 YouTube API 수집 (30분마다) ↓ PostgreSQL 저장 ↓ 성장률 계산 ↓ content_cluster 분류 (10종) ↓ format_type 분류 (6종) ↓ 트렌드 대시보드 ↓ AI 대본 자동 생성 ↓ Edge-TTS 음성 생성 ↓ FFmpeg 영상 합성 ↓ drafts 폴더 저장 처음에는 간단한 스크립트 몇 개면 끝날 줄 알았다. 실전은 달랐다. FastAPI app.mount("/") 사용 시 API 404 오류 해결 방법 FastAPI에서 정적 파일을 서빙할 때 이런 코드를 썼다. # 오류 코드 - API가 전부 404 app . mount ( "/" , StaticFiles ( directory = "static" , html = True ) , name = "static" ) @app . get ( "/api/trends" ) async def get_trends ( ) : . . . API 호출마다 404가 났다. 원인은 라우팅 우선순위였다. app.mount("/") 가 상단에 있으면 뒤에 선언된 모든 엔드포인트가 무시된다. # 해결 코드 - 항상 moun...
자세한 내용 보기

YouTube Data API 쿼터 초과를 피하는 방법 (700개 쇼츠 수집 사례)

이미지
  처음에는 단순히 API 몇 개 호출하면 끝날 줄 알았다. UGREEN DXP4800PLUS NAS 위에서 유튜브 쇼츠 자동화 시스템을 구축하면서 YouTube Data API를 쓰기 시작했는데, 실제로 운영해보니 쿼터 관리가 더 큰 문제였다. YouTube Data API를 사용해 쇼츠 수집기나 트렌드 분석 시스템을 만들다 보면 쿼터(Quota) 부족 오류를 한 번쯤 겪게 된다. 하루 10,000유닛이면 사실상 무제한이라고 생각했는데, 글로벌 AI 키워드를 몇 개 추가하고 나서 하루도 지나지 않아 쿼터 부족 오류가 발생했다. 로그를 확인해보니 범인은 search.list 였다. 같은 API라도 videos.list 는 1유닛인데 search.list 는 100유닛이다. 이 차이를 이해하기 전까지는 쿼터가 왜 사라지는지 전혀 감이 오지 않았다. 약 700개 영상, 4만 개 이상의 스냅샷을 수집하는 과정에서 부딪힌 쿼터 제한과 해결 방법을 정리한다. YouTube Data API 기본 제한 사항 YouTube Data API v3는 무료로 제공되지만 일일 쿼터(Quota)가 존재한다. 기본 할당량: 하루 10,000 유닛 주요 API별 소비 유닛: videos.list : 1 유닛 search.list : 100 유닛 channels.list : 1 유닛 search.list 가 videos.list 보다 100배 비싸다. 처음에 이걸 몰라서 쿼터를 빠르게 소진했다. 실제로 겪은 문제들 문제 1: search.list 남용으로 쿼터 소진 초기 수집기는 이런 구조였다. # 초기 구조 - 쿼터 낭비 search_results = search . list ( q = "쇼츠" , type = "video" ) # 100 유닛 for video in search_results : detail = videos . list ( id = video . id ) # 1 유닛씩 s...
자세한 내용 보기

FastAPI app.mount 사용 후 API가 404가 되는 이유와 해결 방법

이미지
필자는 UGREEN DXP4800PLUS NAS 환경에서 Docker 기반 유튜브 쇼츠 자동화 시스템을 운영하고 있다. FastAPI와 PostgreSQL로 트렌드 수집 대시보드를 구축하던 중 모든 API 엔드포인트가 404를 반환하는 문제를 겪었다. 처음에는 PostgreSQL 연결 문제라고 생각했다. API가 전부 404를 반환하니 DB 연결이 끊어진 줄 알았다. docker compose logs로 컨테이너 로그를 뒤졌고, curl로 직접 호출해보니 FastAPI까지 요청이 들어오지도 않았다. 결국 원인은 app.mount("/") 한 줄이었다. 수정하고 나서 허탈했다. 30분을 날렸다.  app.mount("/") 선언 위치 하나 때문이었다. 수정 후 즉시 정상 동작했다. 이 글에서는 해당 오류의 원인과 해결 방법, 그리고 FastAPI 내부 동작 원리까지 정리한다. 문제 상황 아래와 같이 코드를 작성했을 때 /api/trends 엔드포인트가 404를 반환한다. from fastapi import FastAPI from fastapi . staticfiles import StaticFiles app = FastAPI ( ) # 정적 파일 마운트 app . mount ( "/" , StaticFiles ( directory = "static" , html = True ) , name = "static" ) # API 엔드포인트 선언 @app . get ( "/api/trends" ) async def get_trends ( ) : return { "status" : "success" } 코드 자체는 문법적으로 문제가 없다. 하지만 실행하면 /api/trends 호출 시 404가 반환된다. 원인 분석 FastAPI는 라우팅 처리 시 선언 순서대로 매칭 을 시도한다....
자세한 내용 보기