[IT/리뷰] 글로벌 소프트웨어를 꿈꾸다

글로벌 소프트웨어를 꿈꾸다 : 네이버 도서 (naver.com)

글로벌 소프트웨어를 꿈꾸다 : 네이버 도서

2010년에 초판 발행된 책이라, 현재 국내 IT 회사들과 상황이 꽤 다를 것이라 생각된다. 그래도, 실리콘밸리에 있던 회사들의 모습을 훔쳐볼 수 있지 않을까 해서 이 책을 골랐다. 책에서는 저자가 실리콘밸리에서 일할 때 본 회사들의 모습과 국내로 와서 국내 기업들을 컨설팅하면서 본 모습들을 통해 어떤 점들이 달랐는지 설명해주고 있다. 물론 국내 기업들의 잘못된 모습들을 지적하며, 글로벌 기업들과 다른 한국 시장의 특징과 고쳐나가야 하는 것들에 대해 얘기한다.

 

아래에 책을 읽은 뒤 정리한 내용들을 작성했지만, 요약하자면 대부분은 아래와 같다.

• 필요한걸 알면서 안 한다.
• 필요한 걸 알면서 도입을 하고 잘못 사용한다.
• 형식적인 것에 빠져있다.
• 전체적인 문화적인 부분이 개선되어야 한다.

요약만 봐도 대강 알겠지만, 기술적인 부분은 거의 다루지 않는다. 해봤자 글로벌로 출시를 위해서는 설계 당시 고려를 해야 한다는 내용이다. 네트워크를 고려해야 하고, 다양한 언어로의 전환, 다양한 플랫폼 및 도메인을 고려해야 한다는 내용이다.

 

글을 읽으면서 우리 회사도 많이 개선이 필요하다는 것을 느꼈다. 책을 읽으면서 책에 없던 내용들도 필요해 보였다. 가장 크게 개선이 필요하다고 느낀 것은 CI/CD 도입, CTO 도입, 이슈관리시스템 활성화, 형식이 아닌 실용 위주의 프로세스다. 또, 우리 회사도 한 번 컨설팅을 받아보게 하고 싶다. 경영진에서 건의를 받아들여 컨설팅을 할지, 컨설팅 결과를 받아들일지를 모르겠지만 말이다.

 

다니고 있는 회사에 대입해보더라도, 2010년에 발행된 책이지만 현재에도 많은 회사들이 뜨끔할 내용들이 많아 보인다. 책을 읽으면서 느끼는 것이 국내 기업들은 '기본'이 잘 되어 있지 않았구나 싶었다. 책에서는 계속해서 '기본'에 집중하며, '기본'을 이론적으로 도입하고 아는 것이 아니라 잘 사용해야 한다고 강조하고 있다. 현재 22년에는 다른 회사들은 어떻게 운영되고 있는지 궁금해졌고, 우리 회사도 '기본'을 잘 지키는 회사가 됐으면 한다. 그리고, 이런 '기본'들이 잘 지켜지는 회사에서 근무하고 싶다고 느껴졌다.

 

컨설팅 업체가 궁금해 저자에 대해 검색해봤더니 블로그도 발견했다. 아래는 저자의 블로그다.

Ike Kim's Wisdom on Software (김익환의 소프트웨어 지혜): About Us (ikwisdom.blogspot.com)

 

아래는 책을 읽으면서 정리한 내용들의 일부다.

---

