비전공자를 위한 바이브코딩 공부

웹 기초부터 개발 도구, 데이터, 보안과 수익화까지 처음 배우는 사람의 눈높이로 설명합니다.

• 주소를 입력하면 웹페이지가 열리는 과정을 주문 배달처럼 이해하기

  웹 주소를 입력하면 브라우저는 DNS로 서버 주소를 찾고 HTTP 요청을 보냅니다. 서버가 돌려준 HTML, CSS, JavaScript와 이미지를 조합해 화면을 그리며, 404나 500 오류가 보이면 이 요청과 응답 중 실패한 구간을 확인하면 됩니다.

• 프론트엔드와 백엔드와 데이터베이스를 식당 역할로 구분하기

  프론트엔드는 사용자가 보고 누르는 화면, 백엔드는 요청과 규칙을 처리하는 보이지 않는 부분, 데이터베이스는 회원과 주문 같은 기록을 보관하는 곳입니다. 식당으로 비유하면 각각 홀, 주방, 장부에 해당하며 세 역할이 연결돼 하나의 기능이 완성됩니다.

• API와 JSON을 메뉴판과 주문서처럼 읽는 첫 연습

  API는 다른 서비스에 정해진 방식으로 기능이나 데이터를 요청하는 연결 창구이고, JSON은 그 요청과 답을 이름과 값의 묶음으로 적는 형식입니다. 메뉴판에서 가능한 주문을 확인하고 주문서에 항목을 적는 과정으로 생각하면 두 개념을 함께 이해하기 쉽습니다.

• Git 커밋과 브랜치를 게임 저장 지점처럼 이해하기

  Git 커밋은 지금 파일 상태를 다시 찾을 수 있게 남기는 저장 지점이고, 브랜치는 원본 흐름을 건드리지 않고 다른 수정을 시험하는 별도 길입니다. AI에게 코드를 맡기기 전에 커밋을 만들면 문제가 생겨도 바뀐 부분을 비교하고 안전하게 되돌리기 쉽습니다.

• 환경변수와 API 키를 서랍과 금고처럼 구분하는 법

  환경변수는 주소나 실행 모드처럼 프로그램 밖에서 바꿀 설정을 담는 서랍이고, API 키는 외부 서비스 사용 권한을 가진 비밀번호에 가깝습니다. 비밀키는 브라우저 코드나 Git 저장소에 넣지 말고 서버의 비밀 저장소에서만 읽도록 해야 합니다.

• 파일 경로를 집 주소처럼 읽고 터미널에서 길을 잃지 않는 법

  파일은 내용을 담은 문서이고 폴더는 파일을 묶는 공간입니다. 절대경로는 출발점부터 적은 전체 주소, 상대경로는 현재 폴더를 기준으로 적은 길 안내입니다. 터미널에서는 먼저 `pwd`로 현재 위치를 확인한 뒤 `ls`로 목록만 읽으면 엉뚱한 곳을 바꾸는 실수를 줄일 수 있습니다.

• HTML과 CSS와 JavaScript를 집 구조와 꾸밈과 동작으로 나누기

  HTML은 제목과 버튼 같은 내용의 구조와 의미를 만들고, CSS는 색과 간격과 배치를 꾸미며, JavaScript는 클릭 뒤 문구 변경 같은 동작을 처리합니다. 집으로 비유하면 뼈대와 방 배치, 벽지와 가구, 전등 스위치에 해당하므로 화면 문제를 세 역할로 나누면 고칠 곳을 찾기 쉬워집니다.

• 모바일 반응형 화면과 키보드 접근성을 함께 점검하는 첫 순서

  반응형 디자인은 같은 내용을 휴대전화와 큰 화면에서 읽기 좋게 재배치하는 방법이고, 접근성은 키보드나 화면 읽기 도구 등 다양한 방식으로 기능을 사용할 수 있게 만드는 기준입니다. 390픽셀 화면의 가로 넘침과 Tab 키의 이동 순서를 각각 확인해야 둘을 함께 지킬 수 있습니다.

• 입력 폼의 오류를 주문서 확인처럼 설계하는 법

  입력 폼은 잘못된 값을 바로 고칠 수 있도록 브라우저에서 형식과 누락을 알려 주고, 서버에서는 같은 값을 다시 검사해야 합니다. 브라우저 검증은 사용자를 돕지만 우회할 수 있으므로 보안 경계가 될 수 없고, 오류 문장은 문제 난 항목과 고치는 방법을 함께 알려 줘야 합니다.

