'경력관리'에 해당되는 글 4건

허니몬에 관한 보고서/허니몬의 직장일기

2012년 12월, '일이 재미없습니다.' 이야기 하고 백수가 된지 

근 3개월만에 마음에 드는 좋은 회사에 좋은 기회로 입사하게 되었다.

2013년 03월 11일부터 Software In Life(http://www.softwareinlife.com/w/)에 합류한다.



2012년 12월에는 제대로 놀았다. ㅡ0-)>

2012/12/30 - [허니몬의 취미생활/스쿠버다이버!] - 20121220~20121226, Sabang Beach, Philiphine 다이빙 투어 기록

조금 거하게 돈을 투자해서 따스한 남쪽나라 필리핀에서 크리스마스 연휴를 보내고 왔다.


1월달부터는 구직활동을 시작.

2013/01/09 - [허니몬에 관한 보고서/허니몬의 직장일기] - 2013년 1월의 단상 - 입사지원 우수수 탈락!

내가 평소에 가고 싶었했던 회사에 지원해보기도 했고,

지인들이 많이 들어간 회사에 지원해보기도 하고

블로그에 적지는 않았는데 약간은 불쾌했던 면접도 경험(위의 글로 인한 부정적 효과?)해봤고,

탈락의 쓴잔을 연거푸 마시고 취해서 빌빌거리기도 했다.

그래도 스터디를 함께하던 분들의 격려에 힘입어 제정신을 차리고 일어섰다.



새삼 경력관리에 대한 경각심을 느낀 해이기도 하다.

'프로그래머로 산다는 것'에서 '사람 그리고 프로그래머' 유석문님이 

700명의 개발자에게 공유했다고 하는 경력관리에 대한 이야기를 다시 찬찬히 읽어본다.


프로그래머로 산다는 것

저자
유석문 지음
출판사
로드북 | 2012-09-26 출간
카테고리
컴퓨터/IT
책소개
-
가격비교 글쓴이 평점  


난 안주하고 '나는 어디에든 들어갈 수 있어.'라고 자만하고 있었다.

안주하고 자만해서는 안된다.

새로운 일

새로운 사람들

새로운 환경

새로운 목표

항상 시작은 기대와 두려움을 가지게 된다. 

빠른 듯 느리게 차근차근 하나하나 계단을 밟으면서 적응하려고 한다.


조금 더 활발하게

조금 더 상세하게

조금 더 치열하게

일해야지.

허니몬에 관한 보고서/허니몬의 직장일기

타산지석, ‘남의 산에 돌을 가지고 내 옥을 갈아보련다.’


  나는 최근 프로젝트 하나를 끝마쳤다. 국내에서 상위를 차지하는 큰 기업과 중소기업들이 컨소시엄 형태를 이루어 유지보수사업을 진행하고 있는 곳이었다. 이미 10년 전부터 개발이 진행되고 2~3년 전에 전체적인 개발이 끝나고 안정화되면서 유지보수 사업으로 전환한 곳이기도 했다.

  180여 명의 사람들이 모여서 운영대는 대규모 프로젝트였기 때문일까? 내가 기대하고 알고 있던 것에 비해 더 많은 관리와 통제를 요구하고 있고, 이를 위해 불필요하다고(내가 느끼기에는, 그러나 ‘갑’은 정기적으로 ‘형식’적이고 벅찬) 여기는 보고와 보고서를 만들어 제출하도록 요청하고 있었다.


공공 프로젝트 역시 상황이 다르지는 않다. 발주자()와 수주자()가 뚜렷하게 구분되는 공공업무 특성상 발주자는 더 많은 야으이 프로젝트 감도고가 통제를 위한 정보를 수주자에게 요청한다. 특히, 개발 부분에 이해와 전문성이 부족한 발주자일수록 더 많은 감독과 통조에 의존하는 경향이 많다. 이러한 활동을 통해 얻어진 상세한 프로젝트 현황과 다양한 지표는 그 당시에는 안도의 한숨을 쉴 수 있겠지만 그것으로 인해 오히려 개발자는 품질 확보에 필요한 절대적인 시간을 하나씩 포기할 수 밖에 없음을 알아야 할 필요가 있다.

프로세스는 프로젝트 관리자(발주자 또는 고객)에게 봉사하는 감시와 통제의 프로세스가 되면 바람직하지 않다. 개발자에게 관리 문서의 부담을 줄여줘야 하고 개발자가 개바로가 품질확보에 전념할 수 있는 개발자 중심의 프로세스로 바뀌어야 한다.

마이크로스프트웨어 20111월호 122p, 개발 프로세스 협업도구의 필요성 중



