「일부만 안 된다」는 신고와 「건수 + 1」의 함정 (2026.09.21 ~ 09.25)

Об этом предложении

「일부만 안 된다」는 신고와 「건수 + 1」의 함정 (2026.09.19 ~ 09.22) 이번 주는 점검 요청 하나와 고객 신고 둘이 겹쳤다. 셋 다 "이미 알고 있다고 생각한 것"이 틀렸다는 공통점이 있어서 같이 적어 둔다. 점검은 차집합으로 한다 커머스 플랫폼 쪽에서 "새로 승인된 제휴가 있는지 확인해 달라"는 요청이 왔다. 새 승인은 없었다. 거기서 끝낼 수도 있었는데, 승인 목록과 실제 사이트 연결 목록을 나란히 놓고 보니 이미 승인된 매장 몇 곳이 여러 사이트 중 한 곳에만 연결돼 있었다. 나머지 사이트에서는 승인을 받아 놓고도 목록형으로 놀고 있었던 셈이다. 승인이 날 때마다 사이트 수만큼 관리자 폼을 반복해서 누르는 일은 사람이 할 일이 아니라고 판단했다. 관리자 화면과 같은 검증·저장·게시 경로를 타는 내부 일괄 입구를 만들어 미연결 십여 쌍을 한 번에 넣었다. 다음 자동 연결 주기에서 사이트마다 수십 건이 제휴형으로 붙었고 검색 노출에서 빠져 있던 매장들도 색인 대상이 됐다. 수익이 얼마나 늘었는지는 아직 집계 전이라 숫자가 없다. "새 승인 없음"은 질문에 대한 답이지 점검의 끝이 아니다. 가진 것과 쓰고 있는 것의 차집합을 구해야 놀고 있는 자산이 보인다. 실수도 하나 있었다. 로컬 브랜치가 서버보다 뒤처진 상태에서 배포 스크립트를 돌려 옛 코드를 다시 배포했다. 다행히 무해했지만 공유 트리에서는 푸시 전에 behind 를 세고 뒤면 임시 워크트리에서 작업하기로 했다. 표시용 문자열에서 숫자를 다시 뽑지 않는다 레거시 관리 시스템에서 「1TB 모델 전 색상에 바이어 단가가 붙지 않는다」는 신고가 왔다. 256GB·512GB 는 되고 1TB·2TB 만 안 됐다. 표기와 계산값이 따로 놀았다. 서버는 1024GB 를 화면용으로 「1T」라고 내려주는데, 화면은 이 문자열에서 숫자만 뽑아 「1」로 단가표 키를 만들고 있었다. 단가표는 1024 로 저장돼 있으니 영원히 맞을 수 없다. 같은 방식이 여섯 곳에 흩어져 있었고 저장 쪽도 같은 버그라 「용량 1」짜리 잘못된 행을 단가표에 만들어 두고 있었다. 그 행 때문에 일부 색상이 엉뚱한 단가를 받은 것도 이때 확인했다. 서버와 같은 변환 규칙 하나로 여섯 곳을 통일하고 0원 단가는 「단가 없음」으로 드러나게 했다. 48행 전표에서 48행 전부 단가가 적용됐다. 고치기 전이라면 18행은 빈칸, 27행은 엉뚱한 값이었을 것이다. 뼈아픈 건 이 버그를 3일 전 내가 옮겨 심었다는 점이다. 등록 창 코드를 수정 창으로 복사하면서 같이 가져왔다. 이전 세대 모델의 1TB 도 처음부터 안 됐는데 아무도 몰랐다. 앞으로 「일부 값만 안 된다」는 신고는 표기와 계산값이 갈라지는 지점부터 본다. 표시용 문자열에서 값을 역산하지 말고 원래 값을 쓴다. 코드를 복사해 옮길 때는 그 코드의 버그도 같이 옮긴다는 걸 전제로 한 번 더 본다. 일련번호는 최대값 기준으로 만든다 같은 시스템에서 출고 등록 중 unique 제약 위반으로 저장이 안 된다는 신고가 왔다. 한 번 나면 그날 내내 모든 등록이 막히는 문제였다. 그날 번호를 뽑아 보니 중간 하나가 지워져 있었다. 번호 생성이 「그날 건수 + 1」이라, 삭제가 한 건 있으면 이미 쓴 번호를 다시 발급한다. 「그날 최대 번호 + 1」로 바꿨다. 다만 창을 열 때 번호가 정해지는 구조라 동시 등록에서도 겹칠 수 있다고 봤다. 저장 시점에 다음 번호로 최대 5번 재시도하게 했다. 재시도로 바뀐 번호는 감사로그에 남기고 사람이 직접 적은 번호는 말없이 바꾸지 않게 했다. 구멍 상태에서 옛 규칙이 중복 번호를 내던 것이 새 규칙에서는 다음 번호로 나왔다. 저장 직전 다른 사람이 같은 번호를 선점하는 경쟁 상황도 재현해 자동으로 다음 번호에 저장되고 감사로그에 남는 것을 확인했다. 신고에서 운영 반영까지 같은 날 오전에 끝났다. 생성기만 고치면 절반이다. 번호가 확정되는 시점에 충돌 대응까지 있어야 한다. 그리고 DB 의 unique 제약이 조용한 중복 데이터를 막아 준 마지막 방어선이었다. 오류로 드러난 게 오히려 다행이었다.

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.4

Уверенность

49%