본문 바로가기

TechLog

영구적인 데이터 서비스

:: 티스토리 스패머, 문제가 아닌 근본적인 바람
먼저 블루문님의 위 포스트를 먼저 읽어보시라. 약간 포인트가 다른 이야기라 트랙백은 걸지 않았다.

예전에 BBS를 사용하던 시절에도 그랬고, 홈페이지를 운영할 때도, 지금도 그렇긴 하지만, 나는 데이터에 대한 집착이 조금 심한 편이다. 굳이 다시 꺼내어 읽어볼 일이 별로 없다는 것을 알고 있으면서도 BBS 시절부터의 게시물을 일부 백업해서 갖고 있고, 홈페이지 또한 그러하며 게시판에 저장되어 있던 글들도 db 형태로든 텍스트 형태로든 백업을 해서 가지고 있다. 블로그마저도 이글루, 네이버를 전전하다가 티스토리로 흘러들어온 이유도 여러가지 있긴 하지만, 태터툴즈와 호환되는 백업 파일을 생성할 수 있다는 점이었다. 후에 내가 태터툴즈를 쓰게될지 어찌될지는 모르겠지만, 어쨌든 백업을 해 두면 해당 데이터는 내 스스로 가공할 수 있을테니까.

이러다보니 서비스 형태로 제공되는 각종 이메일 서비스, 홈페이지 서비스, 블로그 서비스 등의 이용을 꺼리는 편이었다. 지금까지 중단된 서비스(예전 통신망이나 채널아이, 넷츠고 등 추억의 이름들이 떠오른다)를 생각해보면, 해당 서비스들은 서비스가 중단되었을 때 노가다 copy & paste 외에는 백업의 방법이라고 할 만한게 없었다. 서비스에 저장된 개인의 데이터가 물론 해당 개인의 것만은 아니겠지만, 분명 데이터에 대한 생성과 관리의 주체가 사용자임에도 불구하고 데이터의 영속성은 서비스를 제공하는 회사에 종속되어 있었으며, 지금도 대부분은 그러하다. 다들 아무렇지도 않게 티스토리, 이글루스, 네이버블로그... 뭐 그 외에도 많은 서비스를 사용하고 있지만, 언제 또 해당 서비스 업체가 문을 닫을지 어떨지는 아무도 모른다. 며느리도 모른다.

저마다 여러 가지의 이유가 있겠지만, 나의 경우에는 오로지 내 성격 탓에(-_-) '서비스에 종속된 데이터를 내가 스스로 관리할 방법이 없을까?'라는 데에까지 생각이 닿았고, '서비스와 데이터의 분리'를 고민해보게 되었다. 그렇다면 이런, 서비스와 데이터의 분리가 어떻게 적용될 수 있을까.

개념적으로는 복잡한 구조는 아니다. 그냥 단순히 데이터의 검색/저장 역할을 하는 서비스를 따로 분리하는 것 뿐이다 :

      블로그, 홈페이지, 이메일, etc ... <----------> 데이터 서비스

  1. 사용자가 데이터 서비스에 가입한다.
  2. 데이터 서비스의, 해당 사용자의 전용 데이터 입출력 URL와 Key 정보를 해당 서비스(예를 들어, 블로그)에 등록한다.
  3. 서비스에서는 데이터 서비스의 URL을 호출해서 데이터를 주고받는다.

이럴 경우 해당 서비스가 종료했을 경우, 저장 정보가 호환되는 블로그가 존재한다면 단순히 데이터 서비스의 URL을 다른 서비스에 등록하는 것만으로도 자신의 블로그 데이터를 옮길 수 있을 것이다. 최악의 경우 저장 정보가 호환되는 블로그가 없더라도, 데이터 서비스에 저장된 데이터를 변환하거나, 하다못해 경쟁 서비스를 제공하는 회사에 해당 데이터의 지원을 요청해 볼 수 있을 것이다. (예를 들어 티스토리가 망했다고 가정해보면, nhn이 그 사용자들을 흡수하고 싶지 않겠는가?)

데이터 서비스의 경우 실제로 어떤 형태가 될 것인지는, 아마 지금의 웹하드 서비스와 거의 다르지 않을거라고 생각한다. 일정 용량을 제공하고 그 용량에 대해 요금을 지불하는 방식이지만, 단지 데이터를 저장/검색하는 인터페이스를 API 형태로 노출시킨다는 점 정도가 차이점이 될 듯.


... 사실은 위 내용으로 비슷한 것을 구현해보기는 했지만, 지금은 다음같은 고민만 남겨놓고 소강 상태 :

  1. 백그라운드의 통신(해당 서비스 <-> 데이터 서비스의 통신 및 보안 기능 적용) 오버헤드를 줄이는 방법
  2. 파일 기반 API, 관계형 DB 기반 API 중 어느 것을 사용해야 하는가
  3. 비정상적인 연결, 재전송 처리

기술적으로 어려운 것이라기보다는, '왜 이런 서비스가 필요한가'라는 공감대를 형성해야 하는 부분이 더 크지 않을까.
조만간 이런 서비스의 등장을 기대해 본다.