수요일, 9월 29, 2010

공개(Open), 참여(Participation) 그리고 비즈니스(Business)

작은 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 라이센스 등의 형태가 존재하고 있다.
소스 코드의 공개는 수익권 측면뿐 아니라 저작 측면 즉, 소스를 저작하는 형태에서도 변화를 불러왔는데, 개인적인 저작물을 단순히 공개하는 차원에서 출발하여 공동의 저작을 촉진하는 형태로 발전하여 왔다. 흥미로운 것은 기존에는 기업 내 저작에 기업이 소유권을 행사하는 방식이었는데, Open Source와 다양한 License의 결과, 공동체 저작에 기업이 소유권을 행사한다거나, 기업이 저작하여 공동체에 소유권을 이양한다거나 하는 다양한 형태의 저작과 소유권 조합이 존재하게 되었다.

Open API
API(Application Programming Interface)는 소스 공개의 매우 제한된 형태라고 생각할 수도 있다. 어떤 시스템과 연계하기 위한 방법을 기술한 것을 API라고 생각하면 된다. API 공개는 보통 소스가 공개되지 않은 라이브러리를 다른 모듈이나 프로그램에서 사용할 수 있도록 인터페이스를 공개하고, 결합하는 방법을 기술해주는 것을 뜻하는데, 최근에 얘기하는 Open API는 Web 2.0이라는 트렌드에서 나오는 것으로 HTTP 프로토콜 기반에 문서 형식은 XML, JSON, RSS, Atom을 사용하여 웹 시스템의 기능 일부를 공개하는 것을 뜻한다. Open API는 웹 시스템 기능을 확장하거나, 다른 시스템과 연계하는 데 많이 사용된다. (여러 개의 Open API를 조합하여 새로운 기능을 만들어내는 것을 흔히 Mashup이라고 한다. Mashup은 완전히 다른 일을 하는 웹 시스템을 결합하여 새로운 서비스나 애플리케이션을 만들어내기도 하지만, Mashup만으로는 한계가 크다.)

Open Standard
공개 표준은 또다른 형태의 공개라고 볼 수 있다. 또, 표준 제정 과정에서 여러 기업과 공동체가 참여하게 되고, 그 결과로 표준의 준수를 요구한다는 점에서 다른 공개와 차이점이 있다.

Open Community
열린 공동체는 공개라기보다는 개방이라고 표현하는 게 좀더 적합한 것 같다. 여기에서 얘기하는 Open Community는 어떤 공공의 이익을 목적으로 만들어진 웹 상의 공동체로 리눅스와 같은 오픈 소스 프로젝트를 위한 공동체도 있지만, wikipedia와 같은 공동 저작을 목적으로 개방된 공동체도 포함한다.
한때 Web 2.0의 특질로 공개와 참여를 들었으며, 공동 저작의 수단으로 wiki가 주목을 받았었다. 공동체와 참여라는 특성은 사회적 특성을 가지는데 현재 이슈화되고 있는 Social Networks 즉 인간관계망과는 달리 특정 개인의 인간 관계 망을 형성하여 구성되는 네트웍 구성이 아니라는 점에서 차이가 있다.

Open Market
여기에서 얘기하는 열린 시장은 AppStore의 공개 형태를 뜻하는 협의의 것으로 아직 구체적 형태는 존재하지 않는다. 다만 시장을 제어하고 관리하는 주체에 대한 이슈를 제기하는 수준에서 언급해보았다.

공개 대상에 대한 정리
앞에서 나열한 공개 대상 범주들을 정리해보면 소프트웨어와 다양한 정보(컨텐츠)를 포함한 지적 저작물들과 관련하여 저작물 자체에 대한 공개, 저작물 규격에 대한 공개, 저작 참여 주체에 대한 공개 그리고 저작물 유통 시장에 대한 공개를 그 대상으로 삼을 수 있다.

저작 주체와 권한 주체
특정 저작물을 공개할 때, 해당 대상의 수익권, 소유권의 주체와 저작 주체가 같지 않은 경우가 많다.
Open Source를 예로 들어보면, 처음부터 완성된 소스를 공개하는 경우도 있지만(이미 있는 제품 혹은 라이브러리의 소스를 공개하는 경우), 미완의 소스 코드를 초기 기여하고, 이를 기반으로 공동체를 형성하여 본격적인 코딩 즉, 저작 활동을 시작하는 경우가 더 많다.
그런데 이들 저작자들은 소스를 공동의 리파지터리에 커밋할 때 해당 공동체가 지정한 라이센스에 동의를 하게 된다.
이 라이센스에는 다양한 형태로 수익권과 소유권을 행사하는 주체를 지정하고 있는데, 공동체에 참여한 저작자들은 사실상 수익권과 소유권에서 배제되는 경우가 많다.
공동체가 이 라이센스의 수익권 주체가 되거나, 이 공동체를 지원하고 관리하는 기업이 수익권 주체가 되거나, 혹은 수익권을 포기하거나 수익권을 금지하거나 하는 등의 라이센스가 있다.
소유권의 경우는 소유권을 주장할 수 없도록 하거나, 집합적인 저작자들(기여자들)이 소유권을 가진다. 결과적으로 해당 재단이나 공동체에 소유권을 잠정 위임하는 효과를 가진다.

수익의 방향과 한계
공개를 다루면서 수익을 얘기하는 것은 여러 가지로 어려운 부분이다. 물론 앞에서 언급한 대로 공개의 모델이 여러 가지가 있긴 하지만, 대부분의 많은 저작자들이 자신의 수익권을 포기하고 저작물 자체에 대한 애정을 가지고 저작에 적극 참여한다.
공공 선에 대한 고민이나 저작물 자체를 사회적 공공재로 보려는 철학적 관점도 이러한 참여 저작을 북돋운다.
하지만, 기업을 통해 혁신을 이어가려는 사람으로써, 이들 공개된 저작물들과 연결하여 직간접적으로 수익이 발생하고, 또 그 수익의 일부가 공개 저작 모델을 경제적으로 유지하는 데 재투자되지 않으면 안된다는 생각을 가지고 있다. 수익 없이 기부나 취미 개념 만으로는 심각한 저작 활동을 지속하는 데 한계가 크다. 초기의 많은 공개 소스 운동은 많은 부분 상대적으로 경제 활동에서 자유로운 대학생들로부터 많은 도움을 받았다가, 이 대학생들이 졸업을 하면서 중단되거나 약화되는 과정을 겪기도 했다.
현재의 공개 저작은 기업에서 후원하여 full-time job으로 공개 저작물에 기여하는 사람들이 많아졌다. 여러 기업이 하나의 공개 저작을 공동 후원하는 경우도 종종 볼 수 있다.
이들 후원 기업은 기업 내부적으로 저작물을 만들고 이를 유지보수하는 것보다 공개 저작물에 기여하여 원하는 수준의 품질을 만드는 것이 더 효율적이라는 판단을 했기 때문이라고 볼 수 있다. 물론 최근에는 좀더 순수한 공공 선에 기업이 투자를 하는 경우도 볼 수 있다. 이것은 어떤 의미에선 기업의 사회 참여 즉, 기부 행위라고 생각된다.

하지만, 기업으로서는 저작물이 공개됨으로써 독점적 점유를 하지 못하는 것에 대한 우려를 가지게 된다. 앞에서 수익권을 특정 기업이 갖도록 하는 라이센스에 대해 얘기하였는데 이러한 경우는 독점적 점유를 유지할 가능성이 높다. 하지만, 점차 이러한 라이센스 모델은 줄어들고 있고, 라이센스 모델을 배타적 수익권이 없는 다른 모델로 변경하여 개방도를 높이는 경우도 종종 만날 수 있다.
한 마디로 기업이 공개된 저작물을 기반으로 직접적인 수익을 발생시키는 모델은 점점 더 어려워지고 있다.
이 부분은 조금 우려되는 부분이기도 한데, 기업이 수익 타당성이 없는 부분에 대해 계속 후원을 하기는 어렵다. 기업이 수익을 내는 데 필요한 기반이 되는 공개 저작물에 대해서는 계속 후원을 하겠지만, 직접적인 수익과 연결고리가 없는 저작물에 대해서는 후원하기가 어렵다는 뜻이다.
소프트웨어로 따진다면 상위 계층으로 올라갈수록 기업의 후원을 받는 공개 저작 프로젝트를 하긴 어렵다는 뜻도 된다.

반대로 말하면 기업이 상위 계층 소프트웨어에서 직접 수익을 내고, 기반이 되는 계층의 소프트웨어는 공개 저작을 활용하여 커스터마이즈하는 것이 비용과 시간 측면에서 유리하다는 뜻이 되기도 한다. 현실을 살펴보면 많은 기업들이 이러한 모델을 채택하고 있다. 다만, 공개 저작을 활용하는 비용이 Free가 아니고, 심지어 처음부터 만드는 비용만큼 지불하게 되는 경우도 보게 된다. 즉, 적합한 공개 저작이 없어 출발점부터 다시 만든 후에 공개로 전환하는 경우인데 이러한 경우에도 유지보수에 대한 비용 측면에서 유리한 측면이 있다.
일반적으로 모든 필요한 요건을 갖춘 복잡한 소프트웨어가 완성품으로 존재하는 경우는 거의 없다. 복잡한 상위 계층 소프트웨어나 서비스를 생각하는 기업이라면 이에 대한 공개 저작의 활용 비용을 새로 저작을 하는 비용과 견주어서 적절한 수준에서 책정하는 것이 안정적일 것이다. 이 비용은 단순히 시간과 돈에 대한 것이라기보다는 소프트웨어 특성 상 필요 인력의 수준 관련된 경우가 많다.

잘 알려진 공개 저작을 통한 수익 모델을 정리해보면 앞에서 언급한 데로 하위 계층의 소프트웨어를 공개 소프트웨어를 활용하여 비용을 줄이는 모델, 공개 소프트웨어나 저작물을 유통 비용만 받고 판매하는 모델, 공개 저작에 대한 유지보수 서비스 비용 모델, 그리고 저작에 광고를 포함하여 광고비를 받는 모델 등이 있다.
구글과 같이 다양한 공개 프로젝트에 기여를 하고, 또 자산을 공개하면서 결과적으로 트래픽을 자사의 서비스를 경유하도록 하여 간접적인 광고 수익을 받는 매우 복잡한 형태의 플랫폼 수익 모델도 있다.


