인포시즈 Product Designer(Architect)는 정답 없는 엔터프라이즈 제품의 정보구조·UX·워크플로우를 설계하고 복잡한 문제를 사용 가능한 구조로 만들며 기술/AI 를 깊이 이해합니다. 화면·컴포넌트 스펙의 시스템 준수를 규칙으로 검사하는 이 게이트는 그 구조화·논리적 사고 역량과 기술 구현력(규칙으로 일관성을 강제하는 일)을 정면으로 입증합니다. 디자인 자체의 미적 판단·제품 방향 설계는 작업물 포트폴리오로 따로 증명되는 영역이라 이 도구가 대신 주장하지 않습니다. 스펙 신호를 디자인 시스템 규칙·차단 가드로 잇는 사슬은 단순 디자인 검토 맥락으로는 그대로 만들 수 없습니다.
제품의 정보구조(IA)·사용자 경험(UX)·워크플로우를 설계합니다. IA 깊이·UX 규칙 검사가 직접 정렬됩니다.
벤치마킹할 경쟁 제품이 없는 새 제품을 논리적으로 구조화합니다. 규칙 기반 준수 검사가 환경과 정렬됩니다.
B2B SaaS·엔터프라이즈 소프트웨어를 설계하고 기술/AI 를 깊이 이해합니다. 게이트 도구 구현이 기술 이해와 정렬됩니다.
화면·컴포넌트 스펙(토큰·간격·색 대비·접근성 속성·IA 깊이)을 받아, 규칙(토큰 위반·대비 미달·접근성 속성 누락·IA 과깊이·결측)으로 통과할지 수정할지 반려할지 정합니다. 정답 여부는 디자인 시스템 규칙과 임계(대비비·토큰 스케일·IA 최대 깊이)로 결정하고, LLM 은 수정 가이드 문장화 보조만 맡습니다. 미적 우열 판정이 아니라 시스템 준수 여부의 객관 게이트입니다.
인포시즈 Product Designer(Architect). 여러 화면 스펙이 디자인 시스템을 지키는지 일일이 눈으로 대조하던 일을, 한 게이트에서 스펙·규칙 위반·수정 가이드를 함께 보고 싶은 사람입니다.
화면·컴포넌트 스펙을 한 스키마로 묶고 디자인 시스템 규칙을 붙이면, (a) 토큰 위반·대비 미달·접근성 누락·IA 과깊이를 규칙으로 거르고, (b) 위반 사유를 스펙 값 인용으로 풀며, (c) 많은 화면을 화면군별로 끊김 없이 검사합니다.
화면·컴포넌트 스펙을 받아 디자인 시스템 규칙으로 통과·수정·반려를 정하고 위반을 막는 동작하는 게이트입니다. 스펙은 디자인 토큰·화면을 가정한 더미로 시작합니다.
준수 판정을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
화면군·규칙 타입별 준수율과 반려 사유 분포를 누적 집계해 약한 화면군을 보여주는 화면입니다.
검사 시나리오 12종(정상·토큰 위반·대비 미달)을 넣으면, 통과·수정·반려 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(IA 깊이 null·미등록 화면군·토큰 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 통과/반려 판정이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 인포시즈의 실 디자인 시스템·실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 실 제품·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 디자인 시스템 규칙 게이트 + 스펙 검증 + 위반 차단 기술입니다. 디자인 자체의 미적 판단·제품 방향 설계 역량은 작업물 포트폴리오로 따로 증명되는 영역이라 이 도구가 대신 주장하지 않으며, 모르는 깊이는 면접에서 솔직히 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 IA 깊이 결측·미등록 화면군·토큰 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 검사만 통과시키는 게 아님을 보여줍니다
미적 우열은 규칙으로 단정할 수 없습니다. 그래서 이 게이트는 '예쁜가'가 아니라 토큰·대비·접근성·IA 깊이 같은 시스템 준수 여부만 객관적으로 보고, 애매한 미적 판단은 검토로 돌립니다
화면군·토큰 표기가 제각각입니다. 정규화로 같은 화면군으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 디자인 시스템 규칙·임계가 더미와 다르므로 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
화면·컴포넌트 디자인 시스템 준수 검사 로그. 준수 규칙이 가장 먼저 질의하는 테이블입니다. IA 깊이 결측·미등록 화면군·토큰 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| item_id | group_raw | group_id | token_ok | contrast_ok | aria_ok | ia_depth | label | ts |
|---|---|---|---|---|---|---|---|---|
| ds_001 | 대시보드 | dashboard | true | true | true | 3 | pass | 2026-03-04T09:00 |
| ds_002 | 대시보드 | dashboard | false | true | true | 3 | fix | 2026-03-04T10:00 |
| ds_003 | 설정 | settings | true | false | false | 4 | reject | 2026-03-04T11:00 |
| ds_004 | 설 정 | settings | true | true | true | 7 | reject | 2026-03-04T12:00 |
| ds_005 | 신규화면군X | — | true | true | true | 3 | review | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 디자인 검사 60행 JSON 배열로 생성합니다. 화면군 2~3개, 정상 위주에 수정·반려를 섞습니다. label 규칙: (contrast_ok=false & aria_ok=false) 또는 ia_depth>=5 또는 (token_ok=false & contrast_ok=false) → reject, token_ok=false(단독) 또는 aria_ok=false(단독) → fix, group_id=null 또는 ia_depth=null → review, 그 외 → pass.
z.object({ item_id: z.string(), group_raw: z.string(), group_id: z.string().nullable(), token_ok: z.boolean(), contrast_ok: z.boolean(), aria_ok: z.boolean(), ia_depth: z.number().nullable(), label: z.enum(["pass","fix","reject"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 검사만 통과시키는 함정 회피): (1) 같은 화면군의 표기 별칭('대시보드'/'대 시보드', '설정'/'설 정'처럼 group_master 로 정규화돼야 함) 3건 이상, (2) 미등록 화면군(group_id=null) 2건, (3) 결측: ia_depth 가 null 인 행 1~2건, (4) 경계값 — 복합 위반(대비+접근성 동시 실패)·IA 과깊이(ia_depth 5 이상) 각 2건, (5) 단일 위반(token 또는 aria 하나만 실패) fix 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.z.object({ item_id: z.string(), group_raw: z.string(), group_id: z.string().nullable(), token_ok: z.boolean(), contrast_ok: z.boolean(), aria_ok: z.boolean(), ia_depth: z.number().nullable(), label: z.enum(["pass","fix","reject"]), ts: z.string() })| 디자인 시스템 | 토큰·간격·대비·접근성·IA 규칙의 출처(검사 기준)입니다 |
| TypeScript | 스펙 파서·검사 규칙·출력 스키마(Zod)의 구현 언어입니다 |
| Zod | 화면·컴포넌트 스펙과 게이트 출력의 런타임 형식 검증입니다 |
| React | 화면군 그리드·검사 카드·위반 하이라이트를 렌더하는 프레임워크입니다 |
| WCAG | 색 대비·접근성 속성 검사의 기준(대비비 임계)입니다 |
| Claude | 수정 가이드 문장화 보조 LLM(판정은 규칙)입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(화면군별 준수율 추이)로 진행합니다.
스펙 1건의 준수 검사 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 미적 우열이 아니라 시스템 준수 여부 게이트입니다.
z.object({ item_id: z.string(), group_id: z.string().nullable(), decision: z.enum(["pass","fix","reject"]), factors: z.array(z.enum(["token_violation","contrast_fail","missing_aria","ia_too_deep","unmapped_group","missing_metric"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "ds_003 (대비 미달 + 접근성 누락)",
"output": {
"item_id": "ds_003",
"group_id": "settings",
"decision": "reject",
"factors": [
"contrast_fail",
"missing_aria"
],
"reason": "색 대비가 WCAG 임계에 못 미치고 접근성 속성도 누락돼 사용성·접근성을 동시에 해칩니다. 그대로 내보낼 수 없어 반려합니다.",
"evidence": "contrast_ok=false, aria_ok=false",
"hedge": "대비·접근성 동시 위반이라 반려합니다"
}
},
{
"input_ref": "ds_004 (IA 과깊이)",
"output": {
"item_id": "ds_004",
"group_id": "settings",
"decision": "reject",
"factors": [
"ia_too_deep"
],
"reason": "정보구조 깊이가 7 단계로 시스템 최대 깊이를 넘어 사용자가 길을 잃습니다. 구조 재설계가 필요해 반려합니다.",
"evidence": "ia_depth=7",
"hedge": "IA 깊이가 임계를 넘어 반려합니다"
}
},
{
"input_ref": "ds_005 (미등록 화면군)",
"output": {
"item_id": "ds_005",
"group_id": null,
"decision": "review",
"factors": [
"unmapped_group"
],
"reason": "화면군이 마스터에 없어 통과를 단정하지 않습니다. 규칙은 모두 통과했으나 화면군 등록 후 재평가가 필요해 검토로 둡니다.",
"evidence": "group_id=null, token_ok=true",
"hedge": "미등록 화면군이라 자동 통과하지 않고 검토로 둡니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 준수 규칙(복합위반/IA과깊이→reject·단일위반→fix·미등록/결측→review·통과→pass)과 일치하는지 봅니다. 3. evidence 가 입력 스펙의 실제 값 인용인지 토큰 매칭으로 확인합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 준수를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.