the Great World Meson

항상 반복되는 질문이지만 인터넷의 자료가 많아진다면 인간은 얼마나 지식이 늘어날까? 알려고 하면 언제든지 알 수 있는 환경이기 때문에 지식을 얻고 싶다면 어렵지 않을 것이라고 생각한다. 일련의 글 속에서 인터넷만으로 인간이 현명해지기 어려울 수 있다는 가능성에 대해서 이야기했다. 

[ 인터넷은 우리를 똑똑하게 해주는가? ; blog.meson.kr/380 ] 을 통해서는 인터넷에 쌓여가는 지식의 양과 질과 별도로 인간이 가지는 인식의 중요성을 이야기했다. 즉, 인간이 인터넷을 통해서 어떻게 받아들이는가의 인식의 중요성을 강조했고 그 과정에서 불완전한 인간의 인식을 도와주기 위해서 좋은 컨텐츠 (contents) [인식의 시작] 이 필요하고 이후 [인식의 발전] 과 [인식의 정착] 의 3단계를 통해 현명한 인식 과정이 더 필요한 내용이라 이야기했다. 

[ 개방성 - 표준을 통한 산업의 발전은 가능한가 ; blog.meson.kr/386 ] 을 통해서 우리가 만들어내는 사용자의 데이터가 웹 서비스 상에서 저장되는데 이때 개방성 (openness) 가 제대로 구현되지 않을 때 사용자는 웹 서비스에 종속되거나 자신이 쌓아온 개인 데이터를 포기해야 하는 상황이 발생할 수 있음을 이야기했다. 

두가지의 앞선 글을 통해 연결하고 싶은 이야기는 인터넷은 우리의 지식 구조를 조직적으로 만들어 줄 수 있는 좋은 도구가 될 수 있는가이다. 즉, 우리가 어떤 생각을 하고 자신만의 좋은 생각을 만들어 내는 과정에서 인터넷이 어떻게 개인의 생각을 논리적으로 흘러갈 수 있도록 도와주는가이다. 이를 위해 [생각의 흐름] 을 강조했다. [ Originality 의 중요성 - 생각의 흐름 ; blog.meson.kr/388 ] 새로운 아이디어를 만들어 내기 위해서는 다양한 방법론을 접하고 적용가능한 내용을 고안해 내는 것도 중요하지만 그만큼 적용할 수 있는 다양한 대상 (재료) 를 찾아내는 것도 중요하다. 그렇기에 논문은 저자가 가지는 생각의 독창성 (originality) 뿐만 아니라 기존의 생각들 (참고문헌; references) 를 어떻게 잘 정리했는가도 중요하다. 인터넷이 제대로 보급되기 이전 참고문헌을 정리하는 것은 무척이나 어려운 작업이었다. 그러나 이제 대부분의 참고문헌 뿐만 아니라 다양한 생각들이 전달되는 인터넷의 공간은 글 하나가 가지는 고유한 주소를 가지고 공유될 수 있다. 예를 들어 누군가 페이스북에 글을 올리면 (post) 해당 글을 다른 곳에 공유할 수 있는 고유한 주소를 가지게 된다. 즉, 흩어져 산재한 (scattered) 생각의 타래들이 인터넷 상의 주소를 통해서 공유될 수 있다. 

이런 인터넷의 변화는 생각보다 오래된 것이 아니다. 인터넷은 고유한 그리고 시간과 공간에 독립적인 (시간과 공간에 유일한) 주소체계를 가지게 된다. 아주 간단한 예를 들어보자. 현재 이 블로그의 주소창에 어떤 주소가 보이는지 확인해보자. 어떤 독자는 blog.meson.kr/475 란 주소를 볼 수 있고 누군가는 blog.meson.kr/?page=2 혹은 ...page=3 과 같은 주소를 볼 수 있다. 그 외에도 다양한 형태의 웹 주소를 가질 수 있다. 문제는 전자의 .../475 와 같은 주소는 이 블로그가 가지는 고유한 주소이다. 반면 후자는 블로그의 글이 증가함에 따라서 글의 내용은 달라질 수 있다. 인터넷이 단순 HTML 을 벗어나 웹 상의 데이터베이스를 호출 (query, request) 하고 해당 값을 받아 내는 과정을 거치게 되면서 인터넷 주소만 잘 보아도 어떤 변수를 통해 내가 보는 페이지를 구성하는지 직관적으로 알 수 있는 경우가 있다. 그러나 이런 경우 상황이 달라지면 해당 페이지의 내용은 달라지게 된다. 사실 후자의 경우 문제가 되는 것은 자신이 공유하고 싶은 내용이 아닌 다른 내용이 공유되거나 공유되는 시점에서는 제대로 공유되어도 이후 해당 주소는 다른 내용으로 변경되는 경우가 발생하는 것이다. 

