지웠는데 돌아온 학습 기록 — 'AI 탐정단'과 찾은 14일 앱의 숨은 오류

소개

안녕하세요. 부동산 하는 도시아재입니다. 저는 초보 공인중개사가 하루 한 가지씩 AI를 연습하는 14일 미션 대시보드를 만들고 있습니다.

그런데 이번에는 조금 이상한 일이 벌어졌습니다. 다른 탭에서 학습 기록을 지웠는데, 열려 있던 앱 탭을 닫고 다시 열자 삭제한 기록이 되살아났습니다. ‘삭제’가 삭제로 끝나지 않는다면, 학습자가 앱을 믿고 쓸 수 있을까요?

1주차에는 첫 조각에서 14일 대시보드로 확장했고, 2주차에는 Spec Kit으로 2일차 소개 문장의 기준을 고쳤습니다. 세 번째 항해에서는 기능을 더 붙이기보다 지금 있는 앱을 다른 눈으로 살피고, 실제로 확인된 문제만 고치기로 했습니다.

셜록 홈스 영화에서 작은 단서 하나가 곧바로 사건의 결론이 되지는 않습니다. 현장에서 같은 일이 일어나는지 확인하고, 다른 가능성과 대조해야 합니다. 이번에는 AI의 코드 검토를 ‘단서’, 브라우저 재현을 ‘현장 확인’, 회귀 검사를 ‘재발 방지 장치’로 삼았습니다.

2주차에 실제 후보를 읽고 고른 일과, 3주차에 처음 쓰는 사람의 관점으로 앱을 점검한 일은 다릅니다. 이번에는 시간상 다른 사람에게 사용을 부탁할 수 없어 AI 페르소나를 대안으로 썼고, 그것을 실제 사용자 평가로 포장하지 않았습니다.

AI가 지목한 문제는 판결문이 아니었습니다. 제가 직접 재현하고, 고친 뒤 다시 확인해야 할 수사 단서였습니다.

사진 1. 지난 글에서 사용한 2일차 작성 조언 화면입니다. 이번 수정 전의 과거 캡처이며, 3주차 검증 결과 화면이 아닙니다.

진행 방법

전체 커리큘럼의 3주차는 ‘완성하고, 남에게 내놓을 수 있게 만들기’입니다. 저는 이번 주의 멈춤 기준을 확인된 저장 오류 수정, 처음 보는 관점에서 2일차 생성 전 흐름 점검, 검증하지 않은 범위 기록으로 좁혔습니다. 공개 여부는 별도의 판단으로 남겨뒀습니다.

1. 서로 다른 AI에 역할을 나눴습니다

3주차 라이브 교안의 ‘다른 눈으로 문제 찾기 → 테스트하고 고치기’ 흐름을 제 앱에 적용했습니다. 먼저 Codex가 현재 앱과 검증 기준을 살피고, 별도 Aside 세션의 Claude Sonnet 5.5(high)는 소스만 읽어 문제 후보를 제시했습니다. Aside에서는 실행 권한 제한으로 테스트를 돌리지 못했습니다.

그 뒤 Astra(gpt-6-astra)에 서로 다른 두 역할을 맡겼습니다. 하나는 부모님의 중개업을 배우는 30대 신규 합격자, 다른 하나는 10년차 공인중개사 겸 AI 강사입니다. 둘 다 같은 모델의 가상 관점이므로 사람 두 명을 관찰한 결과나 서로 다른 모델 간 실험은 아닙니다.

두 번째 역할에는 첫 번째 역할의 평가를 보여 주지 않았습니다. 그래도 같은 모델을 두 번 쓴 것이므로 의견이 겹쳤다는 이유만으로 ‘실제 사용자도 그렇게 느낄 것’이라 단정하지 않았습니다. AI가 늘어도 근거의 질이 저절로 높아지지는 않기 때문입니다.

2. ‘지운 기록이 돌아온다’는 지적을 직접 재현했습니다

문제 후보 중 하나는 다른 탭에서 학습 기록을 전체 삭제해도, 열린 앱 탭이 닫힐 때 예전 기록을 다시 저장할 수 있다는 것이었습니다. 격리된 로컬 주소에 가상 문장을 입력하고 다른 탭에서 localStorage.clear()를 실행했습니다. 그 순간 기록은 사라졌지만, 앱 탭을 닫고 다시 열자 되살아났습니다.

반대로 학습 기록 키 하나만 removeItem()으로 지웠을 때는 자동 저장이 멈춰, 기록이 되살아나지 않았습니다. 전체 삭제와 개별 삭제를 앱이 다르게 처리한 것입니다. 이 비교가 수정 범위를 정해 줬습니다.

비유하면 서류함을 통째로 비웠을 때는 책상 위 복사본을 누가 다시 넣었지만, 특정 서류를 폐기하라고 알렸을 때는 복사본도 더 넣지 않은 셈입니다. 처음에는 ‘삭제가 안 된다’고만 말할 수 있었는데, 대조 시험을 하고 나니 어떤 삭제 신호에서만 문제가 생기는지 말할 수 있게 됐습니다.

