Egloos | Log-in
결론에 가보기
결론에 가보기
태그 : solr
2009/02/25   solr를 이용한 또다른 ^^ 검색서비스 오픈 [6]
2008/11/26   solr 와 함께 좌절중..
2008/05/29   오픈검색서버(Solr)의 통계자료 [3]
2008/03/27   검색이야기 with Solr #3 [1]
2008/01/28   검색이야기 with Solr - #2 활용
2007/10/24   [잡생각] 사건은 점점 미궁속으로~ [2]
2007/08/17   검색이야기 with Lucene, solr [9]
solr를 이용한 또다른 ^^ 검색서비스 오픈

solr와 함께 좌절중 이란 글이 작년 11월 이었으니 3개월후인 어제 무사히 오픈을 마무리 하였다.
참 힘들고 우여곡절도 많고 ^^ 이런것이 나름 노하우가 쌓인다고 하는것인가?

저번에 실패로 깨달은 것은 검색서버의 한계치가 있다는 것이었고
그 수치에 이미 회사의 서비스가 많이 근접해있다는 것이었다.

테스트할때는 1억건까지 데이터를 만들어서 조회테스트를 해보았었는데
조회만을 돌려서 성능을 측정하는것은 실서비스의 운영과 다르기에 의미가 없었다.
조회, 추가, 삭제, commit을 모두 합친 형태로 스트레스 테스트를 했어야만 정확한 수치를 알수 있었다.

solr의 위키에 있는 master/slave 구조도 마찬가지이다.
slave에 commit을 하는 순간 고통스러워하는 서버의 로그를 볼수 있을것이다

이런 저런 테스트를 해보니
이번 서비스의 데이터 구조에서는 서버당 1200만건 이상이 되면 서비스를 하기에 힘들것이라는 판단이다.
이미 1600만건이상으로 서비스하고 있는 서버도 있지만 두개가 유니크키의 사이즈가 다르다.

한쪽은 7자리 이하의 숫자이고 다른 한쪽은 최대 30자리의 숫자+영문조합인데
단순 이런 키사이즈의 차이로 성능이 30%정도 차이가 난다.

결국 4대의 서버를 이용해서 데이터를 분산하여서 2700만건의 검색서비스를 시작하였다.
3대로도 가능하지만 스토리지 구조와 맞추기 위해서 ^^ 조금더 안정적인 4대로 오픈하였다.


휴.... 그래도 한고비 넘겼다. ^^
by 제우스 | 2009/02/25 11:06 | 컴퓨터 | 트랙백 | 덧글(6)
solr 와 함께 좌절중..
어제가 오픈일이었다. 새로운 검색서비스가... 

solr 1.2로 1600만건정도를 잘 색인하고 검색서비스를 제공하고 있었다.
다른쪽에 추가적인 검색서비스가 필요하다고 해서 몇번의 회의를 하였었다.
이미 기존의 서비스를 같이 해본 사람들이었고 스펙도 크게 다르지 않아서 방심을 하였다 ㅠㅜ

사실 방심보다는 다른쪽으로 짜증이 조금 나 있었다.
같이 일하는 사람들이 너무나도 도움을 안주는 것이었다. 지금 잘 동작하지 않는 검색서버를 
교체해준다는 것이었는데.. 샘플데이터를 보고 싶다라고 하니 그냥 테이블 이름 알려주면서 보란다.

투덜투털 되면서 친한 DBA한테 가서 사정사정 해서 데이터를 요청하였는데..
점점 일이 커지기 시작한다. 데이터가 2600만건으로 기존 서비스보다 더 크다..  
윽.. 사이즈가 작은지 알고 편하게 될줄 알았는데.. 큰일이다.. 서버의 스트레스 테스트도 다시 해봐야 하네.

analyzer를 바꿀 예정이었는데.. 이것은 취소하고..(어짜피 게시판이니 효과는 별로일듯)
solr 1.3으로 색인을 시작하였다. solr 1.3의 색인속도가 조금 빨라진것이 체감상 느껴진다. 
한참 색인을 하였는데.. 왠지 데이터가 모자른다는 느낌이다..

