실패한 마감이 삭제 밑에 묻혔다

퇴직한 강사의 과정에 그룹 교육 포털을 통해 실제 수강 신청이 들어왔다. 우리 목록에는 없는 과정이었다.

Open Table of contents

증상 — 목록에 없는 과정
타임라인 — 시간순으로 봤다
원인 — 실패를 덮는 삭제
결과 — 포털에서는 모집중
재발 방지 — 삭제 전에 확인한다
주의 — 확정 못 한 것
정리

증상 — 목록에 없는 과정

먼저 조회했다.

SELECT * FROM portal_course_links WHERE course_id = ?;

0건

deleted_at 을 포함해 보니 나왔다.

SELECT *, deleted_at FROM portal_course_links
 WHERE course_id = ? AND deleted_at IS NOT NULL;

deleted_at   (1년 전)

deleted_at 이 1년 전으로 찍힌 소프트 삭제 상태였다.

목록에 없는데 수강 신청이 들어온다면 우리 자료와 포털 상태가 갈려 있다는 뜻이다. 갈린 시점이 언제이고 무엇 때문인지를 찾아야 했다.

타임라인 — 시간순으로 봤다

작업 이력을 시간순으로 조회했다.

SELECT event, created_at, fail_status, last_log
  FROM portal_sync_jobs
 WHERE course_id = ? AND portal = ?
 ORDER BY created_at;

두 줄이 결정적이었다.

(1년 반 전)  close  FAIL   '포털 최대 입력 가능한 과정명 글자수는
                            공백포함 90byte 입니다.(입력: 96byte)'
(1년 전)     ---    link soft delete

close 가 FAIL 로 끝난 뒤 반년쯤 지나 삭제가 이어졌다.

① 마감 작업 발사  →  실패 (글자수 초과)
② 실패를 아무도 안 봄
③ 강사 퇴직 처리 → 소프트 삭제
④ 목록에서 사라짐
⑤ 포털에서는 계속 모집중

close 가 안 됐는데 우리 쪽에서만 지운 것이었다.

원인 — 실패를 덮는 삭제

close 실패만 있는 경우와 삭제까지 된 경우를 나란히 놓았다.

[마감 실패만 있었으면]  목록에 실패 상태로 남음 → 눈에 띔
[삭제까지 되면]         목록에서 아예 사라짐 → 안 보임

deleted_at 이 채워지면 화면과 목록에서 전부 빠진다.

실패한 작업을 찾는 조회도 deleted_at IS NULL 을 달고 있어 함께 빠지고 다시 시도할 기회가 사라진다. 실패가 해결된 것이 아니라 안 보이는 곳으로 들어간 것이다.

결과 — 포털에서는 모집중

우리 쪽에서 안 보이는 동안에도 포털에서는 계속 유효했다.

[우리]  이 강사 과정 없음
[포털]  모집중

모집중 이라 수강 신청이 들어오는데 퇴직한 강사라 처리할 사람도 없었다.

last_log 에 남은 실패 사유는 사소했다. 상한이 90바이트인데 96바이트가 들어가 6바이트 초과로 걸린 것이었다. 마감 요청인데 과정명 검증에 걸린 것은 포털 API 가 마감에도 전체 과정 데이터를 요구하기 때문이었다.

재발 방지 — 삭제 전에 확인한다

close 와 삭제 사이의 순서를 한 단계 바꿨다. 실패 목록을 따로 보는 것과 삭제 전에 확인하는 것 두 가지 방법 중 뒤쪽을 골랐다. 이유는 따로 보는 목록은 사람이 안 열면 그만이라서다.

[사고 순서]  마감 발사 → (실패) → 삭제
[안전 순서]  마감 발사 → 성공 확인 → 삭제

확인 쿼리도 함께 남겼다.

SELECT event, fail_status, last_log
  FROM portal_sync_jobs
 WHERE course_id = ? AND portal = ? AND event = 'close'
 ORDER BY created_at DESC LIMIT 1;

fail_status 가 실패면 삭제하지 않고 실패 상태로 목록에 남겨 둔다.

소프트 삭제는 정리가 아니라 감춤이었다. 문제가 해결돼서 없애는 것과 문제가 있는 채로 안 보이게 하는 것은 다르다. 해결 여부를 확인하지 않고 감추면 그 문제가 영속화된다.

주의 — 확정 못 한 것

같은 조사에서 instructors 쪽이 하나 더 걸렸다.

SELECT is_active, deleted_at FROM instructors WHERE id = ?;

is_active   1
deleted_at  NULL

퇴직한 강사인데 상위 표에는 활성으로 남아 있었다.

다른 방식으로 관리되는 것일 수도 있고 누락일 수도 있어 확정하지 못했다. 기록에는 반영이 안 됐거나 다른 방식으로 관리되는 것으로 보인다고 미확정으로 적었다.

instructors 한 건으로는 결함인지 설계인지 안 갈린다. 확인하지 않은 것을 확인한 것처럼 적으면 다음 사람이 그것을 근거로 판단한다.

정리

작업 실패 위에 소프트 삭제가 얹히면 목록에서 완전히 사라진다
실패를 찾는 조회에서도 함께 빠진다
삭제가 실패를 덮어 없어진 것처럼 만든다
우리 쪽에서 안 보여도 포털에서는 계속 유효하다
사소한 실패가 안 보이는 곳으로 들어가면 사고가 된다
삭제 이전에 성공 여부를 확인한다
실패면 삭제하지 않는다
소프트 삭제는 정리가 아니라 감춤이다
확정 못 한 것은 미확정으로 적는다