인기없는 10년차 개발자

우리나라에서는 나이 많은 개발자가 별로 인기가 없다. 10년~20년차 개발자들은 그들을 찾아주는 회사가 그렇게 많지 않아서 이직이나 진로에 대해서 항상 고민이 아닐 수 없다.

아직 경험이 적은 개발자들이 불만도 적고, 시키면 시키는대로 일하고, 매일 야근을 해도 버틸 수 있는 체력이 남아 있고, 돌봐야 할 가정을 아직 꾸리지 않은 개발자들이 인기가 많다. 이 개발자들도 곧 체력이 바닥나겠지만, 아직 남아 있는 체력을 쥐어짤 것은 남아 있다.

필자는 개발자가 제대로 아키텍트가 되고 제대로 실력을 발휘하려면 10년 이상은 개발을 해야 한다고 생각한다. 그래서 기술도 두루 셥렵하고 소프트웨어 공학에 대한 경험도 꽤 쌓고, 비즈니스와 경영도 이해하게 된다. 이렇게 제대로 성장한 10년차 개발자라면 일반 프로그래며 10명 이상의 가치가 있다.

하지만 우리나라의 많은 회사에서는 그런 아키텍트가 제대로 일할 수 없는 환경이거나 그들의 가치를 알아보지 못한다. 물론 좋은 회사도 있지만 그리 많지는 않다.

제대로 성장했을 경우 10년차 정도면 실력도 뛰어나고 체력도 남아있고, 아직 꿈도 있고 스타트업에 참여하여 모험을 해볼만하고, 큰 조직에서는 개발 조직의 중추적인 역할을 할 수 있다.

문제 중 하나는 이런 10년차 개발자 중에서 아키텍트라고 부를 수 있는 개발자도 현실적으로 그렇게 많지 않다는 것이다. 또한 그들이 아키텍트로 성장할 수 있는 환경이 아니라는 것이 더 문제다.

매일 불끄기와 야근에 시달리다보면 성장은 커녕 일에 치이고 해놓은 일들이 자신을 발목을 잡고 바쁘기는 하지만 매일 가치없는 일에 매달리고 앞으로 나아가기가 어렵다. 이런 챗바퀴가 우리나라 많은 고참 개발자들의 생활이다.

그 악순환의 고리를 하나씩 끊어가야 한다.

성숙한 개발문화 정착이 어려운 이유

우리나라가 소프트웨어 개발을 잘하기 위해서 꼭 필요한 것 중에서 가장 먼저 성숙한 개발문화를 꼽는다. 그런데 간단해 보이는 것 하나도 정착하기가 보통 어려운 것이 아니다. 도대체, 개발문화가 왜 그렇게 정착하기 어려운지 그 이유를 생각해보자.

첫째, 문화란 혼자 바뀐다고 전체가 따라서 바뀌는 것이 아니다. 

문화란 집단의 공통된 행동 양식인데, 혼자서 전체를 바꾸기란 거의 불가능하다. 서로 이익이 된다면 자연스럽게 바뀌어 나가겠지만 대부분의 성숙한 개발 문화라는 것이 다같이 따를 때는 모두에게 이익을 가져다 주지만 혼자 제대로 하면 혼자 손해를 보기 마련이다. 정보를 공유하자고 해서 혼자 열심히 공유를 하고 다른 사람은 꼼짝을 안하면 혼자서 손해를 보는 것이다. 따라서 모두에게 이익이 되며 현재 수준에서 할 수 있는 것들로 조금씩 바꿔가지 않으면 거의 바뀌지 않는다.

둘째, 문화는 책으로 배우기 어렵다.

우리는 흔히 실리콘밸리의 개발문화를 전해 듣는다. 나이에 상관없이 소프트웨어 개발을 계속 할 수 있고, 나이 어린 팀장과 일할 수 있고, 공유와 리뷰가 활발하며, 이직이 활발하며 그래도 회사는 문제 없이 돌아가며, 개발팀의 기술적인 결정을 영업에서 함부로 뒤집지 않는다. 아키텍처를 고려한 장기적인 시간에서의 결정을 근시안적으로 뒤집지 않고 CTO가 CEO만큼 힘이 있다. 이런 얘기를 맨날 들어봐도 어떻게 해야 그렇게 되는지 알기는 어렵다. 결과만 보이지 상세한 행동 양식은 잘 보이지 않는다. 그래서 따라하려고 해도 따라하기 힘들다. 또한 쫓아 한다고 우리 의식 속에 깊이 자리잡은 우리의 문화를 무시하기도 어렵다.

