블로그의 글을 옮기면서 수많은 생각들이 떠오른다. 가장 기본적인 질문은 왜 블로그에 글을 쓰는가였다. 가장 기본적 질문은 블로그에 어떤 글을 올려야 하나 반대로 올리지 말아야 하는지를 결정하는 가장 기본적인 기준을 만들어 준다. 블로그 플랫폼 (platform) 혹은 서비스 환경을 바꾸면서 그동안 블로그를 운영하면서 느끼게 되었던 불편함을 정리할 수 있고 동시에 그 불편함은 무엇을 필요로 하는지 생각하게 만든다. 그리고 글을 옮기는 과정에서 플랫폼이란 사용자가 원하는 구현시켜주는 것이 중요한 것이 아니라 사용자가 어떻게 바뀌어야 하는지를 제시해줘야 한다는 것을 생각하게 만든다. [ 검색엔진의 진화 ─ 플랫폼을 통한 인식의 진화 ] 를 통해서 플랫폼이 주는 중요성을 강조했다. 플랫폼은 아주 간단히 말하자면 우리가 '하는 일 (tasks) 에'만' 집중할 수 있는 좋은 놀이터이다. 검색엔진의 예를 들면 사용자가 검색해서 가장 원하는 것을 가장 먼저 보여줄 수 있는 좋은 검색결과를 내놓는 것이다. 그렇게 해서 사용자들이 화면을 내리는 수고를 덜하고 가장 원하는 해답이 찾을 수 있도록 도와주는 '환경'이 되는 것이다.
 

DNA Sequencing 은 수많은 발전을 통해 값싼 가격에 분석할 수 있는 플랫폼으로 발전하고 있다.

다른 예를 들어보면, 십년 전만 해도 유전자 염기서열 (DNA Sequencing) 후 이를 분석하기 위해서 수억달러가 들었다. 이유는 제대로 된 플랫폼이 없었고 모든 것이 첫 시도이기 때문에 실험실에서 생화학적 분석 이후 분석된 데이터를 어떻게 처리하고 이를 어떻게 분석하고 이를 원하는 형태의 결과로 보여줄 것인가에 대한 제대로 된 작업의 흐름이 없었다. 그러나 이제 반복된 실험과 분석을 통해서 다양한 문제점을 파악하고 이런 문제점들을 해결할 수 있는 가장 기본적인 작업 순서를 만들고 결과적으로 이제는 실험실의 실험자 (experimental technician or experts) 들은 실험만 하고 결과는 실험자들이 별도의 관리를 하지 않아도 서버에 들어가고 이에 필요한 기초적인 분석부터 시각적인 결과물 (visualization) 까지 완성시켜주었다. 불과 십년 정도 되는 과정에서 엄청난 발전이 이루어졌다.

두가지의 예를 보더라도 우리 삶에서 플랫폼이란 무척 중요한 시스템임을 알 수 있다. 그리고 시스템이 잘 갖추어진 환경에서 일의 본질에만 집중할 수 있게 된다. 예를 들어 이메일 시스템이 보편화되지 않았던 시절에는 이메일 하나를 보내기 위해서 낯선 유닉스 환경에 들어가거나 복잡한 클라이언트 메일 설정을 해야 가능했다. 컴퓨터 그래픽을 작업하는 사람이 자신이 작업한 파일 하나를 지구 반대편의 누군가에게 보낸다고 생각해보자. 지금이야 아주 간단하게 메일을 보내거나 클라우드 스토리지 (cloud storage)에 올려 공유를 하면 되지만 이메일 조차 힘든 시절이라면 이메일을 보내기 위해 이메일에 관련된 설정을 하고 이메일을 보내지만 작업한 파일 용량이 메일이 지원하지 못할 정도로 크다면 이를 보내기 위해 FTP 나 다른 방법을 고민해야 한다. 예전에는 작업의 부수적인 내용까지 다 할 수 있는 사람이어야 했지만 좋은 플랫폼 - 웹 환경의 좋은 이메일, 클라우드 서비스 - 이 존재하면 그래픽 작업에만 집중하면 된다. 결과적으로 좋은 플랫폼은 사용자들이 얼마나 자신의 일에만 집중할 수 있는지를 통해 평가될 수 있을 것이다.

블로그를 이전하면서 드는 첫번째 생각 

블로그를 옮기면서 드는 생각은 기술은 분명 인간이 편하게 사용하고 좀더 섬세한 결과를 만들 수 있는 환경을 위해 노력하고 있지만 그 기술을 전달하는 기술자 (혹은 과학자) 들은 최종 사용자 (end user) 에게 얼마나 그 기술이 좋은지 알려주고 있는지에 대한 의문이 들었다.

HTML5 나 CSS (Cascading Style Sheets) 등 웹서비스의 기본적인 기술들은 점점 사용자들이 사용하는데 편하게 발달하고 고민하지만 결국 그 기술이 보편적으로 구현될 수 있도록 얼마나 좋은 플랫폼을 제공하는가에 대한 의문이었다. 처음 CSS 를 접했을 때 왜 진작 이런 내용을 적용시키지 못하고 매번 블로그 글을 쓸때마다 폰트 크기, 자간, 문단 간격 등과 같은 형식 (format) 에 시간을 투자했었나 싶었다. 그러나 문제는 CSS 에 대해서 익숙하지 않은 사용자들에게는 CSS 가 무엇이고 어떤 규칙에 의해서 작동하는지 모르면 서비스가 제공하는 형식에 따라갈 수 밖에 없다. 그리고 그 과정에서 느끼는 불편함은 어떤 사용자에게는 그냥 참고 넘어갈 내용이 되기도 하고 어떤 사용자에게는 '해결해야 할 문제' 가 된다.

[ Why Google Cares about Computer Science Education ]

'구글은 왜 컴퓨터과학 교육에 신경쓰는가' 란 글을 보았다. 여기에 있는 가장 핵심은 컴퓨터과학은 하나의 직업을 위해 필요한 기술이 아니라 '복잡한 문제를 해결하고 새로운 변화를 이끌어 낼 수 있는 생각하는 방법을 위해서... (Computer Science is about the way of thinking needed to solve complex problems and drive innovation) 라고 말한다. 개인적으로 이 내용에 큰 공감을 하게 된다. 분야를 떠나 프로그래밍의 기본적인 내용을 알고 있는 사람과 그렇지 않는 사람의 차이점은 어떤 문제점이 놓였을 때 문제를 분석하는 방법이 다르다는 점이다. 프로그래밍의 흐름을 알고 있는 사람은 문제를 단순화 시키는 방법과 문제를 현실에 접근시키는 방법을 알고 있다는 점이다.

프로그래밍은 문제 해결을 위한 방법을 배우는 것이지 직업적 기술자를 만드는 것이 아니다.

CSS 를 통해 생각해 본다. 열심히 졸업 논문을 쓰는 사람이 있었다. 둘다 연구 결과는 논문으로 만들만큼 괜찮았다. 두명 모두 열심히 논문 내용을 완성시켜 갔지만 한 사람은 써가면서 제목, 소제목, 본문, 주석에 따라서 자신이 마음먹은 폰트, 크기, 문단 형식을 적용해가며 작성했다. 다른 사람은 워드에서 제공하는 제목, 소제목 등과 같은 속성을 부여하면서 작성해갔다. 그런데 논문 결과물은 거의 비슷했는데 두 사람 모두 제목의 폰트와 문단 정렬이 마음에 들지 않아서 바꿔야 하는 상황이 발생했다면 전자는 모든 제목을 찾아가 폰트와 문단 정렬을 변경해야 한다. 그러나 후자의 경우 제목이란 속성이 가지는 형식만 바꾸어 주면 전체가 다 적용된다. 웹페이지에서도 이와 같은 역할을 하는 것이 바로 CSS 이다. 블로그로 넘어오면 일은 더 복잡해진다. 자신이 지정한 본문의 형식을 변경하기 위해서 모든 글들에 편집에 들어가 바꿔주는 것은 엄청난 일이다. 글이 몇백개가 되어간다면 그냥 포기하는 것이 더 현명할 것이다. 그러나 CSS 를 이용하면 간단하게 CSS 의 형식만 변경해주면 전체 글들이 다 적용이 될 것이다.

여기에서 문제를 단순화 시키는 방법을 생각해본다. 문제는 각 글에 너무 세부적인 형식을 부여 했다는 점이다. (프로그래밍에서는 이를 hard coding 이라 부른다.) 문제는 결국 글의 데이터와 형식을 분리하지 않았기 때문에 유연성 (flexibility) 이 떨어진다는 것을 알게 된다. 그렇다면 이를 해결하는 방법은 데이터와 형식을 분리시킬 수 있는 방법을 생각해야 할 것이다.

그렇지만 문제를 단순화 시켜서 다양한 경우 우리가 정말 원하는 형태의 기술로 사용자가 사용하기 어려운 많은 문제점들이 발생할 것이다. 가장 대표적인 것은 속성이 지정되지 않은 데이터는 어떻게 처리할 것인가와 같은 것이다. 즉, 문제는 단순화하여 문제의 본질은 찾았지만 결국 그 문제를 해결할 수 있는 실질적인 방법이 무엇이냐 (방법론 ; methodology) 는 문제가 생길 수 밖에 없다. 그러나 그런 다양한 문제점들을 해결하는 과정이 바로 기술이 사용자들에게 사용할 수 있도록 발전하는 과정이 된다. CSS 의 경우 이름이 알려주듯이 cascading  이 해결책이 되어준다. 워드프로세서와 달리 CSS 는 폭포수처럼 구조적 단계를 가진다. 즉, 구역 안에 구역이 나누어지게 되고 만약 하위 구역의 형식이 지정되어 있지 않는다면 상위 구역의 형식을 따르게 되는 것이다.

CSS 의 구조를 살펴보면 수많은 불편함을 해결하기 위한 과정이었음을 느끼게 된다. 

이런 내용을 컴퓨터 프로그래밍을 조금이라도 접했던 사람에게 설명하는 것과 접하지 않은 사람에게 설명하는 것은 정말 큰 차이점이 생긴다. 그리고 이런 CSS 라는 기술이 개발되고 이를 일반 사용자들이 이런 CSS 의 기본적 내용을 몰라도 편하게 사용할 수 있는 웹 서비스를 만들어 준다면 사용자들은 CSS 가 무엇인지 몰라도 기술의 모든 유용성을 사용하게 된다. 이처럼 좋은 플랫폼은 기술이 어떻게 작동하는지 몰라도 사용할 수 있도록 만들어 준다. 이제 누구나 컴퓨터를 사용하지 못하는 사람은 없을 것이다. 간단하게 마우스를 움직이고 클릭하고 실행하는 것이 전혀 어렵지 않기 때문이다. 그러나 모든 컴퓨터 사용자들이 클릭하는 것이 어떤 경로의 어떤 파일을 실행하는지 신경쓰지 않아도 된다. 이는 그만큼 컴퓨터 운영체제의 시스템이 얼마나 발전해왔는지 말해 준다.

블로그를 운영하며 느끼는 두번째 생각 

앞서 말한 것처럼 웹서비스는 많은 발전을 해왔지만 여전히 좋은 플랫폼은 아닌 것 같다는 생각이다. 이전에 사용하던 블로그 서비스나 현재 사용하는 구글의 블로거 (blogger) 서비스나 비슷하다. CSS 와 같은 내용을 알아야지 내가 원하는 방향을 조금씩 변경할 수 있고 기본적으로 제공하는 내용으로는 마음에 들지 않거나 불편한 부분들이 생기게 된다는 점이다. 만약 사용자에게 좋은 블로그 서비스라면 CSS 나 구조화된 데이터 (structured data format) 등에 신경쓰지 않을 것이다. 예전보다 많이 손볼 것은 줄어들었지만 여전히 불편한 부분들이 존재한다. 물론 여기에서 충분히 만족하고 사용한다면 문제점은 보이지 않을 것이다. 그리고 개인적으로 느끼는 불편함은 이미 많은 사람들도 같은 혹은 비슷한 불편함을 느끼고 있고 이를 해결하기 위해서 수많은 사람들이 자신의 지식과 경험을 공유하는 공간으로 인터넷은 분명 충분히 멋진 공간이다.

문제 해결을 위해 인터넷의 정보를 충분히 활용한 [ Jack Andraka ] 의 예를 통해 생각해보면 인터넷은 너무도 수많은 정보들이 존재하고 그 정보들을 내가 불편한 내용을 해결하기 위한 목적을 위해 잘 조합하면 충분히 좋은 해결책이 나올 수 있다는 점이다. 즉, Jack Andraka 의 경우 췌장암 진단을 위한 값싼 진단 방법을 만들었고 이것은 분명 창의적 결과물이지만 그 결과물이 나오기 위해 필요한 기술적, 과학적 내용들 - 생화학, 유체역학 등 - 은 이미 많은 사람들이 대답해 주는 내용이었다는 점을 주목해야 할 것이다. 아주 간단하지만 블로그를 내가 원하는 방향대로 만들기 위해서 관련된 내용을 검색하다 보면 '내가 가진 문제점 혹은 고민은 나 혼자 생각한 것이 아니구나 (전혀 창의적 고민이 아니구나...) 라는 점이다. 즉, 누군가는 이미 고민했고 누군가는 이미 그 해결책들을 알고 제시하고 있다는 것이다.

