[카테고리:] 한국어

AI로 만든 가상 신청 폼 하나를 자동화 도구로 조건마다 두 번씩 시험했다. 평가한 경로에서는 최초본도 완료 화면에 도달했지만 입력값이 표시되지 않았다. 한 번의 코드 수정으로 그 정보가 추가됐다. 사용자 성공률이나 AI의 일반적 능력을 검증한 결과는 아니다. 실제 200% 확대는 시험하지 못했고, 한국어 화면의 키보드 조건에도 미평가 단계가 남았다.

개념 일러스트이며 실제 시험 화면이나 확대 성공의 증거가 아니다.

공식 설명과 이 글의 구분: 도달·조작·확대

W3C의 키보드 기준 해설은 기능을 키보드로 조작할 수 있어야 한다고 설명한다. 이 글에서는 버튼에 도달하는 것, 지금 키보드로 조작할 위치인 ‘초점’을 보는 것, 실제 작동을 구분한다.

텍스트 확대 해설은 자막과 텍스트 이미지를 제외하고 텍스트를 200%까지 확대해도 내용과 기능을 잃지 않아야 한다고 설명한다. 이 글의 화면 폭 축소는 그 확대 시험을 대신하지 못한다. WAI의 간단 점검 안내도 일부 점검을 통과해도 접근성 장벽이 남을 수 있다고 설명한다. 이들은 기준 해설·점검 안내이며, 이 폼의 적합성 판정이 아니다.

관찰: 화면 도달과 입력값 표시를 따로 봤다

2026년 9월 27일의 목표 경로는 입력→검토→완료였다. 이름을 비우고 이메일에 invalid를 넣어 거절시킨 뒤, 연습 참가자 또는 Demo Participant와 demo@example.com으로 바로잡았다. 폼 안 ‘뒤로’로 돌아가 오전을 오후로 바꾸는 것을 시도하고, 변경이 확인된 경로에서 제출했다. 모두 합성 자료다.

최초본은 B0, 한 번 코드를 수정한 것은 B1이다. 생성 설정은 명령줄 도구 Codex CLI gpt-6-astra, 추론 강도 high로 기록됐다. 의미에 맞는 HTML과 보이는 항목 이름을 미리 요구했다. 별도 폴더를 썼지만 도구가 물려받은 맥락·실제 모델 설정을 생성 응답만으로 독립 확인하지는 못했다.

자동화는 macOS의 화면 없는 Chrome 153.0.8010.53과 Node v24.19.0/Playwright를 사용했다. 페이지 내부 구조(DOM)를 읽어 조작 대상을 찾았으므로 사람이 화면만 보고 조작한 시험이 아니다. 포인터 조건도 선택 상자를 클릭한 뒤, 포인터 조작에 상당하는 프로그램 명령 selectOption으로 값을 골랐다. 키보드 조건에서 막힌 조작을 포인터로 대신한 경우는 B0·B1 각각 키보드 실행 0/8회다. 키 입력 경로의 시각 확인은 일부뿐이다.

표의 각 행은 B0·B1 각각 두 번씩이다. 기본 폭은 화면 배치 단위인 CSS 픽셀로 1280×900, 좁은 폭은 640×900이다. 기록의 M100은 포인터·입력, K100은 기본 폭 키보드, K200은 좁은 폭 키보드라는 이름일 뿐 실제 확대나 글자 확대가 아니다.

‘기준’은 DOM에서 완료 화면의 이름·이메일·오후 선택과 로컬 데모·미전송 문구를 확인하는 것이다. 표의 충족 수는 화면 도달 수나 사람의 성공률이 아니다. 한국어 화면의 키보드 조건도 앞선 입력·오류 수정·뒤로 이동은 검사했다.

각 행의 두 반복은 같았다. 버전당 12회 중 평가한 8회에서 B0도 완료 화면에 도달했지만 이름·이메일·오후 선택이 없었다. 로컬 데모·미전송 문구는 있었다. 완료 화면의 입력값 재표시는 기획과 평가 기준에 있었지만 최초 생성 요청에서 빠졌다. B0가 받은 지시를 어긴 것은 아니다. B1은 그 정보를 추가해 평가한 8/8회에서 기준을 충족했다. 입증된 변화는 이 정보 추가이며, 키보드·확대 장벽 해결이 아니다.

B0·B1 각각 오류 거절·바로잡기·첫 검토·뒤로 이동은 DOM 확인상 12/12회였다. 정답 입력값을 정해 둔 자동화여서 사람이 오류 안내를 이해해 바로잡았다는 증거는 아니다. 값 보존은 각각 44/44지점이었다(선택 변경까지 간 8개 경로×4지점, 오후를 선택하지 못한 한국어 화면의 키보드 4개 경로×3지점). 오후 검토는 각각 8/12회로, 포인터 상당 조작 4/4회와 영어 화면에서 앞글자 Af를 쳐 Afternoon을 고른 키보드 조작 4/4회다.

한국어 화면의 키보드 4/4회는 두 버전 모두 선택 변경이 미평가다. 자동 입력한 ArrowDown(아래 방향키)과 End로 값이 바뀌지 않았고, 도구가 지원하지 않는 한글 앞글자 선택은 건너뛰었다. Space·ArrowDown·Enter 뒤 오전인 채 검토로 이동해 중단했다. 최종 제출은 아니며, 뒤의 Alt+ArrowDown 대체 절차는 실행되지 않았다. 기록은 오후 선택과 이후 완료를 시험 도구·환경 제약에 따른 미검사로 분류한다. 이는 원인을 확정한 진단이 아니며 앱의 키보드 결함이나 정상 작동 어느 쪽도 입증하지 않는다.

시험 도구도 고쳤고, 보지 못한 화면도 남았다

표의 결과는 시험 도구를 세 번 고친 뒤 얻었다. 앞선 세 묶음은 각각 12/12회, 총 36회 중단돼 분모에서 제외했다. 첫 묶음은 도구가 ‘시간’을 영역과 선택 상자 중 어디에 연결할지 정하지 못한 6회와 선택 변경 중단 6회, 두 번째는 선택 변경 중단 12회, 세 번째는 완료 정보 불일치 8회와 한국어 선택 미해결 4회다. 세 번째의 8회는 뒤에 평가한 B0와 같은 기준의 불일치를 관찰한 것이지만 채점에 합산하지 않았다. 모두 가짜 앱 실패였다는 뜻은 아니다.

도구는 선택 상자를 우선하도록 바뀌었고 앱의 ‘시간’ 이름 중복은 바꾸지 않았다. 이것이 음성 조작 등에 미치는 영향은 미검사다. 과거 이메일이 오후가 된 것은 초점 이동 뒤 키 입력이 이메일 칸에서 이어진 도구 오류로 분류됐으며, 이동한 정확한 순간은 기록에 없다. 앱의 값 손실로 세지 않았다. 생성 AI의 자체 브라우저 확인도 처음에는 실행에 실패해 화면을 검증하지 못했다.

시각 검토는 당시 조정자 Claude(Opus 5.5)가 후보 10장 중 4장을 본 기록이다. 영어 완료, 영어 좁은 폭 선택 상자·완료, 한국어 좁은 폭 첫 오류가 해당한다. 마지막 화면에는 이름 초점 테두리와 두 오류가 보였다. 영어 기본 폭 완료의 재시작 테두리는 아래쪽이 일부 잘렸지만 조정자는 식별 가능하다고 판단했다. 좁은 폭 선택 상자 테두리도 화면 아래 가장자리에 닿았다. B0 완료를 포함한 나머지 6장과 다른 상태의 가독성·초점·가림은 미확인이다. B0의 누락 값은 이 네 장의 시각 판정이 아닌 DOM 평가 결과다. 가로 넘침은 B0 0/910, B1 0/902개 자동 측정에서 검출됐지만, 이것이 모든 화면의 가독성을 뜻하지는 않는다.

앱 수정은 허용한 세 번 중 한 번, 생성 요청은 네 번 중 두 번을 사용했다. 정해 둔 완료 정보→입력 정보 손실→초점·배치 순위에 따라, 평가한 B1 정보 누락은 해소됐고 남은 중단은 도구·환경으로 분류돼 B2·B3를 실행하지 않았다. 제한적으로 본 이미지도 추가 수리가 필요한 장벽으로 판정되지 않았다. 미확인 화면·한국어 선택·테두리 관찰은 남아 있으며 무결함 판정은 아니다.

생성·수정 응답 합계는 6분 33초, 첫 생성부터 B1 시험 종료까지는 1시간 52분 59초다. 전체 작업시간·사람의 수행시간·생산성은 측정하지 않았다. 추가 지출 한도는 0달러였지만 실제 청구액·토큰 비용은 미확인이다. 별도로 보관한 영문 실험 기록에 요청문과 제외 시도·반복별 근거가 연결돼 있다.

판단과 다시 쓸 점검표

내 편집상 판단은 ‘완료’에 필요한 표시값을 생성 요청부터 구체적으로 적자는 것이다. 이 사례에서는 기획에 있던 요구가 전달되지 않았고, 명시적으로 요청한 뒤 평가 가능한 경로에 표시됐다. 이 한 구현의 변화가 독자에게도 같은 효과를 보장하지는 않는다.

실제 확대와 중간 배율, 320 CSS 픽셀 폭에 맞춰 내용을 배치하는 별도 재배치 시험, 화면낭독기 음성, 한글 입력기 조작, 다른 브라우저·모바일, 장애인 사용자 경험은 미검사다. 미전송 문구 확인도 네트워크 감사는 아니다. 유예됐던 Grok 기획·인터뷰 검토는 2026년 10월 5일 수행·판정했다. 실험 전 자료에 대한 사후 편집 검토이며 실행 결과의 독립 검증은 아니다.

다음은 기획 절차를 이 글에서 줄인 기록용 점검표다. 효과가 검증된 도구나 인증표가 아니다. ‘예/아니요/미검사’와 화면·값·막힌 위치를 적는다. 첫 항목인 실제 확대는 이번 실험에서 미검사다.

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

코드를 옮겨 화면이 켜지면 이사가 끝난 걸까? 같은 기기의 합성 앱 모의실험에서 ‘다른 폴더에서 실행’과 ‘원래 서비스 경로를 막고 기록·파일 사용’을 나눠 살폈다.

합성 앱 하나를 같은 Mac의 별도 폴더로 복사했다. 원래 서비스를 흉내 낸 프로그램을 두고 일부 묶음에서 구성요소를 의도적으로 뺐다. 한 앱을 두 번 초기화해 반복한 결과이며 실제 업체의 내보내기, 다른 컴퓨터로의 이전, 일반적인 성공률을 말하지 않는다. 앱은 Astra라는 AI 에이전트의 작업 세션에서 작성했다. 측정 중 모델 호출은 없었으며 AI 자체를 평가한 시험도 아니다.

공식 설명: 코드 밖에도 옮길 것이 있다

Lovable 문서는 사용자가 보는 화면을 다른 곳에 두면서 데이터 등 뒤쪽 기능을 맡는 Cloud 서비스를 계속 쓰는 구성을 설명한다. Supabase 문서는 데이터베이스 백업에 파일 저장 기능인 Storage의 파일 자체가 포함되지 않는다고 설명한다. 파일을 옮길 수 없다는 뜻은 아니다. 두 문장의 근거는 2026년 10월 5일 재확인했다. 이번 실험에서 두 제품을 내보낸 것은 아니다.

실험 기록: 같은 코드, 다른 세 묶음

이 글에서는 코드·기록·설정·파일 내용·서비스를 나눠 본다. 설정에는 접속 주소, 서비스에는 기록·파일을 제공하는 프로그램 등이 해당한다. 의존성은 앱 작동에 아직 필요한 것이다.

2026년 9월 27일 기록 20개·첨부 3개로 시험했다. 코드는 세 묶음 모두 같다. A에는 코드와 원래 서비스로 연결하는 설정만 있다. B에는 기록 DB 사본과 기록을 로컬에서 쓰는 설정을 더했지만 파일은 원래 서비스에서 가져온다. C에는 파일 3개의 내용과 상대 경로로 로컬 기록·파일을 쓰는 설정까지 넣었다. 별도 서비스 프로그램을 추가로 옮긴 것이 아니다. 결과는 설계한 누락의 동작을 확인한 것이며 뜻밖의 업체 결함을 발견한 것이 아니다.

매번 새 사본과 새 브라우저 상태로 시작하고 캐시와 서비스 워커를 우회했다. 원래 서비스로 향하는 중계 경로를 허용하거나, 원래 서비스에 전달하지 않고 즉시 HTTP 503(서비스 이용 불가)을 돌려주도록 했다. 아래 ‘차단’은 이 조건이다. 해지·와이파이 끄기와 다르며 캐시가 켜진 상태, 시간 초과·연결 거부·부분 장애·인증 오류의 동작은 시험하지 않았다. 둘째 반복은 상태가 다음 조건에 남는지 살피려고 순서를 뒤집었다. 한 앱의 3묶음×2상태×2반복, 12조건이지 독립된 앱 12개가 아니다.

