세계는 SNS에서 비즈니스를 창출하고 있는데 국내는 아직도 포탈에 머물고 있고, 자고 나면 해킹으로 털리는 신상정보가 된 탓에 대한민국의 주민등록번호는 더는 개인정보가 아니며, 국내 굴지의 소프트웨어 회사가 오픈소스를 전혀 사용하지 않고 토종 기술로 윈도우 호환 운영체제를 만들었다고 거짓말했다가 그 진실이 만천하에 드러난 IT계의 황우석 사건.

이처럼 소프트웨어 개발이라는 타이틀을 건 막장 드라마가 펼쳐지는 가운데, 클라이맥스가 펼쳐진다. 아이폰발 모바일 혁명에서 촉발된 IT 혁신으로 국내 핸드폰 제조업체는 위기에 처한다. 상황이 심각하게 돌아가자 그 위기의 원인을 언론에서는 소프트웨어에 있다고 진단한다. 그리고 사람들은 대한민국의 소프트웨어가 위기라고 말한다.

극단적으로 말해서, 내가 GW-Basic으로 프로그래밍을 처음 시작했을 때부터 대한민국 소프트웨어는 늘 위기였다. 단돈 500원만 주면 5.25인치 플로피 디스크에 미국에서 나온 최신 게임을 불법 복사해서 즐길 수 있었다. 이런 상황은 국내에서 나온 게임도 마찬가지다.

대한민국에서 좋은 소프트웨어가 나오지 않는 이유는 뭘까? 좋은 소프트웨어가 나올 만한 환경이 아니라서 정부나 회사에서 그토록 바라는 좋은 소프트웨어가 나오지 않는 것이다. 이 책에서는 좋은 소프트웨어를 만들려면 무엇을 고쳐야 할지 살펴볼 것이다. 여기서 다루는 내용은 새로운 것이 아니다. 우리가 몰라서 안 하는 것도 아니다. 그동안 선배들이 그렇게 했기에, 사회가 그렇게 요구했기에, 그렇게 개발하고 만들었기에 대한민국의 소프트웨어는 지금의 상황에 처한 것이다.

자, 대한민국 소프트웨어를 리스타트하자!

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

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

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

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

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

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

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

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

우선 앱시장과 같은 돈을 주고 받는 시장이 조금씩 살아난다는 건 다행이다. 이런 경제적 환경의 개선에 더불어서 소프트웨어를 만들어내는 개발문화도 바뀌어야 한다. 컴키드에서 소프트웨어 컨설턴트로서 우리나라 소프트웨어의 현실을 경험한 저자가 어떻게 하면 좋은 소프트웨어를 탄생시키는 개발문화를 만들 수 있을지, 그 해법을 제시한다. 자! 이제부터 대한민국 소프트웨어를, 리스타트해보자!

신승환

