'인프라 변경 없이도 SEO·AI 검색 대응을 자동화할 수 있게 한다' 는 공고 문장이 이 콘솔의 방식(페이지를 받아 점검·개선안만 내는 것)을 그대로 정의합니다. Search OS 가 CSR·SSR·SPA·레거시를 모두 지원한다고 밝힌 만큼, 렌더 방식별 점검을 규칙으로 다룬 이 도구가 그 제품 방향의 진단 축과 붙습니다. 이 포트폴리오가 입증하는 것은 렌더·검색 항목을 규칙으로 점검하고 개선안 생성을 분리하는 구현이며, 검색 순위 알고리즘이나 GEO 전문성은 주장하지 않습니다. 실제 인용 성과의 인과는 면접에서 모른다고 말하는 편이 낫습니다.
공고가 대규모 플랫폼이 인프라 변경 없이 SEO·AI 검색 대응을 자동화하게 한다고 밝힙니다. 페이지를 규칙으로 점검하고 개선안을 생성하는 이 콘솔이 그 자동화의 진단 축입니다.
SSR/CSR/Edge Rendering 구조 이해와 Next.js 경험, SEO/GEO 개념 이해를 요구합니다. 페이지의 렌더 방식별 점검이 그 기술 이해를 그대로 씁니다.
분석에서 멈추지 않고 실행까지 자동화하는 데 집착하는 사람을 찾습니다. 점검에 그치지 않고 개선안 생성까지 잇는 이 콘솔이 그 태도와 맞습니다.
고객사 페이지(URL·렌더 방식·제목·메타·구조화 데이터)를 받아, 검색 엔진과 AI 검색이 인용하기 좋은 항목을 규칙으로 점검하고(제목 길이·메타 존재·구조화 데이터 유효성·정규 주소·렌더 방식), 실패 항목은 LLM 이 채운 개선안을 원안과 나란히 보여주는 진단 콘솔입니다. 각 판정은 어느 항목을 왜 통과·실패했는지 원문 근거와 함께 추적됩니다.
여러 고객사 페이지가 검색과 AI 답변에 왜 덜 노출되는지 페이지마다 소스를 열어 손으로 확인하던 담당자입니다. 점검은 콘솔이 먼저 해두고, 실패 항목의 개선안을 원안과 비교해 바로 적용 판단하고 싶은 사람입니다.
검색·AI 인용에 필요한 항목을 규칙으로 점검하고 실패분만 LLM 개선안으로 채우면, 페이지 대응을 자동 진단하면서도 통과·실패 근거가 항목과 원문에 걸려 담당자가 개선안만 검토하면 됩니다.
검색·AI 인용 항목 점검 규칙 엔진(제목·메타·구조화 데이터·정규 주소, 단위 테스트 포함)과 개선안 생성, 진단 콘솔까지 Next.js 로 묶어 Vercel 에 배포한 완결품입니다. 실크롤링 대신 페이지 스냅샷 더미를 입력으로 시작합니다(실크롤·자동 적용은 2·3주차).
사람이 라벨링한 페이지 점검 정답표 대비 항목 판정 일치율 리포트와, 구조화 데이터 깨짐·렌더별 제목 결측 경계 케이스 회귀 테스트가 남은 상태입니다.
고객사 URL 을 실제 크롤해 점검하고, target_keyword 대비 제목·본문 대응을 진단해 우선순위 리포트로 정렬하는 흐름이 붙은 상태입니다.
페이지를 넣으면 항목별 점검 결과와 실패분 개선안이 원안과 나란히 나오는 흐름을 시연합니다(구조화 데이터 깨짐·제목 결측 포함).
항목 점검 판정을 사람 라벨 정답표와 대조한 일치율을 보여줍니다(표본: 페이지 60건, 자가 라벨, 항목별 통과·실패 판정 기준).
일부러 만든 구조화 데이터 깨짐·제목 결측·CSR 미렌더·정규 주소 충돌 30종을 넣어도 점검 형식이 깨지지 않고 정확히 실패로 잡힘을 보여줍니다.
위 수치는 작성자가 만든 더미 페이지와 자가 라벨 기준이라 성능 증명이 아니라 데모 조건 동작이며, 개선안이 실제 검색·AI 인용을 높이는지는 서치오에스에이아이의 고객사 데이터와 실측 지표가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
점검 일치율은 작성자가 만든 더미 페이지와 자가 라벨 기준의 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 검증 구조로 솔직하게 설명합니다.
정답을 내가 만들었으니 잘 맞는 게 당연해지는 함정이 있어, 구조화 데이터 깨짐·제목 결측·CSR 미렌더·정규 주소 충돌을 페이지 더미에 일부러 섞습니다.
점검 항목 통과가 실제 검색·AI 인용 상승을 보장하지 않으므로(상관≠인과), 이 도구는 점검·개선안 생성까지만 입증하고 성과 인과는 검증 대상에서 뺍니다.
실서비스 전환 시 실제 렌더링 후 DOM 크롤과 사이트별 예외 처리가 필요하며, 이는 스냅샷 더미와 달라지는 부분으로 분리해 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
점검 엔진의 입력이 되는 고객사 페이지 스냅샷입니다. 결측·구조화 데이터 깨짐·렌더 방식 차이를 일부러 담아 점검 분기를 시험합니다.
| url | render | title | meta_description | h1 | structured_data | canonical | target_keyword |
|---|---|---|---|---|---|---|---|
| https://shop.example.com/p/1 | SSR | 겨울 패딩 베스트 10 | Example | 따뜻한 겨울 패딩 추천 | 겨울 패딩 추천 | {"@type":"Product"} | https://shop.example.com/p/1 | 겨울 패딩 |
| https://shop.example.com/p/2 | CSR | — | — | — | — | — | 러닝화 |
| https://shop.example.com/p/3 | SSR | 이 페이지는 정말 길고 검색 결과에서 잘려서 사용자에게 제대로 노출되… | 설명 | 제품 | {invalid json | https://shop.example.com/p/3 | 가방 |
| https://shop.example.com/p/4 | SPA | 제품 상세 | 제품 상세 | — | https://shop.example.com/p/9 | 지갑 | |
| https://blog.example.com/a/1 | SSR | AI 검색 최적화 가이드 | AI 검색에 잘 노출되는 법 | AI 검색 최적화 | {"@type":"Article"} | https://blog.example.com/a/1 | AI 검색 |
다음 JSON Schema 를 그대로 만족하는 페이지 스냅샷 행을 40개 더 만들어 주세요: {"type":"object","properties":{"url":{"type":"string"},"render":{"type":"string","enum":["CSR","SSR","SPA","legacy"]},"title":{"type":["string","null"]},"meta_description":{"type":["string","null"]},"h1":{"type":["string","null"]},"structured_data":{"type":["string","null"]},"canonical":{"type":["string","null"]},"target_keyword":{"type":["string","null"]}},"required":["url","render"]} url·title·meta 는 실제 상거래·블로그 페이지처럼 현실적이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) title·meta_description·h1 중 하나 이상이 null(결측) 6건, (2) structured_data 가 깨진 JSON 또는 빈 name 5건, (3) CSR·SPA 라 서버 응답에 제목이 비는 렌더 결측 5건, (4) canonical 이 다른 URL 을 가리키는 정규 주소 충돌 3건, (5) title 이 과도하게 길어 검색 결과에서 잘리는 경계 3건.{"type":"object","properties":{"url":{"type":"string"},"render":{"type":"string","enum":["CSR","SSR","SPA","legacy"]},"title":{"type":["string","null"]},"meta_description":{"type":["string","null"]},"h1":{"type":["string","null"]},"structured_data":{"type":["string","null"]},"canonical":{"type":["string","null"]},"target_keyword":{"type":["string","null"]}},"required":["url","render"]}점검 통과·실패를 결정하는 규칙입니다. 어느 항목을 어떤 기준으로 보고 실패·경고인지 담아 정답을 규칙으로 결정합니다.
| rule_id | field | check | severity |
|---|---|---|---|
| S-001 | title | 존재하고 15~60자 사이여야 함 | fail |
| S-002 | meta_description | 존재하고 50~160자 사이여야 함 | warn |
| S-003 | h1 | 페이지에 정확히 하나 존재해야 함 | warn |
| S-004 | structured_data | 유효한 JSON 이고 @type 이 있어야 함 | fail |
| S-005 | canonical | 자기 URL 을 가리켜야 함(다른 URL 이면 충돌) | fail |
다음 JSON Schema 를 그대로 만족하는 점검 규칙 행을 15개 더 만들어 주세요: {"type":"object","properties":{"rule_id":{"type":"string"},"field":{"type":"string"},"check":{"type":"string"},"severity":{"type":"string","enum":["fail","warn"]}},"required":["rule_id","field","check","severity"]} field 는 page_snapshots 의 필드여야 하고 check 는 결정론으로 판정 가능한 기준이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) severity 가 warn 이라 실패가 아니라 경고인 규칙 5건, (2) 같은 field 에 대해 결측·형식·중복을 각각 보는 규칙 3건.{"type":"object","properties":{"rule_id":{"type":"string"},"field":{"type":"string"},"check":{"type":"string"},"severity":{"type":"string","enum":["fail","warn"]}},"required":["rule_id","field","check","severity"]}| Next.js | 진단 콘솔 앱 프레임워크이며 SSR/CSR 렌더 방식별 점검 로직과 함께 1주차 완성품을 Vercel 로 배포합니다 |
| TypeScript | 페이지 점검 규칙 엔진과 콘솔의 구현 언어입니다. 점검 로직의 단위 테스트를 여기서 돌립니다 |
| LLM | 실패한 항목(제목·메타·구조화 데이터)의 개선안 문구를 원안 근거에 맞춰 생성합니다 |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 라벨 정답 대조와 실크롤·키워드 대응으로 넘어갑니다.
✓ pass → 실제 URL 크롤과 키워드 대응 진단으로 넘어갑니다.
규칙 점검 결과와 실패 항목 개선안입니다. 항목마다 원문 근거를 달고 개선안은 실패분에만 채웁니다.
{"type":"object","properties":{"url":{"type":"string"},"issues":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"status":{"type":"string","enum":["ok","fail","warn"]},"evidence":{"type":"string"}},"required":["field","status","evidence"]}},"proposed":{"type":"object","properties":{"title":{"type":["string","null"]},"meta_description":{"type":["string","null"]},"structured_data":{"type":["string","null"]}}},"hedge":{"type":"string"}},"required":["url","issues","proposed","hedge"]}[
{
"url": "https://shop.example.com/p/2",
"issues": [
{
"field": "title",
"status": "fail",
"evidence": "title=null"
},
{
"field": "structured_data",
"status": "fail",
"evidence": "structured_data=null"
},
{
"field": "render",
"status": "warn",
"evidence": "render=CSR 로 서버 응답에 제목이 비어 있음"
}
],
"proposed": {
"title": "러닝화 추천 베스트 | Example",
"meta_description": "가볍고 편한 러닝화를 한눈에 비교해 보세요.",
"structured_data": "{\"@type\":\"Product\",\"name\":\"러닝화\"}"
},
"hedge": "개선안은 target_keyword 기반 제안이며 실제 검색 성과를 보장하지 않습니다. 합성 페이지 기준입니다."
},
{
"url": "https://shop.example.com/p/3",
"issues": [
{
"field": "title",
"status": "fail",
"evidence": "title 길이 60자 초과"
},
{
"field": "structured_data",
"status": "fail",
"evidence": "structured_data 가 깨진 JSON"
}
],
"proposed": {
"title": "가방 추천 | Example",
"meta_description": null,
"structured_data": "{\"@type\":\"Product\",\"name\":\"가방\"}"
},
"hedge": "긴 제목은 잘림 위험만 규칙으로 잡고 문구 품질은 사람 검토가 필요합니다."
},
{
"url": "https://shop.example.com/p/6",
"issues": [
{
"field": "title",
"status": "ok",
"evidence": "운동화 | Example (13자, 키워드 포함)"
},
{
"field": "structured_data",
"status": "ok",
"evidence": "@type=Product 유효"
}
],
"proposed": {
"title": null,
"meta_description": null,
"structured_data": null
},
"hedge": "통과 항목은 개선안을 생성하지 않았습니다. 합성 기준 점검입니다."
}
][자동 검증 · 스크립트가 전수 수행] 1. 출력이 JSON Schema 형식을 통과하는지 확인합니다(형식 깨진 진단이 콘솔에 나가는 것을 차단). 2. issues 의 status 가 규칙 엔진 재실행 결과와 100% 일치하는지 확인합니다(정답은 LLM 이 아니라 규칙이 결정). 3. proposed 개선안이 status=fail·warn 항목에만 채워졌는지, ok 항목엔 null 인지 확인합니다(불필요 생성 차단). [수동 검증 · 사람이 표본 확인] 1. 개선안이 원문 주제·키워드를 벗어나 과장하지 않는지 페이지 30건을 표본 검토합니다. 2. 통과 항목에 개선안이 생성되지 않았는지 확인합니다.