비교 기준을 확인하려고 원래 서비스의 일회용 사본만 실행한 기준 시험도 1회 했다. 원래 서비스 재시작 전후 기록 20/20, 파일 내용·연결 각각 3/3이 일치했다. R05 기록의 메모 수정은 일회용 원래 서비스 DB에만 남았다. 사용하지 않은 목적지 DB 사본과 보존 원본은 그대로였고 이 수정은 이후 조건에 넘기지 않았다.

표의 ‘기록’은 7개 필드가 모두 일치한 기록 수/20이다. 목록과 상세를 따로 확인했고 매 조건 두 수가 같았다. 20/20에는 값·자료형 일치와 ID 누락·추가·중복 없음이 포함된다. 일곱 필드 밖의 의존성은 이 판정으로 알 수 없다. ‘파일 내용’은 다운로드 경로에서 받은 내용의 일치 수/3이다. 일치 수는 처음과 옮긴 앱 재시작 후에 같았다. 수정에 성공했다면 재시작 뒤 R05 메모 하나만 지정대로 바뀌어 있어야 맞다고 봤다.

A 허용의 기록·파일과 B 허용의 파일은 원래 서비스 응답이며 목적지에 들어 있는 내용이 아니다. B의 기록과 C의 기록·파일은 로컬 구성에서 제공했다. ‘옮긴 곳’은 복사한 앱의 폴더·DB를 뜻한다. 요청은 처음·수정·재시작 관측을 합친 원래 서비스로의 앱 전달 시도다. 조건 전에 경로의 허용·차단을 확인한 진단 요청은 제외했다.

C의 0/0/0은 감사한 앱 전달 요청 수다. 차단 6조건 모두 이 요청의 원래 서비스 도달은 0회였다. 브라우저의 모든 통신이나 원본 파일을 읽는 모든 경로를 감사한 결과는 아니다. 운영체제 수준 브라우저 격리는 제거됐고, 별도 브라우저 차단 점검의 실행 근거도 없어 C를 포함한 완전 격리를 입증하지 못한다.

12/12조건에서 처음과 재시작 후 페이지 응답은 HTTP 200이고 앱 제목이 있었다. 이것만으로 기능 정상은 아니다. A 허용에서는 R05 메모가 원래 서비스의 일회용 DB에만 저장됐다. 옮긴 앱을 재시작해도 보였지만 새 곳에 저장된 것은 아니었다. 저장 위치는 화면이 아니라 양쪽 DB의 수정 전후·재시작 후 상태와 요청 기록으로 판정했다. A 차단은 목록·상세·파일·수정 모두 HTTP 503이었다. 0/20은 접근 불가이지 삭제가 아니며 저장 실패는 이전에 저장된 기록의 소실이 아니다.

B 차단에서는 기록과 파일의 연결이 3/3 남았지만 메모.txt, table.csv, bytes.bin 내용은 0/3이었다. 이름·링크와 파일 자체의 차이다. 다른 조건의 파일 연결도 3/3이었으나 A 차단은 기록을 불러오지 못해 연결을 확인할 수 없었다. B·C 수정은 옮긴 DB에만 저장돼 재시작 후 유지됐다. 각 조건에서 지정 메모 외 DB 변경은 없었고 보존 원본은 그대로였다.

C가 확인한 범위는 이 기록·파일·메모 수정·재시작뿐이다. 기록 생성·삭제와 첨부 교체는 시험하지 않았다. 로그인, 결제, 메일, 백그라운드 작업, 실행 중 AI 기능은 구현하지 않았고 시험하지 않았다.

B의 요청 6건은 처음과 재시작 때 파일 3개씩 요청한 것이다. A의 52건과 51건의 경로별 구성은 요약 기록에 열거돼 있지 않아 같은 요청 집합이라고 단정하지 않는다. 각 조건 전에 허용 진단 1회가 원래 서비스에 도달했으므로 차단 조건 폴더의 로그에도 그 과거 접속이 남는다. 표의 앱 요청과는 별도다.

실패한 준비와 확인하지 못한 것

최초 사전 점검은 통신·브라우저 허용 범위 충돌로 보류됐다. 범위 명시 뒤 세 시도가 각각 설정·기록 무결성·브라우저 실행 문제로 멈췄다. 각 시도의 측정은 0/12였고 앱 기능 실패로 세지 않았다. 범위 명시 뒤 넷째 시도에서 12조건을 관찰했다. 세부 오류와 기준 시험 준비 내역은 실험 기록에 보존했다.

측정 전 시험 실행 프로그램을 고쳤지만 앱·데이터·묶음·순서·판정 기준은 유지했다. 다만 운영체제의 브라우저 격리를 제거했으므로 브라우저 자체의 백그라운드 통신 차단은 미입증이다. 브라우저가 허용 목록 밖 로컬 포트를 막는지 보는 별도 점검은 실행 기록이 없고 결과·시간도 미확인이다. 관측된 원래 서비스 경로의 503 차단과는 다른 점검이다. 시험용 임시 폴더의 중간 재배치 과정 일부도 기록으로 확인되지 않는다.

환경은 macOS 27.0 arm64, Python 3.9.6, SQLite 3.54.0, Chrome 153.0.8010.53과 Node v24.19.0·설치된 Playwright였다. 마지막 자동 실행은 기준 시험 포함 약 42초로, 앱 이전에 걸린 시간이 아니다. 전체 제작·수정·초보자 이전 시간, 총비용·모델 식별자·CLI 버전·구독 사용량은 미측정이다. 비용이 들지 않는 이전이나 생산성 향상을 입증하지 않는다.

다른 기기·OS, 실제 업체의 내보내기 권한·난이도·비용, 공개 배포·운영 보안·법적 소유권·라이선스·실제 해지는 확인하지 않았다. 브라우저 저장값의 이전, 운영체제 다운로드 창을 통한 저장, 별도 앱에서 파일 열기도 시험하지 않았다.

판단: 저장 위치와 파일 내용을 함께 적자

필자의 판단으로 ‘수정이 보이나’ 다음에는 **‘어디에 저장됐나’와 ‘원래 서비스 경로 없이 파일 내용도 남나’**를 물어야 한다. C를 모든 앱의 이전 가능성·성공률로 일반화할 수 없다. 원래 서비스를 의도적으로 유지하는 구성도 선택지다.

아래는 첫 확인표다. 원래 계정과 데이터는 보존하고, 먼저 사본에서 읽기 기능 하나를 골라 기대한 내용과 대조한다. 코드 사본도 원래 서비스에 쓸 수 있으므로 수정 시험은 연결된 서비스까지 일회용 시험 데이터로 분리한 뒤에만 한다. 이를 확인할 수 없다면 쓰지 말고 ‘모름’으로 남긴다. 초보자 사용성은 미검증이며 이전 성공이나 계정 해지의 안전을 인증하는 표가 아니다.

각 행에 계획한 위치를 ‘로컬/원래 서비스/모름’으로 적는다. 확인란에는 **원래 서비스 경로 없이 확인했는지(예/아니오/안 함), 수정은 어느 DB에 저장됐는지(위치/안 함/모름)**를 반드시 남긴다. 실서비스 해지나 통신 차단을 바로 실행하라는 뜻은 아니다. 시험 환경의 경로와 저장 위치를 확인할 수 없다면 독립 실행 판정은 ‘모름’이다. 내보내기에 포함됐다는 사실과 원래 서비스 없이 작동한다는 판단도 구분한다.

내용 대조 범위, 내려받은 파일 내용의 일치 여부, 일회용 데이터에서 수정 후 재시작해도 남는지를 적는다. 3개만 봤다면 ‘3개 확인’으로 쓰고 전체 일치로 넓히지 않는다. 모르는 항목은 ‘모름’으로 표시하고 문의 대상을 적는다.

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

여기서 돌아갈 곳은 미리 기록하고 확인한 복구점 T0다. 고장 직전까지 한 일을 모두 포함하지는 않는다. ‘정확히’는 지정한 코드·설정 파일 내용이 바이트 단위로 같고, 저장된 표의 구조와 모든 값, 정해 둔 동작이 기준과 맞는다는 뜻이다.

가상으로 만든 작은 할 일 목록에 결함 하나를 일부러 넣고, 두 복구 방식을 각각 두 번씩 한 차례 시험했다. 실제 사용자 사고나 AI가 우연히 만든 앱 결함을 재현한 것은 아니다. 코드만 되돌리면 잘못된 데이터가 남았고, 코드·데이터·설정을 함께 되돌리면 T0와 맞았지만 이후 정상 작업 두 건이 사라졌다. 성공률이나 일반 규칙을 밝힌 실험은 아니다.

공식 설명: 코드와 데이터의 복원 범위

Git restore는 지정한 원본에서 선택한 파일을 복원한다. 데이터베이스 파일을 Git에 함께 기록하는 프로젝트도 있으며, 제외 규칙도 이미 추적하는 파일에는 적용되지 않는다.

SQLite 백업 기능은 데이터베이스 사본을 만든다. integrity_check는 구조와 일부 제약 조건을 검사하며 외래 키 검사는 별도다. ok는 이 검사에서 문제가 없다는 뜻이다. 여기서 과거 값의 일치까지 보장하지는 않는다는 것은 검사 범위에 따른 해석이다. 위 문서의 확인일은 2026년 10월 5일이다.

이번 실험의 설계

이번 실험에서는 데이터·설정을 처음부터 Git 기록에서 제외하고, 스크립트가 관리하는 쓰기를 멈춰 함께 기록했다. SQLite 기록 방식은 delete였고 외부 프로세스의 쓰기까지 독립적으로 탐지한 것은 아니다. 실행 중인 DB 파일의 단순 복사는 진행 중인 변경 때문에 불완전할 수 있다. 이번에는 SQLite 백업 기능을 썼으며, 쓰기 중단은 이 실험의 조정 조건이지 그 기능의 보편적 필수 조건은 아니다.

기록된 관찰: 첫 시도 중단과 별도 재실행

2026년 9월 27일 한국 시간(UTC+09:00), macOS 27.0 arm64, Git 2.54.0, Python 3.9.6, SQLite 3.54.0에서 실행했다. Astra(Codex)가 실험 스크립트를 작성·실행했다. 로컬 가상 데이터·고정 스크립트로, 측정 중 모델 추론은 없었다. A는 코드만, B는 코드·데이터·설정을 복원하는 방식이다.

첫 시도는 읽기 전용 속성이 코드 사본에도 복사돼 결함을 넣기 전에 권한 오류로 멈췄다. 앱 복구 실패가 아니라 실험 스크립트의 준비 결함이다. 계획한 A·B 각 2회 중 실행은 각각 0/2회다. 정상 확인과 복원 연습은 각각 11/11개 검사를 통과했지만 고장 복구 결과는 아니다. 고장 상태·복구 시간·손실은 미측정이다. 절차를 고정하기 전, 편집 도구가 허용 폴더 밖 파일 생성을 1회 막았고 파일은 쓰이지 않았다. 다른 생성 방식으로 준비했다.

첫 시도는 재시도 없이 종료했다. 이후 사용자가 별도 2차 시도 한 번을 허용했고, 실행 전에 사본의 쓰기 권한 보정과 새 작업 공간을 기록했다. 앱·기대값·검사 규칙은 유지하고 첫 증거도 보존했다. 재실행에서도 정상 확인·복원 연습은 각각 11/11개 통과했다.

기록된 관찰: 2차 시도의 상태 변화

비교 범위는 app.py·.gitignore, tasks(id,title,done)의 표 구조와 번호순 전체 행, settings.json의 목록 제목·완료 항목 표시 설정이다. 0은 미완료, 1은 완료다.

4번 추가와 제목 변경은 정상 작업이다. ‘2번만 완료’의 대상 제한을 일부러 없애고 한 번 실행하자 네 행의 완료 값이 모두 1이 됐다. 2번은 요청한 대상이고 3번은 이미 완료 상태였으며, 1번·4번이 의도치 않게 바뀌었다. 고장 상태는 고장 대조 기록의 11개 검사 중 4개(표 구조·무결성·현재 목록 출력·현재 설정 출력)만 통과했지만 무결성 결과는 ok였다. 항목 이름과 완료 항목 표시 설정은 그대로였다.

기록된 관찰: 두 방식이 돌려놓은 것

복원 범위를 의도적으로 다르게 정한 비교다. 예상한 차이가 이 구현에서 실제로 나타나는지 확인했으며 방식의 우열을 가린 것은 아니다. 동일한 고장 상태의 새 사본에서 A1/B1/B2/A2 순서로, 각각 계획한 2/2회를 마쳤다.

11개 검사는 코드·설정·데이터 대조와 동작 확인을 묶은 것으로, 통과 개수는 복구율이 아니다. T0와 다른 정상 제목 수정도 불일치로 센다. A는 코드·표 구조·무결성·현재 목록/설정 출력·동작 검사에 통과했지만, 과거 행과 T0 설정/목록 대조에는 실패했다.

A는 두 번 모두 코드만 고쳤고 잘못된 완료 값은 남았다. A의 복원 과정이 새로 지운 것은 없었다. 다만 4번은 고장 때 이미 ‘완료’로 잘못 바뀐 채 남아 ‘온전히 보존’은 아니다. 제목 수정은 유지됐다.

