현대 애널리틱스 팀을 위한 준정형 데이터 설명

동료가 CSV 파일을 보내왔는데, 열이 지난주 파일과 맞지 않습니다. 어떤 행에는 프로모션 필드가 있고, 다른 행에는 기기 값이 있으며, 세 번째 행은 세부 정보가 아예 빠진 것 같습니다. 레코드 자체는 쓸모없지 않지만, 고정된 테이블로는 이를 깔끔하게 표현할 수 없습니다.

이는 API 응답, 애플리케이션 로그, 이벤트 스트림을 다루는 팀에게 익숙한 문제입니다. 준정형 데이터는 내용을 해석하는 데 도움이 되는 레이블을 가지고 있지만, 모든 레코드가 동일한 필드를 가질 것을 요구하지 않습니다. 이러한 유연성 덕분에 서로 다른 소스를 통합하기가 더 쉬워지는 한편, 일관된 리포트나 예측이 필요할 때는 새로운 작업이 생기기도 합니다.

쉽게 말해, 관계형 테이블은 정해진 열 집합을 가지고 있고, 준정형 레코드는 자체 구성에 대한 단서를 담고 있으며, 이미지나 자유 형식 텍스트 같은 비정형 문서는 내장된 필드 구조가 전혀 없을 수도 있습니다. 어떤 종류의 데이터를 다루고 있는지 아는 것은 이를 어떻게 수집, 검증, 저장, 보호할지 결정하는 데 도움이 됩니다. 실질적인 과제는 단순히 JSON 페이로드를 인식하는 데 있지 않습니다. 업스트림 데이터가 변경된 후에도 애널리틱스의 신뢰성을 유지하는 데 있습니다.

가만히 있지 않으려는 데이터 형식

소매 이벤트 두 건을 받는다고 가정해 봅시다. 하나는 상품 조회를 기록하고, 다른 하나는 구매를 기록합니다. 첫 번째 레코드에는 상품 ID와 채널이 들어 있습니다. 두 번째 레코드에는 가격과 프로모션 코드도 포함되어 있습니다. JSON으로 표현하면 다음과 같을 것입니다:

{"event": "view", "product_id": "P-42", "channel": "web"}
{"event": "purchase", "product_id": "P-42", "amount": 29.99, "promotion": "spring"}

각 레코드는 자체 필드 이름을 가지고 있습니다. 이에 비해 전통적인 테이블은 먼저 열을 정의한 다음, 각 레코드를 그 공통 레이아웃에 맞춰 저장합니다. JSON은 유용한 레이블을 유지하면서도 레코드마다 다를 수 있게 허용합니다. 이러한 기계가 읽을 수 있는 구조와 가변적인 필드의 조합이 준정형 데이터의 핵심 개념입니다. IBM의 데이터 구조 개요는 정형 정보와 비정형 정보 사이의 이러한 중간 지점을 설명합니다.

행마다 내용이 다르거나 필드가 셀 안에 압축되어 있을 경우, 지저분한 CSV 역시 준정형 데이터처럼 동작할 수 있습니다. 다만 CSV 자체는 중첩된 문서 형식이 아니라 구분자 기반의 텍스트 형식입니다. XML은 태그를 사용하는 반면, JSON은 키-값 쌍과 중첩된 객체 또는 배열을 사용합니다. 두 경우 모두 레이블이나 다른 마커가 콘텐츠를 읽는 방법에 대한 정보를 전달합니다.

비정형 콘텐츠와의 구분은 유용합니다. 태그가 지정된 이벤트는 소프트웨어가 카탈로그화, 색인화, 분석할 수 있는 이름 붙은 필드를 제공합니다. 자유 형식의 이미지나 문서는 시스템이 그 내용을 안정적으로 식별하기 전에 별도의 처리가 필요할 수 있습니다. 준정형 데이터는 막연한 의미에서 "절반만 정리된" 상태가 아닙니다. 모든 레코드가 하나의 엄격한 설계에 맞아야 한다고 요구하지 않으면서도, 소프트웨어가 해석할 수 있을 만큼 충분한 메타데이터를 담고 있습니다.

