AI를 위한 데이터 파이프라인·거버넌스 실무 가이드

왜 AI에 데이터 파이프라인과 거버넌스가 필요한가

모든 머신러닝 모델은 데이터로 학습하고 데이터로 평가된다. Datasheets for Datasets논문는 데이터셋의 성격이 모델의 행동을 근본적으로 좌우한다고 짚는다. 실제로 쓰이는 환경이 학습·평가 데이터와 맞지 않거나, 데이터에 원치 않는 사회적 편향이 담겨 있으면 모델은 현장에서 제대로 작동하지 않는다. 채용·금융·형사사법처럼 결과가 무거운 분야에서는 이런 어긋남이 심각한 피해로 이어질 수 있다고 이 논문은 경고한다.

생성형 AI에서는 문제가 한 겹 더 늘어난다. Google Cloud 글글은 거버넌스가 없을 때의 위험으로 여러 시스템에 갇힌 데이터(사일로), 부정확한 데이터로 인한 AI 에이전트의 환각, 권한 없는 사람에게 민감 데이터가 답변으로 흘러나가는 문제, GDPR·CCPA 같은 규제 위반을 든다. IBM 글글도 이제 거버넌스가 RAG(검색 증강 생성) 시스템, 벡터 DB, AI 에이전트의 입력과 출력이 되는 정형·비정형 데이터까지 다뤄야 한다고 설명한다.

그래서 AI용 데이터 작업은 두 축으로 나뉜다. 하나는 데이터를 실제로 옮기고 다듬는 파이프라인이고, 다른 하나는 그 데이터를 누가 책임지고, 품질을 어떻게 재며, 누가 볼 수 있는지 정하는 거버넌스다. 앞의 것이 길이라면 뒤의 것은 교통 규칙이다. IBM 글글은 거버넌스를 검증된 데이터가 안전한 파이프라인을 통해 믿을 수 있는 사용자에게 흘러가게 하는 '항공 관제탑'에 비유한다.

구성 요소: 수집→정제→저장→색인

수집 단계는 여러 원천에서 데이터를 가져오는 일이다. AWS 글글은 결제·CRM(고객 관리) 시스템, 재고 시스템, IoT 센서, 소셜 미디어, 사내 인사 시스템을 예로 든다. 가져온 원본은 먼저 스테이징 영역(landing zone)이라는 임시 저장 공간에 둔다. 가져오는 방식은 세 가지다. 원천 시스템이 바뀐 레코드를 알려 주는 '변경 알림', 일정 주기마다 바뀐 것만 가져오는 '증분 추출', 변경을 알 수 없을 때 전부 다시 가져오는 '전체 추출'이다. AWS는 전체 추출은 전송량이 크므로 작은 테이블에만 쓰기를 권한다.

정제(변환) 단계에서는 오류를 지우고, 빈 칸을 정해진 값으로 채우고, 중복 레코드를 없애고, 날짜·단위·문자 집합을 한 형식으로 맞춘다. AWS 글글의 예처럼 킬로그램과 파운드가 섞인 레시피 데이터를 한 단위로 통일하는 식이다. 여기에 업무 규칙으로 기존 값에서 새 값을 계산하는 '파생' 같은 고급 변환이 더해진다.

ETL(Extract·Transform·Load)은 이 변환을 저장소에 넣기 전에 끝내는 방식이다. AWS 글글은 ETL을 여러 원천의 데이터를 데이터 웨어하우스라는 중앙 저장소로 모으며, 업무 규칙으로 원본을 정리해 분석과 머신러닝에 쓸 수 있게 준비하는 과정으로 정의한다. ELT는 순서를 바꿔 원본을 먼저 저장소에 적재하고, 변환은 저장소 안에서 필요할 때 하는 방식이다. 원본을 그대로 남겨 두므로 나중에 다른 용도로 다시 가공하기 쉽지만, 저장소 안에 정리되지 않은 데이터가 쌓이지 않게 관리해야 한다.

AI용 파이프라인에는 색인 단계가 하나 더 붙는다. Anthropic 엔지니어링 글글에 따르면 RAG는 문서를 수백 토큰 이하의 조각으로 나누고(청킹), 임베딩 모델로 각 조각을 의미를 담은 벡터로 바꾼 뒤, 의미 유사도로 찾을 수 있는 벡터 DB에 저장한다. 질문이 들어오면 가장 가까운 조각을 찾아 프롬프트에 붙여 모델에 보낸다.