B는 두 번 모두 지정한 코드·설정 파일의 바이트와 데이터 표 구조·번호순 전체 행이 T0와 맞았다. 동시에 정상 작업 두 건, 4번과 제목 수정이 사라졌다. 복구점 일치와 이후 작업 보존은 달랐다. 두 방식 모두 고장 직전의 정상 상태(네 항목의 값 0,0,1,0과 Demo v2)를 되찾지는 못했다.

동작은 별도 사본에 1·2번 미완료, 3번 완료인 (0,0,1)을 넣어 2번만 완료된 (0,1,1)이 되는지, 다시 열어도 같은지 확인했다. A·B 각 2/2회 통과했고 비교용으로 고치지 않은 결함 사본은 실패했다. 이 확인은 복원된 네 행이나 4번을 시험한 것이 아니며, 비교 대상인 복원 데이터 자체를 바꾸지 않았다. 동작 통과는 과거 데이터 복원과 다르다. 첫 시도의 백업은 논리 내용이 같아도 DB 파일 해시(내용 지문)가 달랐다. DB 파일 바이트 일치나 모든 미래 동작을 주장하지 않는다. 기대값은 앱 출력과 별도로 고정했지만 복원과 검증은 같은 스크립트가 수행했다. 독립 구현 검증기는 아니며, 원래 실행 사본 전체는 보관되지 않았다.

표와 이 문단의 시간은 자동 절차의 기록이다. 소수 여섯 자리로 반올림했고, 전체는 복원 시작검증 종료의 별도 측정이라 표시된 구간의 합과 끝자리가 다를 수 있다. 별도 사본 준비는 순서대로 0.007964·0.007863·0.009005·0.009480초, 자동 준비·저장·대조 검사는 0.314130초였다. T0결함도 0.077574초인 자동 실험이다.

첫 시도는 중단까지 시각 기록상 0.214146초였고 준비 합계는 미측정이다. 사람의 작업 시간·속도 우위를 뜻하지 않는다. 사본 준비 수치의 원자료는 시간 기록, 전체 경위는 실험 기록에 남겼다.

판단과 미검증 양식: 복구점 카드

내 판단으로는 무엇과 비교했고 무엇이 남거나 변하거나 사라졌는지 함께 적는 것이 중요하다. 아래 템플릿의 복구·손실 감소 효과는 미검증이다.

복구점 카드
기록 시각·시간대: ___ / 쓰기를 멈춘 범위: ___
코드 버전·위치: ___ / 설정 사본·위치: ___
데이터 사본·위치·해당 DB에 맞는 백업 방법: ___
무엇과 비교할지(앱 출력과 별도로 미리 저장한 기준): 파일 목록·내용, 표 구조·전체 값, 정해 둔 동작 ___
사본 복원 연습 결과: ___
이후 정상 작업과 잃어도 되는 범위: ___
복원 후 대조: 코드 ___ / 전체 데이터 ___ / 설정 ___ / 별도 사본의 동작 ___
남은·변한·사라진 작업: ___ / 확인하지 못한 것: ___

예를 들어 B는 ‘T0의 세 항목·Demo와 일치 / 이후 4번과 제목 수정은 사라짐’으로 적는다. 모르는 칸은 ‘모름’으로 둔다. 이후 작업의 값까지 남긴 근거가 없으면 이 비교만으로 손실을 확정할 수 없다. 항목이 있었다는 기록만으로는 변한 값을 놓칠 수 있다. 비교 결과·대조 검사·예정 범위가 맞지 않으면 멈춰 원인을 확인한다. 이 카드는 앱이 쓰고 있는 DB를 안전하게 백업하는 방법이나 서비스별 복구 절차를 대신하지 않는다.

한 기기·한 결함·방식별 두 번으로 신뢰도·최적 백업 간격·제품 및 모델 우열·생산성은 판단하지 못한다. 초보자 시간·사용성, 실제 비용·구독 잔여량·작성 모델 백엔드·CLI 버전은 미확인이다. 운영·호스팅·동시 쓰기·분산 환경, 데이터 구조 변경, 앱 밖 서비스로 이미 보낸 동작 되돌리기, 같은 디스크 고장으로 백업까지 잃는 경우, 정상적인 이후 작업만 골라 다시 적용하기도 미시험이다. 기존 완료 값의 정상 수정과 결함이 같은 값에서 충돌하는 경우도 시험하지 않았다. OS·파일 권한·파일 시각·미래 동작은 비교 밖이다. 검토 경위와 한계는 편집 회의 기록에 남겼다.

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

가상의 대여 모임에서 1월 규정은 대여 기간을 7일로, 7월부터 이를 대체하는 규정은 14일로 정했다. 지금 기간을 묻는데 옛 문서의 ‘7일’을 정확히 인용하면 충분할까? 문구는 진짜지만 현재 적용할 답은 아니다. 날짜와 수치는 모두 실험용이다. 한 모델에 문서 여섯 개와 같은 뜻의 한영 질문 12쌍을 조건마다 한 번씩 물었다. 이번 실행에서 현재 기간을 옛 7일로 답한 오류는 없었지만, 맞는 답의 인용이 충분하지 않은 사례는 있었다.

출처의 존재, 인용문의 뒷받침, 질문의 날짜·물품과 예외 범위에 대한 적용 여부를 나눠 시험했다.

선행 평가에서 빌린 두 가지 구분

ALCE 연구는 답의 정확성과 인용 품질을 구분해 평가한다. SQuAD의 답할 수 없는 질문 연구는 근거가 있을 때 답하고 없을 때 답을 보류하는 능력을 다룬다. SQuAD는 문서에서 답 구간을 찾는 독해 과제로, 이번 생성형 답변 실험과 다르다. 두 연구에서 빌린 것은 정확성과 인용 품질, 답변과 보류를 나누는 평가 관점이다. 적용일·예외·충돌 구분은 이번 실험의 설계이며, 논문 결과를 지금 모델의 성적으로 옮기지 않았다.

직접 관찰: 같은 문서, 두 가지 요청

2026년 9월 27일, 합성 문서 여섯 개와 사전 정답표로 시험했다. 이전·현재 규정, 카메라 예외, 수령 안내, 상충하는 프로젝터 요금 공지 두 개다. 매번 짧고 읽기 쉽게 만든 문서 전체를 같은 순서로 제공했다. 문서를 찾는 검색 단계와 순서의 영향은 시험하지 않았다. 현재 규정은 이전 규정의 대체와 카메라 예외 유지를 명시했다. 반면 기획본의 요금 충돌 안내 문장은 실행 문서에는 없었다.

A는 기본 출처 요청, B는 확인 규칙 추가다. 둘 다 제공된 문서만 사용하고 문서·조항 번호와 짧은 원문 인용을 붙이도록 했다. 제품의 내장 출처 기능이 아니라 답변에 번호와 인용문을 쓰게 한 시험이다. B에는 적용일·명시적 대체·예외 확인, 늦은 발행일만으로 무효화하지 않기, 동등한 문서의 미해결 충돌과 정보 부재 표시, 인용 지지 확인과 지지되지 않는 주장 빼기, 근거 있는 부분 답하기를 더했다.

실험 범위: 응답에 기록된 모델은 claude-sonnet-5였다. 명령줄 도구 Claude CLI로 문서를 모델 제공자에게 전송했다. 같은 뜻의 질문 12개를 한국어·영어로 만들어 두 조건에서 각각 새 프로세스·세션으로 한 번씩 실행했다(12×2×2=48). 계획·시도·유효 응답은 각각 48개, 무효·미시도·재시도는 0개였다. 한국어는 공백·인용 포함 600자, 영어는 인용 포함 150단어로 제한했다. 동일한 분량 조건은 아니지만 실제 최대는 371자·117단어로 모두 제한 안에 끝났고 기술적 잘림은 없었다. 시험 대상과 다른 AI 도구인 Codex가 사전 정답표에 따라 판단해 채점했으며, 사람의 독립 채점은 없었다.

기록상 실행 전에 제안 모델 claude-sonnet-4-6을 바꾸고, 요청 문구를 복원하고, Q10을 중립적인 확인 질문으로 고쳤다. 이 수정 시점은 독립적인 타임스탬프로 입증되지 않았다. 정확한 CLI·OS 버전과 과금 증빙, 내부 훅·메모리까지의 완전한 격리도 확인되지 않는다. 집계·정정 이력과 원본 입력·출력·정답표·채점 파일로 가는 경로는 별도로 보관한 실험 기록에 있다.

각 칸은 해당 문항 수 중 행의 기준을 충족한 수다. 직접 사실·적용 규칙은 정답표의 필수 사실 충족, 충돌은 두 값과 출처 제시·미해결 표시·확정 보류를 센다. 부재는 제공된 문서에 없다고 밝히고, 값을 지어내거나 수령 규칙을 반납 규칙으로 바꾸지 않은 경우다. 충돌·부재는 문항별로 표시했다.

이 표는 이번 한 번의 실행에서 기준을 충족한 문항 수이며, 실제 문서에서 늘 성공한다는 비율이나 보장이 아니다.

네 조합 모두 Q1에는 월요일–금요일 10–16시 수령을, Q2에는 예약 코드 지참을 답했다. 날짜·예외에서는 현재 일반 대여 14일, 2026년 6월 15일 기준 7일, 카메라 3일을 구분했다. 기간은 주말·휴일을 포함한다. 영어 B의 Q8은 기준일인 2026년 9월 27일에 카메라 한 대와 일반 물품 두 개가 총 세 개로 한도 안이라는 답을 했다. 다만 동결 정답표가 추가로 요구한 ‘카메라 최대 한 대’의 명시를 빠뜨렸다. 따라서 아래 점수는 필수 설명 전체의 충족 여부다. 수량 판단이 틀리거나 허위 규정을 만든 실패로 읽으면 안 된다. 정답표는 재고·승인 보장을 금지했고, 그런 보장을 한 응답은 없었다.

Q1–8의 필수 사실 전체를 충족한 수는 한국어 A·B와 영어 A가 각각 8/8, 영어 B가 7/8이었다. 불필요한 답변 거절은 네 조합 각각 0/8이었다.

충돌 문항에서는 날짜·발행 주체·유효 상태가 같은 공지가 5와 8크레딧을 제시했고 제공된 문서에는 우선순위 규칙이 없었다. 모든 응답이 두 값을 보여 주고 확정을 보류했다. 다만 한국어 B의 Q9은 공통 발행 주체와 유효 상태 설명을 생략했다. 충돌 처리와 설명의 완전함은 별개다.

연체료를 지어낸 응답도, 수령 안내를 근거로 일요일 반납을 허용한 응답도 없었다. 다만 영어 A의 Q12는 만기일이 일요일일 수 있다는 추론을 덧붙였다. 주말도 기간에 포함되므로 그럴듯하지만, 날짜 계산의 시작점이나 일요일 만기를 다른 날로 옮기는 규칙까지 문서가 정하지는 않았다. Codex는 이를 근거가 일부만 있는 주장으로 판정했다. 정보 부재 처리는 통과했어도 추가 추론까지 모두 뒷받침된 것은 아니다.

맞는 답과 충분한 인용은 달랐다

영어 A의 Q5는 ‘7일’이라고 맞게 답했지만 인용은 “including weekends and holidays”뿐이었다. 이 인용에는 7이 없다. 영어 B의 Q8은 카메라 기간 인용에 생략부호를 넣었다. 기간의 의미는 유지했지만 이 실험의 원문 그대로 인용하기 기준은 충족하지 못했다. 의미를 뒷받침하는지와 원문을 그대로 옮겼는지는 별개다.

한국어 A의 Q3도 대체 날짜는 맞았지만 기간 문장만 인용했다. 영어 A의 Q8은 예외가 유지된다는 구절로 ‘3일’을 뒷받침하려 했지만 그 구절에는 기간 수치가 없었다. 일부 A 응답의 추가 수령·카메라 사실에는 문서 번호만 있고 인용문이 없었다.

두 열은 의미 지지와 완전한 인용을 구분한다. B는 지지되지 않는 주장을 빼라고도 했으므로 주장 선택 자체가 분모를 바꿀 수 있다. 답마다 주장 수가 달라 공통 분모의 성능 비교나 합산 비율로 쓸 수 없다. Codex가 주장 경계와 지지 정도를 판단했고 일부 Q9 인용 점수를 사후 정정했다. 초기 점수와 이유는 보존돼 있다.

문서 번호만 있고 인용문이 없으면 이 지표에서 충분한 지지로 인정하지 않았다. 정보나 우선순위가 없다는 진술은 여섯 문서 전체로 별도 확인했다. 인용할 사실이 없는 답은 해당 없음이며 자동 만점이 아니다.

필자의 판단과 직접 써 볼 점검표

필자의 판단은 답과 인용문을 나란히 확인하자는 것이다. B의 우위나 무조건적인 답변 보류를 권할 결과는 아니다. 아래는 시험하지 않은 점검 양식 제안이다. 사람이 오류를 더 잘 찾거나 실제 문서를 더 쉽게 확인하는지는 측정하지 않았다.

정답을 아는 예제로 시험할 때는 AI에게 묻기 전에 예상 답을 적는다. 평소 확인에서는 그 칸을 비워 두고 원문부터 봐도 된다.

시험 질문에는 직접 사실·적용 규칙·충돌·정보 부재를 모두 넣고, 정답표·인용 지지·적용 범위·불필요한 거절 여부를 기록한다. 이번에 검색은 시험하지 않았지만, ‘검색으로 못 찾음’을 ‘문서에 없음’으로 바로 판단하지 말자는 것이 필자의 제안이다.

