2012년 2월 20일 월요일

소프트웨어 회사의 자산은?


소프트웨어 회사의 자산은 무엇일까?

흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이 소스코드들의 가치는 현저하게 떨어진다.

소프트웨어 회사의 진짜 자산은 문서다. 

정확하게 말하면 문서화 된 지식과 자료들이다. 문서화 되지 않는 정보들은 휘발성으로서 개발자들이 나가면 같이 사라지는 정보들이면 회사의 자산도 아니다.

이런 휘발성 정보와 개발자에 의존하는 회사는 수명이 얼마 남지 않았다.

문서화 된 지식과 자료는 문서 파일 형태로 저장되어 있을 수도 있고 시스템에 남아 있을 수 있다.
버그관리시스템,  Wiki, KMS 등에 남아 있는 정보들을 말한다. 

이런 정보들은 개발 시스템 및 개발 프로세스와 맞물려 원활하게 작성되고 리뷰가 되며 기록이 남는다. 기록된 자료는 사라지지도 않고 누구나 쉽게 접근 할 수 있고 결정적으로 관련된 사람들이 퇴사를 해도 그대로 남아서 가치를 발휘한다.

따라서 이렇게 남는 자료와 문서들은 본인이 퇴사를 해도 가치가 있을 정도로 적혀야 한다. 

반대로 생각해서 제대로 적지 않고 내가 퇴사를 하면 파악하기 어렵게 만들어 놓는다면 자신의 가치가 올라갈 것으로 생각하기도 한다. 하지만 그 효과는 퇴사 후에 나타나지 않고 당장 나타나기 시작한다. 당장 협업이 쉽지 않으면 스스로도 다 기억할 수 없을 뿐만 아니라 본인에 대한 평판도 나빠진다. 물론 회사 전체가 그런 분위기라도 서로 똑같다면 회사가 심각한 상태라서 말할 필요도 없다.

그럼 개발자가 회사의 자산이 아니면 무엇일까?

개발자는 회사의 미래이다. 

과거를 이렇게 잘 만들어 놓은 개발자들에게는 회사의 미래를 맡겨도 된다. 과거의 경험과 지식을 바탕으로 미래에 더 가치 있고 훌륭한 일들을 해낼 개발자들이다. 

그렇지 않고 과거에 망쳐 놓은 개발자들은 과거의 발목에 잡혀서 앞으로 나아가지는 못하고 옛날에 싸 놓은 ?을 치우느라고 세월을 다 보낸다. 가끔 이런 개발자들이 다른 개발자들에게 자신이 싸 놓은 ?을 치우지 않고 자신은 또 새로운 프로젝트를 하곤 하는데, 나아지는 것은 없이 이렇게 계속 저질러 놓으면 점점 치워야 할 ?이 많아질 뿐이고 한계를 넘어가면 회사는 더 이상 못 버티게 된다.

경영자들은 개발자가 문서도 없이 뭔가 뚝딱 만들어 내는 것을 신기하게 생각하지 말고 그런 행동이 얼마나 회사를 망치고 있고 회사의 자산을 축내고 있다는 것을 깨달아야 한다.

개발자가 회사의 자산을 자신의 머리 속에 보관하고 있다가 본인도 기억 못하게 하지 말고 밖으로 꺼내서 모두의 자산이 되도록 해야 한다. 

