오픈소스와 비전문가?

jinoos의 이미지

오픈소스진여의 대부분은 CloseSource(?) 진영의 그것과 비교해서 실제 어려운것이 사실입니다. 일반적인 프로그래밍적 지식이 좀더 필요하겠고, 시간 투자를 더 해야 하는것도 사실입니다. 재미와 흥미를 가지고 있다면 더할 나위 업구요.

그러나 대부분의 사람들은 컴퓨터가 자신을 위해 자신이 필요할때 필요한 일만 잘해주길 원하지 컴퓨터를 이해하기 위해 복잡하게 얽힌 문제를 해결하거나, 한가지를 위해 2~3가지를 알아야 한다던지.. 등등의 시간을 허비(?) 하고 싶어 하지는 않는것 같습니다. 그래서 그들이 사용하는것은 좀더 Look and feel 해야 하며, 편한 악세서리들을 더 구비주어야 좋겠죠.

또한 모르는게 약이라는 말처럼 그들의 잘못을 감춰주고 최대한 배려해 줘야 하며 가끔은 쓸데없는 문제가 발생하지 않도록 적당히 권리를 박탈하기도 해야 합니다. 아주 큰문제가 발생하기 전에 문제로 접근하는 길을 막는것이죠. 그래야만 그들은 덜 자유롭지만 안전하고 덜 강력하지만 편안함을 느끼게 되는것이죠.

헌데 처음에 얘기 했듯이 오픈소스의 태생적인 스타일 덕분에 비전문가(대부분의 사람들)의 취향하고는 거리가 좀처럼 좁혀지질 않습니다.

요즘의 현실을 보자면 언론과 미디어들은 오픈소스가 점점더 초보자에게 다가가고 있다고 얘기 하고 있습니다. 몇년전부터 데스크탑(비단 단어적 측면이 아닌 비전문가 들에게 사용을 의미 한다고 봅니다)에서 오픈소스를 사용할수 있다고 얘기해 왔으며 이곳에서도 그러한 말들을 했습니다.

그렇다면 오픈소스역시 비전문가들에게 사용되것을 지향하고 있다고 할수 있지 않겠습니까? 그렇다면 좀더, 그들이 어려워 하는것이 무엇인지에 대해서 귀담아 듣고 필요한 핵심을 찾아내야 한다고 생각합니다.

여러분들 가슴속에도 오픈소스가 널리퍼져서 모든이들이 사용하고 공감할수 있는것이 되기를 바랄것입니다. 그렇다면 좀더 모르고, 좀더 덜 전문적인 사람들의 말에 귀를 기울여야 하지 않을까요?..

PS : 이미 잠겨버린 글타래에 얘기를 다시 끄집어 내는듯 기분이.. :oops: 하네요.
저는 누구를 비판하고 누구의 손을 들어주자는 말은 아닙니다. 다만 오래전 적수네 동네 에서처럼 윈도우즈 옹호글만 등장하면 답글이 수십여개씩 붙어서 그들을 몰아내기, 마녀사냥 하듯 하는것은(KLDP는 그래도 성숙한 토론공간 입니다. ^^) 오픈소스발전에 개미 눈물만큼도 도움되지 않는다는 생각에서 적었습니다.

댓글

jedi의 이미지

사용자의 능력을 발전시키는 방법을 시행하는 것이 인류와 지구의 발전에 훨씬 더 도움이 된다고 생각합니다.
쉬운 윈도에 바이러스가 많은 것 아닐까요?

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

세벌의 이미지

jinoos wrote:
이미 잠겨버린 글타래에 얘기를 다시 끄집어 내는듯 기분이.. :oops: 하네요.
저는 누구를 비판하고 누구의 손을 들어주자는 말은 아닙니다. 다만 오래전 적수네 동네 에서처럼 윈도우즈 옹호글만 등장하면 답글이 수십여개씩 붙어서 그들을 몰아내기, 마녀사냥 하듯 하는것은(KLDP는 그래도 성숙한 토론공간 입니다. ^^) 오픈소스발전에 개미 눈물만큼도 도움되지 않는다는 생각에서 적었습니다.

글쎄요. 최근의 잠긴글 사건은 윈도즈 옹호글이라서 몰아내기 한 건 아니라고 생각합니다. 다른 사람이 그렇게 많이 얘기를 해 주었음에도 다른 사람의 얘긴 못들은 척하고 자기 말만 떠든 사람에게 문제가 있는 거죠.

어쨌든 오픈소스와 비전문가에 대한 토론을 할 만한 가치는 있다고 생각합니다.이 글타래까지 잠기는 일은 없기를...

bh의 이미지

jinoos wrote:
PS : 이미 잠겨버린 글타래에 얘기를 다시 끄집어 내는듯 기분이.. :oops: 하네요.
저는 누구를 비판하고 누구의 손을 들어주자는 말은 아닙니다. 다만 오래전 적수네 동네 에서처럼 윈도우즈 옹호글만 등장하면 답글이 수십여개씩 붙어서 그들을 몰아내기, 마녀사냥 하듯 하는것은(KLDP는 그래도 성숙한 토론공간 입니다. ^^) 오픈소스발전에 개미 눈물만큼도 도움되지 않는다는 생각에서 적었습니다.

저두 이글에 답글 다는것이 참 기분이 묘하네용.. @_@;;;;;
지누스님의 말에 어느정도 공감합니다.. 헥헥..

--
이 아이디는 이제 쓰이지 않습니다.

offree의 이미지

윈도우를 쓰는 사람들, 리눅스를 쓰는 사람들
아니 둘다 쓰는 사람들 .

다양할 것입니다.

그러다 보면 , 이쪽에 있는 좋은 것들이 다른쪽에도 있었으면 하는 바램이 있을 것입니다.

