본문 바로가기
엑셈 경쟁력/전문가 기술기고

박재호의 IT 이야기| 소프트웨어 개발과 창의력 vol.1 창의력의 본질

by EXEM 2016. 2. 23.

 

 

 

 

 

소프트웨어 개발에 창의력이 필요하다는 가정은 거부하기 어려울 것이다. 한번 설계가 끝나고 대량 생산에 들어가는 하드웨어와는 달리 소프트웨어는 요구 사항이 계속해서 변경되는 경향이 있으며 이를 충족하기 위해 사고의 전환이 필요하다. 따라서 소프트웨어 개발을 창의력과 연결시키려는 시도는 자연스럽다. 하지만, 창의력이 무엇인지에 대해 충분히 고민하지 않은 상태에서 무조건적인 자유와 신기술을 소프트웨어 개발의 핵심으로 놓기에는 미심쩍은 구석이 있다. 오늘은 소프트웨어와 연결된 창의력의 본질에 대해 탐험해보자.

 

위키피디아에 따르면 창의력은 독창적이고 가치가 있는 뭔가를 만들어내는 작업과 관련이 있으며, 다음과 같은 특성을 보인다.

 

“문제, 결함, 지식 사이의 간극, 빠진 구성 요소, 부조화 등에 촉각을 곤두 세우며, 어려움을 파악하고, 해법을 찾고, 생각하고, 결함에 대해 가설을 세우고 이런 가설을 다시 실험하고 가능한 경우 변경하고 다시 테스트하는 과정을 거쳐 최종적으로 결과를 알리는 과정이다.”

 

백지에서 출발해 전혀 없는 새로운 물건/사상/개념을 만들어 낸다는 일반적인 상식과 달리 창의력의 특성은 흔히 과학에서 사용하는 ‘가설, 실험, 검증’ 또는 ‘문제 풀이’와 유사하다. 소프트웨어 개발의 목표 중 하나가 바로 고객의 문제 해결이라는 사실을 떠올려보면 연결고리를 찾아낼 수 있다. 따라서, 문제 풀이를 쉽게 만들어주는 여러 가지 프로세스와 도구는 가설, 실험, 검증, 문제 풀이를 위한 수단이며 이를 체계적으로 다룰 수 있는 사람만이 창의력을 발휘할 수 있게 된다. 하지만 창의력을 발휘하기 위해 이렇게 체계적으로 접근해야 한다면 자유를 제한하므로 새로운 뭔가를 추구하는 창의력의 본질이 훼손될지 모른다는 걱정이 들기 시작할 것이다. 설상가상으로 다음과 같은 더 큰 문제가 하나 존재한다.

 

1. 창의력은 기존에 없는 새로운 뭔가를 만들어야 한다.
2. 새로움을 추구하기 위해서는 기존에 존재하는 사항에 대해 잘 알고 있어야 한다.

 

 

1번과 2번의 충돌 또는 모순은 창의력을 발휘하려면 완전한 무에서 시작하는 대신에 어느 정도 기반을 다진 결여의 무에서 시작해야 한다는 사실을 암시한다. 이는 독창성을 강조하는 창의력에 대한 본질을 다시 한번 고민하게 만든다.

 

그렇다면 이런 모순을 어떻게 해소해야 할까? 자니 그로엔이 1990년에 발표한 논문인 ‘호기심이라는 규율’에 제시한 설명을 소개한다.

 

“과학은 단순한 호기심과 창의력이 아니다. 호기심과 창의력을 통제한 형태가 과학이다. … 과학적인 진보를 끌어내는 원동력은 호기심과 규율이라는 기묘한 단짝이다. 끊임없이 ‘왜?’와 ‘어떻게?’를 묻는 호기심과, 과학을 현실로 묶어주는 체계 말이다.”

 

소프트웨어 부문에서도 마찬가지일 것이다. 무조건적인 방법론과 엄격한 관리 체계가 해답은 아니지만 창의력을 빙자한 무질서 역시 해답은 아니다. 소프트웨어 공학도라면 누구나 과학적인 사고 방식으로 고객의 어려움을 해결하기 위한 문제 풀이에 집중해야 마땅하며, 이런 과정에서 사물에 대한 크나큰 호기심과 과거 경험을 토대로 정립된 규율이라는 단짝을 함께 포용해야 한다.

 

하지만 주의 사항이 하나 있다. 여기서 말하는 규율은 상명하복을 무조건적으로 따르는 중앙집중적인 통제가 아니라 개발자들의 자발적인 관리 체계에 가깝다는 사실을 짚고 넘어가겠다. 특히 두뇌 활동을 기반으로 움직이는 조직에서는 자율과 규율이 조화를 이뤄야 제대로 된 ‘창의력’이 발현될 것이다.

 

창의력이 그렇게 쉬운 단어가 아님을 인식했는가? 다음에는 조금 더 구체화해 소프트웨어 설계 과정에서 발현되는 창의력에 대해 살펴보기로 하겠다.

 

 

 

 

 

댓글