거래명세서 인쇄 시 전체 건수 누락 버그 수정

거래명세서 인쇄 버그는 언뜻 보면 단순한 화면 이슈처럼 보였다. 출력 버튼을 눌렀더니 건수가 빠져 있다는 제보였고, 첫 반응은 "렌더링 문제겠지" 였다. 그런데 파고들다 보니 원인은 조금 다른 곳에 있었다.

문제의 구조: 페이지네이션과 집계의 엇박자

partner-portal의 거래명세서 인쇄 기능은 화면에 보이는 데이터를 그대로 뽑는 방식으로 동작하고 있었다. 화면 자체는 페이지네이션으로 렌더링되는데, 인쇄 시 "전체 건수"를 표기해야 하는 영역이 있었다. 문제는 기존 로직이 현재 페이지에 로드된 데이터만 기준으로 집계했다는 것. 1페이지만 보고 있으면 1페이지 건수가 전체인 것처럼 찍혔다.

수정 방향은 페이지 루프를 돌면서 전체 건을 수집한 뒤 집계하는 것이었다. 개념은 단순하지만 구현할 때 신경 쓸 지점이 몇 가지 있다.

// 수정 전: 현재 렌더된 리스트만 집계
const totalCount = currentPageItems.length;

// 수정 후: 루프로 전체 페이지 수집 후 집계
async function collectAllItems(fetchPage, totalPages) {
  const results = [];
  for (let page = 1; page <= totalPages; page++) {
    const items = await fetchPage(page);
    results.push(...items);
  }
  return results;
}

const allItems = await collectAllItems(fetchPage, totalPages);
const totalCount = allItems.length;

코드 구조는 이렇게 단순한데, 실제로는 totalPages 값을 어디서 가져오느냐, 중간에 페이지 데이터가 바뀌면 어떻게 처리하느냐 같은 세부 사항이 따라붙는다. 이번 건은 인쇄 시점에 스냅샷 개념으로 동작하는 거라 데이터 변경 레이스는 크게 걱정할 케이스가 아니었다. 그래서 루프 수집으로 깔끔하게 정리했다.

변경 파일은 뷰/스타일 1개. 서버 로직은 손대지 않았고 프론트 스크립트 수정만으로 해결됐다.

버그 수정 시 빠지지 않는 체크

단순히 증상만 픽스하는 건 위험하다. "인쇄 시 건수 누락"이라는 증상 뒤에 "페이지네이션 집계 로직"이라는 원인이 있을 때, 증상만 건드리면 비슷한 패턴의 다른 화면에서 같은 버그가 나온다. 그래서 원인 파악 후 유사 패턴이 다른 경로에도 있는지 먼저 확인하는 게 습관이 됐다.

이 표가 거창해 보이지만 실제로는 10-15분짜리 작업이다. 안 하면 나중에 같은 이슈로 다시 불려오는 시간이 훨씬 길다. 엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보이는 것도 잠깐이고, 결국 미래의 내가 내는 비용을 지금 줄이는 것에 가깝다.

수정 전 현재 동작을 수치나 스크린샷으로 메모해두는 것도 같은 맥락이다. 수정 후 동일 케이스로 재현할 때 비교 기준이 생기고, 나중에 "원래 이게 어떻게 동작했더라"라고 돌아볼 때도 유용하다.

금융/결제 도메인은 숫자 정합성이 기본값

거래명세서는 단순 UI가 아니다. 거래처에 발행하거나 내부 정산의 기준이 되는 문서다. 건수가 하나 빠진 채로 출력되면 담당자 입장에서는 "시스템이 맞나?"라는 의심부터 생긴다. 그 의심이 쌓이면 신뢰가 무너진다. 숫자 하나짜리 버그가 단순한 버그로 끝나지 않는 이유가 여기 있다.

사내 서비스라도 마찬가지다. 오히려 사내 서비스는 QA 프로세스가 느슨해지기 쉬운데, 그걸 역으로 생각하면 간단한 cross-check 하나로 신뢰도를 꽤 올릴 수 있다.

인쇄 기능은 특히 "한 번 출력하면 그게 기록"이 되는 성격이 있어서 더 신경 쓴다. 화면은 새로고침하면 되지만 출력된 문서는 되돌리기 어렵다. 그래서 이번처럼 집계 로직이 바뀌는 수정은, SQL 집계/상태 머신/화면 렌더링 중 어느 레이어에서 숫자가 만들어지는지 경로를 한 번 짚고 넘어가는 편이다.

사내 서비스를 만들다 보면 기능 하나가 "버튼 하나 추가"로 끝나지 않는다는 걸 계속 체감한다. 이번 버그도 마찬가지였다. 변경 파일은 뷰 1개지만, 그 안에 페이지네이션 집계 구조 파악, 유사 경로 탐색, 회귀 확인이 같이 들어가 있다.

커밋은 "무엇을" 보다 "왜"를 담으려고 노력한다. 이번 커밋도 "건수 누락 수정"보다는 페이지 루프 수집으로 집계 방식을 바꿨다는 맥락을 메시지에 남겼다. 나중에 git log를 봤을 때 수정 의도가 이어져야 하기 때문이다. 논리적으로 독립된 단위로 커밋을 쪼개는 습관도 같은 이유인데, 뭔가 깨졌을 때 원인 커밋을 찾는 시간이 확연히 줄어든다.