국내 원자력발전소(이하 ‘원전’)에서 불량 부품이 사용됐다는 보도는 섬뜩했다. “모조품 사용 원전이 두 군데나 된다”는 소식을 자세히 살펴보니 해당 부품은 아직 전산화되지 않은 업무와 관련돼 있었다. 업무와 부품 간 관계에 대한 시각은 여러 가지가 있을 수 있다. 컴퓨터 전문가는 업무를 컴퓨터 프로그램으로, 부품을 데이터로 각각 인식한다. 컴퓨터 프로그램을 누구나 쉽게 이해하긴 힘들겠지만 스마트폰용 애플리케이션 같은 게 프로그램의 대표적 유형이라고 보면 된다.

프로그램은 짧고 데이터는 길다

프로그램은 데이터를 사용하는 주체이고 데이터는 프로그램에 의해 철저히 이용 당하는 존재다. 네트워크 상에선 이동하는 물건이 많으므로 시스템 전반의 성능 극대화를 감안하면 ‘덩치 작은 존재가 민첩하게 이동하는’ 편이 유리할 것이다. 이렇게 볼 때 데이터는 큰 몸집 때문에 정해진 장소에 무게 잡고 있는 반면, 프로그램은 심부름꾼처럼 이리저리 분주하게 장소를 옮겨 다니며 크고 작은 작업을 수행한다. 그래서 흔히 데이터와 프로그램 간 관계를 묘사할 때 (‘인생은 짧고 예술은 길다’는 말에 빗대) ‘프로그램은 짧고 데이터는 길다’고 한다.

컴퓨터 프로그램은 가장 긴 게 5000만 줄(行) 정도다. 보통 운영체계(OS)가 그렇다. 이에 비해 데이터는 대기업을 기준으로 했을 때 길면 10의 15제곱 줄, 즉 수천 조 줄에 이를 정도로 그 규모가 방대하다. 기업은 이 같은 데이터를 먹고 사는 생명체라고 할 수 있다.

기업은 업무 단위로 돌아가며, 업무는 영업 행위들의 집합이다. 선·후행 순서에 입각해 구성된 행위들의 집단이 기업 단위 업무를 형성하며, 이런 행위가 건드리는 ‘무엇’이 바로 데이터다. 업무 행위가 바로 프로그램 역할을 하며, 일단 전산화되면 모든 업무 행위는 컴퓨터 프로그램으로 바뀌는 것이다. 그래서 업무와 데이터 간 관계는 어떤 방식으로든 표현돼야 하며, 가장 이상적으로 표현해놓은 형태가 ‘업무(직무)기술서’ 혹은 ‘업무 매뉴얼(job description)’이다.

크고 작은 사건 사고를 당할 때마다 그 원인으로 ‘매뉴얼 부재(不在)’가 꼽히곤 한다. 기업도 마찬가지다. 제대로 된 업무 매뉴얼을 갖춘 기업을 찾기란 여간 어려운 일이 아니다. 무늬만 매뉴얼일 뿐, 실제 내용을 들여다보면 형편없는 작품을 매뉴얼이라고 제작해놓았다가 막상 일이 터진 후에야 한탄하는 행태가 매번 반복된다.

프로그램은 어디까지나 데이터를 처리하는 ‘조연’에 불과하다. 데이터가 프로그램을 처리하는 경우란 애당초 있을 수도 없다. 프로그램은 데이터를 생성해 어딘가에 저장하고, 저장된 걸 필요 시 검색하거나 수정·갱신하는 역할을 맡을 뿐이다. 따라서 기업 데이터가 아직 전산화되지 않았다는 얘긴 처음부터 데이터가 컴퓨터에 들어간 적이 없고, 따라서 데이터 조작 프로그램조차 만들어진 일이 없다는 뜻이 된다. 원전에선 데이터 심층 분석을 통해 매출 확대를 꾀하는 식의 일반 기업 관심사에 별다른 관심이 없을 테니 전산화 속도가 다소 늦은 것도 이해할 수 있다. 하지만 비전산화의 그늘에선 부정과 부재가 얼마든지 존재할 수 있다. 가장 큰 원인은 데이터에 대한 주인의식 부족이다. 이때 주인의식은 조직 내 특정인을 가리키지 않는다. 조직 구성원 모두가 데이터에 대해 주인의식을 공유하는 걸 의미한다.

‘데이터 설계 아웃소싱’은 안 될 일

