Outsider's Dev Story

Mobile 카테고리를 추가하고서...

2010-03-14T03:24:26+09:00

블로그에 오늘 Mobile 카테고리를 추가했습니다. 새로운 카테고리를 추가한 것은 참으로 오랜만의 일이군요. ㅎ 아무래도 올해의 최대 이슈라고 할 수 있고 요즘 모든 IT회사들이 올해의 목표라고도 할 수 있죠. ㅎ 올해 하기로 맘먹은 것은 선택과 집중을 했음에도 아주 여러가지가 있습니다. Spring Framework, HTML5, CSS3, Java등등 여러가지가 있는데 그중의 하나로 모바일을 추가했습니다.

작년 11월말에 아이폰이 국내 출시된 이후로 많은 것이 급격하게 달라졌습니다. 사실 제가 아이폰에 기대하던 것도 아이폰 그 자체보다는 아이폰으로 인한 파급력이었는데 기대이상으로 효과를 내주고 있습니다. 정부는 여전히 삽질을 하고 있는듯한 느낌이기는 하지만 그래도 앞으로 여러가지가 달라지리라 기대하고 있습니다.

Image by allaboutgeorge via Flickr

어쨌든 개발외에도 나름 IT에 관심을 가지고 있고 아이폰이나 여러가지 전자기기들이 출시하는 것에 대해서 상당히 관심을 가지고 있었음에도 따로 준비하지 못했음에 대한 약간의 반성과 함께 올해는 사이드로 모바일을 좀 하기로 했습니다. 일단 안드로이드와 아이폰에 꽤 관심을 가지고 있었음에도 그냥 추이만 바라보고 고민했지 그외의 다른 생각까지는 하지 못했었습니다. 아이폰의 힘은 어떤 것인지, 장단점을 생각하고 안드로이드가 아이폰을 상대할 수 있을지 구글은 어떻게 나올지에 대해서 고민하고 이게 뜰것인가 아닌가 같은 고민만 했었습니다만 실제로 이 타이밍에 와서 보니 그 성공여부에 상관없이 아이폰이나 안드로이드는 여러가지 측면에서 기회가 될 수 있었음에도 그에 대한 준비는 전혀 하지 못했습니다. 순식간에 코앞까지 다가와버렸는데 전혀 눈치채지 못하고 있었던 것 같은 기분입니다.

그래서 좀 발을 디밀어 보기로 했습니다. 밖에서만 바라보고 있자니 정확히 알 수 없는 부분도 있고 남의 얘기만 듣고서는 정확하게 판단할 수 없는 것도 있어서 실제로 뛰어들어서 어떤 분위기고 어떤 상황인지 제대로 느껴보아야 할 듯 합니다.

Image by James Young Art via Flickr

그렇다고 업중을 모바일로 바꿀 것은 아니기 때문에 사이드로 공부삼아 좀 만져볼 생각이기 때문에 방향은 아이폰 보다는 안드로이드로 잡았습니다. 좀 알면 알수록 아이폰에 대항하기에는 안드로이드가 가야할 길이 아주 멀기는 하지만 여러가지 개발자로서의 오픈플랫폼을 더 지지하는 부분도 있고 아이폰은 사이드로 개발하기에는 매킨토시를 사야하는 등 여러가지 준비가 필요한 관계로 일단 진입장벽 자체는 낮은(그 뒤는 높다고 하더라도) 안드로이드를 좀 해보기로 했습니다. 팜프리도 좀 해볼 생각이 있긴 하지만 거기까지 여력이 될지는 모르겠습니다. 안드로이드만으로도 좀 벅찬 상황이라서요. ㅎ

전혀는 아니라고 할지라도 App 만들어서 대박의 꿈을 꾸고 있는 것은 아닙니다. 다만 올해는 모바일에 대한 준비를 어느정도는 해두어야 할 마지막 타이밍인듯 하고 여러가지로 재미는 있을듯 합니다. 현재로선 SKAF가 아닌 담에야 안드로이드로 앱으로 돈을 벌수도 없는 상황이죠. 한번 시작해놓으면 분위기 파악도 되고 그 뒤에도 여러가지 대응을 할 수 있을 듯 합니다.

정확히 어떤 얘기를 쓸 카테고리인지 정하지는 않았지만 앱이나 모바일 웹등에 대한 얘기들이 생각날때 마다 적게 될듯 하네요. 갈수록 해야할 것만 많아지는군요. ㅎ

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

KIVA에서 Sierra Leone에 사시는 그룹에 돈을 빌려드렸습니다.

2010-03-14T02:00:04+09:00

어느새 3번째 참여네요. Kiva 의 평균적인 Loan은 현재 5.3입니다.

이번에는 서아프리카에 위치한 Sierra Leone 에 사시는 Future Planners Group에 $25를 빌려드렸습니다. 이 그룹의 리더인 Issa Bangura씨는 오카다(Okada) 운전수이고 이 나라에서는 택시같은 용도로 사용되는 모터사이클인 것 같습니다.

이 사업을 3년째 하고 있고 와이프와 아이가 있다고 하네요. 이렇게 그룹으로 빌리는 것은 돈을 빌려진 돈이 각자에게 나누어지고 채무의 의무도 같이 지게 되는것 같습니다. 개인적으로 하는 것 보다는 서로 헤크할 수 있으니 좀더 책임감이 있다고 할 수 있을듯 하네요.

그리고 지난달 말에 Kiva Korea팀 에 참여를 하였습니다. Kiva에 참여하는 한국분들로 모여진 커뮤니티이고 현재 148분이 참여하고 계시고 평균 2.26개의 Loan을 가지고 계시네요. 저는 한국 평균은 넘었군요. ㅎㅎㅎ 생각보다는 많은 분들이 kiva에 참여하고 계시군요. 커뮤니티가 활발하지는 않지만 이런저런 질문을 하거나 공유를 하는데는 좋을듯 해서 참여를 했습니다.

ps) 팝펀딩은 국내분들이라서 왠지 kiva처럼 이렇게 올리기는 좀 부담되더군요. 좀더 상황보면서 고민해봐야겠습니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

팝펀딩(popfunding)을 참가해 보고 나서.....

2010-03-04T03:29:38+09:00

얼마전에 KIVA에 참여했던 것에 대해서 포스딩을 했었는데 이번에는 KIVA의 한국판이라고도 할 수 있는 팝펀딩(popfunding) 에 참여를 했습니다.

마이크로 파이낸스이란...
팝펀딩은 KIVA와 마찬가지로 마이크로 파이낸스(Microfinance) 2.0 서비스라고 할 수 있으며 팝펀딩은 그라민뱅크 의 크라우드소싱 버전이라고 할 수 있습니다. Kiva에 대해 얘기할때 그라민 뱅크에 대해서는 간략히 설명했고 여기서는 동영상으로 대체하겠습니다. 이 영상을 보시면 그라민뱅크의 시스템과 마인드에 대해서 충분히 이해가능하리라 생각됩니다.

무함마드 유누스는 이 그라민 뱅크를 통해서 마이크로 크레딧(소액대출)이라는 새로운 시스템(?)을 선보이게 되고 이것의 웹서비스판이 Kiva와 팝펀딩이라고 할 수 있습니다. 마이크로 파이낸싱의 큰 의미는 사회제도때문에 의욕은 있지만 가난을 벗어나지 못하는 사람들에게 가난의 고리를 끊을 수 있는 기회를 제공하는데 있다고 생각합니다. 어디나 가난한 사람들은 다 똑같겠지만 머나먼 해외의 사람들을 돕는 것도 가치있지만 국내의 그런 분들을 돕는 것도 큰 의미가 있다고 생각합니다. 내 주위의 이웃도 도울 수 있고 또 국내 웹서비스에도 힘을 실어준다는 생각에 팝펀딩에도 참여를 했습니다.

