Big Project · AI's EYE 10

숫자가 모두 같아 보이지 않게: 데이터 Provenance 설계

대시보드와 CSV에 숫자가 보이면 모두 실제 매장 실적처럼 받아들이기 쉽다. replay와 합성 주문, 미래 시뮬레이션의 차이가 화면에서 왜 중요한지 놓치기 쉽다.

근거 · 프로젝트 문서 · 코드 · 테스트

1장: 모두가 ‘실제’ 같아 보이는 대시보드의 함정

솔라는 노트북을 거실 테이블에 올려놓으며 만족스러운 미소를 감추지 못했다. 잠시 무언가를 골똘히 들여다보던 솔라가 이내 환호성을 지르며 의자 등받이에 몸을 기댔다.

“언니! 이거 봐봐. 드디어 우리 시스템이 빛을 발하는 것 같아. 오늘 오후 2시 피크 타임에 시간당 주문 처리량이 50건을 돌파했어!”

솔라의 목소리에는 자부심이 가득했다. 매장의 운영 효율성을 높이기 위해 개발 중인 새 시스템의 성과를 보여주는 대시보드였다. 화면 중앙에는 ‘시간당 주문 수’라는 이름표를 단 꺾은선 그래프가 힘차게 우상향하고 있었고, 특정 지점에 마우스를 올리자 ‘52건’이라는 숫자가 팝업으로 선명하게 나타났다. 솔라에게 그 숫자는 곧 현실이었다. 분주하게 움직이는 매장 직원들, 쉴 새 없이 들어오는 주문 알림, 성공적으로 고객에게 전달되는 상품의 흐름이 눈앞에 그려지는 듯했다.

“우리가 만든 시스템 덕분에 매장이 이렇게 바빠진 거잖아. 이 데이터 정리해서 내일 회의 때 보여주면 다들 깜짝 놀라겠지?”

솔라의 들뜬 목소리를 들으며 주방에서 차를 들고 나온 루나가 조용히 솔라의 옆으로 다가왔다. 루나는 솔라가 가리키는 화면을 잠시 응시했다. 솔라의 말대로 그래프는 인상적인 성과를 보여주고 있었다. 하지만 루나의 시선은 그래프의 높은 봉우리가 아닌, 화면의 다른 구석들을 천천히 훑고 있었다.

“정말 인상적인 숫자네.” 루나가 입을 열었다. “회의 때 이 숫자의 의미를 설명하려면, 이 ‘52’라는 숫자가 정확히 어디서 왔는지 알아야 할 거야. 혹시 이 주문들이 실제로 매장에서 들어온 건지 확인해 봤어?”

“응? 그야 당연히….”

솔라는 자신만만하게 대답하려다 순간 말문이 막혔다. 당연히 실제 매장 실적이라고 생각했다. 대시보드에 숫자가 보이면, CSV 파일에 데이터가 기록되면, 그것은 의심할 여지 없는 사실이라고 믿어왔다. ‘데이터는 거짓말을 하지 않는다’는 격언처럼, 이 숫자들은 객관적인 진실의 증거라고 여겼다. 루나의 질문은 그 단단한 믿음에 처음으로 작은 균열을 냈다.

“그게… 실제 매장 실적이 아니면 뭔데? 이 대시보드는 우리 매장 운영 현황판이잖아.”

“한번 같이 볼까?”

루나는 솔라의 노트북 옆에 자신의 찻잔을 내려놓았다. 그리고는 솔라가 가리키던 ‘52’라는 숫자를 다시 클릭하게 했다. 팝업 창이 다시 나타났고, 그 아래로 몇 줄의 추가 정보가 펼쳐졌다. 솔라는 여태껏 그 상세 정보 링크를 눌러볼 생각조차 하지 않았었다.

Total Orders: 52
Source Breakdown:
- pos_stream: 8
- vision_replay: 15
- synthetic_order_simulator: 29

“어?”

솔라의 입에서 짧은 탄식이 흘러나왔다. ‘52’라는 하나의 숫자 뒤에 이렇게 다른 이름들이 숨어있을 줄은 몰랐다. ‘pos_stream’은 실제 매장 판매 시스템에서 들어온 주문처럼 보였다. 하지만 나머지 둘은 무엇일까. ‘vision_replay’? ‘synthetic_order_simulator’? 시뮬레이터라는 단어가 특히 눈에 걸렸다.

