5월의 작은 선인장

[키워드]를 새로 작성해야 하나 하는 생각을 하다가 그만 님의 블로그를 방문하고서 Tistory에 하나의 건의를 해 봅니다. 그만님은 위키피디아의 내용을 복사하여 블로그 내에서 키워드로 사용하고 계시더군요.

인터넷에는 이미 많은 사이버 백과사전이 있고, 자유로이 이용할 수 있는 것들도 있습니다. 뿐만 아니라 누리꾼들에 의해서 마음대로 작성/수정될 수 있는 백과사전도 있습니다. '위키피디아'가 바로 그것이죠.
반면 Tistory에는 편리한 사전기능이 있는데 바로 '키워드' 기능입니다. 키워드는 그러나 활성화 되고 있지 못합니다. 왜냐하면 사전은 작성하기 힘들기도 하고, 작성한다고 누군가 많이 봐주지도 않는 공간이기 때문입니다.
그렇다면 위키피디아와 키워드를 혼합하면 어떨까 하는 생각을 해봅니다.
대략적으로 제가 생각한 내용은 다음과 같습니다.


키워드를 각각의 블로그에서 작성하면 주기적인 갱신이 쉽지 않습니다. 그 이외에 여러 가지 어려움을 위키피디아와의 힘을 합쳐 극복할 수 있지 않을까 생각해 봅니다. 위키피디아와 Tistory의 winwin전략이 될 것 같습니다만... 어떻게 생각하는지요?

포털에 펌할 수 없음!

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

다들 아시겠지만, Tistory에 초보블로거들이 적응하지 못하는 중요한 이유들은 관리자화면 때문이다. 관리자화면의 글편집기와 스킨수정시 CSS와 HTML의 난해함이 가장 큰 골칫거리지만, 그 이외에도 사용자들이 어렵게 느껴지도록 만드는 요소는 더 있다.
물론 이러한 요소들은 티스토리의 기능을 강화시키기 위해서 만든 기능들에서 나타나는 것이기 때문에 불만은 없다. 다만 UI를 조금만 더 다듬는다면 초보들도 조금은 편리하게 사용할 수 있지 않을까 싶어서 이 글을 작성한다.

정말 오래간만에 티스토리를 사용하면서 느끼는 불편한 점을 이야기하는 것 같다. 이전의 불편한 점에 대해 이야기한 글은 작성한지가 언젠지도 생각나지 않고, 그 이외에 플러그인에 대한 설명을 하면서 불편한 점을 조금 설명했던 것 같다. (그러고보니 그 글도 추가된 많은 플러그인에 대한 설명을 추가해야겠다.)

이번에 건의하는 개선점은 크게 10가지이며, 관리자화면에 대해서만 이야기한다.

01. 리퍼러 차단 기능
오늘 리퍼러를 확인하는 과정에서 어떤 사이트로 들어갔더니 고의적으로 보이는 한 웹페이지에서 악성코드 2개가 침투하는 것을 발견했다. 마침 설치되어 있던 알약이 바로 검출해서 관계되는 것들을 치료할 수 있었지만 문제는 치료 이후 내 블로그에서는 블로그메뉴바가 뜨지 않도록 되어버렸다는 것이다. 이번 윈도우즈를 깔기 전에도 비슷한 증상이 있었던 것 같은데, 아마도 같은 리퍼러에 당한 것이 아닌가 싶다. (다른 블로그에 가면 오히려 블로그메뉴바가 잘 뜬다. -_-)
아무튼 리퍼러에도 필터링을 통한 차단기능과 신고기능을 둬서 EAS에서 다뤄줘야 한다.

또 한 가지를 추가하자면 리퍼러는 보통 한번 찍히기 시작하면 몇십개가 연속으로 찍히기 마련이다. 이런 것들을 묶어서 이 리퍼러로 몇 개 들어왔다는 방식으로 표시해서 확인해야 할 리퍼러의 개수를 줄여주는 기능이 필요하지 않나 싶다.

