Technical Career Path를 보장하는 방법

그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

아래와 같은 것들이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SVN보다 Git가 더 좋을까?

요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.

1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
2. Github를 써야 한다면 Git를 써라.
3. 그외에는 모두 SVN을 써라.

기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 

CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 

일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.

• Folder공유 타입 - RCS, SCCS
• Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
• 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs

폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.

또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.

• Offline에서 자주 개발을 해야 할 때
• Git 기반의 Open source를 이용한 개발을 해야 할 때
• Git 기반의 Open source 프로젝트에 참여할 때
• Github을 써야 할 때

이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.

SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.

SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용

이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

• 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
• 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
• 그외에는 모두 Git을 써라.
• 회사를 새로 시작한다면 Git을 써라.
• SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
• SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.

주먹구구를 더 좋아 하는 이유

이론과 실제는 다르다. 

모두들 착하게 살아야 한다는 것을 알지만 많은 사람들이 착하게 살지 않고, 운동을 해야 하는 것을 알지만 대부분의 사람들은 운동을 하지 않는다. 이유는 다 있다.

착하게 살고 꾸준히 운동을 하는 사람들은 꾸준히 하다보니 특별한 목적보다도 그 자체가 좋아하고 자연스러운 행동이 된다. 

소프트웨어 회사도 주먹구구식으로 개발하면 안되고 체계적으로 개발해야 한다는 것을 이론적으로는 알아도 그 구성원들은 막상 체계적으로 변화를 하려고 하면 완전히 적응되기 전까지는 크고 작은 거부감과 저항이 있게 된다.

그래서 주먹구구로 회기하려는 힘이 강하게 작용하게 된다.

많은 회사들은 자신의 회사는 주먹구구가 아니라고 생각할 것이다. 물론 Black and White로 구분할 수는 없지만 나의 경험에 의하면 우리 나라 소프트웨어 회사의 90% 이상이 주먹구구에 가깝게 개발을 하고 있고 나머지의 대부분은 체계적인 개발을 하려고 노력하고 있으나 너무 과해서 더 효율성이 떨어지거나 회사에 알맞는 체계를 갖추고 있지 못하다. 정말 극소수의 몇개의 회사들이 효율성 높은 체계를 가지고 있고 문화적으로 자리를 잡고 있다.

여기서는 주먹구구에서 벗어나기 어려운 장애 요인은 무엇이 있나 알아보자. 시간이 흐르고 자리를 잡으면 별거 아닌 것들이지만 변화에 대한 거부감들은 의외로 매우 강한 경우가 많다.

주먹구구로 계속 개발을 하다보면 초창기에는 특공대처럼 놀랄만큼 좋은 성과를 내지만 인원이 많아지고 프로젝트의 규모가 커지면서 프로젝트는 점점 늦어지고 문서는 여전히 거의 없고 정보는 공유가 안되고 회사가 도대체 어떻게 굴러가고 있는지 잘 파악이 안된다. 제품이 버그는 점점 많아지면서 고객의 신뢰를 점점 잃어가는 위기를 겪게 된다.

이를 극복하기 위해서 소프트웨어 회사가 체계를 제대로 갖춰가면 
개발 프로세스를 정립하고 
프로젝트를 수행하면서 문서를 만들고 
조직을 전문화하고
기반 시스템을 구축하고
공유 등 개발 문화를 정착시키기 위해서 애쓴다.

단어적으로 보면 아무도 거부할 것이 없지만 실제로 많은 저항에 부딛히게 된다.
제대로 정착하면 장점으로 가득차 있지만 오로지 단기적인 시각으로 단점만 보면 다음과 같은 것들이 있다.

개발자

개별 개발자들이 과거에는 파워라고 생각했던 것들이 많이 줄어들게 된다.
과거에는 제품, 기술에 관련된 것들은 모두 개발자에게 물어 봐야 하고 개발자의 은총을 받아야만 일들이 진행이 되었다.
심지어는 프로젝트가 언제 끝나는지도 아무도 모르지만 개발자가 열심히 해서 끝내주기만 기다리곤 했다.
하지만 이제는 문서화를 통해서 제품의 스펙도 이미 다 공유가 되어 있고 개발자에게 물어볼 일들이 점점 줄어 들게 되었다. 개발자들은 이렇게 할 수 있도록 스펙(SRS)을 작성하는 일이 짜증나는 일이 됬다. 
나중에 마음에 내키는 대로 개발도 할 수 없게 된다.
과거에는 개발자에게 요청할 것이 있으면 직접 와서 부탁을 해야 했지만 이제는 시스템에 모두 등록이 되어서 개발자들이 이슈 처리를 잘하고 있는지 못하고 있는지 만천하에 드러나게 되었다.
소스코드를 수정한 것도 한줄한줄 완전히 투명하게 공개가 된다.
프로젝트를 진행할 때도 일정이 너무 상세하게 관리되어서 압박이 심하다.
개발자가 한두명이 퇴사를 해도 회사는 잘 굴러갈 것 같은 체계로 가고 있는 것들이 개발자는 불안해지고 파워를 점점 잃는 것을 거부하게 된다.

영업

