SQLite 전문검색으로 리포트 1,113건 뒤지기 — 6.71초를 1.75초로 줄인 방법

한눈에

• 쌓는 것과 찾는 것은 전혀 다른 일이었습니다. 텔레그램에 몇 달 쌓인 시황을 정작 필요할 때 못 찾아서 데이터베이스를 만들었습니다 — 지금 파일 하나에 140MB, 표 24개입니다.
• 1,549건짜리 표를 통째로 지웠습니다. 그중 96%가 요약이 비어 있었습니다. 「데이터가 많다」와 「쓸 수 있는 데이터가 많다」는 다릅니다.
• 리포트를 앞 4쪽만 읽다가 전문으로 바꾸니 검색되는 종목이 397개에서 583개가 됐습니다. 없던 자료를 구한 게 아니라 이미 가진 파일을 끝까지 읽었을 뿐입니다.
• 검색 6.71초 → 1.75초. 원인은 한 곳이 83%를 먹고 있었던 것 — 같은 리포트 더미를 후보마다 122번 훑고 있었습니다. 색인을 만들어 1번으로 줄였고, 늘어난 용량은 1MB 미만이었습니다.

장이 끝나면 그날의 시황을 정리해 텔레그램으로 받고 있습니다. 처음엔 그걸로 충분했습니다. 그런데 몇 달 쌓이니 정작 필요할 때 찾을 수가 없었습니다.

"이 종목 얘기가 언제 나왔더라." "그 테마 리포트가 어디 있었지." 텔레그램을 위로 올려가며 뒤지다가 포기하기를 몇 번 하고 나서, 쌓는 것과 찾는 것은 전혀 다른 일이라는 걸 알았습니다.

그래서 데이터베이스를 만들었습니다. 지금 파일 하나에 140MB가 들어 있고, 표가 24개입니다. 코딩을 모르는 채로 시작해서 여기까지 온 과정을 적어두겠습니다. 기술 설명보다는 «무엇을 잘못 알고 있었나» 쪽에 무게를 두겠습니다.

지금 안에 무엇이 들어 있나

담은 것	양
증권사 인뎁스 리포트 전문	1,113건 · 평균 61,402자
리포트에 등장한 종목 언급	49,975쌍 · 종목 사전 3,056개
일반 리포트	1,203건
상승률 상위 종목 이력	2,377건
일별 시세·수급	3,487건
사후 채점 (그날 뽑은 게 실제로 어땠나)	3,735건

쓴 것은 SQLite입니다. 서버를 따로 안 띄우고 파일 하나가 곧 데이터베이스인 방식이라, 개인이 혼자 쓰기에 가장 손이 덜 갑니다. 파이썬에 기본으로 들어 있어서 따로 설치할 것도 없었습니다.

① 많이 모으는 게 좋은 줄 알았습니다

처음엔 닥치는 대로 넣었습니다. 한때 리포트 표가 두 개였는데, 그중 하나에 1,549건이 들어 있었습니다. 숫자가 커서 뿌듯했습니다.

그런데 검색이 이상했습니다. 분명 걸려야 할 게 안 나옵니다. 세어보니 그 1,549건 중 96%가 요약이 비어 있었습니다. 제목만 있고 내용이 없으니 검색에 걸릴 리가 없었습니다.

결국 표 하나를 통째로 지웠습니다. 1,549건이 사라지고 남은 건 1,203건인데, 검색은 오히려 정확해졌습니다.

「데이터가 많다」와 「쓸 수 있는 데이터가 많다」는 다릅니다. 건수를 세면 전자만 보입니다. 그래서 지금은 새 표를 만들 때마다 「빈 칸이 몇 %인가」를 같이 셉니다.

② 앞 4쪽만 읽고 있었습니다

증권사 인뎁스 리포트는 PDF로 받습니다. 처음엔 앞 4쪽 정도, 6,000자쯤만 읽어서 넣었습니다. 요약이 앞에 있으니 그거면 되겠다고 생각했습니다.

그런데 정작 찾고 싶은 건 뒤쪽에 있었습니다. 「이 테마에 어떤 회사들이 엮이는가」는 리포트 본문 중반 이후에 나옵니다. 앞 4쪽에는 산업 전망만 있습니다.

그래서 전문을 다 넣도록 바꿨습니다. 평균 6,000자에서 61,402자로 26배가 됐습니다. 그 결과가 이겁니다.

검색에 걸리는 종목이 397개에서 583개로 늘었습니다. 없던 데이터를 새로 구한 게 아니라, 이미 갖고 있던 파일을 끝까지 읽었을 뿐입니다.

용량은 늘었지만 그건 문제가 아니었습니다. 디스크는 싸고, 못 찾는 정보는 없는 것과 같습니다.

③ 검색이 느려졌습니다 — 원인은 한 곳이었습니다

키워드를 넣으면 관련 종목을 찾아주는 기능을 만들었습니다. 잘 돌아갔는데, 어느 날부터 답이 나오기까지 한참 걸렸습니다.

여기서 「빠르게 고쳐줘」라고 하지 않고 「어디가 느린지 재줘」라고 한 게 결정적이었습니다. 재보니 이랬습니다.

단계	걸린 시간
리포트 더미를 훑는 부분	9.9초 — 122번 × 0.081초
나머지 전부	2.5초
합계	12.4초

한 군데가 83%를 먹고 있었습니다. 이유는 단순했습니다. 후보 종목이 122개 나오면, 그 122개 각각에 대해 리포트 더미를 처음부터 다시 훑고 있었습니다. 같은 서랍을 122번 여는 셈입니다.

