정보 지도를 어디에 담을 것인가 — vault 설계와 실측

정보 시스템으로 방향을 틀었으니 이제 그릇을 설계해야 한다. 결론부터 쓰면 옵시디언으로 열리는 마크다운 + 쿼리용 인덱스 DB 하이브리드다.

무엇을 파일로, 무엇을 DB로

처음엔 전부 마크다운 파일로 만들려고 했다. 계산해보니 안 된다.

용량보다 파일 개수가 먼저 문제가 된다. 이벤트까지 전부 파일로 만들면 12만 개이고, 뉴스를 넣으면 연간 36만 개씩 는다. inode는 버텨도 rsync가 느려지고 옵시디언이 멈춘다.

사람이 손대는 것만 파일로 둔다. 기계만 읽는 건 DB에 넣는다.

서버 제약을 먼저 계산했다

VPS는 월 $11짜리다. 1 vCPU / 2GB / 55GB.

1~3단계는 현재 VPS로 충분하다. 뉴스 대량 처리가 붙는 5단계에서 증설을 판단한다.

그리고 못 박아둔 규칙이 하나 있다. 백테스트는 절대 VPS에서 돌리지 않는다. 640만 행 피벗을 1 vCPU로 돌리면 웹이 멎는다. 무거운 건 전부 로컬이다.

진짜 비용은 서버가 아니라 LLM

하루 1,000건 기사를 전부 LLM에 넣으면 월 6,000만 토큰이다. VPS $11보다 훨씬 비싸다.

그래서 세 가지 원칙을 세웠다.

1. 규칙으로 1차 필터, 살아남은 것만 LLM. 공시 유형만 봐도 대부분이 버려진다
2. 한 번 읽은 건 노트에 남겨 재처리하지 않는다. 지도가 쌓이면 비용이 준다
3. 과거 소급 배치는 로컬에서

실측으로 확인한 것

추정만 하기 싫어서 실제로 재봤다.

DART 상장사 공시는 하루 377건이다 (3주치, 유가+코스닥 5,277건). 생각보다 적다.

유형 분포를 보니 필터 가설이 맞았다.

상위 두 개(29%)는 이미 정형 데이터로 받고 있어서 LLM이 읽을 필요가 없다. 파싱만 하면 된다. 세 번째 덩어리는 대부분 증권사 ELS 발행 서류다 — 공시가 가장 많은 15개사 중 10개가 증권사였다(교보증권 혼자 134건).

이것들을 걷어내면 LLM이 실제로 읽어야 할 건 하루 50~80건 수준으로 내려간다.

그리고 단일판매·공급계약 체결이 하루 18건이라는 게 중요하다. "A사가 B사에 얼마짜리를 공급한다"가 계약금액·기간과 함께 정형으로 들어있는 공시다. 관계를 직접 주는 데이터다.

뉴스 RSS도 22개를 두드려서 15개가 살아있는 걸 확인했다. 재미있는 건 섹션 RSS 최상단이 "[부고]", "[동정]", 스포츠 기사였다는 점이다. 1차 필터가 왜 필요한지가 실측으로 나왔다.

단계

재료는 이미 있다. DART 재무 63만 행, 임원·대주주 공시 3.3만 건, 폐지종목 417개, 가격 10년치.

임원 공시가 특히 좋다. 인물 노트가 자동으로 생긴다. 누가 어느 회사에서 언제 얼마나 샀는지가 기업과 사람 양방향으로 연결된다.

전용 PC를 검토 중인 이유

미니PC 도입을 한 달 안에 결정하려고 한다. 이유는 24시간 가동이 아니라 LLM 비용이다.

작업의 대부분이 작은 모델로 충분하다. 기사 분류(유의미/무의미), 엔티티 추출(기업·제품·인물) 같은 건 8B급이면 된다. 1차 필터를 로컬로 내리면 API 호출이 10분의 1로 준다.

Mac mini M4가 전력 대비 성능은 가장 좋은데(통합 메모리로 14B급 구동, 월 전기료 5천 원), pandas 백테스트는 x86이 유리하고 기존 스크립트가 Windows/Linux 기준이라 손볼 것이 생긴다.

사기 전에 측정할 세 가지를 먼저 정했다.

1. vault 1~3단계를 현재 PC + VPS로 구축 → 노트 4.4만 개 생성 실제 소요 시간
2. 뉴스 수집 소규모 시작 → 하루 실제 유입량 (1,000건인지 100건인지에 따라 요구가 10배 차이)
3. 로컬 LLM 분류 테스트 → 8B 모델이 "이 공시가 유의미한가"를 실제로 판정하는지. 못 하면 GPU를 사도 소용없다

순서는 만들고 → 재고 → 산다이다.

하드웨어를 먼저 사면 "샀으니 써야 한다"는 압력이 생기고 검증이 무뎌진다. 하루에 백테스트 버그를 다섯 번 잡았는데, 전부 "좋은 결과가 나왔으면" 하는 마음이 작동한 자리였다. 같은 함정을 하드웨어에서 반복하면 비용이 훨씬 크다.