500GB 서버로 만드는 AI 지식 허브 — 데이터를 전부 메모리에 올릴 필요는 없다

AI 서비스를 운영하다 보면 언젠가는 데이터가 문제가 된다. 법령, 판례, 회계, 세무, 기술 문서처럼 다양한 분야의 자료를 모으기 시작하면 저장해야 할 데이터는 계속 늘어난다.

그렇다고 데이터가 많아질 때마다 무조건 더 비싼 서버를 구매해야 할까?

내 생각은 조금 다르다. 저장 공간을 충분히 확보하되, 데이터를 어떻게 나누고 검색할 것인지 설계하는 게 중요하다.

1. 단순한 홈페이지를 넘어 에이전트 지식 허브로

지금 운영하는 AI 지식 허브를 앞으로 어떻게 발전시킬지 생각해 봤다.

단순히 AI 관련 글을 모아 보여주는 홈페이지에서 그치는 게 아니라, 여러 AI 에이전트가 필요한 정보를 직접 검색하고 활용할 수 있는 지식 기반 서비스를 만드는 것이다.

예를 들어 이런 자료들을 생각할 수 있다.

• 법률: 현행 법령, 시행령, 시행규칙, 판례
• 회계·세무: 회계기준, 세법, 공식 행정 자료
• 개발: 리눅스 명령어, API 문서, 오픈소스 기술 자료
• AI 에이전트: 도구 설명, MCP 서버, API 사용법
• 기타 분야: 출처가 명확하고 지속적으로 갱신되는 전문 지식

이런 자료를 체계적으로 축적하고 검색 API로 제공하면, 에이전트는 인터넷을 무작정 뒤지는 대신 필요한 지식을 신뢰할 수 있는 출처에서 찾아 활용할 수 있다.

특히 법률 정보는 더욱 그렇다. 인터넷에 떠도는 설명만 믿기에는 부담이 크다. 개정 전 법령이나 오래된 해석을 현재 기준으로 잘못 사용하는 문제도 생길 수 있다.

그래서 법령은 국가법령정보센터 같은 공식 출처를 활용하고, 원문과 시행일, 개정 이력을 함께 관리하는 것이 중요하다.

2. 법령은 매번 처음부터 수집할 필요가 없다

법령 데이터는 API를 통해 갱신할 수 있다. 중요한 것은 매번 모든 데이터를 새로 가져오고 처리하지 않는 것이다.

정기적으로 변경 사항을 확인하고, 신규·개정·폐지된 법령만 갱신하는 방식으로 운영할 수 있다.

변경된 조문만 다시 임베딩하면 불필요한 계산도 줄어든다. 기존 원문과 개정 이력을 보존하면 과거 기준으로 법령을 확인하는 것도 가능하다.

여기에 증분 백업을 적용하면 변경된 데이터 위주로 백업할 수 있다. 다만 복구를 위해서는 별도 위치에 백업을 보관하고, 주기적으로 복구가 정상적으로 되는지 확인해야 한다.

이렇게 하면 데이터가 많아져도 유지 관리 부담을 줄일 수 있다.

3. 데이터를 작은 블록으로 나누면 어떨까?

이번에 가장 관심을 갖게 된 부분이다.

100GB에 달하는 자료가 있다고 해서 질문이 들어올 때마다 100GB 전체를 읽을 필요는 없다.

법령이라면 법률 전체를 하나의 거대한 파일로 취급하는 대신 조문이나 항 단위로 나눌 수 있다. 기술 문서는 문단이나 의미가 이어지는 단위로 분할할 수 있다.

각 블록에 고유 ID를 부여하고, 데이터베이스나 검색 인덱스에 해당 블록의 위치와 메타데이터를 기록한다.

예를 들면 다음과 같다.

• LAW-00125 — 근로기준법 제26조
• LAW-00126 — 근로기준법 제27조
• TAX-00852 — 소득세 관련 자료
• CASE-01240 — 관련 판례 자료

질문이 들어오면 검색 인덱스를 통해 관련 블록을 찾고, 해당 데이터만 불러온다.

핵심은 단순히 데이터를 쪼개는 데 있지 않다. 블록을 찾을 수 있는 인덱스를 만들고, 그 인덱스를 이용해 필요한 데이터에 바로 접근하도록 설계하는 것이다.

데이터가 커져도 매번 전체 파일을 읽지 않고 필요한 부분만 가져올 수 있다.

4. 100GB의 데이터를 모두 메모리에 올릴 필요는 없다

처음에는 100GB의 지식 데이터를 제대로 검색하려면 그만큼의 메모리가 필요하지 않을까 생각할 수 있다.

하지만 저장 공간과 메모리는 역할이 다르다.

