스타트업에서 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에 기고한 글입니다.

옛날에는 개발을 더 잘했는데

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다.

두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다.

두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다. 그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까요?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다. 과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다.

이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다.

히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다.

그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내놔도 뒤지지 않을만큼 뛰어나지만 골결정력 등 섬세한 고급 기술들이 부족하다고 생각했었다.

하지만 히딩크는 이를 전면 부정하고 고등학교 축구팀처럼 기초 체력 훈련에 집중했다. 주변의 반대가 심했지만 강행했다.

그리고 월드컵에서 그 결과를 보았다. 경기 후반 다른 나라 선수들이 지쳤을 때 우리 선수들은 한발 더 뛸 수 있었고 승리로 이어졌다.

우리나라 개발자들은 개인기들은 뛰어나다. 즉, 코딩을 잘하는 개발자도 많고 온갖 지식도 많이 안다.

솔직히 이 정도로 많이 아는 개발자들은 전세계적으로 찾아보기 어렵다. 그럼에도 세계적인 소프트웨어 회사가 우리나라에 없고, 세계적인 제품을 찾아보기 어려운 것은 기초 체력이 부족하기 때문이다.

개발자들이 많이 아는 지식은 혼자서 배우고 익힐 수 있는 것들이다. 이것은 노력하는 개발자라면 누구나 다 잘 한다.

하지만 기초 체력은 혼자서는 절~대로 배울 수 없는 것들이다. 대부분 잘 갖춰진 개발문화를 가진 SW회사에서 몇년씩 일하면서 자연스럽게 배울 수 있는 것들이다. 그렇게 쌓은 기초 체력을 갖춘 개발자들이 버글버글 해야 그들이 뭉쳐서 좋은 소프트웨어도 만들고 그중에서 세계적인 소프트웨어도 나올 수 있다.

그런 좋은 환경에서 배울 수 있는 기초 체력은 코딩도 아니고 Domain 지식도 아니다.

아래와 같은 것들이다.

• 소프트웨어 개발에 있어서의 개방의 문화
• 리뷰 문화
• 공유 문화
• 협업 문화
• 신뢰의 문화
• 효율적인 개발 프로세스
• 소스코드 관리 기법
• 이슈 관리 기법
• 빌드/릴리즈 기법
• 테스트

이런 것들이 몸에 베어 있어야 한다. 몸에 베이지 않고 지식으로만 알고 있는 것은 막상 시행하려고 할 때 제대로 실행하기 어렵다. 엉뚱한 방향으로 흘러가서 이상하게 되어 버린다.

또 기초 체력에 해당하는 것들은 비싼 툴을 쓰고 정교한 세계 최고의 방법론, 프로세스를 도입한다고 해서 나아지지 않는다. 오히려 방해가 되는 경우가 많다.  그런 비싼 툴과 정교한 프로세스를 그것을 필요로 하는 곳이 따로 있는데 맞지도 않는 것을 쓰게 되면 반감만 커지게 된다.

툴은 꼭 필요하지만 환경에 맞게 필요한 툴과 적절한 프로세스가 필요한 것이다. 그 기반하에서 문화가 꾸준히 쌓이게 된다. 

이런 기초 체력이 뒷받침 되어야 다음과 같은 고급 역량이 생기기 마련이다.

• 분석 역량
• 설계 역량
• 기술 전략 수립

단어만 놓고 보면 우리도 다 하는데라고 생각할지 모른다.

이는 태권도 10급이 태권도 9단에게 나도 태권도 할 줄 안다고 하는 것과 비슷하다.

Global 하게 경쟁 좀 하려면 4,5단은 되어야 하는데 우리나라에서 유단자 찾기 어려운 이유가 기초 체력을 먼저 갖추기 어려운 환경에서 일하기 때문에 이런 고급 기술은 닦을 시간도 없고 방법도 모르기 때문이다.

그래서 내가 중요하게 생각하는 것이 개발 환경을 먼저 바꿔 놓는 것이다.