공개해도 되는 같은 문서와 질문으로 새 대화 두 개를 열어 볼 수 있다. 두 대화 모두 아래 공통 요청을 쓰고, 한쪽에만 B의 추가 요청 전문을 붙인다. 이는 원래 문구를 이용한 연습이며 한 번씩 비교해 어느 쪽이 낫다고 판단할 수는 없다. 기준일·분량 제한도 이 실험의 값이므로 다른 과제에서는 별도로 정해야 한다.

공통 요청

아래 여섯 문서만 사용해 질문에 한국어로 답하세요. 기준일은 2026-09-27이며, 질문에 다른 날짜가 있으면 그 날짜를 사용하세요. 사실을 말할 때 [D번호 §절번호]와 짧은 원문 인용을 붙이세요. 외부 지식은 사용하지 마세요. 답변은 인용과 공백을 포함해 600자 이내로 작성하세요.

B의 추가 요청

적용일, 명시적 대체 관계, 예외의 적용 범위를 확인하세요. 발행일이 더 늦다는 이유만으로 다른 규정을 무효화하지 마세요. 동등한 문서가 충돌하고 해결 근거가 없으면 두 근거와 ‘문서 간 충돌로 확정할 수 없음’을 제시하세요. 답에 필요한 정보가 없으면 ‘제공된 문서에 명시되지 않음’이라고 답하고 추측하지 마세요. 인용이 해당 주장을 실제로 뒷받침하는지 확인하고, 뒷받침하지 않는 주장은 빼세요. 질문 중 근거가 있는 부분은 답하세요.

문서를 전부 제공한 유리한 조건이며 48회가 독립된 현실 과제 48개는 아니다. 같은 영어 시스템 문구와 한 세트의 가상 수치를 썼고, 시스템 언어·수치·길이·순서를 바꾸는 민감도 시험은 하지 않았다. 한 모델·짧은 합성 문서·연관 질문의 단회 관찰로 언어·제품의 우열이나 긴 문서·검색 성능, 일반적인 오류 빈도를 말할 수 없다. 둘 다 인용을 요구했고 B는 규칙 묶음을 바꿔 인용 자체나 특정 규칙의 효과도 분리할 수 없다. 사람의 확인 시간은 측정하지 않았다. 점검표의 시간 절약·생산성 효과는 확인하지 않았다.

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

2026-02-30은 날짜처럼 생겼지만 달력에는 없다. 반면 2028-02-29는 실제 날짜다. AI 코딩 도구가 만든 연습용 준비 목록 앱 하나에 합성 자료로 36개 하위 사례를 점검하도록 구성했다. 한 번 만들고 한 번 고친 앱의 관찰이며, 다른 앱의 실패율을 뜻하지 않는다.

여기서 ‘버틴다’는 실험이 미리 정한 규칙에 맞는 값을 받고, 맞지 않는 값은 저장하지 않으며, 고칠 방법을 알리고 다른 입력을 유지한 채 한 번 고쳐 저장할 수 있다는 뜻이다. 수정본에서는 관찰된 실패가 없었지만 화면에서 미확인인 항목은 남았다. 따라서 이 앱 전체가 검증됐다고 답할 수는 없다.

평가 규칙은 생성 전에 정했다. 제목은 앞뒤 일반 공백을 제거한 뒤 140자, 메모는 비워 둬도 되며 0200자다. 평가 단위는 유니코드 코드 포인트로, 눈에 보이는 글자 하나와 항상 같지는 않다. 이번에는 영문 A와 완성형 한글 가를 썼으며, 이 경계 시험만으로 앱의 다른 문자 조합 계산법까지 확인하지는 않았다. 날짜는 YYYY-MM-DD 형식의 실제 날짜 중 2026~2028년만 허용한다. 분류·세부 분류는 정해진 네 쌍만 허용한다. 공백을 정리한 제목·날짜·분류·세부 분류가 같으면 메모가 달라도 중복이다. 수정할 때 자기 기록은 제외한다. 모두 이 실험의 선택이지 모든 앱에 적용할 표준은 아니다.

참고한 근거: 모양, 의미, 고칠 방법

OWASP 입력 검증 안내는 입력의 형식과 맥락의 의미를 함께 확인하도록 설명한다. 이를 참고해 이 실험에서는 날짜 모양, 실제 달력 날짜, 허용 연도를 나눠 확인했다. 화면의 검사만으로 저장 담당 코드의 검사를 대신할 수는 없으며, 이 인용이나 실험 결과가 보안 검증을 뜻하지는 않는다.

W3C 오류 식별 안내는 자동으로 발견한 입력 오류의 항목과 내용을 글로 알려야 한다고 설명한다. 수정 제안 안내는 고칠 방법을 알면 제시하도록 하되 보안이나 목적을 해치는 경우는 예외로 둔다. 이를 참고하되, 구체적인 수정 안내·입력 유지·한 번의 수정 저장은 이 실험의 평가 규칙으로 구분했다. 이번 앱의 접근성 준수를 판정한 것은 아니다.

기록된 관찰: 한 앱을 만들고 한 번 수정했다

2026년 9월 27일, AI 코딩 도구 Codex CLI에 준비 목록의 입력·저장·수정을 요청한 실행 기록이다. 실행 계획은 gpt-6-astra, 추론 설정 high를 지정했지만 이벤트의 모델 헤더로 독립 확인하지는 못했다. 로컬 HTML·Python·SQLite와 분류 목록, 입력한 글자의 코드·수식 실행 금지는 처음부터 지정했다. 화면 문구는 한국어였다. 정확한 잘못된 날짜를 전달하려고 달력 선택기 대신 글자 입력칸을 썼다. 아래 화면 날짜 결과는 그 입력칸에서의 관찰이며, 기본 날짜 선택기에서도 같은 실패가 생긴다는 뜻이나 선택기를 피하라는 권고는 아니다.

상세 평가 규칙은 최초 생성본 B0에 주지 않았다. 따라서 초기 불일치를 ‘알려 준 지시를 어겼다’고 해석할 수 없다. 이후 처음 만든 Codex 대화를 이어서 규칙, 모든 시험의 기대 저장 상태를 담은 전체 평가 정답표, 실패 기록을 보내 수정본 R1을 받았다. 최초 요청은 환경 조건을 포함해 720바이트, 수정 요청은 255,841바이트였다. 모두 합성 자료였으며 실제 기록을 그대로 보내는 예시가 아니다. R1 검사와 마지막 재실행도 같은 고정 사례를 사용했다. 새로운 입력에 대한 일반화나 독립적인 두 비교군의 프롬프트 효과 실험이 아니다.

자동 시험은 매번 가짜 기록 두 개로 초기화하고, 36개 하위 사례를 화면 입력과 직접 저장 요청(API), 두 경로에서 각각 확인하도록 구성했다. 화면에서 막혀도 저장 담당 코드가 같은 값을 거절하는지는 따로 봐야 하기 때문이다. 화면에서 정확한 입력이나 후속 조작을 수행하지 못한 항목은 미확인으로 남겼다. 화면 차단과 저장 코드의 거절을 구분하고 실제 SQLite 기록도 대조했다. 아래 분모에는 미확인도 포함한다. 36개는 한 앱에 적용한 조건 수이지 독립 반복 36회가 아니다.

다음 표는 화면 기준 아홉 가지 중 저장 상태 하나이며 전체 품질 점수가 아니다.

직접 요청은 실패 16개가 충족으로 바뀌었다. 화면은 실패 14개가 충족으로 바뀌고, 미확인 4개가 새로 확인됐다. 후자는 기록 식별자로 찾게 된 수정 세 사례와 입력 가능해진 빈 세부 분류 한 사례다. 별도 목록·재열기 기준의 13개는 B0 미확인에서 R1 충족으로 바뀌었다. 이는 시험 도구의 관찰 범위 확대이며, B0에서 사람이 수정 버튼을 누를 수 없었다는 증거가 아니다.

오류 설명은 대상 23개 중 B0 충족 2·실패 14·미확인 7에서 R1 충족 19·실패 0·미확인 4로 바뀌었다. 수정 후 복구는 같은 대상 수에서 B0 0·13·10, R1 18·0·5였다. R1의 관찰된 실패가 0개라는 말은 모든 기준을 확인했다는 뜻이 아니다. 이 점수는 W3C 준수 판정도 아니다.

B0는 달력에 없는 2026-02-30과 2026-02-29를 두 경로 모두에서 저장했다. 2026년은 윤년이 아니다. R1은 둘 다 거절했고, 자동 시험 도구가 미리 정한 2026-02-28로 바꾼 뒤 고친 값을 저장했다. 정상 대조값 2028-02-29는 두 버전 모두 그대로 받았다. 03/04/2026과 2026-2-03도 B0에서는 저장됐지만 R1에서는 형식 안내와 함께 거절됐다. 앞 값은 3월 4일인지 4월 3일인지 순서가 모호하다. 고친 날짜는 시험자가 정한 값이며 R1이 의도를 추측한 것이 아니다. 직접 요청의 결과는 글자 입력칸과 별도로 저장 경계를 확인한 증거다.

중복 생성 두 사례도 B0는 받았고 R1은 거절했다. 제목 A와 가를 각각 40번 반복한 값은 두 버전 모두 받았다. 41자 두 값은 B0에서 저장됐고 R1에서는 잘라 저장하지 않고 거절됐다. 빈 메모, 날짜가 다른 같은 제목, 수식처럼 보이는 글자 =1+1도 두 버전 모두 그대로 저장했다. 잘못된 분류·조합의 직접 요청 거절도 B0에서 이미 충족했다. 평가한 항목에서 정상값의 잘못된 거절이나 무관한 기록의 변경은 관찰되지 않았다.

수용과 저장값은 다를 수 있었다. B0는 Workshop cards 를 받아들여 수용 기준은 충족했지만, 양끝 공백까지 저장해 기대 저장값과 달랐다. R1은 이 값의 양끝 일반 공백을 제거하고 안내했다. 이것이 직접 요청의 B0 수용 21개와 저장 상태 충족 20개가 다른 이유다.

빈 제목과 불가능한 날짜를 함께 넣은 사례에서 B0는 브라우저가 제목 빈칸을 먼저 막았다. 첫 제출에서 두 문제를 함께 설명하도록 한 실험 규칙은 충족하지 못했고, 해당 화면 제출의 저장 담당 코드 처리는 미확인이었다. 이는 W3C 기준 위반 판정이 아니다. 직접 요청은 두 버전 모두 거절했다. R1 화면은 두 문제를 설명하고 메모 keep this note와 선택값을 유지했다. 자동 시험 도구가 두 칸을 고쳐 한 번 저장하고 다시 연 값까지 확인했다. 이 장면은 전체 복구 23개 중 확인된 한 사례다.

확인하지 못한 것과 별도 재실행

초기 시험 두 번은 앱 평가에서 제외했다. 한 번은 브라우저 실행 제한, 한 번은 시험 도구가 필수 생성시각을 빠뜨린 초기화 오류였다. 각 72개 예정 관찰 중 유효한 앱 관찰은 0개였다. 앱 입력 오류로 세지 않았다. 유효 검사는 두 시험 도구 수정 뒤에 실행됐다. 자세한 변경은 부록에 남겼다.

R1에서도 잘못된 분류·조합 네 개는 화면에 정확히 넣을 수 없었다. 이런 선택 제한 자체는 예정한 관찰이며 곧바로 앱 실패는 아니다. 해당 입력의 저장 경계 거절은 직접 요청에서 확인했다. 빈 세부 분류 한 개는 화면 거절을 확인했지만 시험 도구의 키보드 수정이 끝나지 않았다. 직접 요청 결과로 화면 공백을 채우지 않았다. 추가 앱 수정 R2는 관찰된 수정 대상이 없어 생략했다. 정상 생성·불가능한 날짜·윤일·정상 수정 네 사례를 경로별로 재실행한 8개 관찰에서는 해당 기준을 충족했다. 이미 공개한 사례의 재실행이지 전체 재검사나 새 입력 시험은 아니다.

판단: 규칙·저장·복구를 따로 보기

이 사례에서 입력 규칙, 실제 저장값, 수정 후 복구를 따로 보는 일이 유용했다는 것이 편집 판단이다. 한 앱을 같은 대화에서 고친 결과로 일반적인 AI 신뢰도나 생산성 향상을 말할 수는 없다. 실행 한도 관리를 위해 준비 25분과 실패한 시험·수정·검증·대기를 보수적으로 포함해 계산한 차감 시간은 최종 재실행까지 76분이다. 사람의 실제 작업시간 총계나 비용을 측정한 값은 아니며, 이후 기록 작성도 별도다. 토큰 사용 기록 역시 청구액이 아니며 부록에서 따로 설명한다.

내 앱에 옮겨 적는 작은 점검표

진짜 자료가 없는 연습용 사본이나 새 빈 앱에서만 시험한다. 이번 실행처럼 자기 컴퓨터의 로컬 주소 127.0.0.1과 별도 합성 데이터베이스를 사용하고, 공유·운영 서버나 실제 로그인 정보는 쓰지 않는다. 아래는 편집 과정에서 구성한 재사용 양식이며, 시간 절약이나 전체 품질을 검증한 도구는 아니다. 먼저 한 칸만 고른다.

