RAG와 AI 에이전트 차이, 기업 데이터 접근 방식 고르는 기준

RAG와 AI 에이전트 차이는 AI가 답할 자료를 사람이 미리 정리해 검색하게 하느냐, 규칙만 주고 AI가 직접 찾아가게 하느냐에 있습니다. 이 글은 두 방식이 어떻게 다른지, 최근 에이전트 방식이 가능해진 이유, 기존 RAG가 여전히 나은 경우, 기업이 에이전트를 도입할 때 둬야 할 통제 장치를 개념 중심으로 설명합니다.

기존 RAG는 도서관 서가를 정리해 주는 방식

RAG(검색 증강 생성, Retrieval-Augmented Generation)는 AI가 답하기 전에 관련 문서를 찾아 함께 읽게 하는 방식입니다. 좋은 답을 얻으려면 문서를 미리 정리해야 했습니다. 문서를 잘게 나누고(청킹), 숫자로 바꾸고(임베딩), 벡터 DB(의미가 비슷한 문서를 빨리 찾는 저장소)에 넣어 검색하기 좋은 형태로 만드는 과정입니다.

도서관에 비유하면 AI가 책을 잘 찾도록 서가와 색인을 꼼꼼히 정리해 주는 일입니다. 이 정리가 부실하면 AI가 엉뚱한 책을 가져옵니다.

에이전트 방식은 능숙한 사서가 직접 찾아가는 방식

최근의 AI 에이전트는 훨씬 능숙한 사서처럼 움직입니다. 어디를 찾아보라고 일일이 말하지 않아도 질문의 의도를 파악해 데이터베이스를 찾아가고, 필요한 도구를 고르고, 정보가 부족하면 다른 곳까지 확인합니다. 그래서 데이터를 무조건 벡터 DB에 넣기 전에, 에이전트가 직접 접근하는 방법부터 검토해 볼 수 있게 됐습니다.

방식은 이렇습니다.

• 문서를 넣어도 되고, 임베딩은 해도 되고 안 해도 됩니다.
• 데이터베이스나 스토리지를 에이전트에 연결합니다.
• 에이전트에게 규칙을 줍니다. "이 사용자가 권한이 없는 자료는 쓰지 마", "여기까지만 찾아"처럼 범위와 금지를 먼저 정해 둡니다.
• 질문이 들어오면 에이전트가 그 규칙의 경계 안에서 알아서 찾아봅니다.

사람이 개입하던 판단을 똑똑해진 모델이 대신하는 예는 다음과 같습니다.

• 정보 10개를 가져온 뒤, 이 사용자가 10개를 다 볼 권한이 있는지 한 번 더 점검합니다.
• 7개만 권한이 있으면 7개만 가지고 답합니다.
• 7개로 부족해 보이면 다시 가서 더 가져온 뒤 답합니다.

코딩 도구에서는 이미 흔한 방식입니다. 클로드 코드는 초기에 코드 전체를 벡터 DB로 색인하는 RAG를 썼다가, 모델이 grep·glob 같은 검색 명령을 직접 실행하는 에이전트 검색으로 바꾼 것으로 알려져 있습니다. 색인 관리의 복잡함, 코드가 바뀌면 색인이 낡는 문제, 색인이 어디에 저장되느냐에 따른 보안⁠·개인정보 문제가 이유로 거론됩니다. 다만 이 판단은 코드를 탐색하는 경우의 이야기이고, 사내 문서 전체에 그대로 적용된다는 근거는 아닙니다.

그래도 기존 방식이 나을 때

회사 DB와 ERP 시스템(전사적 자원 관리 시스템)을 에이전트가 권한 안에서 다 열어 볼 수 있다면, 수집하고 청킹하고 임베딩까지 하는 기존 방식이 굳이 필요할까요? 에이전트가 모든 곳을 직접 찾아가는 쪽이 장기적인 방향일 수 있지만, 그 길에는 늘 보안이 따라옵니다. 그래서 다음 세 경우에는 기존 방식이 여전히 맞을 수 있습니다.

