당신의 연봉은 얼마인가요?

thames의 이미지

경제수업 몇 들었던 생각으로는 수요와 공급에 따라 생겨나는 곡선의 교점이 연봉이 되어야 맞겠지만서도

그 곡선이 생기려면 무수한 점이 필요하듯 가격대가 얼마에 형성되고 있나를 알고 있어야 하는데

주변에 이쪽 계통에서 일하는 사람이 별로 없어서

"누가 좀 프로그램 만들어주세요."

"프로그램 만들어주겠다"

"얼마에 만들어줄래?"

"... 얼마까지 줄 수 있는데요?"

"... 넌 을이니까능 일단 만들어봐-"

식의 대화가 계속 되고 있어서 말입니다. 물론 제가 원하는 만큼 부르는 것도 맞긴 하지만

내 노동력의 가격을 측정하는 노하우라든가, 척도가 있으신지.. 이런게 궁금합니다.

드래곤볼의 스카우터처럼 측정이 되면 참 간편할텐데요. 노동력 1당 100원 이렇게 쉽게 치환되면 좋겠지만;;

많이 부딫혀 봐야만 아는 부분이긴 하겠지만서도... 답답해서요.

프로그래머의 임금, 연봉에 관한 노하우.. 부탁드립니다!

semmal의 이미지

회사에 1억원 벌어다 주면 자신의 연봉은 3000만원정도로 보면 됩니다.

가령 연봉 3천만원짜리 직원 한 명이 2천만원짜리 프로젝트를 한다면, 2개월반 정도의 시간만 투자해서 작업을 완료할 수 있어야 합니다. (장비나 소프트웨어 가격이 들어간다면 더 이전에.)

일한 것보다 더 많이 받을 수 있으면 좋은 회사고, 덜 받는다면 힘든 회사겠지요.

반대로 더 벌어다 주면 좋은 직원이고, 덜 벌어다 주면 곤란한 직원이겠지요.

회사에 따라 다르기는 한데 보통은 연봉x3 정도는 해야 인정받을 겁니다.

------------------------------
How many legs does a dog have?

퀘이크의 이미지

벌어들이는 돈이 그만큼 적다는 말이군요. 미국은 소프트웨어공학자가 직업 1위던데, 한국은 왜 이러나요? 연봉에 관한 글을 계속 봤더니 의욕이 떨어지네 ㅎㅎ

leafriend의 이미지

소프트웨어 공학자와 프로그래머가 약간 다른 개념이기 때문일 것 같습니다. 여기서 제가 사용한 프로그래머란 단어는 보통 주변에서 볼 수 있는 프로그램을 작성하는 모두를 가리키는 말이고, 소프트웨어 공학자란 말 그대로 소프트웨어 공학을 연구하고 적용하기 위해 고민하는 이를 가리키는 말입니다.

그럼 프로그래밍과 소프트웨어 공학(SE)의 차이가 뭐냐라고 하시면 저도 명쾌한 답을 드리기는 어렵네요. ^^; 저도 SE는 학부 때 교양(?)으로 들은 게 다라서 말예요. 그래도 짧은 식견으로 말씀을 드리자면, 프로그래밍은 정해진 환경(언어, 방법론, 개발 도구 등)에서 주어진 목표(작동하는 프로그램)을 이루기 위한 작업이라면, 소프트웨어 공학은 그 환경을 어떻게 더 효율적으로 만들 것인가에 관한 학문이죠. 그럭저럭 갖다 붙이자면, 프로그래밍은 operational activity고 소프트웨어 공학은 strategic activity입니다(영어 단어의 적당한 번역이 생각나질 않네요;).

물론 직업의 귀천은 없으나, 소프트웨어 공학자가 아무래도 더 수가 적고 다루는 영역이 추상적이다 보니 미국에서는 소프트웨어 공학자가 전도유망한 직업으로 인식이 되는 것이겠죠. 그리고 우리나라는 제 경험상 소프트웨어 공학에 대해 고민하는 개발자가 그다지 많지 않다보니 기업에서도 그 중요성을 잘 인식하지 못하는 것 같아 안타깝네요.