여기저기서 ‘빅데이터(big data)’를 얘기한다. 혹자는 ‘데이터 범람 시대’라고도 한다. 여기서 말하는 데이터란 모두 이미 전산화된 데이터를 지칭한다. 전산화됐다 해도 방심은 금물이다. 일명 ‘신(新)정보시스템’ 혹은 ‘차세대 정보시스템’ 구축 시 위험이 도사리고 있다. 이를 극명하게 보여주는 중대 사건이 몇 년 전 미국 공군에서 발생했다. 아웃소싱(outsourcing) 시류에 편승, 데이터 모델링 같은 중대한 초반 과업을 외주 업체에 무분별하게 맡겨버린 게 화근이었다. 이 사고로 6년간 줄기차게 추진해온 공군 내 신정보시스템은 ‘밑 빠진 독’이 돼버렸다. 1조 원이나 되는 거액이 제대로 쓰이지도 못한 채 하수구에 처박혀졌다.

이 사고는 ‘데이터 설계는 어떤 경우에도 아웃소싱해선 안 된다’는 교훈을 극명하게 보여줬다. 데이터 설계가 성공리에 종료되면 그 후속 작업으로 설계도에 따라 시공하는 일, 다시 말해 프로그램을 구현하는 일은 100% 아웃소싱해도 무방하다. 하지만 데이터 설계 부분까지 아웃소싱한 실책이 불러온 파장은 걷잡을 수 없이 컸다. 이 대목에선 우리 기업들도 정신을 바짝 차려야 한다. 국내 역시 외주 관행이 만연해 있는 게 현실이기 때문이다.

아웃소싱은 단순 업무, 이를테면 전화 응대처럼 난이도가 낮은 업무를 외부 업체에 위탁할 때나 사용하는 말이다. 중차대한 기업 업무를 외주로 맡기는 데 사용하는 말은 원래부터 아니었다. 데이터 설계나 기업 보안, 고객 정보 보호 같은 업무가 여기에 해당한다. 이런 업무 영역까지 아웃소싱하게 될 경우, ‘고양이에게 생선 가게를 맡기는’ 꼴을 벗기 어렵다. 한 나라로 치면 국방 같은 중대사를 다른 나라에 맡기는 것과 다를 게 없다.

이 글을 읽는 이 중 일부는 “이미 관행처럼 굳어진 아웃소싱 행태를 이제 와서 어떻게 고치나”라며 반문할 것이다. 하지만 아무리 관행처럼 굳어진 전통이라 해도 기업의 생사를 판가름할 수 있을 정도로 중대한 사안이라면 단번에 바로잡을 수 있는 용기가 필요하다. 기업이 ‘데이터를 먹고 사는 생명체’로 살아남기 위해서라도 이런 용기는 필수적이다. ‘지금은 데이터 시대’란 진리를 가볍게 여기는 일이 더 이상 반복돼선 안 된다. 이렇게 간단찮은 일을 과연 누가 해낼 수 있을까? 데이터의 역할이 날로 중요해지는 지금이야말로 기업이 최고 데이터 관리자(Chief Data Officer) 제도를 본격적으로 도입해야 할 때가 아닌가 생각한다.

※ 이 칼럼은 전문가 필진의 의견으로 삼성전자의 입장이나 전략을 담고 있지 않습니다.

“그건 기본을 지키지 않아 그래.” 살다보면 종종 이런 말을 하고 또 듣는다. 무슨 일이든 기본 철칙을 도외시하면 아무리 많은 시간과 노력을 들였다 해도 해당 분야 전문가에게서 좋은 평가를 받기 어렵다. 제대로 된 전문가는 매사 ‘결과’보다 ‘과정’을 중시한다. 설령 결과물이 훌륭해 보여도 절차상 하자가 있다면 쓸모없는 가치에 불과하다. 소비자 호평도 기대하기 어렵다. 소비자는 비록 비전문가이지만 어떤 게 좋고 나쁜지 직관적으로 안다. ‘내 돈 내고 받는 재화(서비스)’인 만큼 대충, 어설프게 넘어가는 경우는 드물기 때문이다.

좋은 설계도 VS. 나쁜 설계도

기업 데이터를 설계할 때도 마찬가지다. 설계 담당자(이하 ‘설계자’)가 아무리 열심히 노력했다 해도 전문가 평가는 호의적이지 않은 경우가 허다하다. 예를 들어보자. 대부분의 기업은 인사 업무 관련 데이터를 설계할 때 “인사 부서가 직원에게 급여를 지급한다”는 매뉴얼 내용을 기준으로 <그림1> 혹은 <그림2>와 같은 데이터 설계도를 만든다. 하지만 둘 다 명백한 ‘수준 미달 설계’다. 하지만 도표를 접한 설계자 대다수는 고개를 갸웃거릴 것이다. ‘아니, 뭐가 잘못됐다는 거지? 다들 그렇게 하고 있잖아. 누군가 내게 같은 설계를 부탁해도 다르지 않을 것 같은데….’

