LabHub
배우기 러닝패스 코스

디버깅 실전 · 되는 것과 안 되는 것의 차이표 · 이론

되는 것과 안 되는 것을 나란히 놓는다

LabHub 에서 이어서 보기

한 줄 요약

차등 진단은 실패 표본만 들여다보는 대신 성공 표본을 나란히 놓고, 모든 실패에 있으면서 어떤 성공에도 없는 속성만 남기는 절차다.

왜 이게 필요했나

"어떤 고객은 되고 어떤 고객은 안 됩니다." 현장에서 가장 자주 듣는 문장이고, 동시에 가장 좋은 소식이다. 되는 쪽이 있다는 것은 비교할 대조군이 있다는 뜻이기 때문이다.

그런데 대부분은 이 소식을 버리고 실패한 요청의 로그만 파고든다. 실패 로그에는 TLS 핸드셰이크도 있고, 재시도도 있고, 경고도 있다. 전부 수상해 보인다. 그 수상함이 실제로 원인인지 알려면 성공한 요청의 로그에도 같은 것이 있는지 봐야 한다. 성공에도 있으면 그것은 원인이 아니라 배경이다.

이 절차에는 이름이 있다. 의학에서 온 말로 감별 진단(differential diagnosis)이고, 소프트웨어에서는 흔히 차등 진단이라고 옮긴다. 핵심은 하나다 — 한쪽만 보면 모든 것이 원인 후보로 보이고, 양쪽을 보면 대부분이 저절로 지워진다.

어떻게 동작하나

절차는 네 걸음이다.

1. 표본을 모은다. 실패 표본만 스무 개 모으는 것은 의미가 없다. 성공 표본을 비슷한 수로 모아야 한다. 이때 성공 표본은 실패와 가장 비슷한 조건의 성공일수록 좋다. 완전히 다른 나라의 다른 버전 성공 표본은 지워 주는 것이 별로 없다.

2. 속성으로 펼친다. 각 표본을 (속성 = 값)의 목록으로 바꾼다. 지역, 클라이언트 판, 인코딩, 인증 방식, 장치, 엔드포인트, 시간대. 이 목록을 정하는 일이 실제로는 가장 어렵다 — 목록에 없는 속성은 영영 후보가 되지 않는다.

3. 두 집합을 뺀다. 모든 실패에 들어 있는 값의 집합에서, 성공 하나라도에 들어 있는 값의 집합을 뺀다. 남은 것이 후보다. 여기서 지워지는 값들이 중요하다. "모든 실패에 token 인증이 있었다" 는 사실은, 성공의 3분의 1도 token 이었다는 사실과 함께 놓이는 순간 아무 말도 아니게 된다.

4. 후보가 둘 이상이면 갈라 낸다. 이 자리가 이 절차의 진짜 어려움이다.

상관은 원인이 아니다. 같은 시기에 배포된 두 가지가 언제나 함께 다니면, 표본만으로는 둘을 구별할 수 없다. 표가 둘을 똑같이 가리키는 것은 표가 틀려서가 아니라 자료에 그 둘을 가르는 사례가 없어서다. 가르는 방법은 둘뿐이다.

한 속성으로 갈리지 않는 경우도 있다. 인코딩이 utf-8-sig 이면서 장치가 키오스크일 때만 실패한다면, 단독 후보는 하나도 남지 않는다. 각각은 성공 표본에도 있기 때문이다. 이럴 때는 값의 을 후보로 삼아 같은 뺄셈을 한 번 더 한다. 셋 이상의 조합까지 가면 경우의 수가 빠르게 커지므로, 보통은 짝까지 보고 그다음은 개입으로 확인한다.

숫자로 보면 이 절차가 왜 값어치가 있는지 분명해진다. 표본 240건에 속성이 일곱 개, 값이 스무 가지쯤이라고 하자. 실패 40건의 교집합을 구하면 대개 값 두세 개가 남고, 거기서 성공 200건의 합집합을 빼면 한둘이 남는다. 눈으로 훑으면 스무 개가 전부 수상한데, 뺄셈 두 번이면 후보가 한둘이 된다. 사람이 더 똑똑해진 것이 아니라 성공 표본이 나머지를 지워 준 것이다.

한 가지 더. 이 절차는 속성을 늘릴수록 강해진다. 기록에 없는 속성은 후보가 될 수 없으므로, 조사 초기에 "무엇을 함께 기록할 것인가" 를 정하는 일이 사실상 조사의 절반이다. 요청 헤더, 클라이언트 판, 테넌트, 경로, 인증 방식은 대부분의 사건에서 쓸모가 있었다.

현장에서 만나는 모습

첫째, 실패 표본만 모은다. 고객은 실패한 건만 보내 준다. 성공한 건은 아무도 보관하지 않기 때문이다. 그래서 첫 요청은 늘 "성공한 건도 같은 수만큼 보내 주세요" 여야 한다.

둘째, 표본이 치우쳐 있다. 실패는 전부 야간 배치에서 모으고 성공은 전부 주간 화면에서 모으면, 시간대와 경로가 전부 후보로 남는다. 자료를 모은 방식이 자료에 무늬를 남긴 것이다.

셋째, 후보를 하나만 찾고 멈춘다. 후보가 둘 남았는데 그럴듯한 쪽을 골라 보고하면 절반의 확률로 틀린다. 그리고 그 보고는 고치는 데 며칠을 쓰게 만든다. 후보가 둘이면 둘이라고 적고, 가르는 실험을 설계하는 것이 옳다.

넷째, 지운 것을 안 적는다. "auth_mode 는 원인이 아니다" 는 사실은 다음 사람이 같은 길을 다시 걷지 않게 해 준다. 보고서에는 남은 후보만이 아니라 지운 후보와 지운 근거를 함께 적는다.

실무에서 진짜 중요한 것

다음 실습에서 할 것

결제 게이트웨이 표본 240건으로 속성별 차이표를 만들고, 모든 실패에 있고 어떤 성공에도 없는 값을 골라낸다. 후보가 둘 남는 자리에서 새 표본 120건을 더해 한쪽을 떨어뜨리고, 재현기로 속성 하나만 바꿔 결과가 뒤집히는지 확인한다. 마지막으로 한 속성으로는 갈리지 않는 다른 테넌트의 표본에서 짝 후보를 찾아 한 장으로 보고한다.