1.3.5 멱등성(Idempotency) 위배 사례: 동일 입력에 대한 상이한 출력으로 인한 데이터 무결성 훼손
소프트웨어 엔지니어링의 전통적인 패러다임에서 시스템의 신뢰성을 담보하는 가장 핵심적인 속성 중 하나는 멱등성(Idempotency)이다. 멱등성이란 동일한 연산을 여러 번 수행하더라도 결과가 처음 한 번 수행했을 때와 동일하게 유지되는 성질을 의미한다. 예를 들어, 데이터베이스에서 특정 레코드를 특정 값으로 업데이트하는 ‘PUT’ 요청이나, 특정 ID의 자원을 삭제하는 ‘DELETE’ 요청은 여러 번 반복되더라도 시스템의 최종 상태가 변하지 않으므로 멱등적이라고 간주된다. 그러나 대형 언어 모델(LLM)을 포함한 생성형 AI가 소프트웨어의 핵심 로직에 편입되면서, 이러한 결정론적 시스템의 근간인 멱등성이 심각하게 위협받고 있다. AI 모델은 본질적으로 확률적(Probabilistic)이며 비결정론적(Nondeterministic)인 특성을 지니고 있기 때문에, 동일한 프롬프트를 입력하더라도 매번 다른 출력을 내놓을 가능성이 상존한다. 이러한 비결정성은 단순한 텍스트 변이를 넘어, API 호출, 데이터베이스 트랜잭션, 그리고 상태 관리 전반에 걸쳐 데이터 무결성을 훼손하는 심각한 부작용을 초래한다.
1. 멱등성의 고전적 정의와 분산 시스템에서의 위상
전통적인 분산 시스템에서 멱등성은 네트워크 오류나 타임아웃으로 인한 재시도(Retry) 매커니즘을 안전하게 구현하기 위한 필수 조건이다. 클라이언트가 서버에 요청을 보냈으나 응답을 받지 못한 경우, 클라이언트는 해당 요청이 성공했는지 실패했는지 알 수 없으므로 동일한 요청을 다시 보낸다. 이때 서버가 멱등성을 보장한다면 중복 처리가 발생하지 않지만, 멱등성이 깨진 시스템에서는 중복 결제나 데이터 중복 삽입과 같은 심각한 오류가 발생한다.
Idempotence는 수학적 연산에서 f(f(x)) = f(x)로 정의되며, 이는 연산을 반복 적용해도 상태의 변화가 가중되지 않음을 의미한다. IT 기술 시스템에서 이러한 특성은 시스템의 안정성을 보장하는 ’영속적 상태의 안정성’과 직결된다. 엘리베이터 버튼을 여러 번 누르는 행위가 엘리베이터의 목적지를 바꾸지 않는 것처럼, 멱등적인 API 설계는 클라이언트의 중복 요청에 대해 시스템이 안전하게 반응하도록 설계된다. 특히 HTTP 메서드 중 GET, HEAD, PUT, DELETE 등은 표준적으로 멱등성이 요구되며, 이는 분산 컴퓨팅 환경에서 장애 내성(Fault Tolerance)을 확보하는 근간이 된다.
1.1 표 1: 전통적 시스템과 AI 기반 시스템의 멱등성 매커니즘 비교
| 비교 항목 | 전통적 시스템 (Deterministic) | AI 기반 시스템 (Probabilistic) |
|---|---|---|
| 핵심 원리 | 명시적 로직 및 유니크 키 기반 제어 | 확률적 토큰 생성 및 통계적 예측 |
| 동일 입력 결과 | 비트 단위(Bitwise) 일치 보장 | 의미적 유사성은 높으나 형식적 차이 발생 가능 |
| 재시도 영향 | 상태 변경 없음 (Idempotency-Key 사용) | 상이한 출력으로 인한 상태 분기 발생 |
| 데이터 무결성 | 원자성(Atomicity)을 통한 엄격한 보호 | 환각(Hallucination) 및 출력 변이로 인한 훼손 위험 |
| 성능 오라클 | f(x) \rightarrow y (확정적) | P(y \vert x) (확률적 분포) |
2. 비결정성의 기술적 심연: 부동 소수점 연산의 배신
AI 모델의 출력이 동일 입력에 대해 상이하게 나타나는 현상은 단순한 우연이 아니라 하드웨어와 소프트웨어 스택 전반에 걸친 복합적인 요인에 기인한다. 특히 부동 소수점 연산의 비결합성(Non-associativity)과 호스팅 환경에서의 병렬 처리 최적화가 주요 원인으로 지목된다.
2.1 부동 소수점 연산의 비결합성과 오차 확산
컴퓨터 과학에서 부동 소수점 덧셈은 결합법칙이 성립하지 않는다. 즉, (a + b) + c의 결과가 a + (b + c)와 다를 수 있다. 이는 유한한 정밀도를 가진 부동 소수점 형식이 연산 순서에 따라 반올림 오차(Rounding Error)를 다르게 발생시키기 때문이다. 예를 들어 아주 큰 수와 아주 작은 수를 더할 때, 유효 숫자의 범위 밖으로 밀려나는 데이터가 발생하며, 이 연산의 순서가 뒤바뀌면 결과값의 비트 단위(Bitwise) 일치성이 파괴된다.
LLM의 추론 과정은 수조 번의 행렬 곱셈과 가산으로 이루어지며, 현대의 GPU는 연산 속도를 극대화하기 위해 수천 개의 코어에서 병렬로 작업을 수행한다. 이때 연산이 완료되는 순서나 스케줄링이 미세하게 달라지면 부동 소수점 가산의 순서가 변경되고, 최종적으로 로짓(Logit) 값에 비트 단위의 차이가 발생한다. 비록 이 차이가 10^{-7} 수준의 극소값이라 할지라도, 소프트맥스(Softmax) 함수를 거쳐 토큰을 선택하는 과정에서 확률 분포의 임계점에 걸려 있는 두 토큰의 순위가 뒤바뀔 수 있다. 일단 첫 번째 토큰이 달라지면, 그다음 토큰 생성 시 이전의 상이한 토큰이 컨텍스트로 입력되므로 오차는 기하급수적으로 증폭되어 완전히 다른 문장을 생성하게 된다. 이는 소위 ’카오스 이론’의 나비 효과가 신경망의 순방향 연산 과정에서 실현되는 것과 같다.
2.2 호스팅 인프라 및 배치 아키텍처의 영향
상용 LLM API(예: OpenAI, Together AI)는 효율성을 높이기 위해 동적 배치(Dynamic Batching) 및 지속적 배치(Continuous Batching) 기술을 사용한다. 이는 여러 사용자의 요청을 하나의 연산 단위로 묶어 GPU 성능을 극대화하는 방식이다. 그러나 사용자의 요청이 어떤 다른 요청들과 함께 배치에 포함되느냐에 따라 연산 커널의 메모리 레이아웃과 실행 경로가 미세하게 달라진다.
구체적으로, vLLM과 같은 추론 엔진은 ’Prefix Caching’이나 ’Input Buffer Packing’과 같은 최적화를 수행하는데, 이는 입력 토큰이 물리적으로 처리되는 시점과 순서를 가변적으로 만든다. 결과적으로 사용자가 온도를 0으로 설정하더라도, 서버 측의 부하 상태나 함께 처리되는 다른 요청의 존재 유무가 출력의 비결정성을 유발하는 외부 변수로 작용하게 된다. 이는 소프트웨어 엔지니어가 통제할 수 없는 영역에서 멱등성이 파괴됨을 의미하며, 이러한 ’런투런 비결정성(Run-to-run nondeterminism)’은 엔터프라이즈 환경에서 재현성(Reproducibility)을 가로막는 가장 큰 기술적 장벽이다.
3. 데이터 무결성 훼손의 실체적 위협 1: 금융 및 결제 시스템
금융 시스템에서 멱등성은 ’단 한 번의 집행(Exactly-once processing)’을 보장하기 위한 최후의 보루다. AI 에이전트가 사용자의 자연어 요청을 해석하여 송금이나 결제를 수행하는 시나리오에서 멱등성 위배는 직접적인 금전적 손실로 이어진다.
3.1 자연어 기반 결제 에이전트의 재시도 오류
사용자가 “식료품 배달 서비스에 5만 원을 결제해줘“라고 요청한다고 가정하자. AI 에이전트는 이 요청을 해석하여 외부 API를 호출하기 위한 JSON 객체를 생성한다. 이때 네트워크 지연으로 인해 에이전트가 응답을 받지 못해 재시도를 수행할 경우, 다음과 같은 멱등성 위배 현상이 발생할 수 있다.
- 첫 번째 시도: 에이전트가 “5만 원 결제” 요청을 생성하고 고유한
request_id를 할당하여 게이트웨이에 전송한다. 서버는 결제를 처리했으나 응답이 에이전트에게 도달하기 전 타임아웃이 발생한다. - 두 번째 시도 (재시도): 에이전트는 동일한 프롬프트를 다시 처리한다. 이때 비결정성으로 인해 이번에는 “50,000원 결제” 또는 “배달 서비스 5만 원 결제“와 같이 의미는 같으나 형식이 미세하게 다른 페이로드를 생성할 수 있다. 만약 에이전트가
request_id자체를 생성할 때 AI 모델의 출력을 기반으로 한다면, 두 번째 시도에서는 다른 ID가 생성될 가능성이 높다. - 결과: 금융 API 서버는 이를 새로운 별개의 요청으로 인식하여 두 번의 결제를 수행하게 된다. 이는 고객의 불만뿐만 아니라 시스템 신뢰도에 치명적인 타격을 준다.
이러한 문제를 해결하기 위해 도입된 ‘Idempotency-Key’ 헤더 방식조차, 키를 생성하는 로직 자체가 AI 모델에 의존적이라면 무용지물이 된다. 모델이 동일한 비즈니스 의도에 대해 매번 다른 해시값을 유도하는 텍스트를 생성한다면, 결정론적 시스템에서 구축한 방어막이 AI의 확률적 특성 앞에서 무너지는 것이다.
4. 데이터 무결성 훼손의 실체적 위협 2: 자율적 데이터베이스 관리와 스키마 표류
AI 에이전트가 자율적으로 데이터베이스 스키마를 수정하거나 인프라 설정을 변경하는 경우, 멱등성 위배는 시스템 전체의 가용성을 위협하는 ‘구성 표류(Configuration Drift)’ 현상을 유발한다.
4.1 자율적 스키마 변경 시의 충돌 시나리오
AI 기반의 DB 관리 도구가 특정 쿼리 성능을 최적화하기 위해 인덱스를 추가하라는 지시를 받았다고 가정하자. 멱등적 시스템이라면 이미 인덱스가 존재하는지 확인하고, 존재한다면 작업을 건너뛰어야 한다. 그러나 AI 에이전트가 “인덱스를 생성하라“는 명령을 해석하여 SQL을 생성할 때, 실행마다 다른 인덱스 이름을 부여하거나 미세하게 다른 옵션을 적용한다면 다음과 같은 문제가 발생한다.
- 중복 인덱스 생성:
idx_user_email대신user_email_index라는 이름으로 동일한 컬럼에 인덱스를 중복 생성하여 쓰기 성능을 저하시킨다. - 스키마 불일치: 에이전트가 재시도 과정에서 컬럼의 데이터 타입을
VARCHAR(255)에서TEXT로 다르게 판단하여 변경을 시도하면, 하위 데이터 분석 파이프라인이 기대하는 스키마 구조와 충돌하여 전체 워크플로우가 중단된다. - 권한 및 접근 제어의 부작용: 에이전트가 권한 부여 명령을 수행할 때, 첫 번째 실행에서는 최소 권한 원칙을 따랐으나 두 번째 실행에서는 비결정적으로 더 넓은 범위의 권한(
GRANT ALL)을 부여하는 환각을 일으킬 수 있다. 이는 보안 무결성을 근본적으로 파괴하는 행위다.
이러한 위험은 AI 에이전트가 자신의 과거 행동을 정확하게 기억하지 못하는 ’상태 관리의 어려움’과 결합될 때 더욱 극대화된다. 이전 실행에서 생성한 자원의 이름을 현재 실행에서 다른 이름으로 참조하려 시도하는 순간, 시스템은 정의되지 않은 상태로 진입하며 복구가 불가능한 지점에 도달한다.
5. 학술적 조명: 일관성(Consistency) 측정의 방법론과 한계
AI 모델의 비결정성 문제를 해결하기 위해 학계에서는 일관성(Consistency)이라는 개념을 정립하고 이를 측정하기 위한 다양한 프레임워크를 제안해 왔다. 이는 멱등성 위배를 사전에 탐지하고 제어하기 위한 정량적 기초가 된다.
5.1 ParaRel: 사실적 지식 추출의 일관성 연구
Yanai Elazar 등이 발표한 Measuring and Improving Consistency in Pretrained Language Models (2021) 논문은 사전 학습된 언어 모델(PLM)이 의미적으로 동일한 질문(Paraphrase)에 대해 얼마나 일관된 답변을 내놓는지 분석하였다. 이 연구는 “Seinfeld가 처음 방영된 네트워크는이다“와 “Seinfeld는에서 데뷔했다“와 같이 문장 구조만 바꾼 동일한 의도의 질문 세트인 ‘ParaRel’ 데이터셋을 구축하였다.
연구 결과에 따르면, 대부분의 모델은 정답 여부와 상관없이 질문의 형태가 조금만 바뀌어도 다른 답변을 내놓는 등 일관성이 매우 낮게 나타났다. 이는 모델이 지식을 논리적 구조로 저장하는 것이 아니라 학습 데이터의 표면적인 통계적 패턴에 의존하고 있음을 시사한다. 특히 모델이 특정 사실을 정확히 알고 있을 때(Correctness)보다 단순히 응답할 때 일관성이 더 떨어진다는 점은, AI를 소프트웨어 로직의 결정 도구로 사용할 때의 위험성을 잘 보여준다.
5.2 TAR(Total Agreement Rate)과 일관성 지표
비결정성 정도를 정량화하기 위해 On the Consistency of Large Language Models와 같은 최신 연구에서는 TAR(Total Agreement Rate) 지표를 사용한다. 이는 동일한 질문에 대해 N번의 실행을 반복했을 때, 모든 응답이 특정 기준에서 일치하는 비율을 의미한다.
5.2.1 표 2: LLM 출력 일관성 측정을 위한 주요 지표 및 수식
| 지표명 | 수식 및 정의 | 설명 |
|---|---|---|
| TARr@N (Raw) | \frac{\sum_{i=1}^{M} \mathbb{I}(\text{Output}_{i,1} = \dots = \text{Output}_{i,N})}{M} | N번의 모든 응답이 문자열 수준에서 비트 단위로 완벽히 일치하는 비율 |
| TARa@N (Parsed) | \frac{\sum_{i=1}^{M} \mathbb{I}(\text{Answer}_{i,1} = \dots = \text{Answer}_{i,N})}{M} | 정규표현식이나 파서를 통해 추출된 최종 정답이 일치하는 비율 |
| SSD (Semantic Similarity Distance) | D_{sem} = \vert \mu_{fake} - \mu_{real} \vert^2 + \dots | 텍스트가 달라도 임베딩 공간에서의 의미적 거리가 유지되는지 측정 |
| Logical Consistency | P(A \vert B) \text{ vs } P(\neg A \vert B) | 부정문이나 대우 명제에 대해 논리적 모순이 없는지 검증 |
이러한 지표들은 AI 모델이 생성한 결과물을 소프트웨어 시스템의 ’상태 값’으로 직접 사용할 수 있는지 판단하는 척도가 된다. 실험에 따르면 많은 상용 모델들이 특정 벤치마크에서 실행 간에 최대 15% 이상의 정확도 편차를 보이며, 최적의 성능과 최악의 성능 사이의 간극이 무려 70%에 달하기도 한다. 이는 AI 기반 시스템에서 멱등성을 기대하는 것이 얼마나 도전적인 과제인지를 실증적으로 입증한다.
6. 오류의 복리 효과: 다중 단계 추론 에이전트의 붕괴
복잡한 문제를 해결하기 위해 여러 단계의 추론을 거치는 AI 에이전트 워크플로우(Agentic Workflow)에서는 초기 단계의 비결정적 출력이 후속 단계로 전달되며 오류가 ’복리(Compounding)’로 쌓이는 현상이 나타난다.
6.1 추론 경로의 발산과 상태 파괴
어떤 비즈니스 보고서를 요약하고 그 결과를 바탕으로 ERP 시스템에 데이터를 입력하는 에이전트가 있다고 가정하자.
- 1단계 (요약): 첫 번째 실행에서는 모델이 “수익 10% 증가“라고 정확히 요약한다.
- 2단계 (입력): 에이전트는 “10%“를 시스템에 입력하려 시도하지만, 네트워크 일시 오류로 응답 수신에 실패한다.
- 재시도 발생: 시스템은 1단계부터 다시 시작한다. 비결정성으로 인해 이번에는 모델이 “수익이 전년 대비 소폭 상승함“이라고 모호하게 요약한다.
- 최종 붕괴: 2단계에서 에이전트는 “소폭 상승“이라는 텍스트에서 숫자를 추출하지 못해 실패하거나, 기본값인 “0%“를 입력하는 실수를 범한다.
이 과정에서 시스템은 ’동일 입력(원문 보고서) \rightarrow 상이한 중간 출력(요약본) \rightarrow 데이터 무결성 훼손(잘못된 수치 입력)’의 경로를 밟게 된다. 이는 특히 이전 단계의 실수가 다음 단계의 논리적 근거로 활용되는 자율 에이전트 환경에서 치명적이다. 에러가 발생했을 때 이전 상태로 완벽히 되돌릴 수 있는 ’롤백(Rollback) 맵’이 부재하기 때문에, 한 번의 비결정적 변이가 전체 트랜잭션을 오염시키게 된다.
7. 엔지니어링적 대응: 결정론적 오라클과 정합성 보장 체계
AI의 비결정성을 완전히 제거하는 것은 현재의 컴퓨팅 아키텍처상 불가능에 가깝다. 따라서 엔지니어링적 접근법은 AI의 출력을 ’확정적 정답’으로 받아들이는 대신, 이를 검증하고 구조화할 수 있는 결정론적 오라클(Deterministic Oracle) 시스템을 구축하는 방향으로 선회해야 한다.
7.1 멱등성 보장을 위한 설계 패턴
- 시맨틱 캐싱과 멱등성 키 분리: 단순한 텍스트 매칭 캐시가 아니라, 입력 프롬프트의 의미적 해시를 생성하여 일정 임계치 이상일 경우 이전의 확정된 출력을 재사용한다. 이때
Idempotency-Key는 AI가 생성하는 것이 아니라 시스템의 비즈니스 로직에 의해 결정론적으로 생성되어야 한다. - 구조화된 출력 강제(Structured Outputs): JSON Schema 등을 활용하여 모델이 생성할 수 있는 데이터의 형식을 엄격히 제한한다. 형식을 벗어난 경우 AI가 아닌 결정론적 검증 로직에서 이를 즉시 차단하고 재생성을 요구하거나 예외를 발생시킨다.
- 상태 머신 기반 워크플로우: AI에게 전체 흐름 제어권을 전적으로 맡기는 대신, 각 단계의 상태 전이를 결정론적인 워크플로우 엔진이 관리하게 하고 AI는 각 단계 내에서의 데이터 변환 도구로만 사용한다. 이는 AI의 비결정성이 시스템의 ’상태 분기’를 결정하지 못하게 차단하는 보호막 역할을 한다.
- 실행 피드백 루프(Execution Feedback): AI가 생성한 코드나 쿼리를 실제 환경에 적용하기 전, 샌드박스에서 실행하여 그 결과가 기대하는 사양(Specification)을 만족하는지 검증하는 결정론적 오라클을 배치한다.
8. 결론: 신뢰할 수 있는 AI 소프트웨어를 향한 제언
멱등성은 소프트웨어 시스템이 가져야 할 단순한 속성이 아니라, 복잡한 분산 환경에서 생존하기 위한 필수적인 신뢰의 계약이다. AI 모델이 도입됨에 따라 이 계약이 위협받고 있으며, 동일 입력에 대한 상이한 출력은 데이터베이스 트랜잭션 실패, 인프라 설정 오류, 금융 사고 등 실질적인 데이터 무결성 훼손으로 나타나고 있다.
기술적으로 부동 소수점 연산의 미세한 오차와 클라우드 인프라의 동적 배치 구조는 AI의 비결정성을 영구적인 상수로 만들었다. 따라서 미래의 AI 기반 소프트웨어 개발은 모델의 성능 향상에만 의존할 것이 아니라, 이러한 비결정적 출력을 결정론적 정답으로 변환하고 검증할 수 있는 견고한 오라클 시스템을 설계하는 데 집중해야 한다. 멱등성 위배 사례는 우리에게 ’느낌적 코딩(Vibe Coding)’의 한계를 경고하며, 엄밀한 엔지니어링적 원칙으로의 회귀를 촉구하고 있다. 데이터의 무결성은 확률에 맡겨질 수 있는 영역이 아니며, 오직 확정적인 검증 체계만이 AI 소프트웨어의 실전 배치를 허가할 수 있는 유일한 기준이 될 것이다.
9. 참고 자료
- Idempotence & Idempotent Design in IT/Tech Systems - Splunk, https://www.splunk.com/en_us/blog/learn/idempotent-design.html
- What is the difference between an Idempotent and a Deterministic function? - Stack Overflow, https://stackoverflow.com/questions/40296211/what-is-the-difference-between-an-idempotent-and-a-deterministic-function
- Reliability for unreliable LLMs - Stack Overflow, https://stackoverflow.blog/2025/06/30/reliability-for-unreliable-llms/
- Non-Determinism of “Deterministic” LLM System … - ACL Anthology, https://aclanthology.org/2025.eval4nlp-1.12.pdf
- Idempotency: A Deep-Dive Triggered by a Real-World Double-Charge Failure - Medium, https://medium.com/@techmedaddy/idempotency-a-deep-dive-triggered-by-a-real-world-double-charge-failure-7cf1b5c4356f
- Ensuring Idempotency in Java RESTful APIs - IJIRCT, https://www.ijirct.org/download.php?a_pid=2412093
- Database Transactions, Lost Updates & Idempotency - STRV, https://www.strv.com/blog/database-transactions-lost-updates-idempotency-engineering
- What is idempotency in Redis? Cost-saving patterns for LLM apps, https://redis.io/blog/what-is-idempotency-in-redis/
- The Unseen Variable: Why Your LLM Gives Different Answers (and How We Can Fix It), https://hackernoon.com/the-unseen-variable-why-your-llm-gives-different-answers-and-how-we-can-fix-it
- Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
- Determinism in LLMs: Order of Operations, Precision and Why It Breaks | by Pieter Geelen | 𝐀𝐈 𝐦𝐨𝐧𝐤𝐬.𝐢𝐨 | Medium, https://medium.com/aimonks/determinism-in-llms-order-of-operations-precision-and-why-it-breaks-3192c69eaec4
- AI Agents and the Silent Risk in Database Change | The AI Journal, https://aijourn.com/ai-agents-and-the-silent-risk-in-database-change/
- Top 10 OWASP Vulnerabilities in LLM (and How to Avoid Them in Development), https://svitla.com/blog/owasp-vulnerabilities-llm/
- Measuring and Improving Consistency in Pretrained Language Models - MIT Press Direct, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00410/107384/Measuring-and-Improving-Consistency-in-Pretrained
- Measuring and Improving Consistency in Pretrained Language Models - ACL Anthology, https://aclanthology.org/2021.tacl-1.60/
- Measuring and Improving Consistency in Pretrained Language Models - ResearchGate, https://www.researchgate.net/publication/348958567_Measuring_and_Improving_Consistency_in_Pretrained_Language_Models
- Measuring and Improving Consistency in Pretrained Language Models - Yanai Elazar, https://yanaiela.github.io/presentations/consistency.pdf
- Measuring and improving consistency in pretrained language models - Bar-Ilan University, https://cris.biu.ac.il/en/publications/measuring-and-improving-consistency-in-pretrained-language-models/
- Consistency in Language Models: Current Landscape … - arXiv, https://arxiv.org/pdf/2505.00268
- The Six Failures of Text-to-SQL (And How to Fix Them with Agents) | by Karl Weinmeister | Google Cloud - Medium, https://medium.com/google-cloud/the-six-failures-of-text-to-sql-and-how-to-fix-them-with-agents-ef5fd2b74b68
- Generating API Parameter Security Rules with LLM for API Misuse Detection - arXiv, https://arxiv.org/html/2409.09288v2