제39화 — 매뉴얼

첫 고객의 시스템이 새벽 두 시에 멈췄다.

Helioxen 지원전화가 울렸다.

대니얼은 집에서 자고 있었다.

전화는 대니얼에게 오지 않았다.

지원담당자가 받았다.

고객은 작업이 멈췄다고 말했다.

상태코드.

로그.

지원담당자는 한 장짜리 대응표를 열었다.

해당 코드.

작업 재시작.

노드 하나 격리.

원격진단.

삼십 분 뒤 작업은 다시 돌아갔다.

대니얼이 이 사실을 알게 된 건 아침 여덟 시였다.

사무실에 도착하자 팀장이 말했다.

“밤에 고객 장애 있었습니다.”

대니얼의 표정이 굳었다.

“왜 저한테 연락 안 했습니까?”

“해결됐으니까요.”

“첫 고객인데.”

“그래서 지원팀이 해결했습니다.”

“원인은요?”

“노드 하나 메모리 오류.”

“하드웨어?”

“네. 교체 예정.”

“근본원인 분석은?”

“진행 중.”

대니얼은 불편했다.

자기가 몰랐던 여섯 시간.

그동안 고객 시스템이 멈추고.

팀이 대응하고.

복구됐다.

“보고체계는?”

팀장이 대니얼을 봤다.

“아침 보고로 정했습니다.”

“누가?”

“지난 권한회의에서요.”

또 자신이 만든 규칙.

대니얼은 한숨을 쉬었다.

“잘했습니다.”

말은 했지만 표정이 아니었다.

이선이 커피를 건넸다.

“왜 삐졌어?”

“안 삐졌습니다.”

“네가 없어도 해결돼서?”

대니얼이 컵을 받았다.

“고객이 피해 봤잖아요.”

“삼십 분.”

“삼십 분도 피해입니다.”

“그래. 그래서 고치면 되지.”

대니얼은 로그를 봤다.

지원담당자가 남긴 기록이 깔끔했다.

시간.

증상.

조치.

결과.

다음 행동.

“이 매뉴얼 누가 만들었습니까?”

“지원팀.”

대니얼은 매뉴얼 전체를 읽었다.

좋았다.

짧았다.

누가 새로 들어와도 이해할 수 있었다.

“전체 장애코드에 이런 거 있습니까?”

“아직 절반 정도.”

“이번 달 안에 다—”

말하다 멈췄다.

팀장이 웃었다.

“제안입니까, 결정입니까?”

대니얼이 피식 웃었다.

“질문입니다. 언제 가능합니까?”

“6주.”

“네.”

예전의 자신이라면 3주를 요구했을 것이다.

이번에는 이유부터 물었다.

“왜 6주죠?”

“실제 사례가 없는 코드가 많아서요. 문서만 보고 만들면 틀릴 수 있습니다.”

“그럼?”

“발생할 때마다 검증해서 채우고, 중요도 높은 건 시험으로 재현합니다.”

대니얼이 고개를 끄덕였다.

“좋습니다.”

지원담당이 말했다.

“대표님.”

“네.”

“한 가지는 바꿔야 할 것 같습니다.”

“뭡니까?”

“고객이 새벽에 전화하면 누가 최종책임인지.”

“지원팀 아닌가요?”

“큰 장애면요.”

대니얼은 생각했다.

장애대응 매뉴얼이 절반쯤 채워졌을 때, 지원담당자가 한 가지 제안을 했다.

“고객한테도 장애기록 일부 공개하죠.”

대니얼이 물었다.

“왜?”

“우리가 뭘 고쳤는지 알아야 안심할 것 같습니다.”

이선은 바로 찬성했다.

대니얼은 조금 망설였다.

제품 결함을 고객에게 더 자세히 보여주는 일.

마케팅 관점에서는 위험해 보였다.

지원담당이 말했다.

“어차피 그분들이 먼저 압니다. 자기 일이 멈추는데.”

정확했다.

숨길 수 있는 것도 아니었다.

그들은 월간 운영보고서를 만들었다.

가동률.

장애.

원인.

재발방지.

고객은 의외로 좋아했다.

특히 ‘아직 원인을 모르는 것’까지 표시한 부분.

사장이 말했다.

“모른다고 써도 되는 거야?”

대니얼이 말했다.

“모르는 걸 안다고 쓰는 것보다 낫죠.”

“그건 맞네.”

며칠 뒤 고객 측 엔지니어가 장애로그 하나에 댓글을 달았다.

자기들이 발견한 패턴.

특정 작업 뒤에 오류가 더 자주 난다는 것.

Helioxen이 놓친 정보였다.

양쪽 로그를 합치자 원인을 더 빨리 찾았다.

대니얼은 그 장면을 보며 생각했다.

제품을 만드는 회사와 쓰는 고객이 따로 있는 게 아니다.

운영단계에서는 고객도 시스템 일부가 된다.

그렇다면 정보 흐름을 한 방향으로 만들면 안 된다.

Helioxen → 고객.

고객 → Helioxen.

순환.