확인해보니 유니크 키가 이상하다.. 한창 담당팀과 DBA와 논쟁이다. 중복이다 아니다. 
언제부터는 중복이고 중복이 아니다.. 왔다리 갔다리..  결국 db 필드 3개로 키를 만들었다. 
key의 사이즈가 커지니.. 색인속도와 검색속도가 현저하게 떨어진다.. 
거의 3배이상 커졌으니.. 그것도 일정한 자리수가 아니라 변동성의 폭이 크다.. 제길.. 

key를 조정하고 다시 색인을 완료하여서 오픈준비를 하고 있는데.. 그래도!! 데이터의 사이즈가 부족하다.
확인하여보니 solr1.3의 색인 xml 이 조금 바뀐거 같다.. solr1.2에서는 괜찮았는데.. 1.3에선 에러를 튕겨낸다.
물론 그 데이터가 한글이 아니고 유니코드로 변경하였을때 이상한 값들이긴 하였지만... 
2500만건중에서 1500만건뿐이 색인이 안되었다..  이상태로는 안될듯 하여서 solr1.3에서 1.2로 버전을 다운하기로 결정
부랴부랴 다시 색인을 하여서 간단한 테스트로 되는 것을 확인하고 오픈준비를 완료하였다.

오픈날 마지막 1일치 데이터를 색인하려고 하는데.. 윽.. 데이터의 건수가 1.2만건이다.
이것도 복병이었다.. 하루 증감분이 1.2만건이라.. 제길.. 초당 몇건이란 이야기인가.. 
휴.. 제대로 확인하지 않은 사실들이 너무나도 많다. ㅠㅜ
그놈이랑 신경전하느라고 제대로 못챙겼네.. 아띠.. ㅠㅜ

오픈을 하였다.
예상대로 색인요청건수가 너무나 많다.. 근데 색인의 피드백 타임이 너무 오래 걸린다.. 
검색결과의 시간도 너무 오래걸린다. 메모리를 최대한으로 했는데도.. 
GC overhead limit exceeded , Heap 메모리 부족 에러가 발생한다.. 제길
commit을 요청하면 서버가 먹통이 되어 버린다.. 쩝쩝.. 

결국 롤백결정 ㅜㅡ 

길슨.. 제대로 풀 테스트하지 않은것이 화근이다..
근데.. 참 오픈소스라는 것이 힘들다.. 이런 블랙박스의 형태이니 에러발생시 조절할수 있는 부분이 너무 작다
휴.. 어쩌겠냐.. 풀테스트 시나리오를 작성하고 있다... 다시 해봐야지..

원인이 무엇인지 어떻게 해결해야 하는것인지.
키의 사이즈가 문제인지, 데이터의 양이 문제인지, 색인과 삭제 요청의 빈도수에 대한 한계가 있는지..
solr의 서버한계가 이정도인지.. 결론이 나겠지 ^^

난 개발자인가? 테스터인가? 
by 제우스 | 2008/11/26 16:14 | 컴퓨터 | 트랙백 | 핑백(1) | 덧글(0)
오픈검색서버(Solr)의 통계자료
회사에 적용되어 있는 검색서버 Solr의 사양 및 통계적인 자료이다

CPU : 2.3G 듀얼
OS   : CentOS 64bit
memory : 8G
JDK  : 1.6_6
JVM option으로 5G의 memory 사용

총 검색데이터 : 약 1200만건
일평균 조회건수 : 25만건
일평균 색인데이터 :  1.2만건
색인자료용량 : 6G


































^^ 검색을 준비하면서 꼭 만들어보고 싶은 자료이었다.
오픈소스를 사용하는것은 좋은데 이것이 얼마만큼의 성능이 나오는지에 대한 자료는 정말로 없다.
특히나 검색과 같이 블랙박스의 형태인것은 더욱더 절실하다.

BMT등을 통한 스트레스 테스트를 하지만 이놈의 캐싱기능이 있어서 똑같은 단어 1개로
반복시키는 것은 의미가 없고 단어그룹을 만들어야 하는데..
그래도 실제 오픈보다는 정확도가 떨어지겠지 ^^

