AI 에이전트나 개발자용 Web 프로젝트를 비교할 때, 탑 페이지(Top page)의 인상만으로는 판단이 흔들리기 쉽습니다. 본 기사에서는 개인 개발 툴이나 디렉토리를 단시간에 확인하면서도, 나중에 동일한 절차를 재실행할 수 있는 평가 방법을 정리합니다.
먼저 평가 축을 고정해 두면, 인지도나 디자인에만 휘둘리지 않게 됩니다.
| 관점 | 확인 내용 |
|---|
| 목적의 명확성 | 누구의 어떤 문제를 해결하는 서비스인가 |
| ... | |
이하는 Node.js 18 이후 버전에서 실행할 수 있는 작은 확인 스크립트입니다. HTTP 상태(HTTP status), 최종 URL, 응답 시간을 기록합니다. 이는 품질을 자동 판정하는 것이 아니라, 수동 리뷰(Manual review) 대상을 좁히기 위한 전처리입니다.
const targets = process.argv.slice(2);
if (targets.length === 0) {
console.error("Usage: node check.mjs <url> [url...]");
...
자동 체크가 성공하더라도 로그인 필수, JavaScript 의존, 지역 제한 등으로 인해 실제 이용 경험이 다를 수 있습니다. 최종 판정에서는 브라우저로 주요 동선(User flow)을 확인합니다.
- 탑 페이지(Top page)만으로 서비스의 목적을 설명할 수 있는지 확인한다.
- 검색, 목록, 데모 등의 중심 기능을 1회 시도한다.
- 외부 링크, 이용 약관, 개인정보 정보를 확인한다.
- 모바일 너비와 키보드 조작으로 주요 동선을 확인한다.
- 판정 결과와 확인 일시를 CSV 또는 JSON에 저장한다.
결과는 verified, login_required, paid, unreachable, manual_review와 같은 소수의 상태로 통일하면, 나중에 재평가하기 쉬워집니다.
서로 다른 종류의 Web 프로젝트를 동일한 관점에서 확인하면, 체크리스트의 편향을 찾기 쉬워집니다.
- SkillSignal — AI 에이전트용 스킬을 찾을 때의 정보 설계를 확인하는 예.
- MCP Radars — MCP 관련 리소스의 발견 동선을 확인하는 예.
- ChatGPT Image 2 — AI 이미지 워크플로우를 다루는 Web 프로젝트의 예.
- Sunday Arcade — 브라우저 게임의 조작성이나 첫 진입 동선을 확인하는 예.
- Knit Blog — 개인 개발 기록이나 업데이트 정보의 노출 방식을 확인하는 예.
최소한 다음 항목을 남겨두면 차이(Diff) 확인에 사용할 수 있습니다.
{
"checked_at": "2026-08-04T00:00:00Z",
"input_url": "https://example.com/",
...
Web 프로젝트 평가에서는 자동 체크를 합불 판정으로 사용하지 않고, 수동 리뷰의 우선순위 지정에 사용하는 것이 안전합니다. 평가 축, 상태명, 기록 형식을 먼저 고정하면, 대상이 늘어나도 동일한 기준으로 비교하기 쉬워집니다.