기본적으로 이슈관리시스템, 소스코드관리시스템만 제대로 사용해도 반쯤은 바뀐 것이다.

이런 시스템들을 쓰면 우리가 눈치 채지 못하지만 여러가지 원칙, 프로세스를 저절로 배우게 된다. 수십년간 수많은 SW회사들의 성공하는 방법이 녹아 있는 것이 그런 시스템, 툴 들이다.

따라서 이들을 원칙 그대로 사용만 해도 많은 것을 얻게 된다. 기존의 방법과 다르다고 툴을 무시하고 또는 이상하게 변형하면 99.9% 잘못된 방향으로 가고 있는 것이다.

그리고 빌드, 테스트, 리뷰 등등을 하나씩 갖춰나가면 어느덧 꽤 효율적인 조직의 모습을 갖출 것이다.

이때 나타나는 조직의 모습은 다음과 같다.

• 회사의 모든 개발 이슈가 투명하게 Open 된다.
• 모든 업무의 커뮤니케이션이 원활하며 이런 것에 시간 낭비 하지 않는다.
• 모든 소스코드는 공개가 되어 있고, 협업이 원할하다.
• 숨어서 개발하는 개발자는 더이상 존재하지 않는다.
• 경영자와 관리자는 개발 진행 상황을 한눈에 파악하고, 각 개발자들의 업무 진행 상황을 쉽게 파악한다.

대부분은 이쯤에서 만족할 수 있을지도 모르겠다.

하지만 여기까지는 진짜 "기초 체력"이다.

국내 대회에서는 꽤 상위권에 오를 수 있다. 하지만 월드컵에 나가면 한 골 넣기도 어렵다.

이제 "고급 역량"이 필요할 때다.

분석/설계/기술전략 등의 "고급 역량"은 단기간에 배울 수도 없다. 그렇다고 혼자 방법과 길을 알아서 익힐 수도 없다. 그렇게는 너무나 오래 걸려서 은퇴할 때가 될 것이다.

"고급 역량"은 이미 "고급 역량"을 갖춘 선배, 동료들과 진짜 프로젝트를 수행하면서 몸으로 익히는 것이다.

어느정도 방법과 길을 아는데는 몇개월 안걸리지만 진짜 역량이 높아지는데는 5년, 10년이 걸리고 20년이 지나면 또 역량이 올라간다.

우리나라 많은 개발자들이 관리 쪽을 기웃거리다가 또 유지보수에 시달리다가 20년 쯤 지나면 이도 저도 아닌 상태와는 많이 다르다.

기초 체력을 익히는 첫걸음은 기초 체력이 부족하다는 것을 인정하는 것이다. 스스로를 인정하지 않으면 바뀔 수 없다. 이렇게 환경부터 하나씩 고쳐나가야 한다. 

개헤엄은 아무리 잘 해도 개헤엄

나의 경험에 의하면 우리나라 소프트웨어 회사들의 대부분은 Global 경쟁력을 거의 갖추고 있지 못하며 여전히 국내에서만 좀 통하는 주먹구구식 개발 방법에 의존하고 있다.

이런 회사들은 자신들도 모르는 사이에 슬금슬금 그 한계가 다가오게 된다. 이미 한계를 넘어버리면 복구하기는 정말 어려워진다.

지금의 방법으로는 한계에 다다르고 있다는 징후는 다음과 같은 것들이 있다.

