'Essay'에 해당되는 글 86건

  1. 2012.11.09 error value global vs. module specific
  2. 2012.09.12 왜 구글 플레이(안드로이 마켓)에는 유투브 다운로드 앱이 없는가... 에 대한 개인적인 생각...
  3. 2012.07.31 두 가지 SW Branch정책에 대한 단상.
  4. 2012.07.18 회사내에서 추친하는 직원들 기술 교육의 효과가 미미한 이유에 대한 생각.
  5. 2012.06.07 R&R(Role And Responsibility)의 범위의 유연성에 단상
  6. 2012.02.14 RSS list... + RSS icons ^^
  7. 2012.02.13 [Essay] 리더로서 자연스럽게 팀의 업무 상황 파악하기...
  8. 2012.02.02 [Essay][시사] 나꼼수에 대한 기성언론의 보도 형태에 대한 비판...
  9. 2011.12.23 [Essay][시사]진정성이 중요한 이유...
  10. 2011.12.23 [Essay] 개인이 자체 개발 SW를 회사에 공개하지 않는 이유...

error value global vs. module specific

Essay/Software 2012.11.09 14:41

 소프트웨어가 커지다 보면, 자연스럽게 OOP개념들을 집어 넣을 수 밖에 없고 - 그렇지 않으면, SW 유지보수가 거의 불가능 하다. - 각 컴포넌트/모듈들을 독립적으로 구현하기 위해서 고민하게 된다.

 각 모듈이나 컴포넌트가 독립적일수록 재사용성이 높아지고 모듈간 의존도가 줄어들게 된다.

 그런데, 문제는 이렇게 서로 독립적으로 만들다 보면, error value들 역시 독립적으로 선언해야 하게 되는데, 이게... 좀... 거시기 하다.

예를 들어, 모듈 A, B, C가 있을 때, A -> B -> C 이런식으로 C가 B를 reference하고, B가 A를 reference하는 경우, C와 B는 각각 내부 구현을 숨기기 위해서, B와 A의 error value를 노출 시킬 수 없게 된다. 따라서, B는 A의 error value를 B자신의 value로 mapping해야 하고, C또한, 이렇게 mapping된 B의 value를 다시 C자신의 value로 mapping해야 하게 된다.

 쩝... overhead의 chain effect라 불릴만 하다.

그래서 많이 하는 방법이, 상당히 자주 사용되는 error value는 global하게 공통적으로 정의하고 - ex. invalid parameter, out of memory 등등 - 세부적인 것들에 대해서는 모듈 specific하게 정의하는 것이다.

예를 들면...


common_error.h

enum {

COMMON_ERR_01 = 0,

COMMON_ERR_02,

...

LIMIT_COMMON_ERR,

CUSTOM_ERR_BASE_OFFSET,

};


module1.h

enum {

MODULE1_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE1_ERR_02,

...

};


module2.h

enum {

MODULE2_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE2_ERR_02,

...

};


 음... 꽤나 괜찮은 해결책으로 보인다. 아니, 현재까지 생각으로는 현실적으로 가장 좋은 해결책으로 보인다.

 그렇지만, 여전히 몇 가지 문제점이 존재한다. 먼저, error value의 return type을 그냥 int 를 사용해야 하는데 - 공통된 error value의 type을 정의할 수 없다 - constant value는 inline으로 코드에 삽입되기 때문에, debugging시에 썩 좋지 못하다는 문제가 있다. 또한, return type이 그냥 int 라 code readability도 썩 좋지 못하다.  또한, global common error code가 module내에서 사용되므로, 이 모듈을 전혀 다른 SW에 porting할때, common error 부분을 해당 SW에 맞게 수정을 가해야 하는 문제도 있다.

 그렇지만, overhead와 재사용성 양쪽을 균형있게 고려한, 충분히 훌륭한 방법임에는 틀림없다.


음...

 혹시 다른 좋은 아이디어가 떠 오르면... 다시 posting하기로 하고...

신고
Trackback 0 : Comment 0

왜 구글 플레이(안드로이 마켓)에는 유투브 다운로드 앱이 없는가... 에 대한 개인적인 생각...

Essay/General 2012.09.12 18:18

‎"유투브에서 동영상을 다운로드하는 앱들이 인터넷을 찾아보면 널렸는데 왜 마켓에는 없을까..."라는 의문에서... "구글이 자기들 이익을 위해서 그렇게 했다..." 라고 생각했었는데... 오늘 다시 한 번 곱씹어 보니 다른 결론을 내렸다.

유투브의 동영상의 소유권은 구글에 있지 않고, 업로더에 있다고 알고 있다.
그리고 유투브는 소유권자의 동의를 얻어 그 동영상을 스트리밍 서비스 하는 것이고...

그런데, 원칙적으로 "소유권이 없는 컨텐츠를 다운로드해서 보관하고 있는 것 자체는 불법이다."라는 관점에서 보면... 유투브는 업로더에서 스트리밍 서비스에 관한 동의만을 얻은 것이기 때문에, 구글이 다운로드하는 수단을 어떠한 방법으로든 제공한다면, 업로도(소유권자)와의 계약(? - 이걸 계약이라고 말한다면...)관계에서 문제의 소지가 있을 것 같다.


따라서, 마켓에서 유투브 동영상을 다운로드 가능하게 하는 앱을 서비스 한다면, 그 자체가 소위 "수단"을 제공하는 것이라고 해석될 수도 있지 않을까? 이런 문제 때문에 구글이 마켓에서 유투브 다운로드 프로그램을 없애 버리는게 아닐까?