• 쿠키와 세션과 브라우저 저장소를 보관함 위치로 구분하기

  쿠키는 브라우저가 보관하며 조건에 맞는 서버 요청에 함께 보낼 수 있는 작은 값이고, 세션은 보통 서버가 로그인 상태를 보관하고 쿠키에는 연결용 식별자만 두는 방식입니다. localStorage는 같은 출처의 브라우저에 남지만 요청에 자동 첨부되지 않으므로 화면 설정에는 쓸 수 있어도 비밀키 저장소로 보면 안 됩니다.

• npm 패키지와 의존성을 장보기 목록처럼 읽는 법

  npm 패키지는 프로젝트에서 다시 쓸 수 있게 묶은 코드이고, 의존성은 내 프로젝트가 작동하려고 기대는 패키지입니다. package.json은 필요한 이름과 허용 버전을 적은 목록이며 package-lock.json은 실제 설치된 전체 버전을 기록하므로 둘을 함께 보관해야 같은 환경을 재현하기 쉽습니다.

• TypeScript 타입을 택배 상자 라벨처럼 읽는 첫 연습

  TypeScript 타입은 변수와 함수가 받을 값의 종류를 코드에 표시해 잘못된 조합을 실행 전에 찾도록 돕습니다. 문자열, 숫자, 참거짓 같은 라벨을 붙이면 편집기와 검사 도구가 실수를 알려 주지만, 외부에서 들어온 실제 데이터의 내용까지 자동으로 안전하게 만드는 것은 아닙니다.

• 오류와 로그를 진료 기록처럼 읽고 원인을 좁히는 순서

  디버깅은 오류 문장을 지우는 일이 아니라 같은 문제를 다시 만들 수 있는 조건을 기록하고 첫 실패 지점을 찾는 과정입니다. 화면 증상, 입력, 시간, 파일과 줄 번호, 기대 결과를 분리해 적은 뒤 한 번에 한 가지만 바꾸면 로그의 결과와 실제 원인을 혼동할 가능성이 줄어듭니다.

• 단위와 통합과 브라우저 테스트를 주방 검사처럼 나누기

  단위 테스트는 작은 함수 하나, 통합 테스트는 여러 부분의 연결, 브라우저 테스트는 사용자가 보는 화면 흐름을 확인합니다. 한 종류가 통과해도 다른 범위까지 자동으로 보장되지는 않으므로 빠른 작은 검사부터 실제 환경에 가까운 검사까지 겹쳐 배치하고 실패한 범위를 먼저 좁혀야 합니다.

• 저장과 빌드와 배포를 포장 배송 공개처럼 구분하기

  저장은 작업 파일을 남기는 일, 빌드는 소스 코드를 서비스용 결과물로 만드는 일, 배포는 그 결과물을 서버에 올리는 일입니다. 배포 성공 표시만으로 실제 공개 주소가 새 결과물을 제공한다고 단정할 수 없으므로 도메인, 번들, 핵심 기능과 메타데이터를 공개 환경에서 다시 확인해야 합니다.

• 터미널 첫 명령은 현재 위치와 파일 목록 확인부터 시작하기

  터미널을 처음 배울 때는 파일을 바꾸는 명령보다 현재 폴더를 보여 주는 pwd와 파일 목록을 보여 주는 ls부터 익히는 것이 안전합니다. 명령을 입력하기 전 현재 위치, 대상 경로, 옵션의 뜻을 확인하고 삭제·설치·권한 변경 명령은 이해할 때까지 실행하지 마세요.

• Git push와 pull을 보내기와 받아오기로 구분하는 법

  Git push는 내 로컬 커밋을 원격 저장소로 보내고, pull은 원격 변경을 받아 현재 브랜치에 합치는 명령입니다. 바로 주고받기 전에 git status와 git fetch로 차이를 읽고, 비밀 파일과 예상 밖 커밋이 없는지 확인한 뒤 공유 브랜치에는 강제 push를 피하는 것이 안전합니다.

• Git 병합 충돌에서 두 변경을 잃지 않고 해결하는 순서

  Git 병합 충돌은 두 작업 흐름이 같은 부분을 다르게 바꿔 Git이 자동 선택을 못한 상태입니다. 충돌 파일과 양쪽 변경을 먼저 보존하고 표시된 두 내용을 비교해 최종 문장을 직접 만든 뒤, 표시 제거와 테스트를 확인하고 git add와 commit으로 해결을 기록해야 합니다.