과거에는 프로젝트를 할 때 별로 할 일이 없었다. 
개발자들이 SW를 만들어 주면 알아서 팔기만 하면 되었는데 이제는 스펙이라고 작성해와서 몇백페이지나 되는 문서를 꼼꼼히 읽어보고 사인을 하라고 한다. 그리고 나중에 잘못된 내용이 있으면 책임 지라고 한다.
개발이 힘들고 돌아다니는 것이 좋아서 영업을 하는데 공부는 개발자만큼 해야 하나보다.
고객의 요청도 개발자에게 가서 무조건 우기면 제품에 반영해주고 했는데 이슈관리시스템에 자세히 적어야 하고 내용이 만천하에 드러나므로 무조건 우길 수도 없게 되었다. 

경영진

옛날에는 내용을 파악하려면 담당자에게 와서 보고하라고 하면 되는데 이제는 시스템에서 확인해야 한다. 이게 더 좋다고 하지만 나는 영 불편하다.
프로젝트를 진행할 때 무조건 야근과 주말작업을 강요했는데 체계화 되면서 그러기 어려운 분위기가 되어가고 있다.

마케팅

옛날에는 제품 기능 목록 주욱 적어주면 개발자가 개발하고 이렇게 간단했는데 제품 기획을 제대로 하느라고 힘들다. 모든 내용이 문서화되고 시스템에 남기 때문에 나중에 딴 소리를 할 수 없다. 

결론

물론 모든 구성원이 이런 저항감을 가지는 것은 아니다. 변화의 필요성을 잘 알고 적극적으로 변화를 이끄는 많은 사람들이 있다. 이런 구성원이 많다면 회사는 계속 번창해 나갈 것이다. 회사의 분위기와 상황에 따라서 매우 다르다.

하지만 많은 회사들이 이런 이유들 때문에 많은 저항에 부딪혀서 적당한 정치적인 타협으로 기형적인 구조가 되어서 망하는 길로 들어서게 된다. 이러한 저항은 특이한 현상도 아니고 아주 자연스런 현상이다. 이러한 조직 구성원은 잘못된 생각을 가지고 있는 것이 아니고 인간의 자연스러운 본성에 가깝다. 따라서 이를 비난할 수는 없고 이들을 계속 이끄는 것은 회사의 책입니다.

이 고비를 넘어가면 회사의 모든 구성원들에게 그 혜택이 돌아가고 과거에는 어떻게 그렇게 일했는지 모르겠다고 회상하는 때가 온다. 그 중에서도 개발자에게 돌아가는 혜택이 가장 크다고 할 수 있다. 개발자에게 돌아가는 가장 큰 혜택의 개발자의 몸값을 높여준다는 것이다. 

나는 주먹구구 식으로 밖에 개발을 하지 못하는 개발자에게는 20년 이상의 경력이 있어도 연봉 5천도 아깝다. 하지만 체계적인 개발이 몸에 베어서 스펙도 잘 쓰고 설계도 잘하며 공유, 리뷰 문화에 익숙한 개발자는 연봉 1~2억도 아깝지 않다.

체계적으로 바꿔갈려면 감당할 만큼씩 단계적으로 변화를 해야 한다. 보통의 중소기업이 이렇게 단계적으로 변화를 하려면 2~3년 정도의 시간이 걸리고 대기업은 훨씬 더 오래 걸린다. 
또한 그 과정에서 뻔히 보이는 저항에는 굴복하지 말고 슬기롭게 헤쳐나가야 한다. 여기서 가장 중요한 것은 최고경영자의 통찰력과 의지이다. 그래서 최고경영자의 책임은 더욱 무겁다.

나쁜 습관

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

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

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

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

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 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와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

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

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

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

Hotfix에서의 소스코드관리

아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

2010/05/03 - [기반시스템/소스코드관리] - 혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

차우차우

2010/05/03 22:49

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.

우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.

계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.

Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.

Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 

Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

Hotfix	정식 Patch
계획되지 않은 긴급한 패치 보통 충분히 테스트 되지 않고 릴리즈 또다른 문제를 일으킬 가능성이 매우 높음 다른 개발일정에 영향을 줌 고객은 수정된 버전을 바로 받아볼 수 있음	미리 계획됨 계획된 테스트를 수행하고 릴리즈 일상적인 수준의 리스크를 가지고 있음 계획된 일정대로 개발이 가능 고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.

1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?

2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 

1. 그때 그때 다르다.

2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.

Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.

그럼 개발팀 바깥이란 무엇일까요? 

테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.

이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.

Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.

1. 상세한 버그 내용
2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
3. 버그로 인해서 발생하는 고객의 예상 피해
4. 버그를 얼마나 빨리 해결해야 하는지
5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
6. 버그 수정에 투입해야 하는 인력 및 자원
7. 기존 개발일정에 미치는 영향

여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 

Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.

그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.

Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.

지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

이 소스코드는 나 밖에 못 건드려!

"우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요"

"이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"

"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"

"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요."

이와 같은 현상이 친숙하나요? 그럼 Parallel

Development(병행개발)와는 거리가 멉니다.
Development를 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch와 Tag, Merge를 용도에 맞게 능숙하게 사용할 수 있어야 합니다.

개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.

아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 수 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 수 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge를 할 수 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 수 밖에 없습니다.

또한 이 때문에 각 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 수 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.

하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 별 문제가 없어 보이고 또 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 수 없습니다.