전 편에서 블로그에 시리즈 모아보기 페이지를 만들면서, 태스크 단위로 쪼개서 서브에이전트에게 맡기고 각 태스크마다 별도 리뷰어가 diff를 검토하는 방식으로 진행했다. 마지막 태스크에서는 실제 dev 서버를 띄워서 페이지들을 직접 열어보고, 프로덕션 빌드까지 돌리는 수동 검증을 했다. 전부 통과했다. 이 정도면 끝났다고 생각했는데, 태스크 하나하나가 아니라 브랜치 전체를 놓고 다시 보는 최종 리뷰에서 진짜 문제가 나왔다.
발견된 버그
시리즈 상세 페이지가 여러 쪽으로 나뉘면(예: 5편짜리 시리즈), 태그 페이지는 breadcrumb에
“태그이름 (2쪽)“처럼 접어서 보여주는데, 시리즈 페이지는 그 로직이 없어서 페이지 번호가
그대로 노출된다는 지적이었다. 코드를 보니 정확했다 — breadcrumb 접기 로직이 URL의 첫
세그먼트가 "tags"인지만 확인하고 있었고, "series"는 아예 고려된 적이 없었다.
더 흥미로운 지적 — 검증 자체가 틀린 가정 위에 있었다
여기서 끝났으면 그냥 “빠뜨린 케이스 하나”였을 텐데, 리뷰는 한 발 더 나갔다. 앞서 마지막
태스크가 “5개 글이 든 시리즈를 열어보니 한 페이지에 5개가 다 보였다”고 보고했었는데,
설정값(perPage)이 4라면 애초에 한 페이지에 4개까지만 들어갈 수 있어서 그 보고 자체가
앞뒤가 안 맞는다는 거였다.
확인해보니 실제로는 이 사이트의 perPage가 이미 5로 설정돼 있었다(이 기능이랑 전혀
무관한, 훨씬 전에 있었던 설정). 그러니까 지금 있는 시리즈 중 어느 것도 실제로는 페이지가
안 나뉘고 있었고, “여러 쪽으로 나뉘는 경우”라는 케이스 자체를 아무도 실제로 밟아본 적이
없었던 거다. 마지막 태스크의 검증은 실행은 됐고 에러도 없었지만, 정작 확인하려던 상황이
한 번도 발생하지 않은 채로 “통과”라고 기록된 셈이었다.
고치면서 진짜로 확인했다
breadcrumb 접기 로직을 "tags"뿐 아니라 "series"도 포함하도록 넓히는 건 어렵지 않았다.
근데 그것만 고치고 끝내면 또 같은 함정에 빠질 수 있었다 — 고쳤다는 것과, 고친 게 실제로
동작하는 걸 봤다는 건 다른 얘기니까. 그래서 perPage를 임시로 4로 낮춰서 5편짜리
시리즈를 강제로 2쪽으로 나눠보고, 1쪽엔 4개, 2쪽엔 1개가 정확히 뜨는지, 2쪽의 breadcrumb이
제대로 접혀서 보이는지 직접 확인한 다음 설정을 원래 값으로 되돌리고 커밋했다.
남는 생각
타입체크, 태스크별 리뷰, 실제 서버를 띄운 수동 검증까지 — 검증 단계 자체는 부족하지
않았다. 문제는 그 검증들이 전부 같은 전제(perPage=4) 위에서 이뤄지고 있었고, 그
전제가 틀렸다는 걸 아무도 의심하지 않았다는 거였다. 여러 겹의 검증을 쌓아도, 그 겹들이
공유하는 가정 자체가 틀리면 다 같이 틀린 채로 통과할 수 있다. 개별 검증을 잘게 쪼개서
꼼꼼히 하는 것과, 그 검증들이 깔고 있는 전제를 통째로 의심해보는 건 서로 다른 종류의
점검이라는 걸 다시 배웠다.