Talk with Hani

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

Yes24 교보문고 알라딘 리브로 인터파크

얼마전에 중소기업에서 초봉 4천만원을 제시해서 65:1의 놀라운 경쟁률을 보였다는 기사가 있었다. 석박사 급의 우수한 인재가 많이 지원한 덕분에 인력을 더 뽑았다는 아주 훈훈한 소식이었다. 요즘 같은 취업문이 좁은 시기에 사람을 많이 뽑는다는 건 참으로 따뜻한 미담이다.

이에 반해서 SI업체에서는 날코딩에 해당하는 업무를 백만원이 조금 넘는 돈으로 중국에서 아웃소싱할 수 있어, 비용 측면에서 상당히 이득을 보고 있다는 기사도 소개되었다. 사실 이 이야기는 새삼스러울 것도 없다. 그런데 그 기사의 댓글을 읽다가 먹먹해졌다. 자신들도 백만원 조금 넘는 돈 받아가면서 일하고 있다는 댓글이 상당수 달렸기 때문이다.

삼성전자에서는 소프트웨어 인력을 확실히 키우기 위해서 S직군을 신설했다는 소식도 전해졌다. S직군은 기본적으로 다른 직군에 비해서 초봉도 높고 대우도 잘 해준다고 한다. 삼성전자인만큼 여타 대기업보다 더 훨씬 많은 돈을 줄 것임이 틀림없다. 여기에 더블S라는 신조어도 나온다고 한다. S직군에서도 S급 인재를 말한다고 한다. 옥상옥 정도가 될까?

같은 대한민국 아래에서 소프트웨어라는 타이틀을 걸고 일어나는 인재전쟁?을 관통하는 키워드가 있다. 바로 돈이다. 신입사원들이 중소기업을 꺼려한다고 하지만 돈만 많이 준다면, 그곳이 비정상적인 회사가 아닌 이상 지원하는 건 인지상정이다. SI업체는 더 싼 비용을 찾아서 외국으로 나가고, 탑클래스의 회사에서는 최고의 인재를 대우한다는 기사, 그리고 최근에 개발자 모집과 관련된 넘쳐나는 기사에서 공통점을 찾을 수 있다. 바로 돈이다.

기사에 나오는 대한민국 소프트웨어 살리기 해법은, 개발자에게 돈만 많이 주면 될 것처럼 비춰진다. 과연 그럴까? 회사에서는 직원들을 동기부여하려고 노력한다. 그리고 어떤 이상가들은 직원들에게 꿈과 비전을 심어서 동기부여하라고 한다. 그러면서 돈이 중요하지 않다고 한다. 진짜? 그럴싸한 이론을 가져다 붙이지 않더라도, 먹고 사는데 돈이 필요하기 때문에, 당연히 돈… 중요하다. 하지만 돈이 중요하지만 돈으로 모두 해결되지 않는다는 건, 보상이론이나 행동경제학 이런 것들로 충분히 실증되고 있다.

핸드폰 제조업체에서 유발한 소프트웨어 위기 때문에 우리는 모두 개발자를 잘 대우하고 그래야 경쟁력있는 소프트웨어가 나온다고 생각한다. 그런데 내 생각에 소프트웨어는 최근에 위기를 맞은 게 아니라, 내가 이 세계에 입문했을 때부터 위기였다.

소프트웨어는 돈을 주고 사는 물건이 아니라, 아는 형이나 아는 동생한테 부탁만 하면 디스크나 CD로 얻어 와서 설치할 수 있는 품앗이 대상이었다. 그래서 난 최근에 급부상하고 있는 소프트웨어 위기는 정말로 허구라고 생각한다. 그 허구는 핸드폰 제조업의 추락 때문에 생겨난 것이다. 즉 제조업의 붕괴 때문에 발생한 대기업의 위기를 걱정하면서 발생한 것이다.

