SW 위기를 받아들이자.

요근래 - 특히, 구글이 모토로라를 인수했다는 이야기가 흘러나오면서 - IT 위기, 즉 SW에 대한 위기를 말하는 기사와 SNS로 관련 업종에 근무하는 사람으로 마음이 참으로 무겁다. 위기를 받아들이는 입장은 다양하지만, 우선 그 위기를 환경이나 외부 탓으로 말하는 것은 조금은 조급한 심정에서 토로하는 것이 아닌가 생각한다. 진정 SW 위기를 말하고자 한다면, 다시 한번 침착하게 생각을 해보았으면 한다.

SW 위기가 요근래에 화두된 것도 아니고, 벌써 오래전부터 이러한 말들은 나오고 있었지만, 지금의 상황에서 어떠한 희망을 찾기에는 상당히 힘들어보인다. SW 위기를 정책의 부재, IT 인재들의 전향, SW 하청 구조에 대한 문제 등으로 다양하게 해석되기도 하지만, 우리는 근본 문제를 찾으려는 노력을 그보다 먼저 해야하지 않을까 생각이 든다. 왜 그래야 하는 것은 우선은 SW에 종사하는 사람들은 그 누구보다도 이후에 이 업종에 종사하려는 사람들의 선배이고, 앞서서 그 길을 개척한 사람들이기 때문이다. 나 자신이 SW업에 대해 천직이고, 정말 훌륭한 SW를 만들려는 사명감에 불타고자 하는 의욕이 있는 것은 아니다. 그저 내 또래의 동료와 같이 미래에 각광받는 업종이고, 앞으로도 발전 가능성이 무한하다라는 생각에 무작정 뛰어들었던 것이 사실이다.

SW 위기를 대처하는 방법에 대해서 그리고 이러한 위기를 극복하는 방법에 대해서는 어느 누구도 그 해답을 제시한다고 해도 그것이 정답이라 말할 수 없다. 하지만, 무엇보다도 우리 SW 업계에서 일어나고 있는 일들에 대한 자성과 그 해결책들을 생각해본다면 그리고 그러한 것들이 공유되고 스스로의 정화 작업을 먼저하는게 외부와 환경을 탓하는 소모전을 최소화시키는 것이 아닐까. 그리고, 언젠가는 SW 업에서 한 목소리를 내고, 이를 정부 정책이나 타 산업에도 역시 전달하는게 가능하지 않을까.

삼풍 붕괴나 성수대교 붕괴와 같은 사고에 무덤덤한 업계
최근 들어 보안사고와 프로그램의 실수로 인한 사고가 연일 터진 사건들이 있었다. 이러한 사고를 바라보는 SW를 잘모르는 외부 입장은 무조건 책임과 질책을 이야기하고 있다. SW를 잘 알고 있다고 하더라도 이들의 잘못을 거론하는 것은 어디까지 '카더라' 하는 이야기들이다. 건물의 붕괴는 눈으로 보이고 그 피해가 직접 물리적으로 미치기 때문에 그 사고가 일어난 경위와 조사 과정이 상당히 상세하게 보도되거나 증명된다. 하지만, 이에 비견할 수 있는 이러한 사고에서 우리는 그 어떠한 상세하고 뚜렷한 조사 과정을 지켜보지도 또한 드러내지도 않았다. 결국 똑같은 실수와 오류에 대한 반복은 어디에서든 터질 수 있는 뇌관을 시스템 깊숙히 숨기고 있는 것이다. 사실 시스템의 붕괴를 심각하고 치욕스럽게 받아들이는 태도가 그 이면에 있는 것은 아닐까. 24/365를 자랑하던 시스템이 멈춘다든지 정확하게 계산되어서 그 결과에 대해 의심의 눈초리를 거부할 정도로 세밀하게 만들어진 시스템이 오류를 만들어낸다든지에 대한 가능성에 대해서는 이 업계에서는 도무지 용납이 되지 않는 것이다. 그러한 분위기는 결국 이를 운영하는 사람들에게 직접적이든 간접적이든 통제의 형태로 압박이 들어오며, 이는 시스템을 개발하는 시점까지도 영향을 미친다.