Jack Andraka 는 인터넷에서 쉽게 접근할 수 있는 수많은 문제해결 방법들의 조합이 얼마나 창의적인 결과물을 만들어 낼 수 있는지를 보여주었다.

문제점들은 창의적이지 않지만 그 문제점을 해결하면서 내 결과물은 충분히 창의적일 수 있다. 

불편함을 느끼는 것은 문제를 인식한다는 것이다. 불편함이 존재하지 않는다는 것은 해결할 필요조차 없는 상태이다. 수많은 불편을 느끼면서 무엇이 문제인지 느끼게 된다. 그리고 그 불편함을 해결하는 과정들은 거의 대부분 (99.99%) 내가 처음 느낀 불편이 아니기 때문에 세상은 이미 그에 대한 다양한 해결책을 알려준다. 이것이 인터넷이 우리에게 제시하는 가장 큰 혜택이 되길 바란다. 그런 의미에서 인터넷에는 다양한 컨텐츠 (contents) 가 존재했으면 바랬던 이유도 같은 의미가 될 것이다. [ 인터넷은 우리를 똑똑하게 해주는가? ] 만약 누구도 경험하지 않은 문제를 경험하게 된다면 그 자체가 스스로 해결해야 할 새로운 과제가 될 것이다. 그리고 첫번째 해결책을 제시한다면 그 자체가 창의적 결과물이 될 것이다.

블로그 글들을 옮기면서 느끼는 세번째 생각

본 블로그에는 네가지의 큰 범주가 있다. 몽달이생각, 일상다반사, 사람들생각은 글을 옮기기 편했다. 글 자체가 복잡하지도 않았고 순간의 생각들을 정리하는 내용이었기 때문에 나름 글 하나로 완결된 내용이었기 때문이었다. 그런데 컴퓨터 기술의 활용이나 기술이 가지는 철학에 대한 내용을 다루는 '시스템잡설'의 경우 아직까지도 어떻게 글을 옮겨야 하나 고민을 하게 된다. 글에서 소개한 서비스나 내용들이 변경되거나 지금와서 생각하면 불편함인데 이제는 그 불편함을 웹서비스가 깔끔하게 해결해준 경우이다. (그만큼 플랫폼이 좋아졌다는 증거이기도 하다.) 대부분 개인적으로 컴퓨터나 전자기기를 사용하면서 느꼈던 불편한 부분들을 해결하기 위해서 시도했던 내용들이다. 예를 들어 음원 서비스의 태그가 깨지는 경우 이를 해결하기 위해 음원 파일의 태그 구조를 알아야 했고 웹서비스가 지원하는 내용 등을 찾아 이에 맞춰서 해결했고, 가지고 있는 책이나 읽은 책들을 관리하는 방법이 없을까 싶어 스마트폰으로 바코드를 읽어서 ISBN 을 통해 책 정보를 보여주는 서비스를 연결하는 방법으로 해결했었다. 불편한 부분들의 문제점들을 해결하는 과정에서 점점 내가 목적하는 결과물에 접근할 수 있었고 그 과정에 대한 작업기록 (work logs) 를 정리하면 만족도가 높았다.

반대로 특정 서비스, 소프트웨어에 집중한 경우 지금와서 다시 보면 어떻게 해야하나 싶을 때가 많다. 물론 업데이트 되는 내용을 수시로 변경해주었지만 열심히 사용하고 만족스러운 서비스 / 소프트웨어이기에 소개했지만 그 중 서비스가 중단되어 사라지거나 아직도 있지만 점점 발전이 없어서 개인적으로도 더이상 사용하지 않는 소프트웨어 / 앱을 소개하는 글들을 볼 때는 저것들을 어떻게 바꾸나 싶은 생각이 들었다. 그래서 쉽게 시스템잡설에 해당하는 내용은 글을 옮기지 못하였다.

개인적인 만족도가 높았던 메모 서비스였던 SpringPad, 결국 서비스를 중단하였다.

점점 느끼는 것이지만 웹서비스, 소프트웨어, 앱 등이 발전하고 사용자의 요구를 충분히 충족시켜 가고 있다고 해도 시간이 지나면 이런 서비스의 세부적인 내용들도 결국 변화하고 바뀌게 된다는 점이다. 결국 이런 소프트웨어의 기능적 부분을 강조하는 글을 자연스럽게 쓰게 되지만 이또한 시대가 지나면 어떻게 바뀌게 될지 때로는 당시는 아주 유용한 기능이었지만 지금와서 보면 아예 사라지거나 필요가 없어진 것도 있다. 그러나 반대로 몇년이 지나고 오래전 내용이지만 지금와서 보아도 공감을 얻을 수 있는 내용들도 있다는 것에 더 주목하고 싶었다. 대부분 그런 내용은 아주 기본적인 내용들이었다. 여기서 기본은 누구나 알아야 하는 기초 (basic) 이 아니라 잘 활용하는데 필요한 기반 (fundamental) 적인 내용이란 것이다. 오랜동안 사용한 이메일, 웹서비스 그리고 보안에 관련된 내용들은 구현하기 위한 구체적인 기술이 바뀌는 경우는 있어도 그 원리는 거의 비슷하다는 점이다.

결국 새로운 블로그에 옮겨 쓰게 될 '시스템잡설' 의 구체적인 내용도 이 부분에 집중해서 주제를 선택하는 것이 오래 남아도 괜찮을 글이 되지 않을까 싶었다. 블로그를 옮기면서 여러가지 고려하며 설정도 바꾸면서 아주 가볍게 생각하고 있던 인터넷의 기반 기술이 얼마나 중요한지 느낄 수 있었다. DNS 서비스가 그런 예이다.

블로그 글을 쓰다 스마트폰을 보면서 드는 네번째 생각

갑자기 스마트폰을 보면서 생각이 되었다. 다양한 앱들을 받을 수 있는 (구매할 수 있는) 스토어에 들어가면 이처럼 수많은 앱들이 있을까 싶은 생각들이 든다. 그리고 많은 사람들은 이 앱이 무슨 기능을 할 수 있다. 내용에 집중하게 된다. 즉, 이 앱이 나에게 무엇을 해줄 수 있다란 내용이 중요하다. 그런데 모바일 운영체제를 사용하면서 느끼는 점은 '기본적인 내용이 중요하다'이다. 만약 성경을 보고 싶다면 성경 앱을 찾게 될 것이다. 가장 맘에 드는 성경앱은 온라인이 아니면 볼 수 없다. 그렇다면 웹페이지에 들어가서 보는 것과 만족감에 차이가 없다면 깔아놓을 필요가 없을 것이다. 오프라인에서도 보고 싶다면 성경 내용을 텍스트 파일로 구해서 이를 저장해놓고 텍스트 리더를 이용해 보면 될 것이다.

앱 홍수 시대에 자세히 살펴보면 대부분 특별한 목적이나 아주 제한적 상황에서 잠시 사용하고 마는 그런 앱들이 대부분이라는 것을 느끼게 된다. 그런 생각에 사용빈도가 거의 없는 앱들은 다 지워버린다. 특히 고객센터나 특별한 상업적 서비스를 사용하기 위한 앱들은 자주 사용하지도 않는데 사용자가 모르는 기능 (알림 기능이나 위치 기반 서비스 등) 을 위해서 배터리, 저장공간, 모바일 AP (application processor) 등을 자주 사용한다. 편리성을 위해 설치해보면 웹브라우저로도 충분히 같은 기능을 수행할 수 있는 경우가 대부분이다. 그래서 웹브라우저로 해결 가능한 앱 중 사용빈도가 많지 않다면 설치하지 않는다. 그런데 대부분 이런 앱들의 공통점은 기본적인 기능을 그냥 앱이라는 껍데기로 쌓아놓은 경우가 많다는 점이다. 많은 경우 사용하지 않는 앱들은 설치해놔도 특별히 손해볼 것 없지 않겠는가 싶은 마음에 설치해 놓는다.

안드로이드의 파일 관리자 앱, 파일 구조를 탐색할 수 있다는 기능은 상당히 많은 PC에서 해오던 기본적 작업을 가능하게 해주었다.

대부분 스마트폰을 쓰면서 온라인 / 오프라인의 개념을 잊어버리게 된다. 항상 모바일 데이터가 연결해주기 때문이다. 그러나 모바일 데이터를 사용하지 않는 경우를 생각해보자. 설치한 앱들 중에 얼마나 작동이 가능한지 살펴본 적은 없을 것이다. 항상 연결되어 있는 편리함때문에 인터넷이 안되는 불편함 속에서 무엇이 문제인지 생각하지 못한다. [ 앱 디자인의 발견 - 메모 서비스를 생각하다. ] 가끔 인터넷이 끊겨진 상태에서 어떤 앱들이 오프라인 / 온라인을 잘 지원해주는지 확인해본다. 일부러 오프라인의 불편함을 경험해보는 것이다. 예를 들어 노트 앱의 경우 오프라인에서 내가 원하는 노트를 볼 수 조차 없는 경우도 생긴다. 반대로 음악 스트리밍 서비스이지만 사용자가 사용안할 때 미리 내려받아놔서 사용자가 오프라인에서도 일부 음악을 들을 수 있도록 해준다. 어떤 제한 요소 (불편함) 가 존재할 때도 사용자가 편하게 사용할 수 있는 생각을 가지고 소프트웨어를 만드는 개발자는 어느 정도 있을까?

My Tracks 는 초기위치만 확인해주고 이후 인터넷이 전혀 되지 않는 오프라인 환경에서도 자신의 경로를 GPS 만으로 그려준다. 

몇년동안 스마트폰에 익숙해지면서 느끼는 점은 다양한 앱들이 필요한 게 아니라 우리가 스마트폰을 통해 무엇을 하고 싶은지를 모르는 방랑자가 아닌가 싶다. 개인적으로 아이폰 / 아이패드가 아닌 안드로이드를 고집하는 가장 큰 이유는 파일 관리가 가능하다는 점이다. 많은 경우 대부분 웹브라우저로 해결이 가능하다는 점이다. 오프라인에서 작업한 pdf 파일을 잠깐 무선랜을 연결해 메일에 첨부하거나 심지어 자신의 컴퓨터 공유기의 펌웨어 업그레이드같은 아주 간단한 작업은 파일 관리가 안되면 불가능하다. 가장 기본적인 그리고 익숙한 작업들을 해결할 수 있는 환경이라면 모바일인지, 데스크탑인지가 중요한 것이 아니다. 이처럼 내가 필요한 기본적 (fundamental) 내용이 무엇인지 찾아가는 것이 중요하다.

다시 블로그로 넘어오자면 그런 기본적 내용 (fundamental) 들이 모인다면 블로그 자체도 하나의 구조를 가질 수 있다고 믿었던 것 같다. 사회적 현상이지만 과학적 내용으로 해석할 수 있고, 컴퓨터을 이용한 활용이지만 그 문제의 근본을 보면 우리 사회를 바라보는 새로운 시선을 얻을 수도 있다고 믿었다. 그리고 비슷하지만 어떤 주제이든 기본을 말하는 것이 가장 어렵다. 기본은 적용할 수 있는 범위가 넓지만 그만큼 광범위하다는 뜻이기도 하다. 광범위하다는 것은 다양한 분야의 지식을 가진 사람들에게 이끌어 낼 수 있는 공감대의 크기가 클 수 있지만 구체적이고 세부적인 때로는 편견의 시선에 쉽게 공격받을 수 있다는 말이기도 하다.

결과적으로 하고 싶은 이야기는... 

인터넷에 수많은 지식들은 꼭 블로그를 통해서 소개하지 않더라도 이미 많은 사람들이 소개했을 것이라고 생각한다. 그리고 그런 지식들이 여기에서 얻을 수 있는 내용보다 더 정확하고 더 실용적이라 생각한다. 블로그의 글들을 옮기면서 느껴지는 부분들이 많았다. 개인적으로 병원 치료때문에 단기적인 기억을 잃은 적이 있었다. 기억의 상실이 어떤 기분인지 경험하지 않은 이들에게는 설명하기 힘든 답답한 그 자체이다. 블로그 글들을 옮기면서 일부러 한번 더 본다. 그런데 이 글을 쓸 때 나는 도서관 8층에서 멀리 유리창문을 보면서 심지어 건너편에 어떤 사람이 있었는지까지도 기억이 난다. 새로운 글을 쓰다 보면 연결된 내용으로 예전에 쓴 글이 떠오른다.