3. 삭제 신호를 고치고, 같은 상황을 다시 시험했습니다

다른 탭의 전체 삭제 신호는 저장소 이벤트에서 key: null로 옵니다. 앱이 같은 localStorage의 이 신호도 처리하되, 무관한 키나 다른 저장소의 변경은 제외하도록 했습니다. 아래는 실제로 수정한 코드의 핵심 두 줄입니다.

if (event.storageArea !== localStorage) return;
if (event.key !== null && event.key !== STORAGE_KEY) return;

쉽게 말해 우리 앱의 학습 기록 저장소에서 온 전체 삭제나 해당 기록 변경에만 반응하도록 한 것입니다. 관계없는 테마 설정이 바뀌었다는 이유로 학습 내용의 정상 저장까지 멈추면 새로운 오류가 되기 때문입니다.

새 회귀 검사 6개를 더했습니다. 관련 검사 2개는 수정 전 실패했고, 수정 뒤 전체 70개 검사 통과·실패 0개였습니다. 브라우저에서도 전체 삭제와 개별 삭제 뒤 기록이 다시 생기지 않는 것을 확인했습니다. 무관한 테마 변경은 정상 저장을 막지 않았습니다.

여기서 ‘검사 통과’는 코드의 약속을 확인한 것이고, ‘브라우저 재검증’은 실제 화면에서 같은 사건이 다시 일어나지 않는지 본 것입니다. 둘을 함께 기록했지만, 이것만으로 모든 브라우저 환경의 동작까지 보증하지는 않습니다.

이것은 이번에 시험한 탭 간 저장소 동작의 결과입니다. 브라우저 설정 메뉴의 모든 데이터 삭제 방식이나 모든 기기 환경을 검증했다는 뜻은 아닙니다.

4. 두 페르소나의 공통 의견만 2일차에 반영했습니다

두 역할에는 태도 ‘정직, 꼼꼼함’과 ‘부모님의 중개업을 배우며 첫 전셋집을 찾는 청년에게 매물별 확인사항을 비교하고 쉬운 말로 설명하기’라는 같은 가상 입력을 줬습니다. 첫 API 설정창을 닫고 2일차로 이동해 입력·저장까지 확인했습니다. 키 없이 생성 버튼을 누르면 설정창이 다시 열렸지만 입력은 남았습니다.

첫 역할은 이제 막 실무를 배우는 사람의 눈으로, 둘째 역할은 교육 현장에서 초보자를 안내하는 눈으로 살폈습니다. 실제로 관찰한 것은 설정창을 닫을 수 있는지, 1일차 완료 없이 2일차로 갈 수 있는지, 입력이 저장되는지 같은 생성 전 흐름입니다. 두 인물이 느꼈다는 감정이나 만족도는 기록하지 않았습니다.

두 관점에서 겹친 가설은 상가 중심 예시를 주거·전세 상황으로 바꿔도 되는지, 지역을 정하지 못한 초보자는 무엇부터 적어야 하는지였습니다. 그래서 2일차 작성 조언에 분야를 바꿔도 되고 지역이 미정이면 고객과 돕는 방법부터 적으라는 문장 하나만 추가했습니다. 새 문장이 로컬 앱 화면에 실제 표시되고 가상 입력이 저장되는 것도 확인했습니다.

이때도 안내를 한 문장만 바꿨습니다. 가설만으로 생성 규칙이나 다른 날의 미션을 한꺼번에 바꾸면 무엇 때문에 경험이 달라졌는지 알기 어려워지기 때문입니다. 실제 AI 소개 문장을 생성해 품질을 판단하는 일은 이번 점검의 범위 밖에 두었습니다.

사진 2. 이번 로컬 수정판의 2일차 화면입니다. 주거·전세와 지역 미정 안내가 보입니다. 화면의 입력은 가상 문장이고, 아직 AI 결과를 생성한 화면은 아닙니다.

5. Jev에게 ‘이 글이 확인한 것만 말하는가’를 물었습니다

공개 전 의미 검수에는 TypeSafe의 Jev(jev-1.13.0)를 썼습니다. 원고 전체나 API 키가 아니라 대표 주장 5개와 검증 기록·Git 변경 내용의 요약만 보내고, 각 주장이 근거에 부합하는지 supports / overstates / contradicts / insufficient 중 하나로 고르게 했습니다. Jev는 설명문을 대신 써 주는 도구가 아니라, 다시 확인할 표현을 찾는 역할이었습니다.

저장 오류의 재현·수정, 검사 수치, AI 페르소나를 실제 사람과 구분한 표현은 대체로 근거에 부합한다는 판단이 나왔습니다. 반면 ‘오류 1건과 안내 한 문장만 바꿨다’는 식의 전체 변경 범위 설명은 과장 가능성이 있다는 지적을 받았습니다. 공개 상태를 설명한 문항도 판단 확신도가 낮아 사람의 재확인 대상으로 남겼습니다. 이 분류는 Jev의 의견이지 사실 확정이나 공개 허가가 아닙니다.

