무엇이 운영을 정착시키는가

종종 새로운 운영(Operation)을 추가하곤 한다. 실수가 발생하지 않도록 동료가 다시 한번 리뷰하는 프로세스를 만든다거나 하는 식이다. 이러한 리뷰 프로세스 외에도 다양한 운영들이 조직마다 제각각으로 있을 것이다.

직장인이라면 운영이 생겨나고 사라지는 것을 옆에서 지켜본 경험이 누구나 있을 것이다. 우리 조직에서도 종종 새로운 운영이 추가되곤 하는데, 어떤 운영은 잘 정착을 하는 반면, 어떤 운영은 처음에만 반짝 떴다가 시간이 지나면 유명무실해지고, 결국 이름만 남아있거나 사라진다. Slack에 매일, 혹은 매주 오는 알림에 아무도 호응하지 않는 것을 다들 본 적 있을 것이다.

나는 종종 새로운 운영을 만들곤 하는 사람이기 때문에 무엇이 이 차이를 만드는지에 대해 관심이 많다. 지금까지 성공적으로 정착한 운영들과 정착에 실패한 운영들을 본 바, 변수로는 공감, 연속성, 개인의 이익, 의지력 정도가 있는 것 같다.

모두가 공감하는 운영은 수월하게 정착한다. 채용 프로세스, 주간 회의와 같은 거의 모든 회사들이 가지는 운영은 다들 익숙하기도 하고, 필요성에 대해서도 공감하고 있기 때문에 도입이 어렵지 않다. 반면, 의외로 코드 리뷰와 같은 운영은 어떤 조직에서는 공감대가 없어 도입에 어려움을 겪기도 한다.

업무와 연속성이 떨어지는 운영은 정착이 잘 안 된다. 대표적인 예시로 문서화가 있다. 개발자들이라면 누구나 공감할 텐데, 문서화를 해야 하고, 하면 좋다는 것을 아는데도 불구하고 문서화는 정말 잘 챙겨지지 않는다. 코딩이라는 일과 문서화라는 일 사이에는 큰 간극이 있고, 문서화에 대한 강제성이 없다면 코딩만 하고 일을 마칠 수 있기 때문이다. 그래서 차라리 이 간극을 좁히기 위해 코드로부터 문서가 만들어지도록 하는 노력을 하기도 한다.

구성원에게 이익이 있는 운영은 더 쉽게 정착한다. 개발자에게 문서를 잘 업데이트해 달라고 했을 때 잘 업데이트되는 문서가 있고 아닌 문서가 있다. 문서를 업데이트하지 않아서 반복적인 질문을 많이 받고, 문서를 잘 업데이트했더니 질문을 덜 받게 되면 높은 확률로 문서를 잘 업데이트하게 된다. 어감이 좋지 않은 것 같긴 하지만, 책임을 남에게 전가할 수 있는 운영도 잘 지켜질 확률이 높다. QA 프로세스 혹은 상위 조직장에게 의사 결정을 맡기는 프로세스와 같은 것들이다.

마지막으로 누군가가 강력한 의지력을 갖고 추진하는 운영은 잘 정착될 가능성이 높다. 보통은 상위 조직장이 도입을 추진하는 경우가 많고, 꼭 상위 조직장이 아니더라도 운영이 자리 잡을 때까지 끈기 있게 계속 주변 사람들을 설득하여 정착에 성공하는 경우도 있다. 아예 기존 업무 프로세스에 강제로 끼워 넣으면 더 확실하다. 예를 들어, 보고서 작성이라면 작성한 보고를 공유하고 끝내는 게 게 아니라 주간 회의에서 항상 그 보고서를 기준으로 논의를 하는 식으로 하면 보고서를 작성하지 않을 수가 없다.

다르게 말하면 동료들로부터 공감받지 못하고, 원래의 업무와 연속성이 없고, 개인에게 이득도 없고, 누군가의 의지도 없는 운영은 정착하기 어렵다. 사람들이 운영을 잘 지켜줄 것이라는 선의에 기대면 반드시 실패한다.

이러한 변수를 고려하여 운영을 도입하기 전에 미리 생각해 보니 운영이 잘 될 지에 대한 예상이 훨씬 더 잘 되는 것 같다. 그리고 공감, 연속성, 개인의 이익 모두 만족시킬 수 없지만 반드시 필요하다고 생각하는 프로세스가 있다면 나 혹은 다른 누군가가 의지력을 갖도록 만들어서 성공률을 높일 수 있다.