테스트 70개가 통과했는데, 왜 공개하지 않았을까? — 부동산 AI 앱 4주 완주와 마지막 사람의 도장

소개

안녕하세요. 부동산 하는 도시아재입니다.

저는 AI가 낯선 초보 공인중개사가 하루 한 가지씩 연습할 수 있는 14일 AI 학습 대시보드를 만들고 있습니다. 1주차에는 첫 장면을 만들었고, 2주차에는 Spec Kit으로 소개 문장의 기준을 고쳤습니다. 3주차에는 다른 탭에서 지운 학습 기록이 되살아나는 오류를 AI와 함께 찾아 직접 재현하고 수정했습니다.

마지막 4주차에는 더 화려한 기능을 붙이고 싶었습니다. 30일 미션으로 늘리고, 점수와 상장도 넣고, 멋진 결과를 공개하면 완주한 느낌이 날 것 같았습니다.

그런데 실제 사용자 두 사람의 반응은 한 방향으로 모이지 않았습니다. 한 사람은 이미지와 사용 흐름이 좋다고 했고, 다른 한 사람은 무엇을 얼마나 적어야 하는지 헷갈렸고 스마트폰 데이터 분석 장면도 충분히 보이지 않았다고 했습니다.

그래서 이번 주에는 기능을 늘리는 대신, 지금까지 만든 결과를 명세·자동 검사·브라우저·실제 사용자·Jev의 서로 다른 눈으로 다시 확인했습니다. 그리고 최종적으로 아직 공개하지 않기로 했습니다.

집을 살 때 매물 사진 한 장만 보고 계약하지 않듯, AI 결과도 한 번의 “좋아요”나 테스트 통과만으로 완료 도장을 찍을 수는 없었습니다.

사진 1. 로컬 공개 후보판의 14일 대시보드입니다. 아직 공개 주소에는 반영하지 않았습니다.

진행 방법

1. 먼저 ‘누가 무엇을 판단하는가’를 나눴습니다

수업 마지막에 가장 공감한 내용은 명세 자체보다 역할 구분이었습니다.

AI는 요구사항과 명세의 초안을 만들고, 누락·모순·실패 후보를 찾고, 테스트와 작업 순서를 제안할 수 있습니다. 하지만 어떤 문제를 먼저 풀지, 예외를 어디까지 허용할지, 결과를 채택하고 공개할지는 사람이 결정해야 합니다.

저는 이를 부동산 계약에 빗대어 정리했습니다. 매물 광고, 등기부, 현장 확인, 계약서는 모두 같은 집을 다루지만 서로를 대신하지 않습니다. 이번 앱에서도 명세, 테스트, Jev, 실제 사용자 평가는 같은 결과를 보더라도 증명하는 범위가 달랐습니다.

역할

이번에 확인한 것

명세

첫날 안내·저장·사람의 최종 승인처럼 확인할 기준

자동 검사

정해진 입력·저장·API·상태 전환 동작

브라우저

실제 화면·모바일·설정창·탭 간 저장 흐름

실제 사용자

서로 다른 입력으로 체험한 반응과 혼란

Jev 1.14

대표 주장과 근거의 의미상 어긋남 후보

2. 실제 사용자 두 사람의 서로 다른 후기를 받았습니다

이번에는 AI 페르소나가 아니라 앱의 대상과 맞는 실제 초보 공인중개사 두 사람이 공개판의 1일차 미션을 체험했습니다. 각자 다른 각오와 포부를 입력하고 이미지를 생성했습니다.

사용자 1: 이미지가 입력 의도와 잘 맞았고 사용 방법도 쉽고 자연스러웠습니다.
사용자 2: 이미지는 의도와 일부 맞았지만 스마트폰으로 데이터를 분석하는 모습이 충분히 드러나지 않았고, 입력할 글의 길이와 형식이 헷갈렸습니다.

두 사람 모두 글로 후기를 남겼지만, 이번 검수에서는 후기 원문과 생성 이미지를 직접 받지 못했습니다. 따라서 직접 인용이나 전후 이미지 비교로 꾸미지 않고, 교수님이 전달한 익명 요약 후기라는 범위를 남겼습니다.

여기서 바로 고칠 수 있는 것과 추가 증거가 필요한 것을 나눴습니다.

구분

판단

바로 수정

입력 길이·형식 안내를 1~2문장과 두 가지 질문으로 구체화

추가 확인

데이터 분석 장면은 원문·생성 지시·결과 이미지를 대조한 뒤 판단

입력 길이·형식은 실제 화면 문구로 확인할 수 있었습니다. 반면 데이터 분석 장면이 약했던 원인은 입력 원문, 생성 지시, 실제 이미지, 모델 결과를 함께 보지 못했으므로 단정할 수 없었습니다.

3. 확인 가능한 안내 한 문장만 고쳤습니다