이러한 유연성은 데이터베이스 연구자들이 사전 정의된 스키마를 공유하지 않는 웹 정보를 어떻게 조회하고 결합할지 탐구하면서 점점 더 유용해졌습니다. 스키마 온 리드(schema-on-read) 방식은 모든 소스를 사전에 재설계하도록 요구하는 대신, 수집이나 조회 시점에 시스템이 필드를 해석할 수 있도록 합니다.

JSON과 XML이 유연한 데이터의 근간이 된 과정

웹 서비스가 분석 파이프라인에 구매 이벤트를 전송합니다. 페이로드에는 레이블이 붙은 값이 포함되어 있어, 수신 시스템은 테이블 내 위치에 의존하지 않고도 필드를 파싱할 수 있습니다. 이 기본적인 설계 방식 덕분에 JSON과 XML은 웹 서비스와 시스템 간 데이터 교환에서 친숙한 구성 요소가 되었습니다.

XML은 월드 와이드 웹 컨소시엄이 1998년 2월 10일 XML 1.0을 권고안으로 발표하면서 공식적인 이정표를 맞이했습니다. 이 표준은 웹 전반에서 문서 형식을 정의하고, 검증하고, 공유하는 방법을 설명했습니다. XML은 계층적 요소와 속성을 통해 정보를 표현하므로, 문서는 값뿐만 아니라 관계도 나타낼 수 있습니다. 이 형식을 파싱하는 실용적인 입문 지식을 원하는 독자를 위해 ELECTE가 XML을 읽는 방법을 설명합니다.

JSON은 키-값 쌍으로 이루어진 객체와 컬렉션을 나타내는 배열을 사용하는 더 가벼운 방식을 택했습니다. 표준화된 인터넷 명세인 RFC 4627은 2006년에 발표되었습니다. JSON은 웹 애플리케이션과 API에서 흔히 사용되었는데, 간결한 페이로드와 단순한 파싱 방식이 시스템 간 정보 교환에 적합했기 때문입니다. XML은 계층적 문서와 기존에 확립된 기업 간 데이터 교환에서 여전히 유용하게 쓰였습니다.

두 형식 모두 모든 레코드가 동일한 필드를 포함할 것을 요구하지 않습니다. 어떤 API 응답에는 고객이 선호하는 언어가 포함될 수 있지만, 다른 응답에는 그것이 빠져 있을 수 있습니다. 애플리케이션이 발전함에 따라 이벤트에 새로운 속성이 추가될 수 있으며, 이때 모든 생산 측이 한꺼번에 변경될 필요는 없습니다. 이러한 적응성 덕분에 두 형식 모두 API, 애플리케이션 로그, 이벤트 스트림, 그리고 시스템 간 통합에 유용합니다.

이러한 장점의 이면은 분석가가 데이터를 조회하는 순간 바로 드러납니다. 중첩된 경로, 선택적 필드, 변화하는 레이블, 서로 다른 유형으로 도착하는 값들을 모두 고려해야 합니다. JSON과 XML은 데이터를 일관되게 만들어야 할 필요성을 없애주지 않습니다. 이들은 생산 측이 더 자유롭게 데이터를 발전시킬 수 있게 해주므로, 분석 팀은 다운스트림에서 명확한 검증 및 변환 방식을 갖춰야 합니다.

반정형 데이터 분석을 어렵게 만드는 네 가지 과제

들어오는 모든 레코드가 유효한 JSON이라 하더라도 소매 대시보드는 실패할 수 있습니다. 문제는 흔히 레코드들이 단순한 파서는 받아들이지만 보고서는 예상하지 못한 방식으로 서로 다르다는 데 있습니다. 특히 주의해야 할 네 가지 문제가 있습니다.

