실제 Electron과 Python을 실행했다고 해서 웹서비스까지 실제인 것은 아니다. 반대로 공개 사이트를 열었다고 업로드와 게시가 모두 검증된 것도 아니다. 북극성의 시험 기록을 묶으며 도구가 실제인지, 페이지가 실제인지, 업무 결과가 실제인지 세 질문을 나눠야 한다는 것을 배웠다.
통제한 페이지에서는 실패 조건을 정확히 만든다
project-isolation 시험은 독립 프로필에서 실제 Electron을 띄우지만 HTTPS 웹 응답은 소유한 HTML로 바꾼다. 입력 뒤 일정 시간 후 완료 문구가 나타나게 하고 두 프로젝트를 동시에 실행한다. 웹 응답을 통제하니 대기 중 실행이 겹치는 조건을 반복해서 만들 수 있다.
이것은 가짜 실행이라는 뜻이 아니다. 실제 커널과 탭, 실행 번호는 시험 대상이고 외부 서비스의 응답만 고정한 것이다. 실제로 사용한 부분과 시험용으로 대체한 부분을 밝혀야 한다. 그 조건을 숨기면 독자는 공개 서비스가 같은 속도와 구조로 반응한다고 오해할 수 있다.
파일 수신기는 선택과 전달을 나눠 보여 준다
생성한 합성 파일과 로컬 수신기로 실제 선택·전송 바이트를 대조하면 한글 이름과 빈 파일, 여러 파일이나 선택 해제 같은 조건을 반복해서 시험할 수 있다. 화면에 첨부명이 보이는지만 확인하는 것보다 전송 경계를 더 구체적으로 본다. 실제 파일 해시도 이 경계 안에서 의미가 있다.
하지만 로컬 수신기가 받은 바이트가 곧 외부 AI 서비스의 ZIP 해석 성공은 아니다. 실제 Gemini 시험에서 ZIP 내부를 읽지 못한 결과가 별도로 남아 있는 이유다. 파일을 받는 층과 내용을 해석하는 층이 다르다. 텍스트 변환 뒤 검증 코드로 읽기를 확인한 결과도 원래 ZIP을 지원한다고 바꿔 쓰지 않는다.
실사이트에서는 밖에서 바뀌는 조건을 만난다
과거 공개 사이트 감사는 홈·검색·뒤로/앞으로와 플레이어 진행 등 실제로 확인한 동작을 적었다. Google 검색은 외부 확인 화면으로 넘어가 정상 결과를 미검증으로 남겼다. 확인 화면을 없애거나 CAPTCHA를 우회해 성공 수를 맞추지 않았다.
같은 보고서에서 동영상 플레이어가 진행했다는 근거도 광고 스킵 성공과 구분한다. 사이트를 하나 열었다는 사실을 그 사이트의 모든 기능 호환성으로 넓히지 않는 것이다. 실제 계정과 서버의 제한은 fixture가 대신 알려 줄 수 없다. 원래 기록은 버전이 있는 과거 관찰이며 현재 모든 계정에서도 같다는 약속으로 사용하지 않았다.
시험 자체의 오류와 제품 오류를 구별한다
공개 사이트 초기 검사에는 숨긴 창과 불안정한 locator로 실패한 경우가 있었다. 창을 표시하고 명시적으로 탐색을 기다리며 실제 라벨과 보이는 video를 고른 뒤 다시 검사한 기록을 남겼다. 초기 실패를 지우고 처음부터 문제없었다고 쓰지 않았다.
반면 실제 제품의 HTTPS 중간 이동이나 하위 프레임 오류 표시는 별도 수정 항목이었다. 시험이 잘못됐다는 사실이 제품의 모든 실패를 설명하지는 않는다. 어느 가설을 바꿨고 어떤 소스가 바뀌었는지 분리해야 했다. 내 관심은 통과 수만 맞추는 것이 아니라 실패가 재현 조건과 구현 중 어디에 속했는지를 찾는 데 있었다.
서로 다른 근거를 연결하되 합치지 않는다
나는 검수 문장에 실행기·페이지·서버·결과 단계를 넣는다. 실제 Electron에서 소유 fixture를 시험했다면 그대로 쓰고, 실제 서버에서 받은 답변이 있다면 그 버전과 입력에 연결한다. 새 자료를 보내지 않고 기존 결과를 읽은 검수도 별도로 표시한다.
이번에는 과거 보고서와 시험을 대조했으며 새 서비스 요청을 만들지 않았다. 공유 실패 실험실도 순서를 통제한 메모리 모델일 뿐 실사이트 인증서가 아니다. 통제 시험과 실사이트 검수가 각각 답할 수 있는 질문을 지켜야 둘을 조합한 근거가 강해진다. 실제라는 한 단어보다 어떤 부분이 실제였는지를 적는 것이 제작자의 책임이라고 생각한다. 다음 시험도 이 구분에서 남은 질문 하나를 골라야 이전 결과와 비교할 수 있다.