Digital Identity Stories

DDoS 공격에 대해서 왜 MS는 침묵하는가? 또, 보안업계의 책임은?

2009-07-11T10:09:41Z

2009년 7월7일 부터 10일까지 한국을 강타한 DDoS 공격 !!

지난 3일간 모든 관련 기관은 DDoS 공격을 방어하기 위해서 많은 노력을 했다.

공격을 직접 당한 사이트의 보안 담당자들은 이틀, 삼일 밤을 꼬박 새면서, 우회로를 만들고, 방어 시스템을 구축하고, 모니터링을 하면서 아찔함과 안도감을 넘나들었다.

안철수 연구소와 여러 보안 업체들은 악성코드 샘플을 얻어서 분석하여, 9일 3차 공격과 그 방법에 대해서 경고를 해 주었다.

국정원은 북한이 최종 배후에 있다라는 발표를 함으로서 정치권에 사이버 북풍 논란을 야기하고, 사이버 수사대는 좀비 PC 찾으러 전국을 헤매고, 방통위는 ISP 를 만나서 좀비PC 차단 과 숙주 IP 차단을 논의하고, 금감원은 은행들을 모두 모아 대책 마련하라고 하고, 청와대는 200억 예산을 바로 투입하겠다 한다.

이용자들은 메일 접속 안된다고 고객센터에 메일로, 전화로 항의하고, 인터넷 뱅킹 안되는 것 때문에 화가 나고, 북한이 배후에 있다라는 기사 보고 ㅉㅉ 거리고, 그나마, 우리의 안철수 박사님께서 지시를 내리시니 "바이러스 검사 해 볼까" 하다가 안랩에서 "PC HDD 를 망가트린다" 는 경고를 보고 ( 일부언론의 PC 자폭 제목은 정말 짱이었다. ) 그제서야 안랩에서 전용백신을 다운로드 받아서 9일에만 70만이상 다운로드가 됐다라고 한다.

수많은 사람들이 방어 하느라 고생하여, 이제 소강 국면으로 접어들었다. 7월7일 티맥스 윈도우 설명회가 있었는데, 부족한 완성도에 비해 거창한 행사로 많은 비난을 받았지만, DDoS 공격으로 주류의 관심에서 멀어졌다. 티맥스 회장님과 강만수 전 장관은 오히려 안도했을까? ( 이건 농담입니다. ^^ )

그런데, MS 는 어디에도 보이지 않는다. 예전의 1.25 인터넷 대란은 MS 가 그 한가운데 있었다. MS 의 SQL Server 취약성이 문제가 되었고 전세계를 마비시켰다. 내 기억으로 MS 는 정말 열심히 대응 방안을 제공했었다. 그런데 왜 이번엔 어디에도 MS 의 얘기는 나오지 않는가?

MS 얘기가 나올때는 좀비PC 가 양산되는건 ActiveX 의 무분별한 이용으로 인한 웹브라우저와 OS 의 이용자 선택권을 제한 한 우리나라 사이트의 문제 때문이다 라는 의견 뿐이다.

악성코드의 유포 경로는 아직 정확히 알려지지 않았다. 혹자는 1년 이상 된 MS Media Player 취약성 때문이라고도 하고, 혹자는 최근 발표한 MS 취약성으로 인한 ZERO DAY 공격 ( 아직 패치도 나오지 않은 ) 이라고도 한다.

MS 입장에서 보면, 한국에서의 3일간 난리는 아무것도 아닌것 인가?

엄청난 물질적인 피해와 영업방해, 그리고 정신적인 피해의 원인을 제공한 MS 에 피해보상을 요구해야 하는 것인가? MS Windows 를 공짜로 사용한다면 할 말 없지만, 대부분 몇십만원 주고 OS 를 구매했지 않은가?

그래서, 궁금하다.. MS 는 왜 이리 조용한가? MS 의 보안 사이트는 이 난리에 대해서 왜 일언 반구도 없는가?

두번째, 안철구연구소를 비롯한 PC 그린, 알약은 이 악성코드를 확인하고 악성코드를 치료하는 기능을 업데이트 하였다. 악성코드가 특정 사이트에 초당 수십번 이상의 접속을 지속적으로 계속 하는 패턴을 가진다. 더구나, 해당 코드는 정상적인 HTTP 요청이 아닌 경우가 대부분 이었다. 그런데, 악성코드가 확인되기 전에라도, 이러한 패턴으로 패킷을 날리는 비정상적인 경우는 충분히 차단할 수 있지 않을까?

이미 유사한 기능의 제품들이 있는지 잘 모르겠으나, 기술적으로 충분히 가능하다고 생각된다. 실시간 감시 라는 기능은 도대체 무엇인가?

3일 밤낮을 새우고, 아직까지도 고생하고 계시겠지만, 무조건 이용자 의식을 향상시켜야 한다고만 하지 말고, 백신 보안 제품 기능에 대한 반성도 해 주셨으면 한다.

이번 공격을 PC 단에서 미리 차단하는 기능이 V3 Lite 에 있었고, V3 Lite 가 미리 설치되어 있는 PC 에서는 좀비 PC 가 되었다 하더라도 DDoS 공격은 수행하지 못했다 라면, 그 얼마나 행복했을까 라는 생각이다.

tag : 마이크로소프트, 악성코드, 안철수연구소, DDoS

구글 멀웨어 경고 장애와 Gmail 스팸필터 장애

2009-02-01T13:21:04Z

미국시간으로 오늘 오전 6시30분 부터 7시 반까지 구글의 모든 검색 과 Gmail 에서 문제가 발생했습니다.

http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html

If you did a Google search between 6:30 a.m. PST and 7:25 a.m. PST this morning, you likely saw that the message "This site may harm your computer" accompanied each and every search result. This was clearly an error, and we are very sorry for the inconvenience caused to our users.

이러한 경고를 하기 위해서 구글에서는 사이트 리스트를 관리합니다. 문제의 원인은 관리자 실수로 이 사이트 리스트에 "/" 이 들어갔다는 겁니다. "/" 는 모든 URL 에 들어가 있습니다. 그래서, 당연히 모든 검색 결과의 사이트 링크에 위 경고가 노출되고, 이곳으로 이동할 수 있는 링크가 제공되지 않았습니다.

그리고, 이 실수가 Gmail 에도 영향을 주었습니다. 이 시간동안 Gmail 로 온 메일들중 일부를 스팸폴더로 전송했다고 합니다. Gmail을 업무용으로 이용하는 사람들 상당한 혼란이 하루 종일 있을 거 같습니다.

http://gmailblog.blogspot.com/2009/01/this-mornings-spam-filter-issue.html

한 시간 정도의 실수라면, 꽤 큰 사고 입니다. 단순히 이용자 불편 뿐 만 아니라 구글 시스템에도 상당한 부담들이 있었을 겁니다. 좀 더 빠르게 대응 할 수 없었을까요? ^^

단지, "/" 을 스팸 리스트에 넣었을 뿐인데, 이 한 줄이 전세계에 영향을 주네요.

구글은 매우 심플하게 "What happened? Very simply, human error.' 라고 바로 인정하네요. 단순 사고라고 발표했지만, 이로 인한 사회적인 혼란에 대해서는 어느 정도 책임을 져야 할 거 같은데요. 미국에서는 어떻게 진행이 될까요?

"우리 사이트가 악성코드를 배포할 수 있다고 하다니.. 우리에 대한 허위 사실 유표다!! " 라고 하여 명예훼손 또는 "일정시간 동안 사이트 링크를 제공하지 않았으므로 영업 방해다" 라고 구글을 고소할 까요?

"중요한 사업상의 메일이 이 장애로 사라졌다. 난 , 스팸 폴더의 메일을 비웠을 뿐이고 ~~~" 구글 너희들이 책임져... 라면서 구글을 고소하는 경우도 있겠죠?

이렇게 영향력이 큰 사항에 대해서는 보안이 필수 입니다. 핵폭탄이 "프로그램 한 줄" 잘못 check-in 한 거 때문에 발사 된다면 어떻하겠어요 ^^;

tag : 구글, Gmail, 멀웨어, 스팸필터, malware

네이버 오픈캐스트를 누구나 운영할 수 있을까?

2008-12-15T18:07:30Z

오늘 블로그 뉴스에 네이버 오픈캐스트에 대한 글들이 많이 있군요.

오픈캐스트 : http://opencast.naver.com

새로운 네이버 첫 페이지 : http://open.www.naver.com

오픈캐스트에는 다른 블로거의 글도 링크 할 수 있습니다. 이로 인한 문제는 없을까 생각해 봤습니다. 광고 마케팅 및 음란 스팸의 문제는 둘째 치고, 선량한 캐스터들이 실수할 수 있는 문제가 있더군요. 이에 비해 선량한 캐스터들을 보호할 수 있는 장치는 아직 미흡해 보입니다. 바로 저작권 과 본인확인 이슈입니다.

1. 저작권 이슈

요즘 Daum 와 NHN 양사가 저작권 이슈로 검찰의 조사를 받고 있습니다. 얼마전엔 압수수색도 당했죠. 오픈캐스트도 예외가 될 수 없습니다. 저작권 이슈가 있는 블로그 글을 오픈캐스트에 링크로 넣는 것 만으로 저작권 침해가 될 수 있습니다. 또는 남의 블로그 글을 허가 받지 않고 오픈캐스트에 링크로 넣는 것 만으로도 침해가 될 수 있습니다.
오픈캐스트 운영원칙을 보니, 이러한 것을 "부적합 컨텐츠" 라고 정의하고 적절히 제한한다고 합니다. 그러나, 저작권 이슈가 되는지 안되는지에 대해서는 선량한 캐스터가 판단하기 어려울 수 있습니다. 잘못하면, 선량한 캐스터가 어느 순간 범법자가 될 수 도 있습니다. 좀더 적극적인 보호 방안을 제공하길 기대합니다.

2. 제한적본인확인 이슈

많은 사람들이 기대하는 오픈캐스트의 모습이 이 문제로 좌초될 수 있습니다. 정보통신망법에 의하면 일정수준 이상의 방문자가 있는 인터넷 게시판은 글을 게시할때 제한적 본인확인을 받아야 합니다. 이를 어길 때에는 최고 3천만원이하의 과태료를 물게 되어 있습니다. 2008년 12월14일 부터 시행되는 정보통신망법에 의한 것 입니다.

Daum 블로그 뉴스의 경우에, 블로그 뉴스에 송고 하려면 Daum 계정이 있어야 하고 제한적본인확인을 받아야만 합니다.
Naver 오픈캐스트의 경우에, 오픈캐스트가 되려면 Naver 계정이 있어야 합니다. Naver는 실명확인을 하는 곳 이므로 오픈캐스트 생성에는 문제가 없습니다. 그런데, 여기에서 문제가 발생합니다. 오픈캐스트에 다른 사람의 글을 게시(링크)하게 되면 어떻게 될까요?

이러한 경우에, 이 캐스트가 Naver 첫 페이지에 올라갈 수 있을까요? 현재 법령대로 한다면 NO 입니다.

가능한 경우를 생각해 봅니다.

1) 캐스트에 포함된 모든 컨텐츠가 네이버 블로그 인 경우 ( 네이버 계정은 모두 실명확인 되어 있으므로 )
2) 캐스트에 게시한 컨텐츠에 대해서 캐스터가 직접 제한적본인확인을 한 경우 ( 예, 티스토리에서 캐스트를 게시한 경우 )

이외에는 아웃링크로 연결한 캐스트는 네이버 첫페이지에 올라갈 수 없습니다. 법령 위반입니다. 해당 캐스터는 제한적본인확인 위반이며, 네이버는 이를 방조한 것으로 볼 수 있습니다.

이를 해결한 시나리오는 다음과 같습니다.

캐스터가 좋은 정보를 발견합니다. 글 게시자에게 자신의 캐스트에 링크해도 괜찮은지 문의합니다. 동시에, 본인이 운영하는 캐스트는 네이버에서 몇십만 구독자를 가진 캐스트이다라면서 제한적본인확인에 필요하니 실명/주민번호를 요구합니다.

캐스트가 웹 서비스를 운영하는 사업자라면 위와 같은 것이 가능하겠지만, 일반 블로거 들에게는 거의 불가능합니다. 네이버에서 캐스터들을 위한 제한적본인확인 툴을 제공한다면 모르겠네요. 결국, 일반 블로거들이 오픈캐스트를 운영한다는 것은 생산량이 매우 많은 경우를 제외 하고는 거의 불가능합니다.

이러한 상황이 나타나는건, "제한적 본인확인" 이라는 과도한 규제 때문입니다. Daum 첫페이지, Naver 첫페이지에 노출되는 글은 반드시 "제한적본인확인" 의 대상이 되기 때문입니다.

그렇다면, 왜 Daum 첫페이지, Naver 첫 페이지와 같은 곳에 노출되는 게시글은 꼭 "제한적 본인확인" 대상이 되어야 하는가에 대한 의문을 가지게 됩니다.