진정으로 SW 업계의 발전과 공생을 위한다면 이러한 사고나 실패에 대해서 가감없이 공유되기를 바란다. SW의 실패를 조직의 실패라고 생각하고, 이를 담당했던 개발자나 PM이 아닌 전체 조직의 입장에서 숨기는 것이 아니라 명확하게 드러내어서 공유되기를 바란다.

강도가 더해지는 프로젝트 통제
프로젝트의 규모는 시스템의 규모와 마찬가지로 점점 더 거대해지고 있으며, 여기에 투입되는 프로그래머나 개발자들도 많이 늘어나고 있다. 프로젝트는 정해진 시간과 예산, 자원을 통해서 성과를 내야하기 때문에 어느 정도의 통제는 어쩔 수는 없을 것이다. 하지만, 통제에 대한 방법에 대해서는 그동안의 차세대 프로젝트들을 비추어봐서 그리 성공적이라고 말할 수 있는 부분은 거의 없다. 규모가 커짐에 따라서 프로젝트를 통제한다는 것이 어느 한사람의 노력으로 수행되는 것이 아니기 때문에 이는 일방적이고 심지어 가혹하다 싶을 정도로 그 통제의 강도가 더해지는 것이 사실이다.

이는 특히 이전에 개발을 경험했던 PM일수록 그 강도를 더하기도 하는데, 결국 SW 개발자가 업을 떠나는 결정적인 역할을 한 경우가 많다. SW 특성상 외부의 이러한 강력한 압박은 창의적이고 효율적인 결과물을 만들어낸다기 보다, 그냥 현재의 문제를 회피하기 위한 결과물들을 만들어내고 이는 추후 운영이나 유지보수 시점에 다시 뜯어고치는 사태까지도 만들어낸다. 지금의 SW는 과거의 SW와 구현할 비즈니스의 범위와 난이도, 기술에 대한 다양성에서 극적으로 커진 상태이다. 과거에도 그러한 시스템을 몇명이서 개발을 했다라는 이야기를 지금의 개발자들에게 하며 강요하기에는 시스템 구축의 실상을 잘 모르는 경우가 대부분이다. 과거의 게시글은 사용자도 인터넷을 통해 공유할 수 있다라는 신기함에서 그 구현의 정도가 그리 광범위하지 않았지만, 지금은 UX를 시작으로 다양한 멀티미디어 데이터까지 다루어야 하는 심지어 외부 시스템과의 연계까지도 고려해야 하는 게시판을 만들어야 하는 상황이다. 이는 비즈니스가 동일하다고 하더라도 이를 구현하는 관점에서는 그 범위가 상당해진 것이다.

이러한 상황에서 프로젝트의 강압적인 통제가 그리 효과적이라고 보이진 않는다. 또한, 이러한 압박감에서 만들어진 SW는 수많은 내부 버그와 오류를 품고 있는 경우도 있으며, 이를 사용하는 고객에게도 전혀 만족감을 느끼게 하기 힘들다. 이제 프로젝트의 통제에 대한 개념을 과거의 방식에서 탈피할 필요가 있다. 좀더 관리 영역과 개발 영역이 서로 존중하고 신뢰할 수 있는 환경이 만들어져야 하며, 진척이나 WBS상의 진행상황으로 개발자를 압박하는 통제의 방식은 바뀌어야 한다.

