Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

📌 OverEngineering Index (OEI) 공식:

📊 변수 정의:

변수설명
C (Complexity Level)설계 복잡도 (1~10, 시스템 구조, 메시징, DB샤딩, CQRS 등 도입 요소 수 기준)
T (Time Pressure)개발 완료까지 남은 시간에 대한 압박 수준 (1~10, 작을수록 급박)
L (Learning Load)팀 전체의 학습 곡선 부담 (도입 기술에 익숙하지 않을수록 높음, 1~10)
D (Dev Resource)가용 개발자 수 × 숙련도 (팀 역량 지수, 예: 숙련된 3명 → 3×0.9 = 2.7)
P (Project Priority)프로젝트의 긴급성과 ROI 우선도 (1~10, 높을수록 정당한 투자)


주어진 시간은 1주일이내 우리는 다음과 같은 방법을 사용하기로 했습니다.

...

위 와같은 장치를 채택 한다고 해도~ 메시지 전송수준을 어디까지 높일것인가? 도 비용으로 바라볼수 있습니다.

💡 선택 기준 요약표

전송 수준

중복

손실

처리 비용

사용 예시

At Most Once

💲 (낮음)

로그, 알림

At Least Once

💲💲 (중간)

주문, 결제

Exactly Once

💲💲💲 (높음)

금융, 정산

...

🔍 인프라 비용 고려 팁

  • 로그나 비동기 알림 At Most Once로 충분 → 비용 절감

  • 결제, 주문처리 At Least Once + 중복제거 로직 추가로 타협 가능

  • 회계, 정산 Exactly Once 필수지만, 서비스 경계를 좁히면 필요한 범위를 최소화할 수 있음


여기까지가 팀원에게 코칭한 내용이며, 여기서 더 업그레이드해 메시지 전송 수준(Message Delivery Semantics) 까지 고려한 팀원이 해결하고 작성한  테크를 소개합니다.

...

깨알광고 

Image Added

  • https://hey-there.io/
    • 이 기술은 최근오픈한 온사이트 마케팅툴인 헤이데어의 일부로 포함되어있습니다.