이곳은 책임있는 운영자에 의해서 관리되고 편집되는 곳인데, 여기에 제한적본인확인 규제를 넣는 것 보다는 해당 운영자에게 게시 컨텐츠에 대한 책임을 묻는 것이 맞지 않을까요?

네이버 오픈캐스트도 마찬가지 입니다. 캐스터가 캐스트 운영 원칙을 잘 지켜서 정보를 편집하면 되지, 왜 이러한 정보의 생산자를 캐스터가 본인확인해야만 하는 건가요?

네이버가 이 문제를 어떻게 해결할까요? 네이버가 이 문제를 해결 한다면, 티스토리 TOP 에 내 블로그 글이 피처링 되기 위해서 제한적 본인확인 할 필요 없어질겁니다.

tag : 네이버, 저작권, 실명제, 오픈캐스트, 제한적본인확인, OpenCast

Daum 툴바로 오픈아이디 지원 사이트 이용을 편리하게 하는 법

2008-10-28T10:22:31Z

오늘 아침 버스에서 RSS 피드로 등록한 기사들을 보다가 오픈아이디 관련 기사를 몇 개 확인했습니다.

아래 글은 ETRI 의 김승현님께서 포스팅한 글 입니다. WebApps 에서 오픈아이디에 대해서 발표하셨더군요. 또, 야후의 오픈아이디 사용성 기사도 흥미로왔습니다.

http://ayo79.egloos.com/3956889

http://ayo79.egloos.com/3943792

또 하나는 테크 크런치에 올라온 MS 의 오픈아이디 지원 기사 였습니다. 오픈아이디를 "De Facto Login Standard" 라고 하네요. 와우 !!

http://www.techcrunch.com/2008/10/27/windows-live-adds-support-for-openid-calls-it-de-facto-login-standard/

오픈아이디에 대한 포스팅를 읽고, 오랫동안 이런저런 핑계로 오픈아이디 그룹에서 별다른 활동을 하지 못했다는 반성과 함께 새로운 사이트가 뭐가 있나 돌아다녀 보다가 Daum 툴바 의 바로가기 기능 과 로그인 기능을 이용하면 오픈아이디 로그인을 편하게 할 수 있을 것 같다는 생각이 들어서 이렇게 포스팅을 합니다.

오픈아이디로 로그인 하려면, 방문한 사이트에서 오픈아이디 Provider 페이지로 이동하게 됩니다. 여기에서 아이디/비밀번호를 입력하고 사이트 승인을 하고 비로소 방문한 사이트에 로그인을 하게 되죠.

오픈아이디 Provider 가 툴바등을 이용해서 로그인을 지원하게 되면, 이용자는 오픈아이디 Provider 의 로그인 페이지 이동 없이 지금 방문한 사이트에 로그인을 할 수 있습니다. 이것은 피싱 위험을 방지하기 위한 방안이기도 합니다. 물론, 이건 화면이 안보이는 것 뿐이고 오픈아이디 Provider 로의 redirection 및 오픈아이디 로그인 사이트로의 재 redirection 이 일어납니다. 또한, 오픈 아이디 Provider 의 승인 페이지는 보이게 됩니다. "항상 승인" 등을 해 놓으면 한 번 방문한 사이트에 재 방문 할 때에는 툴바에서 로그인 한 상태에서 오픈아이디 입력 만으로 로그인이 가능해 집니다. ^^

최근에 업그레이드된 Daum 툴바 3.5 는 사이트 "바로가기" 기능 과 Daum 로그인 기능이 있습니다. 아래 그림은 이 기능을 이용해서 제가 Daum 툴바를 구성한 것 입니다. 툴바는 http://toolbar.daum.net 에서 다운받을 수 있습니다.

바로가기 기능은 툴바의 오른쪽 + 버튼을 이용하면 됩니다. 바로가기 설정할 때 한가지 흠이 있다면, HTML 의 Title 을 반드시 수정해 주시라는 것 입니다. 등록하고 나면, 수정을 못하게 되어 있습니다. 삭제하고 다시 등록해야 합니다. 툴바 버전이 업그레이드 되면 이 기능은 수정해 주겠죠? ^^

아래 그림은 이렇게 오픈아이디 지원 사이트들을 바로가기로 등록해 놓고, Daum 툴바에서 로그인하고 나서 각 사이트에서 오픈아이디로 로그인 한 화면들 입니다. 새로 방문해 보니 재미있는 사이트들이 꽤 있더군요. 다음에 좀더 살펴보려고 합니다.

Daum 툴바가 오픈아이디 로그인을 좀더 편하게 할 수 있도록 지원하려면, 오픈아이디 로그인 박스를 인식해서 이곳에 오픈아이디를 자동으로 삽입하고 로그인 시켜주는 기능이 필요합니다. Verisign 의 오픈아이디 보안 툴바 등에서 지원하는 기능입니다. 기술적으로는 전혀 어려운 내용이 아닌 것으로 알고 있습니다. Daum 툴바가 이 기능을 지원할 수 있도록 내부적으로 힘써봐야 겠습니다. ^^

승현님 글 중에서 "OpenID의 암호가 노출되면 모든 사이트가 노출되는것 아닌가?" 라는 일반 이용자들이 느끼는 단점은 당연한 우려입니다. 해결책은 하나의 오픈아이디 만을 사용하지 않도록 하는 거 겠죠. ^^ 또 다른 방법은 오픈아이디 Provider 가 강력한 로그인 방법을 제공하는 것 입니다. 11월 초에는 Daum 툴바를 이용해서 OTP 로그인을 할 수 있습니다. 아직은 내부 테스트 단계 이지만, 툴바의 OTP 로그인 기능을 이용해서 안전하게 Daum 로그인을 하고 또 오픈아이디 사이트들도 안전하게 로그인 할 수 있습니다.

기대해 주세요 !!

tag : 오픈아이디, 바로가기, OpenID, 다음 툴바, Daum툴바

Daum 툴바로 편리하게 로그인 서비스 이용하기

2008-10-17T21:06:23Z

최근 Daum 툴바가 3.5 버전으로 업그레이드 되었습니다. 새로운 기능들이 많이 들어갔는데요. 한메일 이나 카페 등 로그인이 필요로 하는 서비스를 많이 쓰시는 분들에게는 무척 편리한 "로그인" 기능이 추가되었습니다.

툴바 3.5 는 http://toolbar.daum.net 에서 다운 로드 받아서 설치할 수 있습니다.

다운로드 링크 http://download.toolbar.daum.net/application/DaumToolbar/DaumToolbar.exe

로그인 기능을 살펴볼까요?

툴바 3.5의 오른쪽 끝을 보면, 하얀 "로그인" 버튼이 보입니다. 로그인을 누르면, 웹브라우저의 한가운데에 로그인 창이 뜹니다.

아이디 저장 기능과 함께 비밀번호 저장 기능이 있는 걸 볼 수 있습니다.

본인만 사용하는 PC 또는 노트북이라면, 비밀번호 저장 기능을 사용하는 것을 강추드립니다. 물론, PC 와 노트북에는 스크린 세이버등을 통해서 암호를 꼭 걸어 놓으세요. 비밀번호 저장 기능을 통해서, 언제든지 로그인할때 로그인 창에서 로그인 버튼만 누르면 됩니다. 편리합니다. 물론, 아이디 저장만도 할 수 있습니다. 메신저 들의 아이디 / 비밀번호 저장 기능하고 거의 같습니다.

저장했던 비밀번호를 지우려면?

아이디 저장 선택만 누르면, 아이디 와 비밀번호를 바로 지워 줍니다. 괜찮네요. 이제 아이디/비밀번호를 입력하고 저장 옵션을 모두 선택하고 로그인을 했습니다.

새로운 메일이 왔네요. 툴바의 메일 버튼에 N 표시가 된 걸 확인할 수 있습니다.

툴바의 버튼을 통해서 메일, 카페, 블로그, 캘린더 등의 로그인 기반 서비스에 대한 간단한 정보를 확인할 수 있습니다. 블로그는 다음블로그의 알리미로 등록해 놓은 RSS 글들이 나옵니다. 편리하게 사용하실 분들도 있을 거 같습니다.

랭킹 서비스도 현재 방문한 사이트의 Daum 디렉토리 서비스에서 제공한 랭킹 정보를 볼 수 있습니다. Daum 블로그는 전체 15위 라고 나오네요.

바로가기 버튼을 보세요. + 표시가 있는 버튼입니다.

여기에서는 현재 페이지의 바로가기를 툴바 버튼 영역에 추가해 줍니다. IE 7 인 경우에는 많이 사용할 만 합니다. 버튼 영역이 넓으니까요. 한가지 아쉬운건 "이름" 을 꼭 에디팅 해 주어야 한다는 거죠. 그렇지 않으면, 긴 타이틀을 가지고 있는 페이지의 경우에 버튼 영역을 다 채울 수 있습니다. 그리고, 바로가기 버튼 아래에 "새로운 기능 버튼" 들입니다. 툴바에서 제공하는 Add-On 기능이라고 보시면 됩니다. 현재는 많이 있진 않지만, 툴바 버튼 위젯처럼 쉽게 연동 가능한 모델입니다. 앞으로 더 추가될 예정입니다. 툴바 업데이트 없이 ^^

바로가기 버튼 옆에는 즐겨찾기 버튼이 있습니다. 별표 모양입니다.

즐겨찾기는 Daum 블로그에 저장된 즐겨찾기 정보를 보여줍니다. IE 의 즐겨찾기 정보를 import 할 수 도 있습니다. 이것으로 좋은점은? Daum 툴바만 깔려 있으면, 어디에서든 나의 즐겨찾기 정보를 툴바에서 로그인 한후 확인할 수 있다는 겁니다. ^^

툴바에서 로그인 하면 정말 좋은점 하나 더 !!!

툴바에서의 로그인 얘기는 정작 많이 안했네요. Daum 에 로그인하고 나서 불편한 점이 있었다면 로그인 시간 제한 이었습니다. 한참 글을 쓰고 게시하려고 했는데, 로그인 하라고 하면서 글이 날라갔던 적 있으신가요? 한메일 로그인해서 잘 사용하다가 잠시 회의 다녀와서 메일 확인하려고 하는데 다시 로그인하려고 해서 짜증 났던 적 있으시죠?

툴바 3.5에서는 이런 불편함을 덜어줍니다. 환경설정의 디폴트 옵션으로 설정되어 있는 "툴바에서 Daum 로그인 상태 유지" 기능으로 툴바가 로그인 상태를 계속 유지 시켜 줍니다. 한메일 과 다음 서비스를 많이 사용하는 저로서는 상당히 편리하더군요. 물론, 이 기능은 다른 사람이 내가 없을때 내 PC 를 볼 수 있다면 내 메일이 다른 사람에게 보여질 수 있습니다. 여러 사람들이 공용으로 사용하는 PC 에서는 이 기능을 꼭 OFF 로 하고 사용하세요.

이렇게 툴바 3.5 를 이용하면, 로그인 기반의 Daum 서비스를 편리하게 사용할 수 있습니다. 툴바를 이용한 "아이디/비밀번호 저장" 기능 과 "로그인 시간 연장" 기능으로 편리한 Daum 한메일 과 카페 이용하세요. 여기에 내가 자주가는 사이트 주소를 툴바 버튼으로 등록해서 나만의 툴바 영역을 구성할 수 있습니다. 업무 상 자주 사용하는 링크가 있다면 넣어보세요. 특히 IE 7 의 경우, 강력히 추천합니다.

tag : 한메일, 다음 툴바, Daum 툴바, 다음 로그인, 비밀번호 저장, 로그인 시간 연장

Daum 로그인 기록 서비스 소개

2008-06-29T17:23:56Z

지난 6월 초 부터 Daum 로그인 기록 서비스를 제공하고 있습니다. 처음엔 일부 회원 대상으로만 서비스를 시작하다가 6월 18일 모든 사용자 대상으로 확대했습니다. 이 내용은 6월 18일 Daum 공지사항을 통해서 서비스 공지되었습니다. 공지사항에 올라가긴 했으나, 많은 분들은 아직 모르시는 것 같아서 소개드립니다. ^^

Daum 공지사항 : http://gnos.daum.net/gnos/bbs_read/daum_notice/?fldid=00015&rdd=000Lczzzzzzzzzzzzzzzzzzzzzzzzz&sdd=zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz&pi=1&ppi=1

로그인 기록 서비스는 "Daum 회원 정보 수정" 에서 왼편 "로그인 기록" 메뉴를 통해서 볼 수 있습니다. 안전한 이용을 위해 비밀번호 확인 절차가 수행됩니다.

Daum 회원정보 수정 : https://user.daum.net/daumuser/loginUserInfo.daum

