560. 데이터 메시 (Data Mesh) - 데이터 소유권의 탈중앙화 (도메인 중심)

핵심 인사이트 (3줄 요약)

1. 본질: 데이터 메시(Data Mesh)는 회사 내 50개 팀의 모든 데이터를 중앙의 '데이터 레이크(Data Lake)' 1곳에 쓸어 담고 데이터 엔지니어 10명이 독박 관리하며 허덕이던 낡은 중앙 집권 병목을 찢어버리고, 각 도메인(결제팀, 주문팀)이 자신의 데이터를 알아서 가공해 '하나의 완제품(Data as a Product)'으로 다른 팀에게 제공하도록 데이터 소유권 자체를 탈중앙화시키는 데이터 아키텍처 혁명이다.
2. 가치: 데이터를 가장 잘 이해하는 도메인 실무자(결제 개발자)가 직접 데이터 품질을 챙기고 API처럼 뽑아주기 때문에, 중앙 팀이 "이 컬럼 대체 무슨 뜻이에요?" 물어보며 3달씩 데이터 파이프라인(ETL)을 뚫던 끔찍한 병목이 사라진다. 회사는 각 부서가 만들어 올린 고품질 데이터 상품(블록)을 뷔페처럼 자유롭게 융합하여 1초 만에 AI 모델과 비즈니스 통계로 굴려내는 전사적 민첩성의 극치를 얻는다.
3. 융합: 거대한 기술 스택(Hadoop, Spark) 하나로 천하 통일하려던 무식함을 버리고, 데이터 거버넌스(표준화 규칙)만을 연합 지휘부(Federated Governance)로 묶은 뒤, 마이크로서비스 아키텍처(MSA, 532장)와 도메인 주도 설계(DDD, 534장)의 위대한 조직 쪼개기(Decoupling) 철학을 소스코드를 넘어 '분석용 데이터 파이프라인'의 영역까지 수직으로 완벽하게 이식한 궁극의 융합물이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: Data Mesh는 도메인 팀(결제, 배송)이 자기 구역의 데이터 생산/정제를 끝까지 책임지고 셀프 서빙(Self-serve) 인프라에 올려서 남들에게 **'데이터를 하나의 팔 수 있는 상품(Data as a Product)'**처럼 진열해 두는 분산형 데이터 관리 철학이다.

• 필요성 (데이터 레이크의 늪과 중앙 병목의 폭발): 옛날엔 빅데이터 열풍에 취해 사내 100개 팀의 데이터를 무지성으로 S3 데이터 레이크 중앙 창고 하나에 다 쑤셔 부었다. 그리고 가엾은 데이터 엔지니어 10명이 그 쓰레기 산(Data Swamp)을 뒤지며 마케팅팀의 "결제 전환율 통계 좀 뽑아주세요!"라는 주문을 매일 받아 쳐냈다. 문제는 중앙 엔지니어는 '결제(도메인)' 로직을 1도 모른다는 것이다. "결제팀에서 status_code 4라고 던졌는데 이거 환불인가요?" 물어보느라 3달이 걸려 파이프라인(ETL)을 하나 뚫었다. **"중앙 데이터팀 10명이 전사 10,000명의 데이터 요구사항을 독박으로 처리하려니 회사의 데이터 민첩성 속도가 0에 수렴하는 끔찍한 바틀넥(Bottleneck)"**이 터지며, 이를 부수기 위한 탈중앙화의 칼바람이 불었다.

• 💡 비유: 기존 데이터 레이크는 **'초대형 중앙 집중식 쓰레기장 겸 재활용 센터'**입니다. 동네(도메인) 50곳에서 온갖 쓰레기(데이터)를 분리수거도 안 하고 한곳에 쏟아붓습니다. 가운데 앉은 불쌍한 재활용 직원 10명(데이터 엔지니어)이 냄새나는 산을 뒤지며 땀 뻘뻘 흘려 쓸만한 플라스틱을 골라냅니다(효율 최악). 데이터 메시는 **'각 동네 재활용 책임제'**입니다. 결제 동네, 배송 동네에서 각자 주민들이 깨끗하게 세척하고 분리수거해서 딱 묶어 '예쁜 완제품 상자(Data Product)'로 집 앞에 내놓습니다. 중앙 직원은 없고, 필요한 사람은 그냥 지나가다 그 예쁜 상자를 가져다 쓰기만 하면 되는 초고속 친환경 시스템입니다.