불편함이 없다면 변화도 존재하지 않는다. 불편함은 변화할 수 있는 기회이다.

복잡하고 어렵지만, 블로그의 글들을 모으면 결국 내가 무엇을 원하고 무엇을 추구하는지 가장 기본적인 불편함에 도달할 수 있을 것이란 생각이 들었다. 그리고 그 기본적 불편함은 문제점을 발견하는 기회로 주어진다. 그리고 그 불편함의 다양한 시선들을 생각한다면 창의적 결과물이 나올 수 있을거란 믿음에서 계속하게 되는 것 같다. 예전에 쓴 글들을 바라보며 '아... 왜 저렇게 밖에 못 썼을까...' 란 후회가 더 크게 남는 것들이 대부분이었다. 그래서 옮기는 것이 의미가 있을까 싶었는데 옮기는 과정에서 느낀 많은 '불편함'이 그동안 그래도 블로그에 글을 남길려고 하는 원동력이었다는 생각을 하게 된다.

불편함의 기회 ... 그것이 아마도 블로그의 새로운 글들을 만들게 될 새로운 주제가 될 것이다.

불편함이 주는 기회 ─ 문제 해결과 창의적 결과에 대해서

인터넷과 문서 작업만 하는 사용자부터 복잡한 작업을 하는 전문가까지 대부분의 컴퓨터 사용자들이라면 자신도 모르게 접하는 기본적인 작업이 존재한다. 아무리 정리 정돈을 하지 않고 막쓰는 사용자라 해도 최소한 저장하는 자료들이 존재한다. 스마트폰이 보급되기 이전 개인적으로 가장 신경쓰는 자료들이 무엇인지 생각해보면 주소록 (contacts) , 일정 (calendars) , 메모 (memos) 을 생각할 수 있다. 예전 팜(Palm, Inc)의 제품들은 개인이 관리하는 자료들의 중요성을 보여준다. 모든 것을 기억할 수 없는 인간의 한계는 필연적으로 저장잘하는 기계의 필요성을 요구하게 되었다.

어린 시절 카시오(Casio) 의 데이터뱅크 시계는 가지고 싶은 물건이었다. 시계에 하나씩 입력한 친구의 전화번호를 저장하고 당시 다이얼 톤으로 전화걸 수 있는 전화에 시계를 대고 버튼을 누르면 바로 전화를 연결해주었다. 당시 누릴 수 있는 가장 첨단의 기술이었다. 기본적으로 저장할 수 있는 기계를 만들면서 사용자는 어떻게든 자료를 저장하는지에 대한 본능적인 필요성을 가지게 된다. 이제는 쉽게 스마트폰으로 많은 사람들이 관리할 수 있게 되었지만 여전히 자료의 관리가 어떤 역할을 하고 어떤 이득을 얻을 수 있는지에 대한 내용은 많이 다루어지지 않는 것 같다. 그런 의미에서 주소록을 통해서 자료 관리를 어떻게 해야 더 많은 이득을 얻을 수 있고, 잘 모르는 기능으로 불편하지 않을 수 있도록 살펴보려 한다.

├ 주소록의 기본 내용

구글이나 페이스북 등 어떤 소셜네트워크 서비스를 시작해도 가장 먼저 물어보는 필수적인 과정은 기존에 자신이 가지고 있는 주소록을 통해 자신의 주소록에 있는 사용자들이 이미 가입되어 있는지 알려주는 과정이다. 그만큼 주소록은 개인의 자료가 관계망 서비스에서 연결될 수 있는 중요한 자료가 된다. 주소록은 기본적으로 자신이 가진 지인의 이름, 주소, 연락처 정보 등을 저장하여 지인의 정보를 저장하는 방법이다.

만약 주소록이 정리가 되어 있고 원하는 사람을 찾는다고 할 때 무엇으로 찾는지부터 생각해보자. 예를 들어 갑자기 어떤 일에 도움을 받아야 하는데 그 일에 전문가였던 사람을 주소록에서 찾는다고 할 때를 생각해보자. 아주 간단한 질문이지만 이 질문은 우리가 왜 주소록을 관리하는지에 대한 근본적인 질문을 생각하게 한다. 친목이 목적이든 업무가 목적이든 우리가 어떤 인물을 생각할 때는 아무런 조건없이 바로 생각해 낼 수 있는 사람들은 그리 많지 않다는 것에 놀랄 때가 많다. 그런 현상은 나의 주소록을 대신 저장해주는 좋은 기기들이 생기면서 더욱 심해진다. 어릴 때 친구 집 전화번호 몇십개 정도는 기본적으로 기억하고 몇십년이 지난 지금도 그 전화번호가 기억나는데 요즘 자라나는 아이들에게 그런 것을 물어보면 그것을 '왜 기억해야 하는지 그 필요성도 느끼지 못할 때가 많을 것이다.'

결국 우리의 기억력을 대신해 저장해주는 주소록과 같은 자료 (데이터) 들은 왜 필요한지에 대한 근본적인 질문을 할 필요성마저 잊어버리기 쉽다.

1. 주소록을 찾는 이유는 무엇인가? 
2. 주소록을 통해 우리가 얻고 싶은 것은 무엇인가? 
3. 똑똑한 사용자가 사용하는 똑똑한 기기 (스마트 기기) 는 무엇일까? 

아주 간단하지만 이 세가지에 대한 질문을 해결하면서 아주 사소한 주소록이란 대상으로 자료 관리의 중요성에 대해서 잠시 살펴보려고 한다.

├ 데이터베이스 필드의 중요성

같은 질문을 반복한다. 오랫만에 누군가를 찾고 싶을 때 주소록에서 어떻게 찾는가? 예전에 같이 일하던 동료분중 데이터베이스 튜닝 (turning) 에 대해서 질문하면 항상 친절하게 답변해주는 분이 계신다. 지금은 전혀 다른 분야에 있고 그분은 지금 호주에서 IT 관련 회사에 계시지만 요즘도 이메일을 보내면 아는 범위에서 도움을 주신다. 그런데 항상 필요할 때마다 그분의 성함이 잘 생각나지 않는다. 회사에서도 이름을 부르기 보다는 성과 직함을 합쳐 불렀기 때문에 우리가 기억하는 이름 (호출 이름) 과 실제 이름은 다를 때가 많기 때문이다. 이런 예가 아니라도 우리가 누군가를 찾을 때 직업에 따라서 이름으로 직접 알아내서 찾는 경우가 더 힘든 경우가 많다는 것을 알 수 있다. 예를 들어 보험 상품 판매하는 영업사원 분들에게는 수많은 고객들의 이름보다는 자신이 기억하는 특징이나 특이점이 더욱 기억에 남을 것이다.

주소록은 이름을 통해서 검색할 수 있는 자료 저장소이기도 하지만 우리의 기억과 단서의 불완전성 (imperfection of memories & clues) 때문에 찾으려는 대상에 대한 희미한 단서를 통해서 재현하여 찾게 되는 것을 알 수 있다. 그런 이유때문에 대부분의 사람들은 자신이 기억하기 쉬운 이름으로 저장하게 된다. 그러나 이또한 모순적이다. 대부분 그렇게 기억하기 쉬운 이름으로 저장된 대상들은 그렇게 기억하지 않아도 쉽게 기억하고 친숙한 사람들이기 때문이다. 즉, 자신이 잘 아는 별명으로 저장하든 실명을 저장하든 별로 찾는데 불편을 못 느끼는 사람들이란 점이다.

검색의 대상은 이름 뿐만 아니라 주소록의 항목 안의 내용까지도 포함된다.

주소록 (contacts) 은 한국어와 영어에서 그 역할과 목적을 알려준다. 주소록의 역할은 내가 알고 있는 사람들의 주소 (address) 를 기록하는 자료들이고, 목적은 연락하기 (to contact) 위해서이다. 그리고 목적을 달성하기 위해서 앞서 이야기한 '내가 찾고자 하는 사람 (person whom I want to contact)' 을 찾기 위해 가능한 많은 기억과 단서 (memories & clues) 를 기록할 필요가 있다. 사용자가 구성하는 항목들은 그런 기억과 단서들이라고 생각하면 된다.

여기에서 기본적으로 데이터베이스에 대한 개념을 생각해 본다. 데이터베이스 (Database; DB) 란 자신이 가진 데이터를 타인과 공유할 목적으로 자료를 일정한 규칙과 표준에 맞게 정리하고 저장한 체계적인 구조를 말한다. 기술적으로 어려울 수 있지만 우리의 모든 일상적인 자료들을 좀 더 체계적으로 관리하는 것 모두를 데이터베이스라고 이야기해도 된다. 그리고 가장 쉬운 예로 주소록을 살펴볼 수 있는 것이다. 데이터베이스의 궁극적 목적은 자료의 저장이 아니라 자료의 검색 (query) 이다. 궁극적 목적이 중요한 이유는 자료의 원할한 검색을 위해서 자료의 저장은 조금 불편을 감수할 필요가 있다는 점이다. 한때 아이폰이 보급되면서 쉽게 볼 수 있는 질문은 기존에 가지고 있던 주소록을 어떻게 아이폰에 넣는가. 혹은 어떻게 자신이 원하는 서비스로 주소록 자료들을 손실없이 옮길 수 있는가였다. 이러한 시기는 기존에 주소록을 노트북 / 데스크탑에서 관리하다 아이폰과 같은 스마트폰으로 주로 관리하게 되었다는 점을 시사했다.

주소록의 구조를 살펴보면 한 사람의 이름, 이메일, 주소와 관련된 정보들이 저장된 하나의 카드의 개념으로 구성된다. 하나의 카드는 데이터베이스에서 레코드 (record) 라고 부른다. 한 사람에 대한 모든 정보를 체계적으로 한 곳에서 모아서 저장해 놓은 것이다.

├ 주소록 목록 정리 팁

컴퓨터를 잘 다루는 사람들도 주소록을 살펴보면 가끔 놀랄 때가 많다. 주소록 자료가 제대로 옮겨지지 않는다고 해서 살펴보면 주소록에서 '성 [last name]', '이름 [first name]' 특히 자신만이 알고 있는 별칭 [nickname] 까지도 '이름' 항목에 들어가 있는 것이다. 그동안 사용하는데 별 문제가 없었지만 이렇게 통합(?) 되어버린 이름은 자료는 저장되어 있지만 체계화, 구조화되어 있다고 말할 수 없다. 그렇다면 왜 '성', '이름' 과 같은 항목을 구별해서 입력하는 것이 좋은가?

개인적으로 이 부분을 설명할 때 쌀과 콩을 섞어 버린 상황에서 쌀과 콩을 함께 먹으면 상관없지만 어느날 콩은 먹기 싫어 콩을 골라내야 하는 경우를 이야기한다. 쌀과 콩이 분리되어 있으면 그만큼 자신의 기호에 따라서 쌀만 먹을 수도 쌀과 콩을 섞어 먹을 수도 있지만 한꺼번에 섞여 있는 경우 쌀만 먹고 싶으면 골라내야 하는 수고가 필요하다. 열역학적 (thermodynamics) 으로 섞이지 않은 경우 엔트로피가 낮지만 이미 섞여 버린 경우 엔트로피가 높아서 높은 엔트로피 상태에서 낮은 엔트로피 상태로 가기 위해 (비가역) 별도의 에너지 (수고) 가 필요하고 효율도 좋지 않을 뿐 아니라 경우에 따라서 불가능한 경우도 존재하게 된다. 주소록을 구성하는 데이터베이스에 적용하면 성과 이름이 분리되어 있는 경우 성과 이름을 함께 표시할 수 있지만 성과 이름이 이미 하나로 저장되면 성과 이름을 분리해서 표시할 수 있는 방법은 별도로 분리하는 작업 이외 방법이 없게 된다. 데이터베이스에서 '성', '이름', '회사명', '직책', '전화번호' 등과 같은 항목을 필드 (field) 라고 부른다. 상식적으로 데이터베이스에서 필드는 보다 구체적이고 세분화되어 있을 때 더 효율적일 수 있다. 반면 이렇게 각 필드에 맞춰 저장하는 것에는 불편함이 있다. 입력할 때 각 항목을 세부적으로 입력해야 한다는 점이다. 이 부분은 앞서 말한 것처럼 데이터베이스는 자료의 저장보다 자료의 검색에 더 목적을 가진다는 점에 동의한다면 조금은 감수해야 할 불편으로 남을 것이다.

개인적으로 사용하는 저장하는 방법을 소개한다. 지극히 개인적인 방법일 뿐 자신에게 적합하고 더 편한 방법이 존재한다면 그것을 따르기 바란다. 아무리 좋은 데이터베이스 시스템이라도 자료를 입력하는 사용자 (관리자) 에 따라서 그 효율은 큰 차이를 가진다. 결국 자신에게 가장 맞는 자료의 입력 방법을 찾는 것이 주소록 관리의 시작이 될 것이다.