위 두 그림은 모양만 보면 설계도가 맞지만 수준은 ‘유치원생급’이란 평가를 피하기 어렵다. 가장 큰 문제는 결과 표현에 급급해 과정이 생략된 것이다. 설계도의 완성도를 높이려면 급여가 그렇게 지급돼야만 하는 연유와 내막이 설계도 내에 드러나 있어야 한다. ‘급여 지급’의 주제가 인사 부서인 건 누구나 알고 있지만 그에 앞서 지급 행위를 구성하는 세부 원인 행위가 구체적으로 하나씩 규명돼야 한다는 얘기다. 이 과정이 설계도상에 가시적으로 표현되지 않으면 설계자와 관찰자 간 소통은 사실상 불가능하다.

관찰자가 설계도에 깔려 있는 배경과 사상을 이해할 길이 없다면 그 설계도는 실패작일 수밖에 없다. 따라서 위 그림 속 설계도가 설계도답게 구성되려면 급여 지급에 선행되는 행위, 이를테면 ‘출장’ ‘교육’ ‘강의’ ‘휴가’ 등이 설계도에 구현돼야 한다. 그런 다음, (최종 행위로서의) ‘지급’을 설계도 내에 나타내야 비로소 앞뒤가 들어맞는다.

데이터 설계에도 ‘소통’이 필요해

제대로 된 데이터란 관찰자가 객관적 시각으로 들여다봤을 때 설계 도중 설계자의 머릿속이 읽히는 데이터다. 이때 ‘제대로’는 ‘수준 미달을 겨우 면한 정도’를 뜻한다. 과정과 절차가 무시된 ‘결과 중심 설계’는 참담한 실패를 불러올 뿐이다. 설계 사상과 철학의 핵심인 ‘원인-결과 상호 대응관계’가 관찰자에 의해 정확하게 읽히지 못한다면 그건 설계도가 아니라 무의미한 추상화에 불과하다. 그런 설계도라면 나중에도 쓸모를 찾기 어려워지므로 처음부터 공 들여 제작할 가치도, 추후 정보 시스템 개발 결과물로 유지하거나 보수할 가치도 없다.

좋은 설계도엔 ‘소통’이 존재한다. 단, 여기서의 소통은 언제나 ‘쌍방향’적이어야 한다. 관찰자도, 설계자도 상대가 어떤 배경과 의도로 논리를 펼치고 있는지 소상히 알 수 있어야 한다는 뜻이다. 소통 가능한 데이터 설계도의 제작 여부는 순전히 설계자의 마음가짐에 달려 있다. “학교에서 배운 적이 없어서” “직장에 들어온 후 내게 설계 방법을 가르쳐준 선배가 없어서”란 말은 한낱 변명일 뿐이다. 요행히 과정과 절차를 중시하는 전문가를 만나 제대로 된 설계법을 배울 수도 있을 것이다. 하지만 본인의 노력만으로도 결과를 중시하는 현행 기업 관행을 충분히 개선할 수 있다. 설계자 스스로 몇 차례 시행착오만 거치면 누구나 완수할 수 있는 임무란 얘기다.

기업 정보 시스템이 생명력을 발휘하려면 데이터 설계 분야에서 “혼자서도 완성도 높은 설계도 제작에 도전해보겠다”는 작은 영웅들이 기업마다 넘쳐나야 한다. 자체적 데이터 설계 능력은 빅데이터 시대에 기업이 살아남기 위한 핵심 역량이다. 이제껏 그래왔듯 위탁 업체에 맡겨버리면 되는 것 아니냐고? 그런 생각은 본인 소유 기업의 빅데이터를 거대한 쓰레기 더미로 만드는 ‘자포자기 선언’이나 다름없다.

※ 이 칼럼은 전문가 필진의 의견으로 삼성전자의 입장이나 전략을 담고 있지 않습니다.

5년 전 스페인을 여행하며 거리에 비만인 사람들이 적잖은 걸 보고 깜짝 놀란 기억이 있다. 장소가 스페인이 아니라 미국이었다면 그다지 놀라지 않았겠지만 불과 20년 전만 해도 스페인 사람들은 어디서나 날씬한 모습이었기 때문에 충격이 더욱 컸다. 미국은 20년 전이나 지금이나 비만이 심각한 사회 문제 중 하나다. 우리나라도 미국이나 스페인보다 사정이 낫긴 하지만 비만 문제가 조금씩 대두되기 시작했다.

중복 데이터 많아야 검색 속도 빨라진다?

