본문으로 바로가기

aria-live가 안 읽힐 때 — ARIA 라이브 리전 제대로 쓰기

"저장되었습니다"라는 초록색 토스트가 화면 오른쪽 아래에 뜹니다. 2초 뒤 사라지고요. 마우스를 쓰는 사람에게는 완결된 피드백입니다. 그런데 화면을 보지 않는 사람에게는요? 그 토스트는 일어나지 않은 일입니다. 저장이 됐는지 안 됐는지 알 방법이 없어요. ...

글 작성일: 2026-09-02 · 글 읽기 시간: 17 분 · 글 단어 수: 8249 단어 · 글쓴이: Isaac

테스트 문화·면접·다음 단계 — 프론트엔드 테스트 시리즈를 마치며

「프론트엔드 테스트 제대로 하기」 시리즈의 22편입니다. 전체 목차 보기 · 용어집 작은 앱 하나에 테스트를 한 겹씩 쌓으면 무엇이 되는지 — 이 글은 그 여정의 회고이자, 프론트엔드 테스트 전체의 지도입니다. ...

글 작성일: 2026-08-08 · 글 읽기 시간: 11 분 · 글 단어 수: 5046 단어 · 글쓴이: Isaac

AI가 만든 코드의 함정 — 접근성·엣지케이스 누락

「프론트엔드 테스트 제대로 하기」 시리즈의 21편입니다. 전체 목차 보기 · 용어집 AI가 짠 코드는 빠르고, 돌아가고, 화면도 예쁩니다. 문제는 그럴듯하게 틀린다는 것이에요. ...

글 작성일: 2026-08-07 · 글 읽기 시간: 12 분 · 글 단어 수: 5653 단어 · 글쓴이: Isaac

Playwright × AI — codegen·MCP·자가치유 셀렉터

AI가 브라우저를 직접 조작하는 시대. Playwright codegen과 MCP 에이전트를 실무 기준으로 짚고, MCP가 스크린샷이 아니라 접근성 트리를 읽는다는 점, 자가치유 셀렉터가 왜 Playwright 기능이 아닌지까지 정리합니다.

글 작성일: 2026-08-06 · 수정됨 2026-10-02 · 글 읽기 시간: 20 분 · 글 단어 수: 9672 단어 · 글쓴이: Isaac

AI로 테스트 생성·보강 — 검증의 몫은 사람

「프론트엔드 테스트 제대로 하기」 시리즈의 19편입니다. 전체 목차 보기 · 용어집 AI(ChatGPT·Claude 같은 대형 언어 모델, LLM)에게 테스트를 짜달라고 하면 될까요? 됩니다. 다만 그대로 믿으면 안 돼요. AI는 그럴듯한 테스트를 몇 초 만에 뽑아주지만, 정작 중요한 경계·실패·접근성 케이스를 조용히 빼먹는 경향이 있거든요. 이 글은 AI를 테스트 작성의 조수로 제대로 부리는 법입니다 — 좋은 초안을 받는 요령부터, 받은 테스트가 진짜 일하는지 검증하는 체크리스트까지. ...

글 작성일: 2026-08-06 · 글 읽기 시간: 12 분 · 글 단어 수: 5991 단어 · 글쓴이: Isaac

popover·앵커 포지셔닝·dialog, 접근성 관점에서 지금 써도 될까

브라우저 지원표가 초록불이어도 접근성까지 초록불인 건 아닙니다. popover·앵커 포지셔닝·dialog·뷰 트랜지션 네 가지 기능을 2026년 8월 기준으로 점검하고, 브라우저가 대신 해주는 것과 개발자가 직접 챙겨야 하는 것을 실제 데모와 함께 정리했습니다.

글 작성일: 2026-08-05 · 수정됨 2026-10-24 · 글 읽기 시간: 28 분 · 글 단어 수: 13911 단어 · 글쓴이: Isaac

커버리지 읽는 법과 품질 지표

「프론트엔드 테스트 제대로 하기」 시리즈의 18편입니다. 전체 목차 보기 · 용어집 커버리지 리포트를 열면 숫자가 네 종류나 나옵니다 — Stmts, Branch, Funcs, Lines. 뭘 봐야 할까요? 이 글은 그 리포트를 읽는 법입니다: 어떤 숫자가 정직한지(스포일러: 브랜치), 빨간 줄에서 무엇을 채울지, 그리고 숫자가 못 보여주는 팀 건강은 어디서 볼지까지. ...

글 작성일: 2026-08-04 · 글 읽기 시간: 7 분 · 글 단어 수: 3247 단어 · 글쓴이: Isaac

GitHub Actions로 테스트·접근성 게이트 만들기

「프론트엔드 테스트 제대로 하기」 시리즈의 17편입니다. 전체 목차 보기 · 용어집 테스트는 '로컬에서 가끔 돌리는 것'일 때는 힘이 없습니다. PR마다 자동으로 도는 관문이 될 때 비로소 팀을 지키죠. 이 글은 GitHub Actions로 그 관문 — 단위 테스트·E2E·접근성 검사가 통과해야만 코드가 합쳐지는 머지 게이트 — 를 워크플로우 파일 하나로 세우는 방법입니다. CI가 처음이어도 됩니다. 용어부터 3분 정리하고 시작해요. ...

글 작성일: 2026-08-03 · 글 읽기 시간: 6 분 · 글 단어 수: 2982 단어 · 글쓴이: Isaac

시각적 회귀 테스트 — 스크린샷 비교

「프론트엔드 테스트 제대로 하기」 시리즈의 16편입니다. 전체 목차 보기 · 용어집 모든 테스트가 초록불인데 화면이 깨진 적, 있으시죠? 로직은 멀쩡한데 CSS 하나가 레이아웃을 무너뜨린 경우요. 시각적 회귀 테스트는 기준 스크린샷(baseline)을 저장해두고 픽셀을 비교해서, 이런 "눈으로 봐야 아는 회귀"를 자동으로 잡는 기법입니다. Playwright에 내장돼 있어 한 줄이면 시작해요 — 대신 흔들리지 않게 찍는 요령과 환경 차이라는 복병까지, 이 글에서 다 짚습니다. ...

글 작성일: 2026-07-29 · 글 읽기 시간: 11 분 · 글 단어 수: 5112 단어 · 글쓴이: Isaac

픽스처·인증 재사용·병렬 실행

「프론트엔드 테스트 제대로 하기」 시리즈의 13편입니다. 전체 목차 보기 · 용어집 E2E 테스트가 열 개를 넘어가면 두 가지가 아파옵니다. 테스트마다 복붙되는 준비 코드, 그리고 순서대로 도느라 느려지는 스위트. Playwright의 픽스처(반복 준비를 테스트에 주입하는 장치)와 병렬 실행이 이 둘을 한 번에 해결합니다 — 이 글에서 커스텀 픽스처, 인증 재사용(storageState), 병렬 안전 수칙까지 정리해요. ...

글 작성일: 2026-07-21 · 글 읽기 시간: 7 분 · 글 단어 수: 3088 단어 · 글쓴이: Isaac
맨 위로