무거운 인터넷뱅킹

인터넷 뱅킹을 하기 위해 여러 헬퍼(?) 프로그램들이 깔리게 된다. 이렇게 지저분하게 된 것은 각 기능을 구현하는 제조회사들이 다르기 때문인데, 은행별로 회사들의 조합이 다르다보니, 은행 두개를 동시에 접속한다든지하면, 트레이는 굉장히 화려하게 된다.

  1. 왜, 은행들은 이들을 통합하여 하나의 설치본으로 만들지 않을까?
  2. 왜 이것들을 ActiveX로 설치할까? 그냥 수동 설치를 유도하면 되는 것 아닌가?
누구 이런 틈새 시장 안들어가나?
  1. 각 은행사들의 ActiveX를 하나로 모아서 하나의 통합본으로 만드는 중재 기구
  2. 한 번에 설치해주고, 문제 보고서를 취합하여 해결해주는 1차 콜센터.
아뭏든 지겹다! 인터넷뱅킹하러 느린PC에 있는 윈도우 쓰는것도 그렇고. 안쓸려다가 어쩌다 접속하면 그 깔아 대는 대여섯개 프로그램도 그렇고...
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 최호진

2008/10/28 16:45 2008/10/28 16:45
Response
No Trackback , a comment
RSS :
http://coolengineer.com/rss/response/607

오픈소셜 되돌아보기 2

간만에 글을 이어 올립니다. 뭔가 마구 쏟아 낼것 같이 번호를 "1"로 붙인것이 후회되었습니다. 요즘 제가 글을 쓸 수 있을 정도로 머리속이 잠잠하지 않은데도 말이죠.

오픈소셜 컨테이너가 제공하는 필드

이번에 얘기하고 싶은 것은, 과연 오픈 소셜 어플리케이션이 얼마나 많은 기능을 컨테이너에게 요구하느냐입니다. 스펙은 한 사람에 대해 가져 갈 수 있는 필드에 대해 실로 많은 것이 정의 되어 있습니다. 그 중 대부분은 OPTIONAL입니다.

어플리케이션을 내가 설치해서 사용하겠다고 하는 순간, 사실 그 어플리케이션은 컨테이너가 제공하는 모든 필드에 접근이 가능한 형태로 구현이 됩니다. 물론, 제한을 가할 수 있습니다만, 그렇게 하게 되면, 어플리케이션에 허용된 필드 리스트를 관리해야하는 부담이 생길 수 있게 됩니다.

왜 이렇게 많은 필드가 있고, 그 필드들에 어플리케이션이 접근할 수 있는 권한을 줘야할까요? 실제 OPTIONAL이 아닌 필드 만으로도 왠만한 어플리케이션은 구현이 됩니다.
  • 사용자 ID
  • 이름
  • 닉네임
  • 썸네일 주소
  • 친구 목록
그리고, OPTIONAL 중에서는
  • GENDER
  • DATE_OF_BIRTH - 생일
  • AGE
  • PROFILE_URL
정도를 활용할 수 있는 어플리케이션이 있을 수 있습니다. 게다가 조금더 제공가능하다면
  • ADDRESSES
  • SCHOOLS
  • STATUS - 한 줄 상태, 오늘의 한마디
이 정도를 구현하면 어플리케이션에서 도움이 될 정도가 되겠습니다.

어플리케이션의 구현 모습

너무 당연한 리뷰인가요? 현재 복잡한 어플리케이션으로 성장하면 다음과 같은 구현이 됩니다.
  • 자체 서버를 가지고 있습니다.
  • 그 서버에 추가적인 정보를 두어 iframe으로 보이는 것이 대부분입니다.
  • 이런 어플리케이션은 컨테이너에서 친구관계와 가장 기본적인 정보만으로 초기 설정이 됩니다.
  • 어플리케이션을 사용하면 할 수록, 어플리케이션 서버에 데이터가 쌓이는 형태로 동작합니다.
  • 어플리케이션이 제일 관심있는 것은 친구관계입니다.
간단한 어플리케이션은 컨테이너가 제공하는 정보로 구현이 됩니다. 이 어플리케이션은 간단한 데이터로 이루어지게 되며 복잡도가 떨어지지만 가볍고, 개인화된 특성을 지닐 수 있습니다. 예를 들어 그 사람의 시간대 정보만을 가지고 현재 시각을 보여주는 어플리케이션도 오픈소셜어플리케이션이라고 할 수 있습니다. 물론 친구관계를 이용하지는 않지만 오픈소셜 컨테이너가 제공하는 개인 정보로 구동되기 때문입니다.

예상되는 어플리케이션

느낌상 어플리케이션이 주로 인기를 끄는 것은 소셜게임이나 로맨스 요소가 들어간 것입니다. 또는 일상생활의 스케치가 계속 반영이 되는 중독성이 강한 요소들이 오래 발전하게 됩니다. 제가 생각하고 싶은 것은 미팅 주선 사이트나 성인 채팅 사이트까지도 오픈소셜에서 충분히 인기를 끌 수 있을 것이고, 아마 초창기 컨테이너 사업에서는 홍보상 자제해주었으면하는 바램도 있을지도 모르겠습니다만, 19세 이상 통제만 잘 이루어질 수 있다면, 예상할 수 없이 인기 어플리케이션이 될 수도 있습니다.