데이터도 신체와 마찬가지로 ‘비만’ 증세를 겪는다. 특히 기업 데이터 비만 문제는 신체적 비만 못지않게 심각한 문제를 야기할 수 있어 주의가 요구된다. 기업 데이터 비만이란 기업 데이터베이스 내 저장 데이터에 중복이 존재하는 현상을 일컫는다. 국내 기업을 기준으로 했을 때 평균 중복률은 65%, 그중 50% 이상이 ‘쓸데없는 중복’이다(나머지 15%가량의 중복은 현행 데이터베이스 기술이 지니는 불가피한 한계로 인한 중복이다). 전체 데이터베이스의 절반 이상이 ‘악성 중복’인 셈이니 보통 심각한 문제가 아니다.

국내 기업의 데이터 비만 문제가 이렇게 심각한 건 ‘중복에 대한 무조건적 맹신과 환상’ 때문이다. 흔히 ‘데이터를 중복시켜놓아야 관련 데이터를 보다 빨리 검색할 수 있다’고 여긴다. 부주의한 이들의 그릇된 통념이다. 그러다 보니 동일한 데이터, 예를 들면 ‘고객 성명’이 많게는 수백 군데에 나타나도록 허용된다. 만약 동일 데이터가 300개 지점에서 발견됐다면 그중 299개는 중복이란 얘기고, 이 경우 중복률(299/300*100)은 약 99.7%다.

데이터베이스 내에 ‘고객 성명’ 같은 속성급 데이터의 가짓수가 5000개 존재한다고 가정해보자. 5000개의 속성별 중복 빈도를 계산해 이들을 합산한 다음, 그 결과를 다시 속성 전체 수 5000으로 나누면 해당 데이터베이스의 전체 평균 데이터 중복률이 나온다. 이 수치가 바로 데이터 비만도다.

체중이 늘어나면 몸은 무거워지지만 순간적 폭발력은 증가한다. 데이터 세계에서도 마찬가지다. 데이터 중복을 일부 허용하면 일시적으로 검색 속도가 상당히 빨라진 것처럼 보인다. 실제로 기업 데이터베이스 내 데이터 중복률이 15% 이하를 유지한다면 전혀 문제 될 게 없다. 42.195㎞를 뛰어야 하는 마라토너도 체지방율이 15%는 된다는 점을 떠올려보면 이해가 빠를 것이다.

‘느린 속도’보다 무서운 건 ‘잘못된 결과’

기업 데이터 중복률이 30% 이하로 유지될 땐 그런대로 적정 속도와 품질을 유지하며 제 몫을 해낼 수 있다. 하지만 30%를 훌쩍 넘겨 60% 이상까지 높아진다면 그 결과가 얼마나 끔찍할지 짐작조차 할 수 없다. 이때 30%는 데이터 테이블 구조가 (가장 저급한 수준인) ‘제1표준형’으로 설계됐을 때 허용되는 최대 중복률 수치다. 제1표준형은 데이터베이스 내 각각의 데이터 테이블이 갖춰야 할 최소한의 요건을 말한다. 따라서 만약 어떤 데이터 테이블이 제1표준형 기준에도 못 미칠 경우, 해당 데이터 테이블을 보유한 데이터베이스는 데이터베이스로서의 자격이 없다. ‘데이터 중복률 30%’를 마지노선이라고 부르는 건 바로 그 때문이다.

데이터 중복률이 30%를 넘어서면 정보 검색 시 두 가지 오류가 발생할 수 있다. 해답 도출에 너무 오랜 시간이 걸리는 경우가 하나, 시간은 얼마 안 걸리지만 틀린 답이 나오는 경우가 다른 하나다. 어느 기업의 차장 A씨가 승진, 부장이 됐다고 가정해보자. 만약 이 기업 정보 시스템의 데이터 중복률이 30% 이상이라면 “오전에 검색했더니 부장, 오후에 검색하면 과장, 이튿날 검색하면 대리”처럼 어처구니없는 결과가 나올 수도 있다. 그런 일이 어떻게 가능하냐고 반문할 사람도 있겠지만 실제 기업에선 이와 비슷한 사태가 종종 발생한다. 3초 이내에 답을 내놓긴 해야겠고, 그러다 보니 ‘정확하지 않은 값이라도 일단 출력하고 보자’는 관행이 이 같은 불상사를 초래하는 것이다. 데이터 중복이 불러일으키는 ‘무서운 역습’인 셈이다.

데이터 비만이 야기하는 폐단은 생각보다 심각하다. 우선 정확한 답이 나오기까지 시간이 너무 많이 걸린다. 미국 뱅크오브아메리카(BoA)가 규정하고 있는 ‘3초의 법칙’을 떠올려보면 재앙에 가까운 수준이다. ‘빠르지만 엉터리인’ 답을 내놓는 경우도 속도 실패 못지않게 참담하다. 그런데도 “그냥 있는 대로 쓰지”라고 체념한다면, 그리고 그렇게 결정하는 주체가 내로라하는 기업이라면 어떤 일이 벌어질까?