그 바램을 해결하려면.

1. 직접 만들거나, 기존것이 있으면 손을 보거나 해야 겠죠.
2. 직접이 어려우면, 다른 사람에게 권유 및 제안을 해서 해야 겠죠.
(이 때는 그에 대한 당위성 등에 대해 충분히 납득할 만한 설명을 해야 겠지요.)

3. 이것도 저것도 어렵다면, 그냥 쓰는 수 밖에 없을테고요.

그런면에서는 조금이나마 가능한 오픈소스 계열이 더 희망적이지 않은가 하는 생각이 듭니다.

이 글타래는 의미있는 글들이 되었으면 합니다. ^^

지난 글의 dummy999 님도 악의로 그런것은 아니라 생각이 됩니다.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

sugarlessgirl의 이미지

부족하지만 저의 의견을 말해보자면..

저는 패키징업체들이 좀 잘됬으면 하는 바램입니다.

모든 사람이 해커가 될 수는 없지요..
그런다고 오픈소스 개발자들이 돈벌자고 하는일도 아닌데 개인사용자가 쓰기 쉽도록 세부적인 부분까지 신경쓰면서 프로그램을 만들어야 할 책임까지 질 이유도 없지요.

중간에서 그런걸 잘 서비스 해주면서 돈도 좀 벌고 공동체에 지원도 하는 회사가 많아지면 좋을텐데,,

개인에게 운영체제를 파는건 별로 돈이 안되는 걸까요?
M$ 에서도 가장 많이 남겨먹는게 Windows 가 아니라 Office 라고 하던데..

오픈소스는 서로 협력하는 것이지..
내가 먹여줄께 하는 것은 아니니까요.

개발자들이 조금 더 친절해진다거나 하면 좋겠지만, 그들이 그것으로 돈을 벌지 않는 한은 그들도 바쁜시간 쪼개 만드는 것일 테니까요..

일반사용자를 대상으로 하는 패키징업체들이 제대로 된 수익구조를 찾거나,
일반사용자들의 의식이 변하거나 (두가지가 서로 관련이 있는 것일 수도 있겠네요..)

확실히 기업환경에서는 나름대로 리눅스가 성공했고,
이제 기업용 데스크탑 환경까지 노리는 것을 보면..
뭐 차츰 차츰 발전해나가면서 밑으로 내려오겠지요..

제 생각같아서는 학교의 역할이 크다고 생각합니다.
아예 중고등학교에서부터 리눅스를 가르치면 좋겠지만..-_-; 그건 무리일듯 하고..
대학교 최소한 컴퓨터학부에서 만큼이라도 가르칠때 M$ Tool 을 안쓰고 오픈 소스 프로그램을 사용하기만 해도 좋을텐데말이지요..

학교의 모든 컴퓨터에는 윈도우가 설치되어있고,
수업도 비주얼 스튜디오로 하고, 알아서 잘 구해다 집에 비주얼 스튜디오 깔아놓으라고 하는데.. 쩝

윈도우가 일반 사람들도 어느정도는 사용할 수 있게 만들어져 있기는 하지요..
(어디까지 어느정도..)

뭐 그거야 M$ 는 돈을 목적으로 하는 회사고, 돈이 많은 회사이기 때문인 것이니까 그렇지요..

결론.
오픈소스의 토대뒤에 패키징 업체같은 구조가 잘 세워져야 한다.
개인을 대상으로 하는 패키징 업체가 제대로 된 수익을 낼 수 있어야 한다.
학교.. 최소한 대학.. 만큼은 리눅스를 가르쳐야 한다.

logout의 이미지

jinoos wrote:

그렇다면 오픈소스역시 비전문가들에게 사용되것을 지향하고 있다고 할수 있지 않겠습니까? 그렇다면 좀더, 그들이 어려워 하는것이 무엇인지에 대해서 귀담아 듣고 필요한 핵심을 찾아내야 한다고 생각합니다.

가장 쉬운 방법은 돈으로 때우면 됩니다. 농담 아닙니다. :)

사실, 리눅스 위에 매킨토시 오에스 텐의 아쿠아 데스크탑 같은 레이어를 하나 더 올려서 상용으로 파는 것에는 아무 제한이 없습니다. 실제 또 상용 업체들이 소위 일반 사용자들의 수요 --- 달리 말하면 고객의 요구 --- 를 파악하기 좀 더 유리한 위치에 있구요. 오피스와 같은 패키지도 마찬가지로 상용 업체들의 참여가 좀 더 바람직합니다. 가격을 매개체로 해서 기술적인 지식이 전무한 사용자와 사용자의 요구를 모르는 개발자가 거래(trade)를 하는 것이죠.

그런데 문제는 아직까지 리눅스 사용자층이 그다지 넓지 않은 까닭에 업체들이 이렇게 뛰어들고 싶어도 채산성이 맞지 않다는 겁니다. 비유를 하자면, 신용이 없으니 돈을 못빌리는데 돈이 없으니 신용을 쌓을 방법이 없고 이것이 악순환이 되면 맨날 돈 빌릴 방법이 없다는... 그런 사이클과 비슷하지요.

이 사이클이 아주 암울한 것은 아닙니다. 조금씩이나마 푼돈에서부터 신용을 쌓아 나가고... 리눅스의 경우 조금씩이나마 사용자층을 늘려나가다보면 어느 순간 임계점을 통과하고나면 전체 사용자 네트워크의 크기가 상용 업체들도 충분히 뛰어들고 싶은 매력적인 규모의 시장으로 탈바꿈 하게 되는 것이지요.