• 등장 배경 및 발전 과정:

  1. Data Warehouse (구석기): 오라클 통짜 DB에 정형화된 데이터만 예쁘게 모아둠. 확장성 부족.
  2. Data Lake (신석기): "야 그냥 다 쑤셔 넣어! 하둡/S3!" (Hadoop 붐). 엄청나게 쌓였으나 아무도 의미를 모르는 쓰레기 늪(Data Swamp)이 됨.
  3. Zhamak Dehghani의 Data Mesh 제창 (2019~): ThoughtWorks의 아키텍트가 일침을 놨다. "니들 백엔드는 MSA로 다 찢어서 애자일 해졌으면서, 왜 빅데이터 분석 인프라(파이프라인)는 아직도 중앙에 모놀리식으로 뚱뚱하게 모아두고 병목 짓거리냐? 데이터도 도메인별로 찢어서 걔들한테 책임지라 그래!" 빅데이터 씬의 거대한 패러다임 시프트가 터졌다.

• 📢 섹션 요약 비유: 데이터 메시의 혁명은 공장의 **'품질 관리(QA) 부서의 해체'**와 같습니다. 옛날엔 100명이 각자 대충 부품을 만들면 맨 끝에 있는 불쌍한 중앙 QA팀 5명이 불량품을 다 걸러내느라(데이터 정제) 공장 출고가 막혔습니다. 데이터 메시는 중앙 QA팀을 없애버리고, "부품 만든 너희 100명이 각자 100% 품질 검사(도메인 책임) 끝내고 라벨 붙여서 컨베이어에 올려라!"라고 생산자에게 독박 책임을 묻는 극강의 품질 분권화입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

데이터 메시를 떠받치는 4대 핵심 원칙 (Zhamak 헌법)

면접과 실무를 관통하는 데이터 메시의 절대 철학 4가지. 하나라도 없으면 그냥 가짜 메시다.

1. 도메인 지향 데이터 소유권 (Domain-oriented Decentralized Data Ownership)
   • 중앙 데이터팀(Data Engineer)이 데이터를 소유하지 않는다.
   • 결제 도메인 팀(결제 백엔드 개발자)이 자기가 만든 결제 데이터를 가장 잘 아니, 그 데이터를 분석용으로 정제(Clean)해서 내어주는 것까지 그 팀의 KPI(책임)로 삼는다.
2. 데이터를 상품으로 취급 (Data as a Product) 👑
   • 결제팀이 "어 걍 DB 덤프 떠서 S3 폴더에 던져놨으니 니들이 퍼가셈 ㅋ" 하는 건 쓰레기 투척이다.
   • 결제팀은 데이터를 **하나의 훌륭한 완제품 API(상품)**처럼 포장해야 한다. 메타데이터 빵빵하게 적고, 버전(V1, V2) 쾅 찍고, 다른 팀(마케팅/AI) 유저들이 1초 만에 검색해서(Discoverable) 보안 승인받고 가져다 쓸 수 있게 고퀄리티 마트를 열어줘야 한다.
3. 셀프 서브 데이터 인프라 플랫폼 (Self-serve Data Infrastructure)
   • 1번, 2번 하라고 결제팀 백엔드 개발자한테 떠넘기면 폭동(퇴사)이 일어난다. "내가 언제 스파크(Spark)랑 에어플로우(Airflow) 데이터 파이프라인 인프라까지 짜라 그랬어!"
   • 플랫폼 인프라 팀은 굽신거리며 **"그냥 SQL이나 설정 파일 1줄만 치면 알아서 S3에 정제 폴더 파지고 파이프라인 뚫리는 미친 마법의 자동화 인프라 플랫폼(PaaS)"**을 닦아 바쳐야 한다. 백엔드 팀은 딸깍! 버튼 하나로 자기 데이터를 상품으로 올린다.
4. 연합 컴퓨테이셔널 거버넌스 (Federated Computational Governance)
   • 탈중앙화로 찢어놨더니, 결제팀은 JSON으로 쏘고 배송팀은 CSV로 쏘고 날짜 포맷도 다르면 파멸이다.
   • 중앙 연합 위원회(보안팀+도메인 짱들)를 하나 파서, "우리 회사 데이터 규격은 무조건 날짜 YYYY-MM-DD고, 암호화 표준 지켜라!"라고 헌법(Governance)만 딱 정해준다. 그리고 이 룰을 사람이 검사하는 게 아니라 인프라 코드 레벨(Computational)에서 자동 필터링 되도록 강제 통제한다.

