분산 시스템에서 가장 성가신 문제는 로직 자체보다 실패를 다루는 방식에서 드러나는 경우가 많습니다. 네트워크가 잠깐 끊기고, 외부 API가 늦게 응답하고, 사람 승인처럼 며칠 뒤에 이어지는 작업이 끼어드는 순간 코드와 운영의 경계가 흐려집니다. Temporal은 바로 그 지점을 겨냥합니다. 이 저장소를 볼 만한 이유도 화려한 추상화보다, 실패를 기본값으로 두고 애플리케이션 실행을 다시 설계한다는 점에 있습니다.
해당 Repository의 접속 URL 및 version. Commit 빈도수에 따른 업데이트 수준. 접속 URL은 https://github.com/temporalio/temporal 입니다. 이번 조사 시점 기준 최신 릴리스는 v1.30.3이고 기본 브랜치 HEAD는 0b372d5ea306041271710c3054481c657bf218ba 입니다. 최근 30일에 100건 이상, 최근 7일에도 36건의 커밋이 관측되어 업데이트 수준은 매우 활발한 편으로 읽힙니다.
무엇을 하는 저장소인가 이 저장소는 Temporal 서버 자체를 담고 있습니다. 개발자는 SDK 쪽에서 Workflow와 Activity를 작성하고, 이 서버는 그 실행 이력을 durable하게 관리하면서 재시도와 복구를 책임집니다. 흔히 메시지 큐, 크론, 상태 머신, 수동 보상 로직으로 흩어지던 장기 실행 업무를 하나의 실행 모델로 모으는 데 초점이 있습니다.
핵심 특징 - Workflow 실행 이력을 기반으로 상태를 재구성하는 방식이라 프로세스가 중단되거나 노드가 교체되어도 흐름을 이어가기 쉽습니다. - 재시도, 백오프, 타임아웃, 스케줄, 시그널 같은 장기 실행 제어 요소가 플랫폼 개념으로 올라와 있어 별도 배치나 보상 스크립트가 줄어듭니다. - README에서 바로 이어지는 docs/architecture, 개발 문서, 샘플 저장소 흐름이 명확해서 서버 아키텍처와 운영 모델을 분리해 학습하기 좋습니다.
실무에서 기대할 수 있는 효과 - 주문, 결제, 정산, 배송처럼 여러 외부 시스템을 거치는 업무를 실패 복구까지 포함해 한 흐름으로 관리할 수 있습니다. - 사람 승인이나 며칠짜리 대기 구간이 있는 업무를 무리하게 배치 작업으로 쪼개지 않아도 됩니다. - 장애 대응 시 어떤 단계에서 멈췄는지 추적하기 쉬워지고, 재처리 전략을 코드와 운영 양쪽에서 일관되게 가져갈 수 있습니다.
실제로 볼 만한 예시 대표적인 장면은 전자상거래 주문 파이프라인입니다. 결제 승인, 재고 예약, 배송 요청, 실패 시 보상 트랜잭션까지 이어지는 흐름을 Workflow로 두면, 중간 API 실패가 나더라도 어느 단계에서 다시 시작해야 하는지 명확해집니다.
또 다른 예시는 문서 심사나 계정 개설처럼 사람 승인이 끼는 업무입니다. 일반적인 웹 애플리케이션에서는 상태 테이블과 배치 재개 로직이 금방 복잡해지는데, Temporal은 장기 대기와 재개를 기본 모델 안에서 다루려는 방향이 분명합니다.