서비스 장애가 나면 개발자들은 정해진 순서를 밟습니다. 먼저 제보받은 문제를 자기 화면에서 똑같이 재현해 보고, 재현되면 곧바로 팀에 알려 대응 채널을 엽니다. 그다음 로그를 뒤져 단서를 찾고, 가장 최근에 바뀐 것부터 용의선상에 올려 범위를 좁힙니다. 원인이 잡히면 이전 버전으로 되돌릴지, 문제가 된 부분만 고쳐 급히 배포할지를 정합니다. 복구를 확인한 뒤에는 보고서를 쓰고, 며칠 지나 회고를 합니다.
기획자 눈에는 멈춘 화면 하나지만, 저쪽에서는 이 순서가 돌아가는 중입니다. 그래서 이 글에는 반대편을 적어보려 합니다. 그 시간 동안 기획자는 뭘 해야 하는가.
먼저 하지 않는 편이 나은 것부터. 진행 상황을 반복해서 묻지 않는 게 좋습니다. 수만 줄짜리 로그를 훑는 일은 집중이 한 번 끊기면 처음부터 다시입니다. 원인을 캐묻는 것도 아직입니다. 그 시점의 개발자는 원인을 모르는 게 정상이고, 모르는 것을 설명하라고 하면 추측이 나옵니다. 추측은 나중에 번복되고, 번복된 말은 신뢰를 깎습니다. 회의 소집은 특히 위험합니다. 복구할 사람을 회의실에 앉히면 복구가 딱 그만큼 늦어집니다.
대신 할 일이 꽤 많습니다. 우선 영향 범위를 파악해야 합니다. 전체가 멈춘 건지 일부 기능만인지, 하필 결제처럼 돈이 걸린 자리인지. 이건 “뭐가 문제예요?”가 아니라 “얼마나 커요?”로 물으면 짧게 답이 옵니다. 원인을 설명하는 건 어렵지만 규모를 말하는 건 그 와중에도 어렵지 않거든요. 그 답이 있어야 이해관계자에게 알릴 수 있고, 대외 공지 문안도 미리 써둘 수 있습니다. 복구된 다음에 공지를 쓰기 시작하면 늦습니다. 플랜B도 이때 세웁니다. 오늘 예정이던 다른 일정을 미룰지, 범위를 줄여서라도 갈지. 그리고 제보를 처음 받은 게 기획자라면, 어떤 계정이 몇 시에 무엇을 눌렀을 때 어떻게 됐는지 정리해 넘기는 것만으로 재현에 걸리는 시간이 크게 줄어듭니다.
복구가 끝나면 회고가 남습니다. 여기서 프레임을 잡는 일은 대체로 기획자 몫입니다. “누가 그랬나요”로 시작하면 다음부터 사람들은 실수를 숨깁니다. 대신 왜 그럴 수밖에 없었는지를 물어야 합니다. 테스트가 부족했다면 왜 테스트를 쓸 시간이 없었는지까지 따라 들어가야 하고요. 책에도 같은 원칙을 적었습니다. “사람이 아닌, 시스템과 문제를 비난하라.”
솔직히 저도 장애 한복판에서 이걸 다 지키지는 못합니다. 화면은 멈춰 있고 위에서는 언제 되냐고 묻는데, 아무것도 묻지 않고 기다리는 일은 생각보다 어렵습니다. 다만 그 시간에 조급해서 했던 일들이 복구를 앞당긴 적은 별로 없었다는 것 정도는 이제 압니다.
장애가 아니어도, 개발자와 말이 어긋나는 자리는 대개 비슷한 모양이더군요.