VPS에서 직접 주식 조사 에이전트 구축하기

자체 호스팅 주식 조사 에이전트란 무엇인가

자체 호스팅 주식 조사 에이전트는 사용자가 소유한 서버에서 실행되는 소형 프로그램입니다. 이 프로그램은 일정에 따라 시장 데이터를 가져와 로컬 데이터베이스에 저장하고, 이를 필터링한 뒤 거대 언어 모델(LLM)에 전달하여 변경 사항을 요약하게 합니다. 이 에이전트는 데이터를 읽고 필터링하는 역할을 수행합니다. 이 프로그램은 직접 거래를 수행하지 않으며, 이 가이드의 어떠한 내용도 투자 조언이 아닙니다.

두 사람이 이 시스템을 처음부터 구축하더라도 서로 다른 라이브러리를 선택할 수 있지만, 결국 동일한 네 가지 구성 요소를 갖추게 됩니다. 가격과 기본 데이터를 제공하는 피드, 지금까지 가져온 모든 데이터를 보관하는 로컬 저장소, 타이머에 맞춰 저장소를 갱신하는 작업, 그리고 필터링된 데이터를 문장으로 변환하는 LLM 계층입니다. 이 가이드는 Python, DuckDB, systemd 타이머, 그리고 Claude API(애플리케이션 프로그래밍 인터페이스)를 사용하여 이러한 구조를 구축합니다. 실행은 별도의 작업이며 고유한 실패 유형을 가지므로, 이는 트레이딩 봇을 위해 설정된 VPS에서 수행해야 합니다.

네 가지 구성 요소와 각 역할

피드(The feed)는 외부와 통신하는 유일한 부분입니다. 티커와 날짜 범위를 요청하는 방법과 행 데이터를 반환하는 방법을 알고 있습니다. 피드 이후의 모든 단계는 피드가 아닌 데이터베이스를 읽으므로, 피드에 장애가 발생해도 화면이 깨지는 대신 하루치 데이터가 누락되는 수준으로 피해가 제한됩니다.

저장소(The store)는 이 작업의 핵심 목적입니다. 기록하지 못한 일일 종가는 보통 나중에 다시 가져올 수 있습니다. 하지만 장중 시세, 수정 전의 추정치, 재작성 전의 펀더멘털 수치는 다시 가져올 수 없습니다. 저장소는 데이터가 발표된 당시에 실제로 무엇을 말했는지에 대한 기록을 구축하는 방법입니다.

스케줄러(The scheduler)는 새로고침 시점을 결정합니다. 서버 환경에서는 systemd 타이머를 사용하며, 이것이 코드보다 VPS가 더 중요한 이유입니다.

LLM 계층(The LLM layer)은 SQL이 생성한 짧은 텍스트 블록을 읽고 요약을 작성합니다. 이 계층은 데이터베이스에 직접 연결하거나 쿼리를 생성하지 않습니다. 만약 모델이 SQL을 직접 작성한다면, 잘못된 토큰 하나가 유창한 문장 속에서 잘못된 숫자로 변할 수 있으며 이를 대조할 방법이 없습니다. SQL이 숫자를 생성하고 모델이 산문만 작성한다면, 모델은 산문에서만 오류를 범할 수 있고 사용자는 전송된 행 데이터를 통해 산문의 내용을 검증할 수 있습니다.

노트북 대신 VPS에서 실행해야 하는 이유

스케줄러가 그 이유입니다. 뉴욕 시간으로 16:00인 미국 시장 마감은 베를린에서는 22:00, 자카르타에서는 다음 날 04:00입니다. 노트북은 이 두 시간대 모두 잠자기 상태일 가능성이 높습니다. 실행을 놓치면 단순히 기록이 늦어지는 것 이상의 손실이 발생합니다. 일봉 데이터는 나중에 다시 가져올 수 있지만, 수정되는 데이터는 그렇지 않으므로 기록의 공백이 영구적으로 남게 됩니다.

두 번째 이유는 더 작지만 여전히 실질적입니다. 서버는 로그인 셸이 없고 하나의 작업만 수행하는 시스템 사용자가 소유한 단일 파일에 하나의 API key를 보관합니다. 웹 서핑을 함께 하는 노트북에서 이러한 환경을 구성하기는 훨씬 어렵습니다. 코드는 물론 모델의 입력값에서도 key를 분리해야 하며, 이에 관한 내용은 AI 에이전트에서 API key를 안전하게 관리하는 방법에서 다룹니다.

