Player Unknown’s Bug: 원인 모를 문제를 기록하면 성장할 수 있나요?
(engineering.ab180.co)우연한 계기로 만든 이슈 페이지를 통해, 팀의 심리적 안정감은 높이고 정보 공유는 늘려 견고한 조직과 서비스를 만들어가는 이야기를 공유드립니다.
개발을 하다 보면 원인 모를 문제를 만나곤 함.
특히 웹 프론트엔드는 서버 등의 상태 외에도 브라우저의 종류나 버전, 크롬 익스텐션 등 수많은 외부 요인에 영향을 받음.
만약 문제의 원인을 모르거나, 문제의 원인이 우리에게 없다면, 포스트모텀만으로 단단한 구조를 만들 수 있을지 문득 의문이 들었음 (부족하지 않은지?).
계기
원인을 알 수 없는 이슈를 리포팅 받고 종결처리 하는 데까지 9시간이 걸렸던 적이 있음.
이슈 디버깅에 4시간을 할애하고 나서야, 문제의 원인이 내부 코드나 인프라에 있지 않고 사용자의 Chrome Extension의 버그로 발생했다는 것을 알게 되었음.
문제의 원인이 어디에 있는지 파악하기도 어려웠지만, 원인이 외부에 있음을 파악하기까지 무려 4~5시간이 걸렸다는 것에 스스로에게 화가 났음.
Notion에 ‘Player Unknown’s Bug(PUB)’ 라는 페이지를 만들고, 분노와 함께 이슈를 대응하며 시도한 것, 아쉬운 것, 보완하면 좋을 것 등을 정리함.
문화로의 정착, 그리고 발전
회고하며 이슈의 원인, 찾아보며 부가적으로 알게 된 것, 오판한 지점 등을 이야기했음. 팀원들은 궁금한 점과 개선하면 좋을 지점들을 짚어주셨고, 그 부분을 모아 장애 대응 프로세스를 정립했음.
이 과정이 좋았던 것이, 이슈 대응 과정에서 느꼈던 어려움을 팀원들이 공감해주었고, 새롭게 알게 된 것을 공유하는 재미가 있었음. 또한, 체크리스트를 만들어 비슷한 상황이 오면 더 빠르게 문제를 파악할 수 있게 되었음. 팀에 이야기하여 정식 문화로 채택됨.
AB180 개발 조직은 기본적으로 ‘포스트모템’을 진행하고 있음. 사내 포스트모템이 Resolution과 Action Items이 중심이라면, PUB는 Lesson Learn, 이슈 대응에 대한 심리적 안정감 형성, 알 수 없는 문제에서 먼저 확인할 요인들을 정리하는 것이 목적.
정보를 자발적으로 공유하는 문화
팀에 정착하면서 다른 팀원들이 대응한 이슈들도 하나 둘씩 쌓이기 시작함.
회고를 하면서 몰랐던 부분을 이야기하고, 더 깊이 파보는 시간이, 작지만 자발적인 '지식 공유 세션'처럼 운영되기 시작함.
이 문화를 조금 더 키워보기 위해 배운 것, 알게 된 것을 수시로 공유하는 Slack 채널을 운영하고 있음. 아직까지는 잘 운영되고 있음.
Lesson Learn
- 장애를 대응한 팀 전체의 심리적 안정감을 높여야하고, 그러기 위해서는 더 많은 이야기를 나눠야한다.
- 그렇지 않았을 때, 문제는 반복되며, 조직 내에 ‘문제 = 말하면 안 되는 것’이라는 생각이 자리 잡는다.
- 정보의 공유를 통해 조직의 심리적 안정감을 만들고, 심지어 높이는 것이 가능하다.
- 그리고 이러한 정보 공유 문화는 생각보다 별 거 아닌 것으로 시작할 수 있을지도 모른다.
저는 반대로 오늘 특정 외부 요인이 원인으로 아주 명확하지만 내부 사정으로 쉽사리 조치할 수 없다고 여겨 발만 동동 구르던 장애가 사실 설정 파일 한 줄만 바꿔주면 해결되는 것이었다는 케이스에 하루종일 시달리다 퇴근했습니다. 이 글을 보니 정말 도움이 되는군요.
오늘 하루도 정말 수고하셨습니다. 그래도 문제를 해결하셨다는게 다행이에요. 위의 글에서 적었던 문제들도 가끔 생각날 때가 있어요. 그때는 힘들었지만 지금은 즐겁게 받아들일 수 있는 것 같아요.
kunggom님께서 오늘 겪은 힘든 일도 시간이 지나면 즐겁게 생각할 수 있지 않을까요? ㅎㅎ
부족한 제 글을 읽어주셔서 감사합니다.
사실 예전이나 지금이나 장애 처리로 힘든 걸 즐겁다고 생각해본 적은 없습니다.
예를 들면 오늘 처리한 장애도 하필 저희 팀에서는 운영 서버에 대한 직접 접근이 막혀 있던 제품에서 발생한 것이라, 장애를 발견하고 현상 파악을 진행하던 초반부와 서버 접근 권한을 간신히 얻어낸 후반부를 제외하고는 상대적으로 무기력할 수밖에 없었습니다. 저희 팀에서 이러이러한 조치를 해달라고 부탁하면 서버 운영 팀에서는 그쪽 사정으로 거부했거든요. 그런 무기력함을 즐겁게 받아들일 수는 없지요.
그래서 퇴근 전까지 포스트모템 문서를 작성하며 느낀 건 차라리 ‘더러워서라도 다음부터는 이런 실수 안 한다!’에 더 가까웠던 것 같습니다.
말씀해주신 내용을 들으니 많이 힘이 드셨겠다는 생각이 듭니다. 말씀해주신대로 같은 실수를 안하게 되면서 조금씩 나아갈 수 밖에... ㅠ
사실 해당 제품은 상당히 오래된 레거시 제품이고, 인수인계 받은 지 얼마 되지 않았으며, 받자마자 기능 변경 소요가 들어와서 최근 코드를 수정은 한 적이 있지만 오늘 발생한 장애와는 아무런 관련이 없는 부분이었습니다. 그래서 실제로 문제가 된 부분은 제가 직접 작성한 내용은 아니었습니다만, 해당 제품을 좀 더 속속들이 알고 있었더라면 더욱 빨리 문제를 해결할 수 있었겠지요. 그게 참 아쉬워요.
그리고 애초에 전면 장애상황을 확인하고 나서 처음에 확신했던 원인에 대한 추정은 사실 절반만 맞는 것이었고 말이죠. 그 추정에 대한 확신이야말로 오늘의 진정한 실수였지 않나 생각합니다.