윤경구의 Log on Java

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할 능력이 생겼다고 착각하진 말았으면 좋겠다. 그건 좀 많이 다르다. 설계와 구현 능력이 어디서 뚝 떨어지지 않는 이상..

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

안철수 교수님의 서울시장 출마 염두 발언에, 지경부 국산 웹 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) 오픈소스와 소프트웨어 계층에 대한 혼돈이 어이없는 주장을 만들고 있다. 상위 애플리케이션이나 서비스만 보...

플랫폼 API 공개가 국내에서도 바람처럼 불고 있다. SKT가 자사의 서비스들 API를 전면 공개하겠다고 선언하고 그 후속 작업에 들어갔다. Open이 SKT의 생존과 직결된 문제로 인식하고 전사적인 지원에 나섰다는 점에서 약간 늦은 감은 있지만 결정에 박수를 보내지 않을 이유가 없다. API 공개와 소스 공개 소프트웨어 관련하여 Open(공개)을 두 가지로 크게 분류해볼 수 있는데 하나는 연결 방법 즉 인터페이스를 공개하는 것이다. API(Application Programming Interface)는 프로그래밍을 통한 연결 방법을 뜻한다. 또다른 하나는 소스 공개 즉, 오픈 소스(Open Source)이다. 오픈 소스의 경우에는 소유권과 사용권의 수준과 방법이 라이센스에 따라 많이 다르다. GPL처럼 철저하게 공공재로서만 사용되고 사적 이해를 위해 사용할 수 없는 라이센스부터 BSD나 아파치 라이센스와 같이 어떤 목적에도 사용할 수 있는 최소한의 제약만 있는 라이센스. 그리고, 특정 기업이 소스를 공개하면서 자사만 사적 이해를 위해 사용할 수 있도록 한 GPL과 Commercial License의 이중 라이센스 방식 등이 있다. API 제공은 플랫폼 위에서 새로운 서비스를 만들 수 있는 수단을 제공하지만, 또 서비스의 관점에서 보면 특정 플랫폼에 종속되는 결과를 낳기도 한다. 이를 보통 lock-in 효과라고 부르는데 Facebook이 자사의 핵심 자산인 개인별 소셜 관계 그래프를 API를 통해 제공하고 좋은 서비스의 자유로운 발전이 자연스럽게 Facebook 자체의 성장이 되도록 하는 것은 놀라운 공생의 비즈니스 모델로 보인다. 플랫폼을 제공하는 방법 역시 이렇게 API 수준에서 공개하는 것 외에 소스를 오픈하는 방법도 있다. 이 경우엔 서비스를 제공하려는 기업 관점에서 보면 오픈 소스 플랫폼의 관리와 운영에 대한 책임을 가져가야 하는 부담이 있는 반면, 특정 기업에 lock-in되는 문제를 피할 수가 있다. 오픈 소스 CMS ...

작은 Startup을 생각하면서 방법론 측면에서는 Creative Innovation, 그리고 기술적 관점에서는 Social, Mobile, Open이 마음 속의 큰 화두이다.다른 영역들은 어느 정도 출발점을 정리했는데 Open 부분은 훨씬 오래전부터 고민해왔지만, 정리를 못하고 있다. 기업이란 Profit을 목적으로 하는 존재인데 Open과 Profit은 직접적인 연결 고리를 찾기가 매우 어렵기 때문이다. 하지만, 이미 Software 전반적으로 Open은 Profit에 대한 큰 위협이자 기회 요소로 자리하고 있기 때문에 거칠게나마 정리를 시도해본다. 정리를 시작하기에 앞서 Open이 Social이나 Community 개념과 많은 관련을 가지고 있기 때문에 한 가지 용어를 정리하고자 한다. '이 글에서 Social과 Community는 구분해서 사용한다.' Social은 Social Networks 즉, 사람의 사람 관계 망을 직접적으로 활용하는 좁은 의미의 Social을 지칭하고, Community 기반의 공동 작업은 Social로 표현하지 않는다. 다시 정리하자면 이 글에서 Social이라 칭하는 영역은 엄밀하게 SNS를 적용한 영역이다. 공개(Open)의 대상. 무엇을 오픈하는가? Open Source 기업에서 소프트웨어를 하면서 가장 큰 도전적 이슈는 소스 코드의 공개, 즉 Open Source였다. 소스 코드의 공개는 소스 코드의 수익권을 부정하는 Free Software 운동과 연결되어 시작되었고, 이후 여러 가지 형태의 소유권(License)이 등장하면서 수익권도 다양해졌다. 소스 코드는 공개하되, 누구나 수익을 추구할 수 있는 Apache 그룹의 라이센스에서부터, 특정 기업에서만 수익을 추구할 수 있는 형태의 라이센스들, 그리고 원래의 수익권을 부정하는 GPL 라이센스 등의 형태가 존재하고 있다. 소스 코드의 공개는 수익권 측면뿐 아니라 저작 측면 즉, 소스를 저작하는 형태에서도 변화를 불러왔는데, 개인적인...