수정 전 1일차 안내는 다음과 같았습니다.

내 생각을 한 문장으로 표현하고, 현장에서 일하는 나의 미래를 만나보세요.

처음 쓰는 사람에게는 ‘한 문장’이 어느 정도인지, 무엇부터 적어야 하는지 알기 어려울 수 있었습니다. 그래서 생성 규칙이나 이미지 프롬프트를 한꺼번에 바꾸지 않고 안내 한 문장만 수정했습니다.

각오와 포부는 1~2문장이면 충분해요. 어떤 공인중개사가 되고 싶은지, AI로 해 보고 싶은 일을 차례로 적어 보세요.

기존 입력 예시, 10자 이상 검사, 500자 상한, 이미지 생성 지시와 확인 항목은 그대로 유지했습니다. 무엇 때문에 경험이 달라졌는지 나중에 구분하기 위해서입니다.

사진 2. 안내가 화면에 보인다는 증거이며 사용성 향상을 증명한 화면은 아닙니다.

4. 코드의 약속과 실제 브라우저를 따로 확인했습니다

3주차에 고친 저장 오류는 다음 두 줄이 핵심이었습니다.

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

같은 학습 기록 저장소에서 온 전체 삭제 또는 해당 기록 변경에는 반응하고, 관계없는 저장소와 다른 키의 변경은 제외하는 조건입니다.

4주차 공개 후보판에서는 다음 순서로 다시 확인했습니다.

1. npm run build:sites로 공개 자산 19개를 만들었습니다.

2. npm run verify:sites로 19개 자산의 바이트 일치, 홈·헬스·키 누락 처리·비공개 파일 제외를 확인했습니다.

3. npm test에서 전체 70개가 통과했습니다.

4. 데스크톱과 390px 모바일에서 주요 미션 화면과 가로 넘침을 확인했습니다.

5. 빈 입력에서는 API 설정창보다 입력 오류가 먼저 보이는지 확인했습니다.

6. 정상 입력 뒤 설정창이 열리고, 직전 클릭 때문에 바로 닫히지 않는지 확인했습니다.

7. 다른 탭에서 localStorage.clear()를 실행한 뒤 자동 저장이 멈추고 삭제한 기록이 다시 생기지 않는지 확인했습니다.

사진 3. API 설정창의 생성 전 흐름이며 인증 성공이나 유료 생성의 증거는 아닙니다.

사진 4. 다른 탭에서 기록이 바뀌자 기존 탭이 저장을 멈췄습니다.

자동 검사와 브라우저 검사는 정해 둔 동작을 확인했습니다. 그러나 이번 최종 검사에서는 비용이 발생하는 OpenAI 이미지 생성을 다시 실행하지 않았고, 수정된 안내를 같은 사용자들이 다시 체험하지도 않았습니다.

5. Jev 1.14에는 글을 쓰게 하지 않고, 주장을 의심하게 했습니다

Jev는 로컬 프로그램을 업데이트하는 방식이 아니라 TypeSafe API 요청에서 jev-1.14.0 모델을 지정해 사용했습니다. 원고 전체나 API 키를 보내지 않고, 검증된 사실·사용자 후기·미검증 범위·확인할 주장만 구조화해 보냈습니다.

검수 질문은 다음 네 종류였습니다.

1. 공개판과 로컬 후보판의 범위를 정확히 구분했는가?
2. 두 사용자 후기에서 말할 수 있는 범위를 넘지 않았는가?
3. 명세·테스트·Jev·사람의 역할을 설명한 핵심 문장이 근거에 맞는가?
4. 이제 사람이 공개 여부를 판단할 만큼 자료가 정리됐는가?

첫 검수에서 Jev 1.14는 기능 차단보다 문서 범위 보완이 먼저라는 신호를 냈습니다. README에 빠져 있던 1일차 안내 변경과 실제 사용자 후기의 한계를 보완한 뒤 다시 물었습니다.

문서 범위: supports, confidence 0.99
후기 한계: supports, confidence 1.00
사례 핵심 문장: supports, confidence 0.93
공개 판단 준비도: ready_for_human_decision, confidence 0.59

사진 5. Jev 결과는 공개 허가가 아니라 사람이 다시 볼 판단 신호로 사용했습니다.

마지막 값은 중요했습니다. ‘사람이 판단할 자료가 모였다’는 선택이 우세했지만 확신도는 높지 않았습니다. TypeSafe의 confidence는 정답률이나 공개 허가가 아닙니다. 그래서 Jev의 결과를 배포 버튼으로 연결하지 않고, 제가 다시 볼 표시로 사용했습니다.

확인 주체

대신할 수 없는 것

명세

빠진 조건과 실제 만족을 자동으로 발견하지 못함

테스트

정하지 않은 사례와 이미지 만족도를 판단하지 못함

