운영 DB 에 남은 테스트 계정이 고객 가입을 막았다

갤러리에서 "가입이 안 된다"는 연락이 왔다. 로그를 봤더니 이렇게 찍혀 있었다.

15:08:36  구글로 계정 생성
15:09:31  로그인 성공
15:09:59  프로필 저장

가입은 됐다. 계정도 있고 로그인도 됐다. 그런데 갤러리 관리 화면이 안 열린다고 했다.

실패한 건 가입이 아니라 신청이었다

2026-08-27, 아트페어 관람 플랫폼을 운영한다. 갤러리가 가입해서 부스와 작품을 등록하면 관람객이 QR 로 그걸 본다. 9월 초에 큰 페어가 있어서 갤러리들이 한창 들어오는 중이었다.

처음엔 가입 실패를 의심했다. 로그인 오류, 폼 제출 실패, 권한 설정 — 전부 아니었다. 신청서가 들어가는 테이블이 비어 있었으니 신청 자체를 못 한 것이었다.

가입 화면은 자기 갤러리 이름을 검색해서 고르고, 담당자 정보를 채워 내는 구조다. 이미 우리가 도록에서 수집해둔 갤러리면 그 정보를 그대로 이어받는다.

그 검색 결과에서 자기 갤러리가 회색으로 「이미 등록됨」 이라 눌리지 않았다.

이유를 찾으니 두 달 전 기록이 나왔다.

2026-06-05 16:21  신청
2026-06-05 16:26  승인 → 직원 계정 1개 연결됨

내가 테스트로 넣고 안 지운 계정이었다. 시스템은 "이 갤러리는 이미 주인이 있다"고 정확하게 판단하고 있었다. 버그가 아니라, 두 달 전 내가 남긴 쓰레기가 정상 동작을 막은 것이다.

덤으로 하나 더 나왔다. 그 테스트 계정에 운영자 권한이 붙어 있었다. 바깥 사람 계정이 내부 관리 콘솔에 들어갈 수 있는 상태로 두 달을 굴렀다.

「테스트 계정을 지운다」와 「그 갤러리를 지운다」는 다른 일이었다

지우기 전에 뭐가 딸려 있는지부터 셌다. 이게 제일 중요한 단계였다.

갤러리 마스터 정보     2026-04-13 생성   ← 테스트 계정보다 두 달 먼저 있던 진짜 자료
9월 페어 부스 배정      B15, 진행 중      ← 지우면 지도가 깨진다
과거 참가 이력          66건
소속 작가               9명

갤러리 자체는 도록에서 수집한 진짜 자료였고, 이미 이번 페어 지도에 부스가 찍혀 있었다. 지워야 할 건 연결 고리 한 줄뿐이었다.

그래서 마이그레이션에 검사를 넣었다. 예상과 다르면 전부 되돌린다.

delete from exhibitor_accounts
 where exhibitor_id = <그 갤러리> and member_id = <테스트 계정>;
get diagnostics v_deleted = row_count;
if v_deleted <> 1 then
  raise exception '예상 1행, 실제 %행. 자료가 이미 바뀌었다. 중단한다.', v_deleted;
end if;

-- 그리고 지우면 안 되는 것이 살아 있는지도 같은 트랜잭션에서 확인한다
if not exists (select 1 from exhibition_participations
                where exhibitor_id = <그 갤러리> and status = 'active') then
  raise exception '페어 참가가 사라졌다. 중단한다.';
end if;

되돌릴 수 없는 삭제를 운영 DB 에 밀 때, 「지운 게 1행인가」보다 「지우면 안 되는 게 아직 있는가」를 같이 확인하는 쪽이 실제로 나를 살렸다. 지우는 대상만 검사했으면 갤러리 마스터를 통째로 날렸어도 통과했을 것이다.

계정을 지우자 「이미 등록됨」이 풀렸고, 다음 날 오전 그 갤러리가 정상적으로 가입을 마쳤다.

남는 것

테스트 데이터는 보통 "지저분하다"는 이유로 정리 대상이 된다. 이번 건은 그것보다 나빴다 — 진짜 고객이 서비스에 못 들어오게 막았고, 막힌 쪽에서는 그냥 "가입이 안 된다"로만 보였다. 에러도 안 났다.

그리고 그 사람이 우리에게 말해주지 않았으면, 나는 영영 몰랐을 것이다.