윤경구의 Log on Java

시간 관리는 대부분의 사람들한테 어려운 부분이고 시간 관리 능력에 따라 성과가 크게 다를 수 있다. 여러 가지 역할을 해야 하는 사람들은 성격이 다른 업무들 간의 전환을 할 때 어려움을 많이 겪는다. 어떻게 시간을 서로 다른 업무들 간에 효율적으로 배분할 수 있을까? 몰입(flow)이 필요한 창의적인 지적 노동을 하는 사람들에겐 더욱 시간의 관리가 중요한 요소이다. 하나의 생각에 깊이 몰입할 수 있어야만 성과를 얻을 수 있기 때문에 몰입할 수 있는 시간 여건을 만드는 관리가 필요하다. 개인적으로도 하루 종일 예정되어 있는 회의들 속에서 생각을 정리하고 설계할 수 있는 시간은 점점 더 찾아보기 어렵다. 어떻게 몰입하고 정리하는 시간을 만들어야 할까? 늘 고민이다. 육체의 피로와 뇌의 피로는 보통 직접적인 관련은 없다. 육체가 피로할 때에도 뇌는 활발하게 활동할 수 있으며, 반면 육체는 멀쩡할 때에도 뇌가 피로할 경우가 있다. 물론 육체가 활발하게 맑은 혈액을 공급해줘야 뇌의 활동이 보장되는 것은 장기적 관점에서 사실이다. 다음 프레젠테이션은 캐나다의 제품 마케팅 컨설턴트인 Etienne Garbugli라는 사람이 작성한 시간 관리 기술에 대한 것이다. 나름 공감되는 부분도 많아서 하나씩 음미해본다. SlideShare : 26 Time Management Hacks I Wish I'd Known at 20 1. 하루 시간의 배분  시간에 우선순위를 두자.  무의미한 Boring 시간을 줄이고 우선순위가 있는 일들로 바꾸자. 2. 매일 일할 분량 4~5시간만 계획하자. 나머지 시간은 차게 마련이다. 3. 하루 종일 일이 전혀 진행되지 않거나, 12시간 이어서 일이 잘 진행되는 게 정상이다. 일이 잘 될 때 좀더 일을 하고, 일이 안될 때 좀더 여유를 갖도록 하자. 4. 자신의 시간당 비용을 생각해보고 그에 따라 행동하자. 내 시간을 존중하고, 또 내 시간이 존중받을 만큼 가치가 있도록 만들자. 5. 멀티태스킹을 없애

창의적으로 ( 소프트웨어)  문제를 푸는 경험은 여러 경로로 만날 수 있다. a. 똑똑하고 적극적인 개인들이 문제를 잘 푸는 경우. b. 문제의 범주를 잘 인지하고 똑똑한 그룹을 형성하여 회의 속에서 토론하여 실마리를 풀어가는 경우. 문제를 푸는 과정이 단순히 a-ha 현상 한 스텝만은 아니므로 사실은 a와 b의 반복을 어느 정도의 긴장감 속에서 만들 수 있는 체계가 가장 효율적이라고 생각한다. management는 이러한 문제를 가려내고 가치로운 문제 해결을 할 수 있도록 개인별 mission과 회의를 통한 아이디어 심화 및 공유를 잘 갖추어주고 회의를 잘 이끄는 것이 중요한 역할이다. 그럼에도 문제를 푸는 (답을 선택하는 게 아니라) 과정을 직접 해야 할 시점은 항상 존재하는데 다른 사람과의 토론 속에서 연상을 통해 풀어내는 경우 외에는 결국 스스로 생각을 다시 정리하면서 풀어야 한다. 개인적으로 이러한 풀이 과정은 자리에 앉아 머리를 싸맬 때보단 계속 생각하면서 걸어다닐 때 해답이 잘 발견되었던 것 같다. 복도를 계속 걸으면서 생각한다거나, 탄천을 헤매면서 생각한다거나... 하나. 문제 해답이 떠오르는 건 문제에 대한 깊이 있는 이해 과정이 거듭되어야 한다. (wicked problem적 특성) 둘. 문제의 인지와 해결 모두 우수하고 적극적인 그룹을 형성하여 논리적 토론을 거치는 것이 가장 중요한 단계이다. A-ha의 한 스텝을 제외하고는 이 과정을 통해 문제의 인지와 심화 그리고 해결의 대부분을 매우 좋은 효율로 이룰 수 있다. 셋. A-ha는 보통 정확하게 problem-solving의 mission을 맡은 사람이 만나게 된다. 그만큼 생각을 많이, 깊게 하는 것이 전제되어야 하기 때문이다. 넷. A-ha 자체의 순간은 몰입이나 이완 등의 과정과 무관한 시점에서 아주 비동기적으로 수많은 생각 중 하나의 한 연결에 이어져서 발생한다.

