태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

개발자간 공유 문화 정착이 힘든 이유

2015.03.28 16:13 by 전규현


잠시 후 Google blogger로 이동됩니다.






소프트웨어를 개발하는데 있어서 가장 중요한 문화 하나는 '공유’ 문화라고 있다. 소프트웨어 개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20, 30 계속 개발자로 일할 있도록 하는 기초 체력이기도 하다

 

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다.  주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다. 특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다. 하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은 들려오지 않는다. 이유는 무엇일까?

 

여러 가지 이유가 있겠지만 번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다

 

죄수 딜레마라고 들어본 적이 있는가

 

상황은 다음과 같다. 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다.

    하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 명이 10년을 복역해야 한다.

    모두 서로를 배신하여 죄를 자백하면 모두 5년을 복역한다.

    모두 죄를 자백하지 않으면 모두 6개월을 복역한다.

 

죄수A 죄수B 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다. 죄수B 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A 죄수B 어떤 선택을 하든지 자백을 선택한다.

죄수B 죄수A 동일한 상황이므로, 마찬가지로 죄수A 어떤 선택을 하든지 자백이 유리하다.

따라서 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

 

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건, 죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

 

도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 빨리 교차로를 빠져나갈 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히 있으면 교차로를 가장 늦게 통과하게 것이다. 심지어는 주변의 차들에게 욕먹을 각오도 해야 한다. 꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 손해를 보게 되어 있다. 그래서 어쩔 없이 다같이 손해를 보는 경우를 선택하게 된다.

 

가족과 함께 괌의 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운 일을 목격했다수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다. 선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다 시간 나타난 선배드의 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선배드를 해놓고 아침식사를 하러 것이었다. 사실 선배드는 모든 사람이 충분히 만큼 많았다. 하지만 이용도 하지 않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀 곳이 없게 것이었다. 한국에서는 이런 현상 이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지, 바뀌었는지 없다. 어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드 개를 놓는 일에 동참하는 우리를 발견하게 되었다.

 

이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는 확신이 없다면 약속은 순식간에 무너진다.

 

그럼, 규칙을 엄하게 적용하면 해결될 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 있지 않을까? 이런 식으로 해결이 있었다면 우리나라의 대부분의 회사가 이미 공유문화가 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

 

첫째 만들어 놓은 규칙이 엄격하기만 공유 문화 정착에 효과적인 경우가 별로 없다. 왜냐면 엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해  적도 없는 사람들이기 때문이다대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이 없다. 게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

 

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다. 문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들  있지만 진짜 필요한 내용이 들어 있는지 확인할 방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜 공유는 피해 다니게 되어 있다.

 

셋째 나만 공유를 제대로 하게 경우 나만 손해를 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린 얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

 

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을 만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을 내는 것도 된다. 현재 상황을 파악해서 공유문화를 만들어 있는 단계적인 접근이 필요하다. 개발자들이 소화할 있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과 일치를 해야 한다. 이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 것이라는 확신을 직원들에게 심어주어야 한다.

 

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다그럼 비효율이 정착된 회사가 것이다.



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

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 공유, 문화

혼자만 알고 있는 개발자들

2015.01.16 22:48 by 전규현


잠시 후 Google blogger로 이동됩니다.






많은 회사 개발자를 만나면서 느끼는 우리나라 소프트웨어 회사들의 가장 큰 문제 중 하나는 개발자간에 정보와 지식의 공유가 잘 안 되는 것이다. 회사가 크던 작던 거의 모든 회사가 동맥경화에 걸린 것처럼 정보와 지식이 공유되고 유통되지 않고 몇 사람만 알고 있다. 회사가 크면 클수록 이런 현상은 더욱 심해진다. 

 
꽤 오래 전 어떤 개발자가 개발을 하면서 특정 라이브러리의 호환성 때문에 한 일주일 고생을 한 적이 있다. 인터넷도 검색하고 여러 시도를 해 보았지만 잘 해결이 안돼 여러 개발자가 고생을 하고 있었다. 수시로 사무실 통로에 서로 모여서 이와 관련된 짧은 토론을 여러차례 하면서 회사 내의 이슈가 되고 있었다. 
 
