AI 기반 시스템, 특히 프로덕션(production)에서 실행되는 파이프라인은 끊임없이 오류의 위험을 안고 있습니다. 저는 네트워크 중단, API 응답 시간, 모델 응답 지연, 데이터 불일치 또는 외부 서비스의 일시적인 사용 불가능과 같은 상황을 빈번하게 마주합니다. 이러한 문제들은 AI 파이프라인의 신뢰성에 직접적인 영향을 미치며 워크플로우를 방해할 수 있습니다. 이 포스트에서 저는 AI 파이프라인의 오류를 관리하기 위해 사용하는 두 가지 근본적인 전략인 재시도(retry) 및 멱등성(idempotency) 메커니즘에 대해 논의할 것입니다. 제가 이를 어떻게 설계하는지, 언제 그리고 어떻게 구현하는지, 그리고 실제 시나리오에서 배운 교훈들을 공유하겠습니다. 저의 목표는 이러한 접근 방식들을 통해 시스템이 더 탄력적(resilient)이고 예측 가능하게 작동하도록 보장하는 것입니다.

AI 파이프라인 오류의 본질과 나의 초기 관찰

AI 파이프라인은 일반적으로 데이터 수집(data ingestion), 전처리(preprocessing), 모델 추론(model inference), 그리고 결과 저장 또는 다른 시스템으로의 전송과 같은 여러 단계로 구성됩니다. 각 단계는 고유한 오류 가능성을 가지고 있습니다. 특히 외부 의존성(external dependencies)과 분산 아키텍처(distributed architecture)는 오류 시나리오를 더욱 복잡하게 만듭니다.

지난달, 저는 제조 기업의 ERP에 통합한 AI 기반 생산 계획 엔진에서 유사한 상황을 경험했습니다. 외부 API로부터 생산 데이터를 가져오는 동안, 네트워크 타임아웃(network timeouts) 또는 느린 API 응답으로 인해 1,000번의 호출 중 평균 15번이 실패했습니다. 이로 인해 계획 엔진이 불완전한 데이터로 작동하게 되었고, 결과적으로 잘못된 생산 결정이 내려졌습니다. 문제의 근본 원인은 API 자체에 있었던 것이 아니라, 순간적인 네트워크 변동에 있었습니다.

ℹ️ 오류 관찰

AI 파이프라인의 오류는 종종 일시적(transient)이며 외부 요인에 의해 발생합니다. 모델 자체가 올바르게 작동하더라도, 데이터 흐름에서의 순간적인 중단이나 지연은 전체 프로세스를 중단시킬 수 있습니다. 따라서 오류의 본질을 이해하는 것은 올바른 해결 전략을 선택하는 데 매우 중요합니다. 이러한 시나리오에서는 오류가 영구적인지(permanent) 아니면 일시적인지(transient)를 구분하는 것이 중요합니다.

영구적인 오류(permanent errors)(예: 잘못된 데이터 형식 또는 권한 문제)의 경우, 재시도(retrying)는 무의미하며 리소스만 낭비할 뿐입니다. 하지만 일시적인 오류(transient errors)의 경우, 재시도 메커니즘을 통해 시스템이 스스로 치유(self-heal)할 수 있게 하여 운영 부담을 줄여줍니다. 제 경험상, 제가 마주하는 오류의 80% 이상은 일시적인 오류였습니다.

재시도: 언제, 어떻게 사용할 것인가?
재시도 메커니즘은 일시적인 오류가 발생했을 때, 특정 간격으로 정해진 횟수만큼 작업을 재시도하도록 보장합니다. 이는 특히 원격 서비스 호출(remote service calls), 데이터베이스 연결(database connections), 또는 네트워크 작업(network operations)에서 매우 중요합니다. 하지만 모든 곳에 무분별하게 재시도를 추가하면 시스템에 원치 않는 부작용을 초래할 수 있습니다.

제가 가장 흔히 사용하는 재시도 전략은 "지터(jitter)를 포함한 지수 백오프(exponential backoff with jitter)"입니다. 이 방법에서는 실패한 시도 사이의 대기 시간이 기하급수적으로 증가하며(exponential backoff), 이 시간에 무작위 지연(jitter)이 추가됩니다. 지터는 동시에 실패한 여러 작업이 정확히 같은 순간에 재시도되는 것을 방지하여, 대상 서비스에 갑작스러운 부하 급증(load spikes)이 발생하는 것을 막아줍니다.

