금요일, 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)