• GitHub Actions로 커밋마다 테스트가 도는 흐름 이해하기

  GitHub Actions의 CI는 push나 pull request 같은 사건이 생기면 별도 실행 컴퓨터인 러너에서 설치와 테스트 단계를 자동 수행하는 방식입니다. 워크플로 파일의 실행 조건, 권한, 비밀값 사용, 통과한 정확한 커밋을 확인해야 하며 초록 표시가 실제 배포나 모든 기능의 정상 동작까지 보장하지는 않습니다.

• 도메인과 DNS와 HTTPS가 배포 주소를 잇는 과정

  도메인은 사람이 읽는 웹 주소이고 DNS는 그 이름을 배포 서비스가 안내한 서버 위치로 연결합니다. 연결 뒤 인증 기관이 도메인 제어권을 확인해 HTTPS 인증서를 발급하면 브라우저가 암호화 통신을 할 수 있으며, DNS와 인증서와 실제 콘텐츠는 각각 따로 확인해야 합니다.

• SQL로 데이터를 만들고 찾고 고치고 지우는 첫 연습

  SQL은 데이터베이스에 말을 거는 문법입니다. INSERT는 새 행을 넣고 SELECT는 조건에 맞는 행을 읽으며 UPDATE는 기존 값을 고치고 DELETE는 행을 지웁니다. 변경 명령은 WHERE 조건이 빠지면 범위가 커질 수 있으므로 같은 조건을 SELECT로 먼저 확인해야 합니다.

• 기본키와 외래키로 두 데이터 표를 정확히 연결하는 법

  기본키는 표 안에서 각 행을 중복 없이 가리키는 번호이고, 외래키는 다른 표의 기본키를 참조해 기록 사이의 관계를 만듭니다. 이름처럼 바뀌거나 겹치는 값 대신 키로 연결하면 고객과 주문을 정확히 찾을 수 있으며, 삭제 규칙은 데이터 손실 범위를 확인한 뒤 정해야 합니다.

• 로그인 확인과 기능 권한 확인을 서로 다르게 설계하는 법

  인증은 로그인 정보로 사용자가 누구인지 확인하는 과정이고, 인가는 그 사용자가 특정 자료를 읽거나 고칠 권한이 있는지 판단하는 과정입니다. 로그인에 성공했어도 모든 기능을 쓸 수 있는 것은 아니므로 서버는 요청마다 대상과 행동에 대한 권한을 확인하고 기본값은 거부로 둬야 합니다.

• 비밀번호 원문을 남기지 않고 로그인 상태를 이어 가는 법

  비밀번호는 복호화할 원문으로 저장하지 않고 검증에 알맞은 느린 해시 함수와 사용자별 소금을 사용해 보호해야 합니다. 로그인에 성공하면 서버는 예측하기 어려운 세션 식별자로 이후 요청을 연결하며, 이 값이 탈취되면 계정을 대신할 수 있으므로 안전한 쿠키와 만료·로그아웃 처리가 필요합니다.

• 브라우저의 출처 제한과 CORS 오류를 구분하는 법

  브라우저는 보안을 위해 웹페이지 스크립트가 다른 출처의 응답을 마음대로 읽지 못하게 제한합니다. CORS는 서버가 허용할 출처와 메서드 등을 응답 헤더로 알리는 방식이며, 브라우저 콘솔 오류를 없애려고 검사를 끄기보다 요청 주소와 서버 허용 설정을 맞춰야 합니다.

• API 호출 제한에서 재시도와 중복 처리를 안전하게 나누는 법

  API 호출 제한을 만나면 즉시 같은 요청을 반복하지 말고 응답 상태와 제한 헤더를 기록한 뒤 기다리는 시간을 점차 늘려 재시도해야 합니다. 읽기 요청과 결제·메일·생성 요청을 구분하고, 변경 작업에는 고유한 작업 식별자와 결과 조회를 둬 중복 처리를 막아야 합니다.

• 웹훅이 결제와 알림 사건을 서버에 전달하는 방식

  웹훅은 결제 완료나 저장소 변경 같은 사건이 생겼을 때 외부 서비스가 내 서버의 약속된 주소로 HTTP 요청을 보내는 방식입니다. 서버는 화면 성공 문구를 믿지 말고 서명, 사건 종류, 사건 ID를 확인하며 먼저 빠르게 응답한 뒤 오래 걸리는 작업은 대기열에서 처리해야 합니다.