기억이란 게 얼마나 엉터리일수 있는지 가끔 놀랄 때가 있다. "무의식의 기억 위조" 현상인데 우리가 기억을 저장할 때 어떤 느낌으로 저장하기 때문일 것이다. 오래되었지만 강렬한 기억은 강력한 위조인 경우가 많은데 낡아진 기억을 복원하기 위해 우리의 무의식은 주변의 비슷한 느낌을 키로 저장된 기억들을 사용하여 완벽(?)하게 재구성하기 때문이다. 수십년만에 페북으로 만난 후배를 마치 잘 알고 있었던 것처럼 느낄 때, 사실은 그 후배와 관련된 기억들은 유사한 이미지를 가진 다른 이의 것이었음을 점차 알게 되고 나중엔 그 이미지조차 원래 그 후배의 이미지가 아니었는데 기억 속에서 바꿔치기되어버렸음을 발견한다. 강렬한 위조였음을... SW 기술의 기억도 다르지 않다. 흔히 지식이라고 부르는 것들이라고 뭐 특별히 다른 방식의 기억소에 저장하는 것이 아니니까.. 중요한 지식, 선입견들 중 첫 인상이 강렬했던 것들은 강력한 방식으로 위조되는 경우가 많다. (난 절대 이런 기억의 정확성을 두고 내기를 하면 안된다 ㅠ) 그런데 어떻게 뇌는 이 수많은 기억들을 미묘한 느낌의 코드로 분류하여 저장하는 것일까? 그 메커니즘은 알수 없지만 기억력과 관련해서는 보통 매우 차분하게 몰입되는 경우가 가장 오래 남고 극도의 긴장 상태에서는 매우 짧은 기간 유지되는 기억 효율이 매우 높은 것으로 알려져있다. 이 사실은 차분할 때 작은 느낌의 차이까지 기억할 수 있고 장기 기억화될 여지가 많다는 뜻이 아닐까? 기억 능력과 아하 현상(a-ha effect, eureka effect)은 직접적인 연관이 없어보이지만 기억에서 차지하는 무의식(인지하지 못하는 뇌의 활동)과 느낌으로 표현할 수 있는 기억의 끄집어냄(검색?) 방식을 보면 유사한 메커니즘일 수 있을 것 같다. 다만 기억은 위조하여(!) 끄집어내는 것이고 아하 현상은 비슷한 것들을 무의식이 총합하여 추천한 것들 중에서 솟구쳐올리듯이 처리한다고나 할까! P.S A-ha 현상이 실재하는

