'J'처럼 개발하기

나의 MBTI는 아마도 I와 T, N과 S의 중간 그리고 하나 확실한 것은 'P'라는 사실이다. 스스로의 MBTI를 잘 알지 못하는 사실은 내가 이를 싫어하기 때문인데, 사람을 고작 16가지 유형으로 나누는 것에 공감할 수 없기 때문이다. 물론 한 친구에게 MBTI를 싫어하는 MBTI도 있다는 이야기를 들은 후 시대의 흐름에 순응하기로 했다. 내가 스스로 'P'라 규정하는 이유는 즉흥적으로 살아왔고, 그것을 즐기기 때문이다. 대학생 때 내 취미는 '버스터미널에서 가장 가까운 시간대의 고속버스를 타고, 발이 이끄는 대로 국내여행을 돌아다니기'였다.

순간의 선택과 우연스러운 만남은 꽤나 낭만적이고 매력적이지만 최근에는 "J"처럼 살기 위해 노력하고 있다. 보다 자세히 표현하면 일을 시작하기 이전에 세우는 계획에서의 꼼꼼함과 그에 따른 일정 관리의 능력을 동경하고 있다. 새로운 프로젝트와 새로운 기능이 아니라면 결국 비슷한 업무 혹은 전에 해봤던 유지보수를 진행하게 되는 경우가 비일비재한데, 그 때 제일 어렵고 잘 안지켜지는 부분은 "일정산출"이다. 내가 계획하고 보고했던 일정보다 업무를 빨리 끝낸다면 보다 많은 일을 할당할 수 있음에도 적은 일을 할당받았기에 능력을 보여줄 수 있는 기회를 잃은 것이고, (혹은 설계 단계에서 시간을 단축할 수 있음에도 하지 못했다거나) 계획보다 일정이 많이 소요된다면 그 다음 일정에도 차질이 생긴다. 그렇기에 "일정산출"은 생각보다 개발자에게 중요하게 요구되는 노력치 중 하나이다.

개인적으로 개발자의 역량을 판단하는 가장 중요한 줏대 중 하나라고도 여기고 있지만 실전에서 이를 잘 지키기는 쉽지 않다. 나에게 주어진 업무의 요구사항을 파악하고, 이를 개발하기 위해 소요되는 시간을 추정한 다음 혹시 모를 변수를 만났을 때를 대비하여 10~20% 정도의 여유 시간을 두는 편인데, 만족스럽게 일정에 맞춘 적이 손에 꼽는다. 지금은 나에게 주어진 일만 따지고, 생각하면 되지만 추후에 리더가 된다면 팀원들의 역량을 고려하여 적절하게 일감을 배분할 수 있을 시각도 가져야 할 것이다. 아직은 요원한 일이다.

요즘은 2주 정도의 시간이 소요된 작업이 있다면 이를 문서로 남기고자 신경쓰고 있다. 물론 다음에 이 업무를 담당하게 될 개발자를 위한 길라잡이를 만드는 측면도 있지만 나 스스로가 생각했던 스코프와 비교하기 위함도 크다. 문서를 작성하면서 이 업무를 담당하기 이전에 어떤 부분까지 고려하였는지, 내가 고려하지 못한 이슈 상황은 무엇이 생겼는지, 그러한 이슈를 해결하기 위해 내가 어느 정도의 시간을 소요했는지 등을 따져보며 조금 더 정확한 일정 산출을 위해 스코프를 조절하고 있다. 최근 담당하고 있는 일정 산출은 실패했다. 내가 생각한 것보다 훨씬 더 깊이 프로젝트 구조에 관련된 이슈를 해결해야 했고, 내 예상보다 많은 신경을 요하는 작업이었다. 잘하는 개발자 이야기 들어보면 요구사항 듣고 딱 생각해서 샥 업무분장하고 슉 개발하던데, 나도 빠른 시일 안에 그럴 수 있길 바래본다.