스타트업에서 SW 개발에 꼭 필요한 시스템

소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.

회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.

1. 소스코드관리시스템

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Bitbucket, Github

추천 시스템: Git, SVN

소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.

호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.

Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.

2. 이슈관리시스템 (버그추적시스템)

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Atlassian Jira OnDemand

추천 시스템: Jira, Redmine

요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.

과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.

3. 빌드시스템

필요성: ★★★☆☆

추천 형태: 자체 구축

추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)

위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.

적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.

4. Wiki

필요성: ★★☆☆☆

추천 형태: 호스팅

추천 시스템: Confluence OnDemand

꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.

Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.

스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.

5. 프로젝트관리시스템

필요성: ☆☆☆☆☆

추천 시스템: 시스템보다는 엑셀 파일 이용

시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.

일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.

기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.

소스코드관리시스템

1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.

2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.

3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.

4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.

이슈관리시스템

1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.

2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.

3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.

4. 모든 이슈는 전 직원에 오픈한다.

지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.

기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.

소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.

이글은 Techit에 기고한 글입니다.

기반시스템(Infrastructure System)을 사용하고 계신가요?

기반시스템(Infrastructure System)란 용어를 들어보신 적이 있나요?

기반시스템(Infrastructure system)은 소프트웨어를 개발하는데 꼭 필요한 기초 환경입니다.

여러분들도 쓰고 계시는 것이 있을 겁니다. 소스코드를 CVS에 저장하고 버그를 관리하기 위해서Bugzilla나 Mantis를 사용하고 있다면 바로 그러한것들이 기반시스템(Infrastructure System)입니다.

이러한 것들은 매우 다양한 분야에서 소프트웨어 개발을 돕고 있습니다.

기반시스템 없이는 생산적으로 소프트웨어 개발할수 없습니다. 기반시스템은 소스코드를 안전하게 보관해주고, 프로젝트 구성원 간의 의사소통을 원활하게 해주는 등 프로젝트의 모든 활동이 잘 진행되도록 돕습니다. 또, 개발자들을 편하게 해주고, 불필요하게 노력을 낭비하지 않게 해주며, 개발에 집중할수 있게 해줍니다. 성공적인 프로젝트는 거의 다 적절한 기반시스템 하에서 개발 된 것이라고 보면 됩니다.

기반시스템에는 좋은 오픈 소스(Open Source) 솔루션이 아주 많습니다. 세계적인 소프트웨어 회사들도 기반시스템으로 오픈 소스 솔루션을 애용하고 있습니다. 특별한 이유가 있는 경우가 아니라면 비싼유료 제품을 사서 쓸 필요가 없습니다.

그러면 수많은 기반시스템 중에서 무엇은 꼭 필요하고 어떤 것은 당장 필요하지 않을까요?

이는 회사에 따라서 상황이 달라질 수 있습니다.

아래 그림은 각 기반시스템의 난이도와 효과를 설명한 것이다. 오른쪽으로 갈수록 도입이 쉽고, 도입시 쉽게 적응할 수 있는 시스템이다. 또 위로 갈수록 도입 시 효과가 크고 프로젝트에 많은 영향을 미치는 것들이다. 아직 아무런 시스템을 도입하고 있지 않는 회사라면 오른 쪽 윗부분의 영역에 있는 시스템부터 차례대로 도입하는 것이 좋을 것이다.

아직 소스코드관리시스템과 버그관리시스템을 사용하고 있지 않다면 가능하면 빨리 도입해야 합니다. 이 두 기반시스템은 어떤 소프트웨어 회사이건 필수적으로 필요하기 때문입니다. 

스타트업을 위한 조직론

스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.

첫째 기반시스템 활용

소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.

둘째 문서다.

흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.

셋째 역할구분이다.

스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.

지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.

이글은 Tech it에 기고한 글입니다.

책소개 - 소프트웨어개발의모든것(All of Software Project)

이번에 집필한 책입니다.

소프트웨어 개발의 전반에 대한 기초에 대해서 다루고 있습니다.

코딩을 어떻게 하느냐하는 내용이 아니고 소프트웨어 회사라면 당연히 갖춰야 할 기반시스템, 조직, 프로세스 등에 대해서 현실적이고 체계적으로 정리를 했습니다.