기업 데이터 ‘군살’ 제거, 3개월이면 충분

지난 20여 년간 기업 현장을 돌며 데이터베이스 현황을 관찰했다. 대부분의 국내 기업이 65% 이상의 데이터 비만도를 기록 중이란 사실만큼이나 놀랐던 건 언젠가부터 기업들이 ‘데이터 설계상의 하자에 따른 정보 처리 속도 저하’를 ‘하드웨어 성능 한계’로 둔갑시키는 지혜(?)를 발휘하고 있다는 사실이었다. IT를 잘 모르는 경영진은 IT 담당 부서의 엉터리 설명을 수용할 수밖에 없다.

더 심각한 문제는 IT 업무 담당 인력들조차 ‘데이터 설계’에 관해선 학교에서도, 직장에서도 제대로 배워본 적이 없다는 사실이다. ‘현장(기업) 중심’으로 돌아가지 않는 학교 커리큘럼이 낳은 비극이다. 실제로 전산학과는 데이터베이스 프로그래밍 교육에 집중할 뿐, 기업 데이터 설계에 관해선 거의 다루지 않는다. 경영학과 역시 데이터 설계를 남의 일로만 취급한다. 경영정보학과에서도 데이터 설계 대신 엉뚱하게 ERP(Enterprise Resource Planning, 전사적 자원 관리) 같은 설계 ‘도구’ 사용법 교육에만 열중한다.

데이터 비만이 불러온 비극은 ‘최초 데이터 설계 오류’가 그 원인인 만큼 과감히 원점으로 돌아가 ‘이제부터라도 제대로 설계해보자’는 허심탄회한 자세로 대처하는 게 최선이다. 하지만 지레 실망할 필요는 없다. 수십 년간 축적돼온 데이터 비만 문제도 불과 수 개월이면 명쾌하게 풀 수 있는 기술적 해법이 반드시 존재하기 때문이다. 다만 궤변과 변명, 경영진을 향한 ‘거짓 설득’의 관행이 계속되는 기업은 외환 위기와 같은 부정적 외부 요인의 공격을 받는 순간, 오랜 세월 풍화된 고목마냥 단번에 쓰러져버릴 것이다.

조금이라도 앞을 내다볼 줄 아는 사람이라면 지금이라도 우리 기업의 데이터 비만도에 관심을 기울일 필요가 있다. 만약 측정 결과, 데이터 비만도가 30% 이상이라면 하루빨리 ‘군살’ 제거에 나서야 한다. 테이블 설계상 최상급인 동시에 가장 모범적인 수준으로 꼽히는 ‘제3표준형’이 허용하는 중복률은 15% 전후다. 어느 기업이든 이삼 개월이면 충분히 조직 데이터베이스의 데이터 비만도를 15% 선으로 낮출 수 있다. 그러니 ‘데이터 다이어트’에 관심 있는 기업이라면 두려워 말고 한 번쯤 용기 있게 도전해볼 일이다.

※ 이 칼럼은 전문가 필진의 의견으로 삼성전자의 입장이나 전략을 담고 있지 않습니다.

TV 다큐멘터리에서 아프리카 초원을 누비는 수컷 사자에 매혹된 적이 있다. 사람으로 치면 20대 초반쯤 됐을 그 사자의 균형 잡힌 몸은 절로 탄성을 자아내게 했다. 동물원에서 보던, 나이가 들 대로 든 사자의 몸과는 차원이 달랐다. 인간의 경우 ‘군살 없이 탄탄한 신체’의 극치는 마라톤 선수에게서 찾아볼 수 있다. 마라톤 선수의 체지방율은 대개 15% 선을 유지한다. 반면, 비만인 사람의 체지방율은 30%까지 치솟기도 한다.

‘꿈의 수치’ 15%를 사수하라

우연의 일치일까. 체지방율과 데이터 중복률은 이상하리만치 그 의미가 유사하다. 흔히 ‘데이터 비만도’라고도 불리는 데이터 중복률 계산법은 매우 간단하다. 어떤 데이터 속성(attribute)이 몇 군데 등장하는지 따지면 된다. ‘데이터 중복률 15%’는 데이터 설계를 가장 완벽하게 해냈을 때 얻을 수 있는 최적의 수치다.

15%가 ‘최선’인 이유는 데이터 테이블 설계 기술의 한계에서 찾을 수 있다. 데이터 모델링의 세계에서 최하 수준의 설계 산출물은 ‘1차 정규형’, 최고 수준의 설계 산출물은 ‘3차 정규형’이다. 전자의 데이터 중복률은 상당히 높아져 30% 선에 이른다. 사람으로 따지면 확실한 비만이다. 반면, 후자로 갈수록 해당 수치는 점차 낮아져 ‘마라톤 선수에 버금가는’ 15%에 가까워진다.

