'허니몬에 관한 보고서/허니몬의 직장일기'에 해당되는 글 43건

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

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


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

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


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

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

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



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

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

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

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

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


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

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



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

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

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

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

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

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

    • 하드웨어 구성

    • 소프트웨어 구성

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

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

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


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


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


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

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


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


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

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


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


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


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

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

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

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

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

이 아닐까?


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

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


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


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


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

허니몬에 관한 보고서/허니몬의 직장일기
- 개발기간 3년 이상 장기간
- 투입인원 연인원 60명, 최대인원 150여명 이상...

사용자들이 정해져 있고 보통 SI(System Integration)라고 부르는 사업이다.
특징 :
(1) 프레임워크나 솔루션이 투입되어 일정한 공수로 개발자들이 투입되어 개발한다.
(2) 기존에 정보시스템이 있거나 대체, 혹은 신규 개발하는 형태다.
(3) 고객이나 사용자들이 일반 사용자에 가까우므로 IT 관련 정보기술에 어둡다.
(4) 고급개발자들은 극소수만 사용할 수 있으며, 초급개발자들을 주로 사용한다.
(5) 기간이나 비용 등이 영업의 힘으로 결정되는 경우가 다반사이며 생각보다 제약사항들이 많다.
(6) 고객의 요구조건을 어떻게 관리하는지와 품질의 영역이 불명확한 경우가 많다.

내가 있는 곳은 10여년의 개발과정을 거의 끝마치고, 유지보수 사업으로 사업전환을 한 곳이다.
그래서 인력을 감축하고 있으며, 고급인력들도 대부분 빠져나가고 있는 상황이다.
초급인력들이 그 자리를 메우고 있는 상황이다.
유지보수가 진행이 되면서, 기존에 개발되었던 시스템구조가 많이 흩으러져서 효율성이 떨어지기 시작하고 있다.
허니몬에 관한 보고서/허니몬의 직장일기
지금까지 크게 몸살이 나거나 병앓이를 한 적이 없었는데,
이번 감기가 독한 건지,
이번 프로젝트를 하면서 날새고 한 것들 때문에 체력이 떨어져서 그런건지,

여러가지 이유가 복합적으로 모여서 단단히 몸살이 났습니다.
엊그제부터 아프기는 했는데, 별거 아니겠거니 했더니,
어제저녁에는 밤새 잠을 제대로 못자고 시름시름 앓으며 보내다가
결국 오늘 하루 월차를 내고 쉬었네요.

아직 해야할 일들이 많은데...

건강!! 꼭 챙기세요. ^^
LONDON, UNITED KINGDOM - DECEMBER 20: Passengers rest at terminal five at Heathrow Airport on December 20, 2010 in London, England. Severe weather has caused major disruption at the United Kingdom's biggest airport for a third day. (Photo by Peter Macdiarmid/Getty Images)


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

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

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

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

가슴이 답답해지는 요즘.


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

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

그리고 내 장래를 고민해봐야지.
허니몬에 관한 보고서/허니몬의 직장일기
검수 일정을 맞추기 위해 오늘도 출근하여,
1개 본수를 마치고 왔다.

엠티를 다녀왔다는 룸메의 등짝. (....)
엠티를 다녀왔다는 룸메의 등짝. (....) by 아침놀 저작자 표시동일조건 변경허락

내가 능력이 부족해서 그런 것인지도 모르겠다.
지금 하고 있는 일은,
델파이(Delphi)로 구현되어 있는 프로그램을 WebLogic 기반으로 하여 EJB로 이식하는 작업을 진행하고 있다.

이 작업을 왜 하는지에 대해서 정확하게 설명하거나 이해하는 사람은 없다.
ㅡ_-)> 그냥 하는거다.

나도 조금 더 무엇인가를 배울 수 있을까 하는 마음에, 프로젝트에 한번 더 참가를 했다.
그런데, 두서없이 진행되는 이런 프로젝트에는 더이상 발을 담그면 안되겠다는 생각이 든다.

우리나라에서 진행되는 SI 프로젝트들이 이런식은 아니겠지만...
꽤 많은 프로젝트들이 이런식의 주먹구구식이면서 관행적인 SI 프로젝트를 진행하지 않을까라는 생각을 하게 된다.

1 ··· 4 5 6 7 8 9
블로그 이미지

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

허니몬