• 개발자 인원수는 과거보다 훨씬 많은데 개발 효율은 훨씬 떨어지고 프로젝트는 데드라인을 못 지킨다.
• 매출은 많이 늘었는데 순이익은 급격히 나빠지고 있다.
• 신입 개발자들을 계속 뽑고 있는데 실제 프로젝트에 도움이 잘 안된다. 밥값을 하려면 몇 개월씩 걸린다.
• 회사의 핵심 개발자들이 퇴사를 하고 있다.
• 신규 개발보다 유지보수에 비용이 점점 많이 들어가고 있다.
• 회사내에서 지식의 공유가 안되고 커뮤니케이션이 안되고 있다.
• 제품들의 버그가 과거보다 훨씬 많아지고 있는데 그 원인을 잘 모르겠다.  
• 개발자들의 전체적인 사기가 과거만 못하다. 옛날에는 인원은 적지만 모든 개발자들이 한마음으로 똘똘 뭉쳐있었다.
• 바쁜 개발자들은 항상 너무 바쁜데, 핑핑 노는 개발자들도 있는 것 같다. 하지만 누가 어떻게 놀고 있는지 잘 파악이 안된다.

이 중에서 2~3개라도 일치하면 한계에 다다르고 있다는 신호다.

소프트웨어 회사가 한계를 넘어가면 다음과 같은 길을 가게 되어 있다.

• 더욱더 밀어 붙이다가 그대로 망하는 길로 달려간다. 
• 상황이 악화됨에 따라서 구조조정으로 회사의 규모를 줄이고 목숨을 연명한다.
• 개발 방법에 변화를 시도한다. Global 경쟁력을 갖추려고 노력한다. 

대부분의 회사는 망하는 길로 치닫는다. 그래서 우리나라에는 성공한 SW회사가 손에 꼽을 만큼밖에 되지 않는다. 또한 Global 경쟁력을 갖추고 세계 시장을 호령하는 회사는 더욱더 찾아보기가 어렵다.

가장 좋은 방법은 한계에 다다르기 전에 회사를 변화시키는 것이다. 제대로 된 길로 가는 것은 빠르면 빠를수록 좋지만 아직 주먹구구식 개발을 하고 있다면 지금이 가장 빠른 시기이다.

하지만 변화는 어렵다.

"변화는 개를 두발로 걷게 하는 것과 같다."라는 말이 있다. 두발로 열심히 걷던 개도 잠시 눈을 돌리면 어느새 네발로 걷게 된다. 즉, 변화는 자꾸 과거로 회귀하려는 성질이 있다. 그래서 기업에서의 대부분의 변화는 실패로 끝나게 된다.

개헤엄은 개헤엄을 뿐이다. 

개헤엄은 아무리 숙달되고 능숙해져도 개헤엄일뿐이다. 절대로 자유형을 이길 수 없다.

변화가 어렵고 개발자들이 자꾸 과거로 돌아가고 싶어하더라도 과거로 돌아가서는 이미 성장해버린 회사는 더 이상 과거의 방법이 통하지 않는다. 개헤엄을 이길려면 새로운 자유형을 배워야 한다.

그래야 경쟁도 할 수 있고 살아남을 수 있다. 

Global 경쟁력을 갖추는 방법은 프로세스, 조직, 시스템, 문화를 체계를 갖추고 변화시켜 나가는 것이다. 변화에 성공해야 개발자와 회사 모두가 행복해진다.

나쁜 습관

소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다. 
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

문서화 딜레마

우리나라 소프트웨어 회사 중에서 문서를 제대로 작성하고 있는 곳을 찾기란 그리 쉬운 일이 아닙니다.

제대로 작성한다는 의미는 꼭 필요한 만큼 적절히 효과적으로 작성하는 것입니다.

대부분의 소프트웨어 회사는 변변한 문서 하나 없이 개발을 하고 있고 반대로 소수의 회사는 불필요한 문서를 잔뜩 만들어서 오히려 효율성을 떨어뜨리고 있습니다.

물론 제대로 하고 있는 회사도 있지만 그 수는 극히 적습니다.

대부분의 여러분들도 겪은 현상이거나 앞으로 겪을 것입니다. 변변한 문서하나 제대로 만들지 않고 소프트웨어를 개발하고 있는 회사는 구멍가게 이상의 규모로 성장하기 어렵습니다. 회사의 규모가 커지면서 문서가 부족하면 커뮤니케이션 비용이 기하급수로 증가하기 시작합니다. 회사가 작았을 때 숨어있던 문제들이 마구 터져 나오기 시작합니다.

