AX 담당자를 위한 RAG 기초: 개념부터 실제 업무까지

기업의 AX 담당자분들을 만나보면, AI 업무를 맡은 뒤 관련 개념을 하나씩 익히는 분들이 많았습니다. 기술을 깊이 이해하는 분들도 계셨지만, 이제 막 사내 AI 도입을 검토하기 시작한 분들에게 RAG나 임베딩 같은 용어는 낯설 수밖에 없습니다.

그런데 RAG를 검색하면 대부분 개발자를 위한 구현 방법이 나옵니다. 개발 지식 없이도 사내 문서를 활용하는 AI가 어떻게 일하는지 이해할 수 있으면 좋겠다고 생각했습니다. 그래서 회의록 하나를 찾아 읽는 일부터 시작해 보려 합니다.

회의록을 읽고 메일을 쓰는 일

AI에게 “A사와 B기능까지 개발하기로 했으니 확인 메일을 써줘”라고 요청하면, 알려준 내용을 바탕으로 메일을 작성합니다. 필요한 정보는 이미 요청 안에 들어 있습니다.

이번에는 “A사 회의록을 찾아서 확인 메일을 써줘”라고 해보겠습니다. AI는 먼저 회의록을 찾고, 어떤 내용에 합의했는지 읽어야 합니다. 그 내용을 참고해 메일을 작성하는 과정이 RAG입니다. 필요한 자료를 검색하고, 찾은 내용을 바탕으로 답변이나 문서를 만드는 방식입니다.

회의록에 “B기능까지 개발하고, 일정은 추후 협의한다”라고 적혀 있다면 메일에도 그 내용이 담겨야 합니다. AI가 할 일은 합의 내용을 잘 전달하는 것입니다. 정하지도 않은 일정을 그럴듯하게 채워 넣는 것이 아닙니다. 문서 검색과 생성이 어떻게 연결되는지 이해하면 RAG의 기본 개념은 잡힌 셈입니다.

문서를 읽는 단계부터 문제가 생깁니다

원리는 간단하지만, 실제 회사 문서를 다루기 시작하면 일이 복잡해집니다. PDF 안의 표에서 텍스트를 꺼냈는데 이름과 연구자번호의 순서가 뒤섞일 수 있습니다. 글자는 모두 추출했어도 누가 어떤 번호를 가진 사람인지는 알 수 없게 되는 겁니다.

문서를 작게 나눌 때도 비슷한 문제가 생깁니다. 검색하기 편하도록 나눈 문서 조각을 ‘청크’라고 부르는데, 글자 수에 맞춰 자르다 보면 이름은 앞 조각에, 번호는 뒤 조각에 남기도 합니다. 나중에 AI가 한 조각만 읽는다면 제대로 답하기 어렵습니다. 표의 구조와 정보 사이의 관계를 살려서 읽고 나누는 일이 중요한 이유입니다.

그다음에는 질문에 맞는 조각을 찾아야 합니다. 임베딩과 벡터 검색은 표현이 조금 달라도 의미가 가까운 내용을 찾는 데 쓰입니다. 다만 이름이나 번호처럼 정확히 구분해야 하는 정보도 있어, 키워드 검색을 함께 활용하기도 합니다. 문서를 어떻게 읽고 나눴는지, 어떤 방식으로 찾는지가 최종 답변에 모두 영향을 줍니다.

잘 찾는 것과 빠짐없이 찾는 것

“상반기에 Wissly 도입 문의를 준 모든 업체를 찾아서 표로 정리해줘.”

얼핏 보면 문서 검색 AI가 쉽게 처리할 것 같은 요청입니다. 하지만 관련성이 높은 일부 자료만 골라 읽는 검색 방식으로는 곤란합니다. 상위 몇 개의 검색 결과만 AI에 전달하는 Top-K 검색에서는, 뒤로 밀린 업체의 정보가 아예 전달되지 않을 수 있기 때문입니다.

