승인된 상품 수정 시 재승인 흐름 버그 수정
목차
supplier 버그를 수정했음. APPROVED 상품 수정 → 재승인 흐름.
변경 파일: 내부 클래스 1개, SQL 매퍼 1개, 뷰/스타일 1개
문제 원인
기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음.
수정 내용
- SQL 쿼리 조건/집계 수정
- 내부 클래스 로직 수정
- 화면 렌더링 수정
- 프론트 스크립트 수정
버그 수정 프로세스
단순히 증상만 픽스하는 게 아니라 왜 발생했는지 원인을 파악하고 수정했음. 비슷한 패턴이 다른 곳에도 있는지 확인했고, 위험한 케이스는 함께 수정했음.
버그 수정 시 체크리스트:
- 같은 로직이 다른 경로에도 있는지 (중복 코드 체크)
- 수정이 기존 정상 케이스를 망가뜨리지 않는지 (회귀 방지)
- 해당 화면 또는 API에서 실제 동작 확인
- 관련 숫자를 다른 화면과 cross-check
엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 나중에 같은 버그로 다시 오는 시간 비용이 훨씬 큼.
검증
수정 후 버그를 직접 재현해서 정상 동작 확인. 숫자 정합성도 관련 화면과 비교했음.
다음
작업 후기
사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.
특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.
개발 방식
- 변경 전 현재 동작 스크린샷이나 수치 메모
- 수정 후 같은 케이스로 확인
- 관련 화면이 있으면 숫자 cross-check
- 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력
작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.
다음
댓글 0
첫 댓글 달아줘.