“이게… 뭐야? 시뮬레이터? 그럼 가짜 주문이라는 거야?”

순간 솔라의 머릿속이 복잡해졌다. 만약 52건 중 29건이 가짜라면, 자신이 봤던 인상적인 성과는 사실 신기루에 불과했다. 회의에서 이 그래프를 자랑스럽게 발표했다가 누군가 이 상세 내역을 물어봤다면 아찔한 상황이 벌어졌을 것이다. 안도감과 함께 일종의 배신감이 밀려왔다. 왜 시스템은 실제와 가짜를 이렇게 아무렇지 않게 섞어서 보여주는 걸까? 왜 언뜻 봐서는 전혀 구분할 수 없게 만들었을까?

“그럼 이 ‘52’라는 숫자는 아무 의미 없는 거네. 사람들을 속이기 위한 숫자잖아.” 솔라가 허탈하게 말했다.

“속이기 위한 건 아니야.” 루나가 차분하게 말을 이었다. “각각의 숫자는 모두 다른 목적을 가지고 있어. 시스템이 잘 작동하는지 시험하기 위한 테스트 주문일 수도 있고, 과거 데이터를 다시 재생해서 특정 상황을 분석하려는 걸 수도 있지. 중요한 건, 저 ‘52’라는 숫자를 보고 ‘매장이 바쁘다’고 단정하기 전에, ‘이 숫자는 무엇으로 이루어져 있는가?’라고 먼저 질문하는 거야.”

루나의 말에 솔라는 고개를 들어 다시 화면을 바라보았다. 이제 ‘시간당 주문 수: 52’라는 숫자는 이전과 전혀 다르게 보였다. 그것은 더 이상 의심의 여지가 없는 단일한 사실이 아니었다. 여러 출처에서 온 데이터들이 모여 만들어진, 해석이 필요한 하나의 ‘결과’였다.

솔라는 방금 전까지 자신이 얼마나 순진하게 데이터를 믿고 있었는지 깨달았다. 화면에 보이는 숫자는 그저 숫자일 뿐, 그 이면에 담긴 맥락과 출처를 이해하지 못하면 언제든 잘못된 판단을 내릴 수 있었다.

“그럼… 진짜와 가짜는 어떻게 구분하는데? 언뜻 보기에는 다 똑같은 주문 실적처럼 보이는데, 구체적인 차이점이 뭐야?”

솔라의 질문에는 더 이상 회의 발표에 대한 기대감이 섞여 있지 않았다. 대신, 눈앞의 숫자에 숨겨진 진짜 의미를 파헤치고 싶다는 진지한 호기심이 담겨 있었다.

2장: 숫자의 본질을 가르는 세 가지 단서: ID, 출처, 저장 여부

다음 날 아침, 솔라는 어젯밤의 허탈함 대신 새로운 종류의 집중력으로 노트북 앞에 앉아 있었다. 진짜와 가짜를 어떻게 구분하냐는 질문에, 루나는 말없이 노트북 화면에 새로운 창을 띄워 보여주었다. 거실 테이블 위에는 어제의 화려한 대시보드 대신, 마치 시스템의 속살을 들여다보는 듯한 단순한 텍스트 로그(log)가 흐르고 있었다. 솔라가 미처 신경 쓰지 않았던 시스템의 가장 원초적인 기록이었다.

루나는 아무 말 없이 특정 주문 데이터 몇 개를 복사해 와, 화면 한쪽에 간이 텍스트 편집기를 열고 붙여넣었다. 각 데이터는 여러 줄의 정보로 이루어져 있었지만, 루나는 그중 세 가지 항목만 남기고 나머지는 모두 지웠다. 솔라가 알아보기 쉽게, 마치 세 개의 열을 가진 작은 표처럼 정리된 형태였다.

Order ID	Source	Saved
`a4e7...`	`pos_stream`	Yes
`f9b2...`	`vision_replay`	Yes
`sim-d8c1...`	`synthetic_order_simulator`	Yes
`(ephemeral)`	`what_if_simulation`	No

“어제 우리가 봤던 ‘52’라는 숫자를 만든 주문 데이터의 일부야. 이 표만 보고 어떤 차이점이 보이는지 한번 찾아볼래?”