결과적으로 서버스펙이 좀 오버된것 같다. CPU의 점유율이 1%도 안된다.. 쩝.
이런 자료가 있었으면 좀더 낮은 스펙으로 결정하는것인데..
아쉽네.. 그래도 머 이정도면 괜찮으니깐 패스 ^^
by 제우스 | 2008/05/29 10:18 | 컴퓨터 | 트랙백 | 덧글(3)
검색이야기 with Solr #3
이번주 화요일(3월25일) 검색서비스의 확장이 있었다.

오픈소스의 검토를 작년 8월쯤부터 시작해서
성능 테스트, 장비테스트, prototype의 적용에서
지금의 본격적인 서비스 적용까지.. 벌써.. 이만큼이나 왔다.

개략적인 solr에 대한 이야기로  검색이야기 with Lucene, solr 를 포스팅하였고
prototype의 적용으로 알게된 내용으로 검색이야기 with Solr - #2 활용 를 포스팅하였다.

새 장비를 가져와서..
기존의 JDK5.0(1.5.0_6) 에서 JDK6.0(1.6.0_5)로 변경하였는데..
성능이 약 30%정도 좀더 좋아진것 같다..

JDK5.0에서 6.0의 성능이 20%정도 좋아졌다라는 얘기를 컨퍼런스에서
들었던 기억이 나는데.. 그것을 몸소 체험하게 되는 ^^ 기회이었다.

4개의 게임에 적용하였던 것을 이제 13개의 게임으로 늘렸고
200만건의 데이터가 1200만건으로 늘어났고
최대처리 건수가 초당 1~2개에서 5~6개로 증가하였다.

아직도 서버1대에서 색인과 검색을 모두 담당하는 방식을 쓰고 있지만..
서버의 처리능력에 최대치는 아직 한참 더 남은것 같은 생각이 든다.
테스트로는 거의 초당 200~300건까지 해본것 같은데.. 단순 조회만이어서
색인과 조회의 까다로운 조합으로는 좀더 낮아질것이 분명하지만.. 지금 한계치는 아닌듯하다.

이제.. 4월달에.. 마지막 게임하나에 더 적용하면..
처음에 목표하였던.. 검색개선은 달성을 하게  된다.
가장 트래픽이 높은 게임이지만.. 지금 상태로 보면.. 그렇게 큰 걱정은 없다..

데이터의 증가가.. 연 300만건정도이니깐.. 한번 더 체크해야 하는 시점인 2000만건까지는
3년정도 남았고.. 최대라고 생각하고 있는 5000만건까지는.. 아직 한참 남았다..

팀에서 오픈소스를 많이 다루지만..
지금처럼 효과에 대해서 절실히 느껴보는 것은 참 오랜만 인것같다..
이제는 ^^ 좀더 다양한 형태로 solr를 확장하는 것에 주력을 해봐야겠다 ^^

==================================================================================

제 solr에 관한 포스팅을 보시면 아시겠지만..
정말 강력하고도 쉽게 사용할수 있는 검색 solution입니다.
10~20만건정도의 작은 규모는 그냥 로컬의 PC로도 처리할수 있는 정도이지요.
문서를 보면 쉽게 적용을 할수 있고.. 조금 더 디테일한 부분에 대해서
제 메일로 문의를 주시면 최선을 다해서 ^^ 알려드립니다. 아는것은요 ^^
by 제우스 | 2008/03/27 16:22 | 컴퓨터 | 트랙백 | 덧글(1)
검색이야기 with Solr - #2 활용
작년 검색일을 시작하면서 첫번째 이야기를 쓴것 같은데
벌써 5개월정도가 흘렀네.. 와~ 시간 빠르네..
그때는 시작하면서 필요한 기본사항에 대해서 얘기를 하였었는데
이제 실제 적용도 해보고 나름 안정성을 위한 노력도 해서 꽤 안정성도 높아졌다.
2월달 전체적용도 앞두고 있고 얼마전에 추가로 붙인것때문에 요즘 검색 생각이
많이 나서 내용을 정리해본다.

1. 우리는 지금 어떻게 Solr를 쓰고 있나?

