프로그래밍의 생산성과 연봉
프로그래밍을 좋아하고 실버엔지니어 실버 프로그래머로의 장래도 생각할
정도로 프로그래머의 일을 계속하고 싶은 마음은 굴뚝 같습니다.
그러나 회사에 입사를 하고 700만에 정도의 연봉을 기준으로 생각을 하면
일본에서도 프로그래머로서 일을 할수가 없다는 결론에 도달을 하게 되어
글을 올려봅니다.
일본에서 700만엔 정도의 연봉이면 파견사원이 아닐 경우는 적어도
회사에 연봉 3배의 매출을 올려야만 회사가 유지를 하고 성장을 할 수가
있습니다.
그러나 프로그래밍으로 저는 1년에 2천만엔이상의 매출을 회사에 안겨줄
자신이 없습니다. 그러다보니 설계를 하고 사양서를 작성해서 하청업체에
일을 맏겨서 생산성을 올리는 일을 할 수밖에 없습니다.
사원 20명이상의 회사를 일본에서 경영한 경험도 있고 하다보니 현재에는
사원으로 일하면서 회사의 입장과 회사에서의 자신의 입장을 많이 생각하게
됩니다. 그리고 저의 전문은 경영학과 마케팅이었기 때문에 회사정책결정과
마케팅분야에도 입김이 어느정도 있어 자신의 전공을 살릴수도 있어 좋지만
하고싶은 프로그래밍은 이제 거의 손을 놓게 되어 점점 감각이 무뎌가고
있는 중입니다.
그러면서 나이를 먹어 가고 있구나 하는 것을 40가까이 되어가면서 이제서야
느끼고 있습니다. 그리고 다시 전 경험으로 일본에서 한 가게 앞의 테라스를
개조해서 포장마차를 시작도 하고 있습니다. 물론 회사의 사장도 알고 모두들
응원해주기 때문에 행운아라는 생각도 합니다. 제 자신은 아무것도 하지 않고
회사빌딩의 일층이기 때문에 문제가 있으면 바로 달려갈 수도 있고 해서 모두
아르바이트에게 맏기고 가계의 주인이 관리도 해주고 해서 아주 편하게 시작을
하게 되었습니다.
그러면서 회사원으로서의 SE와 포장마차 경영이라는 특이한 경험을 하고
있습니다. 그런데 포장마차의 한달 매출이 200만엔인데 시간을 생각하면
프로그래밍은 포장마차의 생산성에도 못미치고 그 프로그램으로 얼마만큼
다시 생산을 해내는가 하는 것을 금액으로 따지면 너무나 조촐하다는 생각이
들기도 합니다. 또 100만엔 정도하는 기계도 판매를 하고 있는데 이것과
SI분야를 비교를 하면 매출금액의 생산성면에서 프로그래밍의 생산성은
시골의 농사보다도 못하지 않은가 하는 생각을 하곤 합니다.
현재의 월급과 포장마차를 하고 기계를 팔고 남는 순이익을 비교하면 회사의
월급의 금액은 용돈 정도에 불과 하다는 생각이 들기도 합니다.
이러한 경험을 하면서 프로그래밍의 금액으로서의 생산성에 많은 의문을
가지게 됩니다.
저로서는 현제 일년 3000만엔 정도 매출을 올리고 있는데 이것이 저의
한 개인으로서의 생산성이라고 생각합니다. 하지만 회사의 순수이익을
따지면 이 매출에 대해서 200에서 300만엔 정도가 됩니다. 실직적으로는
이 금액이 한 프로그래머나 개인의 생산성의 평가 기준이라고 말을 하고
싶습니다만......,
특정한 소프트나 OS등을 제외하고 자신의 프로그래밍의 생산성은 얼마나
된다고 생각하십니까?
솔직히, 제자신과 주변을 볼때, 거의 0에 가까운 경우가 엄청나게 많다고
솔직히, 제자신과 주변을 볼때, 거의 0에 가까운 경우가 엄청나게 많다고 생각됩니다. 저라면, 포장마차하고 기계 파는 것을 주업으로 하고 실버프로그래머를 hobby로 하는 것이 어떨까하는 생각이 드는군요. 저도 뭐 지금 하고 있는 소위 말하는 research를 hobby로 하기 위한 주업을 하나 찾을까 하고 있읍니다.
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
고도화...
IT가 생산성이 낮다고 보진 않습니다.
오히려 지구상에 존재하는 그 어떤 것 보다 높은 생산성을 가지고 있다고 높니다.
생산의 고도화의 결정체로 봅니다.
문제는 그것이 너무 고도화되어 돈이 되기 어렵다는 것입니다.
거의 10년 전에 **공사의 노동조합에서
ERP 프로그램 도입을 반대한 적이 있습니다.
표면적인 이유야 작업장 감시, 인권 등을 내세웠지만
내부적인 이유는 직원의 1/4이 당장 떠나게 된다는 것이였습니다.
여전히 그 공사에서는 지금도 안쓰는 것으로 알고 있습니다.
어제 은행창구에 광과금 납부할려고 40분 기다렸는데
막상 창구에서 안받아 주더군요. 뒤에있는 자동납부기 사용하라고...
은행의 무인점포 이야기가 멀리 있는 것이 아니더군요.
지금은 고작 ERP와 자동단말기 정도입니다만 조금 시간이 지나면
인공지능화된 처리와 로봇들이 등장하면 더욱 달라지겠죠.
하루가 다르게 '러 다이어트'에 대하여 사람들이 논할 것으로 봅니다.
IT노동 해방을 부르는 도구이자 실업을 부르는 도구.
전 그렇게 봅니다.
공생의 지혜를 찾아야 할 시기가 다가 오는 것 같습니다.
조르바와 함께 춤을....
전 한국만의 현실이라고 생각했는데? 일본도 IT쪽은 벌이가 시원찮은가 보
전 한국만의 현실이라고 생각했는데? 일본도 IT쪽은 벌이가 시원찮은가 보네요?
능력있는 고액연봉자가 존재한다는 것은 업무량비 매출액이라는 단순 등식으로
능력있는 고액연봉자가 존재한다는 것은 업무량비 매출액이라는 단순 등식으로만 성립되는것이 아니라고 봅니다.
프로그래밍, 네트워크 등으로 7백만엔대 이상의 고액연봉자가 된 사람이라면 그 경력과 실력이 우수할 것입니다. 그 실력이 우수하다는 것은 단순히 저액연봉 코더가 5시간 걸릴걸 1시간에 끝낸다는 의미가 아니라 저액연봉자가 할수 없는 일을 그사람은 할수있다는 의미라고 생각합니다.
IT회사의 영업부에서 프로젝트를 수주하다보면 실제 그 프로젝트를 해낼만한 기술력이 자기업에 존재하는지, 그리고 그것을 단순히 입으로만 이야기하는게 아니라 발주처에 증명해야할 경우가 있습니다. 그럴경우 그런 우수한 기술자의 존재유무에 의해서 그 프로젝트를 수주할 수 있는가 없는가의 여부가 결정이 되고 그 기술자의 존재로 인해서 해당 프로잭트의 수주유무가 결정된다면 그것은 단순히 시간당 생산성으로 계산될수 있는 문제가 아닐것입니다. 그 고액기술자가 존재함으로 인해서 저액연봉자도 자기일을 받느냐 못받느냐가 결정되니까요.
(조금은 다른 이야기지만 이번에 저희회사에서 NTT코무야와 SE계약을 맺는데 기술시험을 봐서 자격을 입증해야 하더군요. 시험점수에 따라서 받을수 있는 금액도 달라진다는. ㅡㅡ; )
단순코딩 생산성이야기로 돌아와 보면 실력이 있는사람이 코딩하느냐 못하느냐에 따라 디버깅이 쉬워질수도 있고 어려워질수도 있습니다. 그리고 보통 파트별로 코딩시 버그 발생하면 담당자가 디버깅을 하게되는데 자기코드라 할지라도 실력에 따라 디버깅의 시간차이가 엄청나겟죠. 그걸 떠나서 실력자는 좀더 버그가 적고 유연한 코딩이 가능할 것입니다. 최초 사양인식과정에서 실력차가 드러나는 경우도 많고요. 즉 전체적인 엔터테이먼트의 입장에서 고액실력자가 훨씬 효율이 높다고 봅니다.
제가 알기로 일본에서 젊은 프로그래머들의 연봉은 300-400 사이로 알고 있습니다만(틀릴수도 있습니다. 젊다는 기준이..ㅡㅡ; ) 이런 프로그래머 2명보다 700만엔 받는 알짜배기 숙련프로그래머와 같이 팀을 짜고 프로그래밍을 하는게 훨씬 마음든든하고 공수도 단축시킬수 있을거라는 생각이 드는군요. 그게 곧 생산성 아닐까하는 생각을 합니다.
===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com
엔화에 5정도 곱하면 원화로 체감할 수 있는 건가요?제 생각엔 개
엔화에 5정도 곱하면 원화로 체감할 수 있는 건가요?
제 생각엔 개발자의 생산성을 곧바로 돈으로 환산하는데에는
무리가 있다고 봅니다. 왜냐면 한 회사의 매출은 개발자의 생산성만으로
결정되는 것이 아니기 때문입니다. 즉, 개발자가 아무리 우수한 생산성으로
개발을 해도, 그 제품이 팔리지 않으면 말짱 꽝이기 때문이죠. 위에서처럼
돈으로 환산한 생산성은 개발자 개인에 대한 생산성이 아니라, 홍보, 기획
영업, 개발 등이 복합적으로 고려된 회사의 생산성이라고 보여지는군요.
단적인 예로 거의 비슷한 개발 업무를 하는 두 회사에서 받을 수 있는 연봉이
크게 차이가 날 수 있는 경우를 들 수 있습니다. 즉, 돈으로 환산된 개발자의
생산성을 경영자가 생각한다면, 그것은 개발자의 생산성을 잘 못 이해하고
있는 경우이고, 개발자 입장에서는 개발 외의 짐까지 떠맡고 있는 셈이 되죠.
Orion Project : http://orionids.org
Dev생산성=(Output/input)/(dev)
서론>
저는 조그만 벤쳐회사를 다니다가,망할즈음에 사장님의 노력으로 대기업에 인수합병이 된 경우입니다.
현재 일하고 있는 회사는 회사의 태생이," 될만한 것은 전부 사와라"라는
주의입니다.
저희가 합병되고 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)/기획
(분열이 있는조직)
(몇달만에 잡답이 아닌 글을 올려봅니다.^^;)
In the UNIX,
화일 시스템은 지평적인 공간 감각을 제공하며 ,
프로세스는 생명을 갖는 생명체와 같아보인다.
--BACH
RisaPapa 님께서 말씀하신건 생산성이라기보다는 교환가치에 대한 고민
RisaPapa 님께서 말씀하신건 생산성이라기보다는 교환가치에 대한 고민이 아닌가요? 포장마차와 프로그래밍의 생산성이란것을 어떻게 비교하죠? 생산성 비교라는것은 단순히 돈을 얼마나 벌어다주느냐의 비교가 아니라 투입된 노동량 대비 산출된 제품의 양(혹은 정량화된 질적 우수성)을 대비시켜 계산하는것으로 알고 있는데요.
단일 분야의 품목에 대해서는 그런식으로 비교할 수 있죠. 예를들어 단위시간당 A제지 회사의 휴지생산량과 B제지 회사의 휴지생산량을 비교해서 생산성이 어느쪽이 높으냐 하는것은 따질수가 있을것입니다. 헌데 전혀 다른 품목의 경우는 이런 비교가 불가능한것 아닌가요? 말하자면 단위시간당 A제지 회사의 휴지생산량과 B 아이스크림 회사의 아이스크림 생산량을 비교한다는것 자체가 말이 안된다는 얘기죠. 그럴 경우는 단위시간당 산출해내는 교환가치(화폐로 변환되었을때의 가치)를 따져볼수는 있겠죠.
프로그래밍 분야의 생산성이라는것은 요새 각광을 받고 있는 PSP같은 기법들과 같은것에서 측정이 되고, 비교될 수 있는것이라 생각합니다만...
.
.
Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart
글쇠판: 세벌 최종식, 콜맥 (Colemak)
저는 게으른 공학자로서 한 마디 해보겠습니다.프로그래밍이라는 작업
저는 게으른 공학자로서 한 마디 해보겠습니다.
프로그래밍이라는 작업은 어찌보면 인간에게 힘든 반복적 작업과 대용량의 데이터를 처리하는 능력을 대신할 프로그램을 만드는 일입니다.
프로그래머도 인간이고, 인간을 통해 프로그램이 완성됩니다. 프로그래머의 창조력(이렇게 부르고 싶습니다.)만을 이용하여 프로그램을 만들 정도로 고도화된 도구가 요즘엔 많이 등장하였다고 보고 있습니다. (적어도 응용프로그램 레이어에선 말이죠.)
하지만, 아직도 프로그래머를 위한 프로그램은 그리 많이 나오지 않은것 같습니다. 물론 생산성 증대를 위해 협업하는 체계를 갖추고 리포트와 버전 관리를 통해 프로그램 개발을 더욱 수월하게 했다고는 하지만, 사람 스스로가 프로그래밍을 더욱 수월하게 하기는 어렵다고 생각합니다.
프로그래밍을 위한 프로그램으로 더욱 소스 작성을 쉽게, 그리고 더욱 편하게 만드려고 노력한다면, 프로그램 제작에 대한 Load 가 더욱 줄어들지 않을까 생각해봅니다. (물론 그것때문에 여러가지 프로그래밍 언어가 생겨나고 더욱 고 레벨의 언어가 생성되지만, 그래도 그것만으론... -_-a)
[quote]회사에 연봉 3배의 매출을 올려야만 회사가 유지를 하고 성장
이 말은 영업사원에게 해당하는 말로 알고 있습니다.물론, 모든 사원이 이런 마인드를 가지고 있다면 정말 대단한 기업이 되겠지만요.
그리고 제가 보기엔 프로그래밍도 제조업의 생산성과 큰 차이는 없다 봅니다. 윗분이 윈도우나 오라클의 예를 들으셨는데, 사실 제조업에서도 소비재의 경우 그런 일이 있기 힘들지만, 생산재의 경우엔 그러한 생산성 공식이 생길 수 있기 때문이죠. 사실상, 오에스나 데이터베이스 등은 소비재의 측면보다는 생산재의 특성을 가지고 있기 때문에 전체 경제 구조에서 생산성을 가지게 됩니다. 단, 프로그래밍은 제조업과 다른 것이 제조업은 계속적인 생산 활동이 필요로 하기 때문에 까다로운 품질관리가 필요하지만 프로그래밍의 경우 일단 한 제품의 생산이 완료되면 이를 복제하는 방식으로 생산되기 때문에 시제품 생산시 품질관리가 철저하다면 제품제조시 품질관리에 경비가 따로 들지 않는다는 면에서 제조업보다 효율적인 면이 있다 하겠습니다.
RisaPapa님의 글은 phpschool때부터 종종 보아왔는데, 개인적으로 참 존경받으실 만한 분인거 같습니다. 사실, 그나마 kldp에서 나이든 축(?)에 속하는 저하고도 거의 10년배되시는 분인데, 글을 보면 아직도 확고한 의지와 정열를 가지시고 일을 하시는 분 같습니다. 오히려 젊은분들 못지 않게 말이죠. 그런면에서 저는 참 창피한 놈입니다만..
SI업체의 생산성을 말씀하시는데.. 안타까운일입니다. 외주업체, 즉 갑과 을이라는 특성상 회사 입장에서는 생산성이 떨어질 수 밖에 없는 것이 SI업체라고 생각합니다. 모든 조건이 동일할 때 결국 갑에 있어 을을 선택하는 기준은 단가절감이기 때문이죠. 덕분에 출혈 경쟁을 하게 되고, 어떤 경우엔 오히래 마이너스가 되는 액수로 수주를 하기도 합니다. 이건 한국이나 일본이나 크게 다를 것이라 생각되지 않네요. 왜냐면 대부분 SI업체의 프로그래머는 젊은 층이고, 그러다보니 실제 기술적 차이에 있어 경쟁력의 차이가 크지 않기 때문이죠. 그리고 그 출혈 경쟁으로 인해 경험이 많은 프로그래머는 배제됩니다. 왜냐면 근속에 따른 임금이 기업주 입장에서 곤란해지기 때문이죠. 결국, SI의 출혈경쟁은 계속 악순환만 거듭하게 됩니다. 기술적 평준화 -> 생산비 절감요구 -> 출혈경쟁으로 인한 인원의 감축이나 근속자의 정리해고 -> 기술의 하향적 평준성 강화 -> 더욱더 가속화되는 출혈경쟁....이런식이죠.
제 생각엔 그 악순환의 고리를 끊는 것이 바로 Risapapa님과 같은 분들의 존재라고 생각합니다. 회사 경영이나 마케팅을 해보셨다는 분 앞에서 이런 글 쓰기가 머합니다만, 경영이나 마케팅은 단기적인 면만을 봐서는 안되기 때문입니다. 회사의 기술적인 중심에서 경력 많고 실력있는 프로그래머가 전체 기술팀 라인을 관리하고 있다는 것은 분명히 기술적인 평준화에서 이탈할 수 있는 일이기 때문입니다. 곧 그 기업은 기술적인 강점을 가지고 있다는 것이지요.
사실 한국도 일본도 최악의 불황을 경험하고 있는 이 시점에서 현재는 생산성에 있어 포장마차보다 떨어진다고 하더라도, 호황이 왔을 때 기술적인 차별성은 SI업체에겐 출혈경쟁에서 벗어 날 수 있는 중요한 포인트라고 생각합니다. 그때 과연 포장마차의 생산성이 그 회사의 생산성을 앞지를까요.
아, 참 정신없네요. 주저리 주저리...정리도 안되고..
하여간 Risapapa님도 그렇고 다른 분들도 그렇고, 경기침체로 인한 생산성 절감이 어떤 자괴감을 불러온다고 해서 너무 많은 고민하지들 마시고, 경기가 호전되었을 때 자신이 발생시킬 엄청난 생산성을 기대하시면서 열심히 실력을 쌓아나가면 좋지 않겠느냐..머 그런 예기였습니다.
Risapapa님, 그러니 힘내시고, 앞으로도 좋은 글들 부탁드리겠습니다. ;-)
힘없는자의 슬픔
딴지거는건 아닌데 생산성이란 단어를 모호한 기준으로 사용하는것 같아서 혼
딴지거는건 아닌데 생산성이란 단어를 모호한 기준으로 사용하는것 같아서 혼란스럽습니다. 제가 애초에 프로그래밍 분야에서 생각했던 생산성이라는것은 단위시간당 코딩량이나 LOC당 결함비율(PSP에서 정의하고 있는대로)과 같이 소프트웨어 개발 공정이 결부되는 개념이었는데 이 글타래에서는 전혀 다르게 생산성을 정의하고 있는것 같다는거죠.
지금 얘기되고 있는 분위기로는 process보다는 완성된 product가 얼마만큼의 유용성 혹은 퍼포먼스를 내느냐 하는것으로 생산성을 따지고 계신것 같다고 보입니다. 크게보면 완성된 소프트웨어 조차도 인간이 어떤 유목적성을 가지고 사용한다는 측면에서 그것 역시 하나의 과정이라고 생각할수도 있겠지만, 그럴때는 프로그래밍의 생산성이 아니고 소프트웨어의 생산성이라고 해야하는것이 맞는게 아닐까 생각합니다. 이 두가지가 함께 구분없이 얘기되고 있는것 같아서 매우 혼란스럽군요. :roll:
[quote="NeoTuring"]이 두가지가 함께 구분없이 얘기되고 있
이 글타래에서는 프로그래밍을 "순수한 코딩" 만이 아닌, "소프트웨어를 만들어내는 과정"이라는 뜻으로 사용한 것 같습니다. 노동자가 작업을 잘 한다고 하더라도 경영하는 사람들이 말아먹는 회사에 다닌다면 생산성이 낮다고 보는 것이지요.
----
It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]