그렇기 때문에 각 페이지가 시간, 공간에 관계없이 유일한 주소 체계를 가지는 것은 다른 이들이게 내가 공유하고 싶은 내용을 정확하게 전달하기에 중요한 요소가 되었다. 가끔 엉뚱한 주소가 링크되는 경우나 쓸데없는 변수들을 달고 공유되어 공유하는 사람이 무엇을 검색하다가 공유하게 되었는지와 같은 별 쓸데없는 내용까지 공유되는 경우도 생기게 된다. 아무튼 공유 체계를 위해서도 고유한 (unique) 주소 체계가 만들어지는 것이 첫번째 과정이다. 

XML 은 왜 중요한가? 

XML 이 무엇이냐 물어보면 참 대답하기 힘들다. 그러나 우선은 위키피디아의 정의를 인용하여 생각해보자. 

Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.

인용을 해도 뭔 소리인가 싶은 내용들이다. 우선 알아들을 수 있는 것은 인간도 읽을 수 있고, 기계도 읽을 수 있다는 내용이 먼저 들어온다. 그리고 결론적으로 XML 은 문서이다. 그리고 XML 에서 X 는 Extensible 의 약자이다. Extensible 이란 확장 가능한... 이란 뜻이지만 오히려 치환 가능한 이란 뜻이 더 적합할 것 같다. 모르겠다... 일단 직관적으로 느껴지는 느낌으로 XML 을 설명해보자. 

XML 이란 별도의 데이터베이스 관리 시스템 없이 데이터를 구조화 시키는 일반 텍스트 문서이다. 

어설프고 빈틈이 많지만 일단 이렇게 설명해보고 싶다. 우리가 경험하는 거의 대부분의 XML 문서는 일반 텍스트 문서이다. 즉, 어떤 운영 체제도 기본적으로 내용을 살펴볼 수 있다. 원도우라면 기본적으로 메모장으로 다 열어 볼 수 있는 내용이다. 유닉스나 리눅스에 익숙한 분이라면 cat myXmlDocument.xml 과 같은 명령어로도 쉽게 열람할 수 있다. 그런데 우리는 이미 가장 친숙한 XML 을 거의 매일 경험한다. 우리가 웹 브라우저를 통해 보는 모든 문서들은 궁극적으로 HTML 으로 보여주는 화면들이다. XML 에서 X 가 HT 로 치환된 것이다. 즉, Hyper Text 를 위해 만들어진 규칙에 맞춰 작성된 문서가 HTML 이 되는 것이다. 이런 이유로 가장 먼저 인용된 정의에서 a set of rules 는 이 문서를 보내는 사람과 받는 사람이 이미 정해진 규칙을 통해 어떤 기능을 할 것인지 어떤 내용을 보여줄 것인지 정해진 규칙에 따라 주고 받는 것이다. 

HTML 을 포함해 XML 은 <somethings>object for something</something> 과 같이 데이터가 어떤 규칙이나 성격을 가지고 있는지를 정의하는 < .... > 과 </ ....> 의 형태로 정의된 일련의 내용들이다. 이와 같이 규칙을 정의하기 때문에 이 규칙을 공유하는 사람끼리는 서로 이 데이터가 어떤 내용인지 알 수 있다. 예를 들어 <PRICE>50,000</PRICE> <CURRENCY>KRW</CURRENCY> 와 같은 데이터 셋이 있다고 하면 해당 데이터는 가격이 50,000 인데 통화는 한국 원화라는 것을 정의하는 것이다. 그런데 이런 데이터의 정의를 일반 텍스트로 구성하고 있다는 것이다. 앞서 설명한 것처럼 최대의 호환성을 가지는 문서인데 그 평면적인 문서가 < ... > 과 </ ... > 와 같은 표시 형태로 데이터의 구조를 만들 수 있다는 것이다. 즉, 일반 텍스트 문서만 전달한다면 데이터의 구조와 해당 데이터가 어디에 필요한지를 이미 정해진 약속에 의해 전달할 수 있다는 것이다. 

