AI API 제한·Backoff 루프

AI 기능이 외부 모델, 결제, 검색, 이미지 생성, 알림 발송 같은 서비스를 호출하기 시작하면 “코드가 맞는가”만으로는 안정성을 판단할 수 없습니다. 호출량이 몰리는 순간 제한에 걸리고, 재시도 코드가 잘못 설계되면 장애를 더 크게 만들며, AI 에이전트가 원인을 모른 채 같은 요청을 반복하면 비용과 사용자 신뢰가 동시에 무너집니다. 이 글의 주제는 AI가 만든 API 연동을 운영 가능한 형태로 바꾸는 rate limit · backoff · circuit breaker 루프입니다.

초보자는 rate limit을 “상대 서비스가 한 번에 받아 줄 수 있는 요청 수의 울타리”로 이해하면 됩니다. backoff는 실패했을 때 바로 다시 때리지 않고 점점 더 천천히 다시 시도하는 방식입니다. circuit breaker는 실패가 너무 많아졌을 때 잠시 호출을 멈추고 사용자에게 안전한 대체 흐름을 보여 주는 장치입니다. 실무에서는 이 셋을 따로 보지 않습니다. 사용자 행동, 큐, 재시도 간격, 비용 한도, 로그, 알림, 승인 기준을 묶어 하나의 VIBE 코딩 작업 단위로 다룹니다.

핵심 결론

AI에게 API 연동을 맡길 때는 “호출 코드를 만들어줘”가 아니라 “제한을 만났을 때 안전하게 줄 서고, 다시 시도하고, 멈추고, 설명하고, 복구하는 루프를 설계하라”고 지시해야 합니다. 정상 응답만 처리하는 코드는 데모에서는 잘 보이지만 실제 서비스에서는 부족합니다. 제한 응답, 일시적 서버 오류, 네트워크 타임아웃, 중복 클릭, 백그라운드 작업 폭주, 부분 성공, 비용 초과 가능성까지 함께 다뤄야 합니다.

좋은 루프는 네 가지 약속을 지킵니다. 첫째, 사용자가 같은 버튼을 여러 번 눌러도 중복 요청이 폭주하지 않습니다. 둘째, 제한 응답을 받으면 즉시 무한 재시도를 하지 않고 지수 backoff와 jitter로 분산합니다. 셋째, 실패율이 일정 기준을 넘으면 circuit breaker가 열려 더 큰 장애를 막습니다. 넷째, 운영자가 볼 로그와 사용자가 볼 메시지를 분리해 민감한 인증값이나 내부 연결 정보를 노출하지 않습니다.

이 주제는 특히 VIBE 코딩에 중요합니다. AI는 happy path를 매우 빠르게 만들지만, 제한 정책과 실패 정책은 요구하지 않으면 쉽게 빠뜨립니다. 결과적으로 기능은 “한 번 눌렀을 때”는 동작하지만, 사용자가 몰리는 시간대에는 느려지고, 재시도 폭풍이 생기고, 외부 서비스 장애를 내 서비스 장애로 증폭시킵니다. 이 글은 그런 상황을 막기 위한 실전 작업 순서입니다.

왜 중요한가

API 제한은 버그가 아니라 운영 조건이다

외부 서비스의 제한 응답은 이상한 예외가 아니라 정상적인 운영 조건입니다. 모델 호출, 검색 인덱스 조회, 이메일 발송, 메시지 알림, 결제 검증, 지도 검색 같은 기능은 모두 상대 서비스의 정책과 용량 안에서 움직입니다. 요청이 제한되면 코드가 틀렸다고만 볼 수 없습니다. 더 자주 발생하는 원인은 큐가 없이 즉시 호출하거나, 사용자의 연속 클릭을 막지 않거나, 실패한 작업을 모든 워커가 동시에 다시 시도하는 설계입니다.

AI가 만든 초안은 보통 “요청 → 성공 응답 → 화면 표시”에 집중합니다. 그러나 실제 제작 루프에서는 “요청 → 제한 응답 → 대기 → 재시도 → 부분 성공 → 사용자 안내 → 운영 로그 → 알림 → 중단 기준”까지 봐야 합니다. 이 흐름을 설계하지 않으면 작은 트래픽 변화가 바로 장애처럼 보입니다. 특히 자동화 에이전트가 여러 개 동시에 돌면 사람이 예상한 호출량보다 훨씬 빠르게 제한에 닿습니다.