여기서 잠깐 다른 얘기하나 하겠습니다. 위 화면은 FireFox 3.0 에서 로그인기록 페이지를 열어본 겁니다. 주소창에 "녹색" 으로 "Daum Communications Corp." 가 표시되는 것을 확인하세요. 작년 부터 Daum 에서는 우리나라에서는 최초로 EV-SSL 보안 인증서를 이용하고 있습니다. FireFox 3.0 에서부터 이 인증서의 녹색 화면 표시를 지원합니다. IE 는 7.0 부터 지원됩니다. 비교하시려면, 네이버의 회원정보 사이트와 비교해 보세요. ^^ 개인정보를 다루는 웹 페이지에서는 암호 (SSL) 이 적용되고 있습니다. EV 인증서는 해당 사이트가 안전한 사이트라는 것을 녹색 으로 쉽게 표시하고 있습니다.

로그인 기록을 확인하는 시점 부터 한 달 전 까지의 기록을 확인할 수 있습니다. 다만, 처음 기록은 5월30일 부터 입니다. 오늘이 6월 29일 이니 앞으로는 항상 한 달간의 기록을 볼 수 있다라고 할 수 있겠네요. 제공되는 정보는 "로그인 시간, 로그인 위치 (서비스), 로그인/로그아웃/비밀번호 확인, 로그인 결과, IP 주소" 입니다.

서비스 : 아이디/비밀번호가 어떤 서비스 에서 전달되었는가 입니다. Daum 첫화면에서 로그인한 경우 "Daum 첫화면" 으로 나옵니다. 팟플레이어, 메신저 등도 구분합니다. 카페/아고라 에서 직접 로그인을 하는 경우 각각 카페/아고라라고 표시됩니다.

결과 : 성공/실패/일시차단/차단 이 있습니다. 일시차단 이란 비밀번호가 연속해서 일정 회수 이상 틀린 경우 로그인을 일정시간 동안 하지 못하도록 일시적으로 차단되는 것을 의미합니다. 차단 이란 아이디의 로그인 자체가 관리자에 의해서 차단된 경우입니다. 대표적으로 서비스 약관을 어기는 행위에 의해서 차단되는 경우가 있습니다.

나머지 항목에 대한 설명은 생략하겠습니다. 그리 어려운 내용이 아니니까요. 서비스 도움말을 참고하셔도 됩니다.

로그인 기록을 제공하는 이유는 "내 아이디/비밀번호 가 다른 사람에 의해서 도용되었는지 여부를 회원 스스로 판단할 수 있도록 하기 위함" 입니다. 로그인은 대부분 특정 위치에서 많이 하게 됩니다. 집, 사무실, 학교등 에서요. IP 주소만을 보고 여기가 집, 사무실, 학교인지 바로 확인할 수 는 없지만 대략 최근 며칠간의 기억에 의존해서 로그인 시간 등과 매칭한다면 어느 정도 확인 가능합니다.

본인은 전혀 로그인한 기억이 없는데, 로그인 했다라는 기록이 있다면?

1. 가장 먼저 "비밀번호 변경" 을 해 보세요. 그리고, 로그인 기록 내역을 적어도 일주일에 한 번 만이라도 확인해 보세요. 그런데, 또 다시 의심되는 로그인 기록이 있다구요?

2. 그렇다면, 로그인을 했던 PC 에서 악성코드/스파이웨어에 의해 비밀번호가 노출되었을 가능성도 염두에 두어야 합니다. 이런경우엔, 안철수 연구소의 빛자루 특별판이나 이스트소프트의 알약 등을 이용해서 악성코드/스파이웨어 검사/치료를 하세요.

로그인 기록 서비스는 사후 조치로서 나의 정보를 보호하기 위한 것 입니다. 사전 조치는 로그인 시점에서의 "보안 접속" 과 "PC 악성코드/스파이웨어" 로 부터의 보호 조치 ( 빛자루, 알약 등으로 ) 가 있습니다.

현재 Daum 에서 제공하고 있는 로그인 기록 관련 서비스는 "최근 한 달 간의 로그인 기록" 뿐 입니다. 로그인을 상당히 많이 하는 경우에는 이러한 기록 서비스 보다는 통계 서비스 ( 언제, 어느 IP 대역에서 몇회 로그인 했다 등의 ) 가 더 필요할 것 같습니다. 또한, 필터링 기능 ( 특정 아이피에서의 로그인 기록은 제외 한다거나.. ) 과 IP 주소 등록 기능 ( 특정 IP 대역은 집, 어떤 IP 대역은 사무실.. 이렇게 위치 정보를 입력할 수 있도록 .. ) , 그리고 도용 위험 알림 기능 ( 등록되지 않은 곳에서의 로그인 내역 등을 따로 보여주거나 알려주는 기능 ) 등이 있다면 더욱 더 도움이 될 것 같습니다.

좀 더 기다리면, 이런 기능들이 추가 되지 않을까요? ^^

tag : Daum, 로그인 기록, EV 인증서, 비밀번호 도용

아이핀 (i-PIN) 활성화를 위한 현실적인 타협안

2008-06-28T16:57:26Z

아이핀 서비스는 인터넷에서 신분확인을 하기 위한 용도로 '주민등록번호' 를 대체하기 위해서 만들어졌다.

일반적으로 아이핀 서비스를 설명할때에는 "아이핀 서비스" 온라인 서비스 제공자 사이트에서 주민번호를 대체할 새로운 번호 ( 아이핀 ) 를 발급받아서 인터넷 서비스 가입을 할때 신원확인 수단으로 주민번호 대신 입력하면 된다고 한다. 그렇다면, 실제로는 어떻게 연동이 되어 있을까? Daum 과 Naver 의 사례를 살펴 보자.

1. Daum

회원가입 사이트에서 회원인증을 수행하는 화면이다. 실명인증, 휴대폰인증,전화번호인증,i-PIN 인증 이상 네가지 방법을 제공한다. 실명인증은 "실명, 주민번호, 명의자 휴대폰 번호" 를 입력해야 한다.

그럼, i-PIN 인증을 살펴보자. "i-PIN 발급받기" 버튼만 있다. 이 버튼을 누르면, i-PIN 발급기관인 한국신용정보의 i-PIN 서비스 로그인 팝업이 뜬다.

이 팝업창에서 나이스 아이핀 아이디/비밀번호를 입력하면, 아이핀을 받을 수 있다. 회원으로 가입이 안되어 있다면, 당연히 가입 절차가 필요하다.

2. Naver

회원가입 사이트에서 회원인증을 수행하는 화면이다. 실명인증, i-PIN 인증 이상 두가지 방법을 제공한다. Daum 과 다르게 실명인증이 된 경우에만 회원가입을 받아준다. 실명인증은 "실명, 주민번호" 만을 입력한다. i-PIN 인증은 Daum 과 다르지 않다.

아이핀을 선택하면 나오는 화면이다.

역시, Daum 의 경우와 같이 아이핀 서비스 제공자의 팝업이 뜬다. 이곳의 아이디/비밀번호를 입력하면 아이핀을 받을 수 있다. 물론, 회원가입 필수 !!

그럼, 아이핀으로 가입하는 사람들은 얼마나 될까?

http://www.etnews.co.kr/troop/detail_sa.html?id=25 에 따르면, 네이버와 다음에서 아이핀 이용률은 각각 0.2% 에 불과 하다고 한다.무엇이 문제일까? 위 기사의 얘기대로 홍보의 문제일까?

http://www.dt.co.kr/contents.html?article_no=2008010102011760713002 에 따르면, 아이핀 발급 및 관리등 사용자들의 서비스이용편리성이 제고되어야 한다는 의견이 34.4 % 로 가장 많았다. 실제로, 위의 Daum 과 Naver 의 사례에서 살펴보면, 실명인증을 받는 "실명/주민번호" 입력하는 것 대비해서 아이핀을 발급받기 위해서 아이핀 서비스 사이트에서 회원가입을 하고 아이디 비밀번호를 기억해야 한다는 것은 매우 불편하다는 것을 알 수 있다. 이 문제를 해결하지 않고, 단지 아이핀 의무화만을 하는 것은 아무런 의미가 없다. 이것은 오히려 인터넷 사업자와 사용자들에게 인터넷 서비스을 사용하지 못하게 하는 모습으로 될 것이다.

따라서, 당연히 아이핀 활성화를 위해서는 어떻게 하면 이용자들이 편리하게 아이핀을 사용할 수 있을까에 초점을 맞추어야 한다. 기존 실명인증 받는 만큼 편리하게 아이핀을 사용할 수 있다면 아이핀 이용률도 올라갈 것이며 궁극에는 인터넷 사이트에서의 주민번호 수집 금지를 법으로 완전히 제한 한다고 하더라도 큰 혼란은 없을 것이다.

KISA 에서 아이핀 확산 방안을 찾고자 한다고 한다. "주민번호 대체수단 실태조사 사업자" 를 내달 선정한다고 하는 기사가 최근 디지털타임즈에 올라왔다. http://www.dt.co.kr/contents.html?article_no=2008062702010251713002 아이핀을 편리하게 이용할 수 있도록 하는 방안을 중심으로 사업이 진행되길 기대한다.

이 글에서는 아이핀을 편리하게 사용할 수 있는 방안을 제안해 보고자 한다.

1) 인터넷 사이트 회원가입 페이지

--> 2) 실명인증 버튼 클릭

--> 3) 아이핀 팝업 페이지 ( 실명,주민번호 입력 FORM )

--> 4) 실명,주민번호 입력. 추가 인증 절차 수행 ( 핸드폰, 공인인증 )

--> 5) 회원가입 사이트로 아이핀 및 기타 정보 제공

현재의 아이핀 서비스와 다른점이 있다면, 아이핀 서비스의 회원 개념을 없앴다는 것이다. 현재는 이용자가 아이핀 발급 이라는 개념도 이해를 해야 하고, 아이핀 아이디/비밀번호도 기억해야 한다. 더구나, 회원가입 할 때만 아이핀을 이용한다면, 비밀번호 잊어버릴 확률은 거의 90% 이상이다. Daum 이나 Naver 처럼 자주 로그인하는 곳의 비밀번호도 일주일 정도 이용하지 않으면 잊어버리는 경우가 허다한데, 회원가입을 적어도 일주일에 한번씩 하지 않는다면 당연히 아이핀 아이디/비밀번호도 잊게 된다.

* 아이핀 아이디/비밀번호 방식의 회원 개념을 제거 하라.
* 아이핀 사이트 이용시, 실명/주민번호/추가인증(핸드폰명의인증,공인인증서,신용카드등) 만으로 아이핀이 제공될 수 있도록 하라.

위와 같이 하면, 아이핀에 관여된 여러 곳의 이익이 있다.

인터넷 서비스 제공자 : 주민등록번호 관리 필요성 없어진다. 정통망법에서 주민등록번호를 암호화 해야 한다고 한다. 없으면, 암호화 대상이 없어진다. 따라서, DB 암호화 솔루션 등을 구매할 필요가 없다. 또한, 아이핀 이용으로 인한 가입장벽이 사라지게 되므로, 자체 실명인증/회원인증 절차를 수행할 필요가 없다.

아이핀 서비스 제공자 : 아이핀 이용률 급 상승 ㅎㅎ. 아이핀 이용자는 당연히 많아진다. 인터넷 서비스 제공자들에 의해서 유일한 실명인증 수단이 되어 버릴 테니.. 그러나, 아이핀 제공시 마다 추가 인증 비용 부담이 발생한다. 이것은 인터넷 서비스 제공자들과 합리적으로 분담할 수 있을 것 이다. 한편, 이용자의 정보가 집중화 되므로, 보안 대책을 신중하게 세워야 한다.

인터넷 이용자 : 현재처럼 쉽게 아이핀으로 실명인증 받는다. 주민등록번호는 아이핀 제공자에게만 전달된다. 즉, 널리 이용되지 않으므로 안전함을 느낄수 있다. 노출 된다 하더라도, 그 아이핀을 도용해서 사이트 가입을 다른 사람이 할 가능성은 거의 없다. 또한, 일부 아이핀 사업자의 아이핀은 특정 인터넷 서비스 제공자 에게만 유효하다. 즉, 한 곳에서 유효한 아이핀은 다른 곳에서 유효하지 않다.

아이핀 자체의 기술적인 문제도 해결해 나가야 한다. 아이핀 사업자 간에 서로 호환되지 않는 기술을 이용하고 있다. 그러므로, 당연히 아이핀 프로토콜의 공개도 안하고 있다. 이것은 분명히 언제인가 큰 문제를 야기할 것이다. 암호/보안 프로토콜의 안정성을 확보하는 방법은 이미 우리 모두 알고있다. SSL 보안 기술이 그렇고, SEED 암호알고리즘, RSA 암호알고리즘이 이렇게 안정성을 확보해 왔다. 기술 스펙을 공개하라. 분석가 들은 프로토콜의 안정성을 검증하라. !!

마지막, 인터넷 실명제 자체에 대한 나의 의견

