에러 메시지만 보고 코드부터 고치지 않는 법

카드뉴스 생성 버튼을 눌렀는데, 이런 오류가 떴습니다.

기존 카드뉴스 초안 조회 실패: JSON object requested, multiple (or no) rows returned

에러 메시지만 보면 "row가 없거나, 여러 개"라는 뜻인데, 어느 쪽인지는 알 수 없었습니다. 이럴 때 가장 위험한 건 메시지를 대충 해석해서 바로 코드를 고치는 것이라고 생각합니다. 잘못된 추측 위에 수정을 쌓으면, 문제는 사라진 것처럼 보이다가 나중에 더 복잡한 형태로 다시 나타나기 때문입니다.

그래서 코드를 만지기 전에 Supabase Table Editor를 열어 실제 데이터부터 확인했습니다. 확인해보니 원인은 명확했습니다. 같은 게시글 하나에 카드뉴스 초안이 5건이나 중복 저장되어 있었습니다. 조회 로직은 .maybeSingle()을 쓰고 있었는데, 이 함수는 "결과가 0건 또는 1건일 것"이라는 전제 위에서만 정상 동작합니다. 실제로는 재생성 버튼을 여러 번 누르며 중복이 계속 쌓여온 상태였습니다.

여기서 판단이 하나 더 필요했습니다. 5건 중 무엇을 남길 것인가 하는 문제였습니다. 단순히 "가장 오래된 것" 또는 "가장 최근 것"으로 기계적으로 정하지 않고, 각 초안의 생성 시각과 실제 슬라이드 문구를 하나씩 대조해봤습니다. 다행히 내용이 점점 다듬어지는 흐름이 보였고, 별도로 보존해야 할 완성본은 없다는 걸 확인한 뒤에야 삭제를 진행했습니다. 삭제는 되돌릴 수 없는 작업이라, 이 판단만큼은 자동화에 맡기지 않았습니다.

작업을 진행하며 또 하나 발견한 게 있습니다. dev와 prod, 두 운영 환경이 사실은 서로 다른 상태였다는 점입니다. dev DB에는 이미 post_id에 대한 UNIQUE 제약이 걸려 있었는데, prod에는 없었습니다. 같은 스키마라고 믿고 있었던 두 환경이 실제로는 어긋나 있었던 겁니다. 이런 차이는 겉으로 잘 드러나지 않다가, 이번처럼 데이터가 쌓이고 나서야 문제로 드러납니다.

원인이 명확해진 뒤에는 수정 방향도 명확해졌습니다. 중복 데이터를 정리하고, 두 환경 모두에 UNIQUE 제약을 맞춰 걸었습니다. 그리고 "먼저 조회해서 있으면 업데이트, 없으면 삽입"하던 분기 로직을, Supabase의 upsert(onConflict: 'post_id') 호출 한 번으로 리팩터링했습니다. 결과적으로 코드는 77줄이 줄고 24줄만 늘어, 로직 자체가 더 단순해졌습니다.

수정하는 과정에서 AI(Antigravity)가 제시한 설명 하나도 그대로 넘기지 않았습니다. updated_at 필드를 upsert 페이로드에서 빼도 되는지 물었을 때, "일반적으로 DB 트리거가 자동으로 갱신해줄 것"이라는 답이 돌아왔습니다. 그럴듯해 보이지만 확인된 사실은 아니었습니다. 마이그레이션 파일을 직접 검색해보니 이 프로젝트에는 트리거가 전혀 없었고, 그 자리에서 계획을 수정해 updated_at을 코드에서 직접 채워 넣는 방향으로 바꿨습니다.

신규 생성과 재생성, 두 가지 시나리오를 모두 dev 환경에서 검증한 뒤 prod에 배포했고, 배포가 끝난 뒤에도 실제 사이트에서 다시 한번 같은 테스트를 반복했습니다.

이번 디버깅에서 남은 원칙은 세 가지입니다.

첫째, 에러 메시지가 아니라 데이터부터 봅니다. 모호한 메시지를 추측으로 메우지 않고, 실제 테이블을 열어 정답을 확인하는 편이 결국 더 빠릅니다.

둘째, AI의 설명도 검증 대상입니다. 그럴듯한 설명이라도 사실 확인 없이 그대로 받아들이지 않고, 근거가 있는지 직접 찾아봅니다.

셋째, 되돌릴 수 없는 작업은 사람이 마지막으로 확인합니다. 데이터 삭제나 스키마 변경처럼 되돌리기 어려운 단계는 AI에게 맡기지 않고, 실행 결과를 직접 눈으로 확인한 뒤에만 다음 단계로 넘어갑니다.

이 세 가지는 이번 버그 하나에 국한된 이야기가 아니라, 다른 자동화 기능을 디버깅할 때도 그대로 적용할 수 있는 절차라고 생각합니다.