• 오래 걸리는 작업을 대기열과 백그라운드로 나누는 법

  오래 걸리는 작업은 사용자 요청 안에서 끝까지 기다리게 하지 말고 작업 내용과 식별자를 대기열에 저장한 뒤 별도 작업자가 처리하도록 나눕니다. 화면에는 접수 번호와 현재 상태를 보여 주고, 작업자는 재시도 횟수와 중복 방지와 실패 보관함을 갖춰 결과가 사라지거나 두 번 생기지 않게 해야 합니다.

• 캐시와 CDN이 빠른 화면과 오래된 화면을 함께 만드는 이유

  캐시는 한 번 받은 응답의 복사본을 다시 쓰는 방식이고 CDN은 여러 지역의 가까운 서버에서 그 복사본을 전달하는 망입니다. 속도와 원본 서버 부담은 좋아지지만 보관 시간이 남아 있으면 옛 파일이 보일 수 있으므로 HTML의 재확인 규칙과 내용이 바뀔 때 파일 이름이 달라지는 자산 전략을 나눠야 합니다.

• 개인정보를 필요한 만큼만 받고 제때 지우는 설계 순서

  개인정보 최소 수집은 나중에 쓸지도 모른다는 이유로 항목을 모으지 않고 현재 기능 목적을 달성하는 데 필요한 값만 받는 원칙입니다. 항목마다 수집 이유, 사용 위치, 접근자, 보관 기한, 삭제 방법을 정하고 목적이 끝났거나 이유를 설명하지 못하는 정보는 받지 않거나 안전하게 지워야 합니다.

• 로그와 지표와 알림을 병원 기록처럼 나누는 법

  로그는 한 사건의 시간과 내용을 남긴 기록이고, 지표는 오류율이나 응답 시간처럼 변화를 숫자로 모은 값이며, 알림은 정한 조건을 넘었을 때 사람이 확인하도록 보내는 신호입니다. 세 가지를 연결하되 사용자가 실제로 겪는 실패를 기준으로 알림을 정해야 소음 속에서 중요한 문제를 찾을 수 있습니다.

• 페이지뷰와 완료 이벤트로 제품의 쓸모를 구분하는 법

  페이지뷰는 페이지가 열린 횟수를 알려 주지만 사용자가 목적을 끝냈는지는 말해 주지 않습니다. 이벤트는 검색, 저장, 가입 완료처럼 의미 있는 행동이 일어난 순간을 이름과 필요한 정보로 기록합니다. 시작과 완료와 실패를 같은 흐름에서 확인해야 유입 증가와 제품 가치 증가를 구분할 수 있습니다.

• 크롤링과 색인과 표준 URL을 도서관 일처럼 구분하기

  크롤링은 검색 시스템이 URL을 찾아 페이지를 읽는 과정이고, 색인은 읽은 내용을 분석해 검색용 목록에 저장하는 과정입니다. 표준 URL은 비슷한 페이지 여러 개 중 대표로 삼길 바라는 주소를 알리는 신호입니다. 세 단계는 서로 다르므로 페이지 접근, 원문 내용, 선택된 대표 주소와 검색 상태를 각각 확인해야 합니다.

• 광고와 구독과 한 번 결제를 작은 가게처럼 비교하는 법

  광고는 이용자의 주의를 광고주에게 연결해 수익을 얻고, 구독은 가치가 반복되는 동안 정기 결제를 받으며, 1회 결제는 한 번 완성되는 결과에 값을 받는 방식입니다. 인기만 보고 고르지 말고 사용자가 가치를 얻는 빈도, 서비스의 반복 비용, 가격과 해지·환불을 분명히 설명할 수 있는지를 함께 비교해야 합니다.

• 결제 완료 화면과 웹훅과 환불 상태를 따로 확인하는 법

  결제 성공 화면은 사용자의 브라우저가 특정 주소에 도착했다는 표시일 뿐 최종 결제 증거가 아닙니다. 서버는 결제 제공사의 상태와 서명된 웹훅을 확인해 주문을 처리하고 같은 사건을 중복 반영하지 않아야 합니다. 환불도 요청, 처리 중, 성공, 실패 상태를 나누고 실제 완료를 확인해야 합니다.