여기에서 아이핀 활성화에 대한 의견을 피력했지만, 이것이 내가 인터넷 실명제를 바란다거나 옹호하는 것은 절대 아니다. 현실적으로 실명인증이 많이 이용되고 있고 그로 인한 폐혜가 많이 있는 상황에서, 아이핀이 그 폐혜를 극복하는데 현실적인 방안중의 하나이기 때문이다. 물론, 5개 ~ 6개의 아이핀 서비스 제공자들에게 인터넷 이용자들의 회원 가입 내역을 보유하게 되는 문제는 결코 가벼이 간과되어서는 안된다. 이에 대한 감시 활동은 지속되어야 할 것 이다.

나는 실명인증/제한적 본인확인 없이 자유롭게 회원가입하고 상품구매하고 게시판/카페/블로그에 글을 쓰고 읽을 수 있는 자유로운 세상을 꿈꾼다. 온라인에서의 이중 인격 / 다중 인격은 온라인을 더욱더 풍요롭고 창조적으로 만들 것으로 나는 믿는다.

tag : 인터넷 실명제, 아이핀, 회원가입, i-PIN

옥션 천만 회원정보 노출 공개 - 2차 피해와 대처 방안

2008-04-17T16:37:32Z

옥션 피해 상황이 정말 심각하군요.

옥션 관계자는 "경찰 조사 결과 확인된 1천81만명 중 90% 이상은 이름과 아이디, 주민등록번호 등 일반 개인정보만 유출된 경우"라고 밝혔다.
- 출처 : 연합뉴스 2008/04/17

옥션 가입자의 이름과 아이디 주민등록번호 등 개인정보가 유출되었다고 합니다. 설마 했는데, 천만명이 넘는 정보가 유출이 되었네요. 큰 일 입니다. 아직 보고된 2차 피해는 없다고 합니다. 하지만, 없을 수 가 없죠. 이로 인한 2차 피해에 대해서 잠시 생각해 봤습니다.

1. 아이디 유출

실명인증된 아이디 유츨입니다. 당장에 스팸메일 전송에 이용될 수 있습니다. 물론, 이미 왠만한 아이디 리스트는 다 노출되어 있다고 볼 수 있습니다. 영문자, 숫자 등의 조합으로 노출되어 있죠. 그렇게 노출되어 있으니 우리 대부분이 스팸메일을 받게 됩니다.

그러나, 공격자들은 노출된 사용자 대상으로 다른 공격들을 할 수 있습니다. 대표적으로, 요즘 유행하는 피싱 공격 대상이 될 수 있습니다. 아래와 같은 메일을 받았다고 생각해 보죠.

"옥션에서 보내드립니다. 고객님의 정보가 노출되었습니다. http://xxx.xxauction.ac.kr 링크로 들어와서 정보 노출 여부를 확인해 보세요."

