CaseMaker (Figma2Checklist)

디자인·기획 산출물과 QA 사이에 공통 기준이 없다. 명세가 없으면 QA는 테스트 범위 자체를 추론하기 어렵고, 매번 수작업으로 체크리스트를 만들다 보면 누락과 편차가 생긴다.

QA 엔지니어로서 가장 자주 본 공백 - "산출물은 나왔는데 테스트 기준이 없다" - 을 도구로 메우려 한 시도. React+FastAPI 풀스택에 인증·저장(PostgreSQL)·Toss 결제 연동까지 세우고, 공개 Notion 문서를 파싱해 GPT-4o-mini로 체크리스트를 뽑는 경로를 붙였다. 이름·비전은 "Figma2Checklist"였지만 실제 구현은 Notion 문서 기반. James Company에서 2025년에 만든 풀스택 빌드.

• 문서 URL 입력 → 공개 Notion 페이지를 Playwright로 읽어 텍스트 추출(BeautifulSoup) → GPT-4o-mini가 QA 체크리스트 항목을 초안·그룹핑
• 생성한 체크리스트를 계정별로 저장·불러오기
• React + FastAPI 풀스택, 이메일/비밀번호 인증, PostgreSQL, Toss 결제 연동 코드까지 얹은 SaaS 골격
• Figma 경로는 URL 접근성 체크만 구현 - 비전(Figma 파싱)과 실제 구현 사이의 간극을 남긴 채 멈춤

• 명세 없이도 테스트 범위를 추론 - 완벽한 명세를 기다리지 않고 산출물(문서)만으로 QA가 조기에 참여하게
• 체크리스트를 그룹으로 묶어 초안 제공 - QA가 백지에서 시작하지 않게
• 결제(Toss)까지 미리 붙여 SaaS 형태를 검증 - 다만 실 사용·실 결제로 이어지진 않음

• 자동 생성 체크리스트의 정확도·누락을 어떻게 측정하고 회귀를 막는가 - 항목이 그럴듯해도 이 검증 없이는 신뢰가 안 선다(이 프로젝트가 못 푼 핵심 난제)
• GPT-4o-mini가 같은 문서에도 실행마다 다른 항목·그룹을 낼 수 있어, 회귀 방지 설계 없이는 정확도를 애초에 고정할 수 없다는 게 멈춘 이유였는가
• 공개 Notion 페이지 파싱(Playwright + BeautifulSoup)이 문서 구조 변화·비공개·빈 페이지에서 견고하게 실패하는가
• 이름(Figma2Checklist)과 실제 구현(Notion 경로)의 간극을 감추지 않고 정직하게 드러냈는가

인증·저장·결제 연동까지 갖춘 풀스택으로 세운 뒤 휴면. 실 사용·실 결제로 이어지진 않았고 라이브 URL은 없다. 멈춘 진짜 이유는 기능이 아니라 - 자동 생성 체크리스트의 정확도·누락을 회귀 검증할 설계 없이는 항목이 그럴듯해도 신뢰가 안 선다는 것 - 그 자체가 이 프로젝트가 남긴 QA 교훈이다. 이름(Figma2Checklist)과 실제 구현(Notion 기반)의 간극은 정직하게 그대로 둔다.