검수 과정에서 실제 변경 내용을 다시 대조했습니다. 저장 오류 수정과 2일차 안내 외에도 설정창을 연 직후의 클릭 처리와 생성 버튼에서 입력 오류를 먼저 알리는 순서 변경이 있었습니다. 격리된 로컬 주소에서 빈 입력은 입력 오류를 먼저 보여 줬고, 유효한 가상 입력에 API 키가 없으면 설정창이 열렸습니다. 창을 닫아도 입력은 남았습니다. 실제 생성 요청은 하지 않았고, 설정창을 여는 직후의 모든 기기·클릭 타이밍까지 검증한 것은 아닙니다.

테스트가 통과해도 제가 쓴 설명에서 변경 하나를 놓칠 수 있습니다. Jev는 그 빈칸을 찾는 또 하나의 단서였습니다.

결과와 배운 점

이번 주에는 오류 1건을 후보 제안 → 수정 전 재현 → 코드 수정 → 자동 검사 → 브라우저 재검증으로 연결했습니다. 2일차 안내 한 문장도 두 페르소나의 공통 가설만 좁게 반영했습니다. 별도로 원고에서 빠진 설정창 변경의 생성 전 동작도 점검했습니다. 사이트 빌드와 자산 검증은 각각 19개 자산 기준으로 통과했지만, 로컬 변경은 아직 배포하지 않았습니다.

확인된 사실: 전체 삭제 때의 기록 부활을 수정 전 브라우저에서 재현했고, 수정 뒤에는 같은 절차에서 재현되지 않았습니다. 관련 검사 2개는 수정 전에 실패했고, 이번 재실행에서도 전체 70개가 통과했습니다. 새 2일차 안내는 로컬 화면에 표시됐습니다. Jev는 원고의 대표 주장 5개를 근거와 대조했고, 변경 범위 설명의 누락을 원고에 반영하는 계기가 됐습니다.

가설과 예정: 두 페르소나의 공통 질문은 처음 쓰는 사람을 위한 안내 개선의 단서였지 실제 이용자 조사 결과가 아닙니다. Jev의 판단만으로 원고나 앱이 완전히 검증된 것도 아닙니다. 사람의 최종 판단과 공개판 반영은 아직 남았습니다.

사람의 사용 시간·만족도는 측정하지 않았고, 이번 점검에서 실제 AI 소개 문장도 생성하지 않았습니다. AI 페르소나는 사람이 아니며, 자동 검사 통과도 문장의 좋고 나쁨을 대신 판단하지 못합니다. 제게 남은 원칙은 ‘누가 무엇을 주장했는가’보다 ‘어디까지 직접 확인했는가’를 먼저 쓰기입니다.

셜록 홈스 비유로 돌아가면, 단서를 많이 모았다고 사건이 끝난 것은 아닙니다. 직접 재현한 장면과 대조 사례가 있어야 고칠 곳이 보였습니다. 제가 AI를 협력시킨 방법에서 중요한 것은 모델의 숫자보다 ‘후보 제안, 실행 확인, 가설, 최종 판단’을 섞지 않은 것이었습니다.

전체 커리큘럼의 4주차는 정돈·최종 발표·다음 30일 계획·AI에게 넘길 인수인계가 중심입니다. 저는 이번 검증 기록과 사용 안내를 그 입력으로 삼고, 남은 확인 항목을 분리해 전달할 계획입니다. 공개 전 Jev로 대표 주장과 근거를 대조했지만, 최종 판단과 공개 결정은 제가 하겠습니다. 4주차 작업과 공개는 아직 완료한 일이 아닙니다.

4주차에 넘길 재료는 명확합니다. 이번 주에 고친 오류와 테스트 결과, 2일차 안내 변경, 아직 확인하지 않은 실제 사용자·생성 문장 품질·공개판 반영 여부입니다. 이 목록을 바탕으로 발표와 다음 30일 계획을 세우되, 지금 마치 끝난 일처럼 쓰지 않겠습니다.

핵심 내용 정리

ALT

AI 놀이터 3주차 학습 만화. AI 오류 후보, 전체 삭제 후 기록 부활, 저장 키 개별 삭제 대조, 전체 삭제 신호 수정, 검사 결과, Astra의 가상 관점, 2일차 안내 보완, 예정된 Jev 검수와 사람의 공개 결정을 8칸으로 설명합니다.

사진 3. 말풍선과 화면은 검증 과정을 설명하기 위한 재구성입니다. 실제 코드와 검사 수치는 본문을 참고해 주세요. Astra의 두 인물은 AI 페르소나입니다. 그림의 ‘Jev 예정’은 제작 당시 상태이며, 현재 검수 결과는 본문 5절에 적었습니다. 공개 결정은 아직 남았습니다.

도움 받은 글

2주차 사례글은 이번 점검의 출발점인 2일차 소개 문장과 이전 검증 범위를 보여 줍니다. 3주차 교안은 다른 관점에서 문제를 찾고 확인하는 순서를 잡는 데 참고했습니다. 기존 공개 대시보드는 2주차 공개판으로, 이번 로컬 수정이 아직 반영된 주소는 아닙니다.😃 😉 😎