AI에게 할 일 앱을 맡겨 봤습니다 — 첫 결과와 수정 요청을 그대로 공개합니다

완성된 코드를 보여 주는 것만으로는 AI에게 무엇을 요청하고, 결과가 맞는지 어떻게 확인했는지 알기 어렵습니다. 이번에는 새 요청 → 첫 코드 보관 → 브라우저 검사 → 관찰 결과를 담은 수정 요청 → 같은 검사 반복 순서로 진행했습니다.

결과부터 말하면, 첫 코드의 기본 기능은 정상입니다. 새로고침 뒤 할 일과 체크가 남았고, 완료 항목만 지우는 기능도 통과했습니다. 차이가 드러난 곳은 처음 프롬프트에 자세히 쓰지 않았던 중복 입력과 저장 차단 상황입니다. 이 두 가지를 추가 조건으로 전달했습니다.

실행본과 원본 자료

첫 응답 실행하기 · 수정 응답 실행하기 · 프롬프트·코드·검사 기록 ZIP

둘은 서로 다른 파일입니다. 첫 버전은 고치지 않고 그대로 뒀습니다 — 거기서 관찰한 한계가 이 글의 절반이라 손대면 글이 성립하지 않습니다.

중요한 기록을 맡기지 마십시오. 결과를 비교해 보는 학습 자료입니다. 그리고 둘은 저장 형식이 호환되는지 보려고 같은 저장 키를 씁니다. 같은 사이트에서 열면 두 버전이 같은 기록을 들여다봅니다.

ZIP에는 입력한 프롬프트 두 개, 응답 HTML 두 개, 변경 내역, 검사 결과와 파일 해시가 들어 있습니다. 로컬에서 열 때는 각 HTML 파일을 브라우저로 열면 됩니다. 파일 URL의 저장 방식은 브라우저마다 다를 수 있습니다.

어떤 조건에서 진행했나요

두 번째 요청은 첫 대화의 자동 기억에 의존하지 않는 별도 실행이었습니다. 이전 HTML을 다시 붙여 넣어 수정 대상을 명확히 했습니다. CLI의 기본 시스템·환경 안내는 존재하므로 '이 짧은 사용자 프롬프트만이 모델의 모든 입력이었다'는 뜻은 아닙니다. 두 코드 생성 응답에서는 도구 호출이 없었습니다.

기본 설정 모델의 CLI 호환 오류로 코드 없이 종료된 사전 시도는 이 비교에 포함하지 않았습니다. 여기 공개하는 첫 버전과 수정 버전은 모두 GPT-5.5에 요청해 얻은 결과입니다. 이 두 번의 사례로 다른 모델의 품질이나 성공률을 비교할 수는 없습니다.

1. 처음 보낸 프롬프트

초보자가 쓸 수 있는 '오늘 할 일 3개' 웹 앱을 만들어 주세요.

원하는 기능:
- 할 일을 최대 3개 입력합니다.
- 항목마다 완료 체크와 삭제 버튼이 있습니다.
- 완료한 항목만 한 번에 지울 수 있습니다.
- 새로고침해도 할 일과 완료 상태가 남아야 합니다.
- 휴대폰에서도 읽고 누르기 편해야 합니다.
- 한국어 화면, 크림색 배경과 올리브색 버튼을 사용해 주세요.

HTML, CSS, JavaScript를 포함한 index.html 하나로 완성해 주세요.
외부 라이브러리, 외부 이미지·폰트, 서버, 로그인, 광고는 사용하지 마세요.
파일은 브라우저에서 바로 열어 실행할 수 있어야 합니다.
코드 전체를 생략 없이 출력해 주세요.

이번 응답에서는 도구를 호출하거나 파일을 읽지 말고, HTML 코드만 출력해 주세요.
실행이나 테스트를 하지 않았다면 했다고 주장하지 마세요.

할 일을 저장하고 체크하는 기능은 명시했지만, 같은 내용을 두 번 넣거나 저장 기능이 차단되는 경우는 적지 않았습니다. 처음부터 긴 명세를 쓰지 않았을 때 어떤 결과가 나오는지 확인하려는 요청입니다. 실패를 유도하는 코드를 넣거나 생성된 코드에 오류를 심지 않았습니다.

2. 첫 결과에서 통과한 것

실제 브라우저에서 '책 10쪽 읽기', '산책 15분 하기', '첫 앱 화면 그리기'를 추가하고 첫 항목을 체크했습니다. 새로고침해도 세 항목과 체크가 유지됐습니다. '완료한 항목 지우기'를 누르면 미완료인 두 개가 남았고, 개별 삭제도 동작했습니다.

