정합성은 선택이 아니다. 언젠가 비용으로 돌아온다

1️⃣ 정합성은 “지금 비용 vs 나중에 폭탄”의 문제

• 지금
  • 트랜잭션 범위 명확히 정의
  • 동시성 제어(락, 버전)
  • 실패 케이스 설계
• 나중
  • 데이터 복구 스크립트
  • CS/민원 대응
  • 운영자 수동 보정
  • “왜 이 값이 이렇게 됐는지” 추적 불가

👉 지금 안 쓰는 비용은 운영·신뢰·평판 비용으로 이자 붙어 돌아옵니다.

---

2️⃣ “성능 때문에 정합성 포기”는 대부분 핑계

실제 현장 패턴:

• QPS 낮음
• 트래픽 피크 예측 가능
• 병목은 DB가 아니라 외부 API / 비즈니스 로직

그런데도:

• @Transactional 안 씀
• optimistic lock 없음
• 멱등성 없음

이건 성능 문제가 아니라 설계 회피입니다.

---

3️⃣ 정합성 포기해도 되는 유일한 경우

명확한 조건이 있습니다.

조건설명

보정 가능	재집계 / 재처리 가능
사용자 영향 미미	통계·로그·추천
중복 허용	exactly-once 포기 선언
SLA 명시	“실시간 아님”을 문서로 합의

이 4개 중 하나라도 없으면 정합성 포기하면 안 됩니다.

---

4️⃣ SI·공공에서 정합성은 “법적 리스크”

• 금액
• 자격
• 신청 상태
• 승인 이력

여기서 깨지면:

• 감사
• 재처리
• 소급
• 담당자 책임

👉 이건 기술 문제가 아니라 리스크 관리입니다.

---

5️⃣ 좋은 설계의 기준 문장

“이 데이터가 틀리면, 누가 고통받는가?”

• 사용자면 ❌
• 운영자면 ❌
• 나중의 나면 ❌❌

그럼 처음부터 정합성 잡는 게 최저 비용입니다.

---

한 줄로 정리하면
정합성은 기술 선택이 아니라 ‘책임을 지금 질지, 나중에 질지’의 문제입니다.