• 필드명 변경: 한 결제 이벤트는 값을 amount라고 부르고, 다른 이벤트는 이를 total이라고 부릅니다. 한 이름만 기대하는 쿼리는 다른 이름으로 된 레코드를 놓쳐 불완전한 결과를 낳을 수 있습니다.
• 타입 변동: 어떤 필드가 한 이벤트에서는 숫자로, 다른 이벤트에서는 문자열로 들어옵니다. 집계가 실패할 수도 있고, 파이프라인이 원인을 명확히 드러내지 않은 채 예상치 못한 값을 null로 변환할 수도 있습니다.
• 선택적 필드: 프로모션이나 디바이스 속성이 없는 이벤트가 반드시 잘못된 형식인 것은 아닙니다. 하지만 다운스트림의 모든 보고서는 모든 레코드에 해당 값이 포함되어 있다고 가정하는 대신, 누락된 값을 의도적으로 처리해야 합니다.
• 배열이 더하는 복잡성: 구매 건에는 제품 배열이 포함될 수 있습니다. 제품 단위로 보고하려면 팀은 이 배열을 펼쳐야 하거나, BI 시스템이 쉽게 처리하지 못하는 쿼리 함수를 사용해야 할 수 있습니다.

이는 반정형 데이터를 피해야 할 이유가 아닙니다. 오히려 엔지니어링 노력이 어디에서 중요한지를 보여줍니다. 보고서에서 매출 항목이 누락되었다면, 분석가는 소스가 해당 데이터 전송을 중단했는지, 필드명을 변경했는지, 타입을 바꿨는지, 아니면 새로운 위치에 중첩시켰는지 파악해야 합니다. 이러한 가시성이 없으면 대시보드는 사업 활동의 일부를 제외한 채로도 그럴듯해 보일 수 있습니다.

같은 우려는 금융 이벤트 스트림에도 적용됩니다. 하나의 거래 경로만 읽고 대체 경로를 놓치는 리스크 보고서는 활동에 대한 불완전한 시각을 제공할 수 있습니다. 올바른 대응은 페이로드를 프로파일링하고, 중요한 필드에 대한 신뢰할 수 있는 매핑을 정의하며, 결과가 비즈니스 사용자에게 도달하기 전에 타당한지 확인하는 것입니다.

실용적인 원칙: 파싱 가능한 페이로드를 입력값으로 취급하되, 그 필드가 분석할 만큼 일관성이 있다는 증거로 여기지 마십시오.

오늘 바로 적용할 수 있는 파싱 및 전처리 기법

실용적인 파이프라인이라고 해서 모든 소스를 도착하는 즉시 같은 형태로 강제 변환할 필요는 없습니다. 다만 각 변환 과정을 가시화하고 테스트 가능하게 만들어야 합니다.

수집 단계부터 시작하십시오. Kafka와 같은 스트리밍 시스템이나 API용 관리형 커넥터는 이벤트를 포착하여 데이터 레이크나 웨어하우스의 랜딩 영역으로 전달할 수 있습니다. 적절한 경우 원본 페이로드를 보존하여, 엔지니어가 변환된 테이블로부터 재구성을 시도하는 대신 예상치 못한 값을 직접 조사할 수 있도록 하십시오.

그 다음, 도착하는 데이터에 대한 작업용 모델을 구축하십시오. Apache Spark와 같은 처리 엔진의 스키마 추론은 경로와 예상 타입을 식별하는 데 도움이 될 수 있습니다. JSON Schema 검증기는 중요한 필드가 합의된 규칙을 충족하는지 확인할 수 있습니다. 추론은 유용한 발견 도구일 뿐, 비즈니스가 어떤 필드에 의존하는지를 결정하는 것을 대체할 수는 없습니다.

