기대 멤버 집합의 완전성 검증과 원자 upsert
묶음 결과는 행 하나가 아니라 같은 batch key에 속한 기대 멤버 전체로 판정해야 합니다. 일부 행만 존재하는 상태를 완료로 오인하지 않는 읽기·쓰기 계약을 설명합니다.
묶음 생성 결과는 행 하나가 아니라 같은 batch_key에 속한 기대 member_code 집합 전체가 제품 결과입니다. 멤버 하나가 존재한다고 묶음 전체가 준비된 것은 아닙니다.
읽기와 쓰기의 같은 판정
조회는 GROUP BY batch_key 뒤 멤버 집합을 비교하고, 기대 집합과 같을 때만 생성 단위를 skip합니다. 부분 행은 다음 생성 라운드가 복구할 수 있도록 미완료로 남깁니다. 생성기는 중복·미지원 코드·잘못된 코드 이름·개수 부족을 DB 앞에서 거절합니다.
한 묶음, 한 transaction
| 판정 | 저장 동작 | 재시도 |
|---|---|---|
| 기대 멤버 전체 | 한 transaction으로 upsert | 불필요 |
| 멤버 일부 누락·중복 | 저장하지 않음 | 전체 묶음 재생성 |
| DB 오류 | rollback | 같은 묶음 재시도 |
검증된 기대 개수의 행은 executemany와 한 번의 commit으로 저장합니다. 한 행에서 오류가 나면 rollback하고 count를 0으로 보고합니다. 이렇게 하면 UI가 일부 성공을 전체 성공으로 오인하지 않고, scheduler가 재시도할 범위를 유지합니다.
이 원칙은 LLM 출력뿐 아니라 수동 Admin 생성과 자동 scheduler에도 적용해야 한다. 충돌 정책이 마지막 쓰기 우선이어도 완전하지 않은 묶음을 성공으로 만드는 것과는 별개의 문제다.
관련 강좌: 부분 실패·복구·플랫폼 경계를 교차 서비스 계약으로 닫기
검증할 때는 저장 전후의 기대 멤버 집합이 정확히 같은지, 오류 주입 뒤 행 수가 이전 상태로 유지되는지 함께 확인합니다.
data 카테고리의 다른 글
카테고리 전체 보기 →관련 글
여러 PostgreSQL 풀 한 앱에서 관리하기
관리 콘솔이나 백오피스는 한 프로세스에서 콘텐츠·카탈로그·운영 로그처럼 서로 다른 DB에 접근해야 할 수 있습니다. HTTP 경유 대신 풀 직접 접속을 선택할 때는 연결 수, 권한, 장애 격리를 함께 설계해야 합니다.
감사로그 — logAdminAction 패턴
관리자 기능을 갖춘 백엔드에서 "누가 · 언제 · 무엇을 · 왜" 의 네 축을 기록하는 감사로그 (audit log) 는 단순한 관행 이상입니다. 개인정보보호법 · GDPR 같은 규정 준수, 사고 조사, 권한 오남용 방지의 실질 수단.
SQL 을 단일 진실 출처로
스키마는 어디에서 진실을 가질 것인가. ORM 모델·마이그레이션 파일·DDL SQL — 후보가 여럿입니다. 누적 마이그레이션 모델과 단일 SQL 파일 + CREATE IF NOT EXISTS 모델을 비교합니다.
Supabase
Supabase 는 Firebase 의 대안을 표방하며 등장한 오픈소스 백엔드 묶음입니다. 핵심에 PostgreSQL 을 두고 인증·스토리지·실시간·서버리스 함수를 그 주위에 쌓았습니다.