앱이 안 될 때 AI에게 무엇을 보여줘야 할까?

메모 앱에 수량 0을 넣었더니 저장되지 않는 상황을 가정해 보자. 오류 화면을 보내자 AI가 “입력 검증 문제 같습니다”라고 답한다. 이는 원인 후보다. “고쳤습니다”라는 답도 실제 변경과 재현 확인이 따르기 전에는 수리 주장에 머문다.

그렇다면 어떤 기록을 보태야 할까? 이를 알아보려 오류 보고 세 종류를 비교할 준비를 했지만, 진단 대상 모델을 실행한 측정은 한 번도 하지 않았다. 추가 비용 없는 실행 경로와 AI가 정답을 미리 보지 못하게 하는 격리 등을 확인하지 못했기 때문이다. 이 글은 준비 과정에서 확인한 것과 중단 이유, 효과를 측정하지 않은 보고·검증 제안을 다룬다. 어느 방식이 더 빠르거나 정확한지, 최소 몇 항목이면 충분한지는 밝혀내지 못했다.

이 글의 목차

먼저, 다시 확인할 수 있는 보고를 만든다

Claude Code의 공식 오류 수정 안내는 오류, 재현 방법, 오류가 난 호출 경로 기록(스택 트레이스), 간헐적으로 발생하는지 등을 함께 제공하도록 권한다. 이는 작업 지침이지, 각 항목의 효과를 측정한 결과는 아니다. 오류 수정 안내

아래 양식은 검증된 최소 항목이 아닌 편집상 제안이다. 독자나 진단 대상 모델에게 시험하지 않았고, 각 줄이 진단에 도움이 되는지도 측정하지 않았다. 계획에서도 시각·작업명·코드·ID는 한 묶음이어서 개별 효과를 알 수 없다. 정보가 많다고 진단이 나아진다고 가정하지 않는다.

외부에 보내기 전에 로컬 메모에서 작성한다. 이 글의 선별 규칙으로 비밀번호·토큰·개인정보·서버에 보내는 데이터인 요청 본문은 제외한다. 개발자 콘솔의 전체 내용, 로그 파일, 네트워크 기록인 HAR, 설정 파일인 .env, 대화 이력도 통째로 붙이지 않는다. ‘민감정보 제거됨’이라는 표시만으로 안전한 자료라고 볼 수는 없다. 별도로 OWASP는 접근 토큰과 비밀번호 등 민감한 값의 직접 기록을 피하고 로그를 검사하도록 안내한다. 로그 작성 지침 이는 로그 작성 지침이며, AI에 보낼 내용을 더 좁게 고르는 규칙은 이 글의 제안이다.

한 일: 어떤 화면에서 무엇을 입력하고 눌렀는가?
기대한 결과 / 실제 결과:
다시 발생시키는 순서 / 항상 발생하는가:
화면의 오류 문구: 안전한 부분의 원문 그대로
관련 화면: 배치·색·빈 화면 등이 문제일 때 첨부
발생 시각: 몇 시 몇 분, 시간대, 내 시계 기준인지 앱 기록인지
관련 기록: 앱 화면이나 기록에 보이는 경우에만 작업명·오류 코드·이벤트 ID
이미 시도한 일:
요청: 근거가 부족하면 모른다고 말하고, 원인 후보·아직 모르는 점·후보를 반박할 확인 방법을 제시해 주세요. 실제로 하지 않은 소스 확인·실행·수리를 했다고 주장하지 마세요.

보낼 텍스트와 이미지의 픽셀을 직접 살펴본다. 쿠키·인증 값·URL 쿼리·로컬 경로를 포함하지 않고, 화면의 브라우저 테두리·사용자명·다른 창도 확인한다. 이미지는 필요한 부분만 자르고 일반적인 파일명을 쓰며, 파일에 붙은 부가 정보인 메타데이터도 제거·확인한다. 호출 경로 기록이 필요하면 민감정보를 확인·제거한 관련 한 줄만 고른다. 안전하게 공유할 수 있는지 판단하기 어려우면 제외한다. 지운 자리에는 [삭제]처럼 원문과 구분되는 표시를 쓴다. 삭제로 의미가 달라지거나 표시 자체의 안전성이 불확실하면 해당 줄 전체를 제외한다. 남긴 안전한 원문은 임의로 번역하지 말고 설명을 옆에 붙인다. 이 절차가 모든 민감정보 제거를 보장하지는 않는다.

