프로그래밍의 생산성과 연봉

IT가 생산성이 낮다고 보진 않습니다.
오히려 지구상에 존재하는 그 어떤 것 보다 높은 생산성을 가지고 있다고 높니다.
생산의 고도화의 결정체로 봅니다.
문제는 그것이 너무 고도화되어 돈이 되기 어렵다는 것입니다.

거의 10년 전에 **공사의 노동조합에서
ERP 프로그램 도입을 반대한 적이 있습니다.
표면적인 이유야 작업장 감시, 인권 등을 내세웠지만
내부적인 이유는 직원의 1/4이 당장 떠나게 된다는 것이였습니다.
여전히 그 공사에서는 지금도 안쓰는 것으로 알고 있습니다.

어제 은행창구에 광과금 납부할려고 40분 기다렸는데
막상 창구에서 안받아 주더군요. 뒤에있는 자동납부기 사용하라고...
은행의 무인점포 이야기가 멀리 있는 것이 아니더군요.

지금은 고작 ERP와 자동단말기 정도입니다만 조금 시간이 지나면
인공지능화된 처리와 로봇들이 등장하면 더욱 달라지겠죠.
하루가 다르게 '러 다이어트'에 대하여 사람들이 논할 것으로 봅니다.

IT노동 해방을 부르는 도구이자 실업을 부르는 도구.
전 그렇게 봅니다.
공생의 지혜를 찾아야 할 시기가 다가 오는 것 같습니다.

능력있는 고액연봉자가 존재한다는 것은 업무량비 매출액이라는 단순 등식으로만 성립되는것이 아니라고 봅니다.

프로그래밍, 네트워크 등으로 7백만엔대 이상의 고액연봉자가 된 사람이라면 그 경력과 실력이 우수할 것입니다. 그 실력이 우수하다는 것은 단순히 저액연봉 코더가 5시간 걸릴걸 1시간에 끝낸다는 의미가 아니라 저액연봉자가 할수 없는 일을 그사람은 할수있다는 의미라고 생각합니다.

IT회사의 영업부에서 프로젝트를 수주하다보면 실제 그 프로젝트를 해낼만한 기술력이 자기업에 존재하는지, 그리고 그것을 단순히 입으로만 이야기하는게 아니라 발주처에 증명해야할 경우가 있습니다. 그럴경우 그런 우수한 기술자의 존재유무에 의해서 그 프로젝트를 수주할 수 있는가 없는가의 여부가 결정이 되고 그 기술자의 존재로 인해서 해당 프로잭트의 수주유무가 결정된다면 그것은 단순히 시간당 생산성으로 계산될수 있는 문제가 아닐것입니다. 그 고액기술자가 존재함으로 인해서 저액연봉자도 자기일을 받느냐 못받느냐가 결정되니까요.
(조금은 다른 이야기지만 이번에 저희회사에서 NTT코무야와 SE계약을 맺는데 기술시험을 봐서 자격을 입증해야 하더군요. 시험점수에 따라서 받을수 있는 금액도 달라진다는. ㅡㅡ; )

단순코딩 생산성이야기로 돌아와 보면 실력이 있는사람이 코딩하느냐 못하느냐에 따라 디버깅이 쉬워질수도 있고 어려워질수도 있습니다. 그리고 보통 파트별로 코딩시 버그 발생하면 담당자가 디버깅을 하게되는데 자기코드라 할지라도 실력에 따라 디버깅의 시간차이가 엄청나겟죠. 그걸 떠나서 실력자는 좀더 버그가 적고 유연한 코딩이 가능할 것입니다. 최초 사양인식과정에서 실력차가 드러나는 경우도 많고요. 즉 전체적인 엔터테이먼트의 입장에서 고액실력자가 훨씬 효율이 높다고 봅니다.

제가 알기로 일본에서 젊은 프로그래머들의 연봉은 300-400 사이로 알고 있습니다만(틀릴수도 있습니다. 젊다는 기준이..ㅡㅡ; ) 이런 프로그래머 2명보다 700만엔 받는 알짜배기 숙련프로그래머와 같이 팀을 짜고 프로그래밍을 하는게 훨씬 마음든든하고 공수도 단축시킬수 있을거라는 생각이 드는군요. 그게 곧 생산성 아닐까하는 생각을 합니다.

서론>
저는 조그만 벤쳐회사를 다니다가,망할즈음에 사장님의 노력으로 대기업에 인수합병이 된 경우입니다.
현재 일하고 있는 회사는 회사의 태생이," 될만한 것은 전부 사와라"라는
주의입니다.