02. 스킨의 HTML/CSS 편집화면에 '저장하기'버튼 수정
고수들의 경우는 잘 모르겠지만, 초중급 블로거들이 스킨을 편집하다보면 html tag를 조금씩 수정하거나 적용된 (크기, 위치, 색깔 등을 나타내는) 숫자들을 수정하면서 실물을 살펴보는 일일 것이다. 그런데 이러한 작업을 하는동안 보통 2개 이상의 창을 띄워서 스킨 저장하고, 새로 고침 한 번 누르고 하는 작업을 반복하게 된다.
그런데 '저장하기'버튼이 가장 밑에 있다보니 스킨을 저장하기 위해서 스크롤을 많이 해야 한다. 이러한 작업은 저장속도가 느린 것 때문에 나타나는 속도 저하보다 스킨 수정의 속도를 훨씬 더 느리게 만든다.
그래서 다른 곳의 다른 버튼들은 모르겠지만 스킨의 HTML/CSS 편집화면의 '저장하기'버튼은 화면을 따라다니도록 만들어서 언제나 그 화면에서 확인버튼을 누를 수 있도록 만들어야 한다.

03. 댓글/댓글알리미 확인기능
예전... 그러니까 벌써 한 예닐곱 달 전에 댓글^[각주:1] 게시판처럼 댓글알리미 게시판을 고쳐달라고 한 적이 있었다. 당시에는 댓글 게시판의 확인이 무척 쉬웠고, 댓글알리미 게시판은 지금보다 많이 불편했었다. 그런데 이런 건의를 한 뒤에 황당하게도 댓글알리미 게시판이 고쳐진 것이 아니라 댓글 게시판이 현재처럼 저장되는 사태가 발생했다. 아마 개발자가 내가 건의한 부분에 대해서 해독을 잘못한 것이라는 생각을 하게 된다. (많이 바빴나보다.)
현재 댓글을 확인하기 위해서는 어떤 글에 댓글이 새로 달렸는지 알기가 힘들다. 보통 마지막 댓글을 달아준 것 뒤로 새로 붙은 댓글들을 순서대로 글에 접속해서 한 번에 그 글에 붙은 댓글에 답글을 달아주곤 한다. 그런데 이것이 여러 글에 댓글이 달렸을 경우에 답글을 달다보면 한 글을 여러번 들어가게 된다. 각 글마다 어떤 댓글이 얼마나 달렸는지 확인할 수 없기 때문이다.
따라서 댓글 게시판은 하나의 글에 달리는 댓글을 모두 합쳐서 보여주거나  (댓글알리미 게시판과 같이) 댓글과 그에 달린 답글을 동시에 연관시켜보 보여주는 기능이 필요하다.

또 하나의 글에 댓글이 다수 붙었을 경우에는 다른 글에 달린 소수의 댓글들을 확인하는 것이 상대적으로 어렵게 된다. (예를 들어 한꺼번에 100개의 댓글이 달린 글이 있다면 100개의 댓글이 달린 글의 답글은 순서대로 달면 되지만, 그 이외의 다른 글에 달린 서너개의 댓글은 100개 사이에서 찾아야 한다. -_-) 따라서 이러한 문제를 해결하기 위해서도 하나의 글에 달린 댓글과 답글은 모아서 보여주는 것이 좋지 않을까? (아니라면 답글을 달지 않은 댓글들만 앞으로 빼주면 더 편할 것 같다. 그런데 이렇게 하려면 답글을 달지 않을 댓글들을 따로 처리할 수 있어야 한다.)

04. 트랙백 확인화면의 링크문제
한꺼번에 트랙백(엮인글)이 30개가 왔다고 생각해보자. 하나의 글에 30개가 모두 온 것이 아니라 30개가 각각 다른 글에 왔다면 트랙백이 달린 글이 어떤 글인지 어떻게 확인할 수 있을까? 트랙백의 수가 적다면 블로그 메인화면에 나오는 트랙백 리스트에서 클릭하여 각각의 글을 확인하면 되지만, 메인화면에 노출된 수를 넘어가게 되면 확인할 방법이 없어진다.
사실 이에 대해서 오랫동안 생각해 왔었고, TnF에 건의도 해 봤었지만 (어떤 개발자에 의해 필요없다고 무시당했다. ㅜㅜ) 블로그 내의 검색기능을 이용하는 방법 이외에는 방법이 없다. 이것도 한두 개일 경우에는 큰 문제가 없겠지만 30개 정도라면 완전 노가다일 수밖에 없다.

