태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

외국 개발자들이 보기에 군대 같은 한국 회사

2014.11.29 23:48 by 전규현


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






A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.”

B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.

C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할 수도 없다.

 

얼마 전 모 신문 기사에 나온 외국인들이 한국의 기업들에 대해 느낀 점을 얘기한 것이다.

 

국내에서 소프트웨어 개발에 한계를 느낀 대기업들은 해외에 여러 형태의 소프트웨어 조직을 설립하고 현지의 외국인 개발자를 채용하고 있다. 국내 개발자들의 소프트웨어 개발 실력이 떨어져서 소프트웨어를 제대로 개발하지 못했다고 착각하고 있는 것이 아닌가 생각된다.

 

그런데 우리나라 회사들의 조직 문화와 분위기는 외국에도 이미 소문이 많이 났다. 우리나라 기업문화 자체가 나쁘다고 볼 수는 없으나 소프트웨어 개발자들이 선호하는 문화는 아니다. 소프트웨어 전문가라고 하더라도 이런 조직 문화와 개발 환경에서 소프트웨어를 제대로 개발하기는 어렵다. 그래서 우리나라 회사에서 설립한 외국의 현지 소프트웨어 개발 센터에 들어가기를 꺼려하는 현상이 일어나는 것이다.

 

이렇게 소프트웨어 개발에 불리한 기업문화를 가지게 된 이유는 여러 가지가 있지만 중요한 이유 중 하나가 우리나라 회사의 경영진들은 소프트웨어 대한 개념이 없기 때문이다. 여기에 상명하복의 까라면 깐다는 조직 문화가 더해져서 소프트웨어 산업을 망치는 주범의 역할을 하고 있다.

 

A사의 사례다. 회사의 사활이 걸리는 매우 중요한 프로젝트가 있었다. 개발자들이 대충 예상을 해도 1년반 이상 걸리는 프로젝트였다. 하지만 소프트웨어에 대한 개념이 없는 경영진들은 자신의 재임기간에 성과를 내기 위해서 6개월안에 완성하라고 했다. 기업의 분위기가 까라면 까야 하기 때문에 아키텍처가 완전히 망가지는 것을 감수하고 6개월 안에 완수를 했다. 하지만 그로 인한 피해는 심각했다. 제대로 아키텍처를 완전히 수정해서 개발을 했으면 기간과 비용이 2배 이상 들었지만, 급하게 6개월 안에 완성함으로써 미래에 드는 비용은 수십 배가 증가 했으며 이로 인해서 회사는 망하는 길로 들어섰다.

 

프로젝트를 완료했을 당시에는 경영진은 1년이 넘게 걸릴 프로젝트를 자신의 리더쉽과 독려로 6개월안에 완성했다는 것을 자랑하지만 이로 인해서 회사가 망하는 길로 들어섰다는 것은 전혀 몰랐다.

 

개발팀의 아키텍처에 대한 의견은 치기 어린 엄살로 간주하고 탱크같이 밀어붙이는 경영진을 능력 있는 경영진으로 간주하는 것이 현실이다. 이런 무모한 독선은 단기적인 효과는 거둘 수 있어도 미래에는 그로 인해 얻은 이익의 몇 배의 비용을 지불하게 되어 있다.

 

B사의 경영진은 개발자들이 6개월째 집에도 못 들어가고 프로젝트를 하고 있는 것을 자랑스럽게 얘기한다. 야근을 하면 야근 한 시간만큼 생산성이 비례해서 늘어난다는 착각에 빠져 있는 경영진은 정말로 많다. 야근 강요는 소프트웨어 개발을 지식 산업이 아닌 육체 노동 산업으로 내모는 결과를 가져온다. 야근은 대출과 같아서 단기적인 효과는 있어도 장기적으로는 생산성이 더 떨어진다. 자발적인 야근은 효과가 크지만 강압적인 야근은 생산성과 창의력을 점점 낮추게 된다. 지금도 암암리에 야근을 많이 해야지만 인정 받는 분위기 때문에 어쩔 수 없이 경영진의 기대에 맞추기 위해서 수많은 개발자들이 야근을 하고 있다.

 

야근은 생산성 저하 외에도 개인 생활과 가족과의 시간을 희생해야 하기 때문에 일을 위해 가족과의 시간을 희생을 감수하는 우리나라 개발자에 비해서 외국인 개발자들에게는 꺼려지는 문화가 아닐 수 없다.

 

국내의 한 회사에서는 간부들에게는 제품의 아키텍처와 디자인에 절대로 간섭하지 못하도록 최고 경영자의 지시가 있었다. 회사 초창기에는 간부들의 통찰력이 어느 정도 통했지만 회사가 커지고 제품이 복잡해지면서 더 이상 간부들의 간섭은 통하지 않고 오히려 망치는 길이라는 것을 경험적으로 깨달은 것이다.

 

우리나라 대기업의 경영진들은 자신들이 척박한 환경에서 그 짧은 시간에 기적적으로 회사를 성장 시켰듯이 소프트웨어 역량도 순식간에 따라 잡을 수 있다고 생각한다. 하지만 이는 대단한 착각이다. 언뜻 보기에는 간단해 보이는 소프트웨어가 인류가 만들어낸 지식 산업 중에서 가장 복잡하고 어렵다는 것이다.

 

그 동안 기존 산업에서 익혀온 성공 방정식을 소프트웨어에도 적용하다 보니 잠깐의 반짝 성공은 있었을지 몰라도 급한 한발 내딪음으로 인해서 두발 더 뒤쳐지게 되었다.

 

외국인 개발자들이 꺼려하는 이러한 환경은 국내 개발자들도 똑같이 꺼려하는 환경이다. 단지 국내에 태어났기 때문에 다른 선택이 어려워 그런 환경이라도 꾹 참고 일을 하고 있는 것이다. 그래서 요즘은 처음부터 외국 기업을 찾는 개발자자도 많다.

 

외국인들을 위해서 외국인에게 인기가 있는 회사를 무조건 만들라는 것은 아니다. 외국인 개발자에게 인기가 없는 회사가 소프트웨어 개발에 불리한 환경이라는 것이다. 외국인 개발자들에게 인기가 있는 회사가 된다면 국내 개발자들도 일하기 좋은 환경이 될 뿐만 아니라 소프트웨어 산업 전체의 경쟁력도 증가할 것이다.


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

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

전규현 개발조직 군대, 조직문화

스타트업을 위한 조직론

2012.10.18 11:07 by 전규현


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





스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.


첫째 기반시스템 활용


소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.


둘째 문서다.


흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.


셋째 역할구분이다.


스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.


지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.


이글은 Tech it에 기고한 글입니다.


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

전규현 개발조직 스타트업, 조직

  1. 저 앞의 서두는 이쪽은 아니지만 지금 눈앞에서 벌어지는 일이기도 해서 남얘기 같지 않군요.
    정규군엔 정규군다운, 게릴라전에는 게릴라 전에 맞는 인적 구성과 자원활용법, 전술 등이 다른데
    몸에 안맞게 옥죄는 느낌이랄까요...

  2. 안녕하세요. 기반시스템의 활용도를 높여서 관리부담을 좀 줄여보세요. ^^

  3. 으아~ 유익하다..ㅠㅠ

소프트웨어 회사에서의 관리란?

2012.08.23 06:29 by 전규현


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





소프트웨어 회사가 경쟁력을 가지려면 전통적인 관리와는 좀 다른 관리 방법이 필요하다.


첫째, 상하관계 탈피이다.