• 사용자 한 명이 늘 때 드는 비용부터 계산하는 법

  단위 경제성은 사용자 한 명, 주문 한 건, 완료 작업 한 번처럼 반복되는 단위에서 들어오는 수익과 그 단위를 제공할 때 늘어나는 비용을 비교하는 방법입니다. 전체 서버비만 보지 말고 결제 수수료, API 호출, 저장·전송 비용을 같은 단위로 나눠야 무료 범위와 가격이 지속 가능한지 판단할 수 있습니다.

• 개발자 도구 Elements와 Network로 문제 범위를 좁히는 법

  Elements는 브라우저가 지금 그린 화면의 구조와 스타일을 살펴보는 곳이고, Network는 문서·이미지·API 요청이 실제로 오갔는지 확인하는 곳입니다. 글자·간격 문제는 Elements에서, 로딩·상태 코드·응답 문제는 Network에서 먼저 보면 화면 문제와 통신 문제를 빠르게 나눌 수 있습니다.

• 시맨틱 HTML로 웹페이지 구조를 건물 안내판처럼 나누기

  시맨틱 HTML은 화면 구역을 단순한 상자가 아니라 머리말, 탐색, 주요 내용, 독립 글, 보충 내용, 바닥글처럼 의미가 있는 요소로 표시하는 방법입니다. 모양은 CSS로 정하고 내용의 역할은 HTML로 나누면 사람과 브라우저와 화면 읽기 도구가 같은 페이지 구조를 더 분명하게 이해할 수 있습니다.

• 이미지 대체 텍스트와 크기와 로딩 순서를 함께 점검하는 법

  이미지를 넣을 때는 먼저 페이지에서 맡는 의미를 판단해 정보 이미지에는 짧은 alt를 쓰고 장식 이미지에는 alt=""를 둡니다. 실제 width와 height로 자리를 미리 잡고 첫 화면 아래 이미지에만 loading="lazy"를 적용하면 대체 설명, 화면 안정성, 초기 로딩을 함께 챙길 수 있습니다.

• 의존성 업데이트를 보안 경고 숫자보다 변경 범위부터 확인하는 법

  의존성 업데이트는 경고 개수만 보고 모든 패키지를 한꺼번에 바꾸는 일이 아닙니다. 먼저 현재 잠금 파일과 변경 목록을 저장하고, 어떤 기능에서 취약한 패키지를 쓰는지 확인한 뒤 호환되는 작은 업데이트부터 적용해 테스트해야 합니다. 큰 버전 변경이나 자동 수정이 필요하면 멈추고 공식 변경 기록과 복구 방법을 먼저 확인하세요.

• 문자 인코딩과 줄바꿈 때문에 파일 전체가 바뀌어 보이는 이유

  문자 인코딩은 글자를 저장할 바이트 규칙이고 줄바꿈은 한 줄의 끝을 표시하는 보이지 않는 기호입니다. 파일을 다른 인코딩으로 읽으면 글자가 깨지고, LF와 CRLF가 한꺼번에 바뀌면 내용은 같아도 모든 줄이 수정된 것처럼 보일 수 있습니다. 변환 전에 편집기 표시, Git 속성, 실제 변경 범위를 먼저 확인해야 합니다.

• Content-Type이 데이터의 포장 라벨이 되는 이유

  Content-Type은 HTTP 본문이 어떤 종류의 데이터인지 알려 주는 헤더입니다. 응답에서는 브라우저가 HTML, JSON, 이미지 등을 알맞게 처리하도록 돕고, 요청에서는 서버가 받은 본문을 어떤 형식으로 읽을지 알려 줍니다. 주소나 파일 이름만 믿지 말고 실제 헤더와 본문이 서로 맞는지 확인해야 합니다.

• 데이터베이스 백업 파일이 실제 복구로 이어지는지 확인하는 법

  백업은 파일이 존재한다는 사실만으로 끝나지 않습니다. 원본과 분리된 시험 환경에 복원해 표와 대표 데이터, 관계, 권한, 백업 기준 시점을 확인해야 복구 가능성을 입증할 수 있습니다. 운영 데이터베이스를 덮어쓰지 말고 버전과 암호, 담당자, 중단 기준을 기록한 작은 복구 훈련부터 시작하세요.

