완벽함이란 더 이상 무엇인가를 더할 것이 없을때 이루어 지는 것이 아니라, 더 이상 무엇인가를 뺄 것이 없을 때 이루어진다. - 앙뜨완느 마리 로제 드 생떽쥐페리
by 미친병아리 이글루스 피플 2006 이글루스 TOP 100 2007 이글루스 TOP 100
포토로그
메뉴릿
주저리 주저리
라이프 로그
Tomcat, 정말 실망이야..
작년에 진행했던 프로젝트 중에 12대의 서버에 Tomcat을 설치해 진행했던 프로젝트가 있다.. 최대 접속자를 늘리기 위해 여러가지 세팅 값을 바꾸고 최대 성능을 낼 수 있도록 조정을 했었는데 원하는 만큼 속도가 안 나오는게 문제였다.. 우리는 Tomcat과 JSP로 충분한 속도를 낼 수 있다고 했고, 고객사에서는 IIS와 ASP.NET이 훨씬 빠르니 초기접속 및 핵심 페이지 몇개를 ASP.NET으로 바꾸자고 했다..

물론, 앞에 아파치 웹서버를 붙이면 성능에 훨씬 도움이 될 것이라는 것은 알았지만 정적 페이지들은 거의 없었고 디자인을 위한 이미지 파일들도 최소화 시켜둔 상태였다.. 하지만, 그래도 찜찜해하는 고객사 분들 때문에 이 파일들도 모두 IIS 쪽으로 돌렸다..

Windows 2003 서버 12대에 MS SQL 2000 DB 서버가 1대가 운영되었는데, 웹서버에는 IIS와 톰캣이 포트를 달리하여 모두 설치되어 있었다.. 우리는 톰캣이 어느 정도 성능을 내줄 것으로 기대를 했었다.. 아파치는 다른 어떤 웹서버에 비해서도 떨어지지 않는 성능을 보여줬지 않는가.. 톰캣 역시 제우스나 웹로직 같은 상용 WAS에 못지 않는, 혹은 떨어진다고 해도 약간 떨어지는 정도의 성능을 보여줄 것으로 기대를 했었다.. 하지만, 역시 상용 WAS 보다는 성능이 훨씬 못 미치는가 보다..

몇번의 부하 테스트를 통해 톰캣은 원하는 성능이 나오지 못함을 확인했다.. 하지만, 부하가 많이 걸릴 것으로 예상되는 몇개 페이지를 ASP.NET으로 만들어 같은 성능 테스트를 해보니 훨씬 좋게 나왔다.. Tomcat이 상용 서버만큼의 속도가 나올 것이라는 기대를 하는 것은 너무한 기대였을까? IIS + ASP.NET + Windows 2003 서버에 비해 절반 정도의 성능 밖에 안 나오다니.. 리눅스에서 돌리지 않고 윈도우에서 돌려서 그런가? 아무튼 톰캣, 왕 실망이다..

물론, 몇개 페이지만 가지고 단편적인 실험을 통해 이렇게 이야기 하는 것이 좀 무리이긴 하지만 말이다.. 언제 심심하면 Tomcat의 성능비교 자료를 함 찾아봐야겠다..

2008.04.09
댓글로 Tomcat이 그렇게 성능이 떨어지지 않는다며 정보를 주셨던 nokarma님께서 Tomcat, 정말 실망이야..? 라는 글을 통해 좀 더 구체적인 정보를 제공해주심.. 하지만, 구체적으로 Tomcat을 어떻게 튜닝 혹은 세팅값을 변경해야 하며 또는 프로그래밍시 어떤 부분들을 어떻게 하는게 좋다는 구체적인 내용을 담은 자료는 없다.. 나도, 톰캣으로 좋은 성능을 내는 사이트가 있을 것으로 생각한다.. 하지만, 나도 그렇게 하고 싶은데 어떻게 해야 하는지를 모른다는 것이다.. 반면 IIS는 특별한 튜닝 혹은 세팅 없이도 Tomcat 보다 월등한(?) 성능을 내고 있다.. 퍼포먼스 테스트는 다른 방법을 취한게 아니라 실제로 사람이 붙어서 했다.. 8천명 정도가 5~10분 사이에 일제히 들어와 사이트를 사용하는 것인데.. 톰캣은 에러나는 페이지를 많이 보인 반면, IIS+ASP.NET의 조합은 잘 버텨냈다..