작은 화면에서 가로 넘침이 없었으며, 저장된 문자열을 일부러 잘못된 JSON으로 바꾼 경우에도 빈 목록으로 복구했습니다. 즉, 첫 응답이 전부 잘못됐던 것은 아닙니다. 기본 기능을 다시 만들 필요는 없었고, 빠진 예외 조건을 보강할 필요가 있었습니다.

3. 추가 검사에서 발견한 차이

같은 내용이 두 번 들어갑니다

'첫 앱 화면 그리기'를 다시 추가했더니 같은 항목이 두 개가 됐습니다. 이 앱은 최대 세 개만 적는 용도라 중복으로 자리를 쓰는 것이 불편했습니다. 첫 프롬프트에서 중복 금지를 요구하지 않았으므로, 명시한 조건을 어긴 오류라기보다 뒤늦게 정한 사용 규칙입니다.

저장이 차단되면 입력까지 멈춥니다

다음은 저장 기능을 사용할 수 없는 상황을 재현한 화면입니다. 입력란에 내용을 넣고 추가를 눌렀지만 항목이 남지 않았고, 입력란도 다시 비어 있습니다.

이 시험에서는 Playwright의 초기 실행 코드로 window.localStorage 접근이 SecurityError를 던지게 했습니다. 브라우저 환경에서 예외를 주입한 시험이며, 실제 휴대폰 설정에서 같은 증상을 직접 관찰한 기록은 아닙니다. 원본 HTML은 바꾸지 않았습니다.

오류 문구인 Storage blocked for reproducible test도 테스트가 지정한 문자열입니다. 브라우저가 항상 이 문구를 출력한다는 뜻은 아닙니다.

첫 코드의 loadTodos() 는 저장소에서 값을 꺼낸 다음에야 JSON 파싱을 try/catch 로 감쌌습니다. 꺼내는 일 자체가 실패하면 그 오류는 그물 밖입니다. saveTodos() 의 쓰기에는 오류 처리가 아예 없었습니다.

여기가 핵심입니다. "저장된 값이 깨졌다"와 "저장소에 손도 못 댔다"는 전혀 다른 고장인데, 코드는 앞쪽만 막고 있었습니다. 둘을 한 덩어리로 보면 영영 안 잡힙니다.

접근·읽기를 차단한 경우에는 초기화 도중 멈춰 폼의 제출 처리도 연결되지 않았습니다. 추가 버튼을 누르면 기본 폼 제출로 페이지가 다시 열렸고 입력란이 비었습니다. 검사에서 첫 로드 이후 한 번 더 페이지 이동이 발생한 것도 확인했습니다. 쓰기만 차단한 경우는 초기화가 끝난 뒤 저장 단계에서 멈추므로 같은 증상이라도 실행 경로가 다릅니다.

4. 실제로 보낸 수정 요청

아래는 두 번째 요청의 수정 지시 전문입니다. 실제 전송 때에는 이 지시 뒤에 첫 HTML 전체를 붙였습니다. 코드까지 포함한 실제 요청은 두 번째 프롬프트 TXT와 ZIP에 들어 있습니다.

아래는 앞서 생성한 '오늘 할 일 3개' 앱 전체 코드입니다.
Windows Chrome 152에서 실행했으며 기본 추가·체크·삭제·새로고침 복원·완료 항목만 삭제는 정상입니다.
이 기능들과 현재 디자인은 유지해 주세요.

추가 검사에서 관찰한 두 가지를 보강해 주세요. 첫 요청에 구체적으로 넣지 않았던 예외 조건입니다.

1. 중복 방지
재현: '첫 앱 화면 그리기' 입력 → 추가 → 같은 내용을 다시 입력 → 추가.
실제: 같은 내용의 항목 두 개가 생깁니다.
기대: 앞뒤 공백을 제거한 뒤 기존 항목과 같은 내용이면 추가하지 않고 한국어 안내를 표시하세요.

2. 저장 차단 상황
재현: Playwright addInitScript로 window.localStorage getter가 SecurityError를 던지게 설정한 뒤 페이지를 열고 '저장이 막혀도 할 일 추가'를 입력해 추가 버튼을 누릅니다.
실제: 'Storage blocked for reproducible test' 페이지 오류가 나며 항목이 추가되지 않습니다.
원래 HTML을 고친 것이 아니라 브라우저 환경에서 저장 API만 차단한 시험입니다.
기대: 저장할 수 없어도 현재 화면에서는 추가·체크·삭제가 가능해야 합니다. 페이지를 나가거나 새로고침하면 유지되지 않는다는 안내를 항상 보여 주세요.
localStorage 객체 접근, getItem, setItem을 모두 오류 처리 범위에 넣으세요. 저장 읽기는 가능하지만 쓰기가 실패하는 경우도 고려하세요.