기록이 없으면 “관련 기록 없음”이라고 적으면 된다. 코드나 ID를 만들어 채우지 않는다. ID는 같은 표식이 붙은 기록을 맞춰 보는 데 쓰이며 원인을 뜻하지 않는다. 뒤에서 설명할 C 보고에는 각각 합성 사건 하나만 있으므로 기록 연결이나 ID의 효과를 시험한 것은 아니다. 이 로컬 ID는 W3C 추적 ID나 traceparent가 아니다. W3C의 Trace Context 규격은 traceparent와 tracestate에 개인정보·민감정보를 넣지 못하게 하며, 여러 구성요소의 추적 기록을 연결할 때 생기는 개인정보 위험도 다룬다. ID 자체에 개인정보가 없어도 연결 위험은 있을 수 있다. Trace Context

“고쳤다”는 답 다음에 확인할 것

준비한 0 입력 오류에서 배울 수 있는 것은 확인 절차다. 0이 거부됐다는 관찰만으로는 ‘0을 빈 값처럼 처리했다’와 ‘0을 금지했다’를 구별할 수 없다. AI의 설명과 별개로 실제 변경 전후 코드에서 거부 조건을 확인해야 한다. 코드를 읽기 어렵다면 바뀐 부분의 전후 내용을 그대로 보여 주고 어느 줄이 0을 거부했는지 짚어 달라고 요청하는 것을 제안한다. 그 설명도 실제 변경과 대조해야 하며, 아래 동작 확인만으로 내부 원인을 증명할 수는 없다.

수정 전에 기대 동작과 확인 항목을 정해 보존한다. AI가 수정 뒤에 만든 검사만으로 수리를 판정하지 않는다. 아래 목록은 이 0 입력 오류의 동작 확인 항목이다. 실제 변경 전체에서 다른 거부 경로가 남았는지, 검사나 오류 보고를 지우지 않았는지도 확인한다.

그다음 같은 입력 순서로 0이 저장되는지, 양수도 저장되는지, 음수와 숫자가 아닌 값은 여전히 거부되는지 각각 확인한다. 저장 내용을 다시 열어 보고 기존 메모가 남았는지도 살핀다. 이런 항목은 준비한 로컬 검사에 포함됐지만, AI가 만든 수정본을 검증한 결과는 아니다. 원인을 알고 되돌린 준비 작업을 모델의 수리로 바꿔 말할 수 없다.

모의 시간 초과 오류에는 별도 기준이 필요하다. 원래 계약의 120ms 허용 시간을 지키며 80ms 결과를 한 번 저장하고, 121ms 결과는 시간 초과로 처리하며 늦은 결과를 저장하지 않아야 한다. 저장 오류는 불필요한 데이터만 제거하고 4096바이트 한도를 유지해야 하며, 필요한 데이터 자체가 한도를 넘으면 기존 내용을 지우지 않고 실패해야 한다. 한도를 임의로 늘려 통과시키는 것은 이 계약의 수리가 아니다.

비교하려면 무엇을 같게 해야 할까?

준비한 앱은 메모의 입력 확인, 미리보기, 로컬 파일 저장을 수행한다. 정상본과 한 줄씩 다른 오류본 세 개를 만들었다. 0을 빈 값처럼 거부하는 오류, 모의 처리 시간을 너무 짧게 허용하는 오류, 불필요한 데이터를 붙여 시험용 저장 한도를 넘기는 오류다. 실제 통신 장애나 브라우저 저장 한도를 시험한 것은 아니다.

세 조건 모두 같은 재현 순서와 기대·실제 결과를 받도록 설계했다. A도 공통 설명에 이미지를 더하는 조건이다.

준비한 화면 문구는 모두 The operation could not be completed.였다. 0 입력 사례의 C에는 validateNote와 INPUT_REJECTED가 들어간다. AI가 이 코드를 보고 “입력 단계에서 거부됐다”고 되풀이하더라도 내부의 잘못된 조건을 찾아냈다고 볼 수는 없다. C의 읽기 쉬운 작업명과 코드는 실패 단계 식별에 유리하도록 만들어졌다. 다른 두 오류의 표식은 loadPreview / OP_TIMEOUT, persistNote / LOCAL_WRITE_FAILED다. 계획된 채점에서는 표식을 되풀이하면 단계 점수는 받을 수 있지만 원인 점수는 받을 수 없다. 시각이나 ID 각각의 효과도 분리하지 못한다.

OP_TIMEOUT만으로는 허용 시간이 너무 짧은지 작업 자체가 느린지 구별할 수 없고, LOCAL_WRITE_FAILED도 불필요한 데이터가 저장 한도를 넘겼다는 원인을 알려주지 않는다. 코드는 확인할 단서일 뿐이다. 이 코드들이 근거 없는 주장을 줄이는지는 측정하지 않았다.

