주말에 개발을 하는 이유.
개발, 리더 그리고 디테일
올해 들어 휴일에 짬을 내서 잡다한 개발을 하기 시작했다.
이는 내가 조직 리소스 관리 측면에서 좀 더 민감해 질 필요가 있어서다.
개발을 하다보면 어떤 이유로 인해 원래 시간보다 릴리즈가 더 늘어지는 일이 발생한다.
이유를 생각해보면
만들 당시와 현재의 비즈니스가 달라져서 생각보다 많은 수정이 필요하거나,
과거 만들 때 여러 이유로 디테일을 놓쳐서 하는 김에 디테일을 챙기다보니 시간이 오래 걸리거나,
하는 김에 관련된 코드도 리펙토링하고 싶다는 욕심이 생기거나,
어떤 트러블 슈팅으로 인해 삽질을 겁나 하거나,
사전 정리가 되어야 할 부분이 개발하면서 튀어나와 의사 결정이 늘어지거나,
위에 나열한 것 말고도 오만 것들로 인해 늘어지는 것이 발생한다.
또한 개발 코드라는게 lint tool과 가이드라인만 있다고 일관성이 있는 코드, 디테일이 있는 코드가 나오지 않기에 꽤 많은 시간을 들여야 한다.
이는 마치 수학을 70점 맞는 것은 보통의 노력을 들이면 가능하지만 95점을 맞는 것은 배의 노력 이상을 해야하는 것과 마찬가지다.
위 상황은 개발을 하다보면 일상적으로 발생하는 것이고 이미 과거에 나도 많이 겪었던 것이라 누구보다 잘한다고 생각한다.
하지만 리더로서 오랫동안 거버넌스한 부분을 보다보면 위의 이슈가 작게 느껴질 때가 많다. 이는 개발을 넘어서 현재 처해 있는 제품의 가치, 비즈니스 상황, 조직과 구성원들등 꽤 여러가지를 종합적인 시각으로 모든 것을 보게 되기 때문이다.
이런 시각을 계속 갖다보면 개발에 대해서 퍼포먼스가 나지 않는다고 단정 짓게 된다.
비단 개발 뿐만 아니라 기획, 디자인도 마찬가지다.
이런 네거티브한 시각은 조직이 목표를 향해 나가는데 나쁜 영향을 준다.
사람이 자신이 갖는 시각을 바꾸는 가장 좋은 방법은 자신이 실제로 그 일을 해보는 것이다.
마치 우리가 자주 실수를 하고 단정짓는 ‘도대체 저 조직은 어떤 일을하는 것일까?’에 대한 대답으로 자신이 그 조직에 가보거나 그 일을 하게 되면 깨닫는 것 처럼.
한 3주 되었는데.. 다시 한번 깨닫게 되었다.
디테일함을 잡기 위한 개발은 정말 많은 시간이 든다. :”)
One more thing
좋은 리더십을 발휘하는 쉬운 방법은 구성원일 때 느꼈던 것을 잊지 않는 것.