완료 조건:
- 기존 저장 키 today-three-todos와 HTML 요소 ID를 유지하세요.
- 최대 3개, 개별 삭제, 완료 항목만 삭제, 정상 저장·복원, 320px 화면을 유지하세요.
- 같은 항목을 두 번 추가하면 한 개만 남고 이유가 표시되어야 합니다.
- 저장 차단 시 임시 항목을 추가하고 체크·삭제할 수 있어야 합니다.
- 잘못된 JSON을 읽어도 페이지가 멈추지 않아야 합니다.
- 사용자 입력을 HTML로 실행하지 마세요.
- 외부 라이브러리·네트워크·서버·로그인·광고는 추가하지 마세요.

도구를 호출하지 말고 수정한 index.html 코드 전체만 출력하세요.
실제로 실행하지 않았다면 테스트했다고 주장하지 마세요.

아래 코드가 수정 대상입니다.

'다시 제대로 만들어 줘' 대신 정상인 부분, 실제 관찰한 증상, 재현 순서, 기대 결과를 나눠 적었습니다. 저장 키와 요소 ID를 유지하도록 한 것은 기존 데이터와 같은 검사 방법을 계속 사용할 수 있게 하기 위해서입니다.

5. 수정 결과를 같은 조건으로 검사했습니다

같은 검사 스크립트를 첫 코드와 수정 코드에 적용했습니다. 기본 기능이 유지되면서 추가한 두 조건도 충족했습니다.

수정 요청 뒤에는 접근 차단만이 아니라 읽기 차단과 쓰기 차단을 각각 같은 스크립트에 넣고 두 버전을 다시 돌렸습니다.

이게 실제 기기에서 나오는 모든 저장 실패를 다 해 봤다는 뜻은 아닙니다. 정상일 때의 저장·복원과, 일부러 막아 놓은 환경에서의 임시 동작을 따로 확인한 것까지입니다.

수정 코드에는 저장소 접근을 오류 처리 안쪽에서 하는 getStorage() 가 생겼습니다. saveTodos() 는 쓰기가 실패하면 실패했다고 기록만 남기고 돌아오며, 화면은 계속 갱신됩니다.

이 한 가지가 체감을 바꿉니다. 저장이 막혀도 지금 화면에서 하던 일은 그대로 할 수 있습니다. 껐다 켜면 사라지지만, 적어도 작업 중에 앱이 죽지는 않습니다. 중복 검사는 새 항목을 배열에 넣기 전에 합니다 — 넣고 나서 거르면 이미 화면에 한 번 떴다 사라집니다.

위 화면도 첫 버전과 같은 방식으로 저장 API를 차단한 뒤 촬영했습니다. 외형을 예쁘게 그린 비교 이미지가 아니라 각 HTML을 직접 실행한 결과입니다. 항목과 체크는 테스트용 데이터이며 실제 이용자 기록이 아닙니다.

6. 프롬프트를 고칠 때 가져갈 방법

정상인 기능부터 기록하세요. 새로고침 저장과 삭제가 이미 맞다면 그대로 유지하라고 적습니다. 수정 범위가 작아야 결과를 비교하기 쉽습니다.

증상과 원인을 구분하세요. '추가가 안 된다'는 관찰이고, '저장소 접근이 예외를 던진다'는 로그와 코드로 확인한 원인입니다. 원인을 아직 모르면 확정해서 쓰지 말고 행동 순서와 오류를 먼저 전달하세요.

바뀐 조건을 숨기지 마세요. 이 사례의 중복 금지는 첫 요청에 없던 규칙입니다. 나중에 요구한 조건을 처음부터 있었던 것처럼 취급하면 AI 결과를 공정하게 평가할 수 없습니다.

수정 뒤에는 기존 기능도 다시 확인하세요. 예외 처리만 고쳤더라도 정상 저장·복원과 삭제가 달라지지 않았는지 같은 순서로 검사해야 합니다. 실행하지 않은 내용을 검증했다고 적지 않는 것도 중요합니다.

본인 앱에서도 첫 요청 · 첫 결과 · 검사 · 수정 요청을 한 묶음으로 남겨 보십시오. 네 개가 같이 있어야 나중에 "이게 왜 이렇게 됐지"에 답할 수 있습니다. 결과만 남기면 반년 뒤에 아무것도 모릅니다.

이어서 읽을 것

처음부터 조건을 촘촘히 적고 싶으시면 할 일 앱 완성형 프롬프트에, 시간과 입력을 다루는 쪽은 30초 표적 게임 가이드에 있습니다. 저장이 사라졌을 때 원인을 가르는 순서는 브라우저 저장 문제, 남에게 증상을 넘기는 양식은 오류 제보 작성법입니다.