구글이 자신들의 이익때문에 그러는게 아니라, 컨텐츠 소유권자의 권익 보호를 위해서 그러는거다... 라는 긍정적인 방향에서도 볼 수 있겠다....

한편, T-store에 Tubemate(유투브 다운로드 앱)가 버젓이 올라와 있는 건 SKT는 유투브와 전혀 관계없기 때문에 '수단'을 제공할 때 생길 수 있는 어떠한 제약도 없기 때문이 아닐까?


뭐 나름 주저리 주저리 이런 결론도 가능하다.. 라고 생각했다는...ㅋㅋ - 물론 아무런 근거도 없는 나 혼자만의 생각... ^^



신고
Trackback 0 : Comment 0

두 가지 SW Branch정책에 대한 단상.

Essay/Software 2012.07.31 12:28

뭐.. 여러가지 SW Branch 정책들이 있을텐데... (하나의 branch에 전부 때려 잡아 넣고 개발하는 회사라면... 쩝 뭐 특별히 할 말 없다)

보통의 경우 SW branch는 아래와 같은 형태를 가진다.


+------------------------------ sub branch

/ ---------+-------------------+-------------------------------------- main branch

\

+------------------------------------ sub branch


기본적인 형태는 같지만, 정책적인 측면으로 보면 크게 두 가지로 분류할 수 있다.


1. 큰 main branch 정책

main branch가 기능 구현의 주요 작업 공간이 되는 방법.

main branch 가장 자주 update된다.

- feature이 대부분 main branch에서 개발되므로, 다른 외부 project branch의 개수가 적은 편이다.


2. 작은 main branch 정책

sub-branch가 기능 구현의 주요 작업 공간이 되는 방법.

- main branch가 가장 뜸하게 update되고 엄격하게 관리된다.

- feature들을 main branch와는 별도로, 서로 다른 project branch로 관리한다.


위의 두 가지 모두 기본적인 업무 방식은 같다.

1. 특정 시점에서 main branch에서 branch out

2. 필요한 새로운 feature들을 구현하거나, 다른 feature branch로 부터 가져오고, stability를 향상시킴

3. software release

4. 필요한 patch들을 main branch에 다시 merge함.


그렇지만, 위와 같이 서로 다른 방식의 정책을 적용하다보면, branch의 특성이 서로 달라진다.

1. 큰 main branch 정책

- main branch는 feature위주로 관리된다.

- main branch는 거의 모든 feature들을 가진다.(feature들의 super-set)

- main branch가 가장 많은 버그를 가진다.

- main branch의 코드 size가 sub branch에 비해 크다.

- 보통 branch out의 기준은 feature가 된다. 즉, 특정 feature가 available한 시점을 기준으로 main branch로 부터 branch out한다.

장점 : Integration에서 발생가능한 문제들이 main branch에서 충분히 다루어진 상태이므로, sub branch에서 이 문제에 대한 risk가 적다.

단점 : main branch의 stability관리가 어렵다. 그래서, sub branch에서 stability를 위한 비용이 크다.


2. 작은 main branch 정책

- main branch는 stability위주로 관리된다.

- main branch는 최소한의 feature만을 가진다.

- main branch의 stability가 가장 뛰어나다.

- branch out의 기준은 feature보다는 stability가 된다.

장점 : main branch의 stability가 충분히 좋으므로, sub branch에서 stability문제가 발생하더라도, main branch를 기준으로한 debugging이 가능하므로, 적은 비용으로 sub branch의 stability를 유지할 수 있다.

단점 : integration에 따른 문제들이 충분히 드러난 상황이 아니므로, sub branch에서 이것과 관련된 많은 문제들이 나올 수 있다.


branch 정책을 결정할 때는 위의 두 가지 요소를 충분히 고려할 필요가 있다.

stability에 대한 비용 vs. integration에 대한 비용

그리고 거기에 따라, branch 정책을 정할 필요가 있다.


개인적으로 봤을 때, 대부분의 경우, stability를 위한 비용이 integration비용에 비해 상당히 비싸다.

따라서, 작은 main branch정책이 더 좋은 것 같은데.... 


신고
Trackback 0 : Comment 0

회사내에서 추친하는 직원들 기술 교육의 효과가 미미한 이유에 대한 생각.

Essay/Software 2012.07.18 09:38

어지간한 규모가 있는 회사라면, 이유나 목적이야 어떻든 공식적으로는 직원들의 역량 강화라는 명목으로 교육을 실시하는 경우가 많다. 하루짜리 단일성 교육부터 8시간 4~5일짜리 장기교육까지... 가격도 어마어마하다.

그런데 그런 교육의 효과는 어떠한가? 그만한 값어치를 하는가? 교육을 받는 당사자의 생각도 중요하지만, 돈을 들여 교육을 실시한 회사의 입장은 어떤가? 직원들을 일주일간 업무에서 빼고, 비싼 강의료를 지불하면서까지 실시한 교육의 그만한 가치가 있다고 생각하는가?

대부분의 경우 만족스럽지 못할 것이다. 왜 그럴까?

아래는 전부 내 개인적인 생각으로 어떠한 근거도 뒷받침할 자료도 없다. -_-;


과거 학생 때를 돌이켜 보면, 공부에서 가장 중요한 것은 예습/복습이다. 회사에서 실시하는 교육도 그 연장선상에 있다고 본다.