geek이나 hacker 수준의 실력을 갖춰 세밀한 튜닝을 해야 Tomcat이 성능을 발휘한다면 (물론, 그렇게 하면 최상의 성능을 발휘할 것이라 믿어 의심치 않는다..) 하지만, 그런 정보가 공개되어 있지 않은 상태에서 Tomcat은 좋은데 니가 몰라서 그런거야.. 라면.. 별 수 없다.. 그걸 알기 전까지는 Tomcat 별로라고 안쓰며, 한편으로는 성능을 내기 위한 자료 열심히 찾아보는 수 밖에.. 영어를 잘 못해 그런가.. 암튼, Tomcat의 성능 최대화 세팅을 위한 정보는 찾기가 쉽지 않다.. 뭐, 그래도 계속 더 찾아보는 수 밖에..

하긴, 몰라서 제대로 사용할 줄 모르는 것인데 톰캣 욕하고 있어봐야 해결될 것은 없다.. 하지만, 몰라서 그런지 몰라도 성능을 내기 위한 세부 세팅에 대한 가이드 라인 정보를 구하는 것도 쉽지 않다.. 노력 없이 문제해결을 하려는 날로 먹을 속셈.. 맞다.. 하지만, 공개된 정보들도 보면 남들은 이렇게 성능 냈다더라는 정보 말고는 구체적인 도움을 받을 만한 정보는 없는 것 같다.. 물론, 이것도 내 검색 실력이 부족한 탓이리라.. 다른 프로젝트에서는 톰캣을 잘 활용하기 위해서라도 정보 수집을 해봐야겠다..

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

by 미친병아리 | 2008/04/03 23:42 | ▣ 컴터야그 ▣ | 트랙백(1) | 핑백(1) | 덧글(16)
트랙백 주소 : http://madchick.egloos.com/tb/1736328
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 나두미키님의 이글루 at 2009/04/01 09:19

제목 : 톰캣!!
Tomcat, 정말 실망이야.....more

