2017년 6월 26일 월요일

소프트웨어 회사에서 '공유'가 진짜 어려운 이유

많은 사람들이 소프트웨어 회사에서 가장 중요한 기업 문화 중 하나로 '공유 문화'를 꼽는다. 비단 소프트웨어 회사만의 이슈는 아닐 것이다.
공유에 문화라는 이름이 붙으려면 구성원 대부분이 자연스럽고 일상적으로 정보를 공유해야 한다. 공유가 중요한 이유는 소프트웨어 개발은 집단지성이 작동해야 하는 대규모 지식 산업이기 때문이다. 정보와 지식이 한사람의 머리 속에 머무르지 않고 시스템에 저장되고 효율적으로 관리되어야 비로소 경쟁력을 가질 수 있다.
소수의 슈퍼 개발자가 주도해서 성공한 소프트웨어 회사들이 벽을 못 넘는 이유 중 하나도 '공유문화' 부족이라고 볼 수 있다.
많은 회사들이 “공유문화”를 정착시키기 위해서 당근과 채찍을 동원하지만 제대로 된 '공유문화'를 가지고 있는 회사가 그렇게 많지는 않다. 필자가 경영을 하고 있는 이우소프트도 아직 완벽하지는 않지만 '공유문화' 정착을 위해서 5~6년간 치열한 노력을 해오고 있다.
직원들에게 “공유를 잘하자”라고 말하는 것은 “착하게 살자”라는 정도밖에 들리지 않는다. '공유 문화'가 정착되지 않은 회사에서는 직원들 자율에 맡겨 놔도 '공유 문화'가 정착되기는 어렵고, 프로세스로 강제화해서는 더욱 어렵다.
'공유 문화' 정착이 어려운 이유는 '죄수 딜레마'와 같다. 또한 '교차로 꼬리 물기'와 비슷하다. 교차로에서 신호가 끊겼는데도 바짝 따라붙으면 이로 인해서 다른 방향의 차들은 소통이 안되고 연속으로 차들이 꼬리 물기를 해서 교차로가 꽉 막힌다. 교차로 꼬리 물기를 해결하고 교차로에서 가장 많은 차들이 통과되는 비법은 모든 차들이 꼬리 물기를 하지 않는 것이다.


하지만, 아무리 캠페인을 해도 '교차로 꼬리 물기'가 사라지지 않는 이유는 모두다 규칙을 잘 지키면 서로 혜택을 누릴 수 있지만 누구는 지키고 누구는 지키지 않는 상황에서는 규칙을 지키는 사람이 더 손해를 보기 때문이다. 규칙을 지키지 않아서 이익을 보는 사람은 계속 이익을 보고 규칙을 지켜서 손해를 보는 사람은 계속 손해를 본다면 사람들은 자연스럽게 규칙을 지키지 않는 쪽으로 넘어온다.
게다가 '공유를 하지 않는 행동'은 '교차로 꼬리 물기'처럼 눈에 잘 보이지는 않는다. 제대로 공유를 안해도 공유를 안하고 있다는 사실을 완전히 눈치채기는 쉽지 않다.
또한, 자신이 알고 있는 정보를 모두에게 공유하는 것은 자신이 없어도 회사가 돌아간다는 의미로 해석이 되어 매우 불안한 일이 아닐 수 없다. 그래서 어쩔 수 없이 꼭 공유해야 하는 소량의 정보만 공유를 하고 핵심 지식 정보는 공유를 안하기도 한다.
'공유 문화'에 대해서 서로 얘기를 해도 생각하는 정도가 달라서 잘하고 있는 것인지 개선할 것이 많이 필요한지 판단하기는 매우 어렵다. 그래서 필자가 간단한 평가표를 만들었다. 10점 만점에 8점이상이면 공유 문화가 매우 잘 정착된 회사라고 생각된다. 그 이하라면 심각하게 '공유 문화' 개선에 대해서 생각해봐야겠다. 평가방법은 아래 각 항목당 1점으로 계산하면 된다.



  1. 내가 지금 이 순간 회사에서 없어져도 내가 하던 일은 즉시 누군가가 이어받아서 문제없이 진행된다.
  2. 어제 회사에 있었던 크고 작은 모든 회의의 회의록이 시스템에 등록되어 있고 누구나 열람이 가능하다.
  3. 모든 개발자들(직원)이 서로 다른 나라에서 뿔뿔이 흩어져 있어도 지장없이 일할 수 있다.
  4. 나는 회사 Email 시스템에 저장된 모든 Email이 지금 즉시 사라져도 일하는데 전혀 지장이 없다.
  5. 나는 지금 이 순간 시스템을 열어서 나의 팀, 부서 모든 인원이 하고 있는 일과 그 통계를 1분안에 알 수 있다.
  6. 나는 공유를 위해서 별도로 문서를 작성하지는 않는다. 일을 하다 보면 필요한 문서는 자연스럽게 생성된다.
  7. 나를 비롯한 모든 직원에게 회사의 99% 이상의 정보가 실시간으로 공유된다. 공유가 안되는 정보는 극소수에 불과하다.
  8. 내가 지금 하고 있는 모든 일은 시스템에 등록되어 있고 계획, 진행상황, 결과가 실시간으로 기록된다.
  9. 필요한 정보를 찾기 위해서 이 파일, 저 파일 뒤질 필요 없어 몇개의 검색어로 몇 분 안에 원하는 정보를 찾을 수 있다.
  10. 상급관리자나 경영진에게 보고를 하기 위해서 일을 하는 것과는 별도로 PPT를 이용해서 보고서를 만드는 일은 거의 없다.
