왜 대부분의 기업용 AI 프로젝트가 기대에 미치지 못하는가

기업들은 그 어느 때보다 AI에 더 많은 투자를 하고 있지만, 그 투자의 대부분은 이사회가 기대하는 성과를 내지 못하고 있습니다. 에이전트(Agents)는 종종 중요한 문맥(Context)을 놓칩니다. RAG 파이프라인(RAG pipelines)은 잘못된 정보를 가져옵니다. 내부 코파일럿(Internal copilots)은 데모에서는 좋아 보이지만 실제 사용자 콘텐츠를 다룰 때는 어려움을 겪습니다. 문제가 발생하면 팀들은 보통 모델(Model)을 가장 먼저 점검합니다. 그다음 파이프라인을 살펴보고 더 나은 청킹(Chunking), 새로운 임베딩(Embeddings), 다른 벡터 데이터베이스(Vector database), 또는 리랭커(Re-ranker)를 추가하는 시도를 합니다. 이러한 단계들이 도움이 되기는 하지만, 대개 문제가 발생하는 지점은 그곳이 아닙니다.

진짜 문제는 입력(Input)에서 시작됩니다. 파이프라인으로 전송되는 문서들이 AI가 사용할 수 있는 형식이 아니며, 아무리 다운스트림(Downstream) 작업을 수행하더라도 이를 완전히 해결할 수는 없습니다. 만약 스캔된 PDF가 임베딩(Embeddings) 단계에 도달하기 전에 구조화되지 않은 문자들의 엉망진창인 상태로 변한다면, 임베딩은 잘못된 콘텐츠를 가지고 작업하는 것입니다. 만약 다국어 계약서가 영어로만 작성된 것처럼 취급된다면, 모델은 이해할 수 없는 텍스트를 바탕으로 결정을 내리게 됩니다. 만약 코드베이스(Codebase)가 기능(Function) 단위가 아닌 줄 수(Line count) 기준으로 나뉜다면, 코드 인식 에이전트(Code-aware agent)는 실제 의미가 없는 조각들을 가지고 작업하게 됩니다. 이것이 바로 업계가 충분히 투자하지 않은 계층이며, 귀하의 AI 스택(AI stack)이 작동할지 여부를 결정하는 핵심 요소입니다.

'AI-ready'가 의미하는 것: AI-ready 콘텐츠는 단순히 가공되지 않은 텍스트(Raw text) 그 이상입니다. 예를 들어, 계약서에는 당사자, 조항, 정의, 그리고 의무 구조가 있습니다. 연구 보고서에는 서로 연결된 섹션, 도표, 표, 각주, 그리고 인용문이 포함됩니다. 코드베이스에는 모듈, 함수, 임포트(Imports), 그리고 호출 그래프(Call graphs)가 있습니다. 이 중 어느 하나라도 단순히 문자로 축소해 버린다면, 그 가치의 대부분을 잃게 됩니다. 문서가 AI-ready 상태라면 그 구조가 온전하게 유지됩니다. 제목은 제목으로 남습니다. 표는 행과 열을 유지합니다. 문서 전체가 하나의 언어로 되어 있다고 가정하는 대신, 각 섹션의 언어가 식별됩니다. 코드는 구문(Syntax)을 따르는 단위로 분할됩니다. 문서 간의 상호 참조(Cross-references)는 일반 텍스트로 변환되지 않고 링크로 유지됩니다.

테스트 방법은 간단합니다. 다운스트림 (Downstream) AI 시스템이 이 콘텐츠를 재구조화하지 않고도 올바르게 사용할 수 있는가? 만약 그렇지 않다면, 텍스트가 아무리 깨끗해 보이더라도 그 콘텐츠는 AI-ready (AI 준비 완료) 상태가 아닙니다.

입력 계층 (Input layer)이 취약할 때 다운스트림에서 발생하는 문제들