• 📢 섹션 요약 비유: 이 4가지 원칙은 **'아이폰 앱스토어(App Store) 생태계'**와 같습니다. 옛날 애플이 모든 앱을 혼자 다 만들려니 죽어났죠(중앙 집중). 그래서 애플은 **'쉬운 개발 툴(셀프 서브 인프라)'**과 **'엄격한 심사 규칙(거버넌스)'**만 쫙 깔아줬습니다. 그리고 수만 명의 쩌는 개발자(도메인 팀)들이 자발적으로 자기들이 제일 잘 아는 멋진 앱(Data Product)을 만들어서 상점에 올렸습니다. 소비자들은 그걸 쇼핑하듯 다운받아(결합/분석) 쓰며 거대한 구글/애플 생태계가 천하를 통일했습니다. 이것이 데이터 메시의 본질입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 데이터 아키텍처 삼국지 (Warehouse vs Lake vs Mesh)

과목 융합 관점

• 소프트웨어 공학 (MSA / DDD 조직의 데이터적 연장선): 아키텍처의 혁명은 언제나 콘웨이의 법칙(조직 찢기)에서 온다. MSA(532장)로 백엔드 소스코드를 50개 팀으로 찢어 각자의 캡슐화된 로직(Decoupling)을 완성했다 쳐보자. 그런데 정작 통계 뽑을 땐 50개 팀의 DB를 빨대 꽂아 통째로 S3 하나에 다 털어 넣고(Data Lake) 중앙팀이 뚱뚱한 스파게티 쿼리를 짜고 있었다! (분석용 분산 모놀리스의 부활). 데이터 메시는 "야! 백엔드 코드만 찢으면 뭐 하냐! 통계/분석용 데이터 저장고와 파이프라인(ETL)도 똑같이 50개 팀으로 잘게 썰어서 넘겨라!"라는 MSA 철학의 무자비하고도 완벽한 빅데이터 세계관으로의 수직 팽창 수술이다.

• 클라우드 / 데브옵스 (API Gateway와 Data Catalog 융합): 데이터 메시는 50개 팀이 흩어져서 자기 물건을 파는 거대한 플리마켓(시장)이다. 마케팅팀이 "어? 배송 늦어진 사람한테 쿠폰 쏘게 데이터 좀 줘!" 하려는데 배송팀 데이터를 어디서 찾지? 아키텍트는 반드시 전사 데이터 카탈로그(Data Catalog - ex. Amundsen, AWS Glue Catalog) 포털 사이트를 하나 파야 한다. 마케팅팀이 구글 검색하듯 "배송" 검색하면 배송팀이 예쁘게 깎아 올린 최상급 데이터(API 주소, S3 경로)가 1초 만에 뜨고 승인 버튼을 누를 수 있는 융합 포털이 없으면 데이터 메시는 그저 찢어진 파편들의 쓰레기장으로 전락한다.