셋째, 문화란 바뀌는데 오랜 시간이 걸린다.

문화는 짧게는 5년, 10년 이상 걸려야 바뀌는 것이 눈에 보인다. 그런데 우리나라에서는 아직 그정도의 인내심을 가지고 꾸준히 성숙한 문화를 정착하려고 노력해서 성공한 회사가 그렇게 많지는 않다. 중간 중간에 수많은 시행착오로 인해서 옆길로 빠지거나 포기하기 일쑤이다.

넷째, 단독으로 문화만 배울 수는 없다.

각 나라의 문화는 기후, 자원, 자연 등과 깊이 관련이 있다. 소프트웨어 개발 문화도 여러가지와 연관이 있다. 제도, 교육 상황, 산업 규모 등 수많은 것과 연관이 있다. 달랑 한 문화의 단면만 따라한다고 쉽게 되지는 않는다. 항상 기록을 남기는 방식으로 개발문화를 바꾸고 싶어도 기록을 남기는 것에 대해서 너무 훈련이 안된 개발자가 많다. 아키텍처를 중요시 하고 싶어도 뿌리깊은 영업 드라이브 문화는 쉽게 바뀌지 않는다. 따라서 우리의 현실을 무시한 성숙한 문화란 공염불에 그치곤 한다.

결론은 간단하지만 쉽지는 않다. 우리에게 알맞는 개발 문화를 찾아야 한다. 원칙을 거의 같지만 모습은 약간씩 다를 것이다. 그리고 혼자, 한 회사만 바뀌어서 될 일은 아니다. 업계 전체적으로 바뀌도록 노력해야 한다. 또한 5,년, 10년이상 꾸준히 노력해야 한다. 그래서 노력하는 사람이 대다수가 되면 이미 우리도 우리에게 알맞는 성숙한 개발문화를 가지게 될 것이다. 물론 10년안에 그렇게 바뀐다면 행운이고 30년이 걸릴지도 모르겠다.

공짜 점심이 개발자를 행복하게 할까?

이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.

최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다.

필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다.

3D 취급을 받고 있는 국내 소프트웨어 개발자들은 잘나가는 실리콘밸리의 소프트웨어 회사들과 높은 연봉을 받는 소프트웨어 개발자들이 부럽지 않을 수 없다. 종종 그런 회사들의 끝내주는 개발 환경이 부러움을 사곤 한다.

공짜 점심, 자유 출퇴근 제도, 공짜 커피, 편안한 사무실, 환상적인 휴게실/오락실/수영장, 선택 가능한 재택근무 등이 그것이다. 물론 회사마다 다르기는 하다.

우리도 개발자들에게 이런 공짜 점심 등의 혜택과 환경을 제공하면 개발자가 행복해질까? 회사는 더욱 성과를 낼 수 있을까? 뛰어난 개발자들이 모여들까? 

단순히 겉모습만 따라 하는 것은 단기적으로 효과가 있을지 모르지만 장기적이고 근본적으로는 해결책이 아니다.

여기서 우리는 착각하는 것이 있다. 그들이 제공하는 끝내주는 개발환경은 공짜가 아니다. 개발자가 예뻐서 주는 것이 아니다. 그들의 환경, 개발 문화, 개발 프로세스에 맞게 가장 성과를 잘 낼 수 있는 환경을 제공하고 있는 것이다. 

사무실 주변에 식당이 널려 있는 우리나라와는 다르게 실리콘밸리에서는 차를 타고 점심을 먹으러 가거나 샌드위치를 사다 먹어야 한다. 매번 차를 타고 점심을 먹으러 가는 것은 엄청난 시간 낭비이기 때문에 회사에서 공짜 점심을 제공하는 것이 회사에 더 이익이다. 실리콘밸리 회사들은 공유의 문화를 기반으로 수많은 리뷰가 있고 얼굴을 보지 않고도 효율적으로 일할 수 있는 프로세스와 시스템이 갖춰져 있다. 재택근무와 자유 출퇴근을 통해서 뛰어난 개발자를 효율적으로 활용할 수 있다. 이런 끝내주는 환경은 개발문화와 프로세스가 맞물려 나온 결과물이지 목적은 아니다. 

우리나라에서는 환경은 전혀 그렇지 않은데 그 결과나 겉모습만 따라 하면 회사가 잘 되기는커녕 자칫 악화를 초래할 수도 있다.