꼼수는 이제 그만
SW를 만드는데 있어서 다양한 경우의 수가 존재할 수 있다. 또한, 기존의 해법들이 다양한 변이들을 만들면서 그 원천을 알 수 없는 해법들도 인터넷이 흔하게 널려있다. SW는 매번 설계를 어떻게 결정한 것인가를 하는 선택의 과정이며, 이러한 선택은 궁국적으로 운영 시스템에 영향을 미치게 된다. 즉, 다양한 SW 제작 과정에서 우리는 그 결과 시스템의 품질을 결정하게 되는 것이다. 그 과정에서 다양한 원칙들이 적용되는데 문제의 본질을 해결하기보다는 이러한 인터넷에 널려있는 꼼수를 통해서 시스템을 완성하는 경우도 많다. 물론, 시간의 제약으로 인해서 혹은 지식의 한계로 인해서 이러한 결정을 하기도 하지만, 그 선택으로 인해서 어떠한 결과를 만들어낼지에 대해서도 예측할 수 있어야 한다.

꼼수는 전문 용어로 Technical Debt라고도 표현할 수 있는데, 이러한 기술적인 빚은 어느 한계치를 넘어설 때에 시스템의 건전성을 보장받을 수 없다. 기술적인 빚의 형태는 앞으로도 시스템에 상당한 부담으로 작용할 것이며, 이미 기존 시스템들 중에는 이러한 부담으로 인해서 수많은 운영 조직을 필요로 하는 경우도 많다. 이러한 꼼수를 없애는 방법은 SW에 대한 성질을 정확하고 올바르게 아는 노력이 필요하다. 물론, 효과적이고 효율적으로 일하는 방식도 중요하지만, 결국 모든 시스템이 동일한 비즈니스를 담고 있는 것이 아니라 어느 정도는 상이하고 차이가 나는 비즈니스를 담고 있기 때문에 유사 비즈니스라고 하더라도 서로 전혀 다른 구현 결과로 나타나는 경우가 대부분이다.

솔루션이나 패키지 도입만으로 모든 문제를 해결할 수 없다는 이야기는 어디서나 흔하게 볼 수 있다. 정작 중요한 것은 이러한 것들에 대한 도입이 아닌 전체적인 관점에서 이를 어떻게 활용할 것인가의 모습인데, 이는 각 비즈니스 케이스마다 다르다. 결코 이러한 도입이 해당 시스템의 해답이 되지 못한다. 모든 솔루션/패키지 벤더들이 모든 것의 해답인 양 마케팅이나 영업을 하는 효과에 대해서는 그 장단점을 구분할 수 있어야 한다. 꼼수는 이와 같이 손을 댈 수 없는 외부 매개체의 도입 부분에서 발생하는 경우가 많기 때문이다. 결국 전체적인 시스템의 균형(balance)이라는 차원에서 각 시스템의 요소들이 제 역할을 담당하도록 책임성을 균등하게 분할하도록 해야 한다. 꼼수가 가미된 시스템은 어느 한쪽의 책임성이 심하게 불균형 상태가 되고 그로 인한 다양한 문제들이 발생되며, 이를 해결하기 위한 또 다른 꼼수가 덧대어지도 한다.

튼실한 기본기
기본기는 어떠한 분야에서건 반드시 필요하다. SW 분야의 기본기는 궁극적으로 사람으로부터 기인할 수 밖에 없다. 프로세스나 KMS 등의 많은 도구들을 이야기할 수도 있겠지만, 이는 어디까지나 보조적인 수단일 뿐이지 기본기를 갖출 수 있는 근본적인 수단은 아니다. SW 분야의 기본기가 사람으로부터 기인한다는 이야기는 결국 SW 제작을 하는 사람에게 기본기가 튼실한 SW를 만드는 책임이 있다는 것이다. 이는 대규모 시스템을 만드는 경우에 SW팀을 어떠한 형태로 운영하고 어떠한 방식으로 개발할 것인가가 중요한 부분이 된다. 기본기는 SW 만드는 사람의 지식으로부터 시작되며, 이러한 지식이 서로 합해지면서 새로운 가치를 만들어내게 되는데, 이 부분에 대한 가치를 인정하는 환경이 조성되지 못한게 SW 업계의 큰 실수라고도 보여진다.

