어린 시절 카시오(Casio) 의 데이터뱅크 시계는 가지고 싶은 물건이었다. 시계에 하나씩 입력한 친구의 전화번호를 저장하고 당시 다이얼 톤으로 전화걸 수 있는 전화에 시계를 대고 버튼을 누르면 바로 전화를 연결해주었다. 당시 누릴 수 있는 가장 첨단의 기술이었다. 기본적으로 저장할 수 있는 기계를 만들면서 사용자는 어떻게든 자료를 저장하는지에 대한 본능적인 필요성을 가지게 된다. 이제는 쉽게 스마트폰으로 많은 사람들이 관리할 수 있게 되었지만 여전히 자료의 관리가 어떤 역할을 하고 어떤 이득을 얻을 수 있는지에 대한 내용은 많이 다루어지지 않는 것 같다. 그런 의미에서 주소록을 통해서 자료 관리를 어떻게 해야 더 많은 이득을 얻을 수 있고, 잘 모르는 기능으로 불편하지 않을 수 있도록 살펴보려 한다.
├ 주소록의 기본 내용
구글이나 페이스북 등 어떤 소셜네트워크 서비스를 시작해도 가장 먼저 물어보는 필수적인 과정은 기존에 자신이 가지고 있는 주소록을 통해 자신의 주소록에 있는 사용자들이 이미 가입되어 있는지 알려주는 과정이다. 그만큼 주소록은 개인의 자료가 관계망 서비스에서 연결될 수 있는 중요한 자료가 된다. 주소록은 기본적으로 자신이 가진 지인의 이름, 주소, 연락처 정보 등을 저장하여 지인의 정보를 저장하는 방법이다.
만약 주소록이 정리가 되어 있고 원하는 사람을 찾는다고 할 때 무엇으로 찾는지부터 생각해보자. 예를 들어 갑자기 어떤 일에 도움을 받아야 하는데 그 일에 전문가였던 사람을 주소록에서 찾는다고 할 때를 생각해보자. 아주 간단한 질문이지만 이 질문은 우리가 왜 주소록을 관리하는지에 대한 근본적인 질문을 생각하게 한다. 친목이 목적이든 업무가 목적이든 우리가 어떤 인물을 생각할 때는 아무런 조건없이 바로 생각해 낼 수 있는 사람들은 그리 많지 않다는 것에 놀랄 때가 많다. 그런 현상은 나의 주소록을 대신 저장해주는 좋은 기기들이 생기면서 더욱 심해진다. 어릴 때 친구 집 전화번호 몇십개 정도는 기본적으로 기억하고 몇십년이 지난 지금도 그 전화번호가 기억나는데 요즘 자라나는 아이들에게 그런 것을 물어보면 그것을 '왜 기억해야 하는지 그 필요성도 느끼지 못할 때가 많을 것이다.'
결국 우리의 기억력을 대신해 저장해주는 주소록과 같은 자료 (데이터) 들은 왜 필요한지에 대한 근본적인 질문을 할 필요성마저 잊어버리기 쉽다.
- 주소록을 찾는 이유는 무엇인가?
- 주소록을 통해 우리가 얻고 싶은 것은 무엇인가?
- 똑똑한 사용자가 사용하는 똑똑한 기기 (스마트 기기) 는 무엇일까?
아주 간단하지만 이 세가지에 대한 질문을 해결하면서 아주 사소한 주소록이란 대상으로 자료 관리의 중요성에 대해서 잠시 살펴보려고 한다.
├ 데이터베이스 필드의 중요성
같은 질문을 반복한다. 오랫만에 누군가를 찾고 싶을 때 주소록에서 어떻게 찾는가? 예전에 같이 일하던 동료분중 데이터베이스 튜닝 (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) 을 사용하는 회사나 기관의 내부 디렉토리 서비스로 연락처를 공유하는 경우 이러한 별칭 잘 활용하면 유용하다.
업체 (상호) 이름 입력: 이미 예전 글 [
먼저 표시되는 형식을 살펴볼 필요가 있다. 한글로 입력한 항목에 대해서는 일반적인 경우
[경칭] [성][이름][접미명]
영문이나 기타 라틴계열 언어로 입력된 경우,
[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) 에서 제공된 주소록 데이터를 모아서 사용자에게 유용한 재구성된 주소록을 단말기에서 구성하는 형태를 통해 분산된 데이터베이스를 얼마나 잘 조합하면 데이터를 사용하는 주체에게 얼마나 유용한 정보를 만들어 낼 수 있는가에 대해서 생각해보고, 소셜 네트워크 서비스를 통해서 유용하고 사용가능한 데이터가 항상 유지될 수 있는 방법을 생각하고, 마지막으로 검색엔진이 주소록같은 아주 사소할 수 있는 데이터베이스까지도 얼마나 유기적으로 연결될 수 있는지에 대해서 생각할 수 있었기를 바랄 뿐이다.
주소록이란 아주 사소한 대상이지만 데이터베이스, 데이터의 관리, 유지라는 관점에서 살펴보면 생각해야 할 다양한 문제들이 생기고, 그 문제의 해결 방법을 통해서 다양한 아이디어와 그 아이디어를 확장하는 과정을 통해 다양한 분야에 적용할 수 있는 좋은 내용이 될 수 있다고 믿는다. 그런 의미에서 화려해 보이는 화면과 미사려구의 큰 효과가 없는 기능을 강조하는 많은 앱들을 사용하기 보다는 기본적 운영체제가 제공하는 기본적 철학을 충실하게 따르는 앱들의 사용만으로도 충분히 우리에게 유용한 도구가 될 수 있다. 문제는 사용자의 철학이다. 주소록이란 아주 가벼운 대상이지만 실제로 이런 개념을 확장하여 환자를 위한 데이터베이스를 만들 수 있고, 더 나아가 아주 복잡한 형태의 데이터베이스이지만 환자 맞춤형 치료 정보를 위한 거대한 데이터를 구성하고 이를 통해 보다 분석적인 해석이 가능한 방법론도 가능해진다.
아주 단순하지만 '기본으로 돌아갈 때' 우리가 놓치는 것들을 더 많이 보게 되는 것 아닐까.
0 comments:
Post a Comment