이 글은 Hacktoberfest Week 2: Side Hustle에 제출한 내용입니다.
제작 내용
랜딩 페이지는 연락처 링크가 잘못된 주소를 가리키더라도 완성된 것처럼 보일 수 있습니다. 또 다른 약속은 판단하기 더 어렵습니다. 양식(form)이 올바른 필드를 가지고 있더라도 메시지를 전달하지 못할 수 있기 때문입니다.
Checkilex는 프리랜서 웹 개발자가 간략한 기획서(brief)를 검토된 체크리스트와 페이지가 실제로 증명하는 내용을 기록으로 남기는 데 도움을 줍니다.
영어 또는 로마 우르두어(Roman Urdu)로 작성된 기획서를 붙여넣으면, 로컬 Qwen 모델이 최대 여덟 가지의 점검 항목을 제안하며, 각 항목은 클라이언트가 제공한 원래 문구에 연결됩니다. 이 목록을 검토하고 실수를 수정한 다음, 개발자가 통제하는 로컬 페이지를 검사합니다. 결과에는 데스크톱/모바일 캡처와 내보내기 가능한 Markdown 보고서가 포함됩니다.
의도된 고객은 소규모 비즈니스 사이트를 납품할 준비를 하는 프리랜서입니다. 테스트 가치는 체크리스트 작성보다 더 명확한 인계(handoff)에 있습니다. 이와 관련하여 유료 설정이나 지원이 부업이 될 수 있습니다. 아직 고객, 결제 또는 측정된 시간 절약 증거는 없습니다.
데모
45초 분량의 워크스루 보기.
Actual report for a fictional café with planted defects
이것은 고객 세션이 아닌, 합성 데이터로 실제 로컬 앱을 자동 운영한 것입니다. 녹화된 영상에는 32.1초의 추론 대기 시간까지 포함되어 있으며, 무음으로 끊김 없이 담겨 있습니다. Checkilex 이름 변경 이전에 'Site Delivery Check'라는 이름으로 기록되었습니다. 위의 스크린샷은 현재 이름을 사용하고, 기록된 모델 초안을 재현하며, 신선한 브라우저 측정을 수집합니다.
결함이 있는 카페는 세 가지 실패(Failed) 항목을 생성합니다: 숨겨진 영업시간, 잘못된 이메일 주소, 모바일 오버플로우. 좋은 시설로 전환하면 세 가지 검증됨(Verified) 항목이 나옵니다. 이메일 전달 약속은 둘 다 미검증(Unverified) 상태를 유지합니다.
마지막 결과가 중요합니다. 양식은 제출되지 않았고, 메시지가 받은 편지함에 도달했다는 것을 확립한 것도 없습니다. 보고서는 그 발견 사항 옆에 이러한 한계를 보존합니다.
코드
소스, 설정 지침 및 평가 증거.
이 애플리케이션은 MIT 라이선스를 따릅니다. 모든 애플리케이션 코드, 카페 장치(fixtures) 및 평가 브리프는 이 챌린지 기간 동안 작성되었습니다. 이전에 다운로드된 런타임, 가중치 및 브라우저 캐시는 로컬에서 재사용되었습니다.
구축 방법
이 앱은 TypeScript, React, 소규모 Node HTTP 서버, Ollama 0.40.0, qwen3:1.7b 태그 및 Playwright 1.63.0을 사용합니다.
모델은 구조화된 체크 데이터를 반환합니다. 문자 그대로의 텍스트, 링크 레이블 및 목적지는 원본 인용구에 근거합니다(grounded). 알려진 선택적 및 부정어는 구체적인 제안을 제한합니다. 모든 초안은 누락 및 의미에 대한 검토가 여전히 필요합니다.
고정된 체크(Fixed checks)는 1366 × 900 및 390 × 844에서 보이는 텍스트, 정확한 링크 목적지, 지정된 양식 필드 및 수평 오버플로우를 측정합니다. 브라우저는 새로운 컨텍스트와 하나의 명시적인 로컬 출처에 대한 제한된 요청을 사용합니다. 양식은 절대 제출되지 않습니다. 브리프, 체크리스트 또는 대상 편집은 보고서를 폐기합니다.
저의 첫 번째 평가는 실망스러웠습니다:
| 고정 세트 (Frozen set) | 전체 파이프라인 (Complete pipeline) | 키워드 비교기 (Keyword comparator) |
|---|
| 원본 제외 16개 브리프 (Original held-out 16 briefs) | 12/16 | 14/16 |
| 근거 수정 후 새로운 16개 브리프 (Fresh 16 briefs after grounding revision) | 16/16 | 8/16 |
원본 모델은 필수 양식 필드를 누락했고, 모호하거나 모순되는 Roman Urdu 요청을 잘못 읽었습니다. 저는 이러한 실패 사례를 유지하고, 근거(grounding)를 강화한 다음, 재실행하기 전에 새로운 케이스를 고정했습니다.
동일한 근거 규칙을 사용한 더 강력한 비교기는 새로운 세트에서 11/16점을 받았습니다. 수정된 16/16점 결과는 전체 파이프라인에 속합니다. 이러한 작고 목표 지향적인 합성 세트는 일반적인 신뢰성을 확립하지 못하며, 서로 다른 모집단입니다.
네 개의 심어진 브라우저 결함(planted browser defects)은 실패했고, 지원되지 않는 전달 약속(unsupported delivery promise)은 '미검증(Unverified)' 상태로 남아 있었습니다. 이 다섯 가지 단언에 걸쳐 거짓으로 '확인됨(Verified)' 처리된 결과는 0건이었습니다.
성능은 미완성입니다. 단일 요구사항 수정 사례는 제 i5-8350U 노트북에서 5.2~13.3초가 걸렸습니다. 8개 항목 확인 요청 모두 45초 타임아웃에 도달했습니다. 계획했던 30초의 8개 항목 목표는 여전히 달성되지 못했습니다.
Open Innovation이 중요한 이유?
Qwen's open weights와 Ollama는 추론(inference)을 개발자의 노트북에서 유지합니다. 이 앱은 클라이언트 브리프를 호스팅된 추론 API로 보내지 않습니다. 저는 제공업체의 엔드포인트에 의존하지 않고 스키마를 검사하고 변경하거나, 접지 규칙(grounding rules)을 수정하거나, 다른 모델을 테스트할 수 있습니다.
Playwright는 재현 가능한 브라우저 측정 및 캡처를 제공합니다. 이 저장소는 모델의 가중치 다이제스트(weight digest), 런타임 설정, 고정된 입력값, 그리고 원시 출력값을 기록합니다.
이러한 상충 관계는 데모에서 명확하게 보입니다: 이 장치에서의 로컬 추론은 느립니다. 요청당 API 비용은 없지만, 하드웨어, 전기, 설정에는 여전히 비용이 듭니다. 오픈 컴포넌트들이 이러한 특정 로컬 워크플로우를 가능하게 했지만, 그것을 측정해야 할 필요성까지 제거하지는 못했습니다.
다음으로 저는 동의하는 프리랜서가 이 시스템을 자신들의 기존 납품 체크리스트와 비교해 보기를 원합니다. 이는 또 다른 합성적 성공 횟수보다 비즈니스 아이디어를 더 잘 테스트할 것입니다.