윤경구의 Log on Java

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해지겠지요) ...

티맥스소프트에 복귀한 후로 관심의 영역이 세부적으로는 많이 바뀔 수밖에 없었습니다. 소셜, 모바일보다는 미들웨어에 더 많은 깊이의 시간을 필요로 했습니다. 하지만 생각의 깊이 또한 더 요구되었습니다. 창의와 혁신, 그리고 소프트웨어를 주제로 여전히 고민하고 있지만 이제는 혼자가 아니라 많은 젊은 친구들의 힘을 모아서 해결해야 합니다. 트윗할 시간이 거의 없었지만 몇 안되는 트윗들을 정리해봅니다. 제니퍼소프트 이원영 대표의 가치 중심 업무 문화론. 1년의 1주일은 업무를 중단하고 온전히 goal setting에 둔다. 각 개인별로 치열하게 1년 목표를 함께 고민한다. 깊이와 바탕이 부족한 사람으로서 부끄럽다 http://t.co/VuBG3c4Y (2012/8/22) 소프트웨어는 사람의 능력과 태도가 결정적인 역할을 한다. 국내에 잠깐 소프트웨어 바람이 이는 듯하지만 이 바람이 소프트웨어 역량의 핵심인 엔지니어들의 성장을 동반하는 것인지 우려된다. 피상적이고 가시적인 개발만 보고 문제 해결 능력을 키우지 못하면 인재 부족 현상은 더 심해지게 되고, 많지 않은 잠재적 우수 인력들도 성장을 하지 못한다. 이미 충분한 역량을 가진 엔지니어들은 해외의 선진 IT 기업들로 빠지고... 개인이든 팀이든 성장이 필요하다. 소프트웨어는 특히 다면적 분석 능력과 총화 능력, 추상화 능력을 끊임없이 요구한다. 개인으로서는 결코 쉽지 않은 일이며, 성장을 중시하는 조직 경험을 통해 빠르게 체득할 수 있는 것이다.  뛰어난 SW 엔지니어를 꿈꾸는 이들은 잠깐의 흐름을 보지 말고 자신의 성장에 투자하는 지혜를 가지길..  (2012/8/21) Software Architecture 설계에는 전체를 보는 통찰이 가장 중요하지만 더 나은 결론은 핵심 측면을 날카롭게 자르는 명확성과 복잡함을 놓치지 않는 높은 엄밀성이 필요. Clarity, Rigidity가 좋은 해답 여부 판단 기준 (2012/6/1) The jou...

사보에 실었던 컬럼(2012년 4월호)을 블로그로 포스팅합니다. 한계가 컸던 웹서비스 지난 10 여년간 컴퓨팅 패러다임을 바꿀 것으로 기대했던 흐름 중 하나는 웹서비스였다 . 1998 년 마이크로소프트 사에서 정의한 SOAP (Simple Object Access Protocol) 스펙에 기원을 둔 웹서비스는 마이크로소프트 , IBM, BEA( 지금은 Oracle 에 인수됨 ) 3 사의 엄청난 지원에 힘입어 국제 표준으로 자리잡았으며 , 플랫폼과 프로그래밍 언어에 독립적인 XML 의 장점과 원격 프로세스 호출 (RPC) 아키텍처를 결합한 서비스 중심 아키텍처 (SOA) 라는 IT 패러다임을 만들었다 . 하지만 웹서비스는 기대했던만큼 혁신적인 변화를 가져오지 못했다 . 기업은 웹서비스 도입을 꺼려했고 , 컨설팅 주도로 부풀려진 SOA 아키텍처는 기대했던 유연성과 확장성을 가져오지 못했다 . 오히려 성능 저하 , 처리 능력 저하 , 하드웨어 비용 증가의 문제를 일으켰다 . 웹서비스의 실패와 이에 따른 SOA 기피 현상은 기업 주도로 만들어진 인위적인 새로운 흐름의 문제점을 보여주었다 . 가장 큰 문제는 CPU 과다 사용이었는데 XML 자체의 파싱 오버헤드도 있었지만 SOAP 규격이 정의한 Enveloping 오버헤드 문제 , XML namespace 규격의 불필요한 prefix 오버헤드 문제 등 표준 규격 진행 과정에서 성능을 고려하지 않은 부분들이 스스로의 한계를 규정하고 말았다고 볼 수 있다 . 클라우드 컴퓨팅 뜬구름 같은 이야기 , 클라우드 컴퓨팅은 웹서비스의 한계를 여러 측면에서 반성하면서 탄성 있는 확장성과 관리 비용 절감 등을 내세우며 아마존 , 구글과 같은 웹 중심 기술 기업에서 구현하여 제시하고 있는 새로운 컴퓨팅 스택이다 . 클라우드 컴퓨팅은 컴퓨팅 리소스의 위치에 따라 public cloud 와 private cloud 로 구분할 수 있다 . Public cloud 의 ...

