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

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

「프론트엔드 테스트 제대로 하기」 시리즈의 20편입니다. 전체 목차 보기 · 용어집 AI가 테스트 코드를 ‘짜주는’ 것까지는 이제 익숙하죠. 그런데 요즘은 한 걸음 더 나갑니다 — AI가 브라우저를 직접 열고, 클릭하고, 잘 되는지 확인하기 시작했어요. ...

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

새 기능을 도입할 때 우리가 보는 건 대개 지원표입니다. caniuse에 들어가서 초록색 칸이 몇 퍼센트인지 확인하고, 90%를 넘으면 “이제 써도 되겠네” 하죠. ...

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

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

AI 규제 소식은 보통 우리와 먼 이야기처럼 들립니다. 금지된 용도가 어떻고, 벌금이 매출의 몇 퍼센트고, 하는 얘기는 법무팀 몫 같거든요. 그런데 8월 2일부터 적용되는 조항 안에 이런 문장이 있습니다. ...

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

100만 개의 홈페이지를 자동 검사기에 넣고 돌리면 무슨 일이 벌어질까요? 약 5,600만 개의 접근성 오류가 쏟아져 나옵니다. 페이지당 평균 56.1개입니다. 숫자만 보면 “원래 웹이 그렇지” 하고 넘길 수도 있습니다. 문제는 방향입니다. 작년에는 51개였거든요. 1년 사이 10.1% 늘었습니다. 몇 년간 느리게나마 나아지던 웹 접근성이, 올해는 뒷걸음질을 쳤습니다. ...

접근성 검사기를 하나 돌린다고 해봅시다. 사이트 주소를 넣으면, 검사기는 어느 페이지를 봐야 할까요? 홈 하나만 보면 될까요? 그러면 “이 사이트는 접근성이 좋다/나쁘다"라고 말할 근거가 약합니다. 그렇다고 전부 보자니, 게시판·블로그·쇼핑몰은 글이 수백에서 수천 개예요. 다 검사하면 시간도 비용도 감당이 안 됩니다. ...