보통 회사에서 실시하는 교육자체가 직무관련 교육인 경우가 많기때문에 어느정도 예습의 효과는 있다고 본다. - 물론, 교육의 커리큘럼을 따라서 제대로 예습한다면 더 좋겠지만...

그런데 문제는 '복습'이 전혀 이루어 지지 않는 다는 것이다.

1주일 교육이라면, 그 교육이 끝난 뒤에는 바로 업무에 복귀하게 되고, 일반적으로 회사에서 수행하는 없무는 교육받은 내용과 어느 정도 거리가 있기 마련이기 때문에 교육기간 동안 습득한 내용을 자기 것으로 만들 시간이 거의 없다.

복습의 효과에 대해서는 이미 수많은 검증된 연구결과들이 있다. 복습을 전혀 하지 않는 것과 어느 정도 복습을 하는 것은 교육의 효과와 더불어 내용을 기억하는 기간에 엄청난 차이를 가져온다.


그래서 난, 회사가 어차피 직원들을 교육시키는데 비용을 투자하기로 결정했다면, 약간의 비용 - 직원들이 업무 외의 일을 할 수 있는 추가적인 시간 - 을 더 투자해서 '강의'를 통한 교육에 이어서 교육의 내용을 소위 '복습'할 수 있는 공식적인 기간을 주는 것이 필요하다고 본다.

물론, 회사에서 하는 일이니 측정가능한 '성과'는 있어야 할 것이다.

그것이 세미나의 형태가 되었건 아니면, 잘 정리된 문서가 되었건, 아니면 교육의 내용을 기반으로한 간단한 소프트웨어 툴이 되었건, 자신이 습득한 내용을 정리하고 적용해 볼 수 있는 시간을 공식적으로 주고 또 장려할때, 교육의 성과가 극대화 될 것이라고 본다.


구체적으로 예를 들어보면, 하루 8시간 5일 교육을 가정하면, 이후 일주일 - 5 업무일 - 은 '복습'의 시간으로 할애해서, 피 교육생들이 교육시간에 배웠던 것들을 이것저것 실습해보고 적용해 보도록 하는 것이다...


쩝... 전부 내 개인적인 생각들이였다... 교육 들을때만 고개를 끄덕이고, 끝나고 일주일만 지나면, 뭘 들었는지조차 기억에서 희미해지는 그런 비효율적인 교육들을 보면서 답답한 마음에 끄적여 본다...

신고
Trackback 0 : Comment 0

R&R(Role And Responsibility)의 범위의 유연성에 단상

Essay/Software 2012.06.07 10:12
소프트웨어 엔지니어로 10년 가량 직장생활을 하면서 R&R(Role And Responsibility)에 대한 고민은 항상 있어 왔던 것 같다.
블로그에 R&R에대한 다른 포스트들도 여럿 더 있고...
뭐, 사실 이런 류의 논의는 정답이 없기 때문에 더욱 곤란한 경우가 많은데, 각설하고, 한가지 경우에 대한 장단점을 이야기 하고자 한다.

R&R에 대해 이야기 할때, 가장 주로 사용되는 방식이...

너의(혹은 너의 팀의) 주 임무(Main Role)은 'xxx'이다. 그렇지만, 거기에 국한되지는 않는다(not limited). 그러므로 경우에 따라서는 다른 사람(팀)의 일을 도와 주어야 하는 경우도 있을 것이다.


이런 식인데... 과연 이게 적절한 방식인가에 대한 이야기이다

물론, 일 자체가 너무 달라서, 서로의 영역을 서로 도와 줄 수 없는 경우는 고민할 거리도 없지만... 개발 조직 내에서는, 특히 소프트웨어 에서는, 다른 영역에 contribution하는게 충분히 가능하기 때문에 위와 같은 정의가 자주 사용되는 것 같다.


사실 "너는 이 일만 해!"는 현실적으로 불가능하다. 그래서 "거기에 국한되지는 않는다.(not limited)"라는 말이 항상 들어가게 된다.

왜 현실적으로 불가능한가?

일이라는게, 항상 고정되어 있는 것도 아닐 뿐더러, 어떤 때는 이 일이 많았다가, 어떤 때는 저 일이 많았다가... 이런 식이기 때문이다.


장점이라면, 당연히, 남는 자원을 적절히 분배할 수 있다. 특정 일이 많을때는 그 일을 서로 나누어서 할 수 있으니, 인적자원의 효율적인 활용이 가능해 진다.

단점이라면? 사실 이 부분이 이 글에서 이야기하고 싶은 부분인데... 예를 들어 A, B 두 팀이 있다고 생각해 보자.

A팀은 굉장히 적극적이고 또 능력도 뛰어나서 맡은 일을 빠른 속도로 처리해 나가는 팀이고. B팀은 A팀과 반대되는 성향을 가진다고 생각하자.

이 경우, 위와 같은 R&R의 정의를 적용하면, B팀은 항상 제 시간에 일 처리를 끝내지 못하기 때문에 A팀은 항상 B팀을 도와주는 형태로 업무가 진행되게 된다.

A팀은, 비록, 열심히 부지런히, 그리고 소위 '스마트'한 방법으로 자신들의 역할을 다 했음에도 불구하고, B팀의 상황이 안 좋기 때문에 B팀을 도와 주게 되는 것이다.

만약 B팀 역시 A팀과 비등한 정도의 열정/성실/능력 을 가진 팀이라면, 이런 상황은 어쩔 수 없고, A팀 역시 커다른 불만 없이 B틈을 도와 줄 것이다.

