웹퍼블리셔 2026 로드맵: 포트폴리오와 AI 활용 기준

• 직무명보다 산출물 범위 정하기
• 웹표준·접근성·호환성 근거
• 포트폴리오 증거 설계
• AI를 미검증 초안으로 다루기
• 4주 실행 계획
• 결론과 다음 행동

학습 목표: 기존 페이지 한 개를 골라 반응형·키보드·폼 오류를 직접 점검하고, 재현 가능한 이슈 기록 1개를 완성합니다. 준비물은 수정 가능한 HTML·CSS 파일과 브라우저입니다. 프로젝트 개수와 4주 일정은 편집 제안이며 숙련도에 따라 조정합니다.

1. 직무명보다 제출할 산출물의 범위를 정합니다

공고 요구를 그대로 분류합니다

같은 “웹퍼블리셔”라도 한 조직은 시맨틱 HTML과 CSS를, 다른 조직은 디자인 시스템·JavaScript 인터랙션·템플릿 엔진까지 요구할 수 있습니다. 먼저 지원하려는 공고 10개에서 반복되는 업무와 우대 사항을 표로 만들고, 이 글의 로드맵과 다른 항목은 공고를 우선합니다. “2026년에는 반드시 이 기술” 같은 단정 대신 실제 요구 빈도와 본인의 증거 유무를 기록하세요.

최소 산출물을 다섯 묶음으로 고정합니다

산출물	보여줄 증거	피해야 할 대체물
시맨틱 HTML	랜드마크·제목 계층·폼 label 구조	div만 많은 화면 캡처
반응형 CSS	390·768·1440px와 긴 텍스트·확대 테스트	한 해상도 스크린샷
접근성	키보드 순서·focus·오류 연결·대체 텍스트	자동 점수 하나
호환성·성능	대상 브라우저 버전, 재현 절차, 전후 측정	검사 환경이 없는 호환성 완료 문장
협업	이슈·작은 커밋·PR 설명·회귀 검증	완성본 저장소 링크만 제시

2. 품질 기준은 공식 문서와 실제 테스트를 함께 사용합니다

HTML은 요소 의미와 문서 구조부터 확인합니다

WHATWG 문서는 현재 HTML Living Standard를 제공합니다. 요소를 외우는 데 그치지 말고 페이지의 landmark, 제목 계층, form control과 label 관계를 설명할 수 있어야 합니다. 기준 문서는 WHATWG HTML Living Standard입니다.

<header>
  <nav aria-label="주요 메뉴">...</nav>
</header>
<main>
  <h1>프로젝트 제목</h1>
  <section aria-labelledby="project-result">
    <h2 id="project-result">검증 결과</h2>
    <p>키보드·브라우저·성능 테스트 범위와 수정 기록</p>
  </section>
</main>

접근성은 WCAG 항목을 사용자 시나리오로 바꿉니다

WCAG 2.2는 키보드 사용, focus, 이름·역할·값, 오류 식별 같은 성공 기준을 제공합니다. 포트폴리오에는 “WCAG 준수”라고 넓게 쓰기보다 어떤 성공 기준을 어떤 시나리오로 확인했는지 남기세요. 예를 들어 메뉴를 키보드만으로 열고 닫으며, modal을 닫은 뒤 focus가 trigger로 돌아오는지 기록합니다. 근거는 W3C WCAG 2.2입니다.

.button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after { scroll-behavior: auto; }
}

Baseline은 브라우저 테스트를 대체하지 않습니다

MDN Baseline은 주요 브라우저에서 웹 기능을 사용할 수 있는지를 요약하지만, 오래된 기기·WebView·보조공학·성능까지 보장하지 않습니다. 따라서 MDN Baseline 호환성 기준으로 후보 기능을 검토한 뒤, 프로젝트가 지원하는 실제 브라우저·기기 조합에서 다시 테스트합니다.

Lighthouse 점수는 자동화된 신호로 사용합니다

Lighthouse는 성능·접근성·SEO 등의 자동 감사를 제공하지만 모든 사용자 문제를 찾는 것은 아닙니다. 동일한 URL·기기·네트워크 조건에서 JSON을 저장해 전후를 비교하고, 키보드·화면낭독기·실기기 검사를 별도로 남깁니다. 도구의 범위는 Chrome Lighthouse 공식 안내에서 확인하세요.

실습: 문의 폼의 오류 연결 점검

기존 문의 폼에서 필수 입력을 비우고 제출해 보세요. 아래는 직접 수행할 점검 절차이며 이 글에서 모든 프로젝트의 접근성을 검증했다는 뜻은 아닙니다.

순서	직접 할 일	확인할 결과
1	마우스를 사용하지 않고 Tab으로 이동	순서가 자연스럽고 현재 초점이 보임
2	필수 입력을 비운 뒤 제출	문제 항목과 수정 방법을 텍스트로 안내
3	오류 입력을 수정하고 다시 제출	이전 오류가 해제되고 정상 흐름으로 진행
4	화면 확대·좁은 폭·긴 문구로 반복	버튼과 오류 안내가 겹치지 않음
5	실패 사례를 하나 골라 수정	같은 순서로 다시 실행해 전후 비교