• 칸 이름 / 필수 여부 / 허용 형식·범위: ______
• 허용할 값 / 낯설지만 허용할 값 / 거절할 값: ______ / ______ / ______
• 저장 전에 앱이 바꿔도 되는 것(예: 앞뒤 공백 제거) / 중복 기준: ______ / ______
• 각 값마다 한 줄: 입력값 / 기대 결과 / 실제 결과: ______ / ______ / ______
• 오류 항목과 이유를 글로 알려 주는가? 예 / 아니오 / 모르겠음
• 이 앱의 규칙에 맞게 고칠 방법을 알려 주는가? 예 / 아니오 / 모르겠음
• 다른 입력을 유지하는가? 예 / 아니오 / 모르겠음
• 잘못된 칸을 고칠 수 있고, 고친 뒤 한 번 저장되는가? 예 / 아니오 / 모르겠음
• 새 기록은 하나 늘고, 수정은 같은 기록만 바뀌는가? 예 / 아니오 / 모르겠음
• 다시 연 값과 무관한 기록이 기대대로인가? 예 / 아니오 / 모르겠음

‘모르겠음’은 통과로 세지 않는다. 이 점검표는 알려진 수정 방법을 확인하는 실습이지 W3C 준수 평가표가 아니다. 다시 열기는 독자가 할 수 있는 화면 점검이며 실제 데이터베이스와 같다는 증명은 아니다. 이번 자동 시험 도구는 저장소를 별도로 읽었으며, 화면에서 못 넣은 값과 확인하지 못한 결과도 남겼다.

근거 부록: 전체 조건과 확인 범위

본문의 단일 앱 관찰을 재검토하기 위한 보존 기록이다. 별도로 보관한 실험 자료는 영어·기계 판독 형식을 포함한다. 전체 실험 기록, 고정 입력, B0 판정, R1 판정에 정확한 요청·값·수정 절차·화면·저장 전후 근거가 있다. 아래 수는 버전별·경로별 하위 사례 수이며 합계 36이다. 각 버전은 화면 36개와 직접 요청 36개, 총 72개 예정 관찰을 갖는다. ‘수용’은 입력 처리 관찰이며 화면 재열기까지 모두 충족했다는 뜻은 아니다.

중복 기준은 네 항목으로 정했지만 세부 분류만 바꾼 정상값 등으로 각 항목의 역할을 따로 검증하지는 않았다. C04는 Workshop cards 의 양끝 U+0020 공백 제거와 나머지 필드 유지를 확인한 사례다. 반복된 내부 공백, 공백뿐인 메모, 다른 종류의 가장자리 공백은 별도로 시험하지 않았다.

분류의 허용 쌍은 supplies/paper, supplies/pens, space/chairs, space/tables다. 중복 판정에서는 메모를 제외한다. 제목 정리는 양끝의 일반 공백(U+0020)만 허용하며, 대소문자·내부 공백·한글 표현을 임의로 바꾸도록 한 규칙이 아니다.

항목별 분모

아래 각 셀은 충족 / 실패 / 미확인 순서다. 대상 수에는 미확인이 포함된다. 직접 요청에는 화면 설명·유지·복구 등의 UI 기준을 적용하지 않았으며, 각각 36개가 ‘해당 없음’이다. 항목들을 합쳐 성공률을 계산하지 않는다.

화면 기준 중 대상 외 항목은 표시 23개, 공백 안내 35개, 설명·유지·수정 가능·복구 각각 13개가 해당 없음이다. 직접 요청은 각 36개 대상에서 저장 상태 B0 20/16/0 → R1 36/0/0, 수용·거절 B0 21/15/0 → R1 36/0/0, 무관한 기록 유지 두 버전 모두 36/0/0이었다.

B0의 ID로 기록을 찾는 시험 장치가 앱 화면과 맞지 않아 수정 세 사례와 재열기 평가가 빠졌다. 이는 사람이 수정 버튼을 못 누른다는 증거가 아니다. B0의 빈 제목 단독·복합 오류에서 브라우저가 막은 뒤의 앱 처리도 미확인이다. 저장 상태는 그대로여서 충족해도, 하위 처리까지 충족한 것은 아니다. C04는 반대로 수용 처리 충족·저장 상태 실패였다. R1의 화면 입력 불가 네 사례는 저장·처리·설명·입력 유지·수정 가능·복구가 미확인이고, 빈 세부 분류 한 사례는 수정 가능·복구가 미확인이다. 나중의 확인으로 초기 빈칸을 소급해 채우지 않았다.

B0의 C02 두 사례와 C20은 수정 후 DB가 기대와 같았지만 재열기 근거가 없어 복구 미확인 10개에 포함된다. 복구 실패 13개에 포함되는 것이 아니다. 실패 13개는 처음에 거절해야 할 입력을 저장한 사례이며, 뒤의 진단용 수정으로 첫 실패를 지우지 않았다.

별도 최종 재실행은 C01·C08 첫 값·C09·C19 각 경로 4개다. 저장·처리·무관한 기록 유지는 경로별 4/4, 화면 표시는 3/3, 오류 설명·입력 유지·수정 가능·복구는 각각 1/1 충족했다. 실패와 미확인은 없고 나머지는 해당 없음이다. 수정 저장 조작 수는 B0 화면 16회·직접 요청 23회, R1 화면 18회·직접 요청 23회, 재실행 화면 1회·직접 요청 1회다. 조작이 실제 쓰기를 뜻하지 않으며 최초 실패를 지우지도 않는다.

별도 읽기 전용 환경 점검은 1개 중 1개 충족했다. ko-KR / Asia/Seoul에서 저장한 2028-02-29를 en-US / America/Los_Angeles로 읽어 목록·재열기·DB 값이 그대로임을 확인했다. 저장 조작은 0회다. 언어와 시간대를 동시에 바꿨고 화면 문구는 한국어였으므로 영어 현지화나 두 요인의 개별 효과를 증명하지 않는다.

측정하지 않았거나 기록이 부족한 것

• 실험 기록 작성자는 AI 에이전트 Astra이며, 아래 결과는 자동 시험과 보존 자료 판정에서 나왔다. 인간 비개발자의 직접 사용 관찰은 아니다.
• 유효 B0 이전에 Chrome의 루프백 샌드박스 래퍼를 제거하고 설치된 Chrome을 직접 실행하도록 시험 도구를 고쳤다. 앱의 OS 소켓 샌드박스는 유지했지만 브라우저 요청 차단은 백그라운드 트래픽의 OS 격리 증명이 아니다. 이어 초기화에 필요한 created_at·updated_at을 모두 고정값 2026-09-27T00:00:00+00:00으로 넣도록 고쳤다. 앱 코드·고정 입력·기대값·분모 변경은 아니었다.
• 환경은 Mac 계열 Darwin, Playwright로 실행한 headless(화면 창 없는) Chrome 153.0.8010.53, Node 24.19.0, SQLite 3.54.0, 화면 1280×800이었다. 정확한 macOS·Python·Playwright·Codex CLI 버전, 구독 잔여량·실제 청구액은 보존 메타데이터로 확정하지 못했다. 지정 모델과 설정은 실행 계획의 기록이며 이벤트 자체의 모델 헤더로 독립 확인한 값은 아니다.
• 생성 경과시간 7분 37초, 수정 5분 55초, 유효 B0 검사 약 66초, R1 약 74초, 재실행 약 9초가 기록됐다. 준비와 검증을 뺀 제작시간이나 사람의 작업시간 총계로 읽을 수 없다. 76분 차감은 준비 25분과 이후 대기까지 보수적으로 포함한 예산 회계다. 토큰 기록은 B0 입력 183,610(캐시 162,560 포함)·출력 14,479, R1 입력 890,898(캐시 800,256 포함)·출력 11,173이다. 추론 출력 카운터는 각각 848·1,652로 따로 기록됐으며 합산 비용으로 쓰지 않았다. 무료·시간 절약·생산성 비교는 측정하지 않았다. 예산은 조정 시점의 이전 차감 65분·잔여 45분을 기준으로 재계산했으며, 재실행 로그의 잔액은 누적값이 아니어서 사용하지 않았다. 원래 추정한 모든 시간 창을 그대로 지켰다는 증거는 아니다.
• 한 지정 모델·한 생성·전체 평가 정답표와 알려진 실패를 받은 같은 대화의 수정이다. 독립 반복, 다른 모델·브라우저·기기, 실제 비개발자의 사용성·만족도·이해도, 오류 안내 시점 비교는 시험하지 않았다. 빌더가 보고한 자동 테스트 B0 5개·R1 45개는 빌더와 별도로 수집한 이 실험 관찰과 별개다. 사례들은 같은 앱·평가 규칙을 공유하며 통계적으로 독립인 표본이 아니다.
• 한글 입력기의 조합 과정, 분해된 한글, 이모지·눈에 보이는 글자 단위, 모바일, 기본 날짜 선택기, 화면낭독기, 더 넓은 언어·시간대는 미시험이다. 보안·접근성 인증도 하지 않았다.
• 동시 저장·중복 경쟁, 저장 중간의 일시적 쓰기나 원자성, 디스크 실패, 재시작 후 지속성, 배포·인증·접근 격리, 파일 입출력·스프레드시트 수식 안전성은 확인하지 않았다. 즉시 저장 전후 비교의 범위를 넘는다.

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

AI가 만든 여행 준비물 앱에서 추가·챙김 표시·삭제가 작동했다. 첫 화면에는 예시 6개가 있었고 새로고침해도 목록이 남았다. 평가 기준에는 빈 시작과 새로고침 초기화가 정해져 있었지만, 처음 요청에는 없던 조건이었다.

2026년 9월 27일, 가상 데이터로 짧은 요청(A)과 기준을 더한 요청(B)을 한 번씩 비교했다. 기대를 언제 알렸는지 살핀 한 쌍이며, 생산성이나 시간 절감의 증거는 아니다.

출처로 보는 기준: 무엇을 확인하면 끝인가

Scrum Alliance 용어집은 합격 기준(수용 기준, acceptance criteria)을 사용자 기대를 충족하는지 시험할 수 있는 조건으로 설명한다. 이 글에서는 이를 ‘확인 기준’이라 부르고, “공백만 제출하면 오류 문구가 보이고 목록은 그대로다”처럼 결과를 적는다.

2020 Scrum Guide의 완료 정의(Definition of Done)는 제품의 품질 조건을 충족한 상태에 대한 공통 이해다. 이 글 제목의 ‘완성의 기준’은 이 공식 개념이 아니라 한 기능의 확인 목록을 뜻한다. 두 출처 모두 AI 작업 시간 단축의 증거는 아니다.

기록된 관찰: 같은 기능, 서로 다른 정보

같은 HTML 뼈대와 빈 CSS·JavaScript 시작 파일로 로컬 앱을 한 번씩 만들었다. 둘 다 혼자 쓸 여행 준비물 목록의 추가·챙김 표시·삭제와 보기 편한 화면을 부탁했다. 외관은 채점하지 않았다. B에는 목적·사용자·동작·화면 상태·예외·제외 범위, 확인 기준 8개와 항목별 관찰 보고 지시를 더했다. 두 조건 모두 질문을 허용했고, A를 먼저 실행했다. 평가와 변경 요청은 기대를 미리 아는 별도 AI 운영 에이전트(Claude Opus 5.5)가 맡았다. A는 정해 둔 기대를 뒤늦게 알린 조건으로, 일반적인 초보자를 대표하지 않는다.

기록상 도구는 Codex CLI 0.153.4, 요청 모델은 gpt-6-astra, 추론 설정은 medium이었다. 실제 응답 모델 식별자는 보존되지 않아 두 실행의 실제 모델이 같았는지는 확인할 수 없다. macOS 27.0에서 제작했고, 운영 에이전트가 별도 Chrome 153.0.8010.53으로 화면을 확인했다(화면 창 없이 실행, 1280×900). 두 제작 에이전트의 자체 브라우저 실행은 실패했다. B는 브라우저 격리 보호를 끄는 --no-sandbox 옵션으로도 재시도했지만 실패했고, B는 모든 화면 확인을 ‘확인하지 못함’으로 보고했다. A는 실제 브라우저 대신 흉내 낸 실행 환경의 검사 통과를 보고했다. 아래 표는 제작 AI의 보고가 아니라 운영 에이전트의 브라우저 관찰이다. 보고 지시만으로 브라우저 증거가 확보되지는 않았다.

A에는 브라우저가 경고 말풍선을 띄우게 하는 코드가 있어 ‘오류 처리 자체가 없음’은 아니다. 자동 검사는 페이지 본문만 찾아 이 방식의 알림을 감지할 수 없었다. 보존된 화면으로는 그 순간 읽을 수 있는 알림이 떴는지 확정하지 못했다.

앞뒤 공백 제거, 챙김 표시를 두 번 바꿔 되돌리기, 같은 이름 두 개 중 하나만 삭제하기는 양쪽 첫 결과에서 기대대로 작동했다. 이 세부 동작은 A에 끝내 요청하지 않았으므로 브리프 덕으로 돌릴 수 없다. <b>책</b>도 A에 요청하지 않았지만 글자 그대로 보였다. 입력이 화면 코드로 해석되는지 본 한 사례로, 굵은 글씨용 HTML 요소가 생기지 않았다는 결과가 전체 보안 검증은 아니다.