용량 산정: 디스크, RAM, 토큰

디스크 용량 산정은 간단합니다. 일일 데이터는 티커당 거래일마다 한 행씩 생성되며, 미국 증시의 연간 거래일은 약 252일입니다.

[
  {
    "label": "20 tickers",
    "rows_after_1y": "5,040",
    "rows_after_10y": "50,400"
  },
  {
    "label": "100 tickers",
    "rows_after_1y": "25,200",
    "rows_after_10y": "252,000"
  },
  {
    "label": "500 tickers",
    "rows_after_1y": "126,000",
    "rows_after_10y": "1,260,000"
  }
]

20개 티커를 기준으로 1년 후에는 5,040 행이 생성됩니다. 500 tickers 라인은 10년 후 1,260,000 행에 도달합니다. 각 행은 날짜와 몇 개의 double형 데이터로 구성되며, DuckDB는 열 단위로 압축하여 저장하므로 기가바이트 단위가 아닌 수십 메가바이트 수준입니다. 이 추정치를 맹신하지 마십시오. 첫 번째 백필(backfill)을 마친 후 du -h /opt/research/data/market.duckdb를 실행하여 직접 확인한 수치를 사용하십시오.

RAM은 소규모 VPS에서 문제가 될 수 있습니다. DuckDB는 기본적으로 단일 쿼리를 위해 시스템 메모리의 상당 부분과 모든 코어를 점유합니다. 이는 분석 전용 서버에는 적합하지만, 다른 서비스를 함께 운영하는 2 GB 사양의 서버에서는 문제가 됩니다. 전체 가격 테이블에 대해 집계 쿼리를 수행하면 커널에 의해 프로세스가 강제 종료될 수 있으며, systemd는 Main process exited, code=killed, status=9/KILL을 보고하고 journalctl -k은 메모리 부족(OOM)으로 인한 종료를 보여줍니다. memory_limit과 threads를 명시적으로 설정하면 쿼리가 종료되는 대신 속도가 조절됩니다.

토큰 사용량은 추정하지 말고 측정해야 합니다. 모든 Messages API 응답에는 input_tokens과 output_tokens를 포함하는 usage 객체가 포함됩니다. 호출할 때마다 이 값을 테이블에 기록하면 일주일 후 실제 사용량을 파악할 수 있으며, 이를 확인하는 시점의 모델 단가에 곱하여 비용을 산출합니다. 계획을 세울 때 고려할 만한 두 가지 안정적인 요소가 있습니다. 모든 Claude 모델에서 출력 토큰은 입력 토큰보다 비싸게 책정되므로, 메모를 200단어로 제한하는 것이 전송 데이터를 줄이는 것보다 비용 절감에 더 효과적입니다. 또한 프롬프트 캐싱은 하루에 한 번 실행하는 작업에는 도움이 되지 않습니다. 캐시 유지 시간은 분 단위로 측정되므로, 다음 실행 시점에는 캐시된 블록이 만료되어 전체 입력 비용을 다시 지불해야 하기 때문입니다. 캐싱은 한 번의 실행으로 동일한 대용량 텍스트 블록에 대해 여러 번 호출을 수행할 때 비용 효율적입니다.

Install the pieces

sudo apt update
sudo apt install -y python3-venv
sudo useradd --system --create-home --home-dir /opt/research --shell /usr/sbin/nologin research
sudo -u research python3 -m venv /opt/research/venv
sudo -u research /opt/research/venv/bin/pip install duckdb pandas yfinance anthropic
sudo install -d -o research -g research -m 750 /opt/research/data

Check the install before you write any code:

sudo -u research /opt/research/venv/bin/python -c 'import duckdb, yfinance, anthropic; print("ok")'

That prints ok. If you skipped the virtual environment and ran pip install against the system Python, Ubuntu 24.04 stops you with error: externally-managed-environment, because the distribution owns /usr/lib/python3 and refuses to let pip write there. The venv is not politeness. It is the only directory pip is allowed to touch.

The API key goes in a file the service user can read and nobody else can:

