AI 활용기: AI가 만든 검사기를 일부러 망가뜨려봤다
표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.
자동 검사의 '통과' 메시지를 완료의 증거로 삼는 사람에게, 그 통과가 실제로 무엇을 막아냈는지 되짚어보게 한다.
9월 7일 감사에서 정상 입력 1건은 통과했지만, 일부러 망가뜨린 결함 사례 9건은 전부 차단되지 않았다. 검사 항목 수가 아니라 검사가 실제로 무엇을 차단하는지가 신뢰의 근거였다.
지금 쓰는 자동 검사에 정상 사례 하나, 필수 값을 뺀 사례 하나, 오래된 자료를 재사용한 사례 하나를 직접 넣어보고 몇 개가 걸러지는지 센다.
연재 목차
먼저 답하면
9월 8일 수정 전에는 기기가 실제로 회전하지 않아도 캡처 파일만 있으면 가로 화면 검사가 통과했다.
검사 통과라는 메시지를 받으면 안심하기 쉽다. AI가 구현하고 테스트까지 실행했다면 더 그렇다. 앱 공장을 점검하면서는 반대로 잘못된 입력도 정말 막히는지 보게 됐다.
9월 7일 감사 문서는 정상 사례와 별개로 의도적인 결함을 넣은 시험을 정리했다. 자동 검사를 빼거나 통과 조건을 지우고, 필요한 산출물을 제거하는 식이었다. 초기 결과는 정상 사례 한 건이 통과했고 결함 사례 아홉 건은 차단되지 않았다고 적혀 있다. 당시 보고값이며 지금 다시 실행한 결과는 아니다.
항목이 많은 것만으로는 부족했다
검사 정의를 바꿔도 넘어갈 수 있거나 오래된 진행표를 그대로 인정하면, 검사가 많아도 빠져나갈 곳이 생긴다. 이후에는 정의 비교와 오래된 자료 확인, 원본 변경 감지 등을 보완했다.
화면 검사에서도 비슷한 문제가 있었다. 9월 8일에는 실제로 화면이 회전한 뒤 캡처를 판단하도록 수정했다. 가로 화면을 찍으라고 요청했더라도 기기가 회전하지 않았다면 파일이 있다는 사실만으로는 부족하다.
맞지 않는 기기를 지정했을 때 조용히 다른 기기로 대체하는 동작을 막은 기록도 있다. 검사를 실행했다는 것과 원하는 조건에서 실행했다는 것이 달랐다.
이후 보완이 버그가 하나도 없다는 보증은 아니다. 이미지 해시가 변경을 잡아도 화면이 편한지까지 판단하지는 못한다.
다음 자동화에서는 정상 사례를 통과시키는 것과 함께 대표적인 실패도 먼저 넣어보려 한다. AI가 만든 테스트도 확인할 대상이었다. 파일 존재, 실행 상태, 실제 행동, 사용성은 각각 무엇으로 확인할지 나눠야 했다.
검사기를 확인하는 세 가지 입력
자동 검사에는 정상 사례, 필수 값이 없는 사례, 오래된 자료를 재사용한 사례를 넣어볼 수 있다. 셋이 모두 통과하면 검사기가 실제 조건을 보고 있는지 의심해야 한다. 격리된 시험 복사본에서 한 결함씩 넣고 어떤 검사에서 멈췄는지 기록한다.
예를 들어 캡처 검사는 파일 존재만 볼 수도 있다. 이미지 크기가 맞지 않거나 목표 화면이 아닌 파일을 넣었을 때도 통과하는지 따로 본다. 후자는 사람의 화면 확인이나 더 구체적인 장면 검증이 필요할 수 있다. 해시 하나로 사용성을 판단할 수는 없다.
정상 사례를 먼저 보존해야 결함 시험으로 검사기 자체가 망가진 것도 알 수 있다. 마지막에는 정상 입력을 다시 통과시킨다. 이 방법은 통과 항목 수보다 검사가 무엇을 차단하는지 설명하는 데 도움이 되며, 제품 원본을 일부러 손상할 필요는 없다.
← 이전 글: 앱 공장을 여러 개 만들다가 하나로 합쳤다 · 전체 목차 · 다음 글: 앱과 서버를 따로 만들었더니 데이터 이름부터 달랐다 →