이미 문제가 되기 시작한 이후에 문서를 만들어보자는 결심을 하기도 합니다. 하지만 이미 제품을 다 개발한 이후에 유지보수하는 제품의 문서를 제대로 만드는 것은 거의 불가능합니다.

문서의 주목적은 소프트웨어를 제대로 개발하기 위한 것이지 유지보수를 위한 것이 아닙니다. 유지보수 단계에서 문서를 만들면 문서에 많은 내용이 빠지게 되고 의욕도 떨어지게 됩니다.

하지만 문제는 또 다른 곳에 있습니다. 그동안 제대로 문서를 만들지 않고 개발을 해온 개발자들이 문서를 만들자고 결심만 했다고 해서 문서를 작성하는 실력이 갑자기 생기지는 않습니다.

즉, 문서를 만드는 실력이 부족하다는 겁니다.

본인들은 문서를 잘 작성할 줄 아는데 바빠서 만들지 못한다고 합니다. 그래서 시간만 있다면 문서를 언제든지 만들 수 있다고 합니다. 이렇게 말하는 것자체가 문서를 제대로 만들어 본적도 없고 문서를 만들지도 모른다는 반증입니다. 왜냐하면 바쁠 수록 문서를 적절히 잘 만들어야 프로젝트 시간이 단축되기 때문입니다.

그러다보니 제대로 된 문서도 없이 유지보수가 뒤죽박죽이 되어서 항상 고참 개발자들이 유지보수에 매달려야 해서 계속 바쁘게 되고 그러다보니 문서를 제대로 만드는 실력을 향상할 기회는 또 없게 됩니다. 새로운 프로젝트를 시작해도 또 과거의 방식으로 문서도 제대로 없이 개발을 하게 됩니다.

개발자들이 코딩을 잘하는 이유는 수년에 결쳐서 코딩을 계속 해 왔기 때문입니다. 철저히 훈련이 잘 되어 있습니다. 다들 실력차이는 나지만 코딩을 못하는 개발자는 개발자도 아니죠. 

그렇듯 문서도 계속 작성을 해봐야 잘하게 됩니다. 처음부터 기가막히게 멋진 문서를 만들 필요는 없습니다. 항상 기록을 남기는 습관을 들이는 것도 문서를 잘 작성하는 실력을 키우는데 좋은 도움이 됩니다.

물론 프로젝트에서 필요한 문서는 단순히 글을 잘 작성한다고 되는 것도 아닙니다. 하지만 글을 쓰는 습관이 출발점입니다.  그리고 프로젝트에서 필요한 문서는 원래 선배들이 제대로 작성을 해 왔다면 문서를 리뷰할 때 참석해서 문서 작성 방법을 배울 수 있습니다. 하지만 안타깝게도 선배에서 문서 작성법을 배울 수 있는 회사는 우리나라에 그렇게 많지 않습니다. 대부분은 스스로 해 나가야 합니다. 이에 관련된 책들의 도움을 받는 것도 방법 중 하나 입니다.

명심할 것은 욕심을 부리지 않는 것입니다. 너무 많은 내용을 완벽하게 적으려고 하면 오히려 금방 질려서 포기하게 됩니다. 또한 바쁘니까 나중에 몰아서 만든다는 생각도 버려야 합니다. 문서는 지금 이순간이 아니면 만들 수 없습니다.  지금 필요한 만큼만 적당히 적게 만들어야 합니다.

내가 지금 하고 있는 일의 가격

개발자 여러분... 

아침에 출근하셔서 여러분들이 하루종일 일하는 업무의 가격을 생각해보신 적이 있으신가요?

이것을 여러분의 "하루의 부가가치"로 생각을 하죠. 

여러분의 연봉은 "하루의 부가가치" x "일년동안 일한 날"에서 회사에서 여러분에게 사용한 비용을 제하면 됩니다.

