Skip to main content
이 문서는 데이터 기초 섹션의 일부입니다.

왜 데이터 유형을 구분해야 하나요?

데이터 파이프라인을 설계할 때, 가장 먼저 “우리가 다루는 데이터는 어떤 형태인가?”를 파악해야 합니다. 데이터의 유형에 따라 저장 방식, 처리 도구, 분석 방법이 모두 달라지기 때문입니다. 데이터는 크게 정형(Structured), 반정형(Semi-Structured), 비정형(Unstructured) 세 가지로 나뉩니다. 각각의 특징을 이해하면, 적합한 저장소와 처리 방법을 선택하는 데 큰 도움이 됩니다.

정형 데이터 (Structured Data)

개념

💡 정형 데이터(Structured Data) 란 행(Row)과 열(Column)로 구성된 테이블 형태의 데이터를 말합니다. 각 열은 이름과 데이터 타입(숫자, 문자열, 날짜 등)이 명확하게 정의되어 있습니다.
가장 익숙한 형태의 데이터입니다. 엑셀 스프레드시트 를 떠올리시면 됩니다.

예시

특징

💡 RDBMS(Relational Database Management System, 관계형 데이터베이스)란? 데이터를 테이블(표) 형태로 저장하고, 테이블 간의 관계(Relationship)를 통해 데이터를 연결하는 데이터베이스 시스템입니다. MySQL, PostgreSQL, Oracle, SQL Server 등이 대표적입니다. “관계형”이라는 이름은 테이블 간의 관계를 정의할 수 있다는 것에서 유래합니다.

반정형 데이터 (Semi-Structured Data)

개념

💡 반정형 데이터(Semi-Structured Data) 란 고정된 테이블 구조는 아니지만, 태그(Tag)나 키-값(Key-Value) 쌍 으로 일정한 구조를 가지고 있는 데이터를 말합니다.
비유하자면, 명함 과 같습니다. 명함마다 포함된 정보의 종류가 조금씩 다를 수 있지만(어떤 명함에는 팩스 번호가 있고, 어떤 명함에는 없음), “이름”, “전화번호”, “이메일” 등 대체로 비슷한 구조를 가지고 있습니다.

예시: JSON 형태의 사용자 활동 로그

위 예시에서 보시는 것처럼, JSON 데이터는 중첩(Nested) 구조를 가질 수 있으며, 레코드마다 포함된 필드가 다를 수 있습니다 (예: coupon_code가 없는 레코드도 존재 가능).

특징

💡 중첩(Nested) 구조란? 위 JSON 예시에서 user 안에 id, name, tier가 들어있는 것처럼, 데이터 안에 또 다른 데이터 구조가 포함된 형태입니다. 정형 데이터의 평평한(Flat) 테이블과 달리, 트리(Tree) 형태로 데이터가 계층적으로 구성됩니다.

비정형 데이터 (Unstructured Data)

개념

💡 비정형 데이터(Unstructured Data) 란 미리 정의된 구조가 없는 데이터를 말합니다. 사람이 보면 이해할 수 있지만, 컴퓨터가 직접 분석하기 위해서는 별도의 처리(자연어 처리, 이미지 인식 등)가 필요합니다.
비유하자면 메모장에 자유롭게 적은 노트 와 같습니다. 내용은 의미가 있지만, 정해진 양식이 없어서 자동으로 분류하거나 집계하기가 어렵습니다.

예시

특징


세 가지 유형 비교


Databricks에서 각 데이터 유형 다루기

Databricks는 세 가지 유형의 데이터를 모두 하나의 플랫폼에서 처리할 수 있습니다. 이것이 레이크하우스 아키텍처의 핵심 장점 중 하나입니다.

정형 데이터

반정형 데이터

💡 Databricks SQL에서는 : (콜론) 표기법을 사용하여 JSON의 중첩 필드에 접근할 수 있습니다. raw_data:user.name은 JSON 객체 raw_data 안의 user 안의 name 값을 가져옵니다.

비정형 데이터

🆕 최신 기능: Databricks는 ai_parse_document 함수를 통해 PDF, DOCX, PPTX, 이미지 등의 비정형 문서에서 텍스트를 자동으로 추출하는 기능을 제공하고 있습니다. 별도의 외부 도구 없이도 비정형 데이터를 처리할 수 있습니다.