저희가 합병되고 1년후에 또하나의 회사가 합병되었습니다.

현재 한국에서 엄청나게 유행하고 있는 미니홈피를 주력으로 하는 회사였습니다.(c사라고 부르겠습니다.)

c사합병후 몇 개월이 지나면서,우연하게 그곳의 소스및 디비 구조를 보게 되었습니다.

초장기의 설계는 현재와 같은 폭팔적인 P/V,U/V를 감안하지 않은 설계였습니다.물론 현재는 구조를 대부분 바꾸어서,이전과는 많이 달라진 형태입니다.

c사에서 처음 장비를 인수할때는 ,펜티엄급 서버 30대 정도가 고작이였지만,현재는 델서버(그나마 제일 싼 장비)500대가 넘는 규모가 되었습니다.

본론>
개발자/설계자의 입장에서 볼때,C사의 설계는 결함이 많은 ,생산성을 논할 정도의 스펙을 갖고 있는 제품은 아니라고 보여집니다.

구현을 담당하고 있는 친구들도,제 바로 뒷자리에 앉아있는데,전부 병특입니다.대략 2,3년차가 않된 친구들이죠.

소스의 기술적인 완성도가 약간은 미진한 상품이 왜 이렇게 폭팔적인 인기및 매출을 갖오는것일까?라는 생각을 많이 하고 있었습니다.

그런던중,합병과 함께 병가를 내어 미국에서 계시던 C사 사장님이 복귀를 하셨습니다.물론 사장으로 복귀한것은 아니고,본부장님으로 복귀하셨지요.

이 분이 복귀하시면서 사람들을 모아놓고 말씀하시는것을 듣고 이해가 되기 시작했습니다.

C사의 미니홈피는 기획만 3년이 넘었고,현재도 완성도를 더하기 위해서 ,기획자들은 매일 열심입니다.그리고 작은회사의 특성상,개발자와 기획자는 상호 분리할 수 없는 가족과 같은 조직입니다.

결론>
제품은, 생산을 했을때 구매하는 소비자가 있어야 한다고 생각합니다.아무리 좋은 제품도 판매되지 않는다면,생산성을 이야기 할 수 없을것입니다.
(왜냐면 output이 없을테니까요)
소비자가 소비하고 싶은 욕구를 만들어내고,그 시대에 소비자들이 어떤 상품을 소비하고 싶어하는지를 정확하게 포착하는것이 중요하다고 생각합니다.

개발자의 생산성을 단독으로 분리해서 생각하는것은 좋지 않다고 생각합니다.
똑같이 영업의 생산성,기획의 생산성도 분리해서 생각하는것은 마찬가지로 좋은 개념이라고 생각하지 않습니다.

생산성의 맥락은 조직의 효율이라는 차원에서 너무 잔인한 개념으로 생각됩니다.이것은 어쩌면 공장시절의 개념을 현대에 여과없이 적용하려는 억지같은 생각도 들구요(output/input)

조직에서 쏟아부슨 Input을 제대로 된 방향으로 밀어 넣고 있느냐가 더 중요한 개념이라고 생각합니다.

매출 기여도라는것은 , 생산성처럼 output/input이라는 (나누기)개념으로 도출되지 않는다고 생각합니다.

서론에서 잠시 언급한 C사의 성공을 볼때,매출대비 개발리소스는 매우 미미할것으로 생각됩니다.그러나,기획과 개발이 혼연일체가 되어서 하나의 제품을 생산해내었고,그 제품이 시장에서 매우 큰 성공을 거두었을때,(기획+개발)로 output을 나누자는 그들의 모습을 보면서 ,(output/input)/dev라는 개념은

제가 쳐해 있는 현실에서는 약간은 적용하기 힘든 계산이라는 것입니다.

추가>
제가 경험한 업계에서 망하는 조직은 아래와 같을 것이라는 생각입니다.
1.output 자체가 적은 조직
(제품의 방향이 올바르지 않은 조직 or 기본적으로 매해 증가 해 주어야할 input이 없는 가난한 조직 )
2.(input/output)/dev !=(input/output)/영업 !=(input/output)/기획
(분열이 있는조직)

(몇달만에 잡답이 아닌 글을 올려봅니다.^^;)

.

이 말은 영업사원에게 해당하는 말로 알고 있습니다.물론, 모든 사원이 이런 마인드를 가지고 있다면 정말 대단한 기업이 되겠지만요.