• 📢 섹션 요약 비유: 데이터 레이크는 100명의 주방장(도메인 팀)이 만든 요리를 **'하나의 거대한 개밥그릇(S3)'**에 싹 다 들이부어 섞어놓고, 손님(분석가)한테 "맛있는 거 찾아 드세요~" 하는 미친 비빔밥입니다. 데이터 메시는 100명의 주방장이 자기 요리를 **'최고급 뷔페의 100개 은쟁반(Data Product)'**에 이름표와 알러지 성분(메타데이터)을 깔끔하게 써서 진열해 두는 것입니다. 손님은 개밥그릇을 뒤질 필요 없이 우아하게 접시를 들고 돌아다니며 입맛대로 조합(연합 분석)해 먹는 미학입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 중앙 파이프라인(ETL) 폭파와 '병목(Bottleneck)' 부서의 파업: 대형 이커머스에서 빅데이터 분석팀(중앙) 5명이 전사 100개 백엔드 DB의 데이터를 밤마다 빨대로 빨아와 스파크(Spark)로 뭉개서 통계를 냈다. 어느 날 주문팀(백엔드)이 자기들 맘대로 DB 컬럼 이름 order_stat을 status_code로 바꿨다. 그날 밤, 중앙 분석팀의 스파크 코드가 파싱 에러를 뿜으며 터졌고 전사 CEO 아침 보고용 대시보드가 하얗게 날아갔다! 백엔드 팀은 "우린 앱 잘 돌아가는데? 니들 중앙 파이프라인 터진 걸 왜 우리한테 따져 ㅋ" 책임 회피가 터지며 회사 내전이 일어났다.

   • 아키텍트의 해결책: 데이터 소유권과 스키마 유지 의무를 생산자(백엔드 도메인)의 목줄에 묶는 데이터 메시 강제 이관이다. "중앙에서 빨대로 빨아가는 짓(Pull)"을 원천 금지한다! 아키텍트는 주문팀 백엔드 팀장에게 헌법을 하달한다. "너네가 만든 데이터니까, 니들이 분석하기 좋게 깎아서 매일 밤 Data Product 상점(S3+카탈로그)에 진열(Push)해라! 컬럼 이름 맘대로 바꿔서 상점 박살 나면 CEO한테 니들이 시말서 써!" 뼈아픈 책임의 이전(Shift)이다. 도메인 전문가는 자기 데이터의 스키마 변경을 가장 먼저 알기 때문에, 앱 코드를 수정할 때 데이터 진열용 파이프라인 코드도 한 방에 수정(버전업)하여 파업과 병목의 고리를 원천 차단하는 궁극의 조직 개편 마술이다.

2. 시나리오 — 백엔드 개발자들의 반란, "우리가 왜 데이터 엔지니어링 똥을 치워야 해?!": 아키텍트가 데이터 메시 한다고 선언했다. 결제팀 Java 스프링 개발자 5명한테 "앞으로 결제 로그 1억 건 Spark로 뭉개서 파케이(Parquet) 파일로 구운 다음 Data Product로 올려놔라!" 오더를 내렸다. 자바 개발자들이 폭동을 일으켰다. "내가 파이썬이랑 하둡/스파크 1도 모르는데 그딴 파이프라인을 언제 짜고 앉아있어! 다 퇴사할게 ㅂㅂ"

   • 아키텍트의 해결책: No-Code 셀프 서브 데이터 플랫폼(Self-serve Platform) 융합의 무적 방어선 구축이다. Zhamak 헌법 제3조다. 백엔드 개발자에게 생짜 하둡(Hadoop) 던져주면 망한다. 전사 인프라 플랫폼 팀이 미친 듯이 굴러서 포털 사이트를 하나 파준다. 자바 개발자가 포털에 들어가서 [내 오라클 DB 주소 입력] ➡ [숨기고 싶은 컬럼 체크박스 해제] ➡ [배포 버튼 딸깍!] 하면, 백그라운드 인프라 엔진(Debezium + Airflow + S3)이 알아서 빙글빙글 돌며 그 자바 개발자의 이름으로 완벽한 Data Product를 매일 새벽에 구워내 상점에 전시해 줘야 한다. 백엔드 개발자가 파이프라인 로직 1줄 안 짜고도 데이터 주인이 되게 만드는 플랫폼 인프라의 희생이 없으면 데이터 메시는 허상에 불과하다.

도입 체크리스트

• 조직적: "회사 내에 마이크로서비스(MSA)를 도입할 정도로 독립적이고 짱짱한 도메인별 '크로스펑셔널(Cross-functional) 팀'이 구축되어 있는가?" 데이터 메시는 기술이 아니라 "조직 문화"다. 만약 회사에 "우리 팀은 백엔드만 쳐요 ㅋ 데이터는 DB 팀이 알아서 하겠지" 마인드가 팽배한 SI 하청 구조의 사일로(Silo) 기업이라면 데이터 메시 도입하는 날 회사가 두 동강 난다. 넷플릭스나 토스처럼, 한 팀 안에 기획자+백엔드+데이터+프론트엔드가 한 몸으로 뭉쳐 "우리 도메인은 우리가 100% 왕이다!"라는 독립 왕국 사상이 뿌리 깊게 박힌 초거대 조직에서만 10,000%의 시너지가 폭발한다.
• 비즈니스적: 중앙 병목(Bottleneck)으로 인한 기회비용 손실이 큰가? 중앙 데이터팀 3명이 10개 팀 통계를 뽑아주는데 2~3일이면 착착 다 뽑아주는 아기자기한 스타트업이라면? 굳이 메시 할 필요 없다. 100개 도메인 팀이 매일 미친 듯이 "이 데이터 줘! 저 통계 줘!" 10,000개의 티켓을 던져대서, 중앙 분석팀이 과부하로 뻗어 신규 비즈니스 런칭이 3달씩 막혀 썩어 들어가는 대기업의 지옥도가 펼쳐졌을 때, 도끼로 중앙 통제실을 박살 내고 소유권을 분산시켜야 생존할 수 있다.

