Google Labs에서 몇 달 전에 'Google Experimental Search'라는 이름의 베타 서비스를 들이밀었다. "실험적 검색"이라는 타이틀에 걸맞게, 이번 서비스는 검색 결과를 보여주는 새로운 방식들이 테스트되고 있다. 이번 서비스에서는 4가지 결과 view가 실험되고 있다. 그 중에서도 꽤 관심을 끌고 있는 끄는 view가 있는데, 고것이 바로 검색 결과를 시간 기준으로 보여주는 timeline view와 지도로 보여주는 map view이다.
새로운 방식을 이용한 검색 결과 탐험
timeline view와 map view의 공통점은 기존의 list 스타일의 검색 결과 view를 탈피하기 위한 새로운 시도라는 점이다. 어느 나라, 어느 서비스를 막론하고 현재 검색 결과는 기본적으로 list view를 기본으로 하고 있다. (Clusty.com과 같이 클러스터링을 내세운 서비스도 있기는 하지만, 이들도 키워드에 대한 클러스터링을 제외하고선 list view에서 벗어나지는 못했다.) 키워드를 입력하고 '검색' 결과를 누르면 검색 결과들이 1위부터 순서대로 보여진다. "통합 검색" 같은 패러다임도 검색 결과들을 성질에 따라 모아서 보여주는 새로운 패러다임이긴 하지만 '가장 키워드와 관련있다고 판단되는 컨텐츠부터 순서대로'를 벗어나지는 않는다.
이러한 컨텐츠 list view를 탈피하고자 새로운 메타데이터를 활용해 검색 결과를 보여주려고 하는 서비스가 timeline view와 map view이다. 이름에서 알 수 있듯이 timeline view는 시간을, map view는 위치를 중심으로 검색 결과를 보여주고 있다.
Timeline View
엄밀히 따지자면 timeline view 역시 list view를 기본으로 하고는 있지만, list를 생성하는 기준이 기존과 다르다. Timeline view의 검색 결과의 기준은 '시간'이다.
이 시간 정보는 그럼 어떻게 얻어지는가. 위의 'web 2.0' 검색 결과를 timeline view로 보는 그림을 보면 어느 정도 예상할 수 있겠지만, 이 시간 정보는 'web 2.0' 관련 컨텐츠를 분석해서 얻어낸다. 그러니까, (실제로는 어떤 방식으로 처리하는지 알 수 없지만) 다음과 같은 프로세스를 거치지 않을까 추정된다.
1. 'web 2.0' 키워드로 웹 페이지 검색을 한다. 2. 검색된 웹 페이지에서 시간 정보를 추출한다. 3. 추출된 시간 정보를 바탕으로 timeline view를 생성한다.
그러니까 예를 들자면, "web 2.0에 대해서 처음에 O'Reilly가 2004년에 한 학회에서 언급했다."는 내용이 있는 컨텐츠라면, "2004년"이 인덱싱되어 timeline의 2004년에 위치하게 되는 것이다.
Map View
Map view 역시 timeline view와 크게 다르지 않다.
Map view 역시 기본적으로 키워드 검색을 수행한 후, 컨텐츠에 '위치 정보'가 있다면 그것을 추출하고, 그 정보를 기반으로 지도에 표시해주는 형태다. 즉, "web 2.0 학회가 샌프란시스코에서 열릴 예정인데..."라는 컨텐츠가 있다면 "샌프란시스코"가 인덱싱되어 지도에 보여지게 되는 것이다.
한계
Timeline view나 map view 모두, "실험적"인 검색 서비스라는 점에서 봤을 때는 흥미롭긴 하지만, 실제로 서비스가 된다면 "과연?"이라는 느낌이 든다.
메타데이터 추출 임의의 웹 컨텐츠에서 메타데이터를 추출하는 것은 기본적으로 '매우' 어렵다. 이전부터 검색 관련 논문들에서 이런식의 view를 실험하고는 있었는데, 그들은 하나같이 '정확한 메타데이터를 추출하는 것이 어렵다'고 한다. 이는 기본적으로 시각과 위치 정보를 표기하는 명확한 기준이 없기 때문이다. 예를 들어 미국의 경우 mm/dd/yyyy 형태를 쓰지만 우리나라는 yyyy/mm/dd 형태를 쓴다. 또한 1/7/2007 이라고 하는 것과, Jan/7/2007이라고 하는 것에서도 차이가 있다. (이런 차이를 극복하기 위한 방법이 지난 WWW2006 학회에서 소개되긴 했었는데, 그 기술이 적용되었는지는 알 수 없는 일이지만.)
무엇이 올바른 메타데이터인가? 만약 모든 케이스를 구글측에서 학습해 웹 페이지에 있는 시간 정보와 위치 정보를 얻었다고 가정해보자. 그렇다면 추출된 메타데이터들 중 어떤 것이 해당 컨텐츠와 키워드를 가장 잘 연결해주는 메타데이터인가?
지금 'web 2.0' 키워드를 timeline view에서 찾아보면위키피디아의 web 2.0 페이지가 "1995년"에 보여진다. 하지만 이 페이지에서 "1995년"은 "Amazon.com이 1995년에 서비스를 시작할 때 선보였던 기능들이 지금 web 2.0이라고 불리는 기능들과 다르지 않다."는 내용에 포함되어 있을 뿐이다. 오히려 이 페이지에서 'web 2.0'과 관련 있는 시간 정보는 "2003년"(web 2.0은 O'Reilly Media에서 처음 2003년에 사용되었다.)이나 "2004년"(첫 web 2.0 학회는 2004년에 열렸다.)일 것이다. 즉, 이 페이지 하나에만 수많은 시간 정보가 있는데, 아직까지 '어떤 시간 정보가 키워드와 가장 관련이 있는가'에 대한 문제가 해결되지 않은 것 같다.
또한 개인적으로 약 2년 쯤 전에 미국 뉴스 기사들로부터 위치 정보를 추출하는 프로젝트를 해봤을 때, 같은 이름을 가진 도시들, 다른 고유명사와 같은 이름의 도시들 등의 문제로 상당히 골치를 썩었었는데, 과연 map view에서는 이들을 제대로 걸러내고 있을지도 의문이다.
정말 원하는 정보는 있는 걸까? 그리고 무엇보다 가장 큰 의문점은 "timeline view나 map view로 보여지는 결과들 중에서, 내가 정말 원하는 정보가 있을까?"라는 점이다. (역시나 실제로 어떤 프로세스를 거치는지는 알 수 없지만) 2차 필터를 거치는 과정에서 스팸성 데이터 등은 충분히 걸러져, 키워드에 대한 정확도(precision)는 높아지겠지만, 과연 웹 어딘가에 있을, 내가 원하는 정보가 이 timeline view나 map view에 나타나는지(recall)에 대해서는 끊임없이 의심하고 불안해야 한다.
예를 들어 "web 2.0"으로 검색했을 때, 운 나쁘게도 내가 원하는 정보가 있는 컨텐츠에 시각 정보나 위치 정보가 없다면 이 컨텐츠는 timeline view나 map view에 나타나지 않을 것이고, 나는 내가 원하는 정보가 아직 없는 걸까, 의심해봐야 한다. 한마디로 사람 죽는다.
홀로 쓰이기는 어려울 듯
처음 timeline view 인터페이스를 봤을 때에는 "오! 이렇게 나온다면 키워드에 대한 정보를 시간순으로 볼 수 있으니 연구하기에 좋겠는걸! 재미난 데이터도 많이 있겠어!"라고 생각했었다. 하지만 실험을 해봤더니 시각 정보의 추출 등에서 아직 많은 허점이 보여 실망할 수 밖에 없었다.
timeline view 같은 경우엔 차라리 컨텐츠에 있는 시각 정보를 추출해서 사용하지 말고, '처음 그 페이지가 수집(crawling)되었을 때'를 사용했다면 차라리 훨씬 더 의미 있는 view가 되지 않았을까 싶은 생각이 든다. 현재로서는 하나의 웹 페이지가 "1995년"에 나타나도, 그 웹페이지에서 "1995년"을 언급했다는 걸 나타낼 뿐이지, 그 이외의 정보를 직관적으로 얻기는 힘들기 때문이다.
또한 앞서 언급한 recall에 대한 문제도 있어, 메타데이터의 정확성 문제가 해결된다 하더라도 각각 홀로 쓰이기는 힘들 듯 하다. UI에 대한, 혹은 메타데이터 추출을 위한 더 많은 고민을 거쳐 이들이 하나의 서비스로 융합되었을 때 오는 시너지 효과를 노려야 하지 않을까.
개인적으로 위키를 꽤 좋아하는 편이다. 언젠가 지인의 홈페이지가 위키로 만들어진 걸 보고는 혹해서 이건 도대체 뭐냐- 라면서 자세히 뜯어보면서 위키의 매력에 홈빡 빠졌더랬다. 물론, 위키라는게 애초에 Collaborative Intelligence의 대표주자로서 누구나 컨텐츠를 생성하는데 기여할 수 있다는 철학 아래에 만들어진 녀석이기도 하고, Wikipedia.org와 같은 성공사례들도 있긴 하지만, 나는 그것보다 다른 쪽에 더 끌렸다. 웹에서 바로 컨텐츠를 수정할 수 있다는 점, 그리고 페이지간의 링크를 자유자재로 걸 수 있다는 점. 이러한 기능은 말 그대로 브레인 스토밍을 가능케 하며, 또한 각 고유의 정보들이 조각나지 않고 거대한 하나의 조직체로 발전할 수 있다는 점에서 위키는 내게 매우 유용한 도구였다.
그래서 여기저기 홈페이지를 방황하는 와중에도 위키를 설치할 수 있는 환경인 곳에서는 꼬박꼬박 위키를 설치해서 사용하고 있었다. 이 때마다 가장 고민스러웠던 건 무엇보다 access control. 맘 같아서는 모든 과제 파일이나 논문 자료들도 위키에 올려놓고 관리하고 싶은 마음이 굴뚝 같았으나, 외부로 유출되면 안되는 정보, 혹은 자료들이 있는 경우엔 꽤 난감했다. 내가 사용하는 모니위키의 경우엔, 특히나 사용자들의 접근을 막는 건 위키 기본 철학에 위배된다는 개발자님의 강력한 철학 정신으로 한동안 모두 공개 정책을 유지하다가, 얼마 전에 access control을 할 수 있는 플러그인이 만들어져 기본으로 탑재되기 시작했다.
그래도 아직 지식이 별로 없는 내가 소스 코드를 수정하고 플러그인을 적용시키는 건 한계도 있고, 또 당장 된다고 해도 사용하다가 엉뚱한 곳에서 잘못될 수도 있지 않은가? 그래서 난 늘, '개인용 위키 서비스'를 꿈 꿔 왔다.
여기까지 말하면 눈치 빠른 사람들은 알겠지만,
내가 지금 언급하고자 하는 스프링노트는, 개인용 위키 서비스이다. 라고 한줄을 적어놓고 바람을 쐬고 머리를 식히고 있자니, 스프링노트를 개인용 위키 서비스라고 단정할 수 있는지에 대해선 약간 의문이 든다. 오히려 위키의 장점을 흡수한, Desktop-Application-Like-Web-Application이라고 하는게 더 정확할지도.
노트, 입니다. 노트.
실제로 스프링노트도 위키라는 말은 별로 언급하지 않는다. 오히려 '노트'를 키워드로 잡았다. 인터넷에 하는 간단한 메모. 하지만 뭔가 좀 다른 메모. 라는게 스프링노트의 컨셉이다.
스프링노트는 Google Docs + 위키 서비스 같다.
이 말은, 스프링노트가 짬뽕 서비스라는 얘기가 아니라, Google Docs와 같은 Online Wordprocessor와 위키의 장점을 적절히 혼합해 새로운 성격을 서비스를 만들었다는 걸 강조하고픈 마음이다.
그래도 일단은 위키 기반 서비스이니 위키를 중점적으로 얘기해 보자면...
개인적으로 위키의 가장 큰 문제점은 위키라는 형태의 컨텐츠가 낯설다는 것이다. 일부 IT 관련 사람들을 제외하고는 위키라는 것에 대해 컨셉을 쉽게 잡지 못하는 경우를 많이 봤다. 특히 어려워하는 부분은 "함께 동일한 컨텐츠를 작성한다는 것", "어려운 문법", "위키 페이지간의 자동 링크 생성" 같은 것들이었다.
일단, 장담컨데 위키 엔진들이 사용하는 문법들은 한번 익히면 정말 편하다. 링크를 만드는 것이나, 텍스트를 꾸미는 것이나, 마우스로 손을 한번도 옮기지 않고도 키보드 위에서 멋진 문서를 만들 수 있다. 하지만 그러기 위해선 꽤 많은, 다른 곳에서는 잘 쓰이지 않는 위키 문법을 지긋이 앉아 다만 5분이라도 공부해야 한다. 하지만 사람들은 이러한 시간을 투자할 만한 매력을 위키에서 느끼지 못한다. 직접 써보기 전까지는. 닭이 먼저냐, 달걀이 먼저냐.
또한 위키 페이지가 하나의 이름을 가지고 있고, 그 페이지간의 링크가 위키 네임을 통해 자동으로 생성된다는 것도 꽤 이해하기 어렵다고들 한다. 이것도 문법과 일맥상통하게 한번만 제대로 이해해두면 다양한 정보들을 굉장히 의미있게 연결할 수 있는 방법인데, 개념이 너무 헷갈린다는게 문제다.
그리고 함께 컨텐츠를 작성하거나 다른 사람이 작성한 글을 수정한다는 게 어색한 건 좀 문화적인 측면에서 이야기해야 할 듯 하니, 여기에서는 생략.
여하튼 이러한 위키의 한계를 극복하기 위한 스프링노트의 노력이 매우 고맙고도 기특하게(?) 보인다.
다양한 편집 모드
스프링노트는 WYSIWYG이다. 그러면서도 모니위키의 문법을 일부 지원하고, 서식을 적용시킬 수 있는 각종 단축키까지 제공한다! 덕분에 난 모니위키로 만든 나의 컨텐츠들을 그냥 copy & paste를 해서 옮길 수 있었다. (애초에 모니위키를 쓸 때도 복잡한 문법을 사용한 경우가 별로 없었기 때문에-) 게다가 ActiveX 설치 등의 번거로운 작업도 필요하지 않으니, 금상첨화.
서식 수정을 위한 WYSIWYG 인터페이스
그런데 이런 식의 WYSIWYG 인터페이스들은 기존 온라인 오피스 도구들이나 텍스트를 사용하는 다양한 툴들에서 많이 봐왔던 것들인데, 특히 인상깊었던 것은 페이지 링크를 위한 인터페이스. 기존 위키 엔진들이 페이지네임을 가지고, 위키네임(혹은 그것을 대체하기 위한 문법들)으로 그 페이지네임을 가리키는 링크를 생성했던 것과는 달리, 스프링노트에서는 Ctrl + Space 키로 페이지로의 링크를 생성할 수 있다.
위키네임 형태를 과감히 버리고 어떤 형태도 페이지네임으로 사용될 수 있고, UI에서는 몇개의 글자만 적으면 관련된 페이지들을 고를 수 있게 지원하고 있으니, 참 편리하다.
위키식 링크 + Tree 구조 + Color Scheme
위키에서는 페이지를 찾을 때 페이지에 보이는 위키네임에 걸린 링크를 클릭하거나, 페이지 이름을 아는 경우 바로가기 기능을 사용하거나, 혹은 페이지네임이나 full text로 검색을 해서 찾아가는 방식이 있다. 스프링노트는 이러한 위키에서 사용되는 페이지 검색 및 이동 이외에 두가지 더 팬시한 기능을 제공한다.
Tree 구조로 관리되는 페이지들
스프링노트에서는 페이지들이 기본적으로 tree 구조로 관리된다. 메인 페이지(Jayz Springnote)가 하나 있으며, 다른 페이지들은 이 메인 페이지의 하위 페이지로 지정된다. 요즘 너도나도 다들 태깅하는 것에 목숨이라도 건 듯이 태그 기능을 사용하는 것과는 달리, 오히려 위키식와 Tree 구조만 있다. 그런데, 태그보다 이게 훨씬 낫다. = ) 문서라는 특징 때문이기도 하겠지만, 중구난방하고 구조가 flat 하기만 한 태그보다는 이쪽이 더 매력적. 나중에 태깅 기능이 추가될지도 모르겠지만, 지금 블로깅 하는 것처럼 태그에는 별로 손을 안댈 것 같다.
또한 중요한, 자주 보는 페이지들을 표시해 놓기 위해 책갈피라는 이름의 기능을 제공한다. 5가지 색깔의 책갈피를 끼워 놓아 페이지의 visibility를 높이는 방식. 이것은 일종의 카테고리 역할도 함께 수행할 수 있다. (아웃룩을 써 본 분들이라면 flag 기능을 생가하시면 됩니다.) 내가 모니위키를 사용할 때에는 자주 쓰는 페이지들은 메인 페이지에 링크를 걸어 두었었는데, 이런 식으로 color scheme을 제공하는 것이 훨씬 더 그럴싸해 보인다. 다만 색깔을 5개만 해놓으니 '나중에 부족하면 어쩌지?'란 생각이 드는구나.
그래도 아직은 페이지가 적어서 책갈피 기능까지는 안 쓰고 있으니, 괜한 걱정이겠죠. = )
가져오기
워드, 한글, 메모장, HTML 형식의 파일을 업로드해 스프링노트 페이지로 만들 수 있다. 파일을 첨부하는 것과는 달리 XHTML 형태로 변환하는 것이라 예상되므로, 아직 올릴만한 자료가 없어서 테스트는 안해봤지만 과거의 경험들로 미루어 볼 때 어느 정도의 레이아웃 희생은 예상해야 하지 않을까 싶다. 대신 다른 온라인 오피스 제품들과는 달리 파일을 그냥 '첨부'하는 것도 가능하기 때문에, 레이아웃이 복잡하고 원본을 유지하고픈 경우엔 파일을 그냥 첨부해버리는 방법도 있으니 크게 문제될 건 없을 듯. = )
Collaboration
이 부분은 위키 철학에 어긋나는 부분이어서 온라인 오피스군의 특징을 따 온 것 같다. Google Docs에서와 같이 스프링노트에서는 페이지들의 권한 설정을 해줄 수 있다. 이 권한에는 공유자와 열람자가 있는데, 공유자는 페이지를 함께 수정할 수 있는 권한이고, 열람자는 페이지를 볼 수만 있게 하는 기능이다. 이 때 공유자는 스프링노트를 사용하는 사람이어야 하고, 페이지 주인의 초대를 받아야만 가능하다. 열람자의 경우엔 전체 공개/열람자로 초대된 사람에게만 공개 선택을 할 수 있다. 공유자도 '전체 공유' 같은 설정을 넣어주면 좋지 않을까? 히스토리 기능이 완벽히 구현되어 있다면 상관없을 것 같긴 한데... = ) 물론 Spam등의 문제가 남기는 하겠지만, Springnote 회원들만 수정가능, 이런 식으로 어느정도 걸러낼 수 있지 않을까?
내보내기
제일 맘에 드는 기능이다. 서비스의 신뢰도를 가장 중요시했다는 제작진들의 소개에 맞는, 가려운 곳을 쏙쏙 긁어준 제대로 된 기능이다. (굳이 설치형 블로그를 고집하는 이유도 그 때문이다. 적어도 내 스스로가 백업은 할 수 있으니까.) 페이지마다 메뉴에는 '내려받기'가 있어서 페이지들을 xhtml 형태로 내려받을 수 있다. 브라보.
자동 저장
스프링노트의 이 자동 저장 기능에 익숙해지면 다른 웹 서비스들을 사용할 때도 버릇이 드는거 아닌가, 싶은 생각이 들 정도로 위험하면서도 편리한 기능이다.
스프링노트에는 따로 '저장하기' 메뉴가 없다. 뒷단에서 자동으로 모든 데이터들이 저장된다. (이것이야말로 궁극의 AJAX 기능이 아닐까, 혼자 생각해본다.) 브라우저에 스프링노트를 띄워놓고, 필요한 것이 떠오를 때마다 메모를 하고, 브라우저를 그냥 닫아도 된다. 아무 신경도 안써도 된다. 작업하면서 날려버릴까봐 문단 하나, 문장 하나 쓸 때마다 저장하는 수고를 할 필요도 없다. 원츄다.
혹시 저장이 안됐는데 그냥 꺼버리면 어떡하나, 걱정하는 사람들을 안심시키기 위한 한마디. 네트워크 상태가 이상해서 저장이 안되는 경우엔 브라우저 상단에 '현재 저장이 안되고 있습니다, 네트워크가 정상화되면 다시 저장됩니다.'라는 메시지가 나타난다. 물론 그 중에도 사용하는데는 지장이 없고, 네트워크가 정상화되면 '정상화되어 다시 저장하기 시작합니다.'라는 메시지가 나타난다. 또한 브라우저를 닫을 때도, 저장이 안됐으면 알림창을 띄워 저장이 안되었으니 좀 있다가 브라우저를 닫으라고 친절하게 알려준다. 두 경우 모두 직접 겪어본(-_-; ) 일이기 때문에 믿어도 좋다.
WYSIWYM
이건 스프링노트에서 주창하는 새로운 패러다임. What You See Is What You Mean. HTML에서 데이터와 레이아웃을 구분하기 위해 CSS가 나온 것처럼, 보고 있는 문서가 바로 당신이 뜻하는 것이다. 라는 의미다. 사실 일반 사용자에게는 별로 어필되지 않는 철학이긴 하다. 그래도, 확 눈에 들어오거나 당장 필요한 기능은 아니지만, 어쨌거나 필요한 일이고 또 그것을 해냈다는 것에 큰 점수를 준다. 줘야 한다. WYSIWYM을 위해 스프링노트는 페이지들을 xhtml 형태로 사용한다.
스프링노트에도 아쉬운 점들은 있다.
이전부터 굉장히 바라던 컨셉의 서비스이고, 또 성능(?)도 예상보다 훨씬 좋아서 매우 만족하며 사용하고는 있지만, 역시 좀 아쉬운 점들은 있다.
위키 네임
메뉴를 통해 페이지간의 링크를 생성하고, 하위 페이지 개념을 도입한 것도 좋지만, 습관이 들어서인지 위키 네임에 대한 집착 비슷한 것이 생겨버린 듯 하다. 따로 메뉴를 띄울 것도 없이 위키 네임만 쓰면 자동으로 페이지가 연결되거나 새로운 페이지를 만들 수 있도록 지원하는 위키 엔진들이 살짝 그리워지기도 한다.
Source 수정
불릿과 같은 서식을 사용하거나 세세한 서식을 수정하고 싶은 경우엔 WYSIWYG 형식보다 소스를 직접 수정하는게 편할 때가 있다. 그런데 현재는 xhtml 형태로 변환된 페이지를 볼 수만 있고, 소스를 직접 수정할 수는 없게 되어 있다. 자바스크립트 사용과 같은 일을 막기 위한 것인듯 한데, 기왕이면 수정할 수 있게 해주는 것도 좋지 않을까?
내려받기
내려받기 기능은 매우 매력적이지만 아쉬운 기능이기도 하다.
현재 내려받기 기능을 사용하면 html 파일들이 zip 형태로 묶어서 저장되는데, 하위 페이지들을 포함시키지 않고 있다. 예를 들어 'Jayz Springnote'라는 페이지의 하위 페이지들로 'Memo', 'To Do List'와 같은 페이지들이 있어도 'Jayz Springnote'라는 페이지를 내려받으면 'Jayz Springnote'의 컨텐츠만 html 파일로 저장된다. 하위 페이지들을 내려받기 위해선 별도의 관리 메뉴로 들어가야 하는데, 이것은 좀 직관적이지 않고 불편하단 느낌이 든다. 한 페이지를 내려받을 때 하위 페이지들도 함께 내려받을지 선택할 수 있도록 해주면 좋겠다.
그리고 좀 더 욕심을 부리자면, 내려받는 파일의 형식을 지정할 수도 있으면 어떨까? Google Docs의 경우엔 html, doc, pdf, rtf 와 같은 파일 형태들을 제공하는데, 이 기능이 꽤 쓸모있다. 단순히 백업의 성격만이 아니라 오프라인에서 desktop application을 이용해서도 페이지를 수정할 수 있으니, 인터넷을 사용할 수 없는 환경에서 작업해야 할 경우 매우 유용할 것이다. 또한 pdf 파일은 배포에도 효율적이니. = )
아직은 비공개 테스트 중.
스프링노트, 아직은 비공개 테스트 중이다. 3월 말 즘에 서비스가 공개된다고 하니, 많은 사람들이 사용하면서, 더불어 아는 사람들도 좀 들어와서 함께 작성하는 재미를 누려봤으면 하는 소박한 바램이 있다. = )
1. 블로그와 미니홈피가 같은가?
이 보고서에서는 블로그와 미니홈피를 동일 선상에서 바라보고 있다.
이는 대부분의 소위 웹 2.0시대의 1인미디어에 대한 기사나 보고서들에서도 종종 보여지는데, 개인적으로는 아주 마음에 들지 않는다. 이전에 언급했듯이 미니홈피와 블로그는 그 성격적 차이가 분명하다.
(그렇기 때문에 최근 싸이월드의 각종 서비스 개편을 보고 있자면 그러한 점을 제대로 살리지 못하고 블로그나 타 서비스 따라하기의 경향이 늘어나는 것 같아 안쓰럽다.)
그렇기 때문에 블로그와 미니홈피를 같은 분류로 조사해도 될 분류('인터넷 활용 분야'와 같은 분류)가 있고, 그렇지 못한 분류('왜 블로그/미니홈피를 사용하는가'와 같은 분류)가 존재한다.
이 보고서에서는 커뮤니케이션 부분에서 '사람들이 블로그/미니홈피를 이용하는 이유' 중 가장 높은 순위를 차지한 것은 '친교/교제'였는데, 만약 블로그와 미니홈피를 분리해서 조사했더라도 같은 결과가 나왔을까?
개인적으로 사람들이 블로그를 사용하는 이유와 미니홈피를 사용하는 목적이 다를 것이다라는 나름의 가설(?)을 세우고 있었는데,
이 보고서에서도 이놈의 가설을 확인할 방법이 없어졌다. 내심 기대했건만...
2. 정보습득 수단으로서 인터넷 이 보고서에 따르면, 현재 사람들의 주요 정보 습득 수단은 인터넷(95.2%, 복수응답)이며, 그 중에서도 포털 및 검색사이트를 가장 많이(81.3%) 사용하고 있다고 한다.
우선 주요 정보 습득 수단이 TV와 신문에서 인터넷으로 넘어갔다는 것은, 특히 신문의 이용율이 급격히 감소하고(16.2%p) 포털 및 검색 사이트를 주로 사용한다는 것은, 주요 언론 파워가 포털 사이트로 이전하고 있다는 것을 의미한다.
특히 인터넷 정보 수단에서 포털의 강세에 비해 일간지 등 뉴스 사이트의 영향력은 1/10도 안되는 것(6.3%)은, 비대해진 정보들로 넘쳐나는 인터넷과 포털 및 검색사이트의 성격적 특징 때문에 어쩔 수 없다.
이 보고서에서는 '포털 및 검색사이트'라는 항목 자체가 문제시 될 수 있다(포털 및 검색사이트 운용사에서 제공하는 정보인가? 외부 웹 리소스의 인덱싱 정보인가?).
사람들이 '무언가에 대해 모르는' 정보를 인터넷에서 얻는데 검색엔진을 활용하는 것은 당연하다.
그렇다면 문제는, 어떤 사람이 A라는 검색 사이트를 통해 B라는 사이트의 컨텐트를 찾았다고 할 경우, 이 정보를 A라는 검색 사이트에서 얻었다고 생각하는지, B라는 사이트에서 얻었다고 생각하는지가 분명치 않다.
(이것은 검색사이트들의 저작권 문제와도 관련이 있지만 일단 이 문제는 넘어가자.)
아마도 이 설문지에서는 '포털 사이트에서 제공하는 정보(e.g. 네이버 뉴스, 구글 뉴스 등)'를 의미하는 것이었겠지만, 위와 같은 사항들을 명시해 주었어야 하지 않았을지.
3. 사용자 참여 - 퍼나르기 62%
이 보고서에서는 '사용자의 컨텐츠 참여 방법'으로 '카페/커뮤니티', '블로그/미니홈피', '댓글달기', '퍼나르기(펌)'의 4가지를 조사하고 있다.
이 네가지 방법을 통해 사람들이 '사용자 참여'에 동참하고 있다고 조사하고 있는데, 우선 여기엔 '별점매기기'나 '위키'와 같은 항목들도 포함되어 있는지 의심스럽다.
또한, '퍼나르기'의 경우 62.0%라는 꽤 높은 위치를 차지하고 있는데,
1. 사람들이 이렇게 컨텐츠를 잘 '퍼나르는' 것이 과연 바람직한가 하는 의문을 낳고,
2. 이렇게 많은 사람들이 '퍼나르고' 있는데 왜 네이트의 통 서비스는 별 재미를 보지 못한 걸까?
4. 댓글
이 보고서를 읽으면서 가장 '그럼 그렇지.'라고 생각했던 부분이 '댓글' 부분이다.
댓글이라고 하면 악플, 초딩 같은 단어들이 먼저 생각나는 걸 보면, 결코 우리나라의 인터넷 문화가 바람직하지 않은 면을 너무 많이, 또 너무 당연하게 끌어안고 있는게 아닌가 싶은 생각이 드는데,
이 보고서에는 그러한 면들을 잘 드러내는 결과들이 수치적으로 드러나고 있다.
1. '타인 주장에 대한 반론 제기'는 20대 이하 연령층에서 타 연령층보다 높게 나타남
2. 저연령층일수록 댓글 작성 건수가 증가하는 것으로 나타남
3. 스포츠, 연예 분야에 대한 댓글에 관심이 가장 많음
4. 댓글 내용을 신뢰할 수 있다고 생각하는 경우는 35.7%
5. 악의성 댓글에 반론을 제기하거나 신고하는 등 적극적으로 대응하는 경우는 34.8%
이것은 심각한 문제다.
인터넷의 가장 큰 장점인 '다수의 의견/정보 통합'을 잘 살릴 수 있는 댓글이 인터넷을 한낱 무뢰배들의 놀이터로 전락시키고 있다.
'xxx 놀이'와 같은 것들은 재미있기도 하지만 때와 장소(?)를 가리지 못하는 경우도 종종 보이며, 사람들에 대한 근거 없는 (그들의 '유일한 근거'는 자신들의 굳은 선입관이다.) 정보 유포, 인신 공격 등의 일들이 아무런 제재없이 자행되고 있는 것들을 보며 한탄스러워하다가 결국 검증된 블로그나 미니홈피 이외에서는 (누가 읽어보라고 하지 않는 한) 댓글을 전혀 읽지 않게 되었다.
편리함과 정보의 수준의 trade-off에서 편리함이 압승을 거둔 결과다. PV나 유저수에 연연하기만 한 다수의 사이트들이 만들어낸 스스로의 무덤이다.
5. 마무리
글을 쓰다보니 졸려서 이쯤 접는다. (무책임)
그러니 결론은, '보다 성숙한 인터넷 문화를 위해 우리 모두 노력해요.' 정도로 하자.
위키의 ToDoList에, '앗'하는 사이에 10월이 생겨나기 시작했다.
'이제 신입생이에요~'라면서 우스갯소리를 한게 엊그제 같은데, 벌써 한달이 지나버렸다니.
요즘은 시간의 흐름을 잊고 사는지라, 늘상 있는 일이지만 새삼 놀랍다.
그래... 2달이면 1/6년이구나. 허허허.
scene 2. I Love RED
요즘엔 인터넷 쪽의 환경, 문화, 트렌드 등을 조사하는 일을 병행(아마 (적어도 석사 중에는) 메인 테마가 될 듯 하다.)하고 있기 때문에, 각종 사이트들로부터 RSS feed를 받고 있다.
RSS 기술이 널리 퍼져서 엄청나게 다행이라고 생각하는게,
RSS Reader가 아니었다면 난 하루에도 몇시간씩 이 조그만 눈을 부비작거리며 안되는 영어로 인터넷의 바다에 빠져 즉사해 버렸을거다.
(왜 외국 신문 사이트들은 기사 찾는 것도 그렇게 어렵게 느껴지는거냐!)
어쨌거나 나름 메인 사이트라고 여겨지는 녀석들의 RSS feed를 Sharp Reader를 통해 받고 있다.
(그것만해도 양이 엄청나서 아직 헤매고 있긴 하지만.)
그런데, 가끔...
요렇게 사이트 이름이 빨간색으로 나올 때가 있다!
푸하하. Sharp Reader에서 빨간색은, "오류 발생"을 의미하는 것이므로! 이것을 핑계로 "오늘 이정도만 하자"라는 (혼자만의) 핑계 거리로 사용한다.
우하하하하하하하하하하하하하하하하하하하하하하하하.
scene 3. Note
갑자기, 아무 이유 없이, 눈을 감았는데... 감옥에 갇혀 있다는 느낌이 났다.
아니, 감옥에는 가본 적이 없으니, 이 표현은 적절치 않다.
죽을 때까지 벗어날 수 없는 그 무언가에 둘러싸여 있는 느낌.
평소엔 인지하지 못했던 것임에도, 어느 순간 느껴버리게 된 위화감.
"매트릭스"에서 "네오"가 느끼던 "뭔가 이상한" 기분이란 이런 걸까?
도대체 너의 정체가 뭐냐, 날 둘러싸고 있는 너는.
-- Note on 2005.09.25
요즘 화이트보드가 하나 땡긴다.
아이디어 정리나 해야 할일 같은 것들을 위키나 수첩을 이용해서 적어놓고 있긴 한데,
뭐랄까, 가시성이 떨어지는 것 같아서 똑같은 짓을 또 하고 있거나, 잊어버리거나 하는 경우가 다반사다.
특히나 프로젝트 하면서 언어 스키마 만들거나 시스템 컴포넌트 만들 땐 아주 쥐약이야...
그림 편하게 그리고 슥삭슥삭 지웠다가 다시 그리고, pros & cons 같은 것도 막 적어놓고, 아이디어 메모도 해놓고...
타블렛 노트북이 땡겼었지만 200만원이 넘어가는 가격에 좌절하고, 분명 생각보다 쓰는게 불편할거야! 라면서 위안했더니...
그럼 화이트보드는 어떨까? 로 귀결된 것인데...
가격 알아보니 생각보다 싼 편이고... 조그만거 하나 사서 책상 옆에 놔둘까?
혹시 써보신 분들은 어떠신지?
scene 2. 향기
향기나는 사람이 되고 싶다.
어떻게 해야 할까?
누가 충고 좀 해줘요.
@향수 뿌려. 같은 소리 하는 사람들은 초딩으로 간주됩니다! 둥둥둥.
scene 3. 집착
"네가 하고 있는 건 사랑이 아냐. 집착이지."
"네가 사랑이 뭔지 알아? 어떻게 그렇게 단정할 수 있어?"
"...네가 날 사랑한다면 날 놓아줄 수도 있어야 하는거 아냐? 소유욕이나 집착이 사랑을 대신할 순 없어."
"웃기지 마. 집착이 없는 사랑이란 게 있을 수 있어? 그건, 네가 날 사랑하지 않기 때문에 할 수 있는 말이야. 사랑하기 때문에 놓아주라고? 사랑하기 때문에 헤어진다고? 말도 안돼. 그건 사랑이 식어버렸음을 인정하고 싶지 않은 위선자들이 내뱉는 모순이야."
---실제로 난 '사랑하기 때문에 헤어진다'는 말을 싫어한다. 왜? 라고 되묻는다.
scene 4. 10%
하지만, 언제나 너의 그 잘난 계산이 맞아 떨어지는 건 아냐.
이런거 생각해 봤어?
10명 중 한 사람이 나머지 사람들과는 다른 의견을 주장했어. 이건 10%지.
그리고 다른 100명의 집단에서 10사람이 나머지 사람들과 또 다른 의견을 주장했다고 쳐. 이것도 10%야.
그럼 이게 똑같을까?
틀려. 10명 중 1명의 의견은 무시되지만, 100명 중 10사람의 의견은 무언가 변화시킬 수 있거든.
---inspired by '헌터x헌터'
요즘은 연구실에서 그런 걸 느낀다.
scene 5. 언니
수미 누나랑 MSN으로 잠깐(?) 대화를 나누다가, 졸지에 언니라고 부르게 되었다.
쿠하핫. 정말 난 여자로 태어났어야 할 운명인 걸까?
---어딜 가나 다들 비슷한 고민을 하는 것 같다. 난 직장을 얻게 되면 고민이 좀 덜해지지 않을까, 싶었는데 그것도 아니더라. 살아가기 참 힘들다.
블로그의 인기는 식을 줄 모르며 누구든 최신 기술을 좋아하는 건 부정할 수 없는 사실이다.
그러나 블로그가 과연 기업 내부의 통신용 툴로도 과연 적합할 것인가? 블로그와 위키를 비교해, 특히 공공기관에서 사용하기 좋은 것이 어떤 것일지 골라보자.
이 글을 쓰기 전 기업 내 차세대 통신 수단으로 블로그가 적격이라는 기사를 읽은 바 있다. 그런데 솔직히 말해 나는 블로그가 기업, 특히 공공기관에 적합한 툴이라는 생각에 그다지 동의하지 않는다.
몇몇 기업에서는 블로그와 같은 개인 정보 배포 시스템이 괜찮다고 결론내리고 직원들이 참여할 수 있는 내부용 블로그(IBM의 경우)나 외부용 블로그(썬 마이크로시스템즈의 경우)를 만들기도 했다. 외부에 노출된 시스템의 경우 블로그 이용 규칙, 그리고 넘지 말아야 할 선이 직원들에게 주입되지만, 시간이 지나고 규모도 커지면서 회사 측의 검열은 없어질 수밖에 없다.
내부 블로그도 아주 유사한 형태로 운영된다. 하지만 회사 내부의 이야기는 사실 “은연중에” 블로그에 게재되기 마련이다.
신기술 거부론자가 되는 건 싫지만 내부 블로그건 외부 블로그건 상관없이 블로그는 기업 환경에서 폭넓게 사용할 만한 가치가 있기보다는 문제거리가 될 소지가 높다고 본다. 그래도 나는 특수한 상황, 즉 인트라넷 상의 보안 경고 블로그를 만드는 IT 부서나 선거로 당선된 단체장과 같은 사람들이 내부 구성원들과 대화할 목적으로 블로그를 만드는 경우에서는 블로그가 가치있는 툴이 될 수도 있을 거라고 생각한다.
정부 기관들의 경우 “한 목소리”를 내는 것조차도 힘든 것이 현실이다. 국가 기관의 공식 블로그에 현 정책을 거침없이 비판하는 공무원 때문에 혼란이 야기되는 상황은 단지 상상속의 일만은 아닐 것이다.
즉, 직원들에게 인트라넷 상에 자기 생각을 이야기할 수 있도록 한다면 아마도 득보다는 실이 많다는 부정적인 결론이 도출될 것이다. 공공 기물을 개인 용도로 사용하는 것도 문제이며 HR 규칙도 그렇고, 게다가 내부 블로그에 쓴 글은 몽땅 다 공개된 기록으로 남을 수밖에 없다. 이처럼 복잡하고 귀찮은 문제를 정말 떠안고 싶을까?
통신 방법이 부족하다는 말도 그렇다. 이메일, 메신저, 그룹웨어 등 이런 건 다 무엇인가. 의견을 공유하기 위해 또다른 툴이 정말로 필요한 것일까?
내가 기업 내에서 잠재력이 더 크다고 보는 기술은 바로 위키다. 위키가 뭐냐고? 위키에 대해 세상에서 가장 대중적인 정의를 내려보자. 들어봤을지 모르겠지만 위키피디아(Wikipedia)의 정의를 살펴보자.
“위키란 사용자들이 내용을 추가할 수 있는 웹 애플리케이션으로, 인터넷 포럼이지만 누구라도 내용을 수정할 수 있다… 위키는 웹 브라우저에서 간단한 마크업 언어(markup language)를 이용해 공동 문서를 작성할 수 있게 해준다.”
위키는 인트라넷 기능을 멋지게 강화한 시스템으로 상대적으로 저렴한 비용으로 협업 기능을 이용할 수 있도록 한다. T위키(Twiki)는 오픈소스 라이선스를 따르는 구조화된 위키로, 모토로라, SAP, 야후, 디즈니와 같은 대기업들이 사용하고 있다. 다른 종류의 위키로는 잣스팟(JotSpot), 소셜텍스트(Socialtext), 그로브사이트(GroveSite) 등이 있다.
표준 인트라넷 웹페이지와 비교할 때 위키의 장점은 무엇일까? 위키라고 다 같은 건 아니지만 위키가 갖는 공통적인 속성은 공유하고 있다.
사용하기 쉽다 : 페이지 편집, 페이지 연결, 텍스트 형식 변환은 표준 HTML에 비해 훨씬 더 쉽다. 게다가 페이지를 업로드할 때 FTP가 필요치 않다.
관리하기 쉽다 : 변경 관리는 위키가 가진 본래 속성이며 위키에서 일어난 모든 변화는 차후 추적 가능하다. 위키의 모든 텍스트는 검색 가능하고, 위키의 내용은 쉽게 구조화된다.
원하는 기능을 추가할 수 있다 : 사용중인 위키 도구가 무엇이냐에 따라 표준 인트라넷 사이트에서는 프로그램적으로 하기 어려운 일들, 이를테면 데이터베이스 접근, 파일 업로드와 다운로드, 위지위그(WYSIWYG) 기능 등을 플러그인을 이용해서 위키에 아주 쉽게 추가할 수 있다.
위키는 온라인 백과사전인 위키피디아를 만드는 데 사용하는 것 뿐 아니라 다음과 같은 일을 할 때에도 사용할 수 있다.
헬프 데스크 도구
FAQ, 표준 문서, 회의록
지식 베이스(Knowledge base)
프로젝트 협업 도움
위키의 단점은 역설적이지만 ‘누구나 기여할 수 있다’는 점이다. 이 말은 내용에 대해 제어하기가 상대적으로 어렵다는 의미다. 하지만 Twiki같은 것들은 좀더 구조화돼 있고 내용 수정 허가 기능도 포함돼 있다. 따라서 제어는 상대적으로 큰 문제는 아니다.
명심해야 할 게 또 있다. 지원 문제다. 위키 소프트웨어를 어디서 구했느냐에 따라 오픈소스 공동체나 소규모 업체의 지원에 목을 맬 수밖에 없을 수도 있다. 대다수 위키 툴들의 경우 유지해나가려면 회사 내에 펄(Perl), 자바/자바스크립트, 리눅스/유닉스를 다룰 줄 아는 사람이 상시 대기해야 할 것이다. 윈도우 기반 위키도 몇 개 있으나 리눅스에서 구동되는 위키가 더 많다.
요약해보자. 필자는 블로그가 정부 조직의 통신 수단에 가장 적절하지는 않다고 생각한다. 대신 위키는 어디든 도입을 고려할 게 틀림없을 만큼 저렴하고 상당히 유용한 툴이라고 본다.
최근 웹 기반의 협업 관련 툴을 만들어볼 생각을 하고 있었습니다...
블로그에 너무 어려운 글들이 올라온다...는 지적을 여러번 받고 있다는게 동기라면 동기였죠.
어차피 그런 글은 볼 사람만 볼텐데, 그냥 지식발전소를 없애지 말걸 그랬을까요...;(하지만 언제까지 연구실 서버에 빌붙을 수도 없는 거고...)
그런데 생각해보니 계속 이렇게 시간에 쫓기는 주제에 뭘 만들어보겠다고...라는 생각도 들고,
해서... 차선책을 찾고 있는 중입니다.
아마 데스크탑에다가 APM 패키지 정도 깔아놓고 그거에 맞는 위키를 설치해 두는 정도가 될 듯... - _-)a
홈페이지의 시작은 2000년 11월 26일이었습니다.
가을학기에 휴학하고선 뭘 하면 좋을까... 생각하다가 뜬금없이 만들었었더랬죠.
기억하는 사람들도 있겠지만, all black에다가 html로만 이루어진 조잡한 text+image 기반의 홈페이지였습니다.(웃음)
온갖 사진과 이미지들을 캡처, 스캔해서 올렸더랬죠.
끔찍한 막노동이었어요. 이미지 하나 추가하면 모든 페이지들의 링크를 손봐야 했고... 어휴.
과거
초반의 html 기반의 페이지에서,
꽤 한참이나 후에야 spboard( http://www.spcgi.com/ )를 이용해 게시판을 돌리기 시작했죠.
세팔님이 개발하신 perl언어 cgi 기반의 깔끔한 게시판이었는데, 요즘은 각종 블로그 툴과 zeroboard에 밀려 많이 보이지 않는 듯...
하지만 숀과 함께 밤새 spboard를 셋팅하던 추억이 담겨 있기 때문에 아직 애착이 가는 게시판입니다.
(제로보드에 왠지 모를 반감이 드는 건 그 때문인가... -_-;)
한동안은 spboard의 테마 기능을 이용해 홈페이지를 운영하기도 했었습니다. 네...
일일히 html 코드를 손보지 않아도 된다는 사실이 참 즐거웠더랬죠^^
올해 들어서야 태터툴즈( http://www.tattertools.co.kr )와 모니위키( http://moniwiki.sourceforge.net/ )를 이용한 체제로 자리잡았습니다.
2000년에 홈페이지를 만든 후에도 학교내 전자게시판이나 싸이월드, 네이버 블로그 등을 잠깐씩 병행해서 사용한 적이 있지만,(다시 생각해보니 잠깐...은 아니군요.) 역시 제일 잘 노는 곳은 직접 만든 홈페이지였습니다, 네... ^^
현재
현재 돌리고 있는 홈페이지는 모두 2개... 라고 하기엔 좀 부족한데, 하나씩 얘기해보자면...
하나는 이곳, JayZ감성공작소( http://jackleg.x-y.net )입니다.
x-y.net( http://www.x-y.net )에 돈내고 호스팅받아서 하는 거라 아마 죽 이곳을 메인으로 쓸 생각입니다.
x-y.net에서 올해 MySQL 100MB를 추가로 호스팅해 준 덕분에 태터툴즈로의 이동을 감행했죠.
이곳엔 주로 개인적인 이야기들을 올리고 있구요...
나름의 법칙(?)이라고 한다면 나름 블로그의 철학을 지키기 위해 노력한다는 것 정도랄까...
가끔 보면 블로그가 너무 사적인 목적으로 사용되는 것이 아닌가...라는 것을 한탄하는 분들이 계시는데,
분명 블로그가 저널리즘 덕분에 유명해진 것은 사실입니다만... 어떻게 사용하는가는 개인의 취향 문제가 아닐까 생각합니다.
그런다고 제가 막말을 하는 것도 아니고... -_-;
다른 하나는... 이건 별개의 홈페이지라고 하기는 좀 애매하지만, 함께 돌아가고 있는 JayZ지식발전소( http://bizcom.snu.ac.kr/jWiki/ )가 있습니다.
이곳은 위키를 기반으로 각종 잡스런 지식들을 정리해 두는 곳인데요...
연구실 도메인을 몰래-_- 쓰고 있는 것인지라 조만간 이동하게 될 지도 모르겠습니다.
아마도 지식발전소를 없애고 감성공작소와 통합시킬것 같긴 한데...
쨌든, 이곳에 오는 분들은 거의 없다고 해도 무관... -_-;
(일반인(?)이 보기엔 난해한 글들이고, 전문가들이 보기엔 형편없는... -_-;;;)
또 하나는 싸이월드( http://cyworld.nate.com )의 미니홈피.
이곳은 거의 손대고 있지 않습니다. 따로 도메인을 신청하지도 않았구요... 싸이월드 접속하셔서 저 찾아 들어오시거나 일촌 신청해서 오셔야 할 겁니다.
최근 미니홈피도 좀 살려볼까...란 생각을 하고 있기는 합니다만, 역시 좀 심기가 불편하다고나할까... 그렇습니다.
너무 가벼워지는 듯한 느낌.
미래
그냥, 계속 이렇게, 운영할 생각입니다.(웃음)
누가 오든지, 그냥 중얼중얼 저의 이야기를 해 나갈 것이고... 또 그걸 보고 함께 생각해주는 친구들이 있다면 그걸로 충분히 좋겠네요.
바라는게 있다면 오시는 분들 코멘트 많이 부탁-_-*(수줍)
남아있는 주제들
15. 공주님
16. 할머니
17. 새벽 3시 반
18. 장마
19. Fantasy
20. 발렌타인 초콜릿
21. 맥주
22. 소꿉친구
23. 쌍둥이
24. 기면증
25. 푸른색 원피스
26. 명동
27. 제야의 종소리
28. 엘리베이터
29. 시한부인생
30. 통학버스
31. 기차여행
32. 만우절
33. 편집증
34. 이방인
35. 열대야
36. 식중독
37. 액자
38. 백야
39. 제사
40. 서점
41. 거울
42. 말
43. White
44. ID
45. 기말고사
46. Moon
47. 피아노
48. 소원
49. 동그라미
난생 처음 TEPS 시험을 보다.
TOEIC보러 갈 때, 9시까지 입실이어서 "으아~ 30분만 늦춰주면 시험 더 잘 볼텐데!"라고 투덜거렸는데,
정작 9시 30분까지 입실인 TEPS를 볼 때는, "아우... 어차피 조는거 차라리 9시에 시작하고 일찍 끝내지." 이러고 있다... (-_-)
시험 준비는 개뿔; 어제 모의고사 하나 사서 풀어봤더니 결과가 꽤 희망적(?)으로 나와서 그냥 잤는데-_-;
500점 받는게 도대체 어느 정도 수준인지 궁금해서 기어코 TEPS 홈페이지를 뒤져서 찾아봤더란다.
외국인으로서 중하급 수준의 의사소통능력:중장기간 집중 교육을 받으면 한정된 분야의 업무를 다소 미흡하지만 큰 지장은 없이 수행할수 있음.
(Low Intermediate Level Communicative Competence)
최근엔 위키 탐방이 있었다.
랩 홈페이지를 위키로 만들라는 교수님의 어명. (털썩)
교수님이 요구하신 스펙은, 위키 기본 기능이 지원될 것이며, RSS, search기능은 물론이고, 블로그 기능이 될 것.
게다가 파일 관리 기능까지... (풀썩)
예전에 잠깐 썼던 MoniWiki는 rcs인지 뭔지를 써야 버전 관리가 되는지라 알아보지 않았고,
(아아, 정말 언제나 리눅스 공포증에서 벗어나나. 공부해야하는데! 머신이... 으음.)
wikiX, MoinMoin 등 잡다구레한 위키클론들을 설치해 보았으나 다들 2%씩 부족한... (풀썩)
(PHP나 Perl 공부를 해야 하나? 끙...)
그러다가 우연찮게 KLDP 프로젝트 페이지에서 MoniWiki 프로젝트가 아직 진행중임을 발견!
외부 rcs를 사용하지도 않고 php기반이었다! 만세!
하지만... 홈페이지로 사용하려면 위키가 되면서도 필요한 페이지는 잠글 수 있는 기능이 있어야 할텐데, 그 기능은 지원 안한다네.(풀썩)
뭐, 원래 Wiki 철학에 비춰보자면 없는게 당연하긴 하지만... wikiX에는 구현되어 있던데...(울먹)
좀 더 알아봐야겠다.
아아, 그리고.
애니원에서 Stand Alone Complex와 후르츠 바스켓, 풀 메탈 패닉 해준다.
감동받았다.
다시 본다.
봐야 하는 거다!
SAC는 이름을 전부 영어 이름으로 바꿔버려서(;;;) 좀 헷갈렸지만 얼굴만 봐도 매치가 되니 그냥 볼만하다.
게다가 오늘은 마지막 회! 빼먹지 말아야지.
후르츠와 풀 메탈 패닉은 잘 챙겨보진 못하지만... 기회가 되면 계속 챙겨 볼 생각.
우후후후후후후후후후후후후후후후후후후후.
마지막으로.
새삼(?) 느끼는 거지만.
서울 물가 너무 비싸... (풀썩)
대전이 그리워요_ㅠ
주말이라고 영화 하나에 8000원이나 받다니...(펑)
앞으론 조조나 심야 스페샬-_-을 애용해야지. 랄라.
덧붙여.
랩 월급이 PBS로 바뀌었다.
약자로 쓰니 뭔가 있어보인다.
Project Based System이다.
한마디로 일한 만큼 받으라.
나야 뭐... 계속 프로젝트 해 왔으니 월급이 줄거나 하는건 아니지만,
문제는... 돈이 지속적으로 나오는게 아니라는거다.(펑)
스스로가 지름신이 오시진 않으셨어, 응. 이라고 말하고 있긴 하지만,
또 모르지. 어느날 통장에 거액의 돈이 텅. 하고 들어오면 각종 기기들을 질러버릴지도.
(4년 전이 생각나는군-_- 나름대로 early-adapter였던 시절...)
그리고 3-4달 동안 컵라면만 먹으면서 지내는거야-_- 으하하하하하.
(정신차려!)
#1.
대략의 장소와 시간 정도는 정하게 해주지 으하하하. 약간의 팁은 시간은 살짝 이르면 좋겠고 장소는 가능하면 강북이 좋아. -0-;;;
댓글