전통적으로 관리자는 윗사람이고 팀원들은 관리자의 지시를 따르고 관리자가 거의 모든 것의 결정권을 가지고 있다. 하지만 소프트웨어 회사에서 관리자는 기술적인 결정을 할 수 없다. 개발자 출신이라고 기술적인 결정도 하려 하는 경우도 있지만, 기술적인 결정은 개발자의 몫이다. 그리고 전사적인 중요한 기술적인 결정은 CTO나 회사의 최고 개발자들이 하는 것이다.


관리자는 위에서 지시하는 사람이 아니고 개발자들이 개발에 매진할 수 있도록 회의, 보고서 작성, 보고, 의견 조정 등 힘든 일을 도와주는 역할을 해야 한다. 물론 경험이 많은 사람들이 잘할 수 있는 일이기 때문에 평균 개발자보다는 나이가 더 많을 수는 있다. 그렇다고 하더라도 상하 관계보다는 개발자를 지원하고 경영자를 보좌하는 역할로서의 관리자가 더 필요하다.


둘째, 투명한 관리이다.


소프트웨어는 인류가 만들어낸 가장 복잡한 지식산업이다. 너무 복잡하고 이슈가 많기 때문에 모든 이슈를 시스템에 저장해서 관리하고 모두 투명하게 오픈하지 않으면 감당하기 어렵다. 버그, 기능, 프로젝트 일정, 개발 현황 등 모든 것은 한눈에 볼 수 있도록 해야 한다. 내용을 채우는 것은 개발자 및 전직원이지만 관리자는 이런 모든 정보가 빠짐없이 시스템화 되어서 제대로 공유가 되는지 확인을 해야 한다. 


경영자도 이런 시스템을 통해서 개발현황을 훤히 볼 수 있어야 하고 관리자는 시스템을 이용하여 보고서를 작성하여 시간을 절약할 수 있다.


셋째, 자율이다.


소프트웨어 개발은 관리자가 하나하나 시켜서 진행하기에는 너무 복잡하다. 그렇게는 일이 진행되지 않는다. 큰 그림에서는 PM이나 관리자가 파악하고 도와주지만 자세한 일은 개발자 스스로가 해야 할 일을 정하고 일정을 조정하고 해나가야 한다. 이렇게 일을 진행하더라도 혼자서 알아서 진행하는 것이 아니고 모두 이슈관리시스템에 기록을 하고 진행해야 한다.


개발자들이 윗사람이 일을 시키기만 기다리고 있다면 개발 프로젝트는 효율적으로 진행되지 않는다. 이슈관리시스템은 이런 자율적인 개발진행에 큰 도움을 준다. 일단 이슈가 등록되면 전사 이슈가 되어서 수많은 사람들의 의견을 더해서 이슈의 우선순위가 정해지고 진행 상황을 훤히 파악할 수 있다.



물론 전통적인 관리자의 모습에서 하루아침에 바뀌기는 어렵다. 하지만 소프트웨어 개발문화와 충돌이 있는 부분은 엄연히 존재하며 조금씩 바꿔나가야 할 부분이 있다. 큰형님처럼 보살펴주고 모든 것을 무한 책임지며 진행하고 도전적인 일정을 달성하기 위해서 무조건 쪼는 모습에서 조금씩 바꿔보자.





image by HikingArtist.comPP Martin


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

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

전규현 개발조직 관리

일을 잘하는 조직 vs. 못하는 조직

2012.08.13 05:53 by 전규현


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




 일 잘하는 조직

 일을 잘 못하는 조직

겉에서 보기에 여유있게 일한다.

항상 부산하고 바쁘다. 

위임이 잘 되어 있어서 알아서 처리하는 업무가 많다.

사소한 이슈도 모두 보고하고 처리를 해야 한다.

효과적인 업무 프로세스가 있다.

프로세스가 없거나 비효율적이다. 

꼭 필요한 이슈만 모여서 회의를 한다.

모든 결정을 회의를 통해서 결정해야 한다.

회의 시간이 짧고 회의도 적다.

회의가 너무 많아서 일할 시간이 없다. 

회의 Agenda에 집중하여 효율적으로 결정한다.

회의 시간은 길지만 결론이 없다.

회의 후 항상 회의록을 기록하고 후속처리가 잘된다.

회의 후에도 후속처리에 대한 관리가 잘 안된다.

커뮤니케이션 시스템이 잘 구축되어 있다.

구두와 메일에 의존한 커뮤니케이션으로 관리가 안된다.

시스템을 통해서 누가 무슨 일을 하는지 다 알 수 있다. 

누가 무슨 일을 하는지 파악이 잘 안된다. 

필요한 정보에 신속하게 접근할 수 있다. 

어디에 무슨 정보가 있는지 파악이 잘 안된다. 

업무가 효율적으로 분배되어 있다. 

바쁜 사람만 바쁘고 노는 사람은 논다. 

꼭 필요한 문서를 효율적으로 만들어서 공유한다. 

문서가 없는 경우 많고, 있어도 잘 안본다. 

일 잘하는 조직의 특징을 요약하면, 합리적이고 명시적인 프로세스가 있고 적절한 시스템을 도입하고 있으며 회의를 효과적으로 진행하고 적절한 문서를 통해서 업무를 진행한다. 이렇듯 효과적으로 일하는 조직은 의욕만으로 되는 것은 아니고 회사에서 제공해야 할 것이 상당히 많다. 즉, 투자가 필요하다.


image by id-iom



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

전규현 개발조직

허울뿐인 소프트웨어 개발자 경력 보장

2012.07.30 06:19 by 전규현


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






과거 필자가 근무했던 회사에서는 “백발을 휘날리며 개발을 할 수 있는 개발자”를 공개 채용한 적이 있다. 그 당시 수많은 경력직 개발자들이 지원을 했고 개발자로서 경력을 보장받고자 하는 열망을 충분히 알 수 있었다. 필자의 회사는 Technical career path를 확실하게 보장을 하고 있었다. 따라서 관리를 하지 않고 개발자로서 꾸준히 성장할 수 있고 그렇게 성장할 수 있도록 기업 문화와 제도가 뒷받침이 되어 있었다. 또한 대우도 관리자에 절대 뒤지지 않았다.


하지만 필자가 컨설팅을 시작한 이후 접한 수많은 회사들 중에서 제대로 개발자 경력을 보장해주는 곳은 없었다. 가장 큰 이유는 경영자의 이해 부족을 꼽을 수 있다. 개발자 경력 보장에 대한 각 기업들의 현황을 먼저 살펴보면 해결책도 보일 것이다.


우선 대기업 쪽을 살펴보자.


성공한 국내 유수의 대기업들은 HR에 대해서 많은 투자가 이루어지고 있다. 따라서 Career path에 대한 명확한 정책이 존재한다. 하지만 그 속을 들여다보면 문제가 매우 많다.


문제 사례 중 가장 흔한 것이 가장 뛰어난 고참 개발자가 관리자가 될 수 밖에 없는 상황이다. 그냥 오래 개발하다 보면 팀장, 부서장, 본부장이 되어서 조직을 관리하게 되는 것이다.


몇몇 기업은 개발자들이 관리에서 벗어나 꾸준히 개발자로 일할 수 있도록 하고 있지만, 이 또한 문제가 많다. 우선 회사에서 그렇게 개발자로서 성장하여 최고 개발자 위치까지 이른 사례를 찾아보기 어렵기 때문에 개발자들이 따를 Role model이 없다. 따라서 개발자들 스스로도 성장 단계별로 어떤 일을 해야 하는지 알지 못하고 우왕좌왕 하게 된다.