A에는 빈 시작·추가 뒤 총 개수·공백 입력 오류·새로고침 초기화 네 항목의 기대와 실제를 한 메시지로 전달했다. 처음 두 항목은 예시 6개라는 같은 원인이다. 다음 결과는 빈 목록에서 시작하고, 오류 문구를 화면에 표시하며, 자동 저장을 없앴다. 처음 말하지 않은 기대를 뒤늦게 공개한 변경이며, 항목 추가 동작의 고장이나 저장 자체의 잘못은 아니다. 빈 시작과 저장 없음은 이 앱의 정책 선택이며, 어느 쪽이 여행자에게 더 유용한지는 시험하지 않았다. 보존된 수정 검사에서 A의 두 번째 결과와 B의 첫 결과는 8개 기준을 충족했다. 다만 검사 코드가 실험 전 고정본과 같지는 않다. 기준·순서·판정 규칙을 유지했다는 운영 기록은 있으나, 코드의 변경 전후 대조 근거는 불완전하다.

시간 기록: 최초 작성 비용은 모른다

두 요청 모두 미리 작성돼 있었다. 아래 시간에는 최초 작성 비용이 없으며, 두 시간의 차이는 수정 한 번에 든 시간이나 절감량이 아니다.

변경 요청·응답 1회는 여러 항목을 담은 메시지 하나와 그 응답을 뜻한다.

준비는 기존 요청 복사뿐으로, 초 단위 기록에서 약 0분이었다. 요청문과 질문 대비 답변 모음을 처음 쓴 시간, 공통 환경 준비와 확인 도구 사전 점검 시간은 모른다. 운영 에이전트가 실제 확인·기록 작업에 쓴 시간도 분리하지 못했다. 전체 제작 시간이나 절감률로 읽을 수 없다. 구독 자원은 사용했지만 실제 추가 청구액은 별도 확인되지 않았다.

기록의 한계

검사 기록에도 한계가 있다. A의 첫 자동 검사는 화면 요소를 잘못 찾아 무효가 됐고, 수정한 검사로 덮어써 원본이 남지 않았다. 운영 에이전트가 검사 도구 점검용 기준 앱을 먼저 만든 것도 계획에서 벗어났다. B가 A 폴더 이름과 무관한 지침 파일 경로를 열거하는 등 격리도 불완전했다. 상대 코드 내용을 읽은 기록은 없다. 조건별 60분 상한 전에 최종 확인으로 종료했지만, 절차를 모두 준수했다고 할 수는 없다. 세부 근거는 별도로 보관한 실험 기록(영문)에 남겼다.

작성자 판단: 다음 요청에 남길 확인 질문

A는 기대를 알리는 메시지 한 번 뒤 네 항목이 기대대로 바뀌었고 B는 변경 요청이 없었다. 그렇다고 먼저 적으면 덜 고친다는 답은 낼 수 없다. 기대와 실제를 나란히 남기는 것은 변경 내용을 설명하는 기록 습관으로 제안한다. 정보량·길이·공개 시점·검증 지시가 함께 달랐고, 평가자는 기대 결과를 미리 알고 A부터 확인했다. 실제 모델 동일 여부도 미확인이며, A에 남은 필터·진행 표시·그림의 시간 기여는 모른다. 조건당 한 번이므로 브리프의 효과나 일반적인 수정 감소를 결론 낼 수 없다. 8개 기준도 독립 실험 8회가 아니다.

아래는 복사해 채울 수 있는 한 기능용 브리프다. 효과를 검증한 양식은 아니며, 초보자의 작성 부담도 시험하지 않았다. 예시는 이 연습 앱의 선택이다.

만들 것/목적: 무엇을 하기 위한 기능인가?
사용자·기기: 누가 어디에서 쓰는가?
동작: 무엇을 누르고 입력하는가?
화면 상태: 처음·성공 뒤·잘못 입력했을 때 무엇이 보이는가?
예외: 예) 빈 입력·같은 이름·새로고침은 어떻게 처리할까?
이번엔 안 함: 예) 로그인, 저장, 동기화
확인 기준 — 입력·행동 → 기대 결과:
  정상 예) 빈 목록에 물병 제출 → 챙기지 않은 상태로 1개, 입력칸 비움
  거절 예) 공백 세 칸 제출 → 읽을 수 있는 오류, 목록 그대로
완료 보고 방식: 실행 방법과 항목별 실제 관찰을 적기.
  확인 못 한 것은 표시하고, 코드만 보고 통과라 하지 않기.

AI가 확인하지 못했다고 하면 페이지를 직접 열어 입력해 보자. 변경 요청에는 입력·행동 → 기대 → 실제를 남길 수 있다. 적은 조건도 다르게 해석될 수 있고, 기준 자체가 빠뜨린 동작도 있을 수 있다. 이번에는 한글 조합 입력·긴 글·모바일·키보드·접근성·유지보수를 확인하지 않았고, 연습용 조건 통과가 실사용 준비 완료를 뜻하지 않는다. 새 요구가 생기면 기준도 고칠 수 있다.

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

AI에게 원하는 동작을 설명하며 소프트웨어를 만드는 바이브코딩에서, 화면 생성 다음에는 무엇을 확인할까? 이 블로그에서 앞서 따로 진행한 아홉 실험·점검 기록을 다시 읽었다. 새 실행이나 하나로 연결한 제작 과정은 없으며, 2026년은 기록의 시점이지 시장 변화나 작년보다 나아진 정도를 뜻하지 않는다.

새로고침 뒤에도 기록이 보인다면, 정말 저장된 걸까? 저장 실험의 별도 브라우저 시연에서는 페이지를 강제로 다시 불러온 뒤 브라우저 안의 세 저장 공간(sessionStorage·localStorage·IndexedDB)에서 기록이 다시 보였다. 메모리에만 두거나 쓰기를 버리는 조건(drop-write)에서는 기록이 비어 있었다. 새로고침 성공만으로 서버에 저장됐다고 판단할 수는 없었다. 당시 관찰 기록을 근거로 했으며, 이번 종합에서는 브라우저의 원본 화면·동작 기록으로 별도 확인하지 않았다. 페이지를 다시 불러오는 일과 서버 프로그램을 껐다 켜는 일, 브라우저 자체를 종료했다 여는 일은 서로 다른 검사다.

자료의 범위: 하나로 이어진 작업 과정은 아니다

근거는 2026년 9월 5~20일의 선행 실험·점검 기록이며, 9월 27일 이 블로그의 실험 기록 폴더에서 대조했다. 원고의 검증·편집은 보존된 기록과의 대조이며, 실험을 다시 실행한 것은 아니다. 결과는 당시 환경과 입력에 한정된다.

‘다시 사용하기’, ‘맡기고 받아들이기’, ‘화면에서 확인한 것, 전달 전에 남은 것’은 읽기 위한 분류이며, 숙련 단계나 연결해 검증한 제작 과정은 아니다. 실제 실행, 전제 확인 중 중단, 서비스 호출 없는 리허설이 섞여 있어 통과 수를 합쳐 성공률을 낼 수도 없다.

관찰: 다시 사용하기

저장 실험에는 앞의 브라우저 시연과 별개로, 로컬 서버와 SQLite 데이터베이스를 확인한 실행이 있다. SQLite는 이 실험에서 서버 쪽 기록을 보관한 데이터베이스다. 실제 로그인 대신 요청에 가상의 사용자 식별 정보(합성 헤더)를 붙인 조건이었다. 지정한 저장·수정·삭제와 서버 프로그램을 한 번 껐다 켠 뒤의 상태가 각각 독립 SQLite 검사와 일치했다. 이 성공은 실행한 검사에 한정되며, 배포 검사는 실행하지 않았다.

다만 다른 기기에서 열기, 외부 서버에 배포하기, 브라우저 자체를 종료했다 다시 열기는 확인하지 않았다. 기존 정보가 없는 새 브라우저 프로필의 화면, 백업, 실제 서비스의 로그인·보안도 검증 범위 밖이다. 브라우저 시연과 데이터베이스 검사는 서로 다른 곳에 남은 기록을 서로 다른 조작 뒤에 확인했으므로 증거를 섞으면 안 된다.

절차 재사용 실험에서는 같은 업무 설명 파일을 복사한 새 대화에서 파일 로딩을 확인했다. 그러나 로딩 성공이 더 정확한 답을 뜻하지는 않았다. 일반 요청, 본문에 절차를 넣은 요청, 도구에 마련된 절차 호출 기능인 스킬을 명시적으로 부른 요청의 주요 답변 12개가 모두 사실 항목을 통과했다. 별도의 암묵적 호출 진단 두 개는 이 12개에 포함하지 않았다. 모두 통과해 사실 점수의 이점은 관찰되지 않았지만, 세 방식의 효과가 같거나 파일이 도움이 되지 않는다고 입증한 것은 아니다.

가상의 한국어 사례 두 개를 조건별로 한 번씩 AI가 실행·채점한 비교이므로, 장기 기억이나 학습 효과, 시간 절약으로 넓혀 말할 수 없다.

필자의 판단은 “다시 된다”의 뜻을 구체화하자는 것이다. 저장은 어디서, 어떤 재시작 뒤에 확인했는가? 절차는 새 대화에서 읽혔는가, 답의 개선도 측정했는가?

관찰: 맡기고 받아들이기

숨겨 둔 버그를 찾는 실험에서는 업무 규칙만 보고 만든 테스트 묶음을 버그가 없도록 준비한 정상 기준 앱에 적용했다. 실행 가능한 다섯 검사 중 두 개만 통과했다. 결함을 얼마나 잡는지 채점할 자격을 갖추지 못한 것이다. 이를 ‘버그를 하나도 못 찾았다’는 점수로 바꿀 수는 없다.

규칙과 앱 코드를 함께 본 테스트 묶음은 정상 기준에서 여덟 검사를 모두 통과했고, 실험자가 넣어 두고 생성 모델에게는 숨긴 세 결함을 잡았다. 실제 탐지 결과다. 다만 각 조건에서 한 번 생성했으므로 조건의 우열이나 코드 접근이 탐지 성공의 원인이라는 점은 입증하지 못한다.

코드를 함께 본 테스트 묶음을 기능 추가 뒤에 다시 적용하자 한계가 드러났다. 올바르게 기능을 추가한 앱과 새 결함이 있는 앱에서 여덟 검사 중 똑같은 다섯 개가 실패했다. 기존 결과의 모양과 정확히 같아야 한다는 검사가 정상적으로 추가된 메모 항목까지 거부했기 때문이다. 이 실패만으로는 기능 변경 뒤 생긴 오류인 회귀 결함을 정상 변경과 구별해 잡았다고 볼 수 없었다.

별도로 준비한 정답 검사는 메모가 사라져야 할 때 남는 결함을 구별했지만, 그 성과를 생성된 테스트에 돌릴 수는 없다. 처음의 세 결함 탐지 성공도 그대로 남는다.

정해진 시간에 작업을 돌리도록 설정하는 AI, 즉 예약형 에이전트에 관한 기록은 다른 종류의 근거다. 실제 예약이나 AI 모델 호출 없이, 미리 정한 사례를 로컬에서 재생한 리허설이었다. 검증 프로그램은 의도한 입력과 다른 데이터 사본(스냅샷)에 묶인 보고서 초안을 거부하고 따로 격리했다. 거부한 주체는 정해진 규칙대로 작동한 검증기다. AI가 스스로 잘못된 입력을 알아챘거나 실제 예약 서비스가 안정적으로 작동했다는 관찰은 아니다.

두 사례에서 결과물 생성과 검수는 분리돼 있었다. 필자의 판단으로는 먼저 테스트가 정상 기준 앱을 통과하는지 확인하고, “검사가 실패했는가” 다음에 “정상 변경과 잘못된 변경을 구별했는가”를 물을 필요가 있다. 보고서라면 어느 입력에서 나왔고 누가 어떤 기준으로 받아들였는지가 다음 질문이다.

관찰: 화면에서 확인한 것, 전달 전에 남은 것

채팅 안에 앱을 띄우는 대화형 앱 실험은 실험용 컴퓨터의 공식 로컬 참조 호스트에서 수행했다. 한국어·영어 입력에 반응하고 합계가 90에서 100으로 바뀌었다. 같은 실행 중인 프로그램과 같은 세션에서 화면을 새로 띄웠을 때 저장값도 복원됐다. 여기까지는 실제 상호작용의 성공이다. 서버 재시작이나 다른 기기에서도 남는 저장을 뜻하지는 않는다.

지원하지 않는 언어 코드에서는 실제 실패가 있었다. 서버는 경고와 함께 영어 결과를 보냈지만 화면은 경고 없이 한국어를 표시했다. 성공한 입력·복원과 이 불일치를 함께 남겨야 한다. 다른 검사에는 절차가 무효여서 판정에서 제외한 세 항목과 아예 시험하지 않은 여섯 항목도 있었다. 어느 쪽도 앱 실패로 세지 않는다. 상용 채팅 서비스 안에서의 동작이나 모델이 전달 내용을 실제로 받았는지도 이 결과가 증명하지 않는다.