개인 이름 입력 방법: 주소록은 이제 기본적으로 성 [last name] , 이름 [first name] 과 중간 이름 [middle name] 과 접미명 [suffix] 와 경칭 [prefix or title] 로 구성된다. 한국인의 경우 중간이름이 거의 없지만 서양 문화권 뿐만 아니라 중국계 미국인을 비롯한 해외 거주 동양인의 경우 자신의 원래 이름과 영어 이름을 쓰는 경우가 있기 때문에 기본적으로 세가지 필드를 잘 활용하면 좋다. 그리고 중요한 부분이 별명 [nickname] 이다. 우선 각각의 필드의 활용법을 간단하게 설명하면...

조금은 번거롭지만 성, 이름을 구별해서 저장하면 이후 검색 효율 및 주소록 정보를 타 서비스에서 사용할 때 유용할 수 있다.

• 경칭 (prefix or title): 주로 Mr. Ms. 와 같은 경칭이 붙지만 일반적으로 Mr. 와 같은 통상적인 부분을 모두 붙이기는 어렵다. 따라서 자신의 원칙에 따라서 필요에 따라서 Dr. 혹은 Senator, Fr. 의 경우 붙여준다. 이름이 한국어인 경우 적절하게 박사(님), 신부님 과 같이 붙여주면 된다. 호칭을 위한 목적이기 때문에 명함에 나타나 있는 이름 뒤에 붙는 자격 내용 (M.D. , F.A.A.P. M.P.H. 와 같은) 을 호칭으로 넣지 않는다. 개인적으로 사용한 경칭 중 가장 특이한 것은 Sir (영국의 경) 이다.
• 이름 (first name): 가능하면 정식 이름, 명함에 표시된 이름을 입력해준다. 만나서 명함을 받거나 인사를 나누고 성과 이름이 무엇인지 몰라서 물어보는 것은 실례가 아니기에 바로 물어보는 것이 좋다. 오히려 이후 성과 이름을 혼동하는 것이 더 큰 실례가 될 것이다.
• 중간 이름 (middle name): 특별한 경우가 아니라면 John F. Kennedy 와 같이 중간의 줄임으로 F. 만 기록해도 문제가 되지 않는다.
• 성 (last name): 특별한 철자의 성이 있을 수 있기 때문에 철자를 확인하고 입력하는 것이 필요할 것 같다. 경우에 따라서 성은 다른 이름과 구별되기 위해 모두 대문자 (capital) 로 표시하기도 한다. (e.g.: Seungho Philip JEONG )
• 접미명 (suffix): 세례명을 입력하기 위해서 사용한다. 가끔 Jr. 혹은 III (3세) 와 같은 이름에 사용되기도 하지만 막상 그런 사람을 만난 경우도 없고 그런 경우가 생겨도 필요할 때 넣어주면 되기 때문에 세례명으로 이용하는 것이 개인적으로 가장 효과적이었다.
• 별칭, 별명 (nickname): 연락처 (주소록) 서비스에 따라서 지원 여부가 다르지만 별칭은 검색할 때 유용하게 사용될 수 있다. 예를 들어 한글이름으로 입력했지만 실제 부르는 이름이 다른 경우, 예를 들어 중국인 친구 중에는 Ming Yun 이란 이름을 가지고 있지만 단 한번도 이렇게 부른 적이 없다. 이런 경우 별칭 부분에 실제로 자주 부르는 이름인 Raymond 를 넣어주어 검색과 이름 표시에도 알아볼 수 있게 해줄 수 있다. 특히 공식 이름 (legal name) 을 사용하는 회사나 기관의 내부 디렉토리 서비스로 연락처를 공유하는 경우 이러한 별칭 잘 활용하면 유용하다. 

업체 (상호) 이름 입력: 이미 예전 글 [ 개인 데이터 백업 - 웹에 퍼진 내 정보들 ; blog.meson.kr/367 ] 에서 간단하게 소개했다. 많은 경우 사람 이름에 대해서는 쉽게 익힐 수 있지만 업체의 경우 대부분 한 항목에 몰아 입력하는 경우가 대부분이다. 주소록 데이터베이스의 목적은 잘 저장하기 보다는 잘 검색하기 위해서라는 점을 다시 강조하고 싶다.

먼저 표시되는 형식을 살펴볼 필요가 있다. 한글로 입력한 항목에 대해서는 일반적인 경우

[경칭] [성][이름][접미명] 

영문이나 기타 라틴계열 언어로 입력된 경우,

[Prefix] [First Name] [Last Name], [Suffix]  (띄어진 공간 유의)

형태로 표시된다. 먼저 업체 상호명을 몇가지 주로 사용하는 대상을 중심으로 살펴보려 한다. 음식점, 금융, 천주교 등을 통해서 한글 표시 이름을 살펴본다.

음식적의 경우 어떤 음식이 땡기는지 결정하는 과정을 생각해보는 것이 좋을 것 같다. (물론 이 부분은 개인적 차이가 있기 때문에 개인적 취향에 맞추는 것이 좋을 것이다.) 먼저 음식의 종류를 생각한다. 그런 이유로 [성] 에 표시되는 항목에 음식의 큰 종류, 양식, 한식, 중식 등으로 표시하고 이탈리안, 멕시칸 등과 같은 음식을 별도로 표시할지 양식의 한 부분으로 표시할지는 개인의 취향으로... 그리고 이름은 음식점 상호명을 넣고 경우에 따라서 접미명는 지점명 예를 들어 명동점, 홍대점을 표시한다. 그렇게 표시하면,

[한식][맛있는 한식집][홍대점] 으로 입력되어 한식맛있는 한식집홍대점 과 같이 표시된다.

금융의 경우 비슷한 방법으로 [성] 을 대분류인 [금융] 으로 입력하고 [이름] 에는 [대박은행] 으로 넣는다. 비슷하게 지점명은 [접미명] 에 넣어주면 된다. 그런데 같은 대박은행의 경우 고객센터도 있고 알림 서비스, 일반 업무 내용이 있기 때문에 이런 업무의 성격에 따라서 [경칭] 부분에 [고객센터], [알림], [비지니스] 와 같이 넣어주었다. 이렇게 해서 표시되는 이름은

고객센터 금융대박은행 , 고객센터 금융대박카드 , 비지니스 금융대박은행잠원점 과 같이 표시가 된다. 카드 사용을 문자 번호에 [알림] [금융][대박카드 긁었군 +_+] 과 같이 입력하면 카드 쓰면 문자 보낸이가 '알림 금융대박카드 긁었군 +_+' 으로 표시된다.

천주교 성당의 경우 기관이 수도원, 성당, 성지 등 다양한 형태가 있는데 개인적으로 이 경우

[경칭] [성][이름] 을 각각 [천주교] [대성당][명동] 과 같이 표시했다. 위의 금융과 비교해서 입력한다면 이름 부분에 천주교라는 대분류가 들어갈 수 있지만 그렇게 하지 않고 경칭에 [천주교] 라 입력한 이유는 우리가 찾을 성당은 여러 곳이 있을 수 있지만 명동 이라는 이름으로 한두곳으로 특정되어지기 때문에 [이름] 부분은 그런 성격이 가능한 대상을 입력한 것이다. 이 원칙은 위의 금융의 예에서도 동일하다. 따라서 개인적인 원칙은 ⓐ 특정되어지는 중심 이름이 [이름 ; first name] 에 들어가도록 한다. ⓑ 성은 큰 분류를 입력한다.

영문의 경우도 마찬가지이다. 예를 들어 dropbox 의 이메일 주소에 대한 주소록을 예로 들면

[Prefix] [First Name] [Last Name] 의 경우 [Service] [Dropbox] [Cloud] 로 입력하여 결과적으로 주소록에는

Service Dropbox Cloud 와 같이 표시된다. 비슷한 방법으로 음식점의 경우에 한글 입력과 동일하게 입력하여,

[Delicious Taco] [Mexican], [North End] 와 같이 입력하면 Delicious Taco Mexican, North End 와 같이 주소록에 표시된다. 어디까지나 업체 상호에 대한 입력은 개인적인 취향이기 때문에 자신만의 규칙을 통해서 통일되게 입력하면 될 것이다. 그러나 이렇게 하는 것을 좋아하는 사람도 있지만 막상 이런 부분에 대해서 귀찮아 하는 사람들도 많을 것이다. 왜 이렇게 세부적인 필드와 그에 따른 저장이 유용한지는 이후 데이터의 연동과 가공에 대한 부분에서 좀 더 생각해볼 것이다.

├ 데이터 정렬 (sorting) 에 대해서

데이터베이스를 구성하는 과정에서 데이터 (자료) 를 잘 입력하는 것도 중요하지만 그와 함께 조금 생각해볼 문제가 하나 있다. 바로 데이터 정렬 (sorting) 에 대한 문제이다. 데이터를 정렬하는 이유는 아주 간단하다. 우리가 입력한 순서대로 보여주는 페이스북의 글같은 성격도 있지만 주소록과 같이 입력한 시간과 상관없이 일정한 출력의 규칙이 필요한 데이터도 있기 때문이다. 사실 데이터가 많아지고 검색에 의존할 수 밖에 없는 데이터의 양이라면 정렬은 사용자의 몫이 아니라 데이터베이스가 얼마나 잘 설계되어 잘 짜여졌는가에 달렸다.

문제: 지하철의 차량 번호는 규칙을 가진다. 1호선의 첫번째 차량 번호가 1001 이다. 하루에 운행되는 총 차량이 아무리 많아도 999대가 넘지 않는다면 첫 역에서 출발하는 순서대로 001, 002 ... 와 같이 붙이면 된다. 그리고 1호선의 경우 1001, 1002, ... , 1320 (만약 마지막 차량이 320 번이라면) 으로 표시하면 될 것이다. 그런데 도시가 복잡해져 2호선, 3호선 결국 9호선까지 운영되고 10호선이 만들어져서 운행되어야 한다면 10호선은 차량번호를 어떻게 부여해야 할까? 

이 문제를 듣고 해답을 내는 방식에 따라서 생각하는 방법이 얼마나 다양하고 학문적 배경에 따라서 다를 수 있는지에 대해서 볼 수 있다. 어떤 이들의 대답은 간단하게 10001, 10002, ... ,10231 .. 과 같이 표시하면 된다고 할 것이다. 그런데 만약 차량 번호에 따른 운행 효율과 같은 각 차량에 따른 통계를 낸다고 해서 1호선부터 10호선까지 차량번호로 정렬을 하면 1호선 다음 2호선이 아닌 10호선이 들어갈 수 있다는 것을 알게 될 것이다. 즉, 인간의 인지 능력으로는 자릿수가 늘어난 것으로 인식하여 순서를 알지만 컴퓨터의 계산과 정렬에서는 특별한 규칙을 부여하지 않는다면 1호선 다음 10호선을 정렬할 것이다.

논리학이나 이공계의 수리 체계에 대해서 지식이 있다면 10호선이라고 해서 꼭 10 으로 표시하지 않고 A001, A002, ... ,A231, ... 과 같이 9 다음 A 가 들어와도 문제가 없다는 것에 대해서 이해하고 있을 것이다. 이 경우 데이터의 정렬은 자연스럽게 해결될 수 있다. 이처럼 데이터의 정렬의 문제는 데이터베이스의 설께에 많은 고민을 줄 수 있다. 일련 번호 (serial number) 는 그런 의미에서 생각해볼 필요가 있다. 반대로 주소록에서 비록 성, 이름과 표시되는 모든 이름이 동일하다고 해도 같은 주소 자료가 아니라는 것을 알 수 있다. 즉, 데이터는 중복될 수 있는 항목과 중복될 수 없는 항목이 존재한다는 사실을 이해할 수 있다. 예를 들어 실수로 한 사람에 대한 주소 정보를 두번 입력했다고 해도 사용자에게 같은 사람이지만 자료를 저장한 데이터베이스의 입장에서는 다른 존재이며, 다른 레코드이다. 즉, 각 레코드의 각 항목 (필드) 정보들이 동일하다고 해도 같은 레코드가 아니다. 이는 주소록 레코드에는 사용자에게는 보이지 않는 고유한 일련 번호가 부여되어 있기 때문이다.

데이터베이스에서 얼마나 빨리 내가 검색한 키워드에 맞는 자료를 찾아내는가의 문제는 바로 얼마나 빨리 정렬하고 이 정렬된 자료를 보여주는가이다.

├ Join 을 통해 통합하는 방법 

