Beyond Happy Path Engineering

코드에서 네트워크 호출은 한 줄이지만, 실제로는 독립적으로 실패하는 두 시스템 사이의 경계다. 요청이 느릴 수 있고, 응답이 사라질 수 있으며, 응답은 없어도 원격 작업은 완료될 수 있다. 이 경계를 성공과 실패 두 값으로만 다루면 운영 장애가 주문 중복, 대기열 증가, 재시도 폭주로 확산된다. 3줄 핵심 정리 timeout은 대기 예산이다: 호출자가 더 기다리지 않겠다는 뜻이지, 원격 시스템이 작업을 취소했다는 뜻은 아니다. 재시도에는 요청의 정체성이 필요하다: 결제·주문처럼 부작용이 있는 작업은 idempotency key로 중복 실행을 안전하게 처리해야 한다. 실패를 상태와 운영 신호로 만든다: pending·unknown 같은 상태, bounded retry, circuit breaker, load shedding, tail latency 지표가 필요하다. 원문: Beyond Happy Path Engineering: the Network ...

시간은 프로그램에서 가장 익숙한 의존성처럼 보인다. now()를 호출하고 두 시각을 비교하면 예약이 만료됐는지, 세션이 유효한지, 재시도할 때가 됐는지를 알 수 있다고 생각하기 쉽다. 그러나 운영 환경에서는 머신의 시계가 서로 다르고, 시스템 시각이 보정으로 앞뒤로 움직이며, 스케줄러가 늦거나 중복 실행된다. 시간은 단순한 값이 아니라 설계해야 할 경계다. 3줄 핵심 정리 시간의 종류를 나눠야 한다: 경과 시간은 monotonic clock, 사건 기록은 wall-clock, 경쟁 순서는 버전·시퀀스, 사용자 업무 규칙은 시간대와 달력으로 다룬다. 만료 시각은 판결문이 아니다: clock skew와 늦은 worker 때문에 timestamp 비교만으로 예약·세션의 상태를 바꾸면 경쟁 조건이 발생한다. 경계 조건을 명시한다: 늦은 작업, 중복 실행, 자정·서머타임·월말 같은 상황을 테스트하고 재조정·관찰 가능성까지 설계한다. 원문: Beyond Happy Path Engineering: Time ...