그렇다면 리눅스 사용자층이 계속 늘어난다는 보장은 있을까요? 구체적인 데이터는 조사해 보지 않았지만 오픈소스 데스크탑은 지속적인 발전을 보이고 있습니다. KDE와 Gnome이외에 쓸만한 윈도우즈 대체용 데스크탑은 기껏해야 맥 오에스 텐 정도입니다. 즉, 필요한 것은 시간이겠죠.

게다가 요즘의 개발자는 스스로도 GUI 라든가 웹 페이지의 유저빌리티에 대해 생각을 하는 사람들이기 때문에 최소한도의 수준에서 리눅스 데스크탑용 어플의 발전은 기대해도 충분합니다. 그러니 중요한 것은 시간인 셈이지요.

그런 까닭으로 오픈 소스 개발자들이 좀 더 일반 사용자들의 요구를 파악하고... 좀 더 쓰기 쉬운 인터페이스를 고려하고... 굳이 그렇게까지 신경을 쓸 필요는 없는 겁니다. 개발자들은 그쪽에 관심이 있는 만큼만 신경을 쓰면 되는 것이죠. 굳이 이래서 리눅스는 안돼.. 가망이 없어.. 이럴 필요가 없는 것입니다.

최근 들어 보이는 경향중의 하나가 윈도우즈 오에스 위에 처음부터 크로스플랫폼을 고려해 개발한 모질라나 다른 오픈 소스 어플들을 올리는 것인데 이것도 재미있는 움직임이죠. 사용자 입장에서는 윈도우즈의 기존의 장점과 오픈소스 어플의 장점을 동시에 향유할 수 있으니까요. 느린 발걸음이지만 변화는 한단계 한단계 찾아오고 있다고 봅니다.

오픈 소스 데스크탑 쪽에서 개인적으로 좀 아쉬운 점은.... KDE 어플의 윈도우즈 포팅이 아무래도 윈도우즈용 QT에 요금을 부과하는 Trolltech의 라이센스 정책 때문에 오픈소스 개발자들에게는 부담이 있다는 것과 Gnome 어플의 윈도우즈 포팅은 아직 GTK+ for windows가 많이 미숙한 까닭에 윈도우즈 쪽 진입이 힘들다는 것입니다. (그렇다구 트롤테크가 윈도우즈용 qt를 공짜로 풀거나 GTK+ 프로젝트가 GTK+ for windows에 총력을 기울인다고해서 문제가 해결되는 것은 아닙니다.) 어쨌거나 이제는 오픈소스 데스크탑에서도 윈도우즈 시장을 넘볼 때가 되지 않았나 싶은데 어떤 부분에서부터 출발하는 것이 효과적일지는 아직은 미지수인 것 같습니다. 일단은 모질라의 선전에 많은 기대를 걸고 있습니다. :)

"I conduct to live,
I live to compose."
--- Gustav Mahler

perky의 이미지

오픈소스에 참여하는 매력은 아무래도 자기가 하고 싶은 일만 할 수 있다는 것입니다.
자기가 하기 싫은 일을 "사용자와 가까워지기 위해서" 해야하는 상황이 온다면
돈도 안 주는데 그걸 하라고 강요하는 것은 공산당입니다. :)

오픈소스에서 "사용자가 가까워지는" 경우는, 개발자 또는, 개발자를 지원하는 집단이
"하기 싫음"보다 "가까워지고 싶음"이 더 클 때 뿐입니다. 오픈소스 제품들이
영원히 사용하기 어렵다고 하더라도 하고 싶은 사람이 나타나기 전까지는 어쩔
수 없습니다.

사실 새로운 오픈소스 프로젝트를 시작할 때 가장 두려운 것은 사용자들의
요청입니다. 코딩하는 것도 재미있고 새로운 프로젝트를 시작하는 것도 재미있고
버그를 잡는 것도 재미있고, 또한 프로그램을 배포하는 것도 재미있죠. 근데
사용자들이 아무래도 문서를 요구하게 되고 같은 질문을 반복해서 하고, 좀 더 쉬운
인터페이스를 "패치 제공 없이" 요구하며, 사용에 있어서 발생하는 문제에 대한
지원을 요청하는 것은 좀처럼 하고 싶지 않은 일인 경우가 많습니다. 즉,
재미있는 휴식시간을 보내기 위해서 시작한 프로젝트가 나중에는 하기 싫은
일을 강요받는 일이 되는 경우가 많게 되는 것입니다. 그래서, 제 프로젝트 중
몇 개는 tar로는 다운 받지 못하게 막고, 가급적이면 쓸 마음이 안 나도록
받기 귀찮게 CVS로만 배포하는 것도 있습니다. ^^; (물론 받기 어렵게 만들면
소속감이 늘어나서, 패치를 제공하는 개발자로 편입되는 기대 사용자 비율이
늘어나는 장점도 있기는 합니다.)

결국, 통상적으로 재미가 없는 축에 속하는 작업인 UI의 완결성, 아주 드문 상황에서의
에러 대처, 보기 좋은 문서화 등은 그다지 많은 개발자가 참여하지 않게 되고
대부분의 경우에는 레드햇, SuSE, Ximian같은 대규모의 오픈소스
지원 회사의 조건부 고용이나 회사 업무로 진행 없이는 완성되기 힘든 작업이라고
볼 수 있습니다. 다시 강조하자면, 이런 경향은 물론 상업적인 프러덕트들을 많이 사용해
온 사용자들이 오픈소스를 처음 접할 때 가장 비판적으로 볼 수 밖에 없는
부분이기는 하지만, 참여 동기의 3대 요소인 3F (Fun, Fame, Fever) 중
하나도 없는 일을 하는 것을, 맛있는 것을 먹거나, 자거나, 재미있는 책을
보거나, TV를 보거나, 친구랑 놀거나 하는 일보다 좋아할 사람이 얼마나
있을지 생각해 보면 현실적인 요구가 아닙니다.

