로그 회귀 테스트 구축으로 데이터 기반 비즈니스 지키기 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#continuous-integration#vitest#analytics-logging#msw#regression-testing#snapshot-testing

AI 요약

기능은 정상 동작했지만 후속 hotfix가 화면은 그대로 둔 채 logging만 깨뜨려 24일간 click·impression log가 조용히 누락되고 추천 성과 분석이 훼손된 사고가 출발점이다. 외부 보고·장기 지표는 사후 보정도 어렵다는 점에서, UI event부터 API payload까지 보호하는 log regression test를 구축한 과정을 소개한다.

핵심 포인트

수백 개 logging path를 사람이 배포마다 확인할 수 없으므로, component를 render하고 Testing Library로 click을·IntersectionObserver로 impression을 일으키는 자동 test flow를 구성
MSW가 실제 log API 경계에서 request를 가로채 payload를 추출·snapshot 비교해, 내부 module 구현이 바뀌어도 사용자 행동에서 전송 데이터까지의 contract를 검증하고 CI에서 merge 전 실패시킴
첫 구현의 'n번째 payload' 방식은 rendering·useEffect·network timing에 따라 impression 순서가 흔들려 flaky했는데, 호출 순서 index를 각 log의 unique ID 검색으로 교체해 비동기 경쟁 조건에서도 신뢰성 확보
전체 329개 log 중 285개(86.6%)를 보호하고, test 하나당 수동 검수 3분 가정 시 release마다 약 14시간을 절감 — 완벽한 100%보다 핵심 business data의 지속 보호를 강조

왜 읽나기능은 멀쩡한데 log가 조용히 깨지는 blind spot을 겪는 팀에게, 사용자 행동→payload contract를 snapshot·CI로 자동 검증하는 실전 구축기.

챕터별 상세

012:17 – 8:41

24일간 누락된 log가 남긴 business blind spot

연관 상품 기능과 click·impression logging을 검수해 배포했지만 이후 hotfix가 화면은 그대로 둔 채 logging만 깨뜨려 24일 동안 data가 쌓이지 않았다. 뒤늦게 발견한 누락은 추천 성과 분석과 의사 결정을 불가능하게 만들었고, 외부 보고와 장기간 지표는 사후 보정도 어려워 기능 test와 별도로 log 자체를 지속 검증해야 한다는 문제를 드러냈다.

수백 개 logging path를 배포마다 사람이 확인할 수 없으므로 component를 render하고 Testing Library로 click을, IntersectionObserver로 impression을 일으키는 자동 test flow를 만들었다. MSW가 실제 log API 경계에서 request를 가로채 payload를 추출하고 snapshot과 비교해, 내부 module 구현이 바뀌어도 사용자 행동에서 전송 데이터까지 이어지는 contract를 안정적으로 검증한다.

정상 동작을 최초 검수한 시점의 log payload를 snapshot으로 고정하고 모든 pull request의 CI에서 새 payload와 비교해 field 누락이나 형식 변경이 생기면 merge 전에 실패하도록 했다. 긴 expected object를 test code에 반복 작성하지 않아도 되고 diff가 변경 지점을 선명하게 보여 주며, 실제 refactoring 과정에서 의도치 않은 logging 회귀를 잡아 자동화의 효용을 확인했다.

첫 구현은 여러 API 호출 중 n번째 payload를 골랐지만 component rendering, useEffect, IntersectionObserver와 network timing에 따라 impression 순서가 달라져 관련 없는 변경에도 test가 간헐적으로 실패했다. 호출 순서 기반 index를 버리고 각 log의 unique ID로 request 목록을 순회해 정확한 payload만 찾도록 바꿔, 조합 component와 비동기 경쟁 조건에서도 신뢰할 수 있는 검증으로 개선했다.

장보기·쇼핑 web의 전체 329개 log 중 285개, 즉 86.6%를 regression test로 보호하고 이후에는 CI가 배포마다 동일한 검수를 반복한다. Test case 하나를 사람이 확인하는 데 3분이 든다고 가정하면 release마다 약 14시간의 수동 검수를 줄이는 셈이며, 완벽한 100%보다 핵심 business data를 꾸준히 보호하는 자동 안전망의 가치를 강조한다.