그렇다면 오늘날 기업이 보유하고 있는 데이터베이스 내 평균 데이터 중복률은 얼마나 될까? 놀랍게도 60% 이상이다. 40년 넘게 국내외 기업의 각종 대규모 데이터베이스를 현장에서 관찰하며 발굴해낸 ‘실질 수치’가 그렇다. 이런 얘길 들려주면 상대방은 대부분 “설마 그 정도겠어?”라며 반신반의한다. 하지만 데이터 모델을 설계해주는 소프트웨어 도구, 이를테면 ER윈(ER-Win)을 직접 한 번 돌려보면 누구라도 ‘데이터 중복률 60% 전후’ 수치 앞에 맞닥뜨리게 된다. 이 결과를 접한 이들의 반응은 크게 두 부류로 나뉜다. 놀람(“아니, 엉터리로 들어간 데이터가 이렇게 많았단 말이야?”)이 하나, 책망과 탄식(“해답을 빨리 내려고 일부 중복이 허용되는 줄은 알았지만 중복률이 이렇게나 높았다니!”)이 다른 하나다.

기업 데이터, 열 중 여섯은 ‘중복’

데이터 중복률이 60%란 말은 곧 ‘상당수 기업이 1차 정규형에도 훨씬 못 미치는 데이터 테이블 설계 산출물을 활용하고 있다’는 의미로 해석된다. 어째서 이런 현상이 빚어지게 됐을까? 첫 번째 원인은 난해한 정규형 이론에서 찾아야 한다. 60% 전후의 데이터 중복률을 야기시킨 데이터 테이블 설계자는 1차 정규형의 진정한 의미를 제대로 알지 못하는 사람이다.

이 대목에서 함께 풀어볼 문제가 하나 있다. “특정 데이터 테이블의 기본 키(primary key, 데이터 테이블 내 특정 열을 1차적으로 식별할 수 있는 키 필드) 속성이 다른 데이터 테이블에서 키가 아닌 속성(non-key attribute)으로 등장할 수 있을까?” 이 질문에 “그럴 수 있다”고 대답하는 사람은 1차 정규형의 의미조차 제대로 모르는 사람이다. 그리고 대다수 기업의 데이터 모델 설계 담당자가 이 질문을 받고 “그럴 수 있다”며 고개를 끄덕이는 게 딱하지만 엄연한 우리네 현실이다.

정규형 이론에 따르면 한 (데이터) 테이블의 기본기 속성을 다른 (데이터) 테이블에서 키가 아닌 속성으로 등장시키는 건 데이터에 관한 기초 상식조차 갖추지 못한 이들이 임의로 저지르는 ‘종신형급 실수’다. ‘큰 방죽도 개미구멍으로 무너진다’는 옛말은 데이터 설계에서도 유효하다. 이런 무지, 혹은 몰이해의 소치가 기업의 데이터 비만도를 60% 이상까지 끌어올린 주범이다.

이상화 선수에게서 배우는 ‘균형미’

문제의 심각성은 데이터 ‘비만도’에서 끝나지 않는다. 과다한 데이터 중복률은 최악의 경우, 데이터 설계의 균형을 송두리째 깨뜨려버린다. ‘데이터와 인체의 공통점’은 여기서도 고스란히 적용된다. 예를 들어 척추 고통의 경우, 직접 겪어보지 않은 사람은 헤아리기 어렵다. 좌우 균형 붕괴나 나쁜 자세 등 원인은 여럿이지만 일단 고통을 느끼기 시작하면 회복에까지 걸리는 시간은 한이 없다. 이상 증세를 치료하고 고통에서 벗어나려면 장거리 마라톤을 완주하듯 오랜 시간 인고의 과정을 겪어야 한다.

지난해 소치 동계올림픽 스피드 스케이팅 여자 500m 종목에서 금메달을 거머쥔 이상화 선수의 신체는 여러모로 놀랍다. 특히 허벅지 특정 지점에서 출발해 발 끝까지, 거기서 다시 양쪽 손 끝까지 이어지는 균형미는 대단하다. 기업 데이터베이스를 구성하는 ‘데이터 균형미’도 인체 균형미와 다르지 않다. 스포츠 경기든 데이터 검색이든 좌우 균형이 잘 갖춰져 있으면 최고 속도는 어렵잖게 발휘된다.