오픈소스 기반의 상업 프러덕트/서비스 들이 많이 늘어야 하는 이유가 바로
여기에 있습니다.

You need Python

차리서의 이미지

perky wrote:
오픈소스에 참여하는 매력은 아무래도 자기가 하고 싶은 일만 할 수 있다는 것입니다. 자기가 하기 싫은 일을 "사용자와 가까워지기 위해서" 해야하는 상황이 온다면 돈도 안 주는데 그걸 하라고 강요하는 것은 공산당입니다. :)

오픈소스에서 "사용자가 가까워지는" 경우는, 개발자 또는, 개발자를 지원하는 집단이 "하기 싫음"보다 "가까워지고 싶음"이 더 클 때 뿐입니다. 오픈소스 제품들이 영원히 사용하기 어렵다고 하더라도 하고 싶은 사람이 나타나기 전까지는 어쩔 수 없습니다.

사실 새로운 오픈소스 프로젝트를 시작할 때 가장 두려운 것은 사용자들의 요청입니다. 코딩하는 것도 재미있고 새로운 프로젝트를 시작하는 것도 재미있고 버그를 잡는 것도 재미있고, 또한 프로그램을 배포하는 것도 재미있죠. 근데 사용자들이 아무래도 문서를 요구하게 되고 같은 질문을 반복해서 하고, 좀 더 쉬운 인터페이스를 "패치 제공 없이" 요구하며, 사용에 있어서 발생하는 문제에 대한 지원을 요청하는 것은 좀처럼 하고 싶지 않은 일인 경우가 많습니다. 즉, 재미있는 휴식시간을 보내기 위해서 시작한 프로젝트가 나중에는 하기 싫은 일을 강요받는 일이 되는 경우가 많게 되는 것입니다. 그래서, 제 프로젝트 중 몇 개는 tar로는 다운 받지 못하게 막고, 가급적이면 쓸 마음이 안 나도록 받기 귀찮게 CVS로만 배포하는 것도 있습니다. ^^; (물론 받기 어렵게 만들면 소속감이 늘어나서, 패치를 제공하는 개발자로 편입되는 기대 사용자 비율이 늘어나는 장점도 있기는 합니다.)

결국, 통상적으로 재미가 없는 축에 속하는 작업인 UI의 완결성, 아주 드문 상황에서의 에러 대처, 보기 좋은 문서화 등은 그다지 많은 개발자가 참여하지 않게 되고 대부분의 경우에는 레드햇, SuSE, Ximian같은 대규모의 오픈소스 지원 회사의 조건부 고용이나 회사 업무로 진행 없이는 완성되기 힘든 작업이라고 볼 수 있습니다. 다시 강조하자면, 이런 경향은 물론 상업적인 프러덕트들을 많이 사용해 온 사용자들이 오픈소스를 처음 접할 때 가장 비판적으로 볼 수 밖에 없는 부분이기는 하지만, 참여 동기의 3대 요소인 3F (Fun, Fame, Fever) 중 하나도 없는 일을 하는 것을, 맛있는 것을 먹거나, 자거나, 재미있는 책을 보거나, TV를 보거나, 친구랑 놀거나 하는 일보다 좋아할 사람이 얼마나 있을지 생각해 보면 현실적인 요구가 아닙니다.


That's what I thought! :)

perky wrote:
오픈소스 기반의 상업 프러덕트/서비스 들이 많이 늘어야 하는 이유가 바로 여기에 있습니다.

그럼에도 불구하고 여전히 알기 힘든 부분이 바로 이 부분입니다. 의견이나 시각이 달라서 납득할 수 없다는 뜻이 아니라, 말 그대로 오픈소스 세계의 마인드 위에서 이런 '오픈소스 기반의 상업 프러덕트/서비스들이 어떤 구조와 체계로 돌아가는지'에 대한 정보가 너무 부족하여 잘 모르겠습니다. 언제 기회가 되면 S.u.S.E나 RedHat 같은 기업들의 수익 구조와 재야 오픈소스 개발자들과의 관계 등에 대해 좀 더 알아보고 싶습니다만, 지금 당장은 다음 주에 해야하는 세미나가 발등의 불이군요.

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

gang의 이미지

자유(또는 오픈) 소프트웨어는 공짜가 아닙니다. 사용자가 원하는 바를 충족받기 위해서는 비용을 지불해야 합니다. 그냥 공짜로, 자신이 원하는 기능이 없다고 욕할 수는 없잖아요.
소수의 개인이나 기업들이 여러가지 방식으로 이러한 비용을 지불하고 있습니다. (비용에는 금전적인 것뿐만 아니라, 특정 소프트웨어에 대한 feedback이나 관심 등등을 포함시켜 생각합시다) 그 결과가 비용을 지불한 이들에게 뿐만 아니라, 불특정 다수의 사용자들에게도 혜택이 돌아가고 있고요.

그럼, 비용을 지불하지 않은 사람들이 자유소프트웨어의 기능 개선을 요구할 권한이 있을까요? 당연 없습니다. 무작정 맘에 들지 않는다라고 불평하는 것은 공허한 혼잣말일 뿐이죠.

그럼, 돈도 없고 능력도 없으면, 소프트웨어 사용이 불편하더라도 그냥 조용히 죽어 지내야하는 것일까요. 그것도 아니라 생각합니다.