그렇게 며칠이 지날 때쯤 한 개발자가 말하길 이것은 자신이 수개월전에 이미 시도를 해보고 다 조사를 해본 것이라고 한다. 그리고 이것은 불가능하다는 것의 증거를 가지고 있다고 했다. 진작에 이것 때문에 고생하고 있다는 것을 알았지만 개발자들이 일주일이 지나도 해결을 못하자 자랑스럽게 얘기를 해주는 것이었다. 회사가 크고 서로 사무실이 달랐다면 이 조차도 전달이 안되었을 것이다. 그나마 회사가 작으니까 나중에라도 얘기를 해줄 수 있었다. 
 
이런 얘기를 들을 경우 개발자들은 그 개발자를 어떻게 생각할까? 남들이 모르는 것을 알고 있다고 존경심을 가질까? 아니면 왜 미리 알려주지 않았나 서운해할까? 아니면 이런 정보가 공유가 잘 안 되는 회사의 문화, 프로세스와 시스템을 탓할까? 
 
이런 개발자는 회사의 중요한 사람일까? 없어야 하는 사람일까? 내 생각은 이렇게 중요한 정보를 본인만 알고 있고 고의로 공유를 안하는 개발자는 해고감이다. 개발자는 개발에 관련된 내용을 적절히 충분히 기록하고 공유를 해야 한다. 이것은 말은 쉽지만 매우 어려운 일이다. 개발 과정에서 효율적이고 자연스럽게 정보와 기록을 남기고 공유를 해야 한다. 
 
이런 현상이 비단 개발자 탓만은 아니다. 공유가 잘 안되는 문화를 가진 회사에 입사를 해서 다른 사람과 자연스럽게 동화된 것 뿐이다. 공유를 할 마땅한 방법이 없기도 하고, 혼자서 열심히 공유를 하려고 해도 대부분의 개발자들이 자신의 업무에 바빠서 공유된 정보에는 관심도 없는 경우가 많다. 국내 많은 소프트웨어 회사들이 이와 비슷하다. 공유를 위해서 애쓰지만 대부분 성공적이지 않다. 공유에 실패하는 회사는 다음과 같은 특징이 있다. 
 
첫째, 소수의 인원만 정보 공유에 애쓴다. 경영진을 비롯해서 대부분의 개발자는 공유에 별로 관심이 없다. 공유가 왜 중요한지 인식을 못하기도 한다. 개발자 혼자 공유 문화의 전도사처럼 나서지만 누구 하나 인정해주지도 않고 본인도 금방 지치게 된다. 
 
둘째, 공유를 위한 시스템이 없거나 부족하다. 공유를 한다고 문서를 만들어도 문서가 버전관리도 안되고 여기저기 굴러다니고 정보를 찾기도 어렵다. 좋고 비싼 시스템이 있어도 제대로 사용하지 않는다. 이럴 때 비싼 시스템은 오히려 적절한 공유에 방해가 되기도 한다. 
 
셋째, 개발과는 별도로 문서를 따로 만든다. 문서를 만들어도 많이 만든다. 게다가 문서를 만드는데 엄격한 규칙이 있다. 대부분의 대기업이 여기에 해당한다. 경영진이 공유의 의지를 가지고 밀어붙이는 경우도 대부분 이렇게 된다. 하지만 이렇게 별도로 문서를 많이 만든다고 공유가 잘되는 것은 아니다. 엄격한 프로세스로 비효율적으로 많은 문서를 만들기도 하고 이를 형식적으로 지키기도 하지만 이것으로 공유에 성공했다고 볼 수는 없다. 
 
정작 중요한 정보는 공유가 안된다. 이런 회사의 특징은 대부분의 문서가 서로 정보가 안맞고 계속 업데이트가 안되서 쓸모가 없다. 게다가 쓸모 없는 문서와 쓸모 있는 문서가 섞여 있어서 올바른 정보를 구분하기 어렵다. 
 
넷째, 기존의 지식을 문서로 만들려고 애쓰다가 실패한다. 기존의 지식과 정보를 모두 끄집어내서 문서화 하는 일은 거의 불가능한 일이다. 일할 당시 그때가 아니면 문서화는 어렵다. 하루가 지나면 기억 속의 정보는 50%가 사라지고 일주일이 지나면 90%가 사라진다. 지금이 아니면 나중에는 문서화 할 수 없다. 밀린 일기는 포기하고 오늘 일기부터라도 쓰는 것이 좋다. 
 