hb_kim의 이미지

외람되지만 Software Engineer 는 Software Engineering 을 하는 사람이 아닙니다.

Software Engineer 는 소프트웨어를 가지고 문제를 해결할 수 있는 사람을 말합니다.

leafriend의 이미지

제가 짧은 지식으로 글을 쓰다보니 그런 오류를 저질렀군요. ^^;

말씀하신대로 소프트웨어 엔지니어가 반드시 소프트웨어 공학을 한다고 보긴 어렵겠네요. 시간이 되실 때 좀 더 자세하게 말씀해주시면 도움이 될 것 같습니다. :)

hb_kim의 이미지

제가 소프트웨어 엔지니어의 사전적인 정의에 대해 잘 이해하고 있어서 답글을 단것은 아닙니다. 다만 소프트웨어/펌웨어 엔지니어라는 타이틀을 달고 현장에 꽤 오래 있었으니 제가 이해하고 있는 것이 대강 업계에서 뜻하는 것과 크게 다르지 않다고 생각해서 리플을 답니다.

다만 보통 회사에서 소프트웨어 엔지니어를 뽑는다 할때 자격 요건과 요건에 명시되지 않은 묵시적 사항을 보면, 해당 프로그래밍 언어를 사용할 수 있는것은 물론 기본 사항이고, 주어진 문제를 해결하기 위한 모든 과정을 주위의 큰 도움 없이 수행할 수 있는 사람을 구하려 합니다. 스펙을 읽고 이해할 수 있는 능력, 다른 사람과 의사소통을 할수 있는 능력, 목적에 맞추어 소프트웨어의 골격을 잡고, 모듈을 나누고, 기능을 구현하고, 문제가 생기면 다양한 방법으로 디버깅할 수 있는 능력 등등 입니다. 좀 젊잖게 표현해서 이 정도지, 실제로 하다보면 온갖 잡일이 엄청나게 많이 생깁니다. 제품에 문제가 생기면 빠져나갈 구석이 없고 무한대의 책임을 집니다. 그러니까 흔히 코드 짜시는 분들 대부분이 소프트웨어 엔지니어라고 보면 맞습니다.

프로그래머라고 하면 이미 소프트웨어의 골격이 잘 정해져 있고, 모듈이 나누어져 있고, 기능이 잘 정의되어 있을때, 그 정해진 기능을 구현하는 것을 책임으로 하는 경우 프로그래머라고 칭하는 경우가 많습니다. 예로 코볼 프로그래머가 직함일 경우 어느 정도 소프트웨어의 윤곽이 잡혀진 상태에서 코볼을 사용해서 기능을 구현하는 역할을 맡습니다. 이말이 암시하는것은 소프트웨어의 골격을 잡고 기능을 정의하는 역할에는 다른 직함이 주어진다는거죠. 이를테면 COBOL analyst 같은 직함 말입니다. 또 다른 예로는 커널/드라이버 엔지니어라고 하지 않고 커널/드라이버 프로그래머라고 보통 말합니다. 커널/드라이버에 들어가는 소프트웨어는 대부분 입력과 출력, 기능 등이 이미 꽤나 잘 정의되어 있기 때문에 소프트웨어의 설계측면보다는, 언어를 써서 기능을 구현하는 것이 주가 되는 경우가 많기 때문입니다. 제품에 문제가 생기면 아무래도 본인이 구현한 기능에만 책임이 국한되는 경우가 많겠죠.

parkssie의 이미지

충격적인 예시이군요. (공감합니다)

Software Developer

오리가날지못해우물에빠진날의 이미지

연봉은 '얼마를 벌어왔느냐?'보단
'어떤 회사에 있느냐'가 중요하기때문에
지금 하시는 일에 단순 적용하기는 무리일것 같네요.