저는, 자유소프트웨어의 의미를, 소프트웨어의 공공성, 보다 넓게는 정보의 공공성이란 면에서 생각하고 싶습니다. 사람들이 소프트웨어(또는 정보)에 접근할 수 있는 최소한의 조건은 누구에게나 평등하게 사회가 제공해 주어야 한다고 생각합니다. 그런 의미에서 정부의 개입이나 자유소프트웨어를 지원하는 단체와 같은 사회 제도나 장치를 통하여 자유소프트웨어를 생산할 수 있을 것이구요, 사회 구성원들은 사용자 입장에서 그러한 활동에 참여함으로써 원하는 바를 요구할 수 있을겁니다.

그런데, 지금 그런 사회적 장치들이 미약한 것이죠. 하지만, 전혀 없는 것도 아니라고 생각합니다. KLDP 같은 공간도 어느정도 사용자와 개발자들의 이해를 연결시켜 주는 장소로 역할을 하고 있습니다.

여러 사람들의 서로 다른 생각들 속에서, 서로에게 이익이 될 수 있는 공동의 아이디어를 만들어 낼 수 있으면 좋겠습니다.

dhunter의 이미지

느리긴 해도 모두가 요구하는 방향으로 한발한발 나아가고 있다고 생각합니다.

대규모 리눅스 프로젝트의 경우 점점 인터페이스를 고려해야하는 대기업 (아범, 산, 오락후 등등) 들이 달라붙고 있고, 그들에게 물건을 파는 리눅스 회사 (빨간모자) 들도 노력하고 있습니다.

지난 몇년 사이 KDE와 GNOME 은 초기의 허접하고 무거운 윈도 매니저를 벗어나 제대로 독자적인 인터페이스 매니저로 성장했고, 시간이 흐르다 보면 모두가 요구하는 수준까지 오리라 봅니다.

서두르지 맙시다. 여기에서 두드린다고 소스 한줄 바뀌는게 아니잖아요. :)

차분히. 천천히 지켜보면서, 하나하나 피드백 해주는게 우리가 할 수 있는 가장 즐거운 일이라 보입니다.

from bzImage
It's blue paper

sangheon의 이미지

Quote:

중국에서 있던 일인데, 중국은 워낙 자전거들을 많이 타고 다니잖습니까?
보통은 장사하는 집 앞의 담벼락에 사람들이 자전거를 주차하고, 출근을 하는데, 이게 너무 심하더라는 것입니다.

집 주인은 자신의 담벼락에 자전거를 주차하지 말라고 온갖 경고문을 다 써봤습니다.
부탁하는 글을 붙여보기도 하고, 협박하는 글도 써보고... 그러나 소용이 없었답니다.

궁리에 궁리를 하던 중 어느 날 이 집의 주인에게 기발한 아이디어가 생각났습니다.
그리고 그날로 모든 자전거가 자취를 감추었다는데요.
그 명카피는 바로...

"자전거 공짜로 드립니다. 아무나 가져가십시오."

윤주협의 '성공 웹카피 전략' 중에서 (제우미디어, 63p)

TV의 화면 셋팅도 복잡해하는 사람도 많습니다. 예전에 과거 다기능 제품들보다 단순하고 조작이 쉬운 가전 제품이 훨씬 잘 팔린다는 기사도 실린적이 있습니다.

본업에 집중하는 것만으로도 스트레스가 많은 사람에게 '해커'의 기질을 발휘해 보라고 하면 그 기분이 어떨까요?

사용자에게 왜 윈도우를 쓰고 리눅스(유닉스)를 안 쓰냐고 말하기 전에 사용자의 입장에서 생각해 보는 것이 먼저라고 저는 생각합니다.

--

Minimalist Programmer

logout의 이미지

gang wrote:
자유(또는 오픈) 소프트웨어는 공짜가 아닙니다. 사용자가 원하는 바를 충족받기 위해서는 비용을 지불해야 합니다. 그냥 공짜로, 자신이 원하는 기능이 없다고 욕할 수는 없잖아요.
소수의 개인이나 기업들이 여러가지 방식으로 이러한 비용을 지불하고 있습니다. (비용에는 금전적인 것뿐만 아니라, 특정 소프트웨어에 대한 feedback이나 관심 등등을 포함시켜 생각합시다) 그 결과가 비용을 지불한 이들에게 뿐만 아니라, 불특정 다수의 사용자들에게도 혜택이 돌아가고 있고요.

그럼, 비용을 지불하지 않은 사람들이 자유소프트웨어의 기능 개선을 요구할 권한이 있을까요? 당연 없습니다. 무작정 맘에 들지 않는다라고 불평하는 것은 공허한 혼잣말일 뿐이죠.

그럼, 돈도 없고 능력도 없으면, 소프트웨어 사용이 불편하더라도 그냥 조용히 죽어 지내야하는 것일까요. 그것도 아니라 생각합니다.

저는, 자유소프트웨어의 의미를, 소프트웨어의 공공성, 보다 넓게는 정보의 공공성이란 면에서 생각하고 싶습니다. 사람들이 소프트웨어(또는 정보)에 접근할 수 있는 최소한의 조건은 누구에게나 평등하게 사회가 제공해 주어야 한다고 생각합니다. 그런 의미에서 정부의 개입이나 자유소프트웨어를 지원하는 단체와 같은 사회 제도나 장치를 통하여 자유소프트웨어를 생산할 수 있을 것이구요, 사회 구성원들은 사용자 입장에서 그러한 활동에 참여함으로써 원하는 바를 요구할 수 있을겁니다.

그런데, 지금 그런 사회적 장치들이 미약한 것이죠. 하지만, 전혀 없는 것도 아니라고 생각합니다. KLDP 같은 공간도 어느정도 사용자와 개발자들의 이해를 연결시켜 주는 장소로 역할을 하고 있습니다.

여러 사람들의 서로 다른 생각들 속에서, 서로에게 이익이 될 수 있는 공동의 아이디어를 만들어 낼 수 있으면 좋겠습니다.