대기업은 보통 60~70%를 비용으로 제하면 되고, 중소기업들은 30~50%정도의 비용이 듭니다.

여러분은 자신이 만들어 내는 부가가치에 비해서 높은 연봉을 받고 있나요? 낮은 연봉을 받고 있나요?

회사입장에서는 연봉보다 높은 부가가치가 있는 개발자를 더 많이 보유하기를 원하고 있습니다.

물론 이보다 좀더 복잡하기는 합니다만 일단 간단히 생각해보죠.

여기서 문제는 "하루의 부가가치"가 얼마나 되는지 측정하기 어렵다는 겁니다. 특히 여러분 스스로는 자신이 매우 가치있는 일을 하고 있다고 생각하지만, 다른 사람들의 시각으로는 그렇지 않을 수 있습니다.

모두들 알고 계시듯이 모든 재화의 가격은 시장의 원리에 의해서 결정됩니다.

수요가 많고 공급이 적으면 가격이 올라가고, 공급이 넘치면 가격은 떨어지게 됩니다.

여기에 개발자들이 높은 연봉을 받는 두가지 방법이 있습니다.

첫째, 부가가치를 높여서 높은 연봉을 받는 개발자

즉, 회사에 돈을 많이 벌어다 주고 미래에도 더 많은 돈을 벌어다 줄 개발자입니다.

이런 개발자들의 특징은 다음과 같습니다.

• 자신의 경력에 알맞는 일을 수행한다. 즉, 고참이 되어서도 맨날 코딩에만 매달리는 것이 아니고 설계, 요구사항 분석에 집중하며 프로젝트를 이끈다.
• 문서화와 리뷰를 잘하여 지식의 공유를 원활하게 하여 모든 개발자들이 서로 향상되는데 기여한다.
• 커뮤니케이션이 능통하여 복잡한 이슈들을 잘 해결한다.
• 회사의 중요한 기술적인 의사결정에 중요한 역할을 하여 회사의 기술 방향을 결정하여 회사가 기술적으로 올바른 길을 가도록 기여한다.

둘째, 자신이 없으면 회사에 손해를 끼치게 해서 높은 연봉을 받는 개발자

현재는 돈을 많이 벌어다 주는 개발자들이라도 곧 손해를 끼치게 하는 개발자들이 수두룩합니다. 

이런 개발자들의 특징은 다음과 같습니다.

• 항상 바쁘다는 핑계로 문서도 만들지 않고 프로세스를 지키지 않으며 자신만 알 수 있는 코드를 마구 쏟아 낸다.
• 후배들을 적극적으로 양성하기 않고 여전히 본인이 가장 많은 코딩을 한다. 막상 후배들을 시킬려고 해도 가르키기가 어렵고 본인이 제일 바쁘다.
• 회사의 개혁 시도를 방해하고 항상 본인은 열외라고 생각한다.

결론은 자신의 연봉에 걸맞는 부가가치가 높은 일을 해야 합니다.

소프트웨어 프로젝트에서 어려운 업무일수록 비싼 일입니다. 물론 모든 업무는 가치가 있고 꼭 해야 하는 일입니다. 하지만 이제 대학을 갓 졸업한 신입사원도 할 수 있는 일을 연봉을 3~4배나 많이 받는 개발자가 하고 있다면 연봉이 아까울 것입니다. 물론 그러한 일도 신입사원보다 2~3배 잘하기는 할 겁니다. 하지만 프로젝트에는 신입사원은 절대로 할 수 없는 어려운 일이 수두룩 합니다.

개발자들이 하는 업무를 크게 나누어서 간단히 비교를 하면 다음과 같습니다.

Coding < Low level design < High level design < Spec

코딩에서 있어서는 신입사원보다 크게 잘할 것도 없지만, 설계나 스펙은 수십배, 수백배 잘할 수 있는 분야입니다. 코딩도 그렇다고 생각하는 사람들은 코딩에 설계와 스펙을 짬뽕해서 생각하고 있는 것일 가능성이 매우 높습니다.