대기업 A사는 개발자의 직군에 Architect라는 직군을 만들고 이를 10여개로 세분화하고 각 직군마다의 R&R을 정하고 있다. Data Architect, System Architect, Application Architect 등 여러가지가 있다. 하지만 R&R이 소프트웨어 개발 현실과는 거리가 멀고 Role도 명확하지 않다. 결국 타이틀에 불과하고 일하는 방식은 주먹구구 방식과 큰 차이가 없다.


소프트웨어를 잘 모르는 HR 전문가나 관리자들이 만든 개발자 Career path는 현실성이 떨어져서 실제 적용이 잘 안된다.


개발자로 꾸준히 일을 하려고 해도 조직의 문화상 너무 많은 보고서 작성, 보고, 회의를 해야 하는 경우도 많다. 개발 일은 장시간 집중을 해서 성과를 낼 수 있는 일이라서 중간에 다른 일이 자주 끼어들면 제대로 일하기 어렵다. 보고를 이렇게 많이 해야 하고 보고서를 만드는데 오랜 시간을 투자해야 하는 이유는 기업의 기반시스템이 부족하여 경영자가 수시로 보고를 받아야 현황을 파악할 수 있기 때문이다.


또한 보고서의 내용보다 형식에 민감한 경영자가 많고 편하게 앉아서 자신이 필요할 때마다 아랫사람이 자세히 보고를 해주기를 원하는 경영자가 많다. 따라서 개발자라고 하더라도 이런 잡무가 많아질 수 밖에 없다.


이런 귀찮은 일들을 대신해줄 중간 관리자를 채용해도 전문성이 부족한 관리자들은 결국 일들을 개발자에게 토스하는데 그친다. 또한 중간 관리자가 일을 더 많이 만들어서 시키기 때문에 더 귀찮게 하는 경우도 있다.


대기업 개발자들과 인터뷰를 해보면 개발을 좋아해서 개발을 꾸준히 하고 싶은 개발자들도 개발 환경의 열악함, 개발자의 낮은 대우 등으로 인해서 현실적으로 관리자의 경력을 택하고 있었다.


중소기업도 크게 다르지는 않다. 개발을 아주 잘 이해하고 있는 경영자가 있는 회사가 아니라면 중소기업도 개발자 경력이 잘 보장 되지 않는다. 중소기업은 인력이 부족하다 보니 직종을 상세히 구분하지 못하고 개발자에게 팀장 또는 PM(Project Manager)일을 맡기게 된다. 그러다 보면 자연스럽게 개발과 관리의 경계가 무너지게 된다.


많은 회사들이 개발자 경력을 보장해야 한다는 사실 자체는 인지를 하고 있는 것 같다. 하지만 이를 문자 그대로 받아 들일 뿐, 진정으로 깨닫고 있지는 않은 것 같다. 현재의 기업문화와 개발 환경을 그대로 두고 개발자 경력 보장이 되기는 어렵다.


개발에 꼭 필요한 기반시스템들이 잘 구축되어서 제대로 쓰여야 한다. 그래서 투명한 개발 환경이 되어야 불필요한 보고와 회의가 대폭 줄어들게 된다. 경영자들도 매번 보고를 받지 말고 대부분의 정보는 시스템을 통해서 확인 할 수 있어야 한다. 기업 문화도 전문성을 존중하는 방향으로 바뀌어야 한다. 또한 관리자는 윗사람이라 상명하복 관계라는 생각도 바뀌어야 한다. 관리면 관리, 개발이면 개발 각각 전문성 있는 일을 하는 것일 뿐이다.


물론 개발자도 바뀌어야 하지만 경영자와 기업이 먼저 바뀌어야 할 것이다. 그래야 개발자 경력 보장이 제대로 정착이 될 수 있을 것이다.


이글은 Tech it!에 기고한 글입니다.


Image by Zanthia

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

전규현 개발조직

  1. Blog Icon

    비밀댓글입니다

  2. 분석과 설계 문서는 항상 적절하게 해야 합니다.

    적절한 정도가 1page가 될 수도 있고 1,000page가 될 수도 있습니다. 이는 프로젝트마다 다릅니다.

    혼자 개발하더라도 문서는 작성해야 합니다. 제품의 규모와 성격에 따라서 기억으로만 모든 것을 처리할 수 없는 경우가 대부분입니다. 1주일만 지나면 상당 부분 잊어버리는 것이 보통입니다. ^^

    또 나중에 다른 사람들과 협업이 필요 할 수도 있습니다.

    우선은 혼자 개발한다면 본인 스스로 설계를 할 수 있을 만큼 스펙을 작성하고 코딩을 할 수 있을 만큼 설계를 하는 것이 좋습니다. 그렇지 않으면 여럿이 개발하면서 발생하는 재작업 등의 부작용이 똑같이 발생합니다.

    문제는 문서를 제대로 적는 것이 어렵다는 것입니다. 이것은 선배들에게 배우던지, 전문가에게 배우던지, 오랜 시간에 걸쳐서 시행착오를 거쳐서 배우는 방법 밖에는 없습니다.

    제가 검토한 대기업부터 중소기업까지의 수많은 개발자가 작성한 스펙, 설계문서는 95% 이상이 100점만점에 30점 이하입니다. 문서를 강제로 쓰라고 해도 작성 능력이 부족한 상황에서 문서 작성에 대한 회의가 드는 것은 당연합니다.

    여기 질문이 있습니다.
    "문서를 작성하면 개발이 더 빨리 끝납니까?"
    여기에 자신있게 "예"라고 대답하지 못하면 문서 작성 방법이나 역량 등 뭔가 잘못된 겁니다.

    이 질문에 "예"를 할 수 있는 방법을 찾아야 합니다.

  3. Blog Icon
    정동진

    너무나 공감이 가는 글입니다.
    저두 몇년을 문서는 귀찮은 작업으로 여겼다가...
    이제서야 꼭 필요한 작업이라고 느끼고 있습니다.
    진작에 깨닫고 '꼼꼼하게 작성을 했어야 하는데' 하는..
    후회가 밀려오고 있습니다.

  4. Blog Icon
    덕일

    기업문화가 얼마나 중요한지 다시금 깨닫게 하는 글이네요

  5. 덕일님 감사합니다.

전문가 vs. 책임자

2012.03.22 04:06 by 전규현


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






우리나라 조직문화는 전문가보다 책임자를 선호한다.


조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다.

경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하기 쉽다. 


전문가를 우대하는 조직에서 조직의 장은 전문가들이 일을 잘 할 수 있도록 도와주는 관계이다. 전문가가 시간이 흐르고 승진을 한다고 해서 관리자가 되지 않는다. 


최고 경영층도 사장, 전무, 상무 등의 체제에서, CEO, CTO, CFO, CIO, COO 등의 전문가 체제가 일반화되었다. 일단 용어는 다 익숙한 것으로 보아서 많은 회사에서 전문가 시스템을 시도는 하고 있는 것이다. 물론 형식적으로 그렇게 이름만 따서 하는 경우가 허다하기는 하다.


공무원들도 외국에서는 한 분야에서 몇십년을 일해서 공무원들도 전문가가 되는데 우리나라는 고인물은 썩는다고 하여 비리를 줄이려고 공무원을 몇년마다 뺑뺑이를 돌린다. 몇년에 한번씩 지역과 보직을 바꾼다. 그래서 비리는 좀 줄었을지 모르지만 전문가를 양성하기는 어려운 상황이다.


Software 분야도 마찬가지이다.

개발을 잘하는 개발전문가들이 주도하여 일하는 것이 아니고 조직의 장이 책임을 지고 일하는 방식 위주이다. 여기서 전문성을 별로 존중되지 않는다.

그래서 개발자들은 개발을 적당히 하다가 관리자가 되기도 하고 다른 분야로 마음대로 왔다 갔다. 한다.

