RAG 챗봇은 왜 복잡한 요청 앞에서 멈추는가?
기업용 RAG 챗봇을 만들고 나면 곧 한계가 보입니다. 질문을 받아 문서를 검색하고 답을 생성하는 이 일직선 구조가 단선 파이프라인입니다. “작년 4분기 실적을 찾아서 올해 전략 제안서 초안까지 써 줘” 같은 요청 앞에서는, 검색하고 답하기만 하는 단선 파이프라인에 그 일을 처리할 경로 자체가 없습니다.
루프와 분기는 왜 지능의 핵심인가?
편의점에 물이 없으면 사람은 지도를 열어 옆 편의점을 찾습니다. 단선 파이프라인은 “없네요” 하고 멈춥니다. 검색에 답이 없으면 검색어를 바꿔 다시 돌고, 그래도 없으면 다른 도구로 갈아타는 것 — 막히면 되돌아가는 루프와 상황에 따라 길을 바꾸는 분기, 이 둘이 지능의 핵심이고, 이 둘을 설계하는 작업이 오케스트레이션입니다.
역할은 셋으로 나뉩니다. 랭체인은 LLM과 대화하는 표준 부품을, 랭그래프는 루프와 분기를 그리는 제어 흐름을, 랭스미스는 시스템 내부를 들여다보는 가시성을 맡습니다. 셋이 모여야 하나의 오케스트레이션 시스템이 됩니다.
가시성이 없으면 무엇을 잃는가? — 세무 상담 자동화
가시성은 자주 외면받지만, 없으면 AI가 내놓은 답의 근거를 역추적할 수 없습니다. 세무 상담을 예로 들면, 담당 직원은 세법 조항과 고객의 증여 이력을 뒤지느라 하루 한두 시간을 씁니다. 이 업무를 자동화하려면 세법 검색과 이력 조회를 오가는 분기가 필요합니다.
게다가 오답이 곧 법적 책임이 되는 영역이라, 어떤 조항과 어떤 이력을 근거로 그렇게 답했는지 감사 로그까지 남아야 합니다. 이 근거를 남기는 일이 바로 가시성이고, 랭스미스가 맡는 몫입니다.
비개발자는 이 설계에서 무엇을 맡는가?
이 설계에서 비개발자의 몫이 생각보다 큽니다. 어떤 데이터를 넣을지 정하는 데이터 오너십, 업무 논리를 플로우차트로 그리는 일, 질문 100개와 모범 답안으로 평가셋을 만드는 일 — 전부 코딩이 아니라 도메인 지식의 영역입니다. 흐름도를 그릴 줄 알면, 코드로 옮기는 일은 바이브 코딩이 해 줍니다.
다만 오케스트레이션은 API 한 번이면 끝날 일에 붙이면 낭비입니다. 루프와 분기가 필요할 만큼 업무가 복잡할 때 꺼내는 도구입니다. AX의 출발점은 도구가 아니라, 업무 흐름을 그릴 줄 아는 도메인 지식입니다.