일요일, 9월 11, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.8.1~2011.9.11)

안철수 교수님의 서울시장 출마 염두 발언에, 지경부 국산 웹 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)

오픈소스와 소프트웨어 계층에 대한 혼돈이 어이없는 주장을 만들고 있다. 상위 애플리케이션이나 서비스만 보면서 하위 계층은 오픈소스로 적당히 하자는 주장이 마치 소프트웨어를 아는듯한 주장으로 회자된다. (2011/9/11)

'안드로이드 믿자'에서 'OS가 아니라 소셜플랫폼이다'까지. 눈에 보이는 것만 믿고 싶은 건 알겠지만 SW를 무슨 유행 타는 미신 같은 걸로 생각하기 때문에 이 지경에 왔다는 것도 알았으면 함. (2011/9/10)

스티브잡스와 애플 Inc.-마이클 모리츠 http://t.co/Uf5VXLq 이 책은 애플 초기를 생생하게 다룬다. 맨손 창업을 꿈꾸는 IT인들의 가슴을 뛰게 할듯. (2011/9/7)

안철수 교수의 조건없는 양보나 곽노현 교육감의 선의. 사람을 모르면 영원히 이해할 수 없겠지. 이건 논리 이전에 사람을 느껴야 그 행위를 이해할 수 있다는 것. 사람의 아름다움을 느낄 수 있기를. (2011/9/7)

박경철 원장의 눈물. 가슴이 짠하네요. 안 교수님의 결단에는 곧은 의지와 사회의 미래에 대한 깊은 염려가 느껴집니다. (2011/9/6)

개인적으로 서울시장 안철수님을 꼭 보고 싶지만 대통령 후보 안철수는 아직 보고 싶지 않다. 국가는 이데올로기를 갖고 싸울수밖에 없기 때문이다. 박원순 변호사께 시장 후보 양보한 것 깊은 생각에서 나온 결단으로 믿고 지지한다. (2011/9/6)

안철수, 박원순, 노무현 이들의 공통점은 진정성이 삶의 궤적에서 확인되는 분들이라는 점이다. 가치관의 출발점이 따뜻한 인간애라는 점도 같다. (2011/9/6)

안철수 교수가 기존 정당 정치를 해야 하는 건 결코 아니다. 매너리즘에 빠진 정당 속으로 그냥 들어가란 얘기는 아무것도 하지 말란 얘기이다. 민주당, 참여당, 민노당이 정신차리고 변화의 방향을 이끌지 못하면 같이갈 이유가 없다. (2011/9/5)

사회 관계 그래프의 에지는 양쪽에 화살촉을 가진 선분이 아니라 두 개의 서로 다른 굵기를 가진, 화살 방향이 반대인 선분 쌍이다. 그런 측면에서 구플이 가깝다고 볼수 있지만 두 선분의 보이지 않지만 강한 연관성을 보여주진 못한다. (2011/9/5)

아무리 올바르다고 해도 다 똑같으면 재미가 없겠지 (2011/9/5)

느낌은 부정확하지만 큰 이해를 준다. 먼저 느끼고 그 다음 분석한다. 그런데 분석을 통해 느끼려는 사람들이 있다. 느끼지 못하는 사람들이다. (2011/9/5)

안철수 교수를 지지하는 건 이런 유형의 분들 성취욕, 추진력 강하고 시간 관리에 철저한 분들이 역사에 큰 역할을 했었다는 걸 알기 때문이다. 심성과 도덕성, 기업관 등 가치관의 방향 또한 인간에 바탕을 두고 있어 신뢰가 크다. (2011/9/5)

존재하지도 않는 서울 시장 단일 야권/진보 후보 때문에 안교수를 비난하는 "왜 하필 지금" 주장은 짜증난다. 안교수의 출마로 선거 이슈 자체가 달라지는데 대충 시장만 바꾸자는 건가? 단순 바람잡이 수준으로 안교수를 보는 것. (2011/9/4)

정치를 하더라도 소신이 바뀌지 않을 우직한 추진력과 도덕성. 한나라, 민주, 민노 기존 정치 세력의 당락과 상관없이 안철수 교수를 지지합니다. 떨어지더라도 변화를 보여줄 수 있을 것입니다. (그런데 서울시민이 아니라 ㅠㅠ) (2011/9/4)

삼성, 정부에 ‘일침’ 최지성 부회장 “모바일OS 계획 비현실적” "삼성전자 SW 인력만도 2만5천여명" http://t.co/6RWlgzG SW를 얘기하면서 숫자를 얘기하는 사람은 진짜 SW를 모르는 사람. (2011/9/4)

아래아 한글 문서 만들기 넘 힘들다. 단축키로 빠른 문서 작성이 가능했던 게 DOS 시절 장점이었다면 지금은 뭘까? 생각을 풀어갈 수 있게 도와줘야 하는데... 문서를 키보드로 작성하는 사람용이지 머리로 작성하는 사람용이 아니다. (2011/9/3)

무엇을 말하는지 모르지만 느낄 수 있다. 느끼는 것과 언어를 통한 단어의 이해. 서로 다른 소통인데 느낌만큼 부정확하지만 큰 이해를 주는 방법이 없다. (2011/8/31)

웹OS는 오히려 기회일 수 있다. 웹 표준에 기반한 환경이므로 표준화 수준이 높으면 독자 플랫폼으로 성공할 수 있다. 하지만 단기적인 성과를 목표로 하는 정부 과제 방식보다는 투자를 통한 고도의 OS 전문 기업 양성의 방식이어야 한다. (2011/8/30)

플랫폼과 운영체제 기술 없인 안되는 건 분명하다. 리눅스든 웹OS든 자체 OS든 진짜 상업적 OS 팀이 필요하다. 짧은 유행만 보면 무너진다. 국가가 그래서 필요한 것 아닌가? 지금 국가가 하려는 근시안적 WBS 웹OS에 찬성하진 않지만. (2011/8/30)

정부의 웹OS 개발 지원에 반대하며 안드로이드 믿자는 황당한 주장까지 보인다. 국내 SW 기술 수준은 어떤 형태로든 제대로 된 OS 개발진을 필요로 한다. 기반이 되는 기술을 상업적 수준으로 갖추지 않으면 항상 겉만 맴돌게 된다. (2011/8/30)

전문가가 되기 위해선 한 분야에 5천 시간 투입해야. 일주일에 스무 시간씩 5년 후에 도달 가능 - 도널드 A. 노먼 (2011/8/30)

흠... 페이스북 딜스는 왜 실패했을까요?” 매출보다 수익성에서 문제가 많은 그루폰 모델은 페북과 맞지 않아. (2011/8/29)

안철수 교수에 대한 비판 중 기업가로서는 벤처 성공 신화라 할만큼 크게 성장시키지 못했다는 비판에 대해. 그 사실이 틀린 건 아니다. 다만 기업의 목적을 이윤 추구로만 보지 않는 안교수의 글을 진정으로 이해하고 동감하느냐의 차이이다. (2011/8/25)

스티브 잡스 애플 CEO 공식 사임. 잡스의 추천으로 팀 쿡이 CEO. http://t.co/rqSBARf 잡스, 당신은 너무 멋진 일을 이뤘어요. 멋진 인생이었어요. (2011/8/25)

페이스북에 체크인 기능이 추가되었네. 그냥 포스퀘어 킬러. 플레이시즈 없애고 심플하게. 페북은 항상 단순의 미학을 사용자 동선에 적용하기 위해 고심 또 고심. (2011/8/24)

명텐도 뜨니 닌텐도가 엄청 고전. 이제 명도우 뜨면 MS윈도우도 고전할듯 (2011/8/23)

webOS에 대한 개발자들 반응은 전반적으로 좋던데… 정작 hp는 포기하니… 그런데 LG와 삼성이 모바일 OS를 만들겠다니 진심일까? (2011/8/22)

안철수 교수가 대기업으로 키우지 못했음을 힐난하는 분위기를 타서 국내 재벌 기업 창업자들과 비교하여 까는 신문 기사는 어이가 없다. 재벌의 초기 자본 축적과정. 성취욕과 추진력 외에 도덕성이란 잣대가 세상에 무의미해진다면 모를까 (2011/8/20)

확실히 박카스만한 친구가 없다… 힘들때 버틸 힘을 주는 친구.. ㅠ_ㅠ; (2011/8/19)

HP는 B2C에서 손떼고 B2B에 포커싱하겠다는 전략 같다. SW든 HW든 구분하지 않고… HP가 B2B에서 그동안 접어버렸던 SW를 인수합병을 통해서 포트폴리오를 갖출 수 있을까? 힘들것 같다. (2011/8/19)

수직 구조에서는 모든 직장인이 무능력해지는 지위까지 진급한다. 곧 모든 직책을 감당할 능력없는 무능력자들이 차지하게 되고 일은 아직 그곳까지 진급하지 못한 이들이 수행한다. - 피터 원칙 (2011/8/19)

HP가 엔터프라이즈 시장에 포커싱하고 B2C에서 완전히 철수할 것 같다. 그런데 B2B에서도 뭘 할 수 있나? HP/UX는 중단하고 하드웨어와 SI만 하는데.. 자산은 다 접거나 매각하고 미래 투자는 포기하고. 놀라운 전문경영. (2011/8/19)

SW 국가 과제 제안 부분은 좀더 구체화해서 블로깅해보겠습니다. 정권이 여러번 바뀌어도 SW 정책은 별 차이가 없습니다. 구체적인 정책 수준의 국가 SW 계획이 없기 때문이라고 생각됩니다. SNS가 이런 정책을 생산할 수 있다고 봅니다. (2011/8/19)

국가 SW투자는 핵심 기간 SW의 진정한 경쟁력 확보 그리고 창의적인 SW 도전을 가능케 하는 SW 생태계 보장 및 글로벌 도전 지원 등에 집중되었으면 한다. 초기 투자 후 자본회수 기간이 상대적으로 긴 SW 특성을 고려한 VC 연결 활성화도. (2011/8/19)

이를 외면하고 계속 OS를 포함한 모든 SW 과제에 ETRI가 계속 발을 뻗는 건 참 이해하기 어렵다. 누구도 책임을 지지 않고 원인 분석이 공론화되지 못하는 우리나라 SW 정책의 발전없는 쳇바퀴질을 보는 것같다. (2011/8/19)

OS 주전산기, RDBMS 바다에서 크게 실패하면서 나쁜 의미로 검증되었던 ETRI가 오라클은 고사하고 티베로나 알티베이스 수준의 RDBMS나 상용 수준 SW를 왜 못 만드는 이유는 국가연구소의 태생적, 구조적 한계 때문이다. (2011/8/19)

지금 SW 국가과제는 기간 SW 경쟁력을 확보하는 것보다는 국회 감사 때 덜 문제되고 돈쓸 수 있는 곳을 찾는 것 같다. 알려진 기술 따라 구현해보는 수준의 ETRI가 무한경쟁력이 필요한 솔루션 과제까지 가로채는 건 특히 문제이다. (2011/8/19)

끊임없이 문제를 심화하고 창의적인 대안을 만드는, 잘 훈련된 괴짜Geek들의 대오가 필요하다. (2011/8/19)

소프트웨어를 정태적인 사업관리 개념으로 다루는 접근법으로는 경쟁력있는 솔루션이나 서비스를 만들 수 없다. 80% 외형은 카피 전략으로 빠르게 쫓아갈 수 있어 마치 비슷해보이지만 경쟁력을 좌우하는 20%에서는 영원히 캐치업할수 없다. (2011/8/19)

SI에서는 보통 이런 형태의 문제를 다루지 않기 때문에 인력 수 위주의 프로세스를 가져간다. SI는 SW 솔루션이나 서비스와는 다루게 되는 문제의 성격이나 해결 방식이 전혀 다르다. SI와 SW를 함께 얘기하는 것 자체가 오류이다. (2011/8/19)

SW에서 wicked problem을 해결해가는 형식을 XP나 스크럼 같은 애자일 방법론에서 찾을 수 있으나 중요한 것은 끊임없는 요구사항과 해결의 심화와 진화를 가능케 하는 조직 문화이다. (2011/8/19)

솔루션 구현을 통해 요구사항이 명확히 정의되는 문제 영역에서 SW공학의 역할은 미미하다. 관리 편의 위한 SW공학 적용 금지, 국가연구기관 SW 솔루션 과제 금지, 국가SW과제를 정량적 검증에서 질적 성취로 목표 전환 필요. (2011/8/19)

소프트웨어가 wicked problem 즉 문제를 해결해나가는 과정 속에서만 문제를 제대로 인지할 수 있는 문제가 핵심 영역이라면 요구사항 던져주고 닥치고 만드는 게 SW에서는 반드시 실패하는 길임을 쉽게 알수 있다. (2011/8/19)

"아빠 곁에 서면 생각이 크고
엄마 곁에 누우면 사랑이 크지요" (2011/8/18)

의식적인 멀티태스킹은 뇌 구조상 불가능하죠. 다중 업무를 해야 할 때는 시분할 간격을 늘여서 문맥 전환 오버헤드를 줄이도록 노력하고 비동기적 업무는 순차 업무로 전환. (2011/8/18)

보름 넘게 소프트웨어 교육 준비했더니 개발하던 부분이 또 낯설다. 추상 수준이 높은 통찰의 영역과 세세한 코딩의 영역을 오가는 건 아직도 힘겹다. (2011/8/18)

큰 판단 오류를 범한 대기업들이 외부 컨설팅 결과에 근거해 의사결정. 비전을 컨설팅하는 조직, 다시 말해 스스로 판단하고 추진못해 외부 권위에 책임을 넘기는 조직. 이런 공무원 같은 조직의 기업이 IT를 담당하는 나라. (2011/8/18)

구글플러스. 인간 관계망 측면에서는 매우 소그룹만 유대감이 느껴질듯. 트윗처럼 자발적인 채널선택도 쉽지 않고. 사용자가 아무리 늘어나도 IT인들에게만 특별히 유용한 사회관계망으로 남을것 같다. 아쉽다. (2011/8/5)

고객의 입에서 고객이 원하는 것을 들으려 한다면 고객 스스로도 진정 원하는 게 뭔지 모르는 것을 듣는 것. 고객의 행동 패턴을 분석하는 것과는 정반대의 행동이다. 고객이 원하는 게 이미 존재했다면 고객은 그것을 선택할 것이다. (2011/8/5)

MacOS X Lion에서 애플리케이션 실행 시 예전 상태로 자동 복구되는 기능… 적응하기 쉽지 않네요. ㅋ Natural Scroll은 아이패드 덕분에 적응이 쉬웠는데. (2011/8/5)

Finder에서 파일명과 디렉토리 위치 변경했는데 Keynote 최근 문서 목록에 반영되어 나타나네. 와우. 맥 대단하다. Lion만 이런 건가? (2011/8/5)

sell sugar water for the rest of your life or come with me and change the world? 잡스가 스컬리를 설득할때 나이가 스물여덟. 세상을 거칠게 산 친구들이 일찍 세상을 배운다. (2011/8/5)

안철수 교수는 주변 사람들을 통해 물어봐도 그 도덕성에 결함이 없다.. 대단하다... (2011/8/5)

성취 동기가 크고 도전 정신이 강한 사람들은 어느 나라에서나 큰 성과를 낸다. 잡스든 빌게이츠든 안철수 교수든 정주영이든. 다만 도덕적 잣대로 본 길 선택 여부에 따라 크게 결과가 달라지는 환경을 무시할 수는 없다. 한국이 그렇다. (2011/8/5)

끊임없는 도전이란 측면에서 위대한 기업가는 한국에도 많다. 하지만 그 중 도덕과 공생의 철학에 기반한 삶을 사는 사람은 안철수 교수 뿐이다. 큰 수익을 낸 사람을 존경하고픈가 아니면 투쟁하는 운동가가 기업 운영하길 바라는가? (2011/8/5)

몇 건의 안철수 교수 비판글이 트윗되고 있는데 그 필자들은 하나같이 인간으로서의 안교수도 기업가 정신도 이해 못하고 있다. 한국 사회에서 생활 하나하나 도덕적인 기업가가 망하지 않았다는 것만으로도 크게 존경받아야 한다. (2011/8/5)

micro-management가 나쁘고 무조건 위임을 해야 한다는 전적으로 잘못된 주장이다. 소통이 일상화되어야 하고 코칭을 통한 위임이 되어야 한다. 사람 관리의 레이어는 얇아지고 관리 문화와 전통은 철학에 기반해 심화되어야 한다. (2011/8/3)

Facebook Buys iPad Book Creator Push Pop Press http://t.co/t9k1QnS 새로운 iPad 전자책 UX를 선보였던 화제의 푸쉬팝프레스가 페이스북에 인수되었네요. 놀랐습니다. (2011/8/3)

인재 1명이 10만명을 먹여살린다는 이건희 회장의 주장에 대해 시대가 바뀌었다는 반론이 있지만 뒷받침할 근거가 안보인다. 실증할 수 없는 주장이 아닌데 호불호의 선택 문제로 접근하는 건 오류다. 왜 검증가능한 논리를 만들지 않는가. (2011/8/1)

어중간하게 절충한 해결보다는 밑바닥에서부터 뒤집은 해결이 창의적 혁신. 인지된 문제의 해결 방식을 몇번이고 다시 뒤집어 생각해보자. (2011/8/1)

금요일, 8월 19, 2011

소프트웨어 국가 정책을 악제(惡題, wicked problem)적 특성에 맞게

lateral thinking을 번역할 때처럼 wicked problem도 우리말로 옮기기가 쉽지 않다.
창의적 사고의 한 방법으로 제안되었던 lateral thinking은 한 우물을 깊게 파는 수직적 사고 대신에 여러 우물을 주변에 파보는 사고를 제안하는 것인데 이를 "수평적 사고"라고 번역한 탓에 창의는 수직적 위계질서나 권위에 반하는 사고에 기반한다는 단순 논리들을 일으키기도 했다. 어색하지만 "곁을 따라 생각하기" 정도가 맞지 않을까 싶다.
wicked problem은 "까탈스런 문제" 정도의 어감으로 들으면 좋겠다. wicked problem의 대응되는 개념으로는 tame problem "순한 문제"가 있다. 여기에서는 wicked problem을 악제(惡題), tame problem을 순제(淳題)라는 용어를 만들어 써본다. 
악제(惡題, wicked problem)와 순제(淳題, tame problem)
악제(惡題)는 솔루션을 만드는 매 시도가 문제에 대한 이해를 변화시키는 문제이다. 이런 문제들은 문제의 정의가 새로운 가능한 솔루션들이 고안되고 구현될 때마다 문제의 정의가 진화하기 때문에 전통적인 선형적 방법으로 풀 수가 없다. (Rittel & Webber, 1973)
"Wicked" problems are ones for which each attempt to create a solution changes the understanding of the problem. They cannot be solved in a traditional linear Fashion, because the problem definition evolves as new possible solutions are considered and/or implemented.

Jeff Conklin은 다음 여섯 가지 특성을 악제(惡題)에 고유한 특성으로 보았다.
  1. 해법을 개발하고서야 문제를 이해하기 시작한다.
  2. '완료 규칙'이 없다. 충분히 좋은(good enough) 해법이 나오면 중단한다.
  3. 해법이 옳거나 그른 게 없다. 더 낫거나 더 나쁘거나 혹은 충분히 좋거나 불충분하거나 할 뿐이다.
  4. 모든 악제(惡題)는 독특하며 기발하다. 모든 악제(惡題)는 서로 다르며, 해법들은 매번 커스텀하게 고안된다.
  5. 모든 해법은 효력을 가진다. 모든 고안된 해법들은 결과를 가져오며, 또 새로운 악제(惡題)들을 유발한다.
  6. 대체 해법(대안)이 주어지지 않는다. 해법이 없을 수도 있고, 수많은 잠재 해법들이 존재할 수도 있고, 또 수많은 해법들은 생각도 못해봤을 수 있다. 하지만, 해법을 고안하는 것은 창의성의 문제이며, 또 어떤 게 유효하고 어떤 방법을 추구해야 하는지는 선택의 문제일뿐이다.


이에 대응하는 순제(淳題)의 특성은 다음과 같다.

  1. 문제가 잘 정의되어 있으며 안정적이다.
  2. 해법에 도달하는 분명한 종료점이 정의된다.
  3. 객관적으로 옳고 그름을 판단할 수 있는 해법이 존재한다.
  4. 유사한 방법으로 해결될 수 있는 유사한 문제들 클래스에 속한다.
  5. 쉽게 시도해보고 버릴 수 있는 해법들이 존재한다.
  6. 대체 해법들을 가지고 있다.

소프트웨어 개발은 악제(惡題)인 가?

요구사항 이해는 악제(惡題)?
소프트웨어의 모든 측면이 악제(惡題)의 성격을 가지는 것은 아니다. 하지만 특정 영역에서 이러한 성격이 두드러지는데 대부분의 SW 솔루션들이나 B2C 서비스들은 심각한 경쟁적 측면을 가지며 이들 경쟁적 우위에 해당하는 문제들이 대부분 악제(惡題)의 특성을 지닌다.
악제(惡題)는 계획이 정확하기 어려우며 반복적인 feedback을 통해 더 나은 해법을 찾아가야 하는 특성을 가진다. 따라서 이런 성격의 문제들은 미리 요구사항을 확정하고 이에 따라 구현만을 하는 이분법적인 프로세스로는 해결할 수 없다.

미션 크리티컬한 부분의 알고리즘 개선이나, 소비자들이 일상적으로 사용하는 B2C 소프트웨어의 만족도 개선의 문제, 소비자들의 정말 만족할 수 있는 사용자 경험 등은 good enough 외에는 판단할 수 없으며 끊임없는 iteration을 거쳐야 하는 전형적인 악제(惡題)라고 볼 수 있다.
시스템 소프트웨어나 엔드 유저를 대상으로 하는 소프트웨어나 서비스를 개발해본 사람들은 소프트웨어의 악제(惡題)적 특성에 대해 매우 공감할 것이다.

wicked, complex 기준으로 분류해본 Software
위 그림은 절대적인 분류가 아니지만 wicked 정도와 복잡도를 기준으로 대충 그려보았다. 같은 스마트폰용 앱이라도 복잡도가 매우 높은 것이 있을 것이며, 또 악제(惡題)가 강할 수도 있지만, 국내 현실을 기준으로 대충 위치시켜 보았다.