어플리케이션은 단지 위젯이 아닙니다. 하나의 사이트이며, 그 사이트의 홍보 대행을 컨테이너가 대신해주는 것입니다. 사이트 제작의 규모로 접근하지 않으면, 그다지 많이 깔리지 않을 것이고, 지속성이 없을 것입니다.

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 최호진

2008/10/28 14:32 2008/10/28 14:32
이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색
Response
No Trackback , 3 Comments
RSS :
http://coolengineer.com/rss/response/606

독설

보호된 글 입니다. 비밀번호를 입력하세요.

웹 앱스콘 2008 후기

오늘은 월요일 같은 느낌이네요. 어젠 1년 반만에 열린 웹앱스콘2008에 다녀왔습니다. 9:00AM 세션을 맡게되어 굉장히 일찍 출발하여 도착하였고, 다행이 이른 시간에도 도착하여 참석해주신 분들께 감사의 말씀을 드립니다.

이후에 들었던 백엔드쪽세션들도 모두 들을만하였는데, 제가 들은 3,4개 세션에서  병렬처리에 관련된 기술이 소개되어 얼마나 관심있게 진행되고 있는지를 느낄 수가 있었습니다. hadoop 이 많은 회사에서 테스트되고 있더군요. 저도 마침 관심있게 사내 스터디도 하던차에 듣게 되어 도움이 많이 되었습니다.

생각나는것들만 적어본다면:
  • "클라우드 컴퓨팅"에서는 NexR 한재선님께서 아마존의 웹 서비스의 시작이 얼마나 쉬운 일인가를 live로 보여주어 인상이 깊었고, 병렬처리를 위해 아마존 웹 서비스를 이용한 사례를 들어 주셨습니다.
  • "집단지성 프로그램"에서도 윤종완님이 병렬처리를 위한 알고리즘선택에 대한 포인트를 지적해주셨구요.
  • "시멘틱 웹과 Linked data"에서 김학래님의 온톨로지나 시멘틱 웹이 결국 웹의 표준 기술로부터 출발해야한다는 얘기도 잘 들었습니다.
이번 모임에서는 개인적으로 그간 안면이 있던 분들을 모두(?) 봤다 싶을 정도로 많은 분들과 얘기를 나눌 수 있어서 반가왔습니다.

kenu님의 상태(?) 인상 깊었습니다. 사진을 같이 못찍은 것이 아쉽군요. 머리는 아무나 미는게 아니잖아요?, 굉장한 마음 자세를 표현하는 것 같아 내심 부러웠습니다.

멀리 광주에서 올라오신 오픈소셜 프로바이더 및 적용 사례로 고민하시는 지혜님도 드디어 볼 수 있게 되어 고마웠고, 나중에라도 KTH의 한과장님과 잘 연결되시길 바랍니다.

에이콘 출판사부스에서 친절하게 맞아 주셨던 김희정 부사장님 감사드리고요... 나중에 또 즐겁게 뵙겠습니다. 제가 매상에 도움이 안되는 사람이었죠?

그리고, 오후에는 간만에 니들웍스 소속 개발자들이 모여 Textcube 2.0 얘기할 수 있는 시간이 있어서 좋았습니다.

죠엘이 하는 세션은 한 편의 쇼였는데, 말이 넘 빨라..!

그리고, 저녁식사로 스피커와 자봉들에게 제공되었던 해물 부페는 맛있었습니다. 그 시간동안 Textcube 개발진들과 zero board 개발자이신 고영수님, kldp 권순선님(둘은 NHN소속) 어떻게 보면, 국내 활성화가 많이 된 두 오픈소스의 개발자들이 친목을 다질 수 있는 시간이 되어 어제 시간들중 가장 재밌었던 것 같습니다.

앞으로 제로보드와 텍스트뷰브간의 교류가 종종 있었으면 좋겠다는 생각을 해봅니다.

시간 순서로 하루 요약 끝!

정진호님이 찍어주신 사진 감사합니다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 최호진

2008/10/24 10:40 2008/10/24 10:40
이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색
Response
A trackback , 8 Comments
RSS :
http://coolengineer.com/rss/response/604

오픈소셜 되돌아보기 1

짧은 기간 경험했던 오픈 소셜 플랫폼에 대한 경험을 공유하고자 이렇게 정리하는 마음으로 글을 씁니다. 아직까지는 플랫폼이 많이 나오지 않은 상황에서, 어줍잖은 경험이나마 공유할 만한 가치가 있을 것이라 생각되어 정리해봅니다. 글은 두서가 없을 것이며, 생각나는대로 주제를 잡아 끄적이는 노트라고 생각하시면 됩니다.

