2011년, 내가 회사를 그만 둔 이유, 재미난 일을 찾아서...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 하드웨어 구성

  • 소프트웨어 구성

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이 아닐까?

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

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

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

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

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