댓글 7개:

  1. 오타 수정 부탁드립니다.
    자신은 문서다 -> 자산은 문서다

    답글삭제
  2. 정말 좋은 글이네요. 100% 동감합니다. 잠시 코딩을 멈추고 대강 작성한 문서를 살펴봐야 겠습니다.

    답글삭제
  3. 경영자들이 보면 오해의 소지가 많은 글이라 생각합니다.

    이런 글을 읽고 개발자들에게 설계 혹은 메뉴얼을 DOC파일로 만들라고 쪼는 관리자가 생기지 않을까 걱정됩니다.

    Specification을 wiki에 만들어야 하는 것은 당연합니다. 하지만 문서 작업은 그 정도까지입니다. 전체 overview를 다루는 문서도 있으면 좋겠지만 아주 디테일할 필요는 없습니다.
    이정도가 적당합니다. http://www.chromium.org/developers
    링크는 가장 거대한 소프트웨어 프로젝트중 하나는 크롬의 디자인 문서들입니다.
    다 합쳐보았자 A4용지 200장도 않됩니다. 허접한 SI프로젝트의 설계문서만 몇천장이 되는것과는 너무 차이가 나지요?
    코드의 품질도 하늘과 땅 차이입니다.

    정작 중요한것은 소스관리 시스템과 버그추적 시스템입니다.
    WebKit으로 따지자면 https://bugs.webkit.org/ 가 되겠습니다.

    WebKit처럼 소프트웨어 업계에 거대한 영향을 미치고 있는 커다란 코드도 문서는 별로 없습니다.
    모든 토론과 의사결정은 버그추적 시스템과 메일링 리스트를 통해 이루어 집니다.

    중요한것은 문서를 얼마나 만드는 가가 아니라 생각합니다.
    개발자는 코드로 말합니다.
    개발자가 높은 품질의 코드를 만드는 개발 문화, 서로 코드 리뷰를 하면서 동료의 코드 품질을 압박하는 그런 문화가 중요한 것입니다.

    결론은 이 포스트는 오해의 소지가 많습니다.

    답글삭제
  4. 황동성님 안녕하세요.

    제 글들을 보고 오해하는 경영자도 많고 또한 개발자들도 오해를 많이 합니다.

    오해할 경영자들은 무슨 짓을 해도 이해를 시킬 수는 없습니다. 그나마 여기와서 글을 읽고 제가 쓴 책을 보고 관심이 있는 경우라면 아주 약간 낫겠지만 어차피 많은 경영자들은 그렇게 글을 보고 이해하기는 어렵습니다.

    이글 저글보고 오해하고 개발자를 괴롭히고 회사를 망치는 것은 그들의 역량입니다. 거기까지 인거죠.

    제 책과 글들을 보면 전체적인 맥락이 다 나와 있으니 참고하시면 좋을 것 같습니다.

    좋은 의견이신데 제 의견을 조금더 부연설명하면 다음과 같은 것이 있습니다.

    소프트웨어를 개발하는데 있어서 가장 중요하고도 어려운 것은 스펙(SRS)을 제대로 작성하는 것입니다. 스펙을 적는 이유는 프로젝트를 가장 적은 비용으로 가장 빠른 시간에 제대로 만들기 위함입니다.

    스펙문서는 대부분 Wiki로 만들지 않고 문서로 만듭니다. 스펙을 적는 Tool도 많기는 하지만 대부분 장사를 목적으로 한 것이지 별 쓸모가 없습니다. 가끔은 설계문서 없이 스펙문서만 가지고 개발을 하는 프로젝트도 있습니다. 어떤 문서를 만들고 개발을 할지는 상당히 자유롭고 프로젝트의 성격과 상황에 따라서 다릅니다. 이를 획일적으로 정하면 오히려 비효율적입니다.

    스펙을 적는 양도 설계와 구현을 할 수 있을 정도면 됩니다. 그런데 국내 SI회사들은 심한 경우 수십종의 몇만 페이지의 문서를 만들어 냅니다. 내용도 상당부분이 가짜로 만들어 낸 것들입니다. 고객이 나중에 보지도 않기 때문에 내용이 맞는지 검증도 안되죠. 해외 방법론을 핵심은 모르고 배껴다가 사용한 부작용이죠.

    또한 국내 대부분의 개발자들은 분석 역량이 아주 낮아서 스펙을 제대로 적지 못합니다. 이것이 소프트웨어 산업이 크는데 가장 큰 걸림돌 중 하나입니다.

    보여주신 링크는 자세히 살펴보지는 않았지만 크롬을 내부에서 개발할 때 사용하는 스펙 문서는 아닌 것으로 보입니다. 내부에서는 개발용 스펙 문서에 포함되어 하는 것들이 없더군요. 또한 소스코드는 공개해도 내부용 문서는 외부에 오픈하지 않습니다. 이 자료들은 외부개발자들을 위해서 별도로 만든 자료로 추측이 됩니다. 물론 이런 자료를 만들어낸 기초 자료가 스펙과 설계문서들이지요. 그래도 상당 부분 Open이 되어 있군요.

    소스관리와 버그관리는 기본중에 기본이죠. 문제는 제가 살펴본 국내 거의 모든 회사의 툴 사용 역량이 너무 낮다는 것이지요. Global 회사들과는 너무나 큰 차이가 납니다.

    Peer review도 아주 중요한데 스펙이 제대로 적히지 않았으면 코드리뷰가 제대로 진행되기 어렵습니다. 코드리뷰보다 설계리뷰가 중요하고 설계리뷰보다 스펙리뷰가 훨씬 중요하죠. 제 책에는 이런 여러 종류의 리뷰를 어떻게 진행하는지 설명을 하고 있습니다.

    제 글을 보고 오해는 하는 경영자가 많듯이 저희에게 컨설팅을 의뢰하는 회사의 경영자가 소프트웨어 개발에 대해서 너무나 모르는 경우들이 있습니다. 그런 경우에는 제가 쓴 책을 읽어보고 이해가 되면 다시 연락하라고 합니다.

    기초적인 이해가 부족하면 무슨 말을 해도 소용이 없습니다. 좋은 의견 감사합니다.

    답글삭제
  5. 실제로 소스 코드만 있으면 그게 전부 인줄 아는 경영자도 많습니다.

    "소스 코드도 다 있잖아! 뭐가 문제야!?"

    문서가 있으면 새로운 코드, 새로운 제품이 쉽게 나오지만...
    소스 코드가 있다 해서 금방 새로운 코드, 새로운 제품이 나오는 것도 아닐 뿐더러..
    레거시 코드의 오류에 미사용 코드까지 모두 품게되어 가장 최악의 결과로 나타날뿐이죠.

    소스 코드만 어디서 구해와서, "니가 이걸로 잘 만들어 봐!" 라는 마인드의 경영자를 보면..
    무슨 부귀 영화를 누리자고 이 바닥에 남아서 이런 꼴을 보나.. 싶기도 하죠.

    뭐 어차피 넘치는게 개발자고, 대충 데려다가 갈궈 놓으면 날밤 새서라도 아웃풋을 내 놓으니..
    정말 중요한 자산이 무엇이고, 이 자산을 효율적으로 잘 관리하려면 무엇을 해야하는지..
    별로 관심이 없어 보이는 듯 합니다.

    개발자의 머릿속에 있는걸 자산으로 만들 생각조차 않으면서..
    정작 저 자산을 머릿속에 품고 있는 사람들마저 허름하게 대하는 회사들 보면..
    그저 안타까울 뿐...

    답글삭제