메타데이터

메타데이터는 어떤 대상을 설명하려고 따로 적어 두는 데이터입니다. 사진 파일이라면 찍힌 장면이 아니라 언제 어디서 찍었는지가 메타데이터입니다. 대상을 열어 보지 않고도 찾아내고 다룰 수 있게 해 줍니다.

쉽고 빠른 이해

메타데이터는 어떤 대상을 설명하려고 따로 적어 두는 데이터입니다. 사진 파일이라면 찍힌 장면이 아니라 언제 어디서 찍었는지가 메타데이터입니다.

대상이 몇 개뿐이면 열어 보면 그만이지만, 수가 늘면 그럴 수 없습니다. 대상 밖에 따로 적어 두면 대상 자체를 건드리지 않고도 무엇이 어디 있는지 읽고 고칠 수 있습니다.

어떻게 붙는가:

대상 밖에 따로 붙기도 하고, 대상 안에 섞여 들어가기도 합니다
대상 하나에 여러 벌이 붙기도 합니다
무엇에 대해 말하느냐로 갈립니다 — 찾는 데 쓰는 것, 부분들 사이 관계를 적은 것, 관리하는 데 쓰는 것

쓰는 데는 대가가 따릅니다. 어떤 값이 메타데이터인지는 고정돼 있지 않습니다. 보는 자리를 바꾸면 같은 값이 다루는 데이터 자신이 되기도 합니다. 그래서 이 값을 메타데이터로 취급할지는 매번 다시 판단해야 합니다.

상세

식당 메뉴판에 적힌 가격은 손님에게는 음식을 고르는 데 보는 안내입니다. 달마다 매출을 셈하는 주인에게는 그 숫자들이 더해야 할 내용 그 자체입니다. 같은 숫자가 누가 무엇을 하려는지에 따라 안내가 되기도 하고 내용이 되기도 합니다.

메타데이터는 어떤 것을 설명하려고 만들고 저장하고 주고받는 정보입니다. NISO(National Information Standards Organization, 미국 정보표준기구)의 메타데이터 입문서는 이 정보 덕분에 사람이 그 대상을 다루며 필요한 지식을 얻는다고 적습니다. 고전적인 정의는 낱말 자체의 어원을 그대로 따른 것이라고도 적습니다. 데이터에 대한 데이터라는 정의입니다.

설명의 대상이 되는 쪽은 자원이라고 부릅니다. 자원은 파일일 수도 있고 웹에서 주고받는 한 덩이의 표현일 수도 있고 데이터베이스의 테이블일 수도 있습니다.

메타데이터는 자원 밖에 따로 붙기도 합니다. 자원 안에 섞여 들어가기도 합니다. 자원 하나에 여러 벌이 붙기도 합니다.

무엇이 메타데이터인지는 무엇을 자원으로 잡느냐에 따라 갈립니다. 파일의 크기와 소유자는 그 파일을 여는 쪽에서 보면 파일에 딸린 설명입니다. 디스크 사용량을 집계하는 쪽에서 보면 그 값 자체가 다루는 데이터입니다. 같은 값이 관점에 따라 이쪽이 되기도 하고 저쪽이 되기도 합니다. 데이터와 메타데이터를 가르는 선은 값에 붙어 있지 않습니다. 무엇을 설명하려는지에 붙어 있습니다.

배경

자원이 몇 개뿐이면 열어 보면 됩니다. 수가 늘면 그럴 수 없습니다. 무엇이 어디 있는지 알려면 자원마다 내용을 통째로 읽어야 합니다. 자원이 클수록 그 비용이 커집니다.

내용을 다 읽어도 안 나오는 것이 있습니다. 누가 만들었는지, 마지막으로 언제 바뀌었는지, 누가 열어 봐도 되는지는 내용 안에 적혀 있지 않습니다. 이런 것은 자원 밖에 따로 적어 두어야 합니다. 그래야 자원 자체를 건드리지 않고도 읽고 고칠 수 있습니다.

그래서 자원마다 그 자원을 설명하는 짧은 기록을 붙이게 됐습니다. NISO 는 이런 기록이 정보 시스템 곳곳에 퍼져 있다고 적습니다. 날마다 쓰는 소프트웨어 대부분은 핵심 기능이 이 기록에 기대어 돈다고도 적습니다. 사용자가 필요한 항목을 찾고, 그 항목에 대한 핵심 정보를 기록하고, 그 정보를 남과 나누게 해 주기 때문입니다. 데이터에 대한 데이터라는 뜻으로 메타데이터라고 부릅니다.

갈래

무엇에 대해 말하느냐가 축입니다. 같은 자원에 붙어도 찾으라고 붙은 것, 부분들의 관계를 적어 둔 것, 관리하라고 붙은 것이 서로 다릅니다. NISO 는 이 셋을 서술 메타데이터, 구조 메타데이터, 관리 메타데이터로 가릅니다.

