일하는 방식
뭣이 더 중한디~~~
개발 관련 일을 하면서 빈번하게 만나는 아쉬운 상황 4가지에 대해서 말해 보고자 한다.
현상
1. 신규 입사자
그리 어렵지 않다고 생각하는 우리의 업무를 일일이 알려주지 않으면 못한다. 그의 역량이 부족해 보인다.
2. 내가 할 수 있는 것을 남에게도 동일하게 기대
그리 어렵지 않다고 생각하는 어떤 기술을 충분히 알려줬는데 잘 따라 하지 못한다. 그의 역량이 부족해 보인다.
3. 리팩터링을 해야 하는데 기획자들은 이해를 못한다.
내가 하면 충분히 잘 고칠 수 있는 레거시 코드가 있고, 이를 고쳐야만 앞으로 잘할 수 있는데 기획자들이 일정 문제로 반대한다. 기획자들은 개발 문제를 이해하지 못한다고 생각된다.
4. 기능적 완성보다 디테일을 챙기는 것이 중요한데 이해하지 못하는 팀원이 있다.
일정 내에 정해진 기능을 만드는 것보다 하나라도 완성도 높게 만드는 것이 중요한데 이를 이해하지 못하는 팀원들이 있다.
사례 1,2
2008년 즈음 게시판 개발을 할 때 신규 입사자가 있으면 옆에 두고 3달 정도를 강도 높게 가르치려 했다. 이런 행위의 목적은 업무 지식 인수인계도 있었지만 TDD, OOP 등을 기반으로 개발을 잘하도록 가르치려는 목적도 있었다. 그런데 3달 만에 내가 기대했던 것만큼 이해하고, 행하는 신규 입사자는 없었다.
이때 2가지 생각이 들었다.
첫 번째는 우리가 엄청난 일을 하고 있어서 신규 입사자들은 3개월 내에 제대로 배우지 못한다는 생각이 하나였고,
두 번째는 신규 입사자가 역량이 부족해서 TDD, OOP 등을 3개월이나 알려줬음에도 제대로 못하는 것 같다는 생각이었다.
약간의 시간이 흐른 후(2년 정도) 이 두 가지 생각이 얼마나 바보 같은 생각인지를 깨달았다.
첫 번째 문제는 우리의 프로세스나 문서가 부족하여 3개월을 알려줘도 신규 입사자가 우리만큼 일하지 못하는 것이었고,
두 번째 문제는 나는 오랜 기간 동안 배운 지식, 기술을 경력이 적은 신규 입사자가 3개월 만에 따라올 수 있다고 바보 같은 생각을 한 것이었다.
우리의 프로세스나 문서가 콘텍스트가 적은 신규 입사자가 보고 빠르게 이해하고 업무를 수행할 수 있는 수준이어야 우리가 잘하는 것이다. 채용 면접을 통과한 역량 있는 신규 개발자가 이해하지 못하고, 보고도 따라 할 수 없다면 프로세스/문서의 문제일 가능성이 더 높은 것이다. 물론 문서, 프로세스를 잘 만들어도 약간의 설명은 필요한 할 것이다. 설명도 없이 읽기만 해도 이해하고 따라할 수준이라면 문서화에 과한 노력이 들어갈 수 있다.
또 오랜 기간 갈고닦은 나의 기술을 3달 만에 신규 입사자에게 전달하고 그가 행할 수 있다면 아마 그 기술은 정말 별볼일 없는 기술일 것이다. 즉 내가 오랜 기간(10년 넘게) 동안 쌓은 기술은 다른 개발자가 3개월 만에 터득할 만한 소소한 기술일 것이다.
첫 번째 문제의 해결책은 조직 내에 프로세스가 잘 자리 잡고, 문서화가 잘 되어 있어 약간의 설명과 문서를 보고 일을 할 수 있는 수준이어야 하는 것이고,
두 번째 문제의 해결책은 많이 알려줄 수는 있지만 배우는 사람이 이해하고 행할 수 있는 만큼만 업무에서 나올 수 있다는 것을 이해하는 것이어야 한다. 나만큼은 아닐 수도 있지만 나름 상당한 시간이 요구된다는 것을 인정해한다는 것이다.
이 2가지가 내가 신규 입사자나 다른 사람과 일 할 때 가지려 하는 생각이다(종종 잊을 때도 있지만…).
사례 3,4
또 다른 문제로 업무를 진행하다가 나오는 장애물을 임하는 자세에 대해서 이야기를 해 보고 싶다. 가끔 본인이 어디서 본 적이 있거나 조금 공부한 경험을 바탕으로 지금의 문제를 해결하거나 새로운 기능을 추가하기 위해서는 리팩터링(이라고 말하지만 잘 들어보면 자기가 다시 만들겠다는 것)을 해야 한다고 이야기하는 것을 볼 때가 있다. 또 기능적으로는 크게 문제가 없으나 완성도를 위해 디테일을 챙겨야 한다며 예정에 없던 일이나 상대적으로 덜 중요해 보이는 일에 시간을 보내는 것을 볼 때가 있다. 앞서 말한 리팩터링은 리팩터링이 아니라 리컨스트럭션일 것이다. 리팩터링이라면 Robert C. Martin이 말한 것처럼 화장실 다녀오며 손 씻는 것처럼 본연의 업무(소변보기)와 거의 동시 일어나는(손 씻기) 별도의 일정을 잡지 않는, 당연히 해야 하는 일이어야 한다. 그래서 리팩터링을 일정에 별도로 잡는 것은 리팩터링을 할 수 없는 사람이 일정을 잡는 방식으로 보인다. 리팩터링을 잘할 수 없는 사람들이 하고자 하는 리팩터링이기에 잘 되기 어렵다.
두 번째 일정 내에 해야 하는 일이 있음에도 디테일 혹은 풀기 어려운 덜 중요한 문제를 챙기기 위해 시간을 소요하는 것은 내일 시험을 보기 위해 100 페이지짜리 교과서를 공부하다고 30 페이지에서 막히는 문제가 있을 때 어떤 전략을 취할지와 유사한 문제인 것 같다. 100점이 아니면 0점인 상황이라면 30 페이지의 막히는 문제는 반드시 풀고 넘어가야 할 것이다. 또 30 페이지의 문제가 100점 만점에 80~90점에 해당하는 것이라면 반드시 풀어야 할 것이다. 하지만 5점 이하(확률적으로는 1점 1/100 페이지이니)가 할당된 페이지라면 일단은 100 페이지까지 다 보는 것이 합리적인 선택일 것이다. 30 페이지의 문제를 포기하더라도 95점은 받을 수 있을 테니… 30 페이지에 머물다 시험을 보게 된다면 잘해야 35점일 테고 말이다.
결론
약간 억측이 있지만 이상의 내용을 정리하면 아래와 같다.
1. 우리 업무에 익숙하지 않은 신규 입사자가 우리가 그리 어렵지 않다고 생각하는 우리 업무를 어려워한다면 신규 입사자의 역량이 부족해서라기 보다는 우리의 프로세스/문서화가 부족해서 일 가능성이 높다.
2. 뭔가 별로 어렵지 않은 것을 알려줬는데 바로 못 따라오는 경우가 있을 수 있는데, 이때는 알려준 것을 행하는데 일정(수년의) 시간의 학습과 연습이 필요한 경우가 있을 수 있다.
3. 리컨스트럭션은 별도의 프로젝트로 진행해야 할지 모른다. 그리고 리팩터링(매일 조금씩 점진적으로 개선)을 못하는 사람이 새로 만든다고 잘 만들 수 있다고 예상하기 어렵다. 리컨스트럭션을 얘기하기보다 리팩터링을 수련하고 행하는 것이 더 효과적이다.
4. 덜 중요한 디테일을 챙기는 것은 일정을 지키며 나머지 일을 모두 잘 완수한 후에 고민하거나 시간이 부족하다면 현 상태에서 못하는 영역임을 인정해야 한다. “뭣이 더 중한디~~~"
