전제
컴퓨터는 의미를 모르고, 일치만 안다
데이터에 관한 거의 모든 오해는 이 한 가지를 건너뛰기 때문에 생긴다.
사람이 기록을 읽을 때는 맥락으로 의미를 채운다. "홍길동"과 "홍길동 님"이 같은 사람이라는 것, "3/5"가 3월 5일이라는 것을 자동으로 안다. 컴퓨터에게는 이 능력이 없다. 컴퓨터가 할 수 있는 것은 이 글자열과 저 글자열이 정확히 같은가를 비교하는 것뿐이다.
따라서 데이터 작업의 본질은 하나다. 사람 머릿속에 있던 의미를, 기계가 일치 비교만으로 처리할 수 있는 구조로 옮겨 적는 것. 뒤에 나오는 모든 단계는 이 번역 작업의 다른 국면이다.
구조
DIKW — 기록이 판단이 되기까지의 네 층위
데이터가 가치가 되는 과정은 네 단계의 계층으로 정리된다. DIKW(Data–Information–Knowledge–Wisdom) 구조다.
이 구조가 말해주는 것
한 층위는 아래 층위 없이 존재할 수 없다. 정보는 데이터를 집계해야 나오고, 지식은 정보들 사이의 패턴을 읽어야 나오고, 지혜는 지식 위에서만 성립한다. 그런데 층위를 올라가는 힘은 층위마다 다르다.
- 데이터 → 정보는 기계의 일이다. 정제·태깅·스키마·적재라는 처리 과정이 이 구간을 담당한다. 뒤에서 자세히 다루는 "데이터 파이프라인"이 바로 이것이다.
- 정보 → 지식 → 지혜는 사람의 일이다. 숫자들 사이의 인과를 읽고, 회사의 상황에 비추어 무엇을 할지 정하는 것은 도구가 대신하지 못한다. AI는 이 해석을 도울 수는 있어도 책임질 수는 없다.
대부분의 조직이 겪는 문제는 정확히 이렇게 표현된다. 데이터 층에 머물러 있으면서 지혜 층의 답을 기대하는 것. "데이터 다 있는데 왜 아무것도 알 수 없죠?"라는 질문은, 1층에 서서 4층 창밖 풍경을 묻는 것과 같은 구조다.
과정
데이터 파이프라인 — 데이터에서 정보로 가는 여섯 단계
DIKW의 첫 구간, 즉 기록 더미를 "질문하면 답이 나오는 상태"로 만드는 과정이다. 수집은 이 여섯 단계 중 첫 번째일 뿐이고, 비용과 시간의 대부분은 그 뒤에 있다.
수집
기록을 물리적으로 한곳에 모은다 · 어려운 이유: 안 적힌 것
쇼핑몰 주문 내역, 리뷰, CS 상담 기록, 물류 엑셀을 내려받아 한 폴더에 모은다. 여기까지는 쉽다. 함정은 다른 데 있다. 기록되지 않은 것은 데이터가 아니다. "그 고객은 원래 까다로운 분"이라는 담당자 머릿속 정보, 전화로만 처리하고 적지 않은 교환 건 — 이것들은 수집할 대상 자체가 없다. 수집 단계의 진짜 질문은 "어디서 받아오나"가 아니라 "우리 회사는 무엇을 적어왔고 무엇을 안 적어왔나"이다.
정제
표기를 통일하고 같은 것을 같게 만든다 · 어려운 이유: 식별자 문제
모은 기록은 같은 것이 다르게 적혀 있고, 다른 것이 구분 없이 적혀 있다. 날짜가 "3/5", "2026-03-05", "3월5일"로 흩어져 있고, 한 고객이 파일마다 다른 이름으로 존재한다.
이름은 동명이인이 있고 전화번호는 바뀐다. 그래서 데이터 세계에서는 현실에 없는 인공 번호 — 고객번호, 주문번호 — 를 만들어 모든 기록에 박아 넣는다. 이 식별자가 있어야 "이 주문과 저 문의는 같은 고객의 것"이라는 연결이 성립한다. 흩어진 기록들 사이에 이 다리를 놓는 것이 정제의 핵심이며, 여기서 실수하면 이후의 모든 분석이 조용히 틀린다. 에러가 나는 게 아니라, 재구매율이 실제보다 낮게 나오는 식으로 틀린 줄도 모르게 틀린다.
태깅
기록에 셀 수 있는 구분값을 붙인다 · 어려운 이유: 기준의 정의
리뷰 3,200건은 태깅 전에는 그냥 글자 뭉치다. 각 리뷰에 "배송 / 품질 / 가격" 같은 구분값을 붙여야 비로소 "배송 불만이 전체의 몇 %"라는 계산이 가능해진다.
어려움은 3,200건을 읽는 노동이 아니라 분류 기준 자체를 정의하는 데 있다. "배송 중에 파손됐다"는 리뷰는 배송인가, 품질인가? 하나의 리뷰에 태그를 두 개 허용하는가? 몇 단계 깊이로 나누는가? 기준이 애매하면 붙이는 사람마다 다르게 붙여 집계가 무의미해지고, 너무 잘게 나누면 태그당 건수가 적어 통계가 되지 않으며, 너무 크게 나누면 나눈 의미가 없다.
태깅은 "무엇을 알고 싶은가"가 먼저 정해져야 역산으로 설계된다. 이 순서를 모르는 조직은 데이터를 다 모아놓고 "이제 뭘 볼 수 있죠?"라고 묻게 된다. 순서가 거꾸로인 것이다.
스키마 설계
모든 기록의 항목과 형식을 확정한다 · 어려운 이유: 업무 규칙의 확정
스키마는 표면적으로는 "고객 기록에는 고객번호·날짜·금액이 이 형식으로 들어간다"는 약속이다. 그러나 실제로는 업무의 애매함을 강제로 제거하는 작업이다. "주문 금액" 칸 하나를 만들려면 답해야 한다. 할인 전인가, 후인가? 배송비 포함인가? 부분 취소가 나면 원래 기록을 고치는가, 취소 기록을 새로 남기는가?
사람은 애매함을 그때그때 판단으로 흡수하며 일해 왔지만, 데이터 구조는 애매함을 허용하지 않는다. 그래서 스키마 설계 과정에서 "우리 회사는 이 규칙이 정해진 적이 없었네"가 줄줄이 드러난다. 데이터 프로젝트가 예상보다 오래 걸리는 진짜 이유는 기술이 아니라 이 업무 정의가 병목이기 때문이다.
스키마의 또 다른 축은 관계의 설계이다. 고객·주문·상품을 한 표에 다 넣으면, 고객 주소가 바뀔 때 그 고객의 주문 수백 줄을 전부 고쳐야 하고 하나라도 빠뜨리면 데이터가 자기모순에 빠진다. 그래서 고객 표, 주문 표, 상품 표를 분리하고 식별자로 연결한다. 정보를 한 곳에만 적고 나머지는 참조하게 만드는 것 — 엑셀 복사본이 늘수록 숫자가 서로 안 맞게 되는 현상의 정확한 반대말이다.
적재
데이터베이스에 넣는다 · 어려운 이유가 아니라 보증이 핵심
데이터베이스에 넣는다는 것은 저장 위치를 옮기는 게 아니라 규칙 위반이 불가능한 환경에 넣는다는 뜻이다.
제대로 설계된 데이터베이스는 존재하지 않는 고객번호로 주문을 등록하려 하면 거부한다. 엑셀은 뭐든 받아주기 때문에 시간이 지나면 반드시 오염된다. 입구에서 막기 때문에 어제의 데이터와 오늘의 데이터가 같은 규칙 위에 있다는 것이 보증되고, 이 보증이 있어야 정리된 상태가 유지된다. 정리를 한 번 하는 것과, 정리된 상태가 계속 유지되게 만드는 것의 차이다.
조회와 분석
질문하면 답이 나오는 상태 · 여기서부터 DIKW의 "정보"
여섯 단계를 거친 뒤에야 "지난달 재구매 고객은 몇 명인가"라는 질문에 몇 초 만에 답이 나온다. 파일 100개에 흩어진 상태와 데이터베이스에 규칙대로 들어간 상태는 내용이 같아도 질문에 답할 수 있는가에서 완전히 다르다. 이 시점의 산출물 — "3월 재구매율 12%, 전월 대비 3%p 하락" — 이 DIKW 구조의 두 번째 층, 정보다. 여기서부터는 처리의 문제가 아니라 해석의 문제로 넘어간다.
확장
이미지·음성·영상은 왜 난이도가 한 차원 올라가는가
지금까지의 예시는 전부 글자와 숫자였다. 그런데 텍스트는 사실 가장 쉬운 데이터다.
기호와 신호의 차이
텍스트는 의미는 없어도 기호는 있다. "홍길동"이라는 문자열은 최소한 다른 문자열과 비교라도 할 수 있다. 반면 이미지는 픽셀마다의 색상 숫자, 음성은 초당 수만 개의 진동 값일 뿐이다. 기호가 아니라 신호다.
같은 제품을 찍은 사진 두 장도 조명이 조금만 다르면 숫자 배열로는 완전히 다른 데이터다. 컴퓨터가 유일하게 할 줄 아는 "일치 비교"가 여기서는 아예 성립하지 않는다. 전제부터 무너지는 것이다.
파이프라인 앞에 파이프라인이 하나 더 붙는다
그래서 미디어 데이터는 태깅을 시작하기 전에 인식이라는 단계를 먼저 통과해야 한다. 신호에서 기호를 뽑아내는 단계다. CS 통화 녹음은 먼저 글자로 전사(음성 인식)해야 하고, 리뷰 사진은 무엇이 찍혀 있는지 먼저 판별해야 한다. 이 인식이 끝난 뒤에야, 앞에서 본 여섯 단계 파이프라인이 비로소 시작된다.
문제는 이 인식이 확률적이라는 점이다. 음성 인식은 "환불"을 "한몰"로 받아 적을 수 있고, 이미지 인식은 그림자를 피부 트러블로 판별할 수 있다. 정확도 95%라는 말은 스무 건 중 한 건이 틀린 채로 다음 단계에 흘러 들어간다는 뜻이고, 앞 단계의 오류는 뒤의 모든 집계에 조용히 전파된다. 그래서 인식 결과를 사람이 검수하는 비용이 추가로 발생한다.
태깅의 단위 자체가 문제가 된다
텍스트 리뷰의 태깅은 "이 리뷰는 배송 불만"이라고 한 건에 하나 붙이면 됐다. 미디어에서는 어디에 붙일지부터 정해야 한다.
- 이미지 — 사진 전체에 붙일 것인가, 사진 속 영역마다 붙일 것인가? "사용 후 피부 사진"에서 트러블 부위를 표시하려면 영역을 사람이 일일이 그려야 하고, 건당 작업 시간이 텍스트의 수십 배가 된다.
- 음성 — 전사된 글자에 붙일 것인가, "몇 분 몇 초부터 고객 언성이 높아짐" 같은 시간 구간에 붙일 것인가? 시간축이라는 새 차원이 생긴다.
- 영상 — 두 문제가 곱해진다. 초당 30장의 이미지가 시간축 위에 놓인 것이 영상이므로, 공간의 어디 × 시간의 언제를 동시에 지정해야 한다. 1분짜리 언박싱 리뷰 영상 하나가 이미지 1,800장과 같다.
기준의 모호함도 커진다. 텍스트에서는 "배송 중 파손은 어느 분류인가"가 문제였다면, 이미지에서는 같은 사진을 보고도 사람마다 판단이 갈린다. 이 피부 상태가 "개선"인지 아닌지, 두 검수자의 답이 다르면 어느 쪽이 정답인가? 미디어 태깅에서는 "붙이는 사람들끼리 얼마나 일치하는가"를 별도로 관리해야 할 만큼, 정답 자체가 흔들린다.
저장 구조도 이중이 된다
마지막으로 규모의 문제다. 리뷰 3,200건은 몇 MB지만, 같은 건수의 통화 녹음은 수십 GB, 영상 리뷰는 수백 GB다. 용량이 자릿수로 커지면 보관·전송·처리 비용이 전부 따라 커진다. 그래서 미디어는 데이터베이스에 직접 넣지 않고, 원본 파일은 저장소에 두고 데이터베이스에는 그 위치와 인식·태깅으로 뽑아낸 기호만 넣는 이중 구조를 만든다. 관리해야 할 시스템이 하나에서 둘로 늘고, 둘 사이의 연결이 끊기지 않게 유지하는 일이 새로 생긴다.
정리하면, 미디어 데이터는 파이프라인이 어려워지는 게 아니라 파이프라인에 들어가기 위한 자격부터 만들어야 하는 데이터다. 신호를 기호로 바꾸는 인식 단계, 확률적 오류의 검수, 단위와 기준이 흔들리는 태깅, 이중 저장 구조 — 텍스트에서는 존재하지 않던 비용이 층층이 추가된다.
연결
두 구조를 겹쳐 보기
DIKW는 "무엇이 되어가는가"를, 파이프라인은 "누가 어떤 일을 하는가"를 설명한다. 겹치면 이렇게 된다.
| 층위 | 올라가는 방법 | 주체 |
|---|---|---|
| 데이터 → 정보 | 수집 · 정제 · 태깅 · 스키마 · 적재 · 조회 (파이프라인 전체) | 기계 + 설계하는 사람 |
| 정보 → 지식 | 숫자들 사이의 패턴과 인과를 읽는 해석 | 사람 (AI가 보조) |
| 지식 → 지혜 | 회사의 상황·자원에 비춘 우선순위 결정 | 사람 |
"데이터만 모으면 알아서 된다"는 오해는 이 표에서 첫 행의 여섯 단계와 나머지 두 행 전체를 통째로 생략한 것이다.
한계와 역할
AI가 이 과정을 대신하지 못하는 이유
AI는 애매한 것을 그럴듯하게 추측하는 데 강하다. 그런데 파이프라인의 목적은 정반대로, 추측의 여지를 없애는 것이다. "홍길동과 홍길동 님이 같은 사람 같다"는 AI의 추측은 90% 맞겠지만, 회계와 정산은 100%가 필요한 영역이다.
그래서 역할이 갈린다. AI는 태깅 후보를 제안하고, 오염된 데이터를 찾아내고, 정보 층에서 패턴을 짚어주는 보조로는 유용하다. 그러나 분류 기준을 정하는 것, 업무 규칙을 확정하는 것, 지식을 지혜로 바꾸는 결정 — 이것은 회사만이 할 수 있고, 데이터 작업의 진짜 비용이 정확히 거기에 있다.
요약
세 문장으로 줄이면
- 데이터의 가치는 양이 아니라 질문에 답할 수 있는 상태인가에서 나온다.
- 수집은 시작일 뿐이고, 정제·태깅·스키마·적재 — 회사의 애매했던 정의를 확정해 기계가 처리 가능한 구조로 고정하는 일 — 이 전체 비용의 대부분이다.
- 그렇게 만든 정보를 지식과 지혜로 끌어올리는 마지막 구간은 도구가 아니라 사람의 몫이다.