KLDP.net 개발자 경진대회 예정(상품: HHK)

흠. -_- 개인 개발자에게도 참여의 기운이 일어나길 바라겠습니다...

어느 시기에 시작하시게 될런지 궁금할 뿐입니다. -_-a

(시간이 너무 빠르면 준비도 못하는데...)

그래도 단기간에 개발에 착수한다는 것도 어려운 일일듯 싶습니다.

주제와는 관계없는 내용입니다만

kldp.net 에 다국어 지원이 되는가보군요.

로케일을 일본어로 맞추었더니, 메뉴가 일본어로 나옵니다 :D

근데, 한국어 메뉴는 없나요?

제가 잘못 이해했는지는 모르겠습니다만, verotas 님의 "부정적 피드백 강화"는 피드백의 "내용이 프로젝트에 부정적"인 것을 의미한 것은 아닌 듯 합니다. 사용자의 응답이 없고, 개발자는 의욕을 잃고, 사용자는 다시 물어볼 곳을 찾지 못하는 식의 전개를 의미하신 게 아닐까요.

부정적 피드백은, 프로젝트에 적대적 혹은 그밖의 다른 부정적 피드백 혹은 피드백이 별로 없는 그런 성향 모두를 포함합니다.

제가 언급한 부정적 피드백은 한가지 예를 든것이고요.

또한, 위에서 제가 언급한 부정적 피드백에 대한 적절한 대응에 대한 얘기는 제가 쓴것 처럼 쉽게 풀리거나 할 리 없겠지요.

제가 저 부분 쓰면서도 긴가민가 하면서 썼는데, 제가 의도했던 건 raymundo 님이 읽어주신 게 맞고, 그렇게 보면 그냥 "부정적 강화"라는 용어를 써야했던게 맞는거 같습니다. 단지 "부정적 강화"(negative reinforcement)라는 용어가 이 경우에 적절한지에 대한 확신이 부족하다 보니 어설프게 "피드백"을 추가해서 "부정적 피드백"(negative feedback)으로 읽히는 요소를 제공하게 돼버린 것 같습니다.

박원규 님께서 말씀하신 부정적 피드백에 대한 부분은 저도 거의 100% 동의하는 부분입니다. 프로젝트 운영하는 입장에서 욕이라도 좋으니 메일 좀 받아봤으면 좋겠다 싶은 순간들이 분명히 생기죠. 메일링 리스트 가입자가 그래도 100명은 넘어가는 유서 깊은 프로젝트를 넘겨 받아 사실상 '죽음'에 가까운 상태로 만들어본 경험이 있어서 그런지 저런 얘기를 들으면 사실 너무 가슴이 아픕니다. T_T

p.s. 박원규 님, 죄송합니다. 한다던 코딩은 제쳐두고 여기와서 놀다가 들켜버렸네요 ^^;;

영어권 사용자들은 영어로 보입니다.
(HTTP헤더의 preferred language)

이미 제가 하고 싶었던 얘기는 대부분 했다고 느끼기 때문에 사족이 될 가능성도 없지 않지만, BBS라는 매체 특성상 얼마나 기다려야 다시 비슷한 얘기를 하게 될지 기약이 없으므로 일단 여기서 몇 가지 더 짚어 보도록 하겠습니다.

1. 말만 많은 녀석 같으니라구

"고양이 목에 방울 달기"에 대해 한국 사람들이 가지는 유난한 혐오증(?)은 꼭 이런 주제가 아니라도 여러 곳에서 논란거리가 됩니다. 이론과 실천에 관련된 논쟁이야 역사상 어느 나라에서도 있어왔던 것이지만, 조선시대 성리학 관련 논쟁부터 해서 실사구시를 내세웠던 실학 사상, 일제 강점기 시대와 독재정권 시절을 거쳐 강화된 지식인-먹물들에 대한 비하, 1980년대 소위 현장-이론 논쟁까지, 하나하나 따져보면 참 구구절절하다 싶을 정도로 소위 "말만 앞세우는" 것에 대한 비하가 뼈 속 깊이 체화돼 있다 싶습니다.

얘기가 좀 거창해지는 감은 있지만, 제가 이야기 하고 싶은 것은 권순선 님께서 말씀하신 것이 혹시 개인적인 경험에 비춰서 어쩔 수 없는 것이다라는 식으로 비칠 위험이 있기 때문에, 그게 그다지 특이하거나 특수한 상황에서 비롯된 성향이라고 보긴 힘들다는 겁니다.

쉽게 얘기해서, 동서고금을 막론하고 한쪽에서는 다른 쪽을 말만 앞서는 놈들이라고 욕해 왔고 그 반대편에서는 머리에 든 것도 없는 것들이 하고 욕해 왔다는 겁니다.