팝펀딩이란...
첫인상은 상당히 어렵다였습니다. Kiva는 영어라서 사실 대부분의 내용은 대충 이해하고 넘어간 부분도 있기는 하지만 Kiva에 대해서 팝펀딩은 상당히 어렵게 느껴집니다. 가이드를 상당히 정독해야 이해할 수 있는 시스템입니다. 크게 "투자하기"와 "학자금 후원"이 있습니다.(빌리는 부분에 대해서는 언급하지 않겠습니다.) 투자하기가 일반적인 소액대출의 형태인 사람들이 대출요청을 하고 사람들이 모여서 돈을 대출해주는 형태이고 학자금 대출은 이자율없이 학생들에게 학자금을 빌려주는 형태입니다.

그리고 그라민 뱅크와 Kiva와는 다르게 투자라는 개념을 상당히 전면에 내세우고 있습니다. 정확히 말하면 소액투자자들이 보여서 투자를 하고 대출해준 금액의 이자까지 상환받게 되어 투자자는 이익을 얻고 대출자들은 돈을 빌릴 수 있게 된다는 win-win형태입니다. 이러한 모델자체는 크게 나쁘지 않지만 Kiva나 그라민뱅크의 개념으로 접근한 저에게는 약간 당황스럽게 느껴졌고 어려운 사람들을 돕는다기 보다는 투자라는 개념은 너무 앞에 내세워서 오히려 거부감이나 조심스러움이 생기지 않는가 하는 생각이 들었습니다.

투자하기의 방식은 대출자가 빌리고자 하는 금액과 사연을 적어 경매에 등록하면 사람들이 자신이 받고자 하는 이율을 적어서 경매에 참여하게 됩니다. 최대 30%까지 이율을 적을 수 있고 전체금액이 다 채워지면 경매가 낙찰되게 되고 자신이 적은 이율로 대출금을 상환받게 되는 구조가 제가 이해한 구조입니다. 사실 크게 부족함없이 자란 입장에서 30%라는 것이 잘 감이 오지 않았고 돈을 굴리는 입장에서 30%의 이익을 낼 수 있다면 정말 대단한 이익이라고 할 수 있어서 "이걸 빌릴까?"하는 생각이 들었습니다만 많은 사연들을 차차 읽어보니 여러가지 이유에서 금융권에는 돈을 빌릴수 없는 처지이고 사금융은 5-60%정도의 이율이다보니 대출자 입장에서는 팝펀딩이 매력이 있는 것이었습니다.(자세한 내용은 모르지만 사연들을 보아하니 사소한 일에도 신용등급은 쉽게 하락하게 되고 사금융에 한번 손을 대면 금융권에서는 돈을 빌려주지 않기 때문에 계속 사금융의 고리를 끊을 수 없게 되는것 같더군요.)

팝펀딩에 대한 인상
팝펀딩은 아직 가야할 길이 많게 느껴집니다. 일반적으로 국내 웹2.0 서비스가 겪고 있는 참여자 부족을 그대로 겪고 있습니다. 다른 웹서비스와 마찬가지로 아이템이 괜찮더라도 사용상의 불편함이 없으려면 일정수준이상의 인원수가 있어야 합니다. 예를 들어 배틀넷을 예로 든다면 사용자가 배틀넷에 들어가서 너무 많이 기다리지 않고도 게임을 할 수 있는 정도... 여기서는 대출자가 포기하지 않을 정도로 투자자가 참여해서 돈을 빌릴 수 있는 정도의 선순환이 이루어지는 사용자수가 갖추어져야 그 뒤에 성장할 수 있는 폭발력을 얻을 수 있습니다. 팝펀딩도 서비스모델은 상당히 괜찮지만 이것이 부족합니다.

한 2주정도 구경한 입장에서는 2-3일정도에 4-5건정도의 대출요청이 올라오는것 같고 한번에 4-50건 정도의 경매가 진행되고 있는데 그중에 한두건 정도만 성사되는 것 같습니다.(통계는 아니고 그냥 구경해봤을때 그렇다는 것입니다.) 이정도의 건수는 계속되는 선순환 구조가 어렵게 만듭니다. 그리고 사연이 꽤 괜찮아 보이는데도 저조한 경매는 저조하고 활발한 경매는 금액의 140%까지도 올라가 버립니다. 이런 점은 사연자체보다는 일정수준이상의 투자자가 참여하게 되자 더 안전하다고 느껴서 너도나도 참여하게 되고 저조한 경매에는 아직 투자자들이 눈치를 보고 있는 상황이라고 생각됩니다.

위에서도 언급했지만 투자의 의미가 너무 강하지 않나 생각됩니다. 투자라고 생각하니까 왠지 몸을 더 사리게 되고 이율에 집착하게 되는데다가(메인에서는 이익률을 순위로도 보여주고 있습니다.) 투자자의 이익을 지켜주기 위해서 대출자에게는 상당히 많은 서류를 요구하고 있고 그 서류의 증빙여부가 회원정보에 함께 표시가 되기 때문에 투자하는 입장에서는 자연히 이런 부분을 비교할 수밖에 없고 서류증빙이 부족하면 투자를 주저하게 되는게 아닌가 싶습니다. 투자를 사실 저같은 경우에는 기부와 비슷한 개념으로 kiva와 팝펀딩을 참여하고 있고 그냥 도와주고 싶을 뿐인데 경매가 성사되지 않아서 쉽지 않습니다. 이런 팝펀딩의 의도는 그라민뱅크와는 상당히 다르기 때문에 그라민뱅크의 크라우드소스 버전이라고 하기도 좀 어렵지 않은가하는 생각도 하게됩니다. 게시판등을 보아도 투자와 대손에 대해서 신경쓰는 내용들이 많이 보이는 것이 사실이고 대출자한테 돈을 빌려달라고 어필하는 것 보다는 오히려 다른 대출요청자들과 경쟁하는 느낌이 강하고 그중 몇몇에는 과도하게 투자자가 몰리는 것으로 보아 투자자는 어느정도 있어보이지만 어디에 돈을 빌려줄지를 계속 찾고 있는게 아닌가 싶습니다.

학자금 대출은 더 합니다. 학자금대출은 사실상 금액도 상당히 큰데다가 84개월정도의 무이자이기 때문에 이익을 보는 것도 아니며 사실 대형벤더의 서비스도 아닌데 84개월뒤에 몇만원을 기억했다가 받을 생각을 한다는 것은 쉽지 않아보이기 때문에 거의 대출보다는 기부나 마찬가지로 느껴집니다. 이런 점 때문인지 투자와 비교되어서 그런지 학자금 쪽에는 빌려주는 사람의 참여가 더 저조합니다. 어느정도는 젊은분들을 위해서 빌려주고 싶지만 짧은 기간동안 보았음에도 도저히 경매가 낙찰될 걸로 생각되지 않기에 참여하기도 꺼려지는 것이 사실입니다.

Image by SashaW via Flickr

이렇게 경매 낙찰율이 저조하니까 투자자에게도 상당히 피곤한 일이 되어버립니다. 해외의 잘 된 모델중의 하나인 Kiva와 절대적인 비교를 하는 것은 무리가 있지만 사실상 Kiva는 한달에 한두번 들어가서 빌려드릴분 찾고 빌려주면 끝인데 현재 팝펀딩의 상황은 빌려드릴 분 찾아서 경매에 참여하고 경매끝날때쯤 가서 다시 경매 결과를 확인하고 경매가 낙찰되지 않으면(대부분은 참가자부족으로 경매가 종료됩니다.) 또 다른 분을 찾아서 경매에 참여해야 하고 이게 계속 반복되어야 할듯 합니다.(아직 한번밖에 안해봐서....) 이는 수익을 위해서라고 생각한다면 할만한 수고일 수도 있겠지만 저처럼 용돈 약간 아껴서 어려운 분들 도와주겠다는 생각으로 참여한 입장에서는 너무 수고로운 일입니다.