책을 쓰면서 가장 어려운 점은 가능하면 많은 소프트웨어 개발자들이 볼 수 있도록 난이도를 조정하는 것이었습니다. 어차피 책이라는 것이 모든 사람의 눈에 맞출 수는 없으니까요.

그리고 너무 자세한 내용을 기술하지 않은 이유는 그러기에는 수천페이지도 모자를 수 있고, Detail한 내용은 또 많은 경로를 통해서 얻을 수도 있고 일부는 스스로 공부를 하거나 훈련을 해야하는 것이라고 생각했습니다.

그래서 소프트웨어 개발 및 프로젝트를 전체적으로 볼 수 있는 책으로 구성을 했고, 추후 쓰게될 책이나 블로그를 통해서 점점 디테일에 접근을 해나가려고 합니다.

책을 읽으신 독자분이나 그렇지 않은 분이나 블로그를 통해서 소프트웨어 개발에 관한 어떤 얘기도 의견을 주고 받고 싶습니다.

책 소개를 한번 보시죠. 

책소개

대한민국 소프트웨어 분야 권위자인 김익환 대표와 전규현 수석이 제시하는 소프트웨어 개발 필드매뉴얼!  실리콘밸리의 GE, SUN Microsystems와 안철수연구소의 CTO 등을 거치며 소프트웨어 개발 분야의 야전사령관으로 활동해 온 김익환 대표와, ‘한글과컴퓨터’ ‘안철수연구소’ 등을 거치며 현장을 리드해 온 전규현 수석이 제시하는 ‘소프트웨어 개발 실행 지침서’이다.  많은 소프트웨어 개발자들이 프로젝트 진행에 대해 제대로 배울 기회를 갖지 못한 채, 과거부터 해오던 방법을 그대로 답습하고 있다. 그런 상태로 매일 프로젝트에 투입되다 보니, 야근에 야근을 거듭해도 프로젝트가 언제 끝날지 모르는 상황에 빠져들곤 한다. 이 책은 그간의 이 같은 문제를 해결하고 소프트웨어를 성공적으로 개발하기 위해 반드시 알아야 할 ‘조직’ ‘프로세스’ ‘문화’ ‘기반시스템’ ‘방법론’에 대한 현장 실무 위주의 전략을 제시한다.

저자 및 역자 소개

저자 : 김익환 소프트웨어 컨설팅 회사인 ABC Tech의 대표이자 카이스트 소프트웨어 전문가 과정 겸직교수. 서울대학교 공과대학을 졸업하였고 미국 산호세 캘리포니아 주립대학에서 전산학 학사, 스탠포드 대학에서 전산학 석사를 취득하였다. 미국 실리콘밸리의 GE, Sun Microsystems등에서 약 16년간 소프트웨어 실무경력을 쌓고 세계 150여 개 기업에 인터넷 통합 메시지 솔루션을 제공하는 ‘스탠포드 소프트웨어’를 설립하여 제품을 개발하고 회사를 운영하였다. 2000년 귀국 후에는 소프트웨어 분야 컨설턴트로 활동하며 ‘안철수연구소’의 부사장 및 최고기술경영자(CTO)로 근무하였다. 저서로 『대한민국에는 소프트웨어가 없다』, 역서로 『세상을 바꾼 32개의 통찰』이 있다.

저자 : 전규현 (Ray) ABC Tech의 수석 컨설턴트이자 프로젝트관리전문가(PMP, Project Management Professional)이다. 연세대학교 공과대학을 졸업하고 ‘한글과컴퓨터’를 시작으로 ‘안철수연구소’에 이르기까지 약 15년간 수많은 소프트웨어를 개발하였고 Programming Engineer, Project Leader, Project Manager, CTO 등 소프트웨어 개발 분야의 다양한 역할을 두루 경험했다. 현재는 소프트웨어 개발 컨설턴트로서 소프트웨어 회사의 개발에 관한 문제들을 해결하는 일을 하고 있다.

목차/책속으로

