Agile 방법론을 제대로 배우기 이전부터 개인이나 팀이 했던 일을 돌아 보았는데, 이런 일을 아주 오랫동안 두리뭉실하게 ‘review’ 라고 불렀다.
Monthly review, Quarterly review, OKR rating / planning 등..
리뷰에 관련한 건 다음 토픽으로 남겨 두기로 하고, 이 글에서는 구체적인 ‘돌아봄’에 해당하는 두 단어에 대한 이야기를 해보자.
Retrospect(회고)
Agile – Sprint 에서 주로 쓴다.
Google에서의 좋았던 경험으로는 두 가지가 있었다.
1) 큰 과제를 정신없이 달려와 런칭한 후 축하 파티 하기 직전에 했던 것
2) 과제가 삐걱거리면서 하다가 재정비를 위해 잠깐 쉬면서 했던 것
관리자 입장으로 좋았던 건, 다음 일감을 계획하기에 좋은 정보들이 모이기도 했던 것.
반대의 입장일 때는 억지로 불편한 걸 이야기해야 하는 상황이 생겼던 것.
What went well 과 what could be better 라는 용어로 기록을 남겼는데, 직접 대화를 할 때 확실히 효과가 컸었다.
한국 업계로 들어오면서 ‘회고’라는 이름으로 불리는 걸 알게 되었다.
참고로 회고의 영어 번역은 아래와 같이 여럿이다.
retrospect가 명사이기도 해서 retrospection 이라는 표현은 생소했고, remembrance, reminiscence 라는 표현은 좀 더 익숙했다.
그래서 처음에는 ‘회고’를 ‘퇴고’로 듣기도 했다.
한국에서 접한 회고는 이랬다.
1) 2주마다 매 sprint 를 치르며
2) 의무적으로 회고를 하고
3) 모두가 발언을 하기를 기대하며
4) 꽤 길고 감정 소모가 심했던 것 같다.
그래서인지 scrum 이나 sprint 를 잘 운영하는 사람에 따라 편차가 심했던 거 같다.
생각해 보면 미국에서는 조금 편한 편이었는데, 짧은 영어때문이 아니었을까 싶다.
감정 소모를 덜 하게 되지 않았을까라는 생각이 들었다.
Postmortem (사후 검토, 부검)
Google 에서 일하면서 사고를 몇 번 낸적이 있었다.
이런 일은 꽤 있는 편이어고 아주 드물진 않았다.
그 때마다 Postmortem 이라는 곳에 초대되었다. (https://sre.google/workbook/postmortem-culture/)
내가 만든 혹은 남이 낸 사고에 보호 코드를 만드는 이슈를 할당 받기도 했다.
주로 SRE 들이 호출하는데 그닥 유쾌한 기억은 아니었다. ( 어떤 건 나무위키에 박제되어 있기도… )
lesson 을 모아서 다음에 같은 사고가 생기지 않게 하자는 의미인데, 이런 이슈들은 꽤 중요하게 처리된다.
특히 ‘운용’ 단계의 과제들은 더욱 그렇다.
이 문서에 이름이 올라간다고 해서 불이익이 생기거나 편견이 생기는 건 아니었지만, 무서운 단어임에는 변함이 없다.
한국에서도 사고들이 생기면서 SRE 가 없더라도 기록을 남기고자 했다.
그런데 Postmortem을 해보니 한국에서는 조금 더 무서운 번역이 되었다.
“사후 검토”이라는 게 죽을 사(死)가 아닌 일 사(事)이겠지만, 한자 표기 없이 불리다보니 ‘부검’으로 더 많이 불렀다.
그래서 별 고민 없이 ‘사후 부검’, 혹은 ‘사후 검토’라고 했을 때 죽을 사(死)가 먼저 어른어른 거렸다.
한국 정서로는 (원래 취지와는 다르게) 시말서, 경위서에 더 가까운 것 같다.
그래서 조금 더 불편하고, Action Item 들에 대한 강제력이 회사 규모 따라 달라서 어려웠다.
운영팀들에게는 분명 도움이 되겠지만, 해야 할 일들이 생기면서 “그냥 기도하자”, “그냥 버티자”라는 상황도 나왔다.
테크 이외의 조직들이 엮이면 난이도까지 많이 올라갔다.
최근에 여러 뉴스에서 보이던데, 본인의 의지와 관련없이 사고와 사투를 벌이는모든 분들께 무운을 빈다.