예를 들어, 리테일 파이프라인은 amount와 total을 공유 매출 필드로 매핑하면서, 허용 가능한 숫자 문자열을 명시적으로 변환할 수 있습니다. 예상치 못한 값은 통보 없이 강제 변환되는 대신 플래그 처리되거나 격리되어야 합니다. 경량 처리 흐름은 다음과 같을 수 있습니다:

수집 → 파싱 → 검증 → 정규화 → 테스트 → 게시

마지막 결정은 레코드를 중첩된 상태로 유지할지, 아니면 선택된 경로를 컬럼으로 평탄화할지입니다. 팀이 유연한 탐색을 필요로 하거나 소스가 여전히 변화하고 있다면 중첩 구조를 유지하십시오. 대시보드, 반복되는 예측, 또는 다른 워크로드가 일관된 접근에 의존한다면 자주 사용되는 필드를 추출하십시오. 모든 것을 평탄화하면 웨어하우스 유지관리가 어려워질 수 있고, 모든 필드를 중첩 상태로 두면 일상적인 보고 작업이 번거로워질 수 있습니다.

마케팅 시스템 전반에 걸쳐 캠페인 데이터를 계획하는 팀을 위해, doornoc의 데이터 관리 가이드는 플랫폼 간에 흐르는 정보를 조직화하는 데 유용한 맥락을 제공합니다. 소스가 무엇이든, 게시하기 전에 품질 검사를 추가하십시오: 중요한 필드를 검증하고, 어떤 변환이 실행되었는지 기록하며, 보고서를 책임지는 담당자에게 예외 사항을 가시화하십시오.

저장 형식 선택이 쿼리 속도를 바꾸는 방식

파이프라인이 페이로드를 파싱하고 나면, 저장 방식이 쿼리 엔진이 반복해야 하는 작업량을 좌우합니다. 일반 텍스트 문자열로 저장된 JSON 문서는 필드를 가져오기 위해 파싱되어야 합니다. 타입이 지정된 반정형 표현은 탐색 가능한 값을 보존하여 관련 쿼리에 대한 반복적인 텍스트 파싱을 피할 수 있습니다.

TPC-DS에서 파생된 반정형 데이터를 사용한 Databricks 벤치마크에 따르면 Apache Parquet의 Variant 표현 방식은 일반 문자열 저장 방식보다 최대 8배 빠르게 JSON을 읽은 것으로 나타났습니다. 동일한 벤치마크에서 데이터를 쿼리 가능한 컬럼으로 분해(shredding)하면 쓰기 속도는 20%~50% 느려졌지만 읽기 속도는 약 30% 빨라졌습니다. 이러한 결과는 워크로드에 따라 달라지며, 모든 웨어하우스에서 동일한 효과를 보장하지는 않습니다. Parquet의 Variant에 대한 Databricks의 설명에서 이 벤치마크와 아키텍처적 트레이드오프를 다루고 있습니다.

수집량이 많은 피드라면 변환을 최소화하는 것이 합리적인 출발점이 될 수 있습니다. 동일한 필드를 반복적으로 쿼리하는 대시보드나 이상 탐지의 경우, 선별적 추출이 읽기 시점의 작업을 줄여줄 수 있습니다. 팀이 실행하는 쿼리를 벤치마크하되, 중첩 배열의 동작 방식과 필터까지 포함해야 합니다. 데이터 레이크와 데이터 웨어하우스 중 선택하는 방법에 대한 이 가이드는 보다 폭넓은 저장소 결정을 구조화하는 데 도움이 됩니다.

스키마온리드가 여전히 스키마 전략을 필요로 하는 이유

스키마온리드는 소스에 필드가 추가될 때마다 테이블을 재설계해야 하는 필요성을 줄여줄 수 있습니다. 하지만 이는 분석가, 리포트, 모델이 데이터에 대한 기대치 없이 작동할 수 있다는 의미는 아닙니다. 그러한 기대치는 여전히 존재합니다. 다만 그 위치가 다운스트림으로 옮겨갔을 뿐입니다.

