SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

첫째, NIH(Not Invented Here)신드롬이다. 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

셋째, 우리는 다르다고 생각하는 것이다. 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

자신의 코드에 발목 잡힌 개발자들

필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 

그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게 되는 현상에 관한 것으로, 이것이 왜 문제가 되는지 생각해 볼 수 있는 사례이지 싶다.
 
국내 A사는 소프트웨어 개발자만 100명이 넘는 업계 1위 중견기업이다. 이 회사 개발자들은 철저히 자신의 소스코드가 있어서 몇 개 프로젝트를 제외하고는 서로 공동으로 개발하는 경우가 거의 없다. 프로젝트도 거의 혼자서 담당하며 한 사람이 여러 프로젝트를 맡는 경우도 있다. 

이러다 보니 다른 사람의 소스코드를 볼 일이 거의 없다. 소스코드 뿐만 아니라 프로젝트간 정보 교류도 매우 적다. 이슈관리시스템을 사용하지 않고 공유 문화도 매우 취약한 회사다. 

그래서 개발자가 한 명만 아파서 못나와도 프로젝트에 큰 타격이 생기며 다른 개발자가 도와주기도 쉽지 않다. 개발 일이 한쪽으로 몰려도 어차피 소스코드별로 개발자가 정해져 있어 놀고 있는 개발자가 있어도 도와주지 못한다. 

부서마다 조금씩 다르지만 신입 개발자가 입사해 제대로 일하려면 수개월 정도는 공부를 해야 한다고 한다. 기존의 소스코드를 익히고 기반 지식을 공부하는데 수개월이 걸린다. 개발자가 퇴사할 때마다 개발팀은 큰 곤욕을 치르지만 경영진은 개발자를 아끼지 않는 것 같다는 하소연을 한다. 잦은 릴리즈와 고객 밀착형 유지보수 서비스로 개발자들은 이미 지쳐있다. 

우리는 이런 현상을 속된말로 '몸빵'이라고 한다. 개발사가 개발을 주도를 하지 못하고 고객에 끌려 다니면서 그때 그때 대응에 집중하는 것이다. 이런 환경에서는 계획으로 개발을 하지 못하고 격무를 피하기 어렵다. 아키텍처도 깔끔하게 유지하기 쉽지 않다. 

한편으로는 '컴포넌트 오너'라고 하는 현상인데 컴포넌트(Component)별로 주인이 정해져 있어서 다른 사람은 못 건드는 것이다. 이것은 비단 A사만의 얘기가 아니다. 국내 많은 개발자들이 자신이 작성한 소스코드에서 벗어나지 못하고 한 분야에서 계속 땅굴을 파 내려가 경험의 폭이 좁아지고 고급 개발자로 성장하기 어려운 환경에 처해 있다. 한쪽 분야의 숙련공이 될 수 있어도 고급 개발자가 되기는 쉽지 않다. 

국내 B사는 개발자만 수백명에 달하는 누구나 아는 회사다. B사는 이미 이런 문제를 겪었고 이를 타개하고자 개발자풀 제도를 시도했다. 과거에는 개발자를 팀별로 나눠서 팀내에서 주어진 일을 했는데 개발자 풀 제도를 통해 비효율적인 인력운영을 효율적인 체계로 바꾸고자 했다.

팀구분 없이 개발자를 한군데 모아 놓고 프로젝트 관리자가 프로젝트마다 필요한 개발자를 선별해서 개발을 진행하고 프로젝트가 끝나면 개발자는 다시 개발자풀로 돌아가는 방식이다. 잘 활용하면 팀의 구분 없이 최적의 개발자를 투입할 수 있고 한쪽 프로젝트에 일이 쏠려도 개발자들이 도와주기 용이하다. 개발자들은 회사의 여러 프로젝트에 투입되기 때문에 자연스럽게 지식을 공유하게 된다. 

취지는 좋으나 철저한 준비과정 없이 조직만 그렇게 바꿔 놓으니 일이 제대로 진행되지 않았다. 각자 전문분야가 다르니 다른 개발자를 투입해서는 일이 안됐고 결국 해당 일을 하던 개발자를 투입해야 했다. 매트릭스 조직이라 프로젝트 관리자와는 별도로 팀장이 따로 있으니 프로젝트에 특정 개발자가 필요해도 팀에서 개발자를 내놓지 않으면 프로젝트는 진행하기가 어려웠다. 