재시도는 복구 장치이면서 장애 증폭 장치다

재시도는 위험합니다. 한 번 실패한 요청을 다시 보내면 성공할 수도 있지만, 실패 원인이 서비스 과부하라면 재시도는 상대 서비스와 내 서비스를 동시에 더 힘들게 만듭니다. 그래서 backoff가 필요합니다. 첫 재시도는 짧게, 다음 재시도는 더 길게, 그리고 모든 사용자가 같은 순간에 다시 보내지 않도록 작은 무작위 지연을 섞어야 합니다.

중요한 점은 재시도 횟수보다 재시도 의미입니다. 읽기 요청은 안전하게 다시 시도할 수 있는 경우가 많지만, 결제, 발송, 생성, 쓰기 요청은 중복 실행이 치명적일 수 있습니다. 이런 요청에는 멱등성 키, 작업 상태, 중복 제출 방지, 사용자 확인 메시지가 필요합니다. AI에게 “실패하면 세 번 다시 시도”라고만 지시하면 이런 차이가 사라집니다. 더 좋은 지시는 “읽기와 쓰기를 구분하고, 쓰기 요청은 중복 실행 방지 식별자를 사용하며, 제한 응답은 큐에 넣고 backoff로 처리하라”입니다.

비용과 신뢰는 호출 정책에서 결정된다

AI 기능은 호출 한 번이 비용이 될 수 있습니다. 실패한 요청을 무작정 다시 보내면 장애 대응이 곧 비용 폭주가 됩니다. 사용자는 “잠시 후 다시 시도해 주세요”라는 메시지를 이해할 수 있지만, 같은 작업이 몰래 여러 번 실행되거나 요금이 반복해서 발생하는 상황은 받아들이기 어렵습니다. 따라서 rate limit 루프는 성능 최적화가 아니라 비용 통제와 신뢰 설계입니다.

실무에서는 호출 정책을 기능 요구사항에 포함해야 합니다. 하루 예산, 사용자별 분당 호출 수, 작업별 최대 대기 시간, 재시도 횟수, 중단 기준, 관리자 승인 기준을 숫자로 정합니다. 숫자가 있어야 AI가 코드를 바꾸더라도 “더 나아졌는지” 판단할 수 있습니다. 예를 들어 “제한 응답 비율이 5분 동안 20%를 넘으면 새 자동 작업을 멈추고, 사용자가 직접 시작한 작업만 큐에 넣는다”처럼 기준을 적어야 합니다.

실제 작업 순서

1단계: 호출 지도를 만든다

먼저 기능이 어떤 외부 호출을 하는지 지도로 만듭니다. 화면 버튼, 서버 라우트, 백그라운드 작업, 예약 작업, 웹훅 수신, 알림 발송, 데이터 동기화가 각각 어떤 서비스를 호출하는지 적습니다. 호출마다 다음 항목을 표시합니다. 사용자 직접 요청인지, 자동 작업인지, 읽기인지 쓰기인지, 중복 실행이 안전한지, 제한 응답이 예상되는지, 실패해도 나중에 다시 해도 되는지, 즉시 실패를 보여 줘야 하는지입니다.

이 지도는 거창한 문서가 아니어도 됩니다. 작업 티켓이나 AI 지시서에 표로 넣으면 충분합니다. 중요한 것은 AI가 수정할 범위를 알게 하는 것입니다. “검색 기능이 느리다”는 지시보다 “검색 자동완성은 읽기 요청이고 500ms 안에 응답하지 않으면 로컬 최근 검색어를 보여 준다. 저장 버튼은 쓰기 요청이라 중복 실행을 막고 작업 상태를 남긴다”가 훨씬 안전합니다.

2단계: 제한 응답을 정상 경로로 테스트한다

제한 응답을 예외로만 두면 검증이 어렵습니다. 테스트에서는 외부 서비스를 실제로 과부하시키지 말고 응답을 흉내 내야 합니다. 제한 상태, 일시적 실패, 타임아웃, 성공 회복을 각각 시뮬레이션합니다. 화면은 로딩 표시, 대기 안내, 재시도 버튼, 결과 회복을 보여 줘야 합니다. 서버는 재시도 예약, 최대 횟수, 최종 실패 상태를 기록해야 합니다.

