11. 리더의 이슈분석
모든 이슈를 봐야하지만, 들여다보지 않아야 한다
수석엔지니어 리더의 역할을 다시 곱씹어 본다.
- 각 팀별로 돌아가는 개발 아이템과 로드맵들을 구상한다.
- 아키텍쳐를 만들고, 코드리뷰를 통해 팀의 개발진행을 보조한다.
- 팀원 조직관리도 하고 평가를 진행하고, 단위 업무가 순항하게끔 관리자 역할을 수행한다.
이상적인 수석엔지니어(리더 겸)의 업무는 이 정도라고 생각한다.
하지만, 개발팀에서 숙명과도 같은 업무가 있다. 그것은 바로 이슈분석 및 해결.
어?
개발팀에서는 "어~?" 금지라는 말이 있다. 아무것도 아닌 일에 호들갑 떨지 말라는 일이다.
하지만 일주일에 적으면 하루, 많으면 일주일 내내 매일매일 개발이슈가 나온다.
이슈원인이 뭔지, 수정패치가 나을지 Workaround가 나을지 팀원들간의 논의를 한다.
개인적으로 수석엔지니어 리더가 참여하는 순간 리더역할로 참여하기 때문에, 말 한마디가 곧 결정사항이 되는 경우가 흔하다. 그래서 최대한 애써 외면하는 것이 좋다. 알아도 모르는척.
팀원들끼리 논의를 충분히 하고, 결정도 자기들끼리 협의가 됐다면
수석엔지니어의 리더십에서 언급 했던 결정은 본인이 하자, 플랜B를 만들어두자, 액션아이템을 끝까지 수행하자 정도만 수행하면 된다. 모든 개발이슈에 본인이 나서서 진두지휘하는 일은, 누구에게도 도움되지 않는다. 순간 이슈해결에는 얼핏 도움이 된 것 같으나 본인이 해결했다는 느낌일뿐이다.
긴급분석 요청드립니다
발행을 앞두거나 곧 릴리즈를 해야 하는 순간에 개발팀에 전달되는 긴급이슈 (보통은 QA이슈다)
주니어나 시니어 엔지니어가 분석하고 있지만, 가끔 수석엔지니어에게 연락이 온다. 긴급하니 챙겨봐달라고.
수석엔지니어 초기에는 어떻게 해야 "챙기고 있는 건지" 몰라서 그냥 이슈를 같이 분석했다. 로그도 같이 열고, 수정코드도 같이 준비하고, 직접 개발검증도 해보고 등등 그러다가 내가 담당자가 되었다.
실무가 아닌데 실무처럼 행동하는 것은 가장 최악이다.
"챙길 수 있는 것들"을 해보자. 업체코드라 외부업체 연락이 필요하다면 바로 하고 (마찬가지로 "챙겨봐달라고" 연락한다), 실무가 필요한 자원 (단말, 재현규모 등)이 있다면 바로 요청한다. "챙기고 있는" 임원들 진정시키는 일도 담당한다. 즉, 실무가 업무에 집중할 수 있고 장애물이 없도록 하는 것이 수석엔지니어 리더의 역할이다. 그리고 이제 시간이 남는다면, 문제가 뭔지 스스로 찾아보고 파악해보면 된다 (이 때도 실무에게 묻지 않는다, 지금 실무담당자는 바쁘다!)
같이 좀 봐주세요
이 이슈는 조금 더 많은 개발자들의 도움이 필요하다고 수석엔지니어 리더가 판단 했을 때, 지원하라는 의미로 다른 팀원들을 할당할 수 있다. 이것 좀 같이 봐주세요.
하지만 모두가 각자 본업이 있기 때문에, 이슈를 같이 보기 시작한다고 해서 갑자기 도움이 되는 것은 아니다. 그들도 해당 업무에 대해 러닝커브가 필요하고, 진행경과를 따라잡을 수 있는 시간이 필요하다.
따라서 이슈가 생길때마다 사람을 투입하는 것은 괜한 낭비가 되는 경우가 더 많다. 차라리 원래 담당자들이 시간을 갖고 봤을 때 해결되는 경우가 더 많았기 때문이다. 그래서 개인적으로는, 조금 더 원 담당자들을 믿고 기다려주는 편이다. 내가 시니어엔지니어일 때 "모두가 모든 이슈를 같이 보는" 문화에 진절머리가 났기 때문에, 수석엔지니어가 되고나서는 이런 지시는 안 하려고 하는 편이다.
개발팀에게 이슈는 늘 있는 존재이고, 밥 먹듯이 이슈분석과 해결을 하고 있다.
간단한 정적분석이슈부터, 재현도 어려운 QA이슈나 베타테스터이슈까지 매번 터진다.
수석엔지니어 리더는 전반적으로 이슈를 조금은 여유롭고 느긋하게 바라볼줄 알아야 되고, 호들갑 떨지 않는 편이 좋다. 어떤 이슈가 나오더라도 개발팀에 해결에 필요한 인사이트를 줄 수 있도록, 평소에 실력을 갈고닦는(?) 것이 중요하다.