Jev

사실 확정·정답률·공개 승인을 제공하지 않음

사람

근거와 한계를 보고 최종 채택·보류·공개를 결정

6. 준비됐다는 신호를 받고도 공개하지 않았습니다

기능 검사에서는 공개를 막을 새 오류가 발견되지 않았고, 문서도 보완했습니다. 그렇다고 바로 배포하면 이번 사례의 결론과 맞지 않았습니다.

수정된 1일차 안내는 화면에 잘 보이지만 실제 초보자가 다시 읽고 덜 헷갈렸는지 확인하지 못했습니다. 사용자 2가 아쉬워한 데이터 분석 장면도 새 입력과 새 이미지로 대조하지 못했습니다. 14일 전체를 실제 학습자가 사용했을 때의 중단 지점과 재참여율도 모릅니다.

그래서 이번 단계의 최종 상태는 ‘공개 완료’가 아니라 공개 여부를 사람이 판단할 수 있도록 근거와 한계를 정리한 후보판입니다. 저는 앱을 공개판에 반영하지 않고 보류했습니다.

결과와 배운 점

확인한 결과

14일 앱의 로컬 공개 후보판을 정리했습니다.
공개 자산 19개와 자동 검사 70개가 통과했습니다.
데스크톱·390px 모바일·설정창·다른 탭 저장 충돌 흐름을 확인했습니다.
실제 대상 사용자 두 사람이 기존 공개판의 1일차 이미지를 생성했습니다.
확인 가능한 1일차 입력 안내 한 문장만 수정했습니다.
Jev 1.14로 문서 보완 전·후의 대표 주장을 대조했습니다.
로컬 후보판은 공개하지 않았습니다.

배운 점과 나만의 팁

1. 명세는 정답지가 아니라 질문지였습니다. 무엇을 확인할지 정해 줬지만 빠진 조건과 실제 사용자의 혼란까지 자동으로 알려 주지는 않았습니다.

2. 테스트 통과와 사용자 만족은 다른 증거였습니다. 70개 검사는 저장과 화면의 약속을 확인했지만 이미지가 마음에 드는지 판단하지 못했습니다.

3. Jev는 심판보다 이의 제기 역할이 유용했습니다. 높은 확신도도 공개 허가로 쓰지 않았고, 모델 간 판정이 엇갈린 항목은 사람 검토로 남겼습니다.

4. 부동산 도메인 지식은 무엇을 의심할지 정하는 데 쓰였습니다. 매물 사진, 등기부, 현장 확인을 구분하듯 AI의 주장과 증거 수준을 나눴습니다.

5. 공개하지 않는 결정도 결과입니다. 배포할 수 있는 상태와 지금 배포해야 하는 상태는 다릅니다.

시행착오

문제: 첫 브라우저 스모크 검사가 처음 열린 API 설정창에 막혔습니다.
판단: 앱 오류로 단정하지 않고 검증 스크립트가 첫 화면을 처리하지 못한 문제인지 구분했습니다.
해결: 설정창을 닫고 닫힘을 기다린 뒤 미션 검사를 시작하도록 검증 스크립트만 보완했습니다.
남은 한계: 수정된 안내의 실제 사용자 재평가와 새 이미지 품질 비교는 아직 하지 않았습니다.

앞으로의 계획

30일 미션을 바로 구현하지 않겠습니다. 먼저 수정된 1일차 안내를 초보 공인중개사가 다시 사용했을 때 입력 시간이 줄고 무엇을 적을지 덜 묻는지 확인하겠습니다.

그 결과가 긍정적이면 30일 확장의 첫 주 행동을 정하고, 그렇지 않으면 미션 수를 늘리기 전에 첫날의 안내와 이미지 결과 확인 방식을 다시 고치겠습니다.

명세는 확인할 기준을 만들고, 테스트는 정해진 동작을 확인하며, Jev는 놓친 의미를 의심하게 돕습니다. 그러나 어느 것도 실제 사용자 평가를 대신하지 않으며, 마지막 공개 도장은 사람이 찍습니다.

사진 6. 도구는 판단 재료를 만들고, 마지막 공개 도장은 사람이 찍습니다.

도움 받은 글

3주차 사례글: 지웠는데 돌아온 학습 기록 — ‘AI 탐정단’과 찾은 14일 앱의 숨은 오류

- https://www.gpters.org/nocode/post/jiweossneunde-dolaon-hagseub-girog----ai-tamjeongdan-gwa-cajeun-14il-aebyi-Rod8OLwS7V0lp0s

TypeSafe 문서: System One과 confidence의 의미

- https://docs.typesafe.ai/llms.txt

GitHub Spec Kit: Spec-Driven Development 개념

- https://github.github.com/spec-kit/concepts/sdd.html

📢 AI스터디는 24기를 끝으로 방학에 들어가요