• 기능 플래그로 새 기능을 일부 사용자에게 먼저 공개하는 법

  기능 플래그는 배포된 코드 안에서 새 기능을 누구에게 켤지 정하는 스위치입니다. 기본값을 기존 기능으로 두고 내부 사용자와 작은 대상부터 공개한 뒤 오류율과 핵심 완료 흐름을 확인해야 합니다. 문제가 생기면 플래그를 끄되 데이터 변경과 결제처럼 되돌릴 수 없는 영향은 별도로 점검해야 합니다.

• 개발 서버가 열리지 않을 때 프로세스와 포트와 localhost를 구분하는 법

  프로세스는 실행 중인 프로그램이고, 포트는 그 프로그램이 연결을 기다리는 문이며, localhost는 지금 브라우저를 연 컴퓨터 자신을 가리키는 이름입니다. 서버가 안 열리면 먼저 터미널의 실제 주소와 오류를 읽고 해당 포트를 누가 쓰는지 확인하세요. 정체를 모르는 프로세스를 바로 종료하거나 외부 공개 주소로 바꾸지 않는 것이 안전합니다.

• 데이터베이스 변경은 트랜잭션으로 한 묶음에 담아야 한다

  데이터베이스 트랜잭션은 여러 읽기와 변경을 하나의 작업 단위로 묶는 장치입니다. 모든 조건과 쿼리가 성공했을 때만 COMMIT으로 확정하고, 중간에 오류나 조건 불일치가 생기면 ROLLBACK으로 묶음 전체를 취소해야 주문만 생기거나 재고만 줄어드는 반쪽 상태를 막을 수 있습니다.

• 가동 시간과 상태 페이지와 사용자 오류를 따로 보는 법

  가동 시간은 정한 주소가 조건에 맞게 응답한 비율이고, 상태 페이지는 확인된 장애와 영향을 사용자에게 알리는 공간입니다. 둘 다 로그인·결제·저장 같은 실제 완료를 자동으로 보장하지 않으므로 외부 확인, 사용자 흐름, 오류 기록, 상태 안내를 따로 측정하고 같은 시간대에서 맞춰 봐야 합니다.

• API 목록을 페이지와 커서로 빠짐없이 이어 읽는 법

  API 목록은 결과가 많으면 한 번에 전부 주지 않고 여러 페이지로 나눌 수 있습니다. 첫 응답의 개수만 전체라고 믿지 말고 서버가 준 다음 링크나 커서를 그대로 이어 쓰며, 필터와 정렬 조건을 유지하고 종료 신호와 중복 식별자를 확인해야 빠짐과 반복을 줄일 수 있습니다.

• 데이터베이스 인덱스가 조회를 빠르게 하지만 쓰기 비용을 늘리는 이유

  데이터베이스 인덱스는 자주 찾는 열의 값과 실제 행 위치를 별도 순서로 정리해 모든 행을 읽지 않고도 후보를 좁히게 합니다. 조회는 빨라질 수 있지만 자료가 추가·수정·삭제될 때 인덱스도 함께 갱신해야 하므로, 실제 쿼리 조건과 실행 계획을 확인해 필요한 인덱스만 두어야 합니다.

• 입력칸의 이름표를 연결해야 누구나 폼을 쓸 수 있다

  입력칸의 이름은 옆에 글자를 놓는 것만으로 연결되지 않습니다. HTML의 label은 입력칸의 id와 같은 for 값을 가져야 하고, 형식 안내는 별도 문장으로 연결해야 합니다. 이렇게 하면 이름을 눌러 입력칸으로 이동할 수 있고 화면 읽기 도구도 무엇을 입력할지 알려 줄 수 있습니다.

• 글자가 흐리고 키보드 위치가 안 보일 때

  글자가 흐리면 글자와 배경의 밝기 차이인 색 대비를 확인하고, Tab 키로 이동할 때 현재 링크나 버튼에 표시가 보이는지 확인하세요. 일반 글자는 W3C의 4.5대 1 기준을 출발점으로 삼고, 키보드 초점 표시를 지우지 않은 채 실제 화면에서 이동 경로를 살펴봐야 합니다.

• 표의 머리칸을 연결해야 숫자가 길을 잃지 않는다

  자료 표는 선을 그어 칸만 나누면 끝나지 않습니다. 표의 주제를 caption으로 적고, 행과 열의 이름은 th로, 값은 td로 표시하세요. 양쪽에 머리칸이 있다면 scope로 방향을 알려 주면 화면 읽기 도구도 각 숫자가 무엇을 뜻하는지 따라갈 수 있습니다.