소프트웨어 위기가 제조업의 붕괴에 대한 걱정 때문에 조명을 받았든 받지 않았든, 소프트웨어가 현재 위기에 처한 원인을 되짚어 보면, 결국 소프트웨어를 제값 주고 사지 않았다는 점이다. 만약 좋은 소프트웨어에 대해서 적절한 비용을 지불하고 사는 문화가 있었다면, 우리나라 소프트웨어는 위기에 처하지도 않았을 것이며, 그 많은 개발자 지망생이나 경력 개발자들이 월급 많이 주는 회사에 취직하려고 목숨을 걸지도 않았을 것이다. 이 생각이 너무 단순한 생각일까?

물론 지금에라도 개발자들이 중요하다는 것을 인식하고 그들에게 제대로 된 대우를 해준는 건 다행이다. 하지만 소프트웨어 생태계가 복원되지 않고 단순히 제조업의 영속만을 위한 개발자 키우기(라고 쓰고 개발자 모집하기라고 읽는다)에만 집중한다면, 그리고 돈도 중요하지만 돈으로 살 수 없는 가치를 소중히 여기는 개발 문화가 생기지 않는다면 정말 대한민국의 소프트웨어, 그 미래는 암울할 것이란 생각이다.

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

Yes24 교보문고 알라딘 리브로 인터파크

소프트웨어 개발이나 제품 개발에서 요구사항이 중요하다고 한다. 그렇다면 왜 요구사항이 중요할까? 그 예를 단적으로 보여주는 사례가 있다. ‘아키텍트가 알아야 할 97가지’란 책을 보면 미 전투기 F-16의 개발 사례가 나온다. F-16의 초기 요구사항으로 속력이 마하 2~2.5가 되어야 한다는 게 있었다. 전투기의 설계를 맡은 디자이너가 왜 이 요구사항을 달성하는 게 중요하냐고 미공군에 물었다.

“교전 시 회피 능력을 높이기 위해서죠.”

디자이너의 설계는 마하 2 이상의 속력을 낼 수 없었다고 한다. 하지만 이런 속력에 대한 요구사항이 왜 나왔는지 이유를 알아냄으로써 그 해결책을 찾을 수 있었다. 즉 속력은 만족시키지 못했지만 프레임이 없는 캐노피를 도입하거나 G포스를줄이는 좌석을 만들거나 시야를 가리지 않고 전투 정보를 제공하는 디스플레이를 채용함으로써 근본적인 요구사항을 달성할 수 있었다.

고객이나 영업 마케팅에서 요구사항이라고 들고 오는 게 있다. 예를 들면 “앱으로 만들어야 해요.” “Ajax를 사용해야죠.” “클라우드를 도입해야 합니다.” 물론 이런 식의 요구사항을 프로젝트 개발팀도 내놓는다. 하지만 이런 것들은 요구사항을 가장한 설계 명세이다. 마치 F-16을 개발해야 하는 미공군이 마하2.0 이상의 속력을 내야한다는 요구사항을 내놓는 것과 비슷하다.

흔히 요구사항을 What이라고 말하고 설계를 What을 달성하는 How라고 말한다. 하지만 난 요구사항은 Why에 더 가깝다고 생각한다. What도 중요하지만 Why에 집중함으로써 우리가 만들지 않아도 되는 것을 안 만들어도 되고, 더 중요한 것을 만들 수 있게 하기 때문이다.*

* 개발이나 교육을 하다 보면, 요구사항과 요구사항 명세를 명확하게 구별하는 사람이 그다지 많지 않다는 사실에 놀랄 때가 많다. 그만큼 우리는 요구사항이라고 적고 설계(혹은 설계 명세)라고 말하는 것에 상당히 익숙한 셈이다. 이것에 대해서 할 말이 많은데 다음 글을 기약하겠다.