오픈소스는 공공재의 성격을 많이 가집니다. 어떤이는 private provision of public goods 라는 표현도 쓰지요. 오픈소스는 공공재인데 이것을 조달하는 방법은 정부가 아닌 일반 개발자들의 노동으로 이루어지고 있으니까요.

어쨌거나, 오픈소스는 공공재의 성격을 지니기 때문에 정부가 오픈 소스 소프트웨어 개발에 뛰어들 수 있는 이유가 충분합니다. 여기서 조심해야 할 것이, 일반 공공재의 경우는 정부가 뛰어드는 이유가 "공공재의 시장 실패로 인한 사기업들의 공공재 공급이 충분하지 않기" 때문이지만 (그렇다고 정부가 공공재 생산에 뛰어든다고 시장 실패의 문제가 해결되는 것은 아닙니다만... 오히려 정부 실패가 더 무섭죠.) 오픈 소스의 경우 과연 오픈소스에서 시장 메커니즘이 실패하고 있는가... 에 대해서는 논란이 많습니다. 오픈 소스만큼 외부 효과를 효과적으로 활용하고 있는 경우가 없고, 원래 소프트웨어는 복사 비용이 0에 가깝기 때문에 이론상으로는 모든 사람이 마음대로 쓰는 공기같은 재화가 맞습니다. 오히려 수요측면에서보면 디지털의 특성을 가장 잘 살리고 있는 케이스가 오픈소스가 아닌가 싶을 정도이지요.

다만, 오픈소스도 공급쪽의 문제는 여전히 남아 있습니다. 원래 소프트웨어라는 재화의 특성이 그렇습니다... 첫 카피 개발에는 엄청난 비용이 들어가지만 배포는 무한대로 할 수 있거든요. 오픈 소스 개발은 전체적으로 그 엄청난 비용을 수많은 개발자들이 분산시켜 실제 개인 개발자가 감당할 수 있을 정도로 쪼갠다고 볼 수도 있는데 어떤 개발 프로젝트들은 쪼개도 비용이 많은 것들이 있습니다. 리눅스 데스크탑이나 유저 인터페이스의 문제는 오픈소스 개발자가 "사용자가 무엇을 필요로 하는지 잘 몰라서" 발생하는 문제라면 이런 문제들은 "개인 개발자가 뛰어들기에는 감당해야 할 비용이 너무 벅차서" 개발이 저조한 부분이 많습니다.

예를들어, 십년 넘어 끌고 있는 리눅스에서의 한글 폰트 문제도 그렇습니다. 이건 누군가가 폰트 용역 업체에 거액을 투자해서 한글 폰트를 만들면 끝입니다. 실제, MS나 애플과 같은 상용 오에스 업체들이 하고 있는 일이구요. 혹은, 기존에 개발되어 있는 괜찮은 폰트를 아예 배포권리까지 왕창 사서 뿌리면 되는 것이지요.

그런데 이 폰트 문제가 재밌는 것이.... 모두들 리눅스에서 자유롭게 쓸 수 있는 한글 폰트가 있으면 좋겠다고 생각하지만 아무도 지금까지 이 문제를 해결하지 못하고 있습니다. 백묵 폰트가 있지만 (이것도 미지리눅스에서 의지를 갖고 꾸준히 노력해주셔서 이만큼이라도 좋아졌습니다만) 아직까지 부족한 면이 많지요. 아마도 리눅스를 처음 깐 다음 한글 폰트의 모양새를 보고 다시 윈도우즈로 스위칭 하는 사용자들 한둘이 아닐겁니다.

사실 이런 문제에 정부가 뛰어들어줘야 합니다. 이런 문제는 오픈소스 방식으로는 해결이 무척 힘든 문제입니다. private provision of public good 에서 private provision이 비용이 너무 큰 까닭에 자원자가 안나서는 것이죠. 하지만 한글 기본 폰트 한두개 정도라도 무료로 배포된다면 전체 사회적으로는 높은 비용절감 효과가 기대됩니다. 이렇다면 이런데 정부가 참여자로 나서서 문제를 해결할 당위성이 도출 될 수 있는 것이지요.

또한 정부가 오픈소스에 뛰어들 수 있는 좋은 방법중의 하나는 네트워크의 창출입니다. 아예 정부가 사용자 네트워크를 수요 측면에서 창출해 버리는 겁니다. 다행히, 이쪽으로는 우리나라 정부도 생각을 많이 하고 있는 것 같습니다. 최근의 EBS 수능강의용 서버와 클라이언트를 리눅스쪽으로 구성해 보겠다는 소식은 무척 좋은 소식입니다. 디지털 시대에서 결국 부가가치의 원천은 네트워크일 수 밖에 없습니다. 사용자 네트워크가 일단 형성이 되어 있어야 개발자도 개발하는 보람이 있고 (그 보상이 명예든 돈이든 오픈소스든 상용이든 간에요.) 그렇게 되어야 소위 파이가 계속 커질 수 있는 것이거든요.

하지만 우리나라 정부는 아직까지 control에 약간 집착을 하는 경향이 있는 것 같습니다. 그런 까닭에 정부가 소위 공개소프트웨어와 관련한 정책을 내 놓으면 반응이 시큰둥하죠. de facto standard는 오픈소스가 아닌 상용 업체들 사이에서도 이제는 자연스러운 관습인데 가끔씩 표준 리눅스를 만들자와 같은 얘기가 정부쪽에서 흘러나오는 모습은 조금 안타깝지요.