결국 XML 은 전달과 공유를 위한 좋은 도구가 된다. 만약 내가 오라클 데이테베이스 화일을 백업해서 이를 다른 시스템에 복원할 수 있는 스크립트 화일 (SQL) 이 있다고 해도 만약 해당 스크립트를 해석할 수 있는 데이터베이스 시스템이 없다면 무용지물이 되지만 XML 은 사용자의 운영체제에 관계없이 일단 해석도 가능하고 읽을 수도 있는 것이다. (물론 SQL 스크립트를 잘 이해하는 사람이라면 스크립트만 보고도 해석할 수도 있다고 하겠지만 모든 사람이 그럴 수 있다는 것은 지나친 욕심일 것이다.) 이런 이유로 XML 은 가장 기본적인 형태로 데이터를 구조화하여 전달할 수 있는 것이다. 그리고 그 전달은 특별히 전달하는 쪽, 전달받는 쪽 어느 쪽도 특별한 소프트웨어나 시스템을 요구하지 않는데 심지어 모바일 환경이라도 브라우저만으로도 가능하다. 

문서 표준의 변화도 살펴볼 필요가 있다. 이제 마이크로소프트 및 오픈소스 계열의 오피스를 비롯해 거의 대부분의 문서는 XML 형태로 저장하는 것을 알 수 있다. XML 자체가 중요하지만 XML 처럼 호환성과 자체 데이터 구조를 잘 갖출 수 있는 방법론은 항상 고민해봐야 할 대상이다. 

API 와 사랑에 빠지다. 

API 는 원래 Application Programming Interface 이다. 거칠게 소개하면 어떤 개발자가 원도우 환경에서 돌아가는 프로그램을 만들 때 원도우의 기본적인 창 기능, 최대화면, 최소화 뿐만 아니라 아주 기본적으로 버튼이나 화면 구성과 같은 것을 모두 프로그래밍 해서 구현할 필요는 없을 것이다. 초기에는 이런 이유로 원도우와 상당히 이질적인 화면의 프로그램도 볼 수 있었다. 추억돋는 이름이 되어버린 Borland C++ 과 같은 프로그래밍 개발 도구를 이용하면 여기서 제공하는 API 가 달랐기 때문에 아주 기본적인 버튼도 다른 경우도 있었다. 프로그래밍 환경은 프래그램을 컴파일하고 디버깅하는 역할도 있지만 이와 동시에 기본적으로 작동되는 내용에 대해서 기능을 제공해주는 것이고 이런 내용을 API 라고 불렀다. 

소위 프로그램의 단위에서 이야기하는 API 와 다르게 인터넷이 대중화되기 시작하면서 API 는 조금 다른 의미로 발전하게 되었다. 이제는 인터넷에서 다양한 작업과 데이터 교환이 가능하게 되기 때문에 웹상에서 이루어지는 Web API 로 발전한다. 모든 역사를 소개할 수 없기 때문에 공유 체계를 위한 ⓐ 인터넷 고유 주소 체계 ⓑ XML 의 데이터 구조 체계가 만들어 지고 이후 내용을 전달하기 위한 전달 체계가 필요하게 된다. 이러한 전달 체계를 담당하는 것이 Web API 라고 생각하면 좋다. 즉, Web API 는 한 시스템에서 다른 시스템으로 전달되기 위한 전달 체계를 위한 것이다. 

요약하면 결국 인터넷 상 데이터의 공유를 위한 세가지 단계는 

ⓐ 주소 체계 : URI ; Universal Resource Identifier , URN ; Universal Resource Name , URL ; Universal Resource Locator 와 같은 체계를 만들어 주었다. 

ⓑ 구조 체계 : XML 을 소개했지만 이외에도 다양한 형태가 있다. 이외 대표적인 것들은 JSON 이나 YAML 등이 있다. 중요한 것은 이 모든 것이 결국 데이터를 어떻게 구조화하는가를 위한 방법들이다. 

ⓒ 전달 체계 : Web API 로 소개하였지만 구체적인 기술에는 다양하게 존재한다. 중요한 내용은 서버측, 클라이언트 측 모두 교환 가능한 형태의 규약 (protocol) 을 가지고 있다. 가장 대표적인 것에 REST API 를 생각해볼 수 있다. 

다 포기하고 쉽게 접근하자 

거친 형태로 개념을 소개했지만 이런 체계를 통해 공유를 하는 것이 왜 필요한가이다. [ Originality 의 중요성 - 생각의 흐름 ] 에서 소개한 내용 중 인터넷이 어떻게 생각의 흐름에 도움을 주는지 소개했다. 가장 중요한 구조는 바로 공유이다. 만약 공유를 위한 체계가 제대로 구성되지 않았다면 누군가의 블로그에 들어가 해당 글을 다른 이들에게 공유하는 방법은 전문을 복사해서 자신이 공유하려고 하는 공간에 복사해서 올리는 것이다. 그러나 이미 원본 글을 알아낼 수 있는 주소 체계, 데이터를 전달할 수 있는 구조 체계, 그리고 각 웹 서비스 사이에서 원할하게 전달할 수 있는 전달 체계를 가지고 있기 때문에 이제 공유를 위해서는 원본글의 주소만 가지고 쉽게 공유할 수 있는 것이다. 