어쨌든 서비스모델자체는 나쁘지 않기 때문에 이 글을 통해서 팝펀딩을 좀 알리려는 마음도 있습니다. 팝펀딩을 약간 써보면서 느낀 것은 30%의 이율에도 생각보다 돈을 빌리고자 하는 사람들이 꽤 있는 편이고 현재 50만원, 100만원이 현재 없어서 방을 빼줘야 한다거나 빠져나오지 못할 사금융에 발을 들여놓을 수 밖에 없는 등의 처지에 있는 사람들이 참 많다는 생각이었습니다. 그 절박한 상황에서 열심히 살아보겠다고(물론 그중에는 다른 마음을 가진 사람들도 당연히 있겠지만요.) 계속 경매를 올리는 분들을 생각하면 경매가 정상종료되기를 바라지만 아직은 투자자가 많이 부족해서 안타까울 뿐입니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

함수호출 방식에 따른 this의 바인딩에 대해서...

2010-02-24T03:19:34+09:00

더글라스 크락포드의 자바스크립트 핵심 가이드 를 공부하면서 Javascript에는 4가지 함수호출 패턴이 있다는 것을 알게 되었고 이 패턴에 따라서 함수내의 this의 값은 달라지게 됩니다. Javascript에서 this와 객체의 바인딩은 호출시에 일어납니다.

메서드 호출패턴
함수 호출패턴
생성자 호출패턴
apply 호출패턴

Javascript에서 this의 바인딩은 다룰때마가 헷갈리는 문제이므로 기본이 되는 내용을 공부한 김에 정리해 둡니다.

메서드 호출 패턴
여기서 메서드는 함수가 객체의 속성(멤버함수)로 저장되어 있는 경우에 이 함수를 메서드라고 부르고 메서드를 호출할때 this는 객체에 바인딩 됩니다.

var test = {
    x: 100,
    showX: function() {
        alert(this.x);
    }
}

test.showX();   // 100

함수 호출 패턴
함수가 객체의 속성이 아닌 경우입니다. 이렇게 호출했을때 this는 전역객체(window객체를 의미합니다.)에 바인딩됩니다.

var x = 100;
var test = function() {
    alert(this.x);
}

test();  // 100

더글라스 크록포드는 이런 특성이 자바스크립트라는 언어 설계상의 오류라고 지적합니다. 왜냐하면 내부함수를 호출했을때 this는 외부함수의 this변수에 바인딩되어야 하지만 그렇지 않고 전역객체로 바인딩 됩니다.


var x = 1;
var test = {
    x: 100,
    showX: function() {
        alert(this.x);
    },
    whatisX: function() {
        var show = function() {
            alert(this.x);
        }
        show();
    }
}

test.whatisX();   // 1

이 코드를 실행했을때 whatisX의 show()는 함수호출되었기 때문에 this.x가 test.x가 아닌 window.x가 되어서 100대신에 1이 찍히게 됩니다. test.x를 가르키게 하려면 this변수를 다른 변수에 할당해 놓고 사용하여야 합니다.

생성자 호출 패턴
여기서 생성자가 의미하는 것은 new를 써서 인스턴스를 만들어서 쓰는 함수를 의미합니다. 일반적인 함수는 new를 쓸수도 있고 안쓸수도 있지만 prototype으로 확장을 함으로써 new를 써서 사용하도록 하고 파스칼형태로 첫글자를 대문자로 써줌으로써 생성자함수라는 것을 나타내줍니다.

var Test = function(x) {
    this.temp = x
}

Test.prototype.getTemp = function() {
    alert(this.temp);
}

var t = new Test(100);
t.getTemp();  // 100

이렇게 사용하면 new로 만든 객체에 대해서 this가 바인딩 됩니다.

apply 호출 패턴
apply함수는 첫번째 파라미터가 this에 바인딩될 객체이고 두번째 파라미터에 배열로 함수에 넘겨줄 파라미터를 지정합니다. 첫번재 파라미터가 null이나 undefined이면 전역객체에 바인딩 됩니다.

var x = 1; 
var test = {
    x: 100,
    showX: function() {
        alert(this.x);
    }
}

test.showX.apply(null);   // 1

메서드 호출패턴에 사용했던 소스에 apply를 적용했습니다. 첫번째 파라미터로 null을 넘겨주었으므로 this가 전역객체에 바인딩되어서 100이 아닌 1이 찍힙니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

[Book] 손에 잡히는 정규표현식

2010-02-24T01:44:04+09:00

손에 잡히는 정규표현식

손에 잡히는 정규표현식 -
벤 포터 지음, 김경수 옮김/인사이트

개발을 할 때 정규표현식(Regular Expression)의 유용함은 따로 설명하지 않아도 충분할 것 같습니다. 간단한 것은 그냥도 처리가 가능하지만 조금만 복잡해지면 정규표현식의 강력함이 드러나게 되고 나중에는 정규식만 잘 써도 왠만한 텍스트처리는 자유자재로 다룰 수 있습니다.

그럼에도 정규표현식은 따로 공부를 잘 안하게 되는 경향을 띄게 됩니다.(저만 그런지 모르겠지만요...) 개발자로써 공부해야 될 기술들이 산더미같은 마당에 정규표현식에 많은 투자를 잘 안하게 되고 간단한 학습후에는 소위 구글링으로 필요한 정규표현식의 상당수는 얻어낼 수 있기 때문에 한번 공부해야지 하면서도 잘 안되게 되는 것 중 하나입니다.

그런 면에서 이 "손에 잡히는 정규표현식" 은 딱 적당한 책입니다. 국내에는 정규표현식에 대한 책이 이책 외에 "정규표현식 완전 해부와 실습" 이라는 책이 있습니다만 이 책은 600페이지나 되기 때문에 정규표현식의 도사가 될것도 아닌데 학습하기에 좀 부담스러운 면이 있는데 "손에 잡히는 정규표현식" 은150여 페이지 정도로 " Regular Expressions in 10 minutes"라는 제목처럼 부담없는 책입니다. 제목처럼 10분안에 공부할 수는 없겠지만 좀 집중해서 보면 몇시간 정도면 다 볼만한 분량의 책입니다.

그럼에도 내용이 가볍지 않고 문자 찾기부터 시작해서 메타문자 사용하기, 반복찾기, 위치찾기, 하위표현식등 아주 기초적인 내용부터해서 일일이 예제를 보여주면서 설명하고 있으며 가끔 정규표현식을 쓰면서도 전혀 몰랐던 전방/후방 탐색이라든지 조건달기같은 고급까지 모두 설명해 주고 있습니다. 이 책에 나온대로 정규표현식에는 정답이 없고 문법을 알았고 설명이 명확해서 각 기능을 이해하는데 어렵지 않기 때문에 그 이상으로는 각자 연습하면서 익히면 충분할 것으로 보입니다.

부록으로 대표적인 정규식을 예시로 보여주고 있고(미국판이라 저희는 좀 필요없는 것들도 있지만요.) 언어별로의 정규표현식의 차이도 설명해 주고 있어서 정규표현식에 대해서 공부는 하고 싶지만 많은 노력을 들이는 것은 좀 부담스러운 사람들에게 딱 적당한 책인듯 합니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #2

2010-02-23T02:10:57+09:00

이 포스팅은 자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #1에서 이어진 포스팅입니다.

