"놀고먹으면서 일 잘하는 방법은 없을까?"
제가 입사한 후 근 9개월동안 알게 된 IT 현실은 다음과 같습니다.
1) 개발자는 노동강도가 세다. 그들에겐 밤도, 주말도 존재하지 않는다. 왜냐면...
2) 대부분의 개발자들의 업무가 과중하고 업무를 처리하는 방식이 비 효율적이기 때문이다.
(주 업무의 70% 이상이 유지보수 = 버그잡기 이고 신규개발에 의한 과중은 얼마 안되었습니다.)
3) 개발자들도 이 사실을 알고있다.
4) 하지만 여러가지 이유를 들어 섣불리 개선하지 못하고 있다.
5) 그리고 타인과 조직이 잘못되어 있다고 한탄한다.
약간 다른 이야기지만, 저는 몇년전부터 "효율적으로 일하는방법 = 놀면서 일하는 방법"을 고민해 왔습니다.
사실 이러한 저의 고민은 저의 학창시절의 고민에서 시작되었습니다.
저의 학창시절 소원은 1등을 해보는 것이었습니다. 저는 5시간만 자고 공부만 했지만 항상 8시간 이상 자고 친구들과 자주 스타크래프트를 하는 1등이 항상 부러웠습니다. 시험에서의 퍼포먼스와 삶에서의 퍼포먼스 양쪽을 다 잡고있는 그가 매우 부럽고 시기했었습니다. 그리고 저는 "천재"가 아니기 때문에 그러한 것이 불가능할 것이다라고 단정지었었죠.
하지만 대학들어와도 바로 옆 친구가 시험기간동안 게임을 즐기면서도 항상 평점은 4.0 이상 이었던것에 비해, 저는 딱히 노는것도 없이 밤새는데 3.5를 간신히 넘는 상황이 발생하자 그동안 제가 해온 공부 = 일의 방식이 매우 비 합리적이고 아둔하지 않았나 생각하게 되었습니다.
무엇에 차이가 있나 저는 그때부터 잘하는 녀석들을 붙잡고 물어보고 저와 비교하는 일을 시작했습니다. 그 과정은 매우 괴로웠습니다. "나도 이렇게 진작 했다면 좀더 나았을텐데" 라는 생각과 "내가 멍청했다." 라는 자괴감 때문에 많이 괴로웠거든요. 무조건 시간을 오래 쏟는다고 성능이 나아지지 않는것인데 저는 그저 인내하고 파기만 하면 모든게 해결될줄 알았던 것입니다.
아래의 링크는 유명인사들이 왜 다른 평범한 사람들과 같은 시간을 보내면서도 탁월한 성과를 올릴수 있는가에 대한 이야기입니다.
http://lifedev.net/2008/03/10-ways-historys-finest-kept-focused-at-work/
정리하자면, 그들은 자신이 일하는 방식에 대한 그들만의 원칙이 있고. 결코 오래 엉덩이를 붙이고 있는것이 능사가 아니라는 것을 알고 있었으며 짧은시간동안 최대한 문제에 집중하고 나머지 시간은 몸과 뇌를 놀리는데 썼다는 것입니다.
역시 학창시절에 저보다 우월한 녀석들은 "모든 일을 줄기차게 많이 하는것" 보다 "중요한 일에 단시간 집중하여 탁월한 성과를 내는것"을 선호하고, 각자 그렇게 하는 자기만의 최적화된 방법을 연구하고 체득하고 있었다는 겁니다.
결국, "놀면서 일 잘하는 방법에 대한 패턴"은 존재했다고 생각합니다.
그래서 저는 저만의 방법을 찾아 연구했고 이를 간단히 실험해 보았습니다. 공부의 원칙과 시간을 세우고 제가 잘하는 "그림/동영상 기억법"을 이용해서 "숲에서 나무로 훓어 내려가는"공부를 해 보았습니다. 그리고 공부시간 외의 시간은 음악을 듣고 군것질을 하고 잡담을 하고 만화책을 보며 게임을 했습니다. 이전에 시험기간동안 공부에만 투자한 시간이 하루 10시간 이라면 이를 5시간까지 줄였습니다.
그 결과는 생각 외였습니다. 저는 이전보다 많은 시간을 공부에 할애하지 않아도 많은 양을 기억할수 있었고 (일부는 지금도 기억합니다.) 성적도 0.3포인트 이상 더 잘 나왔던 것입니다.
다시 회사 이야기로 돌아가서, 수많은 개발자들이 오늘도 죽음의 행진을 하고 있습니다. 아직 초년때에 이 죽음의 대열에 막 발을 담그고 "정말 대한민국에서의 회사생활과 IT엔 답이 없는가?" 하며 괴로워 하고 있을때 한 상사분께서 다음과 같은 조언을 몇가지 해주었었습니다.
1) 주요이슈(issue)는 정리되어야 한다. (잠재적인것도 포함)
2) 문제는 잘게 쪼개어야 한다.
3) 히스토리는 기록되어야 한다.
4) (상사가 보기에)중요한 몇가지에 우선 집중하라.
5) 문서와 코딩은 같이 가야한다.
6) 설계와 코드는 자주 리뷰되어야 한다.
7) 설계는 절대 폼잡지 말고 실용적이어야 한다.
8) 프로세스를 세우고 이에 맞추어 일하라.
9) 일 할땐 하되, 자주 쉬어라.
10) 개선할것은 시간을 들여서라도 자주 개선하고
11) 위 모든것은 보고하여 실적화가 가능한 형태로 준비하라.
저는 이러한 조언이 그분의 직장생활 10년동안에 나온 귀중한 경험이자 하나의 패턴이라고 생각했습니다. 하지만 그 상사분도 이러한 것들을 제대로 실천하고 계시지는 못하고 계셨습니다. 그래서 저는 여기에 아래와 같은 약간의 변형을 가하고 이를 구체적으로 패턴화 하고 실천하는 작업에 들어갔습니다.
12) 모든 업무는 파이프라인처럼 병렬적으로 진행하도록 한다.
(신속한 태스크 스위칭을 통해서)
저는 스프레드쉬트로 각 업무에 맞는 문서를 만들었고, 오늘의 프로세스를 세워 이를 적어두고 하나씩 실천했습니다. 처음에는 상당히 귀찮을 뿐더러, 번거롭기 그지 없었지만. 이것이 몇달이상 쌓이게 되자 위 11가지 사실을 어느정도 만족시킬수 있는 자료가 되고, 그 자료를 근거로 RISK를 예측하고, 문제에 당황하지 않으며, 한번 해결한 문제가 두번 열리지 않게 하고 남는시간에 중요한 문제에 포커스 하며, 결국 단위시간동안 이전보다 좀더 많은 일을 해결할 수 있음을 알게 되었습니다.
통계를 내본결과. 적용전에 하루 3개 정도의 업무를 해결했었으나 이후 5개 이상 최대 하루 10개까지 완료했다는 사실을 발견했기 때문입니다. (이를 가능하게 해준 Franklyn Planner에게 감사~:) )
결국 개발자들이 겪는 수많은 문제들이 정말 IT란 것이 일이 단순히 많아서가 아니라, 과거에 처리한 Bug가 다시 reopen되거나 대충한 설계와 구현때문에 요구사항이 바뀔때 대응을 못하고, 정작 이러한 모든 일에 대한 전체적인 정리된 문서나 설계서가 없기 때문에 문제원인 파악과 대책마련에 시간이 걸린다는 것을 깨닭게 되었습니다. (결국 인간의 기억력에는 한계가 있는데, 많이들 이를 간과합니다.)
문제가 생기지 않는다는 것은, 그 문제를 끊임없이 관리하기 때문이라는 사실도요.
저는 주로 유지보수일을 하고 있었기 때문에, 신규개발만 하는 분들에게 있어서는 별로 공감이 안갈수도 있겠습니다. 그래서 저는 신규개발에도 이러한 "패턴"을 발견하고 여기서 프로세스를 만들어 이를 실천함으로서 현재와 미래의 퍼포먼스와 RISK 안전성을 높이는 작업 이 가능한지 실험해 보기로 하였습니다. 그래서 몇가지 프로세스를 만들었고 이를 실험하여 "우리의 Agile 실험" 이라는 태그를 붙여 블로그에 포스팅 하려 합니다.
그리고 저 뿐만 아니라 저 주변의 사람들도 이러한 실험을 통해서 개발에 대한 새로운 눈을 뜰수 있게 되길 소망합니다.