가장 쉬운 예는 내가 트위터에 올린 글이 자동으로 페이스북에 올라가거나 내가 포스퀘어에 체크인 한 내용이 페이스북에 올라가는 내용을 생각해보자. 생각해보면 별로 대단한 것이 아니라고 생각할 수 있지만 이와 같이 내가 만들어 낸 데이터를 다양한 플랫폼에 공유한 다는 것은 상당히 효율적인 과정이다. 만약 이런 공유의 과정이 제대로 이루어지지 않았다면, 즉, 앞서 설명한 세가지의 체계 중 하나라도 지원되지 않는다면 사용자는 트위터에 글을 올리고 자신의 글을 복사해서 그대로 페이스북에 올려야 하고, 포스퀘어에 체크인 한 다음 해당 내용을 페이스북에 다시 체크인 해서 알려야 할 것이다. 그러나 적절한 공유 과정을 통해서 백그라운드 작업 (background workflow) 이 이루어져 내가 신경쓰지 않아도 적절하게 원하는 내용이 공유될 수 있는 것이다. 이처럼 서로 다른 웹 서비스에 내가 만든 데이터가 전달되는 체계는 생각보다 수많은 컴퓨터 과학자, 공학자들의 노력과 땀으로 이루어진 내용이라는 것이다. (특별히 그들의 고마움을 매번 표시하라는 것은 아니지만...) 

이런 공유 시스템은 무엇이 좋을까? 

왜 이런 체계를 만든 것일까? 앞서 설명한 것처럼 가시적으로 생각할 수 있는 내용은 원본 글을 보호할 수 있다는 것이다. 반대로 폐쇠형으로 이루어진 커뮤니티, 예를 들어 내가 작성한 하나의 글이 제대로 공유되지 않는 경우에는 해당 글이 아무리 좋아도 다른 곳에 공유하려면 원본글과 분리된 단순히 복제된 글을 생산하는 방법밖에 없다. 즉, 웹 서비스가 개방적인 만큼 사용자들의 글과 그림들이 가지는 Originality 가 보존되는 것이다. Web API 를 위해 소개된 REST API 를 고안한 Roy Fielding 박사는 자신의 박사학위 논문에서 다음과 같은 특징을 설명했다. 

"컴포넌트 상호 작용의 확장성, 인터페이스의 보편성, 컴포넌트의 독립적 배치, 상호 작용의 레이턴시(latency)를 줄이고 보안을 강화하며 레거시(legacy) 시스템을 캡슐화하는 중간 단계의 컴포넌트 역할"

말은 어렵지만 고유한 주소 체계를 가진 인터넷의 웹 자원들이 독립된 보안도 가지면서 상호 작용이 원할하게 이루어질 수 있는 방법을 제시하는 것이 중심이다. 즉, 원본글이 가지는 고유한 주소의 자원이 분리된 형태의 복제나 억지스런 전달이 아닌 원본글의 고유성을 유지하며 공유할 수 있는 방법을 제시해줄 수 있도록 지향한다는 것이다. 

원본글에 대한 Originality 를 증가시켜 주는 것 이외 생각해볼 수 있는 이득은 바로 처음에 제기한 질문에 대한 내용이 될 것이다. 인터넷의 지식이 쌓이고 늘어나는 것도 중요하지만 일단 원본에 대한 가치를 중요시 할 수 있는 시스템이 만들어지고 이후 필요한 것은 이런 시스템 하에서 인간이 어떻게 자신에게 필요한 지식을 체계적으로 얻을 수 있는가의 문제이다. 결론적으로 이 질문에 대한 대답은 역사가 대변해준다고 설명하고 싶다. 인간은 지식으로 학문을 발전시켰는가? 라고 물어본다면 개인적으로 그 대답은 Partly Yes 라고 대답하고 싶다. 이는 인터넷에 지식이 쌓인다면 인간의 지식도 늘어나는가에 대한 대답이다. 결론적으로 쌓여 있는 지식을 재료로 통찰력을 가지고 발전시키지 않는다면 별로 발전은 없을 것이라고 믿는다. 즉, 인간에게 중요한 것은 단순히 모여있는 지식이 아니라 지식의 체계와 구조를 만들어 자신에게 필요한 지식을 만들어 가는 과정이다. 이러한 필요성은 고대부터 느껴왔다. 그리고 역사는 이런 필요성에 의해서 도서관을 만들었다. 

