시장의 요구에 부응하기

bookworm의 이미지

아래 권순선님이 올리신 글(http://kldp.org/node/81263)에 약간 관련하여 쓰는 글입니다.

올리신 글 내용에 정작 오픈소스에 관한 글을 관심을 못 받고, 소란을 일으킨 사람을 뭇매질하는 글만 관심을 받는 부분에 대해 지적하였습니다.

그 부분에 대해 제 생각을 정리해 보겠습니다.

우선 KLDP에 올라오는 최근의 내용 다수가 실제 시장(리눅스 사용자)의 요구와는 다소 동떨어진 부분이 있다고 보여집니다.

요즘 리눅스 많이 씁니다. 모뎀으로 플로피에 넣어서 설치하던 시절과는 괘를 달리할 정도입니다. 문제는 사용처가 대부분 서버라는 것입니다.

실제 리눅스를 사용하는 대부분 사용자는 '업무상'의 목적으로 '서버'를 이용하는 것이지 데스크탑을 사용하는 것이 아닌 것으로 판단합니다. (이 문장을 리눅스가 데스크탑으로 쓰기 부족하다던지, 데스크탑으로 쓸 필요가 없다고 해석하는 일이 없었으면 합니다.)

그렇기에 사용자에게 관심을 끌만한 글은 데스크탑 보다는 서버쪽 글일 가능성이 높다고 생각됩니다.

거기에 더해 이제는 전문적인 SE가 아니더라도 서버 목적의 시스템 기본 셋팅은 개발자들 대부분이 할 줄 압니다. 그런 목적의 글과 책은 넘쳐나지요. 굳이 KLDP에서 찾을 필요가 없는 내용입니다. 책꽃이에 꼽힌 책을 펴면 나오니까요.

만약에 아래와 비슷한 내용의 오픈소스를 이용한 시스템 구축 방법에 대한 글이 나온다면 어떨까요?

'로그인 세션 천만개를 처리하는 클러스터링 세션 서버 구축방법'
'하드웨어 없이 구현하는 아파치 웹 클러스터링'
'MySQL 과 배포판별 궁합 및 벤치마킹'
'가용성 99.99% 에 도전하는 대단위 APM 서버군 구축법'
'프로젝트 기간을 30% 이상 단축시키는 오픈 소스 프로젝트 관리툴들'

현업에서 실무를 하면서 리눅스에 대해 좀 더 와닿는 정보를 갈구하는 사용자가 원하는 것들이 이런 것이 아닐까 싶습니다.

앞으로 KLDP 에서 이와 관련된 정보가 많이 오고 가야 한다고 생각합니다.

PS> 일부 회사(일부 개발자, 일부 사용자)에서는 저런 것을 구현하는 것에 대해 기술자산이라고 생각해서 혼자알고 기술장벽을 치려고 하는 것 같습니다. 안타까운 일입니다.

keedi의 이미지

아직도 리눅스 데스크탑 사용자가 별로 안늘었나보네요.
저는 리눅스 데스크탑만 쓰다보니...
사실 언급해주신 부분들은 크게 와닿지 않는군요. :-)

하지만 언급하신 아이템들은 흥미롭군요~

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

onion의 이미지

아마도 귀차니즘이 제일 강력한 원인(?)이 아닐까 싶습니다..-.-;
하지만 관심을 가질만한 item들이 언급하신 예제들과 가까울거라는 생각에는 동의합니다.
다만 저는 데탑으로서의 효용성이 주가되는 영업쟁이라... 흑..T.T

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

superwtk의 이미지

지식이나 정보를 문서화 하는것도 상당한 노력이 들어가는 일이죠...

--------------------------------------------------------------------------------
http://blog.superwtk.com

dhunter의 이미지

" 거기에 더해 이제는 전문적인 SE가 아니더라도 서버 목적의 시스템 기본 셋팅은 개발자들 대부분이 할 줄 압니다. 그런 목적의 글과 책은 넘쳐나지요. 굳이 KLDP에서 찾을 필요가 없는 내용입니다. 책꽃이에 꼽힌 책을 펴면 나오니까요. "

... 설마요. 당장 CentOS 4.4 에서 SMTPAUTH 구현하려면 죽을만큼 고전해야합니다. 정규화된 문서도 없고 있다고 해도 SMTPAUTH 의 구현의 폭이 굉장히 좁은 프로그램도 많아요. KLDP 에서 찾을수 있다면 나쁠거 없죠.

--
from bzImage
It's blue paper

from bzImage
It's blue paper