전체 데이터는 SSD에 보관하고, 검색 인덱스와 자주 사용하는 데이터는 메모리에 올려두며, 나머지는 필요할 때 불러오는 방식으로 운영할 수 있다.

예를 들어 전체 데이터가 100GB라고 하더라도 특정 질문에 필요한 블록은 그중 극히 일부일 수 있다. 검색 시스템이 해당 블록을 찾아 메모리로 읽어오면 된다.

물론 실제로 읽는 데이터의 양은 검색 방식과 요청 내용에 따라 달라진다. 검색 인덱스 자체가 크다면 그 인덱스를 관리할 메모리도 필요하다.

그래도 모든 원본 데이터를 동시에 메모리에 올려야 하는 것은 아니다.

이 방식은 온디맨드 로딩, 인덱스 기반 접근, 운영체제의 페이지 캐시 등과 관련이 있다. LLM에서 말하는 양자화와는 다른 개념이다. 양자화는 주로 모델 가중치나 임베딩 벡터의 숫자 표현 정밀도를 낮춰 메모리 사용량을 줄이는 기술이다.

5. 검색 방식도 하나로 제한할 필요가 없다

지식 허브를 만들 때 모든 데이터를 하나의 검색 기술로 처리할 필요는 없다.

예를 들어 다음과 같이 역할을 나눌 수 있다.

• PostgreSQL 또는 SQLite: 원문, 메타데이터, 시행일, 개정 이력 관리
• 전문 검색 인덱스: 정확한 단어와 문구 검색
• FAISS: 질문과 의미가 유사한 문서 블록 검색
• 캐시: 반복 요청이 많은 검색 결과 재사용
• LLM: 질문을 분석하고 검색 결과를 해석해 답변 생성

법령처럼 정확한 조문 번호와 문구가 중요한 분야에서는 키워드 검색이 필요하다. 사용자가 자연어로 질문하는 경우에는 임베딩 기반 의미 검색이 도움이 된다.

두 방식을 함께 사용하면 정확한 일치 검색과 의미 중심 검색을 모두 지원할 수 있다.

그리고 검색 결과에는 원문 출처와 시행일을 함께 제공해야 한다. 임베딩은 관련 자료를 찾는 데 도움을 주지만, 그 자체가 정보의 정확성을 보장하지는 않기 때문이다.

6. RAM 64GB와 SSD 500GB를 생각하는 이유

최근 검토 중인 단독 서버 사양은 Xeon 8코어, RAM 64GB, SSD 500GB RAID1, 네트워크 30Mbps다.

월 사용료는 9만 원이다.

내가 이 사양에 관심을 갖는 이유는 단순히 현재 홈페이지를 운영하기 위해서만은 아니다. 앞으로 법령과 판례, 회계·세무 자료, 개발 문서 등을 모으고, 이를 검색 API로 제공하는 여러 서비스를 한 서버에서 운영할 가능성을 생각하고 있기 때문이다.

500GB의 저장 공간 중 일부를 지식 데이터에 할당하고, 나머지는 데이터베이스와 검색 인덱스, 로그, 운영 자료 등에 사용할 수 있다.

다만 실제 사용 가능 용량과 성능은 RAID 구성, 운영체제, 데이터 형식, 인덱스 크기에 따라 달라진다. RAM이 많다고 검색이 자동으로 빨라지는 것도 아니다. 적절한 인덱스와 데이터 구조가 함께 갖춰져야 한다.

또한 RAID1은 디스크 장애에 대비하는 구성이지 백업을 대신하지 않는다.

7. 결국 중요한 것은 저장량보다 설계다

서버에 데이터를 많이 저장하는 것 자체는 어렵지 않다. 중요한 것은 그 데이터를 얼마나 정확하게 관리하고, 얼마나 빠르게 찾아서 활용할 수 있게 만드느냐다.

공식 출처에서 자료를 수집하고, 변경 사항을 추적하며, 작은 블록으로 나누고, 인덱스를 통해 필요한 데이터에 접근하게 만들 수 있다.

여기에 전문 검색과 임베딩 검색을 결합하고, 에이전트가 사용할 수 있는 API를 제공하면 단순한 문서 저장소를 넘어 지식 서비스로 발전시킬 수 있다.

나는 앞으로 AI 에이전트가 많아질수록 이런 기반의 가치도 커질 것이라고 생각한다.

모든 정보를 모델 안에 집어넣는 것이 아니라, 필요한 순간에 신뢰할 수 있는 자료를 찾아 활용하도록 만드는 것이다.

데이터를 많이 쌓는 것보다 중요한 것은, 필요한 정보를 정확하게 찾아 쓸 수 있도록 만드는 일이다.