글쓰는 법에 대한 가이드는 있어도 코딩하는 법에 대한 가이드는 보지 못한 것 같다. 글을 쓸 때에도 탑다운으로 (워드의 개요 모드outline mode 활용할 때처럼) 쓸 때와 글 가는 데로 붓 가는 데로 쓸 때가 다르듯이 코딩도 유사함을 가지고 있다. 논리적 설계와 아키텍처의 중요성을 강조하다가 막상 아키텍처 설계가 일단락되어 실제 코딩 단계로 넘어가면 어쩔줄 몰라하는 친구들이 있다. 물론 코딩 못하는데 설계만 아주 잘하는 건 일반적으로 가능한 이야기는 아니고 이런 이들의 설계는 구멍들이 있거나 현실성이 부족한 경향이 있다. 코딩을 설계를 기반으로 topdown 방향으로 진행하려면 인터페이스나 메소드 시그너처 혹은 커멘트 등을 통해 계속 논리 진행을 코드화해나가야 한다. 아주 디테일한 구현을 하나씩 해나가면서 그야말로 코드 가는 데로 하는 방식은 코드 몰입이 좋을 때 별다른 문제없이 잘 된다. 하지만 디테일 코딩을 하기에 논리적 분량이 많고 여러 가지 고려할 경우의 수가 많은 경우는 메소드 시그너처를 먼저 작성하고 (여의치 않은 경우 소스코드에 커멘트로 디테일 계획을 적어둔다) 디테일은 하나씩 채워나가는 형태가 더 효율적이다. 한마디로 코딩할 땐 구현해야할 모든 걸 코드에 반영하는데 한꺼번에 다 상세 구현으로 반영할 수없는 부분은 윤곽만 코딩하는 것이다. 이것은 그림을 그리는 과정과도 유사하다. 기본 스케치를 먼저 하는 것은 설계 후 주요 인터페이스 시그너처를 정의하는 것이라 볼 수 있고 실제 상세 터치는 어떤 부분은 아주 세밀하게 한번에 그리고 어떤 부분은 윤곽부터 조금씩 구체화하는 방식을 사용한다. 대부분 두 가지 방식이 모두 사용되어야 효율적인데 한번에 상세로 그리는 집중력이 필요한 부분은 그렇게 하고 생각이 끊어지는 여러 부분들은 그 포인트만 먼저 윤곽을 잡는 식인 것이다. 스스로 코딩도 하지만 멤버들의 교육과 성장을 함께 고민하면서 스스로에게 여러 가지 실험을 하게 된다. 논리적 사고의 방법, 창의 도출의 방법, 설계의

제가 주장하는 창의 메커니즘의 핵심은 좀 단순화하여 얘기하면 다음과 같이 요약될 것 같다. "스스로 거듭 논리적으로 생각하면 누구나 해답을 찾을 수 있다" (개인 관점의 창의) 창의도 문제 해결의 관점에서 바라본다는 점에서 해답을 찾는 것이고 (생각한 문제와 다른 문제의 답이 나오는 수도 있지만) 수단은 '스스로'와 '거듭된 논리적 생각' 뿐이라는 거... 누구나 찾을 수 있다고 믿지만 다만 논리적이기 위해서는 생각의 훈련이 필요하고 거듭 생각하는 것도 쉽지 않다는 것을 지적하고 싶다. 또하나는 이 주장을 개인적 관점에서 확대하여 조직의 창의로 발전시키기 위한 부분이다. 조직(팀) 창의는 역시 반복 훈련과 적응 과정이 필요하다. "팀 창의는 개인적 창의의 기반 위에서 이루어지는 것이며 다면적 소통을 통해 더나은 결론을 도출할 수 있다" (조직 관점의 창의)

소프트웨어 스케줄 계획과 기한 소프트웨어를 하다보면 스케줄 계획과 기한이 항상 맞지 않다. 상세한 수준에서 스스로 스케줄링을 하도록 권장하지만 그것을 기한과 맞춰야 하거나 또 큰 기한을 세워야 할 때면 항상 착오가 생긴다. 목표에 기한이 없으면 뒷쪽으로 갈수록 추동력이 떨어지지만, 기한이 합리성을 잃으면 역효과가 나게 마련인데.. 예상과 계획은 늘 어긋나는데 경험과 풀어야 할 문제의 complexity 수준이 제한할 수 있으면(판단되고 제한이 되는 단계가 되면) 예상이 좀더 의미있는 값이 되는 것 같다. 창의적 조직에 대한 고민을 늘 하고 있는데 개인의 성장에 기반한 조직적 지혜의 개선이 가장 중요한 요소라고 생각하지만, 현실에서 마주치는 시간과 기한의 문제는 또다른 어려움이다. 여가와 창의의 관련성에 대한 반론 창의와 시간에 관련된 문제 중 흔히 여가가 창의에 도움을 준다는 주장이 있는데 개인적으로 이러한 주장에 대해서는 사례나 근거를 파악하기가 쉽지 않고 오히려 반례가 많다고 판단하고 있다. 개인적으로는 자발성과 능동성이 그리고 좀더 많은 시간을 몰입하여 생각하는 데에 할애하는 게 창의에 도움을 준다고 생각하는데, 기한이나 문제의 어려움 혹은 현실에서의 댓가와 같은 pressure를 개인이 너무 강하게 의식하게 되면 충분히 생각을 할 수가 없고 생각에 한계를 두게 되기 때문에 창의를 해치는 것은 분명하다. 다만 여가라는 표현은 그야말로 남는 시간을 뜻하는 것인데.. 남는 시간과 휴식이 창의와 연결된다는 근거는 거의 없다. 여러 창의의 발견 형태 중 3M과 같은 사례의 경우 다양한 시도와 조금은 우연성에 기반한 부산물의 재해석을 통한 창의의 형태에서는 주기적인 사고의 전환 즉 몰입하던 문제를 완전히 털어내고 다른 문제로 몰입하는 방식이 중요할 수 있다. 하지만, 그런 경우도 여가가 창의에 기여를 하는 것은 아니라고 생각된다. 여가가 사람에게 필요한가 하는 질문과 여가가 창의에 기여하는가 하는 질문은 전혀 다르기 때문에 사실에 대한 탐구를

