AI 에이전트는 왜 중복 실행을 먼저 잡아야 하는가

Lead: 에이전트가 느린 이유는 모델이 약해서만이 아니다. 같은 도구를 같은 인자로 두 번 부르고, 그 사실을 나중에야 알아차리는 일이 생각보다 자주 일어난다. 중복 실행은 단순 버그가 아니라 비용, 신뢰, 디버깅 시간을 동시에 키우는 운영 문제다.

TL;DR

중복 실행은 에이전트 신뢰를 망치는 가장 조용한 실패 패턴이다.
해결책은 더 큰 모델이 아니라 idempotency, completion state, replay 가능한 로그다.
루프를 잘 설계하면 “똑똑한 에이전트”보다 “운영 가능한 에이전트”를 먼저 만들 수 있다.

왜 지금 중요한가

지금 에이전트 시장은 데모 경쟁을 지나 운영 경쟁으로 들어가고 있다. 그 말은 곧, 사용자가 결과만 보는 시대에서 과정과 반복 비용까지 보는 시대로 넘어갔다는 뜻이다.

오늘 모아진 자료도 같은 방향을 가리킨다.

MCP 도구를 여러 개 붙여 운영할 때, 중복 실행이 실제로 얼마나 자주 생기는지 묻는 질문이 있었다.
re_gent는 AI 코딩 에이전트의 작업을 git처럼 추적하려고 한다.
loop vs graph 같은 설명은 에이전트의 경로 소유권과 종료 조건이 얼마나 중요한지 다시 보여준다.
source of truth와 검증 가능성을 강조하는 메모는, 결국 에이전트가 신뢰를 얻는 방식이 “잘 말하는 것”이 아니라 “잘 남기는 것”임을 말한다.

즉, 에이전트의 성숙도는 똑똑함보다 같은 일을 두 번 하지 않게 만드는 설계에서 먼저 드러난다.

중복 실행이 조용히 돈을 태우는 방식

중복 실행은 늘 눈에 띄는 에러로 나타나지 않는다. 오히려 가장 위험한 형태는 성공한 것처럼 보이는 실패다.

요청 1회 → 도구 호출 1회 → 결과 반영
요청 1회 → 도구 호출 2회 → 결과는 비슷해 보임 → 비용과 혼란만 증가

이 패턴이 무서운 이유는 세 가지다.

비용이 쌓인다
같은 API, 같은 파일 수정, 같은 검색을 두 번 하면 토큰과 시간은 바로 두 배 가까이 늘어난다.
신뢰가 무너진다
사용자는 “되긴 했네”라고 느끼지만, 실제로는 같은 작업을 여러 번 했다는 사실을 모른다.
디버깅이 어려워진다
결과만 보면 정상처럼 보여도, 로그를 열어보면 같은 step이 반복된 흔적이 남아 있다.

그래서 중복 실행은 단순한 버그가 아니다. 운영 품질을 갉아먹는 습관이다.

loop와 graph는 같은 말이 아니다

에이전트 설계에서 자주 섞이는 개념이 있다. loop와 graph다. 둘은 비슷해 보이지만 책임이 다르다.

loop는 반복과 검증을 관리한다.
graph는 분기와 경로를 관리한다.

이 둘을 섞으면 가장 먼저 흐려지는 것이 완료 상태다.

flowchart LR
  A[Input] --> B[Plan]
  B --> C[Tool call]
  C --> D[Verify]
  D -->|pass| E[Commit / Stop]
  D -->|fail| B

이 구조에서 중요한 건 화살표의 개수가 아니다. 어느 지점에서 멈추는지가 분명해야 한다는 점이다.

에이전트가 실행 중일 때는 계속 돌아도 된다. 하지만 한 번 멈춰야 할 순간을 놓치면, 그 다음부터는 반복 실행이 비용으로 바뀐다.

idempotency는 에이전트의 안전벨트다

