파트너포털 보증 잔액 면제 라벨 위치 오류 수정

partner-portal에서 보증 잔액 면제 라벨이 엉뚱한 자리에 붙어 있는 버그를 수정했다. 면제 라벨이 보유금액 컬럼에 렌더링되고 있었고, 수정 후에는 보증 잔액 컬럼 자리에 제대로 표시되도록 바꿨다. 변경 파일은 뷰/스타일 1개. 파일 수는 적지만 원인을 파악하고 주변 패턴을 정리하는 데 훨씬 많은 시간이 걸렸다.

문제 원인

기존 로직에서 면제 상태에 대한 엣지 케이스가 처리되지 않고 있었다. 면제 상태인 행은 일반 행과 다른 레이아웃 분기를 타야 하는데, 그 분기 처리가 누락된 채 공통 템플릿을 그대로 쓰면서 라벨이 엉뚱한 셀에 붙어 있었다.

이런 버그가 생기는 맥락은 대개 비슷하다. 처음 화면을 만들 때는 정상 케이스만 보고 마크업을 짠다. 이후 면제, 유예, 부분 처리 같은 예외 상태가 기획에 추가되면, 기존 뷰 로직을 최소한으로 건드리면서 조건 하나를 덧붙이는 방식으로 구현된다. 그러다 보면 라벨이 어느 <td>에 붙는지는 처음 설계 기준으로 고정된 채, 데이터만 면제 상태를 가리키게 된다. 시간이 지나면 "어? 이게 왜 여기 있지?" 하는 버그로 나타난다.

이번도 비슷한 패턴이었다. 처음 보증 잔액 화면을 만들 때는 면제 케이스가 없었고, 나중에 면제 상태가 추가되면서 기존 템플릿에 조건만 얹은 것으로 보였다. 문제는 그 조건이 올바른 셀을 가리키고 있지 않았다는 것.

<!-- 수정 전: 면제 라벨이 보유금액 셀에 렌더링됨 -->
<td class="holding-amount">
  {{ holding_amount }}
  <span v-if="isExempt" class="badge-exempt">면제</span>
</td>
<td class="warranty-balance">{{ warranty_balance }}</td>

<!-- 수정 후: 면제 라벨은 보증 잔액 셀에 -->
<td class="holding-amount">{{ holding_amount }}</td>
<td class="warranty-balance">
  {{ warranty_balance }}
  <span v-if="isExempt" class="badge-exempt">면제</span>
</td>

코드만 보면 두 줄 이동이다. 이 두 줄을 찾기까지 컬럼 매핑, 데이터 바인딩, 스타일 정의를 차례로 타고 올라가는 과정이 필요했음. 화면에서 '면제'라는 글자가 보이는데 위치가 어색하다는 게 처음 증상이었고, 어느 컬럼 기준으로 어색한 건지 데이터와 뷰를 번갈아 보면서 좁혀 나갔다.

수정 범위와 검증

화면 렌더링과 프론트 스크립트를 같이 수정했다. 렌더링만 고치면 스크립트에서 면제 상태를 판단하는 조건이 여전히 엉뚱한 값을 참조할 수 있어서 두 부분을 함께 정리했다.

수정하면서 확인한 항목들:

비면제 케이스 확인이 특히 중요했다. 라벨 위치를 옮기면서 셀 구조가 바뀌면, 면제가 아닌 정상 행에서도 레이아웃이 틀어질 수 있다. 수정 후 두 케이스를 나란히 두고 확인하는 게 기본인데, 바쁘면 빠뜨리기 쉬운 부분이기도 하다.

면제 라벨이 잘못된 자리에 있으면 단순히 보기 불편한 수준이 아니다. 파트너 포털 맥락에서 보증 잔액과 보유금액은 의미가 다른 수치고, 어느 항목이 면제됐는지는 파트너가 의사결정할 때 기준이 되는 정보다. 틀린 컬럼에 면제 표시가 붙으면 파트너는 잘못된 항목을 면제 처리된 것으로 읽게 된다.

버그 수정 프로세스

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

버그를 처음 접했을 때 바로 코드로 뛰어들지 않고 재현부터 하는 습관이 있다. 재현이 안 되면 수정했는지도 모르고, 재현 조건을 알면 수정 후 검증도 명확해진다. 상태값에 따라 다르게 동작하는 화면 버그는 어떤 데이터 조건에서 터지는지를 먼저 특정해야 원인 범위가 좁아짐. 이번처럼 "면제 상태일 때만 재현"이라는 조건이 명확하면 수정 후 확인도 그 조건으로 바로 검증할 수 있다.

커밋도 논리 단위로 쪼갰다. 렌더링 수정과 스크립트 수정을 한 커밋에 몰아넣지 않고 나눴다. 나중에 같은 화면에서 다른 문제가 생겼을 때, 커밋이 잘게 쪼개져 있으면 어느 변경에서 생긴 문제인지 빠르게 찾을 수 있다. 체감이 크지 않아 보이는데, 실제로 문제 터졌을 때 차이가 꽤 난다. 그래서 논리적으로 독립된 단위로 커밋을 나누는 습관을 유지 중이다.

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 뭔가 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 분기, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 상황에서 이상한 화면이 나온다. 이번 수정이 파일 1개라도, 그 파일이 맞는 자리를 찾기까지의 과정은 간단하지 않았다.

특히 금융/보증 도메인은 숫자 하나, 라벨 하나가 틀리면 신뢰가 흔들릴 수 있어서 꼼꼼함이 기본값이어야 한다. "대충 맞는 것 같다"로 넘어가면 반드시 다시 돌아온다는 걸 작업할 때마다 다시 확인하게 됨.

개발 루틴으로는 변경 전 현재 동작을 스크린샷이나 수치로 메모하고, 수정 후 같은 케이스로 확인하는 방식을 유지한다. 관련 화면이 있으면 숫자를 cross-check하고, 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력한다. 몇 달 뒤 같은 맥락의 이슈를 다시 볼 때 과거 커밋 메시지 하나가 꽤 큰 단서가 되는 경험이 있어서, 귀찮아도 이 습관을 유지하는 중이다.

엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 같은 버그로 다시 오는 시간 비용이 훨씬 크다. 버그 수정에서 가장 중요한 건 "고쳤다"는 확인이 아니라 왜 생겼고 어디까지 영향을 미쳤는가를 파악하는 것. 그게 돼야 비슷한 버그가 다시 생겼을 때 이번처럼 찾는 데 오래 걸리지 않는다.