이러는 과정에서 가장 큰 손실을 입는 분야가 개발 분야이다. 그래서 우리나라에서는 Guru 급의 개발자들이 매우 부족하다. 모기업에서는 S급의 개발자에게는 사장보다 연봉을 많이 주겠다고는 하지만 찾기도 어렵다. 최고의 Software 전문가가 박사학위를 받은 개발자는 아니다.


Software 프로젝트도 여러 전문가들 이끌어간다. 마케터, 프로젝트매니저, 분석가, 아키텍트, UI전문가, QA전문가, Tech pub. 등등 다양하다. 

이들도 전문가로 성장하려면 분야에 따라서 5년, 10년, 20년 경험이 필요하다. 이들이 전문가로 꾸준히 성장할 수 있는 환경이 별로 없는 것이 문제다.  그렇게 진로를 보장해 주는 회사도 적을 뿐더러 관리자보다 연봉도 적고 조직내에서 영향력도 적기 때문이다. 


경쟁이 그렇게 치열하지 않는 동네 축구 리그에서 전문가가 별로 없어도 그럭저럭 살아남을 수 있다.

즉, 국내 시장에서는 그럭저럭 먹고 살 수 있다는 의미이다. 하지만 Global 시장에서 경쟁하려면 실력 차이가 너무 크게 나타난다.

개발자들이 개발에 매진할 수 있고 Software 전문가로 성장할 수 있는 환경이 꼭 필요하다. 닭이 먼저냐 달걀이 먼저냐 고민스러운 부분이다. 그래도 우선 개발자들이 꾸준히 개발자로 성장할 수 있는 제도와 사회적인 분위기를 만드는 것이 중요하다.

 

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

전규현 개발조직

  1. Blog Icon

    비밀댓글입니다

관리자가 이런 일까지?

2012.02.13 03:43 by 전규현


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





우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다.

물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다.

개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와는 약간 다른 얘기다. 이런 개발 팀장은 SW 개발자에 더 가깝고 관리업무는 부수적인 일이다. 물론 개발도 한다.

하지만 개발에서 손을 완전히 땐 관리자의 경우는 점점 개발과 멀어지게 된다. 이렇게 1~2년만 지나도 섣불리 기술에 대해서 얘기하기가 어려워 진다.

이 외에도 개발 경험은 거의 없는 관리자도 있다. 반대로 이런 관리자도 SW 조직 관리를 2~3년 하게 되면 풍월을 읊게 된다. 개발에 대한 왠만한 용어도 알게 되고 어떻게 돌아가는지 대충 파악이 된다. 그렇다고 기술을 아는 것이 아니다.

그런데, 과거에 개발자였던, 개발을 모르는 관리자던 이들이 개발에 있어서 기술적인 결정들을 좌지우지 하는 경우가 있다. 

조직의 상하를 떠나서 기술적인 결정의 책임은 개발자들에게 있는 것이지 관리자에게 있는 것이 아니다. 좀더 중요한 기술적인 결정은 일개 개발자를 떠나서 기술위원회나 CTO가 결정하는 것이다.

하지만 우리나라에서는 상하관계가 엄격하여 기술적인 결정도 관리자들이 영향을 미치는 경우가 많다.
이를 상하 관계가 아닌 역할의 구분으로 생각하는 것이 좋다.
개발과 관리의 전문적인 역할 구분으로 생각하자.

현재 이러한 판단을 하기 애매한 위치에 있다면 기술이든 관리든 하나를 정하는 것이 좋다. 둘다 잘하기는 거의 불가능하다. 개발팀장으로서 관리도 약간 해야 한다면 작은 조직에서는 그야말로 약간만 하는 것은 괜찮다. 이것도 큰 조직에서는 쉽지 않다.

기술은 기술자의 몫이다.
 
image by Brain farts
저작자 표시 비영리 변경 금지
신고

전규현 개발조직

  1. 이글을 지금 일하는 사업의 PM이 봤으면 좋겠네요 ㅋ
    매번 잘 보고 갑니다~

  2. black_H님 오랫만입니다.

    PM에게 보여주시면 되겠네요. ^^

QA팀은 없다고 생각하라

2010.10.11 18:41 by 전규현


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






저는 여러 소프트웨어 회사를 접할 기회가 많기 때문에 우리나라의 소프트웨어 현실을 다양하게 보게 됩니다.

많은 회사들이 전문 QA팀없이 개발자가 테스트를 하곤합니다. 제가 접한 소프트웨어 회사들의 대략 70% 이상이 전문화된 QA가 없었습니다. 심지어는 대기업에 속한 회사들도 QA팀 없이 개발자나 팀장이 테스트를 하는 경우도 있습니다.

그 이유야 제가 이전에 여러번 언급했듯이 주먹구구식 개발이나 형식에 치우친 프로세스를 채용한 회사들은 개발자가 아니면 그 기능을 속속들이 잘 모르기 때문에 개발자나 팀장이 테스트를 할 수 밖에 없고 누가 좀 도와준다고 하더라도 Random 테스틑 밖에 수행을 하지 못합니다.

이 이슈는 차치하고 소수의 QA팀을 가지고 있는 회사들에서는 QA테스트가 제대로 이루어지고 있는지 확인을 해볼 필요가 있습니다. 제 경험에 의하면 많은 회사들이 QA팀이 있다고 하더라도 QA팀을 충분히 활요하지 못하고 있었습니다. 이런 경우들이 존재합니다.

- QA팀에게 개발자의 일을 떠넘기는 경우
QA팀이 무슨일을 하는 것인지 정확하게 모르는 경우입니다.

- QA팀에게 테스트를 할 수 있는 충분한 정보를 제공하지 않는 경우
QA팀이 있다고 해도 또 주먹구구식으로 테스트를 하거나 QA팀이 제품의 기능을 알아내기 위해서 제품을 일일이 써보는 수밖에 없는 경우입니다. 수박 겉핧기씩 테스트를 할 수 밖에 없고 많은 버그는 고객들이 찾아줍니다. 

- QA팀의 테스트 결과를 비난하는 경우
QA팀의 책임이 무엇인지 모르는 경우입니다.

이 중에서 첫번째에 대해서 얘기를 해보려고 합니다. 
소프트웨어 회사들이 QA팀 없이 개발을 하다가 QA팀이 생기고 또는 테스트 전담 인원이 생기면 개발팀의 자신들이 그동안 해 왔던 테스트를 QA팀에서 대신 해줄 것으로 착각을 하곤합니다.

엄밀히 말하면 이는 잘못된 생각입니다. 대부분의 개발자들이 하는 테스트는 QA테스가 아닙니다. 개발자들이 개발과정에서 당연히 해야할 유닛테스트와 통합테스트일 뿐입니다. 

개발자들은 자신들이 하던 테스트를 도와줄 사람이 생겼다고 생각하고 대충 구현을 해서 QA팀에 넘겨버립니다. 그러면 QA팀에서는 버그투성이인 제품을 테스트하느라고 시간을 낭비하곤 합니다. 그래서 정작 제대로 된 테스트는 해보기도 어려운 경우가 허다합니다. 이런 회사들의 특징은 개발자와 QA팀이 타이트하게 붙어서 개발자가 개발을 하는대로 바로바로 테스트를 해줍니다. 혹시 이런 형태로 개발을 하고 있다면 QA팀을 전문가로 생각하지 않고 개발팀의 심부름꾼 정도로 생각하고 제대로 활용하지 못하고 있고 생각할 수 있습니다.

개발자들은 QA팀이 없다고 생각하고 완벽하다고 생각하는 코드를 작성해서 QA팀으로 넘겨야 합니다. QA팀은 이렇게 만들어진 제품을 제대로 검증할 책임이 있습니다.

