Q.강의에서 소개한 책 중 『개발 7년차, 매니저 1일차』라는 책이, 제 상황과 같습니다. 권한을 잘못 휘둘러 새싹 같은 귀중한 아이디어를 짓밟는 실수를 할까 조심스럽습니다. 이 단계에서 가장 경계해야 할 점이 있다면 무엇일까요?

A.

요즘 저 스스로 가장 경계하고 있는 건 ‘보고(reporting)’입니다. 중간 관리자로서 ‘보고를 받고 있다’는 상황이 있을 때는 뭔가 잘못된 신호라고 생각하고 없애려고 합니다. 내가 보고를 받는다는 건 누군가가 보고를 준비하고 있다는 의미며, 그만큼 본연의 업무에 집중하지 않고 포장에 신경을 쓴다는 의미일 수도 있습니다. 

물론 저 스스로도 보고자료를 만드는 입장에서, 보고의 좋은 점도 있습니다. 논리를 더 닦을 수 있고 리서치를 더 하게 됩니다. 

질문자 분도 공감하시겠지만, 그럼에도 보고에는 크게 두 가지 문제점이 있습니다. 기한이 정해져 있다는 것과 보고한 후에 전향적으로 바꾸기 힘들어진다는 점입니다. 새싹 같은 아이디어는 유연함과 거친 성질을 잘 보존해야 하므로, 언젠가 ‘내가 뭐라고 보고를 받고 있지?’라고 반문하며 보고하는 프로세스를 없애보시길 추천합니다. 보고 프로세스보다는 그들의 슬랙 채널이나 대화 흐름에 좋은 질문을 해며 자연스럽게 흐름에 스며들어보기 바랍니다. 그러면 더 날 것의 정보를 언제든 알 수 있다는 장점이 생깁니다. 이는 제 발표에서도 언급했듯 ‘내 손가락만 움직이면 정보는 언제든 나에게 닿을 수 있는 상태’를 유지하는 것이고, 이로써 동료들을 덜 귀찮게 하고 아이디어와 실험에 집중하도록 할 수 있습니다.

Q.불편한 점에 대한 자동화는 고민한 적 있지만, 내가 저런 인사이트를 가졌던 적이 있었던가? 앞으로도 있을 것인가? 이런 생각이 들었던 강의였습니다. 자동화 도입의 길이 헌신의 영역에 가깝다는 부분은 개발자님의 경험담이려나 싶지만, 아쉽기도 했습니다. (편집자 주 : 헌신의 영역이 아니라 정당한 업무와 성과로 인정받을 수 있는 방법이 없을까요?)

A.

저 역시 3년간 자동화로 프로세스를 개선하면서 해왔던 고민입니다. 첫 시작은 누군가의 비정량적인 투자가 있어야 하며, 이는 어쩌면 변화를 만들어내는 물리력이라고도 생각합니다.

그걸 스스로가 아깝다고 생각하면 변화를 못 만들고 현재 프로세스에 불만만 가진 사람이 되는 것이고, ‘못 참겠다. 그냥 내가 하자’고 하면 변화를 만드는 사람이 되는 것의 차이입니다. 다만 희망적인 건, 1년 반 정도 하면 나만의 방법론이 점차 자리잡게 된다는 점입니다. 일이라는 게 다 그렇듯 그 후에는 재생산이 가능하고 셀프참조(자신이 만든 걸 다시 참고하는⋯)도 되어 갑니다. 다시 말해 남들에게 전파할 수 있게 됩니다. 그래서 2년차가 되었을 때는 제가 개선해온 부분과는 달라도 방법론이나 관점은 그대로 가지고 자신들의 영역에서 개선해 나가는 동료들이 여러 명 나왔습니다. 

인사이트를 가지는 건 절반은 경험, 절반은 감각 같습니다. 경험은 말 그대로 더 쉽고 군더더기 없이 일했던 과거의 경험과 현재의 격차를 줄이는 노력이 되겠고요. 감각이라 함은 곧 센스이며, 스스로가 센스를 발휘하는 영역은 누구에게나 있다고 봅니다. 예를 들어, 저는 슬랙에서 나오는 중복된 대화나 업무 프로세스에 유난히 민감하지만, 질문자 분께서는 오래 걸리는 릴리즈나 버그 찾는 데 걸리는 시간을 줄이는 데에서 더 나은 센스를 발휘하실 수도 있습니다.

질문을 다시 보고 답을 드리자면 ‘자동화를 도입합시다’라는 선언이나 프로젝트 설정만으로는 도달 못하는 수준이 있습니다. 자동화를 도입했지만 전반적인 업무 프로세스는 개선 안 되는 경우가 대부분이었습니다. 큰 회사든 작은 회사든 ‘의미 있는’ 변화를 만드는 데 한 사람의 댓가 없는 헌신은 필요했습니다. 어쩌면 그 초반의 댓가는 스스로의 만족감인지도 모릅니다.

Q.마지막으로 생산성 자동화에 대한 정량적 평가가 어렵다고 하셨습니다. 이 부분에 대해 솔루션을 제시한다면, 먼저 생산성에 대한 definition의 range를 정하시면 그 range에서의 생산성 평가 리스트를 만들어 놓고 그 리스트를 체크해 보시면 되지 않을까 생각됩니다. 어떻게 생각하시나요?

A.

