WeKora 지식 베이스 비용은 문서 수가 아니라 데이터 처리, 검색, 모델 호출, 도구 실행, 샌드박스, 운영의 여섯 항목으로 나눠 계산해야 합니다. 처음 검증하는 단계라면 로컬 또는 낮은 동시성으로 시작하고, 사용량이 늘어난 뒤 질의량과 데이터 갱신 빈도를 기준으로 확장하는 방식이 안전합니다.
이 글은 기업 지식 베이스 책임자, RAG와 Agent 프로젝트의 예산을 설명해야 하는 제품 엔지니어, 클라우드 작업 공간의 장기 비용을 계산하는 독립 개발자를 위한 글입니다. WeKnora의 설치 절차 자체보다 어떤 사용 장면에서 비용이 늘어나는지에 집중합니다.
WeKora 지식 베이스 비용의 경계를 먼저 나눕니다
공식 프로젝트 이름은 WeKnora입니다. 검색 과정에서는 WeKora라는 표현도 자주 쓰일 수 있지만, 공식 저장소가 설명하는 범위는 RAG 질의, Agent 추론, MCP 도구, 샌드박스 실행, 자동 위키 생성까지 포함합니다. 기능 범위는 WeKnora 공식 한국어가 아닌 원문 저장소 안내에서 배포 시점마다 다시 확인해야 합니다.
예산은 다음 세 층으로 나누면 설명하기 쉽습니다.
- 초기 배포 비용: 저장소, 데이터베이스, 검색 엔진, 모델 연결, 문서 처리 환경을 준비하는 비용입니다.
- 지속 실행 비용: 문서 변환, 임베딩, 색인 갱신, 질의, 재순위화, 모델 응답, 도구 호출에 따라 반복됩니다.
- 성장 비용: 동시 요청, 데이터 갱신 빈도, 장시간 Agent 작업, 장애 복구와 운영 인력이 증가하면서 발생합니다.
이 세 층을 구분하지 않으면 문서가 적은데도 비용이 높거나, 사용자가 늘어난 뒤 갑자기 저장소와 모델 비용이 함께 증가하는 이유를 설명하기 어렵습니다.
| 비용 영역 | 계산에 넣을 변수 | 비용이 커지는 조건 |
|---|---|---|
| 문서 처리 | 파일 종류, 페이지 수, 추출 작업, 재처리 횟수 | 대량 최초 등록과 반복적인 원문 변경 |
| 색인과 저장 | 원문 저장, 청크, 임베딩, 색인 갱신 | 문서 버전이 많고 삭제·복원이 잦은 경우 |
| RAG 응답 | 질의량, 검색 단계, 재순위화, 입력·출력 토큰 | 긴 문맥과 반복 질의 |
| Agent와 MCP | 단계 수, 도구 호출, 외부 검색, 실패 재시도 | 한 작업이 여러 도구를 연속 호출하는 경우 |
| 샌드박스 | 실행 시간, 작업 수, 임시 파일, 격리 환경 | 코드 실행과 파일 분석이 포함된 경우 |
| 운영 | 모니터링, 백업, 접근 제어, 장애 대응 | 상시 운영과 여러 팀의 동시 사용 |
첫 단계: 문서 유입 비용을 세 가지 흐름으로 기록합니다
WeKnora의 문서 처리 비용은 파일 개수만으로 결정되지 않습니다. 파일을 읽고, 내용을 정리하고, 청크로 나누고, 임베딩을 생성하고, 색인을 갱신하는 과정이 각각 다른 자원을 사용합니다. DocReader의 환경 변수는 문서 처리 구성과 연결 정보를 확인하는 기준이 되므로 공식 DocReader 환경 변수 설명을 배포 전에 대조해야 합니다.
먼저 다음 세 흐름을 별도로 기록합니다.
- 최초 등록: 기존 파일 전체를 읽고 임베딩과 색인을 처음 만드는 흐름입니다. 처리 대상 파일의 형식과 추출 난이도가 핵심 변수입니다.
- 증분 동기화: 변경된 파일만 다시 처리하는 흐름입니다. 변경 감지가 제대로 작동하지 않으면 작은 수정에도 전체 색인이 다시 만들어질 수 있습니다.
- 대량 재구축: 임베딩 모델이나 청크 규칙을 바꿔 기존 데이터를 다시 처리하는 흐름입니다. 운영 중인 지식 베이스에서는 이 작업을 별도 시간대에 예약해야 합니다.
예산표에는 문서 처리 작업 수, 처리 대상 크기, 재처리 비율, 임베딩 생성량, 색인 갱신 횟수를 기록하십시오. 공식 환경 변수 템플릿은 연결 대상과 실행 구성을 확인하는 출발점이지만, 실제 비용은 네가 선택한 저장소와 모델 제공 방식에 따라 달라집니다. 공식 환경 변수 템플릿만 보고 월 비용을 확정해서는 안 됩니다.
WeKnora의 RAG 지식 베이스 예산은 검색 단계별로 계산합니다
WeKnora의 RAG 예산을 계산할 때는 “질의 한 번”을 하나의 비용으로 묶지 마십시오. 질의 전처리, 키워드 검색, 벡터 검색, 후보 결합, 재순위화, 생성 모델 호출이 모두 같은 비중으로 실행되는 것은 아니기 때문입니다.
- 벡터 검색은 임베딩과 벡터 색인에 연결됩니다.
- 키워드 검색은 정확한 용어와 문서 식별자 검색에 유리하며 별도의 검색 경로가 될 수 있습니다.
- 혼합 검색은 두 검색 결과를 결합하므로 검색 설정과 후보 수를 함께 기록해야 합니다. Qdrant의 혼합 검색 설명은 이 구조를 이해하는 참고 자료입니다.
- 재순위화는 후보 문서를 다시 평가하는 단계이므로 추가 모델 호출 또는 추가 처리 자원이 필요할 수 있습니다. Qdrant의 혼합 검색 재순위화 예시처럼 검색 결과를 좁히는 방식에 따라 계산량이 달라집니다.
- 생성 모델은 입력 문맥과 출력 길이에 따라 비용 변수가 달라집니다.
따라서 계산식은 다음처럼 구성하십시오.
RAG 월 비용 = 질의 수 × (검색 비용 + 재순위화 비용 + 생성 비용) + 색인 갱신 비용
여기에 동시 요청을 별도 변수로 두어야 합니다. 평균 질의만 계산하면 업무 시작 시간이나 문서 공개 직후의 집중 요청을 반영하지 못합니다.
| 사용 장면 | 기록할 값 | 예산을 조정하는 기준 |
|---|---|---|
| 일반 질문 | 질의 수, 검색 경로, 문맥 길이 | 평균값과 최대값을 따로 기록 |
| 긴 문서 질문 | 후보 수, 재순위화 여부, 입력 길이 | 답변 품질과 문맥 제한을 함께 검토 |
| 반복 질문 | 캐시 적용 여부, 동일 문서 재검색 | 캐시 적중률이 낮으면 모델 호출 증가 |
| 여러 사용자의 동시 질문 | 동시 요청, 대기 시간, 실패 수 | 처리량보다 피크 시간의 안정성을 우선 |
| 문서 갱신 직후 질문 | 색인 반영 시간, 재처리 작업 | 갱신 작업과 질의 작업의 자원 충돌 확인 |
기업 지식 베이스의 모델 호출과 벡터 저장 비용을 계산할 때는 단가를 임의로 넣지 말고, 네가 선택한 모델 제공자와 저장소의 당월 가격표를 별도로 연결하십시오. 공식 프로젝트 문서에는 기능과 배포 변수가 설명되어 있지만, 모든 외부 모델과 저장소의 가격이 고정되어 제공되는 것은 아닙니다.
복잡한 Agent와 자동 위키는 작업 단위로 분리합니다
RAG 답변은 검색과 생성으로 끝날 수 있지만 Agent 작업은 계획, 도구 선택, 실행 결과 확인, 다음 단계 판단을 반복할 수 있습니다. MCP 도구로 외부 시스템을 조회하거나 웹 검색을 수행하고, 샌드박스에서 코드를 실행하면 하나의 사용자 요청이 여러 자원 사용으로 확장됩니다.
다음 식을 기본 단위로 사용하면 과소 예산을 피할 수 있습니다.
Agent 비용 = 작업 수 × (평균 단계 수 × 단계별 모델 호출 + 도구 호출 + 샌드박스 실행) + 실패 재시도 비용
작업을 다음 세 그룹으로 나누어 기록하십시오.
- 평균 작업: 정해진 도구를 한두 번 호출하고 결과를 요약하는 업무입니다.
- 복잡한 작업: 여러 문서를 비교하거나 외부 검색과 내부 검색을 함께 사용하는 업무입니다.
- 실패 작업: 권한 오류, 도구 응답 지연, 잘못된 형식으로 인해 재시도가 발생하는 업무입니다.
자동 위키 생성도 문서 처리 비용과 생성 모델 비용을 따로 기록해야 합니다. 원문이 바뀔 때마다 위키 전체를 다시 생성하는지, 변경된 부분만 갱신하는지에 따라 비용 구조가 달라집니다. 샌드박스 기능을 사용하는 경우에는 공식 샌드박스 기능 문서에서 격리 방식과 실행 조건을 확인하고, 작업 시간 제한과 임시 파일 정리 정책을 예산표에 추가하십시오.
본사 데이터는 로컬, 클라우드, 혼합 중 조건으로 선택합니다
WeKnora를 로컬에 둘지 클라우드에 둘지는 단순히 어느 쪽이 저렴한지로 결정하면 안 됩니다. 데이터 민감도, 원격 접근 필요성, 운영 담당자 수, 동시성, 장애 대응 시간을 함께 비교해야 합니다.
| 배포 방식 | 적합한 상황 | 장점 | 부담 |
|---|---|---|---|
| 로컬 검증 | 개인 개발, 민감한 샘플, 초기 기능 확인 | 데이터 경계가 명확하고 실험이 빠름 | 외부 접근과 상시 운영이 불편함 |
| 클라우드 상시 운영 | 여러 팀의 원격 사용, 지속적인 Agent 실행 | 접근성과 확장성이 좋음 | 저장소, 네트워크, 모니터링과 권한 관리가 필요함 |
| 혼합 구성 | 원문은 내부에 두고 일부 처리만 외부에서 수행 | 데이터와 실행 환경을 분리할 수 있음 | 연결 지연, 권한 설계, 장애 경로가 복잡해짐 |
판단은 다음 조건으로 진행하십시오.
- 데이터가 외부 환경으로 나가면 안 되면 로컬 또는 혼합 구성을 우선 선택하십시오.
- 여러 사용자가 원격으로 접근하고 업무 시간이 길면 클라우드 상시 운영을 검토하십시오.
- 아직 문서 형식과 검색 품질을 검증하지 못했다면 로컬에서 먼저 확인하고, 바로 상시 클라우드 자원을 예약하지 마십시오.
- Agent가 장시간 실행되거나 샌드박스를 자주 사용하면 실행 환경의 확장 방식과 중단 정책을 먼저 확인하십시오.
- 운영 담당자가 부족하면 자체 구축의 숨은 인건비까지 포함하고, 원격 작업 환경이 필요할 때는 Macstripe의 원격 작업 환경과 비교해 보십시오.
공식 Docker Compose 구성은 어떤 서비스가 함께 실행되는지 확인하는 데 유용하지만, 해당 구성 파일의 기본값을 곧바로 운영 비용이나 성능 보장으로 해석하면 안 됩니다. 공식 Docker Compose 구성을 배포 전에 검토하고, 운영 환경에서는 백업과 접근 제어를 별도로 점검하십시오. 검색 시스템 운영 점검 목록도 저장소 운영 항목을 정리할 때 참고할 수 있습니다.
마지막 단계: 예산 상한과 주간 복기표를 먼저 만듭니다
배포 전에 다음 제한을 정해 두면 비용이 급증해도 원인을 추적할 수 있습니다.
- 사용자별 또는 팀별 질의 한도
- 요청 하나에 허용하는 최대 문맥 길이
- Agent 작업의 최대 도구 호출 수
- 샌드박스 실행 시간과 임시 파일 보관 기간
- 실패 재시도 횟수
- 대량 문서 재처리의 승인 조건
- 자동 위키 전체 재생성의 실행 시간대
주간 복기표에는 새로 들어온 문서량, 변경 문서량, RAG 질의 수, 평균과 최대 문맥 길이, Agent 작업 수, 도구 호출 수, 샌드박스 실패 수, 재시도 비율, 저장소 증가량, 장애 대응 시간을 기록하십시오. 금액을 아직 모른다면 먼저 사용량을 측정하고, 각 항목에 실제 제공자 가격을 대입하십시오. 이 방식은 근거 없는 월 예산을 만드는 대신, 다음 확장 시점과 비용 증가 원인을 설명할 수 있게 합니다.
자체 클라우드 구축만 계속하면 서버를 상시 켜 두어야 하고, 권한과 백업을 직접 관리해야 하며, 사용량이 낮은 기간에도 고정 운영 부담이 남습니다. 반대로 Macstripe의 Mac 렌탈 환경은 짧은 검증이나 임시 Agent 작업에 필요한 작업 공간을 빠르게 마련하기 쉽고, 직접 장비를 구매하지 않아도 된다는 장점이 있습니다. 다만 장기간 안정적인 고부하 운영이나 물리 장치 연결이 필수라면 자체 서버 또는 전용 클라우드가 더 적합할 수 있습니다. 배포 전에 Macstripe 구성 주문 안내에서 현재 제공되는 환경을 확인하고, 네가 만든 변수표의 실행 기간과 실제 운영 조건을 대조하는 편이 안전합니다.