이러한 문제들은 증상이 실제 원인과 멀리 떨어진 곳에서 나타나기 때문에 종종 오진되곤 합니다. 검색 시스템 (Retrieval system)이 오래된 정책을 보여준다면, 이는 문서에 명확한 타임스탬프 메타데이터 (Timestamp metadata)가 부족했거나, 서로 구별할 방법이 없는 거의 동일한 복사본 세 개가 포함되어 있었기 때문일 수 있습니다. 팀은 벡터 데이터베이스 (Vector database)를 탓하지만, 데이터베이스가 문제는 아닙니다. 인제스션 (Ingestion, 데이터 수집) 과정에서 메타데이터를 추출하지 못한 것이 원인입니다.

에이전트 (Agent)가 분기 보고서에 대한 질문에 자신감 있게 틀린 숫자로 답변할 수도 있습니다. PDF가 스캔되었고, OCR (광학 문자 인식)이 일부 세부 사항을 놓쳤으며, 재무 표의 한 행이 엉망이 되었고, 에이전트는 그 틀린 숫자를 사실로서 반복한 것입니다. 팀은 모델이 문제라고 생각하지만, 모델은 단지 주어진 텍스트를 바탕으로 작동했을 뿐입니다.

다국어 지원 코파일럿 (Copilot)이 영어로는 잘 작동하지만 독일어와 일본어에서는 어려움을 겪을 수도 있습니다. 파이프라인 (Pipeline)이 각 문서가 단 하나의 언어로만 되어 있다고 가정했기 때문에, 혼합된 언어가 포함된 티켓들이 처음부터 잘못 처리된 것입니다.

코드 인지 에이전트 (Code-aware agent)가 함수를 깨뜨리는 리팩토링 (Refactor)을 제안할 수도 있는데, 이는 함수 전체를 한꺼번에 보지 못했기 때문입니다. 저장소 (Repository)가 800자 단위 세그먼트로 분할되어 함수가 두 개의 임베딩 (Embeddings)에 걸쳐 나뉘었기 때문입니다.

원인은 입력 단계에 있습니다. 합성 테스트 데이터 (Synthetic test data)에서는 건강해 보이는 파이프라인이 실제 기업용 콘텐츠에서는 성능이 저하되며, 이러한 저하는 문서의 복잡성이 가장 높은 곳에서 가장 두드러지게 나타납니다.

추출 (Extraction)이 이해 (Understanding)와 같지는 않습니다

대부분의 팀은 이 차이에 대해 준비가 되어 있지 않습니다. 추출은 단순히 파일에서 문자를 뽑아내는 것입니다. 이해는 다른 시스템이 중요한 세부 사항을 잃지 않고 사용할 수 있는 출력을 만들어내는 것입니다. 실제로 이는 다음과 같은 것들을 처리해야 함을 의미합니다: 스캔된 PDF, 디지털로 생성된 (Born-digital) PDF, 혼합된 PDF, 또는 일부 손상된 PDF.

실제 정보를 포함하고 있는 차트 및 다이어그램을 포함한 이미지(Images). 화자 식별(Speaker attribution), 타임스탬프(Timestamps), 그리고 주제 구조(Topic structure)가 전사(Transcription) 이상의 의미를 갖는 오디오 및 비디오(Audio and video). 단순한 HTML보다는 렌더링된 DOM 구조에 의존하는 웹 콘텐츠(Web content). 언어, 파일 경계, 그리고 심볼 구조(Symbol structure)를 인식하며 코드로 파싱되는 코드(Code). 이 프로세스는 일관되어야 합니다. 동일한 계약서라면 PDF, Word 파일, 또는 스캔된 이미지로 제공되더라도 동일한 방식으로 처리되어야 합니다. 출력 형식(Output format)은 모든 콘텐츠 유형에 대해 동일하게 유지되어야 합니다. 표(Tables)는 표로 유지되어야 하며, 계층 구조(Hierarchy)는 계층 구조로 유지되어야 합니다. 또한 중첩된 콘텐츠(Nested content)도 처리할 수 있어야 합니다. 예를 들어, 세 개의 PDF 첨부 파일과 임베디드 이미지가 포함된 이메일은 단순히 하나가 아니라 실제로는 문서들의 그룹입니다. 저장소(Repository)는 단순한 파일 목록이 아니라 트리(Tree) 구조처럼 구성됩니다. 만약 콘텐츠 레이어(Content layer)가 이러한 구조들을 평탄화(Flatten)해 버린다면, 입력값의 가치를 만드는 요소의 상당 부분을 잃게 됩니다.