그렇다고 해서 개인적인 성향이 독재를 즐겨하기 때문이라고 하는게 더 나으냐 하면 글쎄요, 제가 보기엔 오십보 백보입니다.

이런 얘기가 나왔을 때 가장 난감한 것은, 별로 더 토론할 여지가 없어진다는 것이겠죠. 내가 이런 걸 겪어서 이렇고, 내가 원래 이렇다는데 대체 남이 무슨 얘길 더 하겠습니까?

2. 다시, 소위 "위임"에 대해

제가 보기엔, 저도 뭐 워낙 흔히 겪는 일입니다만, 제가 얘기하는 "위임"과 권순선 님께서 얘기하시는 "위임"은 전혀 다른 것에다 같은 이름을 붙이는 격인 것 같습니다.

현재 운영하고 있는 서비스 들에서 어떻게 위임을 했는지 자세히 설명하셨지만, 조금 솔직히 얘기하자면, 제가 얘기했던 "technical한 권한과 social한 권한을 혼동"하는 오류를 고스란히 범하고 있다고 밖에 보이지 않습니다.

"혼자서 그많은 사이트들을 다 운영하시다니 정말 대단하시네요."하는 얘기를 듣는데 실제로는 별 것이 없다고요? 그걸 자랑하실 게 아니죠.

저는 이 스레드에서 논점이 권순선 님 개인이 얼마나 힘드실까 어려우실까 이런 걸 걱정해 보자는게 아니라고 생각합니다. 다만, 1996년으로 돌아가서 백지에서 출발을 할 수는 없으니 그간 KLDP라는 사이트가 이뤄놓은 성과를 기반으로 해서 뭔가 해보자 라는 얘기가 나왔고, 그 해보자는 뭔가에 대해 저도 관심이 있기 때문에 이렇게 글을 적고 있는 거라고 생각합니다.

KLDP가 더이상 1인 프로젝트가 아니고, 아니어야 한다고 저는 굳게 믿습니다만, 과연 권순선 님도 그렇게 생각하시는지 궁금하군요.

3. 참여를 유도하는 것은 어렵고 마케팅은 쉽다?

윗 글을 읽으면서 알 수 있는 것 가운데 하나는, 권순선 님께 사이트 운영이라는 것은 남들이 생각하는 것보다 훨씬 쉬운 일이고 (왜냐하면 잘 하는 일이니까), 참여를 유도하는 것은 생각보다 쉽지 않은 일이라는 (왜냐하면 잘 안됐으니까) 점입니다. 세상에는 그것과 정반대인 사람들도 있게 마련입니다. 만약 이 점을 인정하신다면, 답은 간단합니다. social engineering을 더 잘 할 수 있는 사람이 되면 됩니다. 그러나 지금 말씀하시는 내용으로 봐서는 별로 그러고 싶지 않다는 걸로 들리는군요.

제 생각에는, 앞서 언급된 개발자에게 필요한 소양에도 비슷한 부분이 있습니다. 나는 코딩을 좋아하지만 테스트나 문서 쓰는 건 잘 못하니 (싫어하니) 누군가 그걸 해주면 참 좋겠다, 라는 생각으로 자기가 연습 삼아 만드는 프로그램을 떡하니 올려 놓고 관심 가져 주세요, 하면 좋아라 하고 달라 붙어서 테스트 해주고 문서 써주고 할 사람이 누가 있겠습니까? 하지만 SF.net 이나 KLDP.net 이나 대체로 새로 프로젝트 시작하는 사람들은 그러는 경우가 많습니다. 왜일까요? 대체로, 자기가 하고 싶은 일은 남들도 하고 싶어하기 쉽고, 자기가 하기 싫은 일은 남들도 하기 싫은 경우가 많다는 평범한 사실을 간과하기 때문입니다. 해결책은? 역시 간단합니다. 자기는 코딩하는게 좋고 그것만 하고 싶다면, 프로젝트를 잘 관리할 수 있는 사람에게 그 역할을 넘기고 코딩만 하는 거죠. 아니면 자기가 프로젝트를 잘 관리할 수 있는 사람이 되어야 합니다.

그리고 저도 마케팅은 문외한이라고 못박아 놓은 주제에 할 얘긴 아니지만, 마케팅을 다른 사람이 도와주거나 아이디어만 빌려주면 그냥 수행할 수 있는 거라고 생각하시는 동안은, 뭐, 좋은 결과가 있기를 바랍니다. "그렇지만 솔직히 큰 기대는 하지 않고 있습니다."

4. KLDP는 문서화 프로젝트?