다섯째, 항상 너무 바쁘다. 특히 고참일수록 더 바쁘다. 신입사원은 제대로 일하려면 수개월이 걸린다. 그러다 보니 고참이 더 바빠서 공유에는 신경 쓸 시간이 없는 악순환이 계속된다. 
 
반대로 공유에 성공한 회사는 다음과 같은 특징이 있다. 
 
첫째, 경영진을 비롯한 모든 개발자가 공유에 힘쓴다. 공유가 얼마나 중요한지 모두 잘 알고 있고 공유에 문화적으로 시스템적으로 투자를 한다. 
 
둘째, 적절한 시스템이 구축되어 있다. 대부분 이슈관리시스템, Wiki등의 시스템이 잘 구축되어 있고 회사의 거의 모든 정보와 지식이 잘 저장되어 있다. 뿐만 아니라 휘발성 커뮤니케이션 수단인 전화, 메신저, 이메일 등은 보조수단으로 사용되며 중요 정보는 대부분 시스템을 통해서 전달되고 공유된다. 
 
셋째, 문서는 최소로 만든다. 불필요한 문서를 만들지 않고, 꼭 필요한 문서 몇 개만 만든다. 문서의 형식도 꽤 자유롭다. 개발자들이 토론하면서 노트에 그린 그림을 사진을 찍어서 올리기도 하고, 온라인 그리기 도구를 쓰기도 하고 상황에 맞게 자유로운 도구를 활용한다. 
 
넷째, 공유가 습관화 되어있다. 항상 일하는 과정에서 자연스럽게 공유를 한다. 별도로 문서를 만든다고 많은 시간을 소비하지 않는다. 자유롭게 필요한 만큼 알아서 효율적으로 공유를 한다. 항상 노트를 하고 즉각 정리해서 이슈관리시스템이나 Wiki에 등록하는 것이 일상화 되어 있다. 개발자가 수시로 하는 작은 조사, 개발도 모두 문서화되고 공식적으로 진행된다. 
 
다섯째, 리뷰가 활성화 되어 있다. 모든 정보는 문서로 공유하기는 어렵다. 토론도 많이 하고 리뷰도 자주 있다. 리뷰과정을 거쳐서 문서는 꼼꼼히 검토가 되고 여러 직원들의 전문적인 의견이 반영된다. 고참일수록 리뷰에 많이 참석하며 자신의 경험과 지식을 리뷰를 통해서 전수한다. 
 
공유는 소프트웨어에서는 가장 중요한 기업 문화이다. 소프트웨어가 창의적인 지식산업이기 때문에 더욱 그렇다. 하지만 대부분의 회사는 위에서 언급한 공유에 실패하는 증상들이 보이고 있다. 그렇다고 이제부터 공유를 열심히 하자고 마음만 먹는다고 공유가 잘되는 것은 아니다. 복잡한 프로세스를 도입하는 것보다 공유 문화 정착이 열 배는 어려운 일이다. 
 
경영진의 의지가 가장 중요하지만 의지만 가지고 밀어붙이다가는 프로세스만 복잡해지는 함정에 빠지기가 매우 쉽다. 문화란 그만큼 바뀌거나 도입하기 어려운 것이다.


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

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 Wiki, 공유, 문화

  1. Blog Icon
    최정한

    좋은 글이네요.

  2. Blog Icon
    진창훈

    그래서 개발자는 자신의 블로그를 운영해야 합니다. 아무도 보지않을 사내 문서보다는 구글에서 검색되는 블로그를 운영하고, 거기에 상세한 내용을 적어놓으면 언젠가는 쓰이게 될테니까요.

주먹구구식 개발이 통하는 이유

2012.08.27 06:46 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.


여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데


주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.


첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.


둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.


셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.


넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.


다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.


정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.


2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표


그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?


첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.


둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 


셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.


넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.


그럼, 주먹구구식 개발이 앞으로도 계속 통할까?


회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.


개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.


Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.


물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.