내가 경험한 질색의 상황이라고 할까?

  일정기간 마다 전화를 받고 처리한 처리율에 대한 평가(보고서 및 시스템에 기록)를 기록해야 하고, 매주, 매달말이면 정기적인 보고서(형식적인)를 작성하느라, 일정 시간의 노력을 정기적으로 할당해야 하는 반복적인 작업을 진행해야 했다. 거기에 ‘갑’에 감사라도 나올라치면, ‘감사’에 필요할지도 모를 산출물(문서, 각종 정의서, 설계서 등)을 출력하느라 쓸데없이 종이를 동시다발적으로 낭비하는 상황이 찾아왔다. 그것은 국내 SI 대기업이 자신들의 프로세스로 관리한다고 해도(아니 오히려 그들의 프로세스에 맞추어 관리되기 때문에 산출물이 더 많아진 것은 아닐까란 생각을 하는 때도 있었다. 그들의 프로세스는 자신들의 방식보다는 ‘고객’의 입장에 맞추어져 돌아가는 ‘고객 중심’이라고 보여졌으니 말이다), 이런 비효율적인 반복은 계속 될 수밖에 없었다.

개발 현실과 괴리가 있는 추상화 수준이 높은 개발 프로세스

개발 프로세스는 조직, 프로젝트 팀원의 개발 현황이 구체적인 절차와 방법으로 표현되어 개발자에게 전달되도록 작성되어야 한다. 그렇다면 현재 내가 속한 회사의 프로세스가 구체적으로 작성되었는지 어떻게 알 수 있을까? 생각보다 매우 간단하다. 여러분이 속해 있는 조직의 개발 영역 프로세스 문서에서 회사 로고를 제외하고 봤을 때 어느 조직에도 가져다 쓸 수 있는 프로세스라면 그것은 구체적이지 않은 프로세스라고 판단할 수 있다.

마이크로소프트웨어 20111월호 122p, 개발 프로세스 협업도구의 필요성 중


큰 프로젝트일수록 ‘방법론’과 ‘프로세스’가 필요하다는 것은 인정한다.

그러나 그것이 개발자에게 강요되는 것은 인정할 수 없다. 인정하기 싫다!!



내가 ‘회사’를 떠나기로 한 이유는 그 ‘프로세스’를 관리하는 관리자(팀장)와의 부조화 때문이었다.

근무지에 ‘불미스런’ 일이 있은 후에 ‘문책’의 인사가 진행되었고, 그로 인해 생긴 ‘공백’을 메꾸기 위해 다른 곳에서 근무하고 있던 ‘외부’ 관리자를 영입을 한 것이다. ‘인력풀’이 풍부한 대기업이라고 하더라도, 요즘처럼 ‘인력난’에 시달리는 곳이고, ‘안정화’가 된 곳이다보니 능력을 가진 인물이 배치되지는 않았다.

흔한 말로 ‘사람 좋은’ 관리자가 배치되었다. 그리고 개발에 필요한 ‘인력’을 충원하기 시작했다. 나름 ‘개발’ 프로젝트 였지만, ‘예산 소비성’ 선심 프로젝트의 성격이 강한 프로젝트이다보니, 제대로 된 프로세스가 확립되지 않았다. 레거시 시스템(기존에 유지 사용되던 애플리케이션)에 대한 정확한 분석과 개발 과정에 대한 예측이 없었다. 발주자와 수주자의 경험에 입각한 대략적인 일정과 비용 산출만 있었을 뿐이다. 이런 경험에서 비롯된 프로젝트의 진행은 ‘프로젝트’가 진행되면서 생기는 각종 ‘변수’들에 대한 고려가 없었다.

  • 프로젝트 초기 인원의 변동

  • 기존 시스템(레거시 시스템)이 가지고 있던 문제

  • 새로운 시스템에 적용하면서 고려되어야 할 문제

    • 하드웨어 구성

    • 소프트웨어 구성

    • 기존에 사용하던 공통 모듈을 이식하면서 발생할 문제들

    • 인력과 관련된 문제(개발 본수에 비해 부족하게 배치된 인력, 병결, 결원)

    • 무리한 일정으로 인한 의욕 감퇴(이게 내게는 제일 힘들었다)


등등의 문제가 있어서 힘들었다. 다른 이들은 더욱 힘든 상황에서 고생 하고 있는 것도 안다. 조금은 복에 겨운 소리를 하고 있는지도 안다. 하지만, 그런 불만도 상대적인지라 자기 중심적으로 평가를 하는 것이 당연하지 않은가?


