기능이 많아질수록 소개 문구보다 검증 장부가 중요해졌다. 메뉴에 이름이 생겼다는 것과 실제 계정에서 그 일을 끝냈다는 것은 다르기 때문이다. 플러그인의 등록 구조는 앞에서 설명했다. 이번에는 그 목록을 고객에게 어느 수준까지 된 기능이라고 말할지 판단하는 제작자의 기록 방법을 다룬다.
하나의 수에는 하나의 단위를 붙인다
현재 문서에는 ChatGPT26개와 Gemini27개 기능군이 있다. 이는 공통 등록한 기능의 분류이지 실제 서비스의 모든 옵션을 끝까지 실행한 여정 수가 아니다. 기능군 하나에 질문·모델 선택·첨부·읽기 같은 여러 경로가 연결될 수도 있다. 목록 길이를 성공 횟수로 옮기면 단위부터 달라진다.
나는 장부에서 정의 수, 실제 시험 수와 대상 기능을 따로 적어야 한다고 봤다. 한 시험이 여러 기능을 건드려도 그것을 각 열에 적는 것과 총합을 중복해서 더하는 것은 다르다. 소개 페이지의 큰 숫자를 만들기보다 어떤 질문에 어떤 근거로 답할 수 있는지 먼저 보이게 하는 편이 향후 수정에도 유리하다.
연결된 절차와 계정에서 제공하는 기능은 다르다
일반 고급 메뉴는 실제로 읽은 화면 순서를 프로젝트 절차로 저장해 사용할 수 있다. 그렇다고 어느 계정에서나 같은 메뉴가 있다는 뜻은 아니다. 계정의 제공 범위와 현재 화면, 제한 응답이 달라지면 미지원이나 미검증으로 남겨야 한다. 공통 입력 칸이 존재한다고 서버 기능까지 생기지 않는다.
문서의 등록·화면 열기·요청 전달·답변 생성·파일 저장 구분이 이때 도움이 된다. 각 단계에 별도의 결과를 붙이면 메뉴까지만 열린 기능을 완료한 업무로 소개하는 일을 피할 수 있다. 프로그램의 입력 계약을 확인한 근거와 실제 서비스가 그 입력을 받아 처리한 근거를 같은 체크표시로 합치지 않았다.
근거에는 버전과 경로를 함께 적는다
최종 파일 선택 수리는 독립 HTTP 수신으로 확인했어도 같은 최종판으로 실제 서비스에 다시 올리지 않았다면 두 사실을 그대로 쓴다. 예전 버전의 실제 ZIP 읽기·이미지 생성 근거를 최신판 전체 성공으로 복사하지 않는다. 직접 페이지 API로 성공한 흐름을 플러그인 새 실행 성공으로 옮기지도 않는다.
이 구분은 실패를 과장하려는 것이 아니라 다음에 무엇을 확인할지 정확히 찾기 위한 것이다. 수정이 선택 증명에만 영향을 줬는지, 전송과 서버 처리까지 바꿨는지에 따라 필요한 재시험이 달라진다. 같은 서비스 이름보다 실행 버전·진입 경로·실제 확인 단계를 더 중요한 근거 키로 삼았다.
내부 호출0회도 측정한 범위에서만 쓴다
실행기의 modelCalls가0이면 프로그램 내부 모델을 호출하지 않았다는 뜻이다. 외부 Codex 대화나 웹서비스의 답변·이미지 생성 사용량이0이라는 뜻은 아니다. 수치의 이름만 보고 전체 비용이나 효율로 바꾸면 운영 판단이 잘못된다.
같은 이유로 모델 검수의 생성 판단을 시험 통과 수에 넣지 않는다. 후속 문서에는 계층별 근거와 미완료 범위를 함께 남기며 실제 재현과 국소 수정, 독립 시험을 구별한다. 성공한 수를 세는 일보다 무엇을 세었는지 유지하는 일이 어렵고 중요했다. 검증 수치가 커져도 그 바깥의 실제 업무까지 확인했다는 뜻으로 넓히지 않는다.
검증 장부는 다음 질문을 만드는 도구다
고객이 영상 생성도 되느냐고 물으면 등록된 영상 기능명만 보여 주는 것으로 끝내지 않는다. 해당 계정에서 요청했는지, 생성 불가 응답인지, 새 영상이 준비됐는지와 실제 파일을 저장했는지를 찾아야 한다. 제공자의 거절을 받은 사실도 유용한 결과이지만 생성 성공은 아니다.
이번 글은 현재 문서와 과거 결과의 연결을 검토한 기록이며 새 원격 생성을 실행하지 않았다. 공개 실패 실험실은 단계별 결과를 구분하는 합성 도구이고 이 기능군 전체를 시험하지 않는다. 나는 목록을 늘리는 속도만큼 근거의 단위와 빈칸을 유지하는 일을 제작의 일부로 남긴다. 그 빈칸이 다음 검증의 출발점이 된다. 담당자가 바뀌어도 같은 행에서 입력·버전·확인 단계와 남은 질문을 찾을 수 있어야 장부가 이어진다.