사람들이 생각하는 검색의 3단계중에서 데이터 수집, 색인, 검색 중에서
solr는 색인, 검색만을 담당해주는 놈이다. 따라서 지금 나의 상황처럼
게시판의 검색을 solr를 이용하는것은 정말로 적절한 케이스이다.

게시판의 검색? 나도 처음에는 별거 아니라고 생각을 하였다.
그까짓것 걍 DB의 like 검색붙이면 되지 않나? 라는 바보같은 생각을..
단순 게시판의 글의 개수보다 얼마나 많은 트래픽이 있는지도 체크포인트이다.

지금 많은 게시판중에서 몇개만 붙여놨다. 데이터는 200만건정도가 되고
색인요청이 많을때는 초당 1개정도, 적을때는 분당 10개정도
조회요청은 많을때는 초당 1~2개, 적을때는 분당 25개정도..

마지막 붙인 게시판이 데이터는 5만건정도뿐이지만 트래픽이 많아서
기존의 것보다 6배이상 늘어났지만 안정성은 더 좋아졌다
(방식을 바꾸긴 했지만 그 내용은 아래에서 .. ^^)

목표치가 현재 2000만건이고 최대 5000만건을 염두에 두고 있는데
서버구입도 하였으니.. 괜찮아질듯하다 ^^

2. Solr의 실적용에서 고려해야 할 사항 #1 - 메모리

처음 오픈하자마자 발생한 문제^^ 메모리 부족현상이다.
JVM의 옵션을 제대로 주지 못하였던 문제..
찾아보니깐 나름 JVM의 옵션이 아주 다양하고 많다..그래서 적절히 맞춰주니깐
우선 시작인 100만건정도는 쉽게 넘어갈수가 있었다.

덕분에 Out Of Memory 의 문제에 대해서 공부도 많이 하였고
메모리 구조에 대한 공부도 많이 하였다.
http://kr.bea.com/files/services/customer_support/best_tip/07_200409/07_1_02.pdf
http://wiki.javajigi.net/pages/viewpage.action?pageId=1969
http://hjbang.snut.ac.kr/data/java2005/JAVA06.ppt

하지만 32비트에서는 한계가 있었다. 그것은 JVM이 1G까지만 설정이 가능하다는 것이다.
적절한 개수까지는 테스트해보지 못하였지만 5000만건의 데이터를 만들어서
색인과 검색을 동시에 보내니 바로 Out Of Memory가 발생한다.

64비트에서는 4G까지 메모리 설정이 가능하다고 하지만 실제로 커멘드는 10G까지 먹힌다
그런데.. 총 메모리 6G짜리인데 10G라니..흠흠. 어째튼 5G로 설정하고
색인과 조회를 동시에 테스트하여보니 5000만건에서도 OK!!

그리고 가용할수 있는 메모리가 늘어남에 따라서 약 30%이상 성능 향상
(색인시간이 더 빨라짐)도 있기에 64비트가 적절한 것 같다.

3. Solr의 실적용에서 고려해야 할 사항 #2 - commit 주기

commit은 데이터를 추가(add)하고 실제 검색서버가 인식할수 있도록 반영해주는
process이다. 얼마전 추가 게시판을 늘리기전까진 실시간 반영이었다.
글을 쓰고 바로 반영을 하는..
하지만 이것이 얼마나 서버에 큰 부담을 주는지.. 방식을 변경하고 나서야 알게 되었다.

지금은 add 까지만 글을 쓸때 하고 commit은 5분마다 하는 방식으로 변경하였다.
위에서 얘기하였지만 트래픽은 6배이상 늘어났지만 안정성은 3~4배이상 더 좋아졌다.

글을 쓰고 자신이 쓴 글을 검색확인 할수 있는 최대시간 5분..   10배이상 좋아진 안성정과
충분히 바꿀만한 가치가 있는 것 같다.

4. Solr의 확장 아이디어

아직 실행해보지 않았지만 해볼만한 것들의 아이디어이다.
검색서버를 검색이외에 쓸수 있지 않을까?? 내가 속한곳이 게임회사라 ^^
게임쪽으로 생각을 해보면..

랭킹서버..  사용자의 점수를 색인하고 조회하는 방식이다.
검색 + 랭킹보여주기를 붙이면 될듯하고