앱스토어 효과 - 유주완(블로그 )
World of devlopers의 시대가 왔습니다.
개발은 초등학생때부터 했으며 2009년 10월에 아이폰 출시가 가시화되면서 맥을 구입해서 개발을 시작했습니다. 언론에서는 엄청난 고민 끝에 나온 아이디어인 것처럼 나왔지만 실제로는 5분정도도 안걸렸다고 합니다. 그냥 밤에 누가 막차끝났다고 해서 1시간여의 거리를 걸어가던 중에 막차가 지나가버리는 경험도 있고 해서 누구나 할수 있는 쉬운생각으로 만들기 시작했다고 합니다. 10월 20일 서울버스 베타테스터를 모집해서 진행하고 11월 15일에 업로드를 시작했답니다. 인터페이스 빌더가 있었기 때문에 쉽게 개발을 하였다고 합니다. 11월 21일 사용하다가 초선검색의 부재를 인식하게 되고 22일날 kontacts를 만들어서 업로드를 합니다.

배운 점과 느낀 점은 혼자하기에는 다소 벅차고 가장 많이 올때는 하루에 60개정도까지 매일이 오기 때문에 읽고 처리하는데만도 하루가 다 간다고 합니다. 아이폰과 아이팟 터치라는 2개의 기기의 차이점이 있기 때문에 QA의 중요성을 느꼈으면 UX의 중요성도 깨닫게 되었답니다.

서울버스를 공개하고 경기도에서 무단 사용에 대한 연락이 와서 겁먹고 앱을 내렸으나 아버지께서 왜 내리냐고 하셔서 다시 올렸는데 실제로 내려간 시간은 30분 정도였고 그 뒤로는 다 아시는대로 경기도권에서 버스정보가 차단되면서 여론을 타게 되었습니다. 관련해서 국회토론회도 불려갔다 왔다더군요.

그 뒤에는 Q&A시간도 진행되었는데 오브벡티브C를 공부하면서 Seoul Bus를 개발하는데 한달정도가 걸렸답니다. 그 이전에 대부분의 언어는 거의 모두 사용해 보았기 때문에 시간이 그리 오래걸리지 않았으며 UX는 따로 연구하거나 하지는 않고 아이폰에 기본적으로 들어있는 어플들을 보면서 어떤식의 UX를 가지고 있는지를 보면서 만들었지 따로 UX를 기획하거나 하지는 않았답니다.

아이폰 앱인 "Seoul Bus"로 일약 스타로 떠오른 유주완님의 세션입니다. 어도비에서 특별세션을 준비하면서 어떤 분을 초청할까 고민하면서 여러군데에 물어보니 유주완님의 얘기를 듣고 싶다는 얘기가 가장 많아서 초청했다고 합니다. 대단하시더군요 어렸을때부터 개발을 해서 개발습득 능력은 확실히 뛰어나신것 같고(나이에 상관없이 이런점이 개발의 흥미로운 점이지요. ㅎ) 나이답지 않게(얼굴얘기아니고요 ㅎㅎ) 그 많은 사람들 앞에서 떨지않고 발표를 정말 잘하시더군요. 여러가지고 자극도 많이 받고 요즘 이슈되고 있는 주제중의 하나이기도 하기 때문에 상당히 흥미롭게 들었습니다.

뒷풀이도 같이 가서 전화번호도 땄(?)내요. ㅎㅎㅎ

아이폰에서 잘 보이는 모바일 웹 페이지 만들기 - OKJSP 허광남(블로그 )
모바일 브라우저에 대해서는 아픈 기억들이 있습니다. 핸드폰에 있던 Show, June같은 버튼들은 돈이 많이 나가는 버튼이라는 이미지였습니다. 과거 모바일 유저가 400만 정도 된다는 얘기가 있었는데 그중에서 200만은 실수로 눌러서 들어간 유저라는 얘기가 있습니다. 이제 패킷요금은 현실화 되었습니다. 계산해보니 08년도에 1메가에 921원정도, 1기가의 94만 3천원정도였지만 2010년에는 1기가의 3만원 정도입니다.

모바일에는 현재 국내에 4가지 플랫폼이 있다고 할 수 있습니다.

아이폰/아이팟 터치
안드로이드
윈도우 모바일
모바일웹

최근에 알게된 PhoneGap 도 있지만 여기서는 iUI (iPhone User Interface Framework)를 보겠습니다. 각자의 습득정도에 따라 차이가 있겠지만 아주 간단한 주소록을 앱으로는 2일이 걸린 것은 모바일앱으로는 1시간 정도밖에 걸리지 않았습니다. iui의 css와 javascript를 임포트하고 웹페이지 개발하듯이 개발하면 됩니다.

iUI는 매우 쉽고 또 웹페이지 제작시 사파리의 비표준 태그를 이용해서 키보드타이핑시 첫글자 자동대문자가 되지 않게 한다던지 input의 type에 tel, number, email등의 값을 넣어주면 자동으로 type에 맞는 키보드가 호출되도록 할 수 있습니다. 강의자료는 여기 에 있습니다.

오랜만에 뵌 kenu님은 머리가 많이 기르셨더군요. 최근 모바일웹에 관심을 좀 가지고 있는데 여건상 거의 찾아보지는 못하고 있었는데 아주 디테일한 내용은 아니고 대략적인 내용이었지만 몰랐던 부분도 꽤 있어서 좋았습니다. 더군다나 모두가 앱에만 관심가지고 있는 상황에 저는 거의 앱과 모바일웹을 같은 비중으로 바라보고 있기 때문에 이런 주제를 다루주신 것도 좋았습니다. 앱을 개발하시느라고 모바일웹에 대해서는 아직 디테일하게 만지고 계신것 같지는 않았는데 앱에 비해서 모바일웹의 장점이라든지 디테일한 노하우가 좀더 공유되었으면 하는 아쉬움이 약간 있기도 했습니다.

Spring Roo와 함께하는 쾌속 웹개발 - KSUG 정상혁(블로그 )
스프링 루 는 벤 알렉스(Ben Alex)가 만들었으며(어제 날짜로 1.0.2가 릴리즈 되었군요.) 자바를 위한 Text Based RAD(Rapid Application Development) 툴입니다. Roo는 호주사람들이 좋아하는 캥거루를 의미하기도 하며 Real Object Oriented의 첫글자를 딴 것이기도 합니다. Spring, Maven, JUnit등을 바탕으로 코드를 자동생성합니다. 생산성을 빠르게 해준다던지 이것을 사용하면 개발속도가 빨라진다는 건 이제 오랫동안 사기(?)를 당해서 이젠 Rapid라고 해도 시큰둥한 것도 사실입니다. 하지만 Roo는 의존성이 거의 없는 특징도 가지고 있습니다.

발표를 하시면서 동시에 콘솔창을 띄워서 Ruby on Rails가 처음 나왔을 때 15분만에 블로그만들기 처럼 간단한 주류판매페이지를 Roo로 개발하는 시연을 보여주셨습니다. 자바코딩을 하나도 안한테 콘솔에서 Roo의 명령어만을 이용해서 자바소스를 생성하고 디비를 연결해서 테이블까지 생성하고 UI까지 만들어내는 예제였는데 Roo를 어필하기에는 아주 적합한 예제였다고 생각합니다.

Roo를 사용할 때는 Hint와 Help만을 기억하면 됩니다. 명령어가 생각안날때는 tab을 2번 누르면 어떤 명령어가 있는지가 나오고 지금 어떤 단계를 실행해야 하는지에 대해서 아주 자세하게 나옵니다.(이거 아주 매력적이더군요.) ~는 탑레벨을 의미하고 셀레니움 테스트까지 자동화에 포함되어있어서 자동으로 파이어폭스가 실행되면서 UI테스트가 진행되는 시연도 보여주셨습니다. 이렇게 만든 소스를 마지막에 perform eclipse 명령어를 실행하면 이클립스 프로젝트로 개발하기 위한 관련 파일들을 자동으로 생성해 주었습니다.