그 원칙은 훗날 훨씬 큰 공급망과 국제관측망에서도 필요해질 것이다.

그날부터 지원팀은 매뉴얼만 만들지 않았다.

실제 장애가 생길 때마다 ‘누가 먼저 알았는가’까지 기록했다.

센서.

자동경보.

고객.

지원팀.

발견속도를 비교했다.

대니얼은 숫자를 보고 놀랐다.

몇몇 문제는 자동경보보다 고객이 먼저 알아챘다.

“센서 더 달아야겠네요.”

지원담당이 말했다.

“어떤 센서요?”

대니얼은 대답하지 못했다.

무조건 센서를 늘리는 게 답은 아니었다.

어떤 문제를 잡고 싶은지부터 알아야 한다.

또 병목.

또 질문.

대니얼은 웃었다.

이제는 문제가 보일 때마다 짜증보다 호기심이 먼저 생기는 순간이 늘고 있었다.

중단권.

에스컬레이션.

누가 언제 깨워져야 하는가.

그들은 단계를 만들었다.

Level 1.

지원팀 자체처리.

Level 2.

기술책임자 호출.

Level 3.

고객 전체업무 중단 또는 안전문제.

그때만 Daniel 포함.

이선이 말했다.

“축하. 이제 잠 좀 자겠네.”

대니얼은 레벨3 기준을 계속 읽었다.

“너무 높은 거 아닙니까?”

“댄.”

“농담입니다.”

사람들이 웃었다.

그날 오후 고객 사장이 전화했다.

대니얼이 직접 받았다.

“밤에 죄송합니다.”

“뭐가?”

“시스템 멈춘 거요.”

“다시 돌았잖아.”

“삼십 분 손실이—”

“예전 시스템은 가끔 반나절씩 날렸어.”

대니얼이 멈췄다.

“그래도 개선하겠습니다.”

사장이 웃었다.

“그러라고 돈 주는 거지.”

통화 끝.

대니얼은 고객이 자신보다 훨씬 현실적이라는 생각을 했다.

완벽한 시스템을 사는 사람이 아니다.

고장나도 빨리 복구되는 시스템.

그게 더 가치 있을 수 있었다.

첫 삶의 행성방어는 고장나면 복구할 시간이 없었다.

그래서 완벽해야 한다고 생각했다.

그러나 평시 산업에서는 다른 철학이 가능했다.

실패하지 않는 시스템보다.

실패해도 빨리 돌아오는 시스템.

대니얼은 노트에 적었다.

Reliability includes recovery.

그 문장은 훗날 훨씬 더 큰 의미를 갖게 될 것이다.

그날 밤 대니얼은 휴대전화를 침대 옆에 두었다.

Level 3 아니면 전화가 오지 않는다.

처음에는 불안했다.

그래도 잠들었다.

아침까지 전화는 울리지 않았다.

지원팀은 장애대응 훈련도 시작했다.

실제 고객 시스템을 건드리지 않고, 복제환경에서 일부러 노드를 죽였다.

네트워크 단절.

디스크 오류.

잘못된 입력.

한 직원이 시간을 쟀다.

처음 복구.

47분.

두 번째.

31분.

세 번째.

19분.

대니얼은 숫자가 줄어드는 걸 보며 만족했다.

그런데 지원담당은 다른 숫자를 가리켰다.

첫 경보 발생부터 사람이 확인할 때까지 걸린 시간.

여전히 길었다.

“왜죠?”

“알림이 너무 많아서요.”

모니터에는 경고가 줄줄이 쌓여 있었다.

대부분은 실제 장애가 아니었다.

사소한 온도변화.

잠깐의 네트워크 지연.

자동으로 회복된 작업.

“민감하게 잡으면 좋은 거 아닙니까?”

대니얼이 물었다.

“너무 민감하면 아무도 안 봅니다.”

지원담당이 말했다.

대니얼은 잠시 말이 없었다.

경보가 많으면 안전할 것 같았다.

실제로는 중요한 경보가 묻혔다.

그들은 경보 등급을 나눴다.

정보.

주의.

행동 필요.

즉시 호출.

다시 훈련했다.

복구시간보다 먼저 발견시간이 줄었다.

대니얼은 그 결과를 꽤 오래 봤다.

Nightglass를 만들 때도 같은 문제가 생길 것이다.

하늘에는 수많은 점이 있다.

경보를 너무 많이 울리면 정작 진짜 위험이 묻힐 수 있다.

좋은 감시시스템은 많이 보는 시스템이 아니라, 무엇을 먼저 볼지 아는 시스템이었다.

그날 이후 야간 장애가 생겨도 Daniel의 전화가 울리지 않는 밤이 조금씩 늘었다. 그건 운영팀의 성과였다.

지원팀은 새 직원 교육에도 같은 장애훈련을 넣었다.

매뉴얼은 문서가 아니라 반복되는 습관이 되어야 한다는 판단이었다.

대니얼은 그 방식에 별다른 지시를 하지 않았다.

운영팀은 그날 처음으로 자기 기준을 스스로 만들었다.