이벤트 필드 하나 바꿨는데 구독자가 멈췄다면
이벤트에 필드를 하나 추가하거나 이름을 바꾸면 생산 서비스는 정상인데 구독 서비스가 멈출 수 있습니다. 이벤트는 보낸 뒤 여러 시스템이 각자의 속도로 읽는 계약입니다. 생산자만 보고 스키마를 바꾸지 않으려면 호환성과 전환 기간을 설계해야 합니다.
NOTES
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 288
이벤트에 필드를 하나 추가하거나 이름을 바꾸면 생산 서비스는 정상인데 구독 서비스가 멈출 수 있습니다. 이벤트는 보낸 뒤 여러 시스템이 각자의 속도로 읽는 계약입니다. 생산자만 보고 스키마를 바꾸지 않으려면 호환성과 전환 기간을 설계해야 합니다.
주문을 저장한 뒤 메시지 브로커에 '주문 생성' 이벤트를 보내는 서비스가 있습니다. DB 저장은 성공하고 메시지 전송만 실패하면 다른 시스템은 주문을 모릅니다. 두 저장소를 한 번에 완벽히 쓰기 어렵다면 이벤트를 DB 트랜잭션 안에 함께 남기는 아웃박스 패턴을 검토할
최적화 모델이 답을 내지 못할 때 현장은 납기를 맞추기 위해 어떤 제약을 풀어야 할지 묻습니다. 그러나 안전 조건과 고객 약속을 임의로 완화하면 더 큰 문제가 생길 수 있습니다. 제약의 우선순위와 승인 책임을 미리 정해야 합니다.
전체 매출 예측과 상품별 예측을 각각 만들면 두 숫자가 서로 맞지 않을 수 있습니다. 모든 상품의 예측을 더했는데 회사 전체 예측과 다르면 발주와 예산 계획이 서로 다른 기준을 쓰게 됩니다. 계층별 예측을 일관되게 맞추는 절차가 필요합니다.
평균 판매량은 비슷한데 어떤 상품만 자주 품절됩니다. 수요의 차이보다 공급 납기가 들쭉날쭉하기 때문일 수 있습니다. 재고 의사결정은 얼마나 팔리는지와 주문한 물건이 언제 도착하는지를 함께 봐야 합니다.
평균 수요와 평균 이동시간으로 만든 계획은 계산상 깔끔하지만 변동이 있는 날에는 쉽게 무너집니다. 그렇다고 최악의 경우만 대비하면 자원이 지나치게 남을 수 있습니다. 어떤 불확실성을 계획에 반영할지 정하는 것이 강건한 최적화의 시작입니다.
생산계획은 새 주문이나 설비 문제를 반영해야 하지만 너무 자주 바꾸면 현장은 따라갈 수 없습니다. 준비 중인 자재와 이미 배치된 인력이 있기 때문입니다. 가까운 일정은 동결하고 먼 일정은 유연하게 조정하는 구간 설계가 필요합니다.
인건비만 최소화한 근무표가 특정 직원에게 야간 근무를 몰아준다면 오래 유지하기 어렵습니다. 법적·계약상 필수 조건을 지키는 것과 팀이 공정하다고 느끼는 것은 다른 문제입니다. 공정성을 측정 가능한 제약과 목표로 표현해야 합니다.
창고에서 비슷한 주문을 묶어 한 번에 피킹하면 동선은 짧아질 수 있습니다. 그러나 여러 카트가 같은 좁은 통로로 몰리면 대기 시간이 늘고 주문 분류 작업도 복잡해집니다. 피킹 배치 크기는 이동거리만으로 정할 수 없습니다.