image by Tolka Rover


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 공유, 리뷰, 주먹구구, 프로세스

  1. Blog Icon
    RF

    소프트웨어 개발에 관심이 많은 대학생으로써 재밌게 잘 보고 갑니다.
    저런 능력을 키우고 싶은데 ... 더 공부해야겠습니다.

  2. RF님 안녕하세요.

    어치피 학교에서는 기본적인 프로그래밍과 전산 원리 등을 배우죠. 나머지는 대부분은 실제 일하면서 현실에서 배우는 겁니다. 좋은 환경을 가지 회사를 선택하는 것이 매우 중요한 요소라고 생각합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 안녕하세요. 아주 작은 회사를 제외하고는 제대로 된 회사를 찾기는 어렵고 회사마다 다 다릅니다. 콕 찝어서 얘기하기는 어렵습니다.

우리나라 소프트웨어 회사에는 ???이 없다.

2011.07.30 23:59 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라 소프트웨어 회사에는 없는 것이 참 많다.

물론 있는 것도 많다. 머리 좋고 충성심 높은 개발자도 있고, 기반시스템도 갖추고 있는 경우도 종종 있다. 또한 뛰어난 요소기술을 갖추고 있는 경우도 많다.

프로세스와 시스템은 갖추려고 상당히 노력을 하고 있어서 효과를 보는 경우도 간혹 있지만 이 또한 거의 대부분 수박 겉핧기 식에 머무른다. 아주 초보적인 기능만 쓰거나 잘못 사용하는 경우가 많다. 

하지만 대부분의 회사가 거의 갖추고 있지 못한 것들이 있다. 이런 것들을 넘지 못하면 글로벌 소프트웨어 회사로 가는 길은 멀게만 느껴진다.


1. 개발문화가 없다.

소프트웨어 개발을 정해진 프로세스대로 딱딱 진행해서 잘되면 참 좋겠다. 하지만 절대로 그렇게 되지 않는다. 물론 프로세스를 따르지만 프로세스에 모든 것을 다 담을 수는 없다. 모든 절차를 프로세스화 하면 오히려 효율이 떨어진다. 아니 개발을 거의 못할 것이다. 
프로세스는 최소화하고 나머지는 개발 문화로 커버를 하는 것이다. 
개발문화 중에서 가장 중요한 것은 공유와 협업의 문화이다. 물론 많은 개발자들이 공유와 협업을 하고 있다고 생각할지도 모르겠다. 하지만 그 수준에서는 정말 많은 차이가 난다. 
또한 회사내에서 정말 자리잡기 어려운 문화이다. 개발자들 하나하나가 습관을 바꿔야 하는 어려운 난관이 가로막고 있다. 처음에는 강제화를 해야 하는데 무엇을 강제화 해야 하는 지가 문제이다.
공유와 협업 관련된 키워드를 몇가지를 들면 다음과 같은 것들이 있다.

SRS review, SRS sign, Architecture review, Code review, Coding convension, Doxygen, Component, Interface, Wiki, Bug track, Engineering Onepager, Broken tree, Common library

공유와 협업의 문화가 자리를 잡으면 위에 언급한 모든 것들이 확연하게 바뀌게 된다. 하나하나가 엄청난 항목이므로 자세한 설명은 생략한다.


2. 개발자들의 롤모델이 없다.
 
소프트웨어 개발자들은 3,4년만 지나도 위가 잘 안 보인다. 개발자로서 계속 일을 할 수 있을지 확신이 안 선다. 개발을 계속 하고 싶기는 한데 20년이 지나도 개발을 계속 하고 있는 고참을 본 적이 없어서 그 모습이 잘 그려지지 않는다. 사실 아주 드물게 관리직을 포기하고 개발직에 머물고 있는 고참들이 있지만 그 모습이 그렇게 우러러 보이지 않는다.
그래서 개발자 10년에 관리는 전혀 안하고 개발에만 매진하는 개발자를 찾기는 매우 어렵다. 그렇게 관리와 개발 양다리에서 헤매다가 대부분은 관리로 넘어가던가 업계를 떠나게 된다.
하지만 소프트웨어 개발자라는 자리는 코딩만 놓고 보면 5년짜리 개발자나 20년짜리 개발자나 타이핑 속도가 별반 차이가 나지 않는다. 하지만 아키텍처나 회사의 전략을 바라보는 시각은 엄청난 차이가 난다. 하지만 우리나라에서는 그런 개발자를 키워내지 못하기 때문에 롤모델도 없고 개발자는 방황하고 하는 악순환이 계속되고 있다.


3. CTO가 없다. 