똑똑한 Shell을 제공하고 있기 때문에 개발하기가 편하며 모든 명령수행은 Transactional하기 때문에 전체가 실행되거나 말거나 뿐입니다. 자동생성된 파일에서 개발자는 .java와 .xml파일만을 다루도록 하고 Roo는 AspectJ파일인 .aj만 다루기 때문에 개발자는 java, xml만 신경쓰면 됩니다. 쉘이 파일을 모니터링하고 있어서 소스를 수정하면 자동으로 aj에 반영해주고 한계가 약간 있을수 있는 UI자동생성은 옵션으로 제공되고 있습니다.

Entity소스상에 getter/setter가 전혀 없으며 이는 Mixin으로 Roo가 자동삽입해 줍니다. 이렇게 뻔한 것은 개발자가 안해도 된다는 것이고 Assert로직도 Mixin으로 넣어줍니다. Shell에서 backup을 입력하면 자동으로 시간기록된 파일로 백업을 해주고 Roo Shell에서 입력한 명령어가 자동으로 Log파일에 남게되고 이 파일을 이용해서 다시 프로젝트를 생성시킬 수 있습니다.

Spring Roo는 Full Stack으로 모든 레이어의 기술을 다 제공하며 Seam 이나 Ruby on Rails 처럼 강한 주장을 가지고 있는 프레임웍이며 베스트 프렉티스를 컨벤션으로 삼아서 CoC를 지향합니다. DAO를 버리고 Entity와 Controller의 단순한 2단구조이며 엑티브 레코드 패턴도 적용하였습니다. ORM에 대해서 성능에 대한 걱정들이 있지만 현재 생성성이라는 말이 들어가는 많은 곳에서 ORM이 적용되고 있으며 여러가지 기술로 성능에 대한 걱정은 하지 않아도 됩니다.

최근에 많은 인기를 얻고 있는 Dynamic typing언어 진영의 발전에 대하 Java진영의 대답으로 볼 수 있습니다.

발표자료는 여기에 있습니다.

이번 세미나에서 본 내용중 가장 인상적이 세션이었습니다. Spring Roo에 대해서 들은 적은 있었지만 정상혁님 말씀대로 RAD에 대해서 크게 매력을 느껴지지 않을만큼 무뎌지기도 했고 그래서 큰 관심까지는 안가지고 있었는데(난 기초를 더 다져야돼 하는 생각도 있었고요.) 작년 후반기 쯤에 0.9얘기를 들었던 것 같은데 그사이에 Spring Roo가 이렇게 그럴듯한 도구로 발전했는지 전혀 몰랐습니다.

제가 가장 매력적으로 느낀 것은 대부분의 RAD들은(경혐은 별로 없지만 그냥 인상으로만...) 속도의 향상을 위해서 많은 것을 따라야 하는 부분이 있기에 당연히 감수해야하는 제한적 부분도 있는데 Roo는 자동화할 부분을 자동화하는 것과 함께 개발자가 개발할 수 있는 것들은 개발자가 할 수 있게 내어준 것 같은 느낌입니다. 세세한 것은 만져봐야 알겠지만 Roo의 자동화를 잘 활용하면 Java개발을 상당히 편리하게 할 수 있을것 같은 생각이 들었습니다. arawn도 요즘 Roo에 빠져서 조만간 Roo공부를 좀 해야겠군요.(전 Spring도 잘 모르는데요 ㅠ..ㅠ)

신청은 했지만 많은 기대감을 가지고 갔던 세미나는 아니었지만 아주 많은 것을 얻어올 수 있었던 세미나였습니다. 너무 테크니컬하지도 않으면서 너무 추상적이지도 않은 아주 적절한 세션들로 구성되어 있었던것 같습니다. 이날은 뒷풀이도 5시간가까이 진행되면서 많은 생각도 하게 된 날이었습니다.

뒷풀이에 정말 많은 얘기들이 오갔지만 가장 맘에 남는 말은 "개발자가 너무 개발자끼리만 어울리는 것은 좋지 않은것 같다. 개발외에 많은 것을 봐야한다."는 것이었습니다. 개인적으로 노력도 하고 있고 적극 동감은 하고 있지만 개발쪽은 공부해야할께 너무나도 많다는 말이지요 ㅠ..ㅠ

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #1

2010-02-23T01:58:38+09:00

Adobe에서 진행한 "자바 개발자를 위한 ‘共感(공감)’을 찾아서"세미나 에 갔다가 왔습니다. 세미나 주제들이 괜찮아 보여서 바로 신청하기는 했었지만 약간은 의외의 컨셉의 세미나였습니다. 이번행사는 OKJSP , JBoss User Group , KSUG 가 공동주최하고 Adobe 에서 후원하였는데 처음 세미나 공지를 보았을때 "왜? 어도비가 자바세미나를?"이라는 생각이 들더군요. BlazeDS 때문인가 싶기도 했는데 딱히 그런 언급은 없었습니다. 머 의도야 어쨌든 이렇게 좋은 세미나를 무료로 진행해 주니 감사한 마음에 갔다가 왔습니다.

자바와 Flex의 만남 - Adobe Community Champion 엄진영(블로그 )
부재로는 "스프링과 연동한 BlazeDS 활용"이라는 이름이 붙어있었습니다만 실제로는 Blaze에 대한 언급은 거의 없었습니다. 개발의 기술발전의 히스토리들(주로는 엄진영님이 접하게 된 시점위주로)을 설명하면서 RIA가 플래시가 왜 필요한가에 내용이었습니다.

Flex는 이제 Flash라는 이름으로 통일이 되고 있습니다. 그동안은 Flex라는 개념의 혼동때문에 Flash와 Flex의구분을 고객들에게 설명하기 위해서 어려움들이 있었지만 이젠 모두 Flash로 통일되고 있고 Flex builder도 Flash Builder 4 로 변경이 되었습니다. 서버사이드는 보통 자바가 많이 쓰이고 기술과 트랜드는 계속 바뀌고 있습니다. 과거 프로그램을 자주 변경해야 되는 상황이 생기면서 그동안 사용하던 C언어보다는 스크립트 언어를 선호하게 되었지만 곧 만들어야 하는 프로그램의 크기가 커지면서 스크립트 언어로써의 한계에 부딪히게 됩니다. 스펙을 정해놓고 사용하게 되는 엔터프라이즈로 넘어가게 되었는데 실제 개발은 서버보다는 UI를 많드는데 훨씬 많은 시간이 소비되게 되었습니다.

그래서 프로세스의 혁신이 필요해지게 됩니다. 프로세스의 혁신이란 것은 야근등으로 개발자의 능력치를 최대한 끌어냈으나(엄진영님은 "이미 쪽쪽 빨아서"라고 표현을ㅎㅎ) 더이상 끌어낼수 없을때 필요해 지는 것입니다. 초보개발자도(싸니까) 만들수 없을까? 하는 고민을 하면서 프레임워크로 초점이 넘어가고 그후에는 퍼시스턴스에 관심을 가지게 됩니다. 2007년부터 UI에 대한 고민을 시작하게 되고 그전에는 브라우저전쟁에서 승리한 IE에 맞춰서 개발하다가 브라우져마다 약간씩 다르기 때문에 다른 브라우저에 맞추는 추가적인 작업을 하게 됩니다. 국내시장에서는 깔끔하게 IE외의 브라우져는 포기해버렸습니다.

이 상황에 Ajax도 등장하여 서버에 직접 접근하게 되고 엔터프라이즈급 UI를 Javascript만으로 하는 것이 개발자에게 너무 힘든 일이 되어버립니다. 그래서 Needs에 따라 쓰는 방식은 그대로 유지하면서 Flash를 위한 Flex가 등장하게 됩니다.