스마트폰이나 타블렛에서 여러개 계정에서 주소록을 가지고 오면 서로 합쳐지고 중복되면 어떻게 할까 걱정하는 사람들이 있다. 예를 들어 계정 A 에서 가지고 온 Peter Wang 이란 사람의 주소록과 계정 B 에서 가지고 온 Peter C. Wang 이란 사람이 동일한 사람일 때 동일한 사람이 중복되어 표시되는 것도 마음에 안들 수 있기 때문이다. 계정 A 주소록에 Peter C. Wang 이란 레코드와 Peter Wang 이란 레코드가 모두 존재한다면 계정 A 에서 중복 제거 (Merge) 기능을 통해 두개의 레코드를 하나로 합칠 수 있다. 그러나 이 경우 앞서 설명한 일련 번호는 하나가 되고 레코드도 당연히 하나가 되는 것이다.

그러나 스마트폰과 같이 여러개의 계정의 주소록을 가지고 온다면 어떻게 되는 것인가. 이 경우 각 계정의 일련 번호는 원본 그대로 유지하지만 동일인이기 때문에 하나의 주소록처럼 보이게 하는 방법이 있다. 만약 두 계정에서 각각 온 두개의 주소록 레코드가 동일인이란 확실한 증거(?)가 있다면, 예를 들어 이메일 주소가 동일하거나 전화번호가 동일하다면 자동으로 합쳐주어 표시해준다. 그러나 표시하는 방식이 다르거나 이메일 주소가 각각 다른 경우 자동으로 합쳐주지 못한다. 이 경우 사용할 수 있는 방법이 바로 Join 이란 방법이다. 예를 들어 계정 A 의 Peter C. Wang 과 계정 B의 Peter Wang 을 하나로 보고 싶다면 Peter C. Wang 에서 편집 (Edit) 으로 들어가 메뉴에 보면 Join 을 선택하면 주소록 중 가장 근접한 주소록 레코드를 보여주거나 사용자가 원하는 자료를 검색할 수 있다. 검색후 선택하면 두개의 다른 계정에서 가지고 온 레코드는 마치 하나의 레코드처럼 보여준다.

주소록의 개인 레코드에 들어가서 편집을 선택하면 다른 계정에서 가지고 온 동일인의 주소록을 Join 할 수 있다. Viber 에 등록된 주소록의 경우 연동이 되고 바로 해당 서비스로 연결해서 사용할 수 있다.

이 기능을 제대로 활용하지 못해 중복되는 주소록을 임의적으로 지우거나 편집하여 원본 주소록이 삭제되거나 변경되는 경우가 있거나 때로는 원본 주소록을 수정할 권한이 없는 경우에는 불필요한 주소록들이 만들어지는 경우가 많다. 따라서 원칙적으로 아무리 많은 계정의 주소록을 가지고 와도 입력을 위해 사용하는 계정을 정하고 그 외의 계정은 손대지 않고 Join 하는 방법으로 하나의 레코드처럼 보여주게 하는 방법을 권장한다.

반대로 두개의 레코드가 합쳐진 경우에는 분리시킬 수 있다. 이 경우 Separate 를 사용하면 된다. Join 의 경우 두개의 레코드 뿐만 아니라 여러개의 계정에서 가지고 온 레코드를 모두 합칠 수 있다. 이 방법을 주목할 필요가 있는 것은 기본적으로 우리가 어떤 자료를 저장하는 방식에 대해서 생각하게 한다. 즉, 한곳에 집중해서 모든 항목을 포괄할 수 있는 거대한 데이터베이스를 만드는 것이 아니라 다양한 목적으로 만들어진 별도의 데이터베이스 (자료들) 을 서로 연결될 수 있는 지점 (이메일 주소, 전화번호) 등을 통해서 하나의 레코드처럼 표시하여 여러개의 데이터베이스를 포괄하는 새로운 메타-데이터베이스를 만들 수 있다는 점이다. 두번째는 개발자 입장에서 생각해보면 각 계정 (content provider) 에서 제공하는 레코드들의 고유성을 그대로 유지하면서도 개발자의 입맛에 맛는 새로운 데이터베이스를 만들고 운영할 수 있다는 것이다. 이런 것이 가능한 이유는 앞서 설명한 각 레코드의 고유성을 지킬 수 있는 일련 번호를 가지고 있으면서 단말기 (스마트폰, 타블렛 등) 에서 표시되는 새로운 형태의 정렬된 데이터베이스를 통해 검색할 수 있기 때문이다.

├ 소셜 서비스와 연결하기

구글+ (Google+) 가 무엇이냐고 물어보면 대부분 페이스북이나 트위터와 같은 것이라 대답할 것이다. 간혹 남자들만 우글거리는 그런 공간? 이라 대답하는 경우도 보았다. 그러나 구글+ 의 중요한 부분은 개별(user)이 만들어 낸 자신의 정보들이 하나의 주소록처럼 만들어지는 공간이 될 수 있다는 점이다. 그 과정은 다음과 같다.

• 구글+ 에서 자신의 이메일, 주소, 직업 등의 정보를 입력한다. → 자신의 지인 혹은 원하는 사람들과 관계를 맺는다 → 공개 권한에 따라서 상대방에게 자신의 정보가 공유된다. → 자신의 구글+ 에는 자신과 관계 맺은 사람들의 주소록 정보들이 모아진다. → 이 구글+ 계정을 단말기를 통해서 제공받는다. 

기존에 주소록은 자신이 입력한 내용에 기초하지만 이제는 소셜 서비스에서 각자 개인이 입력한 최신 정보들이 바로 공유되게 된다. 많은 부분 공감하지만 예전에 입력한 주소록의 정보 중 대부분은 전화번호가 변경되어 더 이상 쓸 수 없는 경우도 많다. 심지어 영구적으로 쓸 것 같은 이메일도 회사를 옮기거나 위치가 바뀌면서 더이상 쓸 수 없는 정보들도 많아진다. 그러나 소셜 서비스와 연결된 항상 업데이트 되는 내용들은 구글+ 라는 계정을 통해서 항상 사용가능한 정보들로 업데이트 된다. 따라서 구글+ 나 페이스북에서 주소록을 스마트 단말기와 동기화 (synchronization) 할려는 가장 큰 이유는 사용 가능한 주소록 정보를 받아 볼 수 있도록 하기 위해서이다.

그러나 이 부분에서도 사용자 입맛을 만족시키지 못하는 부분이 생긴다. 바로 소셜 서비스에서 상대방이 입력한 이름이 내가 저장하고 싶은 내용과 다를 때이다. 예를 들어 나는 Wonjoo Kang 이란 이름으로 저장하고 싶은데 상대방의 구글+ 혹은 페이스북에서 이름을 '똘아이' 로 입력했다면 나의 주소록에는 '똘아이'로 표시된다. 그러나 이 경우 앞서 소개한 Join 을 통해서 내가 표시하고 싶은 방법으로 레코드를 Wonjoo Kang 이란 이름으로 만들고 이를 구글+ 나 페이스북의 레코드와 Join 시키면 된다. (Join 시 표시할 이름은 자신이 정할 수 있다. 일반적으로 표시하고 싶은 레코드로 들어가 Join 으로 다른 레코드를 불러오면 된다.)

자신이 저장한 주소록과 일치하는 구글+ 계정이 있을 때 외부 소셜 서비스와 연동(connected) 하여 보여준다. 구글 주소록은 기본적으로 구글+ 와 연동을 지원한다. 출처: googlesystem 블로그

단순히 글을 올리고 정보를 교류하기 위한 목적으로 소셜 네트워크가 주목받지만 개인적으로 그보다 각 사용자가 항상 업데이트 시키는 살아있는 데이터 (alive data) 를 연동시켜 살아있는 데이터베이스 (alive database) 를 만들고 이를 활용할 수 있도록 해준다는 의미에서 소셜 네트워크의 의미를 생각해볼 필요가 있다. 이와 같은 개념으로 퍼져있는 (scattered) 데이터를 자신에게 필요한 (focused) 데이터로 통합할 수 있는 방법을 찾고 이를 응용하는 것은 개발자에게 큰 기회가 될 수 있다.

조금 다른 분야의 예를 통해 생각해 보자. 어떤 환자가 A 라는 내과에서 당뇨 만성질환으로 치료를 정기적으로 받고 있는 환자이다. 이 환자가 갑자기 교통사고로 B 라는 정형외과에 가게 되었을 때 환자력이나 진행 중인 치료 내용을 알 수 있는 방법은 A 병원에서 소견서를 가지고 오거나 환자에게 듣거나 아니면 병원 대 병원으로 연락을 해서 업데이트 하는 방법이다. 여기에서 A , B 라는 병원을 구글+ 나 페이스북과 같은 소셜 네트워크로 생각해보자. 환자는 구글+ , 페이스북 가입자이다. 그리고 필요한 정보들은 환자의 단말기에 기록이 되어 있다. 즉, 환자의 단말기를 통해서 내과와 정형외과의 기록을 종합해서 시간 순서대로 확인할 수도 있다. 즉, 외래 환자 (outpatient) 의 경우 자신의 기록이 분산되어 있어도 이를 통합할 수 있는 단말기는 여러 계정에서 정보를 모아 확인할 수 있고 각 병원은 이를 참조하고 이에 맞게 치료를 진행할 수 있다. 그러나 이 경우 각 병원은 서로의 자료를 고치거나 삭제하지 않아도 된다. 즉, 정보의 수집 주체가 병원이 아닌 환자가 된다는 것이다. 심지어 대형 종합병원의 경우 외과 환자지만 편의상 다른 과에 가서 진료할 때 같은 레코드를 편집, 추가하는 경우가 발생한다. 이 경우 여러 계정에서 가지고 오는 주소록이 아니라 여러 계정에서 가지고 온 데이터를 그대로 옮겨 새로운 레코드를 만들어 쌓는 과정이라 생각하면 된다.

├  구글 검색을 통해 전화하기 ; 플랫폼 의 중요성

구글+ 를 통해 각자 사용자들이 업데이트 하는 신선한(?) 정보를 수집하는 형태를 이야기했다. 이와 함께 재미있게 시도해볼 것이 있다. 예를 들어 화요일 약현 성당(서울 중림동 소재)의 미사 시간을 알고 싶을 때 인터넷 홈페이지에서 검색하는 방법도 있지만 전화해서 문의할 수 있을 것이다. 검색 엔진에서 '약현성당' 이라 검색하면 검색결과가 지도와 함께 나온다. (구글 나우에서 검색해도 동일하다.) 이때 지도 아래 전화 (Call) 를 누르고 전화를 끊고 나면 전화 기록에는 '중림동 약현성당' 이란 이름과 함께 남아 있는 것을 알 수 있다. 해당 전화번호가 검색 엔진에 '중림동 약현성당' 으로 되어 있기 때문이다.

구글의 검색엔진에 등록된 장소에 대해서 관련된 전화번호, 주소 및 상호명(기관명) 이 전화기록으로 남는다.

비슷하지만 아이스크림을 먹고 싶어 Ben & Jerry 를 한번 검색해봤다. 가까운 곳에 Ben & Jerry 가 검색되고 내가 좋아하는 Boston Cream Pie 파인트로 있는지 물어보기 위해서 전화를 걸어본다. 전화 통화가 끝나고 아까와 같이 전화 기록을 살펴보면 아이스크림 그림과 함께 전화번호, 주소뿐만 아니라 구글+ 의 주소가 표시되어 있다. 구글+ 에는 지역정보에 대한 페이지가 있는데 자신의 영업 흥보를 위해 페이지를 꾸미거나 사용자들이 위치 정보로 올린 사진들이 연결된다. 원한다면 바로 주소록 추가만 눌러 바로 자신의 주소록에 저장할 수 있고 만약 전화번호가 변경되어 관리자가 변경한다면 변경된 전화번호도 내 주소록에 업데이트 될 것이다.

영업하는 주체가 직접 업데이트한 정보가 소셜 네트워크 서비스를 통해서 제공되고 제공된 정보는 개인의 주소록에 반영된다.

예전에는 주소록을 만들고 관리한다는 것이 번거로운 작업이 될 수 있었지만 소셜 서비스와 지역 기반 서비스 그리고 검색엔진이 제공하는 플랫폼 [ 검색엔진의 진화 - 플랫폼을 통한 인식의 진화 ] 을 통해서 주소록의 저장, 관리까지도 유용하고 효과적으로 만들어 주었다. 모든 단말기에서 이런 기능을 제공해주는지, 모든 검색엔진이 이런 부분까지 생각해서 설계된 플랫폼인지 모르겠다. 강조하고 싶은 점은 검색엔진은 단순히 우리가 원하는 정보를 제공해주는 역할만을 하는 것이 아닌 우리가 원하는 정보를 구성 (organize) 하고 정렬 (sort) 하여 우리에게 유용한 데이터를 단말기를 통해 재구성 (reconstitute) 할 수 있는가이다.

└ 마무리하며... 