그렇지만 그래도 버릴 수 없는 욕심(?)이 언젠가 상용 업체들이 리눅스에 뛰어들어 바꿔놓을 세상입니다. 정부가 오픈소스에 뛰어드는데는 결정적인 한계가 있습니다. 정부야말로 일반 사용자나 개발자들이 무엇을 절실히 필요로 하고 있는지 알려고 하는 유인체계가 없습니다. 그러나 상용 업체들은 이 정보를 항상 가격이라는 매개체로 알아낼 수 있거든요. (그런 면에서 오픈 소스쪽에서도 이제는 수요자가 필요한 기능이 오픈소스쪽 솔루션에 없다면 기꺼이 비용을 지불하고 사서쓰는 관습을 형성해 나갈 필요가 있습니다. 그래야 개발사들이 시장 판세를 보니 리눅스 플랫폼으로 개발해도 장사가 되겠구나 하고 생각을 하게 되고 이것이 상용 솔루션 개발로 이어지는 것이죠. 이런 면에서 보면 구미쪽에서 자꾸만 서비스서비스를 오픈소스의 비즈니스 주요 모델로 생각하는 것이 시장을 만들어 나간다는 측면에서 상당히 괜찮은 발상입니다.) 그렇기 때문에 오픈 소스에 상용 업체의 참여는 중요해 질 수 밖에 없는 것입니다.

글이 쓸데없이 길어졌는데.... 요약하자면 오픈소스에는 정부로, 사기업도 뛰어들어 할 수 있는 일이 무척 많습니다. 다만, 아직은 사용자 네트워크가 희박한 관계로 그러한 가능성이 살아나지 못하고 있습니다. 제가 보기에는 정부가 이 상황에서 사용자 네트워크를 늘여 나가는데 주요한 역할을 담당할 수 있을것 같고, 일단 사용자 네트워크의 임계점을 돌파하고 나면 상용 업체들도 오픈 소스 시장에 매력을 많이 느끼게 되겠지요. 어쨌거나, 여전히 미래는 희망적이고 중요한 것은 네트워크입니다. 리눅스를 오래 보아왔지만 이만큼 역동적인 발전이 지속되는 분야는 몇 되지 않습니다.

"I conduct to live,
I live to compose."
--- Gustav Mahler

dhunter의 이미지

http://bbs.kldp.org/viewtopic.php?t=38667&highlight=

뭐. 소프트웨어 회사는 나름대로 노력하고 있다는 예시일지도 모릅니다. ;)

from bzImage
It's blue paper

jenix의 이미지

eadgbe wrote:
제 생각같아서는 학교의 역할이 크다고 생각합니다.
아예 중고등학교에서부터 리눅스를 가르치면 좋겠지만..-_-; 그건 무리일듯 하고..
대학교 최소한 컴퓨터학부에서 만큼이라도 가르칠때 M$ Tool 을 안쓰고 오픈 소스 프로그램을 사용하기만 해도 좋을텐데말이지요..
학교의 모든 컴퓨터에는 윈도우가 설치되어있고,
수업도 비주얼 스튜디오로 하고, 알아서 잘 구해다 집에 비주얼 스튜디오 깔아놓으라고 하는데.. 쩝

정말 저와 같은 생각을... :shock:

공감입니다.

저는 왠만하면 소프트웨어는 사서 쓰는 편인데..

비쥬얼툴은 돈주고 살 엄두가 안나더군요. :oops:

약간 찝찝한 마음으로 거시기해서 슥삭해서 설치해서 숙제하고.. :oops:

주제와 별로 상관 없는 답글이었네요;;

---------------------------------------------------------------------------
http://jinhyung.org -- 방문해 보세요!! Jenix 의 블로그입니다! :D

병맛의 이미지

Quote:
제 생각같아서는 학교의 역할이 크다고 생각합니다.
아예 중고등학교에서부터 리눅스를 가르치면 좋겠지만..-_-; 그건 무리일듯 하고..
대학교 최소한 컴퓨터학부에서 만큼이라도 가르칠때 M$ Tool 을 안쓰고 오픈 소스 프로그램을 사용하기만 해도 좋을텐데말이지요..
학교의 모든 컴퓨터에는 윈도우가 설치되어있고,
수업도 비주얼 스튜디오로 하고, 알아서 잘 구해다 집에 비주얼 스튜디오 깔아놓으라고 하는데.. 쩝

우리 아이, 리눅스로 시작합시다. ㅡ.ㅡv

logout의 이미지

트랑 wrote:
Quote:
제 생각같아서는 학교의 역할이 크다고 생각합니다.
아예 중고등학교에서부터 리눅스를 가르치면 좋겠지만..-_-; 그건 무리일듯 하고..
대학교 최소한 컴퓨터학부에서 만큼이라도 가르칠때 M$ Tool 을 안쓰고 오픈 소스 프로그램을 사용하기만 해도 좋을텐데말이지요..
학교의 모든 컴퓨터에는 윈도우가 설치되어있고,
수업도 비주얼 스튜디오로 하고, 알아서 잘 구해다 집에 비주얼 스튜디오 깔아놓으라고 하는데.. 쩝

우리 아이, 리눅스로 시작합시다. ㅡ.ㅡv

아이디어 중의 하나가... 예전에 슬래쉬도트에서도 비슷한 글을 본 것 같은데 중고등학교 정식 교과과정 안에 리눅스가 아닌 유닉스 기초 명령어를 넣자는 것이죠.

유닉스 기초 명령어는 아주 논리적이고, 사용하기에 따라서 간단한 유틸 몇가지로 아주 강력한 기능을 발휘할 수도 있습니다. 특히 정규식과 같은 것들은 자라나는(?) 청소년들의 두뇌를 자극시키는데도 도움을 많이 줄겁니다. 뭐.. 선생님들 입장에서 시험 문제 내기도 쉽고, 채점하기도 쉬울거구요. :)

