에러 트래킹

예외는 프로그램이 처리하지 못한 상황을 만나 하던 일을 멈추고 남기는 신호입니다. 사용자 화면에는 "문제가 발생했습니다" 한 줄로만 보이지만, 서버 쪽에는 어느 코드 줄에서 왜 멈췄는지가 남습니다. 곤란한 점은 그 기록을 사람이 찾아 들어가야만 볼 수 있었다는 데 있었습니다.

페이지덱 초기에는 이런 식이었습니다. 수아가 "문서 저장이 안 된다는 문의가 세 건 왔어요" 하고 전하면 태오가 서버에 접속해 그날 기록 파일을 열었습니다. 하루치가 400만 줄이라, 고객의 계정 번호로 걸러 내고 앞뒤를 읽어 원인을 짐작하는 데 반나절이 갔습니다.

더 곤란한 쪽은 아무도 말해 주지 않은 오류였습니다. 같은 원인으로 4200번 터진 오류도 기록에서는 시각과 계정 번호가 제각각인 4200개의 줄로 보입니다. 그래서 310명이 겪는 오류와 한 사람이 한 번 겪은 오류가 같은 무게로 섞였고, 무엇부터 고칠지 정할 근거가 없었습니다.

에러 트래킹은 이 일을 기계에 넘긴 도구입니다. 예외가 날 때마다 서비스가 그 내용을 수집 서버로 보내고, 수집 서버가 같은 원인으로 보이는 것들을 한 건으로 합칩니다. 사람은 기록을 뒤지는 대신 이미 묶이고 세어진 목록을 위에서부터 읽습니다.

흩어진 예외를 고칠 수 있는 단위로 정리하는 일을 맡고, 구체적으로는 네 가지를 합니다.

1. 같은 오류를 한 건으로 묶습니다. 예외가 들어올 때마다 터진 위치와 함수가 불린 순서, 오류 종류를 조합해 지문 같은 값을 만들고, 같은 값이 나오면 기존 항목의 발생 횟수만 올립니다. 4200줄이 "문서 저장 중 권한 조회 실패" 한 줄로 접힙니다.
2. 고칠 순서를 정할 재료를 붙입니다. 항목마다 총 발생 횟수와 영향받은 사용자 수가 따로 나옵니다. 한 사람이 새로고침을 눌러 대 3000번이 찍힌 항목과 300명이 한 번씩 겪은 항목은 무게가 다르고, 뒤쪽이 먼저입니다.
3. 재현에 필요한 맥락을 함께 저장합니다. 스택 트레이스(오류가 난 지점까지 함수가 불린 순서를 적어 둔 목록), 브라우저, 서비스 버전, 직전에 지나온 화면 같은 것들입니다. "저는 안 그러는데요" 하고 끝나던 대화가 "사파리에서만, 그것도 공유 화면에서만" 으로 좁혀집니다.
4. 처음 보는 오류를 알려 줍니다. 새 항목이 생기거나 발생량이 갑자기 튀면 알림이 갑니다. 알림은 정해 둔 조건을 넘었을 때 담당자에게 연락이 가게 만든 장치입니다. 배포하고 10분 뒤에 처음 보는 항목이 분당 40건씩 올라온다면, 방금 내보낸 것을 되돌릴지 지금 정해야 한다는 뜻입니다.

네 가지가 모이면 순서가 뒤집힙니다. 고객이 알려 줄 때까지 기다리는 대신, 아직 아무도 문의하지 않은 항목을 목록 위에서부터 먼저 고치게 됩니다.

예외를 파악하는 방법이 이것 하나는 아니고, 오류의 양에 따라 다른 쪽이 맞을 때가 있습니다.