주소록을 통해 기본적인 데이터베이스를 생각해보고, 다양한 계정 (content provider) 에서 제공된 주소록 데이터를 모아서 사용자에게 유용한 재구성된 주소록을 단말기에서 구성하는 형태를 통해 분산된 데이터베이스를 얼마나 잘 조합하면 데이터를 사용하는 주체에게 얼마나 유용한 정보를 만들어 낼 수 있는가에 대해서 생각해보고, 소셜 네트워크 서비스를 통해서 유용하고 사용가능한 데이터가 항상 유지될 수 있는 방법을 생각하고, 마지막으로 검색엔진이 주소록같은 아주 사소할 수 있는 데이터베이스까지도 얼마나 유기적으로 연결될 수 있는지에 대해서 생각할 수 있었기를 바랄 뿐이다.

주소록이란 아주 사소한 대상이지만 데이터베이스, 데이터의 관리, 유지라는 관점에서 살펴보면 생각해야 할 다양한 문제들이 생기고, 그 문제의 해결 방법을 통해서 다양한 아이디어와 그 아이디어를 확장하는 과정을 통해 다양한 분야에 적용할 수 있는 좋은 내용이 될 수 있다고 믿는다. 그런 의미에서 화려해 보이는 화면과 미사려구의 큰 효과가 없는 기능을 강조하는 많은 앱들을 사용하기 보다는 기본적 운영체제가 제공하는 기본적 철학을 충실하게 따르는 앱들의 사용만으로도 충분히 우리에게 유용한 도구가 될 수 있다. 문제는 사용자의 철학이다. 주소록이란 아주 가벼운 대상이지만 실제로 이런 개념을 확장하여 환자를 위한 데이터베이스를 만들 수 있고, 더 나아가 아주 복잡한 형태의 데이터베이스이지만 환자 맞춤형 치료 정보를 위한 거대한 데이터를 구성하고 이를 통해 보다 분석적인 해석이 가능한 방법론도 가능해진다.

아주 단순하지만 '기본으로 돌아갈 때' 우리가 놓치는 것들을 더 많이 보게 되는 것 아닐까.

주소록에 대한 단상 ─ 데이터의 관리와 진화

디지털 데이터의 증가와 개인이 저장하는 데이터의 절대적인 양 뿐만 아니라 우리가 모르는 사이에 저장되는 기록들은 결국 개인 정보가 되어 우리의 많은 것을 보여준다. 우리들이 친구와 이야기 나눈 대화 내용은 둘만의 이야기라 생각하며 솔찍한 이야기를 하게 되지만 부주의한 실수로 자신의 계정이 노출된다면 더이상 비밀이 될 수 없을 것이다. 스마트폰은 우리들이 다니는 장소를 기록하고 그 장소에 맞게 양질(?)의 정보를 제공해준다. 누가 어디서 무엇을 하는지 사소한 일상부터 자신이 열심히 작업한 대부분의 성과들도 디지털의 형태로 저장되게 된다. 심지어 아날로그 작업으로 만들어진 조각 작품, 요리와 같은 온라인 세상과 전혀 관계 없는 대상들도 이제는 사진으로 찍혀 온라인의 공간에 돌아다닐 수 있게 된다.

이처럼 우리는 알지 못하는 사이에 수많은 데이터와 개인 정보를 온라인에 뿌리고 다닌다. 때로는 사용자가 원하기 때문에, 제공하는 개인 정보에 따라서 적절한 정보를 보상받기 때문에 그런 정보의 제공을 어렵지 않게 생각하기도 한다. [ 빅데이터의 거품과 희망 ─ 개인 정보 & 공적 정보 ] 사적 영역에 대한 필요성을 이야기했다. 즉, 우리가 아무리 보안에 신경쓰고 철저하게 개인 정보를 챙긴다고 해도 그 정보를 담고 있는 시스템의 근본적 취약점으로 정보는 어느 순간 손쉽게 공개되어 버릴 수 있거나 시스템적 사용자의 허가권 (permissions) 은 그 의미가 약해질 수 있기 때문에 비록 개인 정보가 털린다 해도 지켜져야 하는 최소한의 개인 정보 영역을 '사적 영역 (privacy domains)' 으로 설정하고 이에 대한 시스템적 보안뿐만 아니라 법과 규제를 통한 보완을 마련해서 운영해야 한다는 것이다.

흩어지는 개인 정보에 대해서... 

① 누군가 무심코 올린 택배 사진에서 개인 정보 유출을 염려해서 주소 부분은 가리고 올렸지만 사진에 올라와 있는 송장 번호나 송장 번호를 나타내는 바코드를 통해 송장 번호를 알아내 상대방 주소에 대한 정보를 알아낼 수 있다. ② 구인란에 올린 자신의 정보들은 인터넷 검색에서 나타난다. 상대방의 전화번호 뿐만 아니라 개인의 신상에 대한 내용을 조금만 관심있게 살피면 알 수 있다. ③ 상대방의 아이디를 통해서 다른 웹서비스를 검색하거나 아이디를 통해서 무심코 올린 게시판의 글을 통해 어떤 시사회에 참석하는지 상대방의 동선을 파악할 수 있다. ④ 페이스북에 올라간 위치 정보, 때로는 친절하게 '우리집 내방'과 같은 위치 정보를 지정해서 올려서 집주소의 위치를 파악할 수 있다. ⑤ 위치의 메이어 (major) 가 되기 위해 자주 가는 장소에서는 꼭 체크인 (check-in) 하여 자주 출몰하는 지역을 알 수 있게 한다. ⑥ 소셜 네트워크의 설정 정보가 노출되어 자신이 어떤 핸드폰을 사용하는지 파악할 수 있게 된다.

이 밖에도 그리 어렵지 않은 방법으로 개인 정보를 알려고 노력한다면 그리 어렵지 않게 알 수 있는 방법들은 다양하다. 이런 것이 가능한 이유는 우선은 정보를 남기는 시스템 자체가 정보에 대해서 민감하지 않게 생각하여 공개가 기본이 되어 검색 엔진에 검색이 되도록 설정을 했기 때문이다. 특히 개인 정보를 담을 수 있는 게시판, 특히 상품 수령이나 이벤트 당첨과 같은 게시판은 아이디와 이름, 그리고 간단한 개인 정보까지도 공개된 경우가 많다. 또한 잘 고려하지 않는 것 중에는 PDF 문서를 내부 열람 목적으로 올리지만 권한 설정이 제대로 되지 않아 검색 엔진에 쉽게 노출된 경우도 볼 수 있다. 이처럼 우리가 생각하지 못한 경로로 우리들의 정보는 생각보다 많은 곳에 노출되어 있다. 아무리 신경써도 시스템적 한계가 존재하기 때문에 이처럼 퍼져나가는 개인 정보는 어쩔 수 없는 부분들이 많이 발생한다.

지키려는 사적 영역에 대해서... 

그런 이유로 법, 규제를 통한 사적 영역의 보호가 필요하다. 비록 자신의 개인정보가 노출되어서 누군가에 의해 악의적으로 사용이 되었을 때 강화된 처벌에 의해 악의적 사용을 했던 사용자는 법의 처벌을 받아야 한다는 사회적 책임을 법률로 정해야 하는 것이다. 이전 기술에 대한 정확한 이해가 부족했던 시절에는 해킹이 하나의 놀이 혹은 법률이 정하지 못한 범위의 행동들이어서 이에 대한 무분별한 공격과 악의적인 이용이 자주 일어났다. 인간이 만든 기술이고 근본적으로 기술을 쓰는 누군가가 존재하기 때문에 (최종 사용자 ; End User) 완벽한 시스템은 존재할 수 없다. 예를 들어 아무리 보안이 철저하여 100% 해킹이 불가능한 시스템을 만들었다고 해도 그 시스템을 사용하는 권한을 가진 사용자의 정보를 이용하면 그대로 이용가능하다는 것이다. 즉, 시스템을 사용하는 사용자가 존재하는 한 최후의 해킹은 항상 가능하다는 것이다.

이런 이유로 빈번하게 일어나는 금융 전자 사고 (해킹) 의 경우 최종 사용자를 공략하는 경우가 대부분이다. 만약 어떤 사용자가 사용하는 아이디 / 패스워드 뿐만 아니라 거래에 필요한 보안 코드 그 밖에 필요한 모든 도구를 그대로 복제해 가지고 있다면 시스템은 해킹으로 들어온 사용자를 허가된 사용자로 취급할 것이다. 즉, 인터넷 ID 와 개인정보로 이루어지는 모든 온라인 과정은 실제 사용자가 누구인지가 중요한 것이 아니라 허가된 ID 와 정보를 가지고 있는지 중요하다. 따라서 상당수의 시스템의 취약점은 사용자에게 발생하는 경우가 많다. 특히 시스템 전체 관리자도 일종의 사용자이다. 그리고 조금만 시스템 관리자에 경험이 있다면 사용자의 허가 인증보다 시스템 관리자의 허가 인증이 더 허술한 경우가 많다는데 동의하는 사람들도 많을 것이다. 결국 절대 깨질 수 없는 시스템이 불가능하 듯, 시스템만으로 보호할 수 있는 사적 영역도 불가능하다. 항상 기술적 취약점은 인간의 권한을 제한하고 책임을 물을 수 있는 사회적 통제 수단을 마련해야 한다.

무관심한 개인 정보에 대해서... 

그렇다면 왜 이렇게 개인 정보가 노출되고 시스템은 불안한데 그럼에도 불구하고 더 많은 개인 정보를 만들게 되는 것일까? 가장 큰 원인은 기술적 방향이 개인 정보를 더 끌어 들이는 방향으로 설계되고 있기 때문일 것이다. 단순한 개인의 신상 정보뿐만 아니라 개인의 위치, 선호도 뿐만 아니라 온라인 상의 관계를 맺고 있는 네트워크까지 파악할 수 있어 이웃을 분석하는 것을 통해서 개인이 제공하지 않으려는 내용까지도 알아낼 수 있다. 예를 들어 관계를 맺고 있는 온라인 상의 친구들의 정치 성향 혹은 부분적으로 올려진 개인 신상, 혹은 올려지는 글의 성격들만 모아보아도 어떤 성향의 사람인지 파악하는 것은 어렵지 않다. 겉으로는 네트워크에서 다양한 사람들을 만나볼 수 있도록 배려하는 좋은 웹서비스를 제공하는 것처럼 보이지만 관계와 활동을 통해서 개별화된 사용자를 그룹으로 묶을 수 있게 된다. 보통 네트워크를 노드 (nod) 와 라인 (line) 으로 표시한다. 자주 접할 수 있는 자신의 네트워크 관계도를 그려보면 노드에 해당하는 각 사용자들이 어떤 목적으로 모인 사람들이 주로 모였는지 그룹을 만들 수 있다. 그리고 이런 그룹들이 몇개의 그룹인지를 통해 그 사람이 오프라인에서 관계를 맺는 사람들의 관심사를 파악할 수 있다.

이런 관심사 혹은 그룹의 성격을 파악하는 것은 왜 중요할까? 우선 관심사는 광고와 연결이 된다. 막연하게 의뢰받은 광고를 올리는 것은 무척 위험하고 비효율적인 방법이다. 스포츠에 전혀 관심없는 상대방에게 스포츠 용품 혹은 스포츠 동호회 광고가 뜬다면 별로 좋아하지 않을 것이다. 그러나 사용자가 낚시에 관련된 사람들이 하나의 그룹으로 모여 있다면 이런 개인의 기호 (favorites) 를 통해 관련 광고를 적극 추천할 수 있을 것이다. 즉, 이미 소비자가 어떤 것을 좋아할지 알고 들어가는 것이다. 그러나 꼭 이런 그룹화 분석이 항상 맞는 것은 아니다. 비록 스포츠를 좋아하는 사람들이 대부분인 특정 그룹이 있다고 해도 우연히 해당 그룹은 스포츠를 좋아하는 사람이 다수인 대학 모임일 수 있다. 이런 경우에는 노드와 노드 사이 연결된 네트워크의 라인이 얼마나 활동량이 많은가 특히 특정 주제에 대한 반응이나 민감도에 대해서 분석하여 이런 예외성을 분석할 수 있다. 중요한 것은 네트워크를 맺고 있는 사람들 사이에는 사람들이 무엇을 원하는지 그 욕구를 좀 더 정확하게 파악할 수 있다는 것이다.

따라서 사용자는 무관심한 듯 자신의 이야기를 나누고 자신이 관심있는 대상을 찾아갈 뿐이지만 이를 통해 사용자가 어떤 '욕구 가능성'이 있는지 파악할 수 있게 되는 것이다. 우리가 무관심하게 흘리는 대부분의 개인정보는 그다지 우리가 정말 신경쓰지 않는 내용들이 대부분이란 점이다. 너무 일상적이고 너무 평범해서 신경쓰지 않는 정보들이 사실 우리의 자연스러운 모습, 자연스러운 욕구를 보여주는 좋은 정보가 된다. 결국 신경쓰고 가꾸는 정보들보다 무심하게 넘어가는 지극히 평범한 정보들이 우리들의 많은 것을 보여주는 것이 개인정보의 중요한 속성이다.