악제(惡題)와 순제(淳題)의 구분은 매우 중요하다고 생각하는데, 악제를 순제처럼 접근하여 문제 해법을 만들면 다음과 같은 현상이 벌어진다.

이미 알려진 해법들 중심으로 빠르게 약 80%의 외형은 쫓아갈 수 있다. 하지만, 나머지 경쟁력을 좌우하는 20%는 절대 해법을 찾을 수 없으며, 문제 발생 시 문제 해결 능력이 없다.

이것은 악제를 해결하는 사람, 조직과 순제를 해결하는 사람, 조직이 매우 다르기 때문이다. 악제의 해결은 개인과 조직의 창의적인 문제 인지와 해결 과정을 거친다.

버전 3와 악제(惡題)로서 소프트웨어
잠깐 국내 현실을 살펴보자. 예를 들어 엄청난 세금을 쏟아붓는 국가 과제를 통해 소프트웨어의 진정한 경쟁력을 확보할 수 있는가 생각해보자. 지금까지 소프트웨어에 투자된 세금이 적어서 소프트웨어가 사멸하고 있는 것은 결코 아니다.

1990년대 중반에 국산 기간 소프트웨어 기술을 확보하겠다고 주전산기 프로젝트와 바다 RDBMS 프로젝트가 있었다. 주관한 기관은 국가 산하 연구기관인 ETRI였다.

매우 복잡도도 높지만, 엄밀성을 요구하는 운영 체제와 관계형 데이터베이스를 만드는 프로젝트를 통해 ETRI는 무언가 결과물을 만들었다. 그리고 이 결과물들을 삼성, 현대, LG, 대우 등 당시 재벌그룹들의 소프트웨어 담당 기업에 이전하였다. 결과는 어떠하였는가?
ETRI의 결과물은 상용 소프트웨어(commericial software) 수준에 턱없이 미달하는 것이었으며, 각 기업들도 여기에 사활을 걸고 기술 개발을 하려는 기업들이 아니었다. 그저 새로운 과제를 통해 세금을 흡수할 목적만 가지고 있었다.

그런데 15년 가까이 지난 지금 무엇이 바뀌었을까? 지금도 국가 과제 중 소프트웨어 솔루션 부분에 ETRI가 상당히 넓게 참여하고 있다. ETRI의 결과물이 상용 수준으로 좋아졌는가? 여전히 마찬가지이다.
잘 알려진 기술들을 쫓아 구현해보는 수준이지, 새로운 기술을 만들어내지 못한다. 왜 그럴까?

소프트웨어 솔루션 업계에서는 버전 3라는 말이 있다. 마이크로소프트가 MS Windows를 개발할 때 3.x에 이르러서야 고객이 사용해볼 수준이 되었다. 또, 인터넷 익스플로러도 버전 3에 이르러서야 고객이 관심을 기울이기 시작했다.
지금 국내 RDBMS 업체인 알티베이스나 티베로 같은 업체들이 실제로 고객들에게 팔고 시장에서 부딪히면서 완전히 새로운 아키텍처 설계와 알고리즘으로 갈아엎는 데 걸리는 시간들이 바로 마법과도 같은 버전 3이다.

ETRI 같은 연구 기관은 프로토타입 수준의 버전 1을 만들고 과제를 완료한다. 그리고 시장에 책임이 없기 때문에 실제 문제(real problem)에 대해서는 관심이 없다. 그후 또 상용화 과제라는 걸 만들어서 국내 중소기업에 기술 이전을 한다. 하지만, 마찬가지로 그 상용화를 통해서도 절대 경쟁력을 갖추지 못한다. 덜 만들어진 버전 1을 계속할 뿐이다.
미리 완벽한 요구사항에 의해 단순 구현만 하는 순제(淳題)가 아니라 구현을 해보면서 비로소 문제를 재인식할 수 있는 악 제(惡題)를 다루는 것이 솔루션 SW의 핵심이기 때문이다.

지금과 같은 형태의 국가 과제 형태로는 미션 크리티컬한 기반 SW나 경쟁이 치열한 소비자 대상 SW 모두 경쟁력을 잃을 수밖에 없다. (조금 과격한 주장으로 들릴지 모르겠지만 현실이 그렇다. 20년 넘게 퍼부은 정부 SW 과제, 그 결과가 무엇인지 생각해보자.)

소프트웨어를 위해 소프트웨어 공학을 활용해야

우리 나라는 소프트웨어는 거의 질식사하고 있는데 소프트웨어 공학은 관리 편의에 치우쳐서 너무 남용되고 있다. 모든 과정들에 evidence를 요구하지만, 질적인 문제에 대해서는 누구도 책임을 지려고 하지 않는다. 수치적으로 나타나는 결과들을 중심으로 과제를 만들기 때문에 장기적인 투자나 또 정성적인 효과에 대해서는 아무리 중요한 부분일지라도 관심을 두지 못하는 구조이다.
이렇게 되면 실제 악제를 해결하여 경쟁력을 갖추는 과정에 대해 비중을 높일수가 없다. 또, 소프트웨어 경쟁력과 무관한 SI성 프로젝트에 많은 과제를 배당하는 것도 결과적으로 국가 소프트웨어 경쟁력을 약화시키게 된다.

소프트웨어는 악제를 다루기 때문에 사람들간의 내용적인 협업과 소통이 중요한데, 절차 중심인 소프트웨어 공학은 품질의 우수성을 보장해주지 못한다. 한마디로 국내의 소프트웨어 공학 수준은 "품질의 기준 하한선을 보장해주는 불필요하게 과도한 프로세스"에 머무르고 있다.

정량적인 관리와 관리 위주의 소프트웨어 공학을 사용해서는 악제를 다룰 수 없다. 프로세스는 어느 하한 이상은 보장하지만 그 이상은 문화로 정착된 팀웍 속에서 개인과 조직의 문제해결 능력(창의적 해결 능력과 복잡한 문제 해결 능력)에 의해 결정된다.

어떻게 보면 국가 SW 정책을 입안할 때 외형적 수치를 강조하는 SW 공학 전공자의 목소리를 줄일 필요가 있다고도 보인다.

선형 개발 모델(waterfall)은 악제(惡題) 해결에 도움이 되지 않는다

정책 제안

모토롤라 모빌리티를 구글이 인수하고 나자 아이폰 쇼크만큼이나 국내 IT 산업은 위기감에 빠지는 것 같다.
격려하고 믿자는 종교적 얘기들은 잠시 마음의 위안을 얻을 수는 있겠지만 행동의 방향을 잡지 못하는 현실을 도피할 수는 없을 것이다.

예를 들어 삼성전자는 왜 소프트웨어를 못하는가? 긴급하게 S급 인재를 스카웃하고 전열을 재정비하면 가능할까?
왠지 여전히 80:20 룰에 갇힌 것 같다. 80을 엄청난 속도로 빠르게 구현하여 외형적으로는 비슷해보일 수 있지만 진정한 경쟁력을 좌우하는 20에서는 한 발자국 내딛기가 힘든 조직은 아닌지? 지금의 사업 관리 형태로 소프트웨어를 할 수 있는 문화를 갖춘 조직이 만들어질 것인지?

국가 정책 방향으로는 두 가지 정도가 떠오른다.

하나는 기간 소프트웨어를 제대로 할 수 있는 고도화된 전문 기업을 지원 혹은 양성하고 국가가 이에 대한 일정한 지분을 가져가는 것. 범용 OS, RDBMS, 스마트 플랫폼 등 모든 기간 소프트웨어에 대한 국가 지원의 범위와 국가적 전략 지도를 작성하는 것이 하나의 방향일 것 같다.

하나는 창의적인 아이디어로 시장에서 성공할 수 있도록 투명한 체계를 갖추고 초기 창업 비용과 우수 창업자를 위한 생태계를 구축해주는 것. 또 국내 앱 생태계만으로는 장기 생존이 힘들므로 전략적인 글로벌화 지원도 중요한 사업일 것 같다.

아이디어만 있으면 3,4명으로도 창업할 수 있는 환경이 무르익었지만 국내 지원 체계는 너무 미약하다. 여전히 제조사, 통신사 대기업의 진실성도 느껴지지 않는다.

구체적인 정책도 중요하지만 정책의 성과를 장기적인 안목에서 제대로 파악할 수 있는 노력이 필요하다. 정책 판단 기준을 정성적이고 글로벌한 관점에서 바라볼 수 있어야 하는데 지금의 기획 방식과 체계로는 불가능한 것 아닌가?

풍전등화 위기의 IT 산업인데 앞으로 10 년을 더 무사안일하게 보내야 할 것인가?

참고
1. Wicked Problems & Social Complexity (by Jeff Conklin) http://www.cognexus.org/wpf/wickedproblems.pdf
2. Coding Horror: On Software "Engineering"
http://www.codinghorror.com/blog/2005/03/on-software-engineering.html
3. Coding Horror: Development is Inherently Wicked
http://www.codinghorror.com/blog/2004/09/development-is-inherently-wicked.html
4. Wikipedia: Wicked problem
http://en.wikipedia.org/wiki/Wicked_problem

월요일, 8월 01, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.7.9~2011.7.31)

7월이 가고 8월. 안철수 교수님의 시간은 필요에 의해 만들어지는 것이라는 말이 마음 속을 울립니다.

<아웃라이어>를 보면 어떤 분야든 1만 시간을 투입해야 전문성이 쌓이고 성공할 수 있는 기본 자격 요건을 가진다는 법칙이에요. 매일 3시간씩 365일 10년 동안 해야 1만 시간이 되는데요. 집중해서 보내는 3시간이거든요 - 안철수 (2011/7/31)

우선 자신의 분야에 1만 시간 정도를 투입해 전문성을 가지고 있어야 하고, 이와 함께 전혀 다른 분야 혹은 더 깊은 분야에 대한 관심과 공부가 결합됐을 때 창조의 힘이 생긴다 - 안철수 (2011/7/31)

'균형 감각'이란 중간 지점에 서 있는 것이 아니라 양극단을 오가면서 최적점을 찾으려고 노력하는 끊임없는 과정이라고. 세상을 사는 데 균형 감각이 매우 중요한데 그것을 얻게 해주는 건 책밖에 없는 것 같아요-안철수(시오노 나나미 인용) (2011/7/31)

안철수 교수의 삶이 얼마나 사람에 대한 자신의 책임의식과 도전으로 이루어져있는지 그분의 말씀에서 짙게 묻어난다. 사람을 생각하고 사람과 세상의 공영을 생각하며 도전하는 삶이 이 얼마나 아름답고 고귀한 것인지. (2011/7/30)

안철수와 박경철, 독단과 탐욕이 지배하는 우리시대를 이야기하다 http://t.co/KxR3bfv 기업의 목적은 수익창출이라는 말은 정답이 아니다. 수익이 목표가 아니라 어떻게가 중요하다. 혼자만 잘 먹고 잘 사는 것은 범죄와 다름없다. (2011/7/30)

'안철수와 박경철2', 서바이벌·오디션 누르고 시청률 1위 http://t.co/YCFNyFb 잠깐 봤었는데 세상을 바라보는 눈이 저와 다르지 않음이 감동적이었습니다. 사람을 생각한다면 결론이 크게 어긋나지 않겠지요. (2011/7/30)

이건희 회장 “소프트 기술 악착같이 배워라” http://t.co/PIEaMGC 소프트웨어 기술의 핵심은 생각하는 방법과 생각을 모으는 방법, 생각을 행동하는 방법. 악착같이 따라하려면 생각을 가두는 닫힌 문화를 전복해야 한다. (2011/7/30)

역시 지식 생산자는 온오프 사회관계에서 분리되는 안식년이 필요.. (2011/7/29)

MacOS X Lion 써보니 핵심인 미션 컨트롤은 정말 마음에 쏙 드는 기능. 런치패드는 쓸일 없는 기능. 전반적으로 편안하지만 사파리 5.1의 몇가지 버그들이 신경쓰이네요. (2011/7/28)

구글플러스는 페북이나 트위터보다 훨씬 더 전염성이 강한 듯. 서클 전체 숫자를 높이는 건 훨씬(수십배?) 빠를 듯. 그런데 이중 유대감 높은 서클은 한두개이고 나머진 가비지 서클이 될듯. (2011/7/25)

맥OS X Lion에서 멀티터치 스크롤에서 방향이 스노레퍼드와 반대가 된 것은 기존 윈도우 시스템의 스크롤은 스크롤 바의 손잡이를 잡고 끄는 메타포였다면 지금의 스크롤은 아이폰처럼 화면 위치를 잡아서 끄는 메타포이기 때문. (2011/7/23)

아이패드에서 네손가락 멀티터치로 앱전환할 때의 유쾌감이 세손가락 멀티터치로 라이언에서 구현된 느낌. 별것 아닌 것 같은데도 사용성을 크게 키워줌. 복잡하게 화면에 여러 프로그램 겹쳐쓰는 기억에서 해방된 느낌. (2011/7/22)

Lion은 기본적으로 앱은 풀스크린 모드로 동작하는 걸 권장하는 메타포. 기존 앱들은 여러개의 가상 데스크탑 중 하나에 소속시키고 라이언용 풀스크린 앱들(사파리, iCal 등)은 데스크탑과 별도로 실행. (2011/7/22)

OS X Lion 좀 써보니 멀티터치 방식으로 화면 전환, 스크롤, 풀스크린 같은 기능들에서 신선하고 편하다. 복잡한 아이패드 같다. 데스크탑 어플과 태블릿 앱의 공존 같은 느낌이랄까. 다만 몇몇 버그들이 눈에 거슬린다. (2011/7/21)

구글이 역량을 집중해서 성공한 첫 사례는 안드로이드일듯. 플러스가 역량을 집중한 두번째 사례일듯. (2011/7/21)

버즈와 웨이브의 실패, 플러스의 성공이 그런 결론으로 이끌었을듯. 페이지가 굳이 틀렸다고 생각하진 않지만.. (2011/7/21)

래리 페이지가 구글랩스를 닫고 서비스별 랩만 유지한다고. 장난은 그만하고 집중하자는 건데. 장난으로 큰 성공 얻기 정말 어렵다는 교훈과 상향식 의사결정이 하향식에 비해 매우 비효율적이라는 교훈. 이 청산적 교훈이 맞는 결론일까. (2011/7/21)

Lion용 Safari의 forward/backward는 손가락 두개로 수평방향 스크롤로 멀티터치 방식이 바뀌었는데 애니메이션이 훨씬 멋있어졌네요. (2011/7/21)

사고 능력의 훈련은 이래서 고통스러운듯. 도구나 멘탈 이미지의 형상을 활용하는 외화 기법을 사용하면 대단히 효율적인데, 생각 바깥에 내려놓지 않고 머리 속에서 입체적으로 사고하는 훈련은 고통스러운 과정. (2011/7/19)

하지만 이러한 부분 사고의 외화에 익숙해지다보면 통찰을 위해 부분 사고를 매번 외화시켜 내려놓고 봐야하는 습관이 생긴다. 사고의 속도를 떨어뜨리고 통찰의 수준에 한계를 만든다. 머리속에서 외화하고 총화할 수 있는 훈련이 필요하다. (2011/7/19)

생각하는 방법은 많은 훈련이 필요한데 통찰에 필요한 형상화 과정에서는 직접 도표, 그림 등을 그려보면 많은 도움이 된다. 복답한 계산에서도 암산보다 손으로 써내려가는 것이 도움이 된다. (2011/7/19)

개인적인 판단으로 구글플러스는 확고한 기반을 가지는 SNS로 자리잡을 것이지만 페북, 트윗과는 호불호가 명확한 또다른 SNS가 될듯. 사용자 수로도 페북, 트윗을 쫓겠지만 능가하긴 어려울 것. (2011/7/18)

구글 플러스 써클이 네트웍 측면에서는 페북보다 훨씬 충실도가 높을 수밖에 없을 듯. 친구를 우연하게 만나는 조우 효과는 좀 떨어질 듯. (2011/7/15)

구글 플러스의 써클은 한 개인이 사회 관계를 보는 다중 인격을 표현한 뷰라고 해야 하나. 그래서 소셜네트웍 상의 실제 가상 노드로 존재하는 페북의 그룹과 다름. (2011/7/15)

금요일, 7월 08, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.5.28~2011.7.8)

계획 수립이 어려울 정도로 앱 개발 진행이 더뎌 시간과 환경을 디버깅해보고 있습니다. 좀더 느긋하게 일정을 잡되 중단하진 말아야겠어요. 개발의 연속성에 필요한 시간 간격을 만들 수 있는지, 불규칙한 다른 업무로부터 개발 시간을 확보할 수 있는지, 또 짜투리를 활용하면서도 효율을 높일 수 있는 자신에 맞는 개발 환경은 무엇인지 찾아보고 있습니다. 일주일 중 연속되지 않은 특정 요일 이틀만 개발에 투입하기는 매우 비효율적이군요.

구글플러스가 써클이란 네트웍 특성 자체만으로 페북을 압박할 수 있을지는 솔직히 모르겠다. 하지만 그룹 메시징을 중심에 놓고 보면 얘기가 좀 달라진다. 분명 써클 형태가 유리하다. 물론 페북에도 그룹 기능이 있지만 상대적으로 불편하다. (2011/7/8)

그런데 사람 사는 게 다 비슷비슷하여 다중인격체처럼 완전 분리된 몇 개의 인격체로 사는 듯해도 또 그들 생활 간에 blurring이 발생하게 마련이다. 한 사람의 네트웍이 보편적 친구 개념이냐 써클 개념이냐 단순하지 않다. (2011/7/8)

페북을 첨 사용할 때 느꼈던 단점이 사람이 몇 개의 인생을 산다는 것이었는데 구글의 한 엔지니어가 이 단점을 해결하는 대안으로 써클 개념을 제안했었다. (몇년 전 얘기인듯) (2011/7/8)

소셜 네트웍에서 노드(사람)를 연결하는 에지 역할을 하는 관계가 페북은 친구 하나였다면 구글 써클은 대학 친구, 회사 동료, 가족 친지, 동호회 뭐 이런 식이다. (2011/7/8)

Real-life sharing rethought for the web. 구글이 구글플러스에 대해 바라보는 관점을 한줄로 요약. 삶의 공유가 소셜이고 웹이 구글이라는 메시지로 들린다. "웹을 위하여 삶의 공유를 다시 생각한 것" (2011/7/7)

구글 플러스가 성공할 것이란 느낌을 가진 건 서클이란 소셜네트웍보단 행아웃이란 다자간 비디오채팅 기능 때문. 하지만 아직 네트웍 환경 때문에 특정시간대에 유용할듯. 왠지 메시징을 SNS의 핵심으로 본 카톡의 선견지명이 존경스럽다. (2011/7/6)

사람의 기억과 학습 방식이 컴퓨터 메모리-디스크 메타포와 다른 점은 사람의 기억 용량은 거의 무한대라 컴퓨터처럼 working memory 부족으로 thrashing이 발생할 가능성이 없다는 점. (2011/7/3)

세르게이 브린이 직접 지휘했다는 구글의 소셜 플랫폼 구글 플러스가 페이스북에게 가하는 압박은 세계 최고의 압박 축구를 구사하는 맨유와 첼시의 경기를 보는 듯한 기분. 90분 내내 강펀치를 주고받는 두 팀. 페북의 역습이 기대된다. (2011/7/3)

개발자가 자기 관리와 효율을 위해 개발 단위를 어떤 방식으로 끊어가야 하는지 또 주말이나 휴일을 앞두고 일을 어떻게 정리해둬야 할지에 대해서도 시사하는 바가 있다. 단순 투입 시간은 효율과 거리가 있다. (2011/7/2)

이런 기억과 학습 효과 연구 결과는 SW개발자의 개발 효율성을 위해 머릿속의 문제들과 진행중인 코드가 소멸되어 첨부터 다시 고민하지 않으려면 마무리를 하고 내려놓든지 24시간 이내에 이어가야 함을 시사한다. (2011/7/2)

일시적 생각은 24시간 이내 복습되지 않으면 다시 기억하기 어려움은 여러 연구를 통해 알려져있다. 그중 하나로 베레나 슈타이너의 전략적 공부기술이란 책을 추천한다. (2011/7/2)

요일 단위로 다른 일을 한다는 게 개발에는 적합하지 않은 것 같다. 컨설팅 하는 것이야 큰 문제가 없지만. 하루를 쪼개서 시간 단위로 하는 건 괜찮은데. 영구 기억으로 내려가지 않은 정보들이 하루를 넘어가면 휘발되기 때문인 것 같다. (2011/7/2)

상세 기억, 특히 디테일 지식은 학습하지 않는 순간부터 망각되고 무뎌진다. 학습과 제련을 중단하는 순간부터 지식은 아련한 외형의 기억으로 바뀌어간다. 어줍잖은 지식을 행상하려고 해도 끊임없는 재학습이 필요하다. (2011/7/1)

Google Circles 서비스는 2006년 4월에도 베타 형태로 진행되었던 실험 서비스이군요. Google Circle Beta | tech2all.com http://t.co/dBAIwnv (2011/6/30)

Google Circles 서비스에 대한 지난 3월 13일 기사. False Alarm: Google Circles Not Coming Now, And Probably Not Ever http://t.co/g4vqqNK (2011/6/30)

페이스북에 회사 상관이 부담스럽다면? ''구글의 SNS로 오세요'' http://t.co/wqKmuoj 페북 외에 또하나의 SNS 서비스 가입 형식은 성공하기 어려울듯. 하지만 구글 계정을 잘 활용한다면... (2011/6/30)

SW 공학이 SW의 품질을 보장하는 게 아니라 SW를 만드는 사람들이 SW의 품질 수준의 핵심이라는 기본적인 사실. SW공학은 SW 품질의 하한선을 보장하기 위한 것이지 품질의 경쟁력을 보장할 수는 없다는 것. (2011/6/29)

SW 공학 전공하신 분들과 함께 일해보니 경험과 능력있는 분들일수록 분석설계의 중요성에 주목하고 경험 없는 친구들일수록 관리 편의적인 산출물과 메트릭에 집착. 정성적 요인이 많은 SW는 보기편한 수치로 판단할 부분이 거의 없음. (2011/6/29)

어떻게 이런 역량으로 Quality Software를 만들 수 있겠는가. SW 경쟁력 없는 게 이런 상황을 얘기하는 게 아닌가. 국가의 SW 육성 체계가 완전히 뒤집혀야 한다. 전문 인력들이 진정한 깊이를 가질수 있도록 유인해야 한다. (2011/6/29)