Unity Catalog의 Volume

비정형 데이터(파일)를 관리하기 위해 Databricks는 Volume 이라는 개념을 제공합니다.
💡 Volume이란? Unity Catalog에서 테이블이 아닌 파일(이미지, PDF, 모델 파일 등)을 관리하는 저장 공간입니다. 테이블과 마찬가지로 카탈로그 → 스키마 아래에 생성되며, 동일한 권한 체계로 접근을 제어할 수 있습니다. 경로는 /Volumes/<catalog>/<schema>/<volume>/ 형태입니다.

실무에서 가장 골치아픈 데이터 — 반정형 데이터의 현실

세 가지 유형 중 실무에서 가장 많은 시간을 잡아먹는 것은 반정형 데이터, 특히 중첩된 JSON 입니다.

JSON 중첩 구조 처리의 현실

외부 API에서 받아오는 JSON은 이론처럼 깔끔하지 않습니다. 현업에서 마주치는 진짜 문제들을 살펴보겠습니다.

문제 1: 필드가 있다가 없다가 합니다

이 세 가지 케이스를 모두 처리하지 않으면, 파이프라인이 특정 레코드에서 갑자기 실패합니다. 현업에서는 매주 새로운 필드가 추가되거나, 기존 필드의 형식이 바뀌는 일이 비일비재합니다.

문제 2: 같은 필드인데 타입이 다릅니다

💡 현업에서는 이렇게 합니다: 반정형 데이터를 다룰 때는 Schema Evolution(스키마 진화) 을 지원하는 도구가 필수적입니다. Databricks의 Auto Loader는 새로운 필드가 추가되면 자동으로 감지하고, _rescued_data 컬럼에 파싱할 수 없는 데이터를 보관합니다. 이 덕분에 파이프라인이 중단되지 않고 계속 동작합니다.

문제 3: 배열 안에 객체, 객체 안에 배열

이런 깊은 중첩 구조를 평면 테이블로 변환하려면, Spark의 explode()inline()을 여러 번 적용해야 합니다.
⚠️ 성능 주의: explode()는 한 행을 여러 행으로 변환하므로, 중첩 배열을 여러 번 펼치면 데이터 건수가 기하급수적으로 증가할 수 있습니다. 10만 건의 원본이 explode() 두 번으로 1,000만 건이 되는 경우도 있습니다.

비정형 데이터가 AI 시대에 중요해진 이유

기업 데이터의 약 80%가 비정형이라는 통계는 예전부터 있었지만, 과거에는 이 데이터를 활용할 마땅한 방법이 없었습니다. LLM(대규모 언어 모델)의 등장 으로 상황이 완전히 바뀌었습니다.

Before: AI 이전 시대

After: AI + Databricks

💡 현업에서는 이렇게 합니다: 비정형 데이터는 Unity Catalog의 Volume 에 저장하고, 메타데이터(파일명, 업로드 일시, 처리 상태 등)는 Delta 테이블 에 관리합니다. 이렇게 하면 “어떤 PDF가 아직 처리되지 않았는지”를 SQL로 쿼리할 수 있어 운영이 편리합니다.

실무에서의 데이터 유형 조합

실제 비즈니스 환경에서는 세 가지 유형의 데이터가 함께 사용되는 경우가 대부분입니다. 예를 들어 보겠습니다.

예시: 고객 서비스 분석

Databricks 레이크하우스에서는 이 모든 데이터를 Unity Catalog 아래에서 통합 관리하며, 정형 데이터는 Delta 테이블 로, 비정형 데이터는 Volume 으로 저장하여 하나의 거버넌스 체계에서 관리할 수 있습니다.

Databricks에서 각 데이터 유형 처리 시 실전 팁

정형 데이터 팁

반정형 데이터 팁

비정형 데이터 팁


정리

이것으로 데이터 기초 섹션을 마치겠습니다. 다음 섹션에서는 이러한 데이터들을 처리하는 플랫폼인 Databricks에 대해 자세히 알아보겠습니다.

참고 링크