사람을 아무리 많이 투입해도 원래 개발자의 직접적인 도움 없이는 프로젝트를 수행할 수 없었다. 계속되는 혼란을 한참 겪은 B사는 결국 개발자 풀 제도를 포기하고 말았다. 

조직이나 프로세스만 바꿔서 역량을 향상하거나 효율적인 개발을 기대하기는 어렵다는 것을 경영진이 이해하지 못한 사례라고 할 수 있다. 

미국 F사의 경우는 개발자가 수천명에 달하는 글로벌회사다. 개발자가 새로 입사를 하면 오리엔테이션 기간에 실제 서비스가 되고 있는 시스템 버그를 고쳐야 한다. 입사 첫날부터 개발에 직접 투입되는 것이다. 신규 입사자 중에는 해당 개발언어로 개발을 해본 적이 없는 사람도 있다. 

하지만 버그를 고치는데 문제가 없다. 어차피 경험한 개발언어를 보고 개발자를 뽑은 것이 아니고 기초가 튼튼하고 문제 해결 능력이 뛰어난 개발자들을 채용했기 때문이다. 멘토가 있기는 하지만 옆에 끼고 계속 가르쳐 주는 것은 아니다. 

F사 신규 입사자에게는 소스코드가 저장된 SVN(Subversion) 주소와 버그관리시스템인 Bugzilla 주소를 통해  처리할 버그가 할당된다.  아무도 버그를 고치는 방법과 알아야 할 지식을 가르쳐 주지 않는다. 하지만 시스템 스펙과 설계문서에 접근할 수 있고, Bugzilla를 통해서 기존 개발자에게 도움도 받을 수 있다. 

신규 입사자는 소스코드를 분석해 버그 원인을 찾을 수 있다. 소스코드의 각 라인 별로 언제 누가 수정을 한 코드인줄 즉시 알 수 있고 소스코드를 수정할 당시의 관련된 이슈도 확인이 가능하다.

이후 신규 입사자는 SVN에 고친 소스코드를 등록하기 전에 코드리뷰시스템에 등록을 해서 리뷰를 받아야 한다. 간단한 버그 수정은 아무 문제 없이 코드리뷰를 통과하겠지만 몇몇 이슈는 온라인으로 진행된 코드리뷰의 도움을 받아 수정하기도 한다.

이렇게 버그를 고치거나 작은 기능을 구현하는 일은 신규 개발자들이 처리한다. 실력을 인정 받으면 점점 어려운 일을 할당 받는다. 고참 개발자들은 어려운 일이나 스펙과 설계 작업을 주로 진행한다. 개발자는 언제든지 새로운 프로젝트에 투입되고 물론 자신이 관심 있는 프로젝트에 지원할 수도 있다. 많은 개발자가 퇴사해도 서비스에 별 문제가 없고 대부분 즐겁게 일한다. 

우리가 가야 할 길은 명확하다. 구멍가게를 할 것이 아니라면 컴포넌트 오너식 개발은 금방 한계에 다다른다. 혼자서 시작하는 스타트업도 F사처럼 개발을 하는 것이 더 빠르고 효율적이다. 과거의 나와 현재의 나도 공유를 해야 할 필요가 있다. 

혼자 개발해도 적절한 공유와 문서화를 했을 때 개발이 더 빠른 이유다. 어찌 보면 한 우물을 파는 것이 전문성 향상에 도움이 될 것 같지만 다양한 경험 없이 한 우물만 파내려가면 우물 속 개구리가 되고 말 것이다. 

소프트웨어 회사 개발팀의 꽃은 아키텍트다. 개발자들이 다같이 각자의 우물을 파내려 가는 환경에서는 뛰어난 아키텍트가 나오기 어렵다. 뛰어난 아키텍트가 없는 회사의 미래는 뻔하다. 2층짜리 집은 근근히 만들 수 있어도 100층짜리 빌딩을 어찌 아키텍트 없이 만들 수 있을까? 