내가 생각하는 개발자가 진정으로 행복하게 일할 수 있는 환경은 좀 다르다. 개발자가 합리적으로 일할 수 있는 환경이 행복한 개발자가 될 수 있는 환경이라고 생각한다.

합리적인 커뮤니케이션이 가능하고, 개발자의 기술적인 의견이 존중되고, 적절한 개발 일정이 믿어지고 보장되며, 필요한 적절한 리소스가 제공되며, 빈번한 요구사항 변경으로 수많은 야근과 아키텍처가 산으로 가는 일이 없고, 개발자의 노력에 대한 적절한 보상이 이루어지고, 개발자 경력이 보장되는 환경이다. 물론 개발자도 그렇게 할 수 있는 역량이 있어야 한다.

좋은 복지 조건은 뛰어난 개발자를 유치하는데 도움이 되지만 아무리 뛰어난 개발자가 있다고 하더라도 비합리적인 환경에서 일한다면 효율적으로 개발이 되지 않을뿐더러 회사가 어려워 지면 좋은 복지가 오히려 회사의 발목을 잡는다.

나는 공짜 점심을 주는 것보다 경영진이 소프트웨어에 대해 좀더 이해를 하고 아무 때나 함부로 요구사항을 바꾸지 않고 합리적인 개발일정이 받아들여지면 좋겠다. 나는 공짜 커피보다 더 빠른 PC와 개발에 꼭 필요한 기반시스템에 투자를 해줬으면 좋겠다. 그것이 개발자인 나를 더 행복하게 만든다.

실리콘밸리 회사를 따라 가려면 겉모습보다는 그들의 개발 문화를 먼저 따라 하자. 공짜 점심은 약간의 돈만 있으면 쉽게 제공할 수 있지만 개발 문화를 따라 하는 것은 그보다 10배 100배 더 어렵다. 결실을 보는데 시간도 훨씬 오래 걸린다. 개발 문화를 따라 하는 방법은 책을 보고 배우기 어렵기 때문에 제대로 하더라도 5년, 10년 이상 걸릴 일이다. 그들이 50~60년 걸쳐서 쌓아온 문화를 단시간에 따라 잡기는 어렵다.

많은 회사들이 중요한 개발 문화 중 하나인 공유 문화를 따라 하려고 했지만 대부분은 겉모습 흉내만 내다가 정착에 실패를 했다. 또한 문화의 핵심은 모른 채 겉으로 드러나는 기법들만 쫓다가 회의에 빠져들기도 한다. 이렇게 실패한 경우에는 시도하지 아니한 만 못한 경우도 많다. 이도 저도 아니고 어중간해서 더 혼란스럽게 된다.

나름대로 깨어 있다는 개발자들도 의욕은 넘치지만 자수성가로 성장한 탓에 동료들을 이끌어서 효율적인 개발문화를 정착시키기에 한계를 느끼고 좌절하기 일쑤다.

제발 겉멋들어서 겉모습과 기법만 따라 하지 말고 진짜로 개발자가 행복해 할 수 있는 환경을 만들어 보자. 그것이 처음에는 힘들고 더 오래 걸리더라도 제대로 될 길일 것이다.

가끔 왜 두루뭉술하게 얘기를 하고 구체적인 방법을 알려 주지 않냐고 하는 사람들이 있다. 이런 짧은 글로는 방법을 구체적으로 알려주는 것은 불가능하다. 태권도를 글로 알려줄 수 없듯이 개발문화도 실전 경험을 많이 한 선배들의 코칭을 받아 직접 몸으로 부딪혀 보고 경험해 봐야 하는 것이다.

image by mcdonalds.com

‘한국의 저커버그’가 양성되기 위한 조건

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.

예전에는 한국의 빌 게이츠를 키워야 한다고 하더니 요즘은 스티브 잡스를 거쳐서 마크 저커버그를 키워야 한다는 목소리가 높다.  정부 주도의 한국판 저커버그 양성 프로젝트가 생기는가 하면 기업이 주도하는 시도들도 있다.  이런 시도들이 나쁜 것은 아니다.

프로그래머 인력을 키울 수는 있을 것이다. 하지만 빌게이츠나 저커버그 같은 사람이 탄생하는 데는 별 도움이 안될 것 같다. 과연 특수한 교육기관이나 양성 기관에서 그런 인물을 양성할 수 있을까?