국내 SW 개발 과정을 지켜보고 있으면 많은 전문 솔루션 업체도 타겟 솔루션의 핵심 시스템 아키텍처를 식별해내지 못하는 경우가 많다. 핵심 시스템 아키텍처가 불필요한 단순한 경우도 많지만 그럴 역량이 없는 경우가 더 많다. (2011/6/29)

하면 좋을 것 같은 건 잉여 인력이 메인 역량에 거의 영향 없이 해볼 수 있을 때 그것도 시간과 리소스 목표 한도 내에서만 수행해야 한다. (2011/6/29)

그렇다면 아무것도 안해야 하는가. 물론 그렇지 않다. 하면 좋을 것 같은 게 아니라 하면 좋은 걸 도입해야 한다. 그 판단을 누가 어떻게 하느냐가 중요하다. (2011/6/29)

SW 개발 프로세스에 하면 좋을 것 같은 걸 도입하는 건 그만큼 손실이다. 투입 리소스와 시간을 낭비하고 개발자들 집중을 무너뜨리기 때문이다. 해보면 좋을 것 같은 걸 실제 하면 항상 효율만 저하시킨다. (2011/6/29)

SW는 프로토타입밖에 못하는 ETRI. SW에서 프로토타입은 시작도 아닌데 정부 과제 곳곳에 끼어있다. 뭐하는 기관일까. (2011/6/28)

스마트폰 앱 대박이라더니… 앱 개발자, 설 땅 좁아진다 http://t.co/U5OThXg 옥석이 가려지겠지요. 그리고 국내 시장이 너무 작다는 것, 앱 가치에 대한 비용을 지불해야겠다는 마인드도 부족. (2011/6/27)

구글이 소셜네트웍에서 실패한 이유는 인간의 추천보다 알고리즘을 더 믿었기 때문이라는 지적. 유의미. 아직 사람이 원하는 것(선호)에 대해 사람보다 나은 판단을 하는 알고리즘은 없다. 사실 사람도 원하는 게 뭔지 대부분 모르지만. (2011/6/26)

손회장은 한국 피가 흐르지만 일본인의 정서와 행동에 융합된 일본인. 하지만 그의 정신세계는 국가 경계를 넘어선, 개척자를 자처하는 지구 시민. (2011/6/21)

손정의 회장이 800개 계열사에 소프트뱅크 브랜드를 허용치 않는 이유... (2011/6/21)

우울한 아침이었는데 맥북 리부팅 후 xcode 열다가 빵 터짐. 대단한 맥의 한글 어휘 수준. ㅋㅋ http://t.co/E2HXu19 (2011/6/20)

미국에서 일자리는 스타트업에서 순증가, 기존 기업들은 순감소했다는 카우프만 재단의 연구 결과가 2010년에 있었군요. 조사대상 연도는 1977-2005년. 우리나라 MB 정부의 극단적 재벌친화 정책이 가져온 일자리 증감은 어떨지? (2011/6/18)

I might be right (2011/6/18)

“21세기 2차 IT혁명으로 모든 경계 허문다” http://t.co/TV2mrdw 안철수 교수가 I may be wrong 이 중요하다고 강연 (2011/6/18)

iOS 관련 질문들에 가장 성실한 답변을 찾을 수 있는 곳은 http://t.co/LiBuAIv 인듯. 구글로 검색해도 여기로 가고, 여기서 직접 찾으면 더 쉽게 찾을 수 있기도. (2011/6/17)

좀더 많은 사람들이 좀더 싸게 SW를 이용할 수 있는 개념으로 바뀔 필요가 있다. 서비스 중심의 유료 모델만으로는 SW의 발전을 뒷받침하기 어렵다. (2011/6/17)

광고 수익모델 기반의 무료 앱만으로는 SW의 지속적인 성장과 발전을 위한 토대를 만들 수 없다. SW의 가치가 존중되고 가치에 대해 댓가를 지불할 수 있는 유료 기반이 필요하다. (2011/6/17)

결국 지속가능한 SW는 그 가치를 인정받아야 한다. 공공재라 하더라도 가치가 누군가에 의해 지불되어야 한다. 애플은 맥과 iOS 앱스토어를 통해 유료 앱의 가치가 존중되는 생태계를 만드는 데 성공했다. (2011/6/17)

오픈소스SW의 등장으로 SW가 무료로 이용가능한 공공재처럼 만들어지는 경향도 있다. 하지만 공공재도 구축 비용을 누군가 지불해줘야 한다. 아니면 구글처럼 간접 수익 모델이 있든지 해야 하는데 그건 매우 제한적이다. (2011/6/17)

솔루션의 경우 HW는 재료비+공정비+이윤, SW는 이윤이다. 재료비와 공정비가 거의 들지 않는다. 하지만 SW는 투자비와 자금 순환 기간이 길다. 지적 재산은 인류에 귀속되므로 가치를 인정받을 수 없다는 것일까. (2011/6/17)

소프트웨어를 한다는 교수들 입에서 SW는 무료고 기술지원으로 먹고 살아야 한다는 얘기를 들을 때면 황당하다. 왜 SW는 무료라고 느낄까? HW는 gps sensor든 내장 mic든 이어폰이든 다 비용을 지불하면서. (2011/6/17)

iOS용 키노트 구매해서 써보고 있는데 간단한 PT는 쉽게 작성. 인덴트 변경이 좀 불편한 걸 제외하면 훌륭한듯. 다만 PPT로 export는 완벽하지 않아 PC로 보내면 손을 봐줘야 한다는 점은 아쉬움. (2011/6/16)

드레스 코드. 탈권위 시대였던 참여정부가 끝나고 연로하신 분들이 권력 옆에서 한소리씩 하시더니 기업에도 정장 바람이 분다. 아열대화하는 여름 날씨에 개발직군에 와이셔츠라니. 이래저래 권위주의 정부 아래서는 숨쉬기 어렵다. (2011/6/16)

허크.. xcode가 프로토콜 메소드 구현부의 return type이 잘못되었는데도 warning도 안 주네. void로 잘못 복사해서 objc_msgSend에서 EXC_BAD_ACCESS. 1주일 날렸네 ㅠ_ㅠ; (2011/6/15)

전직 구글 엔지니어가 구글의 인프러스트럭처를 구식이라 평가 http://t.co/zZMtu7O GFS나 BigTable은 10년 지난 낡은 아키텍처. 구글의 새 프로젝트를 툴을 필요로 하는 개발자가 아닌 진공 상태의 엔지니어가 기획. (2011/6/13)

나가수 김범수의 님과함께를 보면 협업적 창의의 힘을 여실히 볼 수 있다. 2주의 시간 동안 팀의 수많은 아이디어를 공연에 결합시킨 대단한 전문가들. 쿵푸팬더2와 X-Men 1st class에서 느낀 협업적 창작의 힘을 다시 느낀다. (2011/6/12)

인소싱 집단창작은 아웃소싱 형태인 (오픈 혹은 클로즈드) 크라우드소싱과 더불어 인간의 집단적 지성을 활용하는 큰 두 가지 형태이면서도 단기적인 효율과 완결성 측면에서 후자에 비해 좀더 효율적이다. (2011/6/11)

쿵푸팬더2나 엑스멘 퍼스트클래스 같은 영화를 보고 나면 헐리우드의 집단 창작collaborative(collective) creation의 성과에 감탄하지 않을 수 없다. 프로페셔널 그룹 인소싱의 창작 능력 참 대단하다. (2011/6/11)

프휴. 왼쪽에서 오른쪽으로 가더니 세상 보는 눈 자체가 흐리멍덩해진... 왼쪽 오른쪽이 아니라 삶과 사람을 지금이라도 본다면 그리 오락가락하며 망상 속의 전투를 이어가려나. (2011/6/10)

SW와 같은 고도화된 지적 노동의 지적재산권 문제 참 미묘합니다. 전 판단을 유보하고 있습니다. 지재권 무용론보다는 지재권 보호에 기울긴 하지만 보호 범위에 대해서는.. 특히 미국의 관대한 특허 정책은 반대하는 쪽입니다. (2011/6/10)

티맥스 프로프레임 대법 판결 관련 사법부의 판단에 대해서는 동의하지 않습니다. 기술적으로 전혀 다른 아키텍처를 개작으로 판단한 데 대해. 하지만, 민사 재판 과정에서 저지른 실수들 때문에 판단이 기운 것이라 어쩔 수 없네요. (2011/6/10)

기사 내용이 이상한 것들은 기자가 몰라서 그러려니 했었는데 이런 자세로 IT산업을 비판하다니. 예를 들면 국내기업이 클라우드 도입하지 않는다고 비판하는 황당한 소신 기사도 있었는데. 저널리즘도 팩트도 없는 기자 권력들이라니. (2011/6/10)

핵심 쟁점을 외부에서 알기 어려울 순 있지만 최소한 양쪽 주장을 듣고 판단하는 기자 정신이 있어야 한다. 특정기업 보도자료 그냥 실어주는 언론들, 우리나라 IT 정체에 한 역할들 하는 셈이다. (2011/6/10)

티맥스 프로프레임 관련 상고심 결과 보도를 보면 우리나라 언론의 현실을 볼수있다. 동일한 사실을 승소다, 패소다 교묘하게 보도한다. 특정 기업 홍보실 자료를 그대로 실은 것. 기성 언론 외에 블로터닷넷도 마찬가지. IT 전문언론 한심하다. (2011/6/10)

위키피디아 항목의 첫번째 링크를 쫓아가면 항상 Philosophy로 통한다는 실험 http://t.co/WoXjILg 모든 개념적 항목은 철학에서 출발한다는 철학적 해석이 가능. (2011/6/9)

네이티브 앱이냐 웹앱이냐는 개발의 생산성과 크로스플랫폼 등의 이슈가 함께 물려있는 해묵은 논쟁거리이다. 클라우드 컴퓨팅에서 보면 프로세싱을 클라우드에서 하느냐 클라이언트에서 하느냐의 메타포 이슈로도 볼 수 있다. (2011/6/9)

애플이 다듬어지지 않은 자발적 다양성을 수용 못해온 건 맞지만, 프로페셔널리즘이 필수 플랫폼 서비스들은 free 서비스로 공존시켜 앱의 영역을 클라우드 기반까지 확산시키는 전략을 펴면서 앱과 웹앱의 공존은 당분간 지속될 것같다. (2011/6/9)

애플은 프로페셔널리즘, 웹은 아마추어리즘이라는 글이 있었다. 커머셜 앱들이 웹에서 득세 못하고 애플플랫폼에선 강세인 점에선 유효한 비유이다. 다만 웹은 자발적 다양성과 참여적 전문성이 공존하는데 아마추어리즘만으로 보긴 어렵다. (2011/6/9)

어제밤엔 코피를 다 쏟았다. 몸이 예전만 못하다. 조금만 무리하면 금새. 생각해보면 지난날에도 밤새면서 박카스로 버틴 거지, 체력으로 버틴 건 아니었다. 생각을 필요로 하는 영역에선 자기 한계 관리가 퍼포먼스에 직결. (2011/6/9)

주 100시간 근무, 최고 엘리트들이 만든 스타트업이란 문구. 주 100시간은 일요일에도 밤새 일할 때 나오는 근무시간. 결과와 성과에 대해 자기 책임 하의 관리가 중요. (2011/6/8)

iBookstore가 국내에서는 아직이군요. iTunes store에서 iBooks용 책들을 직접 검색할 수 있게 바뀌었지만(iTunes 10.3) 여전히 국내에서는 Movies, TV Shows, Books, Ping이 안 보임. (2011/6/8)

icloud 발표하자마자 바로 iTunes 새 버전 10.3 다운로드 가능, 앱스토어도 클라우드 기반으로. 앱 개발자로서 당장 dropbox냐 icloud냐 고민해야 하는군. Dropbox 입지가 하루아침에 무너지려나. (2011/6/8)

iTunes 10.3 (iTunes in the Cloud 베타 포함) 다운로드 가능 http://t.co/mV2Jd1Y iBookstore도 iTunes에서 검색이 가능해졌네요. 안되어서 의아했던 기능 (2011/6/8)

iTunes Match 서비스는 음원을 거의 다 확보하고 있는 회사가 클라우드 음원 스트리밍할 때 취할 수 있는 서비스인듯. 멋지긴 한데 국내에서는?! (2011/6/7)

WWDC 키노츠를 와이파이와 3G로 해서 버스와 지하철에서 다 봤음. 2시간. 3G에서도 끊김없이 잘 스트리밍되는 데 감명. 역시 유튜브 동영상이 잘 끊기는 건 뭔가 다른 이유였던 거군. (2011/6/7)

디지털 허브. 스토리지+푸쉬. 프러세싱은 앱. 이것이 스티브잡스의 iCloud 메타포 (2011/6/7)

Wifi sync iTunes, iOS간 메시징. iOS5에 포함된 가장 기다리던 기능들이군요. (2011/6/7)

우리 시간으로 다가올 새벽 2시에 잡스의 키노트와 함께 열리는 애플의 WWDC 개발자 행사. 티켓 값이 1599달러인데 10시간만에 5천장 매진되었다고.(자바원도 그정도 했었나?) 키노트를 라이브로 들을 수 있으려나. (2011/6/6)

그러다보면 기획의도는 어느 정도 만족할지 모르지만 기본 만족도가 떨어지게 된다. 첫 시도라서 그렇겠지만 이런 앱들은 1회성 용역 외주로 만들어지기 때문에 다음에 더 나아지기 어려운 것도 사실이다. IT 플랫폼의 특성을 모르기 때문. (2011/6/5)

씨네21 아이패드앱이나 다른 국내 eReader앱, 혹은 신문앱들을 보면 기본 규칙을 무시하고 내용만 채운다. 이건 플랫폼을 모르는 기획자가 기획 의도에 맞게 밀어붙이는 방식으로 앱들이 만들어졌다는 뜻. 우리나라 앱 생산공정의 현실. (2011/6/5)

아이패드 씨네21 앱(@cine21_editor) 소감. 아이패드의 줌이나 문단 폭 확대 등 기본 읽기 규칙 무시하고 컨텐츠에만 집중해 가독성 낮음. 기본 규칙은 플립보드나 트위터 앱에서 배우길. 아이패드 전용 앱을 시도했다는 데 큰 박수 (2011/6/5)

윈도8이 터치 기반에 윈도폰7 UI 흡수하고 한걸음 더 나아간다. 맥OS X Lion에는 이미 아이폰 장점들을 적용하고 하반기 출시하니 또 한발 늦는 셈. 하지만 MS는 항상 늦게 출발하지만 힘을 사용하는 기업. 아직 끝난 건 아니다. (2011/6/4)

Apple is professional, the web is amateur http://t.co/VHKXIZc 애플의 프로페셔널리즘이 웹과 소셜에서 실패하게 한다는 의견 (2011/6/4)

애플이 탈옥한 iOS 기기를 위한 대체 노티 시스템인 MobileNotifier를 만든 개발자 Peter Hajas를 채용했다고 http://t.co/Gmepvsv 애플로서는 흔치 않은 일인듯. (2011/6/4)

초기 플러스원은 검색 결과에 대한 플러스원을 뜻했는데 이것은 상당히 불편함만 초래. 임의의 웹페이지에 플러스원을 둔다는 건 웹의 각 요소에 +1 의견을 표시할 수 있는 메타포일듯. 소셜 기능과 구글의 이익은 뭘까가 궁금. (2011/6/4)

금요일 오후의 퍼블리싱 http://t.co/tzHTTcG 금요일에 중요한 발표를 안하는 것은 기업하는 사람들에겐 익숙한데 역발상을 하시는 기업가정신 투철한 관료분들이 계시군요. 쩝 (2011/6/3)

현세에 괴로와하며 내세를 위해 사는 많은 분들, 이 나라의 서글픈 현실. (2011/6/3)

마인드매핑 전문가 토니 부잔 Q&A http://t.co/ABQRShq 숙련된 마인드매퍼는 한 주제에 대해 평생 동안 매분 새로운 아이디어를 만들 수 있다. 일반적인 생각법으로는 기껏해야 20개 정도. (2011/6/3)

통찰이 아니라 막연한 감이 맞을 때도 많다. 하지만 통찰은 틀리더라도 오류를 수정하고 발전시킬 수 있지만 감은 열번 맞고 한번 틀려도 그걸로 끝이다. 최소한의 논리를 만들지 않고 감이 좋고 나쁘다는 주장은 반박할 수도 없다. (2011/6/3)

에릭 슈미트는 표준적인 IT회사의 곡선과 관련, 두친구가 회사를 시작해서 상장하고 부자가 되고 회사가 점차 지루해지고 중년회사가 되는 것이라고 말했다. 자체 혁신 사이클 기간의 정체도 우려. 지루할 틈이 없으려면? (2011/6/2)

사람의 뇌는 65세까지는 계속 발전한다고 하지만, 코더로 사는 건 노안이 오기 전까지일듯. 노안이 덮치기 전에 빨리 코딩해야겠다. 아, 다촛점렌즈 안경 쓰고 코딩이라... (2011/6/2)

아이패드나 킨들이 책을 대체하더라도 공책은? 공책은 노트북인데 노트북 컴이 공책은 대체못하니 아이러니. 물론 공책 개념의 태블릿들이 있긴 하지만... (2011/6/2)

"지나간 일은 모두 꿈에 불과해" 요즘 제 기억력 상태는 이렇군요. ㅠㅠ (2011/6/1)

그래서 학습 능력을 높이기 위해서는 한번 학습한 지식을 24시간 이내에 리프레시해주면 장기 기억 장소에 저장되어 오래 기억할 수 있다고 합니다. (2011/6/1)

캐시처럼 들고 있는 정보는 적당한 기간이 지나면 소멸되거나 혹은 기억 장소로 저장하게 되는데 보통 24시간 이내입니다. 그런데 이 캐시에 들고 있는 정보를 다시 학습하게 되면 기억 장소로 이동 저장할 확률이 매우 높다고 합니다. (2011/6/1)

사람 뇌의 스토리지 메커니즘은 많이 알려져 있진 않지만 어떻게 생각이 기억으로 저장되는지에 대해 알려진 게 하나 있는데 정보를 접하게 되면 바로 기억 장소로 이동되지 않고 일종의 CPU 캐시처럼 들고 있는다고 합니다. (2011/6/1)

클라우드 얘기는 kt의 ucloud도 그렇지만 애플의 iCloud를 두고 미국 테크 저널에서도 비슷한 추측을 하길래 의아해서 던져보았습니다. 스토리지도 컴퓨팅의 한 구성요소이긴 하지만... (2011/6/1)

클라우드를 스토리지로 접근하는 것은 어떤 논리에서일까 궁금하네. 스토리지 서비스를 클라우드 서비스로 등치시키는 경향이. (2011/6/1)

시작은 했으나 진척은 이리저리 치인 채 맥만 간신히 살아있는데 벌써 6월이네요. 손댄 일들 마무리에 전념해야겠네요. 마무리를 못하면 새로운 결정을 위한 판단 근거를 만들 수가 없지요. 다행히 이 달은 다른 일이 적은 달 ㅠㅠ (2011/6/1)

아이패드2 HDMI로 AV 리플렉션하면 유튜브 같은 동영상의 경우 리플렉션되지 않고 TV에서만 실행되는데 이 화면은 와이드로 볼수있는 옵션이 설정에 있습니다. 참고하시길. (2011/5/31)

소송 대응도 카피캣. 조롱거리가 되었군. (2011/5/31)

아이패드용 앱은 맥용 어플 수준의 복잡도가 필요한데 플립보드와 같은 터치감과 인터랙션도 필요. 책이나 잡지와도 통하고... 그렇다고 텍스트 입력을 많이 하긴 부족하고... (2011/5/31)

아이패드 몇일 잡고 있으니 맥북과도 많이 다르고 아이폰과도 많이 다르다. 참, 심오하군. 어댑터와 케이블을 따로 사야 하지만 비디오 리플렉션 기능도 괜찮은 아이디어. (2011/5/31)

아이패드2+스마트커버. 책(pdf 문서들) 읽기 딱 좋은 각을 만들어주는듯. 해상도는 생각외로 큰 문제가 아님(세워놓고 읽으니 거리가 있어서인듯). 휴대성은 만원버스 타는 사람에겐 별로(지하철 앉아가는 사람용?). (2011/5/30)

아이패드 멀티핑거 제스처 (앱 닫기, 앱전환) 편한데 사파리에는 왜 맥 사파리의 멀티핑거 제스처 지원 안하는지 아쉽군요. 맥북에 길들여져 있어서 아이패드 사파리 사용 불편. (2011/5/30)

아이패드에서 두 손 입력할 수 있다는 생각은 환상일뿐일까? 메일이나 트윗 정도는 가능할 것 같은데 UI가 쉽게 입력 창을 닫지 않는 앱에서만 가능. (2011/5/29)

안드로이드마켓서 돈 벌기 힘든 이유 "애플리케이션 개발자들이 애플의 앱스토어보다 구글의 안드로이드마켓에서 돈을 벌기가 더 어렵다" http://t.co/t3NaQuB 알려진 것이지만 안드로이드마켓은 유료 앱 성공 어려움. (2011/5/28)

일요일, 6월 12, 2011

Apple iCloud와 Google, Cloud Computing Metaphor 비교

애플의 스티브 잡스는 6월 6일 있었던 WWDC 오프닝 키노트에서 자사의 iOS 플랫폼을 새로운 클라우드 컴퓨팅 플랫폼인 iCloud와 밀접하게 결합하도록 플랫폼의 진화를 선언했다.

일부 클라우드 서비스 제공 기업들이 클라우드를 주로 스토리지 즉, 저장소 중심으로 표현하는 경향이 있어서, 왜 KT 같은 기업들이 클라우드 컴퓨팅을 스토리지 중심으로 바라보나 (혹은 광고하나?) 하는 의문이 있었는데, 애플의 iCloud 발표는 또하나의 다른 시각을 보여주는 셈이었다.

스티브 잡스가 설명하는 애플의 iCloud 메타포

클라우드 컴퓨팅을 어떻게 이해하면 좀더 쉽게 개념(mental image)을 잡을 수 있을까? 그리고 구글과 애플, 기타 다른 기업들의 접근 방식을 이해할 수 있을까?
추상적 개념은 은유법만큼 이해하기 쉬운 게 없고, 또 잘 만들어진 은유 체계는 사고의 깊이를 더하고 더 발전시킬 수가 있다.
조금 지나치게 단순화하는 감이 있지만, 개괄적 수준에서 이해해주기 바란다. 클라우드 컴퓨팅의 기반 기술을 보는 게 아니라 활용 측면에서 바라보는 것이므로 전문 지식 없이도 쉽게 이해할 수 있을 것이다.