이 글은 생각하는 방법과 창의적 사고에 대한 고민의 연장선 상에 있다. 마침 재미있는 책을 하나 읽었다.   Spark of Genius 천재성의 섬광 생각의 탄생 - 다빈치에서 파인먼까지 창조성을 빛낸 사람들의 13가지 생각도구 (Spark of Genius : The Thirteen Thinking Tools of the World's Most Creative People) http://www.yes24.com/24/goods/2535237 레오나르도 다빈치, 아인슈타인, 파블로 피카소, 마르셀 뒤샹, 리처드 파인먼, 버지니아 울프, 제인 구달, 스트라빈스키, 마사 그레이엄 등 역사 속에서 뛰어난 창조성을 발휘한 사람들이 과학, 수학, 의학, 문학, 미술, 무용 등 분야를 막론하고 공통적으로 사용한 13가지 발상법을 생각의 단계별로 정리하고 있다. 역사상 가장 위대하다고 손꼽히는 천재들이 자신... Robert Root-Bernstein과 Michele Root-Bernstein 부부가 함께 쓴 이 책에서는 유명한 과학자, 예술가들의 사례를 분석하면서 다음 13가지 생각 방법들을 사용하여 생각의 창의성을 높일 수 있다고 주장한다. 관찰, 형상화, 추상화, 패턴 인식, 패턴 형성, 유추, 몸으로 생각하기, 감정 이입, 차원적 사고, 모형 만들기, 놀이, 변형, 통합 개인적으로 사례나 통계를 통해 현상들을 관통하는 어떤 법칙이나 경향들을 발견한 다음엔 그 법칙이...

기존 회사로 복귀를 결정하면서 트윗을 거의 하지 못했습니다. 앞으로도 트윗은 점점 더 줄 것 같네요. 새로운 발견, 발명은 논리적으로 추론되는 것이 아니라 직관에 의해 느껴지는 것이다. 논리는 이 발견, 발명의 근거를 만들고 검증하는 과정에 사용되는 것이다 (2012/1/28) 우리가 플레밍이나 파인먼, 콜더나 모짜르트에 매혹되는 이유는 어떤면에서 그들이 어른으로 성장하지 않았다는 사실 때문이다 ... 이들 모두는 파인먼식으로 말하면 '창조적 무책임성'을 스스로 키웠고 그것으로부터 모든 걸 배웠다 - 생각의 탄생 중 (2012/1/24) 나이는 남은 시간과 기회가 급격히 줄어든다는 위기감.. 보이지 않는 지혜.. 그리고 항상 삶 옆에 웅크리고 있는 외로움.. (2012/1/16) 상상력과 구상력... 상상에 단단한 뼈대를 세워 손에 잡히게 하는 능력이 진정한 창의력이 아닐까.. (2012/1/3) 한해가 저무네요. 개인적으로는 지혜도 구하지 못하고 마음 속 완충 기능도 동작하지 않아 답답하고 불편했던 한해였습니다. 새해에는 약간의 지혜와 여백이 있는 판단을 할수 있기를... (2011/12/31) 맥OS X Lion 사파리에서 스마트 줌이 되니까(두 손가락 더블 탭) 정말 아이패드 기분이 난다. Very good! 딴 브라우저 못쓰겠음.. (2011/12/7) 상상력과 구상력... 상상에 단단한 뼈대를 세워 손에 잡히게 하는 능력이 진정한 창의력이 아닐까.. (2012/1/3) 소프트웨어 설계 행위에서 중요한 것은 무엇일까? 교량이나 건물 설계 시 이런 모양과 재료로 이러한 도면에 따라 지으세요란 시행서일까 아님 그러한 시행 결정 근거인 why를 기술하고 판단하는 것일까? (2011/11/5) 어린왕자와 여우 http://t.co/zAEjHOAp ‎"넌 언제나 네가 길들인 것에 대해 책임감을 느껴야 해. 넌 네 장미에게 책임감을 느껴야 해" 관계는 책임.. 새로운 관계만을 찾는 사람들에게 던지는...

안철수 교수님의 서울시장 출마 염두 발언에, 지경부 국산 웹 OS 전략 등 소프트웨어와 직간접적으로 연결된 사건들이 우리 사회를 강타했던 시간들이네요. 사람이란 무엇인가에 대해 다시 한번 생각해본 시간들이었습니다. 클라우드 플랫폼이나 운영체제의 핵심 기술을 모르는 사용자 관점의 피상적인 SW정책은 SW포기 정책이다. ETRI나 소프트웨어 국책연구소 발상이 한심하지만 그렇다고 눈에 보이는 것만 하자는 건 유행따라 흔들대는 뒷북일뿐이다. (2011/9/11) 경쟁력있는 소프트웨어는 필요와 시장 검증의 무한 반복을 통해 발전한다. 구현이 필요를 구체화하는 wicked problem의 iterative solving 과정이다. (2011/9/11) 소프트웨어에선 tame problem도 경쟁력을 갖추려고 하면 wicked problem이 된다. 외형적인 해결에 길들여진 SI나 외주 사업관리 체계의 사고로 소프트웨어를 볼수가 없다. 또 소프트웨어 공학은 소프트웨어가 아니다. (2011/9/11) 우리나라는 사업 아이디어 부족하지 않다. 공정한 수익창출 기회가 적은 문제가 심각하지만 그것만의 문제가 아니다. 핵심 기술로 경쟁할수 있어야 하는데 기술축적이 없다. 경쟁력 없는 뒤늦은 카피 전략이 SW 글로벌 영역에서 작동하지 않는다. (2011/9/11) 내가 이걸 사업화해보겠다는 것과 국가 정책은 차원이 다른 얘기이다. 우리나라 소프트웨어 문제는 인프라 경쟁력 상실이다. 연구소가 아닌 상용 수준의 경쟁력을 갖추는 대안이 필요하다. SW는 투자기간이 길어 자금회전이 늦다. (2011/9/11) 오픈소스는 절대 필요 계층의 모든 문제를 해결하지 못한다. 레디메이드 소프트웨어가 아니다. 다른 레이어의 눈으로만 보면 안된다. 오픈을 공유하기 위해선 진지한 참여가 필요하다. 핵심을 모르고 껍질만 보면서 뒤늦게 유행 쫓자는 건 어이없다. (2011/9/11) 오픈소스와 소프트웨어 계층에 대한 혼돈이 어이없는 주장을 만들고 있다. 상위 애플리케이션이나 서비스만 보...