테스트 이름도 명확해야 합니다. “에러 처리 테스트”가 아니라 “제한 응답을 받으면 즉시 재호출하지 않고 다음 시도 시간을 저장한다”, “동일 작업이 대기 중이면 버튼 연타가 새 작업을 만들지 않는다”, “circuit breaker가 열린 동안 자동 작업은 중단되고 수동 작업은 대기 안내를 받는다”처럼 행동을 드러내야 합니다.

3단계: backoff 정책을 숫자로 고정한다

backoff는 감으로 정하면 흔들립니다. 예를 들어 첫 재시도는 5초 뒤, 두 번째는 20초 뒤, 세 번째는 1분 뒤, 네 번째는 5분 뒤로 늘립니다. 여기에 작은 jitter를 섞어 같은 시간에 몰리지 않게 합니다. 최대 재시도 횟수와 전체 대기 시간을 정하고, 그 이후에는 최종 실패 또는 수동 승인 상태로 넘깁니다.

숫자는 서비스 성격에 따라 달라집니다. 사용자 채팅 응답처럼 즉시성이 중요한 기능은 긴 대기보다 빠른 대체 안내가 낫습니다. 야간 데이터 동기화처럼 즉시성이 낮은 작업은 더 긴 backoff와 큐 대기가 허용됩니다. AI에게는 “모든 실패를 같은 정책으로 처리하지 말라”고 분명히 적어야 합니다. 사용자 인터랙션, 백그라운드 동기화, 비용이 큰 생성 작업을 구분해야 합니다.

4단계: circuit breaker와 대체 흐름을 만든다

circuit breaker는 “잠깐 그만 보내자”라는 운영 판단을 코드로 표현한 것입니다. 최근 실패율, 연속 제한 응답 수, 평균 응답 시간, 큐 길이, 비용 사용량 중 하나 이상이 기준을 넘으면 자동 호출을 멈춥니다. 멈춘 동안 사용자에게는 대기 안내, 저장된 결과, 수동 재시도, 알림 신청 같은 대체 흐름을 제공합니다.

중요한 점은 circuit breaker가 열렸을 때도 서비스 전체가 죽은 것처럼 보이면 안 된다는 것입니다. 가능한 화면은 계속 보여 주고, 문제가 있는 기능만 제한합니다. 예를 들어 AI 요약 생성이 막혔다면 원문 목록은 계속 보여 주고 “요약 생성이 지연 중입니다”라고 안내합니다. 데이터 저장은 성공했지만 알림 발송만 실패했다면 저장 성공과 알림 지연을 분리해 보여 줍니다.

5단계: 로그와 알림을 분리한다

운영 로그에는 호출 종류, 상태 코드 범주, 시도 횟수, 다음 시도 시간, 작업 식별자, 사용자 영향 범위, circuit breaker 상태가 필요합니다. 그러나 공개 화면이나 일반 사용자 메시지에는 내부 연결 정보, 인증 문자열, 원본 헤더, 공급자별 민감 값이 들어가면 안 됩니다. 사용자에게는 “요청이 많아 잠시 대기 중입니다. 저장된 작업은 순서대로 처리됩니다”처럼 행동 가능한 메시지를 줍니다.

알림도 단계가 있어야 합니다. 단발 제한 응답은 로그만 남기고, 5분 이상 지속되는 높은 실패율은 운영 알림을 보내며, 비용 한도 근접이나 쓰기 작업 중복 위험은 사람 승인으로 넘깁니다. AI에게 이 구분을 알려 주지 않으면 모든 실패를 같은 수준의 경고로 만들거나, 반대로 중요한 실패를 조용히 삼킬 수 있습니다.

상황별 예시

예시 1: AI 요약 버튼을 여러 사용자가 동시에 누르는 경우

문제 상황은 흔합니다. 게시글 목록에서 “AI 요약 만들기” 버튼을 눌렀는데, 여러 사용자가 같은 글에 대해 동시에 요청합니다. 단순 구현은 같은 원문을 여러 번 모델에 보내고, 제한 응답을 받으면 각 요청이 즉시 다시 시도합니다. 비용은 늘고 결과는 중복되며 사용자는 느리다고 느낍니다.