왜냐하면, 이 경우는 명백하게, 순간적으로 B팀에게 일이 몰리는 상황이고 이것은 어떻게 처리할 수 없는 형국이기 때문이다.


그렇지만 많은 경우, B팀의 불성실/게으름 등등의 이유로 절대적인 일의 양은 A팀에 비해 많지 않았음에도(혹은 오히려 적었음에도) 불구하고 이런 일이 일어나게 된다. 그리고 이런 경우, A팀에서 이런 사실을 모를리 없다. 이는 당연히 불만으로 이어지고, A팀의 사기를 떨어뜨리게 된다. A팀 역시 일을 부지런히, 빨리 끝낼 이유가 없으니까... 빨리 끝내봤자 B팀의 일을 해야 하니...

B팀 역시, 어차피 A팀이 도와줄테니, 최선을 다해서 현 상황을 이겨나갈려고 하지도 않는다.

즉, B팀 입장에서는 Role은 있으되, Responsibility는 없는 형국이랄까... (A, B팀 공동 책임이다.)


자... 이 두 가지 장/단점 중에서 어느쪽에 손을 들어주어야 하는가?

물론, 항상 어느 한 팀의 일이 많다면, 이것은 일의 양을 잘못 판단한 관리자의 책임이고, 팀 구성을 새롭게 가져 가야 한다.


개인적으로는 지금까지, 위와 같은 R&R의 정의만 보아 왔다. 따라서, 위와 반대되는 R&R을 정의하고 조직이 흘러가는 경향을 관찰해 보고 싶은 호기심을 느낀다.

긍정적인 방향이라면, 각 팀의 자신의 일을 최대한 효율적을 빨리 끝내려고 '스마트'한 일 처리 방식을 끊임없이 연구할 것이고, 일의 전반적인 효율이 증대될 것이다.(일을 빨리 끝내면, 놀 수 있으므로...)

부정적인 방향은, "왜 우리만 항상 고생하는데!"와 같은 불만으로 팀웤이 손상되는 방향이 있을 수 있겠다.


일의 영역이 장기간 고정적이고 변화가 적다면, 유연성이 없는 엄격한 R&R정의도 고민해 볼 필요가 있지 않을까?


신고
Trackback 0 : Comment 0

RSS list... + RSS icons ^^

Essay/General 2012.02.14 23:59

[ 언론 ]

오마이뉴스 :  http://rss.ohmynews.com/rss/ohmynews.xml
노컷뉴스 :  http://rss.nocutnews.co.kr/nocutnews.xml 
한겨레 :  http://www.hani.co.kr/rss/ 
경향신문 :  http://www.khan.co.kr/rss/rssdata/total_news.xml
매일경제 :  http://file.mk.co.kr/news/rss/rss_30000001.xml
한국일보 :  http://rss.hankooki.com/news/hk_main.xml 
전자신문 :  http://rss.etnews.com/Section901.xml 
스포츠서울 :  http://www.sportsseoul.com/rss/rss.asp?cp_flag=1
아이뉴스 :  http://www.inews24.com/rss/news_inews.xml 
SBS :  http://api.sbs.co.kr/xml/news/rss.jsp?pmDiv=all 
MBC :   http://imnews.imbc.com/rss/news/news_00.xml
블로터 :  http://feeds.feedburner.com/Bloter?format=xml 
민중의소리 :  http://mediablog.vop.co.kr/rss 


CNN Top stories :  http://rss.cnn.com/rss/edition.rss 
CNN Technology :  http://rss.cnn.com/rss/edition_technology.rss 
CNN Asia :  http://rss.cnn.com/rss/edition_asia.rss 
CNN US :  http://rss.cnn.com/rss/edition_us.rss 
AP Top stories :  http://hosted.ap.org/lineups/TOPHEADS-rss_2.0.xml?SITE=MAHYC&SECTION=HOME 

[ 포털 ]
다음 : http://www.daum.net/rss.xml
네이버뉴스 - IT/과학 : http://feeds.feedburner.com/NaverNewsGameESports?format=xml
네이버뉴스 - 경제 : http://feeds.feedburner.com/NaverNewsGlobalBusinessNews?format=xml
네이버뉴스 - 많이 본 뉴스 : http://feeds.feedburner.com/naver_news_popular

[ 팟캐스트 ]
나꼼수 :  http://old.ddanzi.com/appstream/ddradio.xml 
나꼽살 :  http://old.ddanzi.com/appstream/ggobsari.xml 
뉴스타파 :  http://newstapa.com/rss
저공비행 :  http://test.handypia.org/radio/jugong.xml 
나의사 :  http://www.docdocdoc.co.kr/podcast/iam_doctors.xml 
희뉴스 :  http://cast.vop.co.kr/heenews.xml 
애국전선 :  http://cast.vop.co.kr/kfline.xml 
낭만자객 :  http://cast.vop.co.kr/nang.xml 
정혜림 도도한 뒷담화 :  http://nemo.podics.com/131613387490 
김미화 여러분 :  http://cbspodcast.com/podcast/k_everyone/k_everyone.xml 
시사자키 정관용 :  http://cbspodcast.com/podcast/sisa/sisa.xml 
변상욱 기자수첩 :  http://cbspodcast.com/podcast/newsshow_journal/newsshow_journal.xml 
김현정 뉴스쇼 :  http://cbspodcast.com/podcast/newshow/newshow.xml 
허재현의 현장일기 : http://feeds.feedburner.com/iblug/OCnu?format=xml