마지막 얘긴 조금 혼란스럽기까지 합니다. KLDP에서 D가 문서로만 해석되지 않고 개발로도 해석되면 좋겠다고 해서 약어 해설까지 안 다시던 분이, 정작 개발 관련된 얘기는 소프트웨어 개발 프로젝트를 진행하는 사람이 아니기 때문에 하기가 적절치 않다?

시비를 걸자는 건 아니지만, 이런 건 KLDP라는 사이트가 지향하는 가치에 대해 불필요한 오해를 줄 수 있기 때문에, 좀더 조심스럽고 가능하다면 일관된 입장을 표명해 주시면 좋겠습니다.

위에서는 이미 문서화 프로젝트 주 도구로 채택한 WikiWiki 관리를 다른 분에게 위임했다고 얘기하지 않으셨나요? 그렇다면 문서화 프로젝트를 진행하는 사람은 더이상 권순선 님이 _아니어야_ 얘기가 앞뒤가 맞습니다. 문서화 프로젝트로 출발했지만, 그 프로젝트는 다른 사람이 맡고 있고, 앞으로 KLDP라는 사이트는 문서화를 포함해 사용자/개발자를 포괄하는 커뮤니티로 만들고 싶다고 하는 거 아닌가요? 그렇다면 권순선 님께서는 그런 커뮤니티를 전체적으로 이끌어갈 방도를 고민하는게 맞습니다.

요약해서 다시 여쭤보죠. 현재 문서화 프로젝트 관리자는 누구인가요? 만약 그게 본인이 아니라면, 그 (위임 받은) 당사자도 그렇게 생각을 하고 있나요? 그렇지 않다면, 그건 "위임"이 아니라 그냥 권한 (또는 책임) "분산"일 따름입니다.

KLDP는 문서화 프로젝트고 나는 그 관리자다, 라고 아직도 생각하신다면 제가 이 스레드에서 했던 모든 얘기는 별로 할 필요가 없었던 얘기가 될 겁니다. 그러지 않기를 바랄 뿐입니다.

5. 맺으며

써놓고 보니 조금 흥분해서 글을 적은 감이 없잖아 있습니다만, 하고 싶은 얘기를 한 번은 솔직하게 쓰는 것도 필요하다고 느끼기 때문에 그냥 올리도록 하겠습니다.

제가 KLDP가 지금까지 이룩한 "성과와 한계"라고 표현했던 것을 관례적인 수사로만 치부하지 마시고, 부디 성과에 만족하지 말고 한계를 극복해서 발전해 나가는 KLDP가 되기를 기원합니다.

마지막으로, 기우이기를 바랍니다만, 이 글이 이래라 저래라 하는 걸로 받아들여지지 않았으면 좋겠고, 그냥 제 삼자가 바라본 관점 가운데 하나 정도로 객관화해서 이해해 주시기를 부탁드립니다.

혹시 제 글을 읽는 분 가운데 어떤 분이라도 기분이 나빠졌다거나 비난 받는 느낌을 받았다면 그건 전적으로 부족한 제 글 재주 때문이니 너그러이 용서해 주시고, 미천한 표현력 때문에 잘 드러나지 않았을지 모르는 속뜻을 조금이라도 헤아려 주시기를 간곡히 부탁드리면서 글을 맺겠습니다.