• 특정 테이블: DB 접근을 사람이 통제하는 편이 맞는 데이터가 있습니다.
• 비정형 문서: 정리돼 있지 않은 문서(보고서, 메모, PDF)는 임베딩 방식이 의미를 찾는 데 더 나을 수 있습니다.
• 데이터가 많거나 종류가 다양할 때: 양이 많아지고 문서 종류가 정말 다양하면 임베딩 방식의 성능이 더 좋은 경우가 있습니다.

에이전트 방식이 무조건 정답은 아닙니다. 기업 상황과 보안 수준에 따라 고를 수 있게 설계하는 것이 현실적입니다. 에이전트가 앞으로 어떻게 바뀔지 모르니, 체제를 너무 급하게 고정하지 않는 것도 방법입니다.

에이전트가 똑똑해진 이유 네 가지

지난 1년 사이에 에이전트 방식을 현실로 만든 변화는 크게 네 가지입니다.

첫째, 컨텍스트가 커졌다

컨텍스트 윈도우(AI가 한 번에 읽을 수 있는 분량)는 2024년에 널리 쓰이던 GPT-4o 같은 모델이 128K(약 12만 토큰)였습니다. 지금은 100만 토큰급을 내세우는 모델이 여럿이라 여덟 배쯤 넓어졌습니다. 옛날에는 문서 하나를 올려 처리했다면, 긴 문서나 폴더를 통째로 넣어 두고 에이전트가 검색해서 가져오게 할 수 있습니다. 모델마다 실제 한도는 다르니 쓰는 모델의 공식 사양을 확인합니다.

둘째, 도구를 알아서 부른다

예전에는 이미지를 만들거나 웹 검색을 하려면 사용자가 토글을 직접 켜야 했습니다. 지금은 "이런 이미지를 만들어 줘"라고만 해도 이미지 생성 도구를 불러야겠다고 에이전트가 스스로 판단합니다. 매번 "문서 DB에 접근해서 이걸 가져와"라고 말하지 않아도 됩니다.

셋째, 대화가 길어져도 맥락을 잃지 않는다

예전에는 한참 대화하다 "그거 뭐였지?" 하면 잊어버리는 일이 많았습니다. 지금은 컨텍스트 윈도우가 길어진 데다, 에이전트가 요점만 압축하는 콤팩션(compaction) 작업을 스스로 합니다. 그래서 문서를 여러 개 넣어도 긴 작업의 맥락을 이어 갑니다.

넷째, 코딩 도구는 관련 파일을 알아서 연다

코덱스나 클로드 코드에서 "로그인 흐름을 찾아서 문제를 고쳐 줘"라고 하면, 에이전트가 관련 있는 파일을 골라 열고 수정합니다.

그래서 접근 순서를 이렇게 제안할 수 있습니다. 임베딩을 무조건 1순위로 생각하지 말고, 에이전트로 먼저 접근해 보고 부족하면 임베딩을 더합니다.

바뀌지 않는 것, 데이터의 질

기술이 달라져도 바뀌지 않는 것은 데이터의 가치입니다. 데이터의 질이 답변 품질에 직접 영향을 주고, 이는 RAG라는 말이 없던 시절부터 같았습니다.

빅데이터 분야에서 자주 쓰는 DIKW 피라미드(Data·Information·Knowledge·Wisdom)가 좋은 예입니다. 데이터가 모여 정보가 되고, 정보가 모여 지식이 되고, 그 지식을 활용한 지혜가 맨 위에 있습니다. 맨 밑 층이 사실이 아니면 위 단계가 모두 꼬입니다. 그래서 불필요하거나 애매한 데이터는 오히려 빼는 편이 낫습니다. 많이 넣는 것보다 정확한 것을 넣는 쪽이 에이전트의 판단을 돕습니다.

에이전트를 통제하는 연결 계층

