홈 / 일하는 방식
관측 → 원인 규명 → 수정 → 재측정
이 네 단계를 고정된 루프로 돌립니다. 아래는 그 루프를 실제로 돌린 사례 세 가지입니다 — 계획이 아니라
이미 벌어진 일을 그대로 옮겼습니다.
01
네 단계
- 01
관측
먼저 화면이 아니라 원문을 본다. site: 검색 결과, 응답 헤더, 저장된 HTML, DB에 실제로 들어 있는 값. 사람 눈에 정상으로 보이는 것과 기계가 읽는 것은 자주 다르다.
- 02
원인 규명
가설을 세우고 하나씩 지운다. "이미지 크기 때문일까?" 지운다. "도달성 때문일까?" 지운다. 남는 것이 원인이다. 짐작으로 고치면 같은 문제가 다른 모습으로 돌아온다.
- 03
수정
원인이 있는 자리만 고친다. 관련 없어 보이는 것까지 같이 손대지 않는다. 고치는 김에 하는 정리는 나중에 무엇이 문제를 고쳤는지 알 수 없게 만든다.
- 04
재측정
고쳤다고 끝이 아니다. 배포 후 다시 관측해서 실제로 바뀌었는지 확인한다. 바뀌지 않았으면 01로 돌아간다. 이 루프에 끝이 있다고 가정하지 않는다.
사례 1 · 리뷰로거
경쟁률 통계가 실제보다 낮게 나가고 있었다
- 관측
- 공개 통계 페이지의 평균 경쟁률이 실제 체감과 다르게 낮았다.
- 원인 규명
- 체험단 플랫폼 8곳이 신청자 수를 아예 공개하지 않는데, DB 컬럼이 그 값을 0으로 저장하고 있었다. "신청자 없음"과 "신청자 수 모름"이 같은 값으로 섞여 평균을 끌어내리고 있었다.
- 수정
- 신청자 수 미공개 플랫폼 목록을 만들어 통계·정렬 로직 양쪽에서 제외했다. 스키마 자체(0 기본값)는 다른 곳에서도 쓰여 바꾸지 않고, 집계 레이어에서만 필터링했다.
- 재측정
- 재계산 결과 평균 경쟁률이 4.87:1 → 5.76:1로 바뀌었다. 그 목록이 실데이터와 계속 맞는지 대조하는 검사를 함께 만들어, 신청자 수를 새로 공개하기 시작한 플랫폼이 생기면 자동으로 어긋남이 잡히게 했다.
사례 2 · 나비랑
meta description이 두 도구의 기준과 동시에 어긋났다
- 관측
- 빙 웹마스터 도구는 짧은 설명을 지적했고, Ahrefs는 같은 문서 중 다른 것들을 길다고 지적했다.
- 원인 규명
- 두 도구가 서로 다른 것을 재고 있었다 — 빙은 신뢰도(너무 짧으면 색인 판단 근거가 부족하다고 본다), Ahrefs는 SERP 잘림(160자 초과)을 본다. 하나의 값(글자 수)만으로는 둘 다 만족할 수 없는 것처럼 보였다.
- 수정
- 두 기준의 교집합인 110~158자 밴드를 정하고, 문장 경계에서만 자르는 규칙으로 221장 전부를 그 안에 넣었다. 자르는 과정에서 조사가 잘리거나 의미가 끊기는 경우를 두 번 더 발견해 수동으로 고쳤다.
- 재측정
- 빌드 시점에 밴드를 벗어나면 콘솔 경고가 뜨도록 검사를 코드에 남겨, 다음에 페이지를 추가할 때 같은 문제가 조용히 재발하지 않게 했다.
사례 3 · 리뷰로거
월간 리포트를 만들려다 삭제 정책을 발견했다
- 관측
- 지난달 리포트를 만들려고 보니, 지금 DB에 데이터가 충분히 남아 있어 보였다.
- 원인 규명
- 운영 DB는 마감 30일 뒤 공고 행을 지운다. "데이터가 많이 남아 있다"는 그 달의 데이터가 전부 남아 있다는 증거가 아니었다 — 이미 마감 후 30일이 지나 지워진 행은 애초에 셀 수조차 없다.
- 수정
- 삭제 영향이 없는 최근 날짜들의 기간 분포로 역산해 손실분을 추정하고, 그 추정치를 리포트의 한계로 명시했다. 근본적으로는 삭제되기 전에 영구 보존하는 별도 테이블을 새로 설계했다.
- 재측정
- 8월 1~2일 발견분 중 약 115건(0.66%)이 이미 지워졌을 것으로 추정된다고 리포트에 남겼다. 다음 달부터는 보존 테이블 도입으로 이 추정 자체가 필요 없어질 예정이다.
더 짧은 기술적 사건 기록은 기록에서 계속 쌓고 있습니다.