메타데이터에서 지식 발견까지: 왜 챗봇으로 시작하지 않는가

오늘날 많은 AI 제품들이 동일한 아이디어로 시작합니다:

문서 업로드.
질문하기.
답변 받기.

다시 말해:

당신의 문서와 채팅하기 (Chat with your documents).

이는 강력한 패턴입니다.

하지만 엔터프라이즈 데이터 엔지니어링 (Enterprise data engineering) 측면에서, 저는 모든 AI 제품이 챗봇으로 시작할 필요는 없다고 생각합니다.

사실, 챗봇으로 시작하는 것은 첫 버전을 불필요하게 복잡하게 만들 수 있습니다.

개방형 챗봇을 만드는 순간, 우리는 다음과 같은 것들도 고려해야 합니다:

• RAG (Retrieval-Augmented Generation)
• 권한 (Permissions)
• 인용 (Citations)
• 환각 (Hallucinations)
• 평가 (Evaluation)
• 가드레일 (Guardrails)
• 범위 제어 (Scope control)
• 사용자 의도 (User intent)
• 지식 최신성 (Knowledge freshness)
• 답변 추적 가능성 (Answer traceability)

이 모든 것들은 중요합니다.

하지만 이것들이 반드시 가장 먼저 해결해야 할 문제들은 아닐 수 있습니다.

Data Engineering Copilot의 첫 버전을 위해, 저는 다르게 생각하고 있습니다.

현재의 MVP (Minimum Viable Product)는 챗봇이 아닙니다.

그것은 워크플로우 애플리케이션 (Workflow application)입니다.

흐름은 단순합니다:

STTM 업로드
    ↓
SQL 생성
...

단순해 보일 수 있습니다.

하지만 저는 그 단순함이 강점이라고 생각합니다.

이 애플리케이션은 가능한 모든 질문에 답하려고 시도하지 않습니다.

대신 하나의 명확한 데이터 엔지니어링 워크플로우에 집중합니다:

구조화된 메타데이터 (Structured metadata)를 입력으로 받아 유용한 엔지니어링 산출물 (Engineering artifacts)을 출력으로 생성하는 것.

이 모델에서 UI 자체는 일종의 범위 제어 (Scope control) 수단이 됩니다.

사용자는 시스템에 Python 게임을 작성해달라고 요청할 수 없습니다.

사용자는 제품의 경계 밖의 무작위 질문을 할 수 없습니다.

사용자는 시스템을 관련 없는 작업으로 강제할 수 없습니다.

사용자는 오직 워크플로우가 허용하는 작업만 수행할 수 있습니다:

메타데이터 업로드.
검증.
산출물 생성.
결과물 다운로드.

초기 AI 제품으로서 이는 강력한 디자인 선택입니다.

리스크를 줄여줍니다.

모호함을 줄여줍니다.

평가를 더 쉽게 만듭니다.

또한 제품을 설명하기 더 쉽게 만듭니다.

이렇게 말하는 대신:

“이것은 데이터 엔지니어링을 위한 챗봇입니다.”

제품은 이렇게 말할 수 있습니다:

“이것은 데이터 엔지니어링 팀을 위한 메타데이터 기반 산출물 생성 엔진입니다.”

이 차이가 중요합니다.

왜냐하면 데이터 엔지니어링 (Data Engineering)에서 많은 작업은 개방형 대화 (Open-ended conversation)가 아니기 때문입니다.

그것들은 반복 가능한 워크플로우 (Repeatable workflows)입니다.

예를 들어:

• STTM으로부터 Snowflake SQL 생성
• PySpark 변환 로직 (Transformation logic) 생성
• DQ (Data Quality) 규칙 생성
• 대조 확인 (Reconciliation checks) 생성
• 데이터 사전 (Data dictionaries) 생성
• 기술 사양서 (Technical specifications) 생성
• 매핑 (Mappings) 검증
• 누락된 메타데이터 식별

이러한 작업들이 항상 챗봇 (Chatbot)을 필요로 하는 것은 아닙니다.

이 작업들은 구조화된 입력 (Structured input), 비즈니스 규칙 (Business rules), 검증 (Validation), 그리고 제어된 생성 (Controlled generation)을 필요로 합니다.