sudo install -d -m 755 /etc/research
sudo install -m 640 -o root -g research /dev/null /etc/research/env
sudoedit /etc/research/env

Put one line in it, with no quotes and no export, because systemd parses this file itself instead of passing it to a shell:

ANTHROPIC_API_KEY=sk-ant-your-key-here

저장소: 두 개의 테이블

# /opt/research/store.py
import duckdb

DB = '/opt/research/data/market.duckdb'

SCHEMA = [
    """
    CREATE TABLE IF NOT EXISTS prices (
      ticker VARCHAR,
      day    DATE,
      open   DOUBLE,
      high   DOUBLE,
      low    DOUBLE,
      close  DOUBLE,
      volume BIGINT,
      PRIMARY KEY (ticker, day)
    )
    """,
    """
    CREATE TABLE IF NOT EXISTS runs (
      started_at    TIMESTAMPTZ,
      model         VARCHAR,
      input_tokens  BIGINT,
      output_tokens BIGINT,
      hits          BIGINT
    )
    """,
]

def connect(read_only=False):
    con = duckdb.connect(DB, read_only=read_only)
    con.execute("SET memory_limit='512MB'")
    con.execute('SET threads=2')
    if not read_only:
        for statement in SCHEMA:
            con.execute(statement)
    return con

(ticker, day)의 기본 키(primary key)는 새로고침을 반복해도 안전하게 유지해 주는 핵심 요소입니다. INSERT OR REPLACE는 특정 티커와 날짜에 대해 이미 존재하는 행을 덮어쓰므로, 백필(backfill)을 두 번 실행해도 테이블 데이터가 중복되지 않습니다. 기본 키가 없다면, 충돌 후 재실행 시 모든 바(bar) 데이터가 조용히 중복되며, 이후 계산하는 모든 평균값은 오류 메시지 없이 잘못된 결과로 이어집니다.

DuckDB는 단 하나의 프로세스만 파일을 쓰기 모드로 열 수 있도록 허용합니다. 두 번째 쓰기 프로세스는 즉시 Could not set lock on file 오류와 함께 실패하며, 이때 해당 파일을 점유 중인 PID가 함께 표시됩니다. 실제 환경에서는 다른 터미널에 열어둔 대화형 duckdb 셸이 원인인 경우가 많습니다. 읽기 프로세스는 read_only=True를 통과하며, 이것이 connect에 해당 플래그가 필요한 이유입니다. 여러 프로세스가 동시에 쓰기 작업을 수행해야 한다면 이는 다른 엔진의 영역입니다. SQLite는 WAL 모드에서 한 명의 작성자가 커밋하는 동안 읽기 작업을 허용하며, busy timeout 설정을 통해 다른 작성자가 실패하는 대신 대기하도록 만들 수 있습니다. 서버 워크로드를 위한 DuckDB와 SQLite 비교에서 두 엔진을 비교하고, VPS에서 SQLite 운영하기에서 WAL 모드를 안정적으로 설정하는 방법을 다룹니다.

갱신 작업

# /opt/research/refresh.py
import sys
import pandas as pd
import yfinance as yf
from store import connect

TICKERS = ['AAPL', 'MSFT', 'KO', 'SAP', 'TSM']
FIRST_DAY = '2016-01-01'
COLS = ['ticker', 'day', 'open', 'high', 'low', 'close', 'volume']

def fetch(ticker, start):
    df = yf.Ticker(ticker).history(start=start, auto_adjust=True)
    if df.empty:
        return None
    df = df.reset_index()
    stamps = pd.to_datetime(df['Date'])
    if stamps.dt.tz is not None:
        stamps = stamps.dt.tz_localize(None)
    df['day'] = stamps.dt.date
    df['ticker'] = ticker
    df = df.rename(columns={'Open': 'open', 'High': 'high', 'Low': 'low',
                            'Close': 'close', 'Volume': 'volume'})
    return df[COLS]