더군다나 오래전에 왔던 엮인 글을 확인할라치면 100% 검색에 의존해야 한다.
그러나 이 문제는 아주 간단하게 해결할 수 있다. 트랙백 게시물에 있는 '분류' 항목을 '받은 글' 항목으로 바꾸기만 하면 된다.^[각주:2]

05. 블로그 요약
관리화면의 센터 한 가운데에 잘 보이는 곳에는 블로그 요약이라는 것이 있다.
다양한 정보를 안내해 주지만...... 하지만 조금 더 자세한 정모를 제공해 줬으면 좋겠다.
현재는 블로그 개설일, 글, 댓글, 트랙백, 방명록 글의 개수를 알려주고, 방문자 통계도 보여준다.
글의 수는 전체글 수와 공개된 글의 수와 보호된 글의 수, 댓글과 방명록 글의 수는 주인장이 쓴 글을 제외한 댓글과 방명록 글의 수, 트랙백은 내가 받은 수와 보낸 수가 표시됐으면 좋겠다.

06. 공지/키워드 수정
블로그를 운영할 때 글을 자주 수정하게 된다. 글을 읽다가 새 창으로 바로바로 띄우고서 수정한다. 그런데 새 창으로 뜨는 창이 불편하다. 한 마디로 이전에 떴었던 위치도 기억하지 못하고 무조건 중앙에 뜨며, 크기도 기억하지 못해 너무 작다. 편집을 하는 동안 링크나 이미지를 수정하기라도 하려면 오른쪽에 열리는 정보표시가 절반밖에 안 보인다. 덕분에 수정하기 위해서 창을 띄우면 창의 위치를 옮기고, 크기를 조절하는 작업을 매번 하게 된다. 여기서 하고자 하는 이야기가 다 나왔다. 새 창을 띄워 글을 수정할 때 이전의 창의 위치와 크기를 기억해 뒀다가 똑같이 띄우게 만들었으면 좋겠다. (애초에 좀 창의 크기가 옆으로 길어 링크나 이미지 정보를 수정할 때 편하게 만들었으면 좋겠다.)

또 한 가지.... 공지/키워드를 수정할 때는 반드시 관리자화면에 접속해서 수정하도록 되어있다. 그런데 왜 이런 차이점을 뒀는지 이해하기 힘들다. 그냥 일반 글과 똑같이 처리하면 안 되는 것일까? 이 부분을 따로 처리하기 위해서 서버의 자원을 따로 소모해야 할 것 같은데....????
공지/키워드는 변경되어야 할 부분이 발견되도 수정하지 않고 그냥 놔두는 경우가 많은데, 이와 같은 이유 때문이다.