소프트웨어 회사의 꽃은 CTO다. 하지만 거의 모은 우리나라 소프트웨어 회사에는 CTO가 없다. 가끔 직함이 CTO인 경우는 있지만 거의 대부분 진짜 CTO는 아니다. 다른 일을 하는데 직함만 CTO인 경우이다.
CTO가 없다면 회사의 중요한 기술적인 결정을 할 수 있는 최고 책임자가 없다는 뜻이다. 따라서 중요한 기술적인 결정이 영업적인 입장에서 결정되는 경우가 많아진다. 고참 개발자들이 가끔 저항을 해보기도 하지만 우리나라에서는 직급에서 눌리는 것을 극복하기는 쉽지 않다.
또한 CTO급이 아니라면 고참 개발자들의 시각도 최고 수준에는 못 미치기 때문에 제대로 결정을 못하고 설득력도 떨어지게 된다. 
소프트웨어 업계에서 20년 이상은 개발자로 꾸준히 제대로 성장해야 CTO급이라고 할 수 있는데 우리나라에는 그런 개발자가 거의 없는 것도 한 이유이다.
당분간은 좋은 CTO를 구하고 싶어도 쉽게 구하지 못할 것이다.


4. 마케팅이 없다.
 
대부분은 치밀한 계획보다는 번뜩이는 아이디어로 시작을 해서 초기에 성공을 거두었기 때문에 마케팅에 대해서는 거의 모르고 오로지 개발자들의 마법에 의존해서 소프트웨어를 개발하곤 한다. 
어느 정도 커지기 시작하면 마케팅에도 관심을 가져야 하는데 대부분의 소프트웨어 회사에는 개발과 영업만 존재하게 된다.
마케팅도 경험을 가진 마케팅 전문가가 부족하기 때문에 왠만한 대기업을 제외하고는 마케터를 구경하기 어렵다. 마케팅에 관심이 있는 회사 주먹구구 방법밖에 모르기 때문에 별효과를 못 보거나 개발자가 알아서 개발해 줄 때보다 못한 경우도 많다.

하나하나가 워낙 갈길이 멀고 무거운 주제들이라서 마음이 무겁지만 천천히 고쳐나가야 할 것들이다.

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
Suzie Katz
저작자 표시 비영리 변경 금지
신고

전규현 개발문화 공유, 문화, 협업

  1. Blog Icon
    정현철

    진짜 좋은 글 인거 같습니다.
    주위에 다른 개발자 분들한테도 알려 봐야겠네요

    경력은 얼마 안됬지만 왠지 개발문화가 없다는것에 진짜 공감이 갑니다. ^^

  2. 정말 슬픈 현실이네요. 이런 것을 공감하는 세대, 나 자신이 결국은 이런 현실을 개선 할 수 있겠지요. 열심히 해야 겠습니다.

  3. 1. 항목에 대해 강한 공감을 표현하고 싶습니다. 최근에 조인한 스타트업에서 공유에 기반한 개발과 더불어 코드 리뷰를 수행하려고 했으나, 수많은 마찰 끝에 각자 개발하는 영역을 나누기로 했습니다. 습관을 바꾼다는 것이 얼마나 힘든 일인지, 무엇보다 본인 스스로 변화하고자 하는 의지가 없이는 불가능하다는 것을 깨달았습니다.

  4. 안녕하세요. gsong님

    현재 결정의 비용은 미래에 10배, 100배로 치르게 되어 있습니다. 습관을 바꾸기 어렵기 때문에 처음에는 강제화가 필요합니다. 하지만 대부분의 경영자들은 개발자들의 그럴듯한 핑계를 꺽기가 어렵습니다.

    조금씩이라도 변화해보는 것이 좋겠습니다.

  5. Blog Icon

    비밀댓글입니다

나쁜 습관

2011.06.19 10:54 by 전규현


잠시 후 Google blogger로 이동됩니다.







소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

 첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

 둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다.
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
en-shahdi
저작자 표시 비영리 변경 금지
신고

