0711 백엔드 실무 심화 (18/N): 데이터 정합성 검증, 모니터링과 운영 리포트 설계
✅ 1. 데이터 정합성이란 무엇인가?
- 데이터 정합성(Data Consistency)은 서비스 안의 데이터들이 서로 모순 없이 맞아떨어지는 상태를 의미합니다.
- 백엔드 실무에서는 상담 신청, 주문, 상태 변경, 결제, 알림 발송, 엑셀 다운로드, 통계 집계처럼 여러 테이블과 기능이 연결되기 때문에 데이터 정합성이 매우 중요합니다.
- 단순히 DB에 저장됐다고 끝이 아니라, 관련 테이블과 상태값, 이력, 통계가 서로 일관되게 맞아야 합니다.
상담 신청 생성
↓
Consult row 생성
↓
상태값 PENDING 저장
↓
ConsultStatusHistory 생성
↓
알림톡 Job 등록
↓
관리자 목록 노출
↓
일별 통계에 반영
- 이 중 하나라도 빠지면 데이터는 저장되었지만 운영상으로는 불완전한 상태가 됩니다.
✅ 2. 데이터 정합성이 깨지는 대표 상황
➕ 2-1. 상태값과 날짜 필드 불일치
status = DONE
completedAt = null
- 상담은 완료 상태인데 완료 시간이 없습니다.
- 이 경우 완료율 통계, 처리 시간 계산, 엑셀 다운로드 기준이 틀어질 수 있습니다.
status = PENDING
completedAt = 2026-07-11 14:30
- 신규 접수 상태인데 완료 시간이 있는 것도 정합성 문제입니다.
➕ 2-2. 현재 상태와 상태 변경 이력 불일치
Consult.status = DONE
하지만 ConsultStatusHistory 마지막 이력:
toStatus = CALLING
- 현재 상태는 완료인데 이력상 마지막 상태는 상담 중입니다.
- 누가 언제 완료 처리했는지 추적할 수 없습니다.
➕ 2-3. ExportJob 상태와 S3 파일 불일치
ExportJob.status = COMPLETED
fileKey = private/exports/consults/2026/07/11/file.xlsx
하지만 실제 S3 파일 없음
- 관리자 화면에서는 다운로드 가능으로 보이지만 실제 파일은 없습니다.
- S3 삭제 배치나 업로드 실패 처리에서 정합성이 깨질 수 있습니다.
➕ 2-4. 알림 발송 상태와 실제 발송 결과 불일치
NotificationLog.status = SUCCESS
하지만 providerMessageId 없음
또는 외부 API Webhook에서는 실패 결과 수신
- 내부 DB와 외부 제공업체 결과가 다르면 고객에게 알림이 갔는지 확신할 수 없습니다.
➕ 2-5. 통계 테이블과 원본 데이터 불일치
DailyConsultSummary.doneCount = 120
하지만 Consult 원본 기준:
해당 날짜 DONE 건수 = 115
- 대시보드, 보고서, 광고 성과 분석이 틀어질 수 있습니다.
- 배치 집계 누락, 중복 집계, 날짜 기준 오류 때문에 자주 발생합니다.
✅ 3. 데이터 정합성 검증이 필요한 이유
- 운영 서비스에서는 오류가 꼭 500 에러로 드러나지 않습니다.
- API는 정상 응답했지만 DB 데이터가 조용히 틀어지는 경우가 더 위험합니다.
➕ 3-1. 정합성 검증이 필요한 영역
상담 신청
주문/결제
상태 변경 이력
엑셀 Export
알림톡/SMS
Webhook
Queue Job
배치 통계
관리자 권한
광고 유입 데이터
- 특히 통계, 정산, 개인정보, 외부 API와 연결된 데이터는 검증 기준을 만들어야 합니다.
✅ 4. 정합성 검증 쿼리
- 정합성 문제는 SQL 쿼리로 주기적으로 확인할 수 있습니다.
- 처음에는 수동으로 실행하고, 나중에는 배치나 모니터링으로 자동화할 수 있습니다.
➕ 4-1. 완료 상태인데 completedAt이 없는 상담
SELECT id, status, "completedAt", "updatedAt"
FROM "Consult"
WHERE status = 'DONE'
AND "completedAt" IS NULL;
➕ 4-2. 완료 상태가 아닌데 completedAt이 있는 상담
SELECT id, status, "completedAt"
FROM "Consult"
WHERE status != 'DONE'
AND "completedAt" IS NOT NULL;
➕ 4-3. 상태 변경 이력이 없는 상담
SELECT c.id, c.status, c."createdAt"
FROM "Consult" c
LEFT JOIN "ConsultStatusHistory" h
ON h."consultId" = c.id
WHERE h.id IS NULL;
➕ 4-4. 현재 상태와 마지막 이력이 다른 상담
SELECT c.id, c.status, h."toStatus", h."createdAt"
FROM "Consult" c
JOIN LATERAL (
SELECT "toStatus", "createdAt"
FROM "ConsultStatusHistory"
WHERE "consultId" = c.id
ORDER BY "createdAt" DESC
LIMIT 1
) h ON true
WHERE c.status != h."toStatus";
- 이 쿼리는 현재 상태와 마지막 변경 이력이 맞는지 확인합니다.
- 상태 변경과 이력 저장이 트랜잭션으로 묶이지 않았을 때 이런 문제가 생길 수 있습니다.
✅ 5. 주문/결제 정합성 검증
- 주문과 결제는 금전과 연결되기 때문에 가장 엄격하게 봐야 합니다.
- 결제 성공인데 주문 상태가 결제 대기가거나, 주문 취소인데 결제 취소 이력이 없는 경우는 운영 사고로 이어질 수 있습니다.
➕ 5-1. 결제 완료인데 paidAt이 없는 주문
SELECT id, "paymentStatus", "paidAt", "createdAt"
FROM "Order"
WHERE "paymentStatus" = 'PAID'
AND "paidAt" IS NULL;
➕ 5-2. 취소 상태인데 취소 이력이 없는 주문
SELECT o.id, o.status
FROM "Order" o
LEFT JOIN "OrderStatusHistory" h
ON h."orderId" = o.id
AND h."toStatus" = 'CANCELLED'
WHERE o.status = 'CANCELLED'
AND h.id IS NULL;
➕ 5-3. 결제 이력은 성공인데 주문은 미결제 상태
SELECT o.id, o."paymentStatus", p.status AS "paymentLogStatus"
FROM "Order" o
JOIN "PaymentLog" p
ON p."orderId" = o.id
WHERE p.status = 'APPROVED'
AND o."paymentStatus" != 'PAID';
- 이런 데이터는 수동 확인 또는 보정 작업이 필요할 수 있습니다.
- 결제 관련 데이터는 자동 보정보다 먼저 원인 분석이 우선입니다.
✅ 6. Export 정합성 검증
- 엑셀 Export 기능은 DB, Queue, Worker, S3, Presigned URL이 연결됩니다.
- 상태와 실제 파일 존재 여부가 맞아야 합니다.
➕ 6-1. 완료 상태인데 fileKey가 없는 ExportJob
SELECT id, status, "fileKey", "createdAt"
FROM "ExportJob"
WHERE status = 'COMPLETED'
AND "fileKey" IS NULL;
➕ 6-2. 처리 중 상태가 너무 오래된 ExportJob
SELECT id, status, "createdAt", "startedAt"
FROM "ExportJob"
WHERE status = 'PROCESSING'
AND "startedAt" < NOW() - INTERVAL '30 minutes';
- Worker가 중간에 죽었거나, 대용량 파일 생성 중 실패했는데 상태 업데이트가 안 된 상황일 수 있습니다.
- 이런 Job은 관리자 화면에서 재처리하거나 FAILED로 변경하는 기준이 필요합니다.
✅ 7. Queue/Worker 정합성 검증
- Queue 작업은 Redis와 DB 상태가 함께 움직입니다.
- DB에는 처리 중인데 Queue에는 Job이 없거나, Queue에는 실패했는데 DB 상태가 PROCESSING이면 운영자가 혼란스러워집니다.
➕ 7-1. 오래된 PROCESSING 작업 찾기
SELECT id, status, "startedAt", "updatedAt"
FROM "ExportJob"
WHERE status = 'PROCESSING'
AND "updatedAt" < NOW() - INTERVAL '30 minutes';
➕ 7-2. 실패했지만 재처리 가능 표시가 없는 작업
SELECT id, status, "errorCode", "retryable"
FROM "JobFailureLog"
WHERE status = 'FAILED'
AND "errorCode" IN ('TIMEOUT', 'NETWORK_ERROR', 'PROVIDER_500')
AND "retryable" = false;
- 재처리 가능한 실패와 재처리 불가능한 실패를 기준화해두면 운영이 편해집니다.
✅ 8. 알림톡/SMS 정합성 검증
- 알림 발송은 고객 응대와 직결됩니다.
- 상담 신청은 저장됐지만 신청 완료 알림이 누락되면 운영자가 놓칠 수 있습니다.
➕ 8-1. 상담 신청은 있는데 신청 완료 알림 로그가 없는 경우
SELECT c.id, c.phone, c."createdAt"
FROM "Consult" c
LEFT JOIN "NotificationLog" n
ON n."relatedType" = 'CONSULT'
AND n."relatedId" = c.id
AND n."templateCode" = 'CONSULT_CREATED'
WHERE c."createdAt" >= NOW() - INTERVAL '1 day'
AND n.id IS NULL;
➕ 8-2. 실패한 알림 중 재시도 횟수 초과
SELECT id, "relatedType", "relatedId", status, attempts, "errorCode"
FROM "NotificationLog"
WHERE status = 'FAILED'
AND attempts >= 3
AND "createdAt" >= NOW() - INTERVAL '7 days';
- 실패 알림은 운영자 확인 메뉴나 재처리 기능과 연결하면 좋습니다.
✅ 9. 통계 정합성 검증
- 관리자 대시보드나 일일 리포트는 보통 원본 테이블을 매번 직접 조회하지 않고 Summary 테이블을 사용합니다.
- 이 경우 원본 데이터와 Summary 데이터가 일치하는지 검증해야 합니다.
➕ 9-1. 원본 상담 완료 수 확인
SELECT COUNT(*)
FROM "Consult"
WHERE status = 'DONE'
AND "completedAt" >= '2026-07-10 00:00:00'
AND "completedAt" < '2026-07-11 00:00:00';
➕ 9-2. Summary 테이블 완료 수 확인
SELECT SUM("doneCount")
FROM "DailyConsultSummary"
WHERE date = '2026-07-10';
- 두 결과가 다르면 집계 기준 날짜, 타임존, 상태 변경 시점, 배치 재실행 여부를 확인해야 합니다.
✅ 10. 타임존 정합성
- 통계와 리포트에서 가장 자주 틀어지는 부분이 날짜 기준입니다.
- DB는 UTC로 저장하고, 서비스 기준은 Asia/Seoul인 경우 날짜 범위를 잘못 잡으면 결과가 틀어집니다.
➕ 10-1. 문제 예시
한국 시간 2026-07-11 00:30 상담 신청
UTC 저장:
2026-07-10 15:30
한국 기준:
2026-07-11 데이터
UTC 기준:
2026-07-10 데이터
- 일별 통계는 “서비스 기준 날짜”가 무엇인지 명확해야 합니다.
- 한국 서비스라면 보통 Asia/Seoul 기준으로 집계합니다.
➕ 10-2. 실무 기준
DB 저장:
UTC 권장
집계 기준:
Asia/Seoul 기준 날짜 범위를 UTC로 변환해서 조회
관리자 화면:
Asia/Seoul로 표시
리포트 파일명:
서비스 기준 날짜 사용
✅ 11. 운영 리포트란 무엇인가?
- 운영 리포트는 서비스 상태와 업무 성과를 주기적으로 확인하기 위해 만든 요약 보고서입니다.
- 단순 통계가 아니라, 운영자가 의사결정할 수 있도록 중요한 지표와 이상 징후를 함께 보여주는 것이 좋습니다.
오늘 상담 신청 수
완료 수
취소 수
유입경로별 신청 수
상품별 신청 수
알림 발송 실패 수
Export 실패 수
Webhook 실패 수
배치 실패 여부
- 운영 리포트는 관리자 대시보드, Notion 문서, Slack 메시지, 이메일, 엑셀 파일 등으로 만들 수 있습니다.
✅ 12. 운영 리포트에 넣으면 좋은 지표
➕ 12-1. 상담/주문 지표
| 지표 | 의미 |
|---|
| 신규 상담 신청 수 | 오늘 들어온 상담 건수 |
| 상담 완료 수 | 처리 완료 건수 |
| 취소/무효 수 | 취소 또는 무효 처리 건수 |
| 미처리 건수 | 아직 PENDING/CALLING 상태인 건수 |
| 평균 처리 시간 | 신청부터 완료까지 걸린 시간 |
| 상품별 신청 수 | 어떤 상품에 관심이 많은지 |
| 유입경로별 신청 수 | 광고/검색/자연유입 성과 |
➕ 12-2. 운영 안정성 지표
| 지표 | 의미 |
|---|
| API 500 에러 수 | 서버 오류 |
| 외부 API 실패 수 | 알림톡/SMS/CRM 실패 |
| Webhook 실패 수 | 외부 결과 수신 처리 실패 |
| Queue failed Job 수 | 백그라운드 작업 실패 |
| 오래된 PROCESSING 수 | 멈춘 작업 가능성 |
| 배치 실패 여부 | 정기 작업 이상 |
| Export 실패 수 | 관리자 다운로드 장애 |
- 숫자만 나열하지 말고, 전날 대비 증가/감소나 위험 신호를 같이 보여주면 좋습니다.
✅ 13. 일일 운영 리포트 예시
## 일일 운영 리포트 - 2026-07-11
### 1. 상담 신청 현황
- 신규 신청: 128건
- 상담 완료: 94건
- 취소/무효: 8건
- 미처리 잔여: 26건
- 평균 처리 시간: 3시간 20분
### 2. 유입경로별 신청
- 네이버 광고: 52건
- 네이버 쇼핑: 31건
- 자연유입: 18건
- 당근: 12건
- 기타: 15건
### 3. 상품별 신청 TOP 5
1. iPhone 17 Pro
2. Galaxy S26
3. iPad Air
4. Galaxy Z Flip
5. 인터넷+TV 결합
### 4. 운영 이슈
- 알림톡 발송 실패: 3건
- Export 실패: 0건
- Webhook 실패: 1건
- Batch 실패: 없음
- API 500 에러: 2건
### 5. 확인 필요
- 알림톡 실패 3건 재처리 필요
- Webhook 실패 1건 원인 확인 필요
- 이런 리포트는 대표/운영자에게 공유하기 좋습니다.
- 개발자 입장에서는 “운영 자동화와 데이터 기반 보고 체계 구축”이라는 성과가 됩니다.
✅ 14. 리포트 생성 방식
➕ 14-1. 실시간 조회 방식
관리자 대시보드 접속
↓
원본 테이블에서 바로 집계
↓
결과 표시
- 데이터가 적을 때는 간단합니다.
- 데이터가 많아지면 느려질 수 있습니다.
➕ 14-2. Summary 테이블 방식
매일 배치 실행
↓
DailySummary 테이블에 집계 저장
↓
관리자 대시보드는 Summary 조회
- 조회가 빠르고 안정적입니다.
- 단, Summary와 원본 데이터 정합성을 검증해야 합니다.
➕ 14-3. 문서 자동 생성 방식
배치 작업
↓
통계 조회
↓
Markdown/HTML 생성
↓
Notion/Slack/Email 전송
- 운영 리포트를 자동으로 남길 수 있습니다.
- 사용자가 직접 대시보드에 들어가지 않아도 매일 현황을 받을 수 있습니다.
✅ 15. 이상 징후 감지
- 운영 리포트는 단순 보고서에서 끝나면 아쉽습니다.
- 전날 대비 급격한 변화나 실패 증가를 감지해 알려주면 훨씬 유용합니다.
➕ 15-1. 감지할 수 있는 이상 징후
상담 신청 수가 평소 대비 급감
특정 유입경로 신청 수가 0건
알림톡 실패 수 급증
API 500 에러 급증
Webhook 실패 반복
ExportJob PROCESSING 장기 지속
Queue waiting 수 급증
배치 작업 실패
➕ 15-2. 기준 예시
네이버 광고 유입 신청:
전날 대비 70% 이상 감소하면 확인 필요
알림톡 실패:
1시간 내 10건 이상이면 알림
ExportJob:
PROCESSING 30분 이상이면 알림
API 500:
10분 내 5건 이상이면 알림
- 처음부터 복잡한 AI 이상 탐지까지 갈 필요는 없습니다.
- 단순 기준 기반 알림만으로도 운영 안정성이 크게 올라갑니다.
✅ 16. 운영 모니터링 테이블 설계
- 운영 지표를 매번 원본에서 계산하지 않고 저장해두면 리포트와 알림에 활용하기 좋습니다.
➕ 16-1. DailyOperationMetric 모델 예시
model DailyOperationMetric {
id Int @id @default(autoincrement())
date DateTime @unique
consultCreatedCount Int @default(0)
consultDoneCount Int @default(0)
consultCancelledCount Int @default(0)
pendingCount Int @default(0)
notificationFailCount Int @default(0)
exportFailCount Int @default(0)
webhookFailCount Int @default(0)
apiErrorCount Int @default(0)
batchFailCount Int @default(0)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@index([date])
}
- 일별 운영 지표를 모아두면 대시보드와 리포트 생성이 쉬워집니다.
- 더 세부적인 유입경로별/상품별 통계는 별도 Summary 테이블로 나눌 수 있습니다.
✅ 17. 정합성 검증 결과 저장
- 정합성 검증도 실행 결과를 남기는 것이 좋습니다.
- 그래야 언제 어떤 문제가 발견됐고 해결됐는지 추적할 수 있습니다.
➕ 17-1. DataQualityCheck 모델 예시
model DataQualityCheck {
id Int @id @default(autoincrement())
checkName String
status String
targetTable String?
issueCount Int @default(0)
samplePayload Json?
checkedAt DateTime @default(now())
errorMessage String?
@@index([checkName, checkedAt])
@@index([status, checkedAt])
}
➕ 17-2. 상태값 예시
PASS:
문제 없음
WARN:
문제는 있으나 즉시 장애 수준은 아님
FAIL:
정합성 문제 발생, 확인 필요
ERROR:
검증 쿼리 자체 실행 실패
- 검증 쿼리 결과가 0건이면 PASS입니다.
- 문제가 있으면 issueCount와 sample 데이터를 저장해 운영자가 확인할 수 있게 합니다.
✅ 18. 자동 정정과 수동 정정 기준
- 정합성 문제가 발견됐다고 해서 무조건 자동으로 고치면 안 됩니다.
- 어떤 문제는 자동 정정이 가능하지만, 어떤 문제는 사람이 확인해야 합니다.
➕ 18-1. 자동 정정 가능성이 있는 경우
status=DONE인데 completedAt이 null
↓
마지막 DONE 이력 시간으로 completedAt 채움
ExportJob이 PROCESSING 24시간 이상
↓
FAILED로 변경 후 재처리 가능 표시
만료된 ExportJob
↓
EXPIRED 처리
➕ 18-2. 수동 확인이 필요한 경우
결제 성공 이력은 있는데 주문 상태가 미결제
주문 취소인데 환불 이력이 없음
상담 상태 이력 순서가 꼬임
Webhook 이벤트 순서가 충돌
개인정보 관련 데이터 이상
정산 금액 불일치
- 금전, 결제, 정산, 개인정보 관련 데이터는 자동 보정보다 원인 분석과 승인 절차가 먼저입니다.
✅ 19. 운영 리포트 자동화와 AI 활용
- 운영 리포트는 LLM을 활용하면 사람이 읽기 좋은 문장으로 자동 요약할 수 있습니다.
- 단, 숫자 계산과 원본 데이터 조회는 백엔드/DB가 정확히 처리해야 하고, AI는 요약과 설명에 활용하는 것이 좋습니다.
➕ 19-1. 권장 흐름
DB에서 지표 계산
↓
백엔드가 JSON 데이터 생성
↓
AI가 자연어 요약 생성
↓
Notion/Slack/Email에 기록
➕ 19-2. 좋은 활용 예시
오늘 상담 신청은 128건으로 전일 대비 12% 증가했습니다.
네이버 광고 유입이 전체의 40%를 차지했고,
알림톡 실패 3건과 Webhook 실패 1건은 재처리가 필요합니다.
➕ 19-3. 주의할 점
- AI가 숫자를 직접 계산하게 하지 않는 것이 좋습니다.
- 숫자는 DB 쿼리나 백엔드 코드에서 계산하고, AI에는 계산된 결과를 전달합니다.
- 개인정보를 AI 요청에 포함하지 않도록 주의해야 합니다.
- 고객 전화번호, 이름, 상담 메모 원문은 요약 대상에서 제외하거나 마스킹해야 합니다.
✅ 20. 관리자 대시보드 구성
- 정합성 검증과 운영 리포트는 관리자 대시보드로 연결하면 좋습니다.
➕ 20-1. 추천 대시보드 메뉴
오늘의 상담 현황
유입경로별 신청 현황
상품별 신청 현황
미처리 상담 목록
알림톡/SMS 실패 목록
Export 처리 현황
Webhook 실패 현황
Batch 실행 현황
데이터 정합성 검증 결과
➕ 20-2. 우선순위
1순위:
오늘 신청 수, 미처리 수, 상담 완료 수
2순위:
알림 실패, Export 실패, Webhook 실패
3순위:
유입경로별/상품별 통계
4순위:
정합성 검증 결과, 배치 이력
- 처음부터 복잡한 BI 대시보드를 만들 필요는 없습니다.
- 운영자가 매일 확인해야 하는 지표부터 간단히 보여주는 것이 중요합니다.
✅ 21. 실무 체크리스트
➕ 21-1. 데이터 정합성 체크리스트
- 상태값과 날짜 필드가 일치하는가?
- 현재 상태와 마지막 상태 이력이 일치하는가?
- 완료/취소 상태의 필수 날짜가 저장되어 있는가?
- 상태 변경 이력이 누락되지 않는가?
- ExportJob 상태와 fileKey가 일치하는가?
- 오래된 PROCESSING 작업이 방치되지 않는가?
- 알림 발송 로그가 누락되지 않는가?
- Summary 통계와 원본 데이터가 일치하는가?
➕ 21-2. 운영 리포트 체크리스트
- 오늘 신규 상담 수를 확인할 수 있는가?
- 미처리 상담 수를 확인할 수 있는가?
- 유입경로별 신청 수를 확인할 수 있는가?
- 상품별 신청 수를 확인할 수 있는가?
- 알림톡/SMS 실패 수를 확인할 수 있는가?
- Webhook/Export/Batch 실패를 확인할 수 있는가?
- 전날 대비 급증/급감 지표를 볼 수 있는가?
- 매일 자동으로 리포트가 생성되는가?
➕ 21-3. 모니터링 체크리스트
- API 500 에러 수를 추적하는가?
- Queue waiting/failed 수를 확인하는가?
- Worker 장애를 감지할 수 있는가?
- 배치 실패 시 알림을 받을 수 있는가?
- 외부 API 실패 급증을 감지하는가?
- 정합성 검증 결과가 저장되는가?
- 정합성 문제 발생 시 담당자가 확인할 수 있는가?
- 자동 정정과 수동 확인 기준이 구분되어 있는가?
✅ 22. AI를 활용해 데이터 정합성/리포트를 설계할 때 질문법
- AI에게 데이터 정합성을 물어볼 때는 테이블 구조, 상태값, 이력 테이블, 통계 테이블, 운영자가 확인해야 하는 지표를 함께 알려줘야 합니다.
- 단순히 “데이터 검증해줘”라고 하면 너무 일반적인 답변이 나올 수 있습니다.
➕ 22-1. 좋은 질문 예시
NestJS + Prisma + PostgreSQL 기반 온라인 휴대폰 판매몰 관리자 시스템에서 데이터 정합성 검증과 운영 리포트를 만들고 싶어.
상황:
1. Consult 테이블에는 status, createdAt, completedAt, cancelledAt이 있음
2. ConsultStatusHistory 테이블에는 fromStatus, toStatus, adminId, createdAt이 있음
3. ExportJob은 PENDING, PROCESSING, COMPLETED, FAILED, EXPIRED 상태를 가짐
4. NotificationLog에는 알림톡/SMS 발송 성공/실패 이력이 있음
5. DailyConsultSummary에는 일별 상담 통계가 저장됨
6. Queue Worker가 알림톡, Export, Webhook 후속 작업을 처리함
7. 매일 운영 리포트를 Notion 또는 Slack에 남기고 싶음
8. 개인정보는 리포트와 AI 요청에 포함하지 않아야 함
요청:
- 데이터 정합성 검증 항목
- 검증 SQL 예시
- DataQualityCheck 테이블 설계
- 일일 운영 리포트 지표
- Summary 테이블과 원본 데이터 비교 방법
- 이상 징후 감지 기준
- 자동 정정과 수동 확인 기준
- AI 요약 활용 시 주의점
을 실무 기준으로 정리해줘.
➕ 22-2. AI 답변 검증 기준
- 상태값과 날짜 필드 불일치를 검증하는가?
- 현재 상태와 마지막 상태 이력 불일치를 확인하는가?
- ExportJob, NotificationLog, Webhook, Batch 같은 운영 테이블도 포함하는가?
- Summary 통계와 원본 데이터 비교를 설명하는가?
- 타임존 기준을 언급하는가?
- 정합성 검증 결과 저장 테이블을 제안하는가?
- 자동 정정과 수동 확인 대상을 구분하는가?
- AI에게 개인정보를 넘기지 말고 계산된 지표만 요약하게 하라고 설명하는가?
📌 요약
- 데이터 정합성은 서비스 안의 데이터들이 서로 모순 없이 맞아떨어지는 상태를 의미합니다.
- 운영 서비스에서는 API가 정상 응답하더라도 상태값, 날짜 필드, 이력 테이블, Summary 통계, 외부 API 결과가 조용히 틀어질 수 있습니다.
- 상태값과
completedAt, cancelledAt 같은 날짜 필드가 서로 맞는지 정기적으로 검증해야 합니다.
- 현재 상태와 마지막 상태 변경 이력이 일치하는지 확인하면 상태 변경 트랜잭션 누락이나 수동 수정 문제를 찾을 수 있습니다.
- ExportJob, NotificationLog, WebhookEvent, BatchJobLog 같은 운영 테이블도 오래된 PROCESSING, 실패 누락, 재처리 대상 방치를 검증해야 합니다.
- 일별 통계 Summary는 원본 데이터와 비교하는 검증 쿼리가 필요하며, 타임존 기준을 명확히 해야 합니다.
- 운영 리포트에는 상담 신청 수, 완료 수, 미처리 수, 유입경로별/상품별 신청 수, 알림 실패, Export 실패, Webhook 실패, 배치 실패 같은 지표를 넣으면 좋습니다.
- 정합성 검증 결과는
DataQualityCheck 같은 테이블에 저장해 언제 어떤 문제가 발견됐는지 추적할 수 있게 만드는 것이 좋습니다.
- AI는 운영 리포트를 자연어로 요약하는 데 유용하지만, 숫자 계산은 DB/백엔드에서 하고 개인정보는 AI 요청에 포함하지 않는 것이 안전합니다.