음.. 결국 조심한다고 했는데도 걱정했던 일이 벌어졌군요. :-( 제가 사실 어릴 때 글쓰기를 좀 못된(?) 방식으로 배워놔서, 나이 먹고서도 잘 안 고쳐지기 때문에 고생하는 경우가 많습니다. 그걸 감안하고 적는다고 적었는데도 상당히 offensive하게 느끼셨나 보네요. 정중하게 사과를 드립니다.

다시 한번 해설(?)을 하자면, 제가 "그걸 자랑하실 게 아니죠"라고 썼던 건 뭐 그게 자랑이라고 얘길 하느냐라는 얘길 하려던게 아니라, 그만큼 들이는 시간을 줄일 수 있는 방책을 마련했다면 그것 자체는 좋은 일이지만, 그 다음에 남는 시간과 관심을 특정한 방향으로 집중할 수 있어야 결과적으로 좋은 일이 될 수 있지 그렇지 않다면 그냥 남들보다 효과적으로 일을 할 수 있다는 것을 증명할 수 있을 뿐인데, 이 부분에 대해 권순선 님이 지금까지 대체로 탁월한 능력을 보여주셨다는 것을 부인할 사람은 그다지 많지 않을 것입니다. 즉, 지금까지 이룩한 성과에 대해 가타 부타 할게 아니라 현재 부딪히고 있는 한계가 어디에 존재하며 그것을 어떻게 해결할 것인가에 더 초점을 맞춰야하지 않겠느냐는 얘기를 하고 싶었던 것입니다.

그리고 마지막에 글 올리기에 대해서는 제가 적은게 지나친 확대해석으로 보일 여지가 있었다는 점 인정하겠습니다. 저도 글을 쓰면서 길어지다 보니 아래 위로 요점이 흩어지고 해서 걱정스러웠는데, 결정적으로 인용을 왜곡하는 잘못까지 저질러 버렸군요. 이 부분은 전적으로 제가 잘못했습니다. (_ _)

그렇다고 해서 제가 그 뒤에 딸린 얘기까지 충동적으로 한 건 아니고, 최근 KLDP를 오가면서 이런 저런 글을 보고 또 벌어지는 사건들을 구경하면서 간간히 느꼈던 개인적인 느낌 가운데 일부를 적은 것은 맞습니다.

어쨌건 이 부분에 대해서 마음이 편치 않으셨다니 제가 의도하지 않은 부작용을 안겨 드린 것 같아 죄송합니다. 다만, 이 부분은 제가 앞선 두 글에서 "위임"에 대해 언급한 것과 연관시켜서 이해해 주시면 고맙겠습니다. 그 부분만 제대로 전달이 됐다면 제가 글 올린 보람이 조금이라도 있을 것 같네요.

현재 KLDP에 대해 대체로 제가 느끼는 것은, KLDP가 어떤 과도기적인 시기를 지나고 있는 것 같고, 좋은 역할 모델과 운영 방식을 찾아내어 좀더 scalability를 키우는게 중요한 목표가 될만한 단계에 온게 아닌가 하는 것입니다.

KLDPWiki에서 관련 페이지를 읽어 보면 불과 몇 달 사이에 권순선 님 본인이 했던 얘기들과 표현했던 생각들도 바뀌어 나가고 기존에 정했던 방침을 수정해서 적용해 나간 일들이 기록에 남아 있는 것을 볼 수 있습니다. 단적으로 사이트 이름부터 해서 말이죠. 제가 얘기하는 변화나 과도기라는 것들은 그런 과정을 통해 변화하고 발전해 나가는 것을 지칭하는 것이고, 현재 뭔가가 크게 잘못되고 있으니 이렇게 또는 저렇게 해야 한다는 식으로 얘길 하려는게 아니라는 것을 밝혀 둡니다.

저도읽어봤는데.. 뭘어떻게 평가할지가 의문이군요 그에따라 참여할수도 있고 안할수도 있습니다. 회사업무때문에 사실상 시간내기 어렵거든요..
그래서 한가지 의견을 내면..

코딩이 약 50Line 로 구현가능한
어떤 로직구현을 최적화구현한 프로그램을 선정하는것입니다..
예를들자면.. 솟수구하기.프로그램..같은..

하나의로직에 대해 깊이있게 고찰할수 있고 후배들에게 정석적인 길을 안내할수도 있겠죠..

평가는 몇가지기준을두는거죠.. 속도, 리소스, 코딩의 간결함, 등..
물론 속도와 리소스에는 비중을 좀두어야겠지요..

속도와리소스는 답이 딱나오겠네요...
코딩같은것은 보기좋은..ㅡㅡ; + 라인수.ㅡㅡ; 등인데 좀모호하니...
점수의 비중을 낮추어 주는식 ..( 속도 총점200, 리소스 총점100, 코딩총점30점 )

저는 프로그램대회 같은 것은 반대입니다.
코딩 테스트 같은 것은 실력을 테스트 할 수 있을런지는 모르지만 열정을 테스트 할수는 없거든요.
우리나라에서는 왜 프로젝트가 안되느냐라는 물음에 실력이 없어서라고 답을 하면 안 그렇다고
대답하실 분들이 많을 겁니다.

사실은 열정이 없어서 일겁니다.

순선님이 이런 이벤트를 준비하는 목적도 우리나라에서 오픈소스 프로젝트의 활성화를 위한 것이란
점에서 열정을 테스트 할수 있는 방향이 되었으면 좋겠습니다. 코딩 실력 테스트는 정말 프로젝트
진행에 별다른 도움이 되지 않는 것 같아서 그렇습니다.

실력이 서 말이라도 커밋해야 보배로군요.

차라리
버그리포팅을 얼마나 많이 했는지.
commit 한 코드가 얼마나 많은지.
feature request를 얼마나 많이 했는지.
패치를 얼마나 많이 만들었는지.
진행하는 프로젝트에 얼마나 많은 릴리스가 존재하는지.

이런 것들이 좋겠다 싶습니다.