개발해야 하는 프로그램이 어떤것인지를 공개해서 금액관련 정보를 얻으시거나
공개가 힘들다면 비슷한 일을 하시는 분을 섭회하시는게 좋을것 같네요.

hb_kim의 이미지

하이젠베르그의 불확정성 원리를 아십니까?

개발자로써 자신의 가치를 아는것은 하이젠베르그의 불확정성 원리와 마찬가지로 거의 불가능합니다. 왜냐하면 자신의 정확한 가치를 알기 위해서는 극한 상황까지 고용주를 압박해야 하기 때문입니다. 이 상황에서 고용주가 어떻게 행동 할지 예측하는것은 고속의 전자에 맞은 중성자가 어디로 튈지 예측하는것과 마찬가지로 어렵습니다.(엉뚱한 비유라면 죄송합니다)

고용주의 100이면 100다 직원이 불만을 표시하고 엄청난 압박을 하지 않으면 면피 수준의 임금을 주려 합니다. 물론 예외도 있습니다만 거의 대부분 그렇다는 이야기입니다.

자신의 가치를 가장 확실하게 알수 있는 방법은 자신을 대체하기 위해 얼만큼의 비용이 들어갈지를 짐작하는 것입니다. 어떻게 짐작할까요? 현재보다 월등히 나은 대우를 받고 다른 고용주에게 옮기려 하고 있다는 의사를 알려주면, 고용주가 자신을 붙잡기 위해 협상 테이블에 내어 놓는 패가 대략 이 비용에 꽤 근접한 수치입니다.

hb_kim의 이미지

이것은 semmal 님의 글을 보고 쓰는 저의 궤변입니다.

저는 직원이 기여하는 이득의 1/3 이상을 보상으로 주는 회사를 좋은 회사라고 생각하지 않습니다. 진짜로 좋은 회사는 직원이 회사에 기여하는 이득이 너무나도 크기 때문에, 그 이득의 극히 일부만을 보상으로 주더라도 직원이 경제적으로 크게 불편하지 않고, 불만없이 다닐수 있는 회사라고 봅니다. 자신의 능력을 최대한으로 쥐어 짤수 있는 그런 회사 말입니다.

일할곳을 고르실 때면, 꼭 제가 한 말씀을 기억하시면 좋겠습니다. 이 회사에서 이 일을 맡아서 하면 과연 얼마나 많은 보상을 받을수 있을지를 생각하는것 보다, 이 일을 함으로써 과연 회사와 사회에 얼마나 큰 가치를 창출할수 있을지를 생각하는것이 앞서야 합니다. 또 이 일을 하면서 얼마나 재미있고 즐거울지, 얼마나 자아성취를 할 수 있을지, 얼마나 많은것을 배울수 있을지를 먼저 생각하시기 바랍니다.

재미있고 즐거운 일을 하면서 큰 가치를 창출하는 곳에서 일을 하면, 그밖의 자잘한 보상은 저절로 따라가기 마련입니다.

semmal의 이미지

"재미있고 즐거운 일을 하면서 큰 가치를 창출하는 곳"

그런 곳이 있다면 추천 부탁드립니다.

근 10년 이상을 찾아 해매도 그런 곳을 못찾겠더군요.

밝히기 곤란한 곳이라면 제 아이디 쪽지로 연락 부탁드립니다.

그런데 제가 무엇을 재밌어하는지 밝히지 않았으니 큰 의미는 없겠군요.

다시 제 글을 읽어보니 마치 비꼬는 말 같은데 비꼬려고 적은 건 결코 아닙니다.

------------------------------
How many legs does a dog have?

hb_kim의 이미지

저는 사실 재미있고 즐거운 일이 없는 회사를 다녀본적이 없습니다. 어느 회사를 가던지, 꼭 도전할 만한 가치가 있는 일거리가 있습니다. 아래는 그 회사들중에서 한 예입니다.