• 목차보기   Part1 소프트웨어 개발의 기초  1. 기반시스템  기반시스템이 잘 구축된 사례┃기반시스템이 잘 구축되지 않은 사례┃소스코드관리시스템┃빌드시스템┃버그관리시스템┃테스트관리시스템과 테스트 자동화툴┃프로젝트관리시스템┃요구사항관리시스템  2. 조직  프로젝트 구성원의 역할 ┃조직체계  3. 개발방법론과 프로세스  소프트웨어 개발방법론┃소프트웨어 개발 프로세스  4. 사람  인재 확보┃문서 작성 기술  5. 문화  동료 리뷰┃연구┃공유┃품질 우선┃규칙 준수┃장기적인 관점으로 보기  Part2 소프트웨어 개발을 성공으로 이끄는 법  6. 생애주기 모델을 제대로 선택하라  폭포수 모델┃반복 모델┃XP 모델┃사시미 모델┃발전적 프로토타이핑 모델  7. 개발 단계별 계획을 수립하라  개발의 각 단계┃단계별 인원 투입┃단계별 일정 분배  8. 프로젝트 활동을 확실하게 관리하라  프로젝트 성공 기준 마련┃개발 계획┃일정관리┃요구사항 분석┃설계┃구현┃품질관리┃리스크관리┃인력관리┃의사소통관리┃원가관리 • 책속으로   이 책에 담긴 내용은 소프트웨어 개발 프로젝트에 직접적으로 참여하는 사람들뿐만 아니라 소프트웨어 회사의 경영자, 프로젝트관리자, 개발자, 상위관리자 등 모든 사람들이 알아야 할 내용 모두를 포함한다. 여기서 말하는 소프트웨어 회사는 소프트웨어 제품만을 개발하는 회사를 지칭하지 않는다. 팩키지 소프트웨어를 만드는 회사나 SI회사는 물론, 장비에 탑재되는 임베디드 소프트웨어를 만드는 휴대전화 개발사나 복사기 제조사, 방대한 전산 시스템을 가지고 있는 은행이나 증권사 등 소프트웨어를 개발하고 유지보수하는 모든 회사가 여기에 해당한다.  --- p.10  소프트웨어 프로젝트는 그저 열심히 수행한다고 해서 성공할 수 있는 것이 아니다. 회사와 직원들 모두에게 기초가 갖춰져 있지 않은 상태로 진행하는 프로젝트는 모래성 위에 쌓아 올린 탑과 같다. 아무리 훌륭한 프로젝트관리자라 하더라도 소스코드관리시스템이나 버그관리시스템도 없고, 테스터도 없고, 개발자들이 서로 리뷰를 해본 적도 없다면, 이들을 이끌고 프로젝트를 성공시키기란 기적이나 다름없다. 반면 기초를 잘 갖추고 진행하는 프로젝트는 튼튼한 탑과 같이 견고하다.  --- p.24  시중에는 수많은 소프트웨어 개발방법론이 넘쳐난다. 지금까지 알려진 방법론만 100가지가 넘는다. 인터넷에서 이에 대한 설명만 보고 Template을 복사해 와서 회사에 적용한다는 것은 기적에 가깝다. Template과 Sample만 보면 방법론을 적용하여 선진 개발 방식을 따라 할 수 있을 것 같지만, 착각이다. 제대로 된 방법론을 잘못 오해하여 적용하거나 특정 부분에 집착하여 전체를 놓치는 경우가 많다.  한 가족이 살기 위한 집을 짓는데 고층 빌딩을 만드는 방법을 적용하면 안 되고, 그렇다고 개집을 만들 때처럼 대충 지어서도 안 된다. 개집을 만들 때는 대충 만들어도 되고, 안되면 다시 만들면 된다. 그러나 빌딩을 만들 때는 한 치의 오차도 없이 정확하고 정교한 방법을 사용해야 한다.  --- p.118  SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋다.  --- p.220  개발자들은 가장 먼저  ● SRS를 작성해야 한다고 생각하고,  ● SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고,  ● 프로젝트관리자는 개발자들과 함께 1, 2일 단위의 상세 일정을 작성하고,  ● 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고,  ● 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며,  ● 구현 시 모든 소스코드는 당연히 리뷰를 하고,  ● 개발자는 매일 스스로 일정을 업데이트 하고,  ● 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며,  ● 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며,  ● 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며,  ● 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.  위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다. 이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다. 하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고 좋은 제품을 만들 수 있을 것이다.  --- p.318

	• 출판사 리뷰

