경영자가 개발자의 거짓말에 현혹되지 않는 법

제대로 체계를 갖추기 못한 회사에서는 개발자가 경력이 늘어갈 수록 거짓말이 늘곤 한다.

비효율적인 것을 알지만 (혹은 모르기도 하고) 자신의 기득권을 지키기 위해서 거짓말로 경영자를 현혹하곤 한다. 고의적인지 아닌지 그 경계는 매우 모호하다. 

물론, 뛰어나고 훌륭한 고참 개발자들도 많다. 회사의 기술을 리드하고 후배들을 이끌며 귀감이 되는 개발자들도 많다는 것을 잘 알고 있다. 

많은 개발자들이 이 글을 보고 반발할 수도 있음에게 이 글을 쓰는 이유는 자의든 아니든 경영자를 거짓말로 현혹하는 개발자들이 꽤 있기 때문이다. 경영자는 이러한 거짓말에 현혹되지 않기를 바라는 마음이다.

경력이 많은 개발자들에 비해서 경력이 부족한 신참 개발자들은 솔직한 편이다. 

신참 개발자들은 지켜야 할 기득권이 별로 없고, 아직 개발에 대한 열정이 남아 있고, 앞으로 개발해야 할 날이 많이 남아 있으므로 올바른 선택을 하려고 노력한다. 

고참 개발자들이 하는 대표적인 거짓말들은 다음과 같은 것들이 있다.

- 프로세스 무용론 : 프로세스란 대기업이나 필요한 것이다. 프로세스는 오히려 효율을 떨어뜨린다.

- 신입 무능론 : 요즘 신입은 실력이 부족해서 일 시키기가 어렵다. 개발도 느리고 버그도 많이 만든다.

- 나 밖에 못한다 : 이것은 복잡하고 어려워서 나 아니면 아무도 못한다. 그래서 뭐든 자기가 하려고 한다. 

- 문서는 개발을 더 늦게 만든다 : 우리 회사는 개발 일정이 너무 촉박해서 문서를 만들 수 없다.

경영자들은 주로 고참개발자들과 얘기를 하기 때문에 신참 개발자들의 솔직한 얘기를 듣기가 어렵다. 그래서 옛날 왕들처럼 가신들에 둘려 쌓여서 실정을 제대로 모르는 경영자가 된다. 이렇게 실정을 모르는 경영자들은 회사가 어려워져도 개발조직이 문제라는 것을 쉽게 알아차리지 못한다. 결국 망해가는 길 밖에 없다.

여기에 현혹되지 않는 가장 좋은 방법은 능력 있는 CTO를 두는 것이다. 능력과 경험이 있는 CTO에게는 개발자들이 하는 어떠한 거짓말도 통하지 않는다. 심지어는 몇 마디만 딱 들어도 왜 거짓말을 하고 실력이 어느 정도 인지 다 파악이 된다. SW개발이 아닌 다른 분야도 마찬가지 아닌가. SW도 똑같다.

경험과 능력 있는 CTO가 절대적으로 부족한 우리나라에서는 경영자가 신참개발자들과 자주 소통을 하는 것이 중요하다. 그러면 고참개발자들과 다른 얘기를 할 것이다. 그러면 둘 중 하나는 거짓말을 하고 있는 것이다. 물론 고참이 거짓말을 할 가능성이 더 높다.

CTO가 없다면 개발자들의 말만 듣지 말고 주변의 능력있는 CTO급 개발자에게 가끔 조언을 구하는 것이 좋다. 단 이해가 얽히지 않는 사람이어야 한다. 경영자가 절대로 알지 못하는 얘기를 해줄 것이다.

그러한 조언자도 없지만 회사의 여러 개발자들과 골고루 얘기를 해야 한다. 그렇지 않는다면 가신에 둘러싸인 왕 신세가 될 수도 있다.

이 글을 보고 발끈한 개발자들 중에는 본인이 여기에 해당하지 않나 생각해보기 바란다. 그렇지 않다면 회사의 진정한 기술 리더 일 것이다.

문서가 없으면

작은 프로젝트인 경우 문서를 거의 만들지 않고 개발을 하면 더 효율적이라고 생각할 수도 있다.

가끔은 그렇게 생각할 수도 있다. 너무 시간이 없다는 핑계를 대기도 한다.

하지만 이렇게 해서 모든 프로젝트에 문서가 거의 없으면 개선을 하려고 하는 회사에서 도움을 요청해도 막상 도와주기가 매우 어렵다.

문서가 거의 없어서 모든 것을 물어보면서 파악을 해야 한다. 있는 것이라고는 거의 쓸모 없는 문서와 소스코드인데 소스코드는 회사와 제품을 파악하는데 별 도움이 안된다.

