https://www.youtube.com/watch?v=3H4umWD5bwI
배달의민족 CEO, 김범준님의 영상이다.
내 언어로 요약하면 다음과 같다.
1. 도움이 필요한 사람에게 적절한 도움을 줄 수 있어야 조직의 생산성이 극대화된다.
2. 리더는 개인의 성장이 팀의 성과로 연결될 수 있는 구조를 만들어야 한다.
3. 개발자의 몸값 상승은, 개발자 1인이 창출할 수 있는 비즈니스 밸류가 커졌기 때문이다.
4. 지시를 받고 이를 코드로 구현하는 데에 머물지 말고, 비즈니스적 문제 해결까지 상상 범위를 넓혀라.
기 - 신입 개발자의 생산성 고민
나는 2021년 6월 현재, 신입 개발자로 일을 시작한지 8개월차에 접어들었다.
요즘의 가장 큰 고민이라면, 사내에서 나 자신이 스스로 설정하는 수준의 생산성에 도달하지 못하는 것이다.
그리고 그 원인에 문서의 중앙화 및 체계화의 부재를 첫째로 꼽고 싶다.
이것도 일종의 기술부채이고, 더 빠른 성장을 위한 트레이드 오프이며, 어제의 최선이라는 점을 인정한다.
그러나 이런 저런 프로젝트를 맡아 진행하고 복기하며 느끼는 것은,
기술적 역량의 부족 보다는, 사내 솔루션의 로컬 룰에 대한 배경지식의 부재가
생산성 저하에 더 크게 영향을 미치고 있다는 것이었다.
오랜 시간 삽질을 하며 결국 정복을 하고 내 딴에는 최선으로 프로세스를 정리하고,
이를 도식화 시각화 문서화하여 나의 발자국을 남기고 있지만,
첫째로 너무 많은 시간이 불필요하게 소비되었으며, 둘째로 내 다음 사람도 같은 경험을 하게 될 거라는 게 문제다.
(이 과정에서 일정 지연으로 인해 상사로부터 받는 스트레스가 사실 그 당시엔 가장 크다 ;;;)
내 문서를 주고 싶지만, 다음 사람은 물론, 다음 사람에게 지시를 내리게 될 사람도
내가 이런 문서를 남겼다는 자체를 모를 것이기 때문이다 ;ㅅ;
가령 지난 4월부터 한 달간 진행한 프로젝트의 경우,
지금의 내가 돌아가서 문서를 주면서 1시간 정도 터치를 해준다면
6주가 걸렸던 소요기간을 보수적으로 잡아도 2주는 단축시킬 수 있을 거라는 게 내 생각이다.
말이 길었는데, 결론적으로 고민을 한 단어로 축약하자면 생산성이다.
처음 시작할 때 이런 부분에 대해 가이드를 받을 수 있었다면,
내가 훨씬 적은 시간 동안 이 작업을 완수할 수 있었을텐데..
다음 사람도 똑같이 이 고통스럽고도 비효율적인 과정을 겪어야만 하겠구나..
승 - 좋은 조직이란, 하나의 팀으로서 높은 생산성을 달성하는 조직
그런 고민을 하다가 이틀 전, 위의 영상을 보게 됐다.
영상의 첫번째 에피소드로 소개되는 것은 아래와 같은 이야기다.
첫 회사에 입사 후, 본인의 역량으로는 주어진 시간 내에 완수하기 어려운 미션이라는 판단이 서자,
해당 코드를 작성했던 사내 다른 분께 도움을 요청했고, 그 분이 하루라는 시간을 들여 설명을 달아줬다.
그 사람의 하루가 나에겐 한 달일 수 있었다.
김범준 CEO는 당시 이 경험을 통해, 좋은 조직이 무엇인가를 느꼈다고 한다.
그리고 여기서 말하는 '좋은' 의 의미는 단순히 잘 모르는 사람에게 도움을 주는 것을 넘어서서,
팀으로서 높은 생산성을 발휘할 수 있는 조직을 의미한다고 해석된다.
영상의 사례는 한 사람의 숙련자가 초보자에게 코드를 이해하는데 도움을 줬던 사례에 그치지만,
이를 조직 전체의 문화로 확대해서 상상해보자면 다음과 같을 것이다.
1. 누군가에게 처음 해보는 유형의 업무를 지시할 때에는, 이에 대한 문서 및 미팅을 통한 가이드가 선행된다.
2. 수행자는 문서 및 미팅을 통해 큰 구조를 미리 파악한 상태에서 작업을 시작한다.
3. 작업 수행 과정에서 비슷한 사례의 이전 개발건의 작업내역을 문서나 협업도구 등으로 참고할 수 있다.
4. 개발 중간중간 어려운 부분에 대해서 간단히 가이드를 요청할 수 있다.
5. 개발이 완료되면, 지시자와 비슷한 사례의 이전 개발건 참여자들로부터 코드 리뷰를 받는다.
6. 어떤 부분에 대한 테스트 및 QA가 필요한지 상사로부터 지시받고 이를 집중 검수한다.
7. 최종 완료 이후엔 본인의 작업내역을 문서화하여 남긴다.
상사에 너무 의존하게 되는 개발자를 만드는 게 아닌가 하는 의문이 생길 수도 있을 것이다.
그러나 해당 유형의 작업을 처음 할 경우엔 무조건 가이드를 받고 진행한 뒤에,
자신의 언어로 정리를 할 기회를 받아야 한다고 생각한다.
그렇지 않을 경우 개인으로서도 조직으로서도 지불해야할 비용이 너무 크기 떄문이다.
첫번째가 어려운 거지, 두번째부터는 별도의 가이드 없이 스스로 해낼 수 있을 뿐만 아니라,
오히려 같은 유형의 작업을 하는 사람을 가이드할 수 있을 것이라 기대된다.
나의 생각을 요약하자면 다음과 같다.
팀으로서 최대의 생산성을 발휘하기 위해서는
개인의 경험을 팀의 경험으로 만들어내고 이를 공유해야 한다.
전 - 좋은 개발자는, 조직의 일원으로서 비즈니스에 적극 동참하는 개발자
김범준 CEO는 엘리베이터 사례를 예로 든다.
엘리베이터가 느리다는 요구사항이 접수되었다 가정하자.
하드웨어 개선을 위해서는 많은 돈과 시간, 자원이 투입되어 적은 차이를 만들어내는데 그친다.
그러나 만약 요구사항을 엘리베이터를 기다리는 시간이 민망하고 지루하다 라고 재해석해낸다면,
거울을 설치함으로써 요구사항을 초월적으로 달성함을 넘어서 고객경험을 창의적이고 월등하게 개선시킬 수 있다.
뿐만 아니라 투입되는 자원도 줄일 수 있고 이는 곧 조직의 생산성으로 직결된다.
겨우 8개월 된 나도 비슷한 경험을 한 적 있다.
신입이니 당연한 거라고 할 수도 있는데, 요구사항에 적힌대로 지시받은 대로만 일하다가,
어느지점부턴가 이게 아닌 것 같다는 생각이 들었고 일을 적지 않은 시간이 지나서
이러이러한 이슈가 있다고 보고드리자 개발방향이 완전히 틀어졌던 경험이다.
그때 경험 이후로, 지시를 받더라도 그것을 100%믿지 말고
정말 그 방법이 맞는지 스스로 재검증해야겠다는 생각을 했던 적이 있다.
그러나 이건 작은 부분일 뿐이고,
실제 내가 속한 조직, 내 팀이 내 파트가 현재 직면한, 해결하고자 하는, 혹은 창출하고자 하는
비즈니스 과제가 무엇인지 정확히 인지하고 개발자 개개인이 메타인지를 활용하며
단순 개발자를 넘어 조직의 일원으로 비즈니스에 동참한다면,
이때 발휘되는 창의력과 상상력은 범위 자체가 달라질 것이다.
물론 이를 위해서는 수평적이면서도 업무와 관련된 아이디어라면
어떤 이야기를 해도 괜찮다는 분위기가 구성되어있어야 하겠다.
개인적인 생각으론 이런 문화는 아직 경험해보지 못했기 때문이기도 한데.. 정말 쉽지 않은 것 같다.
지금껏 내가 경험한 조직에서는 친소관계가 가장 중요한 요소이며
구성원 한 명 한 명의 역량을 최대한 끌어내는데 관심도 없고 자기 일 하는 데 바쁘고
자신이 이끄는대로 기분좋게 맞춰주며 시키는대로 잘 하는 사람만을 원하기 때문이다.
물론 먼저 충분한 시간동안 상사와의 친분관계를 쌓고 (열심히 상사 기분 맞춰줌으로써...)
그 다음에 변화가 필요하다고 생각되는 부분에 대해 적절한 타이밍에 약간 장난치는듯 투정부리는 투로
살짝 언급하는 식으로 의견개진을 하면 더 효과적일 수 있다는 기술적 지식은 있으나..
이런건 정말 내 스타일이 아니다. 일을 하러 와서 그렇게까지 피곤하게 살아야 하나.
난 그냥 일을 정말 잘하고 싶을 뿐인데.. 라고 생각이 드는 나는 아직 많이 미성숙한 것 같다 ...
결 - 지금 내가 할 수 있는 것은 내공을 쌓는 것
지금 내가 할 수 있는 것을 생각해본다.
1. 나에게 누군가 도움을 요청했을 때, 그 사람이 최대한의 역량을 발휘하고 생산성을 증대시킬 수 있도록
나의 자원을 기꺼이 내어주는 것. 그리고 그 사람의 성과를 지켜보며 기쁨을 나누는 것.
2. 나 자신의 역량을 갈고 닦는 것. (자격증, 학위, 언어, 프레임워크, 등등)
3. 내가 했던 일은 발자국을 남겨서 다음 사람의 삽질을 줄이는 것.
세 가지 모두 내가 너무 즐거워하고 지금까지 나름 애써서 해왔던 일이다.
리더십 역량이 요구되는 그때를 대비하며 조금씩 계속 나아가자.