Web과 Social 얼마 전에 " 소셜 웹이다 " 라는 온라인 책을 접할 기회가 있었다. 여러 가지 이슈를 던져주긴 했지만, Web 2.0의 기반을 Social Web이라는 이름으로 부르고 있다. Web 2.0과 구글, 리눅스 그리고 위키피디아의 실체를 Social Web이라고 부르자는 내용이었다. Open Source, Open Community, Collective Intelligence 이러한 내용이 Web 2.0의 핵심 문제 의식이었고 블로그, 위키, 유튜브, 위키피디어, 집단 창작 (더 나아가 구글), 그리고 기술적으로는 REST와 open API, open API에 기반한 mashup 등이 모두 웹 2.0의 실현 형태라고 볼 수 있다. 웹 2.0 자체가 Social Networks에 기반하고 있기 때문에 Social Web이라는 주장. 솔직히 기대했던 것은 Facebook과 Twitter가 대표하고 있는 Web 2.0 이후의 Social Networks에 대한 의견을 듣고 싶었던 것인데, 그 글은 Web 2.0의 Social 측면을 얘기하고 있었다. 기대했던 얘기가 아니어서 실망했지만, 마음 속에 담아두고 있던 Social이란 화두에 대해 돌아보는 계기가 되었다. 그렇다면 Web 2.0의 Social과 지금 열광하는 Social이 같은 것일까? 직관은 Web 2.0의 Soical Networks와 현재의 Social Networks는 질적인 차이가 존재한다고 느낀다. 그것은 무엇일까? Social과 Web의 관계에 대해 의문을 던진 글은 다음 Wired 기사이다. Web 2.0의 실체는 Social Web이라고 보는 앞의 글과 달리, 이 글은 Web은 끝났다고 본다. 웹은 죽었는데 인터넷은 만수무강할 것이라니... The Web Is Dead. Long Live the Internet (2010. 8. 17) Wired 2010년 9월호 표지 글이 "The Web is dead"라는 도...

오픈 소스의 수많은 광고성 문구에도 불구하고, 오픈 소스 전략의 수익성은 크게 검증된 적이 없었다. 오픈 소스화해서 SW와 관련 기술을 공동 명의의 자산으로 등록하는 것도 중요한 일이긴 하지만, 비즈니스 월드에서 이와 관련하여 기업이 생존하고 수익을 내는 방법에 대해서는 현실적인 모델이 많지 않았다. SW 제품을 개발하는 관점에서 보면 제품 개발의 부품으로 검증된 오픈 소스를 활용하는 것은 유익한 접근법임에 분명하다. 하지만, 부품으로 사용하는 순간부터 그 부품에 대한 책임을 가져가는 조건이 붙는다. 제품의 핵심 부품 혹은 차별성을 가지는 부품은 자체 개발하고, 다른 부품들은 오픈 소스를 활용하는 전략은 개발 전략에서 점점 더 중요한 포지션을 차지한다. 일부 부품에 오픈 소스를 활용하는 전략 외에 제품 전체를 오픈 소스화하는 경우는 어떨까? 이 부분은 커뮤니티의 활성화와 개발 프로세스의 고도화 등의 요인에 따라 좌우되기는 하지만, 리눅스를 포함하여 여러 가지 성공 사례를 가지고 있다. 문제는 이 경우 수익 모델이다. 제품 라이센스 기반의 수익 모델은 오픈 소스 기반의 제품에서는 매우 큰 한계를 가진다. 물론 단순히 소스를 공개하기만 하고 기업에서 모든 소스를 컨트롤하는 경우에는 약간의 커뮤니티 contribution을 기대할 수 있다는 부분을 제외하면 제품 라이센스 기반 수익 모델이 가능하다. 이 경우는 제품의 배타적 소유권이 public domain에 있는 것이 아니라 개인 기업에 있는 경우이다. 그렇지 않은 경우, JBoss를 인수한 RedHat과 같이 오픈 소스 비즈니스는 해당 제품을 사용하는 고객에 대한 상업적 지원 즉, 유지보수 서비스에 기반한 수익모델을 가진다. 하지만, 이 경우는 인적 지원에 대한 비용을 수익 모델로 하는 것이므로 폭발적인 수익을 기대하는 것은 매우 어렵다. 마이크로소프트가 보여주었듯이 전통적인 소프트웨어의 수익 모델은 MS 윈도우와 MS 오피스처럼 엄청난 양의 제품 라이센스 비용을 통해 폭발력을 가지는 것이다. 기사에서 인용하자면...

