AI에게 여러 작업을 맡겨도 될까? — Transaction과 Atomicity를 실험해보다

1. 후보자를 등록한다
2. 후보자의 평가 정보를 등록한다
3. 알림을 전송한다

후보자는 등록되었고
평가 정보도 등록되었지만
알림만 전송되지 않은

AI
↓
작업을 요청
...

register_candidate
candidate_id = 123

AI
↓
여러 작업을 요청
...

BEGIN
operation A
operation B
...

BEGIN
operation A
operation B
...

와 같은 중간 상태를 막습니다.

이것이 Transaction과 Atomicity를 생각하는 기본적인 포인트입니다.

## 3. AI를 Transaction으로 생각해서는 안 된다

여기서 중요한 것은,

**AI 자체가 Transaction을 보장해 주지는 않는다**

는 것입니다.

AI는,

와 같은 계획이나 작업 요청을 생성할 수는 있습니다. 

하지만,

-
도중에 실패하면 어떻게 할지
어디까지 변경을 되돌릴지
외부 시스템에 보낸 처리를 취소할 수 있는지
재실행해도 중복 실행이 되지 않을지

와 같은 상태 관리는 AI와는 별개의 문제입니다.

따라서,

와 같은 역할 분담이 필요합니다.

## 4. PI-032 ― 여러 작업을 Fail-Closed로 다루기

먼저, 여러 작업을 요청했을 경우의 실행 제어를 확인합니다.

하나의 요청 안에 여러 작업이 포함되어 있고, 그중 하나라도 승인되지 않는 작업이 존재하는 경우,

로 하여,

라는 Fail-Closed 동작을 합니다.

여기서 확인하고 싶은 것은,

일부 작업이 허가되었다고 해서, 요청 전체를 실행해도 되는지?

여러 작업을 하나의 논리적인 요청으로 다룬다면, 실행 전에 전체를 검증한다는 생각이 중요합니다.

## 5. PI-033 ― 부분 실행이라는 문제

다음으로, 일부러 Transaction이나 Rollback을 고려하지 않은 상태로 여러 작업을 실행합니다.

예를 들어,

operation A → 성공
operation B → 성공
operation C → 실패

이 경우,

라는 상태가 될 가능성이 있습니다.

이는 AI가 잘못해서 발생한 문제가 아닙니다.

AI가 생성한 작업이 모두 정확했더라도,

-
데이터베이스 오류
-
네트워크 오류
-
외부 서비스 장애
-
타임아웃
-
프로세스 종료

등에 의해 처리는 도중에 실패합니다.

즉,

**AI의 출력이 정확한 것과, 처리 전체가 안전하게 완료되는 것은 별개의 문제입니다.**

## 6. PI-034 / PI-035 ― 여러 작업 실행 제어하기

여기서부터는 여러 작업을 하나의 프로세스로 다루기 위한 실행 제어를 확인합니다.

중요한 것은,

라는 사실과,

을 분리하는 것입니다.

AI는,

와 같은 작업 후보를 생성합니다.

그 후, 애플리케이션 측에서,

라는 처리를 수행합니다.

여기서도 AI의 판단을 그대로 실행 제어로 변환하지 않는 것이 핵심입니다.

## 7. Transaction만으로는 모든 것을 해결할 수 없다

여기서 또 다른 중요한 문제가 있습니다.

Transaction은 데이터베이스 변경을 Rollback 할 수는 있지만, 외부 시스템에 대해 수행한 처리까지 자동으로 되돌릴 수 있는 것은 아닙니다.

예를 들어,

이라고 했을 경우,

이메일을 전송한 후에 데이터베이스 측에서 오류가 발생하여 Rollback 하더라도,

**전송된 이메일은 자동으로 사라지지 않습니다.**

즉,

입니다.

AI 에이전트가,

-
이메일을 보내는 것
-
API를 호출하는 것
-
파일을 변경하는 것
-
티켓을 생성하는 것
-
외부 서비스를 조작하는 것

등의 처리까지 하게 되면, 이 문제는 더욱 중요해집니다.

## 8. AI에게 작업을 맡길 때, 애플리케이션이 담당해야 할 것은 무엇인가

지금까지의 실험을 통해 AI와 애플리케이션의 역할을 정리할 수 있습니다.

여기서 중요한 것은, AI에게 아무것도 시키지 않는 것이 아닙니다.

오히려,

**AI가 잘하는 부분은 맡기고, 상태 변경이나 보안 경계는 애플리케이션 측에서 관리한다**

라는 분담입니다.

## 9. 이번 실험에서 생각하고 싶었던 것

이번 실험에서 확인하고 싶었던 것은,

'AI가 정확한 작업을 생성했다면, 그대로 실행해도 괜찮은가?'

라는 질문이었습니다.

실제로는 한 단계 더 생각해야 합니다.

AI를 실제 시스템 조작에 연결할 경우, 단순히 AI의 출력을 검증하는 것만으로는 충분하지 않습니다.

**실행 자체를 안전하게 설계해야 합니다.**

## 10. 다음 문제 ― Retry하면 무슨 일이 생길까?

여기까지에서,

-
작업의 Validation
-
Authorization
-
Access Control
-
여러 작업 실행 제어
-
Transaction / Atomicity

에 대해 생각해 왔습니다.

하지만 실제 시스템에서는, 처리가 실패했다고 해서 단순히 종료되는 것은 아닙니다.

예를 들어,

와 같은 일이 발생합니다.

만약 첫 번째 처리가 실제로는 성공했다면,

이 되어,

**같은 작업이 2번 실행되어 버릴**

가능성이 있습니다.

게다가,
-
Race Condition
-
Idempotency
-
Crash Recovery
-
외부 시스템의 부작용

같은 문제들도 발생합니다.

다음 실험에서는 이 부분을 깊이 파고들 것입니다.
**'실패했으니까 Retry한다'는 정말 안전할까요?**

### Discussion
![](https://static.zenn.studio/images/drawing/discussion.png)