그리고 제가 보기엔 프로그래밍도 제조업의 생산성과 큰 차이는 없다 봅니다. 윗분이 윈도우나 오라클의 예를 들으셨는데, 사실 제조업에서도 소비재의 경우 그런 일이 있기 힘들지만, 생산재의 경우엔 그러한 생산성 공식이 생길 수 있기 때문이죠. 사실상, 오에스나 데이터베이스 등은 소비재의 측면보다는 생산재의 특성을 가지고 있기 때문에 전체 경제 구조에서 생산성을 가지게 됩니다. 단, 프로그래밍은 제조업과 다른 것이 제조업은 계속적인 생산 활동이 필요로 하기 때문에 까다로운 품질관리가 필요하지만 프로그래밍의 경우 일단 한 제품의 생산이 완료되면 이를 복제하는 방식으로 생산되기 때문에 시제품 생산시 품질관리가 철저하다면 제품제조시 품질관리에 경비가 따로 들지 않는다는 면에서 제조업보다 효율적인 면이 있다 하겠습니다.

RisaPapa님의 글은 phpschool때부터 종종 보아왔는데, 개인적으로 참 존경받으실 만한 분인거 같습니다. 사실, 그나마 kldp에서 나이든 축(?)에 속하는 저하고도 거의 10년배되시는 분인데, 글을 보면 아직도 확고한 의지와 정열를 가지시고 일을 하시는 분 같습니다. 오히려 젊은분들 못지 않게 말이죠. 그런면에서 저는 참 창피한 놈입니다만..

SI업체의 생산성을 말씀하시는데.. 안타까운일입니다. 외주업체, 즉 갑과 을이라는 특성상 회사 입장에서는 생산성이 떨어질 수 밖에 없는 것이 SI업체라고 생각합니다. 모든 조건이 동일할 때 결국 갑에 있어 을을 선택하는 기준은 단가절감이기 때문이죠. 덕분에 출혈 경쟁을 하게 되고, 어떤 경우엔 오히래 마이너스가 되는 액수로 수주를 하기도 합니다. 이건 한국이나 일본이나 크게 다를 것이라 생각되지 않네요. 왜냐면 대부분 SI업체의 프로그래머는 젊은 층이고, 그러다보니 실제 기술적 차이에 있어 경쟁력의 차이가 크지 않기 때문이죠. 그리고 그 출혈 경쟁으로 인해 경험이 많은 프로그래머는 배제됩니다. 왜냐면 근속에 따른 임금이 기업주 입장에서 곤란해지기 때문이죠. 결국, SI의 출혈경쟁은 계속 악순환만 거듭하게 됩니다. 기술적 평준화 -> 생산비 절감요구 -> 출혈경쟁으로 인한 인원의 감축이나 근속자의 정리해고 -> 기술의 하향적 평준성 강화 -> 더욱더 가속화되는 출혈경쟁....이런식이죠.

제 생각엔 그 악순환의 고리를 끊는 것이 바로 Risapapa님과 같은 분들의 존재라고 생각합니다. 회사 경영이나 마케팅을 해보셨다는 분 앞에서 이런 글 쓰기가 머합니다만, 경영이나 마케팅은 단기적인 면만을 봐서는 안되기 때문입니다. 회사의 기술적인 중심에서 경력 많고 실력있는 프로그래머가 전체 기술팀 라인을 관리하고 있다는 것은 분명히 기술적인 평준화에서 이탈할 수 있는 일이기 때문입니다. 곧 그 기업은 기술적인 강점을 가지고 있다는 것이지요.

사실 한국도 일본도 최악의 불황을 경험하고 있는 이 시점에서 현재는 생산성에 있어 포장마차보다 떨어진다고 하더라도, 호황이 왔을 때 기술적인 차별성은 SI업체에겐 출혈경쟁에서 벗어 날 수 있는 중요한 포인트라고 생각합니다. 그때 과연 포장마차의 생산성이 그 회사의 생산성을 앞지를까요.

아, 참 정신없네요. 주저리 주저리...정리도 안되고..
하여간 Risapapa님도 그렇고 다른 분들도 그렇고, 경기침체로 인한 생산성 절감이 어떤 자괴감을 불러온다고 해서 너무 많은 고민하지들 마시고, 경기가 호전되었을 때 자신이 발생시킬 엄청난 생산성을 기대하시면서 열심히 실력을 쌓아나가면 좋지 않겠느냐..머 그런 예기였습니다.

Risapapa님, 그러니 힘내시고, 앞으로도 좋은 글들 부탁드리겠습니다. ;-)