def main():
    con = connect()
    empty = 0
    for ticker in TICKERS:
        last = con.execute('SELECT max(day) FROM prices WHERE ticker = ?',
                           [ticker]).fetchone()[0]
        rows_df = fetch(ticker, str(last) if last else FIRST_DAY)
        if rows_df is None:
            print(ticker + ': feed returned no rows', file=sys.stderr)
            empty += 1
            continue
        con.register('rows_df', rows_df)
        con.execute('INSERT OR REPLACE INTO prices '
                    'SELECT ticker, day, open, high, low, close, volume FROM rows_df')
        print(ticker + ': ' + str(len(rows_df)) + ' rows')
    con.close()
    if empty == len(TICKERS):
        print('every ticker returned nothing: the feed is broken', file=sys.stderr)
        sys.exit(1)

main()

수동으로 한 번 실행합니다:

sudo -u research /opt/research/venv/bin/python /opt/research/refresh.py

첫 실행 시에는 수년간의 데이터를 채워 넣으므로 티커당 수천 건의 행이 출력됩니다. 1분 뒤 다시 실행하면 이미 저장된 마지막 날짜부터 작업을 시작하므로 각 줄에 1~2개의 행만 표시됩니다. 이 두 번째 실행이 실제 테스트입니다. 만약 여전히 수천 건이 출력된다면 max(day)가 아무것도 반환하지 않는 것이며, 매일 밤 전체 기록을 다시 쓰고 있는 상태입니다.

df.empty 검사는 파일에서 가장 중요한 줄입니다. Ticker.history()은 잘못된 심볼이나 상장 폐지된 심볼에 대해 오류를 발생시키지 않습니다. 대신 가격 데이터를 찾을 수 없다는 경고(라이브러리 버전에 따라 문구는 다를 수 있음)를 출력하고 빈 DataFrame을 반환합니다. 이 검사가 없는 작업은 아무것도 기록하지 않고도 종료 코드 0을 반환하며, systemd는 정상적으로 실행된 것으로 표시하지만 테이블은 더 이상 늘어나지 않습니다. 매일 같은 행만 반환되는 화면을 보고 나서야 몇 주 뒤에야 이 사실을 알게 됩니다.

타임스탬프 처리에도 이유가 있습니다. 피드가 반환하는 인덱스에는 거래소의 시간대가 포함될 수 있으며, 오프셋을 단순히 제거하는 것은 UTC로 변환하는 것과 다릅니다. 도쿄 세션의 자정 시간은 UTC로 변환하면 이전 날짜가 되므로, UTC 변환을 수행하면 모든 일본 시장 데이터가 하루씩 밀려 기본 키(primary key)가 깨집니다. tz_localize(None)은 일봉 데이터의 의미에 부합하도록 거래소 고유의 세션 날짜를 그대로 유지합니다.

장 마감 시점에 실행되는 타이머

미국 시장은 뉴욕 시간 기준 16:00에 마감하며, 마지막 거래 기록이 정산되기까지 몇 분이 소요되므로 작업은 16:20에 실행합니다. 이를 UTC가 아닌 뉴욕 시간으로 작성하십시오. 뉴욕은 겨울철에는 UTC-5, 여름철에는 UTC-4를 사용하므로, 고정된 UTC 시간으로 작성된 타이머는 1년에 두 번씩 1시간의 오차가 발생하여 장 마감 전에 실행될 수 있습니다. systemd 252 버전 이상에서는 OnCalendar에 시간대를 직접 지정할 수 있으며, Ubuntu 24.04는 255 버전을 제공합니다. systemctl --version 명령으로 현재 버전을 확인하십시오.

# /etc/systemd/system/research-refresh.service
[Unit]
Description=Refresh market data and run the daily screen
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=research
Group=research
WorkingDirectory=/opt/research
EnvironmentFile=/etc/research/env
ExecStart=/opt/research/venv/bin/python /opt/research/refresh.py
ExecStart=/opt/research/venv/bin/python /opt/research/screen.py

# /etc/systemd/system/research-refresh.timer
[Unit]
Description=Run the refresh after the US market close

[Timer]
OnCalendar=Mon-Fri 16:20 America/New_York
Persistent=true
RandomizedDelaySec=180

[Install]
WantedBy=timers.target

