(1) 톰 소여의 리더십
소프트웨어 개발/ 문제 해결하기
서론
1년 전에 "Embedded software 개발팀 팀장" 이라는 인생의 한 단락을 마무리하면서, 그간의 경험을 남겨두고 싶다는 생각에 글을 쓰던 게 있었다. 좀 쓰다가... 미래에 대한 여러 고민들 때문에, 그런 류의 글을 쓴다는 게 부질 없다는 생각에 관뒀었다.
우연히 컴퓨터 폴더를 뒤적이다가 그 때 쓰다 만 글을 발견했는데, 그냥 지우기는 좀 아까워서 수줍게 브런치에 남겨두려고 한다.
내가 만들었던 제품들은 TV 와 연결하는 셋탑박스에 들어가는 소프트웨어 였다. C 와 Java 로 이루어진 소프트웨어였고, 사람들이 "TV 는 죽으면 안 돼" 라는 생각이 강해서 거기에 딸린 셋탑도 자연스럽게 "죽으면 안 돼" 라는 것이 당연했다. (지금 모바일 어플을 개발하면서 "죽으면 사용자가 다시 시작시키겠지" 라고 생각할 수 있는 게 눈물겹다. ㅠ.ㅠ) 그래서, 내가 생각하는 방법들이 다른 영역의 소프트웨어에서는 분명히 다를거다. 더군다나 사람에게는 "성격" 이라는 게 있어서, 정답이 있을 수가 없다. 그러함에도 불구하고, 경험을 쓴다는 것은 마치 정답을 쓰는 것 같은 문체가 될 수밖에 없으니, 혹시라도 지나가다가 우연히 이 글을 보게 되시는 분이 있으시면 가볍게 "그럴 수도 있겠네" 정도의 느낌으로 보셨으면 좋겠다.
일을 하는데 있어서 가장 영향을 준 멘토가 누구냐고 묻는다면, 난 지체 없이 “톰 소여” 라고 대답할 것이다. “톰 소여의 모험” 이라는 책을 아주 어렸을 때 읽었었는데, 사실 톰 소여가 결국 지구를 구했는지, 공주와 결혼을 했는지, 전혀 기억나지 않지만, 담벼락에 페인트칠을 한 에피소드만큼은 분명히 기억한다.
톰 소여가 뭔가 사고를 쳐서, 넓은 울타리에 페인트칠을 다 하라는 벌을 받는다. "이걸 어떻게 다 하지" 라고 잔머리를 굴리다가, 동네 아이들이 근처로 오자, 페인트칠이 너무 재미 있다며 자랑하기 시작한다. 동네 아이들은 급기야 “제발 나도 페인트칠을 하게 해 달라” 며 빌게 되고, 결국, 톰소여의 친구들이 즐겁게 페인트칠을 다 했다는 에피소드이다.
톰 소여가 본인에게는 재미없는 페인트칠을 재미있다고 속이는 부분을 빼고 보면(이것은 일하면서 절대 피해야 할 “거짓말” 이다), 매우 놀라운 리더십이다.
주위 사람들에게 매우 효과적이며 전략적으로, 일에 대한 호기심을 불러 일으킨다.
주위 사람들이 적극적으로 일을 돕게 한다.
주위 사람들이 일이 끝난 후 매우 만족스러워 했다.
일을 하다 보면, 나 혼자서는 해결할 수 없는 많은 문제에 부딪히기 마련이다. 다짜고짜 눈빛이 선해 보이는 만만한 선임에게 가서 “저 어쩌죠?” 라는 불쌍한 눈빛을 지으며, 한없는 선의를 베풀어주기를 바랄 수도 있겠지만, (가끔 그런 것도 필요하지만) 정말 어렵고 복잡한 상황은, 톰 소여의 리더십이 필요하다.
톰 소여의 리더십에 기초하여 문제를 해결해 나가는 과정을 보자.
그 문제를 해결하기 위해서 내가 해 볼 수 있는 건 일단 다 해 본 상태여야 한다. 누가 봐도 간절하고 답답한 상태여야 한다.
이 상태가 되면 아마 결과도, 생각도, 굉장히 지저분할 텐데, 문제를 다른 사람과 공유하기 위해서 잘 정리하고 다듬는 작업을 한다. 잘못된 데이터를 기초로 다른 사람과 논의하게 되면 시간 낭비이므로, 내가 앞으로 “말할” 내용들이 모두 사실인지를 점검하고 정리하는 작업을 한다.
문제를 맛깔 나게 잘 설명한다. (나 같은 경우는 습관적으로 어떻게 설명을 할지 미리 머리 속에서 순서를 다 정하는 편이다. 살짝 미스테리 소설 같은 그런 느낌으로...) 이미 나 스스로는 이 문제를 해결하고 싶어서 답답해 미칠 지경이므로, 마음이 통할 것이고, 평소에 착하게 살았다면 주변 동료가 일차적인 호기심은 보여줄 것이다.
열심히 설명하다 보면, 질문이 들어올 것이다. 내가 기본적으로 해볼 건 다 해 봤다면, 그런 질문들에 대부분 곧바로 대답이 가능할 것이다. 이 때가 주위의 호기심이 극대화되는 순간이다.
“Brain storming” 이란 게 시작이된다. 모두의 호기심이 폭발하며 이건가? 저건가? 라며 열심히 시끄러워지다가, 뭔가의 아이디어가 제시가 된다.
혹시라도 약간 아니다 싶은 아이디어더라도 (가령, “그럴 리가 없는데? 다시 돌려봐” 같은 게 대표적으로 “아니다” 싶은 지침이 되겠다.), 난 혼자의 힘으로 이 문제를 해결하는 걸 포기했으므로, 일단 시키는 대로 해서, 호기심을 계속 이어가도록 해야 한다.
그렇게 여러 사람들의 지혜를 모아 어떻게든 문제가 해결이 되면, 결과적으로 전혀 기여한 바가 없다고 하더라도, 이 문제에 관심을 가져 준 모든 사람에게, 문제가 어떻게 해결되었는지 소개해 줘야 한다. 톰 소여의 리더십이 결정적으로 빛을 발하는 것은, 마지막에 페인트칠을 끝낸 친구들이 매우 “만족”해 했다는데 있다. 마지막에 “아 속았다” 라고하면, 이건 리더십이 아니라, “사기”가 된다. 문제 해결의 무용담을 같이 공유하는 것은, 동료들을 문제 해결의 당당한 주역으로 끌어들임으로써, 그들에게 만족감을주고, 나중에 또 기꺼이 함께 페인트칠을 할 수 있도록 만드는 과정이다.
“Software integrator” 는 문제를 해결하는 게 가장 주요한 역할이다. 수십 명이 만든 코드가 모여서 문제를 “가끔” 일으키는데, 전혀 단서가 없어서, 누구에게 물어봐야 할지도 모르는 상황을 헤쳐나가야 하는 역할. 이 때마다 난 다크 서클이 깊게 내려온 톰 소여가 되어 주변 동료들의 지혜를 모아서 페인트칠을 해 나갔던 것 같다.
문제해결을 위해 주변 동료의 도움을 받을 때가 아니더라도, 관심을 불러일으키고 동기를 유발하는 행동은 어떤 자리에서 무슨 일을 하더라도, 매우 중요한 일이다. 물론 팀장은, 팀원들에게 효과적으로 일을 시키기 위해서 이러한 일을 늘 해야 하지만, 팀장이 아니고, 리더가 아니더라도, 혼자서만 일을 해서 끝나는 프로젝트는 없기 때문에, 순간순간 톰소여가 되어야 할 때가 많다.
예를 들어 보자. 개발자들은 테스트를 해 주는 QA 들과 같이 일하게 된다. 뭔가의 문제가 있어서 단서를 쫓기 위해 테스트를 의뢰하면서, 릴리즈 노트랍시고 “381번 이슈 관련. 다시 돌려주세요.” 이렇게만 쓰는 것은 톰 소여의 리더십이 아니다. 이 문제가 왜 어려운지, 그래서 뭘 하려고 하는지, 지금 이 테스트 결과가 어떻게 나오기를 기대하고 있는지 등을 공유해 주게 되면, QA 들의 눈빛이 “아 내가 지구를 구할 수 있겠구나” 라는 듯, 반짝일 수가 있게 된다. 그렇게 되면 정말로 우주의 기운이 모여서 (^^;) 기적처럼 문제가 해결될 때가 많다.
아무리 작은 프로젝트라도 동료들과 마음을 모아 잘 끝낸다면, 기분만큼은 지구를 구한 것 같을 수 있지 않을까.
- 1편 끝. 2편도 3편도 써 놓은 건 있는데, 막상 이렇게 복사해 두고 보니 또 부끄럼증이 도져서 언제 올릴지 모르겠네요. 흐흐 -
