소프트웨어 국가 정책을 악제(惡題, 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은 다음 여섯 가지 특성을 악제(惡題)에 고유한 특성으로 보았다.
- 해법을 개발하고서야 문제를 이해하기 시작한다.
- '완료 규칙'이 없다. 충분히 좋은(good enough) 해법이 나오면 중단한다.
- 해법이 옳거나 그른 게 없다. 더 낫거나 더 나쁘거나 혹은 충분히 좋거나 불충분하거나 할 뿐이다.
- 모든 악제(惡題)는 독특하며 기발하다. 모든 악제(惡題)는 서로 다르며, 해법들은 매번 커스텀하게 고안된다.
- 모든 해법은 효력을 가진다. 모든 고안된 해법들은 결과를 가져오며, 또 새로운 악제(惡題)들을 유발한다.
- 대체 해법(대안)이 주어지지 않는다. 해법이 없을 수도 있고, 수많은 잠재 해법들이 존재할 수도 있고, 또 수많은 해법들은 생각도 못해봤을 수 있다. 하지만, 해법을 고안하는 것은 창의성의 문제이며, 또 어떤 게 유효하고 어떤 방법을 추구해야 하는지는 선택의 문제일뿐이다.
이에 대응하는 순제(淳題)의 특성은 다음과 같다.
- 문제가 잘 정의되어 있으며 안정적이다.
- 해법에 도달하는 분명한 종료점이 정의된다.
- 객관적으로 옳고 그름을 판단할 수 있는 해법이 존재한다.
- 유사한 방법으로 해결될 수 있는 유사한 문제들 클래스에 속한다.
- 쉽게 시도해보고 버릴 수 있는 해법들이 존재한다.
- 대체 해법들을 가지고 있다.
소프트웨어 개발은 악제(惡題)인 가?
| 요구사항 이해는 악제(惡題)? |
악제(惡題)는 계획이 정확하기 어려우며 반복적인 feedback을 통해 더 나은 해법을 찾아가야 하는 특성을 가진다. 따라서 이런 성격의 문제들은 미리 요구사항을 확정하고 이에 따라 구현만을 하는 이분법적인 프로세스로는 해결할 수 없다.
미션 크리티컬한 부분의 알고리즘 개선이나, 소비자들이 일상적으로 사용하는 B2C 소프트웨어의 만족도 개선의 문제, 소비자들의 정말 만족할 수 있는 사용자 경험 등은 good enough 외에는 판단할 수 없으며 끊임없는 iteration을 거쳐야 하는 전형적인 악제(惡題)라고 볼 수 있다.
시스템 소프트웨어나 엔드 유저를 대상으로 하는 소프트웨어나 서비스를 개발해본 사람들은 소프트웨어의 악제(惡題)적 특성에 대해 매우 공감할 것이다.
 |
| wicked, complex 기준으로 분류해본 Software |
악제(惡題)와 순제(淳題)의 구분은 매우 중요하다고 생각하는데, 악제를 순제처럼 접근하여 문제 해법을 만들면 다음과 같은 현상이 벌어진다.
이미 알려진 해법들 중심으로 빠르게 약 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 공학 전공자의 목소리를 줄일 필요가 있다고도 보인다.
 | |
|
정책 제안
모토롤라 모빌리티를 구글이 인수하고 나자 아이폰 쇼크만큼이나 국내 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
댓글