07. 카테고리 수정화면
카테고리 수정화면을 살펴보면 선택된 카테고리의 상태가 1단 카테고리냐 2단 카테고리냐에 따라서 나오는 항목이 다르다는 것을 알 수 있다. 그런데 왜 다르게 만들어야 하는 것일까?
그냥 2단 카테고리 나타내는 것과 똑같이 나타내고, 2단 카테고리가 선택됐을 때는 1단 카테고리를 보여주고, 거기서 1단 카테고리를 바로 수정(선택)할 수 있도록 만들면 안 되는 것일까? (여기서 선택할 수 있는 것 중 하나를 최상위 카테고리로 만들면 1단 카테고리로 변경할 것인지 2단 카테고리로 유지하면서 위치만 변경할 것인지를 선택하는 기능을 따로 만들 필요가 없어진다.
이 부분이 안되기 때문에 상당히 편집이 귀찮아진다.
1단 카테고리를 선택했을 경우에 (그 카테고리가 2단 카테고리를 포함하고 있지 않다면) 새로운 1단 카테고리를 선택할 수 있도록 만들어 1단 카테고리를 2단 카테고리로 쉽게 보낼 수 있을 것 같다.
새로 카테고리를 만들 경우에도 선택메뉴에 새 카테고리 만들기 기능을 넣어주면 될테니까 1단과 2단 카테고리 이동과 위아래 이동도 전체적으로 쉬워지지 않을까?

08. 휴지통
휴지통에 잘못된 필터링에 의해서 정상적인 댓글/트랙백이 들어갔다면 어떻게 복구할 수 있을까?
물론 하나하나 찾아 복구하면 된다. 하지만 그날 들어온 스팸이 5만개쯤이라면????
그래서 휴지통에서 보여주는 것들도 단순히 목록으로 보여주는 것이 아니라 공통점을 갖는 스팸들을 하나로 뭉쳐 짧게짭게 보여주는 기능이 필요하다고 생각한다. EAS에서 필요하기 때문에 휴지통에 스팸을 놔두라고 권고할 것이면 (휴지통을 둘 이상으로 나눠주면 편하겠다.) 필터링 등록한 IP 등에서 들어온 것들은 휴지통에 있던 없던 사용자에게는 안 보여줘도 상관없지 않을까?
(요즘은 좀 줄었지만, 예전에 하루 스팸트랙백이 10만개 이상 들어왔을 때는 정상적인 댓글이나 트랙백을 몇 개 정도는 놓치지 않았을까 싶어 읽는이들에게 죄송해진다.)

09. 작성중인 글 관리 게시판, 팀블로그용 게시판
이에 대해서는 특별히 할 이야기가 없다. 이미 이전에 지적한 적도 있었고, 티스토리 관리자들도 모두 알고 있으리라 생각한다.
다만 한 블로그에 대용량의 글, 여러명의 운영자, 많은 방문자들이 있음을 감안해서 블로그 전체의 구조를 다시 검토해 줄 것을 요청한다. TextCube도 사실 이 부분에 대해서 완전히 검토가 끝나지는 않은 것같아 보인다.


10번째는 작성했다가..... 내가 좀 오버하는 것 같아서 삭제한다. 한마디로 말하자면 블로그에 링크관리를 좀 강화하자 정도의 취지다. ^^;

---

오늘도 투덜거림을 한 번 해 봤다.
항상 새로운 불만사항들이 나오게 마련이지만, 이 글에 있던 것들 중에 상당수는 오래전부터 고쳐졌으면 좋겠다고 느끼던 것들이다. 하지만 고쳐지지 않는 이유는 Tistory 개발자나 기획자가 Tistory를 많이 써보지 않았기 때문이 아닐까 생각한다.

하지만..... 결과적으로 시스템을 정말 한번쯤 갈아엎어야 하지 않을까 하는 생각을 하게 된다. 분할백업, 숨김카테고리 기능 등 필수적인 것들 중에 지원되지 않는 것들이 너무나 많기 때문이다.

포털에 펌할 수 없음!

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

대선이 끝난 뒤로 올블로그의 블로고스피어 다변화를 위한 정책을 잠깐 맛봤습니다. 하지만 그 뒤로 갑자기 이상한 기류 속에서 최근에 다시 다변화 정책이 사라지는 것 같습니다.
현재의 올블로그 추천정책으로는 어쩔 수 없는 것인가 하는 생각을 잠시 하게 되기도 하는데......

뭐 하여튼 현재 나타난 문제는 크게 두 종류인 것 같습니다.

첫째 스팸 또는 악성 포스팅
스팸 또는 악성 포스팅을 최근 몇 개 신고했는데, 그들의 특징은 개설된 블로그에 글 수가 많지 않고, 신고될 때 이미 상당수의 추천을 받고 있다는 것입니다. 왜 그렇게 될까요? 분명히 가짜아이디를 만들어 사용하기 때문이 아닐까요? 이를 막기 위해서 약간의 패널티를 줘야 한다고 생각합니다.

이런 방법을 사용해도 완전히 막을 수는 없을 것입니다. 하지만 현재로서는 이런 방법을 사용해야 할 것으로 봅니다.

둘째 특정 블로거들의 카르텔 형성
사실 전 카르텔이란 단어 자체는 별로 좋아하지 않습니다. 하지만 곰곰히 생각해본 결과 - 결과적으로 카르텔이 형성되지 않을 수 없고, 안 되서도 안 될 것이라는 결론을 얻은바 있습니다. 그러나 카르텔  형성이 문제가 되는 것은 카르텔을 형성하지 못한 사람들이 상대적으로 손해를 볼 수 있다는 것입니다. 그래서 그에 대한 방법을 마련해야 합니다.

특정인들에게 집중적으로 추천이 이뤄질 경우 이를 감지해서 각 글당 추천점수를 낮추는 것입니다. 총 허용점수를 하루 20점이라고 했을 때 하룻동안 추천을 30점 했다면 추천한 점수를 2/3으로 깎아서 20점으로 낮추는 것이죠.
그리고 10명 정도에게 너무 집중적으로 추천이 이뤄지고 있다면 추천 점수 한계치를 전체적으로 낮추는 것입니다. 물론 이렇게 하기 위해선 조금 복잡한 알고리즘을 써야겠죠. 하지만 이러한 변화는 장기적인 현상이어서 매번 추천할 때마다 계산할 필요는 없을테니 하루단위로 계산해도 큰 문제는 없을 것이라고 생각합니다.

결국 카르텔을 형성하는 사람들이 생겨나겠고, 그들이 필요하겠지만 그들만의 추천으로 좋은 글이라는 평가를 받는 것은 막을 수 있어야 하고, 꼭 제가 말한 방법이 아니더라도 방법은 꼭 만들어야 한다는 것입니다.

---

아무튼....
전 한동안 올블로그에는 방문하지 않게 될 것 같습니다.
요즘 제 글도 그렇지만 요즘 올블로그가 쓰레기통이 된 것 같은 분위기라서......

포털에 펌할 수 없음!

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

현재 초보 블로거들이나 포털에서 운영하던 블로거들이 Tistory로 이전해 올 경우에 가장 어려운 일이 무엇일까? 열이면 아홉은 밑의 세 가지를 뽑을 것이다.

1. 글 작성 Editor 이용
2. SKin 수정
3. 독립도메인 설정

위의 3가지는 나도 처음 이 곳에 왔을 때 무척 고생했던 부분이다. 그나마 Editor는 Html tag 이용을 조금이나마 해 봤던 경험이 있었기에 어려움이 덜했으리라 생각한다. (사실은 지금도 어렵기는 하다.) 결국 Editor를 편하게 사용하기 위해서는 새로 만들어야 할 것 같다. ^^;

독립도메인 설정은 Tistory에서 naming server를 운영하지 않는다면 어려움은 해소되지 못할 것이라고 생각한다. 또 많은 사용자들이 사용하는 것도 아니니까 이를 위해서 새로운 기능 등을 만들 필요는 없어 보인다. 결국 사려깊은 도움말을 도와주는 정도 이상 도와줄 수는 없을 것이다.

그러나 Skin 수정은 관리기능이나 Utility로 구현할 수 있는 요소들이 분명히 존재한다고 생각한다.
이 글은 이에 대해서 작성하고자 하는 것이다.

---

프레임으로 구성되는 포털 스킨이 아닌 Tistory나 tattertools, Textcube 스킨을 가만히 뜯어본 사람들은 누구나 알 것이다. 모든 구성요소는 div tag로 나뉘어져 있다. div를 어떻게 구성하느냐에 따라서 보편적인 스킨이 될 수도 있고, 사용하기 힘들거나 이상한 스킨이 될 수도 있다. 그 이외의 변화들은 대부분 div의 성격을 조절하면서 결정하게 된다.

그 이외에 div들의 간격을 띄우거나(br tag로 줄바꿈을 하거나 div의 안여백, 바깥여백을 조절한다.) 조절하거나 선을 긋는 tag(HR 같은...)를 사용할 수도 있다. 스킨을 수정할 줄 아는 사람이라면 사실 이것이 모든 것이라는 걸 알 것이다. 그러나 이것을 html과 css로 나눠 저장하기 때문에 무척이나 어려워진다.

div라는 것의 속성 또한 제한적이기는 마찬가지다. 창(구성요소)의 위치와 크기를 결정하고, 테두리 선의 모양, 글씨의 기본적인 모양과 링크 글씨의 모양과 표시모양, div에 바탕으로 깔릴 이미지를 결정하거나 색을 결정(혹은 투명하게)하면 사실 더이상 뭔가를 할 일은 없는 것이 아닌가?

물론 내가 위에서 간단히 기술한 것들 이외에도 많은 결정요소들이 존재한다. Java 스크립트를 사용할 것인지 등등......

그래서 블로그 스킨을 만드는 과정에 대한 내 생각은 이렇다.


각 단계에서 필요로 하는 요소들은 사실상 거의 정해저 있으니 옵션으로 설정하는 것이 불가능하지는 않을 것이다. 이러한 옵션 설정치들을 모아서 style과 css를 만들면 될 것이다. 물론 직접 수정하려는 사용자들이 분명 있을 것이므로 사용자에게 보여주는 스킨 text들은 주석을 상세히 보여줘야 할 것이다. 하지만 실제 스킨을 블로그에 적용할 때에는 주석은 모두 빼낸 뒤에 적용해야 할 것이다. (물론 지금도 그렇게 하고 있겠지만....)

어떤 한 사람이 스킨을 만들어 배포하게 되면 이를 이용하는 사람들은 대부분 맨 처음 2번과 4번과 5번 작업을 하게 되고, 이후에는 4번과 5번 작업만을 되풀이할 가능성이 높다. 따라서 1번, 2번 3번은 기능만 구현된다면 특별히 신경쓸 필요는 없어 보인다.

---

마지막으로 스킨에 파일을 올리고자 할 때 이전파일들을 모두 지우거나 대체하는 방법이 있으면 좋겠다. 파일이 수십개인데 하나하나 지우는 방법밖에 없지 않은가? (모르는 사이에 수정이 됐네요.)

웹상에서 하는 것이 힘들다면 스킨을 만드는 기능을 하는 Utility를 만들어 배포하는 것 또한 좋은 방법이 아닐까?

포털에 펌할 수 없음!

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

어제 제 블로그는 다음 블로거뉴스에 두개의 글이 걸려서 블로그 카운터로 약 2만의 방문객이 방문했습니다.
평소 블로그에 찍히는 카운터의 10배에 해당하는 많은 방문객 숫자임에도 이런 경우에는 염려되는 것이 항상 존재합니다.

다음 블로거뉴스 뿐만 아니라 다른 메타사이트 등의 메인에 노출될 경우에는 항상 따라다니는 문제, 바로 허수 카운터입니다.

일전에 말씀드렸듯이 스팸이 몰려오는 시간은 허수 카운터가 급격히 증가한 뒤 며칠 뒤이고, 그래서 간접적으로 스팸업자들이 허수의 카운터를 양산한다고 볼 수 있습니다. 그리고 허수 카운터는 대부분 중요한 글이 메인에 노출된 뒤에 나타나는 것입니다.

밑의 이미지 두장을 보세요.

두 이미지는 거의 같은 시간에 캡쳐한 방문자수 카운터와 리퍼러 수입니다. 리퍼러 수는 255개로 사실 많지 않음에도 불구하고 카운트는 1000을 넘어서서 4배 이상의 차이가 납니다.(봇의 방문 제거 카운터 플러그인을 활성화시키고 있는 중입니다.) 물론 이 이면에는 리퍼러를 만들지 않는 직접방문 같은 경우도 분명 존재할 것입니다. 하지만, 그런 경우는 통계를 살펴보면 약 10~20% 정도에 그칩니다. 결국 700~800 정도의 카운트는 뭔가 문제가 있는 방문이고, 이 문제는 결국 스팸으로 연결된다고 볼 수 있는 것 같습니다.

스팸을 보내는 사람들의 ip가 거의 일정한 것을 생각할 때 스팸봇의 ip도 비슷할 것이라고 생각합니다.
그렇다면 이 부분을 분석하면 스팸봇의 정체에 대한 통계를 얻을 수 있지 않을까요? 제 블로그에는 찍히지 않지만, 훨씬 더 방대한 자료를 접할 수 있는 Tistory 운영자들은 충분히 스팸봇의 ip를 확인할 수 있을 것이라고 생각합니다. (두 데이터를 비교해 보면 어떤 상황인지 알 수 있을 테니까요.)

그러니 Tistory 운영자들은 조금 더 신경써서 스팸봇의 ip를 차단해 주시길 부탁드립니다. 그리고 카운터의 성능 개선좀 요청드립니다.

포털에 펌할 수 없음!

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