먼저 QA팀의 역할이 무엇인지 정확하게 이해해야만 QA팀이 제 역할을 할 수 있습니다.

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


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

전규현 개발조직 qa, 테스트

  1. QA팀이 없다고 생각하지 않아도 실제로 없는게 참...
    좀더 많은 회사에서 제대로 된 QA팀이 운영되기를 바랍니다. ㅎㅎ

  2. 안녕하세요. 제주소년님
    회사의 규모가 얼마나 되나요? 개발자의 인원수에 따라서 QA팀을 운영하는 방법이 달라질 수 있습니다.

  3. QA팀이 개발자의 심부름꾼정도라.. 정말 동감이죠 'ㅅ'
    개발 하다가 나름 QA쪽의 비젼을 보게 되었고, 계속 개발 관련 공부도 하고 QA관련 공부도 계속하는데..

    현실은 답답하기만 하네요.
    적은 규모의 QA팀도 아니고 나름 조직 자체는 제대로 세팅되었다고 하는데..

    가장 큰 문제는 말씀해 주신대로 전체 조직의 인식인 것 같습니다.

  4. Noel님 반갑습니다.
    QA팀이 일단 세팅되면 또 새로운 도전이 시작됩니다. ^^

  5. Blog Icon
    qahuni

    반갑습니다.

    충분한 testbasis를 얻기 위해 개발프로세스와 QA의뢰절차를 개선하고 있습니다.
    개발조직에서는 문서쓰는 것을 힘들어 하고, 심지어 소비적으로 느끼고 있습니다.

    V-Model 등에서는 각 단계별로 testbasis가 산출되어야 하고, 테스트 후 testware가 산출되어야 한다고 정의합니다.

    개발조직에서는 요즘같이 빠르게 변모하고 있는 시대에 매우 뒤처질만한 행동이라고 반박합니다.

    저는 그래도, Agile이라 하더라도 정의되고 리뷰되어야 할 것들은 문서가 반드시 필요하다고 생각합니다.
    기능명세나, 기본설계서 정도는 필수라고 생각하지요.

    실제 다른 회사들은 이 문제를 어떻게 풀고들 계신지요?
    기능명세 없이 테스트를 기획할 순 없지 않을까요?

  6. 조직이 개발 Process 개선을 수행하고 계시는군요. 에자일이건 CMM이건 개발 Process의 중심은 개발하고자 하는 시스템의 유형입니다. 이것에 맞도록 구축되어야 합니다. 에자일 Process라는 분야는 아무리 봐도 정확한 철학이 없고 단지 빠른 개발이라는 마케팅 용어만 보이는데... 빨리 개발한다는 것은 그 안에 정확하게라는 단어를 포함하는 것으로 알아들어야 합니다. 그게 국제적인 관례인데, 우리는 빨리 개발한다고 하면 정말 빨리만 개발하려고 합니다. 이 부분에 대한 오해가 커질 수 있는게 우리 한국 개발문화입니다. 이 부분 진지한 대화가 필요한 분야이지요.

  7. Blog Icon
    KID

    좋은 글 잘 읽었습니다. 책 이외에서도 좋은 글을 접할 수 있었는데 모르고 살았네요..
    저희 조직도 품질이라는 것을 어떻게 해결해야하나 고민중이고. 테스트 엔지니어를 뽑고 면접을 보는 등의 진행이 되고 있습니다.

    한가지 문의 드리고 싶은 사항은 QA 담당자의 개발 경력은 필수인가 아닌가입니다.
    제가 품질 분야 지식이 약해서 우둔한 질문인듯 합니다만, 제 생각에는 개발 경력을 가진 사람이 품질쪽으로 경력이 쌓여져 왔다면 좋은 자원일 수 있다고 생각했습니다.

    하지만 현실에서는 개발 경력을 가지고 품질쪽 업무를 수행하는 사람을 찾기 어렵습니다.
    모집을 하면 말씀하신 것처럼 개발자의 테스트 업무를 대신 수행하는 역할을 주로 해온 분들이 대부분입니다.
    이 상황을 겪다 보니 QA는 개발 경력이 없어도 정말 업무 수행이 가능한건가? 라는 생각이 들었습니다. 개발 경력이 있어야 QA 역할을 더 잘 할 수 있을 것이라고 여기고 있었는데.. 실제 현실은 그렇지 않은것 같습니다.

    어떤 것이 맞는 것일지 고견을 부탁드립니다.

  8. 개발자 경력이 있다면 기획, QA, Tech support 심지어 경영까지 다 도움이 되겠지만, QA엔지니어에게 꼭 개발경력이 필요한 것은 아닙니다.

    개발경력이 있다면 QA엔지니어 업무에서 도움이 되는 경우도 있습니다. White box 테스트도 가능하고 테스트 관련 툴도 개발할 수 있고, 테스트 케이스를 작성하더라고 개발자 관점에서 좀더 넓은 커버리지로 작성이 가능합니다. 개발자 경력이 두루두루 도움이 될 수 있지만 필수는 아닙니다.

    하지만 개발 경력이 없어도 일반적인 QA업무는 수행이 가능합니다. 문제는 스펙이 제대로 작성되지 않았다면 QA업무 전체 프로세스가 어려워집니다. 정상적인 프로세스에서는 QA엔지니어가 테스트케이스를 작성하면 개발자들이 개발자 관점에서 리뷰를 해주기 때문에 중요한 테스트 케이스가 누락되거나 하지는 않습니다.

    하지만 현실은 전문적인 QA엔지니어를 찾기가 쉽지는 않습니다. 개발자의 엉성한 테스트를 도와주는 역할을 하는데 그치는 경우가 많습니다.

    QA엔지니어의 역량 문제는 아닙니다. 개발 전체 프로세스와 문화가 문제입니다. QA엔지니어가 제한된 역할밖에 못한다면 개발자 출신 QA를 뽑을 것이 아니라 프로세스와 개발 문화가 잘못되어 있는지 알아봐야 합니다.

개발팀장과 프로젝트관리자(PM)

2010.10.04 11:13 by 전규현


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





오랫만에 찾아뵙니다.
요즘 워낙 바쁜 날을 보내고 있다는 핑계로 블로그 포스트를 자주 못하고 있습니다. 다시 힘을 내서 시작하려고 합니다.

최근에 컨설팅에 많은 시간을 보내고 있는데, 컨설팅을 하면서 주로 겪게 되는 현실적인 얘기 위주로 적어볼까 합니다. 그 중에서 가장 흔히 보게 되는 것이 개발팀장의 애매한 포지션입니다.

당신이 개발자라면 또는 개발팀장이라면 어떠한 일을 하고 있는지 잘 살펴 보시기 바랍니다. 제가 여러 회사를 컨설팅하면서 만나본 개발팀장의 역할은 천차만별이었습니다. 

공통점은 있습니다. 개발자로서 오랫동안 일을 하다가 개발팀장이 되었다는 것입니다. 
하지만 현재 하고 있는 일들은 천차 만별입니다.

어떤 개발팀장은 여전히 코딩에 90% 매진하고 있고, 어떤 사람은 프로젝트 관리만 하고, 어떤 사람은 회사 경영회의 쫒아다니면서 바쁜 나날을 보내고 있고, 어떤 사람은 코딩도 하고 관리도 하고 정신 없이 시간을 보내는 사람도 보았습니다.

개발팀장은 "개발팀"의 "장"이란 의미를 가지고 있어서 관리자로서의 역할을 요구하고 있는 듯하지만 대부분의 소프트웨어 회사에서는 가장 경험이 많고 뛰어난 개발자들이 맡고 있습니다.  

