RAG 직접 개발과 솔루션 도입, 어디까지 책임질 수 있나요?
사내 문서 검색 RAG를 직접 개발할지 솔루션을 도입할지 판단하는 기준을 정리합니다. 구축 비용, 권한, 문서 갱신, 평가와 운영 책임을 같은 범위로 비교하세요.
RAG를 직접 개발하면 검색 방식과 데이터 흐름을 조직이 설계할 수 있습니다. 솔루션을 도입하면 문서 처리와 사용자 화면, 운영 기능을 제공받는 범위에서 출발할 수 있습니다. 어느 쪽이 유리한지는 첫 데모를 만드는 난이도보다 문서와 사용자가 계속 바뀌는 시스템을 누가 유지할 수 있는지에 달려 있습니다.
PDF 몇 개를 넣어 답변하는 실험과 직원들이 매일 사용하는 사내 문서 검색은 다른 작업입니다. 운영에서는 새 파일을 읽고, 삭제된 파일을 빼고, 원본의 권한 변경을 반영하며, 근거가 없을 때 답변을 보류해야 합니다. 개발과 구매를 비교할 때 이 범위를 양쪽에 똑같이 넣어야 합니다.
먼저 비교할 결과를 한 문장으로 정하세요
예를 들어 “설계팀이 승인된 사양서와 변경 이력에서 현재 적용 조건을 찾고 원문 위치를 확인한다”는 업무를 정할 수 있습니다. 그러면 필요한 파일, 사용자와 평가 질문이 구체화됩니다.
반대로 “기업용 RAG를 구축한다”만으로는 견적이나 개발 일정을 비교하기 어렵습니다. 한 팀은 파일 업로드와 채팅을 생각하고, 다른 팀은 NAS 자동 갱신과 계정별 권한까지 포함할 수 있기 때문입니다. 문서 형식, 저장소, 문서량, 변경 빈도, 동시 사용자와 외부 전송 조건을 먼저 맞추세요.
직접 개발에서 생기는 일은 모델 연결보다 넓습니다
직접 개발하는 팀은 문서 수집과 추출, 분할, 검색 인덱스, 모델 호출, 인용 표시를 설계합니다. 여기에 배포, 계정·권한, 로그, 장애 대응과 운영 화면이 더해집니다.
| 영역 | 직접 개발에서 맡을 일 | 솔루션 도입에서 확인할 일 |
|---|---|---|
| 문서 처리 | 형식별 파서, OCR, 표 구조, 실패 처리 구현 | 대표 파일 처리 결과와 지원 범위 |
| 검색·답변 | 검색 조합, 문맥 구성, 인용과 답변 보류 설계 | 같은 질문에서 답변·근거의 일치 여부 |
| 연동 | 저장소 접근, 변경 감지, 사용자 매핑 구현 | 기본 제공과 추가 개발의 구분 |
| 권한 | 수집·검색·답변 단계의 접근 통제 구현 | 원본 권한 적용 방식과 변경 반영 |
| 운영 | 모니터링, 백업·복구, 업데이트와 재평가 | 고객·공급사 책임, 지원과 인수인계 |
| 종료·변경 | 코드·데이터·모델 변경의 유지 책임 | 내보내기, 삭제, 계약 종료와 이관 조건 |
솔루션을 도입해도 고객의 일이 모두 없어지는 것은 아닙니다. 원본 자료의 소유자, 권한 정책, 최신 승인본의 기준과 최종 업무 판단은 조직이 정해야 합니다. 반대로 직접 개발도 모든 구성 요소를 새로 만드는 방식일 필요는 없습니다. 검증된 라이브러리와 상용 문서 처리, 모델 실행 서비스를 조합할 수 있습니다.
직접 개발이 맞을 수 있는 조건
검색 방식 자체가 서비스의 차별화 요소이거나, 일반 제품이 다루기 어려운 데이터 구조를 깊게 제어해야 한다면 직접 개발의 가치가 큽니다. 개발팀이 시스템을 장기적으로 유지하고, 문서 처리·검색·보안·인프라에 필요한 담당자를 확보할 수 있어야 합니다.
예를 들어 조직이 자체 포털에 특별한 승인 흐름과 검색 화면을 이미 운영하고 있다면, 그 환경 안에 RAG를 넣는 방식이 자연스러울 수 있습니다. 다만 “개발자 한 명이 챗봇을 만들 수 있다”는 사실은 담당자가 바뀌거나 문서 형식이 늘었을 때도 안정적으로 유지할 수 있다는 근거가 되지 않습니다.
개발 계획에는 첫 버전 이후의 시간을 적으세요. 파서와 모델을 업데이트한 뒤 다시 돌릴 평가 질문, 연동 API가 바뀌었을 때 수정할 사람, 장애 시 원인을 찾을 로그가 필요합니다. 이 계획을 채울 수 없다면 개발 범위를 줄이거나 솔루션과의 조합을 검토할 시점입니다.
솔루션 도입이 맞을 수 있는 조건
목표가 AI 기술 개발보다 직원의 문서 업무 개선이고, 검색·답변·출처 확인을 제공하는 제품이 실제 파일에 맞는다면 솔루션 도입을 검토할 수 있습니다. 제공 범위 안에서 문서 처리와 사용자 화면을 활용하고, 내부 팀은 데이터 정리와 업무 적용에 집중할 수 있습니다.
구매 전에는 기능 목록보다 대표 문서의 실패 사례를 보세요. 표가 깨진 사양서, 스캔 계약서, 여러 버전의 규정, 권한이 다른 폴더를 넣고 확인해야 합니다. ERP나 그룹웨어가 “연동 가능”하다고 해도 이미 포함된 커넥터인지, 데이터 모델에 맞춘 개발인지, 조회만 가능한지 구분해야 합니다.
특히 공급사의 제품 업데이트와 고객 환경의 변경이 충돌할 때 누가 조정하는지 확인하세요. 구매 후 적용 부서나 저장소가 늘면 추가 비용과 일정이 어떻게 정해지는지도 계약 범위에 포함해야 합니다.
RAG 구축 비용은 같은 기간과 책임으로 비교하세요
직접 개발의 비용에는 개발자의 최초 투입뿐 아니라 문서 정리, 평가, 보안 검토와 운영 시간이 들어갑니다. 오픈소스 라이선스 비용이 없더라도 인프라, 테스트와 유지보수가 무료가 되지는 않습니다.
솔루션 비용에는 구독·라이선스, 설치, 맞춤 연동, 교육, 지원과 확장 조건이 포함될 수 있습니다. 고객이 따로 마련할 서버와 내부 운영 시간도 더해야 합니다. 양쪽 모두 같은 기간에 사용할 저장소와 사용자 규모를 전제로 비교하세요.
비교표의 빈칸을 0원으로 처리하지 않는 것이 중요합니다. “권한 매핑: 미산정”, “문서 삭제 처리: 설계 필요”, “모델 업데이트: 지원 범위 확인”처럼 남겨야 아직 결정되지 않은 부담을 볼 수 있습니다. 계산 방법과 가상의 예산 예시는 온프레미스 AI 총비용 가이드에서 확인할 수 있습니다.
같은 문서로 개발팀과 공급사를 평가하세요
평가 문서를 각자 고르게 하면 쉬운 자료만 선택될 수 있습니다. 업무 담당자가 실제로 쓰는 자료와 질문을 정하고, 개발한 시스템과 후보 솔루션에 동일하게 적용하세요.
- 질문마다 필요한 정보, 해당 원문과 현재 버전을 적습니다.
- 검색된 자료와 생성한 답변을 나눠 확인합니다.
- 숫자·단위·조건이 인용한 문장과 일치하는지 봅니다.
- 다른 권한의 계정으로 같은 질문을 실행합니다.
- 문서를 수정·삭제하고 결과가 바뀌는지 시험합니다.
- 문서에 없는 질문에서 추측 대신 부족한 근거를 표시하는지 봅니다.
합격 기준은 결과를 본 뒤 정하지 마세요. 특히 권한 밖 자료 노출은 다른 문항의 높은 점수로 상쇄할 문제가 아닙니다. 실제 기록 방식은 RAG PoC 평가표를 활용할 수 있습니다.
일부를 구매하고 일부를 개발하는 선택도 있습니다
문서 검색과 근거 확인은 제품을 쓰고, 조직의 고유한 업무 화면이나 승인 흐름은 별도로 개발하는 방식도 가능합니다. 이 경우 API와 데이터 이동 경로, 권한 적용 지점, 장애 책임을 먼저 확인해야 합니다.
“하이브리드”라는 이름만 정하면 책임이 경계에서 빠질 수 있습니다. 검색 결과는 정상인데 포털 화면에서 다른 사용자에게 보이는 문제, 원본을 삭제했는데 별도 캐시에 남는 문제를 누가 점검할지 명확히 적으세요. 직접 개발과 솔루션을 조합하는 경우에도 하나의 운영 시스템으로 검수해야 합니다.
Wissly를 후보에 넣을 때 확인할 범위
Wissly는 폴더·문서·NAS·드라이브를 연결해 검색하고, 답변의 출처와 원문을 확인하는 문서 AI입니다. ERP·그룹웨어와 업무용 SaaS 연동, SSO·SCIM과 감사 로그 등 Enterprise 구성은 데이터 구조와 권한 환경에 따라 협의합니다. 모든 환경에 같은 범위를 기본 제공한다고 가정하지 마세요.
SaaS, Private Cloud, 온프레미스와 기존 인프라 SI 중 필요한 배포 방식을 검토할 수 있습니다. 직접 개발이 조직의 요구에 더 맞으면 그 판단을 유지하고, 솔루션 후보는 같은 평가표로 확인하면 됩니다.
Wissly 도입 상담에 첫 업무, 대표 파일, 연결할 저장소와 망 조건을 전달하면 제공 범위와 추가 협의 항목을 구체화할 수 있습니다. 최종 결정의 기준은 첫 화면을 얼마나 빨리 만들었는지가 아니라, 선택한 방식으로 필요한 업무와 운영 책임을 지속할 수 있는지입니다.