에이전트가 많아지면 새로운 질문이 생깁니다. 누가 만든 에이전트인지, 어떤 데이터를 받는지, 비용을 얼마나 썼는지, 일을 제대로 하고 있는지입니다. 직원에게 사번과 권한, 업무 평가가 있듯이 에이전트에도 신분과 업무 이력이 필요해집니다. 기업 AI의 경쟁력은 에이전트를 많이 만드는 데서 나오지 않고, 안전하게 키우고 평가하고 필요하면 멈출 수 있는 체계를 갖추는 데서 나옵니다.

도입할 때 중간 계층(미들웨어)에 둘 만한 장치는 다섯 가지입니다.

• 수집⁠·인덱싱 통제(거버넌스) 계층: 임베딩해 둔 데이터를 어떤 규칙으로 답변에 쓸지, 비식별 처리나 마스킹을 할지, 보안 등급을 어떤 기준으로 나눌지 정합니다. 에이전트가 판단하는 기준이 이 계층에서 만들어집니다.
• 권한 확인 계층: 에이전트를 만든 사람과 쓰는 사람은 각자 권한이 다르고 볼 수 있는 데이터도 다릅니다. 이 권한을 확인하는 계층은 반드시 있어야 합니다.
• 모델 관리와 도구 관리 계층: 어떤 LLM을 쓰는지 관리하고, 에이전트가 쓸 수 있는 도구⁠·스킬⁠·MCP·커넥터를 관리합니다.
• 감사 로그: 어떤 질문에 대해 어디를 어떤 데이터로 보았고, 어디까지 접근했고, 어떤 결과를 만들었는지 전체 흐름을 기록합니다. 늘 잘 통제되면 좋겠지만 그렇지 않은 경우가 생기기 때문입니다.
• 에이전트 아이디와 평가: 직원에게 사번이 있듯 에이전트에게도 아이디를 주고, 권한⁠·감사 항목⁠·쓴 비용(토큰)·결과물의 품질 평가를 붙입니다. 결과물이 사람이 쓸 만한지 평가해서 아니라면 손봅니다.

권한 확인에는 주의할 점이 있습니다. 앞에서 에이전트가 10개 중 권한이 있는 7개만 골라 쓴다고 했지만, 접근 통제를 모델의 판단에만 맡겨서는 안 됩니다. 모델은 지시를 잘못 해석하거나 속을 수 있습니다. LLM 보안 가이드(OWASP)도 권한 확인을 모델 바깥의 연결 시스템에서 하고, 영향이 큰 행동에는 사용자 승인을 두라고 권합니다. 에이전트의 판단은 한 겹 더 거르는 장치로 두는 것이 안전합니다.

에이전트를 신입 직원처럼 키우기

도입할 때 에이전트를 신입 직원이라고 생각하면 편합니다. 예전에는 막 만들어서 공유한 뒤 "넌 여기까지만 지식을 써" 정도로 세팅하곤 했습니다. 신입이라면 볼 수 있는 데이터 권한이 한정적이어야 하고 범위도 작게 줍니다. 정직원이 되면 더 많은 걸 맡기듯이, 에이전트도 권한을 한꺼번에 열지 않고 하나씩 열어 주고 스킬도 하나씩 붙이면서 천천히 넓힙니다.

도입 전에 점검할 순서

1. 에이전트가 답해야 할 자료가 어디에 있는지 목록을 만듭니다. 데이터 질이 낮은 것은 이때 거릅니다.
2. 자료마다 접근 방식을 정합니다. 구조가 잘 잡힌 DB는 에이전트 직접 접근, 비정형 문서나 대량 자료는 임베딩 검색을 고려합니다.
3. 사용자별 권한을 데이터 쪽에서 강제합니다. 처음에는 읽기 전용으로 시작합니다.
4. 감사 로그를 켜고, 에이전트마다 아이디를 부여합니다.
5. 작은 범위로 시작해 평가하고, 문제가 없으면 권한과 도구를 하나씩 늘립니다.