이외에 개발자는 잘하기 어려운 전문적이거나 매우 귀찮은 일을 개발자가 하는 경우도 있습니다. 

QA(Test), Project Management, B/R 등이 여기에 포함됩니다.

자신이 첫번째 개발자에 해당하는지 두번째 개발자에 해당하는지 잘 생각해봅시다.

두번째 개발자들이 주도하는 회사의 미래는 뻔합니다. 언제 망하는지는 시간 문제일 뿐입니다. 이런 회사들은 보통 한번의 성장을 이룬 다음에 첫번째 또는 두번째 변곡점에서 보통 망하게 됩니다. 즉, 회사가 성장하는 것이 망해하고 있는 것과 거의 같은 의미입니다. 이런 경우 성장하지 않거나 느리게 성장하는 것이 차라리 오래 살아 남는 길입니다.

주변에서 크게 성장한 다음에 망해간 수많은 소프트웨어 회사들을 생각해보세요. 이러한 특징들이 고스란히 드러납니다. 눈에 띄지 않게 조용히 망한 회사들은 셀 수 없을 만큰 수두룩합니다.

첫번째 개발자가 될지 두번째 개발자가 될지는 여러분의 선택입니다. 주변의 환경때문에 어쩔 수 없다는 것은 핑계에 불과합니다. 방법을 몰라서 그런 것이라면 마음만 열면 많은 도움을 받을 수 있습니다.

CEO 가장 자주 하는 거짓말은 뭘까?

CEO 가장 자주 하는 거짓말 '회사 여러분 것' 직장인들이 뽑은 최고경영자(CEO)의 가장 흔한 거짓말은 ‘이 회사는 여러분의 것’이라는 조사결과가 나왔다. 취업포털 스카우트는 최근 직장인 1천26명을 대상으로 설문 조사한 결과 CEO들이 가장 자주 하는 거짓말은 ‘이 회사 다 여러분들 것입니다’가 25.2%(216명)로 가장 많았다고 27일 밝혔다. 이어 ‘내년 한 해만 더 고생하자’(21.1%), ‘연봉 못 올려줘서 늘 미안해’(13.9%), ‘우리 회사는 미래가 있다, 다른 생각하지 말게’(12.3%), ‘사람 하나 더 뽑아줘야 하는데’(8.9%) 등이 있었다. 후략... Copyrights ⓒ 연합뉴스. (출처:조선일보)

흥미 있는 기사가 있어서 소개도 하고 의견을 좀 올려볼려고 합니다.

아직도 "회사는 여러분 것"이라는 거짓말을 믿고 있는 분들은 없으시겠죠? 회사의 주인이 되려면 CEO의 말만 믿지 말고 "주식"을 사세요. 비록 소액 주주이지만, 주인이 될 수 있습니다.

그럼 회사와 나의 관계는 무엇일까요? 

"주종의 관계"일까요?

먼저 회사의 목적과 나의 목적의 차이를 알아야 합니다.

회사의 목적은 "돈"을 버는 것이고 그 목적에 가장 충실한 사람이 CEO입니다. 충실한 정도가 아니고 그 목적을 달성하지 못하고 파리 목숨이죠. 물론 Owner라면 다르겠지만요.

회사가 "돈"을 많이 버는 방법은 "매출"을 많이 올리고, "비용"을 줄이는 겁니다. 위에서 CEO들이 즐겨하는 거짓말들은 다 이 목적을 이루기 위해서 하는 것들입니다. 직원들이 좀더 열심히 일하게 만들면서 인건비는 최대한 줄여야 합니다.

그럼 내가 회사를 다니는 목적은 무엇일까요?

"돈", "사회적기여", "자아성취", "경력개발" ???