지리즈의 이미지

'로그인 세션 천만개를 처리하는 클러스터링 세션 서버 구축방법'
'하드웨어 없이 구현하는 아파치 웹 클러스터링'
'MySQL 과 배포판별 궁합 및 벤치마킹'
'가용성 99.99% 에 도전하는 대단위 APM 서버군 구축법'
'프로젝트 기간을 30% 이상 단축시키는 오픈 소스 프로젝트 관리툴들'

이런 생각하면 안되지만...
이곳에서 낚시 하려면 저런 제목이면 되겠군요...

링크도 아닌데, 클릭하고 싶은 충동이 마구마구 쏫아 오르네요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

ydhoney의 이미지

일단 "시장의 요구" 에 부흥하기 이전에 "사장의 요구" 에 부흥하는것도 바쁜 분들이 많다보니 그런것이 아닐까 싶은 생각도 듭니다. :-)
 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

alwaysrainy의 이미지

bookworm wrote:
일부 회사(일부 개발자, 일부 사용자)에서는 저런 것을 구현하는 것에 대해 기술자산이라고 생각해서 혼자알고 기술장벽을 치려고 하는 것 같습니다. 안타까운 일입니다.

축적된 기술자산이라고 생각하는 것이 아니라 정리해서 공개할
시간적 정신적 여유가 없는 것 같습니다. 이곳 게시판에 도배되는 글들이
KLDP의 본 취지와 동떨어져가는 이유 역시 마찬가지인 것 같구요.
변명 같지만.. ydhoney(호랑이 기운 캘러그??)님의 말씀처럼
"사장의 요구"에 부흥하기도 바쁘더군요. ㅡ.ㅜ

---------------------------------------
세계는 넓고, 할일은 많다.

---------------------------------------
세계는 넓고, 할일은 많다.

익명사용자의 이미지

'로그인 세션 천만개를 처리하는 클러스터링 세션 서버 구축방법'
'하드웨어 없이 구현하는 아파치 웹 클러스터링'
'MySQL 과 배포판별 궁합 및 벤치마킹'
'가용성 99.99% 에 도전하는 대단위 APM 서버군 구축법'
'프로젝트 기간을 30% 이상 단축시키는 오픈 소스 프로젝트 관리툴들'

이러한 내용은 꼭 리눅스에만 해당되는 것은 아니죠.
위와 같은 내용은 Solution Architect 가 보통 고민해야할 내용이고,
이에 대해서는 대부분의 하드웨어 벤더들이 나름대로의 White Paper
등을 제공하는 것으로 알고 있는데요.

윈도나 유닉스의 경우는 꽤많이 나와있고, 저런 내용이 워낙 경험치에
근거한 내용이다보니 실제 경험해본 리눅스 SE들이 있다하더라도,
회사에서 체계적으로 정리를 하도록 하는 프로세스가 없다면 그냥
개인 블로그 수준에서 끝나기 마련이죠.

결국, 리눅스의 한계라고 볼수 있는 '주인없는 상태'가 정보의 제공을
막고 있다고 저는 생각이 드는군요.

주인이 있는 솔루션은 기술자산으로 아예 막거나 아니면 적절히 필요한
고객에게 오픈하게 되어 있는데, 주인이 없으니 하고 싶으면 하는 거고
말고 싶으면 마는거죠.

몇년전에는 리눅스에서 주로 하던 저 일에 대해서 최근에는 오히려
윈도에서 저런 일에 대한 자료나 글이 훨씬 더 많다는 것도 아이러니죠.

요즘은 저런류의 일을 리눅스보다는 오히려 윈도에서 더 먼저 테스트해
보게 되다니...

권순선의 이미지

공감합니다. 그런 방향이 되면 좋겠지요. 그렇게 되면 실제로 현업에서 일을 하시는 분들에게도 도움이 될 것이고요.

그러나 문제는 방법입니다. 어떻게 하면 그런 방향으로 가게 할 수 있을까요? 예를 들면, SE 전용 게시판을 만들면 가능할까요? 실제로 어떻게 하면 될 것인지에 대해서도 좋은 아이디어 부탁드립니다...

ydhoney의 이미지

1. SE 전용 게시판

2. 개발자 전용 게시판

2.1 임베디드 개발자 게시판
2.2 블라블라
...

개발자가 아니어서 그런지 개발자 구분은 좀 힘들군요;;

일단 이 전용 게시판이라는 의미가 어떤 분들께는 장벽을 만드는것이 아니냐 라는 이야기가 나올수도 있을듯은 합니다만, 장기적인 KLDP의 가치를 높이는 좋은 방법이 될 것이라 생각합니다.

 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