기본 확인만으로 WCAG 전체 준수를 판정할 수는 없습니다. 실제 지원 기기·브라우저·보조기술의 범위를 기록하고 확인하지 않은 조합은 별도로 남깁니다. 기초 실습은 접근 가능한 폼과 반응형 카드를 사용합니다.

대상: 문의 폼
환경: 실제 사용한 브라우저와 화면 폭
재현: 필수 항목을 비우고 키보드로 제출
관찰: 오류 메시지가 입력과 떨어져 있어 원인을 찾기 어려움
수정: 입력에 오류 설명을 연결하고 안내 위치 정리
재확인: 같은 조작에서 오류와 수정 방법을 찾을 수 있는지 기록
미확인: 이번에 사용하지 않은 브라우저·보조기술

3. 프로젝트 2~3개를 서로 다른 증거로 설계합니다

프로젝트 수보다 중복되지 않는 검증 범위가 중요합니다

• 콘텐츠/랜딩: 시맨틱 구조, 반응형 타이포, 이미지 최적화와 레이아웃 이동.
• 폼/커머스: label, 오류 연결, 키보드, 입력 상태와 다양한 데이터 길이.
• 인터랙션: dialog·tab·accordion의 focus 이동, Escape, reduced motion.

README를 검증 리포트로 만듭니다

## 검증 범위
- 키보드: Tab / Shift+Tab / Enter / Space / Escape
- 화면: 390px / 768px / 1440px
- 브라우저: Chrome / Edge / Safari 실제 버전 기록
- 접근성: 레이블, 오류 연결, focus 순서, 대체 텍스트
- 성능: 동일 환경의 Lighthouse JSON 전후 비교
- 회귀: 발견 이슈, 수정 커밋, 재검증 결과

각 이슈에는 재현 조건, 원인, 수정, 재검증 결과를 연결합니다. 공개 저장소에 고객 데이터·디자인 원본·비밀키가 섞이지 않았는지도 제출 전에 검사합니다. 화면 캡처는 보조 자료이고, 작동하는 배포 URL·코드·테스트 기록이 본 증거입니다.

4. AI는 속도를 높이는 미검증 초안으로 사용합니다

잘 맡길 수 있는 일

요구사항을 체크리스트로 바꾸기, 경계값 테스트를 넓히기, PR 설명 초안을 만들기, 반복 마크업의 누락 후보를 찾기는 유용합니다. 다만 생성 결과의 ARIA·브라우저 지원·성능 주장은 공식 문서와 실행 결과로 다시 확인합니다.

직접 책임져야 하는 일

• API 키·토큰·고객 정보·비공개 디자인 원본을 입력하지 않습니다.
• 코드 라이선스와 출처를 확인하고 이해하지 못한 코드를 제출하지 않습니다.
• AI가 제안한 ARIA보다 native HTML 요소를 먼저 검토합니다.
• README에는 AI 사용 여부보다 검증 과정과 본인이 내린 결정을 기록합니다.

5. 4주 실행 계획

주차	목표	완료 증거
1주차	공고 10개 분석, 프로젝트별 증명 항목 확정	요구사항 표와 지원 브라우저·화면 폭
2주차	HTML 구조·폼·키보드 흐름 완성	수동 접근성 체크와 이슈 기록
3주차	호환성·성능 재현과 수정	브라우저별 결과와 Lighthouse 전후 JSON
4주차	회귀 테스트·README·면접 설명 정리	배포 URL, 코드, 검증 리포트, 3분 설명

4주는 보장된 취업 기간이 아니라 산출물을 끝내기 위한 작업 상자입니다. 일정이 부족하면 프로젝트 수를 줄이고, 접근성·호환성·검증 기록은 남깁니다.

6. 오늘 남길 점검 결과

2026 웹퍼블리셔 포트폴리오의 설득력은 기술 이름의 수가 아니라 “어떤 기준으로 구현했고 어떻게 검증했는가”에서 나옵니다. 오늘 할 다음 행동은 지원 공고 10개를 모아 반복 업무를 다섯 산출물에 매핑하고, 첫 프로젝트 README에 검증 범위를 먼저 쓰는 것입니다.

공식 근거

• WHATWG HTML Living Standard
• W3C WCAG 2.2
• MDN Baseline 호환성 기준
• Chrome Lighthouse 공식 안내

내부 학습 경로

• 프론트엔드 이력서와 프로젝트 구성 기준
• AI 시대 개발자 포트폴리오 증거 설계
• React·Next.js·TypeScript 학습 범위 확인

공식 자료와 확인 범위

공식 자료 확인일: 2026년 9월 13일. 아래 문서는 기술·문서 작성·측정 기능의 근거입니다. 학습 순서와 작성 예시는 이 글의 편집 제안이며 채용 합격률이나 회사의 평가 기준을 입증하는 통계가 아닙니다.

• W3C 접근성 기초 점검