RIA의 장점은 플랫폼 독립적이고(자바도 목적은 그랬지만 현실적으로 그러지 못했습니다.) 기존 기술과 유사하여 배우기가 용이하면서 대규모 시스템 개발이 가능하다는 것이었습니다. 그리고 가장 중요한 것은 UI부분이 서버와 투명하게 분리가 가능하게 된 것이었습니다. Ajax덕분에 클라이언트가 서버에 직접 접속하게 되면서 서버에 종속적으로 묶여버렸습니다. 플래시앱(.swf)는 서버와 HTTP 원격객체호출을 할수 있고 HTTP 서비스, 메시징 서비스, 웹서비스를 할수 있으며 Ajax에 비해 binary 데이터를 주고 받을 수 있다는 큰 장점도 있습니다.

히스토리야 어느정도 알고 있는 내용이니 공감은 하고 있었지만 Flash Platform에 대한 당위성에 대한 공감은 좀 약하지 않았나 싶습니다. 여러 연구들과 프레임워크들의 등장으로 인하여 UI가 서버에 종속된다는 것은 공감이 잘 안되기도 했고 (기술적이든 사용상의 문제이든 간에)실제 플래시를 사용하는데에 대한 trade off가 존재하는 것은 사실이라고 생각하고 있습니다. Flash가 등장한 이래 가장 큰 위기감을 최근 느끼고 있다고 생각하는데 Flash가 통짜로 올라가면 화려하긴 진짜 화려하긴 하지만 무겁기도 하고 그렇게 화려할 필요가 있는가에 대한 고민도 하게 되죠.

Apache Hadoop으로 구현하는 상품추천서비스 - JBoss User Group 김병곤
추천검색은 은근히 여기저기 많이 쓰이고 있습니다. 메론, Amazon, 네이버 인물 검색등 알게 모르게 추천검색이 다 적용되어 있습니다. 실제로 추천검색을 적용해 보면 30%정도가 구입을 하는데 이는 엄청난 적중률입니다. 추천시스템을 구현하는 방법에는 사용자로부터 얻은 기호정보를 토대로 예측하는 협업필터링(Collaborating Filtering), 상품간의 연관성을 분석하여 다른 사용자에게 구매하지 않은 상품을 추천하는 연관규칙(Association Rule), 비슷한 대상들끼리 묶은 군집을 이용하는 클러스터링(Clustering)등이 있습니다.

웹2.0의 많은 서비스들이 추천시스템을 사용하고 있고 우리가 하는 모든 행동은 로그가 남고 있고 우리는 엄청난 데이터 속에서 살고 있으며 이 엄청난 데이터는 Hadoop 이 아니면 다룰 수가 없습니다. 데이터가 너무 엄청나기 때문에 데이터베이스로 다룰려면 데이터를 데이터베이스롤 올리는데 시간이 다 가버릴 정도입니다.

패러다임의 전환이 필요합니다.

로직이 데이터에 접근하지 말고 데이터가 있는 곳으로 로직을 옮겨라!

데이터가 쪼개지고 로직도 각 데이터로 분산된 다음에 합칩니다.

왜 데이터베이스가 적합하지 않은가 하면 대용량 파일은 Import하는 것도 어렵고 리소스소비가 심하여 온라인 작업과 배치작업을 분리해야 하는 문제가 있습니다. 그리고 비싼 장비와 SW비용이 필요합니다. 대신 대용량에 Apache Hadoop가 적합한 이유는 로그정보가 수십Tera에 이를 정도로 매우 크고 I/O집중적이면서 CPU도 많이 사용하는 작업입니다. 또한 장비를 증가시킬수록 성능은 향상되고 Intel Core머신은 가격이 아주 쌉니다. 인텔컴퓨터 하나 사서 추가하면 용량이 늘어나기 때문에 개발자는 관리가 힘들어지더라도 운영자입장에서는 당연히 하둡을 선택하게 됩니다. 이런 것을 보면서 이제 데이터베이스는 사라지는 것이 아니냐고도 하는데 Hadoop은 데이터베이스를 대체할 기술이 아니라 공존할 기술입니다.

Hadoop은 "파일을 올리는 것"과 "처리하는 것" 딱 이 2가지가 전부입니다. 즉 File System(HDFS:Hadoop Distributed File System)과 프로그래밍모델(MapReduce)입니다. HDFS는 파일을 64M단위로 나누어 장비에 저장하는 방식이고 사용자에게는 하나의 파일로 보이지만 실제로는 나누어져 있습니다. MapReduce는 HDFS의 파일을 이용하여 처리하는 방법을 제공합니다.

나누어서 처리할 때의 가장 큰 문제는 합치는 것이고 대표적인 것이 소팅입니다. 맵과 리듀스의 개념을 이해하는 것이 코딩보다도 더 중요합니다. Hadoop은 무조건 Key - Value의 데이터 구조 이 한가지 밖에 없습니다. 이 Key - Value로 된 데이터들이 합쳐지면서 같은 Key의 Value는 배열로 묶어줍니다.

연관 규칙(Association Rule)의 예로 간단한 마켓의 상품으로 추천시스템을 적용하는 예를 보여주셨습니다. 연관규칙에는 트랜잭션, 지지도, 신뢰도, 향상도가 있습니다.(이건 좀 통계적인 개념) 몇개의 상품별로 각 값들을 계산하고 이를 Hadoop으로 어떻게 Map과 Reduce가 진행되는 지에 대한 보여주었습니다. 추천시스템의 상품조합은 많으질수록 성능이 급격히 저하되므로 보통 2개의 조합만 사용하며 이 예에서는 맵과 리듀스를 단 2번만 실행하였는데 Hadoop에 대한 개념은 다 들어가 있으면서 한눈에 이해될 정도의 간단한 예제였습니다.

그럼 Hadoop는 언제 써야 하는가 하면 통계에 아주 좋습니다. 또한 데이터에서 필요없는 부분을 제거하는 ETL(Extract, Transform, Load)이나 데이터 마이닝, 로그파일분석, 인공지능에 적용하기가 좋습니다. 하지만 Hadoop은 무식한 배치성 작업이 아주 강하고 인터렉티브하지 않기 때문에 최종적으로는 RDBMS가 필요합니다. Hadoop으로 추출된 최종데이터만 RDBMS로 올리면 됩니다. 이전에는 이것을 디비가 했지만 이제는 개발자가 해야하는 시대가 되었습니다.

처음에 시작할때 초등학생도 이해할 수 있는 수준이라고 말씀하셨는데 사실 Hadoop은 개념이 약간 어려워서 그닥 믿지 않았는데 진짜 여태들은 설명중 최고로 명쾌한 설명이었습니다. 어떻게 하둡을 이렇게 간결하게 설명할 수 있을까 하는 생각이 들 정도였습니다. Hadoop에 대해서 급 관심이 갔으며 막상하면 여러가지 어려움이 있겠지만 오히려 너무 쉽게 설명을 해주셔서 해보면 금방 하겠는데 하는 착각(?)이 들 정도였습니다. ㅎㅎㅎ Hadoop을 어느정도 이해한 것만으로도 아주 큰 수확중의 하나라고 할 수 있겠네요.

글이 길어져서 자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #2로 이어집니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

2월달 KIVA 참여...

2010-02-21T02:11:19+09:00

Kiva에 두번째 참여를 했습니다.(지난번 KIVA 참여글 참조)

이번이 2번째 참여이군요. 이번 $25는 르완다에 살고 있는 Wellars Niyitegeka씨에게 빌려드렸습니다. Wellars Niyitegeka씨는 26살인데 3년째 과일과 야채를 팔고 있다고 합니다. 아주 열심히 일하는 사람이며 르완다 국제공항에서 멀리 떨어지지 않은 콧에서 Kimironko 마켓에 위치하고 있으며 한명의 직원을 두고 잘 조직화되어 있다고 합니다. 이번에 빌리는 $900은 손님을 끌기 위해서 야채를 더 사기위해서 빌린다고 하는군요. 10개월 동안 갚는다고 하는데 장사가 잘 되기를 바랍니다. ㅎㅎㅎ