자동매칭시스템..
게임을 원하는 사람들끼리 1:1, 2:2, 5:5로 팀을 이루에 매핑을 시켜 주는 시스템이다.
점수의 스샷을 떠넣고 자신의 그룹을 쉽게 찾고, 그룹끼리 매칭을 시켜주면 될듯하다.
자세한 방식은 흠흠.. 적용후에 알려드리도록 하죠 ^^

또 주저리주저리 많이 썼네.. 간략히 이미징화해서 써야 하는데..흠흠.
by 제우스 | 2008/01/28 14:57 | 컴퓨터 | 트랙백(1) | 핑백(1) | 덧글(0)
[잡생각] 사건은 점점 미궁속으로~
IT쪽에서 밥을 먹고 살면서 종종 시스템 이라는 놈이 단순한 기계가 아니라
살아있는게  아닐까 하는 생각을 하곤 한다.

어제 Solr를 이용해서 검색서비스를 확장해서 오픈을 하였다.
그전에는 5만건정도뿐이라서 부담도 안되었는데
셋팅도 조금 변경하고 검색도 강화하고 데이터도 100만건이상 ..
이제 검색이라는 단어를 쓸만한 수준으로의 확장이었다.

그래도 크게 걱정하지는 않았다. 1억건정도까지 벤츠마킹 해본적이 있어서
그렇게 문제가 되지 않을꺼라는 생각에 신경을 좀 덜 썼는데
오픈하지마자 문제가 속속 발생하고 있었다.

기본적으로 heap size가 부족해서 out of memory 가 발생하면서
Solr 내부에서의 Exception도 발생을 하였다.
CPU도 100%가까이 먹고 Memory도 80~90%를 왔다갔다 하면서
불안불안한 상태를 유지하고 있었다.

Master/Slave로 만들어진 구조를 Master 단독으로 바꾸고
이것저것 튜닝 포인트를 체크해가면서 변경하였는데 쉽게 잡히지 않았다.

단순한 변경으로 처리가 불가능하다는 것을 인지하고 
에러가 발생하지만 죽지 않는 Solr를 믿고 버티기로 결정하고
개발서버, slave 서버,  BMT를 위한 서버등 있는 서버 모두에서 stress 테스트를
다시 하기로 결정하고 준비를 하였다.

이것저것 옵션을 바꾸고, Master와 동일한 형태로 셋팅을 맞추고
Master의 10배, 20배이상의 스트레스 테스트를 주는데도 에러가 발생하지 않는다.
뿐만 아니라 Master의 서버에서도 해당 에러의 발생빈도가 줄어들더니
이제 거의 발생하지 않는다. 설정이나 기타 변경사항이 한개도 없는데...

사람으로 표현하지만.. 막 시합을 시작하였는데.. 몸이 덜풀린 상태에서
대충 뛰어보고 분위기 파악해서.. 이제 본격적인 가동을 하는 운동선수와 같다고 할까..
처음팀에 들어와서 손발이 잘 안맞다가 몇번의 실수끝에 본격적인 팀워크를
발휘하는 스포츠팀의 모습이라는 생각을 크게 하게 된다.

변경사항이 없는데 시간이 지나서 점차 제모습을 찾는 시스템을 무엇이라고 해야 할까
정확히 얘기하면 말이 안되는 얘기인데.. 이런  상황을 몇번 겪어보고나면
시스템이라는 것도 살아있는 유기체라는 느낌이 든다..

덕분에 듀얼모니터에 잔뜩 로그화면을 띄워두고 오류가 발생하는지 죽어라 쳐다보다가
머리가 띵해져서 힘들기도 하고 앞으로 무엇을 더 해야 할지 막막하기도 하다..

by 제우스 | 2007/10/24 16:59 | 컴퓨터 | 트랙백 | 덧글(2)
검색이야기 with Lucene, solr
나는 개발자이기는 하지만 검색관련은 아니었다.

검색에 대해서 할수 있는 것이라고는
그냥 눈으로 찾던지, DB 필드들의 like 검색을 하는것,
일에 관한것은 구글을 이용, 가십거리는 네이버를 이용하고
내 컴퓨터에서 찾을때는 구글 데스크탑을 이용하는 정도..