하지만 회사에서는 "장"이라는 의미에 따라서 개발자로서의 뛰어난 역할도 계속 해주기를 원하면서 관리도 하기를 원하는 경우가 많습니다. 개발팀에서 필요한 관리란 일반관리와 프로젝트관리인데, 보통 개발팀에서 일반관리는 할일이 별로 많지 않습니다. 일반관리 이슈가 매우 크다면 프로세스나 시스템을 개선해야 할 것입니다. 

따라서 이슈가 되는 것은 프로젝트 관리인데, 이것이 그렇게 만만한 일이 아닙니다. 즉, 개발팀장이 최고의 개발자로서 스펙도 잡고, 설계, 코딩도 하면서 할 수 있을 만큼 프로젝트관리가 간단하지 않습니다. 보통 어디하나 펑크가 나게 되어 있습니다. 

제 경험상 보통 프로젝트 관리에서 문제가 생기는 경우가 많습니다. 개발팀장은 개발자체는 원래 하던일이고 익숙하지만 프로젝트 관리는 경험도 적고 대부분 방법도 모르기 때문에 상식선에서 개발하느라고 바쁜 시간에 짬을 내서 하기 때문에 문제가 생기기 십상입니다.

그래서 필자는 개발팀장은 계속 최고의 개발자로서 개발 조직을 기술적으로 이끌고, 프로젝트 관리는 전문 PM(Project Manager)에게 맡기는 것을 권장합니다. 물론 개발자 출신으로 꼼꼼하고 관리를 좋아하는 사람이 PM으로 성장하는 것도 좋습니다.

개발조직이 10명 미만이고 대부분 소규모 프로젝트만을 진행한다고 하면 PM을 따로 두지 않아도 어떻게든 프로젝트가 진행이 될 수 있을 겁니다. 하지만 조직이 커지고 프로젝트가 복잡해지고 많은 프로젝트를 수행한다면 프로젝트의 성패는 요소기술에 달려 있지 않다는 것을 알게 될 것입니다. 이쯤되면 전문 PM이 없다면 가장 뛰어난 개발팀장들은 기술에 매진하지 못하고 잘하지도 못하는 프로젝트 관리에 허덕일 것입니다.

개발팀장은 쉽게 대체가 되지 않지만 PM은 외부에서 영입을 하는 것도 가능합니다. 즉 외부에서 영입한 사람이 할 수 있는 일을 회사에서 가장 바쁘고 가치 있는 일을 하는 개발팀장에게 맡기는 것은 비효율적입니다.

그렇다고 PM이 아무나 할 수 있다는 뜻은 아닙니다. 이또한 전문적인 일로서 전문가가 해야 하는 일입니다.

지금 일반관리자, 개발팀장, PM 등이 마구 섞여서 일을 하고 있다면 일단 임무를 나누어서 생각하는 습관을 들여야 할 것입니다. 그리고 현재 어느부분에서 문제가 생기고 있고 어느 역할을 보충해야 할지 계획을 세워서 조직을 튼튼하게 해야 합니다. 그렇지 않고 개발자 인원수만 늘여서는 현재의 많은 문제들이 해결되지 않습니다.

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

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

전규현 개발조직

  1. Blog Icon
    csj

    예전 피터 드러커의 책에 나온 비슷한 내용이 생각납니다.
    직위가 올라갈 수록 계속 역할은 바뀌는데, 그 바뀐 역할을 빨리 인지해야 성공할 수 있다는..
    뭐 그런 이야기 였는데요 아마 비슷한 맥락이 아닐까 생각합니다.
    아쉽게도 학부 때 읽은지 오래되어서 책 재목이 생각나지 않는군요 ㅎㅎ
    하지만 현실에선 개발자는 슈퍼맨이 되어야만 하죠 ㅠ.ㅜ

  2. 안녕하세요. csj님
    일부 비슷한 맥락이 있을 수도 있겠네요. ^^ 요지는 전문적인 Role이 중요하다는 뜻입니다.

  3. 안녕하세요 규현님.
    전 PM과 팀장이 나뉘어져 있던 프로젝트를 경험한 적이 있습니다.
    효율적으로 보였으나 그들간의 업무가 중복되었고, 팀장은 실제 프로젝트에서 무엇을 하는지 모를정도로 얼굴을 비추지 않더군요. 간혹 그런케이스를 제외하곤 역시나,.. 큰 프로젝트 일수록 팀장과 PM을 분리하여 역할을 분담하는 것이 더 효율적이라고 생각합니다.
    오랜만에 글이 올라와서 오랜만에 기분좋게 댓글 달고 가요~~ 파이팅~~!

  4. moova님 안녕하세요.
    PM은 전문적인 롤로서 나름대로 표준적인 뜻을 가지고 있지만, 팀장은 그야말로 천차만별로 회사마다 뜻이 다릅니다. 이런 경우는 관리자로서의 팀장을 말하는 것 같습니다.
    PM은 프로젝트 관리, 팀장은 팀 일반 관리를 나눠서 하다보면 Conflict가 나는 경우가 있고, 개발자는 중복 보고를 하기도 합니다. 회사가 워낙 크고 관리가 복잡한 경우라면 모를까 대부분의 경우 소프트웨어 회사에서 개발자에 대한 일반관리는 그렇게 많이 필요하지 않습니다.
    관리를 하는 사람이 둘이 있으면 말씀 하신 것과 같이 문제가 종종 발생하죠.

    제가 말하는 팀장이란 대부분의 소프트웨어 회사에서 그러하듯이 테크니컬 리더를 말합니다. 이런 경우 PM의 중요성에서 대해서 말하고자 합니다.

  5. Blog Icon
    장림

    개발팀장과 PM이 다를 경우에 발생할 수 있는 문제점은 잘 모르겠군요.
    어떤 문제점들이 있을까요?

  6. 안녕하세요. 장림님
    회사마다 팀장의 롤이 다르기 때문에 PM과 Conflict가 나는 경우에는 문제가 발생할 수도 있겠네요. ^^

개발자의 파워는 어디에서 오는가?

2010.08.03 17:37 by 전규현


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






뛰어난 개발자를 관리자로 써먹는 것 같이 개발조직에 비효율적인 일은 별로 없습니다.

하지만 현실에서는 이런 일이 흔히 벌어지고 있습니다. 실제로 저도 여러 회사에서 자주 접하고 있습니다.
여러가지 이유가 있을 수 있겠지만 주요 이유는 회사에서 개발자로서 꾸준히 성장할 수 있는 Career Path를 보장하기 않기 때문입니다.

회사에서 파워를 가지려면 팀장이 되어야 하고, 그래야 개발자들을 거느리며 힘을 행사할 수 있게 됩니다.
하지만 일단 팀장이 되고나면 개발에 전념할 시간은 점점 줄어들게 됩니다. 그렇다고 개발을 포기하고 관리만 하기에는 관리할 일의 양도 얼마 되지 않고, 파워가 줄어들게 될 까봐 걱정을 하게 됩니다.

흔히들 개발자는 행정적인 파워가 없어도 기술력에 따른 카르스마에서 파워가 생긴다고 하지만 이는 실제 현장에서는 공허한 얘기가 됩니다.

제대로 세팅된 소프트웨어 회사라면 개발팀은 관리할 것이 그렇게 많지 않습니다. 하지만 그렇지 못한 회사는 이래저래 관리할 일이 점점 늘어나게 되서 불필요하게 팀장의 관리에 많이 의존하게 됩니다.

이렇게 뛰어난 선임개발자들이 개발과 관리를 넘나드는 사이에 기술은 점점 멀어지게 되고 돌아올 수 없는 강을 건너는 경우가 예사입니다.