여기서는 정답이 없는 것 같네요. "돈"이 가장 중요하다고 생각하는 사람도 많지만, 회사를 다니는 목적의 비중은 서로 다 다릅니다.

하지만, 중요한 것은 내가 회사를 다닌 기록은 사라지지 않는 다는 것입니다.

내가 다녔던 회사가 지금 훨씬 잘 나간 다면 나에 대한 평가도 후해집니다. 하지만, 내가 몸담았던 회사가 처참하게 망해 사라졌다면 나 또한 그 책임에서 자유롭지 못하고 취업 인터뷰 시 죄인을 바라보는 듯한 시선을 받을 수도 있습니다.

즉, 나와 회사는 회사를 다닐 때나 그만둔 후에나 모두 "상생의 관계"일 수 밖에 없습니다.

또한, 다른 직업도 마찬가지 일 수 있지만, 소프트웨어 개발자라면 더욱더 회사가 자신의 몸값을 높이는 중요한 역할을 합니다. 소프트웨어 개발자는 학교에서보다 회사를 다니면서 익히고 배우는 것이 훨씬 많습니다. 똑같은 학교를 졸업해서 주먹구구식으로 개발하는 우리나라 소프트웨어 회사에서 10년 일한 개발자와 Google에서 10년 일한 개발자는 간판만 다른 것이 아니라, 경험한 내용과 실력에서도 엄청난 차이를 보입니다. 그래서 월급이 적더라도 더 많은 것을 배울 수 있고, 미래의 자신의 몸값을 높일 수 있는 회사라면 주저하지 않고 선택할 수 있겠죠. 

즉, 개발자가 회사를 다니는 중요한 목적 중의 하나는 자신의 실력을 만들어나가는 겁니다. 이런 마인드를 가지고 있으면 회사 생활이 달라집니다.

맨날 코딩에 매달리면서 자신의 업무만 처리하는데 열심히 개발자의 10년 후 미래는 그리 밝지 않습니다.

몸값이 높은 개발자는

"비즈니스 마인드가 있어야 합니다."

"가치가 낮은 코딩에만 매달리기 보다는 가치가 더 높은 분석/설계 업무에 더 치중해야 합니다."

"창의적인 생각을 해야합니다."

"넓은 View를 가지고 있어야 합니다."

"커뮤니케이션 능력이 뛰어나야 합니다."

또한, "코딩도 잘해야 합니다."

이렇게 변화를 하려면 문서를 잘 작성하기 위해서 노력을 해야 하고, 넓은 View를 가지기 위해서 자신의 프로젝트 뿐만 아니라 수많은 타 팀의 프로젝트의 리뷰에도 참석하여 기여도 하고 많은 것을 배워야 합니다.

또한 "코딩" 뿐만 아니라 소프트웨어 개발 전반의 지식 영역을 고루 공부하고 경험해야 합니다.

업계 동향과 새로운 기술에 뒤쳐지지 않기 위해서 끊임 없이 공부해야 합니다. 

이러한 자세는 회사의 목적인 "돈"을 버는 것과 어긋나지 않습니다.

개발자들의 이러한 자세가 "회사"와 "개발자" 모두가 성공하는 "상생"의 길입니다.

하지만, 이를 절대 용납하지 않는 환경의 회사를 다니고 있다면, 회사를 왜 다니는지 한번 생각해 봐야 합니다. "돈"을 많이 주는지? 나의 "경력"을 장식해 주는지? 많은 것을 배우게 해주는지?

이도 저도 아니라면 이직을 차근차근 준비해야 할 때가 아닐까요?

SW개발과 Teamwork, 그리고 Review

거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 

그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.

하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.

이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.

팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.

Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처

에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.

물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야

하는 것들은 어떤 것이 있는지 알아보겠습니다.

1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)

제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝

날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다. 

2. SW아키텍처 리뷰 (중요도 : 높음)

웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍

처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.

3. 소스코드 리뷰 (중요도 : 중간)

소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.

소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.

우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다. 

좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.