머 Kiva참여하는 것이 대단한 것은 아니고 이렇게 매번 블로그에 올릴만한 일이 아니라고 생각도 합니다만 Kiva라는 서비스가 괜찮아보이기도 하고 홍보(?)차원에서 할때마다 공유를 하려고 합니다. 좋은 일에 더 많은 사람들이 참여하면 좋은 거니까요.

팝펀딩도 참여해야되는데 시간이 여의치 않군요. ㅎㅎ

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Twitter4j로 트위터 사용하기 #2

2010-02-20T03:33:08+09:00

이 포스팅은 Twitter4j로 트위터 사용하기 #1에서 이어진 포스팅입니다.

Twitter4j사이트의 Code Example 에 간단한 예제가 나와있어서 참고하면 되지만 너무 심플한 예제라 큰 도움은 되지 않습니다. 차라리 JavaDoc 을 많이 보게 되더군요.

인증토큰 얻기
Twitter4J를 사용하려면 당연히 최신버전의 Twitter4J jar파일을 프로젝트에 추가하여 하고 해당 소스를 사용할때 당연히 import도 해야하지만 그런부분은 여기서는 생략하고 소스만 보겠습니다. ㅎ


final String CONSUMER_KEY = "발급받은 CONSUMER Key";
final String CONSUMER_SECRET = "발급받은 CONSUMER Secret 키";

Twitter twitter = new Twitter();
twitter.setOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);

RequestToken requestToken = null;
try {
   requestToken = twitter.getOAuthRequestToken();
} catch (TwitterException e) {
}
//store requestToken.getToken() & requestToken.getTokenSecret()
//Retirect to requestToken.getAuthorizationURL()

위 코드를 통해서 토큰을 얻을 수 있습니다. requestToken.getToken()과 requestToken.getTokenSecret()에서 스트링타입의 토큰을 트위터로부터 받아오게 되고 사용자가 트위터사이트에서 인증을 허락한 뒤에 다시 사용해야 하므로 세션등에 저장해 둡니다. requestToken.getAuthorizationURL()는 트위터 인증URL에 토큰을 파라미터로 넘겨주는 주소로 다음과 같은 형태입니다.

http://twitter.com/oauth/authorize?oauth_token=인증토큰

위의 URL을 이용해서 유저를 리다이렉트 시키면 아래와 같은 화면이 나오게 됩니다.

제가 만들때는 구조상 아이프레임내에서 처리해야 했기 때문에 위 페이지를 아이프레임에서 띄웠습니다만 저 페이지에는 (window.top !== window.self)와 같이 페이지가 프레임에서 띄워졌는지를 검사하는 코드가 있고 프레임일 경우는 전체페이지에 띄우도록 수정해 버립니다. 이부분은 꼼수를 쓰면 막을수 있을지도 모르겠지만 프레임에서 띄우면 사용자가 URL을 볼수가 없기 때문에 트위터와 동일한 모양의 페이지를 만들어 놓고 아이디와 패스워드를 가로챌 수 있는 보안상의 문제가 있기 때문에 굳이 프레임에서 띄우지 않고 새창에서 인증이 진행되도록 하였습니다. OAuth도 인증과정은 유저에게 맡기기 때문에 URL을 사용자에게 표시해 주는 것은 중요합니다.

이제 사용자가 트위터사이트에서 해당 클라이언트의 접근을 허락할것인지 거절할 것인지를 선택합니다. 거절하게 되면 당연히 트위터의 인증을 하지못하게 되고 Allow를 하게되면 트위터가 사용자를 다시 Consumer사이트로 리다이렉트 시키게 됩니다.

http://리다이렉트URL?oauth_token=인증토큰

리다이렉트URL은 트위터 어플등록을 할 때 입력했던 URL을 이용해서 발급했던 인증토큰을 다시 파라미터로 붙혀서 보내주게 되고 파라미터명은 oauth_token입니다. 리다이렉트 페이지에서 해당 토큰을 다시 받아서 인증처리를 해주면 됩니다.

인증하기


Twitter twitter = new Twitter();
twitter.setOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);

String oauthToken = 파라미터로 받은 oauth_token
if (저장된token.equals(oauthToken)) {
   try {
       accessToken = twitter.getOAuthAccessToken(oauthToken, 저장된serectToken);
   } catch (TwitterException e) {
   }

   twitter.setOAuthAccessToken(accessToken);

    //store oauthToke & secretToken to DB
}

받아온 oauth_token값과 앞단계에서 발급받은 토큰의 값을 기뵤해서 값을 경우에 2개의 값(token, serect token)으로 accessToken을 만들어서 twitter객체가 OAuth권한을 얻도록 합니다. 여기까지 진행되면 twitter객체를 이용해서 해당 유저의 트위터를 이용할 수 있게 됩니다. 첫 토큰획득과 2번째 비교할때의 시간텀이 길어지게 되면 트위터에서 인증을 거부합니다.

일시적인 인증이 아니라면 Token과 Secret Token을 디비에 저장해 두면 다음에 사용자가 로그인 했을 경우에도 다시 트위터의 접근 권한을 자동으로 얻을 수 있습니다.


Twitter twitter = new Twitter();
twitter.setOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);

AccessToken accessToken = null;
accessToken = new AccessToken(저장된Token, 저장된SecretToken);
twitter.setOAuthAccessToken(accessToken);

위 코드처럼 2개의 토큰을 이용해서 twitter객체가 다시 인증된 상태로 만들면 됩니다. 이 twitter객체를 세션등에 저장해 놓고 계속 사용하면 됩니다. 그리고 트위터는 인증을 할때 유저의 스크린네임을 돌려주기 때문에 accessToken.getScreenName()를 이용하면 인증하면서 바로 스크린 네임을 얻을 수 있습니다.

트윗 가져오기


List<Status> statuses;

Paging page = new Paging();
page.count(20);
page.setPage(1);

try {
   statuses = twitter.getHomeTimeline(page);
} catch (TwitterException e) {
}

for (Status status : statuses) {
   //status.getId()
   //status.getUser().getName() 
   //status.getUser().getScreenName() 
   //status.getUser().getURL()
   //status.getText()
   //status.getCreatedAt()
   //status.getUser().getProfileImageURL()
   //status.getSource()
}

페이징이 필요할때는 Paging객체 를 만들어서 사용하면 되고 사용자의 타임라인은 getHomeTimeline 을 이용하여 얻습니다. 각 트윗에 대한 정보는 status객체 를 통해서 얻어낼수 있고 사용자 정보는 User객체 를 통해서 추가적으로 얻을 수 있습니다. 멘션이나 Direct Message는 getMentions, getDirectMessages를 통해서 가져올 수 있습니다.

트윗작성하기


Status status = null;
try {
   status = twitter.updateStatus(텍스트);
} catch (TwitterException e) {
}

트윗을 올리는 것은 아주 간단합니다. updateStatus메서드를 이용해서 텍스트를 전송하면 바로 트윗이 올라갑니다. Reply의 경우에는 twitter.updateStatus(텍스트, 리플라이할 트윗의 id); 와 같은 형태로 사용하면 됩니다.

이외에도 Twitter4j에서는 많은 기능을 제공하고 있고 거의 모든 트위터의 기능을 아주 쉽게 사용할 수 있게 잘 작성되어 있습니다. 저도 쓰는거만 만져보고 다 보지는 못했네요.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.

Twitter4j로 트위터 사용하기 #1

2010-02-20T03:18:33+09:00

