콘텐츠성 정보 자산 vs 기준 정보 자산
한국의 마틴 파울러가 되기
RDBMS의 시대가 가고 빅데이터 시대란 이름도 이미 낡은 상황이 되었습니다. 그럼에도 불구하고 다음과 같은 매력적인 그림에 담긴 내용으로 대화할 상대를 구하기는 그다지 쉽지 않습니다.
하지만, 그렇다고 해서 제가 호기심이 많을 뿐, 관련 경험은 많은 것은 아닙니다. 그럼에도 불구하고 조금 더 쉽게 이야기할 수 있는 주제가 하나 있어서 글을 써 볼까 합니다.
콘텐츠성 정보 자산 vs 기준 정보 자산
작년 언젠가 회의를 하다가 설명을 하려는데, 딱 적합한 기술 용어가 없었습니다. 그래서, 저의 말을 만들어야 했습니다. 생소한 단어로 즉시 설명하면 회의가 길어질 듯해서 그냥 메모만 해 두었는데, 그새 몇 달이 흘러가 버렸습니다. 그래서, 이번에는 당장 실행하기에 앞서 글로 써 두어 기회가 될 때 설명 시간을 줄이는 데 써 보자는 생각이 들었습니다.
그때, 썼던 메모가 '콘텐츠성 정보 자산 vs 기준 정보 자산'입니다.
다음 페이지는 구글에서 키워드로 '복잡한 단품 페이지'를 넣고 검색한 결과 화면입니다.
다양한 콘텐츠 설명 페이지
이커머스 분야에서 10년 정도 일을 하면서 프로세스와 용어에 익숙했습니다. 처음 들을 때 굉장히 생소했던 '단품 페이지'는 이제 입에 붙었죠. 모바일 앱이나 위챗 미니 프로그램에 대해 이야기할 때는 '단품 페이지'라는 말은 잘 쓰지 않지만 결과적으로 비즈니스 기능이 똑같은 페이지가 다른 형태로 나타납니다. 물건을 팔려면 상품 설명이 필요하니까 상품 상세 혹은 상 페이지라고 부르는 페이지가 없을 수는 없습니다.
단품이라는 말은 다소 낡은 듯도 하고 의미를 명확하게 전달하지 못해서 이제부터 '콘텐츠 페이지'라고 부르겠습니다. 그런데, 페이지라고 하는 이상은 디자인 요소가 굉장히 중요합니다. 부산에 사는 동생이 자기 본업 말고 사진 찍고 단품 페이지 만드는 알바를 한다며 '형님에게는 공짜로 만들어 줄게요'라는 말을 몇 주 전에 들은 일이 있습니다. 하지만, 소프트웨어를 설계하는 사람이 바라보는 콘텐츠 페이지와 포토샵으로 돈을 버는 사람이 바라보는 콘텐츠 페이지는 또 영 다릅니다.
그러니 여기서 다시 '콘텐츠 페이지'에서 시각적 표현 관점 혹은 그래픽 디자인 요소를 제외한 내용을 생각할 수 있습니다. 저는 이를 '콘텐츠성 정보 자산'이라고 부르겠습니다. 그중에서 '정보 자신'이라는 말은 데이터베이스에 쌓인 것을 뜻하는데, DBMS라는 도구 안에 쌓인 이력 즉 레코드라고 부를 수도 있습니다. 그 레코드 중에서 내용 그대로 '상품이 된다'면 콘텐츠성 정보 자산이라고 부르려는 것이죠.
콘텐츠 설명 페이지가 아닌 콘텐츠 페이지일 수도 있다
'상품이 된다'는 말은 무슨 뜻일까요? 팔려서 돈을 얻을 수 있다는 의미로 쓴 것입니다. 여러분이 프리랜서라면 페이지 자체를 팔 수도 있지만, 이 글은 소프트웨어 설계를 다룬 것이라 페이지를 만드는 기업의 비즈니스를 위한 도구로서의 페이지만 다룹니다. 다시 말해서 페이지에 접근한 사용자가 구매자나 고객이 될 수 있다면 , 그 페이지는 '콘텐츠 페이지'가 되고 거기서 그래픽 디자인 요소를 빼면 바로 '콘텐츠성 정보 자산'이 됩니다.
그런데, 유튜브 같은 영상을 화면에 삽입하면 그 페이지 자체가 상품이 되고 콘텐츠 페이지가 될 수도 있습니다. 상품 평만 있어서 구매를 유도하는 게시판 같은 구성이 되어도 콘텐츠 페이지라 할 수 있습니다. 인스타그램도 그런 페이지로 볼 수도 있죠. 그런 식의 기능 모두는 소프트웨어적으로 '콘텐츠성 정보 자산'을 써야 하기 때문에 그 말을 만들 필요가 있다고 느꼈습니다.
콘텐츠성 정보 자산과 구분하고 싶은 정보 자산
그렇다면, '콘텐츠성 정보 자산'이 아닌 '기준 정보 자산'은 무엇이고 왜 필요할까요? 기업용 전산의 기원이 '전자적 데이터 처리 시스템'(Electronic Data Processing System)으로 출발했다는 사실을 아는 분이라면 설명이 조금 쉬울 텐데 그런 표현을 안다면 연차가 꽤 되어야겠죠?
쉽게 말해서 과거의 전산실은 종이로 하던 일을 전자적으로 바꾸는 일을 오래도록 해 왔습니다. 상호작용이 풍부한 웹이 나오기 전에는 그랬죠. 그래서 중요한 서류의 번호에 '관리 번호'를 매겨서 일관성을 관리했습니다. 그리고, 중요 서류 속에 있는 내용이 반복해서 쓰이면 이들을 '기준 정보'라고 불렀습니다.
사실 어찌 보면 관계형 데이터베이스는 기준 정보 중심으로 데이터를 관리하는 도구입니다. 그런데, 기준 정보에 어울리지 않는 데이터도 모두 넣어서 사용했죠. 여러 가지 이유가 있겠지만, 초창기에는 기준 정보인 것과 아닌 것을 동시에 어떻게 관리할지 방법을 잘 몰랐다고 말할 수 있습니다. 그러는 중에 일부는 새로운 용어(NoSQL)와 솔루션을 내보이며 미래의 변화를 예고했습니다.
RDBMS와는 다르게 써야 한다는 뜻을 담은 NoSQL이란 말을 제가 들은 것도 벌써 10년이 훨씬 넘은 시점이라 서두에 말씀드린 이런 그림을 볼 수 있는 것이죠. 업계는 많은 발전을 이뤘습니다. 하지만, 업계를 선도하는 일부 팀에 속한 일부 개발자와 설계자들이 그렇다는 것이지 업계에 속했다는 이유로 발전하지는 않습니다.
이 글에서는 일단 위 그림에 대해 해독하지 못하더라도 '콘텐츠성 정보 자산 vs 기준 정보 자산'이라는 이분법을 알려드립니다. 여력이 되면 이를 활용하는 방법까지 다룰 생각이지만 그때가 언제가 될지는 아직 모르겠습니다.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
13. 설계는 변화에 대한 준비인가?
18. 동료의 상태도를 검토하기