그렇기에 저는 엔터프라이즈 AI 코파일럿 (Enterprise AI copilot)의 첫 번째 버전이 지나치게 복잡할 필요는 없다고 믿습니다.

다음과 같이 시작할 수 있습니다:

메타데이터 입력 (Metadata In)
    ↓
산출물 출력 (Artifacts Out)

일단 그 토대가 작동하기 시작하면, 제품은 진화할 수 있습니다.

이후 버전에서는 다음과 같은 기능을 추가할 수 있습니다:

• STTM에 대해 질문하기
• 데이터 리니지 (Data lineage)에 대해 질문하기
• DQ 규칙에 대해 질문하기
• 비즈니스 정의 (Business definitions)에 대해 질문하기
• 다운스트림 영향 (Downstream impact)에 대해 질문하기

그 시점이 되면 RAG (Retrieval-Augmented Generation), 인용 (Citations), 권한 (Permissions), 그리고 지식 발견 (Knowledge discovery)이 더 중요해집니다.

하지만 제어된 워크플로우 (Controlled workflow)로 시작하는 것은 제품이 먼저 신뢰를 구축할 수 있게 해줍니다.

이것이 바로 가드레일 (Guardrails)이 실용적으로 적용되는 지점이기도 합니다.

이 MVP (Minimum Viable Product)에서 가드레일은 추상적인 AI 안전 개념이 아닙니다.

그것들은 단순한 엔지니어링 체크 (Engineering checks)입니다:

• STTM 파일에 필수 컬럼이 있는가?
• 소스 (Source) 및 타겟 (Target) 컬럼이 채워져 있는가?
• 변환 규칙 (Transformation rules)이 존재하는가?
• 데이터 타입 (Data types)이 유효한가?
• 타겟 테이블 (Target tables)이 정의되었는가?
• 생성된 SQL이 컴파일 가능한가?
• 매핑된 필드에 대해 DQ 규칙이 생성되었는가?

단순한 검증 규칙 (Validation rule)은 다음과 같이 보일 수 있습니다:

required_columns = [
    "Source_Table",
    "Source_Column",
...

이것은 화려하지 않습니다.

하지만 이것은 현실적입니다.

그리고 엔터프라이즈 시스템에서는 현실적인 것이 대개 승리합니다.

많은 AI 데모들은 개방형 대화를 허용하기 때문에 인상적으로 보입니다.

하지만 엔터프라이즈 제품은 제어 가능하고, 테스트 가능하며, 추적 가능하고, 유용할 때 살아남습니다.

그렇기 때문에 저는 Data Engineering Copilot (데이터 엔지니어링 코파일럿)의 첫 번째 단계가 다음과 같아서는 안 된다고 믿습니다:

모든 것과 채팅하기 (Chat with everything).

대신 다음과 같아야 합니다:

메타데이터 이해 (Understand metadata)
신뢰할 수 있는 산출물 생성 (Generate trusted artifacts)
반복 가능한 가치 창출 (Create repeatable value)

챗봇은 나중에 나와도 됩니다.

지식 발견 (Knowledge discovery) 레이어는 나중에 나와도 됩니다.

에이전트 워크플로 (Agentic workflow)는 나중에 나와도 됩니다.

기초는 단순해야 합니다:

STTM
    ↓
표준 메타데이터 (Canonical Metadata)
...

이것이 제가 탐구하고 있는 방향입니다.

챗봇이 나빠서가 아닙니다.

데이터 엔지니어링 팀에게는 종종 더 구체적인 무언가가 필요하기 때문입니다.

그들은 반복적인 작업을 줄여주는 도구가 필요합니다.

그들은 메타데이터를 이해하는 시스템이 필요합니다.

그들은 검토, 검증 및 개선이 가능한 결과물이 필요합니다.

그리고 궁극적으로, 그들은 문서 검색 (Document retrieval)을 넘어 증거 기반의 지식 발견 (Evidence-based knowledge discovery)으로 나아갈 수 있는 AI가 필요합니다.

그 여정은 작은 워크플로에서 시작됩니다.

메타데이터 업로드.

산출물 생성.

결과물 검증.

신뢰 구축.

그다음 확장하십시오.