AI 비교AI 찾기AI 뉴스AI 활용
회사 소개
개인정보처리방침이용약관FAQ문의하기문의하기
에이아이비 주식회사사업자정보
© 2026 AIB Inc.

오류 허용 AI 시스템 디버깅

오류 허용 AI 시스템 디버깅

DEV.to·2026년 9월 13일 (일)
  • •GoodBarber 엔지니어는 70문단 런타임 실패 원인이 모델이 아니라 60초 캐시였다고 추적했다
  • •4월 이후 날짜가 기록된 10건의 사고에서 모델 직접 원인은 1건이었고, 하네스와 캐시 문제가 반복됐다
  • •9월 3일 테스트에서 create-read-read-delete-list-read 뒤 삭제된 객체가 50번 중 50번 다시 반환됐다
  • •GoodBarber 엔지니어는 70문단 런타임 실패 원인이 모델이 아니라 60초 캐시였다고 추적했다
  • •4월 이후 날짜가 기록된 10건의 사고에서 모델 직접 원인은 1건이었고, 하네스와 캐시 문제가 반복됐다
  • •9월 3일 테스트에서 create-read-read-delete-list-read 뒤 삭제된 객체가 50번 중 50번 다시 반환됐다
  • •GoodBarber 엔지니어는 70문단 런타임 실패 원인이 모델이 아니라 60초 캐시였다고 추적했다
  • •4월 이후 날짜가 기록된 10건의 사고에서 모델 직접 원인은 1건이었고, 하네스와 캐시 문제가 반복됐다
  • •9월 3일 테스트에서 create-read-read-delete-list-read 뒤 삭제된 객체가 50번 중 50번 다시 반환됐다
  • •GoodBarber 엔지니어는 70문단 런타임 실패 원인이 모델이 아니라 60초 캐시였다고 추적했다
  • •4월 이후 날짜가 기록된 10건의 사고에서 모델 직접 원인은 1건이었고, 하네스와 캐시 문제가 반복됐다
  • •9월 3일 테스트에서 create-read-read-delete-list-read 뒤 삭제된 객체가 50번 중 50번 다시 반환됐다

GoodBarber 엔지니어링 리드 피에르-로랑 메도리(Pierre-Laurent Medori)는 자신이 작성한 상태 기반 런타임이 초안 1개에 문단 1개를 만들어야 했지만 70문단을 생성했다고 밝혔다. 해당 런타임은 모델에 작업 명세, 작은 JSON 객체, 마지막 관찰값만 제공했으며, 읽기 검증이 끝나야 작업 완료로 간주한다는 규칙을 뒀다. 매 문단 뒤 읽기 검증에서 문단이 없다고 나오자 모델은 다시 문단을 만들었다.

메도리는 처음에는 모델을 의심했지만, 읽기 검증 크기에서 742바이트가 25번 연속 반환된 뒤 131,991바이트가 한꺼번에 반환된 사실을 확인했다. 문단 목록은 수명 60초짜리 캐시에서 나온 것이었다. 그는 모델이 런타임 지시를 따랐고, 런타임의 자체 읽기 경로가 두 번의 읽기 순서 때문에 오래된 정보를 줬다고 결론냈다.

메도리는 디버깅 방법을 3가지 질문으로 정리했다. 시스템이 무엇을 틀려도 되는지, 어느 계층이 틀렸는지, 오류가 얼마나 오래 살아남았는지다. 그는 자신의 표가 MCP 서버, 7개 블로그에 글을 쓰는 콘텐츠 에이전트, 정오 운영 리뷰와 2건의 코드 리뷰 및 용어집 감시자를 포함한 예약 작업에서 허용 가능한 실패와 절대 허용되지 않는 실패를 나눴다고 말했다. 이 표는 고정된 리뷰 루틴이 없었고, 적어 둔 “절대 허용 불가” 사례의 절반에는 감지기가 없었다는 2가지 약점도 드러냈다.

4월 이후 메도리는 자신의 시스템에서 발생한 10건의 사고에 날짜를 붙였다. 여기에는 4월 10일부터 14일까지 액세스 토큰이 300초로 설정된 일, 4월 8일부터 8월 5일까지 앱별 세션 상한으로 정상적인 429가 발생한 일, 6월 에이전트들이 7개 라이브 블로그에서 46문단을 훼손한 일, 6월 5일부터 22일까지 도구 스키마 변경으로 도구 1개가 17일간 숨겨진 일, 7월 29일과 31일 제한 없는 Redis 풀이 10,000클라이언트에 도달해 3,650연결을 거부한 일이 포함됐다. 10건 중 모델이 직접 원인이었던 사고는 1건뿐이었다. 6월 3일부터 9월 2일까지 5개 앱에서 존재하지 않는 34개 도구로 125회 호출한 사례였다.