클라우드 컴퓨팅의 메타포(은유 체계)
흔히 클라우드라고 부르는 것은 클라우드 컴퓨팅(Cloud Computing)을 뜻하는 것인데 단순화해서 표현하자면 클라우드는 인터넷을 의미하고 컴퓨팅은 개념적인 컴퓨터의 연장선 상에 있다.

메인프레임, 유닉스 혹은 퍼스널 컴퓨터(PC)에 익숙해진 컴퓨팅 개념을 클라우드로 확장시키려면 컴퓨팅의 요소들을 식별해보면 쉬운데 대표적 요소는 1. 프로세서 즉 계산 장치, 2. 장기 기억 장치 즉 저장소(스토리지), 그리고 3. 이 환경에서 실제 실행되는 프로그램들을 들 수 있다.
이렇게 단순화하면 첫번째 요소인 프로세서에는 PC의 경우에 CPU와 메모리, 캐시 등의 요소들이 모두 포함된다고 볼 수 있다. 즉, 프로세서라고 분류한 영역은 계산 능력을 가지고 있다. 좀더 구체적으로 기능을 설명하면 프로그램을 실행하는 요소이다.
두번째 요소인 스토리지는 다양한 용도로 사용될 수 있겠지만, 보통의 경우 프로그램을 저장하는 스토리지와 데이터를 저장하는 스토리지로 구분할 수 있다.
세번째 요소는 프로그램, 실제 실행 가능한 논리들을 가지고 있는 단위이다. 보통 프로그램 프로그램용 스토리지에 저장되어 프로세서에 의해 실행된다고 볼 수 있다.

구글의 클라우드 컴퓨팅
클라우드 컴퓨팅의 확산에 절대적인 기여를 한 기업으로 구글을 들 수 있다. 구글은 현재 회자되는 클라우드 컴퓨팅의 기술적 토대를 구현하고 또 그 기술을 공개하는 등 대단한 기여를 해왔다.
앞의 세 가지 분류에 따라 구글의 클라우드 접근을 정리해보자.

1. 프로세서
구글에게 있어 클라우드 프로세서는 실제 클라우드로 구성되는 서버에 존재한다고 볼 수 있다. MapReduce와 같은 클라우드 상의 동시 처리 기술을 가지고 이에 맞게 설계된 프로그램들이 실제 클라우드에서 실행된다.

2. 스토리지
프로그램 정보도 서버의 확장 개념이라고 볼 수 있는 클라우드 상에 위치하고, 프로그램이 사용하는 데이터 역시 클라우드 상에 위치한다.

3. 프로그램
구글의 클라우드 프로그램은 기본적으로는 기존 서버 프로그램의 확장이라고 볼 수 있다.

클라우드 기반의 프레임웍(PAAS, Platform as a Service)인 Google AppEngine 같은 형태로 혹은 다른 수많은 서비스 API들로 프로그램들을 좀더 쉽게 만들 수 있도록 해주기도 한다.
구글에게 클라이언트 즉 사용자와의 인터랙션을 담당하는 프로그램은 웹 기술을 사용하는 것이다. 웹은 서버에서 주로 실행되는 사용자 인터랙션 처리 코드를 가장 잘 실행할 수 있는 환경이다.

구글의 크롬 넷북은 이러한 클라우드를 사용자에게 잘 전달해줄 수 있는 휴대용 콘솔 역할을 할 수 있다. 프로세서, 스토리지, 프로그램이 거의 모두 서버 개념의 확장인 클라우드에 위치하기 때문에 콘솔 자체는 크게 중요하지 않다.
따라서, 구글의 클라우드 컴퓨팅은 점점 더 웹 표준과 서버쪽 기술에 집중한다. 이런 측면에서 안드로이드 모바일 플랫폼의 현재 모습은 애플의 iOS와 경쟁하기 위해 현실적인 형태를 취하고 있으며 점점 더 웹 콘솔의 역할이 강화될 일종의 전이기transition period 단계에 있다고 볼 수 있다.
모바일의 특성을 살리면서도 크롬 넷북의 성격을 받아들이는 길을 택할 것이다.

애플의 iCloud
이번에 발표된 iCloud는 일반화되어 있는 구글의 클라우드 컴퓨팅 시각과는 조금 다른 측면을 볼 수 있었다.
개인적으로는 분산 컴퓨팅과 서버쪽 기술에서 출발한 구글과 개인화된 클라이언트 컴퓨팅에서 출발한 애플의 특성 차이라고 느꼈다.

1. 프로세서
애플은 클라우드 상에서 실행되는 서비스나 앱에 대해서는 언급이 없다. 여전히 로컬 클라이언트의 CPU에서 대부분의 프로세싱을 처리한다.
프로그램의 주된 형태도 여전히 개인 컴퓨팅 기기에서 실행되는 클라이언트 앱이나 애플리케이션이다.

2. 스토리지
애플의 프로그램 스토리지는 예전처럼 프로그램은 클라이언트 기기에 있고, iCloud는 프로그램 바이너리의 백업 역할을 한다.
데이터 스토리지는 클라이언트 기기에도 있지만, 점점 더 클라우드의 역할이 커질 것으로 보인다. 클라우드의 역할이 커질수록 로컬 스토리지는 클라우드 스토리지의 캐시처럼 역할을 하게 될 것이다.

3. 프로그램
전통적인 로컬 앱과 크게 다르지 않지만, 클라우드 스토리지 활용이 쉬워진다는 차이점이 있다. 구글의 경우 클라우드 기반의 서비스들이 주 프로그램이고 웹이나 앱으로 작성된 사용자 인터랙션 부분은 단순 콘솔 개념의 클라이언트 역할을 하지만, 애플의 경우에는 클라이언트 앱이 핵심 역할을 여전히 수행한다.
클라우드 기반의 서비스는 애플에겐 그야말로 서버 기반 서비스이며 로컬 앱과는 다른 지위를 가지는 것으로 보인다.
물론 애플도 공식적으로는 HTML 5 표준 기반의 웹 앱 지원에 대한 적극 지원을 약속하고 있긴 하지만, 현실적으로는 웹앱에 큰 비중을 두지 않는 것으로 보인다.

애플 iCloud와 구글, 미래는 구름 속
애플의 iCloud는 기존의 클라이언트 컴퓨팅 기조를 유지하면서 프로세싱과 스토리지 측면에서 최대한 클라우드의 장점을 자연스럽게 활용할 수 있도록 하는 iOS 플랫폼의 보완 측면이 강하다.
구글처럼 모든 것을 클라우드에서 처리할 수 있다고 보는 근원적인 발상의 전환과는 차이가 있다.
하지만, 어느것이 더 낫고 못하는가의 문제는 아니다. 여전히 구글은 네트웍은 신뢰할 수 없다network is unreliable는 네트웍 기반 컴퓨팅의 근원적인 약점을 해결 혹은 보완하기 위해 다각도로 노력하고 있다.
최근에 드러나고 있듯이 클라우드 컴퓨팅에서 정보가 한 곳에 모일 경우 개인 정보에 대한 보호, 보안 문제가 해커 뿐만 아니라 정보 당국 압력에 의해서도 위태로와지는 단점도 보인다.
애플의 iCloud는 구글의 컴퓨팅 패러다임 전이처럼 놀라운 일은 아니다. 다만 애플이 해왔던 클라이언트 기반 컴퓨팅 플랫폼의 관점에서 클라우드의 장점을 매우 자연스럽게 결합해내고 있다. 구글이 혁명이라면 애플 iCloud는 개혁 수준이라고 할까.
개인적으로 클라우드의 미래는 아직 완벽하진 않다고 생각한다. 구글 크롬북과 같은 크고 작은 실험들이 어떤 결과를 가져올지에 따라 달라질 것 같다.

토요일, 5월 28, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.4.12~2011.5.28)

지난 트윗들 정리했습니다. 동시에 두세 가지 일을 진행 혹은 준비하는 게 예상은 했지만 무척이나 어렵네요. 5월도 다 저뭅니다. 진척도 있지만 기대에는 못미치고 바빴던 5월이네요.
외부 세계와 단절되어 일할 수 있는 환경이 아니라면 조금씩 그런 영역을 넓혀가야겠지요.

아이패드는 아이폰과 달리 잘맞는 앱들을 구하지 않으면 아무짝에도 쓸모없는듯. 앱이 생명이네요. 좋은 아이패드 앱 추천해주세요. 교육용도 좋구요. (2011/5/27)

정말 너무 단순한 얘기여서 얘기하는 경우도 있지만 자신의 지식 깊이가 얕고 기계적이어서 사물을 단정적으로 얘기하는 이들이 습관적으로 "당연하지"라고 한다. 물론 자신의 지식 한계를 건드릴 때 방어본능에서 말하는 경우도 있다. (2011/5/27)

"당연하지"라는 말을 회의에서 자주 사용하는 사람은 주의해야 한다. 기본 지식이란 권위를 들이대어 논의의 진전을 막는 행위기 때문이다. 세상엔 당연한 논리가 많지 않다. 수많은 사고의 경로가 가능하고 다른 뷰가 존재한다. (2011/5/27)

영화나 음악을 분석적으로 보는 사람들은 예술 향유를 못한다. 일단 사심없이 즐긴 후에 나중에 분석하라. 경쟁에 내몰린 사람들도 그런 경향이 있다. 대단한 창조나 혁신을 먼저 즐기지 못하고 경쟁기업을 깎아내려야 하는 사람들은 불행하다. (2011/5/26)

SW를 국가 경제의 경쟁력 면에서 보면 원천 기술 확보가 반드시 필요하다. 아이러니하게도 글로벌 오픈소스가 이런 경쟁력 확보를 막고 있다. 오픈소스 참여도 미약하고 이해수준도 낮고 제어도 못하면서 마치 기술확보된듯이 치부한다. (2011/5/26)

소프트웨어 엔지니어 혹은 예비자들에게 늘 하는 말, "우린 implementer잖아". 황당한 소설 쓰지 말라는 뜻이자 생산자의 긍지를 가지라는 뜻이기도... (2011/5/26)

iPad2 받고 첫 느낌은 "휴대성이 떨어지는구나" iPad보다 크기는 같지만 얇고 가벼워 손으로 잡기엔 오히려 더 불안한듯. 스마트 커버의 자석 힘만으로 받칠 수 있는 건 장점. (2011/5/26)

명지대 용인캠퍼스 CS 4학년들에게 무료 특강 "창의와 열정, SW 엔지니어" 마치고 나오는 길. 뒤늦게 준비하느라 4시까지 잠못자고 준비해서 간신히 ㅎㅎ (2011/5/25)

창의적 사고의 방법으로 자주 인용되는 lateral thinking을 수평적 사고로 번역하면 완전히 다른 뜻이 되어버리는데 lateral은 사람이 오른손잡이처럼 한쪽을 많이 사용하는 현상을 뜻함. 비대칭으로 생각하기 정도가 맞으려나? (2011/5/24)

부지런함의 대명사 일개미들도 다 부지런하지는 않단다. 약 80%가 부지런하고 20%는 딴짓 부린다는데 재미있는 건 이 20%를 골라내면 부지런한 놈들 중 다시 20%가 어슬렁거리게 된단다. 사람은? ㅎㅎ (2011/5/22)

스티븐 호킹의 위대한 설계 the grand design 읽는 중. 실재와 관찰, 인지, 뇌에 대한 혼돈을 즐긴다. (2011/5/21)

당연한 얘기지만 항상 창의를 위한 사고 패턴을 사용하는 것은 비효율적인 셈이다. 오히려 순차성이 강한 특성의 지식 업무에서는 집중력을 떨어뜨릴 수 있다. (2011/5/20)

지식 노동의 성격에 따라 생각하는 방식에 변화를 줄 필요가 있는데 예를 들어 패턴적인 부분에서는 좀더 차분하게 냉철하게 가라앉히고 연결된 생각을 억제한다든지 솔루션이나 아이디어를 탐구할 때에는 좀더 적극적으로 생각을 연결시킨다든지. (2011/5/20)

모든 지식 노동이 항상 창의적인 것은 아니며, 경험에 의해 숙련된, 기계적이며 반복적인 부분도 포함하게 마련이다. 쾌적한 지식 노동 환경은 지식 노동의 연속성을 보장해주고 건강과 의욕 결국 감성적인 부분을 뒷받침해주는 환경이다. (2011/5/20)

사람의 감정 상태가 사람의 지식 노동에 미치는 영향은 뇌의 활성화나 활동 수준이 아니라 의지, 의욕과 관련된 것이다. 장기적으로 스트레스에 노출되면 건강이 악화되고 의지가 꺾여 지속적인 지식 노동 활동이 불가능해진다. (2011/5/20)

사람의 감정 상태와 뇌의 창의적 활동과는 직접적인 관련이 없다. 자유로움이나 편안한 심리 상태가 창의 활동을 돕지 않는다는 것이다. 긴장, 스트레스가 뇌에 짧은 순간에 많은 입력을 줘서 오히려 창의적 결과를 유발하기도 한다. (2011/5/20)

한 조직에 오래 있으면 변화를 시도하기 어렵다. 전혀 다른 새로운 시각으로 자신의 모습을 돌아볼 필요가 있다. 역설적으로 한 조직에 오래 있으면서 끊임없이 스스로를 변화시키고 원칙을 재정립하는 사람이 정말 대단한 사람이다. (2011/5/19)

크롬북 써보진 않았지만 제한적인 환경(학교 캠퍼스나 기업 안)에서 주로 사용하는 업무에 유용할듯. 사용 패턴 확보해가다보면 패러다임 시프트와 기술변화가 함께 하지 않을까? 당장 수익은 안되겠지만. 패러다임 변화는 긴 호흡의 도전. (2011/5/17)

맥북프로 발열이 계속 되어 구글링해보니 원인은 역시 배터리 충전인듯. 배터리가 충전 상태에서는 상당히 뜨거워지는 듯. 80% 이상 충전 상태(trickling 충전)에서는 좀 덜한듯. (2011/5/17)

큰 실패를 경험한 후 당시 휴먼 네트웍을 다시 잇고 새로운 네트웍을 없앤다면 애써 재도전의 결과를 지켜보지 않아도 결과는 정해져있다. 특히 꿈을 쫓는 사람에겐 현실과의 긴장이 중요하기 때문이다. (2011/5/17)

개인의 휴먼 네트웍은 그 개인을 상당 부분 반영한다. 측근의 성향을 보면 개인의 행동 방향이 예측된다. 정치든 기업이든 측근이 현실 분석과 검증 기회를 막고 왜곡한다면 의사 결정은 비현실적일수밖에 없다. 네트웍을 갈아업지 않는 한. (2011/5/17)

맥OS X이 iOS의 장점들을 흡수하는 작업이 올 여름 공개될 Lion 버전. SW가 이렇게 바뀌니 맥 데스크탑과 랩탑이 강력한 아이패드가 되는 건 당연한 귀결일듯. 비단 맥뿐 아니라 MS나 구글의 움직임도 이러한 흐름 위에 있을듯. (2011/5/16)

Log on Java: Apple의 Hippie 정신을 유지해주는 관리 체계 http://t.co/GQZDcIU 애플의 제품은 히피적이지만 애플 조직은 철저하고 치열하다. (주말 퍼블리시라 다시 트윗합니다.) (2011/5/16)

SW공학의 형식적 적용을 지지하는 이들은 "하는 게 안하는 것보다 낫다"라는 주장을 많이 한다. 사실은 "하는 것의 인적, 시간적, 비용적 손실"을 고려하면 "핵심 문제에서 분명한 개선"이 아니면 안해야만 한다. (2011/5/15)

토론을 할때 "이렇게 해왔고 효율적이라고 느낀다"는 의견이 무의미하진 않지만 "왜"라는 질문에 답할 수 있어야 관행이 아닌 발전과 혁신을 끌어낼 수 있다. 각 개인 스스로 "왜"에 대한 답을 생각해야 개인보다 나은 집단을 만든다. (2011/5/15)

기획과 개발을 분리하는 건 머리와 몸을 분리하는 건데 우리나라 SW 체계에서 개발은 몸의 역할이다. 아이디어가 상향으로 나올 수 없다. 엔지니어는 총화 능력과 창의 능력을 갖춰야 한다. 개발자는 단순 개발만 하는 단순업무자가 되었다. (2011/5/15)

애플의 제품은 히피적이지만 애플 조직은 철저하고 치열하다. (2011/5/15)

Log on Java: Apple의 Hippie 정신을 유지해주는 관리 체계 http://t.co/1tWi8gC 아침에 읽은 포쳔 지의 애플 관련 기사에서 느낀 점을 간략히 적어봤습니다. (2011/5/14)

애플 경영의 핵심은 상무급의 책임제. aspect 중심의 특화된 책임제. http://t.co/3oKJ6I7 (2011/5/14)

맥북으로 PDF 문서볼 때 가장 아쉬운 건 아이패드처럼 세워서 볼 수 없다는 건데 맥을 iOS화하는 Mac OS X Lion이 나오면 맥북도 아이패드화하지 않을까 기대. 큰 키보드 달리고 로테이션 가능한 스크린을 가진 맥북. (2011/5/13)

수익이 장기적으로 가치에 기반하지만 단순 비례하지 않으니 가치 창출을 창업의 진정한 목표 혹은 철학으로 삼아야겠죠. 진정성을 필요로 하는 시대적 요구! 공감합니다. 분명 있고 더 커지고 있지요! (2011/5/13)

공동 창업가들의 창업 목적이 앞에서 말한 1,2,3 범주에서 서로 갈라진다면 그 창업이 성공할 수 있을까요? 적어도 기민한 역동성은 기대할 수 없을 것 같네요. (2011/5/13)

개인적으로는 1. 수익이 나는 "제품을 만드는 것"을 선호. 물론 제품을 만드는 게 아니라 수익이 나는 제품을 만드는 것이지만, 만드는 것 자체가 목적의 핵심을 이룬다는 점에서 엔지니어적인 듯. (2011/5/13)

SW 창업의 목적은 무엇인가요? 1. 수익이 나는 제품을 "만드는 것" 2. 제품을 만들어 "수익을 내는 것" 3. 엔지니어의 협업 사회를 만들어 "공생하는 것"

1은 엔지니어 기업가 2는 세일즈 기업가 3은 그냥 엔지니어의 관점 (2011/5/13)

50:50 균등 지분 창업일 경우 위험하다는 주장과 반론이 있었는데 지분 창업자들이 모두 2P(열정과 퍼포먼스)가 어느 정도 이상 지속해간다면 문제가 되지 않을 것이다. 어느 한쪽이라도 부족하거나 처지는 때엔 재구성하는 게 맞다고 생각 (2011/5/13)

벤처 창업에 필수 요소는 2P 즉, Passion과 Performance라고 생각. 창업자들은 모두 열정과 훌륭한 퍼포먼스를 지속할 수 있어야 한다고 믿음. 그게 아니면 재정적인 투자자로 참여해야. (2011/5/13)

자유로운 영혼으로 살아야 할텐데... 스티븐 호킹 참 대단하군. (2011/5/12)

개체 발생이 계통 발생을 재현한다는 해켈 이론은 오류 http://t.co/aRufrC4 via @ENLIL_kr 다윈 진화론은 이와 관련없고 배발생에서도 진화의 근거는 확인 가능. 잘못된 이론을 사회학 등에서 많이 비유적 인용함은 유감. (2011/5/10)

해켈의 발생재현론도 오류이며 다윈 진화론은 해켈 이론에 기반하지 않고 배발생에서도 진화의 근거는 확인 가능하다. 제 트윗은 배발생이 진화를 반복한다는 인용들이 틀린 주장에서 비롯하므로 삼가달라는 취지였죠. (2011/5/10)

대체로 관찰되지만 엄밀하지 않고 일부 반증도 있어 법칙성은 없기 때문에 진화의 과학적 증거로는 인용할 수 없고 법칙도 아니라는 뜻입니다. 과학은 엄밀성을 요구하지요. 사회학 등에서 많이 비유적으로 인용되는데 주의해야겠죠. (2011/5/10)

JavaOne의 시대는 저물고 Google I/O의 시대가 온 건가... (2011/5/10)

'개체 발생은 계통 발생을 반복(재현?)한다' 이 주장은 현재 생물학에서는 엄밀하게는 성립않는 이론이라고 부정되고 있다는군요. http://t.co/vBggbnd 진화론의 증거 중 하나로 생물 수업 시간에 배웠던 것 같은데. (2011/5/10)

창의적인 지적 업무에는 외부의 동기부여 방식인 당근과 채찍이 아니라 내재적 동기부여 방식인 자율적 의지, 통달, 목표가 중요하다. 100% 동의. http://on.ted.com/9D2F (2011/5/10)

SW 엔지니어는 low level을 추구해야 하나, 변화를 추구해야 하나. 사실 SW 엔지니어에게 엄청나고 급격한 변화가 세상에 일어나진 않는다. 매우 서서히 수십년전부터 있어왔던 것들이 조금씩 현실화되거나 외형적 양상이 변화할뿐. (2011/5/9)

Why is programming unique profession? http://t.co/Yub0HXP 왜 프로그래밍이 독특한 직업인지? 문제 해결 능력과 논리적 사고가 중요한 프로그래머는 진짜배기 사람을 위한 직업! (2011/5/9)

창의적인 프로그래머들을 키우는 환경은 관리와 마케팅을 죽이고 그 반대도 성립한다. 성공한 SW 회사는 프로그래머들을 키운 리더가 있었다. 리더가 관리와 마케팅으로 변신하면서 생산적인 프로그래머들의 조직도 죽는다. (2011/5/9)

How software companies die http://t.co/FMmb11w 창의적인 프로그래머들을 키우는 환경은 관리와 마케팅을 죽이고 그 반대도 성립한다. (2011/5/9)

기회주의와 친일이 지배계층인 한국 역시 과거를 냉정하게 반성, 단절 못하고 외려 이승만, 박정희를 미화하려는 시도는 일본처럼 변화하지 못하고 개인을 고립시키는 사회로 우리 사회를 고착시키려는 반역사적, 반인류적 행위일 것. (2011/5/7)

