2008.01.04
좋은 소프트웨어를 개발하기 위하여(1)
2007. 10. 29
강은성
개발 프로세스는 분업과 협업을 위한 필수 요소
한두 명의 뛰어난 개발자가 제품 개발에서 결정적인 역할을 해 내는 하드웨어 개발과는 달리 소프트웨어 제품(패키지)이나 소프트웨어 서비스, 웹 기반 서비스, 소프트웨어가 제품의 핵심 요소인 보안 어플라이언스, 휴대폰과 같은 각종 임베디드 시스템 등의 소프트웨어 개발에서 많은 인력이 협업을 통해 높은 품질의 소프트웨어를 개발하는 것은 결코 쉬운 일이 아니다. 특히 지식 산업의 특성을 갖고 있는 소프트웨어 산업은, 독특한 개성을 가진 여러 개발자들이 함께 일해서 훌륭한 성과를 내기 위해서는 개발 회사가 무엇보다도 개발 프로세스와 개발 인프라, 개발 문화를 갖춰야 한다.
먼저 개발 프로세스부터 살펴 보자. 소프트웨어 개발 프로세스란 용어를 들으면 우리는 쉽사리 카네기멜론대학에서 개발한 CMMI(Capability Maturity Model Integration, 능력성숙통합모델)나 ISO에서 제정한 SPICE(Software Process Improvement and Capability dEtermination, 프로세스 개선과 능력 결정)를 떠 올리게 된다. 그러한 프로세스들이 좋긴 하지만, 해당 인증이 필요한 회사가 아니라면 굳이 꼭 그런 방식을 고집할 필요는 없다. 각 회사들이 나름대로 개발 프로세스를 수립할 수 있고, 이미 몇몇 회사에서 훌륭한 사례를 갖고 있다. 소프트웨어 패키지 회사로는 마이크로소프트의 것이 많이 알려져 있고, 임베디드 시스템 분야에서는 삼성전자나 엘지전자가 잘 갖추고 있는 것으로 알고 있다. 안철수연구소도 자체 개발 프로세스를 확립하여 운영한 지 4년이 넘었다.
개발 프로세스를 갖추는 장점은 무엇보다도 몇몇 개인의 뛰어난 역량에 전적으로 의존하지 않으면서 제품을 개발할 수 있다는 점이다. 담당 개발자가 퇴직해서 제품이 업그레이드 하기 어렵다고 한다면 그것은 제품을 개발하는 회사로서는 치명적인 일이다. 실제로 벤처기업들이 이러한 경험을 하는 경우가 종종 있다. 개발 프로세스에 따라 개발을 하면, 요구명세서나 설계서, 코딩 규약과 코드 리뷰에 따라 문서와 소스 코드가 작성되고 공유되면서 개발이 진행되기 때문에 특정인에 대한 제품의 의존도를 크게 줄일 수 있고, 전사적인 역량으로 제품을 개발할 수 있게 된다.
개발 단계별로 품질을 관리하면서 발생할 수 있는 버그를 크게 줄일 수 있다는 점도 큰 장점이다. 코딩이 끝난 뒤에 테스트를 통해 버그를 발견, 수정하거나 출시된 뒤에 버그를 고치려면 많은 시간과 노력이 드는 데 비해, 요구 분석 단계나 설계 단계에서 올바로 분석, 설계를 하면 버그를 발생시키지 않을 수 있고, 문제를 사전에 발견하기 때문에 고치는 비용이 크게 줄어든다. 요구분석 단계에서부터 품질 관리(QA) 엔지니어들이나 UI 디자이너, 기술문서 작성자(Technical Writer) 등이 개발자들과 함께 작업을 하면, 제품의 품질도 상당히 높일 수 있다.
또한 개발 프로세스가 있으면 제품기획을 할 때부터 제품의 출시 때까지 해야 할 일들을 미리 알 수 있고, 각 프로세스 별로 걸리는 대체적인 일정이나 인력 규모를 산정할 수 있어서 제품 개발 과정 전체와 인력을 적절하게 관리할 수 있다. 또한 개발자 역시 자신이 지금 할 일과 다음에 할 일들을 충분히 인지하면서 개발을 진행할 수 있는 것도 좋은 점이다.
개발 프로세스가 있을 때 단점으로 흔히 지적되는 것은 그것이 없을 때보다 개발 기간이나 인력이 많이 든다는 점이다. 프로세스를 수립하는 것은 분업을 바탕으로 협업을 하기 위한 것인데, 해당 프로세스 담당자들은 자신의 전문 분야별로 계속 하고 있는 일이 있기 때문에 특정한 일로 인해 일정 변경이 쉽지 않고, 연관된 프로세스 담당자들 사이에 의사소통이 필요하기 때문에 한두 명의 뛰어난 엔지니어들이 자신의 전 생활을 바쳐 전체 프로세스를 담당할 때보다 일정이 늦어진다. 하지만 일정을 어느 정도 앞당기는 것보다 더욱 중요한 것이 제품의 품질이라고 본다면, 사전 준비와 체계적인 개발을 통해 극복해야 할 점으로 보는 것이 타당할 것이다.
한 가지 유의해야 할 점은 개발 프로세스는 구축하는 것도 매우 중요하지만, 회사나 제품의 변화를 반영하여 지속적으로 개선되어야 한다는 점이다. 기술 개발을 위해 파일럿 프로젝트를 하거나 제품의 유지보수를 위해 핫픽스를 낼 때와 같이 품질보다 속도가 더 중요한 프로젝트가 있다면 좀더 간단한 프로세스를 만들어 적용하는 등 유연성을 갖출 필요도 있겠다.
개발 문화로 발전해야
둘째로 이러한 프로세스를 잘 구축하는 것과 함께 개발 인프라를 갖추는 일이 필요하다. 프로세스가 아무리 잘 수립되어 있다 하더라도 개발 인프라가 구축되어 있지 않으면 개발자들이 실제로 적용하기가 힘들기 때문이다. 개발자들은 손쉽게 사용할 수 있는 도구를 통해 요구분석, 설계 등 각 프로세스를 수행할 수 있고, 프로젝트 관리자는 전체 프로젝트 일정과 인력을 쉽게 관리하고, 프로세스팀은 프로세스 진행 현황을 점검하기 쉬운 체계를 구축해야 한다.
또한 버그(이슈) 트래킹 시스템이나 빌드 시스템, 소스 관리 시스템은 개발을 위한 없어서는 안 될 인프라이다. 버그(이슈) 트래킹 시스템은 버그(이슈)의 등록과 수정, 확인, 제품 패치까지 버그의 일생뿐 아니라 해당 버그나 추가 기능 요구가 다음 패치나 업그레이드 제품에 적용되는지까지 관리할 수 있는 도구다. 빌드 시스템은 소스 관리 시스템에서 소스들을 받아서 최종 바이너리를 만드는 시스템이다. 특히 일일 빌드 체계를 갖춰야만 계속 변경되는 소스들 중 누가 등록한 소스에서 버그가 생겼는지 알 수 있기 때문에 대규모로 협업을 할 때에는 반드시 필요한 도구다. 소프트웨어 개발 회사에서 소스 관리 시스템의 중요성은 아무리 강조해도 결코 지나치지 않다. 이러한 시스템들은 굳이 돈을 들이지 않더라도 쓸 수 있는 공개 소스들이 많이 있어서 개발팀이나 개발 관리자들이 의욕만 있다면 충분히 구축할 수 있을 것이다.
개발이 한 차원 더 높게 발전하기 위해서는 개발 프로세스와 개발 인프라가 ‘개발 문화’로 정착되어야 한다. 보통 프로세스란 것이 프로세스팀의 점검이나 각 프로세스 담당 팀의 상호 검증을 통해 강제해야 제대로 수행되는 것이 보통이지만, 그것들이 각 개발 담당자들의 몸에 배어 있고, 개발이나 마케팅, 영업, 기술지원 등 모든 부서에서 문화로 확립되어 있다면, 모든 프로세스나 개발 인프라의 활용이 자연스럽게 수행되고, 제품 개발에 관련된 시장의 요구사항이 물 흐르듯 제품 출시까지 이어질 수 있을 것이다. 이는 모든 소프트웨어 개발 회사에서 바라는 일이 아닐 수 없다.
좋은 소프트웨어를 개발하기 위해서
한 걸음 더 나아가면, 제품에 대한 로드맵을 만들고 유지해야 좋은 소프트웨어를 만들 수 있다. 당장 출시할 제품에 대한 기능을 작성하기도 급급한데, 뜬금없는 소리로 들릴 수도 있을 것 같다. 하지만 최소 1년, 좀더 고민해서 2년 정도의 제품 로드맵이나 기술 로드맵을 만들어 놓고, 1년에 2번 정도 갱신하게 되면, 고객사의 기능 추가 요구에 대해 제품 로드맵을 갖고 설득할 수 있고, 개발 측면에서는 필요한 기술이나 제품 요소, 인력을 사전에 준비할 수 있으며, 경쟁사의 제품이나 기술도 미리 들여다볼 수 있어서 좋은 제품을 개발하는 데에 크게 도움이 된다.
위에서 설명한 것들이 모두 없다 하더라도 좋은 소프트웨어를 개발할 수 있다. 하지만 그러기 위해서 몇몇 개발자들이 열정과 헌신, 엄청난 초과 노동시간을 쏟아 붓는 것에 기대는 경우이다. 이는 소프트웨어 엔지니어들이 소프트웨어 업계를 떠나는 이유가 되고 있고, 해당 제품 역시 지속적인 발전을 이루지 못하고, 중도 하차하는 주요 원인이 된다.
요즘 정보통신부, 언론, 업계 등 여러 곳에서 소프트웨어 인력 양성이나 수급에 대한 논의가 이뤄지고 있다. 학교나 정부에서 할 일이 있지만, 소프트웨어를 개발하는 업계에서 할 일도 매우 중요하다. 아무리 고급 개발자들이 있다 하더라도 개발 프로세스와 인프라, 문화가 갖춰 있지 않은 곳에서 일하면, 그들은 ‘소모’된다고 느끼다가 대기업으로 자리를 옮기거나 아예 업계를 옮기기도 한다. 좋은 소프트웨어를 만들기 위해서는 시장도 있어야 하고, 좋은 인력도 있어야 한다. 하지만 좋은 개발 문화를 갖추지 않고서는 중장기적으로 소프트웨어 개발 업체에 희망이 없다.
강은성 상무는 안철수연구소에서 사용자의 IT 자산을 지키는 보람과
즐거움으로 일하고 있으며, 어린이들도 즐겁게 뛰놀 수 있는 안전하고
편안한 인터넷 세상을 만드는 꿈을 갖고 있습니다.
'AhnLab 칼럼' 카테고리의 다른 글
[칼럼]개인정보보호는 최소한의 권리다. (0) | 2020.04.19 |
---|---|
[안철수연구소 중국법인]보안업무의 서비스 특징 (0) | 2020.04.19 |
좋은 소프트웨어를 개발하기 위하여(2) (0) | 2020.04.19 |
[안철수연구소 중국법인]신제품 발표회에서의 연설내용 (0) | 2020.04.19 |
보안 전문가가 되려면 (0) | 2020.04.19 |