[핵심 요약] — NAS 위에서 AI 주식 분석 파이프라인을 만들며 설계를 세 번 갈아엎었다. LLM 역할을 분리해 단순 판단은 경량 모델로 넘기자 월 운영 비용이 4만원대에서 1만원 이하로 떨어졌다.
본 포스팅은 Synology DS423+ NAS 환경에서 자체 개발한 AI 뉴스 분석 파이프라인의 초기 아키텍처 설계 과정과, LLM 역할 분리를 통한 비용 최적화 전략을 기록한 엔지니어링 문서입니다.
아침마다 주식 앱을 켜고 종목별 뉴스를 하나씩 훑는 일이 언제부터인가 버거워졌습니다. 종목이 10개, 20개가 넘어가면서 장이 열리기도 전에 이미 피곤해졌습니다. 중요한 악재를 제목만 보고 넘겼다가 뒤늦게 확인하는 상황도 한두 번이 아니었습니다.
결국 이 작업을 AI한테 맡기면 어떨까 싶었습니다. 보유 종목 뉴스를 AI가 읽고, 호재인지 악재인지 판단해서, 매일 아침 카카오톡으로 결과만 보내주는 구조입니다. 직접 만들어보기로 했습니다.
지금은 잘 돌아가고 있습니다. 평일 오전 8시에 알아서 실행되고, 별도로 건드릴 일이 없습니다. 여기까지 오는 데 설계를 세 번 갈아엎었습니다. 이 글은 그 과정의 기록입니다.
처음 두 번의 설계가 실패한 이유
아이디어 자체는 단순했습니다. 종목별 뉴스를 긁어다가 AI에 넣고 판단 결과를 받으면 되는 구조입니다. 문제는 실제로 계산해보니 비용이 예상과 완전히 달랐다는 점입니다.
첫 번째 설계에서는 뉴스 분석, 종목 스크리닝, 최종 판단을 전부 같은 AI 모델 하나로 처리했습니다. 3,000개 종목 전체를 돌리면 한 달 운영 비용이 4만원 후반이 나왔습니다. 만들기도 전에 폐기했습니다.
두 번째 시도에서는 AI에 넘기기 전에 뉴스를 먼저 요약하는 단계를 끼워 넣었습니다. 입력 길이를 줄이면 비용도 줄겠다는 생각이었는데, 요약 자체에도 AI를 써야 하니 결국 비용이 비슷하게 나왔습니다. 이것도 접었습니다.
두 번 틀리고 나서야 방향이 보였습니다.
세 번째 시도에서 찾은 정답 — 역할을 나눠라
핵심은 한 가지 AI로 모든 걸 해결하려는 생각을 버리는 것이었습니다. 단계마다 필요한 수준이 다른데, 전부 비싼 모델로 처리하니 비용이 터진 겁니다.
세 번째 설계에서 잡은 원칙은 이렇습니다:
- 데이터 수집은 무료 소스를 최대한 활용한다
- 단순 필터링은 코드로 처리한다 (AI 없이)
- 대량 종목 판단은 저렴한 경량 모델에 넘긴다
- 보유 종목 심층 분석에만 성능 좋은 모델을 쓴다
이 구조로 바꾸고 나서 월 운영 비용이 만원 안팎으로 떨어졌습니다. 처음 설계 대비 4분의 1 수준입니다.
실제 시스템이 돌아가는 구조
운영 환경은 집에 있는 NAS(Synology DS423+)입니다. 24시간 켜져 있는 기기라 별도 서버 비용 없이 활용하고 있습니다. Docker 위에 cron을 올려서 평일 오전 8시에 자동 실행합니다. 결과는 카카오 비즈메시지 API를 통해 카카오톡으로 전송됩니다.
파이프라인은 총 6단계입니다:
- 뉴스 수집 — 여러 소스에서 종목별 최신 뉴스를 가져옵니다
- 중복 제거 — 여러 매체에 퍼진 같은 뉴스를 하나로 정리합니다
- 공시 수집 — DART에서 실적, 수주, 배당 관련 공시를 따로 모읍니다
- 판단 엔진 — 종목별로 호재인지 악재인지 AI가 분석합니다
- 시장 레이더 — 보유 종목 외에도 주목할 만한 종목을 추립니다
- 리포트 발송 — 카카오톡으로 분석 결과를 보냅니다
첫 버전을 실제로 돌리기 전까지 몰랐던 것들
설계가 확정되고 만들어서 돌려보니, 그때서야 보이는 문제가 또 있었습니다. 크게 세 가지였습니다.
뉴스 검색 API 한도를 계산하지 않았습니다. 종목마다 3가지 쿼리를 날리는 구조였는데, 보유 종목 20개 기준으로 하루 60건이 넘습니다. 한 달 평일 기준으로 따지면 1,300건에 가깝습니다. 쓰던 플랜의 월 한도가 그보다 낮아서 매달 초과 요금이 나왔습니다.
AI 모델 비용도 설계 단계에서 충분히 계산하지 않았습니다. 고성능 모델이 더 정확할 거라는 생각으로 스크리닝 단계에도 같은 모델을 썼는데, 단순 판단 작업에는 경량 모델로도 충분했습니다. 역할 분리 원칙을 설계에서 정했는데, 실제 구현에서는 그게 제대로 적용이 안 된 부분이 있었습니다.
주가 데이터를 비공식 라이브러리에 의존했습니다. 처음에는 오픈소스 라이브러리로 주가 데이터를 가져왔는데, 비공식 방식이다 보니 가끔 차단되거나 데이터가 이상하게 들어오는 일이 있었습니다. 한국 주식 특성상 데이터 반영이 늦는 경우도 생겼습니다.
이 세 가지를 어떻게 해결했나
검색 API 한도, AI 비용 구조, 주가 데이터 안정성. 이 세 가지를 해결하는 과정이 2편 내용입니다. 결과만 미리 말하면, 뉴스 소스를 더 늘리면서도 비용을 낮췄고, 주가 데이터는 공식 API로 갈아탔습니다.
만들면서 체감한 것
코드보다 설계가 훨씬 중요했습니다. 처음 두 번의 실패는 “어떻게 만드느냐”보다 “무엇을 AI에 맡기고 무엇은 맡기지 않느냐”를 제대로 잡지 못해서 생긴 문제였습니다.
구조가 자리를 잡고 나서도, 실제로 매일 돌려보지 않으면 보이지 않는 문제들이 계속 나왔습니다. 개발이 끝이 아니라 운영이 시작이었습니다. 그 이야기는 2편에서 이어갑니다.
시리즈 목차