생성형 디자인 실험에서는 문장 입력과 직접 그린 디지털 주석 와이어프레임을 한 번씩 실행했다. 와이어프레임은 캔버스에 도형과 글자로 화면 구조를 표시한 실험용 자료다. 종이에 그린 그림이나 초보자의 제작 경험을 시험한 것은 아니다. 두 결과는 정해 둔 세 화면·두 이동 경로와 세 번의 수정을 충족했다. 텍스트를 먼저 실행했고, 만들어진 선택 방식(목록·버튼)과 일부 빈칸 입력 검사 조건은 달랐다. 어느 입력이 더 낫다는 순위는 낼 수 없다.

수정 방식도 하나가 아니었다. 첫 수정은 요소에 직접 반영됐고, 다음 두 수정은 관련 화면 일부를 다시 생성했다. 마지막 지시는 버튼 이름을 유지하면서 이동 위치만 바꾸라는 것이었다. 결과는 지시를 따랐지만 공간 목록으로라는 이름과 실제 목적지가 어긋났다. 실험 지시가 의도적으로 남긴 불일치이며, 요청한 수정을 수행하지 못한 실패는 아니다. 도구가 의미 충돌을 알아챘는지는 이 결과로 알 수 없다.

이 사례에서 필자가 주목하는 것은 지시 충족과 화면 의미의 관계다. 요청대로 바뀌었더라도 버튼 이름과 목적지가 맞는지는 별도로 볼 수 있다. 또한 내보내기를 하지 않았으므로 전달 가능한 코드나 운영 준비 상태는 확인하지 않았다. 대화형 앱의 참조 호스트와 디자인 캔버스에서 각각 움직임을 확인했지만, 둘을 연결해 배포하거나 휴대전화로 넘겨 본 과정은 없다.

실행 전에 멈춘 세 기록

다음은 제품이 동작하다 실패한 결과가 아니다. 실험을 시작하기 위한 전제를 서로 다른 범위에서 확인하다 멈춘 기록이다.

휴대전화 점검 목록에 있던 꺼진 시뮬레이터는 실제 휴대전화 실행의 증거가 아니다. 한 경로는 전제가 미입증이었고 다른 경로는 당시 환경에서 자격 조건을 충족하지 못했다. 모든 환경에서 경로가 없다는 뜻은 아니다.

이 중단은 제품의 안전성이나 이용 가능성에 대해 어느 방향의 판정도 뒷받침하지 않는다. 반대로 대화형 앱의 언어 불일치는 실제로 실행해 관찰한 실패다. ‘모른다’고 남길 자리와 ‘실패했다’고 기록할 자리를 구분하는 것도 이번 종합의 중요한 부분이다.

판단: 다음 요청에 붙일 확인 질문

이 기록들은 절차 재사용, 저장, 검수와 화면 동작을 다뤘다. 사례를 잇는 전달·배포 과정은 시험하지 않았다. 이들을 함께 읽는 것은 편집적 해석이며, 시장 변화나 완성된 운영 방식의 검증이 아니다.

기록에서 도출해 다음 작업에 붙여 볼 질문은 다음과 같다.

• 어떤 조작 뒤에, 어느 저장 위치에서 결과를 확인했는가?
• 테스트 묶음은 버그가 없는 기준 앱을 통과하는가?
• 기능 변경 뒤의 검사는 정상 변경과 잘못된 변경을 구별하는가?
• 결과를 받아들이는 사람이나 프로그램은 어떤 입력과 기준을 대조하는가?
• 수정 뒤 버튼을 눌러 보면 이름과 도착 화면이 맞는가?
• 실제로 사용할 환경과 전달 단계도 시험했는가?
• 실행 전 조건을 못 갖춘 기록은 제품 실패와 구분했는가?

이는 기록에서 도출한 편집적 제안이다. 실제 문제를 얼마나 줄이는지는 측정하지 않았다.

아래 제목은 앞서 공개한 관련 글로 연결되는 읽을거리 링크이며, 원시 증거나 현재 제품 기능을 입증하는 자료는 아니다. 이번 종합이 근거로 삼는 관찰과 실행하지 않은 범위는 링크가 아니라 이 글의 본문과 표에 담았다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

이번 비교는 종이 그림이나 사진이 아니라, 빈 캔버스에 도형과 글자를 배치한 실험용 직접 그린 디지털 주석 와이어프레임과 같은 요구의 텍스트 명세를 사용했다. 사람의 손그림이나 초보자의 제작 경험을 시험한 것은 아니다. 이미지 경로도 두 경로의 공통 화면 크기·키보드·확대와 실제 예약·네트워크 요청 없이 화면 안에서만 움직인다는 조건을 텍스트로 받았다. 화면·문구·규칙은 이미지에 담았다.

가상의 공용 작업실 예약 흐름은 첫 화면에서 공간을 고르고, 두 번째 예약 정보 화면에서 시간과 인원을 입력한 뒤, 세 번째 예약 확인 화면에서 선택값을 확인한다. 질문은 “무엇이 더 좋은가”가 아니라 “같은 화면·연결·검증 규칙을 얼마나 구현하고 수정하는가”였다.

공식 설명: 무엇을 할 수 있다고 하나

Google Labs의 UI 생성 도구 Stitch는 자연어와 이미지로 UI 디자인과 프런트엔드 코드를 만들 수 있다고 발표됐다. 이후 이미지·텍스트·코드를 맥락으로 쓰고 자연어로 수정하며 여러 화면을 연결할 수 있다고 설명했다. CSS/HTML과 Figma 전달 방법도 발표됐다. 그러나 기능 설명과 특정 입력의 성공 증거는 다르다. 아래는 2026년 9월 20일의 관찰이다.

직접 관찰: 한 번씩, 재시도 없이

Stitch 웹의 로그인된 비공개 프로젝트에서 기기 유형은 앱, 모델 모드는 Balanced였다. 텍스트를 먼저, 와이어프레임을 다음에 넣었다. 각 경로는 기본 생성 1회와 수정 E1~E3를 각각 1회만 수행했다. 생성·수정 요청은 모두 8회였고 재시도와 반복 실험은 없었다.

이 실험용 한국어 명세에서 두 결과 모두 3개 화면과 6개 버튼·입력 요소, 두 이동 경로를 만들었다. 시간 미선택, 인원 범위 이탈, 마감 시간의 오류와 정상 회복도 정한 범위에서 작동했다. 키보드 조작, 조작 요소와 연결된 이름, 브라우저 200% 확대도 제한적으로 확인했다. 다만 텍스트 결과는 인원 입력을 비우면 즉시 2를 되살려 빈 값 오류를 시험하지 못했고, 와이어프레임 결과에서는 확인했다. 같은 요구도 전자는 선택 상자, 후자는 두 라디오 버튼으로 구현됐다. 경로당 한 번의 결과일 뿐 입력 방식의 점수나 우위가 아니다.

수정 방식도 달랐다. E1의 버튼 문구는 두 경로 모두 해당 요소에 바로 반영됐다. E2의 검증 문구 추가와 E3의 화면 연결 변경은 관련 화면 요소 묶음을 새로 만드는 부분 재생성이었다. 바꾸라고 하지 않은 문구·경로·상태에서는 회귀가 보이지 않았지만, 모든 픽셀이나 숨은 상태를 검사하지는 않았다.

E3는 편집자의 확인 지점을 보여 줬다. 지시는 선택한 시간과 인원을 유지하면서 버튼 목적지만 두 번째 화면으로 바꾸고 문구는 유지하라는 것이었다. 두 결과 모두 기능 조건을 통과했지만 버튼 이름은 계속 공간 목록으로였다. Stitch가 문구 수정을 놓친 것이 아니라, 시험 설계에서 의도적으로 남긴 이름과 이동 위치의 불일치다.

사용량(크레딧) 표시는 실행 전 0 / 400, 마지막 관찰에서 12 / 400이었다. 400은 화면에 표시된 허용량이다. 중간 값이 늦게 갱신돼 요청당 크레딧을 계산하지 않았고, 마지막 수치가 최종 요청까지 반영했는지도 단정하지 않는다. 실행 중 화폐 결제나 구매·체험 안내는 나타나지 않았다.

이미지 업로드 때는 HTML 내보내기를 위해 이미지에 안정적인 공개 URL이 생긴다는 안내가 표시됐다. 비공개 프로젝트도 이 안내를 없애지 않았다. 이번에는 민감한 내용이 없는 합성 와이어프레임 한 장에만 동의하고 업로드했다. 이 관찰만으로 공개 목록 노출, URL 발견 가능성, 보존 기간, 기밀성, 모델 학습·처리 사용 여부를 알 수 없다. 민감하거나 식별 가능한 자료는 조건을 확인하기 전에 올리지 않는 편이 안전하다.

판단: 프로토타입 관찰과 전달 검증은 다르다

이번 한 번씩의 실행에서는 두 입력 모두 연결형 프로토타입과 세 번의 수정을 충족했다. 그러나 E3의 레이블 부채가 남아 쓸 준비가 됐다고 할 수 없다. 반복 실행이 없고 생성된 조작 요소도 달랐으므로 입력 방식의 우열이나 성공률도 말할 수 없다. 키보드·이름·확대 확인 역시 일부 미리보기 항목의 관찰일 뿐, 더 넓은 접근성 준수 판정이 아니다.

내보내기와 다운로드는 실험 설계에서 제외했다. 화면의 내보내기 조작은 누르지 않았고 파일, 프런트엔드 코드, 의존성, 로컬 실행을 확인하지 않았다. 개발 전달은 실패가 아니라 not_tested, 즉 시험하지 않은 상태다. 공식 발표나 버튼만으로 이 공백을 메울 수 없다.

비슷한 도구를 시험할 때의 체크리스트

• 두 입력에 같은 화면, 문구, 경로, 오류 조건을 먼저 고정한다.
• 수정할 대상과 바뀌면 안 되는 대상을 함께 적는다.
• 수정 뒤 버튼 이름과 실제 이동 위치가 맞는지 확인한다.
• 빈 값·범위 밖 값·정상 회복과 키보드·확대 상태를 직접 눌러 본다. 키보드와 확대는 기본 점검이지 접근성 판정이 아니다.
• 수정이 요소 직접 변경인지 부분 재생성인지 구분한다.
• 크레딧 갱신과 이미지 URL·데이터 처리 조건을 입력 전에 확인하고, 확인 전에는 민감정보를 올리지 않는다.
• 미리보기 성공과 파일 전달 검증을 별도 항목으로 남긴다.

이런 UI 생성 도구는 연결된 화면을 미리 움직여 보는 데 유용할 수 있다. 그래도 동작과 레이블이 맞는지, 확인하지 않은 단계가 무엇인지는 따로 기록해야 한다. 이번 실험의 유용한 산출물은 승자표가 아니라 그 경계선이었다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

이번에는 앱을 생성하기도 전에 멈췄다. 그래서 실제 휴대폰에서 앱을 돌리는 단계까지 가지 못했다. 미리 정해 둔 두 가지 휴대폰 연결 방법 중 어느 것도 준비됐다는 증거가 없었기 때문이다.

그래서 이 글은 “프롬프트로 만든 앱이 휴대폰에서 잘 됐다”거나 “실패했다”는 사용기가 아니다. 미리보기 화면을 실제 휴대폰 검증으로 착각하지 않으려면, 코드를 만들기 전에 무엇부터 확인해야 하는지를 기록한 한계 보고서다.

‘앱을 만들었다’에는 다섯 단계가 숨어 있다

말로 화면을 생성하고 미리보기가 뜨면 앱이 완성된 것처럼 느껴진다. 하지만 실제 휴대폰이라는 기준을 넣으면 단계가 나뉜다.

1. 생성: AI가 요구사항을 소스 코드로 만든다.
2. 빌드: 코드를 휴대폰 쪽에서 받아들일 수 있는 형태로 묶는다.
3. 설치 또는 열기: 만든 앱 전용 개발 버전을 설치하거나, 이미 휴대폰에 있는 Expo Go라는 앱 안에서 프로젝트를 연다.
4. 실제 휴대폰 도달: 방금 생성한 바로 그 코드 버전(리비전)이 휴대폰 화면에 뜬다.
5. 사용성 확인: 손가락, 실제 키보드, 긴 한글, 다시 열기 조건에서 같은 흐름을 반복한다.

Expo의 AI 빌드 튜토리얼은 AI 코딩 에이전트로 프로젝트를 만들고 휴대폰에서 여는 공식 경로를 소개한다. 개발 시작 안내는 개발 서버의 QR 코드로 물리적 기기에서 프로젝트를 여는 흐름을 설명한다. 그러나 Expo의 워크플로 안내가 구분하듯 Expo Go는 학습과 프로토타이핑용 제한된 실행 환경이다. 그 안에서 열렸다는 사실은 앱스토어용 빌드가 완성됐다는 뜻이 아니다.

원래 하려던 실제 휴대폰 시험

시험 대상은 서버와 로그인, 개인정보, 권한 요청이 없는 오프라인 한글 체크리스트가 될 예정이었다. 미리 정해 둔 같은 문구로 항목을 추가하고, 수정하고, 완료 표시한 뒤 삭제하는 흐름을 세 번 반복하도록 설계했다.