두어달전부터 회사 서비스에 적용할수 있는 검색서비스에 관한 일을 하고 있다.
나처럼 이런 문외한도, 검색서비스를 1~2명이서 개발할수 있도록 도와주는 것이
저 lucene(루씬), solr(솔라) 라는 놈들의 덕분이다.

lucene(루씬)은 자카르타 프로젝트의 탑 시드를 받고 있는 오픈소스이다.
solr(솔라)는 루씬을 기본으로 한번 더 포장한 오픈소스이다.

요즘같이 엄청나게 폭발스러운 데이터에서 필요한 정보를 찾기 위한 검색은
포탈싸이트 같은곳에서는 필수품이 되었고 네이버에서 검색으로 얼마나 많은
돈을 버는지는 말을 하지 않아도 쉽게 알수가 있다.

네이버나 구글에서의 검색프로세스를 살펴보면(그냥 ^^ 간략히)
1. 데이터를 수집한다 (50%)
2. 데이터를 색인(인덱싱) 한다 (40%)
3. 데이터를 검색한다 (10%)
정도이다.

루씬은 검색과 색인의 API를 제공해주는 core 엔진이다.
아주 괜찮은 구조로 되어 있어서 현재 1억건 정도를 색인하고 검색을 하는데
느리다는 느낌을 받지 않는다.

하지만 루씬을 쓴다고 개발자의 할일이 없는 것은 아니다.
루씬은 엔진일뿐 http 나 socket이나 file에서 데이터를 읽어서 색인하라!! 라고 전달해주는 부분과
http나 socket으로 요청을 받아서 검색후 결과를 전달해주는 부분은 만들어야 한다.

여기서!!! 솔라가 또 한몫을 해준다
솔라는 색인과 검색을 루씬엔진을 쓰면서 http 프로토콜을 이용해서
색인 요청을 받고, 검색요청을 받고 결과를 주는 ,
어떤 정보를 어떤 방식으로 색인하고, 어떤 필드들을 저장하고 있는지에 대한 관리툴까지!!!
모두 제공해주는 역할을 해준다.

이런 멋진 엔진과 툴 덕분에 나 같은 놈도 ^^ 검색이라는 서비스까지 만들수 있는 것이다.
이 시점에서 박수!!!! 짝짝짝짝짝짝


루씬과 솔라를 이용하더라도 어쩔수 없는 부분이 있다.
그것은 역시!!! 2바이트 문자인 한글이다. 단순 2바이트 이외에도 한글의 특성상
색인부분을 뽑아내는것이 그리 녹녹하진 않다.
예를 들어보자

"우리 아버지는 대한민국을 사랑하십니다"

영어에서 색인단어를 추출하는 analyzer중 기본인 WhitespaceAnalyzer(빈공간으로 나누기)
로 자르면 [우리] [아버지는] [대한민국을] [사랑하십니다] 로 나온다.
우리빼고는 검색이 안된다.

stopword라는 불용어(색인 대상에서 제외시키는것)에 조사와 십니다, 습니다
와 같은 단어를 모두 포함시키면
[우리][아버지][대한민국][사랑하] 까지는 나오지만
사랑, 대한 같은 키워드로 검색이 안된다.

이런 단어들을 좀더 세분화해서
[우리][아버지][아빠][아부지][대한][대한민][대한민국][한국][사랑][러브] 까지 등록해서
검색할수 있도록 analyzer를 만드는 것은 우리나라 개발자들의 몫이다.
영어를 기본으로 하는 나라에서 만들어진 오픈소스의 한계라고나 할까..
그래도 analyzer를 따로 만들어서 색인시 이용할수 있다는 것이 어디야~

색인의 디테일한 정도와 색인시간은 반비례가 될수밖에 없다.
한국어 사전에 등록되어 있는 단어들로만 등록 가능하게도 할수 있다.
하지만 1억건에 데이터에 대해서 1개의 데이터별로 5~6번씩 사전을 검색해서 가능여부를 판별하는건
그만큼의 시간이 걸린다는 것을 나타낼수밖에 없다.