필자의 회사도 5~6년 전에는 0점에 가까웠지만 꾸준한 노력 끝에 지금은 8~9점으로 평가할 수 있다. 증상에 따라서 처방이 다르기는 하지만 필자가 경험한 몇가지 공유 문화 개선 방법을 제시하고자 한다.

  • 이슈관리시스템, Wiki 등 공유와 협업을 위한 최소한의 시스템을 구축하고 내제화해야 한다. 수단 없이 문화를 이룩하기는 매우 어렵다.
  • 전화나 구두로 논의하고 지시하는 것은 가급적 삼가해야 한다. 메신저도 마찬가지다. 그런 방식은 공유도 안되고 추적도 안된다. 구두로 지시한 것도 시스템에 등록하고 업무를 진행해야 한다. 예외가 있어서는 안된다.
  • 이메일은 안쓰는 것이 좋다. 과거에는 이메일이 업무 혁신의 선두에 있었다면 이제는 골치 덩어리다. 이메일을 정보 보관 수단으로 사용하기 때문에 문제인 것이다. 이메일을 금지하면 자연스럽게 정보는 공유 시스템에 저장된다. 파격적이지만 이우소프트에서는 직원간 이메일이 금지되어 있다. 이메일은 외부용이다.
  • 회의는 10%로 축소해야 한다. 회의가 많은 것은 공유가 잘 안되고 있다는 증거다. 회의를 통제하면 어쩔 수 없이 시스템을 통해서 의논을 하게 된다. 회의는 꼭 필요할 때만 해야 한다.
  • 보고서는 최소화 해야 한다. 지금의 90%는 폐지한다는 생각을 해보자. 보고서가 많다는 것은 공유가 잘 안되고 있다는 증거다. 경영진도 모든 구성원과 동일한 입장에서 시스템을 통해서 공유를 받고 꼭 필요한 경우에만 보고를 받는 것이 좋다.
  • 수평적 사고가 필요하다. 상하 조직 구조에 따른 정보 쏠림 현상을 방지해야 한다. 경영자라고 정보 특별 대우가 없다. 누구에게나 모든 정보가 공유되어야 하며, 의견도 마음껏 개진할 수 있어야 한다.
  • “공유”를 위해 프로세스를 강제화하기 보다는 인식 전환을 위해서 더 힘써야 한다. 강제적인 추진은 부작용만 부른다. 적절한 강제 조치도 필요하지만 마인드를 바꾸는데 더 힘써야 한다.
  • 정보의 홍수를 경계해야 한다. 정보가 너무 많으면 방관자가 될 수도 있으므로 필수 관련자를 잘 구분하여 필수 인원이 방관자가 되지 않도록 해야 한다. 너무 많은 정보가 쏟아지만 정보는 쓰레기가 된다. 수많은 정보 중에서 자신이 추적, 관여할 정보들을 추리고 체계적으로 볼 수 있는 시스템이 필요하다.
  • 공유를 위해서 정보를 생성하는 것도 중요하지만 내용이 바뀌면 업데이트하고 자연스럽게 흩어진 정보를 모으고 정리하며, 적절히 삭제하는 것도 중요하다. 이런 노력을 들여야 공유의 효율성이 올라가고 잘못된 정보로 인한 문제를 방지한다. 이런 활동을 조직내에 심기 위해서는 끊임없는 코칭이 필요하다.
  • 공유 문화가 어느 정도 수준에 오르면 효율적인 글쓰기가 얼마나 중요한지 알게 될 것이다. 직원들을 뽑을 때 지식이 많은 직원도 좋지만 글도 잘 쓰는 직원을 뽑아야 한다. 개발자도 예외는 아니다. 감동을 주는 글을 적어야 한다는 것이 아니고 자신의 생각을 정확하게 전달할 수 있도록 짧고 명료하게 글을 쓸 수 있는 능력이 필요하다.