경영자에서 개발자까지,  소프트웨어 회사에서 반드시 알아야 할 핵심 노하우  이 책 『소프트웨어 개발의 모든 것』은 소프트웨어를 성공적으로 개발하기 위해 반드시 필요한 기초에 대해 설명하고, 그러한 기초를 확실하게 활용하고 실행하기 위한 저자들의 노하우를 제시한다. 여기서 제시하는 내용은 회사가 크냐 작으냐에 따라 달라지지 않으며, 어떠한 형태의 제품을 만드느냐에 따라서도 달라지지 않는다.  1부 ‘소프트웨어 개발의 기초’에서는 소프트웨어 회사에서 기본적으로 갖춰야 할 5가지, 즉 기반시스템, 조직, 프로세스, 기술, 문화에 대해 설명한다. 이 5가지는 우리나라 현실에 맞지 않는 딴 나라 얘기가 아니며, 실제 경험을 통해 가능하고 유용한 것들만 모아 놓은 것이다. 당장 이 5가지를 한꺼번에 갖출 수는 없겠지만 회사의 실정에 맞게 차근차근 모두 다 도입해야 하는 것도 분명하다.  2부 ‘소프트웨어 개발을 성공으로 이끄는 법’에서는 개발방법론의 선택과 도입방법 및 절차를 설명하고, 소프트웨어 프로젝트의 기둥이라 할 수 있는 SRS(Software Requirements Specification) 작성의 중요성을 설명한다. 더불어 소프트웨어 개발의 각 단계별 계획 수립 방법과, 프로젝트 전반을 확실하게 관리하기 위한 저자들의 노하우를 제시한다.  추천평 이 책은 단순한 소프트웨어 공학 책이 아니다. 저자의 25년 소프트웨어 개발 경험과 이론이 응축된 결과물이다. 이 책에는 미국의 실리콘밸리, 한국의 대표적 소프트웨어 회사 안철수연구소의 개발 프로세스와 개발 인프라를 만들고 발전시킨 경험이 담겨 있다. 소프트웨어 개발자나 프로젝트 관리자는 물론 개발 부서장, 기획자 등 소프트웨어 개발에 관련된 모든 사람들이 반드시 읽어봐야 할 책이다. - 강은성 (SK커뮤니케이션즈 커뮤니티개발실장) 소프트웨어를 구현하고 개발을 관리하면서, ‘어떻게 하면 여러 명이 이 일을 함께 잘 할 수 있을까?’ 하고 늘 고민해왔다. 결론은 ‘기본에 충실’이다. 이 책은 실용적인 도구, 프로세스, 문화에 대한 설명을 통해 어떻게 소프트웨어 개발의 기본에 충실할 수 있는 지를 알려준다. - 조재희 (휴맥스 혁신실 부장) 소프트웨어 개발을 직업으로 준비 중인 모든 신입 개발자들에게 가장 추천할 만한 입문서다. 이 책을 읽으면서 떠오른 한 가지 생각은, ‘우리나라 소프트웨어 개발자 중 과연 몇 명이나 이 책에 수록된 지식들을 숙지하고 있을까?’ 하는 의문이다. 국내 모든 소프트웨어 개발 종사자들이 꼭 한번 확인해보아야 할 책이라고 생각한다. - 민상윤 (KAIST 겸임교수, 솔루션링크 대표)

책구매 : Yes24, 알라딘, 강컴, 인터파크

독자서평:

자신이 개발자이고 짜보고 고치기를 반복했다면 필독! | hnsbook (맥스짱) | 2008-10-22 | 평점 ㅣ 추천 0  

지금까지 일이 지지부진했던 이유와 개선방향을 제시해준 책. 맨날 밤새고 집에도 못가지만, 주먹구구식으로 짜보고 고치는 습관을 고치지 못했던 게 후회가 되었다.  우리회사, 우리 팀의 개발 현실의 문제점을 알 수 있었고, 현실적인 대안을 찾을 수 있었다. 물론 실천하기는 쉽지 않겠지만 ^^;

소프트웨어 개발자, 관리자, 경영자라면 꼭 읽어야 할 책.

내용  편집/구성

|용가리 | 2008-10-17

소프트웨어 개발을 하다 보면 자신의 실수나 역량과는 전혀 상관없는 회사의 인프라 부족이나 동료들의 실수, 서로간 의사 소통 부족으로 개발이 지연되고 하지 않아도 될 일들을 해야 하는 경우가 항상 생깁니다.
  저 사람이 내 소스 엎었네~ 이 사람이 홀랑 지웠네~ 소스가 10일전 것으로 돌아갔네~ 이 소스가 아닌가....