정확도, 색인시간, 색인용량, 검색시간... 등등
해당 서비스별로 맞춰서 하는것이 정답이다.
그래도 ^^ 루씬과 솔라를 쓰면 요고(에게~ 요고 ^^)만
고민하면 되니깐 이게 어디겠냐 ^^
by 제우스 | 2007/08/17 12:13 | 컴퓨터 | 트랙백 | 핑백(2) | 덧글(9)
◀ 이전 페이지 다음 페이지 ▶

카테고리
영화나 책
말말말
컴퓨터
게임이야기
태그
나꼽살 직업 원리 제이슨프라이드 마이너코드 스테가노그래피 vanish 웹개발자 공연 슬럼프 화성학 helloworld 게임 라이프사이클 똑바로일하라 서버개발 기타코드 재태크 메이저코드 ror 하이코드 ngrinder 개발자 파워코드 보험 오픈세미나 개발 디아블로3 2nd밴드
전체보기
최근 등록된 덧글
PLAY CASINO GAMES ONLINE: ..
by SCXD at 04/04
PLAY CASINO GAMES ONLINE: ..
by SCXD at 04/04
엄지척 바짝 올립니다. 궁금했던..
by 초보 at 10/11
다자가이든 소작이든 닭이 천 마리..
by yada at 09/20
나는 팔라독 헬 깸.
by 남영찬 at 06/17
^안녕.하세요^;; 골드팟 생기개..
by 전설의레전드소설책 at 03/25
이왕이면---- A7 등등 '7' 이 붙는..
by papagoat at 04/12
매우 감사합니다 ! 아주 쉽게 키..
by papagoat at 04/12
자꾸 F를 라로 표기하시네요 ㅎㅎ
by 안녕하세요 at 12/21
시 클라식 기타 코드표 도 보여..
by 강초보 at 06/08
라이프로그
똑바로 일하라
똑바로 일하라

펜트하우스 코끼리
펜트하우스 코끼리

화폐전쟁
화폐전쟁

10억
10억

거북이 달린다
거북이 달린다

용의자 X의 헌신
용의자 X의 헌신

마더
마더

터미네이터 : 미래전쟁의 시작
터미네이터 : 미래전쟁의 시작

스타트렉 더 비기닝
스타트렉 더 비기닝

천사와 악마
천사와 악마

노잉
노잉

7급 공무원
7급 공무원

박쥐
박쥐

인사동 스캔들
인사동 스캔들

와이키키 브라더스
와이키키 브라더스

매란방
매란방

건투를 빈다
건투를 빈다

코끼리는 생각하지 마
코끼리는 생각하지 마

배려
배려

벤자민 버튼의 시간은 거꾸로 간다
벤자민 버튼의 시간은 거꾸로 간다

작전
작전

워낭소리
워낭소리

작전명 발키리
작전명 발키리

적벽대전 2 : 최후의 결전
적벽대전 2 : 최후의 결전

트랜스포터 - 라스트미션
트랜스포터 - 라스트미션

디파이언스
디파이언스

사랑하지 않으면 떠나라!
사랑하지 않으면 떠나라!

촐라체
촐라체

쌍화점
쌍화점

황후화
황후화

크리스마스 별장
크리스마스 별장

눈먼 자들의 도시
눈먼 자들의 도시

예스맨
예스맨

순정만화
순정만화

펀치 레이디
펀치 레이디

눈에는 눈 이에는 이
눈에는 눈 이에는 이

전략적 책읽기
전략적 책읽기

돈, 뜨겁게 사랑하고 차갑게 다루어라
돈, 뜨겁게 사랑하고 차갑게 다루어라

좋은 놈, 나쁜 놈, 이상한 놈
좋은 놈, 나쁜 놈, 이상한 놈

다크 나이트
다크 나이트

H2 1
H2 1

그림으로 읽는 생생 심리학
그림으로 읽는 생생 심리학

호모 코레아니쿠스
호모 코레아니쿠스

강철중: 공공의 적 1-1
강철중: 공공의 적 1-1

이채원의 가치투자
이채원의 가치투자

쿵푸 팬더
쿵푸 팬더

카불의 사진사
카불의 사진사

인디아나 존스 4 - 크리스탈 해골의 왕국
인디아나 존스 4 - 크리스탈 해골의 왕국

