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회가 아니다.
다음 표는 화면 기준 아홉 가지 중 저장 상태 하나이며 전체 품질 점수가 아니다.
| 실제 저장 상태가 기대와 맞는가 | 충족 | 실패 | 미확인 | 대상 |
|---|---|---|---|---|
B0 화면 |
14 |
14 |
8 |
36 |
B0 직접 요청 |
20 |
16 |
0 |
36 |
R1 화면 |
32 |
0 |
4 |
36 |
R1 직접 요청 |
36 |
0 |
0 |
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개 예정 관찰을 갖는다. ‘수용’은 입력 처리 관찰이며 화면 재열기까지 모두 충족했다는 뜻은 아니다.
| 조건 | 수 | B0 → R1 관찰 |
|---|---|---|
C01 정상 생성 Workshop cards |
1 |
두 경로 정확히 저장 → 유지, R1 화면 재열기도 확인 |
C02 제목 빈칸·공백 세 개 |
2 |
화면 차단/거절, 직접 요청 거절 → R1 두 경로 거절, 화면 수정·재열기 확인 |
C03 빈 메모 |
1 |
두 경로 빈 값 수용 → 유지 |
C04 제목 앞뒤 공백 두 개 |
1 |
공백까지 저장, 정리 안내 없음 → 일반 공백만 제거하고 안내 |
C05 기존 Paper pack과 동일 / 앞뒤 공백·다른 메모 |
2 |
두 경로 중복 생성 수용 → 모두 거절 |
C06 같은 제목, 날짜만 2026-10-02 |
1 |
두 경로 별도 기록 수용 → 유지 |
C07 빈 날짜 |
1 |
두 경로 저장 → 거절 |
C08 2026-02-30, 2026-02-29 |
2 |
두 경로 저장 → 거절, 지정 날짜로 수정 |
C09 2028-02-29 |
1 |
두 경로 정확히 저장 → 유지 |
C10 03/04/2026, 2026-2-03 |
2 |
두 경로 저장 → 거절; 각각 2026-03-04, 2026-02-03으로 시험자가 수정 |
C11 연도 범위의 양 끝 / 바깥 하루 |
4 |
2026-01-01, 2028-12-31 수용 유지; 2025-12-31, 2029-01-01 저장 → 거절 |
C12 제목 A·가 각각 40/41자 |
4 |
두 경로 40자 수용 유지; 41자 저장 → 거절 |
C13 메모 A·가 각각 200/201자 |
4 |
두 경로 200자 수용 유지; 201자 저장 → 거절. R1 목록의 줄임 표시는 재열기에서 원문 확인 |
C14 메모 =1+1 |
1 |
두 경로 일반 문자열로 저장 → 유지. 이 앱의 해당 값 관찰이며 내보내기·다른 수식 문자열 안전성은 미시험 |
C15 분류/세부 분류 각각 빈칸· other |
4 |
직접 요청은 모두 거절 유지. B0 화면 4개 모두 정확한 입력 불가; R1 화면 3개 불가, 빈 세부 분류는 거절했으나 수정 가능·복구 미확인 |
C16 supplies/chairs 불일치 |
1 |
직접 요청 거절 유지; 두 버전 화면에서는 정확한 조합 입력 불가 |
C17 기존 기록을 2026-02-30으로 수정 |
1 |
B0 직접 요청은 저장, 화면은 미확인 → R1 두 경로 거절·원기록 유지 |
C18 다른 기록과 제목·날짜·분류 쌍 충돌 |
1 |
B0 직접 요청은 저장, 화면은 미확인 → R1 두 경로 거절 |
C19 자기 기록의 메모만 revised note로 수정 |
1 |
B0 직접 요청은 같은 ID 수정, 화면은 미확인 → R1 두 경로 같은 ID 수정 |
C20 빈 제목+ 2026-02-30, 메모 유지 |
1 |
B0 화면 두 오류 설명 실패, 직접 요청 거절 → R1 두 경로 거절, 화면 두 오류 설명·한 번 수정 저장 확인 |
중복 기준은 네 항목으로 정했지만 세부 분류만 바꾼 정상값 등으로 각 항목의 역할을 따로 검증하지는 않았다. C04는 Workshop cards 의 양끝 U+0020 공백 제거와 나머지 필드 유지를 확인한 사례다. 반복된 내부 공백, 공백뿐인 메모, 다른 종류의 가장자리 공백은 별도로 시험하지 않았다.
분류의 허용 쌍은 supplies/paper, supplies/pens, space/chairs, space/tables다. 중복 판정에서는 메모를 제외한다. 제목 정리는 양끝의 일반 공백(U+0020)만 허용하며, 대소문자·내부 공백·한글 표현을 임의로 바꾸도록 한 규칙이 아니다.
항목별 분모
아래 각 셀은 충족 / 실패 / 미확인 순서다. 대상 수에는 미확인이 포함된다. 직접 요청에는 화면 설명·유지·복구 등의 UI 기준을 적용하지 않았으며, 각각 36개가 ‘해당 없음’이다. 항목들을 합쳐 성공률을 계산하지 않는다.
| 화면 기준 | 대상 | B0 | R1 |
|---|---|---|---|
저장 상태 |
36 |
14 / 14 / 8 |
32 / 0 / 4 |
무관한 기록 유지 |
36 |
33 / 0 / 3 |
36 / 0 / 0 |
수용·거절 처리 |
36 |
13 / 13 / 10 |
32 / 0 / 4 |
목록·다시 연 값 |
13 |
0 / 0 / 13 |
13 / 0 / 0 |
공백 정리 안내 |
1 |
0 / 1 / 0 |
1 / 0 / 0 |
오류 설명 |
23 |
2 / 14 / 7 |
19 / 0 / 4 |
입력 유지 |
23 |
3 / 13 / 7 |
19 / 0 / 4 |
수정 가능 |
23 |
16 / 0 / 7 |
18 / 0 / 5 |
수정 후 복구 |
23 |
0 / 13 / 10 |
18 / 0 / 5 |
화면 기준 중 대상 외 항목은 표시 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를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.
답글 남기기