캔버스 모드의 어플리케이션은 사용자의 데이터를 사용해야 한다


전에 기술 세미나를 했을 때에도 한 말입니다만, 어플리케이션의 프로필모드는 소유자(owner)의 데이터를 가지고 구동이되며, 캔버스모드는 사용자(viewer)의 데이터를 가지고 구동이 됩니다. 이것은 오픈소셜에서 정의하는 것은 아니고, 일반적으로 그런 방식으로 구현이 된다는 것을 의미합니다. 이것으로, idtail에서 초창기 논란이 많았습니다만, 운영하다보니 나온 결론이었고, 마지막 개편안에는심지어
어플리케이션을 캔버스(canvas) 모드로 전환할 때, 소유자(owner)가 크게 부각되지 않아야한다였습니다.

설치냐 가입이냐


이야기를 더 진행하기에 앞서 먼저 해결해야할 문제가 있습니다.

어플리케이션과 사용자의 접근성을 설치 방식으로 하느냐 아니면, (표현이 이상하지만) 가입하는 방식으로 하느냐는 문제가 그것인데요. 어플리케이션을 설치한다라는 방식으로 접근을 하게 되면, 캔버스 모드로 동작할 때도 소유자의 공간에서 동작한다는 느낌으로 구현하게 됩니다. 또, 가입하는 방식으로 접근한다면, 어플리케이션은 하나의 내부 사이트이고 내부 서브 메뉴 중 하나를 방문하여 뭔가를 사용한다는 개념으로 구현될 것입니다. 마치 까페같은 것이겠죠.

어플리케이션이 위젯이라는 이름을 가지고 있을 때, 우리는 흔히 설치했다는 느낌을 갖게합니다. 여기에서 모든 생각이 꼬이기 시작합니다.

캔버스 모드 어플리케이션은 어플리케이션 자체가  UI의 중심에 있어야한다.


설치 개념으로 사이트가 구현되어 있는데, 소유자(owner)의 얼굴이 버젓이 보이는 공간에서, 사용자(viewer)의 정보나 사용자의 친구들이 화려하게 펼쳐(?)진다고 생각하면, UI가 굉장히 어색하게 됩니다.
캔버스 모드의 근본적인 성격 때문에, 가장 활동적인 모습을 보여주는 상황은 사용자 중심으로 동작하게 되며, 이 경우에 소유자 정보는 어플리케이션이 어떤 방식으로 시작해야할지에 대한 힌트로 사용되고, 어플리케이션이 동작하는 UI를 방해할만한 요소들(소유자의 얼굴사진 등)은 모두 제거 되는 것이 좋습니다.
예를 들어 어떤 사람의 프로필에 설치된 미니 서재를 클릭하여 캔버스로 확대할 경우와 내 프로필에서 캔버스로 확대할 경우, 소유자의 정보가 다르게 되고, 이 때 시작 위치를 다르게 하여 미니서재를 구동할 수 있을 것입니다.

즉, 어플리케이션이 이렇게 구현이 되면, 소유한 어플리케이션이라는 느낌보다 방문하는 서브 메뉴라는 개념으로 구현이 됩니다.

위젯...

어플리케이션 혹은 위젯이라는 개념이 일반 사용자에게는 생소합니다. 블로거들이 위젯을 설치하여 사용하지만, 블로그 시스템에서 절대 다수는 방문자일뿐 블로거가 아닙니다. 그런 위젯을 방문자 모두가 적극적으로 사용하는 상황이 SNS에 도입이 되는데, 이 때 설치한다는 느낌은 UI 면에서 실패할 가능성이 많을 것이라고 결론 지어봅니다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 최호진

2008/10/10 10:46 2008/10/10 10:46
이올린 태그검색올블로그 태그검색티스토리 태그검색
Response
No Trackback , 3 Comments
RSS :
http://coolengineer.com/rss/response/603

Makefile.am Sample

Makefile.am 은 autotool 로 시작하는 프로젝트의 시작입니다. 간만에 하나 재미로 시작해 볼까하여, 끄적여 봅니다.
$ more Makefile.am
bin_PROGRAMS = filezarufs
filezarufs_SOURCES = filezaru.c
filezarufs_CFLAGS = -D_FILE_OFFSET_BITS=64
filezarufs_LDADD = -lfuse

check_PROGRAMS = test-protocol
test_protocol_SOURCES = test-protocol.c
test_protocol_LDADD = -lcunit
TESTS = test-protocol
그리고,
make check
지금의 의욕은 unittest framework 은 CUnit을 쓰는 것으로다가..

냐하..


크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 최호진

2008/10/08 14:09 2008/10/08 14:09
이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색, 이올린 태그검색올블로그 태그검색티스토리 태그검색
Response
No Trackback , No Comment
RSS :
http://coolengineer.com/rss/response/602


블로그 이미지

최호진의 글들입니다.

- 최호진

Archives

Authors

  1. 최호진

Calendar

«   2008/10   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
311653
Today:
32
Yesterday:
209