데이터 검색 시 최고 속도를 구현하려면 데이터 구성 시에도 균형미를 고려해야 한다. 어떤 데이터가 기준점이 되든 해당 데이터에서 좌우 종착점까지 가는 길이의 깊이가 같다면 ‘균형이 잘 잡혔다’고 평가할 만하다. 그래야 어느 방향으로 오가든 ‘최단 이동 시간’을 기록할 수 있다. 균형 잡힌 데이터 설계는 응답 시간 단축에도 기여한다. 반면, 균형미가 파괴된 데이터 설계에서 응답 도출 시간은 그야말로 ‘엿장수 마음대로’다.

군살 ‘제로’ 성공, 다음 수순은?

마라톤 선수는 최단 기록을 달성하기 위해 자기 몸의 군살을 최소화한다. ‘군살 제로(0)’는 데이터 구성에서도 더없이 중요한 원칙으로 작용한다. 데이터 역시 군살, 다시 말해 쓸데없는 중복이 완전히 제거돼야 좌우 균형미를 갖출 수 있다. 속도 역시 그 과정을 거쳐 개선된다. 군살이 사라졌다는 건 한마디로 질적 측면에서 잘 다듬어졌다는 뜻이다. 혹자는 궁금해 할 것이다. “군살을 빼고 난 후 수순은 어떻게 될까?” 다음번 칼럼에선 바로 이 주제를 다뤄볼까 한다.

※ 이 칼럼은 전문가 필진의 의견으로 삼성전자의 입장이나 전략을 담고 있지 않습니다.

최근 페이스북이 자사 서비스 가입자를 대상으로 감정 조작 실험을 감행한 사실이 알려져 화제다. ‘뉴스 피드(news feed)에 대한 긍·부정 반응을 임의로 조작했더니 사용자 대부분이 지대하게 영향을 받더라’는 게 주요 내용이다.

‘소셜네트워크서비스(SNS)가 여론 향방 결정에도 막대한 영향을 끼칠 수 있다’는 결론은 사뭇 충격적이었다. 실험에 참여한 이는 페이스북 사용자 70만 명. 엄밀히 말하면 빅데이터(big data)급엔 미치지 못하는 소규모 데이터 실험이었다. 페이스북 실험 논란은 향후 빅데이터를 앞세운 실험이 가져올 파장을 상징적으로 보여준 사건이었다.

빅데이터에 대한 일부 대중의 인식 속엔 수 년 전 유럽입자물리연구소에서 세기의 실험 끝에 발견된 힉스 입자가 자리 잡고 있다. 혹자는 빅데이터를 ‘SNS 이용자가 주고받는 교신량의 총합’으로 정의하기도 한다. 하지만 빅데이터의 원류를 찾으려면 약 20년 전으로 거슬러 올라가야 한다.

수요일 저녁, 기저귀와 맥주 매출의 상관 관계

1990년대 중반 한 대형 마트에서 있었던 일이다. 매주 수요일 저녁, 기저귀와 맥주 매출이 동반 상승하는 현상이 반복됐다. 이 같은 사실은 마트 판매관리부장이 어느 날 우연히 발견했다. 그는 기저귀와 맥주 간 기묘한 상관관계를 추적하기 위해 기저귀 진열대 위치를 일부러 맥주 진열대 가까운 곳으로 바꿨다. 그랬더니 놀랍게도 다음 달 기저귀와 맥주 모두 매출이 전달의 5배로 뛰었다.

일반적으로 유아를 키우는 가정은 주말에 1주일치 기저귀 한 팩을 구입한다. 하지만 종종 기저귀가 예상보다 빨리 소진되고, 그럴 때마다 (한 주의 절반가량이 지난) 수요일 오후 아내는 직장에 있는 남편에게 전화를 걸어 “기저귀 한 팩만 사 오라”고 부탁한다. 전화를 받은 남편은 오후 6시 퇴근 직후 차를 몰고 마트로 향한다. 기저귀를 사고 돌아 나오던 그는 생각한다. ‘기왕 힘들여 여기까지 왔는데 맥주나 한 팩 사 가지, 뭐!’

실제 월마트에서 있었던 이 사실이 세간에 알려지면서 대형 마트를 비롯한 유통업계를 중심으로 빅데이터에 대한 관심이 급격히 높아졌다. 수많은 품목 중 ‘매출 쌍끌이’ 역할을 해줄 기저귀와 맥주 같은 조합만 찾아낸다면 한 번쯤 시도해볼 만한 일이란 데 눈을 뜬 것이다.

페이스북이 자체 검색 엔진 개발에 나선 ‘진짜’ 이유

페이스북은 이름처럼 ‘얼굴책(facebook)’ 격인 졸업 앨범에서 출발한 기업이다. 천문학적 사용자 수를 보유하고도 이렇다 할 사업 모델이 없어 투자자들에게서 외면 당하던 페이스북은 얼마 전부터 부쩍 달라진 행보를 보이고 있다. 자체 인터넷 검색 엔진을 개발하고 모바일 광고 시장에 뛰어들어 구글과 전면전을 치르는 것 등이 대표적 변화다.