전규현 개발문화 공유, 리뷰, 협업

  1. 어떻게 보면 알박기 개발자들이 있어서 이러한 문화가 더 정착이 안되는게 아닐가도 생각을 해봅니다

    이런 문서작업을 해서 명확하게 하면
    자신의 실력이 다 드러나고, 밑천이 바닥난다고 생각을 해서 오히려 안하고 자기만 꼬옥 껴안고 있다 보니
    이런문제가 더 발생하는 걸지두요

  2. 안녕하세요. 구차니님
    알박기 개발자라... 멋진 표현입니다. ^^

내가 소스코드를 몰래 고치는 이유

2011.02.01 11:39 by 전규현


잠시 후 Google blogger로 이동됩니다.






여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.
여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

 내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

 내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

 엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

 너무 바빠서 공유할 시간도 없다. 

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

 공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 
시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.
SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

 결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Susan NYC

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 SRS, 공유, 리뷰

  1. 비슷한 얘기가 생각나네요. 두 청년이 바둑의 명인이 되기위해 산으로 가서 바둑에만 전념한지 10년째, 자신감에 찬 두 청년은 산을 내려와서 다른사람들과의 대전을했는데, 매번 졌다는 얘기에요;;

    여쭙고 싶은게, 포스팅에 대부분 SRS을 강조하셔서 제 나름대로 개발진행하면서 기능과 이렇게 개발한 이유같은걸 문서로 만듭니다. 근데 혼자하다보니 이게 과연 잘 진행되는건지 의심이 가는건 어쩔수없네요.

    SRS 세미나 혹은 교육같은게 있나요? SRS의 개념을 익히고싶습니다.
    새해복 많이받으세요~

  2. 오산돌구님 안녕하세요.

    개발하면서 기능과 그 이유를 적는다고 한 것으로 봐서 문서를 개발하고 나서 적는 다는 의미 같습니다.

    문서는 원래 개발을 하기 위해서 더 빨리 개발하기 위해서 만드는 것입니다. 지금은 문서가 나중에 필요할 것 같아서 만드시는 거죠? 이런 문서는 용도가 많이 떨어집니다.

    SRS세미나나 교육이 있기는 하지만 SRS를 익히려면 직접 SRS를 직접 쓰고 프로젝트를 진행해 보는 것을 몇년 해봐야 합니다. 그러기 위해서 처음에는 좀 배워야 하는 과정이 필요합니다.

    제 책에 보면 SRS를 배우는 방법에 대해서도 소개가 되어 있습니다.

  3. Blog Icon
    bluemonk

    책을 읽어봤는데 그렇게 하면 되겠구나 라고 하는 느낌까지는 들지 않았습니다.

  4. 안녕하세요. bluemonk님

    그것이 책의 한계인 것 같습니다. 비디오 보고 골프를 배울 수 없듯이 직접 해보면서 경험하지 않으면 알 수 없는 것이 소프트웨어 공학입니다.

  5. Blog Icon
    별의파편

    지금은 좀 덜 하지만 저 같은 경우는 몰래 고치는 게 재미있어서 그런 적도 많아요. 새로운 패턴이나 프레임워크 보면 이전 소스를 고쳐보고 싶은...
    좋게 말하면 리팩토링인데 사실 코드 갖고 놀기....회사 자산 갖고....ㅡ.ㅡ;

  6. 안녕하세요. 별의파편님
    작은 회사에서는 흔히 있는 일이죠.
    회사의 소스코드의 아키텍쳐를 바꾸는 일이라면 여러 개발자와 리뷰를 많이 하면서 더 좋은 방법들을 계속 찾는 작업이 필요할 겁니다.
    소스코드가 변경되면 테스트가 많이 필요하고 코딩 작업 외에도 많은 작업이 필요합니다. 따라서 개인이 혼자서 마음대로 변경하는 것은 나중에 문제가 될 수도 있습니다.
    작은 회사 또는 작은 팀이라서 가능한 걸 겁니다.

  7. SRS가 뭔가요?

  8. 안녕하세요. 중원님
    스펙문서를 말합니다. 제 블로그에서 SRS로 검색을 해보시며 많이 나옵니다.

  9. Blog Icon

    비밀댓글입니다

  10. 감사합니다. ^^

  11. Blog Icon
    ymir

    협업에 관련된 포스트를 읽다가 이 포스트로 넘어왔네요.
    소스를 팀의 산출물로 협업을 통해 관리하는 경우에는 생각보다 투명하게 일이 진행됩니다.
    그러나 중소규모의 회사일수록 그런 경우는 많지 않으며..
    오히려 소수의 인원이 거대 모듈들을 작업하는 경우가 많고, 협업을 하는 케이스가 적습니다.
    그러다 보니.. 소스에 대한 관리 책임이 순전히 개인에게 넘어가버립니다.
    이런 경우 버그가 발생하면 결국 개인의 능력과 실력을 의심당하게 되고..
    회사에 피해를 끼치는 식으로 인식되어 버립니다.
    소위 욕먹고 깨지고 페이에도 문제가 생길수 밖에 없는 구조가 되어 버리죠.
    결국은 책임 회피를 위한 나몰라, 거짓말, 몰래 체크인, 다른 이의 계정으로 체크인 등...
    시스템과 프로세스를 무력화 시킬 수 있는 온갖 방법들이 동원되기도 합니다.
    코드를 대하는 마인드가 변하지 않는 한, 소위 이 '나쁜 습관'들은 쉽게 고쳐지지 않을 것 같습니다.

  12. 안녕하세요. ymir님
    다른 사람 계정으로 체크인은 좀 심하네요. ^^

  13. Blog Icon
    ymir

    다행(?)히도 그런 사례는 서너개의 회사를 거치는 동안 딱 한 번 봤습니다. =)