안전한 설계는 작업 키를 먼저 만듭니다. 같은 글과 같은 요약 옵션이면 하나의 작업으로 묶습니다. 이미 진행 중인 작업이 있으면 새 작업을 만들지 않고 기존 작업 상태를 보여 줍니다. 제한 응답이 오면 작업 상태를 “대기 중”으로 바꾸고 다음 시도 시간을 저장합니다. 사용자는 새로고침해도 같은 상태를 봅니다. 완료되면 모든 사용자가 같은 결과를 공유합니다.

이때 AI에게 줄 지시는 이렇게 씁니다. “동일 문서와 동일 옵션의 요약 요청은 하나의 작업으로 합쳐라. 진행 중 작업이 있으면 새 외부 호출을 만들지 말고 기존 작업 상태를 반환하라. 제한 응답은 실패가 아니라 대기 상태로 저장하고, 지수 backoff와 jitter로 다음 실행 시간을 계산하라. 사용자는 대기·완료·최종 실패를 구분해서 볼 수 있어야 한다.”

예시 2: 자동 동기화 작업이 밤에 몰리는 경우

예약 작업은 사람이 누르지 않아도 호출량을 만듭니다. 특히 여러 섹션을 동시에 동기화하거나, 실패한 작업을 다음 분에 모두 다시 실행하면 제한에 쉽게 닿습니다. 이 경우 사용자 화면은 조용하지만 서버와 외부 서비스는 계속 흔들릴 수 있습니다.

해결은 큐와 예산입니다. 섹션별 우선순위를 정하고, 한 번에 실행할 작업 수를 제한합니다. 실패한 작업은 원래 스케줄에 바로 얹지 말고 별도 재시도 큐로 보냅니다. 하루 호출 예산의 일정 비율을 넘으면 저우선 작업은 다음 창으로 미룹니다. 운영 로그에는 “몇 개가 성공했고, 몇 개가 대기 중이며, 어떤 기준 때문에 멈췄는지”가 남아야 합니다.

AI 지시서는 “동기화 함수를 빠르게 만들어라”가 아니라 “동시 실행 수, 작업 우선순위, 재시도 큐, 하루 예산, circuit breaker 상태를 포함한 실행 계획을 구현하라”여야 합니다. 자동화가 편해질수록 호출량이 보이지 않게 늘어나므로, 숫자로 보이는 통제 장치가 필요합니다.

예시 3: 쓰기 요청이 부분 성공하는 경우

가장 어려운 상황은 쓰기 요청의 부분 성공입니다. 예를 들어 사용자가 글을 저장했고, 그 뒤에 이미지 생성과 알림 발송이 이어집니다. 저장은 성공했지만 이미지 생성이 제한에 걸릴 수 있고, 알림 발송만 실패할 수도 있습니다. 단순 재시도는 저장을 다시 실행해 중복 데이터를 만들 위험이 있습니다.

이때는 작업을 단계로 나눕니다. 본문 저장, 이미지 생성, 알림 발송을 각각 별도 상태로 관리합니다. 본문 저장이 성공했으면 그 결과는 확정하고, 이미지 생성과 알림만 대기 또는 실패로 둡니다. 사용자에게는 “본문은 저장되었고 부가 작업이 지연 중입니다”라고 안내합니다. AI에게는 “전체 작업을 하나의 성공/실패로 뭉개지 말고 단계별 상태와 재시도 가능성을 분리하라”고 지시합니다.

실수와 주의점

이 루프에서 봐야 할 대표 실패 모드는 명확합니다. 무한 재시도, 중복 쓰기, 제한 응답 무시, 사용자 메시지 과노출, 큐 적체, 비용 급증, circuit breaker 우회입니다. 아래 항목은 AI가 만든 API 연동을 검토할 때 특히 자주 발견되는 문제입니다.

무한 재시도를 복구라고 착각한다

가장 흔한 실수는 실패하면 계속 다시 시도하는 것입니다. 무한 재시도는 복구가 아니라 장애 증폭입니다. 재시도에는 최대 횟수, 최대 대기 시간, 중단 기준, 최종 상태가 있어야 합니다. 특히 자동 작업은 사람이 보지 않는 동안 계속 돌 수 있으므로 더 엄격해야 합니다.

모든 요청을 같은 정책으로 처리한다

읽기 요청, 쓰기 요청, 비용이 큰 생성 요청, 사용자 직접 요청, 자동 백그라운드 요청은 위험이 다릅니다. 같은 backoff 함수를 쓰더라도 정책 값과 중단 기준은 달라야 합니다. 예를 들어 읽기 요청은 빠르게 대체 캐시를 보여 줄 수 있지만, 쓰기 요청은 중복 실행 방지와 단계 상태가 더 중요합니다.