• 영웅 개발자가 나오지 않는 환경을 회사가 만들어야 한다. 회사 처음에야 영웅 개발자 덕분에 승승장구하는 것처럼 보여도, 영웅 개발자가 있으면 어떻게든 문제가 생기게 된다.
• 지휘자 아키텍트는 한국에서 반드시 필요한 존재다. 관리직을 더 우대해주지말고 개발자를 더 우대해줄 필요가 있다. 영업과 개발이 의견 충돌이 있더라도 개발 의견을 따라야 한다. 설득을 할 수는 있겠지만. 구글도 개발자 의견이 우선이다.
• 천재 경영자가 필요한게 아니라 개발자를 우대하고 존경하는 기업 문화를 만드는 경영자가 필요하다. 그러면 자연스럽게 소프트웨어 전문가가 생길 것이다.
• 결국 소프트웨어가 성공하기 위해서는 5가지 기반 시스템 / 조직 / 프로세스 / 기술 / 문화가 필요하다. 프로세스는 과해도, 안 해도 안되며, 준비가 된 상태에서 도입해야 한다. 기술은 지나쳐도 되지만, 단기적으로 필요한 만큼 배워 쓰는 것이 효율적이다. 기술들은 계속해서 많이 나오고 기술별로 수명도 짧기 때문이다. 문화는 참여 / 공유 / 개방 3가지 키워드를 항상 기억하자.
• SRS는 '기능 명세서'나 '요구사항 명세서'가 아니다. 그냥 SRS다. 이름을 바꾸니 SRS를 단순히 기능만 적으면 되는줄 아는데, 기능 명세서는 SRS의 일부다.
• SRS는 어떤 기법이나 형식이 아니다. 따라서, 템플릿을 채우는 단순한 목적이 아니다. '어떻게 적는가'가 핵심이다. IEEE의 수많은 실전 전문가가 가이드를 작성한 것을 보면 매우 간단하게 작성되는 것을 알 수 있다. 즉, 템플릿 형식이 아니더라도 가이드에 맞게 쓰면 훌륭한 SRS가 된다.
• SRS를 단순히 문서의 형식으로 생각하지말고, 개발 최소 비용과 최소 시간이 소요되게 하기 위해 작성되는 문서로 생각해야 한다. 그러다 보니, 목적을 위해서는 1페이지짜리 SRS가 있을 수도 있다.
• 다른 관점에서, SRS는 모든 부서의 사람이 동시에 개발에 참여할 수 있는 문서를 만드는 데 목적이 있다. 개발자는 SRS를 보며 개발을 하는 것은 당연하지만, 마케팅, 영업 등에서도 SRS를 참조하며 업무를 진행한다는 것이다. 다른 부서를 위한 내용도 SRS에 적기 때문에 SRS는 단순히 기술만 적혀있는 문서가 아닌 것이다.
• SRS에서 템플릿은 정보 공유를 체계적으로 해주기 위한 용도로써 도움을 준다. 그렇다하더라도, 템플릿이 먼저가 아니라, 작성되는 내용이 먼저다. SRS의 내용을 보조하는 게 템플릿이 되어야 한다.
• SRS를 쓰는 목적은 '무엇'이 아니라 '왜'이다. 단순히 템플릿을 채우는 것이 목적이 아니라, 고객이 원하는 품질 좋은 소프트웨어를 최소시간 최소비용으로 개발하기 위해 필요한 모든 것을 '왜'에 기반해 작성되어야 한다. 그러고 나서, '왜'에서 '무엇'으로 진행되는 과정을 적어야 한다.
• 단순히 초가집과 양옥집 중에 잘 지은 집은 무엇일까 생각해보면, 양옥집이라 할 것이다. 하지만, 잠깐 살 집을 지어야 하는데, 초가집이 아니라 양옥집을 짓는다면 잘못된 것일 것이다. 잘 쓰인 SRS는 그 목적에 따라 적히는 양과 질에 엄청난 차이가 있으며, 차이가 있어야 한다.
• 실용적인 방법론은 개발을 실용적으로 하기 위한 것이 주목적이라 형식에 지나치게 치우쳐있지 않다. 문서도 개발을 효율적으로 하기 위한 정도의 문서만 작성한다. 대부분의 실리콘밸리 회사는 거대한 방법론을 도입하지 않는다. 설령 회사에 세계적인 방법론이 있더라도 모든 프로젝트에 그대로 사용하지 않는다.
• 회사에 CTO는 필수다. 회사에서 CTO는 기술에서의 최고가 되어 있어야 한다. 다른 관리직은 CTO를 하면 안된다. 연구소장, 부사장 등 '장'이 들어간 관리직은 CTO를 하면 안 된다. 관리직은 인사 업무 때문에 기술 업무와 멀어지게 된다.
• CTO의 권한은 절대적이어야 한다. CEO나 연구소장과 같은 관리자가 CTO의 결정을 좌지우지할 수 없어야 한다. 국내 회사는 대부분 이렇게 절대적인 CTO가 없다. 애초에 경쟁사도 CTO 자체가 없다 보니까 모든 회사가 CTO 없이도 운이 좋으면 성공할 수 있는 것이다. 하지만 글로벌 시장에서는 먹히지 않는다. CTO의 부재로, 미성숙한 개발자가 잘못된 결정으로 프로젝트를 망치지 않도록 해야 한다. 심지어 연구소장의 결정을 바로잡아주는 것이 CTO의 역할이기 때문에 반드시 필요한 존재다.
• 200이 목표인 회사가 100에 안주하고 있다면, 그 회사는 반드시 죽는다. 자극없이 현재에 안주하는 회사는 도태된다.
• '일체유심조'라는 말이 있듯이, 믿느냐 안 믿느냐는 개인에게 달렸지만, 실제 생각이 행동에 미치는 영향은 매우 크다. 간혹 우리 회사는 다른 소프트웨어 회사와 다르다는 광신이 보인다. 이런 경우, 어떤 조언도 거부하게 되고 좋은 것을 받아들이지 못하게 되어 결과적으로 악순환에 빠지게 된다.
• 소프트웨어 회사들의 본질은 같다. 패키지 회사, IT 서비스 회사, 임베디드 소프트웨어 회사 등은 모두 정부가 나눈 틀일 뿐이다. 분류 저체가 잘못된 것은 아니다. 하지만, 위의 분류는 관점을 다르게 보면, 회사나 개발자와 관련이 없는 분류다. 근본적으로는 같기 때문에 근본적으로 우리 회사는 상황이 다르다는 것은 오판이다.
• 분리 발주와 분할 발주가 있다. 한국에서 분할 발주는 잘 되어있지 않다. 분할 발주를 할 때, 분석 / 설계 / 개발 중 분석과 설계 / 개발로 단계를 나눠야 한다. 분석 / 설계 그리고 개발로 나누는 경우는 잘못된 것이다. 그리고, 분석 단계에서는 해당 업무 전문가가 아닌, 전문 소프트웨어 분석가가 필요하다.
• 동료검토는 모든 산출물과 산출물을 만들어내는 전략, 모든 것을 대상으로 한다. 하지만 동료검토 전에 선행되어야 할 게 있다. 그것은 미리 설계를 검토하는 것이다. 코드 리뷰 때 단순히 컨벤션이나 문법을 보는 게 아니여야 한다. 설계를 마친 뒤에 개발까지 했는데, 설계를 트집 잡는 게 아니여야 한다. 설계 단계에서 Input / Output과 같은 것들을 먼저 검토해야 한다. 그러고 코드 리뷰도 이어서 해야, 동료 검토를 제대로 하는 것이다.
• 표현이 진보를 가져다주지 않는다. UML을 잘 쓴다고 설계를 잘 하는 것이 아니다. 설계는 머리에서 하고, UML은 표현만 도와준다. 실제로 스티븐 호킹을 예로 들어보자면, 루게릭병에 걸려 몸을 움직이지 못하지만 머리로 모두 생각해 눈으로 표현한다. 그 결과, 스티븐 호킹은 갈릴레이, 뉴턴, 아인슈타인 다음으로 평가받는다.
• 이론 중심의 Scientist, 기술 중심의 Technician 모두 회사에 필요한 존재다. 하지만, 회사에서 가장 중요한 건, 개발자 Engineer다. 개발자는 암묵적 지식의 소유자다. 그러다 보니, Scientist와 Technician에 비해 뽐내기 힘들 수 있다. 설계를 잘하는 것과 UML을 잘 아는 것은 다르다. 개발을 잘하는 것과 Eclipse를 잘 쓰는 것과 다르다. 실제 요구사항 분석과 개발을 잘하는 것은 방법론을 잘 아는 것과 다르다. 전자의 것들을 잘하는 것이 개발자다.