2011년 1월 17일 월요일

기존 소프트웨어를 버리고 언제 새로 만들어야 할까?

Windows Vista가 나온지 얼마 되지도 않은 시점에서 Windows7이 나온다고 하더나 이제는 Windows8이 출시될 것이라는 얘기가 떠돌고 있습니다.
아이폰4도 출시된지 알마 안된 시점에서 아이폰5가 출시될 것이란 얘기가 나왔습니다. 어쩔 때는 이것이 진짜인지 그냥 루머인지 구분이 안되기도 합니다.

소프트웨어 개발을 제대로 이해하고 있는 사람들이라면 Windows7이 출시됨과 동시에 또는 이미 그 이전에 Windows8은 시작이 되었다는 것을 알 수 있습니다.

소프트웨어는 끊이 없이 업그레이드가 되어야 합니다. 그러다보면 새로운 요구를 더이상 담을 수 없는 시점이 오게 됩니다. 그래서 소프트웨어의 아키텍쳐도 끊이 없이 발전하게 됩니다. 

지금의 소프트웨어가 새로운 요구를 더이상 담을 수 없는 그릇이 되게 되면 이미 상당히 늦었다고 볼 수 있습니다.
미래에 생길 요구사항을 미리 예상하여 그 구조를 만드는 것이 소프트웨어 아키텍쳐링입니다. 물론 예언자처럼 미래의 모든 상황을 예측할 수는 없지만 상당부분 예측을 해야 하며 여기서 성공을 하느냐, 실패를 하느냐에 따라서 비즈니스의 성공이 달려있습니다.

그런데 현실에서 보면 소프트웨어 아키텍쳐를 바꿔야할 시점을 놓친 회사들이 매우 많습니다. 이런 회사의 특징은 다음과 같습니다.
  • 소프트웨어에 기능을 추가하거나 버그를 수정하려고 해도 기존의 소스코드가 워낙 복잡해서 분석도 어렵고 고치는데 시간이 많이 들어간다.
  • 버그를 수정해도 이전에 없었던 문제가 자꾸 다시 생겨난다.
  • 유지보수에 바빠서 신규 제품 개발은 꿈도 못 꾼다.
  • 기존 제품을 잘 알고 경험이 많은 개발자들은 유지보수하느라고 바빠서 새로운 아키텍쳐를 연구할 시간이 없다. 그래서 신규 개발자를 투입했는데 진도가 안나간다.
뻔히 다 알다시피 우리나라 대부분의 소프트웨어 회사들은 초창기에 뛰어난 몇몇 개발자들이 주먹구구식으로 상당히 좋은 소프트웨어를 개발해서 좋은 평가를 받으면서 성장해왔습니다. 그런데 회사가 커지고 소프트웨어가 커지면서 작은 조직일 때는 드러나지 않은 주먹구구 방식 때문에 효율성이 급격히 떨어지게 됩니다. 그러다보니 항상 유지보수에만 매달리고 신규 개발에는 투자를 못하게 됩니다. 대부분의 경우 소프트웨어 아키텍쳐가 4~5년 넘어가게 되면 더이상 버티기 어려운 상황에 닥치게 됩니다.

이미 마지막 기회를 놓친 회사들은 끊임 없는 유지보수에 매달리면서 회사의 쇠락을 지켜볼 수 밖에 없습니다. 수많은 회사들이 지금이 마지막 기회라는 것을 인지하지 못하고 지나쳐 버리는 것을 보면 안타깝습니다. 그나마 영업이 잘되는 회사는 막대한 인원과 자금을 투입하여 점점더 되돌아 오기 어려운 길로 가버리기 때문에 회생하기 더 어려워 집니다. 이렇게 침몰하는 거대한 여객선 같은 소프트웨어 회사들이 상당히 많고 경영진들이 이를 알지 못하는 경우도 매우 많습니다. 경영진들은 개발에서 구멍이 났다는 것을 알아도 그 구멍을 어떻게 매워야 하는지 정확하게 모르는 경우가 대부분입니다. 그래서 이런 저런 시도를 하다가 침몰만 가속화 시키곤 합니다. 그래도 시도를 안할 수는 없겠죠.