마이크로 블로깅으로 큰 인기를 얻고 있는 트위터 는 거의 모든기능을 OpenAPI 로 제공하고 있고 최근엔 그나마 나아졌지만 트위터사이트에서는 별다른 UX적인 편리함을 주는 것이 없기 때문에 대부분의 유저들은 데스크탑 클라이언트 혹은 다른 웹사이트들을 이용해서 트위터를 더 많이 사용하고 있습니다. 이렇게 클라이언트를 만들려면 트위터에서 제공하는 OpenAPI를 이용해서 개발해야 하는데 Twitter는 API문서화 가 꽤 잘 되어 있는 편인데다가 다행히도 각 언어별로 상당수의 트위터 라이브러리들이 제공 되고 있기에 가져다가 편리하게 쓸 수 있습니다. 이번에 M31 프로젝트를 하면서 Java로 트위터 웹클라이언트를 만들어야 해서 라이브러리들을 둘러 보았지만 Twitter4J 를 선택했습니다.

현재 Java 트위터 라이브러리 로는 Twitter4J , java-twitter , jtwitter , Twitter Client 의 총 4가지를 존재하고 있습니다. 이 중에서 Twitter4J를 선택한 것은 문서화가 잘 되어 있고, 지속적으로 업데이트가 되고 있기 때문입니다.

OAuth 사용하기
트위터의 외부에서의 인증을 위해서 OAuth 를 사용하고 있는데 OAuth사이트에서는 OAuth를 다음과 같이 정의하고 있습니다.

An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. (데스크탑과 웹어플리케이션에서 간단하고 표준적인 방법으로 안전한 API 인증을 하도록 하는 공개 프로토콜입니다.)

OAuth는 Identity 2.0으로 넘어오면서 OpenID와 함께 생겨난 대표적인 인증 표준이라고 할 수 있습니다. API에서 제공되는 것 내에서만 사용했기에 직접 구현한 것은 아니라서 사용했다고 하기는 뭐하지만 어쨌든 OAuth를 사용한 것은 이번이 처음이었습니다. OpenID에 대해서는 이전에 올렸던 글을 참고하시면 되겠습니다.

인증메커니즘 자체도 약간 비슷한 느낌이긴 합니다만 OpenID는 OpenID Provider가 인증을 책임지고 Consumer에서는 아이디만 Provider측에 넘겨주면 Provider가 인증된 결과를 돌려주게 됩니다. Consumer는 인증에 대해서는 전혀 책임지지 않고 로그인인증을 Provider에 위임하게 됩니다. 반면에 OAuth는 좀더 진보된 인증방식이라고 할 수 있습니다.

어떤 기술을 이해하는데는 스펙을 보는 것이 가장 정확하고 좋기는 하지만 영어권이 아닌 저희로써는 영어문서는 울렁증이나서 오래보는것이 만만치 않고 또 개발하면서 봐야할 때는 더욱 그렇습니다. 저도 스펙은 보지 못하고 그냥 여기저기 찾아서 개발을 했습니다. OAuth는 2007년 12월에 OAuth Core 1.0 파이널 드래프트 스펙 이 나왔고 2009년 6월 24일 OAuth Core 1.0 Revision A 가 발표되었습니다. Beginner’s Guide to OAuth ? Part I: Overview 를 보면 대략적인 내용들이 나와있는데 OAuth에 대해 이해하는데 적당히 요약하겠습니다.

사용자들은 여러가지 서비스를 쓰고 있습니다. 사진은 플리커에 쓰고 동영상은 유투브에 쓰는 등 모든 것을 통합한 사이트가 더 최적화된 기능을 제공하지 못하기 때문에 여러가지 서비스를 나누어서 쓰고 있으며 사용자들은 이들을 함께 써서 더 새로운 것을 쓰고 싶어 합니다. 그렇게 하려면 서로간에 접근을 위해서 사용자간의 개인정보(아이디, 패스워드)를 공유해야하는데 이는 보안에 좋지 않기 때문에 보통은 아이디와 비밀번호로 혼합한 키를 사용하는데 대표적인 것이 OpenID입니다. 하지만 이 키는 공유하기에는 너무 강력하고 제한이 없습니다. 또한 이것은 한번 공유된 것을 취소할 수 없어 유일하게 취소할 수 있는 키변경은 특정사이트만 막지 못하고 전체사이트에 대한 접근을 모두 막아야 합니다. OAuth는 대신 토큰을 공유하고 각 토큰은 특정 리소스와 정의된 기간에 대한 특정사이트로의 접근 권한만을 받습니다.
(쓰고 보니 크게 도움될런지 잘 모르겠군요 ㅡ..ㅡ)

아래 이미지가 OAuth의 인증방식에 대해서 이해하기 좋게 잘 정리되어 있어서 퍼왔습니다.

Image via sitepen

Service가 인증정보를 가지고 있는 사이트(여기서는 Twitter)이고 User가 Service의 인증정보로 Consumer사이트를 이용하려는 것입니다.

사용자가 인증을 하려고 하면 Consumer가 Service에 토큰을 요청하고 Service가 토큰을 생성해서 돌려줍니다.
토큰을 받은 Consumer는 User를 서비스의 인증페이지로 요청토큰과 함께 리다이렉트시킵니다.
User는 Service사이트에서 인증을 하고 Service사이트는 User를 Consumer사이트로 다시 리다이렉트 시킵니다.
Consumer사이트는 엑세스토큰을 서비스에 요청하여 받으면 OAuth의 인증이 완료됩니다.
이후에는 Consumer가 이 토큰을 이용해서 리소스를 Service에 요청하여 받습니다.

Twitter는 기존의 Basic Auth를 더이상 사용하지 않기로 09년 12월에 발표하고 2010년 6월에 Basic Auth는 deprecation하기로 결정했습니다. 이전에는 사용해 본적이 없어서 그전에는 정확히 어떤 절차로 진행이 되었는지 모르지만 분위기로 보아서는 그 이전에는 서드파티서비스에서 아이디와 패스워드를 직접 입력해서 트위터로그인을 하는 것이 가능했었는데 2009년 4월에 트위터는 Sign in with Twitter 기능을 추가하면서 트위터의 인증이 서드파티 사이트로 넘어가는 일이 없도록 OAuth인증을 강화했습니다. 이젠 더이상 서드파티에 직접 트위터의 아이디와 패스워드를 입력하는 것을 권장하지 않고 있습니다. 이는 보안적인 측면에서도 아주 중요한 부분이라고 생각하고 있습니다. 트위터에는 여러가지 유명한 서드파티 서비스들이 많이 좋재하지만 사용자 입장에서는 서드파티의 신뢰성을 판단하기가 쉽지 않기 때문에 그럴듯하게 사이트하나 만들어 놓고 사용자의 아이디와 패스워드를 가로챌수 있다는 의미이기도 합니다. 저도 그렇게 한번 당한적이 있어서 패스워드를 변경해 버렸더랬죠. 너무 많은 트위터 서드파티 서비스가 그런식으로 이용하고 있었기에 아무런 생각도 없이 로그인을 해버렸었습니다. ㅠ..ㅠ

트위터 클라이언트 등록하기
OAuth의 방식을 어느정도 이해했으면 이제 클라이언트 구현전에 트위터 어플리케이션 등록페이지 에서 어플리케이션 등록을 해주어야 합니다. 어플리케이션 등록은 그냥 웹폼에서 간단하게 등록할 수 있습니다. 나중에 트위터 클라이언트에서 트윗을 작성했을 때 표시되는 클라이언트이름을 이곳에서 지정해 주게 되고 데스크탑 클라이언트인지 웹서비스인지를 선택해서 등록을 하면 Consumer key와 Consumer secret를 발급받을 수 있고 OAuth인증을 할때 사용합니다. 데스크탑 클라이언트는 만들어보지 않았지만 데스크탑클라이언트로 등록하면 PIN번호라는 것을 발급받게 되는 것 같습니다.

글이 길어져서 둘로 나눕니다. 이 포스팅은 Twitter4j로 트위터 사용하기 #2로 이어집니다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스 에 따라 이용하실 수 있습니다.