이런저런 이유와 핑계를 두고 회사를 그만뒀다. 프로젝트는 이후가 더 힘들고 중요한 일들이 남아있음에도 도망치는 모습으로(주변에서는 오히려 부러움을 샀지만... 나를 부러워한다는 것도 또한 이 프로젝트가 얼마나 구성원들에게 불만을 품도록 만들었는지 반증하는 것이리라) 프로젝트를 빠져 나왔다.


사람들이 나를 부러워했던 이유는,

‘프로젝트’ 관리를 맡은 ‘관리자’와 더이상 대면하지 않아도 된다는 것이었다.


  내가 참여한 2차 프로젝트에 새로이 ‘배치’된 ‘관리자’는 ‘개발’과 관련된 관리 경험이 전혀없는 사람이었다. 어쩌면, 이전 근무지에서 ‘문책’성 인사발령으로 이 곳에 왔을지도 모른다. 그런 생각은 프로젝트가 진행되고 ‘예상 밖의 일들이 발생하면서 이에 대한 관리하는 모습’을 보면서 더욱 짙어졌다.


나중에 기회가 된다면, ‘관리자’에 대한 이야기를 해보도록 하겠다

내가 본 '나쁜 관리자'의 한 유형에 대해서 성토하고, 나라면 이런 '관리자'가 되겠다는 이야기를 하겠지. 하지만, 난 관리자가 될 생각은 없다. 내가 되려는 '아키텍트'가 되려면 관리도 해야하려나... 


어쨌든 자신이 나온 곳의 이야기를 길게 해봐야 좋을 것은 없으니까... 오늘은 여기까지 꺼낸 것도 나중에 내게 큰 흠이 될 것이다. 그래도 누군가가 해줬으면 하는 이야기를 해줄 필요도 있지 않은가? 나는 ‘좋은’ 사람도 아니거나와 ‘좋은’ 블로거도 아니다. 꽤나 까칠한 ‘성격’을 가진 30대 나이에 ‘10대 후반의 정신연령’을 가진 ‘아키텍트’를 꿈꾸는 개발자일 뿐이다.


1년을 근무하면서, 그 곳에서는 경험하기 어려운 경험들을 할 수 있었다. 그것들을 잊지 않도록 정리하는 시간을 가져보려고 한다. ‘타산지석’, ‘반면교사’ 뭐 어려운 말들을 써보려 하지만, 내가 그 말들을 제대로 이해하지 못하니까 그냥 그때를 회상하며 투덜거리는 글이다.


개발자로서 일이 즐거워지는 것은,

  • 자신이 무엇인가를 만들어 내고 있다는 창조에 대한 즐거움

  • 프로젝트 구성원으로서 다른 개발자들과 협업하고 있다는 것

  • 월급이 들어온다는 것(!!! 돈이 있어야 다른 취미도 가지지!!)

  • 새로운 것을 배워간다는 것

이 아닐까?


이런 즐거움들이 사라지니 일하기 정말 싫더라. ...

이번 경험은 내게 또다른 ‘진로 선택’의 기준이 되었다. 재미없는 일은 아무리 내 자신에게 ‘최면’을 걸면서 일을 해도 ‘재미가 없다’. 하면서 ‘즐겁고’ ‘재미나고’ ‘유익한’ 일을 찾아서 떠나는 것을 멈추지 않을 생각이다. 물론 이런 행동은 ‘경력관리’에는 조금 위배될 수도 있다. 하지만 ‘경력관리’는 결국 나를 위해서 하는 것이다.


어떤 선택에서도 우선시 되는 것은 ‘나’니까....


생각나는 대로 글을 쓰다보니, 많이 두서가 없다.


다음에는 제대로 ‘형식’을 갖추고 이야기를 써봐야겠다.

허니몬에 관한 보고서/허니몬의 직장일기
연말이 되면 항상 하는 고민이다.

요즘 야근, 주말근무를 3개월 하다보니 '이대로 일을 하는 것이 내가 원하는 일인가?'라는 고민을 하게 된다.

나는 개발자가 되고자 지금 이대로 나아가면 될까?

'경력관리' 보다 앞서는 '자기개발'의 욕심이 가득한 요즘...

가슴이 답답해지는 요즘.


푸른 파도가 넘실대는 바다 보러 가고 싶다. 

이번 프로젝트 끝나면 가야지...

그리고 내 장래를 고민해봐야지.
허니몬의 IT 이야기/프로그래머, '코드 엔지니어'
자료출처 : http://sunnykwak.egloos.com/887997

웹 개발 및 SI, DBA, SE 업종 개발자를 위한 경력 로드맵 입니다.


더불어서 이것(http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-2.1.11)도 읽으면 좋을 듯 하다.
1
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