모의 시간 초과 사례의 A 자료는 저장 실패 사례의 A 자료와 같고, B도 두 사례에서 같다. 두 보고 모두 기존 합성 메모가 있는 새 로컬 앱에서 Demo note와 수량 1을 입력하고 Preview and save once를 선택하도록 한다. 기대 결과는 새 메모가 다시 열어도 남고 기존 메모도 유지되는 것이며, 실제 결과는 실패 화면과 새 메모의 저장 실패로 같다. 0 입력 사례와 달리 이 두 사례는 재현 설명까지 같으므로 A나 B만으로는 원리상 둘을 구별할 수 없다. 미리보기와 저장을 한 동작으로 묶고 실패 단계를 감춘 준비 자료의 한계이지, 모든 오류 보고의 한계는 아니다. A/B는 단색 문자 화면의 전달 형식만 비교하는 보조 조건이며, 배치나 색이 핵심 증거인 오류를 시험하지 않았다.

계획은 같은 진단 모델로 오류 3개 × 조건 3개 × 새 세션에서 같은 사례를 두 번씩 반복, 총 18회였다. 매번 새 세션에서 정답·소스·이전 답변을 볼 수 없어야 했다. 실패 단계와 구체적 원인을 구분해 평가하고, 실제 소스를 주는 수리 예제는 사전에 정한 한 건으로 따로 두었다. 소스 열람까지 포함하면 처음 보고 자료만의 비교가 달라지기 때문이다. 이 계획은 실행되지 않았다.

18회를 마쳤더라도 한 모델로 고정된 합성 오류 세 개를 반복한 것일 뿐, 서로 독립적인 실제 오류 표본은 아니다. 전체 오류에 대한 정확도나 통계적 유의성, 다른 앱·모델의 성능, 추가 항목 각각의 효과, 최소 충분 항목 수는 알 수 없다. C는 정보뿐 아니라 길이도 늘어 그 영향을 분리할 수 없고, 답변에 이미지나 로그가 언급되면 채점자가 조건을 완전히 모르게 할 수도 없다. 소스·정답·이전 답변에 대한 접근 차단을 확인하지 못하면 처음 보고만의 비교도 성립하지 않는다. 이 글은 내부 원인을 공개하므로 후속 눈가림 실험은 자료와 세션 분리 설계를 다시 검토해야 한다.

준비에서 확인한 것, 끝내 확인하지 못한 것

2026년 10월 10일에는 오프라인 테스트 12개가 통과했다. 이 검사들은 정상본·오류본·원상복구, 저장 후 다시 읽기, 기존 메모 보존 등을 확인했다. 가짜 비밀값을 심어 내보내기를 거부하는 로컬 합성 검사도 포함했다. 실제 모델로 전송하는 시험이 아니며, 실제 로그·임의의 비밀값·이미지 픽셀·메타데이터를 안전하게 익명화한다는 증명은 아니다.

같은 날 만든 이미지의 문구 일치를 확인했고, 가짜 비밀값을 넣은 이미지는 검토자가 직접 살펴본 뒤 전송 대상에서 제외했다고 기록했다. 그러나 이후 파일 접근과 외부 통신을 제한한 환경에서의 캡처는 실패했다. 과거 이미지나 로컬 검사로 나중에 실패한 캡처 경로의 검증을 대신할 수 없었다.

10월 18일 독립 검토에서는 준비 도구의 오프라인 테스트 77개가 통과했다. 77개는 그 검토에서 센 별도 묶음이며 앞선 12개와 더할 누적 성적이 아니다. 그래도 검토의 판정은 실행 준비 미완료였다. 시험 도구가 시작한 프로그램이 별도로 분리되어 백그라운드에 남아도 확실히 종료할 수 있는지, 기존 구독으로 실행되는지, AI가 정답이나 다른 도구에 접근하지 못하는지, 남은 사용량과 추가 비용 없는 경로가 확인되는지는 해결되지 않았다. 제한된 환경에서의 화면 캡처도 남아 있었다.

시간을 더 쓴다고 이 근거가 저절로 생기지는 않는다. 10월 25일 운영 결정으로 측정을 진행하지 않고 방법론 글로 범위를 정했다. 18회 진단과 예정된 모델 수리 모두 미실행이다. 오프라인 테스트 통과 수는 AI의 진단 성적이 아니다.

독자가 가져갈 제안은 간단하다. 재현 순서와 안전하게 고른 증거를 남기고, AI의 원인 후보를 확인할 방법을 요청한다. 실제 변경과 재현 결과는 별도로 기록한다. 화면 배치나 색이 문제라면 관련 시각적 맥락도 남기는 편이 좋다. 이번 문자 중심 오류 화면 설계로 스크린샷의 일반적인 가치를 판단할 수는 없다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.