그 다음에는 키보드를 연 채 저장 버튼을 다섯 번 누를 수 있는지, 핵심 터치 영역이 iOS의 44×44포인트 또는 Android의 48×48dp 라는 손가락 터치 크기 지침을 충족하는지, 긴 한글과 한글·영문·숫자 혼합 문장이 깨지지 않는지 확인할 계획이었다. 배경 전환, 앱 화면 다시 불러오기, 완전 종료 후 세 번 다시 열기도 서로 다른 항목으로 나눴다.

이 숫자들은 결과가 아니다. 실행 전에 고정한 판정 기준이다. 실제 휴대폰 화면, 탭 기록, 저장 상태는 한 건도 수집되지 않았고, 계획했던 두 사람의 탐색적 사용 기록도 받지 않았다.

실행 전에 확인된 것

2026년 9월 13일, 로컬 환경을 변경하지 않는 범위에서 도구와 설정 존재 여부를 점검했다.

시뮬레이터, 즉 컴퓨터 화면 안의 가상 휴대폰은 화면 모양을 일부 확인할 수 있지만 이번 질문의 답은 아니다. 실제 휴대폰의 손가락 조작과 키보드, 물리적 기기 상태를 대신할 수 없기 때문이다. 그래서 시뮬레이터를 켜서 빈칸을 채우지 않았다.

한 경로는 미확인, 다른 경로는 현재 환경에서 부적합

첫 번째 경로는 휴대폰에 이미 설치된 Expo Go를 같은 네트워크(LAN)에서 여는 방법이었다. 하지만 휴대폰에 Expo Go가 있는지, 그 버전이 프로젝트와 맞는지, 외부 중계 없이 같은 네트워크로 바로 연결되는지, 개인정보가 화면에 찍히지 않게 기록할 수 있는지가 모두 확인되지 않았다.

두 번째는 Android 휴대폰을 USB로 연결하는 방법이었다. 다만 이미 준비돼 있을 때만 쓰기로 한 경로였는데, 현재 환경에는 Android SDK와 ADB, 사용할 수 있는 Java 실행 환경이 없었다. 이를 채우려면 설치나 설정이 필요했다. 휴대폰 신뢰 연결 상태도 확인하지 않았다.

판정은 실행 능력이 입증되지 않아 시작하지 않음(NO_GO_CAPABILITY_NOT_PROVEN)이었다. 앱을 만든 뒤 휴대폰에 도달하는 과정에서 막힌 경우나 앱 기능이 틀린 경우와는 다르다. 생성된 첫 코드 버전 자체가 없었기 때문이다.

빈칸을 대체 증거로 메우지 않은 이유

Expo 명령을 실행하거나 Android 도구를 설치하면 다음 단계로 갈 가능성은 있다. 하지만 다운로드와 환경 변경이 생길 수 있다. 휴대폰을 잠금 해제하거나 연결·신뢰·권한을 승인하는 것도 별도의 기기 행동이다. 계정이나 서명이 필요한 빌드·배포 서비스와 앱스토어 경로는 이번 안전 경계를 벗어난다.

움직이지 않는 화면 그림이나 컴퓨터 안의 모의 앱도 만들지 않았다. 그것은 설명 자료는 될 수 있어도 “말로 만든 그 코드 버전이 실제 휴대폰에서 작동했다”는 증거는 아니다. QR 코드, 빌드 로그, Expo Go 첫 화면, 시뮬레이터 화면 역시 실제 휴대폰에서 생성 앱 화면에 도달했다는 증거를 대신하지 못한다.

독자가 먼저 확인할 세 가지

직접 비슷한 실험을 한다면 코드를 만들기 전에 다음 세 가지를 따로 확인하는 편이 낫다.

• 경로: 휴대폰에 Expo Go 같은 앱이 이미 있는가, 그 버전이 지원하는 SDK에 맞춰 프로젝트를 만들 수 있는가, 같은 네트워크로 직접 연결하는지 외부 중계를 거치는지 기록할 수 있는가.
• 경계: 로그인, 결제, 서명, 스토어, 새 권한이나 기기 신뢰 요청이 나오면 어디서 멈출 것인가.
• 증거: 방금 생성한 그 코드 버전이 실제 휴대폰의 앱 화면에 떴는가. 그 뒤에야 기능, 키보드, 터치, 한글, 다시 열기를 센다.

현재 가장 작은 다음 조건은 이미 Expo Go가 설치된 휴대폰에서, 설치·로그인·결제·새 권한 없이 휴대폰의 Expo Go 버전과 같은 네트워크(LAN)로 연결되는 경로를 확인하는 것이다. 그 뒤 그 버전에 맞는 프로젝트 SDK와 개인정보가 찍히지 않는 화면 기록 가능성을 함께 증명해야 한다. Expo Go가 없는 휴대폰이라면 이 조건이 아직 성립하지 않는다는 뜻이지, 설치하라는 뜻이 아니다. 이것은 이번 글에서 수행한 행동이 아니라, 다음 실행을 열기 위한 조건이다.

따라서 제목의 질문에는 아직 “된다”도 “안 된다”도 답할 수 없다. 앞으로 시험을 통과하더라도 그 결과는 기록한 한 대의 휴대폰과 설정, 그 날짜에만 해당한다. 이번 중단이 뒷받침하는 교훈은 더 좁다. 생성 버튼을 누르기 전에 실제 휴대폰 경로의 증거가 필요하며, 그 증거가 없으면 앱 결과를 꾸며내지 않고 멈춰야 한다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.

예약 실행을 믿는다는 건 결과 문장이 그럴듯하다는 뜻이 아니다. 어떤 입력을 읽었고, 허용된 일만 했으며, 검사를 통과했고, 필요할 때 멈췄다는 기록을 다시 확인할 수 있는가가 이 글에서 말하는 신뢰다.

이 구분이 필요한 이유는 간단하다. 일정이 등록됐고, 작업이 끝났고, 보고서 파일이 쓰였고, 그 내용을 믿어도 된다는 말은 서로 다른 상태다. 2026년 9월 12일에 확인한 OpenAI Scheduled tasks 안내는 저장된 프롬프트와 실행 시점을 구분하고, 로컬 파일을 쓰는 데스크톱 작업의 조건을 설명한다. 또한 좁은 권한과 초기 실행 검토를 권한다. 다만 확인한 페이지에는 결과 정확성, 일반적인 재시도·겹침 동작, 실행당 비용 상한, 보편적인 중간 취소 계약이 제시돼 있지 않았다. 그래서 실제 일정을 켜는 대신, 합성 데이터와 논리시계—실제 시간을 기다리지 않고 고정된 사건 목록을 차례로 진행하는 방식—로 운영 장치를 먼저 연습했다.

그럴듯한 어제 보고서

실제 AI 호출은 없었다. 핵심 장면은 정해진 규칙대로 문장을 만드는 후보 생성기로 일부러 만든 ‘낡았지만 자연스러운’ 보고서였다. 검증기가 기대한 입력은 SYN-20260902였지만 후보가 실제로 읽은 것은 SYN-20260901이었다. 낡은 파일을 바탕으로 만든 보고서는 내부적으로 그럴듯해서 문장만 보면 이상하지 않았다.

하지만 작성은 승인과 달랐다. 독립적으로 고정한 기대 snapshot ID와 입력 해시를 후보가 기록한 실제 값과 비교하자 검증 기록에 binding_mismatch가 남았다. 후보는 accepted 폴더로 가지 못하고 quarantine으로 옮겨졌으며, 보고서를 받아 볼 사람이 보게 될 결과는 rejected_binding_mismatch 라벨의 거절 기록이었다. 이 한 건은 AI의 신뢰도를 보여주는 비율도, AI가 낡은 입력을 알아봤다는 증거도 아니다. 심어 둔 검증 장치가 낡은 입력을 거절했는지 확인한 통제 사례다.

실제 일정 없이 무엇을 시험했나

실험은 외부 모델을 부르지 않는 고정형 후보 생성기(canned deterministic candidate)를 사용했다. 실제 AI의 글쓰기 능력이 아니라 반복 작업을 둘러싼 로컬 실행 장치(wrapper)와 검증기(verifier)를 살펴보기 위해서다. 트리거 역할의 실행기(driver)는 미래 시간을 기다리지 않고 유한한 사건 목록에서 논리시계만 진행했다. 후보 생성기는 실행기가 고른 합성 JSON과 실행 ID를 받았다. 검증기는 따로 고정한 입력 식별값과 정답표(content oracle)를 이용해 입력 identity와 count/change를 대조했다. 검사를 통과한 경우에만 저장기(writer)가 staging 결과를 승인된 최종 산출물(authoritative artifact)로 승격했다.

종이에 허용한 범위, 실제로 막은 통로, 남긴 기록도 서로 다르다. 작업 명세는 읽기·쓰기 범위를 정했고, 로컬 wrapper는 후보 생성기에 network·browser·subprocess·scheduler·provider 통로를 제공하지 않았다. ledger는 wrapper가 관찰한 결정을 남겼다. 이것은 OS 격리나 vendor sandbox를 증명하지 않는다. 이 제한은 후보 생성기에 관한 것이며, wrapper 자체는 파일을 썼다. 실험은 read-only가 아니라 read-centered였다. 실행 루트에는 baseline, staging, verifier, accepted, rejected, quarantine, ledger, inventory, summary 산출물이 기록됐다.

12개 case의 결과

12개 case는 하나의 점수로 평균 내지 않고, 고정된 기대 결과와 각각 비교했다.

• 승인: fresh baseline, 같은 날짜의 변경된 현재 snapshot, 새 날짜의 no-change 보고서는 검증 뒤 accepted가 됐다.
• 시작 전 차단: 누락·schema 오류는 후보 실행 전에 막혔고, 같은 작업이 두 번 도착한 경우에는 두 번째 산출물이 생기지 않았다.
• 충돌과 재시도: 다른 binding의 겹친 요청은 conflict로 기록됐고 원래 binding이 accepted로 남았다. staging 뒤 심어 둔 일시 오류는 첫 결과를 격리한 뒤 모의 재시도 한 번으로 accepted가 됐다. 계속되는 오류는 retry ceiling에서, 재시도하지 않기로 정한 오류는 stopped_nonretryable 이유로 멈췄다.
• 별도 중단: C10의 심어 둔 case-local 예산 거절은 후보 실행 전 0회에서 stopped_local_budget으로 끝났다. future-run stop, active-local interruption, 모의 read-policy 회수도 서로 다른 이유로 기록됐다.

12개 논리 case가 모두 고정된 기대 disposition과 일치했다. 후보 호출은 계획한 11회였고 전체 series의 hard ceiling 20회를 넘지 않았다. C10의 시작 전 거절은 이 20회를 소진했다는 뜻이 아니다. 전체 재생 실행은 25.229ms였으며, 앞 기록과 이어져 변경을 드러내는 hash chain을 가진 ledger 47행이 검증됐다. 이 숫자는 빠른 실제 업무를 뜻하지 않는다. 작은 로컬 fixture와 고정형 후보 생성기의 실행 시간일 뿐이다.

중단은 하나의 버튼이 아니었다

‘앞으로의 실행 막기’는 due event 전에 저장된 marker와 이후 작업 부재로 확인했다. ‘진행 중인 로컬 단계 끊기’는 중단 요청과 확인, partial quarantine, 승격 부재로 확인했다. ‘모의 로컬 읽기 권한 회수’는 새 policy hash를 source 접근 전에 평가했고 cached fallback을 만들지 않았다. 어느 것도 vendor queue, 원격 실행 취소, 계정 권한 회수를 시험한 것은 아니다.

비용 기록은 왜 다섯 줄인가

• provider 호출: wrapper 경계에서 0회
• 추가 청구 관찰: billing 화면에 접근하지 않아 not_checked
• usage 값: unavailable
• local invocation ceiling: 20회이며 이 driver가 통제한 한계
• provider가 강제한 cap: not verified

따라서 “비용 0”이라고 말할 수 없다. 20회 ceiling도 provider 예산 상한이 아니다. 내가 통제한 한계만 강제할 수 있으며, 기록에도 그 경계를 밝혀야 한다.

예약 전에 답할 일곱 질문

반복 자동화를 켜기 전에 다음을 한 줄씩 답해 볼 수 있다.

1. 정확히 어떤 입력을 읽는가?
2. 허용된 행동과 금지된 행동은 무엇인가?
3. 후보와 승인된 결과는 어디에 따로 저장되는가?
4. 성공을 무엇으로 검증하는가?
5. 내가 실제로 강제할 수 있는 비용·호출 상한은 무엇인가?
6. 어떤 오류만 몇 번 재시도하는가?
7. 미래 실행, 진행 중 단계, 읽기 권한을 각각 어떻게 멈추는가?

빈칸이 있다면 그것은 모델의 지능 문제가 아니라 운영 설계의 빈칸이다. 이번 실험에서 말할 수 있는 결론도 조건부다. 이 local wrapper와 verifier는 고정된 synthetic case에서 명세대로 움직였다. 시험하지 않은 것(NOT TESTED): AI 출력 동작, 실제 예약 실행, vendor의 trigger·retry·overlap·cancel·delivery, OS/vendor isolation, distributed exactly-once delivery, zero cost, provider spending cap, 실제 활성화 준비도.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.