공개 저작을 활용한 자사의 서비스나 상위 계층 소프트웨어를 통해 수익을 내는 경우는 공개 저작에 의한 수익으로 보이지 않는 데다가 공개 저작에 대한 비용 지불이 의무가 아니므로, 공개 저작의 역할은 미미해보이기도 한다.
예를 들어, Facebook이나 Twitter와 같은 서비스를 통해 개인들이 마이크로블로깅 활동을 하면 이 저작들을 통한 간접 수익권은 해당 서비스 업체가 가져간다. 직접 소유권과 수익권을 여전히 저작자들이 가지게 되지만, 이들 트래픽을 서비스 업체가 유통함으로써 그 유통에 대한 비용을 광고 수익 등으로 과금한다고 생각할 수 있다.

공개 저작들과 관련된 다양한 형태의 수익 모델이 존재하지만, 직접적인 공개 저작에 대한 수익보다는 간접적인 수익 모델들이 활성화되고 있다. 어떻게 보면 공개 저작이 직접적인 수익을 목적으로 하는 저작이 아닌 경우가 대부분이라 이러한 형태로 정착하는 것은 필연일지도 모르겠다.

공동 저작 (Community Authoring)
공개 저작에서 유력한 저작 방법인 공동 저작 모델의 가장 큰 어려운 점 중 하나는 커뮤니티의 활성화에 있다. 기업이 저작자를 후원하지 않는다면 해당 저작에 적극적인 관심을 가지는 자원 저작자들에 의해 저작이 진행되어야 하는데, 그 참여자들의 수준에 의해 저작의 품질이 크게 좌우된다.
오픈 소스 프로젝트를 보더라도 수많은 기여자들이 있다 해도, 가장 적극적인 핵심 기여자들에 의해그 방향과 품질이 결정된다.

공개 저작 커뮤니티에서도 참여자별로 역할은 제한된다. 참여는 자유롭지만, 참여의 형태는 다양한 검증 과정을 통해 제약을 둔다. 이것은 공개 소스 프로젝트 뿐 아니라, wikipedia와 같은 전지구적 규모의 집단 저작의 경우에도 적용된다.
저작의 내용의 수준을 검증하고 분쟁을 조정하는 등의 역할을 하는 전문가 집단이 wikipedia 내에 존재하며, 공개 소스 프로젝트는 소스를 커밋할 수 있는 권한을 커미터 권한이 있는 사람들에게만 위임하고 일반인들의 소스 커밋은 커미터를 통해 이루어지도록 하고 있다.
누가 전문가가 되는가 하는 것은 다양한 형태가 있지만, 커뮤니티의 경우는 해당 프로젝트의 창시자(Founder)나 핵심 관리자가 몇 가지 경로를 통해 직접적인 위임을 하는 경우와 커뮤니티 과정을 통해 검증된 전문가들이 발탁되는 경우가 있다.
이러한 공동체 저작의 제약은 전문성을 필요로 하는 저작물의 특성 때문이라고 봐야겠다. 

소셜 네트웍에서의 저작은 현재는 공동 저작보다는 저작물들의 유통에 비중이 높은 것 같다. (커뮤니티는 커뮤니티를 매개로 한 독특한 형태의 소셜 네트웍이라고 볼 수 있는데 관계들의 형태가 사람들의 관계만으로 보면 제대로 보이지 않으므로 여기에서는 소셜 네트웍이라고 부르지 않는다.) 한 가지 주목할 점은 소셜 네트웍을 통한 저작의 자유로운 유통 과정에서 점차적으로 영향력이 높은 저작자들이 생겨나는데 이들은 대부분 전문가들이라고 한다.
이 점을 잘 활용하면 Social Authoring이란 형태도 가능하지 않을까 생각해본다.

결론 : 공공 선, 도덕성의 도전 그리고 수익
copyleft symbol
공개는 GPL(GNU Public License)과 FSF(Free Software Foundation)를 빼고 논하기 어렵다. 소프트웨어 저작물의 핵심인 소스 코드를 공개하고, 또 이를 무료로 사용하게 하여 공공재화하겠다는 생각은 기업의 수익과 직접적으로 연결할 방법을 차단하는 데 목적이 있다고 볼 수 있다.공개 소프트웨어 운동은 수익에 얽매이지 않은 인간의 지적 결과물에 대한 공유 정신에 출발하고 있다.
하지만, 경제 활동을 통해 수익을 창출해야 하는 사람으로써 이 아름다운 정신의 결과물을 통해 수익을 고민하는 어려운 상황일 수밖에 없다. 엄청난 기업 Google이 "Don't be evil"이라는 내부적인 기업 모토를 가지고 많은 내부 지적 자산의 공개를 하는 데서 보듯이, 공개의 움직임은 기업에 대한 도덕적 압박을 포함하고 있다.
분명한 것은 공개 운동에서 직접적인 수익은 매우 미약하다. 공개의 주요 주체인 참여 행위를 두고 공동체 형태와 소셜 형태 두 가지를 구분하여 보면 공동체 형태는 기업 후원 형태가 아니라면, 공공 선에 대한 욕구가 수반된 자발적 참여가 핵심이라고 볼 수 있다. 소셜은 창작 집단으로서는 아직 형태를 나타내지 않고 있지만, 다양한 저작의 유통 경로가 되고 있다.

결론은 크지 않다. 당연하게도 공개 자체는 직접 수익을 주지 않는다. 공동체와 소셜에서 유적 존재인 사람들을 주목하고 이들의 행위를 분석하여 저작에 기여케 하는 것과 이들의 행위를 유인하는 것에서 수익을 고민하는 것 뿐이다. 저작 행위 자체가 사람의 욕구에 포함되므로, 이를 활용하는 서비스나 Application들은 이중의 혜택을 얻을 수 있을 것 같다. Facebook이나 Twitter가 microblogging 수단이자, social 유통 채널인 점은 시사하는 바가 크다.

화요일, 9월 21, 2010

Idea(아이디어)와 Creative Innovation(창의적 혁신)이 핵심 가치이다.

창의성을 키우는 영재 교육
초등학교 3학년인 큰 애가 수학 문제 풀기가 싫다고 해서 살짝 놀랐다. 아빠를 꼭 닮아서 단순 암기를 싫어하고, 새로운 걸 익히는 걸 좋아할 줄 알았는데.
자세히 들어보니, 학교 수학이 싫다고 한다. 단순 반복에 가까운 숙제가 많아서 수학에 흥미를 잃고 있는 것 같다. 수학은 논리적 사고와 모든 과학의 핵심이 되는 기초인데 자칫 큰일나겠다 싶어 서점에서 영재교육용 수학책을 하나 사서 일요일마다 아빠랑 같이 풀어보기로 했다. (일주일에 한번 한다니 아빠랑 수학하는 걸 특별히 허락해준다고 ㅠ_ㅠ;;)
그런데 영재교육용 수학책을 들쳐보니 앞쪽은 모두 창의력에 대한 얘기이다. (Torrance, Treffinger 등이 대표적인 이론가라고 한다.)
여기에 몇가지 창의의 방법이 소개되어 있어서 언급해본다.

  • 판단을 유보하고 통제한다.
  • 계속 질문한다.
판단을 유보하는 것은 창의를 위해 매우 중요한 부분인데, 직관적인 느낌으로 미리 판단해버리게 되면 숙고의 과정을 거칠 수가 없고, 모든 논의가 중단되어 버린다. 판단은 신중하게 해야 한다. 실패한 발명의 대명사라고 하는 3M의 포스트잇 같은 사례에서 볼 수 있듯 창의적 판단은 현상적 실패나 불합치에서도 섣불리 판단하지 않는다. 결론을 미리 고정해버리면 사고의 풍부함이 생겨날 수 없다. 아이디어의 빈도는 높더라도 단순한 사람들이 많은데, 이러한 습성 때문에 아이디어가 단순한 생각에 그치거나 수준이 떨어지는 경우가 대부분인 것 같다.

질문이라는 것은 끊임없이 다시 생각하는 것을 의미한다. 부끄러워하지 말고 질문을 통해 정확하게 이해하고, 호기심을 끊임없이 자극하면서 질문을 반복해야 사물을 좀더 이해하고, 새로운 면을 발견해낼 수 있다.

창의는 소프트웨어의 핵심
수익을 목적으로 하는 기업에 몸담고 있으면서, 소프트웨어가 주문 제작 방식의 단순 공정이나 혼이 없는 복제에서 벗어나 높은 수익을 만들기 위해서는 차별화된 아이디어를 담아야 한다. 또, 하나의 특이한 아이디어가 아니라 지속적으로 크고작은 아이디어를 만들어내야 하며, 상당한 기술적 진입 장벽 위에 구축해야 지속 가능한 수익을 만들 수 있다.

지금 소프트웨어를 리딩하는 최고의 기업인 Facebook, Google, Apple 등은 이러한 창의의 규칙을 지키는 미국 기업이라는 공통점을 가지고 있다. 전통적인 미국 대기업들도 매우 힘들어하는 미국의 경제 상황에서도 이들 기업은 지속적으로 혁신을 이어가면서 오히려 기록적인 자산 가치를 기록해가고 있다.

국내의 상황은 문화적인 특성이든, 소프트웨어에 대한 이해가 척박한 탓이든 아직 소프트웨어로 큰 수익을 내는 기업은 없고, 앞으로도 쉽지 않을 것 같다.
교육의 개선으로 창의적 영재들이 앞으로 많이 길러질텐데, 이들을 받아줄 수 있는 기업이 없으면 결국 창의력 교육은 없어지거나, 해외로 우수 인력이 빠져나가거나, 아니면 우수 영재들이 다시 각종 국가고시와 의대 편입 등의 길을 가는 현실이 반복될 것이다.

창의는 "Thinking and Thinking"에서 출발
개인의 창의력을 최대한 발휘하기 위해서는 평소 생활에서 생각을 정리하고 기록하는 습관이 필요하다. 개별 생각을 정리하는 데는 mind map을 그리는 것이 많은 도움이 된다. 큰 보드에 포스트잇을 사용하여 그리든, 스케치북에 그리든 혹은 freemind와 같은 프로그램을 사용하든 mind map 을 사용하여 평소에 떠오르는 생각들을 그래프로 연결하여 기록해두는 습관이 매우 중요하다.mind map 외에 메모를 남기는 것도 또다른 방법이다. 스마트폰이 아닌 일반 피처폰에도 메모 기능은 있으니, 아이디어가 떠오르면 반드시 메모를 남기는 습관을 가지는 게 좋다.

하지만, 단순한 아이디어만으로 가치 있는 창의가 만들어지지는 않는다. 가치 있는 아이디어는 보통 지속적인 생각의 결과물로 연상되어 번뜩 떠오르는 경우가 많다.
두 차례 노벨상을 수상했던 Linus Pauling은 아이디어가 굉장히 많은 사람이었는데 그는 후에 대부분의 자기 아이디어는 별 소득없는 것들이라고 고백했다. 엄청나게 많은 아이디어를 냄으로써 인류에 기여할 수 있었다는 것이다.