기존 스택에서의 위치: 대부분의 AI 엔지니어링 팀은 이미 프레임워크(Framework), 벡터 데이터베이스(Vector database), LLM 제공업체(LLM provider), 그리고 오케스트레이션 도구(Orchestration tool)를 선택했습니다. 그들은 파이프라인(Pipeline)을 재구축하도록 강요하는 콘텐츠 레이어를 원하지 않습니다. 훌륭한 문서 인텔리전스 레이어(Document intelligence layer)라면 그럴 필요가 없어야 합니다. Kreuzberg는 기존 파이프라인의 시작 부분에서 연결되며 LangChain, Haystack, LlamaIndex, Spring AI, txtai, 그리고 CrewAI와 직접 연동됩니다(목록은 계속 늘어나고 있습니다!). 파이프라인의 나머지 부분은 그대로 유지됩니다. 단지 올바른 형식의 콘텐츠를 받기 시작할 뿐입니다.

배포에 대해서도 동일한 개념이 적용됩니다. 일부 콘텐츠는 관리형 클라우드 서비스(Managed cloud service)를 통할 수 있습니다. 일부는 컴플라이언스(Compliance)를 위해 셀프 호스팅(Self-hosted) 상태로 유지되어야 합니다. 일부는 에어갭(Air-gapped) 환경에서 실행되어야 합니다. 대부분의 기업에게 단 한 가지 모드로만 작동하는 문서 인텔리전스 레이어는 실용적인 솔루션이 아닙.

인프라 레이어로서의 Kreuzberg Cloud: 팀들은 종종 콘텐츠 레이어를 일회성 통합 작업으로 간주하기 때문에 이를 재구축해야 하는 상황에 놓입니다. 그들은 문서를 가져와서 텍스트를 추출하고 다음 단계로 넘어갑니다.

하지만 그 후 새로운 콘텐츠 유형이 나타나거나, 다국어 사용 고객이 합류하거나, 누군가 비디오를 추가하고 싶어 하거나, 혹은 감사관이 데이터가 어디에서 처리되는지 묻게 됩니다. 이 각각은 개별적으로는 작은 변화입니다. 하지만 이들이 모이면, 6개월 전에는 완벽해 보였던 콘텐츠 파이프라인 (content pipeline)이 왜 현재 로드맵의 세 가지 항목을 가로막고 있는지 설명해 줍니다. 이것이 바로 문서 지능 (document intelligence)이 인프라 문제인 이유입니다. 이는 대규모 (at scale)로 작동해야 하며, 기업이 사용하는 모든 콘텐츠 유형을 처리할 수 있어야 하고, 데이터가 실행될 수 있는 곳이라면 어디에서든 실행되어야 하며, AI 스택 (AI stack)이 변경되더라도 신뢰성을 유지해야 합니다. Kreuzberg Cloud는 바로 그 역할을 위해 구축되었습니다. 귀하의 AI 프로젝트가 어디에서 정확도를 잃고 있는지 알고 싶으십니까? 가장 빠른 테스트 방법은 파이프라인에서 실제 콘텐츠를 가져와 Kreuzberg를 통해 실행한 다음, 그 결과를 현재 파이프라인이 생성하는 결과와 비교하는 것입니다. 만약 차이가 작다면 문제는 다른 곳에 있습니다. 만약 큰 차이가 있다면, 귀하는 방금 귀하의 스택에서 가장 비용 효율적인 해결책을 찾아낸 것입니다.