이러한 구분은 API가 예고 없이 변경될 때 중요해집니다. 새로운 선택적 속성은 무해할 수 있지만, 재고 예측에 사용되는 필드의 이름이 변경되는 것은 그렇지 않을 수 있습니다. 팀이 두 가지 변경을 동일하게 취급한다면, 유용한 추가 사항을 차단하거나 실제 장애를 놓칠 수 있습니다.

신뢰할 수 있는 드리프트 전략은 다음 네 가지 습관에서 시작할 수 있습니다:

• 경로와 타입 프로파일링: 어떤 필드가 나타나는지, 그 값이 어떻게 표현되는지 추적합니다.
• 핵심 계약 버전 관리: 비즈니스 지표를 좌우하는 필드의 예상 이름과 타입을 기록합니다.
• 추가적 변경과 파괴적 변경 구분: 새 필드는 안전하게 수용할 수 있는 반면, 이름이 바뀌거나 위치가 옮겨진 필드는 신중한 매핑이 필요합니다.
• 이상 징후 경고: 데이터가 대시보드나 모델에 도달하기 전에 필드 수준의 널 비율과 타입 변경을 모니터링합니다.

반정형 데이터에 관한 연구를 검토한 결과, 업데이트, 추가, 스트림, 그리고 변화하는 스키마와 관련된 어려움이 계속되고 있음을 보여줍니다. 일부 접근 방식은 현재 구조를 추론하기 위해 데이터를 재처리해야 합니다. 실무적인 교훈은 분명합니다: 자동 탐지는 변화를 드러내는 데 도움이 될 수 있지만, 그 변화가 비즈니스에 어떤 의미를 갖는지는 결정할 수 없습니다.

스키마온리드는 스키마를 없애지 않습니다. 오히려 데이터를 읽는 리포트와 모델 전반에 걸쳐 팀이 스키마를 관리할 책임을 지도록 만듭니다.

소규모 분석팀에게는 조용한 타입 변환보다 명확한 알림이 더 가치 있는 경우가 많습니다. 알림은 어떤 필드가 변경되었는지, 그리고 어떤 다운스트림 출력이 주의가 필요한지를 담당자에게 알려줍니다.

중첩된 레코드 내부의 개인정보 보호와 보안

데이터베이스 권한은 테이블을 보호할 수 있지만, 중첩된 객체, 배열, 또는 새로 추가된 필드 안에 숨겨진 민감한 값을 놓칠 수 있습니다. API 페이로드에는 고객 객체 안에 이메일이 포함되어 있을 수 있고, 자유 텍스트 필드에는 소스가 모든 분석가에게 노출할 의도가 전혀 없었던 정보가 담겨 있을 수 있습니다.

Cloud Security Alliance의 설문조사에 따르면 반정형 데이터는 조사 대상 기업 데이터 중 약 21%를 차지하는 것으로 나타났습니다. 같은 설문조사에서는 응답자의 56%가 데이터 위치에 대해 부분적인 가시성만 가지고 있다고 보고했으며, 보안, 거버넌스, 개인정보 보호, 컴플라이언스가 주요 우려 사항으로 꼽혔습니다. Cloud Security Alliance의 연구 발표 자료에서 설문조사의 배경을 확인할 수 있습니다.

팀은 특정 필드 이름만 찾는 대신, 중첩된 콘텐츠를 재귀적으로 스캔하고 패턴 검사와 컨텍스트를 결합함으로써 탐색 능력을 개선할 수 있습니다. 또한 민감한 필드에 대한 계보(lineage)를 추적하고, 데이터 사용 방식에 따라 행 및 필드 수준의 접근 제어를 적용해야 합니다. 규칙은 위험과 비즈니스 목적을 모두 고려해야 합니다. 과도한 편집(over-redaction)은 운영 분석을 사용할 수 없게 만들 수 있고, 누락된 값은 노출 위험을 초래할 수 있습니다.