“좋은 아이디어를 만드는 최선의 방법은 많은 생각을 하는 것이다. The best way to have a good idea is to have lots of ideas.” (quoted from http://conciselearning.com/quotes.html) 

끊임없이 생각을 함으로써 얻어지는 결과를 또다시 생각하여 얻어내는 것이 창의적 아이디어라는 것이다.

우연적 창의와 통찰에 기반한 창의
창의나 발명은 순수한 우연에 의해 갑자기 만나는 것으로만 이해하는 경향이 있다. 이것은 창의를 신이 전달한 신호를 듣는 것 정도로 생각하게 한다. 하지만, 창의란 어떤 가치를 가지는 새로운 것을 만드는 행위를 뜻하는 것이라면, 이 가치의 방향에 따라 우연적인 창의와 창의적 문제 해결을 구분할 수가 있다.
우연적 창의는 뚜렷한 목적을 가지고 만들어지는 것이 아니며, 오히려 목적과 상대적으로 적게 연관된 것의 연상을 통한 창의라고 볼 수 있다. 우연적 창의 역시 가치를 가지지만, 과학이나 기업 활동, 특히 소프트웨어에서는 일상적으로 목적을 가진 창의 즉, 창의적 문제 해결(Creative Problem Solving)에 더 무게를 두고 있다고 볼 수 있다.

창의적 문제 해결 또한 우연적 계기를 통해 문제를 해결할 가능성도 열려 있으므로, 기본적으로는 끊임없는 사유에 의해 만들어지는 것이라고 볼 수 있다.
예를 들어 아인슈타인의 일반 상대성 이론은 수년 간의 헛된 계산을 뒤로 하고, 어느날 꿈결의 계시처럼 풀렸다고 한다. 이러한 완전히 새로운 아이디어 혹은 해법은 갑자기 떠오르지만, 그것이 떠오르기까진 줄곧 오랜 동안 그 문제를 생각하고 있는 것이다.

사람의 두뇌는 동일한 입력에 대해 동일하고 순차적인 출력을 던져주지 않는다. 지속적인 사유는 불현듯 새로운 생각을 떠오르게 하고, 그 생각을 논리 틀에서 포착할 때 가치있는 창의로 거듭나게 된다.

우연으로 보이는 뛰어난 아이디어는 그것을 포착할 수 있도록 수많은 시간을 생각과 생각으로 보낸 노력의 결과들이거나, 혹은 그 결과를 재해석함으로써 실패한 창의 혹은 발명을 새로운 성공적 창의로 이끌어낸 덕분에 가치를 부여받게 된다.

통찰, 지적 추상화를 통한 고급한 지적 구조물의 생성
이러한 우연처럼 보이는 아이디어를 포착하기 위해서는 이를 끄집어낼 수 있는 충분한 지식과 경험, 그리고 논리적 사유가 필요하다.
창의의 매우 중요한 수단 중 하나로, 지적 추상화를 들 수 있다.

"지적 추상화(Abstraction)는 하위의 개념들을 결합하여 상위의 고급 개념들을 만들어나가는 지적 발전의 단계로 한 분야의 전문가는 모두 이런 과정을 거친다. '말이 통하지 않는다'는 것은 추상화의 레벨이 다르기 때문인 경우가 흔하다. 높은 추상화 레벨은 연구와 개발에 있어 정신적인 여유를 갖기 위해 매우 중요하다. 자신이 전혀 모르는 새로운 응용 분야를 접해도 '까짓것 조금만 들여다보면 되지'하는 배짱도 생긴다. 이론적인 빌딩 블록은 새로운 주제를 빠른 시간에 파악할 수 있게 해준다."
 - 문병로, 쉽게 배우는 알고리즘 - 관계 중심의 사고법 서문 중

지적 추상화는 귀납적 사고를 통해 bottom-up으로 하위의 개념들을 기반으로 고급한 개념들을 빌딩해가는 논리적 방법이다. 사람의 사유는 지적 추상화를 통해 점점 더 복잡한 사물을 좀더 본질적인 측면을 중심으로 쉽게 인지할 수 있게 되는데 여기에서 중요한 것은 사유의 결과물인 추상화된 개념이다.
물론 이 개념의 정확성 여부를 여러 가지 검증 실험이나 사례, 사고 실험 등을 통해 입증하는 것은 과학적 사고의 기본이다.

추상화된 개념은 은유를 통해 생생하게 그릴 수 있는 정신적 상(mental image)여야 한다
창의적인 결론을 이끌어내기에 충분한 개념들은 스스로 충분히 이해한 결과물이어야 하며, 이것은 정신적인 어떤 상(image)로 표현되어야 한다. 이 정신적인 상을 현실 세계의 유사한 사물이나 다른 관념과 은유(metaphor)로 쉽게 연결할 수 있어야 좀더 생생하게 살아있는 개념이 된다.
은유가 구체적일수록 개념에 대한 이해가 더욱 깊어질수 있으며, 원래 의도하지 않았던 다른 측면까지 연상 효과가 촉진된다.
즉, 창의적 사고의 기반이 되는 지적 추상화를 통한 고도화된 사고는 본질적인 측면을 현실 세계의 다른 측면의 확장이나 변형을 통하여 은유할 수 있을 때 비로소 진정한 개념적 존재로서 사고 속에 자리잡게 된다. 이 비유에 대한 다양한 사고 실험과 공격, 그리고 연상을 통해서 더욱 풍부한 개념과 새로운 아이디어를 유발해내게 된다.

저작이나 다이어그램 등 논리의 외화는 사고의 검증과 발전의 훌륭한 방법
개념을 추상화하고 이를 검증하는 하나의 방법으로 생각을 체계적으로 정리하는 것도 매우 효율이 높은 방법이다.
생각을 체계적으로 정리하는 것은 머리 속의 생각을 바깥으로 끄집어내는 것으로, 논리를 기승전결 구조에 맞추어 블로깅을 하거나, 논문 형태로 작성하거나 프레젠테이션, 혹은 좀더 간단하게 다이어그램으로 표현하는 작업이 이에 해당한다. 광의의 저작(Authoring)이라고 불러도 좋을 듯하다.

저작의 과정은 생각의 개별 조각들을 연결을 하는 매우 중요한 과정이다. 지적 추상화의 과정도 저작의 과정에서 다양하게 일어나게 된다. 주제와 목적에 맞게 분석과 사고 실험 결과를 재구성하고 결론을 도출해내는 훈련을 통해 체계적 사고가 가능해지고 단편화된 지식이 아닌 총화된 산 지식을 갖추게 된다.
저작 행위의 핵심은 개별 지식을 총체적으로 연결하는 새로운 개념으로의 지적 추상화이다.

이 저작 과정을 통해서 생각의 미진한 부분들을 찾아 메울 수 있게 되고, 단편 지식들을 총화할 수 있게 된다.

가장 효율적인 창의의 과정은 여러 사람이 참여하는 회의
개인 혼자서도 외화 과정을 통해 생각을 정리하고, mental image를 구성하며 그 과정에서 정리되지 않은 생각들을 재조립하고 걸러낼 수 있다.
하지만, 기업이나 학교에서라면 외화의 과정을 회의 형태로 담아낸다면 여러 전문가들이 이 mental image를 공유하고 보완할 수 있다. 생각을 잘 정리하였다면 회의를 통해 보다 쉽게 소통하고 다른 참여자를 이해시킬 수 있으며, 이를 통해 본질적인 아이디어의 다양한 측면에 대해 검증하고 또 새로운 아이디어를 포함시킬 수 있다.
회의는 차원 전문가들이 다차원에 숨어 있는 거대한 거인의 모습을 총화해내는 과정과 유사하다. 서로 다른 시각들이 교차하면서 혼자 바라본 상에 대한 오류와 미흡한 부분을 보완해내고, 또 완전히 새로운 상까지 짧은 시간 안에 도달할 수 있다.

회의의 참여자는 회의 성격에 적합한 능력을 갖춘 적극적인 참여자, 뛰어나지만 회의에 적극적이지 않은 전문가, 그리고 열렬한 청중 정도로 제한하면 된다. 능력을 갖춘 적극적인 참여자는 물론, 참여에는 적극적이지 않지만, 일단 불이 붙으면 전문적 식견을 갖추고 회의로 끌어들여 회의의 수준을 높일 수 있는 전문가만 회의에 참여시키고 열렬한 청중은 참여를 제한하고 회의를 방해하지 않는 수준에서만 참여하도록 하면 좋은 회의가 이루어진다. 물론 회의를 이끄는 사람이 전체적인 사고 모델을 정확하게 가지면서 회의의 흐름을 잘 이끌어야 한다. (회의 진행자는 새로운 아이디어에 큰 갈증을 가진 사막의 여행자와 같아야 한다.)

회의에서 같은 공간에서 마주보면서 느끼는 것은 매우 중요한 요소이다. Conference Call 같은 경우는 상당히 답답하며, 바로 소통하는 데에 한계를 느끼기 쉬운데 최근에는 원격지를 포함한 회의를 같은 공간에서 하는 것처럼 느끼게 해주는 Video Conference Call 기술이 액센추어인가 회사의 회의실에 구현이 되는 걸 보았다. 여기에서는 어떨지 궁금하다.

회의나 세미나 형태를 통한 발표의 경우, 풍부한 정신적 상으로 이해하는 사람은 다른 사람들에게 보다 쉽게 생각을 전달할 수 있는 가능성이 높다. 흔히 정말 제대로 이해하고 있는 사람은 비전문가에게도 쉽게 설명해줄 수 있다고 한다.
물론 크게 보아 맞는 말이라고 생각하지만, 설명의 대상을 두 가지로 나눠보는 게 더 좋을 것 같다. 전혀 식견이 없는 비전문가들을 대상으로 하는 설명과 기본적인 전문성은 공유하는 사람들을 대상으로 하는 설명이 그것인데, 전자와 후자를 잘하는 능력은 크게 다르다고 본다. 엄밀한 지적 상을 잘 가진 사람이 잘 설명할 수 있는 대상은 1차적으로는 후자이다. 일반인에게까지 잘 설명하는 것은 이 능력에 더하여 좀 다른 타고난 능력이 요구된다고 생각한다. (한겨레신문의 Science On 이란 온라인 잡지에 보면 아인슈타인 방정식을 이해시켜달라는 샐러리맨을 위해 1년 동안 미적분학부터 가르치는 물리학자에 대한 얘기가 나온다.) 이런 능력과 인내심도 있으면 좋겠지만 실용적인 필요성이나 논리적인 인과 관계 측면에서나 요구하기 어렵다.

소프트웨어 기업에서 창의는?
소프트웨어에서 창의는 왜 핵심일까? 소프트웨어는 인간의 논리 체계를 따라 제품을 만들게 된다. 사람의 사고가 다양한 수준에서 결정을 요구한다. 구체적으로는 개별 코드 수준에서도 여러 가지 분기가 가능하고, 풀려고 하는 문제를 인지하는 시점에서부터 완전히 다른 제품에 대한 기획이 가능하다. 수많은 접근법이 가능하고 단 한 가지의 해답만이 존재하지 않는 곳이 소프트웨어이다.

일전에 가장 창의성을 요구하는 분야라고 할 수 있는 디자인 회사의 네 가지 조직 문화의 원칙에 대해 언급한 적이 있다.
  1. 일반 직원의 참여를 제도화하는 관리
  2. 억눌림 없는 분위기
  3. 자기 만족에 머물지 않도록 자극하는 관리
  4. 개성과 다양성을 독려하는 분위기
소프트웨어 기업 조직은 창의성을 우선시할 수도 있고, 일정 안에 주어진 과업을 완수하는 것을 목적으로 할 수도 있다.
해당 기업이 어떤 부분에서 주된 수익을 만들려고 하는가에 따라 다른 선택을 하는 것이라고 생각한다. 다만, 창의적인 문제 해결의 기풍은 어느 기업이든 어느 조직이든 필요한 기풍이라고 생각된다.
창의적인 소프트웨어를 만들기 위해 매일 생각만 하고 제품 개발은 안하는 것은 물론 아니다. 우수한 기술을 바탕으로 끊임없는 경쟁 속에서 차별화된 제품을 빠른 시간 안에 시장에 내놓는 것이 소프트웨어 기업도 마찬가지의 목적이다. (소프트웨어 기업의 실행 능력이 중요하다)
하지만, 차별화된 아이디어, 차별화된 해법, 차별화된 기술 속에서 기업 제품의 존망을 걸고 도전하는 회사와 현실적으로 그러한 도전은 주어진 주관적 역량으로 봤을 때 무모한 회사가 있다.
소프트웨어 기업이 끊임없는 창의를 통해 수익을 만든다면, 그 수익은 엄청난 규모가 될 수 있다. 사람 수에 의존하는 소프트웨어 기업이 아니라 창의적인 사람 수와 기술 혁신의 수준, 빈도에 의존하는 소프트웨어 기업 소수가 가장 큰 수익을 낼 수밖에 없을 것이다.

국내 소프트웨어 기업은 사실 존재감이 점점 더 미약해지고 있다. 하나도 없는 게 아닐까 할 정도의 수준이 되어가고 있다. 그나마 존재하는 소프트웨어 기업들도 수익률 면에서는 좋아 보이지 않는다. 새로운 제품을 만드는 경우도 잘 보이지 않고, 한번 만든 제품을 근근히 유지보수하면서 수익을 울겨먹는 느낌을 준다. 더 이상 눈에 띄는 새 제품을 만들 가능성도 별로 보이지 않는다. 처음부터 몇몇 개발자들에 의해 핵심 코드가 작성되었고, 이를 유지보수하면서 코드는 뒤집어도 핵심 아이디어는 그대로인 제품들인 셈이다.

창의와 혁신의 기업 문화는 쉽게 만들어지지 않는다. 전사적으로 사운을 걸고 이를 위해 하나하나의 회의 문화부터 바꿔나가고, 끊임없이 구성원들의 아이디어를 요구하고 독려하고, 좋은 아이디어를 끊임없이 사업화하고 나쁜 아이디어를 배척하고 그 이유에 대해 공유하는 과정이 필요하다.
그 과정에서 개인들의 창의를 긴 잠에서 깨어나게 하는 여러 가지 기법들을 소개, 공유하고 우수한 성원들에게 창의의 자신감을 갖게 해야 한다.

일단 성공의 사례가 생기면 창의의 자신감은 바이러스처럼 전염, 확산되게 마련이다.
하나의 창의적인 기업이 성공하면 또다른 창의적 기업들을 쉽게 만들어낼 것이다. 창의에 전염된 사람들은 또다른 창의에 몸던질 도전을 쉽게 결정할 것이니까.

화요일, 9월 14, 2010

Social Networks, 연결하여 더욱 자유로운 개인들

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"라는 도발이다.
근거로 사용하고 있는 그래프는 2000년 웹이 차지하는 트래픽이 50% 가까왔는데 2010년에는 23%로 줄고, 대신 비디오 트래픽이 약 51% 가까이 급증한다는 인터넷 트래픽 분석 데이터이다.
언뜻 보기에도 좀 지나친 비약이라고 보여진다. 비디오 트래픽이 급증한 것은 네트웍 인프라의 확충으로 대역폭이 넓어진 결과가 아닌가 생각된다.
이러한 데이터가 최근 애플이 Apple TV가 스트리밍 전용의 가벼운 장치로 거듭나게 한 결정의 배경이라면 설득력이 있겠지만, 웹이 죽었다고 할 수 있는 근거 데이터는 아니다.

오히려 웹이 죽었다고 할 수 있는 근거들은 웹 트래픽의 비중이 준 것보다는 웹 트래픽의 구성이 변화하고 있다거나 웹 기술의 구성이 변화하고 있는 점을 들어야 좀더 설득력이 있을 것이다.
웹 플랫폼을 과점하고 있는 구글이 Web 2.0 기술의 가장 큰 수혜자이자 기술 리더였다면 현재의 상황은 Web 2.0 기술이 주도하던 기술 기반 위에서 새로운 기술 환경으로의 변화를 보여주는 시기라고 볼 수 있다. 그것은 분명 iPhone 발명이 주도하고 있는 새로운 Mobile Computing 환경과 관련이 있다.

본격적인 Mobile Computing 시대
Smart Phone의 대중화로 인해 사람들의 인터넷 사용 방법이 크게 변화하고 있다. 복잡한 오피스 업무는 여전히 PC 환경에서 MS 오피스를 사용하고 있지만, 이를 제외한 다른 컴퓨팅들은 굳이 PC를 사용하지 않게 되었고, 인터넷을 사용하는 컴퓨팅 장치가 점점 더 mobile화되어가고 있다.
이제 PC보다는 mobile device에서 인터넷에 손쉽게 접속할 수 있게 되었다.

이것은 Web 2.0 기술의 성장을 통해 만들어진 웹 기술들 중 기존 HTML 기술의 비중 약화를 가져오고 있다. Web 2.0이 가져온 Open API나 Mashup과 같은 기술들은 여전히 유효하지만, 모바일에서 웹을 접근하는 방식이 웹 브라우저에만 의존하지 않고, 전용 App을 통해 좀더 편한 경로를 제공하기 시작하였다. 여전히 HTML이 클라이언트 기술 표준으로 존재하고 HTML 5 표준화 작업이 보여주듯 smart mobile computing 환경에 적합하도록 진화하고 있지만, App이라는 쉬운 대체 경로가 만들어지고 있다.

구글은 application들도 웹 기반, 특히 HTML 기반으로 옮겨갈 것이라는 비전을 가지고 많은 기술 투자를 해온 회사이지만, HTML과 AJAX 기술을 사용한 클라이언트는 예전에 비해 많은 발전을 해왔음에도 불구하고, 여전히 상대적으로 사용하기 불편하고 느리며 한계가 분명하다.
이것은 분명 구글로서는 최대의 도전일 것이다. Chrome이라는 플랫폼은 무엇보다 HTML+AJAX 기반의 app들을 실행하는 플랫폼이기 때문이다.
하지만, 현실적으로는 플랫폼에 최적화된 app들에 비해 사용자들을 사로잡기 어렵고, 개발 기술 측면에서도 사용성 높은 app을 빠르게 개발하기에 매우 어려운 플랫폼이 웹 플랫폼이다.

Web 2.0 기술의 발전으로 서버쪽 기술들은 Open API라는 통일적인 인터페이스를 제공하는 데 대부분 동의를 하지만, 이를 사용자들에게 보여줄 클라이언트는 굳이 HTML+AJAX로 가야할 필요성을 못느끼는 경우가 많다.

과거 cross platform이라는 이름으로 Java를 사용하여 클라이언트 프로그램을 만들 경우에도 발생하던 문제인데, 사용자는 구현 기술로 Java를 사용했든 MS-Windows WIN32 API를 사용했든 문제삼지 않는다. 문제삼는 부분은 사용하는 플랫폼과 전혀 다른 독특한 사용자 인터페이스를 제공할 경우 당황하게 된다는 점과, 원래 플랫폼이 제공하는 최신의 기능을 사용하여 보다 나은 사용성을 제공할 수 있느냐는 것이다. 웹 플랫폼 역시 웹 브라우저라는 하나의 레이어 위에 올라가는 cross-platform 기술이므로 클라이언트 구현 시에는 동일한 이슈를 안고 있을 수밖에 없다.

결국 구글이 처음 생각한 것은 고정된 여러 개의 데스크탑에서 동일하게 실행되는 웹탑이었는데, 회사와 집, 노트북에 동일하게 보여질 웹탑이 Smart Mobile device의 등장으로 그 동일성이라는 가치가 사람들에게 주는 매력이 매우 줄어들었다. iPhone과 iPad, iPod Touch 같은 기기에서는 데스크탑과 같은 기능, 같은 화면을 보여주는 데 그치는 것이 아니라 독특한 터치감을 살려 그에 맞는 디자인과 사용성을 가진 새로운 App으로 만들어지길 기대하기 때문이다.

데스크탑 컴퓨터와 노트북 컴퓨터에서 모바일 컴퓨터로 이어지는 컴퓨팅 기기들에 동일한 app들이 동일하게 실행되길 원할 것 같았지만, 막상 모바일 시대를 맞이하고 보니 손에 들고 다니는 모바일 컴퓨터는 사람들에게 컴퓨터라기보단 똑똑하고 interactive한 새로운 기기로 받아들여지고 있는 것이다. Apple의 Steve Jobs가 이러한 현상을 주도했다고 봐야 할 것이다.

물론 HTML 5의 등장으로 점점 더 많은 모바일 클라이언트 App들은 HTML 기반으로 작성될 가능성은 열려있다. 하지만, 사용성이 뛰어난 App들은 HTML 만으로 작성하기 어려우며, HTML이 모든  모바일 클라이언트를 대체해버릴만큼 사용자들을 사로잡기는 어려울 것이다. 사용자들은 HTML 기반 App이든 native App이든 적당한 사용성이 아니라 최적의 사용성을 원하는 경향이 있다.

Cloud Computing 기반 위의 Mobile Computing
iPhone이 성공할 수 있었던 배경에는 구글이 주도한 클라우드 컴퓨팅이란 기반이 있다.
20년 전부터 한동안 유행했던 thin client 패러다임을 생각해보자.
전통적인 서버/클라이언트 방식의 컴퓨팅 모델에서 클라이언트의 역할을 최소화하여 클라이언트 비용을 줄이고 서버의 컴퓨팅 능력을 최대한 활용하는 모델이 thin client이다.
유닉스 시스템 구성에서 X 터미널이 이러한 thin client의 전형적인 예였으며, 실제 구성에서는 PC를 X 터미널 대용으로 사용하는 구성도 많이 사용하였다. 그후 자바가 인기를 끌면서 웹탑(webtop)이라는 개념으로 PC 중심의 데스크탑을 대체해보려는 시도도 많이 나왔다.
thin client의 핵심은 클라이언트는 힘든(?) 계산을 하지 않고 서버가 한다는 것이다.

클라우드 컴퓨팅은 인터넷이라는 전지구 단위의 서버/클라이언트 컴퓨팅을 가능하게 한다.
현재 mobile 컴퓨팅의 핵심은 computing의 mobility 에도 있지만, 인터넷 접근성의 mobility도 매우 중요한 요소이다.
구글이 주도한 클라우드 컴퓨팅과 웹 2.0은 인터넷만 접근하면 서버라고 할 수 있는 인터넷의 엄청난 컴퓨팅 능력을 사용할 수 있도록 해주는 기반을 만들어두었다.
즉, mobile 기기들은 인터넷 접근성을 가진 프로그램(App)들을 통해 마치 thin client처럼 동작하여, 클라우드 컴퓨팅의 콘솔 역할도 할 수 있다.

그림 : Mobile 컴퓨팅과 Cloud 컴퓨팅

그러나, Apple이 보여주고 있듯이 현재의 모바일 컴퓨팅은 클라우드에 대한 콘솔 기능과 더불어, 게임 기기, 멀티미디어 기기 등의 복합 기기 역할을 하고 있다.
클라우드에 대해서는 thin client 역할을 하기 때문에 복잡한 컴퓨팅에 대한 부담을 클라우드로 전가할 수 있는 반면, 사람이 향유할 수 있는 다양한 시각, 청각, 촉각, 또 동작 센서 기능들을 통합하고 있기 때문에 각 개인이 다양한 감각을 통해 향유할 수 있는 컴퓨팅 장치이기도 하다.

현재의 모바일 기기는 다음 세 가지 역할을 할 수 있다.


  1. 클라우드(인터넷) 컴퓨팅의 콘솔 역할
  2. 감각적으로 향유할 수 있는 문화 기기
  3. 감각적으로 클라우드와 만나는 기기. 즉, 인터넷이 형성하는 사회와 감각적으로 교류하는 관문.


이렇게 본다면 웹이 죽고 살고는 별로 중요한 일은 아닌 듯하다. 인터넷의 또하나의 이름인 클라우드가 없었다면 스마트 모바일 혁명은 없었다. HTML이라는 문서 형태가 애플리케이션 개발 방법으로서의 지위를 획득하지 못한다고 해서 웹이 죽니 사니 하는 것은 조금 이상하다. 클라우드는 점점 더 강화될 것이니 말이다.

Mobile 얘기가 나왔으니 Jobs에 대해 언급을 해야겠다. 잘 알려진대로 Apple의 창업자인 Steve Jobs는 매우 섬세한 감각을 가진 사람이다. 인간의 미적 본성에 대해서는 타협할 줄 모르며, 컴퓨터의 구석구석(하드웨어, 소프트웨어 모두)에 심미를 적용했을 뿐 아니라 컴퓨터 기기를 활용하여 새로운 문화를 예측하는 예지력을 가지고 있다. 구글이 모든 것이 웹을 통한다고 하여 웹의 길목을 전지구적으로 만들고 지켜나갔듯이, Jobs는 문화가 컴퓨터와 연결되는 통로를 만들고 지켜나간다. 음악, 영화, 책, TV, 게임을 사람의 손 안에 아름답게 내려앉혔다. Apple이 지키고 선 저 통로의 일부만 확보하면, 향후 10년은 멋진 비즈니스가 가능하지 않을까 생각해본다. 통로를 막고 통행세를 받긴 해도 공생의 생태계이지, 착취의 사슬은 아니니 말이다. 게다가 그 길조차 Apple이 직접 닦은 걸 생각하면 ...

Mobile 에서 Social Networks로

Social에 대해 살펴보기에 앞서 Mobile Device가 인간의 감각을 해석하거나, 정보를 제공한다는 측면은 주목할 필요가 있다.

앞에서 언급한 것은 컴퓨팅 즉, 컴퓨터를 사용한 계산에 대한 것이었다.
웹이든, 인터넷이든, 모바일이든 컴퓨팅을 어디서 어떻게 하며 무엇을 대상으로 하는가에 대한 것이었는데, Social (Relation) Networks 사회관계망은 컴퓨팅과 직접적으로 연결되지 않는다.
Mobile 기기를 얘기하다가 컴퓨팅이 아닌 사람을 논의의 대상으로 끌어들였다. 사회관계망이란 사람의 관계 구조를 얘기하는 것이니 추상의 수준이 달라진다.

Mobile 기기의 사람 감성론을 연결 고리로 삼겠지만, 사회관계를 얘기하기엔 또다른 개념, 좀더 높은 추상 수준이 필요하다. (발상의 전환, 혹은 관점의 전환은 높은 추상 수준으로 갈수록 근본적인 지적 도발이 된다. 논리 설명이 매끄럽지 않다거나, 타성에 젖은 뻔한 결론에 실험치를 조작하여 끼어맞추고 있다면 더 높은 추상 수준에서 부정하는 지적 도발을 시도해봐야 한다. 그것이 창의이다.)

처음엔 Social Computing이라는 생각을 했다. 하지만, 적합하지 않다. 여러 사람이 협업을 하는 것을 Social Computing이라고 부를 수는 있겠지만, Facebook, Twitter, Foursquare 등에서 보고 있는 것을 컴퓨팅이라고 부르는 건 의아하다. 그냥 클라우드 기반, 웹 2.0 기반 컴퓨팅일뿐이고, 서비스 내용 측면에서 Social Networks 인간 관계가 존재하는 분야인 것이다.
다시 말해 Social Networks는 컴퓨팅 패러다임의 이동이라기보다는 컴퓨팅이 다루는 분야의 혁명이라고 봐야 한다. 다만 사람간의 관계가 컴퓨팅의 통로가 되고 플랫폼이 된다.
구글이나 Apple이 아닌 Facebook이 사람 관계 통행세를 떼간다.

왜 지금 사람 관계망인가? 이것은 앞서 말한 Mobile 혁명과 상관이 있다.
Mobile 혁명의 결과, 사람과 사람 사이의 거리가 사라져버렸다. 거의 모든 생활을 함께 하는 내 주머니 속 전화가 인터넷에 연결되어 있다. 네트웍의 특성 상 약간의 지연은 있지만, 인터넷이 버퍼링해주기 때문에 그 지연은 무시되고 실시간으로 연결되어 있다고 생각하게 된다. LA에 있는 친구, 콜롬비아에 있는 선배와 거의 실시간으로 소식과 의견을 주고 받는다.

그러면 왜 사회 관계망인가? 인터넷 전화와 무엇이 다른가?

또하나의 사회, Social Networks
Mobile 혁명의 결과, 물리적인 거리가 인간 관계 유지에 영향을 거의 주지 못하게 되었다. 게다가 관계가 있는 사람은 어디서 무엇을 하는지를 거의 실시간으로 알 수가 있어, 같은 시간대를 살아가는 지구 마을의 동네 친구처럼 느낄 수 있게 되었다.

하지만, 이것만으로는 불충분했다. 왜 facebook과 twitter, foursquare가 뜨고 있는지. 숨겨진 Sociality의 코드는 무엇인지. 왜 구글은 facebook과 같은 소셜 서비스를 못하는지.
문제를 다 풀지는 못했지만, 한 가지 재미있는 것을 발견하였다.

Facebook의 사회 관계는 friend 하나이다. 모든 사람 사이가 친구이다.
또 Facebook의 글에 대한 반응은 like 하나이다. 싫다, 나쁘다, 멋지다, 화난다가 모두 없고 좋아함 뿐이다. (물론 share 를 함으로써 간접적으로 like를 보조적으로 표현할 수도 있다. 하지만 Facebook은 like 와 share 가 결국은 like 하나로 좀더 단순화되어야 한다고 생각하는 듯하다.)

Twitter는 어떤가? twitter의 관계는 일방적인 관계이다. 즉, 방향이 있는 화살표이다. Facebook의 친구 관계가 양쪽 모두 손을 흔들어줘야 하는 양방향 화살표인 반면, twitter는 일방적으로 내가 원하는 방송 채널을 고르듯이 내가 원하는 사람의 이야기를 고른다(follow).
뭔가 해당 채널이 조금이라도 자기와 안 맞거나 이상하거나 식상하면 바로 채널을 틀어버린다(unfollow).

다시 얘기하면 Facebook과 Twitter 모두 지극히 자기 중심의 사회 관계를 설정하게 된다. 공동체 같은 경우 의무와 책임이 따르는 소속감이 있지만, Facebook과 Twitter는 그러한 것이 없다. 사회 관계이기 때문에 친구들을 고려하여 글을 써야 하겠지만, 싫은 사람은 바로 내보낼 수 있는 자기가 구성하는 관계망이다.
like만 있고 dislike는 없는 사회. (이런 사회도 균형을 잡고 번성할 수 있다는 믿음이 없이 Facebook과 Twitter를 좋아하는 사람은 약간 이율배반은 아닐까 하는 생각도 든다. 칭찬으로 북돋우는 것이 교육 측면에서 체벌과 꾸중보다는 훨씬 더 바람직하다고 한다. 대화와 like 두 가지만으로 만들어지는 사회가 Facebook이다.)

또하나 사용자들의 feedback 방식에 대해 사용자 처지에서 생각을 해볼 필요가 있다. 이것은 기존 포털이나 서비스 제공자들도 많은 고민을 했을텐데, Facebook, Twitter의 feedback 방식은 매우 자연스럽다.
feedback이란 사회에서 매우 중요한 것이다.  Facebook의 like, share, Twitter의 RT(retweet), Favorite 등이 feedback 인데, 이것이 기존 커뮤니티에서의 랭킹 시스템과 어떻게 다른지를 주목할 필요가 있다.
대표적인 기존 랭킹 시스템은 글에 대해 별을 다는 시스템이다. 자발적인 참여에 기초하거나 인센티브를 제공하여 별을 달게 하는 것인데, Facebook이나 Twitter는 그럴 필요가 없다.
왜 그럴까 하는 것인데, 친구들 글을 읽고 "좋아, 멋져" 하며 친구를 북돋아주는 것은 자발적인 참여도 아니고 인센티브도 아니다. 너무 자연스러운 사람의 사회 행위인 것이다.
친구의 글을 읽고 반응을 나타낼 수단이 없는 것이 문제이지 몇 개의 커멘트를 남기거나 "좋아" 하는 건 너무 당연한 반응이기 때문에 부자연스러운 캠페인이나 인센티브가 필요없는 것이다.
또, 이러한 반응에 기초하여 좀더 나은 정보를 올리고 RT하는 것도 자연스러운 행위이며, 이러한 행위를 통하여 자연스럽게 올린 글들의 사회 관계 속 authority가 형성된다.
그러한 사회 관계 속의 authority가 어떻게 보면 자연스런 인센티브가 된다.

그림 : Social Networks 마인드맵

사람들의 관계에 기반하여 만들어진 사람 관계 사회는 온라인 위에서 새로운 사람 관계를 맺고 자라난다. 이 사회는 자기라는 노드를 중심으로 직접 연결된 사람들, 그리고 한 관계 걸쳐 간접 연결된 사람들로 구성이 되는 그래프로 표현된다. 철저하게 자기 중심이라는 점. 그래서 자유로운 관계의 사회라는 점이 기존의 소속감 중심의 온라인 공동체들과는 구분이 된다.

인간의 본성과 Social Networks
지금의 Social Networks Service들은 사용자들의 feedback 기반으로 authority를 구성하는 개념이라고 볼 수 있다. like, RT, share 등은 결과적으로 authority를 만들어준다.
처음엔 dislike 같은 감정의 다양화를 통해 social networks를 다르게 만들 수도 있지 않을까 고민해보았다. 하지만, dislike와 같은 감정의 다양화를 통한 접근법은 사람들을 피곤하게 만들어 결국 이 가상의 관계 그래프로 구성된 사회를 무너지게 만든다는 판단을 하게 되었다.
그렇다면 authority 외의 보상은 없을까? 실제 우리의 친목 모임에서 보상이란 무엇인가? 친구들이 좋아하면 자신도 기분좋아지는 보상은 이미 언급하였다.
또, 친구가 아닌 확장 가능한 관계는 무엇일까?
여기에 대한 대답이 새로운 Social Networks 플랫폼을 가능하게 하지 않을까 한다.
동일한 친구 네트웍은 Facebook의 아류로 그칠 것이다.

Social Networks는 현실 세계의 사람 관계 위에서 출발한다. 이미 인생을 통해 형성된 사회 관계를 자산으로 새로운 사회 관계를 만들어간다.
거리 제약이 없어지므로 온라인과 오프라인의 구분이 필요없는 새로운 인간 관계가 형성된다.
짧은 문자 메시지를 통한 publishing의 사람 네트웍을 구성한 Twitter와 친구 관계 기반의 사람 네트웍을 구성한 Facebook. 새로운 사람 네트웍은 없을까?

다시 Smart Mobile Device의 역할
손에 잡히는 Mobile Device가 개인이 바라보는 온라인 세상을 제어한다.
여기에는 미디어가 흐르고, 문화가 흐른다. 또 사람 관계를 이어주는 통로이기도 하다. 이 mobile 기기의 궁극적인 역할은 어디까지일까?
모바일 컴퓨팅, 클라우드의 콘솔, 각종 매체, TV 제어 콘솔, 게임 콘솔, ...
이 모든 것이 특정 장소에 얽매이지 않도록 해주는 기기. 그리고 나의 움직임을 클라우드 상에 공유할 수 있는 기기.
휴대성과 이동성, ubiquitous 연결성, 매체 실행 기능, 그리고 새로운 사람 관계 사회로의 출입구.

"사람을 이해하고, 손에 쥔 요술 기기를 사용하여 사람을 더욱 자유롭게 하라."

Social Networks의 틈새는 작지만, 사람의 복잡함만큼 기회는 많지 않을까.

추가 : wikipedia model과 facebook model
Web 2.0 의 철학적 기반이라고 할 참여와 공유는 위키피디아에서 가장 빛을 발했다.
위키피디아 역시 무명의 개인들이 집단 저술하는 저작물로 봐야 하는데, 이들에게는 다른 보상이 필요없다. 공공의 선 혹은 공공의 이익에 기여하는 참여 자체에서 얻는 기쁨과 또 다른 사람들로부터 해당 저작에 대한 인정을 받는 authority가 핵심 보상이다.
이러한 참여의 사상은 facebook의 개인 중심 사상과 약간 다르다고 본다.
위키피디아에 참여하는 사람은 기여를 목적으로 자발적 참여가 가능한 사람이며, 이렇게 스스로 저작에 도움을 주는 사람은 위키피디아를 향유하는 사람들 중 많지 않은 비율이라고 본다. 대부분의 사람들은 위키피디아로부터 도움을 얻을 뿐 기여를 하지는 않는다.
적극적이며 의지가 강하고, 또 전문성을 가져 authority를 인정받을 수 있는 사람들이 위키피디아의 자발적 저작자들이 될 수 있다.
이것은 facebook의 일상적인 정보 저작과는 차원이 다르다. facebook에 글을 올리는 것은 누구나 하게 되며, 또 like나 comment를 통해 해당 저작을 공유하는 것 또한 누구나 하게 된다.
wikipedia는 social network 중 의지와 능력을 가진 사람들에 의해 저작 활동과 feedback 활동이 가능한 모델이며, facebook은 누구나 일상 속에서 저작과 feedback을 하는 모델이다.
어느 것이 더 우월하고 나쁜 모델은 아니다. 두 가지는 서로 다른 SNS 모델이며, 각자의 역할이 있다.
다만 현 시점에서 논의의 한가운데 있는 것은 일반인들을 Social Network Platform으로 흡입하는 facebook과 twitter 모델이며, 비즈니스를 목적으로 하는 사람의 눈으로 볼 때에는 일반인 대상의 SNS가 훨씬 더 관심을 가질 수밖에 없다.
개인적으로 wikipedia의 참여와 공유는 공공의 선을 목적으로 하는 사회적 성격을 가지며, facebook은 개인의 자유로운 활동이 사람 관계 망을 통해 자연스레 공유되는 성격이라고 본다.
공공 선과 개인 자유라는 두 가지 철학의 차이라고나 할까?

수요일, 9월 08, 2010

영세한 국내 게임 회사들.. 환상은 없다.

(가볍게 facebook에 올리려고 했는데 Status Update는 420글자밖에 안되어서 블로그를 통해 올립니다.)

오늘 저녁, 10년 넘게 게임 회사를 운영하고 있는 후배를 만나고 왔다.
영세한 환경에 여전히 혼자서 핵심 코딩을 다한다. 4,5명 규모의 작은 영세 업체에서 우수한 인력을 확보하기란 너무 어렵기 때문에 어쩔 수 없다는 것은 묻지 않아도 보인다.

혼자서 10여년 동안 하지 않고 다른 사람들과 같이 했으면 스스로도 더 많은 일을 해볼 수 있었을 텐데 아쉽다.
그래도 이 나라에서 Online Game Software 만들어 서비스하면서 10여년을 버텼다는 것만으로도 경외로운 일이다.

서버쪽 기술을 혼자서 익혀와서 체계적이지 못하고 큰 아키텍처와 작은 아키텍처 경계가 섞인다. 티맥스 같은 회사에서 1년만 일했으면 그런 기술들을 스폰지처럼 빨아들여 훨씬 더 대단한 것도 도전할 수 있었을텐데.
여전히 새로운 기술들을 받아들이면서 또 상당한 양의 개발도 병행하랴 수면 부족 속에 살고 있다. 기술들을 받아들이는 것도 혼자서 공부하는 것보다는 여러 사람들이 분석하고 공유하고 회의하면 깊이도 깊어지고 다면적으로 바라볼 수 있을텐데.

게임 쪽을 한번 살펴보려고 하는데 현실이 너무 안스럽다. NCSoft 같은 몇몇 성공한 기업 외에 다른 게임 업체들은 얼마나 척박한가. NCSoft 역시 그러한 과거를 뚫고 성공한 기업이지.

후배 또한 성공의 기회가 온다면 놓치지 말기를.

나는 게임을 한다기보다는 Technology를 활용한 새로운 게임 장르를 하고 싶다. 게임 자체는 충분한 동기 부여가 되지 않는다. 게임 오타쿠들과 소통하기는 조금 두렵다.

화요일, 9월 07, 2010

창의적인 Smart Software Engineer를 위하여

Google을 포함해서 Facebook, Twitter와 같은 미국의 신흥 기술 기업들의 가장 큰 특징은 Smart People 을 확보하고 이들로부터 혁신을 이끌어내는 데에 회사의 운명을 걸고 있다는 점이다.

이들이 절실하게 인재들을 관리하고 이들이 최상의 Output을 낼 수 있는 환경을 만들어가는 것을 보고 있으면, 서울대 전산학과가 매년 정원 미달이라는 우리 나라 현실과 겹쳐진다.

그나마, 우리 나라 기업 문화는 Smart People들의 능력을 이끌어내어 결과를 만들어내기보다는 누구나 고만고만한 결과를 만들 수밖에 없는 관리 방식으로 인해 Smart People 무용론에 젖어있었다. 창의적인 인재들은 외국계 기업으로 나가거나, 창업했다가 한국의 기업 현실 속에 파산하고 현실과 타협하거나, 학교로 돌아가거나, 아니면 그저 혼자 잘난 체 하는 이로 별다른 역할 없이 고립되어 살아간다.

논리적인 비약이긴 하지만, 서울대 무용론 같은 것도 결국 이러한 현실, 즉 탁월한 인재가 엄청난 혁신을 가져오는 것이 불가능한 현실과 맞물려 있는 게 아닌가 싶다.

Google, Facebook, Twitter 같은 회사들은 탁월한 인재를 통해 끊임없는 기술 혁신을 주도하는 데에 회사의 운명을 거는 회사들이다. 마케팅적인 요소, 서비스나 제품 관리 요소 등 다양한 이슈들을 함께 갖고 있지만, 그것들이 회사의 운명을 좌우하는 핵심 요소들은 아니다.

왜 이러한 회사들을 우리는 만들지 못할까.
개인적으로 하루 아침에 이러한 환경을 만들 수는 없다는 답을 가지고 있다.

앞에서 언급한 데로 Smart People들이 Smart한 Output에 끊임없이 도전해야 하는데, Smart People들을 많이 보유한 회사에서 이러한 목표를 가지고 drive해주지 않으면 Smart People들은 자극을 받지 못하고 평범해지거나, 나홀로 헛똑똑이가 되고 만다.

나름 Smart하다고 생각하는 사람들이 자신보다 훨씬 Smart하고 훨씬 시간 관리에 철저하며, 훨씬 높은 Quality의 Output을 만들어내는 사람들을 주변에 두면 그로부터 자극을 받지 않을 수가 없다. 그 자극이 나홀로 Smart들을 진정한 Smart로 변모시키고 또 다른 Smart들을 만들어내는 큰 힘이 될 수 있다.

이러한 자극을 항시적으로 줄 수 있는 Smart Technology Company가 필요하다.

예를 들어, 삼성, LG, KT, SKT 등 많은 국내 대기업들이 지금 Software 쪽으로 많은 비용을 지불하고 있다. 지금 진행하는 방식은 대부분 Software 를 하기 적합한 방식이라기보다는 빠르게 Output을 만들어내는 데 목적을 둔 방식이다. best-of-breed 라기보다는 good enough 의 제품을 만드는 방식이다.
하드웨어에 특장점을 가진 삼성전자가 처음부터 best-of-breed Software를 만들겠다고 투자하는 것은 현실적으로 잘못된 접근일 것이다.
하지만, Software에서 함께 경쟁하면서 또, best-of-breed를 만들 수 있는 Task force 조직을 일부 구성할 필요를 느낄 것이다. 그러한 조직이 놀라운 성과를 내면 자연스럽게 이러한 문화는 확산될 수 있다.
이런 면에서 보면 지금 Software 투자가 중요하지, Software 투자하는 방식이 문제는 아니다. 경쟁 속에서 조금씩 변모할 수 있을 것이다.
투자하다 보면 Smart 들에 대한 가치를 발견할 기회가 있다고 믿는다. 물론 그 Smart들이 얼마나 잘 성과를 내는가에 달려있겠지만.

나홀로 Smart한 People들은 스스로 Smart하다고 자만하지 말고 끊임없이 도전해야 한다. 끊임없이 배우고, 기반을 다져가고, 또 대화해야 한다. 도전하지 않는 Smart는 머저리로 남을 뿐이다.
창의는 순간의 아이디어에 의존해서는 연속성을 가질 수가 없다. 사물에 대한 논리 체계를 정립하고 끊임없이 그 체계에 대해 도전하는 반복된 과정을 통해서 이루어진다. 경험적으로 보면 Smart People들이 대화를 시작하면 항상 새로운 (놀라운) 아이디어가 나오기 마련이다.

이러한 Smart들이 일하는 문화가 일반화되면 Larry Page, Sergey Brin, Mark Zuckerberg 같은 Super Smart들이 탄생할 수 있을 것이다.

많이 덜 Smart가 바라보는 Smart들이 Smart하게 일하는 세상...

일요일, 9월 05, 2010

Obama's decision making process in crisis

(원문 출처 : http://www.usnews.com/articles/news/obama/2009/10/27/exclusive-interview-obama-never-100-percent-certain.html)
작년에 다른 블로그에 쓴 글인데 옮겨왔습니다. 위기 상황의 의사 결정 방법과 일상에서 스트레스를 피하는 방법에 대한 오바마 대통령의 인터뷰 내용입니다. 오바마 대통령은 한번 내린 의사 결정이 완전 무결하리라고 믿지 않고 합리적 행동으로 이를 보완합니다. 과감한 결정, 실행, 피드백을 통해 뒤늦지 않게 보완. 어떤 지위에 있든 중요한 결정을 내릴 때가 있습니다. 중요한 결정은 여러 사람의 삶에 중대한 결과를 가져오게 됩니다. 어떻게 결정을 해야 할까요?

You have faced an extraordinary array of urgent problems. Is decision making under crisis conditions different from decision making in normal times?

평상시의 의사 결정과 위기 상황의 의사 결정에 다른 점이 있나요?

The things that for me work day to day become that much more important in a crisis: being able to pull together the best people and have them work as a team; insisting on analytical rigor in evaluating the nature of the problem; making sure that dissenting voices are heard and that a range of options are explored; being willing to make a decision after having looked at all the options, and then insisting on good execution as well as timely feedback, so that [if] you have to correct the decision that you make, that you are able to do so in time; being able to stay calm and steady when the stakes are high. You know, all those things are, I think, principles I try to apply in any circumstance. I find them particularly useful when the decisions are tough and the consequences of action are most weighty.

최고 사람들로 팀을 구성하여 일하게 만드는 것,
문제의 본질을 파악하기 위해 엄격한 분석을 고수하는 것,
필수적으로 반대 의견 청취와 다양한 옵션 검토를 거치는 것,
모든 옵션을 살펴본 후에는 적극적으로 결정을 내리는 것,

그 다음으로는 분명한 실행과 시의적절한 피드백을 받아서 결정을 적합한 시간 안에 수정할 수 있을 것,
엄중한 문제일 경우에는 조용하고 꾸준하게 진행할 것

How do you get away from the stress?
스트레스는 어떻게 푸시나요?

Exercise every day. Seeing my family. Keeping things in perspective. Reading history. Reminding yourself that this is a long-term proposition and you're not going to get everything exactly right, but hopefully, if you're moving things in the right trajectory, that things usually work out.

매일 운동하기.
가족과 시간 보내기.
비전을 가지고 사물을 보기.
역사책 읽기.
시간이 걸리는 사안이며, 모든 것을 완벽하게 하기보다는 일들을 바른 궤적에 올려놓으면 제대로 동작할 것이라고 낙관하기.

토요일, 9월 04, 2010

Concurrent Processing : Actor Model

actor model에 대한 개념을 정리하려 했는데 간결하지 못하고 장황해져 버렸다. actor model을 둘러싼 이슈에 대한 공유 정도로 읽어주기 바란다.

Concurrent Computing

multi-core CPU가 개인 PC에 일반화되고, 서버 환경에서도 8 CPU 서버는 흔하게 볼 수 있는 게 오늘날의 컴퓨팅 환경이다. 운영체제에서 다중 쓰레드를 지원하는 것은 기본인 데다가, 서버 소프트웨어를 운영하다 보면 발생 확률이 매우 낮을 것 같은 동시성 처리 관련 버그가 몇 달이 못가 심각한 운영 장애의 원인으로 발견되기도 한다. 또, 클라우드 환경에서는 수천대의 컴퓨터를 연결하여 연산을 동시에 분산 처리하여 빠른 결과를 가져오는 것이 일반화된 기술이 되고 있다. 단일 노드, 단일 CPU에서는 발생하기 어렵던 문제들이 서버쪽 소프트웨어에서는 매우 critical한 이슈로 매일 접하게 되었다.

흔히 concurrent programming 이라고 부르는 비동기적이고 동시적인 연산 처리 기법이 이미 보편화되어 있다.
concurrent programming을 위한 여러 가지 모델 중에서 OS 에서 제공하는 thread와 locking을 사용하여 직접 구현하는 방법 외에 수학적 기반에 출발한 처리 모델들이 몇 가지 있다. 많이 사용되는 concurrency 고려 모델에는 여기 소개할 actor model 외에 단방향 그래프 방식으로 워크플로우 구현에 많이 사용되어온 petri-net, WS-BPEL 표준의 수학적 근거로 알려진 pi-calculus(π-calculus)가 있다.

아주 간단하게 설명하자면 Petri Net은 place와 transition으로 구성된 그래프에 token의 이동을 통해 흐름을 제어하는 모델로 동시에 여러 개의 token이 존재할 수 있어 동시성을 표현한다.
Petri Net은 token이 현재의 실행 위치를 나타내므로 제어 흐름을 직관적으로 표현하는 장점이 있지만, 데이터 흐름은 고려할 수 없는 한계가 있다.

Pi Calculus는 통신 채널과 변수를 기본으로 구성한 수학적 모델이며 동시성 표현을 기본으로 지원한다. (WS-BPEL 혹은 BPEL의 프로세스 표현이 Pi Calculus 기반으로 되어 있다고 하지만, 하나의 BPEL 언어 내의 concurrency 표현이 직접적으로 Pi Calculus에 기반한다고 보긴 어려움. BPEL 프로세스의 흐름은 메시지 도달과 타이머에 의해 비동기적으로 제어되며 하나의 프로세스 내에 여러 개의 실행 지점이 있을 수 있음. BPEL은 block structure라는 언어 특성을 가지는데 concurrency control 중 하나로 사용된 Link 개념은 block structure가 아니라 petri-net과 유사한 directed graph 방식을 차용하고 있음.)

여기 소개하는 actor model은 최근 JVM 기반 functional 언어 중 하나인 Scala 에서 동시 처리를 위한 기본 모델로 채택하고, groovy 등 다른 functional 언어들에서도 앞다퉈 도입함에 따라 주목을 받아왔다.

Actor 모델
Actor 모델의 기본 구성 요소는 actor이다.
actor는 actor들 간에 메시지 전달을 통하여 통신을 한다. 즉, send와 receive라는 두 가지 동작을 하는 존재이며 각 actor들은 address를 통해 서로를 인지하게 된다.
또하나의 요소는 function이다. actor는 메시지를 전달받으면 function을 호출할 수 있으며, 또 메시지별로 function을 지정할 수도 있다.

actor 모델이 low level이라고 할 수 있는 thread와 locking을 사용하여 concurrency를 구현하는 것과 크게 다른 점은 간결성이다.
actor model은 actor들 간의 데이터(정확하게는 메시지)를 공유하지 않고, 한 시점에는 하나의 actor만 해당 메시지에 접근할 수 있다는 전제를 두고 있다.
동시에 실행되는 여러 개의 작은 프로세스들(actor이든 thread이든)이 데이터를 공유하면서부터 프로그래밍의 복잡성이 어려워지게 된다. 적어도 actor 모델에서는 actor들이 서로 공유해야 할 데이터 즉, 메시지는 시점적으로 동시에 접근하지 않는다는 전제를 하고 있으므로 locking에 대한 고려를 하지 않아도 된다. (모든 데이터 접근을 메시지 기반 모델로 가져가서 배타적으로 처리할 수 있는 것은 아니다. 요청과 응답과 같은 한시적으로 사용되는 데이터의 경우에는 배타적 처리가 쉽지만, 여러 개의 요청으로 이루어지는 대화형 처리 모델의 경우 공유되는 데이터가 존재하기 마련이고 이런 데이터는 메시지 전달 기법만으로 배타적인 데이터 처리를 할 수가 없다. 다만, 비대화형 처리의 경우에 병렬적 프로그래밍의 복잡성을 완화시켜주는 모델임은 분명하다.)

Java 에서 Worker thread model, Event-driven model 그리고 Continuation
actor model의 구현에 대해 더 나아가기 전에 잠깐 실제 저수준의 thread와 lock이 현실적인 프로세싱에서 어떻게 사용되는지를 짚어보자.

가장 흔하게 만날 수 있는 쓰레드 모델은 boss-worker 혹은 master-slave 관계라고 부르는 worker thread 모델이다. Java Enterprise Edition(Java EE)의 Servlet, EJB 등은 기본적으로 worker thread 모델에 따른 스펙이다.
요청이 들어오면 요청을 처리하기 위한 worker thread를 할당하게 되며, worker thread는 요청을 처리하고 응답을 만드는 일을 담당한다.
이 전통적인 thread 모델의 문제점은 요청을 처리하는 과정에서 blocking operation을 만나게 되면, 그 blocking operation들이 완료될 때까지 해당 worker thread가 block되어야 하기 때문에 한정된 시스템 자원인 쓰레드를 불필요하게 낭비하게 되는 것이다. 이 외에도 worker thread를 요청 시마다 만드는 오버헤드가 있지만, 이 오버헤드는 보통 thread pooling을 통하여 최소화할 수 있다.

불필요한 thread 갯수를 줄이기 위해서는 thread가 block되지 않도록 해야 하는데 이때 흔히 사용되는 방법이 event-driven model이다.
Java EE의 Servlet spec은 3.0 버전에서 AsyncServlet 스펙(JSR 315)을 포함하였다. Java EE 6에 채택된 servlet 3.0 스펙의 AsyncServlet에서는 worker thread가 하나의 메소드에서 요청과 응답을 모두 처리하여 쓰레드를 분리할 수 없는 문제를 해결하기 위해 응답을 위한 별도의 callback 을 호출할 수 있는 AsyncContext 객체를 넘겨주고, 요청 처리 쓰레드를 종료할 수 있도록 하고 있다.

비동기적인 방식으로 요청과 응답을 처리하기 위해서는 내부적으로는 요청, 응답이 준비되는 이벤트를 처리하는 이벤트 전담 처리 쓰레드를 필요로 한다. 흔히 이 방식을  event-driven 모델이라고 한다.
event-driven 모델은 훨씬 적은 갯수의 쓰레드로 context switching 오버헤드를 최소화하여 실행하기 때문에 성능 상의 큰 장점을 가지고 있지만, 동기적인 worker thread 모델에 비해 코드가 복잡해진다는 큰 단점이 있다.
즉, 요청을 처리하여 응답을 만드는 일을 하는 코드를 worker thread 모델의 경우 하나의 메소드에서 요청을 인자로 넘겨받아 차례로 처리한 후 응답을 리턴값이나 인자 등으로 넘겨주면 되지만, 이벤트 모델에서는 각 이벤트가 발생할 때마다 상태에 따라 부분 코드를 실행하도록 한 후 제어를 넘기는 state machine 방식으로 작성해야 한다.

Continuation은 쓰레드를 중지하고 재개하는 개념으로 사용되고 있으며, worker thread 모델처럼 순차적으로 요청과 응답을 처리하는 코드를 작성하고 실제 실행은 이벤트 모델처럼 비동기적으로 실행되도록 하는 데 목적을 두고 있다.
(이상적으로 말하자면, 쓰레드가 실행되다가 blocking call을 만나면 해당 쓰레드는 종료하고 실행 위치만 기억해두었다가, blocking call이 완료되는 시점에서 다른 쓰레드가 기억된 실행 위치부터 실행을 재개하는 개념이 Continuation이다. )
servlet container 중 하나인 JETTY 에서 이 개념을 다음과 같이 구현한 예가 있다.
예를 들어, 동기 처리를 하는 Servlet 클래스는 service(ServletRequest, ServletResponse) : void 라는 메소드에서 요청을 처리하고 응답을 만드는 일을 하게 된다.
JETTY의 경우에는 이 메소드 대신에 doPoll(HttpServletRequest, AjaxResponse) 라는 메소드 안에서 Continuation 객체를 만들고 이 객체에 대해 suspend를 호출하면 내부적으로 특별한 Exception을 만들어 해당 쓰레드를 종료시키고, JETTY 컨테이너는 이 Exception을 catch하여 특별한 자료 구조에 등록을 해둔다. 이후 특정 이벤트가 발생하여 다음 단계로 넘어갈 수 있으면 해당 객체를 resume 시키고 다시 해당 doPoll 메소드를 실행하게 된다.


자바 언어 자체가 thread를 중지, 재개한다거나 thread를 대체하는 방법을 제공하지 않으므로 이를 피하기 위하여 Exception으로 call stack을 벗어나는 trick을 사용하는 것인데 명시적으로 callback을 사용하지 않는다고는 하나 이벤트 모델과 유사한 state machine 방식의 코딩이 일부 포함될 수밖에 없다.
매우 tricky한 반면, 프로그래밍의 복잡성을 줄여주는 측면은 미약하므로 AsyncServlet 스펙에서는 명시적으로 callback 방식을 사용하도록 하고, JETTY의Continuation 객체 개념은 빠졌다.


Actor 모델과 Continuation
Actor 모델을 구현할 때에도 효율적인 처리를 위해서는 이벤트 모델처럼 비동기적인 처리를 할 수 있어야 한다. 명시적으로 쓰레드를 지정하지 않고 Actor 구현체 내부적으로 쓰레드를 관리하므로 효율적 구현은 더 큰 이슈라고 볼 수 있다.

자바의 Actor 모델 구현체 중 하나인 Kilim에서는 bytecode를 추가 변경하는 weaving 기법을 사용하여 Continuation을 구현한다.
Kilim은 코드를 이벤트 기반으로 변경하지 않고서 이를 구현하기 위해서 변수에 특별한 annotation을 통하여 변수의 특성을 지정하도록 하였고, 런타임에서 자바의 call stack을 unwind했다가 다시 wind하도록 call graph를 분석하여 바이트코드를 변경하는 방식으로 구현하였다.
이 방식은 JETTY의 Exception을 사용한 방식에 비하면 훨씬 진보한 방식이지만, 구현이 까다롭고 코더가 변수에 대해 annotation을 지정하는 등 추가적인 코드 작업이 있어 아주 깔끔하지는 않다.

JVM 기반의 functional language인 Scala 에서 제공하는 actor framework 은 메시지 패턴에 따른 함수를 지정할 수 있고, receive 대신 event 기반의 처리를 할 수 있는 react 메소드를 지원하여 Continuation 문제를 해결하려고 한다. 즉, Kilim의 해결 방향은 코드는 그대로 두고 annotation과 static analysis를 사용하여 event-driven과 유사한 효과를 만드는 것이었다면 Scala는 최소한의 코드 변경을 통하여 event-driven 방식의 concurrent programming을 가능하도록 시도하고 있다. Scala의 방식은 AsyncServlet의 코드 패턴에 비해 좀더 직관성을 유지할 수 있다. (inversion of control이 발생하지 않는다.)

결론 : Concurrent Programming과 Performance, Code Complexity
정리하자면 concurrent programming은 크게 두 가지의 문제를 주로 다룬다.

하나는 동시에 여러 개의 쓰레드 혹은 프로세스가 서로 공유하는 자원에 접근할 때의 배타성 보장 문제 즉, locking 문제이다. 이 문제의 가장 좋은 해결책은 동시에 여러 개의 쓰레드가 접근할 필요가 없도록 구성하여 lock-free가 되도록 하는 것이다. actor model은 메시지의 경우 동시에 여러 actor가 같은 메시지에 접근하지 않도록 하여 lock 문제를 피하고 있다. 하지만 공유하는 stateful data 중 일부는 이러한 방법으로 동시 접근 문제를 회피할 수 없는 경우가 있다. 이때에는 전통적인 lock을 사용할 수밖에 없다.

두번째 문제는 쓰레드 갯수가 증가함에 따라 시스템 자원이 낭비되고, 컨텍스트 스위칭 오버헤드에 의한 성능 저하가 심각하게 발생하는 것이다. 이 문제의 가장 좋은 해결책은 Event-driven 방식의 concurrent programming을 하는 것인데, event-driven 방법은  blocking되는 순간 제어를 다른 무엇인가에 넘겨줬다가 block을 해지하는 event가 발생할 때 callback을 호출하는 방법으로 주로 구현되어 코드의 복잡성이 높아지고, 같은 일을 하는 코드 부분들이 떨어져 존재하게 되어 가독성도 떨어진다.
이 복잡성을 줄이기 위해 actor framework의 구현체들은 부분 함수들을 각 메시지 수신별로 지정한다거나, static analysis를 통한 bytecode weaving 기법을 사용하기도 한다.

결론적으로 actor framework은 첫번째 문제는 부분적으로 해결을 하고 있으며, 두번째 문제는 코드를 event-driven 방식으로 scratch부터 작성하는 방법에 비해 성능이 떨어지긴 하지만, 쓰레드 갯수가 많아져서 발생하는 여러 가지 오버헤드와 성능 저하를 간단하게 회피할 수 있는 아주 가벼운 쓰레드인 actor를 지원하며, 또 코드의 복잡성도 상대적으로 줄이는 데까지는 성공하고 있다.
Scala 언어에서 제공하는 actor framework은 어느 정도 완결성을 가지고 있으며 functional language의 장점을 살리고 있으나, 자바 Kilim 라이브러리는 자바 언어의 한계 때문일지 너무 어려운 접근법을 쓰고 있다.

continuation  문제를 Scala가 가장 깔끔하게 풀고 있는 것 같기는 하나, actor framework이 모든 concurrency 문제를 모두 해결해주는 게 아니라 일부는 OS 커널에서 제공하는 쓰레드와 lock을 다시 직접 사용할 필요가 생기게 되니, thread와 lock을 대체하는 concurrent programming model이라고 부를 수는 없을 것 같다. stateless 기반의 구조를 강제하는 Web Oriented Architecture (Web 2.0의 서버 모델) 에서는 상대적으로 여러 세션에 걸쳐 공유하게 되는 데이터의 필요성이 많이 줄게 되므로 Scala의 actor framework 만으로도 구현이 가능하지 않을까 하는 기대는 해볼 수 있겠다.