개발자는 회사의 부품일까 두뇌일까?

정말 오랫만에 글을 쓴다. 워낙 바빠서 시간을 내기 어렵다는 핑계를 대지만 블로그에 올릴 글이 50개 이상은 준비중이고 한두시간만 시간을 내서 정리해 올리면 되는데 바쁠때는 그것도 잘 안된다. 다시 마음을 잡고 글을 올린다.

여러 회사를 컨설팅하면서 각 회사에서의 개발자들의 가치를 비교해보게 된다.

흔히 프로세스가 아주 잘되어 있어서 개발자들가 퇴사해도 문제가 없는 회사에서는 개발자가 부품 취급 받을 것 같다.

반대로 몇몇 슈퍼 개발자들이 슈퍼 파워를 내서 단시간에 놀랄만한 성과를 내는 회사들에서 개발자들의 가치가 더 높아질 것으로 생각하는 경우가 많다.

하지만 그 반대인 경우가 더 많다.

개발자들에게 선택이 가능하다면 두가지 경우 중에서 어느 경우를 선택하겠냐고 물어보면 대부분 두번째 슈퍼 개발자를 선택할 것이다. 두번째 경우가 회사에서 없어서는 안될 중요한 인물이 되고 연봉도 더 높을 것으로 생각된다.

하지만 회사입장에서는 다른 선택을 하게 된다. 우리나라의 대부분의 소프트웨어 회사들은 두번째 경우이지만두번째 상황을 벗어나려고 발버둥치고 있다.

사실 슈퍼 개발자들이 단시간에 놀랄만한 성과를 내는 것은 별로 놀랄 일도 아니다. 주변에서 워낙 흔히 벌어지고 단지 단기간에 낸 성과의 댓가는 미래에 톡톡히 치르기 때문이다.(물론 이런 빠른 전술이 필요한 경우도 많고 이를 적절히 사용해야 한다.) 이런 환경에서 개발자는 더 가치가 있을 것 같지만 시간이 흐를수록 점점 그 가치는 떨어져 간다. 과거에 만들어 놓은 제품을 다른 사람이 유지보수 하기 어려워서 유지보수에만 매달리다가 점점 유지보수가 어려워지면 회사를 떠나곤 하고 남아있는 개발자들이 고생을 해야 한다. 이 과정에서 회사는 프로세스의 중요성에 눈을 뜨고, 남아 있는 개발자들은 피해의식만 커져간다.

반대로 처음부터 적절한 프로세스를 갖추고 개발하는 회사는 당장은 조금 느려보이지만 문서를 만들고 서로 리뷰도 여러사람과 공유를 하며 프로세스를 따라서 개발을 한다. 여러사람과 공유를 하기 때문에 유지보수도 문제가 없고 이전 프로젝트의 족쇄 없이 새로운 프로젝트를 시작할 수도 있다. 또한 퇴사를 해도 회사에 큰 타격을 주지 않는다. 이런 회사에서는 개발자들이 특히 고참개발자들이 유지보수 등 잡일에 목메이지 않고 그런 일은 신참 개발자들에게 맡기고 회사의 두뇌다운 전략이나 로드맵, 아키텍쳐를 고민할 수 있게 해준다. 회사와 개발자간에 상호간에 Risk가 적으며 서로 발목을 잡지 않는다.

이런 환경에서 성장한 개발자는 더 가치 있는 일의 경험이 쌓여서 이직시에도 더 높은 연봉을 받을 수 있다. 하지만 그렇지 못한 회사에서는 10년을 넘게 일을 해도 느는 것은 공력과 해당 Domain 지식밖에 없게 된다. 이런 회사에서는 회사와 개발자가 서로의 발목을 잡고 성장을 못하게 된다. 이직시에도 경쟁회사처럼 비슷한 일을 하는 회사로밖에 옮기지 못하고 이직후에도 비숫한 문제들을 또 일으키게 된다.

현재 자신의 회사가 어디에 해당하는지 아는 방법이 있다.