import time
import random
import requests

def retry_with_backoff ( func , retries = 5 , delay = 1 , backoff_factor = 2 , jitter = 0.1 ):
    """ 특정 함수를 exponential backoff와 jitter를 사용하여 재시도합니다. """
    for i in range ( retries ):
        try :
            return func ()
        except requests . exceptions . RequestException as e :
            print ( f " 시도 { i + 1 } 실패: { e } " )
            if i < retries - 1 :
                sleep_time = delay * ( backoff_factor ** i )
                sleep_time = sleep_time * ( 1 + random . uniform ( - jitter , jitter ))
                print ( f " { sleep_time : . 2 f } 초 동안 대기 중... " )
                time . sleep ( sleep_time )
            else :
                print ( " 모든 시도가 실패했습니다. " )
                raise

def call_ai_service ():
    """ AI 서비스 호출 예시. 가끔 오류가 발생합니다. """
    response = requests . get ( " http://ai-service-endpoint.com/predict " , timeout = 2 )
    response . raise_for_status ( ) # HTTP 4xx/5xx 오류에 대해 exception을 발생시킵니다.
    return response .

json() # 사용 예시

try:

result = retry_with_backoff(call_ai_service, retries=3, delay=0.5)

print(f"성공적인 결과: {result}")

except Exception as e:

print(f"최종적으로 작업이 실패했습니다: {e}")

제 사이드 프로젝트의 Android 애플리케이션에서는 백엔드 서비스 호출 시 일반적으로 지수 백오프 (Exponential Backoff)를 적용하여 최대 2초까지 3회의 재시도 (Retries)를 수행합니다. 이는 모바일 네트워크 환경의 일시적인 변동에 매우 효과적이며 사용자 경험 (UX)을 크게 개선합니다. 하지만 여기서 고려해야 할 트레이드오프 (Trade-off)가 있습니다. 재시도는 전체 처리 시간을 연장하고 대상 서비스에 추가적인 부하를 줄 수 있습니다. 따라서 재시도 횟수와 대기 시간을 올바르게 설정하는 것이 매우 중요합니다. 재시도가 너무 많으면 리소스 낭비와 더 긴 지연을 초래할 수 있고, 너무 적으면 시스템이 취약해질 수 있습니다.

멱등성 (Idempotency): 왜 중요하며 어떻게 보장하는가?
재시도 메커니즘을 구현할 때 간과해서는 안 될 가장 중요한 문제 중 하나는 멱등성 (Idempotency)입니다. 어떤 작업이 여러 번 수행되더라도 시스템의 상태가 첫 번째 실행 후와 동일하게 유지된다면 그 작업은 멱등하다고 합니다. 이는 분산 시스템 (Distributed Systems), 특히 재시도 메커니즘이 사용되는 곳에서 매우 필수적입니다. 그렇지 않으면 동일한 작업이 여러 번 처리되어 데이터 불일치나 원치 않는 부작용 (Side effects)을 초래할 수 있습니다. 예를 들어, 운영 중인 ERP에서 주문 상태를 업데이트하는 AI 서비스를 가정해 보겠습니다. 이 업데이트 중에 네트워크 오류가 발생하여 재시도 메커니즘이 활성화되면, 동일한 업데이트 요청이 서버에 여러 번 도달할 수 있습니다. 만약 멱등성이 보장되지 않는다면, 주문 상태가 두 번 업데이트되거나 다른 부작용이 발생할 수 있습니다.

⚠️ 멱등성 없는 재시도의 위험성
멱등하지 않은 작업을 재시도하는 것은 예상치 못한 데이터 손상, 중복 레코드 생성, 또는 금융 시스템에서의 이중 결제와 같은 심각한 문제로 이어질 수 있습니다. 따라서 재시도를 구현할 때는 관련 작업이 멱등하도록 보장하거나, 멱등하게 만드는 것이 필수적입니다.

멱등성(Idempotency)을 보장하는 방법에는 여러 가지가 있습니다:

• 고유 요청 ID (Unique Request IDs / Idempotency Keys): 각 요청에 고유한 ID(UUID와 같은)를 추가합니다. 서버는 이 ID를 사용하여 동일한 요청이 이전에 처리되었는지 확인합니다. 이미 처리되었다면 동일한 결과를 반환하고 작업을 다시 수행하지 않습니다.
• 조건부 업데이트 (Conditional Updates): 데이터베이스 업데이트를 수행할 때, 특정 조건(예: 버전 필드)이 충족되는 경우에만 작업을 실행합니다.
• UPSERT (INSERT ON CONFLICT): 데이터베이스 수준에서 레코드가 존재하지 않으면 삽입하고, 존재하면 업데이트합니다. PostgreSQL에서는 INSERT ... ON CONFLICT (id) DO UPDATE ... 구문이 이 기능을 제공합니다.