이 글을 보면 비법을 공개했다고 회사 관계자들은 걱정할지 모르겠지만 비법은 별것이 없다. 골프를 잘 치는 방법은 책에 모두 나와 있지만 끊임없이 제대로 노력을 해야 골프를 잘 칠 수 있다. 다같이 노력해서 대한민국에 좋은 공유문화를 가진 회사가 많아지면 좋겠다.
문화는 '집단의 습관'이다. 구성원들끼리 더이상 공유하라는 얘기를 안할 때 “문화”가 된 것이다. 한번 자유를 맛 본 사람들은 자유를 박탈당한 환경에서 살기 어렵듯이 진정한 공유 문화를 맛보고 나면 과거로 돌아가는 것은 거의 불가능하다. “공유”가 숨쉬는 것처럼 자연스러워질 때 비로서 글로벌 회사들과 경쟁을 한다고 명함을 내밀 수 있을 것이다.

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

2017년 6월 6일 화요일

이우소프트에 대한 오해와 진실

가끔은 “이우소프트가 개발자에게 그렇게 좋은 회사라면서요?”라는 말을 종종 듣는다. 이 말은 맞기도 하고 틀리기도 하다.

입사지원자에게 듣기도 하고 지인들에게 듣기도 한다. 몇몇 얘기를 듣고 과도하게 확대해석하기도 하고 오해하기도 한다. 모든 현상이 그렇듯이 몇줄의 글을 통해서 상황을 정확히 설명하기란 매우 어렵다. 하지만 내 블로그의 글을 보고 많은 개발자들이 이우소프트에 지원을 하기 때문에 좀더 정확한 설명이 필요하다.

일단 이우소프트는 “개발자가 일하기 좋은 회사”를 만드는 것이 목적인 회사는 아니다.

이우소프트의 비전은 “글로벌 경쟁력을 갖추고 세계 1등의 Software를 만들어 내는 것”이다. 거의 모든 것은 여기에 맞춰져 있다. 이를 위해 행해지는 것들이 개발자에게 좋을 수도 있고 나쁠 수도 있다. 또한 어떤 개발자에게는 좋은 것이 어떤 개발자에게는 나쁜 것이 될 수도 있다. 

퇴근 후 개인 시간이 거의 보장된다.


퇴근 후 개인 시간을 보장해야 하는 이유는 생산선 향상 때문이다. 어차피 하루 8시간 이상은 몰입이 어렵다. 또한 퇴근 후에 영어, 운동, 신기술습득, 문화활동 등 장기적으로 성장하기 위한 활동을 해야한다. 그리고 야근이 없다는 오해도 있는데 야근은 있다. 최대한 합리적으로 프로젝트를 진행하려고 하지만 야근에 내몰리는 경우도 종종 있다. 또한 자발적으로 야근을 하는 개발자도 있다.


개발일정은 개발자가 정한다.