메도리는 대화 기록을 증거가 아니라 목격자로 봐야 한다고 말했다. 대화 기록은 실제로 무슨 일이 일어났는지가 아니라 모델이 무엇을 보고 말했는지를 기록하기 때문이다. 2026년 9월 3일, 그는 테스트 앱에서 create-read-delete-read 주기를 50번 실행했다. 삭제 직후 읽기는 여전히 객체를 50번 중 3번 반환했고, 생성 읽기 1번은 새 글을 찾지 못했다. 더 현실적인 순서인 create, read, read, delete, list, read에서는 삭제된 객체가 50번 중 50번 반환됐고, 중앙값 61.1초, 최대 61.2초 동안 남아 있었다.

같은 테스트는 8월 티켓 3건도 확인했다. 삭제는 `deleted`, `id`, `status` 없이 정책 봉투만 반환했다. `cms_create_article`은 여전히 기본값이 `published`였다. 생성 검증 힌트는 읽기 도구를 알파벳순으로 나열했지만, 도구 계획은 검증을 `cms_list_cms_sections`로 향하게 했다. 메도리는 그 계획을 따르면 섹션 목록으로 글을 검증하게 된다고 말했다.

메도리는 오류율보다 감지까지 걸리는 시간이 더 중요하다고 주장했다. 그의 사례에는 삭제 후 오래된 읽기가 매번 61초 동안 남은 일, 8일치 로그를 121로 읽은 뒤 잘못된 부속 보고서가 몇 시간 지속된 일, 17일간 보이지 않았던 도구, 6월 이후에도 남아 있는 빈 프랑스어 초안, 8월 8일, 9일, 15일, 16일의 운영 리뷰 4건 누락이 첫 누락 기준 26일간 발견되지 않은 일, 존재하지 않는 도구 호출 125건이 CSV 내보내기로 드러나기 전까지 92일간 살아남은 일이 포함됐다.

메도리는 디버거 자체도 비결정적일 수 있다고 경고했다. 그의 첫 E2 검증기는 모든 프랑스어 본문을 영어 길이 1로 나눠 올바른 초안 6개를 실패 처리했다. 8월 12일 생성된 클라우드 용어집 감시자는 실행 때마다 자체 검사기를 다시 썼고 2번 실행됐으며 둘 다 녹색이었다. 그는 8월 17일 이를 버전 관리 아래 둔 고정 스크립트, 22개 음성 테스트 사례, 양성 대조군으로 교체했다. 이후 보고서 4건은 170페이지에서 녹색이었고, 각각 89초에서 166초가 걸렸다. 9월 3일 temperature 0에서 동일한 번역 호출 20번은 서로 다른 출력 1개를 만들었고, 결정적 검사 8개는 주입된 결함 6개를 모두 잡아냈으며, 바뀐 URL은 정확히 검사 1개에 걸렸다.

GoodBarber 엔지니어링 리드 피에르-로랑 메도리(Pierre-Laurent Medori)는 자신이 작성한 상태 기반 런타임이 초안 1개에 문단 1개를 만들어야 했지만 70문단을 생성했다고 밝혔다. 해당 런타임은 모델에 작업 명세, 작은 JSON 객체, 마지막 관찰값만 제공했으며, 읽기 검증이 끝나야 작업 완료로 간주한다는 규칙을 뒀다. 매 문단 뒤 읽기 검증에서 문단이 없다고 나오자 모델은 다시 문단을 만들었다.

메도리는 처음에는 모델을 의심했지만, 읽기 검증 크기에서 742바이트가 25번 연속 반환된 뒤 131,991바이트가 한꺼번에 반환된 사실을 확인했다. 문단 목록은 수명 60초짜리 캐시에서 나온 것이었다. 그는 모델이 런타임 지시를 따랐고, 런타임의 자체 읽기 경로가 두 번의 읽기 순서 때문에 오래된 정보를 줬다고 결론냈다.