회사에서 통신비를 절감하려고 일반 전화를 인터넷 전화기로 교체했습니다. 출장을 갔다 오니, 정들었던 전화기는 이미 다른 곳으로 떠났고 한눈에 보기에도 많은 기능이 있을 법한 인터넷 전화기가 제 책상 한 구석을 차지했습니다. 예전에 사용한 전화기의 기능은 매우 간단해서, ‘전화걸기’ , ‘전화받기’ , ‘당겨받기’ , ‘전화 돌려주기’ , 전부 합쳐서 기능 네 개로 구성됐죠. 새로 설치된 인터넷 전화기에 딸려 온 매뉴얼 양은 간단한 스크립트 언어의 쿡북(cookbook)보다도 두꺼웠습니다. 그만큼 기능이 많다는 뜻이죠

가장 인상 깊은 기능은 인터넷 전화기였기 때문에 전화기마다IP가있었고 웹 브라우저로 전화기에 접속해서 전화기를 관리하는 것이었습니다 지금까지 웹 브라우저로 전화에 접속해본 것은 처음 받았을 때 테스트한 게 전부였지만, 전화기도 웹 브라우저로 접속한다는 것은 확실히 인상 깊었습니다.

쿡북 같은 설명서를 처음부터 끝까지 읽고 철저히 공부해서, 그 어려운 ‘단축 다이얼 설정하기’ 작업을 설명서 없이 해내는 동료도 있었지만, 전 전화를 걸거나 받고 부재 시에 걸려온 전화 내역을 확인하는 정도으로도 충분했습니다. 출장이 잦은 편이어서 대부분의 전화가 핸드폰으로 오기 때문에 새로 바뀐 인터넷 전화를 철저하게 마스터할 필요도 느끼지 못했습니다.

출장이 없던 날 사무실에 앉아서 그 동안 밀린 서류를 정리했습니다. 마침, 다른 자리에서 전화가 울렸습니다. 전화벨이 몇 번 울려도 받지 않자, 전 수화기를 들고 아무 생각 없이 별표를 눌렀습니다. 하지만 전화를 당겨 받지 못했습니다. 아차! 전화기가 바뀌어서 ‘당겨받기기능’ 이다른버튼인 것을 몰랐습니다. 옆에 있던 동료에게 전화를 당겨 받으려면 어떻게 하냐고 물었더니, 그 동료도 몰랐습니다. 전화를 받는 일은 주로 신입사원이 했기에 동료도 당겨 받는 법을 몰랐고, 그날따라 사무실에는 신입사원도 다른 직원도 없었습니다.

계속해서 울리는 벨 소리에 급한 전화일지 모른다는 생각이 들어, 전화가 울리는 자리에 가서 전화를 받았습니다. 프로젝트 관련된 전화였는데, 제 옆자리에 앉은 동료가 답할 수 있는 문제였기에 동료자리로 전화를 돌려주려고 시도했지만 어떻게 해야 할지 몰랐습니다. 전화를 받을 동료도 몰랐기 때문에 결국, 동료가 제가 있던 곳에 와서 전화를 받았습니다.

최첨단IT분야에 종사하는 사람들이 그 단순한 ‘전화당겨받기’ 와 ‘전화 돌려주기’ 를 못한다는 게 창피스러워서, 전 서류 작업을 마친 뒤에 전화 설명서를 펼치고 전화 기능을 마스터하기로 결심했습니다. 우선 당겨받기와 돌려주기 기능은 쉽게 마스터하고, 3자 통화까지는 버튼 한두 개로처리할 수 있었기 때문에 암기가 가능했습니다. 하지만 ‘단축 다이얼 설정하기’ 같은4단콤보(combo)나 ‘유동 아이피 설정’ 같은10단 콤보는 제 능력 밖이었습니다. 전 재빨리 학습을 포기를 하고, ‘당겨받기’ , ‘돌려주기’ , ‘3자통화’ 기능을 마스터한 것으로 만족했습니다.