결국 100원짜리 개발자를 10원짜리 관리자로 만들고 맙니다.

물론 개발자 중에는 관리능력도 뛰어나서 관리자 역할을 훌륭하게 수행해 내는 사람도 있습니다. 
이 경우 개발자가 개발보다 관리에 관심이 많고 관리 능력이 더 뛰어나다면 관리자로 전환하는 것도 좋을 겁니다. 하지만 개발과 관리 둘다 능력이 좋다면 개발을 선택하는 것이 좋을 겁니다. 개발이 훨씬 부가가치가 높으며 다른 사람으로 쉽게 대체할 수가 없습니다. 둘다 훌륭하게 수행해내기를 바란다면 욕심입니다. 

뛰어난 개발자를 개발자로 있게하려면 회사에서 경력을 보장해줘야 합니다. 
개발자로 꾸준히 성장할 수 있는 Position을 만들어야 하고 연봉에서 대우을 해줘하고 관리자 이상의 파워를 가질 수 있는 제도를 마련해줘야 합니다. 그렇지 않는다면 뛰어난 개발자들이 개발과 관리사이에서 끊임없이 고민하다가 많은 개발자들이 관리자로 전환되면서 회사에 손해를 끼치게 될 겁니다.

수평적인 조직구조를 가진 외국의 회사들과 다르게 수직적인 조직구조를 가지고 있는 우리나라 회사에서 개발자에게 힘을 실어주기란 쉽지 않습니다. 그래서 제도적으로 뒷받침이 되지 않으면 어렵다는 것입니다.

현실적으로 쉽지 않은 일임을 공감합니다. 개발에 대한 전문성을 인정해주는 분위기가 같이 성장을 해야 개발자 경력 보장도 점점 이루어질 것입니다.

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

