Will be Prosumer's Revolution and Technical Revolution in the Future!
Linux User/Developer is also Windows User/Developer... Cross Platform Engineer...
"21C 공학인을 대통령, 국회의원으로 만들자!" "더욱 더 많은 동지분들이 공학제국 건설에 동참할 수 있도록 널리 알려주세요~" [ F = m * a ]
과학기술/공학인이 대한민국 국회 의석의 50% 이상을 확보하는 그날을 위하여~ ^___^
한두 명의 뛰어난 개발자가 제품 개발에서 결정적인 역할을 해 내는 하드웨어 개발과는 달리 소프트웨어 제품(패키지)이나 소프트웨어 서비스, 웹 기반 서비스, 소프트웨어가 제품의 핵심 요소인 보안 어플라이언스, 휴대폰과 같은 각종 임베디드 시스템 등의 소프트웨어 개발에서 많은 인력이 협업을 통해 높은 품질의 소프트웨어를 개발하는 것은 결코 쉬운 일이 아니다.
특히 지식 산업의 특성을 갖고 있는 소프트웨어 산업은, 독특한 개성을 가진 여러 개발자들이 함께 일해서 훌륭한 성과를 내기 위해서는 개발 회사가 무엇보다도 개발 프로세스와 개발 시스템, 개발 문화를 갖춰야 한다.
먼저 개발 프로세스부터 살펴 보자. 소프트웨어 개발 프로세스란 용어를 들으면 우리는 쉽사리 카네기멜론대학에서 개발한 CMMI(Capability Maturity Model Integration, 능력성숙통합모델)나 ISO에서 제정한 SPICE(Software Process Improvement and Capability dEtermination, 프로세스 개선과 능력 결정)를 떠 올리게 된다. 그러한 프로세스들이 좋긴 하지만, 해당 인증이 필요한 회사가 아니라면 굳이 꼭 그런 방식을 고집할 필요는 없다.
각 회사들이 나름대로 개발 프로세스를 수립할 수 있고, 이미 몇몇 회사에서 훌륭한 사례를 갖고 있다. 소프트웨어 패키지 회사로는 마이크로소프트의 것이 많이 알려져 있고, 임베디드 시스템 분야에서는 삼성전자나 엘지전자가 잘 갖추고 있는 것으로 알고 있다. 안철수연구소도 자체 개발 프로세스를 확립하여 운영한 지 4년이 넘었다.
개발 프로세스를 갖추는 장점은 무엇보다도 몇몇 개인의 뛰어난 역량에 전적으로 의존하지 않으면서 제품을 개발할 수 있다는 점이다. 담당 개발자가 퇴직해서 제품이 업그레이드 하기 어렵다고 한다면 그것은 제품을 개발하는 회사로서는 치명적인 일이다.
실제로 벤처기업들이 이러한 경험을 하는 경우가 종종 있다. 개발 프로세스에 따라 개발을 하면, 요구명세서나 설계서, 코딩 규약과 코드 리뷰에 따라 문서와 소스 코드가 작성되고 공유되면서 개발이 진행되기 때문에 특정인에 대한 제품의 의존도를 크게 줄일 수 있고, 전사적인 역량으로 제품을 개발할 수 있게 된다.
개발 단계별로 품질을 관리하면서 발생할 수 있는 버그를 크게 줄일 수 있다는 점도 큰 장점이다. 코딩이 끝난 뒤에 테스트를 통해 버그를 발견, 수정하거나 출시된 뒤에 버그를 고치려면 많은 시간과 노력이 드는 데 비해, 요구 분석 단계나 설계 단계에서 올바로 분석, 설계를 하면 버그를 발생시키지 않을 수 있고, 문제를 사전에 발견하기 때문에 고치는 비용이 크게 줄어든다. 요구분석 단계에서부터 품질 관리(QA) 엔지니어들이나 UI 디자이너, 기술문서 작성자(Technical Writer) 등이 개발자들과 함께 작업을 하면, 제품의 품질도 상당히 높일 수 있다. 또한 개발 프로세스가 있으면 제품기획을 할 때부터 제품의 출시 때까지 해야 할 일들을 미리 알 수 있고, 각 프로세스 별로 걸리는 대체적인 일정이나 인력 규모를 산정할 수 있어서 제품 개발 과정 전체와 인력을 적절하게 관리할 수 있다. 또한 개발자 역시 자신이 지금 할 일과 다음에 할 일들을 충분히 인지하면서 개발을 진행할 수 있는 것도 좋은 점이다.
개발 프로세스가 있을 때 단점으로 흔히 지적되는 것은 그것이 없을 때보다 개발 기간이나 인력이 많이 든다는 점이다. 프로세스를 수립하는 것은 분업을 바탕으로 협업을 하기 위한 것인데, 해당 프로세스 담당자들은 자신의 전문 분야별로 계속 하고 있는 일이 있기 때문에 특정한 일로 인해 일정 변경이 쉽지 않고, 연관된 프로세스 담당자들 사이에 의사소통이 필요하기 때문에 한두 명의 뛰어난 엔지니어들이 자신의 전 생활을 바쳐 전체 프로세스를 담당할 때보다 일정이 늦어진다. 하지만 일정을 어느 정도 앞당기는 것보다 더욱 중요한 것이 제품의 품질이라고 본다면, 사전 준비와 체계적인 개발을 통해 극복해야 할 점으로 보는 것이 타당할 것이다.
한 가지 유의해야 할 점은 개발 프로세스는 구축하는 것도 매우 중요하지만, 회사나 제품의 변화를 반영하여 지속적으로 개선되어야 한다는 점이다. 기술 개발을 위해 파일럿 프로젝트를 하거나 제품의 유지보수를 위해 핫픽스를 낼 때와 같이 품질보다 속도가 더 중요한 프로젝트가 있다면 좀더 간단한 프로세스를 만들어 적용하는 등 유연성을 갖출 필요도 있겠다.
◆개발 문화로 발전해야
둘째로 이러한 프로세스를 잘 구축하는 것과 함께 시스템을 갖추는 일이 필요하다. 프로세스가 아무리 잘 수립되어 있다 하더라도 시스템으로 구축되어 있지 않으면 개발자들이 실제로 적용하기가 힘들기 때문이다. 개발자들은 손쉽게 사용할 수 있는 도구를 통해 요구분석, 설계 등 각 프로세스를 수행할 수 있고, 프로젝트 관리자는 전체 프로젝트 일정과 인력을 쉽게 관리하고, 프로세스팀은 프로세스 진행 현황을 점검하기 쉬운 체계를 구축해야 한다.
또한 버그(이슈) 트래킹 시스템이나 빌드 시스템, 소스 관리 시스템은 개발을 위한 없어서는 안 될 시스템이다. 버그(이슈) 트래킹 시스템은 버그(이슈)의 등록과 수정, 확인, 제품 패치까지 버그의 일생뿐 아니라 해당 버그나 추가 기능 요구가 다음 패치나 업그레이드 제품에 적용되는지까지 관리할 수 있는 도구다. 빌드 시스템은 소스 관리 시스템에서 소스들을 받아서 최종 바이너리를 만드는 시스템이다.
특히 일일 빌드 체계를 갖춰야만 계속 변경되는 소스들 중 누가 등록한 소스에서 버그가 생겼는지 알 수 있기 때문에 대규모로 협업을 할 때에는 반드시 필요한 도구다. 소프트웨어 개발 회사에서 소스 관리 시스템의 중요성은 아무리 강조해도 결코 지나치지 않다. 이러한 시스템들은 굳이 돈을 들이지 않더라도 쓸 수 있는 공개 소스들이 많이 있어서 개발팀이나 개발 관리자들이 의욕만 있다면 충분히 구축할 수 있을 것이다.
개발이 한 차원 더 높게 발전하기 위해서는 개발 프로세스와 개발 시스템이 ‘개발 문화’로 정착되어야 한다. 보통 프로세스란 것이 프로세스팀의 점검이나 각 프로세스 담당 팀의 상호 검증을 통해 강제해야 제대로 수행되는 것이 보통이다. 하지만 그것들이 각 개발 담당자들의 몸에 배어 있고, 개발이나 마케팅, 영업, 기술지원 등 모든 부서에서 문화로 확립되어 있다면, 모든 프로세스나 시스템이 자연스럽게 수행되고, 제품 개발에 관련된 시장의 요구사항이 물 흐르듯 제품 출시까지 이어질 수 있을 것이다. 이는 모든 소프트웨어 개발 회사에서 바라는 일이 아닐 수 없다.
◆좋은 소프트웨어를 개발하기 위해서
한 걸음 더 나아가면, 제품에 대한 로드맵을 만들고 유지해야 좋은 소프트웨어를 만들 수 있다. 당장 출시할 제품에 대한 기능을 작성하기도 급급한데, 뜬금없는 소리로 들릴 수도 있을 것 같다. 하지만 최소 1년, 좀더 고민해서 2년 정도의 제품 로드맵이나 기술 로드맵을 만들어 놓고, 1년에 2번 정도 갱신하게 되면, 고객사의 기능 추가 요구에 대해 제품 로드맵을 갖고 설득할 수 있고, 개발 측면에서는 필요한 기술이나 제품 요소, 인력을 사전에 준비할 수 있으며, 경쟁사의 제품이나 기술도 미리 들여다볼 수 있어서 좋은 제품을 개발하는 데에 크게 도움이 된다.
위에서 설명한 것들이 모두 없다 하더라도 좋은 소프트웨어를 개발할 수 있다. 하지만 그러기 위해서 몇몇 개발자들이 열정과 헌신, 엄청난 초과 노동시간을 쏟아 붓는 것에 기대는 경우이다. 이는 소프트웨어 엔지니어들이 소프트웨어 업계를 떠나는 이유가 되고 있고, 해당 제품 역시 지속적인 발전을 이루지 못하고, 중도 하차하는 주요 원인이 된다.
요즘 정보통신부, 언론, 업계 등 여러 곳에서 소프트웨어 인력 양성이나 수급에 대한 논의가 이뤄지고 있다. 학교나 정부에서 할 일이 있지만, 소프트웨어를 개발하는 업계에서 할 일도 매우 중요하다. 아무리 고급 개발자들이 있다 하더라도 개발 프로세스와 시스템, 문화가 갖춰 있지 않은 곳에서 일하면, 그들은 ‘소모’된다고 느끼다가 대기업으로 자리를 옮기거나 아예 업계를 옮기기도 한다. 좋은 소프트웨어를 만들기 위해서는 시장도 있어야 하고, 좋은 인력도 있어야 한다. 하지만 좋은 개발 문화를 갖추지 않고서는 중장기적으로 소프트웨어 개발 업체에 희망이 없다. /강은성 안철수연구소 상무
눈팅만으로는 전체글을 볼 수 없습니다. 로그인하셔야 합니다.
He can do, She can do, why not me?
[한국리눅스유저그룹]의 글을 퍼가실때에는 반드시 [출처]를 표시해 주시는 센스가 필요합니다!
지금 이시간, 공부하고 있는 당신은 머지않아 최고가 될 것입니다. 즐겁게 공부하시고, 힘내십시오!
포스팅 글이 유용하셨다면 RSS를 구독하시면 됩니다.
유용하고, 좋은글 포스팅 바랍니다. 포스팅된 글은 (전세계)? 대부분의 소셜 사이트에 포스팅됩니다.
한국LUG 사이트는 1024 x 768 해상도(운영자 노트북:14")에 최적화 되어 있습니다. : LINUX FANSITE
WWW.LUG.OR.KR Server is made by CentOS Linux, P4 1.8G, Memory 512MB, Main HDD 160GB, Backup HDD 40GB and LAMP, qmail MTA.
CentOS Linux & Mozilla Firefox UTF-8 Base Created.
1998-2024 www.lug.or.kr Directed By Great Dragon, Kim.
Top
LUG 포인트 정책 : [회원가입 : +100점] [로그인(하루한번) : +100점] [글쓰기 : +20점] [코멘트 : +10점] [다운로드 : -200점] [질문 포인트 : 최소 200점]
데스크탑 프로그래밍(gcc, g++, wxGTK[wxWidgets] 등)은 "Fedora"를 사용하고, 서버 운영(WEB, FTP 등)은 "CentOS"를 사용하시길 권장합니다.
도전하는자, 자신을 투자하는자만이 뜻하는바를 이룰 수 있다.
Information should be Exchanged with Interactive, not One Way Direction.
준회원,
정회원,
우수회원,
VIP회원,
기업회원,
관리자 Be Maker!
인생에서, 100% 순이익을 보장하는건 없다. 1%의 지식을 나눔으로써, 가끔씩 손해볼 필요도 있다.
그대가 가진 1%의 지식만이라도 공공을 위해 포스팅하라. 손해본다는 생각이 앞선다면 그대의 인생은 힘들어질것이다.
자신이 가진 지식의 1%도 투자하지 않고, 오로지 자신의 이익만 탐하는자와는 동지가 되지마라.
만나서 대화하면 모두 좋은 사람들이지만, 유독 인터넷에서만 자신을 밝히지 않고, 좀비로 서식하는 사람들이 많다.
부지불식간[不知不識間], 좀비(하류) 인생이 될지도 모르니, 항상 자신을 경계하도록 하라.
[도서 안내]
1. CentOS Linux
2. gcc로 공부하는 C++
베스트셀러 입성^^