1. 로깅만 두고 필요할 때 뒤지는 방법입니다. 로깅은 실행 중 벌어진 일을 한 줄씩 글로 남기는 것입니다. 가장 싸고 이미 어디에나 깔려 있지만, 누군가 찾아 들어가야 보이고 같은 오류를 세어 주지 않습니다. 하루 예외가 수십 건인 사내 도구라면 이걸로 충분합니다.
2. 에러율만 메트릭으로 보는 방법입니다. 메트릭은 같은 종류의 값을 세어 시간축에 쌓은 관측 데이터입니다. 실패율이 0.2퍼센트에서 14퍼센트로 튄 시각은 짚어 주지만 어떤 오류가 튀었는지는 말해 주지 않아, 대체재가 아니라 짝으로 씁니다.
3. APM으로 갈음하는 방법입니다. APM은 어느 화면과 어느 요청이 느린지를 응답 시간 중심으로 보여 주는 도구인데, 요즘 제품은 예외 목록도 함께 보여 줘서 도구 수를 줄일 수 있습니다. 다만 오류를 묶는 규칙이나 담당자 배정은 전용 도구 쪽이 촘촘합니다.
4. 직접 만드는 방법입니다. 예외를 데이터베이스에 쌓고 화면 하나를 붙이는 일 자체는 하루면 끝납니다. 손이 가는 곳은 그다음입니다. 무엇을 같은 오류로 볼지 정하는 규칙, 오래된 것을 지우는 보관 정책, 폭주할 때 수집을 줄이는 장치를 계속 손봐야 합니다.

"이 이슈 오늘만 4200번이고 영향받은 사용자가 310명이에요. 다음 주 말고 지금 고칩시다."

발생 횟수가 아니라 사람 수를 근거로 순서를 앞당기자는 말입니다.

"어제 배포 이후로 새 이슈가 하나 올라왔는데, 하루 지나도 세 건이라 일단 지켜보려고요."

처음 보는 오류이긴 하지만 되돌릴 만큼은 아니라는 판단입니다.

"그건 봇이 보낸 요청이라 무시 처리했어요. 이제 목록에 안 뜹니다."

고칠 대상이 아닌 항목을 걷어 내 목록을 지키는 작업입니다.

페이지덱에서는 릴리스 직후 30분이 이 화면을 가장 오래 보는 시간입니다. 태오가 새로 생긴 항목만 걸러 두고 지켜보다가, 처음 보는 항목이 분당 수십 건으로 올라오면 영향받은 사용자 수를 그대로 지현에게 전합니다. 숫자가 두 자리에 머물면 핫픽스로 그 부분만 고쳐 내보내고, 수백 명대로 번지면 배포를 되돌리고 인시던트로 올립니다. 인시던트는 서비스에 영향을 준 사고를 뜻하고, 이 단계부터는 고객 공지와 복구 기록이 따라붙습니다.

붙여 두기만 하면 장애를 다 알게 된다고 여기기 쉽습니다. 오류가 실시간으로 쌓이는 화면을 보고 있으면 실제로 그렇게 느껴집니다. 하지만 이 도구가 잡는 것은 예외가 난 경우뿐입니다. 8초씩 걸리지만 끝내 성공하는 요청, 계산이 틀려 잘못된 숫자를 멀쩡하게 보여 주는 화면, 서버가 죽어 아무것도 보내지 못하는 상황은 한 건도 올라오지 않습니다. 이 화면만 지키고 있으면 가장 조용한 장애를 가장 늦게 알게 됩니다. 그래서 가동률처럼 바깥에서 재는 값을 함께 둡니다.

목록을 0으로 만들어야 한다는 생각도 자주 나옵니다. 이슈가 남아 있으면 관리를 안 한 것처럼 보이니 그렇게 여길 만합니다. 하지만 사용자가 만드는 오류에는 고칠 수 없는 것이 늘 섞여 있습니다. 지하철에서 연결이 끊긴 채 저장을 누르는 경우입니다. 0을 목표로 걸면 팀은 고치는 대신 무시 처리를 늘리는 쪽으로 움직이고, 반년 뒤에는 화면은 깨끗한데 정작 봐야 할 항목까지 걸러져 있게 됩니다. 기준으로 삼을 것은 남은 개수가 아니라 새 항목이 하루 안에 분류되는지입니다.