SW 개발자를 위한 멘토링

변화에 대처하는 방법

dextto™ 2012. 11. 15. 23:08


  얼마 전에 공무원이라는 영화를 봤다.일상에 변화가 없다는 게 가장 큰 장점이라고 생각하는 7급 공무원이 그 주인공이다. 하지만 공무원이라고 업무에서 가정에서 그리고 자신의 인생에서 변화가 생기지 않을까? 회사 업무를 하다 보면 주위에 모든 것이 변한다. 조직개편이 되서 몸담고 있던 조직이 이동되기도 한다. 신입사원이 들어오고, 주위에 누가 퇴사했더라 하는 소식이 들려온다. 조직개편 되서 조직책임자가 바뀌면 무언가 이전에 있던 프로세스가 사라지고 새로운 프로세스가 생기기도 한다. 그런데 이게 그분이 처음에 의도했던 데로 항상 좋은 방향으로만 흐르지 않는 게 문제이긴 하다. 이건 다음 기회에 다시 이야기 하기로 하고 오늘 주제로 다시 돌아가자.


  소프트웨어 개발 업무 중에도 역시 많은 것이 변경된다.


-. 고객 요구사항

  일명 시나리오. 시도 때도 없이 바뀐다. 일정한 주기나 근거가 있으면 그나마 받아들이는데 스트레스는 안 받겠다. 저 위에 누군가가 하라고 하는 것들이 너무나도 많다. 제품 책임자가 권한이 그나마 좀 있어서 어느 정도 쓰잘데기 없는 기능을 잘라주기라도 하면 다행이다. 시나리오가 바뀌는 게 나쁘다는 게 아니다. 소프트웨어가 진화하는 과정에서 아주 자연스러운 일이다. 문제는 원칙없이 즉흥적으로 바뀔 때가 많다는 거다.


-. 소스 코드

  시나리오가 바뀌는 데 소스코드가 안 바뀔리가. 버그를 수정할 때도, 리팩토링을 할 때도 소스는 바뀐다. 몇 달 동안 변하지 않는 코드가 있다면 시간을 내서 다시 한 번 들여다 보시길 바란다. 사용자가 쳐다 보지도 않는 기능을 구현해 놓아서 바뀔 필요가 없었던 것은 아닌지.


-. 개발 프로세스

  이전 프로젝트에서 사용하던 프로세스는 이젠 구식이다. 누군가는 (대부분은 회사에서 제품 출시에 영향력이 있는 부서. Q부서가 힘을 가지면 개발 부서는 피곤하다.)  이전 프로세스를 개선하여 다른 부서에 요청합니다. 개발 프로세스가 바뀌면 시스템도 변경된다. 새로운 업무 시스템 사용법도 익혀야 한다.


-. 개발 환경

  예전에 프로젝트에 새로운 솔루션을 처음 적용해서 안정화 시키느라 그룹사람들 100여명이 죽도록 개고생한 적이 있다. 그 때 모 그룹장님께서 이번 프로젝트만 출시되면 좀 낫지 않겠냐고 아주 설득력 있게 연구원들을 독려했던 적이 있다. 정확하게는 아니지만 당시 K군의 MSN 대화명이 기억에 남아있다. "희망은 가장 강력한 독이다." 

  개고생한 프로젝트가 끝난 뒤의 프로젝트도 만만치 않았다. 남들 보다 좋은 제품을 시장에 내 놓으려면 이전 것을 우려먹어서야 되겠나? 뭔가 새로운 걸 또 만들어야지. 또 이야기가 잠시 옆으로 샛다.


  어쨌든 개발언어도 바뀌고 컴파일러도 바뀌고, 다운로드 툴도 바뀌고 많은 것들이 바뀐다. 그 때 마다 새로운 언어를 익히고 팁도 배우고 500페이지 넘는 책을 보고 따라하기도 해 보고 한다. 게다가 코드 리뷰 시스템도 새로 익혀야하고, 소스 관리 툴도 ClearCase에서 요즘 대세인 GIT으로 넘어갔으니 이것도 공부해야한다. 새로운 이슈 트래커를 도입했다고 하니 이 놈은 또 어떻게 쓰느 것인 지 알아봐야 한다. 남들 다 쓴다는 WIKI 사용법도 공부해야 된다. 개발자가 순수 개발 외에도 컴퓨터 앞에 오래 앉아 있을 수 밖에 없다.