그래서 국내 1등은 가능해도 딱 거기까지가 한계다. 더 심각한 문제는 이런 식의 개발 환경에서는 개발자가 행복하지 않다는 것이다. 야근을 반복해야 하며 고참이 되도 계속 과거의 코드에 발목을 잡혀서 앞으로 나아가기가 어렵다. 

고참이 더 바쁜 회사는 이런 함정에 빠진 경우다. 이직을 하면 고리가 끊어지지만 새로운 회사에서 똑 같은 일이 반복된다. 

이를 해결하는 기가 막힌 한가지 묘수가 있는 것은 아니다. 가장 중요한 공유문화를 비롯해서 성숙된 개발문화가 정착되면 자연스럽게 해결 된다. 개발문화를 소홀히 생각하고 프로세스만 강화해서는 절대로 F사와 같은 상황이 벌어지지 않는다. 이것이 다같이 성숙한 개발문화에 정착에 힘을 써야 하는 이유다. 

대한민국 개발자가 불행한 이유

미국에서 과거 10년 넘게 최고의 직업에 항상 소프트웨어 개발자와 아키텍트가 자리하고 있고 미래 성장 가능성도 상당히 높게 평가하고 있는 것을 보면 격세지감을 느낀다. 10개나 100개 직업 중에 1위가 아니고 몇 만개의 직업 중에 1위라는 것은 대단한 것이다. 그러나 우리나라에서 소프트웨어 개발자는 그렇게 인기가 있는 직종이 아니다. 의사, 변호사와 비교는 고사하고 3D 직업이라는 인식도 팽배하다.

이는 단순히 소득의 차이 때문은 아닌 것 같다.

우리나라에서 소프트웨어 개발자로 일하게 되면 10년, 20년 그리고 30년 이상 소프트웨어 개발자로 계속 일할 수 있다는 희망이 잘 보이지 않는다. 왜 그럴까? 이런 환경에서 태어난 대한민국의 소프트웨어 개발자는 불행하다고 할 수 있다. 미국이라고 무조건 개발자로서 성공적인 삶을 사는 것은 아니지만 같은 조건이라면 개발자로 잘 성장할 확률이 더 높고 여건도 좋다.

이런 차이가 발생하는 이유는 타고난 재능의 차이도 아니다. 개발자들의 기술력의 차이도 아니다. 바로 환경의 차이 때문이다. 소프트웨어 산업 생태계의 차이도 크지만 각 회사, 개발팀의 개발 문화 차이가 가장 크다. 이런 개발 환경을 만든 것은 개발자 여러분은 아니고 여러분의 선배들과 회사이다.

지금 이 글을 읽고 있는 소프트웨어 개발자가 만약에 미국에서 태어나 소프트웨어 개발자로 일하고 있다면 상당히 다른 환경에서 다른 경험을 하면서 성장할 것이다.

물론 우리나라가 더 좋은 환경을 가지고 있는 것도 있고, 내세울 수 있는 것도 있지만 소프트웨어 환경에 대해서는 이 땅에서 태어나 영어 때문에 고생하는 것처럼 핸디캡이 되는 것은 사실이다.

소프트웨어 선진국은 개발 프로세스, 기반 시스템, 조직 문화, 개발 문화 측면에서 큰 차이가 있고 성장을 도와줄 선배 개발자들이 많고 롤모델(Role model)도  있다. 우리나라에도 선배 개발자들이 많이 있지만 경험의 전수가 잘 안되는 구조가 문제다. 여기서 선순환과 악순환의 차이가 발생한다.

소프트웨어 선진국에선 입사를 하면 대부분 바로  업무에 투입된다. 문서, 시스템이 잘 갖춰져 있어서 버그를 수정하는 일을 하는데 큰 어려움이 없다. 버그추적시스템을 통해서도 버그를 할당 받고, 많은 정보를 얻을 수 있다. 소스코드는 시스템을 통해서 바로 한줄 한줄의 수정된 역사를 볼 수 있고 내용을 물어보러 다니지 않아도 웬만한 버그는 수정이 가능하다. 빌드도 자동화 되어 있어서 내용을 몰라도 누구에게 물어보지 않고도 한번에 빌드가 된다. 또한 내가 고친 코드는 피어 리뷰(Peer review)를 통해서 코딩 컨벤션 준수 여부뿐만 아니라 더 좋은 기법 등을 배운다. 분석, 설계 등에도 참여하고 지속적인 피어 리뷰를 거치면서 경험이 점점 깊어지고 후배나 동료들에게 내 지식과 경험도 공유하게 된다.