Type=oneshot은 여러 개의 ExecStart을 허용하는 유일한 서비스 유형이며, 순차적으로 실행하다가 0이 아닌 종료 코드가 발생하면 중단합니다. 이는 정확히 의도한 동작입니다. 데이터 갱신에 실패했을 때 오래된 데이터를 화면에 표시해서는 안 되기 때문입니다. Persistent=true는 커널 업데이트로 재부팅되는 VPS에서 중요합니다. 이 설정이 없으면 16:15에 재부팅될 경우 해당 작업은 누락되지만, 설정이 있으면 시스템이 복구되는 즉시 작업이 실행됩니다.

sudo systemctl daemon-reload
sudo systemctl enable --now research-refresh.timer
systemctl list-timers research-refresh.timer

list-timers 명령을 실행하면 다음 평일 실행 시간이 서버의 현지 시간으로 변환되어 NEXT 열에 표시되어야 합니다. 목록이 비어 있다면 타이머가 활성화되지 않았거나, 유닛 파일에 [Install] 섹션이 누락되어 enable이 timers.target로 연결할 대상이 없다는 의미입니다.

화면: SQL을 먼저, 모델을 나중에

SQL은 정확하며 실행당 비용이 발생하지 않습니다. 모델은 둘 다 해당하지 않습니다. 따라서 쿼리를 통해 데이터 범위를 좁히고, 살아남은 데이터만 모델로 전송합니다. 이를 /opt/research/screen.sql로 저장하십시오.

WITH ma AS (
  SELECT ticker, day, close,
         avg(close) OVER w20 AS ma20,
         avg(close) OVER w50 AS ma50,
         row_number() OVER (PARTITION BY ticker ORDER BY day) AS n
  FROM prices
  WINDOW
    w20 AS (PARTITION BY ticker ORDER BY day ROWS BETWEEN 19 PRECEDING AND CURRENT ROW),
    w50 AS (PARTITION BY ticker ORDER BY day ROWS BETWEEN 49 PRECEDING AND CURRENT ROW)
)
SELECT ticker, day, close, round(ma20, 2) AS ma20, round(ma50, 2) AS ma50
FROM ma
WHERE n > 50 AND ma20 > ma50
ORDER BY day DESC, ticker
LIMIT 20;

n > 50 필터는 장식이 아닙니다. ROWS BETWEEN 49 PRECEDING AND CURRENT ROW은 존재하는 모든 행의 평균을 계산하므로, 티커의 세 번째 행은 3일 치의 평균을 반환하면서도 여전히 ma50이라고 부릅니다. 이를 ma20와 비교하면 모든 티커 기록의 시작 부분에서 실제로는 발생하지 않은 교차 지점을 만들어내게 됩니다. 행 번호로 필터링하면 윈도우가 채워지지 않은 행들이 제거됩니다.

모델이 보는 것과 절대 보지 못하는 것

# /opt/research/screen.py
from anthropic import Anthropic
from store import connect

SYSTEM = (
    'You are a research assistant. Use only the rows in the message. '
    'If a number is not in the rows, say that it is not available. '
    'Do not give investment advice, price targets or buy and sell calls. '
    'Write at most 200 words.'
)

con = connect()
sql = open('/opt/research/screen.sql').read()
rows = con.execute(sql).fetchall()
block = '\n'.join(' / '.join(str(v) for v in row) for row in rows)

client = Anthropic(max_retries=5)   # reads ANTHROPIC_API_KEY from the environment
resp = client.messages.create(
    model='claude-sonnet-5',
    max_tokens=600,
    system=SYSTEM,
    messages=[{'role': 'user', 'content': 'Screen hits, ticker / day / close / ma20 / ma50:\n' + block}],
)

print(resp.content[0].text)
con.execute('INSERT INTO runs VALUES (now(), ?, ?, ?, ?)',
            ['claude-sonnet-5', resp.usage.input_tokens,
             resp.usage.output_tokens, len(rows)])
con.close()

시스템 프롬프트의 단어 제한은 비용이 많이 발생하는 작업의 범위를 제한합니다. 제공된 행만 사용하라는 지시는 신뢰하기보다 직접 검증해야 하는 부분입니다. 블록에서 열 하나를 삭제한 뒤 다시 실행하여 출력 결과를 확인하십시오. 해당 열의 수치가 여전히 나타난다면 모델이 빈칸을 임의로 채운 것이며, 이는 프롬프트가 충분히 엄격하지 않다는 의미입니다. 이 테스트는 2분이면 충분하며, 모델의 동작을 확인하는 유일하고 정직한 방법입니다.

