AA 핵심 설계 프레임 요약 (판정용)

AA 핵심 설계 프레임 요약 (판정용)

AA 프레임 = 구조를 만드는 도구가 아니라
시스템의 “결정”을 고정하는 체크리스트

---

1️⃣ 상태 중심 vs 이벤트 중심 (최상위 세계관 결정)

가장 먼저, 반드시 하나를 주인공으로 선택

상태 중심

• 현재 값이 진실
• CRUD + 강한 트랜잭션
• 조회 단순 / 구현 쉬움
• 이력·재처리·감사에 약함

이벤트 중심

• 발생한 사건이 진실
• 모든 변경은 이벤트
• 이력·재처리·감사 강함
• 설계·운영 난이도 높음

AA 판정

• ❌ 둘 다 핵심으로 섞지 않는다
• ⭕ 혼합 가능하나 주인공은 하나

---

2️⃣ 트랜잭션 경계 프레임

“어디까지가 하나의 실패 단위인가?”

강결합 트랜잭션

• 요청 = 트랜잭션
• 전부 성공 / 전부 실패
• 단순하지만 확장성 낮음

분리 트랜잭션 + 보상

• 단계별 커밋
• 실패 시 보상 처리
• 대규모 시스템 필수

AA 산출물

• 주문/출고/정산의 원자성 범위
• 실패 시 상태 정의(실패, 보류, 재시도)

---

3️⃣ 진실의 원본 (Source of Truth)

“이 데이터의 최종 책임자는 누구인가?”

• 재고의 진실은 어디?
• 매출의 진실은 어디?
• 고객 정보의 기준은 무엇?

AA는 반드시 명시

• 읽기 허용 위치
• 쓰기 독점 위치
• 수정 방식(직접 수정 ❌ / 이벤트 ⭕)

👉 없으면 중복 계산·이중 반영 지옥

---

4️⃣ 동기 / 비동기 경계

“지금 실패해야 하나, 나중에 처리해도 되나?”

동기

• 사용자 즉시 체감
• 실패 = 즉시 실패

비동기

• 결국 처리되면 됨
• 메시지/큐 기반
• 재시도 허용

AA 결정 예

• 결제 승인까지만 동기
• 정산/리포트는 비동기
• 재고 반영은 이벤트 소비자 책임

---

5️⃣ 책임 분리 (BFF / Core / Batch)

구조이자 운영 프레임

• BFF: 화면·조합·인증
• Core: 비즈니스 규칙의 진실
• Batch: 느리지만 무거운 계산

AA 질문

• 이 로직은 “즉각 반응”인가?
• 아니면 “일관성 유지”인가?

👉 이 판단 없으면
BFF에 비즈니스가 쌓이고
Batch에 API가 생긴다.

---

6️⃣ 변경 허용 범위

운영 사고를 막는 핵심 프레임

질문:

• 이미 확정된 걸 다시 고칠 수 있는가?

AA 원칙

• 직접 수정 ❌
• 취소/보정 이벤트 ⭕
• 히스토리 보존 ⭕
• 덮어쓰기 ❌

👉 이 선이 없으면
운영팀이 DB를 직접 만진다.

---

7️⃣ 확장 방향 (미래 잠금)

“언젠가”를 설계 언어로 번역

• 멀티 테넌시?
• 국가/통화?
• 외부 연동?

AA 방식

• 지금 구현 ❌
• 구조적으로 막지 않음 ⭕
• 키 구조 / 코드 체계 / 이벤트 스키마 선확정

---

한 줄로 압축하면

AA 설계 프레임은
“구현 방법”이 아니라
“되돌릴 수 없는 결정을 미리 고정하는 장치”다.

이 프레임들이 문서로 남아 있으면:

• 개발자 10명 바뀌어도 구조 유지
• 일정이 밀려도 방향 유지
• 기능이 늘어도 시스템이 버틴다