Linked at anarch님의 글 - [20.. at 2008/04/04 11:29

... ; 로그인 http://me2day.net/ 암호 로그인 유지 미투 가입하고 새로운 친구를! ← 2008년 4월 1 2 3 4 4 Apr 2008 0 metoo Tomcat, 정말 실망이야. 오전 11시 29분 댓글 (0) 0 metoo 주제: 종종 사람들이 인터넷으로 무얼하면서 노는지 궁금하다. 오전 11시 25분 me2ox me2o 여러분의 인터네 ... more

Commented by Sikuru at 2008/04/04 10:13
자료는 없고 경험적 (그것도 2년쯤은 된-_-) 정보밖에 없습니다만...

제가 써본 것이 톰캣, 웹로직, 제우스를 써봤는데 톰캣하고 성능차이가 생각보다 꽤 납니다. 그보다 유지보수 측면에서 톰캣쪽이 정신적/육체적으로 압박이더군요 ; (특히나 납품형 프로젝트의 경우에는 더욱-_-)

웹컨테이너들이 대규모(?)가 되면 모르겠지만 어느정도 프론트 100대급 이하의 소규모에서는 php/asp... 정확히는 IIS/Apache+PHP 에 비해 성능적으로 우위점이 전혀 없었습니다.
Commented by navis at 2008/04/04 10:22
commons.pool 을 1.4 로 업그레이드 해보세요.
Commented by 가우리언 at 2008/04/06 21:41
우리회사에서도 IIS 에서 Apache+Tomcat 으로 전환한 사이트가 하나 있었는데, 역시 성능에서 문제가 발생하였고, 사용자도 그다지 많지 않았는데 접속이 잘 되지 않는 현상도 있었습니다. 몇가지 사항들을 튜닝하면서 겨우 겨우 해결했었지요. 그리고 상용 WAS와도 성능비교테스트를 했었는데, 역시 차이가 있었습니다. 그당시 Tomcat 4 였었는데, 지금은 어떨지 궁금하네요. 그냥 IIS로 다시 돌아가는 것이 낫지 않을까도 종종 생각합니다.
Commented by 미친병아리 at 2008/04/07 04:11
Sikuru님 : 쩝.. 저도 앞으로는 좀 크다 싶으면 Tomcat 사용 안하려 합니다..

navis님 : 음.. 해보겠습니다..

가우리언님 : 아무래도 성능차이가 많이 나는 듯 합니다..
Commented by nokarma at 2008/04/07 08:39
프로덕션 시스템에서 Apache/Tomcat 로 동시접속 40만명 이상 커버하는 곳도 있는데, 얼마나 크길래 그런지 모르겠군요. 동시 로긴 사용자수 40만명이 아니라, 동시 HTTP request 발생수 40만입니다. 물론 클러스터링 하구요.
Commented by aromi at 2008/04/09 14:07
상용 WAS는 엔지니어가 튜닝시켜주지만 톰캣은 튜닝 엔지니어가 따로 없다는게 문제긴 하죠. 그나마 톰캣은 버전5에 들어와서 튜닝할 수 있는 값이 많이 늘어나서 꽤 빨라졌다는 평을 듣습니다. 그러나 수많은 업체에서 대용량 서비스에 잘 적용해서 사용하는데도 이렇다할 튜닝값이 없다보니 Server Configuration 문서를 뒤져가며 테스트하는 수 밖에 없지요.
http://tomcat.apache.org/tomcat-5.5-doc/config/index.html
찾아보면 의외로 만질 수 있는 값이 많이 있다는걸 알 수 있는데, 톰캣은 기본적으로 대충 설치해도 동작하도록 설정이 느슨하게 제공됩니다. server.xml을 열어보면 이것저것 엄청나게 많지만 대부분 예제일 뿐이죠.
튜닝의 시작은 server.xml의 필요없는 항목은 모두 제거하고 webapps 폴더 안의 필요없는 폴더도 모두 삭제한 후, Connectors의 파라마터와 Context의 파라마터를 조정해 가면서 테스트합니다.

그밖의 유의할점은 톰캣은 단일 jvm process에서 동작하는데 OS에는 한 process에서 open할 수 있는 file의 수나 thread 수, 사용할 수 있는 메모리 등에 제한이 있어서 튜닝값을 그 이상으로 올려도 의미가 없습니다. 단순히 CPU 사용량만 보고 과다하게 높여잡은 파라마터가 오히려 퍼포먼스를 깍아먹는 경우도 있었습니다.
한 process에 요구되는 부하가 클 경우 아파치나 IIS 등과 AJP로 연동해서 한 서버에서 톰캣을 2개 이상 띄우는 것도 괜찮은 선택입니다. 시스템의 효율은 높아지지만 단점은 데이터 이동 경로가 길어집니다. 그래도 이 선택이 더 나을 경우도 있습니다.

프로그래밍시 주의할 점이라면.. 너무 많아서 이미 책이 나와있을 정도라 생략하고 가끔은 프레임웍을 안쓰고 날코딩으로 하는게 더 빠를 때도 있습니다. (아마 유지보수는 지옥이 될 가능성이 있겠지만요.)

마지막으로 IIS 같은 경우는 약간 반칙이 있는데, IOCP 같은 공개된 기능 말고도 다른 일부 기능이 커널 레벨에서 동작한다고 들은 적이 있습니다. 그래서 윈도우 서버가 있고 ASP 계열 개발자가 있고 어플리케이션 요구사항이 '유닉스 서버를 도입할지도 모르니 대비해 주세요'라고 하는 경우가 아니라면 그냥 그 환경을 이용하는게 최선입니다.
Commented by 미친병아리 at 2008/04/09 18:52
nokarma님 : 좋은 정보 주셔서 감사합니다.. 헌데, 어떻게 하면 그렇게 구성을 할 수 있는지에 대한 정보를 제 능력으로는 얻기가 어렵네요.. 쩝..

aromi님 : 문서를 뒤져가며 테스트라.. 흠.. 그게 쉽지가 않은 어려움이 좀 있습니다.. 매일 항상 사용하는 시스템이 아니라서리.. 한번 사용할때 왕창 붙고, 한동안 사용 안하다 사용하고 이래서, 테스트할때 인력동원한 내용을 가지고 시스템 설정을 바꿔가며 최적치를 찾아내는게 쉽지 않습니다.. 어느 정도 최적화된 수치값 등이 공개된게 있으면 큰 도움이 될 것 같습니다..
Commented by nokarma at 2008/04/11 15:00
본인이 공부하시겠다는건 좋은데 그건 본인이 개인적으로 짬짬이 할 일이지 고객 프로젝트 진행중 그렇게 하겠다는건 문제가 있는 어프로치라고 봅니다. 비행 경력 10년인 기장이 승객들한테, 제가 정비쪽은 잘 모르는데 공부해가면서 여러분을 모시겠다고 하는거나 마찬가지니까요. geek이나 hacker가 필요한게 아니라 단지 그 분야 유경험 전문가를 고용해서 프로젝트팀에 합류시켜면 될 일입니다.

MS Windows server, IIS, ASP.NET, SQL*Server는 이미 그 조합으로 end-to-end 튜닝되어서 나오는 종합 선물 세트나 마찬가지라고 봅니다.
실전에서 Apache/Tomcat을 Windows server, IIS, SQL*Server와 쓴 예는 본적이 없는것 같군요.
tomcat 기반 production 시스템은 거의 epoll 지원하는 Linux 2.6 64bit version에 Apache, Tomcat, 64bit JVM에 오라클 씁니다. 이 조합 경험 전문가는 쉽게 구할수 있습니다만. Windows, IIS, Tomcat, SQL*Server 조합 경험 전문가는 별로 구하기 쉽지 않을것 같군요. 한국은 또 다를수도 있겠습니다만.

IIS, Tomcat, SQL*Server쓰는 경우에는 IIS와 tomcat 연결 시켜주는 component가 병목일수도 있고, tomcat 자체 설정이 문제일수도 있고, JVM설정이 문제일수도 있고, database connection pool이 병목일수도 있고, SQL*Server JDBC driver가 문제일수도 있습니다. 사람 7,8천명이 실제로 로드테스트한다는 경우는 처음 들어보네요. 확실히 한국은 사람값이 싸다는 생각이 드는군요. consistent하게 로드테스트 결과 비교하려면 이것도 툴써서 전문가에게 시켜야 될 일입니다. 성능이 일정수준에 달할때까지 반복해서 돌리면서 병목을 찾아 제거해야 되거든요.
그리고 로드테스트 시나리오도 여러가지로 변경하면서 해야되구요.
램프업 타임은 제외해줘야 되고, 특정 시나리오의 목표 피크로드에서 어느정도 버텨줘야 된다는 계획에 부합하는 로드를 생성시켜서 테스트해야 합니다.

한마디로 요약하면, 공부는 따로하시고 프로젝트에서는 전문가 시키세요.
Commented by kenu at 2008/04/12 15:34
톰캣에 신경 안 쓴지 꽤 되었네요. 처음엔 문서도 몇 개 번역하고 했었는데 말이죠. 좋은 얘기들 많이 들려주셔서 감사합니다.
페이지 소개해야할 것 같습니다.
Commented by 미친병아리 at 2008/04/12 20:00
nokarma님 : 뭐, 상황이 그런 전문가를 투입할 수 없는 상황이라 그런것이죠.. 프로젝트는 고객사 요구대로 ASP.NET으로 개발하여 종료시킨 상태입니다.. 앞으로 다른 프로젝트를 위해 정보를 수집중입니다.. 물론, 이런 자문을 해줄 수 있는 전문가를 구하는 일도 병행중입니다..
테스트 과정은 개발중에는 특정시간에 사이트로 몇초간격을 두고 접속해보는 프로그램을 작성해 내려보내서 합니다.. 인프라가 되니 이런건 편하더군요..
실제로 사람이 붙어서 테스트를 하는 것은 사실 시스템 테스트 보다는 사람들에게 시험보는 환경을 경험시키고, 직무평가의 중요성을 알리기 위해서 하더군요.. 개발하는 입장에서는 고맙지요.. 연수원에 들어가 보던 시험을 온라인평가로 대치하는 과정이라 가능한 일이지요.. 한국이 사람값 싸서 가능한 일은 아닙니다.. 국내의 큰 은행 직원들인데, 싼 인력이 아니지요..

kenu님 : nokarma님이 좋은 정보 많이 주셨지요~ ^^
Commented by Kenny at 2008/04/12 23:57
상황에 따라 다르긴 한데..
MS에서 제공하는 JDBC 드라이버는.. 은근히 심각한 성능상의 문제가 있습니다.. ;;
그냥 jTDS 쓰시는 것 추천..
특히 DB 서버를... MS-SQL을 쓰신다면... 그냥 ASP.NET 쪽이 성능이 나을 가능성이 높죠.. 별다른 설정 안해줘도 잘 나오고..
Commented by nokarma at 2008/04/13 00:17
원칙적으로 따지자면, 로드테스트는 클라이언트 IT조직에서 그 프로젝트의 PM으로 assign된 사람이 비용 및 일정을 프로젝트 계획에 포함시키고 실행해야 될 일인데, 그게 잡혀있지 않은 상황이라면 그 사람 책임입니다.
대형 은행 정도 되는 조직이면 이미 내부 web 어플리케이션 load test팀이 있거나, 주로 거래하고 있는 외부 로드테스트 서비스 업체가 있는게 정상이구요.
Mercury Interactive같은데서 이런 서비스를 지원을 했었는데, HP로 합병되었으니 HP쪽을 컨택하면 어떤식으로 로드테스트 해야하는지에 관한 정보를 얻을수 있을겁니다.
Commented by 임은천 at 2008/04/14 19:17
부하가 많이 걸릴 것이라 예상되는 페이지의 JSP 코드와 ASP.NET의 코드는 정확하게 동일한 순서로 처리되지 않을 것입니다. 가장 저수준에서 CLR과 JVM의 동작 방식은 비슷하지만, 일단 GC 알고리즘이 기본적으로 .NET과 JVM이 다를 것입니다. 먼저 CLR과 JVM 자체가 Open 방식의 구현을 가지기 때문에 여러 JVM 벤더의 제품을 사용해서 테스트 해보기 바랍니다.
Sun의 제품을 사용했다면, Client JVM 방식이 아니라 Server JVM 방식으로 설정하고.. GC 알고리즘을 수정한 뒤에, JVM 힙 영역의 크기 같은 것도 조절해 주신 뒤에 비교하셔야 합니다.

그리고 코드 측면에서 미친 병아리님께서 작성한 코드가 ASP.NET과 JSP에서 동일한 코드라고 볼 수가 없습니다. 동일한 동작을 하는 응용 프로그램을 interface로 추상화 해서 설계를 마친 후에 구현만 ASP.NET, JSP 이렇게 따로 해서 비교를 하는 것이 어떨런지요.

객체 그래프에 참여하는 인스턴스가 상이하고, 구동 되는 가상 머신의 GC 알고리즘 방식 등이 다른데다가 정량적인 판단을 할 수 있는 동일한 클라이언트가 아닌 메뉴얼 방식의 승인 테스트(Acceptance Test) 방식으로 테스트한 것으로 Tomcat을 판단하면 신뢰도가 떨어지는 테스트가 됩니다.

톰캣은 약간의 성능향상을 할 수 있게 JNI 방식의 DLL도 지원합니다. 이것도 마찬가지로 추가를 해주셔야 합니다.


만약 정확한 비교를 원하시면 JSP와 ASP.NET 쪽 코드를 공개해 주시는 것도..(모든 코드가 아니라 부하가 심했던 부분만이라도..) 괜찮을 듯 합니다.
Commented by mangdee at 2008/04/14 22:11
형....톰캣으로 고생이 많았었나보네...
톰캣은 설정을 좀 해야해설^^;;
Commented by nokarma at 2008/04/15 15:37
말할까 말까하다 관둔 부분을 다른분이 지적해주셨군요.
보통 성능 문제는 infrastructure쪽 보다는 application에서 더 많이 생깁니다.
ASP.NET 쪽 구현한 사람과 Java쪽 구현한 사람의 optimal한 시스템 구현 스킬이 비슷해야 공정하게 비교할 수 있는 코드가 나옵니다.
Commented by 미친병아리 at 2008/04/19 17:41
Kenny님 : 좋은 정보 감사합니다.. 다음 프로젝트에서는 드라이버를 교체해보도록 하겠습니다.. 순전 드라이버의 문제였을 수도 있겠군요.. 결국, 자바 환경을 별로 신경 안쓰는 Microsoft 때문일 가능성도 있겠네요.. 나쁜.. ㅎㅎㅎ

nokarma님 : 맞습니다.. 하지만, 국내 SI에서 그런 전문가에 대한 비용을 확보하면서 제대로 프로젝트 할 수 있는 PM이 몇이나 될까 하는 생각도 듭니다.. 상황이 이런데도 해보겠다고 하는 내가 바보 아닐까 하는 생각도 가끔 합니다..

임은천님 : 사이트의 모든 기능을 JSP와 ASP.NET, 모두 구현한 것은 아니고 특정 몇 페이지만 작성했습니다.. 정확히 3개 페이지 이며, 정확한 테스트를 위해 다른 준비를 할 만큼 복잡한 페이지도 아니며 단순히 리스트 뿌려주는게 전부입니다.. 따라서 개발자의 능력에 따라 성능이 차이날 페이지도 아니지요.. 소스코드를 공개하는 것이 이 논의를 진행하는데 얼마나 도움이 될 지 모르겠지만, 조만간 가장 비교가 되는 한 페이지를 정리를 해서 올려보도록 하지요..
하지만, 제가 이야기 하고자 했던 핵심은 톰캣의 경우 이래 저래 신경을 많이 써야 성능이 나오는 반면, IIS는 별다른 설정 없이도 일정 성능이 나온다는 것이었습니다.. 제 글의 제목이 낚시성이라 문제가 되었던 것 같습니다..

mangdee님 : 설정을 좀이 아니라.. 많이 해야하는 것 같다..

nokrma님 : 정확히 쿼리 하나 날리고, 리스트 뿌려주는 페이지라 큰 차이는 없을 것 같습니다.. 쿼리도 거의 비슷한 실행속도와 거의 차이가 없는 쿼리문 실행이라 개발자의 스킬 때문일 가능성은 거의 없다고 생각합니다..

:         :

:

비공개 덧글

Creative Commons License

< 이전페이지 다음페이지 >


이글루 파인더
카테고리
태그
최근 등록된 덧글
최근 등록된 트랙백
마이클잭슨 사망 소식들..
by Bluesky
후아유(2002) : 2000년대 ..
by 생활의 발견
知的人의 생각
by peter_c's me2DAY
톰캣!!
by 나두미키님의 이글루
정규 표현식 완전 해부와..
by 김재호의 디지털보단 아..
HTML 소스 제대로 보자,..
by [부동산]개발.정비구역
내 손안의 PC - 자바가 ..
by 上善若水
Stringbuilder OutOfMe..
by Pinch of Smack for D..
웹 오피스 정리
by Web N Bizr
네이버 블로그 검색 - ..
by InformationRedesign
에반게리온: 서 - 사운드..
by LG전자 XCANVAS홈..
블로그에서 수익은 기대..
by IT, 모바일, 엔터테..
"다음으로 지원한 이메일..
by 민노씨.네
알라딘 TTB2 둘러보다
by NKOKON's Web-Note
문답 # ActiveX 문답
by 아이리스가 만개한 언덕..
미친병아리의 생각
by madchick's me2DAY
나의 에반게리온, 그리..
by 공포영화를 좋아하는 블로그
소비지향의 대학축제
by 세상을 보는 또 다른 시선
러브양이님에 의해 도서..
by 도서가격비교 와비
덕평 자연 휴게소
by 지민아빠의 해처리
이글루 링크
EBC (Egloos Broad..
erehwon.LAB
About willy
Living Loving and L..
修身齊家萬事成
【 이름쟁이™의 눈으로 】
개 풀 뜯어먹는 소리
觀鷄者의 망상 공간
Oz in Wonderland
김명신의 즐거운 하루
Clip for 눈love
함께.. 늘 그렇게..
荷花(hehua)
소스코드위를 걷다.....
가로등 프로젝트
zoops 이야기
까모의 룰루랄라~
▒ 제닉스의 사고뭉치 ▒
河伊兒의 고물상
가로수들은 여전히 제자..
餘分D: physics and fun
hansang's world is no..
길고양이 이야기
어쨌건간에 흘러가는 者
선인장 일지
~★~ 우하하!!~ 프로..
without coffee
Lady Nariel's Golde..
검색엔진 루씬 Lucene..
fire, walk with me
디지털을 말한다 by oojoo
♠후리지아 향기처럼♠
일상 생활 속의 파편들
뽐뿌 inside
책읽는 엄마의 보석창고
Mono log
blogger jely
반복되는 일상속의 비정..
골룸에세이
질풍 17주의 머브러브 라..
maniacs
AURA's Showcase
ozzyz review 허지웅..
디제의 애니와 영화 이야기
ANTIEGOIST : GyuHo..
미달이의 육아일기
All about IT Trends
Suicide Solution
얼음집
외계인 교차점
모기불통신
Trip
찬별은 초식동물
숲 속 작은 섬
snowcat blog
전도서에 바치는 장미
한글이 꿈틀
이우진의 UCC 제작실 ..
INVENT
위로..위로..위로..
woody's film review
Show me the money
전자음악 알아보기
sunny's store
이규영 연예영화 블로그
◀ M.HOUSE - Masade..
공순이 감성로그
쉽니다.
roadster
무디의 무책임한 세상
이제 다시... 바라보다.
random life
Beyond Web
ricordati di me
Jania's Blog
Gaious 功房 네오베..
애자일 이야기
- Last Paromix -
T9T9 Research Center
양군 블로그
소프트웨어 이야기
chef's garden
Requirement Enginee..
티오
고재관의 블로그
mocca
yundream의 프로그래..
통TON
lalou
생각이 없는 블로그
이전 블로그
rss

skin by 이글루스