과거를 냉정하게 반성하지 못하는 민족의 선진성이 무엇일까. 나찌를 죄악시하는 독일과 전범이 지배계층인 일본의 사회적 수준 차이가 최근 일본 위기에서 극명하게 나타나지 않았던가. (2011/5/7)

Xcode 단축키 PDF http://bit.ly/fKO33r 문득 편집하다가 습관대로 ^t를 눌렀더니 transpose된다. 그러고보니 ^a, ^e, ^y, ^x^x, ^spc 등 이맥스 편집키가 상당히 지원. (2011/5/6)

필요한 단계를 거치지 않고 아니 식별 노력도 하지 않고 다음 단계로 바삐 가려 하다가 시간을 허송한다. 마음만 급한 탓인지, 천재연하고픈 건지, 아직 설된 건지... (2011/5/6)

Mac OS X의 한글 저장 방식 http://t.co/p1Cow6D 맥에서 한글이 자소 조합 형태로 나타나는 경우에 대한 설명. 압축 파일을 Finder에서 풀면 이렇게 NFD 형태로 저장되는 듯. 호환성 높이는 방법은 없을까요? (2011/5/3)

일전에 구글이 타이머 엔트리를 링크드리스트에 저장하는 특허를 무효화시키려다 패소했다는 소식이 있었는데 매우 폭넓게 IPR을 인정해주는 미국으로부터 한미 FTA 체결 후에도 SW나 IT 산업 육성할 수 있을까요? (2011/5/2)

기억력이 강하지 않은 사람이 머릿속에 담고 있으면 다른 생각에 간섭이 일어나 생각을 진행할 수가 없다. 무조건 컨텍스트 전환을 위해 外化를 필요로 하는 경우이다. 완벽하게 메모리 속에서 전환하는 사람들이 부럽다. 그들이 진정 천재. (2011/5/2)

두 가지 생각을 계속 머리에 담고 동시에 생각할 수 있다면 좋겠지만 그건 좌뇌의 구조 상 불가능. 하나를 생각하면 하나는 내려야 하는데 기억력을 믿고 내릴 수 있는 사람과 메모를 통해 外化해야 하는 사람이 있을뿐. (2011/5/2)

SW의 low level을 깊이 다룰 기회는 많지 않다. high level은 쉽게 한계에 부딪힌다. 개인적으로 학습하려면 매우 어렵고 더딘 부분이다. (2011/5/2)

Coding Horror: Why I'm The Best Programmer In The World http://t.co/V8XXTsi 자신의 지식에 겸손한 프로그래머가 빠르게 성장한다. 프로그래머 관리의 어려움과 학습의 중요성. (2011/5/2)

iPad 시대에 맞는 새로운 형태의 책을 구현하는 기술 회사인 푸시팝 프레스는 애플 엔지니어 출신이 만든 스타트업 http://t.co/NrHQ81H 책이 변화의 시대에 온 건 분명한데 더 많은 정보를 몰입하도록 전달할 수 있을지가 관건 (2011/5/1)

결정은 언제나 어렵다. 무엇를 취하고 무엇을 버릴 것인가. (2011/5/1)

아마존 EC2와 RDS 서비스 중단 사고 공식 해명. http://t.co/WFIhI7V 스케일링 작업 실수로 낮은 클러스터에 트래픽 집중되고 경쟁조건 발생. 미션크리티컬 작업엔 사람의 개입을 최소화하고 단순화, 툴화에 관심 기울여야. (2011/4/29)

수퍼맨, 미국 시민권 포기…미 보수층 발끈 http://t.co/YaVnxYm 미국 시민권에 목을 맨 사람들에게 수퍼맨이 보여주는 아름다운 정의랄까.. ㅎㅎ (2011/4/29)

서울대, 안철수 교수 임용 확정 - 중앙일보 뉴스 http://t.co/gtAhH3Y 안철수 의장은 도덕성에 기반한 회사 경영과 후진 양성으로 정평이 나 있더군요. 우리나라에 도덕성을 경영의 기반 원칙으로 삼으시는 몇 안되는 분. (2011/4/29)

잡스 ''답변 내놓는데 일주일도 안걸렸다'' http://t.co/tMr5DEz "우리는 공학 기술 중심의 회사다. 사람들이 문제를 제기할 때 우리가 가장 먼저 하는 것은 진실이 무엇인지 찾아내는 것" (2011/4/28)

안되는 걸 되게 밀어부치는 연금술사 역할은 더 이상 하고 싶지 않다. 가능성을 현실성으로 바꾸는 작은 역할을 하고 싶다. (2011/4/28)

numpy나 mlpy 같은 파이슨 라이브러리를 iOS 앱에서 호출하는 게 가능하다는 얘기. (2011/4/27)

애플의 iOS 앱 제약은 사파리 브라우저에서 실행하는 자바스크립트 코드를 제외하면 어떤 코드도 외부의 코드를 다운받아 실행하는 걸 금지하고 있다. 플래시, 액티브X, 자바 애플릿 같은 형태가 금지. 로컬 코드를 인터프리트하는 건 허용. (2011/4/27)

일전에 좋은 분위기의 SW팀에 대한 트윗을 한 적이 있는데 이것은 팀의 일상적인 지적 혹은 코칭과 관련이 있다. 팀원의 의견을 무조건 존중하는 게 아니라 정확하게 문제를 지적하면서 코칭할 수 있는 팀웍을 갖추는 게 중요하다. (2011/4/27)

外化는 구체적으로 글이나 그림으로 적어 사고 바깥의 형태로 정리하는 걸 뜻한다. SW 아키텍처 설계에 사용하는 外化의 방법으로는 키노트나 파워포인트 같은 프레젠테이션 툴이 체계적인 外化를 위해 가장 좋은 것 같다. (2011/4/27)

外化(externalization)는 감정적 기복이나 복잡한 복합 사고로부터 사고의 논리성을 보장해주는 방어 수단이다. SW에서 핵심 아키텍처 설계는 반드시 外化해야 즉흥성을 벗을 수 있는데 外化는 소통을 크게 도와주기도 한다. (2011/4/27)

존중이란 치열한 상호 침투와 새 아이디어를 만들며 부대끼는 과정에서 필요한 것이지 영역별로 개인에 전적으로 찢어 맡기는 데 필요한 게 아니다. 개인의 합으로 만든 SW는 가장 뒤처진 개인 수준, 상호침투는 잠재한 팀의 최상 수준에 근접시킨다. (2011/4/25)

진정 분위기 좋은 SW개발 조직은 존중의 문화를 가진 조직이 아니다. 치열한 토론을 통해 더나은 아이디어를 지속적으로 만드는 팀웍의 조직이다. 상호 영역 존중하는 우수한 인재로 구성된 팀이 허술한 결과물을 낳는 경우가 많다. (2011/4/25)

한국 재벌기업들이 일본 기업문화를 쫓아가니 일본이 성공한 전자, 자동차에선 성공할수 있겠지만 SW 같은 영역에서는 결코 성공하지 못하겠구나 하는 생각이 문득 스쳤다. (2011/4/21)

커머셜을 만들지 못하고 프로토타입밖에 못만드는 사람들은 대학원 lab에서처럼 SW를 만든다. 이런 SW 불임증에 걸린 사람, 조직은 지옥의 강을 건너기 전엔 치유되지 않는다, SW 프로페셔널이 되지 못한다. (2011/4/20)

SE의 문제가 정말 형편없는 데이터였다면 머신러닝을 적용해서 개선할수 있다는 건데 정성 데이터의 계량적 취급은 쉽지 않을듯. (2011/4/20)

Software, Metrics and Ethics http://t.co/xCZYebM SE가 형편없는 건 SW의 복잡성 때문이 아니라 메트릭에 사용된 데이터가 형편없기 때문이라는 주장. 개인적으론 정량화 어려운 정성적 요소가 지배적이라 그렇다고 생각 (2011/4/20)

첨부터 커머셜로 만든 제품조차 보통 사이클을 2,3회 돌아 버전3가 되지 않으면 신뢰하기 어렵다. 커머셜 SW퀄리티의 핵심은 만드는 사람들의 능력 축적에 있다. 프로토타입만 만든 사람들은 지옥의 강을 건너지 않으면 절대 커머셜을 만들지 못한다. (2011/4/20)

일전에 ETRI가 SW국가과제를 받아 프로토타입만 만들고 상용화라는 또다른 과제를 하는 게 우리나라 SW발전에 걸림돌이라고 트윗했는데 실제 커머셜SW를 만드는 건 훨씬 어렵다. (2011/4/20)

Whitebox 테스트를 어떻게 SI만 하던 친구들에게 설명해야 하나. 테스트 코드를 본 코드에 필적하게 짜야 한다고 하면... (2011/4/20)

창의력과 실현력. 그 다음은 즐기면 된다. 고민을 사서 하지 말자. (2011/4/20)

요즘 사람들을 잘 안만나는데 가끔 만나는 분들이 측은하게 본다. 자본도 없이 사업 준비해서 성공하겠느냐는 것. 나도 충분히 동의. 그저 즐겁게 몇년 인생에 도발해보고 싶을뿐. (2011/4/15)

코드량이 많지 않고 아키텍처를 장악한 코더가 있다면 refactoring 운운할 필요없이 과감하게 다시 짜는 게 정답인 경우도 많다. 이런 경우는 사람의 능력 수준에 의존한다. (2011/4/15)

완전히 새로 짠다면 재사용되는 것은 코드가 아니라 사람과 타당성 검증된 개념이다. SW 코드 재사용 문제는 OOP, CBD에서 과대광고되어왔다. 개인적으로는 재사용보다는 모듈화의 방법으로 OOP를 선호한다. (2011/4/15)

코드 재사용의 문제 첨언하면 프로토타입 수준의 개발과 시장경쟁가능한 커머셜 개발은 차원이 다르다. 어떤 방법론을 쓰더라도 프로토타입 코드가 커머셜에서 재사용되어 차지하는 비중은 10% 미만일 것. 버리고 완전히 새로 짜거나 비중이 낮거나. (2011/4/15)

반대로 아키텍처 분석 없이 외형적으로만 조금씩 변경하는 것도 문제. 아키텍처 계층의 문제가 확인되고 재설계되면 이 부분만 전면적으로 다시 코딩하는 게 보통 가장 효율적이다. (2011/4/15)

흔한 오류는 기존 아키텍처 분석이 안되어 무조건 재작성을 얘기하는 경우. 설계 능력이 없어 분석 능력이 없는 것이므로 새로 하면 더 나쁜 코드 작성. (2011/4/15)

보통 다른 팀이 들어오면 기존 코드 갈아업고 전면 재작성을 주장한다. 고도화는 보통 아키텍처 수준의 고도화이므로 아키텍처 수준의 레이어는 재작성이 효율적, 하지만 기능적 요소는 코드째 오려붙이기할 수 있어야 한다. (2011/4/15)

또다른 예로 가동중인 기존 시스템의 유연성을 높이기 위한 고도화 사업이란 걸 하면 과연 기존 코드를 재사용할 수 있느냐 하는 것인데 이것은 코드 수준 아키텍처를 장악하고 있는 코더 유무에 의존적이다. (2011/4/15)

예를 들어 ETRI에서 무슨 과제로 개발 완료했다 하고 상용화 과제란 걸 또 하는 경우가 많은데 이 자체가 우스꽝스런 얘기지만 두 과제에서 재사용이 될지. 솔직히 사업비만 늘리는 게 아닌지. (2011/4/15)

일전에 CMU가 CS 1학년 과정에 OOP를 뺐다고 트윗했었는데 SW 재사용이란 참 어려운 부분이다. (2011/4/15)

말장난, 이해하지 못하는 현학적 단어로 논의 진전을 막는 행위. 매우 비생산적인 조직의 회의 방식. 관료 사회의 비생산성은 검증의 노력없는 현학적 허세라는 방패로 보호됨. 매우 경멸하며 성취적인 일을 함께 할 수 없는 사람들로 판단함. (2011/4/14)

SP인증 준의무화, 솔루션 업계 미래 경쟁력 잠식 우려 http://t.co/z8Rdcqc 좀 늦게 기사를 봤네요. 이 기사 하나가 실제로 정부기관에 반향을 일으킨 듯합니다. @thhwang 기자님, 좋은 기사 감사 ^^; (2011/4/12)

수요일, 5월 25, 2011

창의와 열정, Software Engineer

5월 25일 명지대 용인캠퍼스 CS 학부 졸업반을 위한 격려와 조언 성격의 강의 자료
(회식 후 뒤늦게 만드느라 새벽 4시까지 ㅠ_ㅠ)

iPad/iPhone 사용자를 위한 문서 뷰


소프트웨어 엔지니어 혹은 예비자들에게 늘 마무리 삼아 하는 말,

"우린 implementer잖아".

황당한 소설 쓰지 말라는 뜻이자 생산자의 긍지를 가지라는 뜻이기도...

토요일, 5월 14, 2011

Apple의 Hippie 정신을 유지해주는 관리 체계

애플이나 페이스북 같은 엔지니어 중심의 기업 문화에서는 직원들 모두에게 엔지니어적인 사고 방식을 요구한다.

엔지니어적이란 표현을 페이스북에서는 소프트웨어 프로그래머의 의미에 가깝게 사용하지만 이 표현의 핵심은 엔지니어의 창의적이고 분석적인 자세에 있다고 생각한다.

끊임없이 '왜' 라고 되묻는 문화이기도 하고, 평범함을 거부하는 변화 지향적인 문화이기도 하며 실질적인 가치와 성과를 중시하는 문화이기도 하다.

다만 애플은 다른 기업과 달리 의사 결정 과정에서 디자인 파트의 의견을 매우 중시한다고 알려져 왔었다. 디자인 역시 심미적 가치를 생산하는 창의적 활동이므로 엔지니어 정신에 포함하여 생각해왔다. 아침에 읽은 다음 기사에서 드러난 애플의 관리 체계를 보면 조금 다른 부분이 있다.


아침에 접한 포츈 지의 Apple 관련 기사 번역 글




www.appleforum.com
잡스가 떠나면 애플이 살아남지 못 하리라 믿는 이들은 다세포식 조직도 아마 믿지 않을 것이다. 애플이 실제로 다세포 조직일 수는 있겠지만 생명의 기반은 역시 잡스이기 때문이다. 그러나 지금으로서는 모두 의견의 영역일 따름이다. 잡스 스스로는 애플을 자기가 없을 때도 살아남을 수 있게 해 놓았다고 믿고 있다. 항상 즐겁지는 않더라도 애플의 문화를 여러 모로 만들어냈고, 자신의 방식을 내부화시켜 놓았기 때문이다. 심지어 잡스는 자신의 가르침을 모아서 적절하게 보존한 다음에, 애플의 다음 세대 지도자들이 자신의 가르침을 갖고 활용할 수 ...



엔지니어적인 관리 혹은 의사결정이라고 하면 의사 결정자는 실질적인 내용을 파악하고 있는 사람이어야 한다. 애플은 이를 직접 책임자(Directly Responsible Individual, DRI)라고 명하며 모든 중요 프로젝트에는 DRI를 명기하도록 하고 있다고 한다. DRI가 분명하다면 해당 프로젝트의 DRI에 해당하는 사람은 모든 핵심 내용을 파악하고 이에 대한 책임을 지려고 할 것이며, 최고 의사결정권자인 CEO 즉, 스티브 잡스는 DRI를 통해 해당 프로젝트의 상태를 정확하게 파악하며, 의사결정 과정에 개입할 수 있을 것이다.

대부분의 스타트업 혹은 엔지니어 중심 기업에서는 조직의 효율을 위해서 관리를 위한 관리자를 두지 않는 편이다. 실질적인 판단을 직접 할 수 있는 책임자를 요구한다. 이런 측면에서는 애플의 DRI 제도는 명시적으로 책임자를 알기 쉽게 하여 책임과 권한을 집중시켜주며 또, 원 기사에서도 지적되어 있듯이 상향식의 아이디어 캡처가 원활하게 이루어지는 효과가 있지만, 여타 실리콘 밸리의 기업들과 크게 다르진 않을 것이다.

애플의 관리 체계에서 주목한 것은 이러한 단일 책임 구조에서 디자인과 같은 전문적이면서도 하나의 프로젝트에 국한되지 않는 요소들을 어떻게 결합하느냐인데 번역 글에서는 "특화"라고 표현한 방식으로 해결하고 있었다.
(원문에서 어떤 용어를 사용했는지 궁금한데 검색해도 나오지 않는군요)

"잡스는 특화를 모든 역할에 최고로 알맞는 직원들을 배치시키는 과정으로 간주하며..."

별도의 전문 영역이라고 인정되는 디자인이나 회사의 사진 관리, 재고 관리 등의 영역에서는 프로젝트와 무관하게 총괄 책임을 가진 조직이 따로 존재하는 것이다.

DRI와 특화는 얼핏 충돌하는 개념으로 보이지만, DRI가 효율적으로 장악하기 어려운 전문 영역은 특화된 조직에서 책임을 가져감으로써 상호보완하는 형태로 보인다.

프로그래머의 시각으로 보면 전문 영역의 책임을 특화하는 것은 마치 AOP (Aspect-Oriented Programming) 기법처럼 보인다. 전체적인 프로그램의 큰 구조를 만드는 것은 OOP (Object-Oriented Programming)나 구조적 프로그래밍을 따른다고 하더라도 모듈 구조에 상관없이 반복되며, 많은 모듈에 걸쳐 침투하는 특정 영역은 별도의 aspect로 따로 관리하는 것이 효율적이라는 발상.
책임을 단순화하면서도 전문성을 타협하지 않는 책임 구조로 매우 유사하지 않은지?

구글에서도 조직이 비대해지면서 창의적이고 도전적인 기업 정신을 유지하기 위한 수많은 노력들이 있다는 것이 잘 알려져 있지만, 35년 된 애플의 기업 정신 역시 여전히 태생부터 갖고 있던 히피 정신을 아직도 유지하고 있다는 것이 놀랍다.

그러고보면 애플은 여타의 실리콘 밸리 기업들에 비해 개인에게는 자유로운 선택권이 많지 않은 편이다. 책임과 권한이 분명한 편이다. 그럼에도 제품은 여전히 Hippie적이다. 히피 정신으로 포장되어 있지만 통제되고 있다고 해야 할까?
(제품은 Hippie적이지만 조직은 철저하고 치열하다)

훌륭한 제품을 위한 프로토타입과 시연이 손익계산보다 우선시된다는 애플 문화.
기존 체계에 길들여지지 않고, 끊임없이 새로운 가치를 추구하는 도전 정신이 계속 기업 문화의 정수로 남아있길 바란다.

화요일, 4월 12, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.3.13~2011.4.12)

다시 한달이 지났네요. 일본 지진과 후쿠시마 원전 사태가 그 동안 해결되지 않고 계속 진행 중이네요. 계획했던 일정을 재조정하였습니다. 해결해야 할 문제들을 끊임없이 스스로 만들고 있는 것처럼 보이네요. 5월말에 간단한 iPhone용 mindmap 앱을 내놓을 생각입니다. 출시되면 이를 기반으로 재미있는 것들을 확산시켜나갈려구요. 
영화 'Finding Nemo'의 대사처럼 "세상이 그대를 속이거나 괴롭게 할 때에도 just keep swimming" 하시기 바랍니다. ^^;

거듭된 생각과 심화된 생각이 반복된 입력이 되면서 비동기적인 착상이라는 출력을 뇌의 비동기적이고 병렬적인 구조에서 떠오르게 만드는데 이 착상들을 catch하는 것이 창의적 추론이다. 창의적 추론은 직접적인 인과관계가 성립않는 경우가 많다. (2011/4/12)

뇌가 추론하는 두 가지 방식 중 순차적이고 논리적인 생각이 입력이 될 수밖에 없는데 이러한 생각의 반복이 비동기적이고 병렬적으로 동작하는 메커니즘에 의해 다른 착상을 유발하게 된다. (2011/4/12)

시간 압박과 긴장이 집중을 돕는 쪽으로 동작한다면 창의를 돕는다. 그 반대로 생각에 집중할 수 없게 심적 부담으로 동작한다면 창의를 막게 된다. 직접적인 인과관계가 아니라는 것이다. (2011/4/12)

여유로운 시간을 더 주는 것이 창의에 필요한 게 아니라 끊임없이 생각할 수 있도록 만들어주는 게 창의에 필요하다는 것이다. 이 환경에서 집중하여 생각하는 것은 각 개인의 능력이다. (2011/4/12)

시간 혹은 마음의 여유가 창의에 직접 역할하지 않는다는 것. 또 긴장이 창의를 가로막지 않는다는 것도 확인할 수 있다. 물론 과도한 압박은 거듭된 생각과 집중을 방해하는 환경적 제약들에 속한다. 당연히 창의를 가로막게 된다. (2011/4/12)

뇌에서 감정적 영역을 담당하는 부분은 집중을 방해하는 역할 외에 창의와 직접적인 촉진 혹은 저해 효과를 가지지 않는다고 판단한다. 엄청난 창의적이었던 사람들 이야기에서도 스스로에 대한 간단한 실험과 경험에서도 금새 확인할 수 있다. (2011/4/12)

이 거듭된 생각과 집중이란 수단을 논리적, 순차적 방식과 병렬적, 비동기적 방식이 독립적으로 동작하는 뇌 체계가 완전한 새로운 착상을 내어놓게 하는 유일한 알려진 자극이라고 판단하고 있다. (2011/4/12)

개인적으로 가진 창의에 대한 메타포를 설명해보자면.. 뇌의 미스터리한 초능력이 창의라고 한다면 그것을 결과하게 하는 메커니즘으로 거듭된 생각과 집중이 마치 뇌에 대한 입력 내지는 창의의 원인 역할을 한다고 보았는데.. (2011/4/12)

집중은 내적 메커니즘 관점에서 initiator로 봤다면 flow는 어떤 결과한 상태를 보는 것이랄까. 통계적으로 현상을 해석할 때 내적 메커니즘에 대한 발견으로 나아가지 못하면 답답하기 마련인데 flow론은 좀 그런 느낌이었다. (2011/4/12)

Flow(몰입으로 번역됨)에 관한 책을 읽었는데 이 flow와 사고의 방법으로 강조한 집중은 좀 다르다. 외부를 차단하고 뇌의 세계를 심층 탐험하는 수단으로 집중을 이야기한 데 비해 flow는 감성적 환경과의 교류 상태를 주목했다. (2011/4/12)