갈래	무엇에 대해 말하나
서술 메타데이터	자원의 내용. 찾거나 이해하는 데 씁니다
구조 메타데이터	자원을 이루는 부분들이 서로 어떤 관계인지
관리 메타데이터	자원을 관리하는 데 필요한 정보. 아래에 셋이 더 있습니다
관리 › 기술 메타데이터	파일을 디코딩하고 화면에 그려 내는 데 필요한 정보
관리 › 보존 메타데이터	파일을 오래 관리하고 나중에 옮기거나 에뮬레이션하는 데 필요한 정보
관리 › 권리 메타데이터	내용에 붙은 지식재산권

관리 메타데이터 아래에는 다시 셋이 있어, 갈래는 아래처럼 2층입니다.

flowchart TD
    M["메타데이터"] --> S["서술 메타데이터"]
    M --> ST["구조 메타데이터"]
    M --> A
    subgraph A["관리 메타데이터"]
        G["기술 메타데이터"]
        P["보존 메타데이터"]
        R["권리 메타데이터"]
    end

서술 메타데이터

자원의 내용에 대한 정보입니다. 사진이 언제 어디서 찍혔는지처럼, 그 자원을 찾거나 이해하는 데 도움이 됩니다. NISO 는 문화유산 분야가 이 갈래를 다른 갈래들과 구별해 왔다고 적습니다.

구조 메타데이터

자원을 이루는 부분들이 서로 어떤 관계인지를 적습니다. NISO 가 든 예는 책 한 권 안에서 차례대로 이어지는 쪽들, 각 장의 시작 쪽을 가리키는 목차, 그리고 같은 내용을 해상도나 비트 깊이만 달리해 담은 여러 판을 서로 잇는 것입니다.

관리 메타데이터

자원을 관리하는 데 필요한 정보, 또는 자원이 만들어진 경위와 관계된 정보를 아우르는 말입니다. 그 안에 다시 셋이 있습니다. 기술 메타데이터는 디지털 파일을 디코딩(부호화된 데이터를 원래 형태로 되돌리는 것)하고 화면에 그려 내는 데 필요한 정보입니다. 파일 형식 같은 것입니다. 보존 메타데이터는 파일을 오래 관리하고 나중에 옮기거나 에뮬레이션(다른 환경에서도 원래처럼 돌아가게 흉내 내는 것)하는 일을 뒷받침합니다. 체크섬이나 해시가 그 예입니다. 권리 메타데이터는 내용에 붙은 지식재산권을 적습니다. 크리에이티브 커먼즈 라이선스가 그 예입니다.

NISO 는 서술 메타데이터와 관리 메타데이터를 구조 메타데이터와는 별개의 것으로 봅니다. 서술과 관리는 자원 자체에 대해 말하지만, 구조는 부분들 사이의 관계에 대해 말하기 때문입니다.

예시

HTTP 표현 메타데이터

표현은 메시지에 담겨 오가는 데이터 한 덩이를 가리킵니다. HTTP(HyperText Transfer Protocol) 명세인 RFC(Request for Comments) 9110 은 8.2 절을 표현 메타데이터에 씁니다. 표현 헤더 필드가 그 표현에 대한 메타데이터를 준다고 적습니다. 메시지에 내용이 담겨 있으면 표현 헤더 필드가 그 데이터를 어떻게 해석할지 설명합니다. HEAD 요청에 대한 응답이라면, 같은 요청을 GET 으로 보냈을 때 담겼을 표현 데이터를 설명합니다.

명세가 이 자리에 두는 필드는 Content-Type, Content-Encoding, Content-Language, Content-Length, Content-Location, 그리고 검증자 필드입니다. 검증자 필드에는 Last-Modified 와 ETag(entity tag, 엔티티 태그)가 있습니다.

명세에 실린 예시 메시지 교환은 값까지 보여 줍니다.

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.

빈 줄 아래가 본문입니다. 위에서 이름을 든 표현 헤더 필드만 그 본문에 대해 말합니다. Content-Length: 51 은 본문이 51바이트라고 적습니다. Content-Type: text/plain 은 그 바이트를 평문으로 읽으라고 적습니다. ETag: "34aa387-d-1568eb00" 은 검증자 필드에 든 값입니다. 같은 응답에 있는 Server · Date · Vary · Accept-Ranges 는 표현 헤더 필드가 아니라서 본문에 대해 말하지 않습니다.

파일 시스템의 inode

POSIX(Portable Operating System Interface) 명세는 파일마다 따로 있는 자리인 inode(아이노드)에 그 파일에 대한 정보를 담아 두고, 이를 struct stat 로 정의합니다. 파일 내용은 여기 없습니다. 파일에 대해 말하는 값만 있습니다.