-. 일정

  경영진 이하 일명 관리자라고 불리는 직급의 계신 분들이 가장 신경쓰는 것. 일정이 안지켜 지는 이유에 대해 간단히 한 마디만 하자면, 개발자의 참여 없이 Deadline을 정한 다음 역산으로 일정을 짜 맞추기 때문다. 개발할 수 있는 만큼만 개발해서 시장에 출시하면 과연 경쟁사를 이길 수 없을까? "집중과 선택" 전략으로 채택된 기능이 Key Feature라면 충분하다. 프린터기가 달린 커피머신을 만드는 과오는 범하지 말아야 한다.


-. 팀원

  팀장의 입장에서는 이게 제일 골치 아플 것 같다. 팀원들 장단점도 파악하고 업무도 어느 정도 돌아가게 만들어 놓았다. 그런데 어느 날 한 녀석이 더 이상 못해먹겠다고 퇴직한다. 그러고 신입이 보충됩니다. 뭘 더 말하겠나. 팀원만 바뀌는 게 아니다. 시나리오 담당이 바뀌어서 기존 소프트웨어가 가지고 있던 특색이 사라지고 다른 쪽으로 변질된다. GUI 담당이 바뀌어서 새로 만든 아이콘이 뭔가 어색하다. 상사가 바뀌어서 업무를 A-Z 설명해 줬더니 이젠 프로젝트가 산으로 가려고 한다. 조금 과장했지만 프로젝트를 진행하다 보면 인원 변경은 비일비재하다.



  개발을 하다 보면 변하지 않는 게 없다는 게 더 맞는 말인 것 같다. 그럼 이런 변화가 생길 때 사람들은 어떻게 대응을 하는가? 크게 다음 3가지 부류로 나눌 수 있다.


1. 회피자형

  변화를 거부한다. "이런 일을 왜 또 벌이나?"하고 투덜거리며 자신에게 익숙해 있던 방식으로 업무를 처리한다. 뭐 당분간은 그렇다고 해서 생산성이 떨어지는 것도 아니다. 변화에는 어느 정도 과도기라는 게 있어서 새로운 방식과 이전 방식이 둘다 통용되기도 하니까.

  문제는 이전에 자신만의 경험에 빗대어 판단을 내린다는 겁니다. "이전에 비슷한 거 해 봤는데, 소용 없어. 다 쓸데 없고 결국 없어 질거야"라는 말을 자신이 자주 한다면 회피자형이라고 할 수 있겠다. 하지만 결국 그도 새로운 방식을 익혀야 한다. 주위에서 다들 변하는 데 자기만 그대로일 수 없다.


2. 얼리어답터형

  변화에 아주 민감하다. 변화에 긍정적인 비판을 해 본다. 좋다는 판단이 들면 주위에 퍼뜨리려고 노력한다. 보통 이런 사람들에 의해 시스템이 개선되어 전파되는 경우가 많다. 그렇다고 해서 얼리어답터가 항상 좋은 것만 채택하는 건 아니다. 나중에 보니 아무도 쓰지 않는, 쓸모 없고 누군가의 KPI만 채워 주는 것들도 있다.  하지만 이런 것들이 쌓이고 쌓여서 발전을 한다고 생각한다.


3. 추종자형

  대부분이 여기에 속할 것이다. 얼리어답터에게 설득당하고 주위에서 좋다는 소리를 들으면 따라서 변화에 몸을 담근다. 스트레스는 가장 적다.



  당신은 이 중에 어느 부류에 속하는가? 적어도 회피자는 되지 말아야 겠다는 생각을 해 본다.

반응형