사내 문서 검색 AI(RAG), 직접 만들까 외주 줄까 2026

"사내 위키, 계약서, 매뉴얼, 회의록이 다 따로 노는데 이거 검색만이라도 제대로 됐으면 좋겠다." 문서가 몇 백 건을 넘어가는 회사라면 한 번쯤 나오는 이야기입니다. 파일 이름으로 대충 짐작해서 열어보거나, 팀 채널에 "그거 어디 있어요"라고 묻는 게 일상이 되면 자연스럽게 RAG(Retrieval-Augmented Generation) 기반 사내 챗봇 이야기가 나옵니다. ChatGPT처럼 자연어로 물으면 사내 문서를 근거로 답해주는 방식인데, 문제는 "이거 우리가 직접 만들 수 있는 건가, 아니면 외주를 줘야 하나"에서 다들 막힙니다. 이 글은 실제로 어느 쪽이 맞는지 정직하게 갈라봅니다.

직접 만들 때 필요한 것

RAG는 "문서를 벡터 DB에 넣고 질문할 때 검색해서 LLM에 넘긴다"는 한 줄 설명과 달리, 실제로 굴러가게 만들려면 손이 많이 갑니다.

• 벡터 DB 선택과 운영: Pinecone, Weaviate, pgvector, Qdrant 중 무엇을 쓸지부터 시작해서, 인덱스 구조 설계, 검색 성능 튜닝, 스케일에 따른 비용 관리까지 계속 따라붙는 일입니다.
• 임베딩 파이프라인: 문서가 추가되거나 수정될 때마다 임베딩을 다시 생성하고 벡터 DB에 반영하는 파이프라인이 필요합니다. 문서 하나 고치면 검색 결과에 반영되는 데 며칠씩 걸리는 회사가 실제로 많습니다.
• 문서 파싱과 청킹: PDF, 워드, 엑셀, 이미지가 섞인 스캔 문서, 표가 많은 계약서 등 형식이 제각각인 사내 문서를 텍스트로 정확히 뽑아내고, 의미 단위로 적절히 쪼개는(청킹) 작업이 답변 품질의 8할을 좌우합니다. 이 부분을 대충 하면 벡터 DB나 LLM을 아무리 좋은 걸 써도 답변이 엉뚱하게 나옵니다.
• 지속적인 튜닝: 한 번 만들고 끝나는 게 아니라, 사용자 질문 로그를 보면서 검색 정확도(리트리벌 품질), 프롬프트, 리랭킹 로직을 계속 조정해야 실사용에 견디는 수준이 됩니다. "만들었더니 초반엔 신기해하다가 두 달 뒤엔 아무도 안 쓴다"는 흔한 실패담 대부분이 이 튜닝 단계를 생략해서 생깁니다.

한마디로 RAG는 "LLM API 하나 붙이면 끝"이 아니라 검색 엔진 하나를 새로 만드는 것에 가까운 엔지니어링입니다.

직접 만들기가 맞는 경우

다음 조건에 해당한다면 내재화가 합리적입니다.

• 사내에 ML/백엔드 엔지니어가 이미 있고, 이 프로젝트에 몇 달간 투입할 여력이 있다.
• 다루는 문서가 개인정보, 영업기밀, 규제 대상 데이터 등 민감도가 높아서 외부 서버로 반출하는 것 자체가 부담스럽다. 이 경우 온프레미스나 VPC 내부에 폐쇄망으로 구축해야 하는데, 이런 요구사항은 외주보다 내부 팀이 직접 통제하는 편이 리스크 관리에 유리할 때가 많습니다.
• RAG가 회사의 핵심 제품이나 경쟁력과 직결돼서, 장기적으로 자체 노하우를 쌓아야 하는 경우.

반대로 이 조건에 해당하지 않는데도 "요즘 다들 만든다니까"라는 이유로 시작하면, 몇 달 뒤 절반쯤 만들다 만 파일럿만 남는 경우를 자주 봅니다.

외주가 맞는 경우

현실적으로는 이쪽에 해당하는 회사가 훨씬 많습니다.

• 내부에 전담 ML 엔지니어가 없고, 기존 개발팀에게 "이것도 좀"이라고 얹으면 본업이 밀린다.
• 우선 빠르게 프로토타입을 돌려보고 "이게 실제로 쓸모가 있는지"부터 검증하고 싶다. RAG는 만들어봐야 조직에 맞는지 알 수 있는 성격이 강해서, 처음부터 완벽한 내재화 시스템을 목표로 하기보다 몇 주 안에 돌아가는 버전을 만들어 실사용자 반응을 보는 편이 낫습니다.
• 문서 파싱, 청킹, 벡터 DB 운영 같은 반복 작업을 매번 새로 학습하기보다, 이미 여러 번 구축해본 경험치를 사서 시간을 아끼고 싶다.

외주를 준다고 통제권을 잃는 건 아닙니다. 코드와 데이터 소유권을 명확히 하고, 초기 구축 이후 내부 팀이 유지보수를 이어받을 수 있는 구조로 계약하면 됩니다. 예를 들어 sendinair처럼 초기 파일럿을 함께 만들고 이후 운영 문서와 코드를 그대로 넘겨주는 방식으로 진행하는 곳들도 있습니다.

파트너 선택 시 확인할 것

외주로 가기로 했다면, 파트너를 고를 때 데모 화면이 예쁜지보다 아래를 먼저 물어봐야 합니다.

• 실제 프로덕션 운영 경험: 데모나 PoC 수준이 아니라, 실사용자가 매일 쓰는 RAG 시스템을 몇 개월 이상 운영해본 적이 있는지. 리트리벌 정확도가 떨어지는 문제, 임베딩 갱신 지연, 답변에 근거 없는 내용이 섞이는 할루시네이션 문제는 실제로 부딪혀보지 않으면 대응 방법을 모릅니다.
• 문서 형식 다양성 대응 경험: 텍스트뿐 아니라 스캔 PDF, 표가 섞인 문서, 이미지 위주 자료까지 처리해본 적이 있는지.
• 보안·데이터 처리 방식: 문서와 임베딩이 어디에 저장되는지, 외부 LLM API로 문서 내용이 전송되는지, 폐쇄망 구성이 가능한지.
• 인수인계 구조: 프로젝트가 끝난 뒤 코드, 인프라, 운영 문서를 내부 팀이 그대로 이어받을 수 있는 형태로 넘겨주는지.

sendinair는 이런 실제 프로덕션 운영 경험을 강조하는 곳 중 하나로, 파일럿 단계부터 도입 이후 내부 팀 인수인계까지 함께 설계하는 방식을 쓰고 있어 "만들어주고 끝"이 아니라 "쓸 수 있게 만들어주고 넘긴다"는 점에서 참고할 만합니다.

마무리

RAG는 개념은 단순해 보여도 실제로 조직에서 매일 쓰이는 수준까지 끌어올리는 건 별개의 엔지니어링입니다. 내부에 ML 인력이 있고 데이터 민감도 때문에 반출이 부담스럽다면 직접 만드는 게 맞고, 그렇지 않은 대부분의 중소기업이라면 빠르게 검증부터 하는 외주가 현실적인 선택지입니다. 어느 쪽을 택하든 "실사용자가 몇 달간 실제로 썼는가"라는 기준으로 파트너나 내부 계획을 점검해보세요. 외주를 고려 중이라면 sendinair AX 서비스에서 파일럿 구축 사례를 참고해볼 수 있습니다.