대부분의 생산성 향상이나 효율화 프로젝트는 말씀대로 진행됩니다. 하지만 대체로 ‘프로세스 개선’까지 이루는 데는 실패합니다. 그 이유는 조직과 상황마다 복합적이겠지만 제가 봐온 바에 의하면 현재의 프로세스를 너무 존중하면서 만들어지기 때문입니다. 아주 조금 변하거나, range/list에서 언급된 사항과 수치만 맞추려고 전체가 더 비효율적으로 변하기도 한다는 것이지요. 

실제 사례를 들자면, 최근 어느 팀은 의사결정의 혼란을 줄이기 위해 의사결정 정례 회의를 만들었고, 이로써 업무의 의사결정은 대법원마냥 1년에 50번 정도만 이루어지게 되었습니다. 이 회의체는 투표 집계를 효율화하기 위해 투표 프로그램을 회의에서 사용했습니다. 투표결과를 집계하는 건 자동화되었지만, 전체로 볼 때는 그것이 프로세스를 개선했다고 보기는 어려울 것입니다. 

대부분의 효율화 프로젝트는 이런 모습과 그리 다르지 않습니다. 더 근본적으로 회의를 없애든, 조직을 바꾸든, 의사결정까지 일어나는 대화 채널이나 업무 문화를 개선하든, 이는 range/list 등을 정하고 지워나가는 것보다는 스스로가 구성원들에게 시도와 증명을 해가며 변화를 설득하는 비정량적인 과정을 겪어야 하더군요. 

질문을 다시 돌아와서 보면, 어쩌면 range/list에 넣는 항목을 만드는 과정(definition)에서 이미 ‘적당히 가능한 수준’의 것들만 넣기 때문에 문제 해결을 못하는지도 모릅니다. 생산성을 자동화하는 일은 어느 시점을 정해놓고 ‘개선을 개시합니다!’ 같은 방법이 아니라 계속 은은하게 해야 하다 보니 프로젝트화 하기엔 애매하고, 수치화/정량화하기에도 상황에 따른 역동성이 떨어지는 특징이 있습니다.

Q.Q. 이직하고 7개월째입니다. 조직개편으로 갑작스레 팀장이 되었습니다. 아직 팀장 짬이 없지만 IT가 주류인 회사가 아니어서(업무 외 방침 등에 간섭할 만한 인원이 적은 때문에) 팀 내 권한은 적지 않게 부여되어 있습니다. 의욕과 권한이 있을 때, 작은 목표나마 불편한 점을 자동화하는 방법을 고민해보고 싶어졌습니다. 에러 로그를 푸시 서버를 통해 알림 받거나, 반복적인 에러에 대한 간단한 규모의 자동화 같은 것으로요. 혹시 제 시점에서 주의해야 할 점이나 필요한 조언이 있다면 부탁드리고 싶습니다.

A.

먼저 영전 축하합니다. 주의할 점을 두 가지 말씀드리자면, 먼저 스스로가 일관된 방향으로 개선해야 한다는 점입니다. 예를 들어, 뭐든 절대적인 시간을 줄이는 방향으로 개선하든, 한 팀의 수작업만 없애기 위해서 개선하든, 슬랙으로 처리할 수 있게 개선하든, permalink로 확인할 수 있게 개선하든, 하나의 빌드 서버에 몰아넣어서 작업하든, 그래프로도 볼 수 있게 개선하든. 이렇게 일관된 방향을 가지면서 몇 개월 꾸준히 개선하면 모두가 자신이 개선하는 방향을 기대하고 응원하고 변화에 불안해하지 않습니다. 어쩌면 이것이 스스로의 ‘스타일’이자 방법론이 될 것입니다. 

두 번째로, 이미 했던 개선을 계속 꾸준히 개선해야 한다는 점입니다. 알림 메시지를 하나 만들었다면, 그 다음엔 문구를 수정하거나, 링크를 추가하거나, 색상을 추가하거나, 옵션을 넣거나 등 계속 책임감을 가지고 개선해야 합니다. 이 점이 대부분의 프로세스 개선을 노력하는 사람들이 실패하는 지점입니다. 

저는 발표에서 100여개의 자동화 스크립트를 만들었고 운용 중이라고 했습니다만 보안 업데이트, 패키지 업데이트, 리팩토링, 문서화 등을 꾸준히 하면서 남들도 더 쉽게 쓸 수 있도록 닦고 또 닦고 있습니다. 그렇지 않은 노력은 대부분 ‘스크립트 쪼가리’에 끝난다는 걸 아셔야 합니다. 번거롭더라도 수정해 나가야 시간이 지날수록 적어지고 완성도는 높아지고 쓰임새도 많아질 것입니다. 이 귀찮음을 스스로가 극복한다는 건 어쩌면 공부도, 사업도, 매니징도, 사람 일이란 건 매한가지인거 같습니다. 

말을 마치며 예를 하나 들자면, 저는 위키(wiki)에 릴리즈 노트를 자동으로 만드는 작은 스크립트를 만든 적이 있는데요, 릴리즈 노트에 해결된 이슈뿐 아니라 다운로드 링크, 협력사의 이슈, 안내 문구 등을 노출하는 기능을 넣다보니 지금은 나름의 규칙으로 위키 내용을 저작하는 수준이 되었고 이는 회사 위키의 자동 생성된 리포트가 일관된 형식과 품질로 만들어지게 하는 프로세스가 되었습니다.