오늘(2013년 5월 14일) 저녁에 있었던 이화여대 컴퓨터공학과 학부 4학년을 위한 특강 자료.. 강의 자료는 예전에 명지대에서 했던 자료를 재작성했는데 아쉬움이 있지만 그래도 발표자료보다 내용 전달은 잘되었을 거라 생각합니다. 아무도 주무시지 않고 경청해주셔서 감사. ^^; Smart software engineer from Kyung Koo Yoon P.S 강의 자료에서 보완할 부분이 세 가지 정도. 강의 자료에는 빠져 있지만 세번째 항목을 제외하면 특강 때에는 언급한 내용입니다. a. 뇌 활동 중 인지하는 부분과 인지 못하는 부분 (의식과 무의식) b. wicked problem의 특성들 c. 소설 읽듯이 코드를 읽는 법 (논리적 사고의 연장선 상에서 코드 구조 가설-내가 구현한다면-을 먼저 세운 후 실제 코드를 보고 그 차이를 비교하면서 다시 읽어가는 방식)

목표(goal)는 수준과 시간의 의미를 함께 가지고 있다. goal을 설정하는 것과 성취하는 것은 많은 경우 하나의 연속된(반복된) 과정이다. goal 설정 시 수준을 반영하는 간단한 문장을 요구하는 편이지만 시간에 대한 부분은 늘 reasonable한 수준이라고 implicit하게만 요구한다. 스스로는 계속해서 수준과 시간을 수정해가야 하겠지만 manager 혹은 adviser가 판단할 수 있는 건 그 사람의 능력을 고려한 합리적인 노력 여부와 방법적인 부분 정도이다. 시간에 대한 한계를 먼저 설정한다는 건 매우 어려운 일이지만 시간을 무시하는 것은 또한 잘못된 일이다. "내가 마무리할 때가 마무리하는 것이다"라는 사고는 대부분 성과 측면에서 비효율적이며, 목표를 추진하는 사람의 성장에도 도움이 되지 않는다. 수준과 시간, 그리고 성장이란 화두가 적합하지 않은 영역도 있을 것이다. 아마도 그런 영역은 goal이란 표현도 적합하지 않을 것이다. 조금 시각을 다르게 해서 근원적인 문제를 떠올려보자. 왜 우리는 더 나은 성과와 성취, 성장을 얘기하는 걸까. 하고 싶은 만큼 일하고 그 결과를 나눠가지면 안되는 걸까. 엄청난 수준으로 생산력이 향상되면 과연 그게 가능한 것일까? 나는 그렇지 않다고 판단한다. 사람 자체의 생산력이 기술의 발전에도 불구하고 아무런 비용 없이 무한의 잉여를 주지는 못할 것이라고 본다. 물론 불필요한 일들은 크게 줄일 수 있으리라고 본다. 판단에 집중할 수 있고 상대적으로 변화와 개선의 사이클도 짧아질 수 있으리라고 본다. 그럼에도 불구하고 그건 그러한 통찰을 가능하게 하는 고도의 인간 활동의 숙련을 위해 보조하는 역할들을 할 거라고 본다. 적어도 잉여의 생산은 유럽의 복지에 대한 개념이 국내의 복지에 대한 개념과 다른 것처럼 노동 없이도 인간으로서 삶을 기본 보장하는 건 가능할 것이다. 하지만, 진보를 이끄는 힘들은 여전히 goal을 필요로 한다고 본다. 인간다운 삶에 대한