권순선의 이미지

어떤 게시판을 더 추가하면 좋을지 계속 의견 부탁드립니다... 뭐 잘 안되면 나중에 다시 통합하면 되니까요.

기술별로 나누기는 좀 그렇고 제가 말씀드렸던 대로 직무별로 나누는게 좋겠다는 생각입니다. 리눅스 & 오픈소스가 적용되는 직무를 어떻게 효과적으로 나눌 수 있을까요? System & Network Engineer, Kernel & Hardware Engineer, Application SW Developer 정도면 될까요?

ydhoney의 이미지

일단 크게 나누는것이 Engineer 그룹과 Developer 그룹으로 나뉠 수 있겠고..

말씀하신 Kernel 은 Engineer보다는 Developer그룹의 성격이 있고

Hardware의 경우는 Driver 개발을 의미하시는것이 아니라면 그냥 SE나 NE의 범주에 속해버리는것이 아닐까 싶습니다. 만일 드라이버를 말씀하시는 것이라면 이 또한 Kernel Develop의 범주에 들어갈테고 말이지요.

일단 정말 간단한것이 Engineer 직무와 Developer 직무로 나뉘는것이겠지요.

개발자 분들은 단순 Developer 정도로 뭉뚱그려지는것이 어떠실지 모르겠습니다만, 엔지니어 입장에서는 Engineer 그룹 하나로 뭉뚱크려 통칭해도 크게 무리는 없다고 봅니다. 일단 엔지니어라는 직무의 특성상 한번 발을 들여놓으면 단순히 뭐 하드웨어만 한다거나, OS만 한다거나 하는것이 아니라 말 그대로 시스템 통합(SI)이 되어버리는 것이니까요.

물론 OSS라는 개념에서 생각할 수 있는 범주와는 약간 다를수도 있겠습니다만, 실제로 엔지니어 그룹의 특성상 운용하는 시스템이 OS건 어플리케이션이건간에 일단 OSS인가와는 별개 문제가 되어버리는 경우가 태반이기 때문이기도 합니다. 일례로 OS는 오픈소스라고 리눅스가 깔립니다만, 그 위에 올라가는 솔루션은 하다못해 오라클이 될수도 있고, SAP이 될 수도 있고, 거기에 붙는 다양한 하드웨어와 거기에 따르는 Kernel 구성은 오픈소스가 아닌 상용 툴 드라이버를 사용하는 경우도 많겠고 말이지요.

말이 길어졌는데 일단 엔지니어 카테고리는 그 하나로 족하다고 봅니다.

개발자 카테고리는 개발자 분들 내부적으로 정해주세요. 개발자 카테고리를 업무 특성이 아닌 OSS적 구분(이라고 하지만 실제로 유닉스 계열이라고 통칭될 수 밖에 없을..)으로 나뉘자면 Kernel Developer와 Service Daemon Developer, Application Developer 정도로 나뉘는것이 맞지 않을까 싶습니다. 뭐 굳이 나누자면 그렇다 이거죠.

일단 개발자 게시판을 하나 만들고, 그 아래에 작은 카테고리 구성(이게 드루팔에서 가능할지 모르겠는데, 예전 제로보드등의 보드 부류의 경우 게시판 하나를 또 세부 카테고리로 나눌 수 있어서 오른쪽 상단에 게시판 내 카테고리를 별도로 선택할 수 있는 버튼이 존재했었지요.)이 가능하다면 개발자 게시판 하단 카테고리를 위에서 언급한 세 종류로 나눠주는것이 좋을 것 같습니다만, 이건 의견일 뿐이니 너무 집착하지 마시고 편리하고 좋은 방법으로 나누어 주셨으면 좋겠습니다.

감사합니다.
 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

ydhoney의 이미지

데스크탑 사용자를 위한 전용 게시판이 하나 있었으면 합니다. 리눅스가 아무리 유닉스 기반으로 서버로서의 역할로써 발전을 해왔다지만 그래도 데스크탑 또한 무시할 수 없는 부분이고, 서버 운용을 위해서 엔지니어가 존재한다면, 데스크탑 이용을 하는 End-User 도 존재하기 마련이지요. 이미 리눅스에서의 데스크탑 사용 또한 큰 축으로 자리잡고 있는것이 현실이기도 하구요.