그날 이후로 가끔씩 당겨 받거나 돌려주기를 하면서 전화를 잘 사용하기에, 인터넷 전화기에 숨겨진 수많은 기능을 새롭게 학습하고 싶은 의지가 생기지 않습니다. 다만 아직까지 ‘3자통화’ 기능을 한 번도 사용하지 않았기에 그날 배운 것을 활용하지 못한다는 아쉬움이 많이 남지만, 긴 직장 생활을 놓고 보면 언젠가 쓸 일이 있지 않을까요?

상용화를 앞둔IPTV 사업자 회사에 정부관련 인사가 방문해서IPTV의 데모를 봤다고 합니다. 이 고위 인사는IPTV 리모컨을 사용해서IP TV의여러 기능을 사용해 보고 시도했지만 실패했다고 합니다. 그러면서 “리모컨에 기능을 충실히 담아내는 것은 좋지만 복잡하게 만들어서는 안 된다.”하는 충고 한마디를 던졌다고 합니다.

물론 이 고위 인사가 리모컨을 디자인한 설계자만큼IPTV에 대해서 잘 아는 것도 아니고 사용성이든지 사용자 경험이라는 개념을 들어 본 것은 아니겠지만, 직관적으로 리모컨을 사용하기 불편하다는 것을 알아차리고, 이런 리모컨이IPTV 대중화에 걸림돌이 될 수 있다는 것을 지적했겠죠. 비전문가 한 지적이지만 따뜻하고 냉철한 충고를 관계자들이 허심탄회하게 받아들이지 못한 이유는, 이날 데모에서 사용한 리모컨 버튼은 원래51개였는데6개나 줄여45개로 만든 것이었기 때문입니다.

이 연재는 이미 출판된 겸손한 개발자가 만든 거만한 소프트웨어의 글을 옮겨 놓은 것입니다. 아래 링크를 통해서 책을 구매하시면 더욱 충실하게 읽어 보실 수 있습니다.

예스24, 인터파크, 알라딘, 강컴

횡단보도의 신호가 녹색으로 바뀔 때, 바로 건너지 않고 2-3초 기다린다. 몰상식하거나 신호를 인지 못한 운전자가 신호를 무시하고 지나갈 수 있기 때문이다. 신호가 바뀌자마자 건너다가 이런 차들 때문에 놀랄 때가 있다. 이럴 때마다 운전자에게 화가 나고 한소리하고 싶다. 이건 인지상정이고 당연한 일이다. 녹색신호에 맞춰서 건너는 것은 내 권리이고 이렇게 되어야 시스템에 문제가 없다.

하지만 권리만 생각하고 건너다 사고를 당할 수 있다. 룰을 지키고 있음에도 이런 룰을 벗어나는 예외 상황 속에서 사고를 줄일 수 있는 수단이 바로 유연성이다. 유연성을 발휘하려면 신호가 바뀌었을 때 2-3초를 기다릴 수 있는 여유가 꼭 필요하다. 말하자면 여유가 바로 유연성의 핵심이다.

프로젝트에서 일상화된 야근을 반복하다보면 개발자에게 여유가 없다. 그리고 주어진 사명을 다하고 있다는 의식에 몰입하게 된다. 즉 지금하고 있는 일이 전부라는 생각을 가지게 된다. 말하자면 주의를 살필 여유가 없게 된다. 그러다 보면 내가 옳고 상대가 그른 상황에 처했을 때 그릇된 상대와 충돌을 피할 유연성을 발휘하기 어렵다. 이런 여유 없음이 유연성을 발휘할 여지를 줄이고 팀원이나 고객과 쓸데 없이 충돌을 줄일 수 있을 여지를 없앤다.

그래서 내가 프로젝트에서 야근을 최대한 줄일 것을 강조하는 이유는, 단지 복지적 인 이유 때문이 아니다. 성공적인 프로젝트를 위해서 유연성이 프로젝트에 꼭 필요하고, 유연성의 핵심은 여유다. 그리고 그런 여유는 오버페이스하지 않는 프로젝트 리듬에서 나온다.