백부장님의 2가지 가르침을 공유합니다.
백부장님은…
전 회사에서 서버개발자로 함께 일한 분이셨다.
나와는 두바퀴 띠동갑이셨는데 ‘그냥 형처럼 생각해’라고 말씀하시며 잘 챙겨주셨다.
금융과 SI쪽에서 굵직한 경력들이 있는 정말로 무협지에 나오는 재야의 고수와 같은 분이셨다.
코딩도 코딩이지만 짬에서 나오는 도메인 이해와 이를 통한 통찰력이 어마어마하신 분이셨다.
척하면 척이고 말했다 하면 예언처럼 이뤄지곤 하는 정말 신기한 분이셨는데
회사에서에서도 핵심 시스템을 유일하게 이해하고 계신 분이셨다.
나에게는 스승과도 같은 존재셨다. 떄때로 정말 많은 조언을 해주셨는데
퇴사하기 직전에 술 한잔 사주시면서 지금까지도 기억에 남는 두가지 가르침을 남겨주셨다.
- ‘이 사람이 무슨 생각일까?’를 항상 고민해라
- 헤게모니를 나의 것으로 만들어라
사실 이 가르침을 배운지는 좀 되었지만
지금까지도 잘 실천하지 못하기도 하고해서
스스로에게 되새기고자 기억나는 대로 내용을 정리해보았다.
1. ‘이 사람이 무슨 생각일까?’를 항상 고민해라
첫번째 가르침은 바로 대화할 때 말 속의 진짜 의도를 파악하는 것이 항상 중요하다고 말씀해주셨다.
이는 단순히 단어 뜻대로 해석하는 것이 아니라 이 말을 하는 이유와 목적을 파악해야 한다는 의미였다.
예를 들어 동료가 자신의 실수를 숨기기 위해서 무언가 엉뚱한 요청을 한다던가
고객이 스스로 무엇이 필요한지 잘 모르는 상태로 도움을 요청하는 경우 등
말과 실제 목적이 다른 경우가 종종 생기기 마련이기 때문에
백부장님은 이 말에 속지말고 숨은 속 뜻과 목적을 최대한 해아리는 자세가 필요하다고 하셨다.
나는 이 얘기를 듣고 스티브 잡스가 남긴 이 이야기가 떠올랐다.
대부분 사람들은 제품을 보여주기 전까진 자신들이 원하는 게 뭔지도 정확히 모른다.
고객의 말을 곧이곧대로 이해하는 대신 진짜로 고객의 니즈를 찾아내야 한다는 교훈을 시사하기도 한다.
다만 고객 뿐 아니라 동료, 상사, 다른 사람들 조차도
정확한 이해 없이 또는 체면이나 다른 이유로 실제 말하는 것과 다른 의도가 있을 수 있다.
사실 나도 비슷한 실수를 많이 했던 기억이 난다.
사업팀 동료로부터 개발계 테스트앱을 배포해달라는 개인적인 부탁을 받은 적이 있었는데
당연히 테스트를 위해서일거라 생각하고 내부망에서만 테스트가 가능한 앱을 배포했었다.
그런데 알고보니 테스트가 필요해서가 아니라 제휴영업을 위해 잠재고객에게 전달할 샘플이 필요한 것이었다.
결과적으로 두어번의 추가 배포 이후에서야 최종 목적을 듣게되었고
그제서야 실제로 편의점에서 시연가능한 운영계 데모앱과 매뉴얼을 전달했다.
이 일이 있고나서부터는 배포 부탁을 받으면 배포이유를 꼭 듣고 배포를 하게 되었다.
이 가르침은 최대한 몸에 배도록 노력하지만
지금도 가끔씩 ‘아차!😧’ 하며 되새길 때가 있다.
2. 헤게모니를 나의 것으로 만들어라
헤게모니란?
백부장님은 헤게모니란 표현을 많이 사용하셨는데 여기서는 쉽게 주도권 정도의 의미로 이해하면 된다.
다시 말해 헤게모니를 나의 것으로 만들어라는 주도권을 가져오란 뜻인데
좀 더 구체적으로 이야기하자면 도메인과 시스템의 이해를 통해 업무 관계자들 사이에서 주도권을 가져오라는 의미다.
헤게모니를 가져오는 방법은 아래와 같았다.
프로젝트 시작 첫 일주일에 바짝 고생해라
백부장님이 SI를 뛰던 시절에 보통 프로젝트에 처음 투입이 되면
보통은 처음에 여유롭고 뒤로 갈수록 바빠진다고 하셨다.
하지만 백부장님은 반대로 첫번째 주에 바짝 고생하는 것으로 헤게모니를 가져올 수 있다고 하셨다.
무슨 소리냐면 첫번째 주에 마치 프로토타이핑 또는 목업처럼
프로젝트의 핵심 플로우을 한번 설계해보는 것이다.
이런 과정을 통해 프로젝트와 시스템에 대한 이해를 갖추고 실제 데이터 흐름을 눈으로 봐서
설계 단계에서의 실수를 미리 찾아내는 과정이 필요하다는 뜻이다.
백부장님은 이 과정을
한 싸이클을 돈다
라고 표현하셨다.
한 싸이클을 도는 것이 핵심이다
한 싸이클을 돌았을 때의 효과는 다음과 같다.
- 시스템에 대한 전체적인 맥락을 이해할 수 있다.
- 설계 단계에서 잘못된 부분을 남들보다 먼저 찾을 수 있다.
- 상세 작업단위에서 난이도를 미리 파악하여 예상 일정을 보다 정확하게 산출할 수 있다.
시스템에 대한 전체적인 맥락의 이해가 있다면
회의와 같은 자리에서 자연스럽게 남들보다 유리한 위치에 있게 되고
또한 설계 단계에서의 실수를 먼저 찾아서 이후에 발생할 일정 손실을 사전에 막아낼 수 있으며
어느 작업이 일정을 잡아먹을 지 미리 알고 있게 된다는 것이다.
이러한 과정이 반복되다 보면 어느샌가 팀 내에서 이미 전문가로 인정받으며
자연스럽게 헤게모니를 가져올 수 있게 된다는 것이 백부장님의 설명이다.
일례로 회의 때, 다른 사람과 시스템에 관해 논쟁이 붙이 마련인데
이미 이럴 때 나는 해봤으니까 남들보다 훨씬 더 깊게 이해하고 있게되고
이런 논쟁을 지켜보던 사람들이 결국 자신을 인정할 수 밖에 없게 된다는 것이다.
또 재밌는 점은 이러한 논쟁에서 굳이 설득할 필요 없다고 하셨다.
내가 확신이 있지만 다른 사람이 동의하지 못한다면 굳이 설득하려고 애쓰지 마라
나는 굳이 설득하지 말아야 할 이유를 '틀리면 쪽팔리니까?' 정도로 생각했는데
백부장님의 답은 '어차피 내가 맞을테니까' 였다.
한 싸이클을 제대로 돌아서 이미 시스템에 대한 이해를 하고 있다면
상대가 틀린 소리라는걸 알고 있다 하더라도 모두가 이 사실을 언젠간 알게 될텐데
굳이 힘들게 설득하려고 애쓸 필요 없다는 것이다.
이런 식의 과정을 몇번 반복하고 나면
어느샌가 내가 설득하려고 애쓰지 않아도 사람들이 내 말을 신뢰하게 되고
결과적으로 아까 말한 헤게모니를 가져오게 된다는 것이 백부장님의 설명이다.
그럼 그 헤게모니로 뭘 하면 될까요?
백부장님은 이러한 헤게모니를 보통 일정조율에 사용하셨다고 하셨다
개발자들(특히 SI)에게는 일정이 목숨인데
적은 공수로 이른바 딜을 하며 필요한 곳에 더 일정을 얻는 식이었다고 하셨다.
난이도 파악이 되어 어떤 요구사항이 시간이 오래걸릴지 알고 있으므로
클라이언트와의 일정 조율 때 협상에서 훨씬 유리하게 작용한다고 하셨다.
쉽게 말해 어려운 기능은 좀 덜어내고 쉬운 기능을 좀 얹어주는 식으로
클라이언트와의 줄다리기로 일정을 벌어낼 수 있다는 뜻이었다.
나의 반성
사실 아직까지도 이 헤게모니에 대한 가르침은 실천하고 있지 못하다.
솔직히 말로는 쉽지만
단 일주일만에 시스템의 핵심 플로우를 그려보는 것이 보통일이 아니다.
또한 예상 공수를 산정하는 것 조차 쉬운 일이 아니다.
지금 회사에서 하고 있는 프로젝트 초반에 이런 과정을 거치지 않았고
결과적으로 지금 뼈빠지게 야근하면서 그때그때 개발하다가 설계상의 미스를 찾곤 한다.
이것이 나뿐만 아니라 팀 전체에게 결과적으로 영향을 미치게 되는데
이럴 때 마다 백부장님의 가르침을 떠올리며 반성하게 된다.
이 부분은 습관보다도 노력과 연습이 필요한 가르침인 것 같다.