갈수록 공개 소스 소프트웨어에 많이 의존하게 된다. 어쩌면 피할 수 없는 흐름인지도 모른다. 가장 많이 사용하는 부분은 XML 처리에 관련된 것들이다. XML parser, XPath engine, XML-Java binding, ... 투자 대비 개선이 뚜렷하지 않은 부분에서 좋은 공개 소스를 가져다 쓰는 것은 개발 비용의 절감 뿐만 아니라 소프트웨어의 질적 향상을 기할 수 있다는 점에서 나쁘지 않은 일이다. 하지만, 수많은 공개 소스들로 인해 옥석을 가리기가 점점 어려워지고 있으며, best-of-breed를 요구하는 제품의 핵심 부분을 공개 소스로 채울 경우 제품 자체의 수준이 떨어질 우려가 높아진다. 필요는 발명의 어머니여서, 다양한 소프트웨어 요구는 다양한 소프트웨어 개발로 이어진다. 공개 소스도 대부분 특정 요구에서 출발하게 되며, 이후 점차 다양한 요구를 수용하면서 일반화되는 양상을 보인다. 그것은 장점이자 단점이 될 수 있다. 각 소프트웨어에 대한 요구를 일반적 요구로 대체할 수 없듯이, 보다 특정한 요구에서 보다 잘 동작하는 소프트웨어를 만드는 것과 공개 소스 소프트웨어 모듈은 가끔씩 충돌하게 된다. 최고 수준의 공개 소스 소프트웨어 모듈을 잘 활용하는 것, 하지만 핵심적인 부분에서 잘 튜닝되고, 개선된 자체 코드를 사용하는 것이 필요할 것 같다. 공개 소프트웨어와 상용 소프트웨어를 비교할 때 흔히 리눅스가 솔라리스보다 나은가 하는 얘기를 하게 된다. (공개 소프트웨어 내에서도 리눅스와 FreeBSD를 비교하는 경우가 있지만...) 역시 요구에 따라 다른 판단을 내릴 수밖에 없으리라 생각한다. 보다 엄밀한 기업 환경에서 아직 리눅스가 솔라리스와 같은 상용 소프트웨어를 대체할 수 있다고 생각하지 않는다. 물론 비용의 문제도 있지만, 소프트웨어 가격 문제를 배제하고 요구에 따른 질적 수준만을 고려할 때, 리눅스가 더 낫다고 얘기하는 것은 아직 무리라고 생각된다. (리눅스가 새로운 기술을 적극 수용하면서 하나의 방향으로 개선되고 있는지에 대해서도 의...

오픈 소스의 거대한 흐름이 기성의 관념들을 뒤엎으면서 소프트웨어 비즈니스의 한 축으로까지 떠오른 것은 닷컴의 붕괴 이후 소프트웨어 업계에서 가장 큰 주목거리 중 하나일 것 같다. 오픈 소스가 가지고 있는 수많은 장점들과 매력들을 무시할 수 없으며 또, 수많은 자발적 전도사들까지 형성하여 웹을 떠돌며 지배적 담론을 형성하고 있는 듯하다. 예전 MS가 수많은 공격적인 마케팅과 막대한 광고를 통해 우호적 개발자군을 형성하고, 광고 이미지를 제품의 품질이나 서비스로 믿게 하는 데 천재적인 재능을 보였던 그러한 일들이 오픈 소스 진영에서는 몇몇 옹호자들에 의해서 시작하고 자발적인 전도사들에 의해 인터넷을 점령하는 방식으로 일어나는 듯하다. 비용 하나 들이지 않고... 하지만, 순수하게 소프트웨어 비즈니스 관점에서, 아니 내가 사업의 주체로서 오픈 소스를 바라본다면 정말 오픈 소스 사업은 수익성이 높은 사업일까? 오픈 소스와 비즈니스가 쉽게 win-win할 수 있는 것일까? 비즈니스의 관점에서 보면 MS의 광고만큼이나 오픈 소스의 비즈니스적 의미들은 hype이 아닐까? 오픈 소스 프로젝트의 성공과 실패를 살펴보면, 오픈 소스 프로젝트의 성공에는 한두명의 걸출한 해커가 있거나, 거대 기업들의 필요에 따른 끊임없는 투자가 있다는 특성을 보게 된다. 중소규모의 프로젝트는 열성적이고 능력있는 코더 하나 둘에 의해 좌우되게 마련이고, 좀 더 큰 규모의 프로젝트는 엄밀하게 시장과 소통하는 제품 개발 및 관리 프로세스를 갖춘 프로젝트가 성공할 수 있다는 것을 볼 수 있다. 수없이 많은 오픈 소스 프로젝트들이 명멸하고, 그 대부분은 조용히 잊혀지고, 묻혀진다. 시기적으로 스폿라이트를 받는 기술들은 잠시 흥하다가, 스폿라이트가 지나가면 잊혀진다. 그런 와중에 새로운 오픈 소스 소프트웨어 비즈니스들이 등장하고 또 성공한다. 최근의 경우라면 JBoss를 들지 않을 수 없다. JBoss가 최고의 J2EE AS라고 생각하는 개발자들은 많지 않을 것이다. 하지만 JBoss는 기업 환경에서 살아남...