그럼 한국의 빌게이츠, 저커버그를 양성하기 위해서 그들이 어떤 역량을 가지고 있는지 살펴보자. 물론 “인생 운칠기삼”이라는 말이 있듯 역량이 뛰어나기 때문에 빌 게이츠나 저커버그가 성공한 것은 아닐 것이다.

또한 그런 역량이 있는 사람이 무조건 성공하는 것은 아니다. 하지만 그런 역량을 가진 사람이 많이 배출될 수 있는 환경이 있다면 우리나라도 빌게이츠 같은 사람을 배출할 가능성이 높아질 것이다.

필자는 소프트웨어 개발자가 가져야 하는 역량 또는 소양을 8가지로 구분하여 비교를 해보았다. 비교 대상은 주변에서 흔히 볼 수 있는 일반적인 코더 또는 프로그래머, 경험이 많고 뛰어난 아키텍트 그리고 마지막으로 청년 시절의 빌 게이츠다.

비교 수치는 지극히 필자의 개인적인 의견이기 때문에 실제와는 차이가 있을 수 있으며 전체 맥락을 설명하기 위한 것이니 수치의 정확성을 가지고 논하지는 말자.

각 항목은 뛰어난 개발자 또는 아키텍트가 되기 위해서 필요한 역량과도 상당히 비슷하니 개발자라면 관심을 가져보자. 그럼 각 항목을 살펴보자.

1. 창의력

남들이 생각하지 못하는 새로운 생각을 해내고, 문제에 봉착했을 때 참신하고 뛰어난 해결책을 찾아가는 능력이다. 단시간의 교육으로 배울 수 없으며 소프트웨어에 대한 지식뿐만 아니라 다양한 인문학도 창의력과 연관이 있다.

2. 논리력

소프트웨어 개발자에게 필수적으로 필요한 역량이다. 수학 교육과 다양한 논리 교육으로 향상 될 수 있으며 선천적인 지능에 크게 좌우된다. 이를 향상하기 위해서는 어렸을 때부터 오랫동안 꾸준한 교육이 필요하다.

3. 커뮤니케이션 능력

일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다.  어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.

4. 문서 작성 능력

가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.

5. 컴퓨터, 소프트웨어 지식

소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.

6. 코딩 능력

누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 다른 부분에 비해서 상대적으로 단기적인 교육의 효과가 있다.  우리나라 프로그래머들이 별로 떨어지지 않는 능력이다.

7. 소프트웨어 공학 경험

소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.

8. 도전정신

소프트웨어 개발자에게 꼭 필요한 역량은 아니지만 빌게이츠나 저커버그를 양성한다고 하면 필요한 정신이다. 타고난 유전자가 큰 영향을 미치며 주변 환경에 영향을 받을 수 있다. 단기적인 교육으로 향상하기는 어렵다.

이 중에서 교육기관이나 양성기관에서 단기적으로 키워서 효과를 볼 수 있는 분야는 소프트웨어 지식이나 코딩 정도이다. 나머지는 어렸을 때부터 꾸준히 키워야 하거나 실전 개발을 통해서 배워야 하는 것이다. 인위적이고 단기적인 교육으로 빌게이츠나 저커버그를 만들어낼 수 없다는 것은 자명하다. 인문학을 조금 더 가르치는 것도 새발의 피일 뿐이다.

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

직업훈련소 같은 학원을 세울 것이 아니고 불합리한 소프트웨어 업계를 바로잡는 제도와 법률을 손보고 도전하는 청년 창업자를 지원하는 것이 좋겠다. 그렇게 소프트웨어 생태계를 건강하고 매력적으로 만들어야 우수한 인재들이 모여들고 소프트웨어 환경은 더욱 좋아질 것이다.

출처: http://cnet.co.kr/view/18291 

결국 최고 걸림돌은 경영진이다.

소프트웨어 회사가 제대로 개발 역량을 갖추는데 최고의 걸림돌은 소프트웨어에 대한 이해가 부족한 경영진이다.

일반 경영자들이 소프트웨어를 이해할 수 없기 때문에 CTO가 존재한다. 하지만 우리나라 대부분의 소프트웨어 회사에는 CTO가 없거나 있다고 하더라도 CTO역할을 하지 않고 있다.

흔히 벌어지는 심각한 문제는 프로젝트 기간 아무때나 요구사항을 변경하고 심지어는 소프트웨어 기획의 방향을 완전히 뒤엎곤 한다. 이로 인해서 소프트웨어 개발에는 어떠한 일들이 벌어지는지 모르는 듯하다.

