2025. 4. 22. 13:32ㆍ카테고리 없음
요즘 AI 업계에서 ‘RAG’라는 말을 자주 듣는다. Retrieval-Augmented Generation, 검색 기반 생성 모델이라는 뜻인데, 막상 실전에서 이걸 직접 구현해본 사람은 많지 않다. 이번에 본 Contexual AI CEO의 유튜브 강연은 꽤 인상 깊었다. Meta와 Hugging Face에서 이름을 알린 연구자이자, 현재는 Contextual AI의 CEO인 Douwe Kiela가 직접 자신의 경험을 바탕으로 RAG 시스템 구축에 필요한 현실적인 조언들을 들려주었다. 그는 Meta 시절, RAG 기술을 개발한 주역이었고, 지금은 스탠퍼드에서 겸임 교수로도 활동 중이다. 2023년에 창업한 Contextual AI는 설립 1년 만에 약 1억 달러를 유치했고, HSBC, Qualcomm 같은 대기업을 고객으로 두고 있다.
Contextual AI CEO 가 말하는 10가지 교훈
1. RAG는 단순한 LLM과 DB의 조합이 아니다.
RAG를 단순히 LLM의 동작으로만 이해하는 사람들이 많다.하지만 Douwe는 RAG는 결국 시스템으로 동작한다. LLM의 추론과 단순한 RAG 검색 정확도만으로는 부족하다. 인덱싱, 리랭킹, context window 설계 등 모든 단계가 유기적으로 연결되어야 한다. 하나의 파이프라인으로서 작동해야 진짜 결과를 낼 수 있다는 이야기다.
2. 모델보다 중요한 것은 결국 데이터다
무슨 모델을 쓰느냐보다, 어떤 데이터를 얼마나 잘 준비하느냐가 훨씬 더 큰 영향을 미친다. 특히 도메인에 특화된 문서를 얼마나 정제하고 정리했는지가 성능을 좌우한다. 형식이 제각각이거나, 버전 관리가 되지 않은 문서는 오히려 성능을 떨어뜨린다. 수집, 전처리, 인덱싱 과정을 반복하면서 다듬는 일이 핵심이다.
3. Pilot이 잘 돌아간다고 실전에서도 잘 되는 것은 아니다
이 부분이 내가 제일 크게 공감했던 내용이다. 실제로 나도 몇몇 프로젝트에서 Pilot 단계에서는 아무 문제 없이 잘 작동했다. 하지만 production 환경에 옮겨가면서부터는 상황이 완전히 달라졌다. latency가 튀고, 캐싱이 안 되고, 보안 요소들이 누락되면서 하나하나 다시 손봐야 했다. 단순히 100개 내외의 문서로는 RAG는 정말 잘 동작한다. 하지만 이게 기업의 전체 문서가 되고 몇 십만 건의 문서가 넘어가면서 이제 온갖 문제들이 터지기 시작한다. 결국 병목은 모델이 아니라 전체 시스템 구조에서 발생했다. Douwe도 같은 말을 했다. Pilot에서는 잘 보이지 않는 문제들이 production에서는 반드시 드러난다. 처음부터 production 기준으로 설계하지 않으면, 나중에 더 큰 비용을 치르게 된다. 운영 환경에서 필요한 요소들을 미리 고려하고, 전체 시스템으로 바라보는 시각이 필요하다.
4. 구조는 단순하고 모듈화돼야 한다
복잡하고 멋진 아키텍처보다, 단순하고 교체 가능한 구조가 장기적으로는 훨씬 유리하다. 검색기, 리랭커, LLM, UI 같은 컴포넌트들이 독립적으로 작동할 수 있어야 유지보수도 편하고 확장도 용이하다. MLOps와 DevOps의 협업을 고려한 구조가 결국 제품의 생명력을 결정한다.
5. 아무리 좋은 모델이라도 UX가 나쁘면 외면받는다
모델이 아무리 좋아도, 사용자 경험이 나쁘면 결국 사용자는 떠난다. 느린 검색, 불명확한 답변, 출처가 없는 결과는 신뢰를 떨어뜨린다. 버튼 배치, 히스토리 기능, 직관적인 인터페이스 같은 기본 요소들이 오히려 실제 사용성을 좌우한다. 기술도 중요하지만 이걸 누가 쓰는지 유저 경험도 고려해야 한다.
6. 측정할 수 없는 것은 개선할 수 없다
느낌만으로는 시스템을 개선할 수 없다. RAG 시스템의 특성상, hallucination 비율, recall@K, 사용자 클릭 피드백 같은 맞춤형 지표들을 정의하고 추적하는 일이 매우 중요하다. 단순한 accuracy보다, 실제 사용자 만족도를 반영하는 지표가 훨씬 더 가치 있다.
7. 사용자 피드백이 가장 강력한 데이터다
서비스는 런칭 이후가 진짜 시작이다. 실패한 응답, 사용 중단 시점, 반복적인 행동 패턴 등을 데이터처럼 수집하고 분석해야 한다. 이 피드백을 retraining에 반영하고 개선하는 사이클을 꾸준히 반복해야 진짜 ‘PMF (Product-Market Fit)’에 도달할 수 있다. 사람들이 스스로 다시 찾아오게 만드는 제품, 그것이 진짜 성공이다.
8. 실패는 빠를수록 낫다
완벽한 제품을 만들겠다는 욕심은 종종 출시조차 못 하게 만든다. 오히려 빠르게 시도하고, 빠르게 실패하고, 빠르게 개선하는 것이 더 현명한 방법이다. “이건 아니다”를 빨리 확인하는 것도 큰 진전이다. 실패는 시간 낭비가 아니라 학습의 속도다.
9. 보안과 프라이버시는 처음부터 고려해야 한다
3번 항목과도 비슷한 내용인데, 엔터프라이즈 시장에서는 보안이 필수 조건이다. GDPR, SOC2, 멀티 tenancy, 접근 권한, 감사 로그 같은 요소들은 제품을 설계할 때부터 포함되어야 한다. “우리는 고객 데이터를 직접 보지 않는다”는 구조를 만들 수 있어야 한다. 그래야 기업 고객의 신뢰를 얻을 수 있다.
10. 기술보다 중요한 것은 팀과 전략이다
좋은 기술만으로는 성공할 수 없다. 궁극적으로 중요한 것은 팀의 조합과 방향성이다. 뛰어난 개발자, 문제를 정의할 줄 아는 PM, 도메인에 대한 깊은 이해를 가진 전문가가 함께할 때 진짜 제품이 만들어진다. 단기적인 기능 개선보다, 장기적인 비전을 그릴 수 있는 팀이 결국 시장에서 살아남는다.
마치며
RAG 시스템을 도입하거나 준비하고 있는 사람이라면, 이 10가지 교훈은 꽤 현실적인 체크리스트가 될 수 있다. 특히 PoC만 잘 되면 다 된 거라고 생각했던 나의 과거 경험을 떠올리며, 다시 한 번 “연습과 실전은 다르다”는 말을 마음에 새기게 된다. 또한 Douwe 의 현장에서 굴러본 경험이 돋보이는 유튜브 영상이었고 현장이 중요하다는 생각을 가지고 있는 내게도 많은 울림을 주는 영상이었다. 시간이 되시는 분들은 꼭 한 번 보셨으면 좋겠다.
유튜브 링크