모델은 API key를 절대 볼 수 없으며, 데이터베이스 경로를 확인하거나 쿼리를 직접 실행하지도 않습니다. 모델은 행 데이터를 받아 산문으로 반환할 뿐입니다. 이러한 경계 덕분에 출력 결과를 검증할 수 있습니다. 보고서에 포함된 모든 숫자는 전송한 블록 내에 존재해야 하므로, 이를 줄 단위로 대조할 수 있습니다. 프롬프트 작성과 관련한 자세한 내용은 Claude를 활용한 재무 분석에서 모델이 읽기에 적합한 데이터 형식을 더 깊이 다룹니다.

단일 실행, 종단 간 처리

뉴욕 시간 기준 16:20에 타이머가 서비스를 시작합니다. refresh.py은 마지막으로 저장된 날짜부터 각 티커에 대한 피드를 요청하고, 티커당 한두 개의 새로운 바(bar)를 기록한 뒤 티커별로 한 줄씩 출력합니다. screen.py는 동일한 파일을 열어 이동 평균 쿼리를 실행하고, 몇 개의 행을 반환받습니다. 이 행들은 수백 개의 토큰으로 구성된 텍스트 블록이 됩니다. 단 한 번의 API 호출로 이 블록이 짧은 메모로 변환되고, 메모는 저널로 전송되며, 토큰 수와 적중 횟수가 포함된 한 행이 runs에 기록됩니다.

journalctl -u research-refresh.service -n 50 --no-pager

정상적인 로그에는 티커당 한 줄, 이어서 메모, 그리고 research-refresh.service: Deactivated successfully이 포함됩니다. 일주일 후, 데이터베이스에서 직접 비용을 확인하십시오.

SELECT count(*) AS runs,
       sum(input_tokens)  AS in_tokens,
       sum(output_tokens) AS out_tokens
FROM runs;

해당 합계에 확인한 날짜 기준으로 모델이 명시한 백만 토큰당 가격을 곱하십시오. 그러면 타인의 추정치가 아닌 실제 수치를 얻을 수 있습니다. 게시된 가격은 변하지만, 산술 방식은 변하지 않습니다.

백테스트가 과적합되는 이유와 그 징후를 파악하는 방법

두 윈도우 길이를 변수로 하는 스크린 함수를 작성하고, 쌍(pair)의 그리드를 스윕(sweep)한 뒤 수익률 순으로 정렬해 보십시오. 가장 좋은 성과를 낸 쌍은 매우 훌륭해 보일 것입니다. 이것이 바로 결과가 아닌 문제입니다. 200개의 쌍을 그리드로 구성했다면 이는 200번의 실험을 수행한 것이며, 그중 가장 운이 좋았던 결과를 선택한 것에 불과합니다.

이 현상은 10분이면 확인할 수 있습니다. 데이터를 날짜 기준으로 절반으로 나눕니다. 앞선 절반의 데이터로만 그리드를 스윕하여 승자를 기록하십시오. 동일한 그리드를 나머지 절반의 데이터로 다시 스윕합니다. 두 승자의 파라미터가 크게 다르다면, 해당 파라미터는 노이즈에 맞춰진 것입니다. 특정 구간에서만 승리하는 쌍은 미래에 대해 아무것도 보장하지 않습니다.

생존 편향(Survivorship bias)은 튜닝으로 해결할 수 없기에 과적합보다 더 위험합니다. 티커 목록이 현재 지수 구성 종목이라면, 살아남은 기업들만 포함되어 있습니다. 2019년에 상장 폐지된 티커를 데이터 피드에 요청하면 빈 프레임이 반환됩니다. 즉, 해당 기업은 데이터 저장소에 들어오지 않으며 테스트에도 포함되지 않습니다. 실행하는 모든 백테스트는 이미 실패한 사례를 제외하고 있습니다.

수정된 펀더멘털 데이터(Restated fundamentals)는 타임라인을 왜곡합니다. 오늘 API가 반환하는 2019년 분기 매출 수치는 2019년 당시 발표된 수치와 항상 일치하지는 않습니다. 오늘의 펀더멘털과 2019년의 가격을 혼합한 스크린은 당시에는 존재하지 않았던 정보를 사용하고 있는 것입니다. 가격 데이터는 대개 안전하지만, 펀더멘털 데이터는 그렇지 않은 경우가 많습니다.