사용자 메시지에 내부 사유를 과하게 노출한다

사용자는 “외부 공급자의 제한 코드”를 볼 필요가 없습니다. 사용자에게 필요한 것은 지금 무엇을 할 수 있는지입니다. 기다리면 되는지, 다시 눌러야 하는지, 저장은 되었는지, 알림을 받을 수 있는지입니다. 운영 로그에는 세부 사유가 필요하지만 공개 메시지는 행동 중심으로 써야 합니다.

성공 로그만 보고 안심한다

제한 루프는 성공 건수만 보면 위험합니다. 제한 응답 비율, 재시도 큐 길이, 평균 대기 시간, 최종 실패 수, circuit breaker 열린 횟수, 비용 사용량을 같이 봐야 합니다. 성공이 늘어도 대기 시간이 길어지고 비용이 급증하면 좋은 상태가 아닙니다.

AI에게 운영 숫자를 맡기지 않는다

AI는 그럴듯한 기본값을 만들 수 있지만, 운영 기준은 서비스 맥락에 따라 정해야 합니다. 무료 기능인지 유료 기능인지, 사용자가 기다릴 수 있는 시간인지, 실패가 데이터 손실로 이어지는지, 사람 승인이 가능한 시간대인지에 따라 숫자가 달라집니다. AI에게 숫자 후보를 제안하게 할 수는 있지만, 실제 적용은 운영 기준으로 승인해야 합니다.

검증 체크리스트

• 동일 사용자가 버튼을 여러 번 눌러도 외부 호출이 중복으로 폭주하지 않는가?
• 동일 리소스에 대한 같은 작업이 이미 진행 중이면 기존 작업 상태를 재사용하는가?
• 제한 응답을 받았을 때 즉시 재호출하지 않고 다음 시도 시간을 저장하는가?
• backoff 간격, jitter, 최대 재시도 횟수, 전체 대기 한도가 숫자로 정의되어 있는가?
• 읽기 요청과 쓰기 요청, 사용자 직접 요청과 자동 작업의 정책이 구분되어 있는가?
• 쓰기 요청에는 중복 실행 방지 식별자와 단계별 상태가 있는가?
• circuit breaker가 열렸을 때 자동 호출이 멈추고 사용자 화면은 안전한 대체 흐름을 보여 주는가?
• 운영 로그에는 시도 횟수, 상태 범주, 다음 시도 시간, 영향 범위가 남는가?
• 공개 메시지에는 인증 문자열, 내부 연결 정보, 원본 헤더 같은 민감 정보가 노출되지 않는가?
• 비용 한도, 실패율, 큐 길이 중 어느 기준에서 사람 승인이 필요한지 정해져 있는가?
• 테스트가 제한 응답, 타임아웃, 부분 성공, 회복 성공, 최종 실패를 모두 다루는가?
• 배포 후 대표 사용자 여정에서 콘솔 오류, 중복 요청, 공개 금지 문구가 없는지 확인했는가?

AI에게 줄 지시 예시

기능 구현 지시

목표: AI 요약 생성 API 호출에 rate limit 대응 루프를 추가한다. 정상 응답뿐 아니라 제한 응답, 일시적 실패, 타임아웃, 부분 성공을 테스트로 고정한다. 동일 문서와 동일 옵션의 요청은 하나의 작업으로 합치고, 진행 중 작업이 있으면 새 외부 호출을 만들지 않는다. 제한 응답은 대기 상태로 저장하고 지수 backoff와 jitter로 다음 시도 시간을 계산한다. 최대 재시도 횟수와 전체 대기 시간을 넘으면 최종 실패로 전환한다. 사용자 메시지는 행동 중심으로 쓰고, 운영 로그에는 상태 범주와 시도 횟수만 남긴다. 공개 화면에 민감한 인증값이나 내부 연결 정보가 보이지 않도록 스캔을 추가한다.

디버깅 지시

