Temporal을 쓰기로 했다고 Service까지 직접 운영해야 하는 것은 아니다. 반대로 Cloud를 선택한다고 문서 처리 애플리케이션의 모든 운영 책임이 사라지는 것도 아니다. 이번 초안은 자체 운영과 Temporal Cloud를 기능 이름보다 책임과 비용 항목으로 비교한다. 최신 가격 숫자나 검증하지 않은 가용성 우열은 제시하지 않는다.
공통 업무는 허용량 예약, 가상 문서 변환, 결과 저장, 예약 확정이다. Worker가 이 코드를 실행하고 외부 예약·저장 시스템과 통신한다는 구조는 두 선택에서 모두 중요하다. 아래 비교는 아직 실제 운영비와 장애 대응 시간을 측정하지 않은 판단 틀이며 특정 선택을 확정하는 보고가 아니다.
Service를 맡긴다는 범위를 정한다
자체 운영에서는 Temporal Server 구성과 persistence, Visibility, 배포, schema 업그레이드, 백업·복구, 보안, 용량을 직접 관리해야 한다. 어떤 부분을 별도 관리형 DB에 맡기더라도 전체 실행 경로의 호환성과 복구 확인은 남는다.
Temporal Cloud는 관리형 Service를 사용하는 선택이다. 사용자는 계정과 Namespace, 연결 방식, 인증 정보, 접근 권한, 서비스 한도와 관측을 이해해야 한다. 어떤 보장과 기능이 제공되는지는 선택한 Cloud 구성과 공식 조건을 확인해야 한다. 관리형이라는 말만으로 필요한 복구 목표가 충족됐다고 가정하지 않는다.
Worker와 업무 코드는 별도다. Java Worker를 어디에서 실행할지, 어떤 버전으로 배포할지, 결과 저장 실패를 어떻게 처리할지, 외부 API의 중복 효과를 어떻게 막을지는 여전히 애플리케이션 설계의 문제다. Service 운영을 맡기는 결정과 코드 운영을 맡기는 결정을 혼동하지 않는다.
책임표는 빠진 일을 찾기 위해 쓴다
| 영역 | 자체 운영에서 확인할 책임 | Cloud 사용 시 남는 확인 |
|---|---|---|
| Service·저장소 | 배포, 용량, 패치, schema, 복구 | 제공 범위, 한도, 관측, 지원 경로 |
| Worker | 실행 환경, 확장, 배포, 종료 | 실행 환경, 확장, 배포, 종료 |
| 업무 정확성 | 멱등성, 보상, 동시성, 외부 결과 | 멱등성, 보상, 동시성, 외부 결과 |
| 접근 통제 | 네트워크, TLS, 인증·인가 구성 | 계정·Namespace 권한, 자격 관리, 연결 |
| 장애 대응 | Service부터 업무까지 진단·복구 | 공급자 상태와 Worker·업무 진단 연결 |
이 표는 계약상의 완전한 책임 분담표가 아니다. 실제 제품 구성과 조직에 맞춰 확인할 항목을 정리한 것이다. 운영자가 “이 일은 누가 하기로 했는가”에 답하지 못하는 칸이 있다면 기능 비교보다 먼저 정해야 한다.
개인 학습 목적도 따로 고려할 수 있다. Server와 DB의 관계를 이해하려고 자체 운영 실험을 하는 것은 가치가 있다. 그러나 학습용 설치를 완료했다는 사실을 production 운영 준비가 끝났다는 근거로 사용하지 않는다. 배우는 선택과 실제 업무를 맡기는 선택의 성공 조건은 다를 수 있다.
비용은 청구서 외에도 존재한다
자체 운영의 비용에는 Server와 DB, 검색 저장소, 백업, 관측 도구, 네트워크, 복구 시험 환경이 들어간다. 이를 유지하는 작업 시간과 장애 대응, 패치와 업그레이드의 반복 비용도 고려해야 한다. 작은 개발 환경의 VM 요금만으로 전체 운영비를 계산하면 빠지는 항목이 많다.
Cloud 쪽에서는 공식 가격 체계의 과금 단위, 저장과 보존, 용량 모드, 지원 조건, 네트워크 비용 등을 선택 시점에 확인한다. SDK 지표의 Activity 횟수와 실제 과금 항목을 같은 것으로 간주하지 않는다. Workflows가 같은 수라도 이벤트와 재시도, payload, 보존 조건이 다르면 비용 양상이 달라질 수 있다.
Worker 실행 비용과 외부 문서 저장 비용은 양쪽 모두에서 남을 수 있다. Service 요금만 비교하고 이 공통 비용을 한쪽에만 더하면 비교가 왜곡된다. 공통 비용과 선택에 따라 달라지는 비용을 나누고, 아직 모르는 항목은 추정 근거와 함께 표시한다.
연결 실패는 어디에서 해결할까
대표 실패는 Cloud 연결이 정상이고 Service 상태도 정상인데 결과 저장이 계속 실패하는 경우다. 가상 Worker가 외부 저장소에 쓸 권한을 잃었다면 Service를 관리형으로 바꾼 사실은 이 오류를 해결하지 않는다. Activity 재시도만 반복될 수 있으므로 외부 원인과 업무 상태를 직접 확인해야 한다.
자체 운영에서도 비슷한 구분이 필요하다. DB 지연 때문에 실행 관리가 느린 것과 결과 저장소 때문에 Activity가 느린 것은 다르다. Service 지표, SDK 지표, 외부 API 지표를 함께 수집했던 이유다. Cloud를 선택하면 공급자가 제공하는 관측과 자신의 Worker 관측을 연결하는 방법을 검토한다.
실험은 같은 생성 문서 Worker를 두 환경에 연결하되 한 번에 하나씩 사용하도록 설계할 수 있다. 연결 자격과 Namespace를 분리하고 외부 저장 실패를 같은 조건으로 주입한다. 예상하는 학습 결과는 Service 운영 경로가 달라져도 애플리케이션 실패를 진단하는 책임이 남는다는 것이다. 실제 지연과 비용 차이는 측정 전 단정하지 않는다.
배치 제약과 복구 목표도 판단에 넣는다
외부 연결이 제한된 환경, 데이터 위치 요구, 인증 체계, 네트워크 경로는 선택을 제한할 수 있다. 요구가 있다는 사실과 제품이 지원한다는 사실을 별도로 검증한다. Cloud의 연결 옵션이나 지역을 기억에 의존해 적지 말고 선택 시점의 공식 문서를 확인한다.
자체 운영에서는 “우리가 복구할 수 있다”를 시험 기록으로 보여야 한다. Cloud에서도 제공되는 복구 목표가 업무에 충분한지, Worker와 외부 예약 시스템의 복구는 어떻게 연결할지 검토한다. 종료 History를 오래 보존하는 설정은 이 판단을 대신하지 않는다.
최종 결정은 운영 책임을 감당할 수 있는 사람과 절차, 실제 workload의 비용, 필요한 기능과 제약을 묶어 내린다. 아직 시험하지 않았다면 “자체 운영은 싸다”나 “Cloud면 안전하다”처럼 단정하지 않는다. 대신 무엇을 확인하면 결정을 내릴 수 있는지와 재검토 조건을 적는다.
검증 질문은 “Cloud로 바꾸면 없어지는 운영 작업과 그대로 남는 업무 책임은 무엇일까?”다. 또 “자체 운영 비용에서 복구 시험과 업그레이드 시간을 빼면 어떤 판단이 왜곡될까?”를 생각해 보자. 도구 사용과 운영 책임을 함께 설명할 수 있을 때 선택이 구체적이 된다.