그럼, "언제 다시 만들어야 하는지?" 질문으로 돌와와 보죠. 
회사마다 제품의 성격과 규모마다 다르지만 대부분은 첫번째 제품이 개발되면서 이미 두번째 제품의 기획도 시작이 되어야 합니다. 또한 두번째 제품을 누가 개발을 할지 언제 개발을 할지 계획을 미리 가지고 있어야 합니다.
첫번째 제품은 개발 후에 유지보수는 어떻게 진행을 하고, 누구는 두번째 제품에 투입이 되어야 하는지 등의 계획을 미리 가지고 있어야 한다는 뜻입니다.
이 얘기는 무슨 뜻이냐면 처음부터 개발을 체계적으로 하면 된다는 뜻입니다. 분석이 제대로 되고 설계가 제대로 되어야 해결이 된다는 얘기 입니다.

그럼 이미 첫번째 제품을 주먹구구식으로 개발을 한 회사는 어떻게 해야 할까요? 지금이라도 두번째 제품을 체계적으로 다시 기획을 해야겠죠. 주먹구구의 결과로 필요한 상당히 많은 자료는 개발자들의 머리속에 들어 있습니다. 이것들을 끌어내서 문서화 하면서 두번째 제품을 기획하고 분석을 해내야 합니다. 개발자들은 이미 기본의 제품이 가지고 있는 문제점과 개선점을 아주 잘 알고 있습니다. 문제는 이것들이 문서화가 되어 있지 않고 리뷰가 안되었다는 겁니다. 이것들을 문서로 끌어내는 것만으로도 두번째 제품의 상당한 스펙이 됩니다. 또한 업계 동향과 신기술도 끊임 없이 조사를 해야 합니다.

그럼 이미 두번째 제품을 만들 마지막 기회를 놓친 회사들은 어떻게 해야 할까요? 
늦었다고 생각할 때가 가장 빠른 때입니다. 쉽지는 않겠지만, 큰 고통이 따른 변화가 필요합니다. 기존의 영업의 손실을 감수하고라도 유지보수 정책의 전면적인 변화가 필요하며 새로 투자를 더 해야 할 수도 있습니다. 회사의 조직과 프로세스의 전면적인 개혁도 필요할 것입니다. 즉, 다시 원칙에 충실해야 한는 거죠. 이 과정에서 개발자나 회사 모두 고통이 따르겠지만 이렇게 해서 성공할 것 같으면 시도를 할 수도 있고 그런 확신이 없다면 그냥 지켜보는 수 밖에 없을 겁니다. 

귀사의 소프트웨어는 어느 시점에 와 있나요? 곰곰히 생각해보시기 바랍니다.