메도리는 디버깅 방법을 3가지 질문으로 정리했다. 시스템이 무엇을 틀려도 되는지, 어느 계층이 틀렸는지, 오류가 얼마나 오래 살아남았는지다. 그는 자신의 표가 MCP 서버, 7개 블로그에 글을 쓰는 콘텐츠 에이전트, 정오 운영 리뷰와 2건의 코드 리뷰 및 용어집 감시자를 포함한 예약 작업에서 허용 가능한 실패와 절대 허용되지 않는 실패를 나눴다고 말했다. 이 표는 고정된 리뷰 루틴이 없었고, 적어 둔 “절대 허용 불가” 사례의 절반에는 감지기가 없었다는 2가지 약점도 드러냈다.

4월 이후 메도리는 자신의 시스템에서 발생한 10건의 사고에 날짜를 붙였다. 여기에는 4월 10일부터 14일까지 액세스 토큰이 300초로 설정된 일, 4월 8일부터 8월 5일까지 앱별 세션 상한으로 정상적인 429가 발생한 일, 6월 에이전트들이 7개 라이브 블로그에서 46문단을 훼손한 일, 6월 5일부터 22일까지 도구 스키마 변경으로 도구 1개가 17일간 숨겨진 일, 7월 29일과 31일 제한 없는 Redis 풀이 10,000클라이언트에 도달해 3,650연결을 거부한 일이 포함됐다. 10건 중 모델이 직접 원인이었던 사고는 1건뿐이었다. 6월 3일부터 9월 2일까지 5개 앱에서 존재하지 않는 34개 도구로 125회 호출한 사례였다.

메도리는 대화 기록을 증거가 아니라 목격자로 봐야 한다고 말했다. 대화 기록은 실제로 무슨 일이 일어났는지가 아니라 모델이 무엇을 보고 말했는지를 기록하기 때문이다. 2026년 9월 3일, 그는 테스트 앱에서 create-read-delete-read 주기를 50번 실행했다. 삭제 직후 읽기는 여전히 객체를 50번 중 3번 반환했고, 생성 읽기 1번은 새 글을 찾지 못했다. 더 현실적인 순서인 create, read, read, delete, list, read에서는 삭제된 객체가 50번 중 50번 반환됐고, 중앙값 61.1초, 최대 61.2초 동안 남아 있었다.

같은 테스트는 8월 티켓 3건도 확인했다. 삭제는 `deleted`, `id`, `status` 없이 정책 봉투만 반환했다. `cms_create_article`은 여전히 기본값이 `published`였다. 생성 검증 힌트는 읽기 도구를 알파벳순으로 나열했지만, 도구 계획은 검증을 `cms_list_cms_sections`로 향하게 했다. 메도리는 그 계획을 따르면 섹션 목록으로 글을 검증하게 된다고 말했다.

메도리는 오류율보다 감지까지 걸리는 시간이 더 중요하다고 주장했다. 그의 사례에는 삭제 후 오래된 읽기가 매번 61초 동안 남은 일, 8일치 로그를 121로 읽은 뒤 잘못된 부속 보고서가 몇 시간 지속된 일, 17일간 보이지 않았던 도구, 6월 이후에도 남아 있는 빈 프랑스어 초안, 8월 8일, 9일, 15일, 16일의 운영 리뷰 4건 누락이 첫 누락 기준 26일간 발견되지 않은 일, 존재하지 않는 도구 호출 125건이 CSV 내보내기로 드러나기 전까지 92일간 살아남은 일이 포함됐다.

메도리는 디버거 자체도 비결정적일 수 있다고 경고했다. 그의 첫 E2 검증기는 모든 프랑스어 본문을 영어 길이 1로 나눠 올바른 초안 6개를 실패 처리했다. 8월 12일 생성된 클라우드 용어집 감시자는 실행 때마다 자체 검사기를 다시 썼고 2번 실행됐으며 둘 다 녹색이었다. 그는 8월 17일 이를 버전 관리 아래 둔 고정 스크립트, 22개 음성 테스트 사례, 양성 대조군으로 교체했다. 이후 보고서 4건은 170페이지에서 녹색이었고, 각각 89초에서 166초가 걸렸다. 9월 3일 temperature 0에서 동일한 번역 호출 20번은 서로 다른 출력 1개를 만들었고, 결정적 검사 8개는 주입된 결함 6개를 모두 잡아냈으며, 바뀐 URL은 정확히 검사 1개에 걸렸다.

원문 보기 (영어)·2026년 9월 11일
#debugging#observability#mcp#runtime#cache#read back#redis#json ld#agents#deterministic checks