그리고 혹시 이 이야기가 나올까봐 먼저 선을 긋고 시작을 할 것이, 문득 생각해보면 지금 논의하고 있는 새로운 게시판들에 대한 내용들이 기존의 Q&A와 토론 토의 게시판에서 모두 커버가 가능한 부분이 아닌가 라는 생각을 하시는 분들도 있을 듯 한데, Q&A의 경우 일반 사용자가 궁금해하는 내용이 한정적이라는 데 문제가 있고, 토론토의 게시판의 경우 어떤 의제를 발의하고, 거기에 대한 전문적인 의견을 "아주 빡세게" 나누기에는 약간 부족한 점이 있고, 그것이 단순한 토론으로 남기보다는 좀 더 Professional한 수준으로 올라가는데 대한 한계성이 있고, 그 토론 내용들이 KLDP의 지적 자산으로써 남기에는 단순 토론게시판만으로는 부족한 점이 있을것입니다. 물론 기존의 토론 내용들이 프로페셔널하지 못하다거나, KLDP의 지적 자산으로 남을 내용이 아니다 라는 이야기는 아니니 오해 없길 바랍니다. :-) 단지 좀 더 체계적으로 정리되고, 거기에 대한 내용을 한 곳에서 간편하게 훑어 볼 수 있다면 좀 더 효율적이지 않겠는가 라는것이지요.

하다못해 업계의 관계자 분들도 이 정도의 프로페셔널한 내용들이라면 충분히 관심을 갖거나 도움을 얻을만한 부분도 있을것이고, 이에 따르는 부수적 효과도 기대할 수 있지 않겠는가 하는 생각입니다.
 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

권순선의 이미지

http://kldp.org/node/81596 에 따로 올렸으니 의견 주시기 바랍니다...

bookworm의 이미지

일단은 코어 그룹에서 적절한 주제나 문제를 설정하고 그에 관해 풀어나가야 할 각 요소들을 위키나 포럼을 통해서 해결하고, 이를 다시 총괄적으로 정리해서 하나의 문서로 만드는 작업이 필요할 것입니다.

방법은 간단하지만, 코어 그룹에서 총대를 맬 서너명의 인물이 필요하다는게 문제입니다. 일단 코어 그룹에서 멍석을 깔면 수가 적던 많던 누군가는 끼어들겁니다.

여러차례 강조드리지만 결국에는 사람이 문제입니다. ㅎㅎ.

--

B/o/o/k/w/o/r/m/

B/o/o/k/w/o/r/m/

권순선의 이미지

현재는 그러한 작업을 발의하고 관리할 만한 여건이 되는 분이 없습니다... 관련해서 향후 의견은 http://kldp.org/node/81596 에 올려 주시면 감사드리겠습니다.

1day1의 이미지

KLDP 가 좀 진정(?)이 되었군요. ^^ (한동안 글쓰기를 안했는데, 이제 좀.. )

위키와 kldp.net 이 활성화 되는 방법은 없는것인가요?

요즘 커뮤니티내에서 얼마나 심도(?)있는 문서들이 나올 수 있을지 모르겠습니다.(꼭 KLDP 를 이야기하는 것은 아님)
그런것들을 할 만한 개발자들은 블로그 같은 자신만의 공간을 가지고 있는 경우가 많은 것 같습니다.

좀더 현실적(?)으로 kldp 에서 http://dna.daum.net/lens/ 처럼 개발관련 블로그들을 모아서 보여주는
코너가 있으면 좋겠습니다. (planetplanet 같은 것을 도입하면 유지보수도 그리 어렵지는 않을 것 같습니다.)
http://dna.daum.net/lens/ 도 괜찮긴 한데, 뭔가 좀 덜 geek(?) 해서 좀 그렇습니다. ^^

이것이 단순히 메타블로그 를 운영하자는 것 보다는 KLDP 블로그의 적은 포스팅수를 보완하면서
새로운 글을 주제를 바탕으로 토론등을 이끌어 낼 수 있을 듯 합니다.
저도 사실 KLDP 블로그에 글쓰는 것은 부담도 되고 한편으로는 불편하기도 합니다.

digg 같은 시스템을 도입하면 좋겠지만, digg 시스템 자체가 아직 국내사정에는 별로 안 맞는 것 같습니다.

이상. 의견이라기보다는 지나가는 생각이었습니다. ^^

F/OSS 가 함께하길.. (F/OSS서포터즈 : [[FOSS/Supporters]], [[FOSS/Supporters/Group]]) - 추천 프로젝트 : 추천하기 힘드시나요? 추천 꾹 눌러주세요! -

F/OSS 가 함께하길..