Talk with Hani

건물을 새롭게 올리고 나면 조경 공사도 멋지게 한다. 대개 정원이나 잔디밭을 사각형으로 만들고 그 사이에 사람들이 걸어다니는 길을 꾸민다. 사각형의 정원이나 잔디밭을 따라서 길을 만들었기 때문에, 사람들이 건물로 들어갈려면 정원과 잔디밭을 가로질러서 가지 못하고 돌아서 가야한다. 하지만 사람들은 최단 거리로 이동하고 싶어하기 때문에, 관리하는 사람이 없다면 정원과 잔디밭을 관통한다. 이런 사례가 반복되어 잔디가 죽거나 조경이 망가지면, 회사에서 잔디밭 무단 횡당 금지를 선언한다.

그렇다면 사람도 편하고 잔디도 보호하려면 어떻게 해야 할까? 조경하고 나서 바로 인위적으로 인도를 만드는 게 아니라, 일정 시간이 경과한 후 인도를 만들면 된다. 즉 사람들이 자연스럽게 잔디밭이나 정원을 걸어다니면서 최적화된 경로를 만들기 때문에, 사람들이 걸어다니면서 생긴 길 주위로 펜스를 치고 길을 만들면 된다. 실제로 이런 식으로 조경 작업을 하는 건축가도 있다.

회사에서 소프트웨어 개발 프로세스를 개선하는 경우를 보면, 인위적으로 길을 내는 경우와 비슷할 때가 많다. 최신 사례와 표준을 참고해서 멋있는 표준을 만들지만, 그렇게 만든 프로세스는 상당히 인위적이다. 현실감이 없기 때문에, 사람들이 그 프로세스를 따라서 일할려면 효율적이지도 않고 효과도 없을 때도 있다. 하지만 어떤 조직에서는 이런 현실을 인정하지 않고 무조건 조직의 표준이니 일단 지킬 것을 강요한다. 결국 일과 사람보다 규정이 중요한 셈이다.

괜찮은 소프트웨어 개발 프로세스를 만드는 방법은 사람이 편한 인도를 만드는 것과 동일하다. 조직원들이 어떻게 일하고 있는지 잘 관찰하고 그 방법을 잘 살려서 일하게 하면 된다. 이게 쉽고 효과적인데, 대개 이렇게 하지 않는다. 왜 그럴까? 프로세스를 개선해야 하는 사람들 입장에서, 그다지 뽀대가 나지 않기 때문이다. 사람들이 멀리 돌아가더라도 네모 반듯한 인도가 더 멋있는 이유와 비슷하다.

얼마 전에 “소프트웨어 개발, 돈이면 해결될까?”란 글을 올렸다. 요즘처럼 불황의 문턱에서 대한민국이 방황하는 시국에, 안정적인 수입원처럼 동기부여되는 것은 없을 듯하다. 먹고 사는 일이 갑인 시절임을 인정하지만, 한편으로 정말 돈만 많이 주면 대한민국이 원하는 소프트웨어가 뚝딱하고 만들어질까,란 의문으로 그 글을 썼다.

물론 그 글에서 구체적인 해법을 제시하지 않았다. 단지 돈만으로 좋은 소프트웨어를 만드는 데 부족하지 않냐는 의문을 던졌을 뿐이다. 사실 이 주제는 평생의? 화두이기도 하고, 직업상 늘 던지는 질문이기도 하다. 마침 스마트폰 스나미 때문에 국내 휴대폰 제조업에 위기가 닥쳤고, 그 덕분에 소프트웨어가 무대의 중심에 서게 되었다. 이런 시국 속에서, 그동안 품고 있던 의문들을 정리하는 게 의미가 있겠다는 생각을 했다. 그래서 그 생각들을 정리해서 한 권의 책을 출판하게 되었다.

‘대한민국 소프트웨어, 리스타트: 위기를 넘어 도약으로’가 바로 그 책이다. 이 책에서는 지난번 쓴 포스트에 대한 해답을 제시한다고 볼 수 있다. 즉 돈만으로 좋은 소프트웨어를 만드는 데 부족하다면, 뭐가 더 필요한데?란 의문에 대한 답이다. 난 그 해답을 좋은 소프트웨어 개발 문화라고 생각했고, 그 아젠다로서 “소프트웨어 엔지니어링을 지배하라!” “소프트웨어, 사람이 만든다!” “위험을 감수하고 이익을 극대화하라!”를 제시했다. 각 아젠다에는 읽고 적용할 수 있는 실천방법들을 모아두었다.

요약하자면, 좋은 소프트웨어를 만들고 싶은 개발자와, 개발자와 협업해서 좋은 소프트웨어를 만들고 싶은 사람, 그리고 개발자를 고용해서 그레이트 소프트웨어를 만들고 싶은 사업가들이 읽으면 무척 좋을 것이라, 믿는다. 올해 연말 쯤에 서점에 풀릴 예정이니 이 책을 읽고 새해엔 좋은 소프트웨어를 만들 수 있는 힌트를 얻으시기를 바란다!

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

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

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

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에 집중함으로써 우리가 만들지 않아도 되는 것을 안 만들어도 되고, 더 중요한 것을 만들 수 있게 하기 때문이다.*

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