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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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