한 페친이 프로젝트 정량화에 대한 글을 올려서 몇 가지 의견을 제시한 글들을 옮겨놓습니다. "왜 정량화를 하려는지 목적이 무엇인가요? 또 프로젝트 결과란 무엇인가요? 프로젝트별 목표가 다르기 때문에 각 목표는 있을 수 있겠지만 sw 프로젝트 일반에 대한 정량화란 말 자체가 무엇인지 생각해보기 바랍니다. 가능한 것은 프로젝트별 목표이고 그나마 정성적인 요소들은 일반화된 기준의 수치화는 시도하는 게 무의미합니다." "SW 프로젝트 결과물이란 SI이거나 SW 솔루션이거나 서비스이거나 하겠지요. 그 결과물의 점수를 일반적으로 점수화한다는 시도 자체가 피겨 스케이팅의 점수 채점을 객관화하는 것과 왜 비슷하다고 생각하는지 모르겠구요. 그에 앞서 왜 점수화를 하려고 하는지 편의적인 발상이 아닌가 하는 부분입니다. 일반화한 정량화는 비교가 가능한 정량화인데 그것을 추구하는 의도가 무엇인가요? SW에서 가장 경계하는 것 중 하나가 단지 있으면 좋을 것 같은 것입니다. 왜 하는지 모르고 하는 거죠. SW가 그냥 일반적인 목적을 갖지 않는다면 SW를 일반화한 평가가 의미가 있는 걸까요? 비교 분석하려는 평가 목표 자체가 문제가 있다고 생각합니다. 비교라는 건 엄밀한 제약 조건을 가지고 있어야 하는데 단순 논리에 의한 일반화의 오류가 보이기 때문에 얘기했습니다. SW에 대한 일반화된 정량화보다는 목표의 엄밀한 설정이 중요하다고 생각합니다." "SW가 어떤 목적을 달성하기 위한 해결책인데 목적과 무관한 일반화된 평가 지표.. 그것은 비현실적인 생각인데 그것을 일반화하려는 무리한 시도 자체가 SW의 질적 수준을 저해한다고 생각합니다. 국내 SW 정책이 그런 정량주의에 기반하고 있죠. SW가 아닌 SW공학이 SW 정책을 입안하고... SI 프로젝트와 같이 SW 수준이 중요하지 않은 프로젝트에서나 가능한 걸 일반화하기도 하고.." "프로젝트 결과를 정량화하는 게 도덕적 사회적 기준으로 한다는 걸

10년전 얘기지만 면접볼 때 DB를 만든다고 한 친구가 있었다. 그 친구 말을 들어보니.. postgresql을 사용하고 일부 버그 리포트를 보내는 경험을 가진 친구였다. 왜 그는 스스로를 DB creator라고 착각하고 있었을까 하는 의문을 가졌었다. open된 source code를 들여다보고 이해하게 되고 또 이슈 리포트나 수정한 코드를 커뮤니티에 보낸다고 그 사람이 그러한 모듈을 만들 수 있는 능력이 생기는 건 아니다. maintain과 create는 엄청난 차이가 있다. 회사가 어려움을 겪으면서 maintain해야 할 코드의 양과 제품 수가 많이 늘어났지만 제품의 아키텍처와 성격을 이해하면 (혹은 잘 이해하지 못하는 경우에도) maintain은 대부분 가능했다. 하지만 scratch부터 무언가를 만들어야 하는 건 달랐다. 새로운 제품을 만든다는 건 훨씬 더 어려운 일이며, 새로운 버전을 만든다는 것도 maintain과는 비교할 수 없는 어려운 일이다. open source를 통해 핵심 기술이 우리 것이 되는 것처럼 착각하는 경우가 종종 있다. 그냥 그렇지 않다. 그 open source의 새 버전을 주도적으로 설계하고 핵심 모듈을 코딩할 수 있을 때 우리 것이 되는 것이다. 다만 아키텍처라도 충분히 이해하는 데서 출발했으면 한다. create나 evolve를 할 능력은 안되더라도 use는 할 수 있다. 그건 사실이다. use는 대부분 그렇게 어렵지 않으며 코드 이해도 어느 정도의 훈련만 되어 있다면 대부분 필요 기능 중심으로 파악이 가능하다. 하지만, use하고 있다고 혹은 일부 repair하고 있다고 create할 능력이 생겼다고 착각하진 말았으면 좋겠다. 그건 좀 많이 다르다. 설계와 구현 능력이 어디서 뚝 떨어지지 않는 이상..