[ MBC 라디오 표준 FM ]
건강한 아침 황선숙입니다. : http://minicast.imbc.com/PodCast/pod.aspx?code=1002588100000100000
손석희의 시선집중 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000674100000100000
손에 잡히는 경제 이진우입니다. : http://minicast.imbc.com/PodCast/pod.aspx?code=1000671100000100000
여성시대 양희은, 강석우입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000630100000100000
성경섭이 만난 사람 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002424100000100000
배한성, 배칠수의 고전열전 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002488100000100000
지금은 라디오 시대 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000669100000100000
김창옥의 세계는 그리고 우리는 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000681100000100000
최양락의 재미있는 라디오 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000678100000100000
윤하의 별이 빛나는 밤에 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000677100000100000
신동의 심심타파 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000664100000100000
이동진의 꿈꾸는 다락방 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002589100000100000
세상을 바꾸는 생각 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002590100000100000
김나진의 세계도시여행 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000621100000100000
라디오 북클럽 김지은입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000698100000100000
타박타박 세계사 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000628100000100000

[ MBC 라디오 FM4U ]
세상을 여는 아침 허일후입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000575100000100000
오늘아침 심현보입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000576100000100000
정오의 희망곡 스윗소로우입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1001919100000100000
두시의 데이트 주영훈입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000586100000100000
간미연의 친한친구 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002413100000100000
FM 음악도시 성시경입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1002600100000100000
푸른밤 정엽입니다 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000578100000100000
이주연의 영화음악 : http://minicast.imbc.com/PodCast/pod.aspx?code=1000580100000100000

[ SBS 라디오 PowerFM ]
정선희의 오늘같은밤(오밤) : http://wizard2.sbs.co.kr/w3/podcast/V0000349378A.xml
김형준의 뮤직하이 : http://wizard2.sbs.co.kr/w3/podcast/V0000328480.xml
김영철의 Fun Fun today : http://wizard2.sbs.co.kr/w3/podcast/V0000351036.xml
이숙영의 파워 FM : http://wizard2.sbs.co.kr/w3/podcast/V0000010343.xml
아름다운 이 아침 김창완 : http://wizard2.sbs.co.kr/w3/podcast/V0000010355.xml
공형진의 씨네타운 : http://wizard2.sbs.co.kr/w3/podcast/V0000321755.xml
최화정의 파워타임 : http://wizard2.sbs.co.kr/w3/podcast/V0000010346.xml
두시탈출 컬투쇼 : http://wizard2.sbs.co.kr/w3/podcast/V0000328482.xml
김창렬의 올드스쿨 : http://wizard2.sbs.co.kr/w3/podcast/V0000329545.xml
박소현의 러브게임 : http://wizard2.sbs.co.kr/w3/podcast/V0000336099.xml
붐의 영스트리트 : http://wizard2.sbs.co.kr/w3/podcast/V0000352536.xml
이석훈의 텐텐클럽(텐텐) : http://wizard2.sbs.co.kr/w3/podcast/V0000349380.xml

[SBS 라디오 LoveFM ]
서두원의 시사초점 : http://wizard2.sbs.co.kr/w3/podcast/V0000349385.xml
최영아의 책하고 놀자 : http://wizard2.sbs.co.kr/w3/podcast/V0000328499.xml
SBS 전망대 : http://wizard2.sbs.co.kr/w3/podcast/V0000337960.xml
정석문의 섹션라디오 : http://wizard2.sbs.co.kr/w3/podcast/V0000329544.xml
정철진의 스마트경제 : http://wizard2.sbs.co.kr/w3/podcast/V0000355936.xml
박준형의 시사갈갈 : http://wizard2.sbs.co.kr/w3/podcast/V0000356536.xml
김지선,김일중의 세상을 만나자 : http://wizard2.sbs.co.kr/w3/podcast/V0000337995.xml
라디오오디션 국민DJ를 찾습니다 : http://wizard2.sbs.co.kr/w3/podcast/V0000351237.xml
이성미의 이야기쇼 : http://wizard2.sbs.co.kr/w3/podcast/V0000349373.xml
희망사항 변진섭입니다 : http://wizard2.sbs.co.kr/w3/podcast/V0000349388.xml
안선영의 라디오가 좋다 : http://wizard2.sbs.co.kr/w3/podcast/V0000340869.xml
여러분의 국민DJ 이예랑입니다 : http://wizard2.sbs.co.kr/w3/podcast/V0000362236.xml




[ 기타 ]
이털남 :  http://rss.ohmynews.com/RSS/podcast_etul_main.xml 
이해찬 정석정치 :  http://rss.ohmynews.com/rss/podcast_bbong_main.xml 
오마이tv 저자 대화 :  http://rss.ohmynews.com/rss/podcast_authortalk_main.xml 
라디오 반민특위 :  http://www.615tv.net/podcastbanmin/jkbsbanmin.xml 
아트앤스터디 인문강의 - 수유 너머 :  http://www.artnstudy.com/podcast.xml 
김광수경제연구소 포럼 공부방 :  http://podcast.kseri.net/forum/pod_audio.xml 
그들이 말하지 않는 23가지 - 장하준 :  http://nemo.podics.com/131113737488 
문국현과 새로운 세상 :  http://nemo.podics.com/132607634128 
망치부인 시사수다방 :  http://nemo.podics.com/131192848437 
한국일보 시사난타H :  http://rss.hankooki.com/podcast/ 
고재열의 독설닷컴 :  http://poisontongue.sisain.co.kr/rss <= RSS 소스가..ㅜ.ㅜ

