고객이 요구사항을 너무 자주 바꿔요.

우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

변화하지 못하는 회사들의 공통점

회사가 변화하지 못한다는 것은 더 이상 발전이 없고 점점 쇠퇴해 간다는 것을 의미합니다.

변화하지 못하는 회사들은 항상 핑계를 대기 마련입니다. 어떠한 종류의 핑계들을 대며 변화하지 못하고 정체되어 있는 회사들의 공통점을 얘기해보죠.

첫째, 항상 바쁩니다.

주먹구구식으로 일을 하면서 항상 바쁘고, 또 바빠서 변화를 받아들일 수 없다고 합니다. 물론 핑계죠. 지금과 같이 일을 하면 계속 더 바빠지고 뒤죽박죽이 될 것이므로 혁신을 해나가야 하는데, 이를 핑계로 개발자들이 경영자에게 겁을 주면 대부분 잘 넘어갑니다.

둘째, 자기 회사는 매우 독특한 줄로 착각합니다.

1명짜리 소프트웨어 회사나 1,000명짜리 소프트웨어 회사나 소프트웨어를 개발하는 원리는 별반 다르지 않습니다. 그런데, 우리는 금융이라서 안전성이 매우 주요해서 프로세스는 도입할 수 없다. 우리는 포탈이라서 신속히 개발을 해야 하므로 문서를 쓸 시간이 없다. 우리는 게임을 만들기 때문에 일반적인 개발 방법은 통하지 않는다. 이와 같은 온갖 핑계를 댑니다. 물론 기존의 방법이 익숙하고 변화는 귀찮은 일이지만 변화하지 않고는 살아남기 어렵죠.

셋째, 경영자가 회사가 어떻게 돌아가는지 잘 모릅니다.

물론 경영자자 소프트웨어 개발에 대해서 개발자만큼 속속들이 잘 알 수는 없습니다. 그래서 CTO를 두는 것이고 CTO가 없다면 경영자가 소프트웨어 개발이 어떻게 이루어지는지 전체를 보는 눈이 있어야 합니다. 그렇지 않은 경영자들은 개발자에게 속아넘어가기 십상입니다. 우리나라에서는 CTO를 제대로 두고 있는 회사가 별로 없는 것이 안타깝습니다. 설령 CTO가 있다고 하더라도 그 역할과 파워가 많이 축소되어 있는 경우가 많습니다.

넷째, 회사에 파벌과 정치가 난무합니다.

회사의 변화는 Global 경쟁력을 갖춰나가고 효율성을 높이기 위한 방향으로 진행이 되어야 하지만, 정치가 난무하는 회사는 각 파벌들의 이익에 따라 회사가 좌지우지 됩니다. 이러한 회사에서 살아남는 방법은 승자에 편승하거나 떠나야죠. 정치판에 오래 몸을 담그면 자신도 물들어서 빨리 떠나는 것이 좋습니다.

다섯째, 개발자들이 우물 안에 개구리입니다.

개발자들이 자신의 실력을 과대포장하여 경영자들을 현혹하고 자신의 기술이 최고인양 착각하는 것입니다. 이러한 개발자들이 포진해 있는 회사는 아주 왜곡된 결과물들을 낳으며 금방 밑천이 드러나게 됩니다. 이러한 개발자일수록 자신의 기득권을 지키기 위해서 경영자를 쉽게 속이려고 합니다.

이 외에도 과거에 잘못된 방향으로의 변화 시도에 대한 아픈 기억들을 가지고 있어서 변화에 두려움을 갖고 있는 회사들도 있고, 방법을 몰라서 고민하는 회사도 있고, 재정적으로 충분한 여유가 없어서 가만히 있는 회사들도 있습니다. 하지만 어떻게든 변화하지 않으면 점점 후퇴한다는 것을 알아야 합니다.

변화하는 회사들의 공통점

여러 소프트웨어 회사들을 컨설팅 하다 보니 빠르게 변화해서 성공적으로 변신하는 회사가 있는가 하면 조그만 변화도 어렵게 어렵게 시도를 하면서 아주 더디게 변화하는 회사들도 있습니다.

A회사는 단 2개월 만에 목표한 바를 150% 달성하기도 하고

B회사는 1년 동안 처음에 계획하고 기대한 목표치의 50%밖에 달성하지 못하기도 합니다.

 물론 회사에 있어서 변화는 어렵습니다. 기존의 습관을 버리는 것도 어렵고, 기존의 방법이 잘못되었다는 것을 알아차리기도 어렵습니다. 설령 안다고 하더라도 기존의 방법을 구축해 놓은 사람들이 변화를 가로막고 심지어는 기득권을 지키려고 방해를 하기도 합니다. 또 변화 후에 더 좋아진다는 확신을 얻기가 어렵기 때문에 변화 자체는 항상 불안한 것입니다.

하지만 변화하지 않으면 더 이상의 발전이 없기 때문에 점점 경쟁력을 잃어서 결국은 끝나게 됩니다. 그래서 회사에 있어서 변화는 필수적입니다.

그럼 변화하는 회사들은 어떤 특징이 있는지 알아보겠습니다.

첫째, 경영자의 식견이 가장 중요합니다.