가치있는 개인 정보에 대해서... 

사용자들은 별로 신경쓰지 않지만 그리고 개인의 입장에서 중요하지 않은 개인 정보들도 대규모로 모으면 상업적 가치가 높은 개인 정보들이 많다.  특히 개인의 상품 구매, 활동 영역 및 관심 분야과 같이 소비자의 소비 유형과 관련이 깊은 정보들을 생각할 수 있다. 이는 사생활에 관련된 내용이지만 여러 사람들의 정보가 모이면 이는 어떤 지역에 어떤 상품이 소비가 많이 이루어질 수 있다는 좋은 마케팅 데이터가 될 수 있다. 이런 이유로 소비를 직접 관찰할 수 있는 데이터를 끌어오기도 한다. 소비와 직접 연관된 데이터는 지불에 관련된 처리를 담당하는 데이터, 예를 들어 신용카드 및 선불카드와 같이 지불의 내역까지도 확인할 수 있는 데이터가 우선이지만 적립 포인트와 관련된 정보들도 적립금이 직접 소비량과 소비 패턴, 지역 등을 확인할 수 있다. 따라서 다양한 방법으로 소비자의 구매 성향을 파악하고 이를 데이터로 관찰하려는 많은 기업들이 생기게 된다.

대부분 소비에 관련된 데이터를 모으기 위한 목적은 알려주지 않고 대부분 소비자를 위한 혜택, 포인트 결재와 같은 형태로 소비자에게 사용을 유도하게 된다. 특별히 개인의 입장에서 사소한 사생활을 조금 넘기는게 뭐 문제가 되지 않거나 그보다 더 큰 혜택이 주어진다는 보상 심리에 별 부담없이 사생활을 넘기기 쉽다. 즉, 우리가 무의식적으로 넘기는 대부분의 개인 정보는 어떤 과정으로 어떤 기관, 회사에 그 정보가 저장되고 그 정보가 어떤 목적으로 사용될 수 있다는 내용은 알기 힘들고 오히려 눈 앞에 보이는 실질적 이득에 더 집중하게 되게 된다. 즉, 개인 정보와 맞 바꾸는 무엇인가가 존재한다는 사실은 제대로 파악하기 힘들다 왜냐하면 그런 이득은 당장 몇명의 개인 정보로 나타날 수 있는 모습은 아니지만 기과 및 회사가 약속하는 당장의 포인트 및 할인 혜택은 눈 앞에 실질적 이득을 보이기 때문이다. 그러나 이윤을 목적으로 하는 기업이 이득이 일어나지 않는데 무료로 자선사업을 할 이유는 없다.

냉정한 입장에서 구글의 다양한 서비스가 무료라고 이야기하는 것은 거짓이다. 개인이 서버를 구매하고 이를 운영하며 이메일 서비스 및 관련된 서비스를 사용하려고 해도 기본적인 운영 비용이 들어간다. 단지 사용자의 인터넷 사용을 향상시키기 위해서 다양한 서비스를 무료로 제공한다고 해도 사용자들은 이미 다양한 인터넷 광고 시스템의 소비자가 되어 있는 상태이다. 문제는 능동적 사용자인가, 수동적 사용자인가이다. 능동적 사용자라면 자신의 관심사에 맞게 알맞는 상품들을 보여주는 광고가 신기할 것이다. 수동적 사용자라면 다소 귀찮고 불편해도 그리 쓰는데 불편을 느끼지 않을 것이다. 미국에서 웹 사이트 개발자로 일하는 친구의 이야기를 인용하자면 인터넷 광고의 묘미는 사용자가 '나를 괴롭힐 정도로 광고가 많지 않다고 느낄 정도의 정돈된 템플릿 속에서도 순간 보이는 잠깐의 광고가 더 효과적'이라고 이야기한다. 이와 동시에 보다 넓은 영역에서 광고를 잠깐 잠깐 노출시키는 것이 더 효과적이란 것이다. 즉, 개인 사용자의 블로그를 적극 활용해서 이를 하나의 광고 플랫폼으로 이용하도록 끌어 들이는 것도 좋은 전략이 된다는 것이다.

이에 비해 국내의 많은 광고 시스템은 복잡하고 심지어 본문 내용을 방해하거나 광고를 클릭하지 않으면 찾았던 내용을 볼 수 없는 수준까지 화면 구성을 만드는 경우가 많다. 특히 언론사까지도 양질의 기사를 보여주기 보다는 광고를 위해 기사가 존재하는 것이 아닐까 싶을 정도이고 특히 흥미유발의 기사인 듯 라인 링크를 만들어 놓고 이를 광고와 연결시키는 경우도 쉽지 않게 볼 수 있다. 소비자들이 자신의 개인 정보를 제공하려는 이유는 그만큼 충분한 보상이 느껴진다 생각하기 때문이다. 즉, 당장의 보상이 존재하지 않고 자신의 본 목적마저도 방해하는 광고가 가득하다면 사용자들은 광고에 의해 불쾌함을 느끼게 될 것이다. 광고를 단순 소비하는 소비자의 입장이든, 포인트와 할인 혜택을 위해 사생활을 제공하는 입장이든 중요한 것은 개인 정보는 분명히 가치가 있다는 것이다. 그리고 그 가치를 어떤 방식으로 뽑아낼 것인가는 사실상 인터넷 서비스 업체의 비지니스 모델이 된다. 문제는 그 비지니스 모델이 개인 정보를 상품으로 판매하거나 수집한 개인 정보가 개인들에게 예상하지 못한 무기가 되어 되돌아 오는 비도덕적 상황을 만들지 말아야 한다는 것이다.

의도적인 개인 정보에 대해서... 

개인 정보는 대부분 연결 고리를 가진다. 예를 들어 이벤트 응모를 위해 올린 이메일이 어떤 가치를 가지는지 별 생각없이 올릴 수 있다. 이렇게 올려서 인터넷에 노출된 경우 개인 정보는 어떤 곳에 가입되었는지 혹은 어떤 서비스를 사용하고 있는지 가장 기본적인 정보부터 만약 다량의 이메일 / 패스워드가 해킹되었을 때 주요 목표가 될 수 있다는 점도 생각할 수 있다. 예전에 광고 문자 / 메일이 와서 '본 광고 수신을 원하지 않는 경우 클릭해주세요' 와 같은 문구에 친절하게 대응해주는 사람을 본적이 있다. 그러나 광고를 보내는 사람이 친절하게 '이 사람은 광고를 원하지 않는구나' 하고 광고 수신 목록에서 제거해주면 고맙지만 그렇게 대응한 목록만 모으면 실제 수신을 하는 소위 '진성 사용자'를 골라낼 수 있게 된다. 즉, 실제 사용하는 사람이 있는 계정이라는 것을 확인시켜 주는 경우이다.

특히 대부분 이메일 계정을 통해 얼마나 많은 것을 알 수 있을까 ... 생각하며 습관적으로 다양한 웹 서비스에 가입하는 경우가 많다. 그러나 이는 흩어져 있는 개인 정보를 충분히 잘 모으면 한 사람에 대한 충분한 정보로 구성할 수 있는 연결 고리가 되어 준다. 따라서 이런 경우에 대비해 소셜 미디어에 가입하는 목적으로 이메일을 자주 사용하는 계정과 다르게 가입하는 것도 좋은 방법이다. 최근 이메일 서비스에는 별명 (alias) 서비스를 제공해주기 때문에 이런 별명 서비스를 활용하거나 쥐메일의 경우 자신의 계정뒤에 account+shopping@gmail.com 과 같은 형태로 이메일을 입력해도 자신의 계정에 수신될 수 있는 기능이 있기 때문에 예를 들어 ebay 에 가입할 때 myaccount+ebay@gmail.com 과 같이 지정할 수 있다. 이렇게 지정한 경우 해당 이메일이 가입 서비스 이외 다른 곳에서 노출된다면 해당 서비스가 최초 공개 지점인 것을 확인할 수 있다. [ 이메일 서비스를 생각한다 - 매력적인 웹서비스를 위해... ]

이전에는 garbage in garbage out 이라고 해서 입력 데이터가 양질 (quality) 이 아니면 결과도 양질의 결과를 기대하기 어렵다고 이야기했지만 때로는 의도된 쓰레기 값이 보안적 측면에서는 충분한 가치를 가질 수 있다는 것도 흥미로운 부분이다. 즉, 데이터는 거짓을 이야기하지 않지만 데이터를 만드는 사람은 충분히 의도를 가지고 거짓 데이터를 만들 수 있다는 것이다. 그런데 이런 쓰레기 정보들은 역설적으로 무엇이 사실인지 확인하는 수단이 될 수 있다.

의도적인 추적 정보에 대해서... 

범죄 영화를 보면 조직원 중에 첩자, 프락치 등이 잠입해서 적에게 정보를 알리거나 결정적 순간에 배신의 아이콘이 된다. 가장 기억에 남는 영화 중에 무간도(無間道; 2002) 는 경찰과 범죄 조직 사이 오랜동안 상대방의 조직과 경찰에서 성장하는 첩자를 그린다. 미국 경찰 드라마에 빠지지 않고 들어가는 이야기도 위장 경찰 (undercover) 에 대한 내용이다. 그리고 이야기 속에는 내부 첩자를 어떻게 잡아내는가, 그리고 어떻게 위기를 모면하는가를 보여준다. 대부분 내부 첩자를 잡아내는 과정은 거짓 정보를 흘려서 그 거짓 정보가 어떻게 흘러가는지 그리고 누구를 통해서 흘러가는지를 파악하기 위해 의심 인물들에게 서로 다른 정보를 주는 것이다. 앞서 예를 든 것처럼 자신의 이메일 계정 뒤에 +ebay 와 같이 특정된 (exclusively) 정보를 붙여 해당 정보가 어떻게 흘러가는지 확인하는 과정이다. 그래서 첩자는 항상 무엇이 거짓인지 무엇이 사실인지 확인하는 과정이 필요하다. 습관적으로 확인 (double check) 하고 소위 이차 계획 (backup plan; plan B) 를 구상해야 하기 때문에 첩자들은 스트레스가 이만저만 아닐 것이다.

이처럼 의도적인 추적 정보는 개인 정보가 어떻게 흘러가는지 확인하는 좋은 도구가 된다. 본 블로그에서 가장 많은 검색어 중 하나는 '페이스 북에서 친구가 뜨는 순서' 이다. 페이스북 대화목록이 어떤 순서로 보이는지 그 원리와 순서를 알고 싶어한다. 당연하지만 페이스북은 알려줄리 없다. 그런데 많은 사람들의 공통된 이야기는 우연히도(?) 자신이 관심있는 상대방... 특히 이성 친구들이 상위에 보인다는 것이다. 마치 페이스북이 자신의 깊은 속마음을 알려준다 생각할지 모른다. 그러나 알고 싶은 의욕이 강하다면 몇개의 다수 계정을 만들어서 다수의 컴퓨터 (요즘은 가상화 기술이 있어 좀 더 수월하다.) 혹은 더 원한다면 가상의 접속 위치 (Proxy 서버 및 VPN 과 같이) 를 의도하여 접속하였을 때 어떤 결과가 만들어지는 확인해 보는 것이다. 대부분 사용자들은 제한된 숫자의 컴퓨터와 제한된 브라우저 환경 특히 개인의 정보 및 접속 기록이 자세히도 기록된 브라우저로 접속한다는 것이다. 따라서 완전히 통제된 상태의 가상의 사용자를 만들 수 있다면 페이스북이 어떻게 친구 목록을 보여주는지 짐작하기 쉬울 것이다. 사실 그보다 자신이 생각했던 원리들 중 맞지 않는 내용을 제거할 수 있을 것이다. 마치 내부의 첩자를 찾아내기 위해 의도적인 활동을 만드는 것과 비슷하다.