기본적으로 맞다. 하지만 여유로운 개발일정을 정하는 것은 절대 아니다. 프로젝트마다 일정의 중요도가 다르기 때문에 프로젝트마다 다른 기준에 따라서 일정이 정해진다. 개발자가 산정한 일정을 가장 우선시하지만 가끔은 고정된 일정에 개발자가 맞춰야 할 때도 있다. 이때는 합리적으로 조정하려고 노력한다. 부족한 일정만큼 개발자를 더 투입하거나, 외주를 투입하거나, 기능을 축소하거나, 단계별로 기능을 제공하거나, QA를 더 투입하거나, 상용 라이브러리를 구매하는등 여러 수단을 동원한다. 스펙을 철저히 쓰고 그렇게 합리적으로 진행하더라도 예상치 못한 Task가 추가로 생기는 등의 변수로 인해서 어려움에 봉착하기도 한다. 이를 해결하기 위해서 PM(Project Manager)과 TL(Technical Leader)은 머리를 맞대고 해결책을 고민한다. 최대한 합리적으로 계획을 세우고 해결책을 수립해도 프로젝트에는 어려움이 닥친다.  PM과 TL은 노하우를 쌓아서 이런 상황을 최소화 해나가고 있다.

개발자 캐리어는 확실히 보장한다.


개발자는 확실히 개발만 하게 한다. 그래야 효율성이 높기 때문이다. 전문 PM이 별도로 있어서 관리는 PM이 전담한다. PM 또한 대단한 전문성을 요구한다. 개발자에게는 개발만 요구하기 때문에 개발자로서 확실한 실력을 보여줘야 한다. 끊임없이 공부하고 노력해서 연차에 걸맞는 실력을 보여줘야 한다. 그렇지 않으면 신입 개발자들에게 밀리는 일이 발생한다. 사람들과의 관계와 공력으로 버티는 개발자들은 살아남기 힘든 환경이다. 야근이 별로 없다고 하더라도 퇴근 후에 해야 할 공부가 많다. 개발자는 평생 공부해야 한다고 하지만 성향에 따라서는 쉬운 일이 아니다. 나조차도 종종 고3때보다 공부를 더 하는 것 아닌가 생각할 때가 있다.

모든 것을 공유해야 한다.


공유하지 않는 것은 거의 없다고 보면 된다. 오늘 내가 한 모든 것이 온라인 시스템을 통해서 공개되고 공유된다고 보면 된다. 서로 만나서 말로 논의하고 끝나는 경우가 없다. 10분짜리 회의라도 Wiki 시스템에 기록이 남고 ITS(Issue tracker system)을 통해서 모든 이슈(버그, 개선, 신기능, Task 등)는 시스템에 기록되고 온라인으로 논의한다. 개발외에도 모든 업무가 온라인을 통해서 진행된다. 모든 직원이 당장 떨어져서 일해도 전혀 어려움이 없는 상황이다. 글로 적는 습관과 실력이 없는 사람들은 보통 곤역스러운 일이 아니다.

이것은 회사에게는 큰 장점이다. 직원이 하나 갑자기 빠져나가도 회사는 문제 없이 돌아간다. 하지만 개발자에게는 좋기도 하고 나쁘기도 하다. 열심히 일한 개발자는 자신이 과거해 해놓은 일에 발목을 잡혀서 새로운 일을 못하지 않는다. 언제든지 다른 사람들에게 유지보수를 맡기도 새로운 일을 할 수 있다. 하지만 의도치 않게 자신의 지식과 정보를 숨겨서 이를 자신의 존재가치로 삼는 개발자에게는 아주 안좋은 환경이다. 이런 회사는 개발자가 중요한 자산이기도 하지만 Risk가 되기도 한다.

자연스럽게 모든 정보를 시스템에 남기는 형태로 일하는 것은 습관이 되기 전에는 매우 곤역스러운 일이다. 따라서 모든 개발자에게 꼭 좋은 환경이라고 볼 수는 없다.

개발을 위한 신입사원 교육이 없다.


신입사원 교육이 있기는 하지만 회사의 일반에 관련된 내용이고 개발을 하기 위한 신입사원 교육이 없다. 이는 좋기도 하고 나쁘기도 하다. 신입사원은 입사하자마자 이슈(버그, 신기능, 개선 등)를 할당 받기 때문에 알아서 개발을 해야 한다. 단, 시스템에 거의 모든 정보가 있기 때문에 정보를 찾아가면서 개발을 해야 하고 멘토나 팀장이 가끔 가이드를 해준다. 하지만 옆에 끼고 가르치는 것은 없다. 고참들은 신입사원이 많이 들어와도 이들을 가르치기 위해서 시간을 빼앗기지 않는다. 신입들은 아무도 가르쳐주는 사람이 없어서 막막하겠지만 시스템을 검색해보면 필요한 정보가 거의 다 있기 때문에 본인의 능력여하에 따라서 훨씬 빨리 배울 수 있다. 또한 자연스럽게 본인들도 공유하는 습관을 가지게 된다.