사실 도서관은 건물의 의미가 강하지만 도서관이 가지는 기능적 역할은 바로 Archive 이다. 항상 Archive 란 말을 어떻게 번역해야 하는지 어려울 때가 많다. 그러나 도서관의 가장 중요한 역할은 이 Archive 이다. 인터넷도 마찬가지이다. 쓰레기 같은 정보들과 혼재된 정보의 바다를 Archive 라고 부르지 않는다. 도서관은 아무 자료나 기록하는 것이 아니다. 그렇다고 물리적인 책만을 저장하는 것만 이야기하는 것은 더욱 더 아니다. Archive 는 기록의 체계를 가지고 그 기록을 통해 관련된 내용을 한 곳에서 동시에 비교하며 볼 수 있는 기능을 제공해주어 관련된 지식들을 통해 통찰력을 수행할 수 있도록 도와준다. 이런 이유로 개인적으로 인터넷이란 정보의 바다에서 제대로 살아남고 자신에게 필요한 재료를 잘 모으는 것, 다른 표현으로 자료저장소의 개인화 (Personalized Archives) 에 대한 투자가 필요하다고 보는 것이다. 

Archives 를 조금 거칠게 자료저장소라고 불러보자. 만약 자신이 음악에 대한 관심이 있고 음악 관련 일에 종사한다고 할 때 음악에 관련된 웹 서비스에서 자신만의 저장을 할 것이다. 웹 서비스가 적절한 공유 체계를 지원한다면 자신만의 음악 링크를 만들고 싶을 수 있다. 예를 들어 유투브를 사용한다면 유투브 자체에서도 자신만의 Playlists 를 통해 분류하고 정리할 수 있을 것이다. 다른 경우를 생각해보자. 페이스북을 사용해보면 알지만 페이스북은 쓰면 쓸수록 어색하게 만들어주는 웹 서비스란 생각이 든다. 만약 페이스북을 사용하는 목적이 자신의 생각을 정리하고 이를 남기기 위한 것이라면 좀 불편해지는 경우가 발생한다. 예를 들어 자신의 생각을 이어가기 위해서 예전에 쓴 글을 검색할려고 하면 이처럼 불편한 경우도 없게 된다. 조금 고민하다 자신이 모든 글을 전체 공개 (Public) 으로 설정했다면 구글링을 통해 찾아볼 수 있지만 이또한 전체 공개를 하지 않은 사람에게는 거의 불가능하다. 이런 경우 점점 과거로 가면 갈수록 느려지기만 하는 자신의 타임라인을 거슬러 가야 한다. [물론 이 방법을 해결하는 꼼수로 자신의 페이스북 데이터를 백업받아 백업받은 파일에서 검색하는 방법은 있다.] 

그런데 만약 자신의 페이스북에 쓴 글을 제목, 글 내용, 작성일자 등과 같은 기본적인 내용을 가지는 데이터를 스프레드시트(엑셀)파일로 가지고 있다고 한다면 어떨까? 사용자가 예전의 페이스북 글을 검색하기 위해서는 시간걸리는 복잡한 페이스북 타임라인을 거슬러 올라가며 추억에 돋지 않아도 스프레드시트 파일만 검색하면 금방 검색할 수 있는 것이다. 

어떤 웹 서비스도 완벽하지 않다. 

인터넷 공간에서 자주 보는 사람들의 반응 중 어떤 특정 서비스를 언급하며 지금까지 모든 웹 서비스를 이길 수 있는 소위 킬링 서비스 (killing service) 라고 소개하는 경우가 있다. 뭐 소위 요즘 말로 '대박 웹 서비스' 정도가 될 것이다. 그러나 지금까지 어떤 웹 서비스도 완벽하게 만족감을 주는 서비스는 전혀 존재하지 않았다. 수많은 블로그 시스템이 생겼다 사라지고 한다. 생길때마다 첫 느낌에 혹해서 혹은 특별한 구성에 매력을 느껴 사용자들이 찾아들게 되지만 결국 사용자를 계속 사용하게 유지하는 것은 특별한 기능이 아니라 쌓여가는 내 데이터와 내 글에 대한 유연성을 더 필요하다고 느끼게 된다. 