회사의 개발 일들이 특정인이 아니면 못하는 구조로 되어 있으면 문제가 있는 경우이다.
또한 특정인이 퇴사하면 과거에 해 놓은 프로젝트가 엉망이라면 고민을 해야 한다.
하지만 특정인이 퇴사하면 미래에 할 프로젝트에 피해가 간다면 개발자들이 진정한 회사의 두뇌로 생각되는 경우일 것이다. 물론 칼로 무를 자르듯이 경계가 명확한 것은 아니다.

개발자가 회사의 부품이 아니고 두뇌가 되는 길은 2,3명 회사이던 1000명 회사이던 적절한 프로세스를 통해서 개발자가 두뇌의 역할을 해줄 수 있는 환경을 조성하는 것이다. 여기서 "적절한" 것이 가장 어렵기는 하지만 그 필요성을 공감하는 것이 첫걸음이다.

획일화된 프로세스의 함정

SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.

대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.

이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.

프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.

가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.

하지만 대부분이 회사는 이러한 기회를 놓치게 된다.
그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.

가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

여기에 현혹되지 않는 가장 좋은 방법은 능력 있는 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 회사들 중에는 세계적으로 이름을 날릴 회사가 여러개 나올 것이라고 생각한다. 내가 이런 작은 회사에 관심이 많은 이유이다.

소스코드 Conflict

소스코드 Conflict는 두 명의 개발자가 같은 소스코드를 동시에 다르게 수정한 경우를 말한다.

소스코드관리시스템에서는 이런 소스코드 Conflict가 일어났을 경우 대부분 효과적으로 Merge를 해준다.

하지만 개발자들이 같은 줄을 서로 다르게 수정했을 경우에는 자동으로 Merge가 안된다. 이런 경우에는 사용자가 직접 Merge를 해야 하고 이때 이용하는 것이 Merge Tool이다.

많은 회사들이 Merge에 대한 두려움 때문에 소스코드 Conflict가 나지 않도록 각 소스코드 파일의 담당자를 정해서 담당자만 해당 소스코드를 수정할 수 있도록 하고 있다. 이런 방법은 소스코드관리시스템를 잘못 사용하고 있는 예가 되겠다. 이런 방식의 개발은 개발 시간이 더 오래 걸리고 서로 공유가 안되는 등의 여러가지 문제를 일으킨다.

Merge Tool은 크게 2-way와 3-way방식으로 구분이 되며 3-way Merge는 블로그에 많은 글들이 있으니 참조할 수 있다.

2008/11/21 - [기반시스템/소스코드관리] - Diff and Merge in SCM(Software Configuration Management)
2009/02/25 - [기반시스템/소스코드관리] - Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

3-way Merge 툴을 이용하면 쉽게 Merge를 할 수 있지만 애초에 Conflict가 발생하지 않게 소스코드를 작성하는 것이 더 좋다.

같은 내용을 코딩하더라도 코딩하는 방법에 따라서 Conflict가 일어나게 또는 일어나지 않게 소스코드를 작성할 수 있다.

근본적으로는 설계를 잘 해서 컴포넌트가 잘 나뉘어지고 인터페이스가 초기에 확정이 되어서 잘 유지되면 Conflict를 줄일 수 있다.

변수 선언이나 여러 구문에서 한 라인에 너무 많은 코드를 적지 않아야 한다. 줄을 효과적으로 잘 나누는 것이 좋다. 또한 코드를 추가할 때 기존의 Line에 끼어 넣기 보다는 새로운 라인을 추가하는 것이 좋다.

소스코드를 수정하고 있을 때 다른 사람도 같이 고치고 있다는 생각을 항상 하고 있는 것이 좋다.

그리고 소스코드를 괜히 줄을 맞추지 말고, 이유 없이 라인을 이동하지 않아야 한다.

현재 혼자서 개발하고 있는 것이 아닌데 Conflict에 대해서 전혀 걱정을 하고 있지 않다면 오히려 문제가 될 수 있는 상황이다. (사실은 혼자 개발을 해서 Conflict가 일어나고 여러명이 동시에 병행 개발할 때와 똑같다. 왜 그런지 이해하시는 분은 댓글을 달아주면 어떨까요? ^^ )

Conflict는 항상 일어날 수 있다고 생각하고 가능하면 줄이는 노력을 해야 하고 Conflict가 발생했을 때 Merge를 능숙하게 할 수 있어야 한다.