[ 기타2 ]
모바일 컨텐츠 이야기 :  http://mobizen.pe.kr/rss 
이정환 닷컴 :  http://www.leejeonghwan.com/media/atom.xml 
예병일의 경제노트 :  http://www.linxus.co.kr/lib/rssblog.asp?blogid=yehbyungil 
 

 

신고
Trackbacks 2 : Comment 0

[Essay] 리더로서 자연스럽게 팀의 업무 상황 파악하기...

Essay/Work 2012.02.13 23:23
리더가 팀을 이끌어 과는 과정에서 팀원의 업무 파악은 상당히 중요한 일이다.
업무 파악을 위해서 가장 많이 하는 일은 다음과 같은 것들이 있다.
  - 주간 업무 회의 : 주 1회 정도 정기적인 업무 회의를 통해서 보고 받는다.
  - E-mail 참조 : 업무관련 E-mail 을 주고 받을때, 리더를 CC에 넣도록 한다.
  - 식사/커피 등 함께 하기 : 자연스러운 분위기에서 업무 관련 이야기를 듣고자 한다.

다 좋다. 필수 적이기도 하다.
그렇지만 위의 것들을 모두 잘 하고 있음에도 불구하고, 늘 팀원의 업무 파악이 제대로 되지 않는 것 같다고 느끼는 경우도 있다.
무엇이 문제인가?
내가 생각하기에, 위의 방법들도 좋지만, 가장 중요한 것은 팀원들이 리더에게 도움을 받을 수 있어야 하고, 팀원이 이를 실질적으로 느끼고 있어야 한다는 것이다.

예를 들면, 어떤 문제에 대해서 실무자가 자기 자신의 힘만으로는 해결이 힘들어서 리더에게 보고를 하는 경우를 생각해보자.
이런 문제의 경우 대부분이 내부에서 실무적으로 처리하기는 한계가 있다고 실무자가 판단하는 경우이다.
즉, 외부 혹은 타 부서와의 협력을 통해 문제를 해결할 필요가 있는 문제이다. 

이때, 리더가 취하는 가장 일반적인 자세는, 일단 무엇이 문제인지 문제를 파악하고자 한다. 그래서 실무자에게 관련 문제에 대한 문답이 이루어진다. 여기까지는 자연스러워 보인다.

그런데 이후, 물론 리더에 따라 다르겠지만, 실무적인 가이드를 시작하는 경우가 있다. 그리고 이런 경우는 대부분, 상당한 시간을 소모함에도 불구하고, 리더가 제시한 가이드가 해결에 도움이 되기 보다는, 리더가 문제에 대해 더 잘 이해하는데 도움이 되는 정도로 끝난다.
이 과정이 반복되면, 일단 실무자는 피로를 느끼게 된다.
최악의 경우는, 리더가 실무에 대한 잘못된 가이드를 제시하고, 실무자의 의견에 반하여 그 가이드에 따라 일을 진행시키라고 강요하는 경우다.
이런 리더에게 실무자는 어떠한 도움도 구하고자 하지 않는다.

그리고 이후, 리더는 자신의 실무적인 해결책에 도움이 되지 못하게 됨을 깨닫고, 실무자에게 어떤 도움이 필요한지를 묻게 되고, 실무자는 " xxx가 필요합니다."라는 말을 하게 된다. 이런 도움의 대부분은 타 부서와의 업무 협조, 상위 부서에 보고 등에 대한 문제이다.
실무자가 요구한 사항을 리더가 해결해 주는 것이 정상적이나, 어떤 리더의 경우는 "그래? 그럼 xx씨가 직접 oo한테 연락해서 처리하도록."의 식으로 결국 실무자가 모든 일을 해야 하는 방향으로 결정을 내리기도 한다.

자. 위에서 문제가 된다고 생각하는 과정을 거친 실무자의 입장에서 보면, 본인이 진행하는 업무에 문제가 있어서 리더에게 보고를 했을때, 업무 진행에 도움을 받기 보다는, 시간과 에너지를 소모하고, 결국 자기 자신이 처리해야 하는 방향으로 결론이 난 것이다.
즉, 문제를 보고하는게 하등 도움이 되지 않는 것이다.
실무자가 이렇게 느낀다면, 과연 이후 업무에 대해서 리더에게 보고하려고 할까?
그냥 정기적인 보고 이외 특별히 리더와 업무에 대해 상의하고자 하지 않을 것이다.
어차피 결과적으로는 자기 자신이 모두 처리해야 하니까...

주저리주저리 이야기가 길었다.
간단하게 결론을 정리하면, 리더가, 실무자에게 도움을 줄 수 있고, 또 그렇다고 실무자가 느낀다면, 리더는 자연스럽게 실무자가 가지고 있는 문제를 보고 받게 되고, 팀원들이 업무적으로 가지는 문제가 무엇인지 이해할 수 있게 된다는 말이다.
직설적으로 이야기 하면, 맨날 보고 안한다고 뭐라고 하지 말고, 실무에 도움이 좀 되란 말이다. 그럼 자연스럽게 팀원들이 보고하게 될테니까...
실무적으로 아는게 없다고 해서 팀원들에게 도움을 줄 수 없다는 말은 하지 말자. 외부와의 소통문제, 업무 협조 요청 등등 수많은 일들로 팀원들을 도울 수 있으니... 
신고
Trackback 0 : Comment 0