알파 버전이 출시된 이후에 아키텍쳐를 뒤흔들만한 기능을 추가하도록 하는 경우도 있다.

자동차를 개발하면서 양산 직전에 휘발유차를 디젤차로 바꾸자는 소리를 하는 사람은 아무도 없을 것이다. 그런데 소프트웨어 회사에서는 경영진의 개인적인 주관으로 이런 요구를 하곤 한다.

관리적인 측면에서도 문제가 생긴다. 관리자와 개발자의 차이를 구분하지 못하고 고참 개발자는 무조건 관리를 해야 하는 것으로 생각한다. 전문 개발자는 30년이 지나도 관리는 전혀하지 않고 개발만 하는 것이다. 그러나 이렇게 개발 경력이 보장이 되는 소프트웨어 회사를 우리나라에서 찾는 것은 그렇게 쉬운 일이 아니다. 아무리 개발이 하고 싶고 관리는 적성에 맞지 않아도 우리나라에서 개발을 하는 이상 관리 업무에 대한 압박은 떠나지를 않는다.

또한 합리적인 관리를 할 수 없으니 무조건 일정을 쪼는 일 밖에는 하지를 않는다. 그러다 보면 아키텍쳐는 형편 없어지고 개발 문화는 뒤쳐질 수 밖에 없다.

몇몇 경영자는 이러한 현상이 개발자들이 제대로 못해서 그렇다라고 핑계를 댈 수는 있다. 닭이 먼저냐 달걀이 먼저냐의 이슈 같아 보이지만 강자인 경영자가 바뀌는 것이 우선이다.

이러한 문제점의 고리를 끊을 수 있는 사람은 개발자가 아니라 경영자이다.

문제의 핵심도 경영자이고 이를 해결할 수 있고 해결 해야 하는 사람도 경영자이다.

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 

그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.

1%

스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.

10%

그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.

30%

이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.

100%

SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.

따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.

그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다.

내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까?

그럼 한달동안 안나오면 어떻게 될까?

대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다.

이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다.

개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤 한다. 실제로 우리나라에서는 개발자들이 자리를 지키기 위한 좋은 수단이 되기도 한다.  하지만 개발자가 좀더 중요하고 새로운 일을 하는데 발목을 잡히곤 한다.

물론 내가 없어도 회사가 쌩쌩 잘 돌아가는 상황이 매우 불안한 사람도 있을 것이다. 또한 그렇게 합리적으로 돌아가지 않는 회사도 있으니 잘 판단해야 한다.

개발자 뿐만 아니라 Operating에서도 문제는 벌어진다. 특정 직원이 없으면, 빌드나 팩키징을 못하거나 라이센스 발급이 안되는 경우도 있다. 업무는 특정인만 아는 형태로 진행되어서는 안되고 메뉴얼이 필요하고 백업이 가능해야 한다.

회사 입장에서는 리스크일 뿐만 아니라 이런 현상이 벌어지고 있다는 것 하나만 봐도 소프트웨어 개발 전반에 많은 문제가 있다는 것을 짐작할 수 있다.

첫째, 많은 정보, 지식이 특정인 머리 속에 들어 있고 시스템화 되어 있지 않다는 것을 알 수 있다. 또한 리뷰를 통한 공유가 잘되어 있지 않은 것이다.

둘째, 스펙이 제대로 작성되어 있지 않은 것이다.

세째, 개발 프로세스가 제대로 구축되어 있지 않은 것이다. 그 외에도 문제가 많다.

회사는 어떠한 개발자라도 한달 동안 또는 영원히 사라져도 문제 없이 돌아가는 상황이 되어야 한다. 이렇게 하기 위해서 프로세스, 스펙/설계, 기반시스템, 개발 문화를 제대로 구축하는 것이 부담이 된다고 생각하는 경우도 있다. 이는 무조건 주먹구구가 더 빠르고 효율적이라고 주장하는 것과 같다. 초 단기적으로는 주먹구구가 더 나을 수는 있지만 이런 상황은 오래 지속되지 않는다.

특정 개발자가 없어도 잘 돌아가는 환경은 개발자에게도 유리하다. 그래야 개발자는 과거의 일에 발목을 잡히지 않고 합리적으로 일할 수 있는 환경이 된다.

이를 검증하기 위해서는 개발자에게 휴가를 한달씩 줘 보면 된다. 개발자에게 한달짜리 휴가를 줄 수 있는 회사가 되어보자.