벌써 4월 하순이다. 열흘만에 제품 하나 프로토타이핑을 하겠다고 했는데 곧 한달이 다 되어간다. 다행히 due date이 한달 정도 연기되어서 여유(?)가 생긴 것도 있고 현실적으로 주중에는 일정이 너무 빠듯하여 코딩을 하긴 어려워 주말 중심으로 코딩을 하다보니.. (주중엔 정말 혼절하는 일이 잦고.. ㅠ_ㅠ) 그래도 그와중에 진전이 되고 다시 코더로서의 흐름이 되살아나고 있다. 역시 믿을 건 내가 짠 기존 코드들.. ㅠ_ㅠ 설계를 상당히 상세한 수준으로 진행하고 난 다음에 top-down으로 코딩을 스크래치부터 시작하는데.. 코딩을 하면서 느끼는 안타까움은 설계를 열심히 하는 연구원들 중에 코딩을 못하는 친구들이 종종 있다는 것.. 물론 설계도 팀 회의 수준에서 편하게 발표할 때와 세미나 형식으로 앞에 나와서 할 때는 차이가 많이 나고.. 세미나 형식에서는 역시나 논리적 발표를 못하는 문제가 보통 보이지만... 문제가 뭘까 많이 생각해보고 어떻게 개선할 수 있을까 고민 중인데 현재까지 판단은 1. 앉아서 하는 팀 발표는 개별 사안을 산발적으로 편하게 얘기해도 다 이해하고 보통은 공통된 지식 기반이 많아서 일부 이슈만 가볍게 터치하면 되지만, 서서 하는 세미나는 좀더 큰 주제를 깊이있게 얘기할 것을 요구하기 때문에 훨씬 큰 논리성을 요구한다. 부담도 크고, 논리적으로 생각을 정리하기 위해서도 bottom-up과 top-down을 통해 개념 모델을 여러 번 다음어야 하는데 이런 일을 부담스러워하고 실제로 잘 극복하지 못하는 것이다. 논리가 산발적이고 나열적인 수준이라고 할까. 2. 그런 데로 작은 이슈들을 모아서 어느 정도 설계가 된 후에도 코딩을 전혀 시작하지 못하는 경우가 있는데 이건 왜 이럴까 생각을 해보면.. 설계는 큰 개념 모델을 통해 논리를 전개하지만 코딩은 철저하게 bottom 수준에서 시작해야 한다. task를 가능한 한 쪼개서 해야 하고 여러 개의 task를 동시에 머리에서 전개하면 진행하기 어렵다.