이렇게 할 수 있는 핵심은 적절한 피어리뷰다. 피어리뷰가 가능한건 기반시스템이 잘 갖춰져 있기 때문이다. 또 개발에 집중할 수 있고 다른 일은 신경쓰지 않아도 되는 프로세스와 조직문화 때문이다. 10년, 20년이 되면 시니어 엔지니어가 되거나 아키텍트가 될 수 있다. 회사 내에서 다른 프로젝트로 옮겨 다니거나 이직을 해도 후배들이 이어 받아서 아무 문제없이 개발이 지속된다. 15년이 되었는데 연봉도 다른 직업의 친구들보다 훨씬 높고 만족감이 높다.  과거 같이 일하던 동료가 차린 유망한 스타트업에 스톡옵션을 받고 참여하는 기회도 잡을 수 있다.

그럼 우리나라에서 소프트웨어 개발을 시작한다면 어떨까? 좋은 회사, 나쁜 회사, 여러 가지 경우가 있지만, 그 중 일반적인 예를 하나 보자.

대학에서 소프트웨어 전공을 하고 입사를 했다. 회사에서 개발하고 있는 소프트웨어에 대한 도메인 지식이 없으면 개발에 참여 하기가 어렵다. 관련 서적을 받아서 몇 달간 공부를 하고 회사에 대한 여러 가지 교육을 받는다. 제대로 개발에 참여하려면 최소 6개월이 걸린다고 하니, 일단 바로 유지보수에 투입된다. 소프트웨어를 파악할 수 있는 자료는 소스코드 밖에 없다. 선배들에게 물어물어 소스코드를 내려 받았고 개발환경을 구축하는데도 하루가 걸렸다.

빌드가 쉽지 않아서 여러 번의 실패와 우여곡절 끝에 빌드에 성공했다. 소스코드를 보고 분석을 하다가 도저히 몰라서 선배에게 물어보려니 개발한 선배가 퇴사를 했단다. 밤을 세서 수정을 했는데 제대로 동작하고 부작용(Side effect)은  없는지 확신은 없다. 누구도 내가 작성한 코드를 리뷰해주지 않는다. 그러다가 개발한지 얼마 되지도 않았는데 실전 사이트에 투입됐다. 선배와 같이 고객을 만나서 요구사항을 듣고 커스트마이징 작업을 진행했다. 워낙 바빠서 문서작성은 꿈도 못 꾸고 코딩만 했다.

선배와 내가 아니면 회사의 누구도 우리가 한 작업의 내용을 모른다. 경험이 쌓이면서 좀더 어려운 일을 맡고 바쁜 개발일정을 소화한다. 문서도 없고, 시스템에도 정보도 없고, 피어 리뷰도 없는 것은 여전하다. 회사에서 강제로 문서를 만들라고 해서 만들기는 하지만 쓸모 없는 문서일 뿐이다.

7년쯤 일하니 회사에서 제일 개발을 잘하는 개발자가 되었다. 경영진이 능력을 인정해서 팀장도 되었다. 팀장이 되니 회의도 많고 보고서도 많이 써야 한다. 낮에는 일할 시간이 거의 없어서 직원들 퇴근 후에 개발을 하게 되었다. 그러나 보니 차츰 개발에서 손을 떼게 되었다. 다시 개발로 돌아 가려고 하지만 여건이 안 된다. 팀장을 몇 년 하다 보니 정체성이 없어지고 앞길이 막막해졌다. 이제 치킨집을 차릴 때가 되었나 보다.

이러한 선순환과 악순환의 차이를 극복하려면 개발 환경을 바꿔야 한다. 개발프로세스, 기반시스템, 개발문화, 조직문화가 바뀌어야 한다. 우리가 이를 바꿔나가지 않으면 우리 후배들도 10년, 20년 후에 똑같은 얘기를 하면서 한숨을 쉬고 있을 것이다. 이는 비단 후배들만을 위한 일은 아닐 것이다. 우리가 일할 10년, 20년 후의 소프트웨어 환경을 바꾸는 일이다.

