소개
첫 번째 프로토타입에서는 AI 페르소나 50명을 테스트하며 화면 흐름과 데이터 저장 구조를 점검했습니다.
AI 페르소나 테스트는 오류와 주요 관찰 지점을 미리 찾는 데 도움이 됐습니다. 하지만 실제 사람이 어떻게 이해하고, 어떤 화면을 선택하며, 무엇을 불편하게 느끼는지는 대신 확인할 수 없었습니다.
두 번째 프로토타입에서는 테스트 방식을 다음과 같이 바꿨습니다.
AI 페르소나
→ 실제 참가자
로컬 주소
→ 외부 접속 링크
자동 생성 응답
→ 참가자가 직접 입력한 응답
에이전트 중심 실행
→ 참가자가 혼자 진행하는 비조정형 테스트진행 방법
- Hermes Agent: 기존 프로토타입 구조 파악, 제출 흐름과 오류 점검, 결과 분석
- HTML·CSS·JavaScript: 참가자가 직접 사용하는 비교 테스트 화면 제작
- Vercel: 외부 참가자가 접속할 수 있는 링크 제공
- Vercel Function: 참가자의 제출값을 서버에서 검증
- Supabase: 비식별 참가자 ID와 응답 저장
- CSV: Supabase 원본 데이터를 내려받아 보존
- 로컬 분석 파일: 참가자를 U1·U2 형식으로 정리하고 응답 분석
- GitHub: Vercel 배포에 필요한 소스 관리
Git과 Vercel 연결 및 배포는 제가 직접 진행했습니다. 에이전트는 배포할 파일, 제외할 파일, 환경변수, 제출 API와 검증 항목을 정리하는 역할을 맡았습니다.
이번 핵심은 실제 참가자가 혼자 진행할 수 있도록 바꿨다는 것입니다.
AI 페르소나 테스트에서는 에이전트가 정해진 흐름을 따라 응답을 만들 수 있었습니다. 실제 참가자 테스트에서는 진행자가 옆에서 설명하지 않아도 화면만 보고 과업을 끝낼 수 있어야 했습니다.
그래서 테스트 흐름을 다음과 같이 구성했습니다.
기본 정보 입력
→ 화면 A 경험
→ 화면 A 질문 응답
→ 화면 B 경험
→ 화면 B 질문 응답
→ 최종 선택과 이유 작성
→ 제출
→ 저장 성공 후 완료 화면이번 테스트에서는 같은 참가자가 A와 B를 모두 경험했습니다. 따라서 일반적인 A/B 실험보다 비교 사용성 테스트에 가깝습니다.
확인하려는 내용도 실제 사업 성과가 아니라 다음 범위로 제한했습니다.
- 참가자가 각 화면의 목적을 이해하는가
- 필요한 정보를 찾을 수 있는가
- A와 B 중 어떤 화면을 선택하는가
- 화면을 선택한 이유는 무엇인가
- 혼란스럽거나 부족한 정보는 무엇인가
또한, 참가자 정보는 조사에 필요한 범위만 받았습니다.
실제 사람의 응답을 받기 때문에 AI 페르소나 테스트와는 다른 데이터 기준이 필요했습니다.
Supabase에는 이름이나 닉네임 대신 브라우저에서 생성한 UUID를 저장했습니다.
Vercel을 통해 외부 접속 환경을 만들었습니다.
GitHub의 비공개 저장소를 Vercel에 연결하고, 운영용 배포 링크를 만들었습니다.
전체 구조는 다음과 같습니다.
실제 참가자의 브라우저
→ Vercel에 배포된 테스트 페이지
→ 같은 주소의 POST /api/submit
→ Vercel Function
→ Supabase브라우저가 Supabase에 직접 값을 보내는 대신, Vercel Function이 제출값을 먼저 확인한 뒤 Supabase에 저장하도록 구성했습니다.
이 구조를 사용한 이유는 세 가지였습니다.
1. 프런트엔드와 서버에서 같은 입력 규칙을 확인할 수 있음
2. 저장 실패 시 완료 화면이 잘못 표시되는 것을 막을 수 있음
3. Supabase 연결 정보를 브라우저 요청에 직접 포함하지 않을 수 있음
Vercel에는 다음 환경변수의 실제 값을 별도로 등록했습니다.
SUPABASE_URL=
SUPABASE_PUBLISHABLE_KEY=
ALLOWED_ORIGINS=파일럿에서는 다음 내용을 확인했습니다.
- 배포 링크가 모바일과 데스크톱에서 열리는가
- A와 B 화면이 정상적으로 전환되는가
- 필수 질문이 빠지면 제출을 막는가
- 응답이 Supabase에 저장되는가
- 저장값과 실제 입력값이 일치하는가
- 같은 UUID가 중복 행을 만들지 않는가
- 저장 실패 시 잘못된 완료 화면을 보여주지 않는가
이상이 없는 것을 확인한 뒤 실제 참가자에게 링크를 전달했습니다.
앞으로의 계획
다음 4편에서는 다음 내용을 정리할 예정입니다.
- 개인정보를 최소한으로 수집한 기준
- Supabase RLS와 익명 사용자의 저장 권한
- 서버와 데이터베이스에서 입력값을 다시 검증한 이유
- 환경변수와 공개 파일을 구분한 방법
- CSP·XSS·클릭재킹 방어
- Git과 Vercel에서 제외한 파일
- 배포 후 보안과 저장 흐름을 확인한 방법