은행의 내부 플랫폼에서 저는 거래 기록을 유지할 때 항상 transaction_id 또는 request_uuid를 사용했습니다. 이를 통해 네트워크 장애가 발생한 후 동일한 작업을 다시 보냈을 때도 시스템이 이를 단 한 번만 처리하도록 보장할 수 있었습니다. 이는 금융 거래와 같은 중요한 영역에서는 필수적인 접근 방식입니다. 저는 또한 제가 만든 금융 계산기(financial calculators)로 들어오는 요청에도 유사한 X-Request-ID 헤더를 사용합니다.

FastAPI 예시

from fastapi import FastAPI, Header, HTTPException
from typing import Optional
from uuid import uuid4

app = FastAPI()
processed_requests = {}  # 실제로는 데이터베이스나 Redis를 사용해야 합니다

@app.post("/process_ai_task")
async def process_ai_task(data: dict, x_idempotency_key: Optional[str] = Header(None)):
    if not x_idempotency_key:
        raise HTTPException(status_code=400, detail="X-Idempotency-Key is required")

    if x_idempotency_key in processed_requests:
        # 이전에 처리됨, 동일한 결과 반환
        print(f"Idempotency Key {x_idempotency_key}로 이미 처리됨, 동일한 결과 반환 중.")
        return processed_requests[x_idempotency_key]

    # 작업 수행
    print(f"Idempotency Key {x_idempotency_key}로 새로운 작업 시작 중.")

)
result = {
"status": "processed",
"data": data,
"processed_id": str(uuid4())
}
processed_requests[x_idempotency_key] = result
# 실제 애플리케이션에서는, 이 시점에 작업이 완료된 후 영구적으로 저장되어야 합니다.
# 예: 데이터베이스에 저장하고 committed_transactions 테이블에 idempotency_key를 추가합니다.
return result

사용 예시 (curl 사용)

curl -X POST "http://localhost:8000/process_ai_task" \

-H "X-Idempotency-Key: some-unique-key-123" \

-H "Content-Type: application/json" \

-d '{"prompt": "Generate a summary"}'

이 예시에서 processed_requests 딕셔너리는 간단한 인메모리 저장소 (in-memory store) 역할을 합니다. 실제 운영 환경 (production environment)에서는 Redis와 같은 빠른 키-값 저장소 (key-value store) 또는 데이터베이스의 전용 테이블을 사용하여 이를 관리해야 합니다. 키의 생명 주기 (lifecycle) 및 정리 메커니즘 (cleanup mechanisms) 또한 고려되어야 합니다.

재시도(Retry)와 멱등성(Idempotency)을 함께 설계하기

재시도 (Retry)와 멱등성 (Idempotency)은 서로를 보완하는 두 가지 강력한 메커니ism입니다. 재시도는 일시적인 오류 (transient errors)를 극복함으로써 작업이 완료될 확률을 높여주며, 멱등성은 이러한 재시도가 시스템 내에서 의도하지 않은 중복을 생성하지 않도록 보장합니다. 이 두 요소를 올바르게 설계하면 분산 AI 파이프라인 (distributed AI pipelines)의 신뢰성을 배가시킬 수 있습니다.

클라이언트 프로젝트 중, 운영 중인 ERP에서 들어오는 데이터 스트림 (data stream)에서 주문의 배송 상태가 변경될 때 AI 모델에 이를 알릴 필요가 있었습니다. 만약 이 알림 과정에서 네트워크 중단 (network outage)이 발생하여 재시도가 수행될 경우, 멱등성이 없다면 모델이 동일한 주문의 배송 상태를 두 번 처리하려고 시도할 수 있습니다. 이는 잘못된 생산 계획이나 불필요한 자원 할당으로 이어질 수 있습니다. 이러한 시나리오를 위해 저는 일반적으로 고유 메시지 ID (unique message IDs)와 함께 "트랜잭션 아웃박스 패턴 (transaction outbox pattern)" 또는 메시지 큐 (message queues, 예: Kafka, RabbitMQ)를 사용합니다.

