Software-Architecture

유한 상태 머신(FSM, Finite State Machine)은 시스템이 가질 수 있는 상태와 그 사이 전이를 명확히 정의하는 모델 복잡한 비즈니스 로직을 단순화하고 예측 가능하게 만들어 결제나 주문처럼 순서와 무결성이 중요한 도메인에 적합 개념/배경 상태와 규칙을 명시적으로 모델링해 허용되지 않은 동작을 구조적으로 차단하는 접근 요구사항이 늘어도 상태 전이 규칙을 중심으로 변경 범위를 제한해 안정성 확보에 유리 핵심 개념 상태 State 시스템이 존재할 수 있는 유한한 조건 집합 예 로그인 전, 로그인 후, 결제 대기, 결제 완료 이벤트 또는 입력 Event/Input 상태 변화를 유발하는 외부 행위나 신호 예 버튼 클릭, 네트워크 끊김, 시간 초과 전이 또는 규칙 Transition/Rule 어떤 상태에서 어떤 이벤트가 발생하면 다음 상태로 이동한다는 정의 규칙에 없는 전이는 거부 또는 무시 동작 원리 현재 상태와 입력을 받아 다음 상태를 결정하는 전이 함수 관점으로 해석 가능 f(state, event) -> nextState 형태 전이에는 가드 조건과 부수효과가 수반될 수 있음 가드는 전이 허용 여부 판단, 부수효과는 알림 전송이나 로그 기록 등 외부 행동을 명시적으로 수행 정의되지 않은 전이를 막아 비정상 흐름 차단 재진입이나 중복 이벤트 처리 시에도 일관된 행동을 보장 예시 자판기 모델 상태 대기 중, 이벤트 동전 투입 -> 다음 상태 금액 충족 돈이 들어와야만 다음 상태로 이동 상태 금액 충족, 이벤트 상품 버튼 누름 -> 다음 상태 상품 배출 중 상품 선택 가능 상태 상품 배출 중, 이벤트 배출 완료 -> 다음 상태 대기 중 초기 상태로 복귀 상태 대기 중, 이벤트 상품 버튼 누름 -> 상태 변화 없음 금액 미충족 시 입력 무시 장점과 효과 정합성 보장 정의된 전이 외 동작 불가하므로 데이터 꼬임 예방 결제가 완료 상태에서 결제 요청 이벤트가 다시 들어오면 규칙에 없는 전이로 처리되어 거부 또는 무시되어 중복 결제 차단에 기여 멱등 처리 전략과 결합 시 효과적 예측 가능성 향상 몇 개의 상태와 전이 규칙으로 복잡도를 축소해 로직 이해와 디버깅 용이 테스트 용이성 상태 x 이벤트 조합별로 기대 결과가 명확해 단위 테스트 케이스 설계가 단순 주의와 베스트 프랙티스 상태 폭발 주의 의미 있는 상태만 유지하고 파생 속성은 별도 데이터로 관리 전이 정의의 단일 소스 유지 가드와 부수효과를 전이 정의 근처에 모아 산재된 분기 로직을 제거 잘못된 전이 로깅과 모니터링 활성화 무시된 입력을 계측해 모델 누락이나 외부 시스템 이상 조기 탐지 멱등성 고려 중복 이벤트 재수신 가능 환경에서는 전이와 부수효과를 멱등하게 설계 분산 환경에서는 상태 영속화와 재시도 정책을 명시 크래시 후 재기동 시 일관성 있는 상태 복원 필요 마무리 FSM은 상태와 전이를 중심으로 시스템 동작을 제한하고 드러내며, 규칙 밖 동작을 원천 차단해 안정성을 끌어올림 결제나 주문 같은 순서 기반 도메인에 특히 유용하며, 상태 정의와 전이 규칙만 명확히 유지하면 변경에도 견고하게 대응 가능 ...

개념/배경 Single Source of Truth(SSOT)는 소프트웨어와 데이터 관리에서 중요한 데이터는 권위 있는 하나의 출처만을 가진다는 원칙을 뜻함 핵심은 원본은 한 곳에만 두고 나머지는 그 원본을 참조하거나 파생해 사용함 원본이 분산되면 동기화 비용과 불일치 위험이 기하급수적으로 증가함 왜 필요한가 데이터 불일치 발생 위험 증가 위치 A의 유저 나이가 20인데 위치 B에서는 21로 표시되는 상황 유지보수 비용 급증 수정 시 흩어진 모든 복제본을 찾아 변경해야 함 일부 누락 시 버그와 장애로 연결됨 변경 전파가 느림 캐시나 로컬 복제본 만료 정책이 미흡할 때 최신성이 깨짐 실생활 비유 주민등록과 같은 신원 시스템의 원본 데이터는 정부의 공식 저장소에 존재 은행이나 병원은 이를 조회해 사용할 뿐 별도의 원본을 만들지 않음 스마트폰 연락처가 전화번호의 원본 역할을 수행 연락처에서 번호를 바꾸면 메신저나 문자 앱도 최신 번호를 참조해 표시함 개발 적용 예시 프론트엔드 상태 관리 Bad 부모 컴포넌트에 userData 보유, 자식 컴포넌트가 이를 복사해 별도 상태로 관리 부모 변경이 자식에 반영되지 않을 수 있음 SSOT 상위 컴포넌트 또는 중앙 스토어에만 userData 보관 자식은 props나 selector로 읽기 전용 접근 데이터베이스 모델링 Bad 주문 테이블에 고객 주소를 중복 저장하고 회원 테이블에도 주소 저장 SSOT 회원 테이블에만 주소 저장 주문 테이블은 회원 ID를 참조해 조인으로 조회 타입 정의 공유(TypeScript) Bad 동일한 API 응답 타입을 페이지 A와 B 각각에서 중복 정의 SSOT types/user.ts에 단일 타입 정의 위치 확보 후 모든 모듈에서 import하여 사용 베스트 프랙티스와 주의 쓰기 경로 단일화 원본에 대한 쓰기는 반드시 한 경로로만 수행 읽기 복제본과 캐시 관리 캐시는 파생물로 취급 만료 정책, 동기화 주기, 재검증 전략을 명시 식별자 기반 참조 우선 파생 데이터에는 식별자만 저장하고 필요 시 조인 또는 조회로 해석 양방향 복제와 수동 동기화 지양 충돌 해결 복잡도와 데이터 드리프트 위험 상승 마이그레이션 단계 관리 이중 쓰기 기간 최소화, 피처 플래그와 데이터 백필 계획 수립, 점진적 전환 적용 요약 원본은 하나만 관리하고 나머지는 참조한다는 단순한 원칙이 SSOT의 전부 이를 지키면 데이터 신뢰성 확보와 변경 비용 축소에 직접적인 효과가 있음 프론트엔드 상태, DB 스키마, 타입 정의까지 동일한 기준으로 일관 적용 권장 ...