창의적 사고는 거듭된 생각과 집중에서 이루어진다. 수식으로 하면.. (생각^some_many)X(집중^some_many)=창의 (2011/4/12)

과감한 추진력, 그리고 현실성의 간극은 항상 존재하는 듯. 하지만 그 과정에서 1%~5%에 대한 분석과 검증 과정을 생략하면 꿈은 비전에서 꿈으로 돌아간다는 교훈. 판단하는 방법과 논리는 다르더라도 생략해선 안됨을. (2011/4/10)

상상력의 빈곤, 변화와의 동거를 거부하는 사회. 그게 관료가 지배하는 사회. 일본 얘기가 아니라 우리 얘기. 정치적인 좌파, 우파를 막론하고 식상하거나 일관되게 부패하거나. 변화를 고민하는 이는 소수이자 어떤 권력에도 배제. (2011/4/9)

영국 수상 데이빗 카메룬의 TED 연설 http://on.ted.com/9636 보수당 당수의 진보성도 놀랍지만 상상력 없고 매너리즘적이며 자족해하는 민주당과 평가하기도 싫은 현 정권의 정책에 대한 문제의식 수준과 엄청 비교된다. 다만 행동경제학의 효과는 의문 (2011/4/9)

영재교육과 경쟁은 같은 얘기가 아닌데 서열화 지상주의는 단기적인 성과에만 매달리는 우리나라의 구조화된 사회 현실을 반영하는 것 같다. (2011/4/9)

니모를 찾아서 영화 대사 중 : 삶이 그대를 속일 때 어떻게 해야 하나? Just keep swimming! (2011/4/9)

문제 배경엔 인간을 사상해버린 단순 경쟁 사고가 있지만 영재를 범인으로 교육하는 건 인류의 손실이다. 프랑스 대학에서 소르본을 없앴다는 게 달갑게 와닿지 않는다. 지식노동을 평균화하는 건 아인슈타인을 추앙하는 이들에게 사형선고와 같다. (2011/4/8)

카이스트의 교육목표를 둘러싸고 전인교육과 영재교육의 가치관이 대립한다. 영재라고 전인교육을 방기해도 안되겠지만 전인교육만 주장하는 이들에게 영재의 관점에서 전인교육을 봐주길 h부탁하고 싶다. (2011/4/8)

안드로이드 총책임자인 앤디 루빈이 허니콤이 폰용이 나오면 소스 공개하겠다고. 오픈이 오픈이 아닌.. http://t.co/CMIluDZ (2011/4/7)

개인에게 정성적으로 task를 나눠 관리하게 하고 프로젝트나 매니저는 이를 도와주는 모델이 적합할듯해서 그 정성적 기준을 어떻게 조언해둘 수 있을까 생각하는 중. (2011/4/6)

스스로 관리하게 하되 task queue 관리를 잘하라는 지침을 만들고 싶은 건데 미국에서 SE 실무하신 분이 2일 기준을 얘기해서 개인 태스크 관리와 프로젝트 태스크 관리를 고의로 혼용 (2011/4/6)

Iterative, agile 모델이라면 매 사이클별로 문맥 전환을 구분할수 있으므로 task 단위의 시간량은 2시간에서 2,3일 정도가 될듯 (2011/4/6)

Task를 내용적으로 나눈다면 생각을 이어갈수 있는 수준 즉, 심각한 컨텍스트 스위칭(현재 생각 저장 후 클리어, 새로운 일 로딩) 여부가 기준이 되면 적합할듯. 1,2시간에서 몇주까지 시간은 유동적일듯. (2011/4/6)

Task 관리를 하려면 Task granularity를 어떤 기준으로 나눠야 할까요? 어떤분은 시간 기준으로 2일을 얘기하시던데. 개발자 스스로 단위를 정한다면 가장 적절한 기준은 과연? (2011/4/6)

스마트사인이 특별한 기술이냐 여부는 할 얘기가 없지만 공인인증서 방식이 필요하냐 안하냐는 좀 다른 차원의 논의일듯. 실시간 금융거래가 많은 우리나라와 신용 방식 거래 중심의 외국의 보안 문제의 차이를 무시하기보단 분석적 접근이 필요. (2011/4/4)

창의의 유일한 동력은 집중. 그런데 즐거운 집중과 위기감 속 집중은 다른 것일까? 기분이 집중의 내용을 바꾸는가? 경험적으로 No. 오히려 도전감 없는 집중은 생각의 집중이 필요없는 일에나 가능. (2011/4/3)

SW를 문제해결로만 본다면 한계가 있다. 문제를 다루는 과정을 problem finding, problem shaping, problem solving으로 구분하면 보통 문제 형성은 해결의 일부로 진행하지만 문제 발견 과정은 간과된다. (2011/4/2)

페북이 갇힌공간이라는 것을 상업적으로 혹은 공개에 반대되는 개념으로만 받아들일 필요는 없음. 소셜네트웍이란 사람들이 모이는 까페나 사랑방 기능이 중요하니. 트윗은 페북보다는 약하지만 가능하고 검색은 구글+1에 아직 그런 개념은 없음. (2011/4/2)

페이스북이 트위터보다 평균적으로 체류 시간이 높은 건 페이스북이 갇힌 공간이라는 것을 뜻하는 것일수도. 그런 측면에서 태생적으로 체류시간은 페북>트위터>검색으로 유리. 하지만 나처럼 트윗의 정보 배달을 더 좋아하는 사람도 있으니.. (2011/4/2)

맞고 그름을 떠나 주어진 정보를 토대로 직접 생각하여 판단하는 훈련이 시민사회에 뿌리내리지 않으면 경직된 이데올로기를 쫓아 우왕좌왕하는 꼴을 계속 볼 것 같다. 좌우를 막론하고 치졸하게 이해를 쫓는 우스꽝스런 정치집단들도 계속 볼테고. (2011/4/1)

DJ 정부를 구성했던 사람들이 참여정부에서 일하기 힘들었던 이유는 무엇일까. 권위에 대한 도전은 아니었을까? 권위에 의사결정을 위임하지 않고 토론을 통해 다면 검토하는 의사결정 과정을 전문가의 권위가 견디지 못한 것은 아니었을까? (2011/4/1)

새창으로 띄우고 친절하게 와서 +1. 사람들이 그렇게까지 구글의 안위를 걱정해준다면야. 페이스북이 왜 국내 포탈처럼 랭킹을 매기지 않고 like로 단순화했는지와 비슷한 수준의 의문으로 가게 되는데. (2011/4/1)

의사결정을 커뮤니티에서 하느냐가 오픈의 수준을 결정한다고 보면 안드로이드는 자바의 오픈 수준 근처에도 이르지 못한다. 그럼에도 구글이라 오라클보다 오픈과 친한 이미지를 유지함은 대단하다. 구글이 반오픈은 아니고 안드로이드가 어정쩡한것. (2011/4/1)

근데 ETRI는 어디에 표준 제안한다는 얘긴지? w3c에? 거기서 받아줄리는 없고. 아님? (2011/4/1)

현재도 키보드 보안과 공인인증서가 매우 불편한데 공인인증서 프로그램을 띄우는 방법이 액티브X냐, url handler냐의 차이가 있을뿐. 다른 브라우저에서도 실행가능하다는 게 장점. 보안 모델은 동일. (2011/4/1)

공인인증서를 포기하지 않고 액티브X나 플러그인 사용 안하는 방법은 별도 어플로 다시 제작해 url handler로 등록해서 호출하는 방법밖에 없을 듯. 실시간 금융거래가 많은 국내 환경에서 어느 보안모델이 맞을지는 자신없음. (2011/4/1)

ETRI SmartSign이 혁신기술이냐 여부를 떠나 정부가 공인인증서를 포기하느냐 여부가 핵심일듯. 공인인증서를 계속 사용하려니 액티브X 없이 인증서 관리어플을 실행하는 방법을 이상한 url handler 등록으로 해결하려는 것 (2011/4/1)

페이스북에 Question 기능이 생겼길래 페북과 트윗 중 어느 걸 더 많이 쓰냐(시간 기준)는 질문을 올렸는데 트윗을 더 많이 쓰는 사람은 아직까지 혼자뿐. 페북 모바일 기능이 약해서 덜쓰게 되는데 다른 사람들은 어디서 쓸까 (2011/4/1)

묘하게 맥에서는 firefox 사용이 익숙치 않다. 윈도우에서도 그랬지만 폰트 크기가 다른 브라우저와 좀 달라서 밸런스가 안 맞는 심미적인 문제가 가장 크고, 사전 기능이 안되는 버그 등. 멋진 f1 버튼과 다양한 확장들 아쉬움. (2011/4/1)

구글이 웹과 서버 기술에서는 탁월하지만 소비자 부문에서는 취약하다. 우수한 엔지니어들의 UI 경시 경향 탓일지도. SW가 문제해결이라면 문제 대상 범위를 좀 넓힐 필요가 있을듯. 사용성 문제도 SW 엔지니어가 다룰 문제 (2011/4/1)

구글이 Blogger에 역동적인 새로운 뷰 기능을 추가. URL 뒤에 /view를 붙이면 볼 수 있습니다. http://t.co/AmtpxlQ 제 블로그 뷰 http://t.co/PGuXUkX (2011/4/1)

구글이 안드로이드에 대한 제어를 강화 http://t.co/Kbh2IRH 페이스북 폰 견제, 버라이즌 폰에 빙 검색엔진 탑재 견제 등 전력. 릴리스 전에는 구글 승인자만 접근하는 체계. 릴리스 후에야 오픈하는 개방형. ㅎㅎ (2011/3/31)

애플이 태양열 충전 가능한 새로운 파워 어댑터를 개발 중이라고. http://t.co/A23a3An via @PatentlyApple AC/DC 어댑터와 태양열 전지를 겸할 모양. 외부에서는 태양열 충전, 건물 안에서는 AC/DC 변환 (2011/3/31)

구글 검색의 +1 버튼. 발상의 전환이 필요하다. 기술만으로 사람을 사로잡을 순 없다. (2011/3/31)

구글 검색 +1 버튼은 사용해보니 치명적인 약점이 있다. 보통 검색 결과 링크를 클릭 이동한 후에 내용을 보고 +1 버튼을 눌러야 할텐데 이미 이동해버려 누를 수가 없다. 페이스북과는 전혀 다름. 동선을 가두는 UI라야 의미가 있을텐데 (2011/3/31)

With +1, Google Search Goes Truly Social — As Do Google Ads http://t.co/Ngv6PtO 구글의 소셜 기능 +1. 검색과 소셜 기능의 결합은 훌륭. 문제는 소셜 서클인데 페북 검색에 밀릴듯 (2011/3/31)

고슬링이 구글에서 안드로이드의 adult supervision role을 맡을 것 같다는 추측이 있군요. 예전에 고슬링이 안드로이드는 adult supervision이 필요하다고 말했었다고.. (2011/3/30)

CMU drops OOP http://t.co/5v4fUuG CMU에서 1학년 CS 과정에서 OOP를 제외. 이유는 반모듈적, 반병렬적 특성 때문이라고. imperative와 functional 언어로 대체. CMU 훗. (2011/3/30)

집중과 관조. 언뜻 극단에 위치해 보이는 두 가지가 지적 행위의 핵심 방법이다. 두 가지가 반복적으로 병행되어야 지적 창의, 지적 성취가 이루어진다. (2011/3/29)

고슬링이 구글로 join하는 걸 보니 썬의 위대한 유산들은 오라클이 샀지만 최고 인재들은 다 빠져나감을 확인하게 된다. 엔터프라이즈 시장에서 최고의 인재만 필요한 건 아니라는 뜻일까? 최고 인재는 자기 일을 할 수 있는 곳을 찾는다. (2011/3/29)

자바 언어의 아버지, 제임스 고슬링이 구글로 간다고 - CNET News http://t.co/Er1Ln89 오라클과 구글의 안드로이드 자바 소송으로 미묘한 시기인데.. (2011/3/29)

맥 OS X이 오늘로 10주년. http://t.co/A7taWdd 잡스가 돌아와 기존 OS를 맥 클래식이라 부르며 버리고 오픈소스인 BSD 기반으로 다시 만든다고 했을 때 애플이 정말 힘든가보구나 했는데 정말 현명한 선택이었던듯. (2011/3/24)

트위터와 페이스북은 공개를 통해 자정될 수 있다는 관점이라면 비밀주의는 선민들만 이해하고 대중은 우매하다는 관점인듯. 물론 일반인이 아닌 다수의 전문가들에게 오픈하고 지혜를 빌려야 할 경우도 많으나 전문가는 정치적으로 인용되기만 하는듯 (2011/3/24)

CMMi나 Spice가 복잡한 SW 즉 OS, DB, 오피스, 브라우저 그외 패키지 솔루션들, 소셜 서비스 등에서는 가치가 없습니다. 포커스가 다르기 때문이죠. (2011/3/24)

외국에서도 주로 대형 SI 프로젝트에서 인증을 요구하고 전문 솔루션 업체는 하지 않습니다. SW공학 내부에서도 논쟁거리입니다. MS, 구글, 오러클이 SI 아닌 부문에서 정형화된 프로세스 도입하지 않습니다. 정성적으로 내재화합니다. (2011/3/24)

SP인증을 현재는 협력업체가 하지는 않는데 인증 요청이 많아지면 인증기관이 추가되겠지요. GS인증을 TTA에서 다 소화못하는 것과 유사하게 됩니다.  일반적인 컨설팅 기업은 자격이 안될테구요. (2011/3/24)

지금은 인증을 요구하지 않는데 앞으로 SP인증에 가산점을 주겠다고 합니다. 형평성 때문에 CMMi 등도 가산점. 이 얘기는 2년전엔가 SP 인증 의무화 운운하다가 실행은 안되었는데 또 나온 거지요. (2011/3/24)

가뜩이나 수준이 떨어지는 국내 현실에 불필요하고 단계를 형식화하고 단계별로 산출물 즉 문서작업을 의무화하겠다는건 SW를 인력용역 정도로 보는 것과 무관치 않습니다. (2011/3/23)

SW공학이 수준높은 SW를 보장하는 게 아님은 복잡할수록 사람에 의존하는 SW의 특성에 반해 사람의 수준과 무관하게 질을 보장하려는 발상부터 오류라고 보고 있습니다. (2011/3/23)

인증 요구하면 인증 비용, 버릴 문서 작성 등에 인력만 낭비되지요. 복잡한 SW를 만드는 데 도움이 전혀 되지 않는 SW전문회사 괴롭히기입니다. 관리위주의 SI회사에나 적합하지요. (2011/3/23)

복잡성이 없고 규모가 큰 프로젝트나 매우 엄격한 안전요건이 적용되는 원자로에 사용되는 SW에는 유의미하지만 복잡성이 있는 일반 솔루션에는 공학프로세스는 적합하지 않습니다. (2011/3/23)

SW솔루션 업체들은 정형화된 형식적 규칙에 의해 구분되는 절차로 제품을 만들지 않습니다. 내재화된 개발 프로세스를 사용하지 않고 외부인의 단계별 검증을 목적으로 하는 인증을 따르게되면 형식을 지키기위한 시간과 문서작성 인력 낭비 (2011/3/23)

프로세스 인증하면 좋은 SW 나오는 줄 아느냐. 창의와 영혼이 없는 주물덩어리가 나온다. (2011/3/22)

정부 SW 구매할 때 SP인증이나 CMMi 인증 등에 가산점을 주겠다는 얘기가 또 나온다. SI 프로젝트 선정이 아닌 SW 선정에 이런 멍청한 짓거리. 제발 SW는 삽질하지 말고 공정 경쟁만 시켜라. 일 벌일 때마다 SW 영혼이 시든다. (2011/3/22)

후쿠시마에서 목숨을 걸고 싸우시는 100명의 엔지니어에게 인류의 일원으로 감사의 뜻을 전하면서 저는 이만 잠자리에 듭니다. 내일은 문제의 원자로들이 안정화되기를 기원합니다. (2011/3/17)

체르노빌과 후쿠시마 모두 긴박한 상황에서 나름 근거있는 기지로 대처. 하지만 하나의 문제를 급하게 풀다보니 부작용을 보지 못한다. 모든 경우의 수를 사고 실험으로 커버한다는 건 불가능하다. 부디 전 인류의 지혜를 모으고 신이 돌보길. (2011/3/16)

희생을 무릎쓰고 복구에 나서는 일본 국민들에게 크나큰 신뢰를 보내지만, 문제 해결의 결정권자인 일본 정치인들과 도쿄전력엔 신뢰가 없다. (2011/3/16)

일본 정치가 후진성을 못 면하는 건 그런 할복류의 개인 책임 문화 때문 아닐까? 문제를 오픈하고 도움을 요청해야지. 속으로 모든 걸 삼키는 건 좋은 게 아니다. 때를 놓쳐 인류의 과오를 또하나 만들지 말기 바란다. (2011/3/16)

일본 국민들의 침착함과 질서정연함엔 감탄하지만 원전 처리에서 보여주듯 관료와 기업은 무능하다. 아니 국민성도 문제가 있다. 연료봉 용융 못막으면 할복할 사무라이 정신으로 나서지만 비장감이 문제를 풀어주나, 덮기만 하지. (2011/3/16)

일본 원전 사고를 보면 하나의 원인에 여러개의 백업들이 함께 고장나 백업의 가치를 없애는 걸 볼 수 있다. 원전은 어떠한 재해에도 최악을 피하도록 설계해야 하는데 재해 상황을 테스트하지 않고 사고 실험만으로 백업을 검증하는 데는 한계가 있다. (2011/3/16)

그렇다면 재해 시뮬레이션 테스트를 할수 있는가? 가능한 것도 있겠지만 비용이 크고 현실 재해와는 차이가 크며 또 시나리오 몇개만으로 모든 재해를 대비하긴 어렵다. 최소 30~40년을 재해에 무릎쓰고 가동해야 할 원전 안전공학의 딜레마이다. (2011/3/16)

신을 배제하고 가치관의 기준을 생각한다면 인류의 이해가 출발점이 될수 있을 것 같다. 하지만 최근 자연과 인류의 대립을 보면 인류와 자연의 공존을 논리적 추론 결과가 아닌 또하나의 절대적 가치 기준으로 격상할 필요가 있지 않나 싶다. (2011/3/16)

과학은 특히 국내 사회과학자들에서 오류가 두드러지며 종교는 예수 제자들의 기록을 인간의 사적 필요에 따라 갖다쓰고 아랍은 교리 해석을 둘러싸고 전쟁을 불사한다. 실험적 검증도 신성과의 대화도 없이 권위만 차용한다. (2011/3/16)

인간의 능력을 과신하는 결정이 인류의 운명을 결정할 수도 있다. 검증되지 못하는 능력으로 인류의 운명을 실험 대상으로 만들면 안된다. 종교든 기술이든 철학이든 맹신자들이 인류의 적이다. (2011/3/15)

이번 강진은 일본뿐 아니라 전 인류에 대한 도전이다. 지구가 인류에게 안전한 천혜의 혹성이길 거부하는 상황에서 인류가 어떻게 지구의 불평에 대처할지 류의 수준을 보게 된다. 만약 혼돈과 파괴로 대응한다면 2012 종말 예언이 실현되겠지 (2011/3/13)

일본 지진을 바라보는 MBC와 타 언론들이 인류라는 가치를 모르는 저열한 태도로 일관하는 것은 언론을 장악한 세력의 반사회적 부도덕을 드러낸다. 기업의 사회적 책임, 복지 이슈에서 보여준 사회합의 수준에서 수십년 뒤로 후퇴한 언론. (2011/3/13)

우리나라 인재들은 단순 지식의 유무에 너무 목맨다. 인재가 생각을 하지 않고 단순 지식 암기로 자기 능력에 만족하는 국가는 퇴행한다. 조선의 세종과 집현전 학자들, 정조 때의 실학자들처럼 생각하는 인재들이 불필요하게 똑똑한 바보들에게 고립된다. (2011/3/13)

금요일, 3월 18, 2011

창의적 방법론은 무엇일까 (서평 : Software Creativity 2.0)

소프트웨어와 창의적 혁신을 화두로 꾸준히 얘기를 해나가고 있으니, 친구가 책 한권을 추천했다. 이 블로그의 태그들 중 가장 많은 게 Software와 Creativity인데 이 책을 한번 읽어보는 게 어떻겠냐고.

번역서가 있어서 도서관에서 대출받을 수가 있었다.

YES24 : 소프트웨어 크리에이티비티 2.0


책을 읽어나가면서 주장하는 내용 즉, 실천적인 결론에서 많은 부분이 닮아있음을 보았다.
소프트웨어를 지적 노동으로 바라보고 이에 따라 창의성을 중시하는 문제 해결 방법을 따라야 한다는 것이 기본 주장이란 점에서 반가운 마음이 앞섰다.

얘기를 풀어가는 방식은 조금 달랐는데 개인적으로 논리적인 전개를 통한 증명을 선호하는 데 비해, 이 책의 저자인 Robert L. Glass는 일화 형태로 사례를 들어 주장하는 방식을 사용했다.
실천적 주장은 비슷하지만, 결론에 도달하는 방식은 매우 다르다고 할까.
개인적으로는 사람의 두뇌의 특성과 지적 사고 방법 등 내적 논리를 만들려고 노력하고 이에 따라 결론을 유도하는 연역적 전개를 선호하는데 Glass 씨의 책은 경험적이고 사례적인 근거에 따라 결론을 유도하는 귀납적 논리 전개를 사용한다.

개인적으로는 주장이란 bottom-up을 통해 구성한 지식 체계를 top-down으로 설명할 수 있어야 좋은 주장이라고 생각한다. 물론 지식 전달의 관점에서는 논리적인 top-down 전개가 더 낫다, 일화를 통한 스토리텔링 방식이 더 낫다는 편견을 가진 건 아니다.
(딱딱한 논리적 전개의 정합성을 많이 의식하기 때문에 이 블로그들 중 상당수가 일반 독자들이 읽기에 재미가 없다는 지적도 많다. 일화 중심으로 가벼운 블로그들의 pageview가 높은 것이 어떻게 보면 당연하다. 좀더 가볍게 블로그를 쓰고 싶으나, 아직 논리적인 탐구들이 단언할 수준의 결론으로 이르지 않은 부분이 많아서 논리적 재구성을 고심하여 쓰다보니 논지들이 설익고 딱딱하다.)