💡 트랜잭션 아웃박스 패턴 (Transaction Outbox Pattern)

트랜잭션 아웃박스 패턴은 데이터베이스 작업 (예: 레코드 업데이트)과 이 작업에 의해 트리거되는 메시지 (예: 이벤트)가 원자적 (atomically)으로 발행되도록 보장합니다.

이는 데이터베이스 레코드가 업데이트될 때 메시지가 반드시 전송되도록 보장하며, 재시도 (Retry) 메커니즘과 결합하여 멱등성 (Idempotency)을 확보하는 강력한 방법이 됩니다. 이 패턴에서는 데이터베이스에서 작업이 수행될 때, 동일한 트랜잭션 내의 "아웃박스 (outbox)" 테이블에도 이벤트가 함께 기록됩니다. 트랜잭션이 성공하면, 별도의 서비스나 프로세스가 이 아웃박스 테이블을 모니터링하며 이벤트를 메시지 큐 (Message Queue)로 전송합니다. 만약 오류가 발생하여 작업이 재시도되더라도, 아웃박스 테이블에 있는 고유한 이벤트 ID (멱등성 키 (Idempotency Key) 역할) 덕분에 동일한 이벤트가 중복 전송되는 것을 방지할 수 있습니다. 이 접근 방식은 특히 이벤트 소싱 (Event-sourcing) 아키텍처나 마이크로서비스 간 통신 (Inter-microservice communication)에서 자주 사용됩니다. -- 예시 아웃박스 테이블 스키마 (PostgreSQL)

CREATE TABLE outbox_messages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid (),
aggregate_type VARCHAR ( 255 ) NOT NULL ,
aggregate_id VARCHAR ( 255 ) NOT NULL ,
event_type VARCHAR ( 255 ) NOT NULL ,
payload JSONB NOT NULL ,
created_at TIMESTAMPTZ DEFAULT NOW (),
processed_at TIMESTAMPTZ ,
status VARCHAR ( 50 ) DEFAULT 'PENDING' -- PENDING, SENT, FAILED
);

-- 하나의 트랜잭션과 아웃박스 기록을 원자적 (Atomically)으로 작성하기 (의사 코드 (Pseudocode))

-- BEGIN TRANSACTION;
-- UPDATE orders SET status = 'SHIPPED' WHERE id = 'order-123';
-- INSERT INTO outbox_messages (aggregate_type, aggregate_id, event_type, payload)
-- VALUES ('Order', 'order-123', 'OrderShipped', '{"order_id": "order-123", "new_status": "SHIPPED"}');
-- COMMIT TRANSACTION;

이 구조는 분산 시스템 (Distributed systems)에서의 트랜잭션 일관성 문제를 크게 완화합니다. 제 경험상, 이 패턴을 구현한 시스템에서는 AI 파이프라인으로 전송되는 데이터의 일관성과 작업의 재현성 (Repeatability)이 크게 향상되었습니다. [관련: 분산 시스템에서의 트랜잭션 관리 (transaction management in distributed systems)]에 대해 더 알고 싶으시다면, 이전에 제가 작성한 관련 기사를 확인해 보시기 바랍니다.

모니터링 및 알림 메커니즘: 장애 탐지

재시도(Retry)와 멱등성(Idempotency) 메커니즘이 아무리 강력하더라도, 시스템 내의 오류와 그 영향을 모니터링하는 것은 필수적입니다. 파이프라인 성능, 오류율(Error rates), 재시도 횟수(Number of retry attempts), 그리고 재시도 성공률(Success rate of retries)과 같은 지표(Metrics)는 시스템의 상태(Health)에 대한 귀중한 통찰을 제공합니다. 관찰 가능성(Observability) 없이는 이러한 메커니즘이 얼마나 효과적으로 작동하고 있는지, 또는 어디에서 개선이 필요한지 이해하기 어렵습니다. 저에게 있어 모니터링이란 오류를 탐지하는 것뿐만 아니라, 시스템의 정상적인 운영 조건으로부터의 이탈을 탐지하는 것을 포함합니다. 제가 사용하는 몇 가지 주요 모니터링 지표는 다음과 같습니다:

• 오류율 (Error Rate): 전체 작업 수 대비 실패한 작업의 비율.
• 재시도 횟수 (Retry Count): 하나의 작업이 재시도된 횟수. 높은 재시도 횟수는 지속적인 일시적(Transient)