고친 방법도 단순합니다. 「어느 리포트에 어느 종목이 나오는가」를 미리 표로 만들어 뒀습니다. 그러면 서랍을 열 필요 없이 그 표만 보면 됩니다. 훑기가 122번에서 1번이 됐습니다.

	전	후
검색 한 번	6.71초	1.75초
늘어난 용량	—	1MB 미만
표 만드는 시간	—	최초 1분 51초 · 이후 7초

이런 걸 색인이라고 부릅니다. 책 뒤의 「찾아보기」와 똑같습니다. 책을 처음부터 읽는 대신 찾아보기를 보는 것이고, 그 대가로 종이 몇 장을 더 씁니다. 여기서는 1MB였습니다.

④ 「0」이 「없다」는 뜻이 아니었습니다

어떤 키워드로 검색했더니 결과 한 칸이 전부 0으로 나왔습니다. 저는 "그 항목에 해당하는 게 없구나" 하고 넘어갔습니다.

그게 아니었습니다. 파고들어 보니 「없음」이 아니라 「안 봄」이었습니다. 프로그램이 그 부분을 애초에 조회하지 않고 0을 그대로 내보내고 있었습니다.

이게 데이터를 다룰 때 가장 위험한 종류의 오류입니다. 「0」은 화면에 멀쩡하게 나옵니다. 오류 메시지도 없습니다. 그래서 틀린 줄 모르고 그걸 근거로 판단하게 됩니다. 차라리 프로그램이 죽었으면 바로 알았을 겁니다.

그 뒤로는 0이 나오면 «없어서 0인가, 안 봐서 0인가»를 먼저 묻습니다. 둘은 화면에서 똑같이 생겼습니다.

⑤ 색인은 낡을 수 있습니다

③에서 만든 색인에 함정이 하나 더 있었습니다. 새 리포트가 들어왔는데 색인을 다시 안 만들면, 검색이 그 리포트를 조용히 놓칩니다. 이번에도 오류는 안 납니다. 그냥 결과에서 빠집니다.

그래서 검색할 때마다 «아직 색인에 없는 문서»를 그 자리에서 직접 훑어 메우도록 만들었습니다. 색인이 최신이면 할 일이 없고, 뒤처져 있으면 그만큼만 더 봅니다.

정확성을 «내가 잊지 않고 갱신하는 것»에 걸지 않는다 — 이게 여기서 배운 규칙입니다. 사람이 매번 해야 하는 절차는 언젠가 빠집니다.

⑥ 백업 파일 이름이 사고 일지가 됐습니다

DB를 크게 손댈 때마다 백업을 남겼습니다. 지금 8개, 합쳐서 667MB가 쌓여 있는데, 파일 이름을 보면 그날 무슨 일이 있었는지 그대로 나옵니다.

표를 합칠 때, 이름을 바꿀 때, 잘못 쌓인 행을 지울 때, 휴장일에 잘못 들어간 데이터를 걷어낼 때 — 매번 하나씩 늘었습니다. 되돌릴 수 있다는 걸 알아야 과감하게 고칠 수 있습니다. 백업이 없으면 손대기가 무서워서 잘못된 구조를 그냥 안고 갑니다.

그리고 이 글을 쓰다가 또 하나 찾았습니다

글을 쓰려고 오늘 표를 세어보다가 발견했습니다. 상승률 상위 이력의 날짜 칸에 형식이 두 가지 섞여 있었습니다.

형식	건수
20260821 — 숫자 8자리	1,222건
2026-08-21 — 하이픈	1,155건

같은 칸에 두 형식이 있으면 「8월 이후만 보여줘」 같은 조회에서 한쪽이 통째로 빠집니다. 그런데 오류는 안 납니다. 결과가 나오긴 나옵니다. 절반만 담긴 채로요.

④와 정확히 같은 종류입니다. 조용히 틀리는 것입니다. 데이터를 넣는 경로가 둘인데 형식을 맞춰두지 않은 게 원인이었고, 지금 고치는 중입니다.

정리하면

DB를 만들면서 배운 건 문법이 아니었습니다. 여섯 가지가 전부 「조용히 틀리는 것」에 관한 이야기였습니다.

프로그램이 멈추거나 빨간 글씨가 뜨면 오히려 쉽습니다. 어려운 건 결과가 멀쩡하게 나오는데 틀린 경우입니다. 요약이 비어 있어도 건수는 1,549건으로 찍히고, 앞 4쪽만 읽어도 검색은 됩니다. 0은 0처럼 보이고, 낡은 색인도 답을 내놓습니다.

그래서 지금은 무엇을 만들든 「이게 틀렸다면 어떻게 알아차릴 수 있나」를 같이 묻습니다. 그 답이 「모른다」면, 알아차릴 방법부터 만들어야 합니다.

이 전부를 말로 만들었습니다. 저는 SQL을 쓸 줄 모릅니다. 「이걸 찾고 싶은데 안 찾아진다」고 말했고, 「어디가 느린지 재줘」라고 했을 뿐입니다. 그런 작업을 어떻게 시작하는지는 클로드 코드 설치와 첫 실행에 적어뒀습니다.

※ 이 글은 개인의 개발 기록입니다. 데이터베이스에 담긴 내용이나 그것으로 뽑은 결과는 공개하지 않으며, 특정 종목의 매수·매도를 권유하지 않습니다.