최근 미 국가 정보기관의 일반 사용자까지 포함한 광범위한 개인 데이터 수집이 많이 이야기된다. 일반적 상식으로 국가가 그리 중요하지 않는 익명과도 같은 사용자들의 데이터를 왜 수집하는가에 의문을 품는 사람들도 많지만 한편으로 설마 나같은 개인 사용자까지 해당할까 무시할 수 있지만 수집된 양으로 보면 인터넷을 매일 사용하는 사용자들만 생각하면 최소 개인당 월 1000건 이상의 개인 데이터는 수집되었다고 한다. 단지 그런 데이터들이 별로 상관없다 (irrelevant) 판단되어 그냥 지나쳐 넘어갔을 뿐 마음만 먹는다면 충분히 캐낼 수 있다는 점이다. 이미 엉뚱하고 황당한 사건들이 많이 일어났다. 미국 여행을 가려는 유럽 사람이 자신의 트위터에 재미있게 놀겠다 란 뜻으로 '폭파해버리자' 라고 적어놓자 미국 출입국 심사에서 몇시간동안 감금되는 사건이나 페이스북에 장난으로 폭발물처럼 꾸민 친구 생일 선물을 공개하자 몇시간 후에 경찰 특공대가 자신의 집에 투입된 사건 등 개인 영역이고 자신들의 친구들만 볼 수 있는 공유 정보임에도 정부 관계자들은 이를 알아내고 과잉 대응했던 것이다. 이런 사건들이 종종 일어나자 인터넷 상에는 'SWAT (경찰 특공대) 를 자신의 집에 초대하는 방법'을 조소섞인 내용으로 돌게 되었다.

이처럼 '의도한 쓰레기 정보'들은 특정 행동, 결과가 유발되는지 확인하는 것으로 더이상 쓰레기 정보가 아닌 것이다. 쓰레기 정보들은 사실 이미 많은 부분 우리들의 정보 데이터 처리에서 많이 사용된다. 패리티 비트 (Parity Bit) 는 정보의 전달 과정에서 오류가 생겼는지 아닌지 확인하는 부가적인 데이터이다. 실제 전달하려는 데이터는 아니지만 전달되는 데이터가 전달 과정에서 소실되거나 변질되지 않았는지 확인하는 목적이다. 패리티 비트는 전송된 정보가 오류라는 사실은 알려주지만 직접 오류의 내용을 수정하지 않는다. 즉, 전송된 데이터의 패리티 비트가 맞지 않는다면 수신하는 쪽은 송신하는 쪽에 아까 보낸 데이터를 다시 보내달라고 재차 요청하게 된다. 즉, 데이터의 진실성에 대해서 확인하지만 무엇이 진짜인지는 제대로 확인할 수 없다. 유사하지만 내부 첩자를 잡아내는 과정도 비슷하다. 의도한 쓰레기 정보를 추가하는 것은 무엇이 누가 첩자인지는 확인하고 제거할 수 있지만 그렇다고 딱히 그 첩자를 제거하여 특별히 이득이 되는 요소는 없다는 점이다. 그런 의미에서 쓰레기 정보학에 추가되는 데이터들은 어떤 부분이 문제가 된다는 문제의 확인은 해줄 수 있고 어디를 고쳐야 한다는 정보는 줄 수 있지만 제거되어야 할 부분이 제거된 이후 무엇이 향상되었는지에 대한 구체적인 이득을 계산하기 어렵다는 특징을 가진다.

일상적인 추적 정보에 대해서... 

너무 완벽한 논문은 매력없을 때가 많다. 특히 오탈자 하나 없는 경우는 그렇다. 의도하지 않은 경우는 아니겠지만 가끔... 종종 논문 표절 이야기가 나오면서 가장 많은 증거로 제시되는 것은 원문에 포함된 오탈자까지도 동일하게 복사된 경우이다. 이에 다양한 변명을 하지만 사실 일반적 상식으로 오탈자까지 동일하게 틀리는 경우는 표절을 하지 않고서는 동일인의 영혼이 빙의되어 동일한 오탈자를 표준어로 굳게 믿는 경우가 아니라면 거의 불가능한 일이다. 의도하지 않았지만 옥의 티도 때로는 진실에 접근할 수 있는 좋은 도구가 되어 준다. 이것도 일종의 쓰레기 정보가 주어 부정한 행동을 했는지 아닌지 알 수 있게 해준다. 특별히 이런 경우 논문이라는 중요한 작업에 남이 쓴 논문을 한번이라도 읽어 오탈자라도 고칠려는 노력도 안하고 Ctrl-C, Ctrl-V 했다는 의혹도 심하게 받을 것이다. 가끔 이런 의도된 오류들도 충분히 가치를 줄 때가 많다.

쓰레기 정보라고 말하기 어렵지만 일상적인 사생활을 기록하는 것도 그리 나쁘지 않은 방법 중 하나이다. 언제 어디서 무엇을 했는지를 모두 기억할 수 있는 사람은 그리 많지 않다. 그러나 아주 빠른 시간에 자신의 흔적을 남길 때 구체적인 기억으로 이끌어 낼 수 있는 좋은 방법이 되기 때문이다. 세상이 복잡해지고 사람들 사이에 오해가 많이 발생할 수록 이런 사생활에 해당하는 내용을 최소한 사적 영역으로 기록하는 것도 필요하다고 생각한다. 사실 스마트폰은 이런 기능을 이미 많은 부분 수행하고 있다. 사용자와 거의 붙어 있는 스마트폰의 경우 기본적인 설정을 조정하지 않는다면 사용자가 어디에 있는지 위치 정보를 수시로 기록할 수 있다. 위치 기반 광고만 보아도 최소한 한번 이상은 사용자의 위치를 보낸다는 것은 예상할 수 있다. 문제는 이런 정보들이 일련된 개인의 사생활 내용으로 기록되는가 아닌가의 문제이다. 이부분은 수집하는 회사와 관계를 두고 어떤 정보를 수집할 것인지 약관 등을 통해 수집됙고 법률 등을 통해 제한될 것이다. 스마트폰이 기록하는 이런 사생활 내역을 오히려 개인의 기록으로 구체화 시킬 필요가 있을까? 구글 계정과 구글 나우 (Google Now) 를 사용한다면 [ https://maps.google.com/locationhistory ] 에 들어가면 어떤 위치 정보들이 기록되었는지 확인할 수 있다. 자신도 모르게 기록되는 정보가 무엇인지 확인하고 이를 자신이 관리하는 데이터로 끌어낼 필요도 있다.

최근의 사건들이지만 많은 경우 사용자가 기록하지 않아도 기록으로 남게 된 정보에 대한 법적 효력 혹은 법적 결정에 상당한 영향을 주는 경우가 많다는 것이다. 예를 들어 개인이 일상적으로 대화했던 기록이나 개인의 위치 정보 등은 상당한 법적 효력을 가지게 된다. 물론 이에 대해서 공정한 법집행이 이루어진다면 문제가 없지만 상당 부분, 특히 미국의 국토 안보와 테러에 관련된 내용의 경우 일반 사용자, 학생들이 뜻하지 않게 테러리스트 혹은 테러를 일으키지도 않았는데 테러를 일으킬 의도를 가진 사람으로 지목되어 인권이 무시되는 경우가 있었다. 물론 국가의 안보는 중요한 요소이지만 문제는 개인의 사생활 영역이 침범당해 혹은 개인의 사생활 정보는 디지털 데이터이기 때문에 특별히 그 데이터의 진위 여부를 교차 검증하기 어렵다는 한계를 가진다. 즉, 어떤 특정 정보 기관이 의도를 가지고 개인 사생활 정보를 조작할 수 있다면 충분히 한 개인을 테러리스트로 만들기에 충분한 위치 정보와 의도성을 만들 수 있다는 점이다.

자신도 모르는 사생활을 시스템이 기록한다고 해서 개인이 특별히 잘못을 하지 않으면 무엇이 문제일까 싶지만 디지털 데이터는 생각보다 아날로그 영역의 증거에 비해 그 진위성을 확증하기가 어렵고 일방적으로 데이터가 제공될 때 즉, 사용자는 의식하지 못하는데, 수사하는 쪽에서 전화 통화 기록이나 위치 정보 등을 제공할 때 수사하는 쪽이 제공하는 데이터가 확실하다고 어떻게 검증할 수 있는가이다. 최근 디지털 데이터의 수사 과정에서 가장 큰 문제는 그 사생활 내용에 대해서 협의 사실을 피의자가 인정한다면 별 문제가 안될 수도 있지만 정 반대로 피의자가 인정못하는 경우 디지털 데이터가 조작되었을 때는 어떻게 이를 확인할 수 있는가이다. 소위 조작된 형태의 디지털 데이터를 어떻게 검증할 수 있는지 방법이 별로 없다. 이런 경우 믿고 싶지 않지만 사법적 폭력을 위한 충분히 좋은 도구로 사용될 가능성이 높다는 것이다.

목적있는 정보 사용에 대해서... 

개인 정보의 가장 큰 속성은 그 중요성이 강조되지만 그 중요성 만큼 사용자는 크게 의식하지 않는다는 점이다. 개인 정보에 대한 확실한 대책은 전혀 없다. 그게 사실이다. 문제는 얼마나 악용되는 비율을 줄일 수 있는가이다. 그렇기 위해서 단순히 기술적 방법으로 모두 막을 수 없다는 공감대가 형성되어야 한다. 개인 정보는 말그대로 개인의 사유이기도 하지만 시스템의 허술함은 개인의 사유가 쉽게 노출되는 너무도 큰 취약점을 만들어 버렸다. 그리고 그 취약점이 제대로 보완되기도 전에 시스템은 확대 생산되고 그에 따라 사용자들은 그 중요성을 인식하기도 전에 이미 너무 많은 정보를 온라인에 올려놔 버렸다.

따라서 문제의 시선을 다르게 볼 필요가 있다. 개인 정보의 노출에 의해 발생하는 문제점에 대해서 심각하게 받아들이고 그에 대한 피해와 책임을 강하게 규제해야 한다. 대규모의 개인 정보가 해킹당했는데 정작 그 정보를 지켜야 하는 기업은 거의 책임을 지지 않는다면 기업은 점점 이에 대해서 소홀하게 다룰 것이다. 즉, 개인 정보가 얼마나 가치있는지를 평가하는 것은 개인의 인식도 중요하지만 책임의 크기가 더 중요하다. 살인범이 소매치기보다 더 무거운 형량을 받는 이유는 살인이 소매치기보다 더 무거운 범죄라는 평가가 내려졌기 때문이다. 마찬가지로 개인 정보를 얻어 만드는 이득은 회사가 챙기고 그에 대한 책임은 가지지 않는다면 이에 대해서 누가 중요하다고 생각할 수 있겠는가.

목적있는 정보 사용을 위해서 그만큼 의식도 필요하지만 그와 함께 사용자들이 자신의 개인정보를 ⓐ 어떻게 보호할 수 있는지, 최소한 ⓑ 노출된 경우 얼마나 그 피해를 최소화 시킬 수 있고, ⓒ 그에 대한 책임을 물을 수 있는 정보를 얻을 수 있는가도 신경써야 한다는 것이다. ⓒ 의 경우를 위해서 쓰레기 정보학은 하나의 좋은 대안이 될 수 있다. 정보학의 관점에서 보았을 때 국내의 주민등록번호처럼 멍청한 시스템도 그리 많지 않다. 생년월일 뿐만 아니라 성별, 출생지를 알 수 있고 이 번호가 맞는 (유효한) 정보인지 마지막 번호로 알려주는 번호 하나만으로 완결된 정보를 제공하기 때문이다. 당연하지만 개인 정보는 수집하려는 노력에 따라서 어느 정도 수집할 수 있다. 문제는 얼마나 노력이 필요한가이다. 아주 간단한 노력만으로 상대방의 개인 정보의 많은 부분을 알아낼 수 있다면 많은 문제가 발생할 것이다. 같은 의미로 한동안 떠들석 했던 고위 법조인의 혼외자식이라며 알아내는 과정도 주민등록번호 하나로 사생활이 노출되는 단적인 예를 보여주기도 했다. 따라서 개인 정보에 관련된 내용은 분산 (distributed) 될 수록 개인 사생활 (인권) 차원에서 더 좋다.

따라서 일상의 생활에서 적절하게 쓰레기 정보학을 이용하면 책임을 묻기 위해서도 유용하다. 본 블로그에도 본문의 무단 복사를 막기 위해 무단으로 복사할 경우를 대비해서 오탈자와 본문에는 보이지 않지만 그대로 복사한 경우 남을 수 있는 내부 코드를 포함하고 있다. 이런 의도된 쓰레기 정보들은 목적을 가지고 있기 때문에 그 목적성은 문제가 발생했을 때 중요한 단서로 작용하게 된다. 따라서 우리의 개인 정보를 단순히 지키려고 하는 노력 뿐만 아니라 노출되었을 경우 이를 확인할 수 있는 쓰레기 정보를 의도적으로 첨가하는 것도 개인 정보를 지키는 하나의 노력이 될 것이다. 우리가 개인정보를 관심있게 관리하고 이에 대한 적절한 대책을 마련한다면 그 피해를 원천 봉쇄할 수 없지만 최소화할 수 있거나 문제 해결을 위한 좋은 해결책이 될 것이다.

Garbage In Garbage Out 의 시대에서 이제는 Garbage In Fancy Out 을 기대하며...

쓰레기 정보학 ─ 개인정보의 속성에 대해서