댓글 16개:

  1. 흠... 가만 보니 저희 회사가 주먹구구로 시작해서 나름 잘 됐는데 두번째 개선에서 죽 쑤는 중이네요.
    거기다 소통도 안되고 뒷방에서 뭔가 왔다갔다 하니까.. 걱정이네요.

    답글삭제
  2. 안녕하세요. 별의파편님
    이런 증상은 매우 흔합니다. 일반적인 과정입니다.
    두번째는 방법이 달라져야 합니다. 더이상 구먹구구는 안됩니다. 그런데 과거의 성공에 대한 환상을 가지고 있는 경연진은 몇몇 개발자들을 특공대처럼 구성해서 만들려고 합니다.
    하지만 이미 회사는 이전의 규모가 아니고 시장의 요구도 몇배 커졌기 때문에 십중팔구 실패를 맛보게 됩니다.

    답글삭제
  3. 제가 속한 회사도 이제 한 제품을 끝내려 합니다.
    한동안 정신없이 날밤 새다가 요새 정시 퇴근하며 기력을 되찾고 있습니다. 그렇지만 어딘가 허전한데 원인을 통 몰라 혼자 헤매고 있던 와중에 귀가 번쩍 뜨이는군요. 정말 감사합니다. 문서 기타 등을 정리하려면 막 끝낸 시점만큼 좋은 때가 없죠. ^^ 다른 팀원은 쉰다고 하더라도 저는 첨부터 끝까지 차분히 리뷰/정리해봐야겠습니다. ^^

    답글삭제
  4. 주먹구구가 되는 가장 큰 이유는 돈 문제죠.

    조직이 되었던.. 개발 프로세스를 관리 해줄 솔루션이든.

    만들어내고 도입을 할려면 자금이 들어가야 되고.

    더군다나 초기에는 주먹구구식이 비용이나 생산성에서 더 효율적입니다.

    적절하게 조직을 만들고, 프로세스 관리를 도입하는게 경영진의 몫이겠죠.

    개발자에게 관리까지 떠 넘기는건 문제가 있습니다.

    그런데 초기 핵심 개발자들이 진급하면서 관리롤이나 영업롤을 맡는 경우가 상당수라서..

    여기서 병목현상이 벌어지기도 합니다.


    개발자는 개발만 시키고..

    제품 라이프 사이클에 맞춰서 경영진이 현명한 판단을 해야곘죠.

    답글삭제
  5. 비판은 아니고요.. 의견입니다.

    주먹구구식으로 하는 개발 비용 vs 체계적인 설계를 해서 개발하는 비용
    두 비용은 비슷하다고 봅니다..

    초기비용은 전자가 덜 들겠지만 어차피 Q/A를 할 때 비용이 더 많이 들어가리라고 봅니다.

    핵심개발자가 진급하면 영업롤을 맡기는 회사라면 회사 자체에 좀 문제가 있지 않을까 합니다.

    답글삭제
  6. 안녕하세요. soma님
    더이상 시장이 없어서 단종을 하시는 것인지? 다음제품 또는 대체 제품을 만들고 이전 버전을 단종하는 것인지 궁금하군요.
    이전 제품을 차분히 분석해서 lesson learned 를 파악하는 것도 좋습니다. 하지만 끝나고 몰아서 정리를 해보는 것은 누락된 것이 엄청나게 만을 겁니다.
    평소에 wiki나 이슈관리시스템을 이용해서 전 개발자들이 모든 이슈를 정리하는 습관을 가지는 것이 좋습니다.
    이것들은 추후 중요한 스펙이 됩니다.

    답글삭제
  7. 안녕하세요. 쩝님
    개발자에게 관리를 맡기는 것은 저도 항상 반대를 합니다.
    대부분의 회사가 주먹구구로 개발을 하는 이유는 주먹구구밖에 방법을 모르기 때문이라고 생각하고 있습니다. 실제로 많은 소프트웨어 회사를 접한 저는 충분히 많은 사례을 가지고 있습니다.
    시간과 돈만 있으면 우리도 문서를 잘 만들고 체계적으로 개발할 수 있다고 하는 사람도 많지만 시간과 돈이 있어도 제대로 못합니다.
    또한 혼자 개발을 해도 체계적으로 개발하는 것이 더 빠릅니다.
    이것이 소프트웨어 공학에서 가장 이해하기 어려운 부분입니다. 이것을 이해하고 있다면 소프트웨어 공학을 이미 다 이해한 것입니다.
    체계적으로 개발하는 방법을 모르는 개발자나 회사는 오로지 주먹구구식으로 개발하는 방법밖에는 모릅니다.
    이 경우 프로젝트의 규모가 작다면 주먹구구식으로 개발을 해도 프로젝트를 성공할 가능성이 있습니다. 그래서 주먹구구에 대한 환상을 가지고 있는 경영자들도 많습니다.
    그리고나서 몇번 실패를 맛봐도 실패의 탓을 주먹구구 방식으로 돌리지 않고 개별 개발자나 다른 이유를 찾기도 합니다.
    경영자가 현명해져야 합니다.

    답글삭제
  8. 안녕하세요. 몽님
    몽님도 대체로 소프트웨어 공학을 이해하고 계신 것 같군요.
    하지만 조금더 이해를 하면 체계적으로 개발하는 것이 주먹구구 방식보다 비용이 적게 들고 프로젝트 시간도 절약된다는 것을 아시게 될 겁니다.
    여기서 "체계적"이라는 용어에 대해서 서로 오해를 합니다. 형식적인 프로세스밖에 경험하지 못한 개발자들은 "체계적"이라는 것을 천편일률적으로 생각하고 매우 거북한 것으로 생각합니다.
    "체계적"이라는 단어를 "효율적"으로 바꾸면 더 이해하기가 쉬울 겁니다. 설계를 하더라도 필요한 만큼 효율적으로 한다고 보면 됩니다. 이를 판단하기 위해서는 경험이 많이 필요합니다.
    그리고 유지보수 할 때는 말할 나위도 없죠. ^^

    답글삭제
  9. 좋은 정보가 많네요.
    "효율적"인 프로세스 도입이 좋은것은 자명하겠지만 현실적으로 그렇게 되지 않는데는 이유가 있겠지요.
    구성원들이 그 효율성에 대한 개념을 이해하기 위해서는 능력과 경력의 동반이 반드시 필요한 것 같습니다.
    게다가 현실적으로 몇 몇 뛰어난 개발자 및 경영자는 그런 프로세스 무시하고도 성공을 하는모습을보여주니
    대부분의 소규모 소프트웨어 개발회사들이 어떤 방법을 택할지 선택을 못하는 경우도 있습니다.
    우리나라 소프트웨어산업 발전 및 종사자들의 처우 개선을 위해서는 현실에 맞는 소프트웨어 공학의 발전이 우선되어야 하는건 아닌가 하는 생각도 듭니다.

    답글삭제
  10. 1. 이 블로그에 오면, 글도 글이지만, 댓글에서도 많은 것을 배우고 갑니다. 항상 좋은 글 올려주셔서 감사합니다.

    2. 그 때 칭찬해 주신 Mercurial 관련 글을 http://sainthkh.codex.kr/lec/Mercurial/mercurial.html 에 모아 두었습니다. 현재 서버 만드는 법에 대한 것이 좀 빠져서 아쉬운데 나중에 공부해서 꼭 올려보겠습니다.

    3. 나중에는 Mercurial 강좌 스타일로, 명세서 작성법에 대한 이야기가 하고 싶기는 한데, 언제가 될는지 모르겠습니다. 저조차 명세서 작성에 대한 글을 쓰기에는 너무 많이 부족하다는 생각을 해서요. 5페이지 정도 작성했던 GUI 관련 명세가 부실하다는 것을 깨닫고, 명세서 Refactoring을 시작했습니다.


    4. 지금 가르쳐주시는 많은 것들을 학교에서 가르쳐 주면 참 좋겠다는 생각을 합니다. 전에 한 번 동기들에게 Subversion 강의하면서 돌아다녔던 기억이 나네요... 교수님들도 이것들이 왜 필요한지 이해하지 못하시는 분들도 많은 것 같습니다.

    답글삭제
  11. 스피드님 안녕하세요.
    맞습니다. 평생 그렇게 해서는 구멍가게 밖에 못하죠. 또한 그런 프로그래밍영웅들은 주먹구구식으로 밖에 개발을 못해서 그런거죠.
    사실 프로그래밍영웅 개발자도 할말은 있습니다. 자신들도 제대로 배울 기회가 없었기 때문이죠.
    그래도 Open mind만 있고 소통이 중요하다는 것을 깨달으면 계속 주먹구구 방식을 고집하지는 않겠죠.

    답글삭제
  12. 안녕하세요. 주의사신님
    제 블로그에서도 명세(스펙, SRS)관련된 글이 많고 책에서도 가장 많이 강조를 하지만 소프트웨어를 개발하는데 있어서 가장 중요하고도 어려운 분야이기 때문에 글로 설명하기 쉽지 않을 겁니다.
    글을 올려주시면 같이 의논해볼 좋은 기회가 될 것 같습니다.
    소프트웨어 공학을 대학에서 가르치는 곳도 있었습니다. KAIST에서는 대학원 과정으로도 있습니다. 하지만 일부 대학 교수님 중에는 이론에 치중해서 실전에는 약한 분들도 있기는 합니다.
    단, 소프트웨어 공학은 학교에서 배웠다고 하더라도 실전에서 경험하지 않으면 진짜 배운 것이라고 하기 어렵습니다. 즉, 경험이 가장 중요하다는 말입니다.

    답글삭제
  13. 확실히 개발중인 모듈을 언제 포기하고 다시 재설계해서 만들어 낼지를 결정하는 것도
    상당히 힘든 선택이고, 이러한 결정 자체도 점점 두려워지더라구요.

    그래도 그 이전의 버전을 설계/개발하면서 가진 노하우가 있으니 금세 보완하고 더욱 좋게 만들수는 있지만 말이죠 ^^

    답글삭제
  14. 구차니님 안녕하세요.
    노하우는 축적되나 개발 방법에서는 별 진전이 없는 경우가 많습니다. 그래서 기술은 더 좋아졌으나 프로젝트에 실패하는 경우가 많습니다. 즉 시작은 더 오래 걸리고 품질도 떨어지곤 합니다. 또한 기존에 축적된 노하우만 추가하다보니 미래의 요구사항을 반영하지 못해서 금방 또 고쳐야 하는 요구가 생기곤 합니다.
    개발자가 골고루 실력이 향상될 수 있어야 하는데, 코딩 실력만 늘기 쉬운 것이 문제입니다.

    답글삭제
  15. 늦게 달게 됐군요.^^;
    단종/대체가 아니고 신규 제품을 처음 서비스하게 됐습니다.
    저야 개발자 입장에서 서비스 들어가니 이제 개발이 어느정도 끝났다고 생각하지만 뭐.. 현실도 그렇진 않지요. ^^; 다만 지금 제품의 다음 버전은 막 서비스하기 시작하는 지금 시점부터 준비하는게 가장 확실하다고 본문을 읽고 느끼게 됐습니다.

    답글삭제
  16. 끝낸다는 것이 프로젝트가 끝난다는 뜻이었군요.

    답글삭제