문서가 제대로 있다면 80%는 문서를 보고 20%만 물어 보면 된다.

이때 개발을 하고 나서 나중에 만드는 문서는 그 효율성이 반으로 줄어든다.

나중에 만드므로 일단 충실도가 떨어지고 개발하기 전에 만들때 고려해야 할 요소들은 프로젝트가 이미 끝났기 때문에 다 생략된다. 사실 제대로 적기도 어렵다.

이런 문서라도 없는 것보다 낫기는 하지만 프로젝트만을 위한 것이라면 이런 문서는 별로 필요도 없다. 유지보수를 위해서라면 차라리 코드를 보는 것이 낫다. 들어간 시간에 비해서 효과가 별로 없다는 뜻이다.

이는 신입사원이 입사를 했을 때에도 똑같다. 개발팀에 합류하여 제대로 개발을 시작하려면 프로젝트를 파악해야 하는데 문서가 없으면 파악하기가 너무 어렵다.

선배들이 말로써 하나씩 설명을 해줘야 하는데 다들 바빠서 그렇게 할 수가 없다. "멘토" 또는 "사수"를 정해서 알려주라고 하는데 어디 사수들이 그렇게 한가한가?

그러다 보니 신입 개발자들은 제 능력을 발휘하려면 너무 오랜 시간이 걸린다. 거의 자수성가 식으로 소스코드를 보고 분석해서 하나씩 시행착오를 거쳐서 배워야 한다. 이 과정에서 버그도 많이 양산해내게 된다. 

몇 년이 지난 후에 이제 좀 개발을 할만하면 또 후배가 들어온다. 해 온 방식이 이 방식이라 후배들에게 똑같이 전수를 하게 된다.

즉 "악순환"인 것이다.

프로젝트를 진행하면서 프로젝트 기간을 단축하기 위해서 당연히 만드는 문서들은 다른 개발자들이 도와주기 쉽게 만든다. 

무슨 문서를 얼마나 자세히 만들어야 하는지는 프로젝트마다 다르다. 하지만 내가 경험한 수많은 프로젝트들은 문서가 그렇게 많이 필요하지 않았다. 설계문서까지도 필요 없는 경우도 매우 많다. 어떤 문서를 어떻게 적는 것이 가장 효율적인지는 경험에서 나온다. 경험없는 개발자들이 문서를 아예 적지 않거나 너무 많이 적는다.

너무 많이 적을 바에는 아예 문서를 적지 않는 것이 나은 경우도 많다.

문서는 딱 필요한 만큼만 적어야 한다.

그래야 다른 사람이 도와줄 수 있고 나는 더 가치 있는 일을 할 수 있다.

아는 것과 실행하는 것

"아는데 지금은 바빠서 못한다."라고 하는 말을 종종 듣는다.

"개발을 체계적으로 해야 하는데 지금은 그럴 여유가 없다."

"소프트웨어 개발을 할 때 문서를 제대로 써야 하는 것을 알고 쓸 줄도 아는데 시간이 없어서 그렇게 할 수 없다."

"Peer review를 해야 하는데 그럴 시간이 없다."

"시간이 걸리더라도 신입 개발자들에게 시켜야 하는 일이지만 너무 급해서 내가 직접 한다."

가만히 얘기를 들어보면 시간만 있으면 뭐든지 다 할 수 있을 것 같이 얘기를 한다. 그리고 또한 다 할 줄 안다고 한다.

이런 얘기를 하는 사람들의 대부분은 해본적도 없고 할 줄도 모른다는 것이다. 또한 시간이 아무리 많이 있어도 그렇게 하고 싶은 생각은 없을 것이다.

이런 것이 필요하다는 것을 알고 있다면 이미 시행하고 있을 것이다. 시간이 없어서 소프트웨어 공학을 적용하지 못한다는 것은 핑계이거나 소프트웨어 공학이 무엇인지 전혀 모르고 있는 것이다.

문제는 이런 사람들이 분위기를 흐린다는 것이다. 소프트웨어 공학이 마치 필요는 하지만 지금은 아닌 것 같은 착각을 하게 된다. 소프트웨어 공학은 1명이 개발하더라도 필요하고 10,000명이 개발하더라도 필요한 것이다. 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다. 

시간이 없어서 그렇게 못하고 있다면 소프트웨어 공학이 뭔지 잘 모르고 시행하는 방법을 모르고 있었던 것 뿐이다.

