기본 콘텐츠로 건너뛰기

소프트웨어 국가 정책을 악제(惡題, 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

댓글

이 블로그의 인기 게시물

Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다.

일단 생소하기 때문에 어렵다.

그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다.

먼저 G1GC를 이해하는 데 유용한 사이트이다.

Garbage-First CollectorGetting Started with the G1 Garbage CollectorUnderstanding G1 GC LogsTuning Garbage Collection for Mission-Critical Java ApplicationsControlling GC pauses with the GarbageFirst CollectorG1: One Garbage Collector To Rule Them AllGarbage First (G1) Garbage Collection Optionscompare JVM options for public메일 : G1 GC clean up time is too long
JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다.
(새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.)

지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다.
즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다.
앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다.

둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한 처리는 아직 최적화되지 않았다. 보통 한 region의 50% …

Heap Dump 분석을 통한 Perm Area Memory Leak 원인 진단

Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class…

새로운 관리자 모델은 훌륭한 코칭 능력을 필요로 한다.

"직원의 학습과 개발 70%는 일 자체에서 일어나지, 정형화된 교육 프로그램을 통해 일어나지 않는다."
관리는 많은 부분 코칭의 스킬을 필요로 하게 되었고, 코칭의 출발점은 Listening이다.
물론 관리자들도 코칭 및 관리 스킬을 개선하기 위해 코칭을 받을 필요가 있다.

코칭이 이루어지지 않거나 코칭 스킬이 개선되지 않는 회사는 미래 지향적 회사가 되지 못할 것이다.
시간을 이유로 좀처럼 사람들에게 귀기울이지 않는 기업은 결국 진보하지 못할 것이다.
Listening을 통한 Coaching과 Insight가 개선되는 조직이 지속적인 경쟁에서 성공할 수 있다고 할까.
그런 측면에서 위기는 listening을 징후로 하고 식별자로 리더의 코칭 능력 개선과 insight 능력을 들 수 있다.

그런데 듣기만 하고 insight가 없어서 코칭을 못한다면 이러한 기업은 정체할 뿐, 성장을 이끌지 못할 것이다.
코칭의 핵심은 멤버들과 코칭하는 관리자의 동반 성장이기 때문이고, 이를 통해 insight를 더 구체화하고 공유하는 것이기 때문이다.

코칭과 insight를 잘하는 리더 후보를 다수 보유한 기업이 진화하는 미래 지향 기업이라고 볼 수 있다.

관리자에 대해 코칭의 중요성을 지적한 아래 하바드 비즈니스 리뷰 글은 상당히 공감이 간다.

HBR 기사 원문 : 좋은 코치가 아니면 훌륭한 관리자가 될 수 없다.

아래는 기사를 대충 번역해본 것이다.

좋은 코치가 아니면 훌륭한 관리자가 될 수 없다. 2014년 7월 17일 Monique Valcour 글

가장 우선적으로 생각해야 할 리더십 덕목은 '사람들이 직장에서 경험하는 가장 강력하게 동기 부여하는 조건은 개인적으로 의미있는 무언가에서 진전을 이루는 것'임을 아는 것입니다.
당신이 누군가를 리딩하는 일을 하고 있다면 매일 해야 할 가장 중요한 일은 팀원들이 의미있는 일에서 진척을 경험하는 것을 것을 돕는 것입니다.

그렇게 하려면 각 멤버의 동인을 이해하고 각자의 일과 조직의 미션 및 전…