2026 프론트엔드 개발자 로드맵: React, Next.js, TypeScript

• 현재 실력은 결과물로 확인하기
• 1. 의미와 배치가 유지되는 화면
• 2. 입력·상태·비동기의 연결
• 3. 데이터 형태와 없는 값의 구분
• 4. 상태의 위치와 화면 책임
• 5. 주소와 데이터 처리 위치
• 6. 검증과 AI 활용
• 완성 프로젝트의 제출 기준
• 다음 공부를 고르는 기준

현재 실력은 결과물로 확인하기

목표는 상품 목록과 검색 기능처럼 작은 화면 한 개를 끝까지 만드는 것입니다. 같은 기능을 바닐라 JavaScript에서 React로 옮기면 표현 방식의 차이를 비교할 수 있습니다. Next.js·서버 데이터·배포는 그 뒤에 필요한 범위만 더합니다.

단계	산출물	다음 단계로 넘어갈 기준
웹 퍼블리싱	반응형 목록과 입력 폼	키보드·긴 제목·좁은 화면에서 사용 가능
JavaScript	검색·필터·비동기 상태	입력→값 변경→화면 변화를 설명
TypeScript 기초	데이터·함수·props 타입	null·잘못된 입력을 구분
React	컴포넌트와 상태로 구성한 목록	상태 위치와 계산 값의 차이를 설명
Next.js	목록·상세·직접 주소 접근	서버 데이터와 클라이언트 상호작용 구분
검증·배포	다시 실행할 수 있는 프로젝트	실패 상태와 실행 방법을 기록

문법을 전부 외운 뒤 다음 기술을 시작할 필요는 없습니다. 통과 조건에서 막히는 지점만 해당 학습 글로 돌아가 고치고, 같은 사용자 흐름을 다시 확인합니다.

1. 의미와 배치가 유지되는 화면

제목·목록·링크·버튼·입력 요소를 역할에 맞게 배치합니다. 버튼을 클릭하지 않아도 키보드로 이동할 수 있는지, 입력에 이름표가 연결되는지 확인합니다. CSS에서는 정해진 화면 하나를 맞추는 것보다 긴 텍스트와 좁은 폭에서도 내용이 겹치지 않는지가 중요합니다.

• 상품 제목을 평소보다 길게 바꾸고 넘침·줄바꿈을 확인합니다.
• 화면 폭을 줄이고 가로 스크롤이 생긴 원인을 찾습니다.
• Tab 키로 검색 입력과 버튼에 이동해 초점이 보이는지 확인합니다.

화면 검증은 시맨틱 문서와 폼 실습 → 반응형 카드 실습로 이어집니다. 웹퍼블리싱 경험이 있어도 검증하지 않은 접근성 항목까지 완료로 적지는 않습니다.

2. 입력·상태·비동기의 연결

검색어를 읽고 배열을 필터링한 다음 화면에 표시합니다. 검색 결과가 없거나 요청이 실패했을 때도 사용자가 다음 행동을 할 수 있어야 합니다. React를 배우기 전에 DOM 코드 한 번을 작성하면 이벤트와 상태가 바뀌는 흐름을 비교하기 쉽습니다.

직접 할 일	확인 질문
검색과 필터를 함께 적용	두 조건을 모두 만족해야 하나, 하나만 맞으면 되나
검색어 초기화	전체 목록과 안내 문구도 함께 돌아오는가
비동기 요청	로딩·성공·실패를 구별하는가
빠른 연속 입력	이전 응답이 나중에 와도 최신 조건이 유지되는가

연습은 DOM 폼 실습과 fetch 오류 처리를 사용합니다. 예제 서버와 실제 서비스 API는 응답 구조·인증 조건이 다를 수 있으므로 연결했다고 동일하게 검증된 것은 아닙니다.

3. 데이터 형태와 없는 값의 구분

JavaScript 함수와 배열을 다룰 수 있다면 기본 타입을 붙여 봅니다. 상품의 가격은 숫자인지, 이미지가 없을 수 있는지, 검색 결과를 못 찾으면 무엇을 반환하는지 먼저 정합니다. 복잡한 타입 퍼즐보다 실제로 오류가 났던 값의 흐름을 명확하게 만드는 것이 이 단계의 목표입니다.

타입을 선언했다고 외부 API 응답이 런타임에서 검사되지는 않습니다. 응답이 예상과 다를 수 있는 위치에서는 실제 값을 확인하는 과정이 필요합니다. any로 오류를 없앤 뒤 완료로 처리하지 말고, 값의 형태를 좁히는 조건을 설명해 보세요.