Open Source Software에 대한 여러 가지 찬반이 있는데 어느 한쪽 방향으로 판단하기는 쉽지가 않다. 공개라는 점은 공유를 전제로 한다. 오픈 소스 운동이 공개를 통해 공유의 범위를 넓힘으로써 소프트웨어 혁신의 출발점 수준을 넓혀온 점은 분명하다. 그런 반면 소프트웨어 저작 활동이 지식 노동이기 때문에 지적 노동의 가치를 어떻게 할 것인가 하는 측면에서는 여러 가지 복잡한 관점이 뒤섞인다. 많은 경우 단순히 기부의 관점으로 바라본다. 지적 노동을 공유 자산화하는 관점이다. GPL, LGPL, Apache/BSD License 등은 분명 그러한 측면이 강하다. 자산을 사적 이익으로 파생화하는 것을 허용하느냐 안하느냐의 관점 차이가 있지만 이렇게 공개된 소스들이 다수의 이익을 위한 기부가 된다는 점은 동일하다. 다만 그 기부가 개인적 기부인지 혹은 상업 회사가 고용한 저작의 기부인지의 차이는 있다. 하지만 이렇게 노동이 보상되지 않는 기부라면 직업적 노동으로는 한계가 있다. 소프트웨어 저작이 직업화되지 않고 기부 활동에 그친다면 그것은 오히려 새로운 소프트웨어 혁신을 저해하는 것 아닌가. 순수한 잉여 시간 노동의 기부를 하는 전문 소프트웨어 엔지니어가 있고, 또 상대적으로 직업적 압박으로부터 자유로운 학생들의 적극적인 기부도 있다. 그외에 상업적 이익을 간접적으로 올릴 수 있는 구글 같은 기업도 적극적으로 공개 소프트웨어 활동을 통한 지적 노동의 기부에 참여한다. 애플, 오라클, IBM과 같은 전통적인 소프트웨어 기업들은 공공재화된 공개 소프트웨어들을 활용하고 또 일부 기부를 통해 공개 소프트웨어의 결과물들을 자신들이 원하는 방향으로 이끌기 위한 활동을 하기도 한다. 기부가 아닌 경우도 존재한다. 일부 제한된 기능에서만 활성화된 커뮤니티를 통해 협업적으로 기부를 하고, 핵심 기능들은 상업용으로 비공개하는 방식을 통해 제한된 커뮤니티 버전만 기부하고 그 커뮤니티를 주도적으로 이끌며 상업용 버전은 판매함으로써 커뮤니티

How To Be More Interesting (In 10 Simple Steps) - Forbes 어떻게 하면 좀더 재미있게 살 수 있을까? Software를 얼마나 재미있게 할 수 있을까? 늘 갖고 있는 생각인데 저는 대부분 매우 재미를 가지고 일을 하는 편입니다. 새로운 것을 알게 되는 것이 매우 즐겁고 여러 사람들과 토론 속에서 문제를 해결해가는 과정은 때론 신비롭기도 하고 놀랍기도 합니다. 그 놀라움의 대상은 뛰어난 아이디어를 내는 다른 연구원일수도 있고 문제를 여러 토론 속에서 얼떨결에 해결해내고 있는 자신일수도 있습니다. 개인과 소규모 그룹, 그리고 그보다 더 큰 그룹을 유기적으로 연결하여 혁신 아이디어 체계를 구축하는 일이 현재의 본업이라고 생각하는데 그 출발점은 각 성원들이 흥미를 가지고 자신의 일과 관심 속에서 아이디어를 만들고 공유하고 또 발전시키는 것이라고 생각합니다. 재미있게 일하는 것은 여러 가지 아이디어를 적극적으로 매사에 적용해보는 것이 아닐까 생각해봅니다. 또 일을 하는 것이 아니라 늘 같지 않은 일로 만들 수 있는 적극성이 필요한 것이지요. 다행히 제 일인 소프트웨어는 늘 아이디어를 필요로 하고 아이디어에 따라 크게 달라집니다. 이 글은 벤다이어그램이나 그래프로 표현한 것이 재미있어서 옮겨봅니다. 1. 탐험하라. 아이디어, 장소, 의견을 탐험하라. 에코 체임버 안에 모든 지루한 사람들은 갇혀 있다. (해야 할 일과 가야할 곳이 만나는 곳이 무한의 영역이라는 표현 재미있습니다.) 2. 발견한 것을 공유하라. 발견한 것을 인심좋게 공유하라. 모든 사람이 당신의 탐험을 함께 하지 않았다. 다른 사람들이 당신의 탐험, 모험을 대리경험할 수 있도록 하라. (발견을 공유하지 않으면 발견이 많더라도 dumb 벙어리일 뿐이고 발견이 많고 이를 공유를 많이 하는 사람이 smart하다는 것. 공유하는 과정에서 더 발견이 많아지고 깨달음도 커지고 당연히 smart해지겠지요)