환경을 바꾸려고 하니 무엇부터 바꾸어야 할지 막막한 경우가 많다. 물론 회사마다 다르기는 하지만 쉬운 것부터 하는 것이 좋겠다. 우선 효율적인 기반시스템을 갖추는 것이 좋다. 성숙도에는 차이가 크겠지만, 소스코드관리, 버그관리, 빌드 자동화를 갖추고 서로 연동을 시킨 뒤  소스코드를 보면 버그나 이슈가 연결되고 반대로 버그가 소스코드와도 쉽게 연결될 수 있는 환경을 만들어야 한다.  그리고 나면 피어 리뷰를 할 수 있는 환경이 조금씩 되어 간다.

거의 모든 것을 완벽하게 자동화하는 것이 바람직하다. 자질구레하게 중간중간 수동 작업이 많이 들어가면 회사가 커갈수록 비용은 점점 올라가고 비생산적인 일에 많은 노력을 들여야 한다. 또 완전 자동화된 시스템 환경이어야 공유와 효율적인 협업이 가능하다. 인터넷에서 정보를 얻어서 좋을 툴을 설치하는 것은 어렵지 않지만 제대로 구축해서 잘 사용하는 것은 몇 백배 더 어렵다. 경험을 많이 해본 선배들의 도움을 받는 것은 필수적이다.

이 정도 되어야 환경을 바꾸기 위한 마라톤의 한 발을 내디딘 것이라고 보면 된다. 그래도 시작이 반이다. 의미 있는 한발이 될 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

티끌모아 태산 (개발 시간 절약하기)

성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다.

하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다.

시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다.

10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다.

소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로 발전시켜나가는 노력이 필요하다.

회사마다 여건이 조금씩 다르지만 몇가지 예를 들어보겠다.

10초라도 낭비하면 아까운 시간들이다.

• 빌드가 완전 자동화가 되어 있지 않아서 소스코드를 빌드할 때마다 약간이나마 중간에 수작업이 들어가는 시간 - 빌드는 완전 자동화를 구현해야 한다. 당연히 Command line으로 빌드가 되어야 하고 한번의 Enter로 최종 설치본까지 생성이 되어야 한다.
• 이슈(버그)관리시스템을 잘 관리해보고자 너무 많은 커스텀필드를 넣어서 이슈(버그)를 등록할 때마다 몇초씩 더 걸리는 시간 - 적당한 커스트마이징은 필요하지만 과도함은 삼가해야 한다.
• 이슈관리시스템이 있는데 보고나 관리를 위해서 별도의 자료를 만드는 시간 - 이슈관리시스템을 이용하면 원하는 View로 원하는 정보를 실시간으로 볼 수 있다. 관리자도 보고를 기다리지말고 직접 이슈관리시스템을 봐야 한다.
• 여러벌의 Branch에 같이 존재하는 버그를 동시에 고치기 위해서 수작업을 할 때 - SCM의 Merge기능을 믿지 못하거나 기능을 활용할 줄 몰라서 수동으로 Merge를 하는 행위는 정말 시간 낭비이다. 제대로만 사용한다면 SCM의 Merge기능은 막강하고 99.9% 믿을만하다. 수작업이 아니고 최종적인 확인 정도만 해도 되는 경우가 대부분이다.
• 개발자들의 주간 보고서 작성하기 - 이부분은 약간 논란의 이슈가 있다. 정말 간단한 주간보고서는 큰 무리가 없지만 부담스러울 정도의 주간보고서는 개발자들이 작성하지 않는 것이 좋다. 개발자들의 업무 기록은 이슈관리시스템 등에 다 남아 있다. 관리자는 개발자를 괴롭히지 말고 스스로 시스템을 보면 된다. 물론 기반시스템들이 잘 구축되어 있어야 한다.

이 외에도 코딩시 일반 업무시 절약할 수 있는 시간음 무궁무진하다. 이런 시간을 꾸준히 찾아서 제거해 나가는 노력이 필요하다.

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

스타트업을 위한 조직론

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

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

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

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 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에 기고한 글입니다.

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

이론과 실제는 다르다. 

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

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

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

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

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

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

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

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

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

개발자

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

영업

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

경영진

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

마케팅

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

결론

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

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

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

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

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