Glass 씨는 딱히 결론을 내리지는 않고 있다. 오랜 소프트웨어 경험에서 나온 직관적 판단과 소프트웨어공학 쪽의 이론 흐름 등을 대비하면서 창의적이고 지적 노동이 소프트웨어 성공의 핵심 요소라는 심증을 사례를 통해 증명하려고 노력한다.
창의성이 중요하다는 것은 여러 가지 사례를 통해 입증하려 했지만, 어떻게 해야 한다는 방향까지 주지는 못했다는 점은 아쉽다.

책의 논점들 중 몇 가지 재미있는 논쟁점들을 뽑아 개인적인 생각을 적어본다.

  1. 소프트웨어가 지식 노동이냐 사무적 노동(단순 노동?)이냐
  2. 소프트웨어에 있어 사람의 우수성이 중요하냐 프로세스가 중요하냐
  3. 응용수학과 이론수학, 그리고 전산학, 소프트웨어공학의 관계. 전산학이 너무 이론수학에 경도되어 발전이 더딘 것은 아닌가?
  4. 소프트웨어 공학이 적합한지 실무적인 개발 프로세스가 적합한지
  5. 창의성을 위한 프로세스를 정의할 수 있는가?

1항, 2항은 연결된 질문이다. 지식 노동적 성격이 강할수록 사람의 우수성에 의존하게 된다. 예를 들어 CASE 툴이나 4GL 툴들이 지식 노동적 성격을 최소화하고 단순 사무적 노동으로 만들 수 있다면 분명 프로세스가 더 중요해진다.
하지만, 대부분의 소프트웨어는 그렇게 단순하지 않다. 코드가 매우 단순해지고 복잡성이 없는 영역에서는 사무적 성격이 강해진다.
개인적으로는 어디에서나 CASE툴, 4GL, 프레임웍 등 다양한 툴들이 등장하지만 점점 더 사람의 창의와 지적 노동이 필요한 영역이 늘어난다고 본다. 단순 작업을 줄이기 위해 프로그래밍 언어와 툴들이 발전하고 있을뿐이며 아직 업무 설계를 지적 코딩 없이 소프트웨어로 변환해주는 툴들은 만족하기 어려우며, 그러한 툴들은 업무의 변화에 따른 구조적 변화를 쫓아가기 어렵다고 본다. 물론 그것이 가능하다는 과대광고는 많았었고, 계속될 것이다.
즉, 단순 노동과 지적 노동의 비율이 항상 긴장 관계를 유지하고 있지만, 핵심 영역에서는 지적 노동을 없앨 수 없다는 것이다.

3항은 수학과 전산학의 관계에 대해서 문제제기를 하면서 학계는 너무 수학적 정형주의 틀에 전산학을 맞추려는 경향이 있다고 지적한다. 현재 전산학의 많은 부분에서 수학이 사용되고 기반이 되는 것은 분명하다. 다만 소프트웨어를 정형화된 수학 모델에 의해 프로세스화하고 관리할 수 있다고 보는 경향에 대한 우려라고 생각하면 될 것 같다.

4항은 소프트웨어공학을 배척한다기보다는 그 방향에 대해 좀더 목적을 분명히 할 필요가 있다는 점을 지적한다. 좋은 소프트웨어 제품을 만드는 것이 목적인지 프로세스를 잘 지키는 것이 목적인지 가치를 전도시키는 일부 경향에 대한 비판이다.
프로세스가 필요없다고 생각하진 않지만 항상 목적과 결부하여 도입할 필요가 있다. 프로세스를 완벽하게 준수한다고 대단한 소프트웨어 제품이 나오는 것이 아니라면 프로세스는 한계가 큰 것이다.

마지막 5항은 소프트웨어공학의 프로세스들이 오히려 소프트웨어 엔지니어의 재미를 줄인다는 지적과 관련이 있다. 창의적인 문제 해결에 가장 많은 재미가 있는데 이 과정을 정형적으로 관리한다는 것은 맞지 않다는 것이다.
블로그에서 소수로 프로젝트를 하고, 정성적으로 퍼포먼스를 평가해야 한다는 주장을 여러 번 했었는데 Glass 역시 같은 맥락의 주장을 한다. (정성적 평가는 공학자들이 아주 꺼리는 경향이 있다.)
소프트웨어의 창의는 지적 수준이 받쳐줘야 한다는 점도 지적한다. 설계와 개발 단계에서는 논리적 검증이 필요한 영역이라 단순 아이디어가 바로 창의로 이어지기 어렵다는 점이다.

책 내용 중에 일반적인 창의 프로세스를 소프트웨어에도 적용하려는 시도에 대한 언급이 있다. 생각들을 공유하고 심화하는 것은 매우 중요한 과정임이 분명하다. 이 절차들이 의미가 있을지 생각해보자.
원 실험은 Creativity and Innovation in Information Systems Organizations (J Daniel Couger, 1996)이라고 한다.

  • 유추/은유(Analogy/Metaphor)
  • 브레인스토밍(Brainstorming)
  • 파란 쪽지(Blue Slip)
  • 추정(Extrapolation)
  • 점진적 추상화(Progressive Abstraction)
  • 6하원칙(5W1H)
  • 力場분석(Force Field Analysis)
  • 평화로운 환경(Peaceful Setting)
  • 문제 반전(Problem Reversal)
  • 연관/이미지(Association/Images)
  • 소망적 사고(Wishful Thinking)

창의를 위해 정형화된 프로세스적인 뒷받침이 창의적인 조직에 꼭 있어야 하는 것은 아니라고 생각한다. 다만 이러한 창의를 돕는 기교들이 자연스럽게 개인의 창의적인 생각방식과 조직의 회의 방식에 일상적으로 녹아있을 필요가 있다.

토요일, 3월 12, 2011

소프트웨어 개발, 집중력이 변화의 출발점

문제 해결에서는 집중 혹은 몰입이 유일한 정성적 방법
초등학생인 딸애와 수학 공부를 가끔씩 같이 하는데, 수학을 잘하기 위해 필요한 것으로 타고난 두뇌도 중요하지만 집중력과 끈기가 훨씬 중요하다고 얘기하곤 합니다.

단순 계산을 하는 것이 아니라 빠르게 문제 해결의 실마리를 머리 속에서 끄집어내야 하는 상황에서 먼저 끈기 있게 문제에 도전하는 자세가 가장 먼저이고, 다른 잡념 없이 문제에 몰입하는 게 두번째입니다.
사람의 뇌가 좌뇌와 우뇌로 나뉘어져있고 그 역할이 상당히 다르다는 것은 잘 알려져 있는데 계산을 빠르게 하고 논리성에 따라 추론하는 것은 주로 좌뇌에서 이루어집니다.
하지만, 사전 암시 없이 문제 해결의 실마리를 머리 속에서 떠올리는 역할은 좌뇌만으로 이루어질 수 없으며, 우뇌 혹은 좌뇌와 우뇌의 협력을 통해 이루어집니다.
집중 혹은 몰입은 이러한 뇌의 활동을 최대한으로 활성화시킬 수 있는, 사람에게 알려진 거의 유일한 방법입니다.

소프트웨어 개발자들도 수많은 문제들의 해결을 요구받습니다.
쉬운 문제도 있고, 복잡한 문제도 있지만 단순 개발자가 아니라면 가장 중요한 것은 집중할 수 있는 능력입니다. 집중을 돕는 방법은 별로 없습니다. 스스로 집중하는 수밖에 없습니다. 주변 환경의 개입을 최소화하고 스스로를 몰입할 수 있도록 훈련하는 수밖에 없습니다.
개발할 때 음악을 듣거나 하는 경우가 있는데 음악을 들으면 몰입이 되지 않습니다. 뇌가 음악에 방해를 받게 됩니다.
다만 음악이나 명상은 집중하기 힘들 때 뇌의 휴식을 줄 때 도움이 될 수 있습니다.
집중하기 어려우면 뇌가 완전히 쉴 수 있도록 고요한 명상이나 클래식 음악을 활용하고 생각을 멈추는 시간을 가지면 도움이 됩니다.

하지만, 일단 개발을 시작하면 집중을 하도록 해보십시오. 익혀진 패턴을 반복하는 개발이 아니라 상황을 모두 제어, 지배하는 집중하는 개발로 변화하면 개발자의 능력도 향상되고, 결과 퍼포먼스와 퀄리티 또한 향상되게 됩니다.

집중과 끈기, 그리고 자신에 대한 신뢰가 큰 변화를 가져옵니다.

경험에 비추어보면 패턴의 단순 반복이 많을수록 흥미를 잃어버리고, 집중할 수 없게 됩니다. 동일한 문제라 하더라도 새로운 방법을 시도할수록 집중도가 회복됩니다. 항상 더 나은 방식, 새로운 방식을 고민하는 것이 개발자 자신의 흥미를 위해서도 중요합니다.

설계와 의사결정에서는 여러 지식들을 기반으로 통찰력을 발휘하고, 적절한 메타포를 사용하여 체계를 구축하는 것이 중요합니다. 이러한 과정 속에서 기존 체계를 도전적으로 재해석하고 새로운 체계를 만들며 차별적인 창의를 추구할 수 있습니다.

SW 개발자의 집중, 높은 수준의 소프트웨어를 가능하게 하는 원천적인 방법
일전에 페이스북이나 구글은 개발자들에게 훨씬 더 많은 책임을 요구한다는 것을 블로그에 올린 적이 있습니다.

극단적이긴 했지만, 한 페이스북 개발자는 탁월한 개발자는 코딩 과정에서 무결한 코드를 작성할 수 있다는 믿음을 갖고 있기도 했습니다.
이 말 자체는 적어도 사실이 아닙니다. 사람은 모든 경우의 수를 머릿속의 사고 실험을 통해 다 테스트할 수 있지 않습니다. 반드시 실제 테스트를 거쳐서 검증해야 할 필요가 있습니다.

하지만, 집중을 통해 사고 실험을 최대한으로 거치는 코드와 패턴에 따라 관성적으로 만들어진 코드는 퀄리티와 에러율을 비교할 수가 없습니다.

창의에 대한 도전, 자신에 대한 신뢰는 도전적인 개발자의 발전을 뒷받침하는 또다른 무기이자, 보호 갑옷과 같습니다.

얼마전 멀티태스킹을 죽여야 한다는 글을 읽은 적이 있습니다.


the99percent.com
What's the key to better productivity? According to an informal poll of the 99% audience, it's all about destroying the multi-tasking myth.


크게 세 가지를 얘기하고 있었습니다.

1. 시간 관리를 공격적으로 하라.
2. 창의를 고민하거나, 깊은 사색을 할 때에는 모든 것을 끊어버려라.
3. 디지털과 아날로그 중 더 적합한 것을 선택하라.

사람의 뇌는 논리적인 일을 할 때에는 멀티태스킹을 할 수 없다고 합니다. 논리적인 추론을 담당하는 부분이 좌뇌인데 좌뇌는 순차적인 방식으로 실행이 되기 때문입니다. 비동기적이고 비정형적이며 멀티태스킹이 되는 부분은 우리가 논리적으로 제어 가능하지 않은 영역인 우뇌입니다.
우뇌가 주로 창의를 담당하긴 하지만, 언제 그 결과를 던져주는지에 대해서는 기대하기가 어렵습니다. 자신을 믿고 반복적으로 질문을 던져놓고 되씹으면 어느 순간 여러 가지 답들이 비동기적으로 떠오르거나, 비슷하지만 다른 답들이 떠오르게 됩니다. 아마도 우뇌의 동작 방식은 유사 패턴 검색에 가깝지 않을까 생각됩니다.

논리적으로 제어하는 목표 때문에 멀티태스킹을 하는 것은 매우 비효율적입니다. 하나의 생각, 하나의 문맥에서 집중해야 순차적인 논리 추론이든, 창의적인 아이디어든 해법이 나오게 됩니다.
멀티태스킹을 해야 하는 상황은 시간을 나눠서 문맥 전환하여 집중해야 합니다. 한번 집중에서 빠져나오면 다시 집중하는 데에는 많은 시간이 걸립니다.
이것은 개발자들의 업무 효율에 매우 중요한 이슈입니다.

자신의 업무를 단순 반복 업무로 비하하지 말고, 애정을 가지고 더 나은 것으로 발전시키고 확대시키기 바랍니다. 그 출발점은 집중의 향상입니다.

기존 역할이 도저히 스스로에게 동기부여하기 어렵다면, 하는 일을 바꾸고 과감히 도전하시길.

개인적으로는 하기 싫은 일을 억지로 하지 않는 것이 오랜 신조였습니다. 대신 하고 싶은 일의 범위를 매우 넓히려 했습니다. 소프트웨어 개발 관련된 일들은 코딩부터 고객 만나기, 디버깅하느라 고객사에서 몇주일째 밤새는 일도 다 즐거운 일의 범위였습니다.
하지만 아쉬운 점은 너무 무리한 일정에 밀리게 되면 집중력이 약화되고, 관성화되는 경향이 생기는 것도 사실이었습니다.
개발자 스스로 관리하고, 성과에 대해서는 엄격하게 정성적으로 평가받는 체계를 만들지 않으면 단순 반복적인 개발 외에는 성공할 수가 없습니다.

국내 소프트웨어 개발자들에게 집중이란 화두를 던져봅니다. 무모한 페이스북 개발자의 약간 잘못된 신념처럼 무결하고, 최고의 코드를 만들 수 있다는 자신감이 필요합니다. 그에 가까이 가는 방법은 최고의 집중에서 시작합니다.

금요일, 3월 11, 2011

소셜, 모바일, 창의, 혁신 관련 중심으로 지난 Tweet들 정리 (2011.2.19~2011.3.11)

3월도 벌써 중순으로 접어들었네요. iPad2가 발표되고, 소셜커머스가 지역기반 온라인커머스가 되는 것 같네요. 
작은 사업 아이디어들을 몇 개 적어두었는데 한달에 한개씩만 생각해도 1년이면 12개 사업 아이템이 되는군요. 올해는 그만 생각할까봅니다. ㅠ_ㅠ; 올해는 첫 시도로 마인드맵 앱, 그리고 구상중인 또다른 한 가지 서비스. 두 가지를 런칭해서 현실에 부대껴볼 생각입니다.


국내 SW 현실이 일당 받는 용역거리로만 간주되는 열악한 인식 수준 때문인데 뭐 집에 컴퓨터가 부팅안된다고 전화주시는 친척분들도 여럿 계시는데 ㅠㅠ (2011/3/11)

개발자라고 하면 이것 좀 개발해줘 하는 사람들이 꽤 있다. 개발자가 똑같지라며 용역을 팔지 않는다는 걸 이해못하는 분들. 피카소나 고흐에게 극장 간판 그려줘라고 할 사람들.. (2011/3/11)

애플이 맥용 페이스타임 정식버전 0.99$, xcode4 정식버전 4.99$. 맥앱스토어 만든 후부터는 맥버전 어플들도 박리다매 전략에 들어간듯. 가까운 시장 생겼으니 얼마라도 내고 써라? 맥앱스토어와 iOS 지배력이 유료화 계기일듯 (2011/3/10)

용어를 고유명사화하는 건 개념적 논의를 회피하는 주요 방법이다. 고유명사는 역사적 특수성에서 만들어진 이름이다. 그 역사를 언급하기만 하면 권위를 보장할 수 있다. 하지만 그 용어는 본래의 말뜻으로 사용될 수는 없다. 동적 프로그래밍처럼. (2011/3/9)

교체 가능하지 않은 직원. 추천받은 책을 펼치니 기업 관리에서 가장 쟁점이 되는 것은 이것이란다. 테일러주의에서는 해고 대상이고 창의적 기업에서는 한 사람 한 사람의 특성이 기업의 미래를 좌우한다. (2011/3/9)

능력에 맞게 조금 늦게 시작하고 열정으로 쫓아가면 된다. 꼭 경쟁과 생존보다 즐길 수 있는 한판을 벌여보자. slow-starter지만 steady-player가 되자. (2011/3/9)

난 아직도 slow-starter이다. 빠르게 빌드하는 머리좋은 코더들이 부럽다. 데니스 크라울리도 이건희도 빨리 빌드해라 시간없다고 재촉한다. 하지만, 오늘 내 판단이 내일 또 달라질 걸 안다. 두 단계로 심화된 감이 올때까지 기다린다. (2011/3/9)

skating to where the puck is going to be, not where it has been. - Wayne Gretzky 잡스가 생각하는 마케팅의 원칙이기도. (2011/3/9)

It’s not just what it looks and feels like. Design is how it works. 스티브 잡스가 디자인을 핵심으로 보는 이유. (2011/3/9)

안티 맥UI. 1996년에 작성된 글. UI 원칙 이해하는 데 도움이 될듯.  http://t.co/rgweqZV (2011/3/8)
포스퀘어 창업자 데니스 크라울리: Stop Sketching, Start Building http://t.co/g6yI5eT 크라울리는 구글에 Dodgeball 서비스 매각 후 구글 직원이었다가 아이디어를 살리려고 다시 창업 (2011/3/6)

스윙을 애플 출신들이 협업하여 만들지 않았었나? 애플>넷스케이프IFC>자바JFC. 툴과 언어, 프레임웍 3박자가 맞아야 하는데 프레임웍만으로는 어려웠을듯. 자바에 애노테이션이 추가된 건 JDK 1.5부터이고 IDE 툴은 클라이언트 UI용이 아님. (2011/3/4)

애플의 코코아 프레임웍과 xcode IDE는 확실히 MVC 아키텍처의 툴 요소와 언어 요소를 잘 구현했다. MS의 MFC/VC나 자바 스윙보다 많이 진화한 체계. (2011/3/4)

Technology alone is not enough. Technology married with liberal arts, humanities, yields the result that makes our hearts sing. 어제 잡스의 결어 (2011/3/4)

잡스가 애플의 DNA는 기술과 인문학의 교차점에서 포스트 PC 시대에 맞는 제품을 만든다고 하며 휴머니티를 언급한 건 사뭇 감동적이다. 가치의 근본 척도인 사람을 보라는 것은 경쟁사들과 현 인류에게 주는 잡스의 인생 충고 같았다. (2011/3/3)

iBooks용 책들이 국내에는 많이 보이지 않는데 미국에서는 여러 가지 책 유통채널과 협약을 맺어 상당수가 iBookstore에 올라온듯. 미국 내 가장 큰 북셀러인 랜덤하우스도 3월부터 올라온다니 컨텐츠 유통사를 사로잡는 잡스의 협상력이란! (2011/3/3)

아이패드2에 자이로스코프가 들어가서 의아했는데 개라지밴드에서 피아노 건반 타이핑의 세기를 느끼는 데 활용한다니 놀라움. 아이패드의 핵심소프트웨어는 오피스가 아니라 iMovie, Garageband인듯. (2011/3/3)

오캄의 면도날은 단순한 게 진리라는 식으로 종종 오용된다. 간결하게 설명되는 게 보통 참인 경우가 많다 정도. 진위보다는 동일한 값이면 단순한 것이 낫다 정도로 선호를 표현하는 게 적합. SW의 단순성 원칙에도 오캄의 면도날이 종종 인용된다. (2011/3/2)

1. 시간 관리를 공격적으로 2. 깊이 생각할 때에는 모든 것을 꺼버려라. 3. 디지털과 아날로그 중 선택하라. (2011/3/1)

HBR 관리 팁 Risk-taking하는 3가지 방법.
1. risk-taking하는지를 측정하라.
2. 아이디어 공유가 부담없는 환경을 만들라.
3. 짧은 사이클의 실험을 수행하라. http://t.co/ST1R8eH (2011/2/28)

티맥스의 쇠퇴에는 risk taking만 하고 분석과 단계적 확대없이 바로 올인하는 도박 전략에 가장 큰 원인이 있지만, 시장 선점자를 따라하고 저가 전략에 기대는 고급 기술 팔로워 전략도 문제. 독창적으로 재해석한 개념체계 없인 한계. (2011/2/26)

메타포(은유)는 원 개념을 다면적으로 이해하고 직관적을 받아들일 수 있게 도와주는 지적 추상화의 핵심 사유법. (2011/2/24)

스티브 잡스가 비유를 적절하게 활용했다는 것은 메타포를 사용한 사유 방법의 전문가임을 보여줌. 정확한 메타포는 생생한 이해를 도울뿐아니라 메타포 대상의 다양한 특질을 원 개념에 재적용케 하여 창조를 유도. (2011/2/24)

아이폰4 iBooks의 장점은 한손으로 책을 읽기 편하다는 점. 초고해상도에다가 글자도 작지 않고 엄지 터치로 부드럽게 동작. 첨엔 랜스케이프로 눕혀 읽을 것 같았지만 세워 읽는 게 아이폰에 적합. 아이패드와도 다른 글읽기 환경. (2011/2/20)

아이폰 iBooks로 애플 개발 관련 책 읽고 있는데 꽤 괜찮음. 결국 출판도 1인 출판이 강화되고 출판사는 게임 퍼블리싱 회사처럼 기획 유통이나 허브 역할로 변모하지 않을까. 앱 쏟아지듯 출판도 생태계 만들어질듯. (2011/2/20)

토요일, 3월 05, 2011

Minecraft 게임에서 보는 집단 지성(Collective Intelligence)

집단 지성을 동력으로 하는 혁신
혁신은 여러 가지 형태로 나타날 수 있는데 이들 중 사람의 창의를 동력으로 하는 창의적 혁신과 그룹 혹은 불특정한 인류의 협업적 지성을 동력으로 하는 집단적 혁신(Collective Innovation)이 최근 두드러지는 혁신의 형태들입니다.
집단적 혁신은 일정 수준의 개방과 공유를 필요로 한다는 점에서 열린 혁신 혹은 개방형 혁신(Open Innovation)과 상당 부분 겹치게 됩니다.
소프트웨어 관련 혁신을 두고 공개(Openness)의 의미에 대해서는 몇 번 블로그를 통해 분석을 시도한 적이 있습니다.


Minecraft 게임의 인기
Minecraft 게임은 스웨덴의 한 게임 개발자가 2009년 5월에 일주일만에 개발하여 대중에 공개한 게임으로, 계속해서 수정과 패치를 거듭하는 알파 버전이었다가 2010년말에 베타 버전이 릴리스된 일종의 3차원 빌딩 블록 게임이라고 볼 수 있습니다.
3월 5일 현재 496만명이 가입하고 149만명이 구매한 것으로 집계되고 있을 정도로 매우 인기 있는 게임입니다.

Minecraft 소개 동영상