여기 링크를 누르면, 지금의 옥션 개인정보 유출 확인 사이트 ( https://memberssl.auction.co.kr/Authenticate/Popup/Popup1.aspx ) 처럼 보여질 수 있습니다. 메일을 받은 이용자들은 당연히 옥션 아이디/비밀번호 입력합니다. 그렇다면? 공격자는 바로 이 사람의 옥션 아이디/비밀번호 를 알 수 있습니다. 이 아이디와 비밀번호는 인터넷 많은 곳에서 같이 사용됩니다. 피싱 공격의 무서움이죠.

옥션의 "개인정보 유출여부 확인하기 팝업창" 은 그래서 너무도 위험합니다. 피싱 공격을 방지하기 위해서 별도의 채널 또는 방법을 제시해야 합니다. 또한 메일을 통해서도 이 페이지에 대한 링크를 제공해서는 안됩니다. 마지막으로 "옥션에서는 메일을 통해 개인정보 유출여브 확인하기 링크를 제공하지 않습니다. 피싱에 주의하세요" 라는 공지사항도 꼭 필요합니다.

물론, 여러 기관들에서 피싱 사이트에 대한 모니터링도 강화해야 할 겁니다.

2. 이름/주민등록번호 유출

당장, 2007/07/27 시행된 정통망법 제한적 본인확인제 실효성 논란이 일어납니다. 이름/주민등록번호가 일천만명 이상 노출되었고, 이 정보를 누군가 가지고 있다면, 어느 순간 나도 모르게 경찰서에서 악플, 선거법 위반등으로 소환당할지 모릅니다. 물론, 얘기할 수 있겠네요. 이거 내가 한거 아니다라고. 경찰 분들 힘들어 지시겠어요. 그 친구가 언제 어디서 이렇게 악플을 달았는지 까지 확인해야 하니까요.

전국민의 1/5 정보가 유출 되었으니, 지금 많은 사이트들이 운영하고 있는 실명인증의 벽이 허물어 져 버린 셈입니다.

아이디 찾기, 비밀번호 찾기 등의 회원정보 관련 프로세스들도 전반적인 검토와 재 정비가 필요합니다. 많은 사이트들이 아이디 찾기에 이름/주민번호를 통한 아이디 제공을 하고 있습니다. 공격자는 이를 통해서 해당 서비스의 아이디를 얻고 주민번호등을 이용해서 쉽게 로그인 할 수 있을 겁니다. 많은 사람들이 비밀번호를 주민번호등을 이용해서 만들고 있습니다.

이에 대처 하는 방법

소송 카페 회원수가 급증하고 있답니다. http://cafe.daum.net/auctionlawsuit 피해를 입으신 분들은 여기에서 소송에 참여하시면 보상을 받으실 수 있겠죠.

그러나, 보상 보다 더 중요한 것 !! "나의 개인정보 보호" 입니다. 비밀번호 노출에 대한 얘기는 없습니다. 다행입니다. 물론, 아니라면 더 큰일이죠. 옥션 피해 공개 이후 Daum 과 네이버를 포함해서 많은 사이트들이 비밀번호 변경 캠페인을 진행했습니다.

주요한 사이트의 비밀번호를 모두 변경하세요. !!

비밀번호 변경을 하라고 했을때 귀찮아서 하지 않으셨다면 지금이라도 해 주세요.
그리고, 꼭 비밀번호는

    8자 이상 문자 와 숫자 또는 특수문자를 섞어서 사용하세요.
    주민번호, 이름 등의 개인정보는 포함하면 안됩니다.
    연속된 문자, 숫자 도 사용하지 마세요.

Daum 의 경우에는 비밀번호 입력시 강도 체크를 해 줍니다. 또한, 개인정보가 들어가게 되면 경고를 하고 있습니다. 이 규칙을 지켜서 비밀번호를 사용하시면 나의 개인정보 보호 레벨이 크게 올라 갑니다.

메일을 통한 피싱 위협에 절대 빠지지 마세요

옥션에서는 피해자 개인들에게 메일을 보낼거라고 합니다. 이를 가장한 피싱 메일은 절대로 열어 보거나 열더라도 안에 있는 링크를 통해서 사이트로 이동하지 마세요. 그리고, 어디든 신고하세요. 메일을 포털 사이트에서 사용하신다면, 해당 사이트에 신고하세요. Daum, 네이버 모두 잘 대응해 드릴 겁니다. 또는 www.kisa.or.kr 이나 사이버수사대에 신고하시면 됩니다.

꼭 피해여부를 확인하고 싶으면 옥션 사이트로 직접 가서 확인하세요. 중요합니다. !!

www.kisa.or.kr

tag : 옥션, 해킹, 피싱, 주민등록번호

윤종수 판사님의 "네트워크시대의 다중인격" 공감

2008-04-11T09:49:08Z

오늘 오전 zdnet 을 살펴 보다가, "윤종수 판사" 님 께서 기고하신 "네트워크 시대의 다중인격" 을 읽게 되었다.

Digital Identity 2.0 서비스에 대한 고민을 하던 지난날 "인터넷에서의 다중인격" 이 활성화 될 수 있는 인프라를 지원해야 한다고 생각했던 적이 있다. 그랬으니, 이 제목을 보고 너무 끌릴 수 밖에 없었다. ^^

http://www.zdnet.co.kr/itbiz/column/anchor/iwillbe/0,39033556,39167490,00.htm

아래는 이 글의 일부를 발췌한 부분이다.
----------------------------------
인터넷과 디지털 시대의 가상현실과 사이버 공간은 인격의 원래 모습인 분열적 본성이 자연스럽게 발현되도록 기여하고 이에 따라 다중인격의 멀티태스킹이 본격화되었다고 한다.
...
네트워크 시대의 진정한 주인공들은 네트워크 안에서 다양한 집단과 관련을 맺지만 결코 어느 한 집단에 종속되지 않고 끊임없이 변신하며 자신의 가능성을 찾아가는 다중인격적인 개인이다. 그들의 다중인격성은 경악과 공포의 대상이 아니라 무한한 가능성과 에너지의 원천이며 네트워크가 가져다 준 기회의 상징이다. 하지만 변신과 다양성에 대한 우리들의 너그러움과 장려가 없이는 그토록 무한한 가능성과 에너지도 한낱 음침한 병리적인 현상에 그칠 수 있음을 기억해야 한다.
----------------------------------

내가 2년전 블로깅을 시작한지 얼마 안됐을 때 작성했던 글에서 윤종수 판사님처럼 논리적이고 깔끔한 글은 아니지만 비슷한 내용이 들어가 있는 글을 올렸었다.

"익명성과 신뢰, 그리고 익명의 가치~~~" http://blog.daum.net/jsbaek/8094748

----------------------------------
온라인에서의 익명성은 활동의 자유도를 높여준다. 온라인에서는 오프라인과 전혀 다른 새로운 Identity 를 창조할 수 있다. 오프라인에서의 자신의 Identity 정체성 때문에 활동의 제한을 받게 되는 곳에서 탈출이다. 새 생명의 탄생이다 !!
...
익명성을 통해 창조되는 새로운 Identity 들이 많아지도록 하여 사람들이 가지고 있는 가치를 극대화 시키고 새로운 컨텐츠를 만들수 있는 온라인 환경을 만들어야 하는 것...
----------------------------------

현재의 Digital Identity 관리 기술은 "네트워크의 다중인격" 을 활성화 할 수 있는 근간을 마련해 주는 방향으로 발전해 나가고 있다. Identity 1.0 이라고 말할 수 있는 기존의 "Real Identity" 와 "Digital Identity" 의 1대1 연결 방식에 고집하지 말자. "실명인증" 기반 과 "제한적 본인확인제" 라는 그 틀에서 벗어날 수 있는 환경을 만들어가자.

윤판사님이 말씀하신대로 "변신과 다양성에 대한 우리들의 너그러움과 장려" 를 제공할 수 있는 인터넷 Identity 플랫폼을 만들어가는 것이 우리가 해야 할 일이다.

윤종수 판사님의 글은 너무도 공감이 가고, 나에게 큰 힘이 된다. 감사합니다. ^^

tag : 익명성, 다중인격, 윤종수, Identity

OpenID 제한적 본인확인 확장에 대한 의견

2008-04-09T16:13:20Z

최근 myID.net 에서 OpenID 기반에서 제한적 본인확인을 할 수 있는 기능을 개발했고, 같은 회사 (오픈마루)의 서비스인 레몬펜 - 중앙일보 총선 사이트 에 적용했습니다.   http://openid.or.kr/73

이전부터 많은 서비스 제공자 ( RP ) 들이 OpenID 제공자 ( IDP / OP ) 에 요청해온 사항입니다. myID.net 에서 제안한 방법을 이용해서 RP 들은 비용 및 관리 부담 감소와 사용자들은 각 사이트에서 실명인증을 할 필요없다라는 장점을 가지게 됩니다.

더 할 나위 없이 좋습니다. 저도 대 찬성입니다. !!

하지만, 몇가지 현실적인 제약이 따르는 것 같습니다. 이 글에서는 이러한 문제들에 대해서 제기하고자 합니다. 해결 방안을 같이 고민해 봤으면 합니다.

1. myID 제한적 본인확인 프로토콜 기술 이슈

myID 에서 제안한 제한적 본인확인 프로토콜 스펙 ( http://blog.myid.net/58 ) 에서 자세히 언급되지 않은 부분이 있어서 확인이 필요합니다.

openid simple registration extension ( http://openid.net/specs/openid-simple-registration-extension-1_0.html ) 에는 다음과 같은 부분이 있습니다.

----------------------------------------------------------------------------
3. Request format

The request parameters detailed here SHOULD be sent with OpenID Authentication checkid_immediate or checkid_setup requests.

4. Response format

The fields below SHOULD be included in the Identity Providers's response when "openid.mode" is "id_res".

The response's "openid.signed" field list MUST include the returned registration field names, prefixed without the openid. prefix (e.g., sreg.nickname). The "openid.sig" field MUST provide a signature for the sreg. fields in addition to the OpenID data according to the OpenID Authentication specification.
----------------------------------------------------------------------------

본인확인 프로토콜도 마찬가지로 openid.kren.request 가 OpenID Authentication checkid_immediate 또는 checkid_setup requests 에 포함되어 전달되어야 한다는 것과 openid.kren.verified 가 openid.mode 가 id_res 인 Identity Providers 의 response 에 포함되어야 한다는 점을 명확히 해 주셔야 할 것 같습니다. 현재 구현도 그렇게 되어 있는 것으로 보입니다만, 제가 미처 확인하지 못했습니다. 중앙일보 총선사이트에 적용된 레몬펜에서 확인이 안되더군요. ^^;

하나 더, 서비스제공자(RP) 에 의해서 이 정보가 요청되고, OpenID 제공자 ( IDP/OP )가 이 정보를 제공함에 있어서, 해당 사용자에게 실명확인 여부 정보가 제공된다는 노티가 꼭 필요하다는 사실도 빠져서는 안됩니다. 물론, 기술 스펙에 이러한 내용까지 넣을 필요는 없지만, 구축 가이드등에는 꼭 들어가야 합니다. 현재의 sreg ( 기본 개인정보 ) 를 제공할때 이용하는 확인창에 같이 들어가면 됩니다.
단지, 오픈아이디와 retrieve request를 OpenID 제공자에게 요청하면 사용자 확인없이 T/F 를 제공해서는 안됩니다.

2. OpenID 의 유일성 문제

이 프로토콜에 따르면 본인확인 정보는 서비스 제공자 (RP) 가 보유하게 됩니다. 여기에는 openid : 본인확인여부(y/n) 의 형태가 될 것입니다. 문제는 OpenID 는 하나의 아이디로 여러 사이트에서 이용된다는 것입니다. 그렇다면, 이 정보가 떠돌아 다닌다면, "본인확인된 OpenID 리스트를 판매합니다." 라는 식의 행위가 나올 수 있습니다. 이 리스트를 사는 사람들은 해당 OpenID 들이 더 가치있는 것으로 판단하고 이러한 OpenID들에 대해서 특정 공격등을 할 수 있습니다. 물론, 주민번호/실명이 돌아다니는 것에 비해서 훨씬 안전하지만 이 마저도 문제가 될 수 있습니다.

SAML 2.0 의 pseudonym ID 는 아이디 연결과정에서 IDP 와 RP 둘 사이에서만 알 수 있는 값으로 지정됩니다. 즉, IDP 와 RP A, RP B 에서 P 라는 사람은 IDP 와 RP A 에서는 1111 로 연결되고, IDP 와 RP B 에서는 2222 로 연결될 수 있습니다. 그리하여 RP A 가 해킹을 당한다 하더라도 RP B 의 이용자와 연결시킬 수 없습니다. OpenID는 하나의 아이디로 여러 사이트를 이용합니다. RP A 가 본인확인 여부 정보를 가지고 있다면, RP B 에게 사용자의 확인 과정 없이 본인확인 여부가 바로 노출될 수 있습니다. "나는 RP B 에게 본인확인 정보를 제공한 적이 없는데 내가 실명확인된 사람이다라는 정보를 어떻게 알았지?" 라는 문제입니다. 이것으로 발생할 수 있는 문제점에 대해서 OpenID 커뮤니티에서 많은 고민을 해 봐야 할 것 같습니다.

3. 중복가입 방지 방안

주민번호를 이용하는 대표적인 이유입니다. OpenID를 사용하고자 하지만 주민번호당 하나의 아이디 또는 아이디 수 제한을 두고자 하는 서비스가 있다면, 이슈를 제기할 만 합니다. 현재의 프로토콜로는 방법이 없습니다. 프로토콜을 확장해서 하나의 OpenID 제공자에서 주민번호로 OpenID 개수를 제한하고 이에 대한 정보를 제공하는 것이 하나의 방법이 될 수 있습니다. 그러나, OpenID 제공자가 여러개 있기 때문에 OpenID 제공자 수 만큼은 만들 수 있습니다. 이 문제를 해결하려면, 주민번호 대체수단에서 제공하는 "중복확인가입정보" 와 유사한 기능을 제공해야 합니다.

하지만, 아이디 수 제한을 두는 것 자체가 넌센스 라고 생각합니다. 본인확인 가능하다면, 굳이 아이디 수 제한 둘 필요 없을 거 같습니다. 물론, 서비스 내부에서 도배질을 한다든지, 다른 아이디로 여론을 조작한다든지 얼마든지 할 수 있겠죠. 역기능은 분명이 존재할 겁니다. 이건 서비스 제공자가 다른 방법으로 해결해 나가야 하지 않을까요?

4. 서비스 사이트의 ID 찾기 및 cs 대응 방안

보통 주민번호를 통해서 ID 찾기등을 제공합니다. OpenID 를 이용해서 내가 사용할 아이디가 3-4개로 한정되므로 특별히 이러한 내용을 제공할 필요는 없겠죠. 문제는 오픈아이디와 자체 계정을 둘다 지원하는 경우인데요. 최근 미투데이도 그렇고, 사용자들의 오픈아이디 이용 혼란으로 인해 오픈아이디를 지원하면서도 자체 회원 계정을 구축하는 경우가 늘어나고 있습니다. 이러한 경우, id 및 비밀번호 찾기 cs 를 지원하기 위해서 주민번호등을 이용하고자 하는 유혹에 쉽게 빠질 수 있습니다. OpenID 본인확인 프로토콜이 무용지물이 될 수 있죠. 흑흑..

5. 사후 본인확인 정보 제공 프로세스. 공공기관의 협조 요청

수사기관의 이용자 확인을 위한 주민번호 및 서비스 이용기록 확인 요청이 들어오는 경우에 해당합니다. 수사기관은 RP 에 주민번호를 주면서 이 사용자의 활동 기록을 달라고 요청할 겁니다. 그러면, RP 는 주민번호를 IDP 에 전달해서 오픈아이디를 얻어야 합니다. 그런데, RP 는 이 주민번호가 어떤 IDP 에서 이용되는지 모릅니다. 헉, 그렇다면 모든 IDP 에 주민번호를 주면서 해당 주민번호에 대한 오픈아이디를 달라고 요청해야 한다는 겁니다. 이런, 당연히 불가능 합니다.

그럼, RP 는 수사기관에 우리는 이 주민번호에 해당하는 이용자를 확인할 수 없습니다 라고 얘기할 수 있을까요? 그럼, 제한적본인확인제에 어긋납니다. 큰일이네요. 몇몇 큰 IDP 에만 요청할 수 도 있겠죠. 그럼, 해당 IDP 에서 주민번호를 받고 오픈아이디를 제공할 수 있을까요? RP 의 요청만으로는 제공하지 못합니다. 이용자의 특별한 동의도 없었고, 사전에 이와 관련된 약관도 없기 때문입니다. 결국 수사기관이 여러 IDP 에 주민번호를 제공해서 해당 오픈아이디를 얻어야 하고, 수사기관은 RP 에 오픈아이디를 제공하고 활동 내역을 받아야 합니다. 수사기관들 많이 싫어 하겠는데요.

6. 법률 이슈

기본적으로는 제한적 본인확인 책임을 "서비스 제공자 (RP)" 가 가집니다. 즉, 정보통신망법(2007/7/27)에 의해서 일정 수준 이상의 방문자가 있는 게시판 류의 서비스는 제한적본인확인이 반드시 필요합니다. 제한적본인확인을 충분히 이행하지 못했거나 문제가 발생하는 경우에는 해당 서비스 제공자가 책임을 지도록 되어 있습니다.

그렇다면, myID 나 Daum OpenID 가 제한적본인확인 여부를 OpenID 프로토콜을 통해서 제공한다고 했을때, myID 와 Daum OpenID는 잘못된 정보를 주더라도 별다른 책임을 추궁당하지 않을 수 있겠죠? 신뢰의 문제지만, 그런 사고가 날 개연성은 충분합니다. 그리고, OpenID Provider 는 누구나 될 수 있으므로, 결국 서비스 제공자는 신뢰하는 몇몇 OpenID 제공자만을 허용할 수 밖에 없을 것 입니다.

이러하기 때문에, 현재의 실명인증/본인확인 서비스 비지니스 모델은 서비스제공자가 본인확인제공자와 계약을 맺게 됩니다. 이 계약은 서비스제공자는 본인확인제공자에게 비용을 지불하며 본인확인제공자는 본인확인 제공 사실에 대한 책임을 집니다. 즉, 혹시 서비스 제공자가 잘못된 정보를 통해서 제한적본인확인을 충분히 이행하지 못했을 때, 그에 대한 책임을 지으면서도 이에 대한 금전적인 보상들을 본인확인서비스 제공자로 부터 받을 수 있다는 겁니다.

또한, 본인확인기관들은 일정수준의 보안 시스템을 구성하고 있습니다. 전자적 침해 행위와 물리적 출입통제 와 장애 및 재해에 대한 조치 및 비상계획들을 구비하고 있습니다. 여기에 대해서 정기적으로 KISA 와 같은 특정 기관들로 부터 감사도 받습니다. 그럼, OpenID 제공자도 이런 수준으로 보안 시스템을 구축해야 하고 감사도 받아야 할 까요? 보안 시스템 구축은 필요하지만, 감사까지 받는다면 OpenID 제공자의 부담은 몇배가 됩니다. 흑흑..

7. 비지니스 모델

큰 문제가 될 수 있겠네요. 현재 4-5 개의 신용기관에서 실명인증 및 본인확인 서비스를 제공합니다. 많은 사이트들이 이들 기관에서 돈을 내고 서비스를 받고 있습니다. 심지어는 공공기관 까지도. 그런데, 이들 기관에서 서비스를 제공받는 Daum 이나 myID ( 오픈마루 ) 가 다른 곳에 대해서 실명확인 서비스를 제공한다고 하면, 이들의 밥그릇을 뺏는 결과를 가져옵니다. 물론, Daum 과 실명확인 서비스 업체와의 계약서에는 다음과 같이 명시되어 있겠죠.

"Daum 이 운영하는 서비스에서 필요한 실명인증용도로 사용한다"

myID 는 이 문제를 어떻게 풀으셨나요? 자사 서비스인 레몬펜에 들어가는 것 이기 때문에 아직 문제가 안될 수 있습니다. 하지만, Daum 이 동일하게 제공한다면, 또는 다른 RP 들이 본인확인 서비스를 이용한다면 바로 신용기관에서 태클 들어올 수 있습니다.

설령, 문제가 안된다고 합시다. 그렇다면, 실명확인 서비스 업체와 Daum 은 별도의 계약을 하는 수 밖에 없습니다. Daum 의 비용이 추가되겠죠. 그렇지만, 실명확인서비스 업체 입장에서는 손해보는 장사가 될 겁니다. 아무래도 Daum 이 훨씬 더 힘이 세고, 실명확인 업체는 여러곳이 있으니 경쟁 관계에서 큰 돈을 벌기 쉽지 않으니까요. 지금까지는 대형 업체들과의 구축 reference 를 이용해서 자사 서비스를 홍보하고 작은 사이트들에서 돈을 버는 구조였는데, 그게 깨지는 거죠. 그럼, 종국에 실명확인 서비스 업체들은 Daum 에 서비스 제공 하지 않겠다 라고 할 거 같습니다. 또는 이런 서비스를 제공하지 않겠다라고 할 지도 모릅니다. "돈" 이 안되니. 그럼, 본인확인 물 건너 가네요.

더 좋은 세상이 찾아오게 되는 걸까요? ㅎㅎ

정리

대략 몇 가지 이슈를 제기해 봤습니다. 그러나, 이러한 문제들은 해결하라고 있는 거죠. 이러한 문제들 때문에 시작부터 포기하는 것은 바람직 하지 않습니다. 그런 면에서 myID 의 본인확인 기능 제공을 환영합니다. Daum OpenID 가 동일하게 지원할 수 있을지는 아직 말씀드리기 어렵습니다. 내부에서도 이에 대한 검토를 해 보려면 좀 골치가 아플거 같습니다.

인터넷 ID 의 근간으로서 OpenID 가 성숙해 진다면, OpenID 제공자는 이러한 문제들에 대해서 성실한 책임을 가져야 합니다. 법률적인 문제나 수사기관 협조의 문제는 프로세스를 조금 정비하면 쉽게 해결 될 겁니다. 문제는 비지니스 모델 과 비용입니다. OpenID 를 제공함으로서 충분한 이익을 여러곳에서 얻을 수 있을테니, 이 정도는 해 줘야 하는 것이 당연하지 않겠느냐 라고 말할 수 있습니다. Daum 과 Naver 는 그렇게 말 할 수 도 있을 겁니다. 그러나, 작은 OpenID 제공자는 쉽지 않을 겁니다. 또한, 실명인증 기관들이 같이 공존할 수 있는 기회도 마련이 되어야 합니다. 실명인증 기관이 망해버리면, 모두 꽝이 되죠.

마지막으로, 제가 여러곳에서 OpenID의 장점을 얘기하면서, OpenID 제공자와 서비스 제공자(RP) 사이에 계약서 가 필요없다라는 얘기를 많이 하고 다녔습니다. 그런데, 이것이 '본인확인' 으로 가게 되면 애�은 서비스 제공자만 당할 수 도 있습니다. 그래서, 계약서를 만들게 됩니다. 그럼? OpenID 장점이 사라집니다. 아이고 ~~~

tag : 실명확인, OpenID, 본인확인, myID

조선일보 사이트에 멀웨어가 있다는 구글 검색 결과

2008-03-31T11:06:13Z

2008년 3월31일 오전 현재, 조선일보 사이트가 구글 ( www.google.co.kr ) 에서 "이 사이트는 컴퓨터에 문제를 야기할 수 있습니다." 라고 뜨고 있습니다.

저는 FireFox 의 주소창에서 "조선일보" 나 "한겨레" 를 직접 치고 들어가는 편 입니다. 그러면, 사이트를 찾아보다가 해당 사이트가 없으면 구글 검색으로 가서 해당 사이트로 바로 이동 되더군요. 그런데, 오늘 아침 "조선일보" 를 넣으니 아래 처럼 나옵니다.

조선일보 링크를 누르면, 아래 화면이 나오고, 더욱더 강력한 경고 메시지를 보여줍니다.

StopBadware.org 에 들어가서 chosun.com 에 대한 내용을 봤는데, 이상한 건 3월30일 현재 이 사이트에 보고된 BadWare 는 없다라고 합니다.

"No StopBadware partners are reporting badware behavior on this site as of 3/30/2008"

그런데, 왜 구글 검색 결과에서 조선일보 링크가 "멀웨어 경고" 를 받고 있을까요? 구글 검색이 이상한 한 건 가요? 혹시 구글 코리아만의 일인가 해서 www.google.com 에서 확인해 봤는데, 동일한 결과가 나옵니다. 영어로만 바뀌어서..

혹시라도 www.chosun.com 이 최근 해킹을 당했는데 이게 구글에 감지된 걸 까요 ? 아니면, 구글 측의 단순한 실수 일까요?

검색에서의 "웹사이트 보안 기능" 을 체험하게 되네요. 그렇지만, 보안은 "신뢰"가 매우 중요합니다. 혹시 구글의 실수 라면 또 반복된다면 누가 구글의 검색 결과에서 맬웨어 경고를 믿을 까요.

조선일보, 구글 모두 빨리 확인해 보셔야 할 거 같습니다.

tag : 조선일보, 보안, 구글 검색, 멀웨어

MS 의 U-Prove 기술 확보

2008-03-11T11:41:49Z

Microsoft 의 Kim Cameron 블로그에서는 연일 Credentica 사의 U-Prove 기술 및 관련 특허 확보에 대한 글이 포스팅 되고 있습니다.

MS는 2008년 3월 6일 U-Prove Technology 를 인수했습니다. 이 기술은 "다중 도메인에서의 Identity 및 Access 관리" 요구사항 충돌을 잘 조화시는 방법을 제시한다고 합니다.

현재 이용되고 있는 개인정보 제공 기술은 PKI Attribute 인증서, 그리고 SAML 기반의 Attribute Assertion 이 대표적입니다. 여기에 OpenID Attribute Exchange 기술도 나오고 있습니다. 이용자의 개인정보를 전달할 때, 인증서 또는 Assertion 을 발행해 주는 기관(Issuer)은 이 정보들을 받고자 하는 검증자(Verifier)를 확인하고, 검증자 만이 정보를 얻을 수 있도록 정보들을 암호화 하여 전송하게 됩니다. 개인정보 제공자는 이용자의 모든 개인정보를 알고 있게 됩니다. 또한, 개인정보를 제공함에 있어서 개인정보의 소유자(이용자)가 제공여부를 컨트롤 할 수 없게 됩니다.

소유자 -> 개인정보 제공자 -> 개인정보 검증자

그러나, U-Prove 기술을 이용하게 되면, PKI 인증서와 같이 이용자 PC 에 저장된 개인키 정보를 알지 못하면, 개인정보 검증자에게 전달할 데이터를 만들 수 없게 됩니다. 즉, 개인정보 제공자 ( 또는, ID Token 발급자 )는 개인정보를 개인정보 검증자에게 직접 전달할 이유가 전혀 없게 되며, 이용자의 컨트롤(전자서명)이 있어야만 개인정보가 전달되게 됩니다. 개인정보를 전달할때, 개인정보 제공자가 온라인으로 붙어있어야할 이유도 없게 됩니다.

ID 토큰 발급자 -> 이용자 -> 개인정보 검증자

여기에 더해서, 이용자는 ID 토큰에 저장되는 개인정보에 대하여 특정한 속성들을 선택하여 꼭 필요한 정보만을 개인정보 검증자에게 보낼 수 있습니다. 나의 이름 만을 보낼 수 도 있고, 나의 소속 기관 정보만을 보낼 수 도 있습니다. 온라인 신뢰 개인정보 제공자 없이, 개인정보를 소유자가 직접 컨트롤 할 수 있도록 암호 기술을 이용하여 구현한 것으로 이해 될 수 있습니다.

이 기술은 CardSpace 플랫폼에 연동 될 것으로 보입니다. Kim Cameron은 매우 좋아하고 있는거 같네요. CardSpace 플랫폼에서 상상하던 개인정보의 이용자 컨트롤을 "암호학" 적으로 해결하게 됩니다. 우리의 일상 생활의 모습과 점점 더 닯아 간다고 볼 수 있습니다.

"운전면허 라이센스를 정부로 부터 받아서 내가 소유하고, 면허증을 내가 직접 필요할 때 제공함으로서 나를 증명할 수 있다"

하지만, 현재의 모습은 ( SAML 등을 이용하는 경우... )

"운전면허 라이센스가 있습니다. 이것은 운전면허 당국에서 확인해 줄 수 있습니다. 당국으로 전화해서 확인해 보세요"

입니다. 그 차이점, 아시겠죠?

좀더 자세한 특징은 아래 Credentica 사이트 에서 확인하세요.

http://www.credentica.com/unique_features.html

tag : MS, Privacy, U-Prove, CardSpace

회의록 작성하기 - 위키 협업, 네이밍 룰, 그리고 Regular Expression

2008-03-04T09:40:59Z

위키를 이용하여 팀 업무와 프로젝트를 관리하기 시작한지 한달이 조금 넘었습니다. 지난 한달 동안의 위키 이용에 대한 평가를 해 보면, 팀 업무와 진행되는 프로젝트를 개괄적으로 (overview) 볼 수 있다는 점에서 상당히 편해 졌다라고 생각합니다. 일부 파트는 나름대로 그룹 업무 페이지를 잘 구성해 주고 있지만, 일부 파트는 그렇지 못한점이 아쉽습니다.

나름, 한 두가지 기능을 팀 위키에 추가했습니다. "회의록" 이 바로 그것입니다.

팀내 그룹, 다른 팀, 다른 회사와의 협업이 증가하면서 회의는 점점 많아 지더군요. 상당한 귀찮니스트인 저는 회의록 이라고 하는 문서의 작성을 거의 안하는 편 이었습니다. 회의 후에 따로 그 회의에서 나왔던 얘기들을 정리하는 시간을 가지는 것을 상당히 싫어하는 편이거든요. 당연 문제가 발생하죠. 예를들어, 프로젝트 개발 회의를 할때, 회의에서 나온 추가 개발 요구사항을 결정하게 되면 저는 담당 PL에게 요구사항을 정리하고 구현에 필요한 사항들도 더 정리하라고 요구합니다. 얼마후, 제가 요구한 문서가 도착합니다. 하루 정도 이내에 도착하면, 업무는 잘 진행됩니다. 그러나, 이틀, 일주일 지나서 도착하면 제가 무슨 말을 했는지 잊어버리게 되고 회의 시간에 논의한 내용이 모두 포함이 되었는지 판단하는 것은 거의 불가능 해 집니다. 하나라도 뭐가 빠졌다면, 또 회의해야 하고 또 구현 고민해야하는 반복을 해야 합니다. 이런, 저의 기억력을 너무 과신 한 탓이죠.

그러다, 텍스트 문서를 이용해서 회의시간에 조금씩 정리하는 버릇을 기르게 되었습니다. 회의후 정리까지 바라지는 않았지만, 회의 시간에 문서로 정리하기 시작하니 회의라고 하는 것이 생산적이 된다라는 기분이 들게 되더군요. 정리하면서 회의하고, 회의 끝에는 다시 한번 회의 내용 확인하고, 결론도 만들어 보게 되었습니다. 항상 회의는 이렇게 해야 한다라는 얘기는 많이 들었지만, 왜 그래야 하는지 잘 모르던 제가 비로소 그 필요성을 몸소 체험하게 되었습니다. ^^

이렇게 되니, PL이 정리한 기술 문서를 보면서 회의시간에 얘기한 내용중에서 뭐가 부족한지 판단하기 좀더 쉬워졌습니다. "인증 방법에 대한 OOOOO 사항이 빠졌어요." 라고 지적하게 되죠. 그런 얘기 없었다고 반항 (ㅎㅎ) 하면, 제가 작성했던 회의록 보여줍니다. ㅎㅎ 저의 WIN 이죠. 그러자, PL 분이 정리한 회의록을 메일로 보내달라고 합니다. 저만을 위한 회의록을 작성했기에 회의후 잘 공유하지 않았었는데, 미리 공유하면 더 도움이 될 거 같다는 필요성이 확 듭니다.

자, 이제 이 회의록을 팀 위키에 올리려고 작정합니다.

먼저, 하던 대로 노트패드에서 회의록을 쓰고 회의후에 의식적으로 위키 페이지를 만들어서 올렸습니다. 흠, 귀찮은걸. 회의 끝나고 정리하는 걸 하기 싫어하는 저로서는 이것도 너무 귀찮네요. 그래서, 아예 노트패드를 버렸습니다. 위키에서 직접 작성하기 시작했습니다. 그렇게 하니, 저에게 놀라운 변화가 생기는 군요. "흠, 다들 이 회의록을 볼테니 그래도 회의록에 필수로 들어가야 할 건 들어가야 겠지. 아무렇게나 내가 알수 있는 대로만 쓰면 창피하잖아.." 라는 생각이 저절로 드네요. 그래서, 자연스럽게 회의 일시, 참석자, 그리고 회의 제목과 내용들로 먼저 항목들을 구분하고 채워 나가더군요. 그런데, 문제가 생겼습니다. 제 노트북의 OS는 VISTA 입니다. CPU 사양은 좋지 않은데, 테스트 겸 꾹 참으면서 사용하고 있었습니다. 하지만, IE 에서 위키 텍스트 에디터의 속도가 정말 극적으로 느립니다. 한 글자 타이핑하고 2초는 있어야 다른 글을 타이핑 할 수 있습니다. ㅜㅜ 노트패드는 제가 입력하는 속도에 맞게 잘 작성해 주는데, IE 의 form 에서는 절대 안되네요. 흑, 이런 장애물이 발생할 줄 이야. 그러다, 혹시? 하는 마음에 파이어폭스를 이용해 봤습니다. 호, 제가 타이핑하는 속도를 따라오네요. 적어도 제가 입려한 키를 잊어버리지 않습니다. 그후, 저는 파폭을 저의 메인으로 사용하게 됐답니다. ^^

이제, 회의록을 작성하고 회의록 주소를 같이 회의했던 분들에게 메신저로 공유합니다. 흐믓하죠. 즐거운 마음으로 팀 위키 홈페이지에 다시 가 보았습니다. 여기에 회의록 링크가 올라오면 공유하기 더 편하겠구나, 회의후에 언제든지 팀 위키 홈페이지에 오면 자동으로 올라오니 메신저로 공유할 필요도 없고 라는 생각이 듭니다. 팀 위키 첫페이지 변경하고 회의록 링크를 넣으려고 했습니다. 링크만 추가할까 하다가, 이것도 자동으로 할 수 있을 거야 라는 생각까지 드네요. 더욱더 흐믓해 집니다.

회의록 페이지 명을 일정한 규칙으로 만들면, 회의록을 작성하기만 하면 바로 리스트에 뜨게 됩니다. 귀찮게 회의 하나 하나 할 ? 마다 회의록 리스트 페이지에서 그 링크를 넣을 필요가 없습니다. 저는 회의록 페이지 이름을 이렇게 만들어 봤습니다.

[팀 그룹명]/meeting/[날짜]-[업무명]

예) Identity/meeting/2008-02-10-Refactoring

이렇게하고, 회의록 리스트 페이지 (Meeting) 는 이렇게 구성합니다.

== 업무 회의 ==
[[PageList(regex:^.*/meeting/2008-02-..-*)]]
----
=== 전체 회의 리스트 ===
[[PageList(regex:^.*/meeting/2008-..-..-*)]]

그리고, 팀 위키 첫페이지에 회의록 리스트 페이지를 다음과 같이 include 합니다. 그러면, 팀 위치 첫페이지에는 2월달의 회의록 리스트가 모두 나타나게 됩니다. 3월이 되면 어떡하냐구요? Meeting 페이지에서 살짝 02 를 03으로 바꿔줍니다. ^^ 하지만, Meeting 페이지를 직접 보게 되면 전체 회의 리스트는 다 보이게 됩니다. ( 2008년 이요.. ^^ )

[[Include(Meeting,,,from="^== 업무 회의 ==$",to="^----$",editlink)]]

이제, 팀내의 모든 그룹에서 회의한 내용을 위의 네이밍 룰에 따라 회의록을 작성하기만 하면, 회의록 리스트에 바로 나오게 됩니다. 신나서 회의할때 회의록을 꼭 작성해 봅니다. 그리고, 얘기하죠, 꼭 팀 위키에서 확인해라. 메신저로 링크 줄 필요도 없고, 제가 위키에 링크를추가로 달 필요도 없습니다. ^^

기존 그룹웨어 하고 다른 점은 뭘까요? 기존 그룹웨어들은 팀별, 그룹별 게시판들을 이용합니다. 그룹별 회의록은 그룹 게시판에 올릴 거고, 팀 회의록은 팀 게시판에 올리겠죠. 팀 게시판에서도 그룹회의 내용을 보고 싶은데, 힘든 구조 입니다. 그러나, 위키는 다릅니다. 위에서의 회의록 리스트 페이지만 조금 수정해서 그룹별 위키 페이지에서 include 하면 해당 회의록은 전혀 수정하지 않고 그 위키페이지에서 보여져야 하는 회의록 리스트만 볼 수 있습니다. 아래처럼 하면, Identity 그룹의 회의록만 볼 수 있게 됩니다.

최근 한달 회의 목록
[[PageList(regex:^Identity/meeting/2008-02-..-*)]]
----
전체 회의 목록
[[PageList(regex:^Identity/meeting/2008-..-..-*)]]

프로젝트에 관련된 회의록 리스트만 볼때도 마찬가지 입니다. 저는 이렇게 해 보았습니다. 회의록 작성시에 업무명에 공통으로 들어갈 프로젝트 명을 쓰는 거죠.

예) Identity/meeting/2008-02-10-Login-Refactoring
예) Identity/meeting/2008-02-10-Login-StressTest