3PAR 라는 회사가 있었읍니다. 제가 들어갈때만 해도 첫 제품을 출시하지 못한 스타트업 회사였습니다. 캐리어 클래스 클러스터 엔터프라이즈 스토리지를 만들어서 EMC 나 히타치 데이터 시스템과 경쟁하겠다는 포부를 가지고 있는 회사였습니다. 시스템은 8 way 클러스터에 SMP 노드가 붙어있고, 최대 2000개 가량의 Fibre Channel 디스크를 붙일수 있는 SAN 스토리지 시스템이었습니다.

이런것을 흔히 만들어 보신분이야 별 큰 흥미가 없겠지만, 제가 입사할때만 해도 이런 대형 시스템을 개발한 경험이 없는 저로서는 새로운것 투성이였습니다. 저는 Fibre Channel 디바이스 드라이버를 만드는 커널 프로그래머 업무에 지원했었습니다. 커널 프로그래머는 시스템을 완전히 파괴할수 있는 버그를 만들수 있기 때문에 개인마다 시스템이 주어졌습니다. GUI 등을 하시는 분들은 시스템을 공유해서 쓰고 있었죠. 이 시스템과 이 시스템에 로드를 걸수 있는 각종 서버가 가득찬 실험실에서는 매달 전기료만으로 2만불을 사용했습니다. 왜인지는 모릅니다. 하지만 남자는 굉장히 큰 시스템, 무거운 장비, 겁나게 빠른 컴퓨터, 고속으로 코너를 돌수 있는 스포츠카에 본능적으로 끌리게 되어 있습니다.

또 이 회사의 모토는 "유틸리티 스토리지" 로서 그때 당시에는 비교적 새로운 개념의 판매 철학 이었습니다. 보통 스토리지 업체들이 관리나 확장시의 편의점등을 내세워 스토리지 시스템을 팔면서 대량의 디스크를 같이 구매하도록 유도함으로서 업체의 이익을 최대화하는것이 관행이었습니다. 그런데 아시다시피 하드 디스크의 용량은 매년 급속도로 증가하고, 가격은 떨어지기 때문에 나중에 채워갈 용량을 단지 확장이 불편하다는 이유로 모든 디스크를 미리 구입하는것은 전력소모와 초기 투자 비용면에서 고객에게는 큰 손실이 됩니다. "유틸리티 스토리지"에 사용되었던 thin provisioning 기술은 고객이 모든 논리 볼륨을 원하는 크기로 미리 잡아 놓을수 있으면서도 디스크는 실제로 데이터를 채운 양에 맞춰서 단계적으로 구입할 수 있는 방법을 제공하게 되었습니다.

이 회사에서 일하면서 High Availability 구현이나 클러스터 프로그래밍 같은 막연히 들어서만 알고 있던 것들을 배워가면서 직접 해볼수 있었으며, 제가 만든 디바이스 드라이버가 완성되자 전체 시스템의 성능이 2배 가량 향상되면서 그때 당시 EMC, HDS 의 시스템을 제치고 엔터프라이즈 스토리지 시스템중 최고 성능을 갖는 시스템이자 SPC1 기록갱신자로 인증되었습니다. 또한 이전에 사용하던 HBA 와 디바이스 드라이버의 조합에 비해서 큰 신뢰성 향상이 있어서 시스템의 안정성도 많이 좋아졌다는 평가를 들었습니다.

1년 반 정도을 다니면서 제가 한일이 과연 이 회사에 얼마나 큰 가치를 창출했는지 저는 구체적으로 액수를 산출할 수는 없습니다. 하지만 제가 받은 모든 금전적 보상에 비해 단지 3배 정도의 가치를 창출하는데 그치지 않았다는것은 확신할수 있습니다.

* 지금은 3PAR 는 HP 에 인수되었습니다.