솔라는 표를 유심히 들여다보았다. 어제 대시보드에서 봤던 Source 필드가 눈에 띄었다. pos_stream, vision_replay, synthetic_order_simulator… 그리고 처음 보는 what_if_simulation까지. 솔라는 실시간으로 들어오는 주문이 가장 ‘진짜’라고 생각했다.

“음… pos_stream이 실제 매장에서 들어온 실시간 주문 같아. 나머지는 replay나 simulator 같은 단어가 붙었으니, 과거 데이터를 재생하거나 아예 가상으로 만든 데이터겠지. 결국 실시간이냐 아니냐의 차이 아닐까?”

솔라는 데이터의 ‘실제성’이 곧 ‘실시간성’과 같다고 생각했다. 화면에 흐르는 현재의 데이터만이 가치 있고, 나머지는 모두 부차적인 모조품이라고 여겼다. 루나는 솔라의 대답을 듣고는 고개를 끄덕이면서도, 다른 곳을 가리켰다.

“그것도 중요한 관점이야. 하지만 다른 열들도 한번 볼래? 특히 Order ID를 봐. 다른 것들과 유독 달라 보이는 게 하나 있지 않아?”

루나의 손가락 끝을 따라가자, 솔라의 눈에 한 줄이 확 들어왔다. 세 번째 줄의 Order ID는 sim-이라는 이상한 접두사로 시작하고 있었다. 다른 ID들은 평범한 숫자와 알파벳의 나열인데, 저것만 혼자 이름표를 달고 있는 것 같았다.

“sim-… 아! 시뮬레이션 데이터라는 표식이구나. Source 필드를 일일이 확인하지 않아도, ID만 보고도 ‘이건 가상 주문이네’ 하고 바로 알 수 있도록 만든 거네.”

“맞아. 그게 첫 번째 단서야. 데이터의 고유 식별자(ID)에 그 출처에 대한 힌트를 심어두는 거지. 마치 소포 상자에 ‘취급주의’ 스티커를 붙여두는 것처럼 말이야. 내용을 다 열어보지 않아도 중요한 성격을 짐작할 수 있게 해.”

솔라는 고개를 끄덕였다. ID와 Source 필드가 서로 다른 방식으로 데이터의 정체를 알려주고 있었다. 하나는 이름표, 다른 하나는 상세한 자기소개서 같았다. 하지만 마지막 열 Saved는 여전히 의문이었다. ‘Yes’와 ‘No’라는 단순한 값의 차이가 대체 무슨 의미일까.

“마지막 열은 뭐야? ‘저장됨’? what_if_simulation만 빼고 나머지는 다 저장된다는 뜻 같은데… 저장되고 안 되고가 그렇게 중요해?” 솔라가 물었다.

“이게 가장 근본적인 차이야.” 루나가 설명했다. “데이터가 저장된다는 건, 그 기록이 시스템의 공식적인 ‘역사’의 일부가 된다는 뜻이야. 나중에라도 다시 꺼내서 분석하거나, 문제가 생겼을 때 원인을 추적하는 데 사용할 수 있지. vision_replay나 synthetic_order_simulator의 주문들은 비록 가상이지만, 시스템 테스트나 분석을 위해 ‘있었던 일’로 기록되어야 해. 그래서 데이터베이스에 저장되는 거야.”

루나는 표의 마지막 행, Saved가 ‘No’로 표시된 what_if_simulation을 가리켰다.

“하지만 What-if는 달라. 이건 ‘만약 매장에 직원을 한 명 더 투입한다면 시간당 주문 처리량이 어떻게 될까?’ 같은 질문에 답하기 위한, 일회성 계산에 불과해. 화면에 잠시 결과 값을 보여주고는 그대로 사라지는, 말 그대로 안개 같은 데이터지. 굳이 저장해서 역사의 일부로 남길 필요가 없어. 그래서 ‘저장하지 않음’이라는 정책이 이 데이터의 본질을 정의하는 거야.”

그제야 솔라는 모든 조각이 맞춰지는 것을 느꼈다. 자신이 생각했던 ‘실시간이냐 아니냐’는 데이터의 성격을 구분하는 여러 기준 중 하나일 뿐이었다. 데이터의 진짜 정체는 세 가지 단서가 복합적으로 드러내고 있었다.