Peer Review의 방해꾼들

2009.04.02 23:10 by 전규현


잠시 후 Google blogger로 이동됩니다.




Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다.
Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다.

Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발자들의 사기를 높여줍니다.

그런데, 결함을 줄이고, 비용과 시간을 절약하며, 지식을 공유하는 것을 싫어하는 개발자들이 의외로 꽤 많습니다. 공유를 통해서 자신만 알고 있는 지식이 빠져나가면 자신의 가치가 줄어들 것으로 생각하며 심각한 버그를 만들어서 자신만이 멋지게 해결하는 모습을 보고 싶어하고, 프로젝트의 일정을 항상 궁지로 몰아 넣고 자신이 이를 해결할 수 있는 유일한 사람인척 행동하는 많은 개발자들이 있습니다. 이러한 행동이 자신의 가치를 높여주고 자리를 보존해 준다고 생각합니다. 하지만 그 말로는 뻔하죠. 본인도 성장하지 못할 뿐더러 동료와 후배의 성장도 방해하고, 결국 실력은 부족한데 영향력만 유지하려고 하는 "정치꾼 개발자"로 전락하고 맙니다. 

회사들은 알고도 또는 모르고 이러한 개발자들에게 인질로 잡혀서 끌려다니곤 합니다.

Peer Review를 시행하면 이러한 개발자들의 방해에 부딪혀서 좌절하기 일쑤이며 이런 개발자들에게 동조한 관리자들도 방해자 노릇을 톡톡히 해냅니다. 프로젝트의 지연을 Peer Review의 탓으로 돌리기 일쑤이며 Peer Review의 성과를 평가절하 합니다. 또 영업부서가 고객이 Peer Review를 반대하기도 합니다.

이러한 방해꾼들을 극복할 의지가 회사에 없다면 Peer Review는 그림의 떡입니다. 즉 회사가 정말로 Peer Review의 필요성을 모르는 상태이거나 아직 이를 시행할 외적인 준비나 성숙도가 떨어진다고 볼 수 있습니다. 준비를 조금 더 해야겠죠? 

그럼 다음에는 Peer Review를 시행하기에 앞서서 준비가 되어야 할 것들에 대해서 알아보겠습니다. 

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 개발문화 Peer Review, 개발자, 공유, 리뷰, 문화, 방해, 성장

  1. Blog Icon
    ~_~

    아무런 문서화도 로직설명도 끝나지 않은채 버그리포트를 시키고 수정하라고 시키는 사람도 있다는거...

  2. 별의별 사람이 다 있죠.

  3. Blog Icon
    아름드리

    제가 있던 회사에도 자신이 만든 프로그램의 소스 코드를 암호화 수준까지 작성해서 아무도 안 보여주는 사람이 있더군요. 이런 사람 얘기는 웹을 통해서 간혹 봤지만 실제로 보니 대책이 안 서더군요.

  4. 아름드리님 반갑습니다.
    이런 개발자들을 어떻게 해야 하는지는 제 블로그의 여러 글들에서 언급을 해 놨습니다. ^^

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..