가장 기본적으로 어떤 웹 서비스도 완벽한 것은 없다는 가정에서 시작해야 한다. 그리고 사실이다. 많은 사용자가 있다는 것은 인적 관계를 위해 유리한 점이 있을 수 있지만 이는 인터넷의 기본적 공개성 (publicity) 를 피해서 개인적 공간과 사적 공간을 위한 노력으로 만들어지는 부분이라고 보아야 한다. 블로그와 같은 공간은 그 기본이 공개성이다. 그리고 그 공개성을 적절하게 잘 활용한다면 인터넷에서 자신에게 필요한 자료를 수집하고 자신만의 자료저장소를 만들고 그 저장소에서 자신의 통찰력으로 자신에게 필요한 개념들을 만들어 낸다면 인터넷은 나의 인식을 발전시키고 인간 지식의 진보를 위한 좋은 도구가 될 것이다. 따라서 완벽한 웹 서비스나 인터넷 환경이 되기를 바라며 기다리는 것은 인터넷을 너무 맹신하는 결과가 될 것이다. 중요한 것은 자신이 노력하는 과정이고 그 과정의 구체적인 흐름 (workflow) 은 자신만의 자료저장소를 어떻게 잘 만들어 내는 것도 하나의 방법이라 생각한다. 

인터넷 정제 공장을 만들자. 

자신에게 필요한 자료를 모으고 이를 잘 저장하는 방법은 상당히 시간 소모적 일인적이 있었다. 사실 그런 작업의 하나로 얼마나 북마크 (즐겨찾기) 를 잘하는가는 얼마나 자료를 잘 모으는가를 나타내는 하나의 기준인 적도 있었던 것 같다. 그러나 이제 그런 작업을 시간들여 한다는 것도 별 의미가 없어졌다. 가장 큰 이유는 정보의 단계가 웹 페이지에서 웹 페이지 안의 내용으로 들어갔기 때문이다. 그리고 이렇게 세분화된 내용들은 고유한 주소 체계, 구조 체계, 전달 체계를 잘 만들어 주어 조금의 노력만으로도 잘 구성된 자신만의 Archive 를 만드는 것도 어렵지 않게 되었다. 페이스북의 Like (좋아요) 내용을 모은 것이나 구글플러스의 +1 페이지도 이런 맥락에서 생각해볼 수 있다. 그러나 이렇게 모아진 페이지들은 그저 모아진 것일 뿐이다. 다시 찾아보는 순간 내가 왜 이런 쓸데 없는 것도 +1 이나 Like 를 눌렀나 하는 후회도 하게 될 것이다. 

그래서 자신에게 필요한 정보를 잘 정제 (purification) 하는 것이 필요할 것이다. 다른 말로 일종의 필터 (filter) 작용을 통해 자신이 다시 볼 가치가 있는 정보를 모아보는 것이다. 이를 위해 많은 사람들은 자신만의 위키 사이트를 만드는 등의 노력도 하게 된다. 그런 노력의 하나로 소개했던 내용이 구글 알림 (Google Alerts) 이다. 이메일로 자신이 관심있는 검색어를 등록하여 해당 검색 내용이 발생하면 이메일로 알려주는 것이다. [ 정보의 가공 및 개인화 - 논문 작성을 중심으로 ; blog.meson.kr/377 ] 

IFTTT & Yahoo Pipes 

이런 노력을 극대화하고 앞서 설명한 Web API 의 편리한 사용을 가능하게 해주는 서비스가 IFTTT (IF THIS Then THAT) 으로 웹 서비스들에서 제공하는 Web API 를 통해서 만약 THIS 가 이루어지면 THAT 을 실행하는 것이다. (홈페이지에서 발음은 gift 에서 g 발음을 빼고 발음해서 [이프트] 라고 발음해달란다...) 구체적인 프로그래밍 기술이 없어도 간단하게 다양한 웹 서비스를 연결시킬 수 있는 서비스이다. 백문이 불여일견이라 직접 살펴보고 어떤 가능성이 있는지 확인하자. 

화면은 큰 아이콘 위주로 구성되어 있다. 어떤 서비스인지는 직접 살펴보면 직관적으로 알 수 있다. 관심있게 볼 항목은 Recipes 와 Channels 부분이다. 채널 (Channels) 은 IFTTT 에서 연결을 지원하는 서비스 내용이다. Recipes 는 내가 직접 구성할 수 있는 부분이다. 먼저 채널 부분을 살펴보자. 채널 부분은 내가 구성할 수 있는 (웹) 서비스들이 보인다. 이중 자신이 사용하고 있는 서비스를 연결하거나 가입할 수 있다. 조금 아쉬운 점은 IFTTT 는 연결된 서비스는 하나의 계정만 사용할 수 있다. 예를 들어 자신이 사용하는 이차 계정 (secondary account) 를 사용할 때 두개의 계정을 동시에 등록할 수 없는 것이다. 여러개의 계정을 지원하는 서비스도 있다. 가장 대표적인 서비스가 Buffer 인데 Buffer 의 경우 IFTTT 보다 조금 복잡하다는 느낌이 있다. 만약 필요하다면 IFTTT 의 채널에 Buffer 서비스가 있기 때문에 적절하게 연결하는 방법도 가능하다. 