맨날 건강을 위해서 운동을 해야 하는데 지금은 바빠서 운동을 못하고 있다고 얘기하는 것과 똑같다. 이런 사람은 시간이 남아 돌아도 운동을 하지 않는다. 운동이 재미 있어야 하는 것이다. 

소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다. 경영자 입장에서는 비용이 줄어든다. 그렇지 않다고 생각하고 있는 사람이 있다면, 또는 알고는 있는데 지금은 바빠서 못한다고 생각하는 사람이 있다면, 소프트웨어 공학이 무엇인지 잘못 알고 있는 것이 아닌가 다시 한번 생각해보는 것이 좋다.

작은 회사에서 희망을 보다.

흔히 우리나라 소프트웨어 업계는 희망이 없고 SW개발자는 4D (Dirty, Difficult, Dangerous, Dreamless) 업무를 하고 수행하고 있다고 생각한다.

제대로 된 방향으로 이끌 맨토가 부족해서 선순환 하지 못하는 업계에서 Global 경쟁력을 갖춘 소프트웨어 회사는 많지 않다. 하지만 아직은 부족하지만 Global 시장에서 성공할 가능성이 있는 작은 회사들이 눈에 띄는 것은 희망적이다. 

큰 회사보다 작은 회사에서 더 희망을 볼 수 있는 것은 의외일 수 있다.

SW 회사들 중에 큰 회사는 개발자가 수백명이고, 매출액이 수백억, 순이익이 100억 이상인 회사들이 꽤 있다.

이렇게 외형적으로 좋아 보이는 회사들이 미래가 어두운 경우가 많은 것은 믿어지지 않을 수 있다. 

(물론 흔하지는 않지만 정말 좋은 회사도 종종 있다.)

이런 회사가 미래가 어두운 이유는 여러가지가 있겠지만 주된 이유는 회사의 성장 과정에서 볼 수 있다. 많은 경우 개발 역량을 키우고 뛰어난 제품을 개발하기보다는 영업력으로 성장을 해오면서 개발프로세스는 엉망이고 여전히 단기적인 이익을 쫒으며 눈앞의 목표에만 목을 맨다. 

경영자가 변화를 하려고 해도 방해하는 세력이 많고 반대하는 세력의 그럴듯한 이유를 거부할 수 있는 힘이 경영자에게는 없다. 또한 개발자는 변화를 싫어해서 이에 동조한다.

물론 경영자가 문제 상황의 핵심을 제대로 파악하고 있지 못한 경우도 많다. 

매출액 1,000억을 목전에 두고 성장의 한계에 다다랐고, 쇄락의 미래밖에 보이지 않는다. 1,000억의 한계는 어떤 SW분야든 우리나라 경제 규모에서 내수 시장만 공략해서 넘기 힘든 벽으로 생각된다. 즉, Global 경쟁력 없이는 이쯤에서 꺽이는 것이 당연하다.

신규투자는 순이익 감소 때문에 경영자가 쉽게 결정하지 못하는 경우도 많다.

이미 경쟁력을 잃은 개발 조직은 더 좋은 제품을 만들어 내지 못하고 계속 비용만 증가시키곤 한다.

이런 회사는 살아남기 위해서는 뼈를 깍는 변화의 고통을 이겨내야 한다.

하지만 작은 회사 중에서 희망적인 경우는 어떨까?

비록 매출액은 10억 안팎에서 20~30억, 순이익도 몇억 정도. 

작은 회사지만 즐겁게 일하고 독자적고 독보적인 기술력을 가지고 있는 경우가 많다.

이런 경우도 뛰어난 기술력에 비해서 소프트웨어 공학 경험은 부족해서 문제는 있지만 조직이 워낙 작아서 아직 문제가 심각해지지 않은 상태이다.

결정적으로 중요한 것은 경영자가 개발자 출신인 경우가 많고 변화에 관심이 많고 방해 세력도 거의 없다는 것이다. 개발자들도 아직 기득권 세력으로 자리를 잡지 않아서 오픈마인드인 경우가 많다.

이런 회사라면 경영자가 주도하는 변화에 무리없이 직원들이 따라오게 된다.

물론 대기업이라면 경우가 다르기 때문에 예외로 한다. 왜냐하면 대기업은 소프트웨어 개발 능력외에도 다른 경쟁력을 가지고 있기 때문이다. 

또한, 중견 SW회사는 희망이 없다는 것은 아니다. 규모가 큰만큼 변화에 훨씬 많은 노력을 들여야 가능하다는 것이다.

몇년 안에 이런 작은 SW 회사들 중에는 세계적으로 이름을 날릴 회사가 여러개 나올 것이라고 생각한다. 내가 이런 작은 회사에 관심이 많은 이유이다.