같은 인자로 두 번 호출해도 결과가 한 번만 반영되게 만드는 장치가 없으면, 에이전트는 재시도와 중복을 구분하지 못한다.

그래서 최소한 아래 셋은 있어야 한다.

idempotency key: 같은 작업인지 구분하는 키
completion state: 작업이 진행 중인지, 끝났는지, 검증됐는지
replay 가능한 로그: 나중에 경로를 다시 볼 수 있는 기록

이 셋이 있으면 “두 번 실행”은 무서운 사건이 아니라 탐지 가능한 이벤트가 된다.

예를 들면 다음처럼 나눌 수 있다.

상태	의미	다음 행동
created	작업이 생성됨	실행 시작
running	도구 호출 중	결과 수집
verifying	검증 단계	pass/fail 판단
completed	끝남	기록 보관
duplicated	같은 작업이 다시 들어옴	차단 또는 병합

이 표가 중요한 이유는 단순하다. 에이전트가 “무슨 말을 했는가”보다 어떤 상태에서 멈췄는가가 더 중요하기 때문이다.

실제 사례에서 보인 신호

오늘 읽은 자료는 각자 다른 맥락이지만, 같은 문제를 비춘다.

1) 여러 MCP 도구를 붙인 운영자는 중복 실행을 묻고 있다

도구가 많아질수록 모델은 선택지를 더 많이 갖게 되지만, 동시에 같은 일을 반복할 위험도 커진다. 도구 수가 늘어날수록 필요한 건 더 큰 자유도가 아니라 중복을 막는 운영 규칙이다.

2) `re_gent`는 작업을 git처럼 추적하려고 한다

이건 단순한 UX가 아니다. 에이전트가 무엇을 했는지 log, blame, show, replay로 복원할 수 있어야 중복 실행도 눈에 띈다.

3) loop vs graph 설명은 종료 조건의 중요성을 다시 보여준다

루프는 계속 돌리는 구조가 아니라, 끝낼 수 있는 구조여야 한다. 끝이 없으면 자동화가 아니라 소모다.

4) source of truth와 검증 가능성은 기본 문법이 된다

에이전트가 실무로 들어가면, 사용자는 결과물만 믿지 않는다. 경로와 증거를 같이 본다.

바로 해볼 실험

이 주제는 추상적으로만 보면 끝이 없다. 대신 바로 점검할 수 있다.

최근 에이전트 세션 20개를 뽑는다.
같은 도구가 같은 인자로 반복 호출된 지점을 찾는다.
반복이 많은 단계에 idempotency key를 붙인다.
created / running / verifying / completed / duplicated 상태를 분리한다.
하루만 다시 돌려서 호출 수와 수동 개입 횟수를 본다.

이 실험의 목표는 성능 향상이 아니다. 중복 실행이 줄어드는지, 그리고 줄어든 이유를 설명할 수 있는지를 보는 것이다.

리스크 / 반론

물론 모든 반복 호출이 나쁜 것은 아니다.

재시도는 필요하다.
네트워크 오류는 일어난다.
검증을 위해 같은 정보를 다시 읽어야 할 때도 있다.

그래서 핵심은 “무조건 금지”가 아니다. 재시도와 중복을 구분할 수 있게 만드는 것이다.

좋은 시스템은 에이전트를 막지 않는다. 대신 에이전트가 반복했을 때 그 반복이 정상인지 이상인지 판별할 수 있게 만든다.

결론

AI 에이전트의 성숙도는 똑똑함이 아니라, 같은 일을 두 번 하지 않게 만드는 설계에서 드러난다.

중복 실행을 먼저 잡아야 하는 이유는 단순하다. 그 문제를 해결해야만 비용이 줄고, 신뢰가 쌓이고, 디버깅이 가능해지기 때문이다.

결국 사용자가 원하는 건 더 많은 실행이 아니라, 한 번의 실행이 끝났다는 확신이다.