우리는 왜 AI를 위해 데이터를 복사하고 있을까요? (임베딩의 함정과 Federation)
AI 도입 시 흔히 발생하는 데이터 중복 문제와 'AI 중앙화의 세금'을 지적하며, 그 대안으로 MCP와 Tool Calling을 활용한 Federation 아키텍처를 제안합니다.
송찬영
CTO
안녕하세요. 풀링포레스트 CTO 송찬영입니다.
요즘 개발자들 사이에서 가장 뜨거운 화두는 단연 AI 도입일 겁니다. "우리도 AI-First 기업이 되어야 해"라는 경영진의 선언이 떨어지면, 엔지니어링 팀은 본능적으로 움직이기 시작합니다. 데이터 파이프라인을 구축하고, 문서를 잘게 쪼개고(Chunking), 임베딩(Embedding)을 만들어 벡터 데이터베이스(Vector DB)에 넣습니다. 그리고 그럴싸한 RAG(검색 증강 생성) 파이프라인을 완성하죠. 저 또한 풀링포레스트 초기 AI 도입 단계에서 정확히 이 로드맵을 그렸습니다.
하지만 프로젝트가 진행될수록 묘한 위화감이 들었습니다. 우리가 만드는 것은 서비스의 혁신일까요, 아니면 유지보수해야 할 또 하나의 거대한 '데이터 사본'일까요?
오늘은 우리가 흔히 빠지는 'AI 중앙화의 세금(AI Centralization Tax)'과 그 대안인 'Federation(연합)' 아키텍처에 대해 이야기해보려 합니다.
AI를 위한 별도의 성을 쌓지 마세요
우리가 흔히 범하는 실수는 기존 레거시 시스템 위에 AI만을 위한 병렬 인프라를 또 짓는다는 점입니다. CRM에 있는 고객 데이터, 결제 서버에 있는 청구 이력, 데이터 웨어하우스(Snowflake, BigQuery 등)에 있는 분석 정보를 굳이 벡터 DB로 옮겨옵니다.
이 과정에서 엄청난 비용이 발생합니다. 단순히 클라우드 비용 이야기가 아닙니다. 데이터 싱크(Sync)를 맞추기 위한 ETL 파이프라인의 복잡도, 실시간성이 떨어지는 데이터로 인한 환각(Hallucination), 그리고 무엇보다 비즈니스 로직이 변경될 때마다 임베딩을 다시 해야 하는 운영 비용이 바로 그 '세금'입니다.
솔직히 고백하자면, 저도 "고객의 최근 결제 내역을 알려줘"라는 단순한 질문을 처리하기 위해 수십만 건의 데이터를 벡터화하려던 시절이 있었습니다. 정작 필요한 건 그저 '결제 API'를 호출하는 것뿐이었는데 말이죠.
데이터를 가져오지 말고, 에이전트가 찾아가게 하세요
여기서 'Federation(연합)'이라는 개념이 등장합니다. 거창한 용어 같지만 핵심은 간단합니다. "데이터를 AI 앞으로 가져오지 말고, AI가 데이터가 있는 곳을 조회하게 하라"는 것입니다.
우리가 신입 사원에게 "A 고객사의 최근 이슈가 뭔가요?"라고 물었다고 가정해봅시다. 그 신입 사원은 회사의 모든 문서를 복사해서 자기 책상에 쌓아두고 읽지 않습니다. 대신 사내 CRM에 접속하고, 슬랙 히스토리를 검색하고, 지라(Jira) 티켓을 확인합니다.
AI 에이전트도 똑같습니다. 최신 LLM들은 추론 능력이 뛰어납니다. 굳이 모든 지식을 내부에 담고 있을 필요가 없습니다. 적절한 도구(Tool)만 쥐여주면 됩니다.
RAG가 만능열쇠는 아닙니다
RAG는 훌륭한 기술입니다. 특히 매뉴얼이나 규정집 같은 비정형 텍스트 데이터에는 탁월합니다. 하지만 "이번 달 매출 합계는?"이나 "내 티켓 상태는?" 같은 정형 데이터나 실시간성이 중요한 질문에는 최악의 선택이 될 수 있습니다. 벡터 유사도 검색은 정확한 숫자나 최신 상태 값을 보장하지 못하기 때문입니다.
풀링포레스트 팀은 최근 이러한 문제를 해결하기 위해 MCP(Model Context Protocol)와 Tool Calling(도구 호출)을 적극적으로 도입하고 있습니다.
예를 들어보겠습니다. 기존 방식(RAG)에서는 사용자가 "내 주문 배송됐어?"라고 물으면, 벡터 DB에서 유사한 문서를 찾습니다. 운이 좋으면 어제 크롤링 된 배송 상태 문서를 찾겠지만, 운이 나쁘면 지난달 주문 정보를 가져와 엉뚱한 대답을 합니다.
반면 Federation 방식(Tool Calling)에서는 AI가 스스로 판단합니다.
사용자의 의도가 '배송 조회'임을 파악합니다.
get_delivery_status(order_id)라는 툴을 호출합니다.
실제 배송 서버의 API가 실시간 데이터를 반환합니다.
AI는 "현재 대전 허브에 도착했습니다"라고 정확히 답변합니다.
이 과정에서 우리는 별도의 벡터 인프라를 구축할 필요가 없었습니다. 기존에 있던 API를 AI가 쓸 수 있게 열어주었을 뿐입니다.
지금 당장 시작할 수 있는 변화
물론 모든 것을 Tool Calling으로 해결할 수는 없습니다. 하지만 무작정 벡터 DB부터 도입하기 전에, 여러분의 유스케이스를 냉정하게 돌아봤으면 합니다.
여러분의 AI가 해야 할 일이 "우리 시스템에 있는 X 정보를 가져와 줘"와 같은 형태라면, 멈추십시오. 복잡한 임베딩 파이프라인 대신, AI 에이전트에게 기존 시스템을 조회할 수 있는 '권한'과 '도구'를 주는 것이 훨씬 효율적이고 강력합니다.
기술은 결국 문제를 해결하기 위해 존재합니다. 화려한 아키텍처보다 중요한 것은, 지금 당장 실무에 적용 가능하고 유지보수 가능한 구조를 만드는 것입니다. AI를 위해 시스템을 다시 짓지 마세요. 이미 여러분이 훌륭하게 구축해 둔 기존 시스템과 AI가 대화하게 만드세요. 그것이 가장 빠른 길입니다.
이 글이 AI 인프라 구축을 고민하는 테크 리더분들께 작은 힌트가 되었으면 좋겠습니다. 데이터의 늪에서 허우적대기보다, 똑똑한 에이전트를 키워내는 즐거움을 느끼시길 바랍니다.
