범인을 찾지 말고, 일단 문제를 해결해요.
회사 생활은 크고 작은 사고의 연속입니다. 서비스 플랫폼 기업의 프로덕트에 관여하는 기획자, 디자이너, 개발자, 마케터 등등 언제나 잘못된 의사결정을 내리기 마련이고 실수를 합니다. 우린 인간이니까요. 간혹 수습이 쉬운 시시껄렁한 실수도 있지만 그 정도로 끝나지 못할 수 있습니다. 높은 사람에게 불려 갈 수도 있고 업무 폭탄을 맞을 수도 있어요. 생각만 해도 지옥 같네요.
하지만 그 정도의 일을 어물쩍 넘어가는 건 더더욱 안될 일이에요. 인간은 그런 실수들이 모여 커다란 가치를 만들어내 왔고 그 결과로 지금의 굴지의 기업들이 탄생한 것이니까요. 반드시 돌아보고 그 이유를 찾아서 늦었지만 시스템을 구축해야 합니다.
작년 10월에 대한민국을 강타한 카카오 데이터센터 화재 사고를 회고한 세션에서 따온 슬라이드입니다. 그중 가장 와닿았던 문구예요. 우리가 집중해야 할 것은 돌아보고, 다시는 이런 문제를 겪지 않도록 예방하는 것입니다.
상황을 가정해 볼게요. 당신의 팀에서 엄청난 실수가 발생했어요. 누군가의 잘못된 의사결정과 삽입된 몇 줄의 문구와 코드 몇 줄로 회사는 1억 원의 금전적 손실을 입었고 회사는 고객의 신뢰를 잃어 금전적으로 환산할 수 없을 만큼의 수치상 손실을 입었습니다. 이 상황에서 누구의 책임인지 잘잘못을 따지는 게 과연 중요할까요?
지금 해결해야 할 문제는 누가 이 작업을 지시했는지, 누가 시발점인지, 누가 마지막 배포 버튼을 눌렀는지 등의 경위가 아니라 문제를 수습하는 것입니다. 이 과정에서 이따 보자라며 으름장이라도 놓는다면 수습이 잘 될 리 없습니다.
당연히 실수를 반복하는 것은 그 사람의 역량이라 볼 수 있습니다. 단순히 꼼꼼하지 않거나, 능력이 없지만 가당치 않은 업무를 부여받았을 수도 있고, 소통이 없어서 쉬운 문제도 어렵게 풀다가 꼬여버렸을지도 모릅니다. 다만 그 실수를 비난하고 책임을 물면 그 사람은 더 이상 도전적인 일을 하지 않을 거예요.
누가 손해만 보는 곳에 투자를 하겠습니까. 어느 정도 안정적인 곳에 하죠. 업무도 똑같습니다. 일을 하는 과정에서 실수할게 뻔하고, 실수하면 비난만 받는 환경에서 그 누구도 도전적이고 어려운 일에 참여하고 싶지 않을 겁니다.
사람을 탓하지 말고 시스템을 탓하라는 말이 있어요. 아무리 실력 좋은 사람이 있어도 그 사람 컨디션이 안 좋을 수도 있고, 부재중일 수도 있습니다. 언젠가 퇴사할 수도 있잖아요. 어떤 사람이 오더라도 해당 업무가 흘러갈 수 있고 실수에 대처할 수 있도록 하는 시스템이 필요합니다.
시스템은 두 가지로 나눠볼 수 있어요. 인프라에 해당하는 기술적 시스템과 사고 발생 직후 처리에 대한 프로세스를 말하는 업무적 시스템을 말해요.
기술적 시스템은 정말 중요해요. 어차피 그 실수가 발생한 프로덕트 단에서 사용자가 보는 영역은 개발자가 컨트롤할 수 있으니까요. 문제가 생기거나 잠재적 문제를 감지했을 때 즉각 이전 스테이블 버전으로 롤백할 수 있는 인프라, 개발자들에게 실수를 두려워하지 않고 개발할 수 있는 힘이 되어줍니다.
자동화 테스트 도구도 그 일환입니다. 아무리 작은 변경이라도 어떤 변화를 가져올지 장담할 수 없습니다. 실제로 간단한 수정이라고 생각해서 배포한 내용이 앱을 죽이기도 하니까요. 하지만 매뉴얼 한 테스트는 노동입니다. 이러한 테스트는 자동화된 시스템으로 해결할 수 있어요. 기능 추가나 수정, 리팩터링 같은 모든 행동들에 테스트 환경이라는 든든한 인프라가 지켜줘요.
개발자만 실수하는 게 아닙니다. 기획자, 마케터 등의 잘못된 의사결정도 실수라고 볼 수 있어요. 정량적 데이터뿐만 아니라 정성적인 데이터들도 이를 방증하니까요. 벌써 프로덕트에 반영된 의사결정을 컨트롤할 수 있는 플래그나 A/B테스팅 환경도 기술적 시스템의 일환입니다.
이밖에 Saas로 판매하는 많은 도구들이 속한다고 볼 수 있어요. 많은 부분을 직접 감내하기 위해 직접 구현하거나 수작업으로 일일이 작업하는 것보다는 어느 정도 잘 만들어진 자동화 툴을 통해 실수를 줄이고 책임을 그 서비스에 전가할 수 있습니다.
업무로서 사후조치 시스템이 있고 없고의 차이는 실무자의 사고방식에 큰 영향을 준다고 생각해요. 사고의 규모에 따라 간단한 문서 한 장으로 정리할 수 있는 내용일 수도 있고, 몇 장의 보고서가 될 문제일 수도 있어요. 수준이 어떠하든 양식에 맞춰 기록하고 모든 이해관계자에게 전파하고 다시는 같은 사고가 일어나지 않도록 하는 일련의 프로세스가 있어야 합니다.
저도 이런 시스템의 정착을 위해 현재 속한 조직에서 쓰는 문서 관리 도구에서 사후처리, 히스토리 문서 템플릿을 만들었어요. 간단하게 문제가 발생하면 노션에 문서 하나를 만들고 사후처리 템플릿을 클릭하면 아래와 같은 문서를 볼 수 있고, 내용을 빠르게 기록하고 공유만 하면 되는 시스템이에요.
##현상
// 구체적으로 어떤 문제가 있었는지 써주세요 (되도록 타임라인이 있으면 좋습니다)
## 기록물
// 스크린샷, 로그, 슬랙 메시지 등 히스토리는 최대한 남겨주세요
## 대응 // 어떻게 대응하셨나요?
## 대응 방지책 // 다시 발생하지 않으려면 어떻게 해야 할까요? 있다면 적어주세요.
어쩌면 하지 않아도 될 페이퍼 워크를 한 단계 추가한 것 같죠? 하지만 저는 이렇게 간단하게라도 발생한 문제나 실수에 대해 회고하고 동료들에게 나와 같은 실수는 하지 말라고 문서를 전달하는 프로세스는 필요하다고 생각해요.
하지만 궁극적으로 가장 중요한 건 그 조직의 문화입니다. 아무리 시스템이 잘 갖춰져 있고, 실력 좋은 사람들이 모여있다고 하더라도 분위기가 그렇지 않다면 말짱 도루묵입니다. 문화의 측면에서 리더가 실수한 사람에게 비아냥대거나 실수했으니 커피나 밥을 사라는 둥 건강하지 못한 문화가 자리 잡은 곳에서는 잘 만들어진 알량한 시스템 따위가 위력을 발휘할 수 없어요.
00 씨 왜 그러셨어요를 말하고 싶은 게 아닙니다. 어떤 과오에 대해 우리는 왜 이런 실수를 하게 된 걸까, 왜 이런 의사결정을 내렸을까, 어떤 시스템이 이 문제를 막을 수 있었을까. 생각해 보면 우리는 이 문제를 겪지 않을 수 있었는데 어떤 것이 부족해서, 사회적으로 발생한 어떤 문제 때문에, 기술적으로 어떤 점이 부족해서 등등 나름의 이유를 찾을 수 있어요.
문제의 범인을 찾으면 속은 시원할 수 있어요. 안도의 한숨을 쉴 수도 있고 문제 해결에 마음이 편해질 수도 있습니다. 하지만 문제를 해결하고, 더 도전적인 일들을 하기 위해서는 피해야 할 태도라고 생각합니다. 저도 많은 실수를 하고 제 동료들도 많은 실수를 하지만 비난하지 않고 문제 해결에 집중하는 태도가 그 집단을 성장시키는 것 같다고 생각합니다.
Copyright © HOJUN IN. All rights reserved.