[Essay][시사] 나꼼수에 대한 기성언론의 보도 형태에 대한 비판...

Essay/시사 2012.02.02 23:31
근래, 나꼼수의 인기는 상상을 초월한다.
그래서, 나꼼수 자체가 이미 '미래의 권력'이 아니라 '현재의 권력'이라고들 이야기 한다.
그런 나꼼수가 소위 '비키니 시위'건으로 전방위로 타격을 받고 있다.

사람마다 생각이 다르고, 가치관이 다르므로 위 건에 대해 여러 의견들이 표출될 수 있다는 것에는 전적으로 동의한다.
그렇지만, "나는 네 말이 기분나쁘게 들린다. 그러니 사과해라." 라고 이야기 하고, 이 말이 존중되기를 바란다면 "나는 네가 기분나쁘라고 한 말이 아니다. 그냥 웃자고 한 이야기다. 그러니 사과 못하겠다."라는 말도 존중하는 것, 다시 말해, 서로의 차이를 인정하는 것에서부터 논의의 출발이 이루어져야 하지 않을까?
물론, '성희롱'이라는 것 자체가, 상당히 광범위하고 주관적인 법리해석이 가능하므로 논란의 여지가 많을 수 밖에 없다.
그러므로, 단순한 "서로간 생각의 차이"라는 것에 동의할 수 없다면? 결국 "법대로 하는 방법" 밖에는 없겠지... 그러라고 법이라는게 존재하는 것이니까...

여기까지는, 내 개인적으로 나꼼수를 옹호하는 글이였다면, 이 다음은 기성 언론에 대한 비판이다.

지금 수많은 뉴스거리가 터져나오고 있다.
10.26선거에 대한 의혹, 자원외교 + 주가조작, 돈 봉투, FTA, 진보 연대, 한나라당 비대위,  MBC파업 등... 이루 말할 수 없는 많은 사안들이 하루가 멀다 하고 회자되고 있다. 그런데 과연, 소위 '비키니 시위'가 이런 사안들보다 더 중요하고, 또 국민들이 알아야 할 내용일까? 그래서 그 귀중한 "신문의 1면"을 장식해야 했을까? 내가 보기엔, 단순히 "여론을 형성하는 새로운 흐름에 대한 기성언론의 불안감에 대한 발로"로 밖에 보이지 않는다.
즉, "기성언론(진짜 '언론'이 아닌, 언론이라고 불리워지길 원하는 것들도 포함해서...)의 자신의 밥그릇 + 권위에 대한 방어 행위"로 느껴진다는 말이다.

또 한편으로는, 자신들이 수십년간 다져놓은 "언론이란 xxx해야 한다." 패러다임이 무너질 것에 대한 막연한 불안감도 어느 정도 있지 않았나 싶다.그래서, 그 틀에 나꼼수를 짜 맞추어 넣고, 튀어나온 부분은 전부 정으로 쳐 버리려고 하는 것 같기도 하다.
그렇지만, 나꼼수는 단 한번도 자신들을 '언론'이라고 이야기한 적이 없을 뿐더러, 비단 '언론'이라고 칭했다 하더라도, 암묵적으로 형성된 기존의 패러다임을 따라야 한다는 의무는 어디에도 없다. 왜 꼭 그래야 하는데?

마지막으로, 지금 이 시점에서 국민들이 알아야 할 내용이, 과연 소위 말하는 '비키니 논란'인지 아니면, 앞에서 열거한 수많은 현안들에 대한 내용인지 다시 한 번 생각해 보았으면 한다. (신문 지면, 웹 페이지 공간이 아깝지도 않나?)
신고
tags : 나꼼수
Trackback 0 : Comment 0

[Essay][시사]진정성이 중요한 이유...

Essay/시사 2011.12.23 23:10

유시민 전 장관께서 예전에, 서울대학교 강연에서 "진정성은 중요치 않다. 제시한 정책이 좋냐, 나쁘냐로 판단해야 한다."라고 하셨던 것이 생각난다.
유 전 장관님의 이야기는 아마도, "초점을 정책 자체에 두라!"라는 의미였을 것이다. "정책은 정책 자체로 평가되어야 하지 외부적인 요소가 개입되면 안되다는 뜻" 이 아닐까? 난 그 말에 전적으로 동의한다.
그렇지만, 여기에 내 개인적인 생각을 약간 첨언하고자 한다.
정책을 판단할때 가장 중요한 요소는 정책 자체이다. 그런데 문제는, 정책이 "좋냐, 나쁘냐"를 판단할 수 있는 경우 만큼이나, 판단할 수 없는 경우도 많다는 것이다.
예를 들어, FTA (굳이 이번 한미 FTA가 아니더라도)에 대해서 생각해보자.
FTA로 인해 명백하게 이익이 되는 혹은 명백하게 손해가 나는 사람들이 분명히 존재한다. 그런 사람들이 FTA를 판단할 때는 정책자체 - FTA는 정책이 아니긴 하지만... 따지지 말자. - 를 놓고 찬성/반대 하면 된다.
그렇지만, 애매한 사람들도 많다. 이게 국민에게 - 라고 말하지만, 사실은 '나'에게 - 이익이 되는지 손해가 되는지 도무지 판단할 수 없는 사람들 말이다. 정부, 또 각종 언론 등에서 이런 저런 예측 수치를 내 놓지만, 그건 단지 예측일 뿐이다. 그것도 적중률이 상당히 떨어지는...