저장소와 조직: 웨어하우스·레이크·레이크하우스·데이터 메시

데이터 웨어하우스는 표와 열로 정리된 데이터를 모아 두는 중앙 저장소다글. Databricks 글글은 웨어하우스가 의사결정 지원과 BI(비즈니스 인텔리전스, 보고서·대시보드)에 오래 쓰여 왔지만, 비정형·반정형 데이터나 양이 많고 빠르게 바뀌는 데이터를 다루기에는 맞지 않거나 비싸다고 설명한다. 데이터 레이크는 정형·비정형 데이터를 미리 구조를 정하지 않고 있는 그대로 담는 저장소다글. 값싼 저장소에 원본을 쌓을 수 있어 데이터 과학과 머신러닝에 쓰이지만, Databricks 글글에 따르면 트랜잭션을 지원하지 않고 품질을 강제하지 않아 관리가 안 되면 '데이터 늪(data swamp)'이 된다.

그래서 많은 조직이 레이크와 웨어하우스를 둘 다 두는 2단 구조를 써 왔다. 운영 DB에서 레이크로 한 번 ETL하고, 중요한 데이터만 다시 웨어하우스로 ETL하는 식이다. Databricks 글글은 이 구조가 데이터 중복, 추가 인프라 비용, 보안 문제, 그리고 데이터가 최신이 아닌 상태(staleness)를 낳는다고 지적한다. 레이크하우스는 이 둘을 합치려는 설계로, 값싼 레이크 저장소 위에 메타데이터 층(예: Parquet 파일 위의 Delta Lake)을 얹어 ACID 트랜잭션, 스키마 강제, 과거 버전을 조회하는 '타임 트래블'을 제공한다. Databricks는 타임 트래블과 감사 기록이 머신러닝의 재현성에도 도움이 된다고 밝힌다. 다만 이것은 레이크하우스를 파는 회사의 설명이므로, 자기 조직의 규모와 기존 시스템에 맞는지는 따로 따져 봐야 한다.

데이터 메시는 저장 기술이 아니라 조직 원칙이다. Zhamak Dehghani의 글글은 기술 발전이 데이터 양과 연산 규모는 해결했지만, 원천과 사용자의 증가, 용도의 다양화, 변화 속도라는 다른 차원의 규모는 해결하지 못했다고 본다. 그 해법으로 네 원칙을 내세운다. 도메인 중심의 분산된 데이터 소유, 제품으로서의 데이터, 셀프서비스 데이터 플랫폼, 연합된 계산형 거버넌스다. 즉 데이터를 가장 잘 아는 업무 팀이 데이터를 '제품'처럼 책임지고, 공통 플랫폼과 정책은 중앙이 코드로 제공하는 구조다.

설계 원칙: 거버넌스와 데이터셋 문서화

거버넌스는 데이터를 수집·적재부터 분석, 안전한 폐기까지 생애 주기 전체에 걸쳐 원칙 있게 관리하는 방법이다글. IBM 글글은 이를 데이터 관리의 한 부분으로 보고, 품질·보안·가용성에 초점을 둔다고 정리한다. 출처들이 공통으로 말하는 구성 요소는 네 가지로 묶을 수 있다. 첫째 품질이다. Google Cloud 글글은 품질을 정확성·완전성·일관성·적시성·유효성·고유성의 여섯 차원으로 본다. 둘째 리니지(데이터가 어디서 와서 어떻게 바뀌었는지의 계보)와 메타데이터다. IBM 글글은 거버넌스 도구의 공통 기능으로 메타데이터 관리, 데이터 카탈로그, 리니지 추적, 업무 용어집을 든다.

셋째는 접근 권한이다. IBM 글글은 개인 식별 정보 같은 민감 데이터에 대해 거버넌스 팀이 정책을 정하고, 관리 팀이 역할 기반 접근 제어(RBAC)로 구현하는 분업을 설명한다. 또 사용자와 앱이 필요한 데이터에만 접근하도록 '데이터 범위'를 정하라고 한다. 사람이 아니라 AI 에이전트가 데이터를 읽는 일이 늘면서 권한 설계가 더 중요해졌다는 점도 IBM글과 Google Cloud글가 함께 짚는다. 넷째는 책임 구조다. IBM 글글은 운영위원회, 데이터 오너(도메인별 정확성·품질 책임), 데이터 스튜어드(일상 관리), 이해관계자로 역할을 나눈다.

