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

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

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

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

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

서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System)

소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다.

이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다.

만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다.

그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단하게 예를 들어 보겠습니다. 여기서 예라고 하는 이유는 계속 개량 발전시켜나면 연동하는 것들은 점점 늘어나고 자동화 되면서 효율은 더욱 높아지기 때문입니다.

물론 이 외에도 사용하는 기반시스템들도이 있지만, 아래 그림이 소프트웨어 회사라면 필수록 필요한 최소한만 추린 것입니다. 

  

각각의 연동 방식이나 자세한 내용은 많은 양이므로 추후 하나씩 설명하도록 하겠습니다.

그리고 하나하나의 운영 방법도 다양하고 계속 발전하고 있어서 자신의 회사에 적당한 방법을 찾아야 합니다.

이렇게 서로 연동되고 있지 않으면 자동화 될 수 있는 일에 괜히 시간과 노력을 들이고 있는 겁니다. 그렇게 된다면 개발자들은 개발을 해야 할 소중한 시간에 쓸데 없는데 시간을 허비하고 실수에 의한 사고 가능성도 높아집니다. 또 오랫동안 개발 정보가 쌓여도 그리 효율적으로 활용되지 못합니다. 

일단 이런 식으로 잘 갖추워진 기반시스템 하에서 개발을 하다보면 과거의 방식으로는 도저히 돌아갈 수 없고, 과거에 왜 그렇게 개발을 하면서 시간을 낭비했는지 안타까운 마음이 생길 겁니다.

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

조직, 프로세스, 문화, 기반시스템이다. 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

여기에는 몇 가지 논란이 있을 수 있다. 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.

본 칼럼은 ZDNet Korean에 기고한 글입니다.

스타트업을 위한 조직론

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

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

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

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 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일전 것으로 돌아갔네~ 이 소스가 아닌가....