위키냐 RAG냐, 결국 다 거쳐가는 그 길

에이전트코리아방 오후 시간, 한 참여자가 IT 기술 도메인을 검색·검증해주는 스킬을 찾고 있다며 운을 뗐다. 웹 검색만 시키면 출처가 부실하고, 검증을 겹겹이 시키면 답 없는 헐루시네이션(그럴듯하지만 근거 없는 답변)으로 샌다는 딜레마였다.

🔸 참여자 13:20:22 "IT 기술 도메인에 대해 검색/검증을 잘 해주는 스킬은 어떤게 있을까요??"

돌아온 답은 기성 스킬 도입이 아니라 직접 만들어보라는 조언이었다.

🔸 참여자 13:20:51 "걍직접만는게 제일좋더라구요"

LLM 위키에서 RAG로, 다들 걷는 그 길

리서치 결과를 저장소(LLM 위키 — 조사한 내용을 문서로 쌓아두는 저장소 형태의 지식 창고)로 쌓기 시작했다는 원 질문자에게, 뉴스레터·구독형 정보라면 위키보다 RAG(자료를 검색해 답변에 붙여주는 구조)가 낫다는 답이 왔다.

🔸 참여자 13:28:42 "Rag가 더 나을걸요"

다만 곧바로 RAG로 건너뛰지 말고 위키 단계에서 어디서부터 못 읽는지 몸으로 겪어보라는 권유가 이어졌다. 그 경험이 쌓여야 감이 생긴다는 논지였다. 검색 엔진 조합 얘기에서는 BM25(키워드 일치를 점수화하는 전통 검색 방식)와 의미검색을 함께 쓰는 조합이 정답에 가깝다는 공감대가 있었고, 정확한 배합 비율은 영업비밀이라며 웃음으로 넘겼다. 왜 RAG를 해도 결과가 시원찮은지에 대한 질문도 나왔다.

🔸 참여자 13:36:36 "왜 RAG를 해도 결과가 안좋죠? "

결론은 뒷단 검색 시스템보다 앞단에서 자료를 얼마나 입맛에 맞게 정리해 넣느냐가 관건이라는 쪽으로 모였다.

🔸 참여자 13:41:25 "결국 앞단에 자료를 내입맛에 얼마나 잘 맞게 모으냐가 관건이라 Agents 나 Skill 로 방법 찾아보려 하고 있죠."

PDF와 이미지, RAG의 진짜 난관

대화 말미엔 실전에서 가장 골치 아픈 데이터 형태로 화제가 넘어갔다. 텍스트로 정리된 자료면 다행이지만, 표와 이미지가 섞인 PDF는 텍스트로 읽히는 글자와 OCR(이미지 속 문자를 인식해 텍스트로 바꾸는 기술)이 필요한 부분이 뒤섞여 있다는 지적이었다.

🔸 참여자 13:48:03 "PDF 인식되는 글자는 파싱 잘 되는데 표는 OCR로"

한 참여자는 차라리 PDF를 통째로 이미지로 취급해 처리하는 편이 더 안전하다고 덧붙였다.

🔸 참여자 13:46:57 "PDF도…. 이미지로 처리된다는 사실"

같은 고민을 먼저 밟아본 사람들이 방 안에 많다는 사실이, 질문을 던진 참여자에게는 위안이자 다음 단계로 넘어갈 확신이 됐다.