ID: sim-처럼 한눈에 정체를 드러내는 이름표.
출처(Source): synthetic_order_simulator처럼 생성 방식을 구체적으로 알려주는 이력서.
저장 여부(Saved): 시스템의 공식적인 기록으로 남을지, 아니면 일회성 계산으로 사라질지를 결정하는 운명.

이 세 가지 단서를 통해, 겉보기에는 똑같아 보이는 숫자 뒤에 완전히 다른 목적과 의미가 숨어 있음을 알 수 있었다. 그것은 더 이상 ‘진짜’와 ‘가짜’라는 이분법으로 나눌 수 있는 문제가 아니었다.

“이제 알겠어. 대시보드의 숫자를 볼 때, 그냥 숫자로만 보면 안 되는 거였어. 이 숫자가 어떤 이름표(ID)를 달고, 어떤 이력서(Source)를 가졌으며, 과연 기록으로 남는(Saved) 존재인지까지 읽어내야 진짜 의미를 파악할 수 있는 거구나. 마치 데이터의 출생증명서를 확인하는 것 같네.”

솔라는 이제 데이터를 판독하는 자신만의 방법을 찾은 듯했다. ‘출처 판독기’라도 손에 넣은 기분이었다. 하지만 이내 새로운 질문이 고개를 들었다.

“좋아, 이렇게까지 해서 출처를 꼼꼼하게 구분하는 방법은 알겠어. 그런데… 이게 실제 의사결정에 그렇게까지 큰 영향을 미쳐? 데모용 데이터가 좀 섞여 있다고 해서, 그걸 보고 내리는 판단이 얼마나 달라진다고 이렇게 복잡한 설계를 하는 거지?”

3장: 오해를 방지하고 신뢰를 만드는 데이터 Provenance의 힘

솔라의 질문이 끝나자, 루나는 어제와는 다른 대시보드 화면을 노트북에 띄웠다. 어제 솔라를 흥분시켰던 꺾은선 그래프 대신, 여러 개의 핵심 성과 지표(KPI)가 나열된 간결한 화면이었다. 대부분의 숫자는 녹색이나 노란색으로 표시되어 있었지만, 솔라의 눈길을 사로잡은 것은 한 KPI 옆에 붙은 낯선 꼬리표였다.

평균 준비 시간: 3.5분 (Mixed)

‘Mixed’? 섞여 있다는 뜻인가? 솔라는 어제 루나가 보여줬던 데이터의 출생증명서, 즉 ID와 Source, 저장 여부를 기록한 표를 떠올렸다. 어쩌면 저 (Mixed)라는 표시는 여러 출처의 데이터가 섞여 있다는 뜻일지도 모른다. 솔라는 이제 데이터를 곧이곧대로 믿지 않고, 그 이면을 의심하는 법을 배웠다. 하지만 여전히 마음 한구석에는 이런 생각이 남아 있었다.

‘데모용 데이터가 좀 섞여 있다고 해서, 그게 그렇게까지 중요할까? 전체적인 추세를 보는 데는 큰 문제 없지 않을까? 결국 기술적인 세부사항일 뿐이야.’

솔라는 자신의 생각을 시험해 보기로 했다.

“언니, 이 평균 준비 시간: 3.5분이라는 지표를 보고 내가 매장 관리자라고 가정해 볼게. 이 정도면 꽤 괜찮은 성과잖아? 주말에 대비해서 직원을 더 뽑을 필요는 없겠다고 판단할 것 같아. 저 (Mixed)라는 표시는 아마 시스템 테스트용 데이터가 포함됐다는 뜻일 테니, 실제 성과도 크게 다르지 않을 거고.”

솔라는 자신의 판단이 꽤 합리적이라고 생각했다. 데이터 출처를 구분하는 것은 중요하지만, 그게 모든 의사결정을 뒤흔들 만큼 결정적이라고는 믿기지 않았다. 루나는 솔라의 말을 가만히 듣고 있다가, (Mixed)라고 표시된 부분을 클릭했다. 그러자 작은 팝업 창이 나타나며 숨겨져 있던 세부 정보가 드러났다.

평균 준비 시간: 3.5분 (Mixed)

상세 내역:
- Source: pos_stream (실제 주문): 5건 / 평균 6.2분
- Source: synthetic_order_simulator (합성 주문): 45건 / 평균 3.1분