수정 주가(Adjusted prices)는 변동합니다. auto_adjust=True을 사용하면 종가는 배당과 액면분할을 반영하여 과거 시점까지 소급 조정됩니다. 따라서 다음 달에 동일한 쿼리를 실행하면 과거 데이터가 미세하게 달라집니다. 실제로 사용한 행(row)을 저장하는 것이 결과의 재현성을 보장하며, 로컬 저장소가 필요한 또 다른 이유이기도 합니다.

또한 백테스트는 수수료와 슬리피지를 무시하며, 주문이 가격에 영향을 주지 않는다고 가정합니다. 이는 실행(execution)의 영역이며, 본 문서의 범위를 벗어납니다. 관련 내용은 VPS에서 트레이딩 봇 실행하기에서 다룹니다.

실패 유형과 확인되는 메시지

error: externally-managed-environment pip 실행 시 발생합니다. 가상 환경 외부에서 실행 중입니다. /opt/research/venv/bin/pip를 전체 경로로 호출하십시오.

Could not set lock on file, 뒤에 PID가 표시됩니다. 다른 프로세스가 DuckDB 파일을 쓰기 모드로 점유 중입니다. 보통 잊고 닫지 않은 대화형 셸이 원인입니다. 해당 셸을 종료하거나 read_only=True 옵션으로 두 번째 연결을 여십시오.

Main process exited, code=killed, status=9/KILL, systemctl status 내에서 발생합니다. 커널이 메모리 부족으로 작업을 강제 종료했습니다. journalctl -k | grep -i oom로 확인한 뒤, store.py의 memory_limit 값을 낮추십시오.

성공으로 표시되나 아무것도 기록되지 않음. systemctl status이 active (exited)을 읽었으나 테이블이 증가하지 않았습니다. 피드에서 빈 프레임이 반환되었습니다. 이 실패는 가장 오랫동안 발견되지 않으므로, 모든 티커의 응답이 비어 있을 때 작업이 0이 아닌 종료 코드를 반환하도록 설정하십시오.

시장 휴일에 타이머가 작동함. systemd는 거래소 달력을 알지 못하므로 Mon-Fri에는 휴일이 포함됩니다. 작업이 실행되어도 피드에 새로운 데이터가 없으며, 작업은 이를 오류가 아닌 정상적인 상황으로 처리해야 합니다.

API로부터 429 발생. 속도 제한을 초과했습니다. Anthropic SDK는 자체적으로 백오프를 수행하며 재시도하고, Anthropic(max_retries=5)은 시도 횟수를 증가시킵니다. 매일 실패가 지속된다면 한 번의 요청으로 너무 많은 데이터를 처리하려는 경우입니다.

이 도구가 아닌 것

이 도구는 연구 보조 도구입니다. 모델이 공시 자료를 요약하면 해당 자료에 대한 해석을 제공하지만, 텍스트에 인쇄된 숫자에 대해 확신을 가지고 틀릴 수 있습니다. 따라서 이 노트의 모든 수치는 사용자가 제공한 행(row)으로 추적 가능해야 합니다. 출력된 내용은 직접 읽어봐야 할 항목의 목록으로 간주하십시오. 이 내용 중 그 어떤 것도 재무 조언이 아니며, 매매 신호도 아닙니다.

백테스트는 아이디어를 기각하는 데는 유용하지만, 아이디어를 확증하는 데는 취약합니다. 사용자의 데이터에서 실패한 전략은 실제로 죽은 전략입니다. 통과한 전략은 단지 사용자의 데이터를 통과했을 뿐이며, 이는 새벽 1시에 느껴지는 것보다 훨씬 작은 의미를 가집니다.

실행(Execution)은 의도적으로 범위에서 제외했습니다. 주문 및 브로커 자격 증명은 읽기 전용 연구 환경과는 다른 위험 프로필을 가지며, 이를 혼합하면 LLM 프롬프트가 있는 동일한 머신에 트레이딩 키를 두게 됩니다. 이 패턴이 개인 서버에서 실행할 가치가 있는 다른 항목들과 어떤 위치에 있는지 확인하려면, 직접 호스팅할 가치가 있는 AI 에이전트를 통해 더 넓은 내용을 살펴보시기 바랍니다.

