불변(Immutable) RAG 에이전트. 우리는 이 방식을 선택했는데, LangChain을 실무에서 돌리는 분들의 솔직한 피드백을 구합니다.
Immutable RAG agents. We made the bet, looking for honest pushback from people running LangChain in production
핵심 요약
배포된 RAG 에이전트를 수정하지 않고 버전 관리로만 운영하는 아키텍처에 대한 실무자들의 의견을 구하는 글.
- 불변성 아키텍처 — 배포된 RAG 에이전트를 수정하지 않고 버전 관리로 대응함.
- 규제 준수 — 의료, 금융 등 감사 요구사항이 엄격한 산업군을 타겟으로 함.
- 성능 트레이드오프 — 최신 모델이나 기술을 즉시 반영할 수 없는 단점이 존재함.
- 생산 환경 재현성 — 특정 시점의 에이전트 상태를 증명해야 하는 문제를 해결하고자 함.
저는 ConnexŪS Ai에서 전략 담당자로 일하고 있습니다. 엔지니어링 쪽은 아니지만, 저희 RAG 플랫폼(RAGböx)을 구축하는 팀과 긴밀히 협력하고 있습니다. 제가 이 글을 쓰는 이유는 저희가 내린 아키텍처적 결단에 대해 이 커뮤니티의 냉정한 피드백을 받고 싶기 때문입니다.
저희의 결단: RAG 에이전트는 배포되면 불변(Immutable) 상태가 됩니다. 한 번 작성하면 실행만 가능합니다. 배포 후에는 프롬프트, 검색 로직, 파인튜닝을 수정하지 않습니다. 무언가 변경해야 한다면 기존 에이전트를 수정하는 대신 새로운 버전의 에이전트로 업그레이드합니다.
이유: 저희의 타겟 고객은 법률, 의료, 금융 분야입니다. 이들은 특정 시점에 모델이 어떤 출력을 생성했는지 증명해야 하는 감사 요구사항이 있습니다. 지속적인 평가 시스템은 이를 어렵게 만듭니다. 불변성은 '날짜 Y에 출력 X를 생성한 에이전트는 현재 버전 Z로 배포된 에이전트다'라는 식으로 질문을 단순화하여 이 문제를 해결합니다.
트레이드오프는 불편합니다. 배포된 에이전트를 반복적으로 개선할 능력을 잃게 됩니다. 베이스 모델은 계속 좋아지고, 검색 기술도 계속 진화하니까요. 저희는 고객들이 그 트레이드오프를 받아들일 것이라고 베팅하고 있습니다. 장기적으로 옳은 결정인지 100% 확신할 수는 없습니다.
같은 방향의 다른 아키텍처 선택들:
정의된 신뢰도 임계값 미만일 경우 낮은 신뢰도의 출력을 생성하는 대신 답변을 거부하는 '침묵 프로토콜(Silence Protocol)'. 규제 준수에는 옳지만, 일반적인 Q&A에는 답답할 수 있습니다.
사용자가 업로드한 문서 내에서만 근거를 찾는 인용(Citation grounding). 외부 지식이나 모델 내부의 기억은 사용하지 않습니다. 출력물은 페이지와 문단을 인용합니다.
Weaviate 벡터 저장소 위에서의 Self-RAG 반성 루프. 고객 관리 키를 사용한 AES-256 암호화. ABAC 접근 제어. 암호화 해싱을 통한 불변 감사 추적(Veritas).
선택적 에이전트 간 인식. 멀티 에이전트 배포는 사용 사례에 따라 전체 상호 컨텍스트, 부분적 인식, 또는 완전히 격리된 에이전트로 실행될 수 있습니다.
참고로, 저희 모회사(Visium Technologies)가 어제 인수 의향서(LOI)를 발표했습니다. 기업 배경이 궁금하신 분들을 위해 링크를 남깁니다:
제가 이 커뮤니티에 정말 묻고 싶은 질문은 이것입니다:
현재 LangChain(또는 LangGraph나 LlamaIndex)을 실무에서 돌리고 계신다면, 내일 이해관계자가 '날짜 X에 사용된 에이전트가 무엇이었나?'라고 물었을 때 자신 있게 답할 수 있으신가요? 아니면 솔직히 '찾아봐야 한다'고 답하시겠습니까?
불변성이라는 베팅이 장기적으로 옳은 선택인지, 아니면 과잉 대응인지 저는 정말 모르겠습니다. 하지만 생산 환경에서의 재현성이라는 근본적인 문제는 이 생태계가 아직 완전히 씨름하지 못한 부분이라고 생각합니다. 다른 팀들이 실제로 이 문제를 어떻게 해결하고 있는지(혹은 해결하지 못하고 있는지) 듣고 싶습니다.
앞으로 몇 시간 동안 댓글을 확인하겠습니다. 솔직한 피드백 환영합니다. 동의보다 더 환영합니다.