데이터셋 문서화는 거버넌스를 사람이 읽을 수 있는 형태로 남기는 일이다. Datasheets for Datasets논문는 전자 부품마다 사양서가 붙듯 모든 데이터셋에 동기·구성·수집 과정·권장 용도 등을 적은 문서를 붙이자고 제안한다. 목적은 만드는 쪽은 생성·배포·유지 과정을 신중히 돌아보게 하고, 쓰는 쪽은 알맞은 데이터셋을 고르고 의도치 않은 오용을 피하게 하는 것이다. 이 논문은 질문 목록이 정답 양식이 아니며 분야와 조직에 맞게 달라져야 한다고 말하고, 문서 작성을 자동화하지 말라고 강조한다. 자동화는 편하지만 만드는 사람이 생각할 기회를 없애기 때문이다.

Data Cards논문는 이 생각을 대규모 산업 현장에 맞게 다듬었다. Data Card는 데이터셋 생애 주기 전반의 핵심 사실을 구조화해 요약한 문서로, 원천·수집과 라벨링 방법·의도된 용도처럼 데이터 자체에서는 추론할 수 없는 맥락을 담는다. 연구진은 여러 직군의 독자가 함께 보는 '경계 객체(boundary object)'로 설계했다고 설명한다.

단계별 적용 방법

처음 시작할 때는 다음 순서를 권한다. 첫째, 용도와 범위를 정한다. 이 데이터가 분석용인지, 모델 학습용인지, RAG 검색용인지에 따라 저장소와 변환 방식이 달라진다. Anthropic 글글은 지식 베이스가 20만 토큰(약 500쪽)보다 작으면 RAG 없이 전체를 프롬프트에 넣는 편이 간단하다고 밝혔으므로, RAG가 정말 필요한지부터 확인한다. 둘째, 원천 목록과 오너를 정한다. 어떤 시스템에서 무엇을 가져오는지, 각 데이터의 책임자가 누구인지 적는다. 데이터 메시의 도메인 소유 원칙글을 다 받아들이지 않더라도 '이 데이터는 누가 고치는가'는 처음부터 정해 두는 것이 좋다.

셋째, 수집과 정제를 만든다. 원천이 변경 알림을 주는지, 증분 추출이 가능한지 보고 방식을 고른다글. 중복 제거·형식 통일·빈 값 처리 규칙을 정하고, 품질 여섯 차원글 중 우리 용도에 중요한 항목을 측정 지표로 삼는다. 넷째, 저장소를 고른다. 정형 분석 위주면 웨어하우스, 원본 보관과 다양한 가공이 중요하면 레이크나 레이크하우스를 검토한다. 학습 데이터라면 어떤 버전으로 학습했는지 다시 찾을 수 있게 버전 관리 기능을 확인한다글.

다섯째, RAG라면 색인을 만든다. Anthropic 글글은 임베딩 검색과 정확한 단어 일치를 찾는 BM25를 함께 쓰고 결과를 합치는 방식을 소개한다. 임베딩은 의미는 잘 잡지만 'TS-999' 같은 오류 코드처럼 정확히 일치해야 하는 문자열을 놓칠 수 있기 때문이다. 또 조각이 문서 맥락을 잃는 문제를 줄이려고, 조각마다 문서 전체 속 위치를 설명하는 50~100토큰의 맥락 문장을 모델로 만들어 앞에 붙이는 Contextual Retrieval을 제안한다. Anthropic은 이 방법이 검색 실패를 49%, 리랭커와 함께 쓰면 67% 줄였다고 밝혔다. 여섯째, 권한과 문서화를 붙인다. 민감 데이터에 역할 기반 접근 제어를 걸고, 데이터셋마다 Datasheet나 Data Card를 쓴다. 마지막으로 감사와 개선을 정기 일정으로 만든다글.

점검 목록

수집 단계에서는 원천마다 오너가 정해져 있는지, 추출 방식(변경 알림·증분·전체)이 원천의 성격에 맞는지, 스테이징 영역의 원본을 문제 추적용으로 얼마나 남길지 정했는지 확인한다글.