현재 증상: 피크 시간대에 AI 요약 버튼이 느려지고 같은 문서에 중복 요약 작업이 생긴다. 최근 로그에서는 제한 응답과 타임아웃이 섞여 있다. 먼저 호출 지도를 작성해 사용자 직접 요청, 자동 작업, 읽기 요청, 쓰기 요청을 분리하라. 중복 작업 생성 경로를 찾아 테스트로 재현하고, 같은 작업 키를 재사용하도록 수정하라. 그다음 제한 응답을 모의해 즉시 재시도가 발생하지 않는지 확인하라. 수정 범위는 요약 작업 생성과 재시도 스케줄링에 제한하고, 화면 디자인은 바꾸지 말라.

운영 점검 지시

배포 후 30분 동안 제한 응답 비율, 재시도 큐 길이, 평균 대기 시간, 최종 실패 수, circuit breaker 상태를 확인하라. 제한 응답 비율이 5분 평균 20%를 넘거나 재시도 큐가 100건을 넘으면 자동 작업을 멈추고 수동 요청은 대기 안내로 전환하라. 사용자 화면에는 저장 여부와 다음 상태만 보여 주고, 내부 사유나 민감한 연결 정보는 노출하지 말라. 점검 결과를 성공, 주의, 중단 필요 중 하나로 분류하라.

중단과 승인 기준

즉시 중단해야 하는 기준

다음 조건 중 하나라도 보이면 AI에게 추가 구현을 맡기기보다 호출을 멈추고 설계를 확인해야 합니다. 제한 응답 비율이 짧은 시간에 급증한다. 같은 작업이 여러 개 중복 생성된다. 쓰기 요청이 두 번 실행될 가능성이 있다. 재시도 큐가 줄지 않고 계속 늘어난다. 사용자 화면에 내부 오류 사유가 그대로 보인다. 비용 사용량이 예상보다 빠르게 증가한다. circuit breaker가 열렸는데도 자동 작업이 계속 외부 호출을 보낸다.

중단은 실패가 아닙니다. 중단 기준이 없으면 AI가 코드를 계속 바꾸며 상황을 더 복잡하게 만들 수 있습니다. 중단 기준은 “여기부터는 사람이 승인한다”는 안전선입니다. 특히 결제, 발송, 삭제, 데이터 변경, 비용이 큰 생성 작업은 자동 재시도보다 사람 승인 상태가 더 안전할 수 있습니다.

사람 승인이 필요한 기준

정책 숫자를 바꿀 때는 승인이 필요합니다. 예를 들어 최대 재시도 횟수를 늘리거나, 하루 호출 예산을 올리거나, circuit breaker 기준을 완화하거나, 사용자별 제한을 풀거나, 쓰기 요청을 자동 재시도하도록 바꾸는 결정은 기능 수정이 아니라 운영 정책 변경입니다. AI가 제안할 수는 있지만 자동으로 적용해서는 안 됩니다.

승인 요청은 짧고 구체적이어야 합니다. “재시도 정책을 바꿔도 될까요?”보다 “현재 최종 실패가 많아 두 번째 재시도 간격을 20초에서 45초로 늘리고 전체 대기 한도를 10분에서 20분으로 늘리려 한다. 예상 효과는 제한 응답 감소이고, 위험은 사용자 대기 시간 증가다”처럼 써야 합니다. 그래야 운영자가 선택할 수 있습니다.

다음 단계

작게 시작하려면 외부 호출이 있는 기능 하나를 고릅니다. 가장 좋은 후보는 사용자 버튼과 자동 작업이 동시에 존재하는 기능입니다. 그 기능에 대해 호출 지도, 제한 응답 테스트, backoff 숫자, circuit breaker 기준, 사용자 메시지, 운영 로그를 한 번에 정리합니다. 처음부터 모든 API를 통합 관리하려고 하면 범위가 커집니다. 하나의 기능에서 성공한 패턴을 만든 뒤 다른 호출로 확장하는 편이 안전합니다.

이미 서비스가 운영 중이라면 먼저 로그를 봅니다. 제한 응답, 타임아웃, 중복 작업, 긴 대기, 최종 실패가 어디에서 많이 나오는지 확인합니다. 그중 사용자 영향과 비용 영향이 큰 경로를 첫 개선 대상으로 잡습니다. VIBE 코딩의 장점은 AI가 코드를 빨리 고친다는 점이지만, 운영 루프의 장점은 AI가 고칠 범위와 멈출 기준을 알게 만든다는 점입니다. rate limit과 backoff를 설계하면 AI 연동은 데모 기능에서 운영 가능한 제품 기능으로 바뀝니다.