원하는 서비스를 연결하고 나면 IFTTT 의 서비스 성격을 살펴볼 수 있다. 다른 이들이 만든 Recipes 를 살펴보면 재미있는 연결이 많다. 예를 들어 포켓 (Pocket) 계정에 저장하고 읽고 나서 보관 (Archive) 로 만든 아이템을 자동으로 에버노트에 노트를 만들어 저장되게 만드는 연결, 쥐메일 (Gmail) 에서 받은 첨부파일들을 드랍박스 (Dropbox) 로 복사하는 연결, 인스타그램에 올린 자신의 사진 혹은 좋아요 (♥) 를 누른 사진을 저장하는 연결 등 다양한 연결이 가능하다. 만약 어느 정도 필요성이 느껴졌다면 직접 만들어 보자. 만들고 크게 문제되는 경우는 별로 없기 때문에 일단 직접 시도해보자. 화면 구성은 아주 간단하고 직관적이라 어렵지 않다. THIS 에 해당하는 서비스를 찾아보자. THIS 는 TRIGGER (유발 서비스) 가 되는 서비스이다. 즉, 앞의 예에서 포켓, 쥐메일, 인스타그램 등이 그런 것들이다. 그리고 ACTION (작동 서비스) 이 되는 서비스는 THAT 에 해당한다. 

개인적으로 사용하는 Recipe 하나를 통해 살펴보자. 개인적으로 페이스북에서 가장 불편한 부분은 내가 과거에 썼던 글들을 다시 찾아보기 어렵다. 그래서 이런 불편을 해소하기 위해서 페이스북에 올린 내 글을 박스 (Box) 서비스에 텍스트 파일로 저장하는 방법이다. 

THIS 서비스 (TRIGGER) 를 선택하면 해당 서비스에서 가능한 Trigger 내용들이 나온다. 이 부분은 THIS 서비스가 허용하는 Web API 의 내용이 된다. 이후 THAT 서비스를 선택한다. ACTION 의 부분을 보면 구성은 아주 간단하다. 데이터를 받아오는 곳은 THIS 이기 때문에 THIS 서비스에 해당하는 변수를 가지고 파일이름이나 내용을 구성할 수 있다. 그러나 어떤 형태로 데이터를 받아들이는가는 THAT 서비스의 기능과 환경에 제한이 되기도 한다. 따라서 ACTION 의 화면 구성은 THAT 서비스의 내용과 직접 연관이 있다. 자신의 구미에 맞게 파일이름, 폴더명, 내용 구성을 마치고 만들면 자신의 Recipe 가 만들어진다. 

이후 해당 Recipe 에 해당하는 Trigger 가 발생하면 자신이 설정한 내용대로 실행이 된다. 아주 간단한 형태이지만 이와 같은 소위 백그라운드 실행 (background action) 은 사용자가 반복적으로 수행하는 작업을 자동으로 구현해주게 된다. 개인적으로 사용하는 Recipes 의 내용을 살펴보면, 

→ TWITTER 에서 작성된 나의 TWEET 을 구글 드라이브 (GOOGLE DRIVE) 의 특정 스프레드시트 문서에 내용을 기록한다. 

→ POCKET 에 저장한 아이템을 구글 드라이브 (GOOGLE DRIVE) 의 특정 스프레드시트 문서에 내용을 기록한다. 

→ FACEBOOK 에 올린 글들을 BIT.LY 에서 자동으로 PRIVATE LINK 를 만들어서 저장한다. 

→ GMAIL 에서 STAR 마크한 메일의 내용을 자동으로 EVERNOTE 에 노트로 저장한다. 

→ INSTAGRAM 에서 좋아요 (♥) 누른 사진을 자동으로 SKYDRIVE 에 저장한다. 

→ 500PX 에 저장된 특정 태그 (tag) 의 사진을 모아 자동으로 BOX 에 저장한다. 

여기까지의 예들은 주로 웹 서비스를 중심으로 만든 내용이다. IFTTT 에서 지원하는 채널에는 몇가지 특이한 채널을 살펴볼 수 있다. 첫번째는 뉴욕타임즈 (the New York Times) 나 ESPN 과 같은 뉴스 채널도 지원하고 날씨 및 주식 서비스 등 일반적 정보에 대한 수집도 가능하게 해준다. SmartThings, WeMo, Philips Hue 서비스도 지원한다. 웹 서비스 뿐만 아니라 하드웨어와 연결된 ACTION 도 가능하다. 예를 들어 Philips Hue 전구를 사용하면 하루 날씨가 맑으면 필립스 휴 전구는 파란색을 표시하거나 비가 내리는 날이면 핑크색으로 표시할 수 있다. 혹은 WeMo 하드웨어를 통해서 특정 시간대에는 전기를 차단할 수 있게 만든다. 만약 특정인이 보낸 메일을 받으면 빨간색으로 전구를 표시할 수도 있다. 이처럼 실제 하드웨어와 연결된 소위 스마트 하우스웨어 (houseware) 를 통해서 보다 빠르게 사용자에게 다양한 방법으로 알림이 가능해진다. 