기본기가 다져지는 시점을 학교 교육으로 보는 경향도 있겠지만, 이는 어디까지나 SW 업을 처음 시작하는 시점으로 봐도 무방할 것이다. 즉, SW를 제작하는 초반의 습관을 어떻게 들이느냐가 SW를 만드는 이후의 관행에 결정하게 된다. 물론 이 초반이라는 기간을 어디까지로 봐야 하느냐의 견해는 서로 다를 수 있겠지만, 소위 말하는 '제대로 된' SW를 만들려는 노력을 들이는 절대적인 시간이 필요하다는 것으로 해석될 수 있다. '제대로 된' SW를 만드는 노력은 잘 짜여진 교육이나 교재, 혹은 가이드와 같은 것으로는 어느 정도 한계가 있다. 튼실한 기본기로 '제대로 된' SW를 만드는 노력은 거의 장인 정신(Craftsmanship)과도 비견할 수 있다. 여기에는 아무런 보상이나 이익을 기대하기 힘든 영역이기도 하다. 변수명 이름을 근사하고 멋있게 짓는다고 그 누가 월급이나 성과급을 더 줄 사람은 아무도 없기 때문이다. 100줄의 코드를 10줄로 줄인다고 하더라도 그 누구가 봐줄 사람도 없다. 오로지 자기 만족을 하는 영역이기도 하다. 하지만, 이러한 노력을 쌓는 것이 궁극적으로 '제대로 된' SW를 만드는 밑거름이 될 것이라는 믿음을 잃지않는게 중요하다.

'위기'를 '기회'로
위기를 기회로 만든 사람들은 외부나 환경 탓을 하기보다는 스스로의 끊임없는 노력을 통해서 만드는게 대부분이다. 외부 탓만을 하는 것은 나의 위안이 될 수 있겠지만, 그 안에서 해법을 찾는데는 크게 도움이 되지 않는다. 결국 외부의 해결책은 SW 업 전체에 영향을 미칠 것이며, 이는 결국 '나'라는 입장에서 그 혜택이 크게 줄어들 수 밖에 없다. 그렇다고 SW업의 고질적인 병폐나 문제를 외면하고 싶지는 않다. 이러한 부분들은 어느날 하루 아침에 해결될 문제는 결코 아니기 때문에 SW업 내실을 다지고 장기적인 안목에서 해결해야 될 문제이기도 하다. 당장 대기업의 하청 문제 역시 SW 업만의 문제는 아니지 않는가. 다양한 정책과 규제가 걸린 문제이고 그 무엇보다 대기업의 시각이 바꾸려는 노력이 절실한 상황이다. 이는 꾸준히 제기되고 해결방법을 같이 모색해야 할 부분이기 때문에 지금의 SW 위기를 당장 해결하는 해법이 되기에는 어느 정도 한계가 있는게 사실이다. 이제는 SW 성공의 잘난 부분들과 같이 고질적인 문제나 실패와 같은 영역까지도 모두 공유되고 같이 고민할 수 있는 시기가 필요하다고 본다. 당장 응급처치를 필요로 하는 시스템들은 많지만, 이를 성공이라는 이름으로 포장해봤자 그 어느 누구에도 이익이 되지 않는다. 위기가 기회가 되기 위해서는 정확한 진단이 필요하고 그에 맞는 처방전이 필요하다. 그러한 진단과 처방전은 다양한 각도를 통해 조명되어야 하고, 문제를 같이 공유하려는 노력이 더없이 필요하다고 본다. 당장의 해법을 만들 수는 없을 수도 있고, 지금의 위기를 전환시킬 수도 없을 수 있지만, 최소한 문제를 공유하려는 노력 만큼은 얻을 수 있는 기회가 생기지 않을까. 그리고 이러한 노력이 궁극적으로 SW 산업의 부활을 희망해보는 끈이 될 수 있지 않을까.

SW업에 먼저 발을 디딘 사람으로써 후배들에게 이러한 모습을 보여주는게 내심 부끄러운게 사실이다.