에러 자동 수집
손님 화면에서만 나는 오류를 잡는 유일한 길이에요. 재현이 안 되는 버그가 여기서 잡혀요.
쉽게 말하면
배달을 보낸 도시락을 떠올려 보세요. 손님 집에서 국물이 새면 그 손님은 전화를 안 해요. 그냥 다시 안 시켜요. 그래서 가게가 할 수 있는 일이 하나 있어요. 도시락에 신호를 보내는 쪽지를 같이 넣어 두는 거예요. 국물이 새는 그 순간, 어느 메뉴가 어느 동네에서 어떻게 새었는지 적힌 쪽지가 가게 접수함에 저절로 쌓여요. 오류 자동 수집이 그 쪽지예요. 손님 화면은 이미 내 손을 떠난 도시락이고, 쪽지가 없으면 무슨 일이 났는지 알 방법이 없어요.
손님 화면에서 난 오류는 사장님 컴퓨터에 아무 흔적도 남기지 않아요. 그 오류는 손님 기기 안에서 나고 손님 기기 안에서 끝나요.
로그가 내 서버가 쓰는 영업일지라면, 이 문서는 그 일지가 닿지 못하는 손님 기기 쪽을 다뤄요. 서버는 요청을 받은 적조차 없는 사고가 여기서 나요.
불편을 겪은 손님 대부분은 말없이 나가요. 그래서 문의 한 건이 실제로 몇 명의 일인지 알 수 없고, 고칠 순서를 감으로 정하게 돼요.
말없이 나간 손님의 흔적이 남아요. 무엇부터 고칠지가 추측이 아니라 목록이 되고, 배포 직후 생긴 것인지도 시각으로 갈려요.
오류가 내 손까지 오는 다섯 구간
자동 수집은 마법이 아니라 다섯 구간의 배달이에요. 어디서 끊길 수 있는지 알면 접수함이 조용할 때 그걸 어떻게 읽어야 하는지도 알게 돼요.
- 1손님 기기에서 오류가 나요. 버튼을 눌렀는데 아무 일도 안 일어나는 그 순간이에요. 화면은 조용해도 안에서는 오류 하나가 발생한 상태예요.
- 2화면에 심어 둔 수집 코드가 그걸 붙잡아요. 코드 몇 줄이 화면 전체를 지켜보다가, 아무도 처리하지 않은 오류가 나면 낚아채요.
- 3쪽지 한 장을 만들어 밖으로 보내요. 오류 문구, 난 위치, 기기와 브라우저, 시각을 담아 수집 서비스로 보내요. 손님 화면에는 아무것도 안 보여요.
- 4받는 쪽이 같은 오류끼리 합쳐요. 300명이 같은 오류를 겪으면 목록에 300줄이 아니라 한 줄에 300건으로 쌓여요.
- 5정해 둔 조건에 걸리면 알림이 와요. 처음 보는 종류가 나타났을 때, 또는 짧은 시간에 건수가 튀었을 때처럼 조건을 내가 정해요.
접수함이 비어 있는 건 오류가 없다는 증거가 아니에요
세 번째 구간이 가장 잘 끊겨요. 손님 인터넷이 끊긴 상태면 쪽지도 못 나가고, 광고 차단 확장이 수집 주소를 막기도 해요. 그래서 조용한 접수함은 두 가지 중 하나예요. 정말 평온한 것이거나 쪽지가 못 오고 있는 것이에요. 붙인 직후에 일부러 오류를 한 번 내서 쪽지가 도착하는지 확인해 두면 이 의심이 사라져요.
같은 오류 300건이 한 줄로 합쳐져요
합치기가 이 도구의 핵심이에요. 오류는 손님 수만큼 나기 때문에, 합치지 않으면 접수함이 같은 내용으로 뒤덮여서 아무것도 안 보여요.
| 합쳐진 한 줄에서 볼 칸 | 그 칸이 알려 주는 것 | 그걸로 정하는 것 |
|---|---|---|
| 건수 | 그 오류가 몇 번 났는지예요 | 고칠 순서의 출발점이에요. 다만 건수만으로 정하면 자주 틀려요 |
| 겪은 사람 수 | 500건이 세 사람의 반복인지 500명의 일인지 갈라요 | 급한지 아닌지예요. 사람 수가 곧 피해 폭이에요 |
| 처음 난 시각 | 어느 배포 뒤부터 생겼는지 보여요 | 되돌릴지 말지예요. 배포 직후면 이전 버전으로 되돌리기가 가장 빠른 약이에요 |
| 마지막으로 난 시각 | 지금도 나고 있는지, 어제 끝난 것인지예요 | 오늘 손댈 것인지예요. 멈춘 오류는 급하지 않아요 |
| 기기와 브라우저 분포 | 특정 기종에 몰려 있는지 전체인지예요 | 재현 조건이에요. 한 기종에 몰렸으면 원인 범위가 크게 좁아져요 |
| 직전에 손님이 한 동작 | 어느 화면에서 무엇을 누른 뒤였는지예요 | 내가 똑같이 눌러 볼 순서예요. 재현이 되면 절반은 고친 거예요 |
두 번째 칸이 가장 많이 놓치는 자리예요. 한 사람이 안 되는 버튼을 500번 눌러도 건수는 500이 돼요. 순서를 정할 때는 건수보다 사람 수를 먼저 보세요.
확인해 보세요
접수함에 두 줄이 있어요. A는 500건인데 겪은 사람이 3명이고, B는 40건인데 겪은 사람이 38명이에요. 무엇부터 고쳐야 할까요?
자동 수집이 못 잡는 것
이걸 붙였다고 모든 문제가 보이는 건 아니에요. 수집 코드는 코드가 멈춘 순간을 잡아요. 그래서 코드가 멈추지 않는 종류의 사고는 그대로 지나가요.
| 손님이 겪는 증상 | 자동 수집에 잡히나 | 그럼 무엇이 보나 |
|---|---|---|
| 버튼을 눌러도 아무 반응이 없어요 | 대개 잡혀요. 이 도구가 가장 잘하는 종류예요 | 쪽지에 난 위치까지 찍혀 와요 |
| 화면이 하얗게 비어요 | 잡혀요. 그리는 중에 멈춘 것이니까요 | 직전에 열려던 화면이 같이 적혀 와요 |
| 화면은 뜨는데 합계 금액이 틀려요 | 안 잡혀요. 코드가 멈추지 않았으니 오류가 아니에요 | 로그와 사람 눈이에요. 이런 종류는 손님 문의로만 드러나요 |
| 저장을 눌렀더니 실패했다고 떠요 | 서버 쪽 수집에 잡혀요. 화면 쪽 쪽지에도 요청 실패로 남아요 | 두 쪽지를 같은 시각으로 맞춰 보면 어디서 끊겼는지 보여요 |
| 앱이 통째로 꺼져요 | 화면 수집으로는 못 잡아요. 쪽지를 보낼 화면이 이미 사라졌어요 | 멈춤·강제종료 기록이 그 자리를 맡아요 |
| 사이트가 아예 안 열려요 | 안 잡혀요. 수집 코드가 실린 화면 자체가 안 열렸어요 | 살아 있나 감시하기가 그 자리를 맡아요 |
가장 비싼 사고는 조용해요
세 번째 줄이 이 표에서 가장 무서운 줄이에요. 금액이 틀리거나 알림이 안 나가는 사고는 오류를 하나도 만들지 않아요. 그래서 접수함이 깨끗한 날에도 주문 건수와 매출은 사람이 봐야 해요. 자동 수집은 눈을 하나 더 붙이는 일이고, 원래 있던 눈을 대신하지 않아요.
쪽지가 외계어로 보일 때
실제로 손님 화면에 올라가는 코드는 사람이 읽던 모양이 아니에요. 공백을 지우고 이름을 한 글자로 줄여 한 덩어리로 압축해서 보내요. 그래야 화면이 빨리 떠요.
그래서 쪽지에 적힌 위치가 "파일 하나의 1번째 줄, 4만 번째 글자"처럼 와요. 오류가 난 건 맞지만 그게 내 코드의 어디인지는 아무도 몰라요.
장면 1 · 고치는 사람이 쪽지를 보고 말했다
“위치가 압축된 파일로 찍혀 있어서 어디인지 못 찾겠어요. 소스맵도 같이 올려 주세요.”
소스맵은 압축된 코드와 원래 코드의 대조표예요. 배포할 때 이 대조표를 수집 서비스에 같이 올려 두면, 쪽지의 위치가 원래 파일 이름과 줄 번호로 번역돼요. 없으면 쪽지는 왔는데 못 읽는 상태가 돼요. 사장님이 물을 한마디는 하나예요. "배포할 때 소스맵도 같이 올라가게 돼 있나요."
쪽지에 배포 번호를 같이 담아요
쪽지마다 지금 올라간 판의 번호를 같이 적어 두면 "언제부터 생겼나"가 자동으로 답이 나와요. 새 오류의 배포 번호가 어제 올린 판이면 원인 범위는 어제 바꾼 것뿐이에요. 바뀐 것 기록과 나란히 보면 원인 찾기가 몇 시간에서 몇 분으로 줄어요.
헷갈리기 쉬운 것
이 주변에 비슷한 이름이 다섯 개나 있어요. 다섯이 겹치는 게 아니라 각자 다른 자리를 보고 있어요. 하나로 다 보려고 하면 반드시 구멍이 생겨요.
| 비슷해 보이는 것 | 무엇이 다른가 | 언제 그걸 보나 |
|---|---|---|
| 로그 | 오류가 아닐 때도 계속 흐르는 평상시 일지예요. 주로 서버 쪽이에요 | 원인을 앞뒤로 되짚을 때예요 |
| 오류 기록 모으기 | 모인 오류를 어떤 기준으로 세고 무엇부터 고칠지 정하는 쪽이에요 | 고칠 순서를 정할 때예요 |
| 살아 있나 감시하기 | 밖에서 문을 두드려 보는 것이에요. 문이 열리면 통과라서 안에서 난 오류는 못 봐요 | 문이 아예 안 열릴 때예요 |
| 오류 화면 | 손님에게 보여 줄 안내예요. 수집과는 방향이 반대예요 | 손님이 막혔을 때 무엇을 볼지 정할 때예요 |
| 손님 문의 | 맥락이 가장 정확해요. 대신 불편을 겪은 사람 중 아주 일부만 해요 | 무엇이 왜 불편했는지 알고 싶을 때예요 |
순서를 하나만 기억하면 돼요. 문이 열리는지는 감시가 보고, 문 안에서 난 사고는 자동 수집이 보고, 왜 그랬는지는 로그가 답해요.
가짜 오류가 접수함을 망쳐요
처음 붙이면 하루에 수백 건이 쌓여요. 그리고 그중 상당수가 내가 고칠 수 없는 것들이에요. 이걸 안 걸러 내면 다음 주에 알림을 끄게 되고, 알림을 끈 수집기는 없는 것과 같아요.
| 자주 쌓이는 가짜 | 정체 | 어떻게 하나 |
|---|---|---|
| 브라우저 확장이 만든 오류 | 손님이 깔아 둔 확장 프로그램이 화면을 건드리다 낸 것이에요 | 무시 목록에 넣어요. 내 코드에 손댈 것이 없어요 |
| 손님 인터넷이 끊겨서 난 요청 실패 | 지하철이나 엘리베이터에서 생겨요. 내 서버는 멀쩡했어요 | 한 줄로 합쳐 건수만 보세요. 갑자기 튀면 그때는 내 문제예요 |
| 봇과 아주 오래된 브라우저 | 사람 손님이 아니거나 몇 년 전 브라우저예요 | 지원할 범위를 정하고 그 밖에서 온 쪽지는 접어 둬요 |
| 손님이 화면을 닫아서 중간에 끊긴 요청 | 정상 행동이에요. 사람은 기다리다 나가요 | 오류로 세지 않게 걸러요. 이걸 세면 이탈이 많은 날마다 알림이 와요 |
| 이미 알고 있고 안 고치기로 한 것 | 판단이 끝난 항목이에요 | 해결로 표시해서 접수함에서 내려요. 다시 나타나면 알림이 와요 |
붙인 첫 주는 정리하는 주예요
첫 주의 목표는 고치는 게 아니라 접수함을 조용하게 만드는 것이에요. 알림이 하루 세 번 안쪽으로 줄어들면 그때부터 알림 하나하나가 뜻을 가져요. 그 상태를 만들어 둬야 사고가 났을 때 첫 신호를 놓치지 않아요.
하나 더
붙인 첫날 400건이 쌓였어요. 확장 프로그램 오류와 인터넷 끊김이 대부분이에요. 지금 할 일은?
쪽지에 담으면 안 되는 것
쪽지는 내 서버가 아니라 밖의 수집 서비스에 쌓여요. 그래서 쪽지에 담는 것은 그 순간 밖으로 옮겨 둔 정보가 돼요.
고치는 데 도움은 거의 안 되고 위험만 커져요. 수집 서비스 계정이 털리면 사고가 한 곳이 아니라 두 곳에서 나요.
고치는 데 필요한 건 어느 손님인지가 아니라 어느 상황인지예요. 내부 번호만 있으면 내 장부에서 그 손님을 되짚을 수 있어요.
그대로 옮겨 쓸 문장
직접 만드는 중이면 아래 문장을 그대로 보내면 돼요. 전문어를 몰라도 돼요. 왼쪽에서 내 상황을 찾아 오른쪽을 복사해 쓰세요.
| 내가 원하는 것 | 그대로 보낼 문장 |
|---|---|
| 손님 화면 오류를 받아 보고 싶어요 | "손님 화면에서 처리되지 않은 오류가 나면 자동으로 수집되게 붙여 주세요. 손님에게는 아무 표시도 안 보이게 해 주세요." |
| 쪽지에 무엇이 담기는지 알고 싶어요 | "쪽지에 담기는 항목을 목록으로 먼저 보여 주세요. 개인정보가 들어가는 항목이 있으면 표시해 주세요." |
| 개인정보가 나가지 않게 하고 싶어요 | "이름·연락처·카드번호·로그인 열쇠값은 보내기 전에 가려 주세요. 손님 구분은 내부 번호로만 해 주세요." |
| 위치가 외계어로 오는 걸 막고 싶어요 | "배포할 때 소스맵도 함께 올라가게 해 주세요. 쪽지의 위치가 원래 파일과 줄 번호로 보이게요." |
| 언제부터 생긴 오류인지 알고 싶어요 | "쪽지마다 지금 배포된 판의 번호를 같이 담아 주세요." |
| 가짜 오류가 너무 많아요 | "브라우저 확장이 낸 오류와 손님 인터넷 끊김으로 생긴 요청 실패는 수집에서 빼 주세요." |
| 알림을 언제 받을지 정하고 싶어요 | "처음 보는 종류가 나타났을 때와 짧은 시간에 건수가 튈 때만 알려 주세요. 매 건마다 보내지 말아 주세요." |
직접 해보기
두 번째 문장부터 붙여 보세요
일곱 줄 중 하나만 쓴다면 두 번째예요. "쪽지에 담기는 항목을 목록으로 먼저 보여 주세요." 이 한 줄이 개인정보 사고를 미리 막고, 무엇이 수집되는지 사장님이 아는 상태를 만들어요. 스튜디오에서 만들고 있는 것이 있으면 그 자리에 그대로 붙여 보세요.
스튜디오에서 적어 보기자주 묻는 것
- Q. 손님이 이 쪽지를 보내는 걸 알아야 하나요?
- 오류 상황을 고치기 위한 기술 정보만 담고 개인을 특정하지 않으면 손님 화면에 따로 알릴 필요는 없어요. 다만 손님 이름이나 입력값을 담기 시작하면 성격이 달라져요. 그때는 개인정보 처리방침에 수집 항목과 목적을 적어야 해요. 그래서 담을 항목을 좁게 유지하는 것이 서류를 줄이는 방법이기도 해요.
- Q. 이걸 붙이면 사이트가 느려지지 않나요?
- 평소에는 거의 영향이 없어요. 쪽지는 오류가 났을 때만 나가고 크기도 작아요. 느려지는 건 다른 경우예요. 같은 오류가 초당 수십 번 나는데 매번 쪽지를 보내면 손님 화면이 그 일에 힘을 써요. 그래서 같은 오류를 짧은 시간 안에 몇 번까지만 보내게 제한을 두는 설정이 대개 있어요.
- Q. 돈이 드나요?
- 직접 만들면 도구값은 안 들지만 쪽지를 쌓아 둘 곳과 볼 화면을 내가 만들어야 해요. 외부 수집 서비스를 쓰면 무료로 시작할 수 있는 구간을 두는 곳이 많고, 월 건수가 넘으면 유료로 넘어가요. 값이 오르는 이유는 대개 하나예요. 가짜 오류를 안 걸러서 건수가 부풀어요. 걸러 내기가 곧 요금 관리예요.
- Q. 서버 오류와 화면 오류를 한 곳에서 볼 수 있나요?
- 볼 수 있어요. 같은 서비스에 양쪽 쪽지를 보내면 시각 순으로 나란히 놓여요. 이게 값이 나가는 이유가 있어요. 손님 화면에 저장 실패가 뜬 시각과 서버가 거절한 시각이 맞아떨어지면, 원인이 화면이 아니라 서버라는 게 그 자리에서 갈려요.
- Q. 오류가 하나도 안 올라와요. 잘 된 건가요?
- 먼저 쪽지가 오는지 확인하세요. 일부러 오류를 한 번 내 보고 접수함에 뜨면 통로는 살아 있는 거예요. 안 뜨면 수집 주소가 막혔거나 설정이 안 붙은 상태예요. 오류가 0인 서비스는 흔하지 않아요. 조용한 접수함은 보통 좋은 신호가 아니라 확인해야 할 신호예요.
- Q. 고친 뒤에는 어떻게 확인하나요?
- 그 줄을 해결로 표시하고 새 판을 올려요. 같은 오류가 새 배포 번호로 다시 올라오면 아직 안 고쳐진 거예요. 며칠 동안 안 올라오면 고쳐진 거예요. 이 확인이 있으면 "고친 것 같다"가 "고쳐졌다"로 바뀌어요.
더 깊이 (안 읽어도 괜찮아요)
같은 오류로 합치는 기준이 흔들릴 때 · 합치는 쪽은 오류 문구와 난 위치를 보고 같은 것끼리 모아요. 그런데 오류 문구에 손님 이름이나 주문 번호가 섞여 있으면 문구가 매번 달라져서, 같은 오류가 수백 개의 다른 줄로 흩어져요. 접수함이 갑자기 지저분해졌다면 이걸 의심하세요. 문구에서 매번 바뀌는 값을 빼는 것만으로 수백 줄이 한 줄로 돌아와요.
표본만 받는 설정이 있는 이유 · 손님이 아주 많아지면 오류 하나에 쪽지가 수만 장 옵니다. 그때는 열 장 중 한 장만 받아도 판단이 달라지지 않아요. 건수는 비율로 되짚을 수 있으니까요. 대신 처음 붙인 가게에서 표본을 줄이면 안 돼요. 건수가 적을 때는 한 장이 사라지는 것이 곧 사고 하나가 안 보이는 것이에요.
오류율은 분모가 있어야 숫자예요 · 오류 200건은 그 자체로 좋은지 나쁜지 알 수 없어요. 방문이 300번이었다면 큰 사고이고, 3만 번이었다면 평소 수준일 수 있어요. 그래서 볼 숫자는 건수가 아니라 방문 대비 비율이에요. 배포 전후로 이 비율을 비교하면 새 판이 안전한지가 하루 안에 판정돼요. 이 판정이 이전 버전으로 되돌리기를 감이 아니라 근거로 하게 만들어요.
이것만 기억하세요
- ·손님 기기에서 난 오류는 내 서버에 흔적을 안 남겨요. 쪽지를 심어 두는 것이 유일한 길이에요
- ·고칠 순서는 건수가 아니라 겪은 사람 수로 정해요. 500건이 세 사람의 일일 수 있어요
- ·코드가 멈추지 않는 사고는 안 잡혀요. 금액과 주문 건수는 여전히 사람이 봐요
- ·소스맵과 배포 번호를 같이 올려 두면 어디에서, 언제부터가 자동으로 답이 나와요
- ·첫 주의 목표는 고치기가 아니라 가짜를 걸러 접수함을 조용하게 만드는 것이에요