전규현 개발조직

  1. 글 잘 읽고 갑니다. :D

  2. 안녕하세요. 우울한 딱따구리님...
    요즘 워낙 바빠서 블로그 포스팅이 뜸해지네요.
    그래도 언제나 글을 읽어주셔서 감사합니다.

  3. 개발과 관리를 둘 다 잘 하는 사람이 있으면 관리를 시키는 것이 낫지 않을까 싶습니다.

    관리 잘 하는 사람이 많은 것 같아도 사실 개발자와 프로젝트를 관리 할 수 있는 관리자는 정말 뛰어난 개발자보다 더 소수가 아닐까 싶거든요.

    이런 관리자가 있어주어야 그 밑에서 정말 개발만 잘 하는 사람들이 편하고 효율적으로 일 할 수 있지 않을까 싶기도 하구요.

  4. 안녕하세요. bookworm님
    우리는 흔히 팀장과 PM을 혼동하곤 하는데, 위에서 언급한 내용은 팀장, 즉 일반관리자 역할입니다.
    팀장은 관리자트랙인데 비해서 PM은 특수한 영역으로서 개발자와 관리자의 중간쯤에 있는 트랙입니다. 즉 개발도 잘 이해하고 관리도 잘할 수 있는 사람들의 영역입니다.

    일반적인 작은 회사나 작은 개발팀은 전문적인 PM이 필요하지도 않고 관리도 그렇게 많이 필요하지 않습니다. 그냥 선임 개발자가 대춤 겸업을 해도 큰 문제가 발생하지 않습니다.
    그래도 우리는 보통 마구 혼동해서 사용합니다. 하지만 규모가 커지기 시작하면 모든 영역이 매우 전문화가 되어야 합니다.

    말씀하신 내용은 PM에 가까운것 같습니다. 프로젝트가 커지면 PM의 역할이 정말로 중요하고 뛰어난 PM이 프로젝트 성공에 가장 큰 역할을 하며 책임도 큽니다. 개발자중에서 PM 트랙을 선택하는 것도 좋은 선택중 하나라고 생각합니다. 단, 우리나라에서는 PM의 역할에 대해서 제대로 정의가 안된 회사가 많기 때문에 자칫 이직시 애매해지는 경우가 많은 것 같습니다.

    아무튼, 아직 개발자, PM, 관리자에 대한 전문성에 대한 이해가 전반적으로 부족한 분위기는 차츰 바꿔나가야 하겠습니다.

  5. 말씀하신 부분에 공감합니다.

    우리나라는 아직 일반 관리자, PM, 개발자 등의 역할이 전문화가 안 된 것 같습니다.

    개인적으로 개발자로 하고 싶은 것이 많은데 일반 관리부터 PM까지 겸업하려니 고민과 갈등이 많습니다.

  6. 관리자라고 한다면 피플매니징이 주요 업무여야 한다고 봅니다. PM은 말 그대로 프로젝트만을 관리해야 하는 거구요.

    예전까지는 팀장 = 관리자 = PM이었는데(종종 프로젝트에 따라서 PM이 아닌 경우는 있었지만), 외국계는 이 매니저와 PM이 확실하게 다른 캐리어 트랙을 타더군요.

  7. 안타까운 현실에 우울하죠.
    몇 년 뒤면 이제 40이 되는데, 등 떠밀려 선택을 하게 되겠죠? ㅡ,.ㅡ;;

  8. whiterock님 안녕하세요.

    계속 개발을 하고 싶은 개발자들이 등떠밀려 관리자가 되는 것은 개인이나 회사에 모두 손해입니다.
    본인의 의지를 회사에 피력을 해보시죠. 회사 사정은 정확하게 모르지만 시도를 해보시는 것이 어떨가요?

  9. 앞으로의 진로를 고민하는 사람으로 말씀하신 것처럼 문화가 바뀌기를 바라고 있지만, 현실적으로 한국 기업문화에서는 쉬운 부분은 아니라고 생각합니다. 저 또한 그렇게 만들고 싶고 그러기 위해서는 힘(?)이 있어야 하고, 힘을 가지려면 관리자가 되어야하니까요..아쉬운 현실입니다.
    님께서 가지고 계신 가치관이 많이 전파되었으면 하는 바램입니다. 글 감사합니다.

  10. 꼬부가빠님 안녕하세요.
    기업이 생존을 위해서는 어쩔 수 없이 이렇게 하지 않으면 안됩니다. 한국의 기업문화 그대로 따라서는 살아남을 확률이 너무 많이 떨어집니다.
    변화는 선택의 문제가 아니고 생존하느냐 죽느냐의 문제입니다.

  11. thankee님 안녕하세요.
    무슨 말쓴인지?

  12. Blog Icon
    godway

    Postion 이라고 쓰신 부분이 Position 맞죠?

  13. 안녕하세요. godway님

    당연히 오타죠. - -; 바로 수정했습니다.

  14. Blog Icon
    대한민국 개발자

    마지막 까지 살아남는자가 최고의 승자이죠

  15. 외국에서는 10년 정도 개발하면 이제 조금 하는 구나
    하는데 우리나라는 5년정도 개발하고 관리자로
    빠지니 관리도 못하고 기술도 잘 모릅니다.
    그러면서 기술은 중요하지 않다라고 하죠.

  16. beyondj2ee님 안녕하세요.
    10년차와 20년차가 또 다르죠.
    그런데 우리나라 대부분의 SW 개발자들은 그 차이가 별로 없는 경우가 많습니다. 고참 개발자들이 신참과는 다르게 무슨 일을 어떻게 해야 하는지 모르는 경우가 대부분입니다.

  17. 우리나라의 대부분의 SW업체가 중소기업이지만....
    워낙 작은 회사는 모든 구분이 참 애매모호합니다.
    또한 회사 업무 내용이나 개발 규모등에 따라서도 많이 틀려지겠죠

    우리회사 같은 경우에는 한두사람이 하나의 프로젝트를 개발하고
    다수의 기존 프로젝트 유지보수까지 끌고 가는 상황이라
    별도의 관리자나 PM등이 있지도 않고요
    개발자가 계속 경력을 쌓고 개발을 할 수 있도록 지원할 생각은 하고 있습니다.

    개발자에게 힘을 실어주는 제도라는게 구체적으로 어떤 예가 있을까요?

  18. 크레브님 안녕하세요.
    작은 회사에서는 한사람이 여러 프로젝트를 진행하기도 하고 여러 역할을 겸임하기도 합니다. 아주 일반적인 현상입니다.
    단, 여러일을 겸임할 때도 역할의 구분을 하는 것이 좋습니다. 즉 최소화를 해야 좋지만 문서도 만들고 프로세스도 따른 것입니다. 그래야 조직이 조금씩 커지면서 자연스럽게 업무들이 분배됩니다.
    혼자 여러일을 한다고 혼자만 알 수 있게 또, 구분없이 일들을 마구 섞어서 하게 되면 인원이 늘어가도 효율적으로 돌아가지 않습니다.

    개발자에게 힘을 실어주는 제도 중 하나는 행정적으로 의사결정을 할 수 있는 권한, 예산을 집행 할 수 있는 권한을 부여한는 것입니다. 사실 회사의 의사결정 중에서 기술적인 것들은 개발자들이 해야 하는 것입니다. 특히 회사의 최고 개발자들이 결정을 해야 합니다. 하지만 개발과 관리가 애매한 회사에서는 기술적인 결정임에도 불구하고 관리자들에 의해서 많이 좌지우지 됩니다. 따라서 기술적인 결정이 개발자에 의해서 결정될려면 회사의 최고 기술자가 최고의 임원자리를 차지하고 있어야 합니다. 그래서 CTO가 필요한 법이지요. CTO에는 개발자에게 Role model이 될 수도 있습니다.

    그럼에도 많은 회사에서 CTO가 관리자의 역할을 하는 것을 보면 사실 CTO가 아닌것이지요. 그냥 연구소장인 것입니다.

    경영자가 기술의 중요성과 전문성을 이해해야만 이 모든 것이 가능합니다.

  19. 드물겠지만 개발을 하고 싶은 사람도 있는데 관리직으로 떠밀린다면 우울할꺼 같아요

  20. 구차니님 안녕하세요.
    개발자도 고참이 되어도 개발자로서 계속 가치를 부여하기 위해서는 달라져야 합니다.
    경력이 많아지는 것만 가지고는 부족합니다.
    뷰도 넓어져야 하고, 비즈니스도 잘 알아야 하고, 많은 프로젝트와 후배들에게 영향을 많이 줘야 합니다.
    그러기 위해서는 회사의 프로세스와 시스템이 잘 갖춰져 있어야 하며 문서화와 리뷰가 잘 이루어져야 합니다.

  21. 공감합니다.
    아직 개발을 더 하고 싶은데 관리자로 되면 힘들것같아요;;

    아직 저는 신입 개발자이지만

    관리자로서 준비를 해두어야 할지
    개발자로서 살길을 찾아야할지 고민입니다.

  22. acude님
    대한민국에서는 어려운 결정입니다.
    아직 신입이시니까 더 좋은 여건입니다. 이미 머리가 굳은 경력이 많은 개발자들은 쉽게 마인드를 바꾸기가 어렵습니다.
    지금부터 꾸준히 소프트웨어 공학에도 관심을 가지고 경력을 쌓아보세요.

  23. 안녕하세요. 오랜만에 들려봅니다. ( 그동안 병원생활하느라;;;)
    여전히 깨어있는 글. 무척이나 공감합니다.
    얼마전 해외에서 일하는 후배와 이야기를 하다가,
    암담한 한국의 소프트웨어 업계와, 그래도 캐리어를 꾸준히 보장해 주는 해외 소프트웨어 업계를 비교해 보고 참.. 한국의 기업들이 개선해야할 부분이 너무 많은것 같아서 답답하기까지 하더라구요.

    물론 해외기업과 한국기업이 문화태생부터 다른 것은 사실이지만 같은 소프트웨어를 다룬다는 입장에서는 똑같을 듯 싶은데.. 왜 한국 기업은 공학인들에게 당연히 보장해 줘야 될 부분들을 그렇게 늘~~ 그늘에 놔두려고 하는지..참 안타깝기 까지 했습니다.

    그리고 기술밥먹는 사람들은 기술밥먹는 사람끼리 뭉쳐서 타 도메인에 대한 상생을 좀 무시하는 경향이 있는것도 같구요.

    또, 말씀하신것처럼 개발자도 소프트웨어공학에 대한 지식을 꾸준히 연마해야 한다고 봅니다. 기업에 프로젝트를 하러 다니면 소프트웨어공학에 대해 관심도 없고, 배우려고 하지 않는 곳이 꽤 많았습니다. 단지 API의 어떤 기술만 외쳐댈뿐이었지요. (숲을보는 인재가 별로 없는 듯) 어디서부터 잘못된 문화인지... 그 원인을 분석하고 개선할 수 있다면 정말 좋겠지만.. 아직까지 먼 세상이라고 느껴집니다.
    부디 깨어있는 분들이 계속 개선점을 고치고 알리어 꾸준히 바뀌어 나가길 희망합니다.

  24. 안녕하세요. moova님
    오랫만입니다. 그동안 쾌차하셨는지요?

    그래도 저와 저의 회사에서는 그동안 여러 회사를 컨설팅하면서 마이드를 많이 바꾸고 있습니다. 그래서 점점 이러한 것들이 파급되고 있다고 생각합니다. 그 일환으로 책도 쓰고 블로그도 하는 것입니다.

    이땅에서 소프트웨어 개발자가 최고의 직업이 되는 날까지 저는 뜁니다. ^^

  25. Blog Icon
    Kevin

    안녕하세요, 이전에 'SVN' 이란 것을 검색하다가 게시된 글들에 흥미를 느껴 간간이 들리고 있는 IT분야 취업 준비생입니다. 간단히, 저의 소개를 하자면 국내 컴퓨터공학과를 졸업했으며 오는 하반기에 국내취업을 목표로 하고있는 젊은 청년입니다. 또한, 현재 Wipro라고 하는 인도 SI업체에서 프로젝트를 맡아 수행중이기도 합니다.
    앞으로 저보다 앞서서, 미래를 그려나가는 선배님들께 좋은 말씀도 들었으면 합니다.
    잘 부탁 드리겠습니다 : )

  26. Keyvin님 안녕하세요.

    새술은 새부대에 보관해야죠...
    경력이 오래된 개발자들은 마인드가 쉽게 바뀌지 않습니다. 그동안 이룩해 놓은 것들과 몸에 밴 습관을 버릴 수가 없기 때문에 그렇습니다.

    그래서 kevin님과 같은 신진들이 더욱 중요합니다.
    처음부터 올바르게 시작해야 합니다. 하지만 현장에서 실제로 일을 하다보면 반대된는 도전에 수없이 직면할 것입니다. 그것이 지금 우리나라의 현실입니다. 여기에 좌절말고 꾸준히 정도를 걸어나가면 뛰어난 개발자가 될 수 있을 겁니다.

    요소 기술만 신경 쓰지 마시고 소프트웨어 공학고 꾸준히 공부를 하고 경험을 하는 것이 중요합니다. 소프트웨어 공학은 공부만 해서는 절대로 익힐 수 없는 것이고 제대로된 경험을 하는 것이 익히는 유일한 방법이며 시간도 많이 걸립니다.

    현장에서 여러 도전에 부딪힐 때 저를 비롯한 선배들이 도움을 줄 수 있기를 바랍니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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