이 일을 맡긴 사람은 관련 업체 몇 곳이 궁금한 게 아닙니다. 조건에 맞는 업체를 모두 알고 싶은 겁니다. 한 건의 정보를 정확히 찾는 일과 전체 목록을 빠짐없이 만드는 일은 처리 방식부터 달라야 합니다. 저희도 Wissly를 개발하면서 이런 차이를 계속 마주했습니다.

계산이 필요한 업무도 마찬가지입니다. 자료에서 숫자를 찾았다고 분석이 끝나는 것은 아닙니다. 이때는 AI가 계산할 코드를 작성하고, 별도 환경에서 실행한 결과를 받아 설명하도록 할 수 있습니다. 언어 모델이 숫자를 그럴듯하게 답하는 데 맡기지 않고, 계산 과정을 실제로 실행하도록 하는 접근입니다.

“문서에 없어서 작성할 수 없습니다”

저희가 초기에 특히 어려움을 겪었던 문제입니다. AI가 없는 사실을 지어내지 않도록 “문서에 없는 내용은 만들지 말라”는 지침을 넣었습니다. 정보를 찾아 답할 때는 필요한 지침이었습니다.

그런데 새 사업계획서의 초안을 작성해 달라고 하면 문제가 생겼습니다. 새로 쓸 문서가 기존 자료에 그대로 있을 리 없는데, AI는 해당 내용이 없다며 작성을 거절하는 겁니다. 회사 자료와 공고문을 참고해서 써 달라는 요청을, 이미 완성된 문서를 찾아 달라는 요청처럼 받아들이는 셈입니다.

저희도 처음에는 지침에 조건을 덧붙였습니다. 조회할 때는 사실만 말하고, 작성할 때는 창의적으로 쓰라는 식이었습니다. 하지만 동작이 안정적이지 않았습니다. 이 문제를 풀려면 요청의 의도를 먼저 판단하고, 조회와 작성 등 목적에 맞는 지침을 적용하는 방법을 생각해 볼 수 있습니다.

사실을 정확히 찾아야 할 때와 그 사실을 바탕으로 새로운 초안을 써야 할 때, AI가 맡는 역할은 다릅니다. 같은 회사 자료를 사용하더라도 어떤 일을 요청받았는지에 따라 다르게 움직여야 합니다.

검색한 자료가 실제 업무로 이어질 때

저희 팀은 연구노트를 작성할 때 GitHub에 쌓인 개발 변경 이력을 활용합니다. 작업 내용을 가져와 읽고, 이를 바탕으로 연구노트 초안을 작성하도록 했습니다. 이후 IRIS 등록과 승인 처리까지는 별도의 업무 자동화를 연결했습니다. RAG는 그중 실제 작업 기록을 읽어 초안을 만드는 데 쓰입니다.

고객 문의 응대에도 활용했습니다. 반복해서 들어오는 질문에 매번 같은 대화를 이어가는 일이 많았기 때문입니다. 과거 상담 기록을 정리해 FAQ와 가이드로 만들고, AI가 관련 자료를 찾아 답변하도록 했습니다. 회사 안에 이미 쌓여 있던 정보가 매일의 업무에 쓰이기 시작한 것입니다.

RAG를 업무에 적용하다 보면 한 단계의 문제를 해결하려고 전체 구성을 다시 살펴봐야 할 때가 많습니다. 문서를 읽는 방식, 검색 범위, 답변 지침이 서로 연결되어 있기 때문입니다. 그래서 저희는 RAG를 한 번 구축하고 끝나는 기능으로 보지 않습니다. 실제 요청과 결과를 보면서 계속 다듬어야 하는 일입니다.

Wissly가 하려는 일도 여기에 있습니다. 회사 안에 쌓여 있지만 찾고 활용하기 어려웠던 자료를, 실무자가 일을 할 때 꺼내 쓸 수 있게 만드는 것입니다. 우리 회사의 문서로 어떤 업무를 맡길 수 있을지 고민하고 계시다면 함께 이야기해 보고 싶습니다.