Minecraft가 새삼 주목을 받게 된 것은 이 게임은 참여자가 직접 게임 툴을 사용하여 레고 블럭을 쌓듯이 다양한 창조물을 만들 수가 있다는 점인데 광물을 채집하는 다양한 형태의 광산 뿐아니라, 호수 위에 떠있는 태양계 행성들, 피라미드, 인기 TV 시리즈인 스타트렉에 나오는 우주 모함, 심지어 8비트 CPU 에뮬레이터 등 실제 게임보다 게임 사용자들의 기발한 창조물들이 끊임없이 쏟아져나왔다는 데 있습니다.
게임은 최소한의 규칙과 창조를 위한 툴을 제공하고, 게임 플레이어들이 새로운 우주를 그 안에서 만들어내는 형태인 셈입니다. 현재는 단순한 빌딩 모드 외에 밤에는 괴물들이 나오고, 다양한 해로운 건축물들이 숨어있는 생존 게임 모드를 지원합니다. (게임을 직접 해보지는 않아서 정확하진 않습니다. 게임의 빌딩 블록들이 아주 단순한 레고 블록들은 아닙니다. 간단한 전기회로나 논리 게이트 같은 것들이 포함되어 지능을 가질 수 있습니다.)
이 게임의 또하나 주목할만한 점은 홍보 등 마케팅 수단이 게임 참여자들의 구전과 자신이 만든 게임 내 창조물을 올린 유튜브, 그리고 이를 알린 소셜네트웍 등 철저히 참여자들의 자발성에 의한 것이었다는 점입니다. 즉, 입소문이 인터넷과 소셜네트웍을 통해 전파되어 급속하게 확산된 모델입니다.

Minecraft는 몇일 전에 발표된 2011 IGF(Independent Game Festival) 경쟁 부문에서 그랑프리를 수상하였습니다.

집단 지성 관점에서 본 Minecraft 게임

개인적으로 Minecraft에 관심을 갖는 것은 위키피디아 외에 뚜렷하게 혁신의 성과를 보여주지 않은 불특정 다수가 구성하는 집단 지성의 혁신이 게임 영역에서 나타났기 때문입니다.
참여와 나눔을 통하여 인간이 마음의 평화와 위안을 얻는 것은 인간의 본성이라고 볼수 있는데 위키피디아의 추동력은 바로 나눔의 인간 본성이라고 생각합니다. 반면 Minecraft는 나눔보다는 창조 자체에 대한 본성과 게임적인 유인들이 결합했다고 보는 게 정확하지 않나 싶습니다.

보통 회사나 조직 내부 인력들의 집단적 창의와는 대응되는 개념으로 집단 지성을 얘기하는데, 집단 지성은 집단의 구성 방식에 따라 점점 인류의 공공재화되어가는 인터넷을 통한 집단 지성, 소셜 네트웍을 통한 집단 지성, 전통적인 그룹의 집단 지성 등으로 형태를 세분할 수 있습니다.

집단 지성을 활용한 업무 형태를 흔히 크라우드소싱(crowdsourcing)이라고 부르는데, 개방형 혁신(Open Innovation)에서 흔히 볼 수 있는 업무 형태입니다.

Minecraft에서 창조된 건축물, 조형물들은 인터넷 집단 지성의 결과라고 볼 수 있는데 이 결과물들이 다시 게임 속에서 다른 참여자들과 공유할 수 있다면 좀더 완전한 개방형 혁신이라고 볼 수 있을 것 같습니다. 현재는 Minecraft는 통합 서버가 없고 클라이언트나 특정 서버 ip에 접속해서 잘 알려진 그룹들끼리만 공유가 가능한 형태입니다. 추후 Minecraft가 클라우드 기반의 단일 서비스 형태로 발전해갈 것으로 예상합니다.
게임 참여자들의 결과물이 다시 게임의 요소가 되면 이상적인 집단 지성으로 볼 수 있겠지만, Minecraft 역시 플랫폼을 제공하고 플랫폼을 자유롭게 활용하여 새로운 계층(layer)을 만들 수 있게 한다는 점에서는 다른 개방형 혁신의 부분 레이어 개방 방식과 유사합니다.
하지만, 참여자들의 결과물 즉, 다양한 건축물들이 현 시점에서는 재사용되거나 하지는 않으므로 집단 지성에 기반한 혁신은 적합한 표현이나 개방형 혁신이라 부르는 것은 무리일 것 같습니다.

다만, 게임 사용자들이 창의를 발휘할 수 있는 플랫폼을 제공하고 게임 사용자들은 자신만의 창조물을 만들어 공유할 수 있는 형태의 게임이라는 점에서 집단 지성을 활용하는 비즈니스 전략의 성공 사례로 주목할 필요가 있습니다.


Minecraft에서 나타난 집단의 창의를 크라우드소싱하자
앞에서도 지적했듯이 Minecraft는 사람들의 창조에 대한 욕구와 게임적 요소를 동시에 자극하는 특성을 가진 게임입니다.
창조할 수 있는 재료와 도구를 주고, 그 창조물을 공유할 수 있는 공간을 만들어주면 사람들은 다양한 것을 만들 수 있다는 가능성을 보여줍니다. Minecraft가 게임이긴 하지만 게임 요소를 유인으로 하는 다른 형태의 비즈니스에도 이러한 창의에 대한 소싱은 사람들을 자발적으로 참여하게 할 것입니다.
다른 기술, 다른 서비스, 다른 게임 영역에서도 사람의 창조와 공유에 대한 욕구를 집단 창의의 유인으로 사용할 여지가 충분하다고 보여집니다.


P.S. 창의적 혁신과 집단적 창의
Minecraft 게임 사례를 보면서 집단 지성에 기반한 혁신을 언급했습니다. 개인적으로 화두로 갖고 있는 창의적 혁신과는 조금 다른 부분이라고 볼 수 있는데, 마음 속에 품고 있는 의문을 꺼내봅니다.

집단 지성의 창의와 일반적인 기업이나 조직의 창의의 관계는 어떠할까요?
어느 것이 더 특정 문제 해결에 효율적이며 더 나은 결과를 만들어줄까요?

이 문맥에서 얘기하는 집단적 창의는 기업이나 조직 외부의 창의를 뜻합니다. 일반적으로 내부의 창의는 전문성과 경험, 팀웍, 창의를 북돋우는 문화 그리고 개개인의 창의에 의존합니다.
창의적인 문제해결에 영향을 주는 요소들을 몇 가지 짚어봅니다.

(1) 전문성
중요한 의사 결정에 관여된 지식의 전문가가 필요하며 매우 결정적인 역할을 하게 됩니다.
전문성을 크라우드소싱할수 있느냐 여부가 집단적 창의를 만드는 데 중요한 전제 조건이 됩니다. 글로벌의 전문가들을 모두 활용할 수 있다는 가정이 내부 소싱(in-sourcing)보다 크라우드소싱의 우수성을 강조하는 데 종종 사용됩니다.
보통 개방형 혁신을 강조하는 중요 전제 중의 하나가 전문성의 글로벌소싱 가능성입니다. 개방형 혁신과 집단 지성이 Minecraft 사례에서 보듯이 동일한 것으로 볼 수는 없지만, 집단 지성이 개방형 혁신의 핵심 추동력이 됩니다.
위키피디아와 같은 형태이든, 오픈소싱을 통한 공유 형태이든 이 부분에 대해서는 현실적인 판단이 필요합니다.
고무적인 것은 교육 부문에서는 전문가들의 자발적인 참여가 적극적으로 확산되고 있다는 점입니다. 하지만 보호되는 지적재산을 둘러싼 영역에서는 각 기업의 이해에 의존하는 측면이 강합니다.
완벽하진 않지만 점차 개방, 공유되는 지적 영역들이 늘어나고 글로벌 영역에서 핵심 소프트웨어의 많은 부분들이 소스 수준이나 API 수준에서 개방되어 전면적으로 혹은 제한적으로 사용 가능하게 되는 현상은 매우 고무적입니다.

전문성은 내부 소싱이든 크라우드소싱이든 확보해야 할 전제가 됩니다. 다만, 비즈니스의 경우 내부 소싱할 전문성이 부족해서 크라우드소싱에 의존할 때에는 그 분야가 비즈니스의 핵심 차별 영역이면 비즈니스를 운용하기 어려울 것입니다.

각 도메인 별로 크라우드소싱의 현황을 분석하고 새로 크라우드소싱을 구축하고자 한다면 유인들을 잘 준비해야 합니다. 위키피디아의 사례에서 보듯이 필요하다면 정부나 공익 기구, 대학 등 다양한 채널을 활용할 필요가 있습니다.

(2) 브레인스토밍과 문제 심화
창의를 개인의 수준에 전적으로 의존하는 게 아니라면 참여 구성원들의 아이디어들을 심화하고 문제를 재설정하는 과정이 매우 중요합니다.
브레인스토밍의 경우에는 내부 소싱, 크라우드소싱에 따른 직접적인 문제는 아니지만 지역적인 인접성과 동시성이 중요합니다. 같은 장소, 같은 시간에서 팀웍을 갖추어 진행할 필요가 있습니다.
비디오 컨퍼런스 등 여러 가지 툴들이 좋아지고 있지만, 아직 같은 장소에 모여서 서로를 느끼면서 진행하는 것만큼 깊이 있게 아이디어를 공유하고 또 토론을 통해 발전시킬 수 있는 방법은 없는 것 같습니다.
크라우드소싱 역시 이러한 부분을 보완하기 위한 face-to-face 협의 등을 진행할 수 있습니다.
하지만, 역시 한계는 크다고 생각됩니다.
크라우드소싱은 팀웍으로 뒷받침된 내부 소싱에 비해 개인의 창의에 의존하고 아이디어의 상호 침투가 상대적으로 느리게 진행됩니다. 

(3) 의사 결정
심화발전된 창의는 의사 결정을 통해 실천되어야 합니다.
크라우드소싱의 경우 중요 의사 결정이 상대적으로 느리게 진행되는 경향이 있습니다. 이를 보완하기 위해 크라우드소싱의 경우에도 운영위나 코디네이터를 설치하여 의사 결정을 진행하는 경우도 많이 있습니다.
내부 소싱이든 크라우드소싱이든 의사 결정 단계에서 전문가들이 참여하여야 합니다.

내부 소싱과 크라우드소싱은 장단점이 분명히 있습니다.
크라우드소싱이 글로벌 단위에서 소싱이 이루어진다고 해서 내부 소싱보다 더 나은 전문가의 적극적 참여를 확보할 수 있다는 생각은 지극히 낮은 확률의 가능성일 뿐입니다.
내부 소싱은 효율적인 창의적 아이디어의 조탁 측면에서 분명히 유리한 부분이 있습니다. 그렇다고 크라우드소싱의 창의적 영역이 완전히 다른 것은 아닙니다.

스스로의 질문에 대한 답은 이 정도 수준에서 보류하고 더 탐구해나가야 할 것 같습니다.

크라우드소싱은 자발적인 참여를 이끌어내는 유인이 매우 중요합니다. 끊임없는 창의를 크라우드소싱하여 혁신을 만들 수 있느냐는 판단하기 쉽지 않습니다.

비즈니스를 고민하는 사람이라면 크라우드소싱할 부분은 그 유인에 포커스를 두고, 내부 소싱할 부분은 핵심 영역의 전문성과 창의적 문화를 갖추는 데 포커스를 둘 필요가 있습니다.
무엇보다 크라우드소싱과 내부 소싱할 영역들을 분명하게 구분할 필요가 있겠지요.

토요일, 2월 26, 2011

국내 소프트웨어, 변화를 시작하자

페이스북, 구글의 개발과 테스트에 대한 글들을 접하면서 국내 개발자들의 반응은 충격적이다, 부럽다 다양했습니다.
우수한 개발자들이 훨씬 더 많은 책임을 가지고 혁신을 향해 뛰어가는 모습이란 점에서 페이스북과 구글은 크게 다르지 않았습니다.

다들 국내 소프트웨어 환경의 열악한 처우 혹은 경쟁력에 대해 비판적으로 언급하였지만 어떻게 변해야 할까에 대해서는 엇갈리는 것 같습니다.

국내 소프트웨어의 경쟁력을 갖추는 현실적인 방법은 무엇일지 생각나는 데로 적어봅니다.

많은 사람들이 소프트웨어 정책의 변화가 필요하다고 말씀을 하시는데 그 변화의 방향은 조금씩 다른 것 같습니다.

소프트웨어 기업 내부 변화가 필요하다

정책에 앞서 먼저 소프트웨어 기업 내부적인 변화가 필요합니다.
저는 페이스북, 구글에서 보여주는 엔지니어 중심적이고 기술 중심적인 변화, 그리고 끊임없는 창의와 혁신을 북돋우는 문화가 우리 소프트웨어 기업들에도 가야할 방향이라고 보고 있습니다. 블로그에서 몇번 언급했던 내용들이긴 하지만 다시 한번 정리해봅니다.


1. 단순 기능 분업은 기술 기반 혁신을 막는다.
기획 따로, 개발 따로의 분업 구조는 엔지니어의 책임 범위를 축소시키고 수동적인 존재로 만듭니다. 실리콘밸리는 비즈니스를 배운 엔지니어에 의해 혁신이 추동됩니다. 엔지니어가 기획하고 검증하는 시도들이 많아져야 합니다. 소프트웨어를 지식 산업의 방향으로 이끌려면 기술을 아는 엔지니어가 비즈니스에 과감하게 도전하는 문화가 기업 내에서도 필요합니다.

2. 엔지니어를 4,5명의 소그룹으로 정예화하여 새로운 도전을 활성화하라. 과감하게 Risk taking하되 빠르게 검증하고 성과를 분명히 하라.
페이스북과 구글은 우수한 엔지니어가 아니면 직원을 뽑지도 않고 또 평범한 퍼포먼스의 엔지니어는 결과적으로 내보내는 문화를 가지고 있습니다. 국내에서는 그렇게 할 수 있는 기업은 없을 것입니다. 아이디어를 가진 능력있는 엔지니어들 중심으로 짧은 기간 동안 도전을 하도록 유도할 필요가 있습니다. 아이디어의 타당성을 2개월~4개월 정도 프로토타이핑하며 그 후 확산 혹은 폐기 등을 기술과 시장 관련 책임자들이 함께 모여 브레인스토밍으로 결정하는 문화가 필요합니다.

3. 철저하게 성과 위주로 평가하라. 비즈니스와 기술, 미래를 모두 고려하여 성과를 평가하라.
시간을 가지고 평가하는 것은 획일적으로 시간을 많이 투입하라고 하든지 적게 투입하라고 하든지 동일한 오류라고 생각합니다. 소프트웨어는 시간당 성과의 차이가 엄청나게 큽니다. 자기 시간을 더 투입하든, 덜 투입하든 성과 위주로 철저하게 관리할 필요가 있습니다.
엔지니어는 설정된 자신의 목표를 위해 스스로를 관리하면 됩니다.

4. 엔지니어의 책임을 확대하라.
엔지니어의 책임을 훨씬 더 넓힐 필요가 있습니다. 엔지니어 개인이 맡은 범위를 넓혀 불필요한 인터페이스를 줄이고, 분석 설계부터 구현, 테스트 검증까지 엔지니어에게 일차적 책임을 둬야 합니다. 많은 국내 기업들은 엔지니어가 코드 테스트(white-box test)를 수행하지 않습니다. 엔지니어가 단순히 결과에 대한 블랙박스 테스트만 하거나 그나마 QA 조직에 넘기고 있습니다. 설계를 가장 잘 아는 엔지니어가 코드의 테스트부터 기능 테스트, QoS 기준 테스트까지 테스트도 설계하고 코딩해야 합니다.

5. 교육과 성장을 관리하라.
구글, 페이스북과 달리 미숙한 엔지니어에 대한 교육과 관리가 항상 중요 이슈가 됩니다.
미숙한 엔지니어를 성장시키는 내적 과정을 정착해야 합니다. 소프트웨어 엔지니어는 외부 교육을 통해 성장할 수 없습니다. 일정 수준 이상 도달할 때까지 항상 별도 관리해야 합니다. 대학교, 대학원을 졸업해도 실제 프로젝트에서 혼자에게 요구되는 역할을 할 수 있을 때까진 일종의 내부 인턴으로 관리되어야 합니다. 엄격한 엔지니어 수준 관리는 소프트웨어 전문 기업에서는 매우 중요합니다.

6. 항상 생각하고 브레인스토밍하라.
생각하고 또 생각하는 창의적 문화로 바꿔야 합니다. 아이디어에 대해 모든 관리자들이 목말라하고 고무하고 이끌어줘야 합니다. 엔지니어로부터 CEO의 정책 결정까지 아이디어의 유통이 가능해야 합니다. 그러기 위해서는 CEO, CTO를 포함한 모든 관리자들이 아이디어를 중시하고 눈사람처럼 뭉쳐 키우는 문화를 만들어야 합니다.

7. 마케팅이나 컨설팅에 전략을 의존하지 말라.
시장 변화를 주도할 새로운 기술은 마케팅 예측을 할 수가 없습니다. 마켓 분석은 숫자에 불과합니다. 참고 자료 그 이상도 이하도 아닙니다. 그냥 참고만 하고 비전을 만들기 바랍니다.
핵심 정책을 decision making하기 위해 컨설팅을 하는 것은 내부적으로 회사의 비전을 갖고 있지 못하다는 뜻일 뿐입니다. decision making 능력은 내부 사람들의 판단을 총합하여 비전과 결합하고 발전시키는 능력입니다. 그게 안된다면 그 소프트웨어 기업은 미래가 없습니다. 그런 기업은 핵심 경영진을 교체하십시오.

소프트웨어 정책과 관행이 변화해야 한다

기업 외적인 문제들도 많습니다. 솔직히 현실은 답답하기만 하고 과연 소프트웨어를 아는 사람이 소프트웨어 정책을 수립하는가 하는 얘기는 너무 많이 듣습니다.


1. 사람 수에 의한 프로젝트 계약 관행 없애야.
일의 범위와 질에 의해 계약되어야 합니다.
공공 프로젝트부터 민간 프로젝트까지 범위에 의한 계약, 질과 완성도에 따른 감리를 할 수 있어야 합니다.
범위 산정도 못하고 질에 대한 검증도 못하는 수준이 계속 반복됩니다. 투입 인력만 계산하는 육체노동적인 국내 소프트웨어 프로젝트 계약 관행을 바꿔야 합니다.
전체 소프트웨어 업계가 머리 수만 중시하게 됩니다.

2. 위험도가 있는 기간 소프트웨어를 정부 과제에서 지원해야
정부 과제는 민간 영역에서 위험을 감당하기 어려운 기반 소프트웨어에 투자해야 합니다. 국가 과제가 미래의 국가 기반 투자를 책임지는 것이 가장 중요하며 소프트웨어에서도 그대로 적용됩니다.
정부 산하 연구기관에서 시장성이 떨어지는 프로토타이핑 수준의 소프트웨어를 만들도록 과제가 지원되는 것도 삼가하고 민간 기업 연계나 창업을 유도하고 감시해야 합니다.
연구 기관에서 소프트웨어 제품을 개발하고 연구원들이 시장에 대한 책임을 지는 것은 현실적이지 않습니다.
민간 기업에서 시장에서 적용가능한 소프트웨어 연구 개발을 할수 있도록 지원하고 그 성과를 모니터링해야 합니다. 민간 기업에서 고급 소프트웨어 연구개발이 중단되고 그 명맥이 끊어져가면 혁신이란 불가능합니다.

3. 선정 및 평가의 수준과 공정성

소프트웨어 과제 선정할 때 흑자 기업이라는 요건은 아이러니합니다. 기술력 있고 비전 있는 소프트웨어 기업은 초기 투자가 많은 소프트웨어 산업 특성 때문에 적자 기업일 가능성이 높습니다. 국가 과제에서 비전과 기술력을 평가하라고 하면 주관적이라고 꺼려하기도 합니다. 기술력과 소프트웨어 제품의 가능성에 대한 평가를 소프트웨어 정책을 이해하고 책임질 분들이 해야 하나 현실적으로는 그렇지 못합니다. 당분간은 해외에 평가와 선정을 맡기는 것이 최선이 아닐까 생각합니다.


4. 소프트웨어 제값 구매를 활성화해야
정부 과제만으로 연명하는 과제 전문 소프트웨어 기업을 만들지 말고 소프트웨어 제값 구매를 해서 소프트웨어 기업이 성장할 수 있도록 소프트웨어 시장 규모를 정상화시켜야 합니다. 공공 부분의 예산 책정 시 가장 고려해야 할 부분입니다.
이외에도 스마트폰 혁명으로 붐이 일고 있는 다양한 형태의 소프트웨어 생태계에서도 소프트웨어나 앱 시장이 일부 대기업에 의해 왜곡되지 않도록 해야 합니다.


국내 소프트웨어 기업들이 갑자기 실리콘밸리의 기업처럼 되는 것은 쉽지 않습니다. 10년 전 코스닥 붐의 버블이 꺼진 이후부터는 국내 소프트웨어 벤처들의 암흑기였습니다. 네이버, 다음 등을 배출했던 코스닥 붐은 다시는 오지 못했고 소프트웨어 기업들은 명맥만 이어가는 형태가 되었습니다.
암흑기를 걷어낼 조짐이 보인 것은 아이폰에 의해 촉발된 스마트폰 혁명입니다.
아이폰은 앱스토어라는 글로벌 유통망을 개발자들에게 가져다줬습니다. 소셜 미디어들은 새로운 마케팅 채널로 활용되고 있습니다.
아이폰, 안드로이드 폰, 아이패드, 페이스북 등 새로운 앱 플랫폼의 등장도 소프트웨어 기업들에게 기회를 주고 있습니다.
하지만, 그 기회를 잡으려면 기업들이 변화해야 합니다. 기술과 혁신을 내재화한 소프트웨어 기업들이 성공하는 시대이지만 국내 기업들은 기술도 정체하고 혁신을 만들기 어려운 경직된 구조이기 때문입니다.

더 많이 생각하고 빠르게 소규모로 도전하는 체질 변화가 필요합니다.
누구보다 엔지니어들이 변화의 중심이 되어야 합니다.
하루 아침에 결과가 나오진 않겠지만 이미 변화 중인 기업들에서 혹은 새로 변화를 채택한 기업들에서 머지 않아 놀라운 창의와 혁신을 보여줄 것입니다. 다른 길은 없으니까요.