이런 이유로 중학교 기술 교과서에 유닉스 기본 명렁어를 컴퓨터의 기본 이해의 한 파트로 집어 넣는 것이 어떻냐는 아이디어를 예전에 본 적이 있습니다. 유닉스의 사용 그 자체가 상당히 저수준인 것도 맞구요. 게다가 유닉스는 리눅스 말고도 여러 종류이니 학교에서 정식 교과과정으로 채택해도 특정 업체를 도와준다... 이런 논란도 없을테니 금상첨화인 셈이지요. :)

근데 요즘 세상에 유닉스 명령어를 교육시킬 필요가 있다고 생각하는 학교 선생님들이 얼마나 될지도 의문이기는 하네요. :)

"I conduct to live,
I live to compose."
--- Gustav Mahler

bluetux의 이미지

제 생각에 많은 오픈 소스가 어찌 보면 완성도가 없어 보이는것은..

그 프로그램 자체의 완성도 보다는..

다른 상업적 어플리케이션에 비하여 UI Design 이 떨어져 서 일 경우가 많다고 생각합니다.
(UI디자인은 GUI 디자인 을 포함한 더 큰 개념으로 압니다.)

최근에는 어떤 제품(?)이던디 UI design 에 대하여 보다 폭 넓게 검토 되가 자체 가이드 라인을 만들어
사용자 편의성(?)을 좀더 제공 하려고 하는것으로 압니다.
또 그러면서도 이 UI 디자인의 효용성이 참 미묘해서 그 적용의 타당성이.. 또 쉽지만을 않고..

대표(?) 적인 예로 애플 과 M$ 사 둘다 UI 디자인쪽에 많은 $$ 를 투입하여 가이드 라인을 만들고
그에 따라 제품(?) 군을 출시한다고 합니다.

당연히 이것은 간단하게 개인 개발자(?) 에 한정되어 해결 될수 있는 문제가 아니라고 생각합니다.

제가 아는 한에서는 현재 gnome gtk 쪽에만 ui 디자인 가이드 라인이 있는데.. 정말 많이 부족한거로 압니다.

한번은 enlightenment 채널에서 ui 디자인 가이드 라인이 있냐고 물어 보았더니..
그런 질문 하는 사람도 생겼다고 좋아만 하는.. --;

리눅스 배포판 회사등 이 좀더 이 디자인 가이드라인을 잡는데 투자(?) 좀 했으면 좋겠다는 생각을 해봅니다..

----
개인적으로 오픈소스에 어떻게든 UI 디자인쪽으로 참여 할수 있을까 해서..
없는 돈(50 만원.. 흑) 모아 UI 디자인 과정을 한번 들어 보긴 했는데.. 쉽게 할수 있는 분야가 아니 더라구요.
(교육받으면서.. 자기도 내고 다니는 사람이 저뿐이더군요.. --;)

pinebud의 이미지

이전에 팜 어플을 개발해봤을때는 Zen of Palm 이라는 문서가 많이 도움이 되었습니다. 모바일에 한정된 경우라서 전체적으로 적용이 될지 모르겠지만 디자인까지를 포함한 전체적인 디바이스의 철학 같은 것이 있었습니다. 가장 기억에 남는 말은 "사용자는 모바일 디바이스를 사용하기 귀찮아한다"는 말입니다 -_-;

A rose is a rose is a rose..

bus710의 이미지

미래를 경영하라......라는 책에서,
디자인은 제품의 영혼이라고 까지 말하.......한다고 하더군요;
저도 어제 아는 분께서 추천을 해 주셔서 검색해 보니 나온 말입니다.
읽어보고 독후감 남기겠습니다.

akudoku.net Bob Marley - Burnin and Lootin

life is only one time

freecatz의 이미지


저도 그냥 저냥 비전문가가 되...네용..ㅜㅜ

언제쯤 전문가가 되려나..아흑~

---------------------------------------------------
1t의 생각보다 1g의 실천이 낫다.

pinebud의 이미지

오픈소스의 목적이 그저 코딩을 위한 코딩이라면 사용자를 고려하지 않아도 될 것 같습니다. 뭐. IT 전문가들이 회사서 남아도는 시간에 스킬도 올리고 다른 사람들 코드도 구경하기 위해서 오픈소스가 존재할 수도 있겠죠.
그보다 실제로 사용되고 사용자에게 가치있는 무언가가 되기 위해서는 코딩외에도 고려할부분이 많은 것 같습니다. 위에서 말씀하신 UI 시나리오같은 것도 예가 되겠죠. (조엘 책에 나온 만화중에 개발자를 위한 MP3 플레이어 UI 만화가 생각납니다 -_-;) 또는 요구되는 feature를 정하거나 프로젝트의 데드라인 관리도 오픈소스의 문제라고 생각합니다. 개인적인 생각입니다만 비지니스와 연계되어 비지니스에 사용되는 오픈소스 프로젝트가 제일 좋은 모델이 아닐까 싶습니다. 리눅스가 지금과 같이 발전 된 것도 값싼 유닉스 대용품이라는 비지니스 매리트가 있었기 때문 아닐까요? 오픈소스 참여하는 개발자는 일만하는 봉인가? 하는 생각이 들기도 하지만 오픈소스가 사용되면서 그만큼 고용이 늘어나거나 프로젝트 관련된 작은 일거리가 늘어나는 면은 있는 것 같습니다. gimp를 위해 만들어진 GTK가 상업적으로 더 성공하고 프로젝트 localization 관련 소일거리가 생기거나 하는 예가 있는 것 같습니다. 더 크게는 clutter나 gstreamer, gcc같은 경우도 상업적인 성공사례겠지요.

A rose is a rose is a rose..

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.