개발 slecs

정산 화면 쿠폰마진 집계 버그와 날짜 표시 오류 수정

목차

merchant-balance 버그를 수정했음. 쿠폰마진 컬럼이 판매대금을 집계하던 버그 수정 + 일시 포맷팅.
변경 파일: 내부 클래스 1개, SQL 매퍼 1개, 뷰/스타일 1개

문제 원인

SQL 쿼리 조건이 잘못돼 있었거나, JOIN/필터 누락으로 데이터가 잘못 집계되고 있었음. 기대값과 실제값을 비교해서 어느 쿼리에서 차이가 발생하는지 좁혀 찾았음.

수정 내용

  • SQL 쿼리 조건/집계 수정
  • 내부 클래스 로직 수정
  • 화면 렌더링 수정
  • 프론트 스크립트 수정

버그 수정 프로세스

단순히 증상만 픽스하는 게 아니라 왜 발생했는지 원인을 파악하고 수정했음. 비슷한 패턴이 다른 곳에도 있는지 확인했고, 위험한 케이스는 함께 수정했음.

버그 수정 시 체크리스트:
- 같은 로직이 다른 경로에도 있는지 (중복 코드 체크)
- 수정이 기존 정상 케이스를 망가뜨리지 않는지 (회귀 방지)
- 해당 화면 또는 API에서 실제 동작 확인
- 관련 숫자를 다른 화면과 cross-check

엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 나중에 같은 버그로 다시 오는 시간 비용이 훨씬 큼.

검증

수정 후 버그를 직접 재현해서 정상 동작 확인. 숫자 정합성도 관련 화면과 비교했음.

다음

작업 후기

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.

개발 방식

  • 변경 전 현재 동작 스크린샷이나 수치 메모
  • 수정 후 같은 케이스로 확인
  • 관련 화면이 있으면 숫자 cross-check
  • 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.

다음

댓글 0

첫 댓글 달아줘.