그리고, Login 이라는 프로젝트 페이지에서는 아래 부분을 추가합니다.

관련 회의 목록
[[PageList(regex:^Identity/meeting/.*Login-*]]

이렇게 되면, Login 관련 프로젝트의 회의록을 작성하기만 하면, 팀 위키 페이지, Identity 그룹 위키 페이지, 그리고 Login 프로젝트 위키 페이지에서 모두 자동으로 링크가 연결된 것을 볼 수 있습니다. 웹페이지에서 링크의 중요성도 다시 한번 깨닫게 되죠. 업무의 효율성도 높아집니다. 이젠 뭘 하죠? 팀원들에게 전파 합니다.

"앞으로 회의 하시면, 회의록을 꼭 이렇게 작성해서 위키에 올리세요. 이와 같은 규칙으로 페이지 명을 정해서 올리기만 하면, 자동으로 링크가 나오게 되고 손 쉽게 다른 사람들과 업무 내용을 공유할 수 있습니다."

전파는 한 번으로 끝내면 안되죠. 제가 회의록 작성하고, 글이 자동으로 올라가는거 계속 자랑합니다. 지금까지 우리팀의 회의록은 지난 보름 사이에 총 10개가 올라왔네요. 이중 9개를 제가 작성했다는 안습 ㅜㅜ. 하지만, 주욱 푸쉬 할 겁니다. 지겨워 할 때 까지. ^^ 그리고, 이렇게 한 분이 있으면 많이 칭찬해 드릴 겁니다. ^^

이런식으로 구성하는데 있어서, 가장 어려운 부분은 Regular Expression 입니다. 창피한 얘기지만, 저는 Regular Expression 을 사용하는데 익숙하지 않습니다. 그럴 기회가 별로 없었다는 것으로 핑계를 삼죠. 하지만, 팀 위키 협업을 고민하면서 부터 틈틈히 사용하게 되네요. 그러면, 곧 잊지 않고 또 찾아보지 않고도 훌륭하게 Regular Expression으로 원하는 바를 이룰 수 있을 거 같습니다.

개발자 아니신 분들 위키를 사용하는데 어려움이 많다고들 합니다. 특히, 운영함에 있어서 Regular Expression 은 큰 장벽이 될 수 도 있습니다. 그러나, Regular Expression 을 사용해 보세요. 처음엔 저 처럼 쉬운 기능으로 이용하시고, 그러면서 하나 씩 하나씩 필요에 따라 공부하시면 될 겁니다. 검색해 보니, 다음 신지식에 초보자용 Regular Expression 설명이 나와 있더군요. 저도 이거 보고 배웠습니다. ^^ 위의 Regular Expression 에 대해서 자세히 이해 하려면, 아래 링크를 참고하세요.

다음 신지식 : http://k.daum.net/qna/openknowledge/view.html?boardid=-&qid=0sm3A&q=regular+expression&srchid=NKS0sm3A

위키와 Regular Expression 의 위력은 항상 저를 감동 시킵니다. ^^

참고로, 제가 사용한 위키는 MoinMoin 입니다. 다른 위키를 사용하신다면, 위의 Include 나 title 입력 방식이 다를 수 있습니다.

tag : 회의록, 프로젝트 관리, 위키 협업, Regular Expression

안랩 빛자루 3.0 - 완전 무료 백신 - 출시. 알약/PC그린 기능 비교

2008-01-31T12:27:44Z

안철수 연구소에서 1월 31일 빛자루 특별판 데스크톱 3.0 을 배포하기 시작했습니다. 실시간 감시 기능과 자동 업데이트 기능도 모두 무료입니다. 빛자루 2.0 설치할때 불편했던, 회원 가입도 이제 필요없습니다. 실명인증 받을 필요도 비밀번호 설정할 필요도 없습니다. 너무 좋습니다. ^^ 설치하고 나니 아래 처럼 바로 실행 화면이 뜨는 군요.

다운로드 사이트 : http://www.vitzaru.com

알약이 개인용 백신 시장에서 돌풍을 일으키고 있는 가운데, 조금 늦은 감은 있지만 PC 그린 과 함께 새로운 경쟁 구도를 구성하게 됐습니다. 간단하게 각 제품별 주요 기능들을 비교해 봤습니다. 이 기능표는 빛자루, 알약, PC 그린 사이트에서 제공하고 있는 자료를 바탕으로 작성한 것 입니다.

무료 백신 종류	실시간 감시	바이러스,악성코드 검사 치료	엔진 자동 업데이트	네트워크 방화벽	보안 패치	PC 튜닝	그레이웨어 검색/차단	IE 다운로드 파일 검사	유해 사이트 (악성코드, 피싱) 알림 및 차단
빛자루	O	O	O	O	X	O	O	O	O
알약	O	O	O	X	X	O	X	X	X
PC 그린	O	O	O	X	O	O	X	X	X

빛자루의 IE 다운로드 파일 검사 와 유해사이트 알림 차단 기능은 빛자루 설치시에 같이 설치되는 다음-빛자루 툴바를 통해서 서비스 됩니다. 빛자루 데스크탑 자체 기능만으로 비교한다면 두 기능은 빼야 겠죠. 하지만, 보안 기능을 탑재하고 있고 빛자루 설치시 기본 옵션으로 설치되도록 되어 있으니 포함했습니다.

네트워크 방화벽 과 그레이웨어 검색/차단 기능은 빛자루만 제공하고 있습니다. 방화벽은 대부분의 백신 소프트웨어가 제공하고 있던 기능이지만, Windows XP 서비스팩 2 와 Vista 운영체제가 나오면서 부터는 OS 가 기본 제공하고 있어서 그 필요성이 약간 반감되긴 했습니다. 하지만, 방화벽 및 네트워크 보안 정책 설정과 보호 서비스는 Windows 기본 방화벽 보다 신속하고 더 전문적으로 제공됩니다. 설치해 볼만 하다는 거죠. 그레이웨어 검색/차단 기능은 꽤 유용한 기능입니다. Windows 의 제어판 - 프로그램 제거 기능을 대신할 수 도 있습니다. PC 에 설치된 프로그램들을 정리할때 유용하게 사용할 수 있습니다. 다만, 컴퓨터를 잘 다루지 못하는 분들은 그다지 많이 사용하지 않을 거 같습니다. 이 분들은 프로그램 제거 자체를 잘 안하시는 경향이 있잖아요.

보안 패치 기능은 PC 그린에서만 제공하고 있습니다. 보안 패치의 중요성은 더 말할 나위가 없습니다. 하지만, 이 기능 역시 Windows XP 서비스팩 2 와 Vista 에서 부터는 보안 패치가 나오는 경우 거의 강제적으로 설치를 하고 시스템을 부팅 시키고 있습니다. 알림 기능은 괜찮아 보이지만, 이것은 사실상 OS 영역으로 이동 된 것 같습니다.

빛자루를 설치할때 같이 설치되는 사이트보안 (다음-빛자루 툴바) 은 다른 제품들에는 없는 안전한 웹서핑 기능을 제공합니다. 파일 다운로드시 바이러스/악성코드 검사를 하고 유해사이트에 낚시 당해서 갔을때 임의의 ActvieX 가 설치되거나 피싱 사이트로 이동했을때 사이트 이용 전에 경고를 합니다. 파일 다운로드시 바이러스 검사는 실시간 검사 기능으로 약간 그 빛이 바랬지만, 성능적으로 실시간 감시 기능을 보완하는 측면이 있다고 생각합니다. 다운로드시 바이러스 검사를 자동으로 함으로서 실시간 감시 모듈에 추가적인 부하를 주지 않는다면, 실시간 감시의 시스템 점유율도 낮아질 것으로 기대합니다.

바이러스 엔진에 대해서도 잠깐 알아보면, 빛자루는 자사의 파워 V3 엔진을 사용합니다. PC 그린은 4월경에 V3 엔진이 탑재 된다고 하죠. 지금은 카스퍼스키 엔진을 사용하고 있구요. 아 물론, PC 그린은 멀티 엔진 탑재가 가능합니다. 근데, 멀팅 엔진 탑재라는건 PC 그린이 플랫폼 역할을 하겠다는 건데, 너무 오버하는거 아닌가 싶습니다. 소비자에게는 그다지 필요없다고 생각하는데요. 작년 네이버와 안철수 연구소의 논쟁에서 이기기 위한 논리의 산물이 아닌가 싶습니다. 알약은 비트디펜더(안티바이러스) 와 PC지기엔진(안티스파이웨어)을 사용한답니다.

최근 계속된 논쟁이지만, 제 개인적으로는 안철수 연구소의 V3 엔진을 신뢰한답니다. 현재로서는 엔진 사이의 차이점을 백신 전문가가 아니면 거의 분간할 수 없습니다. 이후 유지보수와 신속한 서비스등이 가장 중요하다고 생각합니다. 국내 제품이기 때문에는 아닙니다. 지금까지 보여준 신뢰성이라고 생각합니다. 물론, 외산 솔루션과의 끝없는 경쟁은 계속됩니다. 이 경쟁이 더욱 더 안철수 연구소를 압박하고 있는 형국입니다. 경쟁 속에서 더 좋은 제품과 서비스가 만들어 질 것으로 확신합니다. 물론, 알약과 PC 그린도요. ^^

tag : 바이러스, PC그린, 알약, 무료 백신, 빛자루

위키 (wiki) 를 이용한 프로젝트 매니지먼트

2008-01-23T21:05:28Z

2008년 새해 되어, 팀원이 두배 가까이 늘었습니다. 팀원만 늘은게 아닙니다. 업무도 기존에 하던 업무에 새로운 업무들이 많이 추가되었습니다. ^^; 정리를 별로 좋아하지 않다보니 (천성이 좀 게을러서 ^^) 팀 내부의 업무 관리를 주로 메일과 머리속의 기억에 의존해 왔습니다. 그러나, 더 이상 안되겠더군요. 나이 들어가면서, 개인적으로 또는 회의때 공유/결정 했던 내용들을 잊어버리곤, 다른 소리를 하기 시작하는 모습을 보게 되었습니다.

팀원 :"지난 번에 팀장님이 이렇게 하라고 하셨잖아요 !!!"
팀장 :"무슨 소리야, 내가 언제 그랬어? 난 그런 기억이 없어!!! 내가 그런 결정을 내렸을 리 없어. 지금 생각해 봐도, 당신이 얘기한건 틀렸어, 그건 아니야..."
팀원 :"에잇, 다음 부터는 팀장님 얘기 녹음해 놓을 거예요 !!!"

그래서, 업무 관리에 좀 신경을 써야 겠다라는 생각이 저절로 들더군요. 위 얘기는 몇 년전 팀원이 (지금은 아이 엄마가 됐어요 ^^) 저에게 했던 얘기입니다. 이제서야 제가 뭔가 하려 하다니, 저도 참 게으른 사람이죠. ^^

요즘에는 일주일에 한 번 전체 팀원이 모여서 같이 한 주간 했던 업무 얘기를 합니다. 다들 이렇게들 많이 하죠. 주간 업무 회의를 하기 위해서, 팀원들에게 이번 주 한 일과 다음 주 할 일을 보고서로 작성해서 제출하라고 합니다. 목요일 오후쯤에 회의를 하니까, 회의 한시간 전 쯤에 모든 팀원에게 메시지를 보냅니다.

"주간 보고서 작성해 주세요. 오늘 회의시간에는 누가누가 ID 보안에 대해서 세미나 할 겁니다.^^"

그나마, 팀 내에서 위키를 사용하고 있어서, 모든 팀원들은 bjstar/2008-01-18 처럼 날짜 페이지를 만들어서, 이 페이지에 주간 보고서를 작성합니다. 보고서 형식보다는 내용이 중요하다는 생각을 가지고 있는 저는 형식을 통일 시키라고 하지 않았습니다. 그러다 보니, 같은 프로젝트를 수행하는 데도, 다른 프로젝트 명을 사용하는 경우도 있습니다. 읽어보면, 같은 프로젝트인줄 알지만.. ^^

"회원정보 관리 시스템 개편"
"IDMS Refactoring"
"회원정보 시스템 리팩토링"

이렇게 말이죠. 사실 하나의 프로젝트 인데요. "내용이 중요하고, 다들 무슨 프로젝트인줄 아니까, 뭐 괜찮지.." 라고 생각합니다. 그런데, 내가 제 상관에게 팀 업무를 보고할 때 "회원 관리 시스템 개선" 이라고 프로젝트 명을 씁니다. 헉, 이럴 수가.. ^^;; 이건 아니다 라고, 다시 한번 반성하면서, 팀 매니지먼트를 효율적으로 할 수 있는 방법을 생각해 봤습니다.

우리 팀은 여러 개의 워킹 그룹으로 구성되어 있습니다. 워킹 그룹은 서로 다른 업무 영역이어서 팀원이 동시에 다른 워킹 그룹에 소속되서 업무를 진행하는 경우는 드뭅니다. 간혹, 다른 워킹그룹의 프로젝트에 속하기도 하지만, 보통은 그렇지 않습니다. 워킹 그룹은 동시에 여러 프로젝트를 진행합니다. 한 워킹 그룹에 3~4명이 있으니까, 동시에 세 개 이상의 프로젝트를 진행하기는 사실 좀 어렵습니다. 또, 워킹 그룹은 시스템 개발 뿐만이 아니라 시스템 운영 업무도 같이 맡고 있습니다. 여기에 그룹 스터디나 개인별 스터디등을 합니다. 워킹 그룹 별로 업무 진행사항을 모니터링 하기 위해서는 크게 세 가지 VIEW가 필요합니다.

수행중인 프로젝트 리스트 VIEW : 현재 수행중인 프로젝트 리스트를 보고, 최근 2주 이내의 진행상황을 한 눈에 볼 수 있어야 함.
프로젝트 상세 내용 VIEW : 프로젝트에 대한 상세 내용과 진행 상황을 모두 확인할 수 있어야 함.
운영업무 수행 현황 VIEW : 워킹 그룹 멤버들이 수행한 최근 운영 업무 현황

자, 이제 팀원들에 대해서 얘기해 볼까요. 팀원이 수행하는 업무는 업무 성격으로 보면 크게 세 가지로 구분됩니다. 대략 다음과 같이 나름 정의했습니다.

프로젝트 : 최소 2주 이상 지속 되어야 하는 개발/운영 업무
운영업무 : 일상적인 시스템 운영 및 장애 처리 와 프로젝트로 승격되지 못한 업무
기타 (자아실현^^) : 개인 또는 그룹 스터디, 출장, 휴가 등등

팀 관리를 효율적으로 하기 위해서는 팀 관리 자체를 위한 일들을 줄여야 합니다. 주간 업무 보고서를 작성하는데, 입력해야 하는 필드가 많아지면 업무 보고 자체가 일이 되어 버립니다. 업무 진척현황을 팀원이 %로 제시하는 것도 팀원에게 지나친 부담을 주는 것 같습니다. 팀원들은 빠른시간에 쉽게 주간 보고서를 작성할 수 있어야 합니다. 주간 보고서를 워드에서 입력하고, 파일명을 결정하고, PC 에 저장하고, 메일에 첨부해서 인사말과 함께 상사에게 전달하는 것 과 웹 페이지에서 클릭 한 번 하고 보고서 입력하고 저장하는 것으로 끝나는 것은 너무도 큰 차이가 납니다.

팀 업무 관리 시스템을 생각하면서, 가장 중요하게 생각한 것이 팀원들이 효율적으로 이용할 수 있도록 하자 입니다. 일반적인 프로젝트 매니지먼트 툴들은 어떻죠? 제 생각엔 관리자들을 위한 기능에 지나치게 치우쳐 있다고 생각합니다. 뭐, 그런 툴의 구매 결정권자 이니 만큼, 어느 정도는 필요하겠지만요.

프로젝트 관리자도 마찬가지입니다. 프로젝트가 잘 수행될 수 있어야지, 상부에 보고하기 위한 프로젝트 보고서 꾸미기는 그 자체가 필요없는 일 이라고 생각합니다. 진척사항 %는 프로젝트 관리자에게 별로 의미없는 수치입니다. 프로젝트 관리자가 상관에게 보고할때 필요한거죠. 대충 얘기해도 되지 않을까요? 중요한 건 완료 일정과 품질이니까죠.

주간 업무 보고서 : 한 페이지에서 프로젝트, 운영, 기타 업무를 한번에 입력할 수 있어야 한다.

팀원들은 간단하게 자신이 수행한 업무와 수행 예정인 업무를 기술합니다. 프로젝트 관리자는 해당 프로젝트에 대해서 어떤일이 수행되었는지 팀원들이 기입한 내역으로 확인하고, 프로젝트의 진척 사항등을 판단하여 적절하게 기술합니다. 워킹 그룹 관리자는 팀원들이 수행한 운영 업무들 과 기타 사항들 (자기 개발, 연구 등)을 주욱 확인합니다.

이 정도로 프로젝트 매니지먼트, 아니, 팀 업무 관리에 대한 개략적인 그림을 머리에 떠올리고, 실제 구현에 들어가 보기로 결정했습니다.

MS 아웃룩을 써볼까? 아웃룩을 보니, 작업 할당 과 일정 관리등을 메일들을 이용해서 적당히 할 수 있을 것 같습니다. 하지만, 아웃룩 만으로는 부족해 보입니다. MS SharePoint 가 있다는데, 당장 내 손에 없으니 확인을 못하겠습니다. 그리고, 검색을 통해서 몇몇 프로젝트 관리 툴들을 살펴 보았습니다. 이런, 입력해야 할 게 너무 많더군요. 도저히 제가 사용할 엄두가 나지 않았습니다. 프로젝트 관리에만 너무 치우쳐서 팀 업무 관리용으로는 적절하지 못한 것들도 있었습니다. 제가 아직 미천해서 그런지, 프로젝트 관리 툴들은 너무 어렵게만 느껴지더군요.

흠, 기존 툴들은 너무 복잡하고, 툴 사용법 익히는 데도 오래 걸릴 것 같고, 또 비용도 지불해야하고.

이럴 때 하는 게, 직접 만든다. ㅎㅎ 이 정도 요구사항이면 만드는데 그리 오래 걸리지 않을 것 같았습니다. 그런데, 이번주 목요일 팀 회의 부터 이 시스템을 이용해서 팀 업무 관리를 하고 싶다라는 욕심이 나네요. 3일 이내에 이걸 개발할 수 있을까? 근데, 누가 개발하지? 내가? (할 수 는 있을 텐데, 요즘 코딩을 많이 안해봐서, 좀 걸리겠지) 음... 서버는 있나? 음... 나중에 유지보수는 누가? 음... 흑흑 결국 팀 업무 관리를 위한 시스템을 만들고 관리하는데 비용이 만만치 않다는 판단이 섭니다. 아.. 이대로 포기해야 하나...

이때, 문득 지금 팀에서 사용하던 위키가 눈에 들어옵니다. 주간 업무를 팀원들이 작성하면, 팀 전체 업무를 한눈에 볼 수 있도록 하기 위해서 팀원들의 주간업무 페이지들을 팀 주간업무 페이지에서 Include 합니다. 오호, Include 라는 기능이 있구나. 제가 사용한 위키는 MoinMoin 위키 소프트웨어 입니다. Include 라는 좋은 매크로가 있습니다. 그래서, 위키의 Include 매뉴얼을 보게되었습니다. 훌륭합니다. 파라미터로 Regular Expression을 이용하여 Include 할 위키 페이지들을 지정하는 기능과 해당 페이지의 내용 중에서 일부만 포함시킬 수 있는 기능, 위키 페이지 이름으로 소팅 하는 기능, 그리고 Include 할 페이지 갯수와 skip 할 목록 갯수까지 모두 설정 가능합니다. 뭔가 머리를 확 스쳐 가네요.

[[Include(pagename, heading, level, from="regex", to="regex", sort=ascending|descending, items=n, skipitems=n, titlesonly|editlink)]]

팀원들이 주간보고서를 쓸때, 통일된 문서 구조와 프로젝트 명을 동일하게만 사용한다면 제가 원하는 프로젝트 리스트 VIEW 와 프로젝트 진행 현황을 팀원들의 주간보고서 정보만으로 재 구성해서 한 눈에 볼 수 있다는 얘기 입니다. 아, 위에서 얘기했던 "프로젝트 명" 을 통일할 필요성이 생겼습니다. ^^

팀원들의 주간 업무 보고를 아래처럼 작성하고, [id]/2008-01-24 의 형태로 위키 페이지 이름을 만들면,

== project ==
=== 프로젝트 명 ===
프로젝트 수행 내용
----
=== 프로젝트 명 2 ===
프로젝트 수행 내용
----
== operation ==
운영업무
----
== etc ==
기타 업무
----

운영 업무 만을 다른 페이지에서 보고 싶을때,

[[Include(^bjstar/2008-..-..,,,from="^== operation ==$",to="^----$",sort=descending,items=2,editlink)]]

위 코드를 넣습니다. 그러면, bjstar 의 최근 주간 보고 2건이 포함되는 것을 볼 수 있습니다. 와우 훌륭하네요. 그렇다면, 프로젝트 리스트도 위키의 테이블을 이용해서 쉽게 볼 수 있다는 얘기입니다. 이렇게 해서, 제가 원하던 프로젝트 리스트 VIEW, 프로젝트 VIEW, 워킹 그룹 VIEW, 개인 업무 페이지 등을 모두 만들 수 있었습니다. 단지, 오후 4시간 투자해서 말입니다.

위키를 자주 쓰기는 했지만, 그다지 좋아하지 않았었는데, 이번을 계기로 위키가 얼마나 훌륭한 협력 도구인지 깨닫게 되었습니다. Include 매크로 하나로 말 입니다. 물론, 몇가지 좀더 자동화를 했으면 하는 것들이 있습니다. 이건, Python 으로 직접 매크로를 만들어야 합니다. 시간 날때, 또 절실하게 필요하다고 여길때 만들어 볼까 합니다.

이렇게 만들어 놓고 보니, Include 를 상당히 많이 씁니다. 문득, 이게 모두 문자열 검색인데, 한 페이지를 여는데 Include 를 수십번 해야 한다면, 사용자가 많아지면 시스템에 무리가 가지 않을까 우려됩니다만, 20-30명 정도의 소규모 팀 관리에는 걱정없을 거 같습니다. 문제가 되면, 좋은 프로토타입을 만들었다 생각하고, 다시 만들죠 뭐.

주간 업무 보고서의 문서 구조화도 큰 도움이 될 거 같습니다. 이후에, 다른 시스템으로 변경할때도 쉽게 XML 같은 구조화 문서로 변경이 가능하다는 얘기죠. 그렇다면, 지금 만들어놓은 업무 보고서들을 손쉽게 다른 시스템으로도 이식할 수 있다는 얘기이구요. 문서의 구조화라는 중요성을 다시 한번 느끼게 됩니다.

시스템 유지보수? 걱정없습니다. 위키 자체는 관리하는 팀이 있고, 위키 관리팀은 우리 팀 업무 관리 시스템을 몰라도 됩니다. 하드 디스크가 부족하면, 추가하면 됩니다. ^^ 우리 때문에 하드 디스크가 부족하고 투덜 거릴 날이 오면 좋겠습니다. 여기에 위키의 수많은 기능들을 그대로 이용할 수 있으니 - 내용 검색, 문서 백업 및 히스토리 기능,파일 첨부, 이미지를 포함한 유연한 편집 기능 - 너무 행복합니다.

tag : 위키, 주간보고, 프로젝트 관리, Include