엊그제, OpenID Consumer는 사용자마다 복수의 OpenID를 허용해야 한다는 이야기를 하자마자, myid.net이 잠깐 중단되었었다고 한다. 국내에는 현재 알려진 OpenID Provider는 myid.net이 유일한 상태에서 me2day나 springnote, lifepod(이건 아직 안열었지만) 등이 OpenID"만"을 지원하는 현실에 많은 이들이 불편해했을 듯 하다.
OpenID Provider가 365X24 무결점으로 돌아가면 제일 좋겠으나 그건 불가능하고, 결국 Consumer측에서 이러한 사고에 대한 준비가 되어있어야 한다. 각 사용자별로 복수의 OpenID를 하나의 계정에 등록해둘 수 있게 하여 필요할 때마다 추가, 변경, 취소가 가능해야하며, 각각에 대한 delegation도 가능해야겠다.
좋은 OpenID Consumer가 되려면 품이 많이 든다. 어쩌면 기존의 아이디/패스워드보다 더 공이 많이 들어야 하리라. 이럴 때일 수록, 최초에 도입하는 트렌드 리더들이 더 꼼꼼한 모습을 보여야 하겠다.
2007년 3월 28일 수요일
2007년 3월 25일 일요일
How to delegate openid
최근, 스프링노트의 delegation 문제에 대해 고민하다가(내가 왜... 남의 서비스에 대해 고민을... -_-a) OpenID 컨슈머 구현시 delegation 부분과 관련하여 더 나은 사용성을 제공하는 방법에 대해 생각해보게 되었습니다.
1. What is my OpenID?
아주 원초적인 문제입니다만, 나의 OpenID Account URL은 무엇일까요?
여기 eouia.myid.net이라는 OpenID Account를 가지고 있는 사용자가 하나 있다고 합시다. 이 사용자는 OpenID를 제법 잘 이해하고 있어서, 재미없는(?) myid.net이라는 도메인 대신 자신을 더 잘 identifying해줄 수 있는 http://dnzin.com을 delegated URL로 쓰고 있다고 하지요.
이제, OpenID인증이 필요한 곳마다, 이 사용자는, eouia.myid.net과 dnzin.com 두 가지 중의 한가지를 입력하는 선택을 해야 합니다. 사용자는 두가지 URL이 모두 유효하며 동일한 사용성을 가지는, 동등한 인식키라고 생각할 것입니다. 즉, dnzin.com은 eouia.myid.net의 alias라고 여기겠지요.
그렇다면, Consumer측에서는 이러한 사용자를 위해 어떻게 해야 할까요?
간단하게는
- 입력받은 URL을 방문해서 openid server와 delegation정보(만약 있다면)를 받아와 진짜 OpenID URL을 확인한 후, 해당 정보로 OpenID 인증을 시도합니다.
겉으로 보기에는 이것으로 끝이겠지만, 실제로 뒷단에서는 조금 골치아픈 일이 생길 수 있습니다.
이 사용자의 unique id로써 무엇을 DB에 저장해야 할까요? (계정을 생성하고 유지하기 위해서는 DB에 해당 사용자의 세션을 만들 필요가 있으므로...)
아마도 eouia.myid.net을 이 사용자에 대한 unique id로 잡는 것이 상식적일 것입니다.
그래야만, 사용자가 delegation을 바꾸더라도 동일한 account를 유지할 수 있을테니까요.
예를 들어, 사용자가 http://dnzin.com 대신, http://eouia.com으로 블로그를 바꾸면서 delegation도 바꾸었습니다. 이런 경우에도, 사용자는 delegation을 통해 새로운 http://eouia.com으로도, 새로운 가입절차 없이 이전과 동일한 계정에 로그인할 수 있기를 원할 겁니다.
따라서, Consumer측에서는 로그인시에, 입력받은 URL이 OpenID일거라고 가정하고 바로 DB에 저장된 값과 비교하는 대신, 반드시 해당 URL을 방문해서 delegation 정보를 획득하여 매번 OpenID 인증을 시도해야만 합니다.
현재 스프링노트에서는, 가입시에는 delegation 처리를 하지만, 로그인시에는 delegation 처리를 건너뛰고 있는 듯 합니다. 또는, 조금 있다가 따로 이야기 하겠지만, 사용자의 unique id로 실제 openid url대신 사용자로부터 최초 입력받은 url을 키값으로 쓰고 있을지도요. (버그 게시판의 답변을 미루어보자면 그런 듯... 실제로 안이 어떻게 구현되어있을지 저는 모르죠. ^_^)
여기까지는 가장 기본적인 Consumer 구현법입니다만, 실제로는 좀 문제가 있습니다.
2. How to change my OpenID?
이 사용자가 어느날, myid.net은 싫어... 라며 다른 OpenID Provider로 자신의 OpenID를 바꾸게 되었습니다. 그럴 일이 있겠냐구요? 어느날 myid.net이 없어지거나, 혹은 더 좋은 OpenID Provider가 생겼다거나, 혹은 myid.net이 SRE를 지원하지 않아 불편해.. 라고 생각할 수도 있겠지요.
그래서, eouia.newopenid.com이라는 새로운 OpenID 계정을 사용하기로 결심했습니다. 그래도 delegation을 통해 이전처럼 eouia.com이라는 url로 동일하게 로그인이 가능할 거라고 기대하겠지요. (delegation의 장점이죠.)
그런데, Consumer측에서는 문제가 생겼습니다. 사용자 계정 정보를 실제 OpenID URL(eouia.myid.net)을 키값으로 삼고 있었는데, 전혀 다른 새로운 OpenID URL(eouia.newopenid.com)이 들어오면 이것이 동일한 사용자라고 판단할 수 없기 때문입니다.
그렇다면, 역시 DB의 키값으로는 최초 입력받은 URL을 키값으로 삼는 것이 해결책이라고 생각할 수도 있겠지만... 이 경우에는 delegated URL을 바꿨을 때가 문제가 됩니다. (1번 참조)
결국, 이 사용자에 대한 unique id로 OpenID URL도, delegated URL도 사용하기 곤란한 상황이 됩니다.
3. multiple OpenID
그렇다면, 아예 DB의 유니크한 키값으로 URL을 쓰지 않는 방법이 가능하겠죠.
사용자는 언제든지 사용하고 있는 OpenID를 변경할 수 있고, delegate URL도 바뀔 수 있으며, 그 모든 경우에 대해 동일한 사용자로 인정받기를 원할 수 있습니다.
하지만 한편으로는, 동일한 OpenID에 대해 별개의 Persona의 개념을 원할 수도 있지요. (이 부분은 다른 기회에 다시...)
뿐만 아니라 인증 자체가 내가 컨트롤 할 수 없는 Provider쪽의 시스템을 이용하는 것이기 때문에, 별도의 안전장치를 필요로 합니다. 예를 들어, 어느날 갑자기 myid.net의 인증서버가 고장이 난다면, myid.net을 이용하던 사용자들은 다른 Consumer서비스를 전혀 이용할 수 없게 됩니다. 마른 하늘의 날벼락이죠. (OpenID Provider들이 더 늘어난다면 분명 이러한 문제가 생길 경우도 예상할 수 있습니다.)
따라서 친절한 Consumer라면 이러한 문제들을 해결하기 위해 다음과 같은 방법을 고려해야 합니다.
1) 하나의 계정당 복수개의 OpenID를 등록해서 사용할 수 있게 할 것.
2) 기존의 계정에 새로운 OpenID를 추가등록할 수 있게 할 것.
3) 물론 당연히 각각의 등록된 OpenID에 대해 delegation을 허용할 것.
4) 사용자가 등록된 OpenID를 삭제할 수 있을 것.
4)이 좀 이해가 안갈 수도 있을테니 부가설명 들어갑니다.
여기, eouia.com이라는 도메인을 가지고 있는 사용자가 있습니다. 자신의 OpenID로 eouia.com을 사용하고 있었는데, 깜박 잊고 도메인 연장을 하지 않아 타인에게 이 도메인을 빼앗겼습니다. 그 후, eouia.com을 획득한 타인이 역시 자신의 OpenID로 해당 도메인을 사용하고, 이를 이용해 이전 사용자의 인증을 도용한다면 어떻게 될까요. 이런 경우를 막기 위해서 사용자는 자신의 OpenID를 서비스에서 삭제할 수 있어야 합니다. (혹은, 추후 OpenID 스펙에, 해당 URL은 더이상 유효하지 않음을 Consumer들에게 알리는 프로토콜이 들어가는 방법도 있겠지요.)
4. Best Practice
어쨌거나 이러한 프로세스를 Consumer에서 제공하기 위해서는 사용자별로 OpenID를 unique id로 잡아서는 안되겠지요. 사실, openid만 사용가능한 서비스들(국내의 경우라면 스프링노트나 미투데이 등)은 아마 대부분 이런 식으로 구현될텐데, OpenID만 사용가능하게 하는 것이 사용자 정책적으로 전혀 바람직하지 않을 뿐더러, 실제로 운용에 있어 위에 언급한 바와 같은 문제점들이 발생할 수 있습니다. 그런 면에서 본다면, 왜 스프링노트나 미투데이 등이 OpenID 전용으로만 서비스하는지 조금 이해하기 어렵습니다. (정식 오픈때도 설마 OpenID전용은 아니겠지요.)
결론내리자면,
1) 단일 OpenID URL에 종속적인 인증은 사용자의 사용성을 저해할 수 있습니다.
2) 서비스 설계시 OpenID의 변경 가능성 및 복수 이용에 대해 열려있어야 합니다.
3) 결정적으로 OpenID에만 의존하는 인증방법은 바람직하지 않습니다. OpenID외에도 인증방법은 여러가지가 있을테니까요. (1년 서비스하고 말거면 뭐 상관없겠습니다만.)
1. What is my OpenID?
아주 원초적인 문제입니다만, 나의 OpenID Account URL은 무엇일까요?
여기 eouia.myid.net이라는 OpenID Account를 가지고 있는 사용자가 하나 있다고 합시다. 이 사용자는 OpenID를 제법 잘 이해하고 있어서, 재미없는(?) myid.net이라는 도메인 대신 자신을 더 잘 identifying해줄 수 있는 http://dnzin.com을 delegated URL로 쓰고 있다고 하지요.
이제, OpenID인증이 필요한 곳마다, 이 사용자는, eouia.myid.net과 dnzin.com 두 가지 중의 한가지를 입력하는 선택을 해야 합니다. 사용자는 두가지 URL이 모두 유효하며 동일한 사용성을 가지는, 동등한 인식키라고 생각할 것입니다. 즉, dnzin.com은 eouia.myid.net의 alias라고 여기겠지요.
그렇다면, Consumer측에서는 이러한 사용자를 위해 어떻게 해야 할까요?
간단하게는
- 입력받은 URL을 방문해서 openid server와 delegation정보(만약 있다면)를 받아와 진짜 OpenID URL을 확인한 후, 해당 정보로 OpenID 인증을 시도합니다.
겉으로 보기에는 이것으로 끝이겠지만, 실제로 뒷단에서는 조금 골치아픈 일이 생길 수 있습니다.
이 사용자의 unique id로써 무엇을 DB에 저장해야 할까요? (계정을 생성하고 유지하기 위해서는 DB에 해당 사용자의 세션을 만들 필요가 있으므로...)
아마도 eouia.myid.net을 이 사용자에 대한 unique id로 잡는 것이 상식적일 것입니다.
그래야만, 사용자가 delegation을 바꾸더라도 동일한 account를 유지할 수 있을테니까요.
예를 들어, 사용자가 http://dnzin.com 대신, http://eouia.com으로 블로그를 바꾸면서 delegation도 바꾸었습니다. 이런 경우에도, 사용자는 delegation을 통해 새로운 http://eouia.com으로도, 새로운 가입절차 없이 이전과 동일한 계정에 로그인할 수 있기를 원할 겁니다.
따라서, Consumer측에서는 로그인시에, 입력받은 URL이 OpenID일거라고 가정하고 바로 DB에 저장된 값과 비교하는 대신, 반드시 해당 URL을 방문해서 delegation 정보를 획득하여 매번 OpenID 인증을 시도해야만 합니다.
현재 스프링노트에서는, 가입시에는 delegation 처리를 하지만, 로그인시에는 delegation 처리를 건너뛰고 있는 듯 합니다. 또는, 조금 있다가 따로 이야기 하겠지만, 사용자의 unique id로 실제 openid url대신 사용자로부터 최초 입력받은 url을 키값으로 쓰고 있을지도요. (버그 게시판의 답변을 미루어보자면 그런 듯... 실제로 안이 어떻게 구현되어있을지 저는 모르죠. ^_^)
여기까지는 가장 기본적인 Consumer 구현법입니다만, 실제로는 좀 문제가 있습니다.
2. How to change my OpenID?
이 사용자가 어느날, myid.net은 싫어... 라며 다른 OpenID Provider로 자신의 OpenID를 바꾸게 되었습니다. 그럴 일이 있겠냐구요? 어느날 myid.net이 없어지거나, 혹은 더 좋은 OpenID Provider가 생겼다거나, 혹은 myid.net이 SRE를 지원하지 않아 불편해.. 라고 생각할 수도 있겠지요.
그래서, eouia.newopenid.com이라는 새로운 OpenID 계정을 사용하기로 결심했습니다. 그래도 delegation을 통해 이전처럼 eouia.com이라는 url로 동일하게 로그인이 가능할 거라고 기대하겠지요. (delegation의 장점이죠.)
그런데, Consumer측에서는 문제가 생겼습니다. 사용자 계정 정보를 실제 OpenID URL(eouia.myid.net)을 키값으로 삼고 있었는데, 전혀 다른 새로운 OpenID URL(eouia.newopenid.com)이 들어오면 이것이 동일한 사용자라고 판단할 수 없기 때문입니다.
그렇다면, 역시 DB의 키값으로는 최초 입력받은 URL을 키값으로 삼는 것이 해결책이라고 생각할 수도 있겠지만... 이 경우에는 delegated URL을 바꿨을 때가 문제가 됩니다. (1번 참조)
결국, 이 사용자에 대한 unique id로 OpenID URL도, delegated URL도 사용하기 곤란한 상황이 됩니다.
3. multiple OpenID
그렇다면, 아예 DB의 유니크한 키값으로 URL을 쓰지 않는 방법이 가능하겠죠.
사용자는 언제든지 사용하고 있는 OpenID를 변경할 수 있고, delegate URL도 바뀔 수 있으며, 그 모든 경우에 대해 동일한 사용자로 인정받기를 원할 수 있습니다.
하지만 한편으로는, 동일한 OpenID에 대해 별개의 Persona의 개념을 원할 수도 있지요. (이 부분은 다른 기회에 다시...)
뿐만 아니라 인증 자체가 내가 컨트롤 할 수 없는 Provider쪽의 시스템을 이용하는 것이기 때문에, 별도의 안전장치를 필요로 합니다. 예를 들어, 어느날 갑자기 myid.net의 인증서버가 고장이 난다면, myid.net을 이용하던 사용자들은 다른 Consumer서비스를 전혀 이용할 수 없게 됩니다. 마른 하늘의 날벼락이죠. (OpenID Provider들이 더 늘어난다면 분명 이러한 문제가 생길 경우도 예상할 수 있습니다.)
따라서 친절한 Consumer라면 이러한 문제들을 해결하기 위해 다음과 같은 방법을 고려해야 합니다.
1) 하나의 계정당 복수개의 OpenID를 등록해서 사용할 수 있게 할 것.
2) 기존의 계정에 새로운 OpenID를 추가등록할 수 있게 할 것.
3) 물론 당연히 각각의 등록된 OpenID에 대해 delegation을 허용할 것.
4) 사용자가 등록된 OpenID를 삭제할 수 있을 것.
4)이 좀 이해가 안갈 수도 있을테니 부가설명 들어갑니다.
여기, eouia.com이라는 도메인을 가지고 있는 사용자가 있습니다. 자신의 OpenID로 eouia.com을 사용하고 있었는데, 깜박 잊고 도메인 연장을 하지 않아 타인에게 이 도메인을 빼앗겼습니다. 그 후, eouia.com을 획득한 타인이 역시 자신의 OpenID로 해당 도메인을 사용하고, 이를 이용해 이전 사용자의 인증을 도용한다면 어떻게 될까요. 이런 경우를 막기 위해서 사용자는 자신의 OpenID를 서비스에서 삭제할 수 있어야 합니다. (혹은, 추후 OpenID 스펙에, 해당 URL은 더이상 유효하지 않음을 Consumer들에게 알리는 프로토콜이 들어가는 방법도 있겠지요.)
4. Best Practice
어쨌거나 이러한 프로세스를 Consumer에서 제공하기 위해서는 사용자별로 OpenID를 unique id로 잡아서는 안되겠지요. 사실, openid만 사용가능한 서비스들(국내의 경우라면 스프링노트나 미투데이 등)은 아마 대부분 이런 식으로 구현될텐데, OpenID만 사용가능하게 하는 것이 사용자 정책적으로 전혀 바람직하지 않을 뿐더러, 실제로 운용에 있어 위에 언급한 바와 같은 문제점들이 발생할 수 있습니다. 그런 면에서 본다면, 왜 스프링노트나 미투데이 등이 OpenID 전용으로만 서비스하는지 조금 이해하기 어렵습니다. (정식 오픈때도 설마 OpenID전용은 아니겠지요.)
결론내리자면,
1) 단일 OpenID URL에 종속적인 인증은 사용자의 사용성을 저해할 수 있습니다.
2) 서비스 설계시 OpenID의 변경 가능성 및 복수 이용에 대해 열려있어야 합니다.
3) 결정적으로 OpenID에만 의존하는 인증방법은 바람직하지 않습니다. OpenID외에도 인증방법은 여러가지가 있을테니까요. (1년 서비스하고 말거면 뭐 상관없겠습니다만.)
2007년 3월 20일 화요일
내가 RoR을 안하는 이유
몇가지가 있긴 하다.
1. 아직 완벽하게 익히지 못했다.
그렇다고 다른 랭귀지가 완벽하냐. 그건 절대 아니고, 가장 기초적인 syntax grammar조차도 일부러 안외우고 그때그때 레퍼런스에 의존하는 나로서는 RoR에 대해 충분할 만큼 레퍼런스를 숙지하지 못했다는 뜻. 사실, 아래의 변명들은 결국 이 이유에서 파생된다.
2. RoR의 생산성을 자신할 수 없다.
확실히, 단순한(?) 모델링에서 RoR이 멋짐을 깨달았지만, 복잡도가 증가할 수록 다른 수단과의 격차가 점점 줄어들드라. 이게 나의 잘못인지, 아니면 애초에 복잡계에서의 작업량 수렴의 한계치가 정해져있는 것인지는 아직 미정.
3. 이미 프레임워크를 쓰고 있다.
결국, RoR은 컨벤션의 통일에 의한 효율성과 메타프로그래밍의 용이성이 장점인 듯 한데, 아예 프레임워크를 안썼으면 모를까, 이미 다른 개발환경에서도 프레임워크를 쓰고 있는 나로서는 그다지 엄청난 마법의 지팡이같은 생각은 안든다. 예를 들자면, 코드가 좀 지저분하긴 해도 php로도 충분히 버금가는 퍼포먼스의 프레임워크가 존재할 수 있다. 심지어 비슷한 컨벤셔널 룰로.
4. I'm not native
Ruby 코드의 가독성이 좋다고 하던데, 왜 그런 이야기가 나오는지 수긍이 가긴 하지만, 뭐랄까, 문어체 스타일. 영어가 네이티브가 아닌 나로서는 소위 말하는 Fortran류의 수식형 코드쪽이 더 이해하기 쉽다. 아아, 네이티브 급의 개발자 분들에게는 아무 상관없고 오히려 장점이겠지만.
여튼, Ruby코드보다는 차라리 Perl코드가 더 잘 눈에 들어오는 구식 개발자라서 그런가 보다.
5. 이게 진짜 이유인데..
RoR로 한게 고작 그 정도야? 라는 평가를 스스로 내리거나 남들로부터 듣고 싶지 않기에... 사실, 별로... 남들이 해놓은 RoR도 그 코스트등을 곰곰히 살펴보면, 그다지 Agile하거나 Rapid하지도 않더라... 라는 걱정.
1. 아직 완벽하게 익히지 못했다.
그렇다고 다른 랭귀지가 완벽하냐. 그건 절대 아니고, 가장 기초적인 syntax grammar조차도 일부러 안외우고 그때그때 레퍼런스에 의존하는 나로서는 RoR에 대해 충분할 만큼 레퍼런스를 숙지하지 못했다는 뜻. 사실, 아래의 변명들은 결국 이 이유에서 파생된다.
2. RoR의 생산성을 자신할 수 없다.
확실히, 단순한(?) 모델링에서 RoR이 멋짐을 깨달았지만, 복잡도가 증가할 수록 다른 수단과의 격차가 점점 줄어들드라. 이게 나의 잘못인지, 아니면 애초에 복잡계에서의 작업량 수렴의 한계치가 정해져있는 것인지는 아직 미정.
3. 이미 프레임워크를 쓰고 있다.
결국, RoR은 컨벤션의 통일에 의한 효율성과 메타프로그래밍의 용이성이 장점인 듯 한데, 아예 프레임워크를 안썼으면 모를까, 이미 다른 개발환경에서도 프레임워크를 쓰고 있는 나로서는 그다지 엄청난 마법의 지팡이같은 생각은 안든다. 예를 들자면, 코드가 좀 지저분하긴 해도 php로도 충분히 버금가는 퍼포먼스의 프레임워크가 존재할 수 있다. 심지어 비슷한 컨벤셔널 룰로.
4. I'm not native
Ruby 코드의 가독성이 좋다고 하던데, 왜 그런 이야기가 나오는지 수긍이 가긴 하지만, 뭐랄까, 문어체 스타일. 영어가 네이티브가 아닌 나로서는 소위 말하는 Fortran류의 수식형 코드쪽이 더 이해하기 쉽다. 아아, 네이티브 급의 개발자 분들에게는 아무 상관없고 오히려 장점이겠지만.
여튼, Ruby코드보다는 차라리 Perl코드가 더 잘 눈에 들어오는 구식 개발자라서 그런가 보다.
5. 이게 진짜 이유인데..
RoR로 한게 고작 그 정도야? 라는 평가를 스스로 내리거나 남들로부터 듣고 싶지 않기에... 사실, 별로... 남들이 해놓은 RoR도 그 코스트등을 곰곰히 살펴보면, 그다지 Agile하거나 Rapid하지도 않더라... 라는 걱정.
MSN 당황
가끔, MSN에 누구인지 가물가물한 상대에게서 메시지가 올 때가 있습니다.
왠만하면 제대로 기억해내는 편이지만...
미안, O군. 사실 아까 메신저 받았을 때 누군지 기억 못했어. 하필이면 O군과 같은 이름(성은 다른)이 또 있는지라, 그 친구인줄로만.
갑자기 MSN으로 메시지가 왔을 때, 게다가 이쪽에서는 약간 가물가물 할 때 갑자기 친근모드이면 차마, 누군지 모르겠다는 말을 못하겠습니다. 차라리 메일이었으면, 단도직입적으로 "누구신가요?"라고 물어봤을테지만, 메신저에서는 대화간에(그것도 한껏 친근모드일 때) 그렇게 인터럽트 걸기가 어렵다구요.
여튼, 최대한 기억해내겠습니다. 혹시나 기억하고 있지 못했다 해서 실망하셨다면 매우 죄송. 이 블로그를 보고 연락을 준거였는지는 모르겠지만, 혹시 보고 있다면 뒤늦게라도 사과를.
이런 난처한 경우는 꽤 많을 법도 한데, 이 문제를 해결해줄 수 있는 솔루션은 없을까요? 평소에는 구글링을 솔루션으로 애용하고 있습니다만, 구글링에 안걸리는 경우도 있으니까.
왠만하면 제대로 기억해내는 편이지만...
미안, O군. 사실 아까 메신저 받았을 때 누군지 기억 못했어. 하필이면 O군과 같은 이름(성은 다른)이 또 있는지라, 그 친구인줄로만.
갑자기 MSN으로 메시지가 왔을 때, 게다가 이쪽에서는 약간 가물가물 할 때 갑자기 친근모드이면 차마, 누군지 모르겠다는 말을 못하겠습니다. 차라리 메일이었으면, 단도직입적으로 "누구신가요?"라고 물어봤을테지만, 메신저에서는 대화간에(그것도 한껏 친근모드일 때) 그렇게 인터럽트 걸기가 어렵다구요.
여튼, 최대한 기억해내겠습니다. 혹시나 기억하고 있지 못했다 해서 실망하셨다면 매우 죄송. 이 블로그를 보고 연락을 준거였는지는 모르겠지만, 혹시 보고 있다면 뒤늦게라도 사과를.
이런 난처한 경우는 꽤 많을 법도 한데, 이 문제를 해결해줄 수 있는 솔루션은 없을까요? 평소에는 구글링을 솔루션으로 애용하고 있습니다만, 구글링에 안걸리는 경우도 있으니까.
2007년 3월 16일 금요일
WYM의 구현
현재까지 쓸만한 WYSIWYM 웹 에디터는 WymEditor가 유일했는데, 모 사의 모 클로즈드 베타 서비스를 사용해보니 WYM을 아주 간단하면서도 상콤하게 구현해놓았다.
Wiki이기 때문에 간단하면서도 상콤하게 WYM이 가능했던 것일까? 애초에 내가 생각했던 WYM의 문제점은 사용자들의 비시맨틱마크업에 대한 욕구를 어떻게 풀어나갈 것인가였는데, Wiki는 애초에 그것이 필요가 없으니까.
발상의 전환이랄까... 처음부터 안돼!라고 해서 사용자를 길들이는 것이 그렇게 힘든 일은 아닐 것 같다. 확실히 무지개 알록달록을 원하는 사용자들이 많긴 하지만, 그 요구를 들어줘야 하는 타당한 이유를 찾을 수 가 없다. (소비자는 왕이지만 폭군이 되도록 놔두는 것이 옳은 것은 아니라고 생각.)
아무튼, 훌륭하네. 간만에 괜찮은 서비스를 봤다.
자세히 보니 WYM이 아니라, 그냥 WYSIWYG다. -_-a
Wiki이기 때문에 간단하면서도 상콤하게 WYM이 가능했던 것일까? 애초에 내가 생각했던 WYM의 문제점은 사용자들의 비시맨틱마크업에 대한 욕구를 어떻게 풀어나갈 것인가였는데, Wiki는 애초에 그것이 필요가 없으니까.
발상의 전환이랄까... 처음부터 안돼!라고 해서 사용자를 길들이는 것이 그렇게 힘든 일은 아닐 것 같다. 확실히 무지개 알록달록을 원하는 사용자들이 많긴 하지만, 그 요구를 들어줘야 하는 타당한 이유를 찾을 수 가 없다. (소비자는 왕이지만 폭군이 되도록 놔두는 것이 옳은 것은 아니라고 생각.)
아무튼, 훌륭하네. 간만에 괜찮은 서비스를 봤다.
자세히 보니 WYM이 아니라, 그냥 WYSIWYG다. -_-a
pneumonoultramicroscopicsilicovolcanoconiosis
새학기가 시작되었다.
중고등학교 다닐 때, 새로 입학하면 꼭 사전을 새로 샀는데(그래봤자 2번이지만), 늘 민중서관의 에센스를 사긴 했지만 내심 엘리트사전의 깔끔한 디자인을 더 부러워하긴 했다.
사전을 고를 때에, 좋은 사전을 찾는 한가지 나만의 노하우(?)가 있었는데, 바로 다음 단어가 수록되어있는지를 확인하는 것.
pneumonoultramicroscopicsilicovolcanoconiosis
뜻은 "진폐증". 45자로 이루어진 가장 긴 영어단어라고 한다.
뭐, 저게 있어야 좋은 사전이라는 기준 자체는 엉터리이긴 하지만.
새 도메인을 하나 찾고 있는 중인데, 생각나서 검색해보니... 비어있다.
pneumonoultramicroscopicsilicovolcanoconios.is
아이슬란드... 살까 말까 고민중. 그런데... 뭐에 쓴다냐...
중고등학교 다닐 때, 새로 입학하면 꼭 사전을 새로 샀는데(그래봤자 2번이지만), 늘 민중서관의 에센스를 사긴 했지만 내심 엘리트사전의 깔끔한 디자인을 더 부러워하긴 했다.
사전을 고를 때에, 좋은 사전을 찾는 한가지 나만의 노하우(?)가 있었는데, 바로 다음 단어가 수록되어있는지를 확인하는 것.
pneumonoultramicroscopicsilicovolcanoconiosis
뜻은 "진폐증". 45자로 이루어진 가장 긴 영어단어라고 한다.
뭐, 저게 있어야 좋은 사전이라는 기준 자체는 엉터리이긴 하지만.
새 도메인을 하나 찾고 있는 중인데, 생각나서 검색해보니... 비어있다.
pneumonoultramicroscopicsilicovolcanoconios.is
아이슬란드... 살까 말까 고민중. 그런데... 뭐에 쓴다냐...
사용자의 경험을 존중하자
바로 앞의 포스트와는 반대되는 이야기일 수도 있는데,
개인적으로 웹페이지에 단축키를 넣는 것을 그닥 바람직하게 생각하지 않는다. 왜냐하면 웹사이트는 사용자의 경험과 환경을 알 수 없기 때문에, 때로는 과잉 친절은 전혀 의도하지 않은 부작용을 낳을 수도 있기 때문이다.
예를 들어, "Ctrl + Space"를 중요한 단축키로 사용하는 어떤 서비스가 있다고 하자. 이것은 대개의 경우에 사용하는데 아무런 문제가 없지만, Mac사용자는(그리고 혹시 OS단에서 이미 선점하는 다른 어떤 환경에서도) 해당 기능을 사용할 수 없다. 왜냐하면 Ctrl+Space는 Mac OSX의 중요한 기능 중 하나인 Spotlight를 위해 예약되어있기 때문이다.
시각장애인들의 경우에도 비슷한데, 이들이 사용하는 각종 보조장치/프로그램의 단축키가 제법 많아서 웹페이지의 단축키와 충돌하는 경우들이 있기 때문이다.
확실히 단축키는 편리하긴 하지만, 그래서 더욱 조심스럽게 접근해야만 한다. 일단 단축키 없이 이용가능해야 하는 점이 가장 중요하고, 단축키를 사용할 때에는 기존의 사용자경험과 상충되지 않는지 확인해야만 한다. 그러나 사용자의 경험은 모두 제각각인데 어떻게 해결할 수 있을까.
가장 좋은 해결책은 아마도, 단축키 재정의가 사용자마다 가능하도록 하는 것. 사용자의 경험을 존중하는 서비스들이 많아지길.
개인적으로 웹페이지에 단축키를 넣는 것을 그닥 바람직하게 생각하지 않는다. 왜냐하면 웹사이트는 사용자의 경험과 환경을 알 수 없기 때문에, 때로는 과잉 친절은 전혀 의도하지 않은 부작용을 낳을 수도 있기 때문이다.
예를 들어, "Ctrl + Space"를 중요한 단축키로 사용하는 어떤 서비스가 있다고 하자. 이것은 대개의 경우에 사용하는데 아무런 문제가 없지만, Mac사용자는(그리고 혹시 OS단에서 이미 선점하는 다른 어떤 환경에서도) 해당 기능을 사용할 수 없다. 왜냐하면 Ctrl+Space는 Mac OSX의 중요한 기능 중 하나인 Spotlight를 위해 예약되어있기 때문이다.
시각장애인들의 경우에도 비슷한데, 이들이 사용하는 각종 보조장치/프로그램의 단축키가 제법 많아서 웹페이지의 단축키와 충돌하는 경우들이 있기 때문이다.
확실히 단축키는 편리하긴 하지만, 그래서 더욱 조심스럽게 접근해야만 한다. 일단 단축키 없이 이용가능해야 하는 점이 가장 중요하고, 단축키를 사용할 때에는 기존의 사용자경험과 상충되지 않는지 확인해야만 한다. 그러나 사용자의 경험은 모두 제각각인데 어떻게 해결할 수 있을까.
가장 좋은 해결책은 아마도, 단축키 재정의가 사용자마다 가능하도록 하는 것. 사용자의 경험을 존중하는 서비스들이 많아지길.
2007년 3월 13일 화요일
좌회전 금지
스테이플러 찍어주는 복사기 이후, 간만에 인간에게 실질적인 도움을 주는 과학기술의 발달을 체감한 기사 한토막.
좌회전 신호대기시 낭비되는 연료를 절감하기 위해, 좌회전을 금지하고, 대신 직진과 우회전만으로 최적경로를 찾는 소프트웨어라... 아주 멋지다. 저런게 진짜 기술이지.
좌회전 신호대기시 낭비되는 연료를 절감하기 위해, 좌회전을 금지하고, 대신 직진과 우회전만으로 최적경로를 찾는 소프트웨어라... 아주 멋지다. 저런게 진짜 기술이지.
2007년 3월 12일 월요일
playtalk, me2day
별건 아니고,
만약 playtalk이 단지 wannabe proxy서비스라면....
정작 놀라야 할 건, 10여일 만(me2day가 외부에 노출된 후??)에 간단히 뚝딱 만들어낸 그 Rapidity랄까.
그렇게 agile스럽다는 RoR과 비교하면 어느쪽이 더 빠른 것일까 제법 궁금해진다.
보기에는 .NET인 듯 한데...
누가 누구걸 베꼈느니 하는 이야기는 다른 사람들이 많이 할테니까, 접어두고.
각자 자기였다면 과연 10여일 만에 만들어낼 수 있겠나 하는 질문들을 스스로에게 던져두는 편이 좋지 않을까.
역시 프레임워크가 중요하렷다.
돌고 돌기
me2day
* daily archive의 부활
*
A tumblelog is a quick and dirty stream of consciousness, a bit like a remaindered links style linklog but with more than just links. They remind me of an older style of blogging, back when people did sites by hand, before Movable Type made post titles all but mandatory, blog entries turned into short magazine articles, and posts belonged to a conversation distributed throughout the entire blogosphere. Robot Wisdom and Bifurcated Rivets are two older style weblogs that feel very much like these tumblelogs with minimal commentary, little cross-blog chatter, the barest whiff of a finished published work, almost pure editing...really just a way to quickly publish the "stuff" that you run across every day on the web.
* moblog의 부활
크게 한바퀴 돌아 블로그의 초기형태로 돌아가기.
역사는 순환하며 발전하므로, 이미 블로그가 아닌 소셜 네트워크 커뮤니케이션 도구에 더 가까와졌지만.
아무튼, 재미있는 서비스.. 모쪼록 멋지게 성공하시길.
웃는 남자 단상
조금만 기다리면 동영상에서도 실시간으로 웃는남자의 출현을 볼 수 있을지도.
패턴 인식은 지금까지도 컴퓨터 사이언스에서 매우 중요한 위치를 차지하고 있었지만, 시간이 갈 수록 점점 더 그 중요성은 커져갈 것이다.
UCC라는 정체불명의 유행은 차치하더라도, 동영상을 비롯해, 이미지, 음성, 텍스트, 바이너리 데이터 들의 컨텍스트에서 의미소를 추출해내는 패턴 인식 기술은 향후 10년 내에 가장 중요한 컴퓨터 기술로 꼽히게 될 것이며, 그로 인해 컴퓨팅 스타일도 획기적으로 변하리라.
진대제 전 장관이 모 벤처회사에 거액을 투자한 이유도, 따지고 보면 그 회사의 서비스 자체(요즘 통 소식을 못들었음.)보다도, 패턴 인식 - 얼굴 인식이라는 기술 자체가 아닐까.
"저 배우가 입은 옷 예쁘네. 어디서 살 수 있지?" 에 대한 기술적 구현은 상당히 다양하게 시도되어왔었다.
Digital Interactive TV 진영에서는 방송데이터에 대한 메타태그들을 함께 담아보내려 하고 있고(늘 그렇듯이, 컨텐트 프로바이더가 내보내는 데이터는 그 양과 질에 한계가 있다. 도대체 누가 사용자의 복잡다양한 욕구를 전부 알리오.)
YouTube 같은 소위 web 2.0 진영에서는 집단지성이라는 미명으로 사용자 그룹에 의한 노가다 태깅으로 이 문제를 해결하려 한다.
한편 패턴 인식을 이용해 기계로 하여금 시맨틱한 컨텐트를 이해하도록 하는 시도도 있고.
결과적으로 어느쪽이 우세할 지 점치는 것은 지금으로서는 아직 이르지만...
여튼, "웃는 남자"의 출현을 위해서도 패턴 인식쪽이 얼른얼른 발전했으면 좋겠다.
2007년 3월 6일 화요일
롱테일과 매쉬업 다시보기
"왜 우리 서비스는, 남들이 하는 것들을 대부분 하고 있는데도 사용자들의 만족도가 높지 않을까? 남들이 하는 것의 90%를 제공하고 있으니 최소한 90%수준의 트래픽이 나와야 하는 것 아닌가?"
어떤 웹서비스에 다음과 같은 이익(utility)을 원하는 사용자층이 있다고 하자.
1. A, B, C, D, J
2. A, B, C, D, F
3. A, B, C, D, H
4. A, B, C, E, F
5. A, B, C, E, G
6. A, B, C, D, G
7. A, B, C, E, H
8. A, B, C, D, I
9. A, B, D, E, H
10. A, B, C, G, H
만약 이상적으로 A~J까지의 기능을 모두 제공하는 웹서비스라면 모든 사용자가 진정으로 만족하겠지만...
현실적으로는 비용을 고려해보면 모든 기능을 완벽히 제공하기란 어렵다. (혹은 반대로, 모든 사용자의 마음에 들 수 있는 서비스란 어렵다라는 말로 표현할 수도 있겠다.)
고전적인 서비스 기획자라면, 모든 이가 반드시 사용하는 A,B의 기능을 포함하고, 90%이상의 사용자가 사용하는 C의 기능을 포함하는 선에서 타협을 볼 것이다. 조금 더 여유가 있다면 제법 많은 이들이 사용하는 D, E의 기능까지 넣을 수 있을 것이다.
이 서비스는 만족스러운가?
통계적으로 잡힌 가상의 대부분의 사용자들이 원하는 대표적 기능 'A, B, C, D, E'는 실제로 파렛토 법칙에 따라 "대다수의 사용자가 가장 많이 사용하는 기능들"을 구현했음에도 불구하고, 이 서비스는 어떠한 사용자에게도 만족스럽지 않다.
이것은 단지 통계의 마술일뿐일까?
조금 다른 가정을 해보자.
어떤 서비스는 똑같은 비용을 들여 'A, B, C, D, H'를 제공한다고 하자. 이 서비스는 최소한 1/10의 사용자에게는 완벽한 만족을 주는 서비스가 될 수 있을 것이다. 그렇다면 나머지 9/10에게는 앞서 말한 전통적 방식보다 더 안좋은 서비스일까?
실제로는 나머지 9/10에게는 앞서 말한 방식보다 특별히 더 나쁘게 여겨질 것도 없다. 어차피 자신들이 원하는 기능이 완벽히 제공되지는 않기 때문에. 혹자에게는 이전 방식보다 더 나은 면도 있을 테고.
만약 또 다른 어떤 서비스는 조금 더 비용을 들여 'A, B, C, D, G, H' 까지 제공하도록 만들어졌다고 하자. 1개의 기능이 추가됨으로 인해, 'A, B, C, D, H'만 지원하는 서비스에 비해 만족하는 사용자수가 3배가 되었다.
이 3개의 서비스가 경쟁하면 어느 것이 시장에서 더 성공할 수 있을까?
여기까지의 교훈
1. 가상의 "User"를 잡지 말 것. 사용자들은 하나의 magic word - "user"로 표현될 수 없다. 이는 브로드밴드시절의 매스마케팅 스타일 접근방식이며 웹의 장점을 포기하는 일이다.
2. 실제로 서비스의 만족도는 80%의 기능 "A, B, C, D, E"에서 차이나는 것이 아니라, 나머지 20%의 기능 "F, G, H, I, J"에서 결정된다.
그렇다면, "A, B, C, D, E"를 제공하는 서비스는 무엇을 잘못한걸까? 전형적인 근시안적 Greedy 알고리즘의 폐해일 뿐일까? 이 서비스는 되살아날 수 없는 것일까?
매쉬업 전략을 채택해보면 어떨까? 핵심기능 'A, B, C, D, E'만 제공하고 나머지는 3rd Party의 매쉬업 서비스를 가능하도록 열어둔다면?
특정 매쉬업 서비스 'A, F', 'A, B, I, J' 같은 것이 만들어질 수 있도록 오픈해두면 이전과는 반대로 사용자들은 이 서비스에 대한 만족도가 올라가게 될 것이다. 기본적으로 'A~E'까지의 핵심기능이 제공될 뿐더러, 이 서비스를 이용함으로 인해, 자신이 불만족스러워했던, 'F~J'까지의 기능을 매쉬업으로 제공받을 수 있으니까.
그러기 위해 이 서비스 업체가 취해야 할 전략은, 의도적으로 'A, F' 같은 형태의 매쉬업이 쉽게 생성될 수 있도록 유도하는 것이다. 결국 자신이 만들기는 싫지만(비용등의 문제로 인해), 타인이 쉽게 만들 수 있도록 하는 것. 따라서 바람직한 형태의 매쉬업으로 유도하기 위해 API등의 오픈 수위나 레벨을 조절할 필요가 있을 것이다.
롱테일과 매쉬업은 지극히 자연스럽게 결합된다. (아마존처럼 'A~J'까지 모든 것을 다 아우르지 못한다면.)
2007년 3월 5일 월요일
What the hell is the USER?
도대체 "User"란 누구를 말하는 것일까?
1. 싸이월드 미니홈피의 "User"는 "미니홈피의 소유자"를 말하는 것일까? 아니면 "미니홈피의 방문자"를 말하는 것일까?
2. 이명박(혹은 박근혜) "UCC" 동영상을 만드는 이는 "user"인가?
3. 올블로그의 User는, 블로그 피드를 등록한 사람을 가리키는 것일까? 아니면 올블로그를 방문해서 링크를 클릭하는 사람을 가리키는 것일까? 아니면 올블에 로그인해서 추천을 날려주는 사람일까?
4. 우리 기획자가 말하는 "User"는 도대체 누구일까? 혹시 기획자의 또다른 분신?
5. "User들은 그런 걸 안좋아하죠."라고 할 때 User는 또 누구일까?
자기 맘대로 편리하게 가져다 쓰는 "user", 도대체 "user"가 누구라고 콕 찝어 말할 수도 없으면서 왜 "user"는 만병통치약처럼 쓰일까?
바보상자라는 타이틀은 이제 TV가 양보할 시대가 왔나보다. 지극히 퍼스널미디어스러울 것 같은 웹은 실은 매스미디어의 규칙아래 놀아나고 있을 뿐.
"시청자 참여"가 늘어난다 해서 방송권력이 민중으로 이양되는 것은 아닌 것처럼, 웹 2.0의 수식어를 아무리 가져다 붙여도, 근본적으로 "정체불명의 Mass"를 대상으로 하는 매스미디어식 접근 방식의 웹서비스들은 그 한계를 벗어날 수 없다. (타게팅 운운의 헛다리짚는 소리 사양.)
MassWeb의 환상에서 벗어나기.
대중에서 다중으로, 그리고 다시 분중으로...
피드 구독하기:
글 (Atom)