“아…”

솔라의 입에서 나지막한 탄성이 터져 나왔다. 화면에 나타난 진실은 충격적이었다. 솔라가 ‘꽤 괜찮다’고 판단했던 3.5분이라는 숫자는 허상이었다. 그럴듯해 보이는 평균값은, 시스템의 이상적인 성능을 보여주기 위해 대량 생성된 합성 주문(45건, 3.1분)에 의해 심하게 왜곡되어 있었다. 실제 매장에서 들어온 주문의 준비 시간은 무려 6.2분으로, 목표치에 한참 미치지 못하는 수준이었다.

만약 솔라가 매장 관리자였다면, 3.5분이라는 숫자에 안심하고 아무런 조치도 취하지 않았을 것이다. 그리고 주말 피크 타임에 밀려드는 주문을 감당하지 못해 고객들의 불만이 폭주하는 최악의 상황을 맞이했을지도 모른다. (Mixed)라는 작은 꼬리표는 단순한 기술적 표시가 아니었다. 그것은 ‘이 숫자를 그대로 믿고 의사결정하면 위험하다’고 외치는 강력한 경고 신호였다.

“이제 알겠어… 왜 이렇게까지 출처를 구분해야 하는지.” 솔라가 힘없이 말했다. “데이터 출처는 그냥 참고 정보가 아니었어. KPI의 의미 자체를 완전히 바꿔버리는, 가장 핵심적인 맥락이었구나. 이걸 무시하는 건, 나침반의 N극과 S극이 뒤바뀐 채로 항해하는 거나 마찬가지였네.”

루나가 조용히 덧붙였다. “맞아. 그래서 대시보드는 주문의 Source가 하나일 때는 ‘실제’ 또는 ‘데모’라고 명확히 보여주지만, 둘 이상 섞이면 (Mixed)라고 표시해서 사용자가 반드시 확인하게 만드는 거야. 오해를 막고, 데이터에 대한 맹목적인 믿음 대신 비판적인 신뢰를 만들기 위한 최소한의 장치지.”

데이터의 출처, 즉 ‘Provenance’를 밝히는 설계는 기술적 세부사항이 아니었다. 그것은 데이터 소비자에게 정직한 정보를 전달하고, 잘못된 의사결정으로 인한 위험을 막아주는 신뢰의 보호막이었다. 숫자가 모두 같아 보이지 않게 만드는 것, 그것이 데이터 시스템이 가져야 할 가장 기본적인 책임이었다.

솔라는 잠시 생각에 잠겼다가, 다시 어제 자신이 발표 자료로 만들려던 첫 번째 대시보드 화면을 띄웠다.

시간당 주문 수: 52

이제 이 숫자는 솔라에게 완전히 다르게 읽혔다. 솔라는 더 이상 ‘엄청난 성과’라며 흥분하지 않았다. 대신, 노트북에 새로운 메모장을 열고 내일 회의에서 발표할 문장을 차분하게 적어 내려가기 시작했다. 그것은 더 이상 숫자를 자랑하는 문장이 아니었다. 숫자의 의미를 정직하게 해석하고, 신뢰도를 보정하는 문장이었다.

시간당 관측된 주문 처리량: 52건

데이터 구성: 실제 매장 주문 8건, 과거 데이터 재현 15건, 시스템 부하 테스트용 합성 주문 29건으로 구성됨.

판단: 현재 실제 매장의 시간당 처리량 기준선은 8건으로 판단해야 하며, 나머지 44건은 시스템 테스트 및 분석 목적의 데이터임. 따라서 현재 운영 효율성 평가는 ‘8건’을 기준으로 진행해야 함.

솔라는 자신이 작성한 메모를 루나에게 보여주었다. 루나는 말없이 미소를 지으며 고개를 끄덕였다. 솔라는 더 이상 화려한 숫자에 현혹되지 않았다. 대신 데이터의 출생증명서를 꼼꼼히 확인하고, 그 신뢰도를 스스로 보정하여 가장 정확한 진실을 찾아내는 능력을 갖게 된 것이다. 이제 솔라의 손에는 어떤 데이터 앞에서도 올바른 판단을 내릴 수 있게 해주는 자신만의 ‘데이터 신뢰 보정기’가 들려 있었다.