결제 승인과 재고 차감은 끝났습니다. 그런데 배송 주문을 생성하기 직전, 함수 인스턴스가 충돌해 종료됩니다. 고객에게는 결제 완료 알림이 떴지만 판매 시스템에는 배송할 주문이 없습니다. 재고는 이미 줄었고, 함수는 재시도될 수도 있습니다.
이때 남는 질문은 단순하지 않습니다.
이미 외부 시스템에 반영된 결제와 재고 변경은 누가, 어떻게 책임질까요?
Serverless는 서버 프로비저닝, 자동 확장, 런타임 운영을 대신 처리해 줍니다. 개발자는 인프라를 관리하지 않고 이벤트가 발생할 때마다 함수를 실행할 수 있습니다. 하지만 함수가 실행 도중 실패했을 때, 결제 API·데이터베이스·메시지 큐처럼 함수 바깥에 남은 결과까지 자동으로 되돌려 주지는 않습니다.
예를 들어 주문 처리 함수가 다음 순서로 실행된다고 가정해 보겠습니다.
1. 결제 승인 요청
2. 재고 차감
3. 배송 주문 생성
4. 주문 완료 메시지 발행
3단계에서 함수가 종료되면 상태는 이렇게 어긋날 수 있습니다.
| 시스템 | 남은 상태 |
|---|---|
| 결제 시스템 | 승인 완료 |
| 재고 시스템 | 재고 차감 완료 |
| 배송 시스템 | 주문 없음 |
| 고객 화면 | 결제 성공 또는 처리 중 |
| Serverless 함수 | 실행 실패, 재시도 가능 |
가장 위험한 부분은 재시도입니다. Serverless 플랫폼은 장애 복구를 위해 동일한 함수를 다시 실행할 수 있습니다. 그러나 이전 실행에서 결제가 성공했는지, 재고가 이미 차감됐는지, 배송 주문이 어디까지 생성됐는지를 함수가 알지 못하면 중복 결제·중복 차감·중복 주문이 발생할 수 있습니다.
그래서 기존에는 개발자가 직접 복잡한 방어 로직을 구현해야 했습니다.
- 결제 중복을 막기 위한 idempotency key
- 단계별 처리 상태를 기록하는 데이터베이스
- 실패 시 결제를 취소하고 재고를 복구하는 보상 트랜잭션
- 보상 요청 실패를 다시 처리하는 재시도 큐
- 이미 실행된 메시지 발행을 추적하는 운영 도구
문제는 정상적인 주문 흐름보다 실패한 중간 상태를 처리하는 코드가 더 어려워진다는 점입니다. 결제는 취소할 수 있어도 이미 발송된 이메일은 회수할 수 없고, 재고 복구 요청도 네트워크 오류로 실패할 수 있습니다. 함수 하나는 짧고 단순해 보여도, 여러 외부 시스템과 연결되는 순간 분산 시스템의 실패 문제가 그대로 들어옵니다.
AtomicFaaS가 주목받는 이유도 여기에 있습니다. 이 접근은 함수 내부의 성공·실패만 보는 대신, 함수가 외부에 남긴 효과를 플랫폼이 기록하고 실패 시 보상하는 방향을 제안합니다. 즉, Serverless가 서버 관리뿐 아니라 실패 뒤에 남은 흔적을 정리하는 책임까지 맡을 수 있는지를 묻는 기술입니다.
Saga의 짐을 플랫폼으로 옮기는 Serverless
여러 외부 시스템을 호출하는 함수를 만들 때 가장 어려운 부분은 정상 실행이 아닙니다. 중간에 실패했을 때 이미 발생한 작업을 어떻게 되돌릴 것인가가 진짜 문제입니다.
예를 들어 주문 처리 함수가 결제 승인, 재고 차감, 배송 요청을 순서대로 실행한다고 가정해 보겠습니다. 배송 요청 직전에 함수가 중단되면 결제와 재고 변경은 이미 외부 시스템에 남아 있을 수 있습니다. 개발자는 이를 해결하기 위해 각 단계마다 취소·환불·재고 복구 같은 보상 로직을 직접 작성해야 합니다.
바로 이 지점에서 Saga 패턴이 사용됩니다. 하지만 수동 Saga는 코드와 운영 부담을 함께 키웁니다.
- 각 작업에 대응하는 보상 함수를 구현해야 합니다.
- 실패한 정확한 지점을 저장해야 합니다.
- 재시도 과정에서 중복 결제나 중복 메시지 발행을 막아야 합니다.
- 보상 작업이 다시 실패하는 경우도 처리해야 합니다.
- 개발자가 보상 단계를 누락하거나 순서를 잘못 정하면 외부 상태가 불일치할 수 있습니다.
AtomicFaaS는 이 책임을 애플리케이션 코드가 아니라 Serverless 플랫폼 계층으로 옮기려는 접근입니다. 개발자가 함수마다 “실패하면 무엇을 되돌릴지”를 일일이 오케스트레이션하는 대신, 플랫폼이 외부 호출을 관찰하고 기록한 뒤 실패 시 보상 절차를 수행합니다.
함수 코드 밖에서 관리되는 보상 흐름
AtomicFaaS가 제안하는 핵심 흐름은 비교적 명확합니다.
함수 실행
└─ 외부 서비스 호출 발생
└─ 플랫폼이 호출을 가로채고 효과를 로그에 기록
└─ 함수 실패 감지
└─ 완료된 작업을 찾아 역순으로 보상
예를 들어 함수가 다음 순서로 실행됐다고 해보겠습니다.
결제 승인 성공
재고 차감 성공
배송 주문 생성 실패
기존 방식에서는 개발자가 결제 취소와 재고 복구를 호출하는 로직을 직접 작성해야 합니다. 반면 AtomicFaaS 모델에서는 플랫폼이 내결함성 로그에서 이미 완료된 결제와 재고 작업을 확인하고, 해당 작업의 보상을 실행합니다.
이때 로그에는 단순한 성공 여부만이 아니라 보상에 필요한 정보가 기록돼야 합니다.
- 어떤 함수 실행에서 발생한 작업인지 나타내는
Invocation ID - 개별 외부 호출을 식별하는
Operation ID - 호출 대상 서비스와 원래 요청 정보
- 외부 작업의 완료 상태
- 취소·환불·복구에 필요한 보상 메타데이터
- 보상 실행 및 재시도 상태
함수 컨테이너가 갑자기 종료돼도 이 정보가 플랫폼에 남아 있기 때문에, Serverless 런타임은 사라진 함수 인스턴스의 외부 효과를 추적할 수 있습니다.
Saga가 사라지는 것이 아니라, 보이지 않게 되는 것
AtomicFaaS는 Saga 자체를 없애는 기술이라기보다, Saga의 실행과 추적을 공통 플랫폼 기능으로 추상화하는 기술에 가깝습니다.
| 구분 | 수동 Saga | AtomicFaaS 방식 |
|---|---|---|
| 보상 로직의 위치 | 애플리케이션 코드 | Serverless 플랫폼 |
| 상태 추적 | 개발자가 DB·워크플로 엔진에 구현 | 플랫폼의 내결함성 로그 |
| 재시도 처리 | 함수별 조건문과 멱등성 코드 | 호출 효과와 실행 상태를 기반으로 관리 |
| 주요 위험 | 보상 누락, 순서 오류, 중복 처리 | 보상 API 부재, 플랫폼 운영 복잡성 |
| 개발자 경험 | 유연하지만 복잡함 | 단순해지지만 플랫폼 규약 필요 |
이는 특히 여러 팀이 다양한 외부 API를 연결하는 환경에서 의미가 큽니다. 각 팀이 제각각 Saga를 구현하면 실패 처리 방식이 달라지고, 운영 중 문제를 재현하기도 어려워집니다. 반대로 플랫폼이 공통 형식의 로그와 보상 상태를 제공하면, 장애 분석과 관찰 가능성도 일관되게 설계할 수 있습니다.
재시도를 더 안전하게 만드는 Serverless 실행 모델
Serverless 환경에서 재시도는 흔한 일입니다. 네트워크 오류, 타임아웃, 컨테이너 종료, 일시적인 외부 API 장애가 발생하면 플랫폼은 함수를 다시 실행할 수 있습니다.
하지만 외부 효과가 발생한 뒤 응답을 받기 전에 함수가 종료됐다면, 재시도는 위험합니다. 첫 번째 실행이 실제로 결제를 완료했는지 확실하지 않은 상태에서 같은 요청을 다시 보내면 중복 결제가 발생할 수 있기 때문입니다.
AtomicFaaS는 재시도를 단순히 “함수를 다시 실행하는 작업”으로 보지 않습니다. 이전 실행이 남긴 효과를 먼저 확인하고, 필요한 경우 보상 또는 정리 절차를 수행한 뒤 다음 실행으로 이어질 수 있는 기반을 제공합니다.
다만 이것이 모든 문제를 자동으로 해결한다는 뜻은 아닙니다. 결제 취소, 재고 복구처럼 되돌릴 수 있는 작업에는 효과적이지만, 이메일 발송이나 SMS 알림처럼 이미 외부에 전달된 정보는 완전히 취소할 수 없습니다. 결국 각 외부 서비스는 보상 API, 작업 식별자, 멱등성 규칙을 제공해야 합니다.
그럼에도 AtomicFaaS가 던지는 메시지는 분명합니다. 실패 복구는 더 이상 함수 개발자가 매번 처음부터 구현해야 할 부가 기능이 아니라, Serverless 플랫폼이 책임질 수 있는 핵심 실행 의미론이 될 수 있다는 것입니다.
Serverless가 호출을 가로채고, 로그를 남기고, 되돌리는 방식
함수 컨테이너가 갑자기 사라졌더라도 플랫폼이 어떤 외부 작업이 이미 성공했는지 알고 있다면, 실패 대응의 방식은 완전히 달라집니다.
AtomicFaaS의 핵심은 단순합니다. 함수가 외부 시스템에 요청을 보낼 때 이를 가로채고, 결과를 내결함성 로그에 남기며, 함수 실행이 실패하면 기록된 정보를 바탕으로 이미 발생한 효과를 보상합니다. 이 세 고리가 연결돼야 Serverless 환경에서 재시도와 장애 복구를 더 안전하게 처리할 수 있습니다.
외부 호출을 플랫폼 계층에서 가로챈다
일반적인 Serverless 함수는 데이터베이스, 결제 API, 메시지 큐, 재고 시스템처럼 다양한 외부 서비스와 통신합니다. 문제는 함수 코드가 외부 호출을 수행한 직후 충돌할 수 있다는 점입니다.
예를 들어 결제 승인 API는 성공했지만, 응답을 받은 뒤 함수 컨테이너가 종료될 수 있습니다. 이때 함수 내부 메모리와 실행 상태는 사라집니다. 재시도가 시작되면 플랫폼은 첫 번째 결제가 성공했는지 알기 어렵고, 같은 요청을 다시 전송해 중복 결제를 만들 위험이 있습니다.
AtomicFaaS는 함수와 외부 서비스 사이에 중간 계층을 둡니다.
Serverless Function
│
▼
AtomicFaaS 호출 가로채기 계층
│
├── 내결함성 로그 기록
│
▼
데이터베이스 · 결제 API · 메시지 큐 · SaaS API
이 계층은 외부 요청의 성공 여부만 확인하지 않습니다. 나중에 해당 작업을 취소하거나 되돌릴 수 있도록, 보상에 필요한 메타데이터도 함께 관리합니다.
대표적으로 다음 정보가 기록될 수 있습니다.
- 함수 실행을 식별하는
Invocation ID - 개별 외부 작업을 구분하는
Operation ID - 호출 대상 서비스와 작업 유형
- 원래 요청의 결과 또는 외부 리소스 식별자
- 보상 호출에 필요한 정보
- 작업 완료, 보상 대기, 보상 완료 같은 상태
이 구조의 목적은 명확합니다. 함수 인스턴스가 죽어도 외부 효과의 이력을 플랫폼이 잃지 않도록 만드는 것입니다.
내결함성 로그가 실패 이후의 기준점이 된다
AtomicFaaS에서 로그는 단순한 디버깅 기록이 아닙니다. 실패한 실행을 복구하는 데 사용하는 운영 데이터입니다.
가령 주문 처리 함수가 다음 순서로 실행된다고 가정해 보겠습니다.
결제 승인 → 재고 차감 → 배송 주문 생성
재고 차감까지 성공한 뒤 배송 주문 생성 단계에서 함수가 충돌했다면, 플랫폼은 로그를 통해 다음을 판단할 수 있어야 합니다.
결제 승인: 성공
재고 차감: 성공
배송 주문 생성: 미완료 또는 실패
함수 실행: 실패
이 정보가 없으면 재시도는 위험합니다. 반면 AtomicFaaS처럼 외부 효과가 내결함성 로그에 남아 있다면, 플랫폼은 실패한 invocation이 남긴 작업을 식별하고 정해진 보상 절차를 시작할 수 있습니다.
실패한 함수 실행 감지
│
▼
플랫폼 로그 조회
│
▼
성공했지만 최종 완료되지 않은 외부 작업 확인
│
▼
역순 또는 정의된 정책에 따라 보상 실행
여기서 중요한 점은 로그가 함수 컨테이너 안에 존재해서는 안 된다는 것입니다. 컨테이너는 장애, 자동 축소, 타임아웃, 재배포로 언제든 제거될 수 있습니다. 따라서 로그는 함수 생명주기와 독립된 플랫폼 관리 영역에 내구성 있게 저장돼야 합니다.
실패가 감지되면 이미 발생한 효과를 보상한다
AtomicFaaS는 함수 코드의 예외만 실패로 보지 않습니다. Serverless 환경에서는 코드가 정상적으로 오류를 반환하지 못하는 실패가 더 까다롭습니다.
플랫폼은 다음과 같은 상황을 감지한 뒤 보상을 시작할 수 있습니다.
- 함수 코드에서 처리되지 않은 예외가 발생한 경우
- 함수 타임아웃이 발생한 경우
- 컨테이너 또는 함수 인스턴스가 충돌한 경우
- 네트워크 장애로 실행 상태를 확정할 수 없는 경우
- 플랫폼이 함수를 재시도하기 직전인 경우
보상은 일반적으로 이미 성공한 작업에 대해 반대 효과를 수행하는 방식입니다.
| 원래 작업 | 가능한 보상 작업 |
|---|---|
| 재고 수량 차감 | 재고 수량 복원 |
| 예약 생성 | 예약 취소 |
| 임시 파일 생성 | 파일 삭제 |
| 메시지 예약 발행 | 예약 취소 또는 소비 전 무효화 |
| 결제 승인 | 승인 취소 또는 환불 요청 |
예를 들어 결제 승인과 재고 차감이 끝난 뒤 배송 주문 생성에 실패했다면, 플랫폼은 보상 메타데이터를 사용해 재고를 복원하고 결제 승인을 취소할 수 있습니다.
결제 승인 성공
재고 차감 성공
배송 주문 생성 실패
│
▼
AtomicFaaS 보상 시작
│
├── 재고 차감 보상: 재고 복원
└── 결제 승인 보상: 승인 취소
이 과정은 강한 분산 트랜잭션의 즉시 롤백과는 다릅니다. 외부 효과는 잠시 존재할 수 있고, 보상은 실패 뒤에 비동기적으로 수행될 수 있습니다. 그럼에도 플랫폼이 작업 이력을 알고 재시도 가능한 보상 절차를 제공한다는 점에서, 개발자가 각 함수마다 Saga 상태와 보상 순서를 직접 관리하는 부담을 크게 줄일 수 있습니다.
재시도도 더 안전한 실행 모델로 바뀐다
기존 Serverless 재시도는 종종 “같은 함수를 다시 실행하는 것”에 가깝습니다. 하지만 외부 효과가 포함된 함수에서 단순 재실행은 중복 결제, 중복 메시지 발행, 중복 데이터 갱신으로 이어질 수 있습니다.
AtomicFaaS는 재시도 전에 이전 실행의 흔적을 확인하는 모델을 지향합니다. 즉, 실패한 실행이 완전히 정리됐는지, 아직 보상이 진행 중인지, 재실행해도 되는지를 플랫폼 로그를 기준으로 판단할 수 있습니다.
다만 이 접근이 효과를 내려면 원래 작업과 보상 작업 모두 멱등성을 갖춰야 합니다. 보상 요청이 네트워크 오류로 여러 번 전송되더라도 재고가 여러 번 복원되거나 결제가 중복 취소되어서는 안 됩니다.
결국 AtomicFaaS는 Serverless 함수에 “실패하면 다시 실행한다”는 단순한 규칙을 넘어, 실패 이전에 무엇이 외부에 반영됐는지 추적하고 정리한 뒤 재시도한다는 실행 의미론을 더합니다.
자동 보상은 원자적 커밋이 아니다: Serverless에서 알아야 할 경계
플랫폼이 실패한 작업을 자동으로 되돌려 준다고 해서, 모든 일이 완벽하게 없던 일이 되는 것은 아닙니다. 이미 고객에게 발송된 이메일을 회수할 수 있을까요? 제3자 시스템에 전달된 요청이 취소 API를 제공하지 않는다면 어떻게 될까요?
AtomicFaaS가 제공하려는 것은 강력한 자동화지만, 이는 분산 트랜잭션의 원자적 커밋(atomic commit) 과는 분명히 다릅니다.
먼저 실행하고, 실패하면 되돌리는 모델
전통적인 강한 원자성은 모든 참여 시스템이 하나의 트랜잭션처럼 움직이는 것을 목표로 합니다. 모든 작업이 성공하면 함께 커밋되고, 하나라도 실패하면 어느 시스템에도 변경이 남지 않아야 합니다.
반면 AtomicFaaS의 Serverless 실행 모델은 다음 흐름에 가깝습니다.
외부 작업 실행
↓
플랫폼이 작업 결과와 보상 정보를 기록
↓
함수 실패 감지
↓
이미 성공한 작업에 보상 요청 수행
즉, 결제 승인이나 재고 차감 같은 외부 효과는 일단 발생할 수 있습니다. 이후 함수가 실패하면 플랫폼이 취소, 환불, 재고 복구 같은 보상 작업을 실행합니다.
이 방식은 실용적이지만, 보상이 완료되기 전까지 외부 시스템에는 중간 상태가 존재합니다.
결제 승인 완료
재고 차감 완료
배송 주문 생성 실패
↓
결제 취소 및 재고 복구 수행
이 짧은 사이에 고객이 결제 승인 알림을 받거나, 다른 시스템이 감소한 재고를 조회할 수 있습니다. 결국 보상은 상태를 복구하려는 절차이지, 처음부터 효과가 외부에 보이지 않게 막는 장치는 아닙니다.
되돌릴 수 없는 외부 효과가 있다
자동 보상이 특히 어려워지는 지점은 역연산이 존재하지 않는 작업입니다. 대표적인 사례는 다음과 같습니다.
- 이메일, SMS, 푸시 알림 발송
- 외부 메신저 채널에 게시한 공지
- 물리적 장치 제어 명령
- 취소 기능이 없는 제3자 API 호출
- 외부 사용자가 이미 확인하거나 처리한 정보
- 현금 지급, 배송 출고처럼 현실 세계에 영향을 미친 작업
예를 들어 주문 처리 함수가 결제 승인 후 고객에게 “주문이 완료되었습니다”라는 이메일을 보낸 뒤 실패했다고 가정해 보겠습니다. AtomicFaaS는 결제를 취소할 수 있고 재고를 복구할 수도 있습니다. 하지만 이미 도착한 이메일을 고객의 받은편지함에서 삭제할 수는 없습니다.
이때 가능한 것은 ‘완전한 취소’가 아니라 새로운 보상 효과를 만드는 일입니다.
주문 완료 이메일 발송
↓
주문 처리 실패
↓
결제 취소 및 재고 복구
↓
주문 취소 안내 이메일 추가 발송
이는 기술적으로 일관성을 회복하는 과정이 아니라, 사용자 경험과 업무 흐름까지 고려한 업무적 보정입니다.
보상 작업도 실패할 수 있다
보상은 또 다른 외부 호출입니다. 따라서 원래 작업과 마찬가지로 실패할 수 있습니다.
- 결제 취소 API가 타임아웃됨
- 재고 복구 서비스가 일시적으로 중단됨
- 보상 요청은 전달됐지만 응답을 받기 전에 함수가 종료됨
- 같은 보상 요청이 재시도로 여러 번 실행됨
- 취소 가능 시간이 지나 보상 요청이 거부됨
따라서 Serverless 환경에서 자동 보상을 신뢰하려면 원래 작업뿐 아니라 보상 작업도 멱등적이어야 합니다. 같은 취소 요청이 여러 번 도착해도 한 번만 처리된 것과 같은 결과를 만들어야 합니다.
운영 측면에서는 다음 상태를 추적할 수 있어야 합니다.
| 상태 | 의미 |
|---|---|
| 완료 | 모든 업무 작업이 정상적으로 끝남 |
| 보상 대기 | 함수 실패가 감지됐으며 보상이 필요함 |
| 보상 진행 중 | 플랫폼이 이전 효과를 되돌리는 중 |
| 보상 완료 | 추적 가능한 보상 작업이 모두 끝남 |
| 보상 실패 | 재시도 또는 운영자 개입이 필요함 |
| 보상 불가 | 역연산이 없거나 허용 시간이 만료됨 |
자동 보상은 개발자의 코드를 줄이지만, 보상 실패를 다루는 운영 체계까지 없애 주지는 않습니다.
Serverless 설계에서 필요한 현실적인 구분
AtomicFaaS 같은 접근은 결제 취소, 예약 해제, 재고 복구처럼 명확한 보상 API가 있는 업무 효과에 특히 적합합니다. 반면 이메일·SMS·알림처럼 철회가 어려운 효과는 별도 전략이 필요합니다.
실무에서는 외부 작업을 다음처럼 나누는 편이 안전합니다.
보상 가능한 작업
- 결제 승인 취소
- 재고 수량 복구
- 예약 해제
- 주문 상태 롤백
→ AtomicFaaS 기반 자동 추적·보상 적용
보상하기 어려운 작업
- 이메일·SMS 발송
- 외부 공지 게시
- 물리적 배송 지시
→ Outbox, 승인 상태 확인, 재처리 및 운영 reconciliation 적용
특히 사용자 알림은 핵심 업무 상태가 확정된 뒤 발행하는 것이 좋습니다. 예를 들어 주문 생성, 결제 확정, 재고 확보가 모두 확인된 후에만 “주문 완료” 이벤트를 outbox에 기록하고, 별도 소비자가 이메일을 발송하도록 분리할 수 있습니다.
핵심은 ‘완벽한 취소’가 아니라 ‘통제 가능한 복구’다
AtomicFaaS는 모든 분산 작업을 하나의 데이터베이스 트랜잭션처럼 처리하지 않습니다. 대신 함수가 남긴 외부 효과를 기록하고, 실패 시 가능한 범위에서 일관되게 되돌릴 수 있도록 돕습니다.
따라서 이 기술을 도입할 때는 다음 질문을 먼저 던져야 합니다.
- 이 외부 작업에는 취소 또는 보상 API가 있는가?
- 보상 요청이 중복되어도 안전한가?
- 보상이 지연되는 동안 중간 상태를 누가 볼 수 있는가?
- 보상할 수 없는 효과는 어떤 방식으로 사후 처리할 것인가?
- 보상 실패 시 자동 재시도와 운영자 개입 절차가 준비돼 있는가?
결론적으로 Serverless의 자동 보상은 “모든 실패를 지운다”는 약속이 아닙니다. 더 정확한 표현은 실패 후 남은 효과를 추적하고, 되돌릴 수 있는 범위에서 복구하는 플랫폼 기능입니다. 이 경계를 이해해야 자동 보상을 과신하지 않으면서도, 분산 실패 처리의 복잡성을 크게 줄일 수 있습니다.
Serverless의 다음 단계는 실패의 의미를 관리하는 것
Serverless의 핵심 가치는 지금까지 명확했습니다. 서버를 직접 관리하지 않아도 되고, 요청량에 따라 자동으로 확장되며, 사용한 만큼 비용을 낸다는 점입니다. 하지만 실제 서비스에서 더 어려운 문제는 함수가 정상적으로 실행될 때가 아니라, 실행 도중 멈췄을 때 발생합니다.
AtomicFaaS가 던지는 질문도 여기에 있습니다.
플랫폼은 단순히 함수를 자동 확장하는 것을 넘어, 실패 뒤에 남은 외부 상태를 추적하고 정리하는 책임까지 맡을 수 있을까요?
예를 들어 주문 처리 함수가 결제를 승인한 뒤 재고를 차감하고, 마지막으로 배송 요청을 생성한다고 가정해 보겠습니다. 배송 요청 단계에서 함수가 충돌하면 결제는 이미 완료됐을 수 있습니다. 이후 재시도가 발생하면 결제가 중복 승인되거나, 재고와 주문 상태가 서로 어긋날 위험이 생깁니다.
기존 Serverless 환경에서 이 문제는 대체로 개발자의 몫이었습니다. 개발자는 멱등성 키를 설계하고, 단계별 상태를 저장하며, 실패 시 결제를 취소하거나 재고를 복구하는 Saga 보상 로직을 직접 구현해야 했습니다. 그러나 이러한 코드는 정상 흐름보다 예외 흐름에서 더 복잡해지고, 작은 누락 하나가 금전적 손실이나 데이터 불일치로 이어질 수 있습니다.
AtomicFaaS는 이 책임을 플랫폼 계층으로 옮기려는 시도입니다. 함수가 데이터베이스, 결제 API, 메시지 큐 같은 외부 시스템을 호출하면 플랫폼이 이를 가로채고, 호출 결과와 보상에 필요한 메타데이터를 내결함성 로그에 기록합니다. 함수가 예외로 종료되거나 컨테이너가 사라지면, 플랫폼은 남아 있는 외부 효과를 확인해 보상 작업을 수행합니다.
이 접근이 의미 있는 이유는 Serverless의 추상화 범위를 넓히기 때문입니다.
- 기존 Serverless: 서버 운영, 확장, 런타임, 재시작을 추상화
- AtomicFaaS가 지향하는 Serverless: 외부 효과의 추적, 실패 감지, 보상 절차까지 추상화
물론 이것이 모든 문제를 해결하는 것은 아닙니다. 이미 발송된 이메일, 외부에 노출된 알림, 취소 API가 없는 제3자 서비스 호출은 완전히 되돌릴 수 없습니다. 또한 보상 요청도 실패할 수 있으므로 재시도, 운영 큐, 감사 로그, 수동 조정 절차가 필요합니다.
그럼에도 방향성은 분명합니다. 앞으로의 Serverless 경쟁력은 얼마나 빠르게 함수를 실행하고 확장하는가만으로 결정되지 않을 것입니다. 함수가 실패했을 때 어떤 외부 효과가 남았는지 알고, 이를 얼마나 안전하게 복구할 수 있는가가 더 중요한 플랫폼 역량이 될 수 있습니다.
AtomicFaaS는 Serverless가 단순한 실행 환경을 넘어, 분산 시스템의 실패 의미론까지 관리하는 플랫폼으로 진화할 가능성을 보여줍니다.