페이스북이 개발한 검색 엔진은 십수억 명의 회원이 쌓아 온 소셜 데이터를 기반으로 하기 때문에 빅데이터 시대에 특화됐다는 특징을 지닌다. 페이스북이 빅데이터에 관심을 갖는다는 사실은 달리 말해 페이스북이 자사 시장 매출에서 ‘기저귀와 맥주’ 역할을 해줄 데이터 쌍을 발굴해낼 자신이 있다는 뜻이다.

월마트와 페이스북 사례는 두 가지 교훈을 던진다. 첫째, 빅데이터에서 ‘빅(big)’이란 실로 천문학적 규모의 데이터를 의미한다. 월마트의 경우, 기저귀와 맥주 간 조합을 알아내기 위해 동원된 데이터 분량은 수집되는 모든 정보를 A4 복사용지에 빽빽하게 기입한 후 수직으로 쌓아 올렸다고 가정했을 때 에베레스트산 수십 개 높이에 해당한다.

둘째, 특정 데이터가 빅데이터의 일부로 인정 받으려면 최소한의 ‘자격’을 갖춰야 한다. 데이터가 아무리 많아도 그 중 상당수가 엉터리라면 진정한 빅데이터라고 하기 어렵다. 실제로 우리가 빅데이터로 지칭하는 데이터 뭉치 속엔 ‘가짜 데이터’가 꽤 많이 산재해 있다. 빅데이터 분석을 통해 유의미한 데이터 쌍을 찾아내려면 이 같은 쓰레기 데이터부터 찾아 분류해야 한다. 그래야 좀 더 빠른 속도로, 좀 더 질 높은 데이터를 추출해낼 수 있다.

뭐든 열심히 모으기만 하면 훌륭한 데이터가 된다?

데이터 검색 과정에서 일정 수준 이상의 속도를 내려면 일종의 ‘내비게이터’가 필요하다. 이는 마치 자동차 운전자가 낯선 곳을 찾아가기 전 해당 지역 지도를 참조하는 것과 같은 논리다. 이 작업을 기업 정보 시스템으로 확장시키면 지역 지도는 ‘전사(회사 전체)데이터맵’에 해당한다. 개인과 조직 할 것 없이 지도나 내비게이터가 없으면 데이터를 대충 찾을 수밖에 없다. 전사데이터맵은 쉽게 말해 ‘기업 데이터 교통지도’다. 기업 정보를 찾을 때도 정확한 지도가 없다면 정답은 늦게 도출될 수밖에 없다. 오답이 나왔을 때 그 원인을 규명하는 일도 불가능해진다. 당연히 검색의 질과 속도는 현저히 떨어진다.

이제껏 크고 작은 기업이 전사데이터맵 작성에 뛰어들었다. 대표적 사례가 전사적자원관리(ERP)와 데이터창고화(DWH) 같은 것들이다. 요즘도 꽤 여러 곳에서 두 방식이 통용되고 있긴 하지만 ERP의 경우 ‘진화정지설’이 회자되고 있으며 DWP 역시 무용(無用)론이 제기된 지 오래다.

ERP나 DWH의 결정적 패인은 내부에 꽉 들어찬 엉터리(쓰레기) 데이터다. 이들 개념이 데이터맵 개념조차 없던 시절 도입됐다는 사실을 감안하면 이런 결과가 빚어진 것도 무리는 아니다. 오늘날 두 이론에 전사데이터맵을 억지로 적용하려 해도 데이터 비만도가 너무 심각해 원하는 결과를 얻기 어렵다. ‘뭐든 열심히 모으기만 하면 훌륭한 데이터가 될 것’이란 안일한 생각이 빚은 참사다. 실제로 일부 기업의 ERP나 DWH는 축적된 데이터의 절반가량을 솎아내야 할 정도로 심각한 수준이다.

이런 데이터 찌꺼기(혹은 중복)를 속 시원히 제거하기 위해서라도 기업 정보를 한눈에 들여다볼 수 있는 데이터맵은 반드시 존재해야 한다. 데이터맵에 자신 있게 나타낼 수 없다면 데이터로서의 존재 가치는 없는 것과 마찬가지다. 문제는 국내 기업 중 수준급 전사데이터맵을 갖춘 기업이 사실상 한 군데도 없다는 사실이다. 단언컨대 전사데이터맵 개념이 없거나 희박한 기업에 빅데이터란 한낱 신기루에 불과하다.

※ 이 칼럼은 전문가 필진의 의견으로 삼성전자의 입장이나 전략을 담고 있지 않습니다.