소프트웨어 개발, 프로젝트 관리, 프로세스 컨설팅 등의 업무를 십 년간 수행했으며, 현재는 차량용 임베디드 소프트웨어를 만들고 있다. 읽은 것과 생각한 것을 블로그(http://talk-with-hani.com)와 트위터(@talkwithhani)에 꾸준히 남기려고 노력한다. 지은 책으로는 「겸손한 개발자가 만든 거만한 소프트웨어」, 「도와주세요! 팀장이 됐어요」, 「시지프스를 다시 생각하다」, 「당신의 인생에 집필을 더하라」가 있으며, 다수의 IT 서적을 번역했다.

  • 시작하는 글
    • 대한민국 소프트웨어는 위기?
    •  
  • 01부_소프트웨어 엔지니어링을 지배하라!
    • 정도의 차이가 있을 뿐 요구사항 명세는 개발의 핵심이다
    • 요구사항, 요구사항 명세, 설계는 다르다
    • 회사에서 만드는 소프트웨어가 망해간다면 UX에 주목하자
    • UX란 개발 이상의 것이다
    • 사용자의 말보다 행동을 믿자
    • 아키텍트가 없더라도 아키텍처는 꼭 필요하다
    • PM과 아키텍트는 다르다
    • 사공이 많은 프로젝트 팀이라면 아키텍트가 반드시 필요하다
    • 매뉴얼을 만들기보다 매뉴얼이 필요 없는 소프트웨어를 만들자
    • 제대로 테스트하려면 자원, 프로세스, 문서가 필요하다
    • 최적의 테스트 기법을 찾아라
    • 테스트하기 전에 품질을 개선할 수 있는 방법이 있다면 그걸 선택하자
    • 개발자도 테스트해야 한다
    • 형상관리와 버전관리는 다르다
    • 소프트웨어 프로덕트 라인은 은총알이 아니다!
    • 우수한 품질은 명확한 품질 기준에서 나온다
    • QA는 체크리스트를 채우는 게 아니라 품질을 완성하는 것이다
    • 프로세스를 개선하려면 절차, 도구, 인력 모두 개선해야 한다.
    • CMMI와 애자일 방법론은 양립하기가 매우 어렵다
    • 애자일 방법론은 한물 간 방법론이 아니다!
    • CMMI가 적당한 조직이 있다!
    • 레거시의 저주를 피하려면 선배, 후배 모두 노력해야 한다
    •  
  • 02부_소프트웨어, 사람이 만든다!
    • 자격증이 프로젝트 관리자의 역량을 보증하지 못한다
    • 인본주의 관리가 효과가 있으려면 개발자의 자세가 매우 중요하다
    • 진짜 보수개발자와 진짜 진보개발자가 일하는 문화를 만들자
    • 업무가 중심이 되는 일터를 만들자
    • 야근은 필요악이라도 악일 뿐이다
    • 관리자는 회의를 하면 일을 한다고 생각한다. 이건 정말 착각이다!
    • 이해당사자의 역학관계를 파악하자
    • 일을 지정하기보다 범위를 정하자
    • 멋진 의사결정 결과보다 그 과정이 더 중요하다
    • 신입사원에게는 멘토링을 하자
    • 피드백이 성공하려면 문제에 대한 객관화가 먼저다
    • 이기지 않는 게 이기는 것이다.
    • 아이디어를 많이 얻으려면 말을 자르지 마라
    • 너무 적게 혹은 너무 많이 측정해서는 안 된다
    • 프로젝트 관리자는 완전한 잣대가 돼서는 안 된다
    • 갑질은 대물림해서는 안 된다
    • 을을 대하는 자세
    • 외호내혐 PM이 강한 팀워크를 만들 수도 있지만 그래도 문제는 있다
    • 관리자도 0.5MM는 힘들다
    • 영업을 하든 관리를 하든 둘 중에 하나만 하자
    • 권한이 없다면 관리할 수 없다
    • 성공일지라도 팀원이 꼭 좋아하는 건 아니다
    • 프로젝트에서 시간은 늘 부족하다
    • 열심히 일한 개발자에게 잠깐의 휴식이라도 허하라
    •  
  • 03부_위험을 감수하고 이익을 극대화하라!
    • 제안서나 기획서가 아무리 상세해도 불확실성을 최소화하지 못한다
    • 위험, 이슈, 문제를 구분하자
    • PM은 불확실성의 화신이다
    • 불확실성이 제거되지 않는다는 건 프로젝트가 망해간다는 명백한 증거다
    • 불확실성을 극복하려면 팀 내 이견을 최소화해야 한다
    • 일찍 실패하는 것이 좋다
    • 계획이 변하더라도 계획은 늘 세워야 한다
    • 프로젝트는 어쨌든 끝난다
    •  
  • 맺는 글
    • 오픈 이노베이션을 DNA화하라, 그리고 DNA의 핵심은 사람임을 잊지 말자!
  • p94 밑에서 2번째 줄

    빼와 살을 ---> 뼈와 살을

  • p127 5번째 줄

    그거에요 ---> 그거예요

  • p247 8번째 줄

    바랬기 ---> 바랐기

관련 글