2013년 9월 9일 월요일

생각의 폭을 넓혀야 한다.

우리나라에서 Global Software가 많이 탄생하지 않는 이유 중 하나는 개발자의 생각의 넓이가 좁기 때문이다. 물론 우리나라에도 뛰어난 아키텍트들도 있지만 생각이 넓이가 좁고 단편적이고 지엽적인 생각에 갇힌 개발자들도 매우 많다.

뛰어난 아키텍트라면 소프트웨어의 Scalability를 항상 생각한다. 물론 모든 상황에서 모든 Scalabiltity를 생각하는 것은 아니다. 비즈니스 계획 및 전략을 고려하여 가능성을 모두 검토한다.

지금보다 고객이 100배로 늘어난다면?
지원하는 국가 및 언어가 100배로 늘어난다면?
다뤄야할 데이터가 100배, 10,000배로 늘어난다면?
소스코드의 크기가 100배로 늘어난다면?
개발자가 100배로 늘어난다면?
고객과의 거리가 100배, 10,000배로 늘어난다며?

아키텍처는 이런 Scalability를 충분히 고려해서 설계를 해야 한다. 또한 프로세스를 자동화 해야 한다. 이렇게 여러분야에서 100배씩 늘어간다면 복잡도는 수천, 수만배 복잡해지는데 자동화를 하지 않으면 그 배수만큼 고스란히 비용이 발생한다.

여기서 국내 소프트웨어 회사와 글로벌 소프트웨어 회사의 차이가 많이 발생한다. 여러분도 다 아시는 국내 포탈회사는 아직도 많은 부분을 수동에 의존하고 있고 물론 고객도 그렇게 수동으로 관리된 컨텐츠를 좋아하고 있다. 그러다 보니 글로벌 시장에서 경쟁은 점점 어려워지고 있다. 로컬 1등 기업을 될 수 있어도 글로벌 유망 기업은 되기 어려운 이유 중 하나이다. 

많은 개발자들은 제품 초기에 아무런 비즈니스 전략 없이 대충 만들어 놓았다가 비즈니스가 잘되면 더 어려워지는 경우가 흔다. 개발자들이 생각의 폭을 좀더 넓혀야 한다.


2013년 9월 4일 수요일

소스코드가 없어졌다.

필자는 소스코드가 없어진 Software 회사를 여러번 보았다. 물론 회사의 전체 소스코드가 없어진 것은 아니다. 일부 소스코드가 없어져서 낭패를 보는 경우는 매우 흔하다. 소스코드는 어떻게 없어지게 될까? 물론 아래 모든 경우는 전사적인 소스코드 관리 및 백업을 받지 않은 경우에서 발생한다.

1. 하드디스크가 망가졌다.

하드디스크는 그렇게 믿을 만한 미디어가 아니다. 어느날 갑자기 망가져 버릴 수도 있고 복구가 안되는 경우도 종종 있다. 10년간 잘 돌던 하드디스크가 PC를 옮겼더니 갑자기 먹통이 되는 경우도 있다. 이런 경우 백업이 없다면 소스코드를 잃어버리는 것이다. 각 개발자의 PC에 사본이라도 있다면 History는 없어져도 최신 소스코드는 건질 수 있지만 그렇지 않아서 소스코드르 잃어버리는 경우를 종종 보았다.

2. 외주를 주고 소스코드를 받지 않은 경우

이 경우도 의외로 많다. 개념이 없이 소스코드를 받지 않은 경우도 있고, 계약상 소스코드는 제공하지 않는 경우도 있다. 두경우 문제가 되기는 마찬가지다. 개발툴을 업그레이드하려면 소스코드가 필요한데 그럴때 외주사가 망해 버리면 영영 발목이 잡혀버린다. 이럴 때는 소프트웨어진흥원에 소스코드 에스크로를 하면 회사가 망했을 때 소스코드를 가져올 수 있다. 외주사가 망해서 소스코드가 없어지는 경우은 의외로 흔하다.

3. 개발자가 소스코드를 관리하다가 퇴사를 한 경우

회사의 중요 제품이라면 소스코드를 잃어버리는 일이 흔하지 않지만 오래된 제품이나 툴등의 소스코드라면 개발자가 대충 소스코드를 보관하고 있다가 퇴사를 해버려서 언제 어떻게 잃어버렸는지도 모르게 소스코드가 없어지는 일이 발생한다. 수년 후 나중에 소스코드가 필요할 때 없어졌다는 사실을 알게 된다.

4. 회사의 소스코드관리시스템(SCM)을 백업받지 않은 경우

소스코드관리시스템을 도입하고 백업을 받지 않는 회사는 엄청나게 많다. 놀랄 일이다. Git등의 분산SCM을 쓴다면 어딘가에 백업이 있지만 SVN을 쓰다가 서버가 날아가면 간신히 부분적인 최신 소스코드만 건지게 된다. History가 사라진 최신소스코드는 그 가치가 몇분의 일로 줄어든다. 물론 많은 회사가 소스코드관리를 제대로 하지 않아서 History가 거의 가치없는 경우가 많다. 하지만 소스코드관리를 제대로 한 경우라면 History는 꼭 필요하다. SCM의 백업은 선택이 아닌 필수다.

이를 방지하는 방법은 전사적으로 소스코드관리를 철저히 하는 것이다. 하나의 통일된 소스코드관리시스템을 사용해야 한다. 회사 몰래 개발자가 숨겨 놓은 소스코드가 존재하면 안된다. 아무리 그렇게 관리를 해도 개발자들이 개인적으로 가지고 있는 소스코드가 존재할 수 있다. 스크립트라고 등록하지 않고, Install shield 프로젝트는 등록하지 않기도 한다. 이런 문제가 발생하는 또다른 이유는 개발자가 개발자PC에서 빌드를 하기 때문이다. 빌드를 빌드 전용서버에서 빌드 담당자가 하게 될 경우 숨어 있는 소스코드를 모두 끄집어 낼 수 있다. 빌드 전용서버는 오로진 SCM에서 소스코드를 가져다가 빌드를 하기 때문에 개발자PC에 숨겨진 소스코드가 있다면 빌드가 되지 않게 된다. 개발자를 못 믿어서가 아니고 빌드는 개발자PC에서 하면 안되는 것이다.

그리고 백업을 제대로 받아야 한다. 백업은 제3의 장소에 보관해서 회사가 완전히 불타 없어져도 소스코드를 바로 복구할 수 있어야 한다는 생각으로 백업을 해야 한다.

이런 환경을 구축하는 것은 비용이 더 많이 드는 일이 아니다. 제대로 관리를 하지 않고 소스코드를 엉망으로 관리하면서 오는 비효율과 비용 및 손실과 비교하면 훨씬 이익이다.

2013년 9월 3일 화요일

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

미국에서 과거 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)