이렇게 어떤 개발자에게는 좋은 환경이기도 하고 어떤 개발자에게는 매우 나쁜 환경이 되기도 한다. 하지만 이런 과정을 통해서 모든 프로젝트는 일정을 지키며 개발자들의 생산성은 매우 높다. 개발자는 글로벌 회사의 개발자들과 다를바 없는 수준으로 꾸준히 회사와 같이 성장할 수 있도록 노력하고 있다.


막연히 좋은 점만 상상을 했다면 이우소프트는 그런 모습은 아니다. 회사가 글로벌 회사들과 경쟁하는 것이 목표이며 이를 위해 필요한 모습을 갖추고 있을 뿐이다. 성향이나 적성이 일치하다면 좋은 환경이지만 그렇지 않다면 적응하기가 쉽지 않다. 물론 신입개발자들은 대체로 적응을 잘한다. 백지에는 무엇이든지 잘 써지기 때문이다.

2017년 4월 10일 월요일

이우소프트에는 이것이 있다 vs. 없다


개발자 캐리어 보장이 있다.

  • 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
  • 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

  • 남여에 따른 역할,대우의 차이가 전혀 없다.
  • 100% 역량에 따른 차이 밖에 없다.
  • 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

  • SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
  • 무조건 고참이라고 아키텍트가 되는 것은 아니다.
  • 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
  • 아키텍트는 사원부터 수석 연구원까지 있다.
  • 여자 아키텍트도 있다.

관리만 하는 개발팀장이 없다.

  • 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
  • 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

  • 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
  • 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
  • 비전문가가 감놔라 대추놔라 하지 못한다.

영어 이름이 있다.

  • 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
  • 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
  • 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

  • 개발자들은 직급이 아무것도 말해주지 않는다.
  • 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
  • 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

  • 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
  • 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.

운동 시설이 있다.

  • 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
  • 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.


파티션이 없다.

  • 파티션이 전혀 없이 책상들끼리 붙이 있다. 
  • 모든 직원이 한눈에 보인다.

어린이집이 있다.

  • 직원에게는 무료로 제공되는 어린이집이 있다.
  • 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
  • 자녀와 같이 출퇴근을 할 수 있다.



회의록이 있다.

  • 모든 회의가 하나도 빠짐없이 기록이 된다.
  • 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
  • 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
  • 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

  • 회의시간이 1초도 늦는 직원은 없다.
  • 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
  • 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

  • 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
  • 억지를 부리지 않는다.
  • 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

  • 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
  • 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
  • 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
  • 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

  • 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

  • 강요된 야근이 없다.
  • 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
  • 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
  • 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
  • PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

  • 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
  • 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
  • SRS가 완료되면 모든 Stakeholder의 대표들이 서명을 한다.
  • 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
  • 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정이 지연되는 프로젝트가 없다.

  • 지연되는 프로젝트가 하나도 없다.
  • 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
  • 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
  • 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

  • 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

  • 개발자에게 보고서 강요가 없다. 주간보고도 없다.
  • 개발자는 개발만 하면 된다.
  • 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

  • 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
  • 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

서울에도 스마트워크 센터가 있다.

  • 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.


E-mail이 없다.

  • 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
  • E-mail은 주로 외부인과만 주고 받는다.
  • 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

  • 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
  • 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
  • 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

  • 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
  • 더 중요한 것은 스펙, 설계 리뷰다.
  • 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
  • 시니어 개발자는 20% 이상을 리뷰에 할애한다.

마시고 죽자는 회식이 없다.

  • 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.


즉석 라면이 있다.

  • 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
  • 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

꼭 지켜야 하는 문화가 있다.

  • 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
  • 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.




2017년 2월 11일 토요일

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.
그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.
완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.
 
Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?
A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?
A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?
A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?
A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?
A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?
A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?
A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.
A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?
A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.
모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.