경영자가 변화의 필요성을 인식하고 변화의 올바른 방향을 파악할 수 있는 능력이 있어야 합니다. 경영자가 소프트웨어 기술을 자세히 알지 못해도 무엇이 필요한지 캐치해 낼 수 있는 능력은 있어야 합니다. 

둘째, 경영자의 의지가 중요합니다.

모든 변화는 반대와 방해에 부딪히게 됩니다. 그 방해는 그럴싸한 포장으로 둔갑해 있기 때문에 경영자의 의지가 강하지 않으면 쉽게 좌절하게 됩니다.

마지막으로 직원들의 Open mind입니다.

변화는 항상 힘들지만 올바른 변화는 회사의 경쟁력도 높여주지만 직원들의 가치도 올려줍니다. 그런데, 변화의 과정이 귀찮고 어렵다고 또 현재의 기득권을 잃게 될 것 같다고 변화를 거부하면 평생 그 자리에 머물러 있게 될 것 입니다. 

결국 변화는 경영자에게 달려 있다고 말하는 것 같은데 많은 부분 경영자에 달려 있는 것 맞습니다. 따라서 깨어 있는 직원들은 스스로 변화를 모색하기 보다는 경영자를 설득하여 경영층의 후원도 받아내야 변화에 성공할 수 있습니다. 

오늘의 잡담 - 개발자와 영어

이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다.

나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다.

대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다.

이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 경쟁하는 것과 같다고 생각합니다.

일단 소프트웨어 업계로 들어서면 너무 바빠지는 것이 일반적이라서 개발자가 왠만해서는 영어 공부를 하기 쉽지 않습니다. 학교 다닐 때 미리미리 영어 공부 유창하게 될 때까지 하고 오세요.

이미 개발자로 일하고 있고, 영어가 부족하다면 음... 알아서 꾸준히 공부하세요.

참고로 제 개인 블로그(http://raymond.pe.kr)에서는 영어 공부에 대한 주제로도 글을 꾸준히 올리고 있습니다. 혹시 영어 공부에 관심이 있으시다면 미미하나마 도움이 되면 좋겠네요.

"영어는 가까이하기엔 너무 먼 당신이다" - 매우 다가갔다고 생각하면 어느덧 또 멀어져 있는.......

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

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

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

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

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

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

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

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

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

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

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

모짜르트와 두 제자

모짜르트가 두 명의 제자에게 피아노 레슨을 한적이 있답니다.

한 명은 이제 막 피아노를 시작한 완전 초자이고

또 한 명은 이미 연주를 능숙하게 할 줄 아는 사람이었다고 합니다.

모짜르트는 누구에게서 더 많은 레슨비를 받았을까요?

바로 두 번째 사람이었습니다.

첫 번째 사람은 완전 초자이므로 모짜르트가 시키는 대로 그대로 따라와줘서 진도도 잘 나가고 강습에 문제가 없는 반면 두 번째 사람은 자기스타일을 고집하기도 하고 오랫동안 몸에 익은 습관을 버리기가 어려워서 먼저 그 습관을 다 없애고 다시 배워야 하기 때문에 배우는 시간도 몇 배 더 오래 걸리고, 가르치기도 더 어려웠다고 합니다. 그래서 레슨비를 더 많이 받아야 했습니다.

소프트웨어 컨설팅을 할 때도 아무것도 없는 회사는 맨땅에게 건물을 짓는 것과 같아서 상당히 빨리 성과를 낼 수 있습니다. 하지만 어설프게 프로세스와 시스템을 이것 저것 많이 만들어 놓은 회사들은 비효율적인 것들을 모두 부수고 다시 만들어야 하기 때문에 시간이 더 오래 걸리고, 기존에 그렇게 만들어 놓은 사람들의 반대와 방해에 부딪혀서 어려움에 봉착하는 일이 많습니다.

잘못된 길로 들어 선 회사들은 빨리 다시 되돌아 와야 합니다. 

되돌아 오기에는 너무 먼 길로 간 경우도 종종 있습니다. 이런 경우는 어쩔 수 없습니다. 환자에게 너무 큰 칼을 대면 죽을 수도 있으니까요. 비효율적이지만 익숙한 방법으로 계속 해나가는 수밖에는 없습니다. 그러면서 서서히 조금씩 바꾸는 것이 사망하지 않고 바꿀 수 있는 방법입니다.

성급하게 이것 저것 마구 시도해서 나쁜 습관만 잔뜩 들지 말고, 차근차근 제대로 갖춰 나갑시다.

레퍼런스 있어요?

컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다.

또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다.

히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 

레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다.

아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터 다시 다져야 합니다.

정부에서는 Global 수준의 소프트웨어 개발 방법을 배우기 위해서 외국인들을 활용하려고 하는 정책들이 나오고 있는데, 또, 헛돈을 쓰는 시행착오로 끝날 것이 불 보듯 뻔합니다. 국내 현실을 전혀 모르는 외국인들이 과연 국내 소프트웨어 회사들을 어떻게 바꿀 수 있을지 그림이 안 나옵니다. 영어도 잘 안 통하는 한국에서 또 뜬구름 잡는 소리만 하고 비싼 세금으로 만든 비용을 받아 가겠죠. 

결과를 지켜봐야겠습니다.