민감한 정보가 흐르는 경로를 문서화하는 방법에 대한 실용적인 입문서로는 컴플라이언스를 위한 데이터 매핑이 팀이 해당 작업을 체계화하는 데 도움이 될 수 있습니다. 이를 분석 팀을 위한 보안 제어와 함께 활용하십시오. 개인정보 보호 조치는 일회성 데이터베이스 설정으로 취급하지 말고, 스키마가 변경될 때마다 다시 점검해야 합니다.

반정형 소스를 AI 분석 플랫폼과 통합하기

유용한 엔드투엔드 워크플로는 비즈니스 질문에서 시작하여 데이터를 소스까지 거슬러 추적하는 방식입니다. 소매업체가 재고 예측을 개선하고자 한다면, 관련 입력 데이터에는 재고 기록, 구매 이벤트, 프로모션 세부 정보, 그리고 커머스 플랫폼의 API 피드가 포함될 수 있습니다. 팀은 이러한 소스를 어떻게 파싱하는지뿐만 아니라, 예측이 어떤 필드에 의존하는지, 그리고 변경 사항을 어떻게 포착할 것인지도 이해해야 합니다.

AI 기반 분석 플랫폼은 팀이 데이터 소스를 연결하고, 수신되는 정보를 전처리하며, 결과를 보고서와 예측에 반영하는 데 도움을 줄 수 있습니다. 구체적인 기능은 플랫폼과 해당 커넥터에 따라 다르므로, 자체 API, XML 피드, 이벤트 로그, 변경되는 필드를 플랫폼이 어떻게 처리하는지 신뢰하기 전에 반드시 확인하십시오. 플랫폼이 유형 변경, 누락된 값, 예상치 못한 경로를 어떻게 드러내는지, 그리고 분석가가 결과 이면의 변환 과정을 검토할 수 있는지 질문하십시오.

데이터 거버넌스는 페이로드 형식을 넘어서는 영역까지 확장됩니다. 기업이 외부 또는 라이선스 데이터를 사용할 때는 허용된 사용 범위, 출처, 처리 요구 사항을 이해해야 합니다. 이러한 문제를 검토하는 팀은 전반적인 데이터 관리 검토의 일환으로 기업용 데이터 라이선스 옵션을 살펴볼 수 있습니다.

비즈니스 사용자에게 새로운 소스를 공개하기 전에 다음 체크리스트를 검토하십시오:

• 수집: 페이로드를 안정적으로 캡처하고, 문제를 조사하는 데 필요한 충분한 맥락을 보존하세요.
• 스키마 전략: 핵심 필드를 정의하고 필드 추가, 이름 변경, 타입 변경을 어떻게 처리할지 결정하세요.
• 저장: 쿼리 방식과 수집 패턴에 적합한 표현 방식을 선택하세요.
• 거버넌스: 민감한 값을 발견하고 데이터를 따라다니는 통제를 적용하세요.
• 비즈니스 연계: 분석 결과를 재고 가용성이나 예측 정확도 같은 명확한 KPI와 연결하고, 예외 사항을 눈에 띄게 만드세요.

잘 관리된 파이프라인은 유연한 데이터를 더 쉽게 활용할 수 있게 해주며, 그 과정에서 변동성에 대한 관리가 필요 없다고 가장하지 않습니다. 결과물은 단순히 파싱된 레코드 이상이어야 합니다. 팀이 해석하고, 거버넌스를 적용하고, 의사결정에 활용할 수 있는 정보여야 합니다.

중소기업을 위한 AI 기반 데이터 분석 플랫폼인 ELECTE는 비즈니스 데이터를 연결하고 팀이 이를 리포트, 예측, 실행 가능한 인사이트로 전환하도록 돕습니다. ELECTE가 여러분의 팀이 반정형 소스를 더 명확한 분석 워크플로우로 통합하는 데 어떻게 도움이 될 수 있는지 알아보세요.