정제와 저장 단계에서는 중복 제거와 형식 통일 규칙이 문서로 남아 있는지, 품질 지표(정확성·완전성·일관성·적시성·유효성·고유성, w4)를 실제로 재고 있는지, 같은 데이터를 여러 저장소에 복사해 서로 다른 값이 생기고 있지 않은지글, 과거 버전을 다시 조회할 수 있는지 본다.

색인과 RAG 단계에서는 의미 검색만 쓰고 있지 않은지, 오류 코드·제품 번호 같은 정확 일치 질문을 따로 시험했는지, 조각이 문서 맥락을 잃지 않았는지 확인한다글. 거버넌스 단계에서는 민감 데이터에 역할 기반 권한이 걸려 있는지, AI 에이전트가 사용자 권한을 넘어 데이터를 읽어 답변에 내보낼 수 없는지글글, 리니지와 카탈로그가 최신인지, 데이터셋마다 동기·구성·수집 과정·권장 용도를 적은 문서가 있는지논문 점검한다.

흔한 실수와 한계

가장 흔한 실수는 파이프라인을 계속 덧붙이기만 하는 것이다. Dehghani의 글글은 운영 데이터와 분석 데이터를 잇느라 계속 실패하는 ETL 작업과 점점 복잡해지는 파이프라인의 미로를 많은 조직에 익숙한 풍경으로 묘사한다. Databricks 글글도 여러 번의 ETL을 거치는 2단 구조가 꾸준한 유지 보수를 요구하고 데이터를 낡게 만든다고 지적한다. 단계를 늘리기 전에 같은 데이터를 두 번 옮기고 있지 않은지 먼저 본다.

두 번째 실수는 레이크를 '일단 다 넣어 두는 곳'으로 쓰는 것이다. 품질을 강제하지 않고 권한이 제각각인 레이크는 데이터 늪이 된다글. ELT처럼 원본을 먼저 적재하는 방식일수록 메타데이터와 권한 관리가 함께 가야 한다.

세 번째는 문서화를 형식 채우기로 만드는 것이다. Datasheets 연구진논문은 약 2년 동안 질문을 다듬으며 제품 팀이 예·아니오로만 답하지 않도록 질문을 고쳤고, 법·윤리 질문은 따로 모아 두기보다 생애 주기 각 단계에 넣었을 때 더 잘 답한다는 것을 발견했다. Data Cards논문 사례 연구에서도 작성 과정에서 '알 수 없음' 값이 많은 이유를 따져 보게 되는 등 데이터 설계를 개선할 기회가 드러났다. 문서는 생각을 끌어내는 도구일 때 가치가 있다.

한계도 있다. 거버넌스 틀은 조직마다 달라 정답이 없고, 오래된 틀은 빠르게 낡는다글. 웹 출처 다수는 자사 플랫폼을 소개하는 회사의 글이라, 기능 설명은 참고하되 제품 선택은 자기 환경에서 따로 검증해야 한다. 또 Contextual Retrieval의 수치는 Anthropic이 자체 실험에서 보고한 값이다글.

더 공부하려면

개념을 처음 잡는다면 AWS의 ETL 설명글으로 수집·변환·적재의 기본 용어를 익히고, Databricks의 레이크하우스 글글로 웨어하우스·레이크·레이크하우스가 어떤 문제를 풀려고 나왔는지 흐름을 본다. 조직 구조가 고민이라면 Dehghani의 데이터 메시 원칙 글글을 읽는다. 도구 처방보다 공통 언어를 세우는 글이라 기술 선택 전에 읽기 좋다.

거버넌스는 IBM 글글이 역할·정책·감사·도구를 가장 체계적으로 나누고, Google Cloud 글글은 AI 시대의 위험과 품질 여섯 차원을 짧게 정리한다. 데이터셋 문서화는 Datasheets for Datasets논문의 질문 목록을 먼저 보고, 대규모 조직에서 실제로 적용한 경험이 궁금하면 Data Cards논문를 이어 읽는다. RAG 문서 파이프라인을 직접 만든다면 Anthropic의 Contextual Retrieval 글글이 청킹·임베딩·BM25·리랭킹을 한 흐름으로 보여 준다.