안티패턴

• "데이터 거버넌스(Governance) 없이 무지성 찢기 파티로 방치하기": 탈중앙화 뽕에 취해서 각 부서에 알아서 S3 파일 파서 올리라고 냅뒀다. 결제팀은 유저 아이디를 usr_id (문자열)로 올리고, 배송팀은 UserID (숫자)로 올리고, 마케팅팀은 CSV로 올렸다. 전사 CEO 대시보드 만들려던 개발자가 3개 폴더를 JOIN 하려다가 포맷이 개판이라 에러 터지고 퇴사했다. "데이터 메시는 무정부주의(Anarchy)가 아니다! 중앙 연합 위원회가 반드시 '전사 날짜 포맷은 YYYY-MM, 필드 카멜케이스 통일, 주민번호 암호화 필수!'라는 강력한 표준(Standard) 헌법을 세우고, 이 규격을 안 지킨 데이터 상품(Product)은 인프라 봇이 검사해 아예 상점에 진열조차 못 하게 컷(Deny)해버리는 철통 거버넌스가 결합해야만 우주적 융합 분석이 성립된다."

• 📢 섹션 요약 비유: 거버넌스 없는 데이터 메시는, 전 세계 100개국 사람들이 **'통역기 없이 한 방에 모여서 각자 자기 나라 말로 미친 듯이 소리치는 난장판 회의(분산)'**와 같습니다. 아무도 서로의 말을 이해(조인/통계)할 수 없습니다. 데이터 메시의 연합 거버넌스는 이 방의 입장 규칙입니다. "자기 나라 말로 자유롭게 발표하되, 반드시 '영어(전사 표준 데이터 포맷)' 자막을 밑에 예쁘게 달아서(Governance) 단상에 올라와라!"라는 철칙 덕분에, 수백 개 팀의 지식이 하나의 거대한 지혜(AI 통계)로 1초 만에 매끄럽게 엮여 들어가는 통제된 자유의 쾌감입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Data Fabric (데이터 패브릭)과의 융합과 상호 보완: 데이터 메시는 "사람과 조직"을 찢어놓는 철학(Sociotechnical)이고, 데이터 패브릭은 낡고 분산된 수천 개의 DB를 중앙 AI가 거미줄처럼 엮어 물리적인 1개의 거대 통짜 뷰(View)로 보여주는 "기술 인프라" 솔루션이다. 아키텍트들은 조직적으로는 각 팀이 자기 앞마당을 챙기는 메시(Mesh) 철학을 들이부으면서, 밑단 인프라는 AI 엔진이 100개 부서의 분산 DB를 1초 만에 매핑해 엮어주는 패브릭(Fabric) 기술을 도입하여, 철학과 기술의 빈틈없는 이중결합 차세대 메타-아키텍처를 완성해 나가고 있다.
• AI 딥러닝 팩토리의 무제한 탄약 보급소: 챗GPT, 거대 언어 모델(LLM) 부서가 죽어나가는 이유는 "학습할 깨끗한 고품질 데이터가 없어서"다. 쓰레기 레이크에서 똥물 핥아먹던 AI 부서에게, 데이터 메시는 천국이다. 50개 도메인 부서의 1티어 전문가들이 자기 이름을 걸고 먼지 하나 없이 깨끗하게 깎아놓은 다이아몬드(Data Product) 수백 개가 S3 상점에 상시 진열되어 있다. AI 연구원은 그냥 카탈로그 쇼핑하듯 빨대만 꽂으면 극강의 품질을 가진 학습 데이터가 파이프라인 딜레이 0초로 쏟아져 들어오는 무한 탄약 보급의 시대가 활짝 열렸다.

참고 표준