기본 타입 실습 → union·unknown 좁히기 순서로 연습합니다. 다음 단계의 React props 타입에 같은 기준을 적용합니다.

4. 상태의 위치와 화면 책임

정적인 컴포넌트를 먼저 나누고 변경되는 값을 상태로 둡니다. 검색어와 원본 목록으로 계산할 수 있는 검색 결과까지 별도 상태로 저장하면 서로 어긋날 수 있습니다. 같은 값을 사용하는 컴포넌트가 어디에 있는지 보고 공통 부모에 둘지 판단하세요.

상품 카드가 보이는 일과 목록을 조회하는 일, 검색 조건을 관리하는 일이 어느 컴포넌트에 있는지 적어 봅니다. 모든 파일을 잘게 쪼개는 것이 목표는 아닙니다. 값이 바뀌었을 때 어느 화면이 다시 계산되는지 추적할 수 있어야 합니다.

제어 폼과 상태 끌어올리기를 끝낸 뒤 실제 서버 상태가 필요할 때 TanStack Query 첫 조회로 넘어갑니다. 전역 상태 도구는 여러 화면의 공유 문제가 생겼을 때 선택 근거를 따로 정리합니다.

5. 주소와 데이터 처리 위치

목록에서 상세 화면으로 이동한 뒤 주소를 직접 붙여 넣고 새로고침해 봅니다. 링크로만 접근했을 때와 직접 접근했을 때 같은 결과가 나와야 합니다. 존재하지 않는 상세 항목, 요청 실패, 로딩 중 화면도 구분합니다.

서버에서 데이터를 읽는 부분과 브라우저의 클릭·입력 상태를 다루는 부분을 나눕니다. 처음에는 데이터가 어디서 읽히고 언제 화면에 전달되는지 설명하는 데 집중하세요. 캐시·인증·배포는 실제 사용하는 버전과 환경을 기준으로 별도 확인합니다.

App Router 첫 프로젝트에서 파일 구성과 실행 절차를 따라갑니다. 로드맵에 미완성 getProduct() 예제를 복사하는 대신 해당 실습의 전체 파일과 데이터를 함께 사용하는 편이 재현하기 쉽습니다.

6. 검증과 AI 활용

수정한 기능마다 기대 결과를 먼저 적고 실제 입력으로 확인합니다. AI에는 초안·오류 후보·테스트 아이디어를 요청할 수 있지만 최종 코드의 동작은 별도로 검사해야 합니다. AI가 자신 있게 설명했는지는 통과 조건이 아닙니다.

상황: 검색어 변경 후 이전 결과가 다시 나타납니다.
조건: 두 요청의 응답 순서가 뒤바뀔 수 있습니다.
요청: 현재 코드에서 원인 후보를 설명하고 수정 범위를 제안해 주세요.
확인 기준: 최신 검색 결과 유지, 취소와 실제 오류 구분.
작업 후: 바뀐 파일과 실행한 검사, 남은 미확인 항목을 기록합니다.

문서 예시이며 특정 AI 제품 기능을 보장하는 명령은 아닙니다. 테스트 학습은 사용자 동작 테스트에서 시작하고 첫 E2E 테스트로 확장합니다.

완성 프로젝트의 제출 기준

• 설치·실행 방법과 필요한 설정 이름이 문서에 있습니다.
• 정상·빈 결과·실패·복구 경로가 설명됩니다.
• 본인이 결정한 구조와 제외한 대안을 말할 수 있습니다.
• 수행한 테스트와 미확인 환경이 구분됩니다.
• 사용자·매출·성능 성과는 실제 근거가 있을 때만 적습니다.

학습 프로젝트의 크기를 늘리기보다 한 흐름을 완성하고 설명 자료를 작성하세요. 그다음 자신의 목표 직무에서 빠진 근거를 찾아 다음 학습을 선택합니다.

다음 공부를 고르는 기준

현재 기능에서 막힌 질문 하나를 적고 해당 단계로 돌아갑니다. 화면 배치는 웹 퍼블리싱, 값의 변화는 JavaScript·React, 없는 값은 TypeScript, 직접 주소 접근은 Next.js, 검증은 테스트 과정과 연결합니다. 이 루프를 반복하면 강의를 끝낸 수보다 직접 설명하고 고칠 수 있는 범위가 남습니다.

공식 자료와 확인 범위

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

• React 컴포넌트와 상태 설계
• TypeScript 기본 타입
• W3C 접근성 기초 점검
• GitHub README 안내

다음 학습

• 포트폴리오 구성
• 이력서 작성
• 웹퍼블리셔 품질 점검