핀코드 자릿수 변경이 표시·검증·CSS까지 번진 이야기

시작은 단순했음

처음엔 핀코드 자릿수만 바꾸면 끝날 줄 알았음. 12자리에서 16자리로. 유틸 한 줄 수정하고 커피 마실 작정이었는데 그게 함정이었음.

숨어있던 호출 지점들

생성 유틸 한 곳만 보면 될 것 같았는데, 추적해보니 같은 값이 표시·검증·전송·저장 네 축에 다 박혀있었음.

특히 주문 완료 페이지에서 핀코드 그룹을 보여주는 박스 너비가 12자리 기준 고정 픽셀로 박혀 있었음. 16자리 넣으니까 줄바꿈되면서 한 그룹이 다음 줄로 떨어짐. 이런 건 단위 테스트로 절대 안 잡힘.

"최종" 다음에 "최최종"이 오는 이유

스스로 끝났다 싶을 때마다 Codex 검증 돌리는 습관이 있음. 이번엔 세 라운드 돌았음.

• 1차: 정규식 자릿수 누락 → 잡힘
• 2차: 그룹 분리 후 빈 그룹 처리 (16은 4로 딱 떨어져서 OK였지만 가드 추가) → 잡힘
• 3차: CSS 고정 너비 → 잡힘

[1차] "다 됐다" → Codex: 정규식 12 남음
[2차] "이번엔 진짜" → Codex: 분리 함수 가드 빠짐
[3차] "최종" → Codex: 화면 너비 안 맞음
[4차] "최최종" → 통과

커밋 메시지에 "최최종"이라고 적는 순간 자존심이 좀 꺾이지만, 안 적었으면 누구도 이 자릿수 변경에 화면 깨짐이 묶여 있는 줄 몰랐을 것임.

배운 것

• 자릿수 같은 스칼라 상수도 표시·검증·전송·저장 네 축으로 영향 그래프를 그려야 함
• "한 줄 수정"이 정말 한 줄로 끝나는 경우는 거의 없음. 호출 지점 grep을 먼저 깔고 시작하기
• 자기 검증은 자기 만족도와 비례함. 외부 시점(Codex)이 들어와야 만족 너머의 결함이 보임
• 커밋 메시지에 "최종" 쓰지 말고 그냥 버전 번호 박는 게 정신건강에 좋음

다음