• Zhamak Dehghani의 Data Mesh 논문: 소프트웨어 아키텍처 씬에 MSA와 DDD가 있다면, 빅데이터 씬에는 이 영광의 논문이 패러다임을 통째로 갈아엎었다. "데이터 파이프라인의 모놀리스(Data Lake)를 부수고 조직의 도메인(Domain)에 권력을 이양하라!"
• Data as a Product (DaaP): 데이터를 단순한 부산물(로그 쓰레기)이 아니라, 외부에 돈 받고 팔아도 손색없을 수준의 API 퀄리티, 메타데이터, 버전 관리를 갖춘 "상품"으로 빚어내라는 데이터 메시 헌법 제2조.

데이터 메시 (Data Mesh)는 소프트웨어 공학이 도달한 **'마이크로서비스 아키텍처(MSA)의 거룩한 탈중앙화 불길이, 차갑고 비대하게 굳어있던 중앙 데이터 레이크(Data Lake)의 심장부까지 태워버린 가장 위대한 수직(Vertical) 영토 확장'**이다. 우리는 과거 10년 동안 백엔드 코드와 DB를 50개 부서로 예쁘게 찢어 무한한 속도의 날개를 달았으면서도, 정작 회사의 운명을 가르는 '데이터 분석과 통계'는 또다시 낡은 파이프라인을 통해 거대한 중앙의 쓰레기 늪(모놀리스)으로 들이부으며 스스로 목줄을 조였다. 데이터를 만든 사람(도메인 팀)과 데이터를 치우는 사람(중앙 팀), 그리고 데이터를 써먹는 사람(분석가)이 3동강 나버린 그 침묵의 사일로 속에서 회사의 혁신은 썩어 들어갔다. 자막 데가니(Zhamak Dehghani)는 도끼를 들어 이 거대한 중앙 하수처리장을 내리쳤다. "네가 만든 결제 똥은, 네가 예쁘게 포장해서 황금(Product)으로 만들어 진열해라!" 이 잔혹하고도 아름다운 '도메인 책임제' 선언. 이제 50개의 팀은 50개의 빛나는 데이터 마트를 차려놓고 뷔페를 연다. 누군가 내 데이터에 빨대를 꽂아 1초 만에 새로운 AI 모델을 창조하고 수백억의 가치를 뽑아내는 거대한 연쇄 폭발(Network Effect)의 소용돌이. 찢어져 있기에 한없이 가볍고, 얽매이지 않기에 우주처럼 무한히 팽창하는 진정한 분산 데이터 제국의 절대 헌장이다.

• 📢 섹션 요약 비유: 데이터 레이크가 100가구의 마을 사람들이 강가 한 곳(중앙)에 무지성으로 **빨래, 식수, 쓰레기를 다 쏟아부어 놓고, 이장님 혼자서 뜰채로 정수기 돌리며 땀 빼는 지옥(중앙 집중 병목)**이라면, 데이터 메시는 100가구 집집마다 **최고급 정수기와 분리수거 통을 놔주고 "니들 똥물은 니들 집에서 100% 1급수 생수로 정화해서(Data Product) 마을 공동 상점(카탈로그)에 예쁘게 포장해서 내놔라!"**라고 통치하는 각개전투 시스템입니다. 이장님(중앙팀)은 노가다를 멈추고, 오직 "물통은 투명한 500ml 페트병만 써라!(Governance)" 규칙만 감시합니다. 마을 전체가 1급수 마법의 생수를 기다림 1초 없이 콸콸 마셔대는 혁명의 시작입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 학교 도서관(데이터 레이크)에 100명의 친구가 자기가 읽은 책들을 대충 아무렇게나 섞어서 바닥에 휙 버려두고 갔어요. 사서 선생님(중앙 데이터팀) 혼자서 그 산더미를 예쁘게 정리하느라 매일 코피를 쏟고 쓰러졌죠 ㅠㅠ (파이프라인 병목 폭발!).
2. 그래서 교장 선생님이 규칙을 싹 바꿨어요! "얘들아! 자기가 읽은 책은 무조건 자기가 먼지를 털고 예쁜 책 커버를 씌워서(데이터 상품화) 자기 반 교실(도메인) 앞 진열장에 이름표 달아 전시해 놔!" (데이터 메시)
3. 이제 사서 선생님은 책 정리를 안 해도 돼요! 친구들이 다른 반 진열장에 가서 예쁘게 꽂혀있는 멋진 책을 1초 만에 쏙쏙 골라 빌려보는 짱 똑똑하고 안 기다려도 되는 마법의 분산 도서관 시스템을 '데이터 메시'라고 부른답니다!