struct stat {
    dev_t      st_dev;      /* ID of device containing file */
    ino_t      st_ino;      /* Inode number */
    mode_t     st_mode;     /* File type and mode */
    nlink_t    st_nlink;    /* Number of hard links */
    uid_t      st_uid;      /* User ID of owner */
    gid_t      st_gid;      /* Group ID of owner */
    dev_t      st_rdev;     /* Device ID (if special file) */
    off_t      st_size;     /* Total size, in bytes */
    blksize_t  st_blksize;  /* Block size for filesystem I/O */
    blkcnt_t   st_blocks;   /* Number of 512B blocks allocated */
    struct timespec  st_atim;  /* Time of last access */
    struct timespec  st_mtim;  /* Time of last modification */
    struct timespec  st_ctim;  /* Time of last status change */
};

명세는 st_dev 를 그 파일이 사는 장치라고 적습니다. st_ino 는 그 파일의 inode 번호입니다. st_nlink 는 그 파일에 걸린 하드 링크의 개수입니다. st_size 는 파일 전체 크기를 바이트로, st_uid 는 소유자의 사용자 ID(Identifier)를 담습니다. st_mtim 은 마지막으로 내용이 바뀐 시각입니다.

Amazon S3 의 오브젝트 메타데이터

Amazon S3(Simple Storage Service) 공식 안내서는 오브젝트에 붙는 메타데이터를 두 갈래로 가릅니다. 시스템이 정하는 것과 사용자가 정하는 것입니다.

시스템이 정하는 쪽은 S3 가 알아서 유지합니다. Last-Modified 는 오브젝트를 만든 날짜와 마지막으로 고친 날짜 가운데 나중 것입니다. 멀티파트 업로드(큰 오브젝트를 여러 조각으로 나눠 올리는 방식)라면 오브젝트를 만든 날짜는 그 업로드를 시작한 날짜입니다. ETag 는 오브젝트의 특정 판을 나타내는 엔티티 태그입니다. 안내서는 이 값이 데이터의 MD5(Message-Digest Algorithm 5) 다이제스트(원본을 요약해 담은 고정 길이 값)가 되는 조건을 함께 적습니다. 멀티파트 업로드로 올린 오브젝트가 아니어야 합니다. 그리고 암호화하지 않았거나 SSE-S3(Server-Side Encryption with Amazon S3 managed keys, S3 가 관리하는 키를 쓰는 서버 측 암호화)로 암호화한 오브젝트여야 합니다.

사용자가 정하는 쪽은 헤더 이름 앞에 x-amz-meta- 를 붙입니다. 다른 HTTP 헤더와 구별하려는 것입니다. REST(Representational State Transfer) API(Application Programming Interface)로 오브젝트를 가져오면 이 접두사가 그대로 돌아옵니다. 실제로 붙는 모양은 x-amz-meta-ascii: AmazonS3 같은 한 줄입니다.

크기 제한도 붙습니다. PUT 요청 헤더는 8KB 까지입니다. 그 요청 헤더 안에서 사용자 정의 메타데이터는 2KB 까지입니다.

PostgreSQL 의 시스템 카탈로그

PostgreSQL 공식 문서는 데이터의 생김새를 담아 두는 자리로 시스템 카탈로그를 둡니다. pg_class 는 테이블과 인덱스와 시퀀스와 뷰를 담습니다. 문서는 이것들을 릴레이션이라고 부릅니다. pg_attribute 는 테이블의 열을 담습니다. 문서는 이것을 어트리뷰트라고 부릅니다.

대부분의 시스템 카탈로그는 데이터베이스를 만들 때 템플릿 데이터베이스에서 복사됩니다. 그 뒤로는 데이터베이스마다 따로 갑니다.

정보 스키마는 그 옆에 놓인 뷰 묶음입니다. 지금 데이터베이스에 정의된 오브젝트에 대한 정보를 담습니다. 문서는 정보 스키마가 SQL(Structured Query Language) 표준에 정의돼 있어 이식 가능하고 안정적으로 남으리라 기대할 수 있다고 적습니다. 시스템 카탈로그는 그렇지 않습니다. PostgreSQL 에만 있고 구현 사정을 본떠 만들어졌다고 적혀 있습니다. 테이블과 열이 무엇인지에 대한 정보를 테이블 형태로 담아 둔 것이니, 이 카탈로그 자체가 메타데이터입니다.

Dublin Core 의 용어

DCMI(Dublin Core Metadata Initiative)는 자원을 기술하는 용어를 명세로 정합니다. 필드 이름과 그 이름이 무엇을 담는지가 적혀 있습니다.

title 은 자원에 주어진 이름입니다. creator 는 자원을 만드는 일에 주로 책임이 있는 주체입니다. 명세는 사람일 수도, 조직일 수도, 서비스일 수도 있다고 적습니다. date 는 자원의 생애에서 어떤 사건과 이어진 시점 또는 기간입니다. identifier 는 주어진 맥락 안에서 그 자원을 가리키는 모호하지 않은 참조입니다. subject 는 자원의 주제입니다. 명세는 보통 키워드나 핵심 구절, 분류 코드로 나타낸다고 적습니다. 다섯 낱말 모두 자원 자체가 아니라 자원에 대해 말하는 값입니다.