한꺼번에 바꿨더니 문의가 들어왔다

비밀번호 규칙을 강화하면서 기존 회원 전원을 변경 필요 상태로 바꿨다. 다음 날 문의가 몰렸다.

Open Table of contents

무엇을 바꿨나

MySQL 에서 member 의 pw_change_required 를 전부 켜는 UPDATE 한 줄을 돌렸다. 로그인하면 비밀번호 변경 화면으로 보내는 Servlet 코드는 이미 있었다.

의도한 대로 됐다. 4,000명 전원이 그 JSP 화면을 만났다.

들어온 문의는 세 종류였다. 새 비밀번호가 규칙에 안 맞는다고 나오는데 규칙이 화면에 없다는 것, 예전 비밀번호를 다시 넣었는데 왜 안 되는지 안 나온다는 것, 그리고 바꾸고 나서도 계속 그 화면이 나온다는 것이다.

셋째가 진짜 문제였다. MemberDao.updatePassword() 에서 플래그를 안 내리고 있었다.

memberDao.updatePassword(id, newPw);
// pw_change_required 를 안 내렸다

바꿔도 pw_change_required 가 그대로니 다음 로그인에서 또 간다. 전원에게 한꺼번에 나간 뒤라 이 버그도 전원에게 나타났다.

UPDATE 전 값이 어디에도 없었다. 원래 켜져 있던 사람과 이번에 켠 사람을 구분할 방법이 없다.

전원을 끄는 수밖에 없는데 그러면 원래 바꿔야 했던 사람까지 풀린다. CREATE TABLE ... AS SELECT 한 줄이면 됐는데 그걸 안 했다.

CREATE TABLE member_pw_flag_backup_20111015 AS
SELECT no, pw_change_required FROM member;

전원을 한 번에 바꾼 것이 근본 문제였다. LIMIT 으로 나눠 했으면 첫 묶음에서 알았을 것이다. 5퍼센트만 먼저 켜고 하루 보면 됐다. 고친 뒤에 나머지를 켰다.

나누는 기준을 잘 잡으면 대상 자체가 준다. 무작위가 아니라 pw_updated_at 이 오래된 사람부터 하면 되는 일이었다. 최근에 바꾼 사람까지 다시 바꾸게 할 이유가 없다. WHERE 조건을 그렇게 두니 대상이 4,000명에서 900명이 됐다.

문의 내용은 그대로 JSP 에 넣을 것이었다. 규칙을 미리 적어 두면 틀린 뒤에 알려 주지 않아도 된다. 틀렸을 때도 무엇이 어떻게 틀렸는지 적으면 몇 번씩 다시 넣지 않는다.

며칠 뒤 문의를 종류별로 세니 바꿔도 또 나온다는 것이 18건, 규칙을 모르겠다는 것이 11건, 예전 것을 못 쓴다는 것이 6건이었다. 가장 많은 것이 버그였다. 세어 보지 않았으면 원래 문의가 많은 작업으로 넘겼을 것이다.