→ 하루의 날씨를 매일 아침 SMS 으로 보내준다. 

→ 자신이 보유한 주식의 현황을 SMS 으로 보내준다. 

이외 마지막으로 소개할 두가지 Recipes 가 있다. 

→ YOUTUBE 에서 좋아요 (Favorites) 에 넣은 동영상 클립을 TUMBLER 에 올린다. 

: 이런 방법으로 만든 블로그 : tb.meson.kr (Meson's Tube Box) ; 원래 tumbler 를 뜻하는 tb 였지만 사용 빈도가 거의 없어 폐기하려고 하던 중 페이스북이나 소셜 네트워크에 개인적으로 좋아하는 클립을 올려도 나중에 다시 모아 볼 수 없기 때문에 이를 해결하기 위해 만들었다. 우연하게 이름도 tb 를 Tube Box 로 개명했다. 직접 글을 올리는 경우는 한번도 없지만 다시 보아도 좋은 나만의 동영상 저장소가 되었다. 

→ TWITTER 의 내 TWEET 을 자동으로 BLOGGER 의 블로그에 올린다. 

: 이런 방법으로 만든 블로그 : saddle.onni.me (Saddle in Ripple) ; 트위터의 경우 완결된 생각을 적기 보다는 더 큰 그림을 그리기 위한 작은 조각의 글인 경우가 많았다. 예전의 글들을 모아 하나의 새로운 완성된 글을 쓰고 싶었는데 이를 위한 적절한 트윗 저장소로 만들었다.  

IFTTT 는 이외에도 다양한 재료 (채널) 과 방법을 통해서 보다 편리한 자신만의 자료저장소를 만들 수 있는 좋은 도구가 되어준다. 특별히 이런 서비스가 필요없는 경우도 많지만 이렇게 자신만의 자료저장소를 만들면 종합적으로 검색할 수 있다는 장점을 가진다. 

이와 비슷하지만 조금 다소 프로그래머의 감각을 건드리는 서비스도 있다. Yahoo Pipes 인데 개인적으로 좋아하는 서비스이지만 사실 IFTTT 를 쓰면서 많은 부분 사용하지 않는 경우가 많다. 일단 설정에 직관적이기 보다는 프로그래머의 감각을 요구하는 경우가 많기 때문이다. 그래도 IFTTT 가 제공하지 않는 기능이나 웹 서비스에 대해서 적절하게 자신만의 필터를 만들 수 있다는 장점을 가진다. 

마무리하며... 

IFTTT 에서 주고 받는 데이터가 XML 이라는 점, 그리고 그 전달 체계가 Web API 라는 점은 주목할 필요가 있다. 아주 작은 예들이지만 우리가 사용하는 데이터를 어떤 방식으로 관리하고, 구조화하며 전달할 것인가에 대한 아이디어를 알려주기 때문이다. 단순히 인터넷에서 이루어지는 IT 에 제한된 이야기라고 생각할 수 있지만 이런 생각은 인터넷 서비스 뿐만 아니라 도서관의 도서 관리 체계, 회사에서 문서 관리 체계 등을 만들 때 도입될 수 있는 좋은 아이디어가 되어준다. 

예를 들어 한 회사의 문서를 포함한 자료들을 관리하는 시스템을 만들 때, 어떤 체계를 가져야 하는지에 대한 도움을 줄 수 있기 때문이다. 문서에 고유한 관리 번호를 부여하는 내용, 관리 번호에 의해 데이터를 어떻게 구조화할 것인지에 대한 내용,  그리고 이런 체계를 바탕으로 어떻게 전달하고 권한과 보안을 어떻게 설정할 것인지에 대한 내용 들도 결국 인터넷의 시스템과 연결되기 때문이다. 

인터넷의 서비스 시스템을 이해하기 바라는 마음에서 마무리하지만 결국 우리가 세상을 바라볼 때 얼마나 체계를 가지고 생각하는가에 따라서 이후 시스템의 운영과 관리에 있어서 효율성이 좋아질 수 있는지에 대한 유용성에 대해서도 느낄 수 있기를 바라는 마음이기도 하다.