FAQ

유료 시장 데이터 피드가 필요한가요?

프로토타입 단계에서는 필요하지 않습니다. 학습용으로 시스템의 구조를 파악하는 데는 무료 비공식 피드로도 충분합니다. 다만, 해당 피드는 의무가 없는 웹사이트에 의존하므로 언제든 중단될 수 있습니다. 보통 예외를 발생시키기보다 빈 프레임을 반환하는 방식으로 중단되므로, 작업 시 행 개수를 반드시 확인해야 합니다. 데이터가 의사결정에 활용되기 시작하면 문서화된 API와 기술 지원 주소가 제공되는 유료 피드로 전환하십시오. 스토어(store) 구조를 사용하면 이러한 교체가 간편해집니다. 가져오기(fetch) 함수만 변경하면 되며, 스케줄, 스키마, 화면은 그대로 유지됩니다.

가격 데이터를 SQLite에 저장해야 하나요, DuckDB에 저장해야 하나요?

DuckDB는 컬럼 기반 저장소로, 10년 치 데이터의 이동 평균과 같은 집계 연산을 위해 많은 행을 스캔하는 데 최적화되어 있습니다. SQLite는 행 기반 저장소로, 여러 프로세스가 동시에 수행하는 다수의 소규모 읽기 및 쓰기 작업에 더 적합합니다. 수백 개의 행을 추가하고 수백만 개의 행을 스캔하는 단일 스케줄 작업에는 DuckDB가 더 나은 선택입니다. 여러 프로세스가 동시에 데이터를 써야 한다면, SQLite의 WAL 모드를 사용하십시오. 읽기 작업은 쓰기 작업이 커밋되는 동안에도 계속될 수 있으며, busy timeout 설정을 통해 다른 쓰기 작업이 실패하지 않고 대기하도록 할 수 있습니다.

LLM 호출 비용은 한 달에 얼마나 드나요?

모든 응답에서 usage.input_tokens와 usage.output_tokens을 테이블에 기록한 뒤, 주간 합계에 모델별 백만 토큰당 가격을 곱하십시오. 이 가격은 확인하는 시점의 모델 가격표를 기준으로 합니다. 이 수치만이 다음 분기에도 유효합니다. 일일 스크린 작업 한 번은 적은 호출 횟수를 발생시키며, 비용은 요약문의 길이를 조절하여 제어할 수 있습니다. 모든 Claude 모델에서 출력 토큰은 입력 토큰보다 비싸게 책정되므로, 행을 줄이는 것보다 요약문을 200단어로 제한하는 것이 비용 절감에 더 효과적입니다.

작업은 성공했는데 왜 새로운 행이 기록되지 않나요?

두 가지 일반적인 원인이 있습니다. 첫째, 시장이 휴장일 경우입니다. systemd Mon-Fri 스케줄은 거래소 휴장일을 고려하지 않기 때문입니다. 둘째, 피드가 모든 티커에 대해 빈 프레임을 반환한 경우입니다. 클라이언트 라이브러리는 이를 예외가 아닌 경고 메시지로 출력하는 경우가 많아, 프로세스는 종료 코드 0으로 정상 종료되고 systemd는 성공으로 표시합니다. SELECT max(day) FROM prices를 마지막 실제 거래일과 비교하여 이를 구분하고, 모든 티커의 데이터가 비어 있을 경우 작업이 0이 아닌 종료 코드를 반환하도록 설정하십시오.

에이전트가 무엇을 살지 결정할 수 있나요?

아니요. 에이전트에게 매수 결정을 맡기려 하는 것이 이 프로젝트들이 실패하는 주된 이유입니다. 모델은 시장에 접근할 수 없으며, 사용자의 포지션이나 세금 상황을 알지 못하고, 자신의 계산 결과를 검증할 방법도 없습니다. 모델이 잘하는 것은 방대한 텍스트를 읽고 오늘 주의 깊게 살펴볼 항목을 추려내는 것입니다. 모델이 작성하는 어떤 내용도 재무 조언이 아니며, 결정과 그에 따른 책임은 전적으로 사용자에게 있습니다.