시골의사의 부자경제학
시골의사의 부자경제학

종자돈 700만 원으로 부동산 투자 200억 만들기
종자돈 700만 원으로 부동산 투자 200억 만들기

우리동네
우리동네

디지로그 digilog
디지로그 digilog

대하소설 주역 4
대하소설 주역 4

읽지 않은 책에 대해 말하는 법
읽지 않은 책에 대해 말하는 법

Stick 스틱!
Stick 스틱!

색즉시공 시즌 2
색즉시공 시즌 2

바르게 살자
바르게 살자

20대는 통장을, 40대는 인생을 채워라
20대는 통장을, 40대는 인생을 채워라

점퍼
점퍼

생로병사의 비밀
생로병사의 비밀

추격자
추격자

오늘의 거짓말
오늘의 거짓말

주식시장을 이기는 작은책
주식시장을 이기는 작은책

대한민국 진화론
대한민국 진화론

무방비 도시
무방비 도시

피라니아 이야기
피라니아 이야기

우아한 세계
우아한 세계

경제를 읽는 기술
경제를 읽는 기술

실용주의 프로그래머
실용주의 프로그래머

블로그 비즈니스
블로그 비즈니스

어거스트 러쉬
어거스트 러쉬

세븐데이즈
세븐데이즈

뷰티풀 선데이
뷰티풀 선데이

괴물 1
괴물 1

킹덤
킹덤

당신과 일하기 힘들어 죽겠어
당신과 일하기 힘들어 죽겠어

뉴욕의 프로그래머
뉴욕의 프로그래머

나를 바꾸는 데는 단 하루도 걸리지 않는다
나를 바꾸는 데는 단 하루도 걸리지 않는다

벽오 금학도
벽오 금학도

해바라기
해바라기

펀드투자가 미래의 부를 결정한다
펀드투자가 미래의 부를 결정한다

상식이 통하는 웹사이트가 성공한다
상식이 통하는 웹사이트가 성공한다

아버지의 가계부
아버지의 가계부

본 얼티메이텀
본 얼티메이텀

최강 로맨스
최강 로맨스

여자도 여자를 모른다
여자도 여자를 모른다

부동산 10년 대폭락 시나리오
부동산 10년 대폭락 시나리오

아키텍트 이야기
아키텍트 이야기

보물지도
보물지도

오션스 13
오션스 13

게임회사 이야기
게임회사 이야기

바람피기 좋은 날
바람피기 좋은 날

조폭 마누라 3
조폭 마누라 3

삼미 슈퍼스타즈의 마지막 팬클럽
삼미 슈퍼스타즈의 마지막 팬클럽

광기와 우연의 역사
광기와 우연의 역사

런어웨이
런어웨이

회사가 당신에게 알려주지 않는 50가지 비밀
회사가 당신에게 알려주지 않는 50가지 비밀

롱테일 법칙
롱테일 법칙

해리 포터와 불사조 기사단
해리 포터와 불사조 기사단

사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편
사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해
우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해

트랜스포머
트랜스포머

20대부터 시작하는 스트레스 제로기술
20대부터 시작하는 스트레스 제로기술

미운오리새끼의 출근
미운오리새끼의 출근

캐리비안의 해적 : 세상의 끝에서
캐리비안의 해적 : 세상의 끝에서

미녀는 괴로워
미녀는 괴로워

유태우 교수의 내몸개혁 6개월 프로젝트
유태우 교수의 내몸개혁 6개월 프로젝트

브레이크 업 : 이별후애(愛)
브레이크 업 : 이별후애(愛)

인사이드 맨
인사이드 맨

마키아벨리, 회사에 가다
마키아벨리, 회사에 가다

웹 2.0 경제학
웹 2.0 경제학

한반도
한반도

연애, 그 참을 수 없는...
연애, 그 참을 수 없는...

구미호 가족
구미호 가족

럭키 넘버 슬레븐
럭키 넘버 슬레븐

찰리와 초콜릿 공장
찰리와 초콜릿 공장

아파트
아파트

레전드 오브 조로
레전드 오브 조로

rss

skin by jiinny
X