이럴 경우는 무엇을 근거로 정책에 대한 찬성/반대를 해야할 것인가?
이럴 때 '진정성' 이 다시 중요해진다.
확률적으로, 정치인이 '진정'으로 "이것이 국가/국민에게 이익이 된다."라고 믿고 추진하는 정책이, 정치인 개인의 이익에 근거해서 추진되는 것보다는, 국민/나 에게 이익이 될 확률이 높기 때문이다.
물론, '진정성'을 정확히 판단하는 것은, 정책 그 자체를 판단하는 것 만큼이나 어려울 것이다.
그렇지만, 특정 정치인의 삶의 발자취에 근거한 '진정성'에 대한 판단은 신뢰할 만하지 않을까?

그래서, 많은 사람들이 '진정성'에 대해 이야기 하고, 또 고민하는 것이 아닐까?
(물론, 특정 정치인의 삶의 발자취를 '제대로' 분석하는 것이 쉬운일은 아닐테지만... - 그래서 언론의 역할이 중요한데, 이건 뭔...쩝...)

신고
Trackback 0 : Comment 0

[Essay] 개인이 자체 개발 SW를 회사에 공개하지 않는 이유...

Essay/Work 2011.12.23 22:50

회사에서 근무하는 개발자들 가운데, 개발 자체를 좋아하거나, 혹은 기술을 숙련시키는 과정의 한 방법으로 자체적으로 SW를 개발하는 사람들이 있다. 대부분의 경우, 개인이 제한된 시간안에서 prototyping하는 정도일 것이다. 그렇지만, 그 중 몇몇은 조금만 개선/발전 시킨다면, 제법 괜찮은 SW의 근간이 되는 것들도 있을 것이다.
대표적으로, Google의 경우 20%의 시간은 개발자가 자기가 하고 싶은 것을 하도록 두는데, 여기서 나온 산물을 회사차원에서 지원해서 제품으로 발표한 것들도 적지 않은 숫자가 된다고 알고 있다.
그런데, 국내 개발자들 대부분이 자신이 틈틈이 개발한 SW를 회사에 공개하는 것을 극도로 꺼려한다.
왜 그럴까?

근본적으로 지적 재산권 문제가 걸린다.  물론 회사마다 정책이 다르겠지만, 국내 대부분의 회사에서는, 개발자가 자체개발 SW를 회사측에 공개하는 즉시 지적 재산권 전부를 회사에 넘겨준다고 보는 것이 좋다 - 국내 대부분의 회사의 고용계약서의 위의 사항이 명시되어 있다. 따라서, 내가 잠자는 시간을 줄여가며, 여가시간을 희생해 가면서 만든 SW를 아무런 대가 없이 회사에 넘겨 주는 것은 그리 유쾌한 일은 아니다.
그렇지만, 만약 공개한  SW가 회사의 지원을 받게 되고, 개발자 본인이 그 일에 참여할 수 있다면, 지적 재산권을 넘겨주는 손해도 충분히 감수할 만한 경우도 있다. 사실 자신의 SW를 회사에 공개하는 개발자의 대부분은 이런 결과를 기대했었을 것이다.
물론 의도한 대로 진행되면 좋겠지만, 회사의 판단이 개인의 판단과 달라서, 개발자 개인은 충분히 가치있다고 생각되는 SW를 회사에서 사장시키기로 결정했을 경우 문제가 복잡해진다.
이런 상황에서 개발자는 자신의 꿈과 열정이 담긴 SW의 가치를 믿고 계속 발전시켜 나가고자 하지만, 이미 지적재산권이 회사로 넘어간 이후이므로 그렇게 할 수가 없다. 왜냐하면, 개발자 개인이 아무리 많은 열정과 노력을 해당 SW에 쏟는다고 하더라도 모든 권리는 회사의 것이기 때문에 말 그대로 "죽 쒀서 개 주는 꼴" 밖에 되지 않기 때문이다.
즉, 원작자는 눈물을 머금고 자신의 SW가 사장되는 것을 지켜볼 수 밖에 없어진다.
이러니, 어떤 개발자가 자신의 SW를 회사에 공개하려고 하겠는가?

위와 같은 구조는 개인과 회사 모두에게 손해가 된다.
개인이 혼자서 SW개발을 하는 것은 분명히 한계가 있으므로, 개발자는 자신이 생각하는 내용의 SW를 완성시키기 위해 너무 많은 노력이 든다 (회사의 지원을 받을 수 없으므로). 반대로 회사는 충분히 좋은 idea의 SW들을 제공받을 수 있는 통로 하나를 상실한다.
이런 문제를 해결하기 위한 해결책은 없을까? 내 개인적인 생각은 아래와 같다.

기본적으로, SW의 지적 재산권은 회사가 가진다.
그렇지만, 공개된 SW에 대한 특정 심사 기간을 두고 (ex. 3개월), 회사에서 해당 SW를 사장시키기로 결정했다면, 해당 SW에 대한 지적 재산권을 개발자 개인에게 돌려 주는 것이다. 반대로, 만약 SW가 지원할 가치가 있다고 판단되면, 개발자에게 관련 중책을 맡긴다.

위와 같은 정책이 정직하게 운영되는 회사라면 아마도 많은 SW개발자들이 자신의 SW를 회사에 공개하지 않을까... 조심스럽게 생각해 본다.

신고
Trackback 0 : Comment 0

티스토리 툴바