AI 접근성 스모크 루프

AI가 UI를 빠르게 만들수록 접근성은 “나중에 고치는 품질 항목”이 아니라 배포 스모크의 일부가 되어야 합니다. 버튼이 보이고 클릭된다고 해서 모든 사용자가 쓸 수 있는 것은 아닙니다. 키보드만 쓰는 사용자, 스크린 리더로 화면을 읽는 사용자, 저시력 사용자, 모바일 확대 사용자는 AI가 만든 작은 마크업 실수 하나로 가입, 결제, 검색, 저장 같은 핵심 흐름에서 막힐 수 있습니다.

AI 접근성 스모크 루프는 기능 개발이 끝난 뒤 별도의 대형 감사로 접근성을 몰아넣지 않습니다. 작업 지시서에 접근성 acceptance criteria를 넣고, 구현 중에는 시맨틱 HTML과 상태 이름을 확인하고, 배포 전에는 키보드 탐색, 포커스 순서, 스크린 리더 힌트, 색 대비, 모달 포커스 트랩, 대체 텍스트, 접근성 회귀 테스트를 짧은 루프로 확인합니다. 초보자는 “마우스 없이도 길을 잃지 않는지 확인하는 배포 전 점검”으로 이해하면 됩니다. 실무자는 더 엄격하게 봐야 합니다. 접근성은 선의의 문구가 아니라 DOM 구조, 상태 전환, 자동 검사, 수동 스모크, rollback 기준으로 운영되어야 합니다.

이 글은 AI가 만든 화면을 실제 사용자가 쓸 수 있게 만드는 실전 루프를 다룹니다. 목표는 모든 국제 표준을 한 번에 외우는 것이 아니라, 매번 배포 가능한 수준의 접근성 안전망을 만드는 것입니다.

핵심 결론

AI 접근성 스모크 루프의 결론은 간단합니다. “화면이 예쁘다”와 “화면이 사용 가능하다”를 분리해서 검증해야 합니다. AI가 만든 UI는 시각적으로 그럴듯해도 버튼을 div로 만들거나, 아이콘 버튼에 aria-label을 빼거나, 모달을 열어 놓고 배경 링크로 포커스가 빠지게 만들거나, 오류 메시지를 색만으로 표시할 수 있습니다. 이런 문제는 스크린샷 리뷰만으로는 거의 보이지 않습니다.

따라서 접근성 acceptance criteria를 작업 시작 전에 작성합니다. 예를 들어 “저장 흐름은 키보드 Tab, Enter, Escape만으로 완료 또는 취소할 수 있다”, “아이콘 버튼은 스크린 리더에서 목적이 읽힌다”, “오류 메시지는 색과 텍스트로 동시에 전달된다”, “모달이 열리면 포커스가 모달 안에 머물고 닫으면 원래 버튼으로 돌아간다”처럼 관찰 가능한 문장이어야 합니다.

그다음 구현은 세 층으로 나눕니다. 첫째, 시맨틱 HTML을 기본값으로 둡니다. 링크는 링크, 버튼은 버튼, 제목은 제목, 목록은 목록으로 작성하게 합니다. 둘째, 자동 검사로 빠르게 걸러냅니다. axe 같은 도구를 통해 누락된 이름, 낮은 색 대비, 잘못된 aria 속성을 확인합니다. 셋째, 사람의 수동 스모크로 실제 흐름을 걷습니다. 키보드 탐색, 포커스 순서, 스크린 리더 읽기, 확대 화면, 오류 상태, 로딩 상태를 짧게 확인합니다.

좋은 루프는 접근성을 “전문가만 하는 별도 리뷰”로 격리하지 않습니다. AI에게 UI를 맡길 때마다 작업 지시서, 테스트, 리뷰, 배포 스모크에 접근성 항목을 작게 넣습니다. 그러면 접근성 회귀 테스트가 자연스럽게 쌓이고, 문제가 생겼을 때 어떤 변경을 rollback해야 하는지도 분명해집니다.

왜 중요한가

AI는 시각적 완성도를 접근성으로 착각하기 쉽다

생성형 AI는 사람이 보는 화면 설명을 잘 맞춥니다. “둥근 카드, 선명한 CTA, 미니멀한 폼” 같은 지시를 주면 보기 좋은 컴포넌트를 만들 수 있습니다. 하지만 접근성은 눈에 보이는 스타일만으로 결정되지 않습니다. 버튼의 accessible name, 입력 필드와 label의 연결, heading 구조, focus-visible 스타일, live region의 알림 방식, 이미지 대체 텍스트, 색 대비, 키보드 탈출 경로처럼 DOM과 상호작용에 숨어 있는 조건이 많습니다.

초보자가 자주 놓치는 부분은 “내 마우스로 클릭해 봤다”는 확인이 충분하지 않다는 점입니다. 마우스 클릭은 접근성 검증의 일부일 뿐입니다. 키보드만으로 같은 기능을 끝낼 수 있는지, 화면 읽기 도구가 버튼 목적을 알려 주는지, 오류가 발생했을 때 사용자가 어디를 고쳐야 하는지 알 수 있는지 확인해야 합니다.

실무에서 더 무서운 문제는 접근성 결함이 배포 직후 고객 문의나 이탈로 드러난다는 점입니다. 가입 버튼은 보이지만 키보드 포커스가 가지 않거나, 결제 모달에서 Escape가 동작하지 않거나, 검색 결과가 갱신되어도 스크린 리더가 변화를 알려 주지 않으면 특정 사용자는 서비스가 멈춘 것처럼 느낍니다. AI 코딩 속도가 빠를수록 이런 결함도 빠르게 누적됩니다.

접근성은 품질과 속도의 반대말이 아니다

접근성을 느린 절차로 오해하면 팀은 항상 마지막에 미룹니다. 하지만 루프가 작으면 오히려 속도가 빨라집니다. 시맨틱 HTML을 먼저 쓰면 별도 역할을 덧붙일 일이 줄어듭니다. 포커스 순서를 초기에 잡으면 모달과 드롭다운을 나중에 갈아엎지 않아도 됩니다. 색 대비 기준을 디자인 토큰에 넣으면 페이지마다 색을 다시 따지지 않아도 됩니다.

VIBE 코딩에서 접근성은 AI에게 더 좋은 제약을 주는 방법이기도 합니다. “예쁜 카드 UI를 만들어 줘”보다 “키보드 탐색과 스크린 리더 이름이 유지되는 카드 목록을 만들어 줘”가 훨씬 안전합니다. AI가 선택할 구현 공간을 좁혀 주기 때문입니다. 제약이 분명하면 AI는 임의 div 클릭 영역보다 button과 a를 사용할 가능성이 높고, 아이콘만 있는 컨트롤에는 aria-label을 붙일 가능성이 높습니다.

실제 작업 순서

1단계: 접근성 acceptance criteria를 먼저 적는다

작업을 시작하기 전에 기능의 핵심 흐름을 한 문장으로 씁니다. 예를 들어 “사용자는 키보드만으로 검색어를 입력하고 결과 첫 항목으로 이동할 수 있다”처럼 씁니다. 그 아래 접근성 acceptance criteria를 붙입니다. 포커스 순서, 스크린 리더 이름, 오류 전달 방식, 색 대비, 모달 포커스 트랩, 대체 텍스트, 로딩 알림 중 해당되는 것만 고릅니다.

좋은 기준은 측정 가능합니다. “접근성이 좋아야 한다”는 기준은 AI에게도 사람에게도 쓸모가 없습니다. “Tab 순서가 시각적 흐름과 일치한다”, “아이콘 버튼은 aria-label로 목적을 제공한다”, “입력 오류는 필드 아래 텍스트와 aria-describedby로 연결된다”, “삭제 확인 모달은 열릴 때 제목으로 포커스가 이동하고 닫힐 때 삭제 버튼으로 돌아온다”처럼 적어야 합니다.

이 기준은 테스트 이름이 되기도 합니다. 접근성 회귀 테스트를 모두 자동화할 수는 없지만, 작성한 기준이 있어야 어떤 부분은 자동 검사로, 어떤 부분은 브라우저 수동 스모크로 확인할지 나눌 수 있습니다.

2단계: AI 작업 지시서에 금지와 선호를 같이 넣는다

AI에게는 구현 요구만 주지 말고 접근성 기본값을 함께 줍니다. 예를 들어 “클릭 가능한 div를 만들지 말고 button 또는 a를 사용한다”, “아이콘만 있는 버튼에는 aria-label을 넣는다”, “폼 필드는 label과 설명 텍스트를 연결한다”, “모달은 Escape로 닫히고 포커스가 모달 밖으로 빠지지 않는다”, “색만으로 상태를 전달하지 않는다”처럼 선호와 금지를 함께 씁니다.

이때 너무 많은 표준 문서를 통째로 붙일 필요는 없습니다. 기능에 필요한 제약만 골라야 AI가 집중합니다. 검색 폼이면 label, 오류 메시지, 결과 갱신 알림, 키보드 탐색이 중요합니다. 이미지 갤러리면 대체 텍스트, 빈 상태, 로딩 상태, 카드 링크 이름이 중요합니다. 결제 모달이면 포커스 트랩, Escape, 배경 스크롤 잠금, 오류 회복 경로가 중요합니다.

3단계: 구현 직후 자동 검사를 돌린다

구현이 끝나면 axe 기반 검사나 테스트 환경의 접근성 검사로 빠른 결함을 찾습니다. 자동 검사는 만능이 아니지만, 이름 없는 버튼, label 없는 입력, 잘못된 aria 속성, 명백한 색 대비 문제처럼 흔한 결함을 빠르게 잡습니다. 이 단계에서 잡히는 문제는 대부분 사람 리뷰 전에 고칠 수 있어야 합니다.

자동 검사를 통과했다고 끝내면 안 됩니다. 자동 도구는 포커스 순서가 사용자에게 자연스러운지, 문구가 실제로 이해되는지, 모달 흐름이 제품 맥락에 맞는지 완전히 판단하지 못합니다. 그래서 자동 검사는 “최소 안전망”이고, 다음 단계의 수동 배포 스모크가 필요합니다.

4단계: 키보드 탐색으로 핵심 흐름을 걷는다

브라우저에서 마우스를 내려놓고 Tab, Shift+Tab, Enter, Space, Escape만 사용합니다. 첫 포커스가 어디로 가는지, 포커스 표시가 보이는지, 시각적 순서와 포커스 순서가 맞는지, 닫을 수 없는 팝업이 없는지 확인합니다. 특히 메뉴, 드롭다운, 모달, 탭, 토스트, 무한 목록은 포커스 문제가 자주 생깁니다.

키보드 스모크의 핵심은 “가능하다”가 아니라 “길을 잃지 않는다”입니다. 포커스가 화면 밖으로 가거나, 같은 카드 안에서 불필요하게 많은 숨은 요소를 지나가거나, 닫힌 메뉴 안으로 들어가면 사용자는 흐름을 잃습니다. AI가 만든 UI에서 이런 문제는 CSS 숨김 방식이나 조건부 렌더링 실수로 자주 발생합니다.

5단계: 스크린 리더와 텍스트 의미를 확인한다

전문 접근성 감사가 아니더라도 최소한 주요 버튼과 링크 이름은 확인해야 합니다. 아이콘 버튼이 “button”으로만 읽히는지, 카드 링크가 모두 “자세히 보기”로만 읽히는지, 입력 필드가 어떤 값을 요구하는지 알려 주는지 살핍니다. aria-label은 부족한 이름을 보완할 때 유용하지만, 보이는 텍스트와 다른 이름을 주면 오히려 혼란을 만듭니다.

스크린 리더 스모크에서는 화면에 보이는 섹션 제목과 실제 heading 구조가 맞는지도 봅니다. H1이 여러 개 반복되거나, H2 없이 H4로 뛰거나, 카드 제목을 모두 과한 heading으로 만들면 사용자가 구조를 훑기 어렵습니다. AI는 스타일을 맞추려고 heading을 장식용으로 남발할 수 있으므로, 제목 구조는 리뷰 대상입니다.

6단계: 상태 전환과 오류 회복을 확인한다

접근성 문제는 정상 상태보다 오류 상태에서 더 자주 드러납니다. 빈 입력으로 제출했을 때 오류가 어디에 나타나는지, 스크린 리더가 오류를 알 수 있는지, 포커스가 사용자가 고쳐야 할 영역으로 이동하는지 확인합니다. 저장 중에는 중복 제출이 막히는지, 완료 후에는 결과가 텍스트로 전달되는지, 실패 시에는 다시 시도 방법이 명확한지 살핍니다.

모달과 토스트도 상태 전환을 확인해야 합니다. 모달 포커스 트랩이 작동하지 않으면 키보드 사용자는 배경의 링크로 빠질 수 있습니다. 토스트가 색과 아이콘만으로 성공 또는 실패를 표시하면 저시력 사용자나 스크린 리더 사용자는 의미를 놓칠 수 있습니다. 이런 상태는 배포 스모크에 반드시 포함합니다.

7단계: 배포 전후 스모크와 rollback 기준을 연결한다

로컬에서 통과한 접근성 스모크는 배포 후에도 대표 경로에서 다시 확인합니다. 프로덕션 빌드, 데이터 상태, 폰트 로딩, 이미지 최적화, 실제 라우팅 때문에 로컬과 다르게 동작할 수 있기 때문입니다. 배포 스모크에는 목록 페이지, 상세 페이지, 폼 제출 흐름, 모달 또는 메뉴 하나를 포함합니다.

rollback 기준도 미리 적어 둡니다. 예를 들어 “가입 또는 결제 핵심 흐름에서 키보드로 완료할 수 없으면 즉시 rollback”, “스크린 리더에서 주요 CTA 이름이 읽히지 않으면 배포 보류”, “모달이 닫히지 않거나 포커스가 회복되지 않으면 hotfix 또는 rollback”처럼 숫자와 조건을 둡니다. 접근성은 배포 후 언젠가 개선할 미학 문제가 아니라 사용 가능성 문제입니다.

상황별 예시

검색 폼과 결과 목록

검색 UI에서 가장 흔한 실수는 입력창과 결과 목록이 시각적으로만 연결되는 것입니다. AI가 만든 검색창이 placeholder에만 설명을 넣고 label을 생략하면, 입력 후 placeholder가 사라졌을 때 사용자는 맥락을 잃을 수 있습니다. 결과가 바뀌어도 아무 알림이 없으면 스크린 리더 사용자는 목록이 갱신되었는지 알기 어렵습니다.

이 경우 acceptance criteria는 “검색 입력은 label로 목적이 연결된다”, “결과 수가 텍스트로 표시된다”, “검색 후 첫 결과 또는 결과 요약으로 포커스 이동 전략이 명확하다”, “결과가 없을 때 빈 상태 메시지가 제공된다”가 됩니다. 자동 검사는 label 누락을 잡고, 수동 스모크는 검색어 입력 후 포커스와 결과 안내가 이해되는지 확인합니다.

카드 목록과 아이콘 버튼

카드 목록에는 좋아요, 공유, 저장, 더보기 같은 아이콘 버튼이 많습니다. AI는 아이콘 이미지만 놓고 버튼 이름을 생략하기 쉽습니다. 그러면 스크린 리더에서는 같은 “button”이 반복되거나, “star”처럼 의미가 부족한 이름만 읽힙니다. 카드 전체가 링크이면서 내부에도 버튼이 있으면 포커스 순서가 복잡해질 수 있습니다.

해결은 카드의 주요 이동 링크와 보조 액션을 분리하는 것입니다. 카드 제목 링크는 목적지를 설명하고, 아이콘 버튼은 “이 글 저장”, “이 프로젝트 공유”처럼 대상이 포함된 aria-label을 가집니다. 카드가 많을수록 “자세히 보기” 같은 반복 링크 이름을 피해야 합니다. 수동 스모크에서는 Tab으로 카드 하나를 지나갈 때 포커스 가능한 요소가 과도하게 많지 않은지 봅니다.

모달, 드롭다운, 모바일 메뉴

모달은 접근성 결함이 가장 자주 숨어 있는 영역입니다. 열릴 때 포커스가 모달 제목이나 첫 입력으로 이동해야 하고, Tab은 모달 안에서 순환해야 하며, Escape 또는 명확한 닫기 버튼으로 닫을 수 있어야 합니다. 닫힌 뒤에는 사용자를 원래 열기 버튼으로 돌려보내야 합니다. 이 흐름이 없으면 키보드 사용자는 화면 안에서 위치를 잃습니다.

드롭다운과 모바일 메뉴도 비슷합니다. 메뉴가 닫혀 있을 때 내부 링크가 포커스 가능한 상태로 남아 있으면 안 됩니다. 반대로 메뉴가 열렸는데 포커스 표시가 숨겨지거나, 배경 페이지로 이동해 버리면 안 됩니다. AI에게 메뉴 UI를 맡길 때는 모달 포커스 트랩, Escape, 닫힌 상태의 focusability, 열림 상태 안내를 지시서에 포함해야 합니다.

데이터 테이블과 관리자형 화면

테이블은 보기에는 단순하지만 접근성 구조가 중요합니다. 헤더 셀과 데이터 셀이 연결되어야 하고, 정렬 버튼은 현재 정렬 상태를 알려야 하며, 행 액션은 어떤 행에 대한 액션인지 이름에 포함해야 합니다. “편집” 버튼이 수십 개 반복되는 테이블은 스크린 리더에서 의미가 부족합니다. “홍길동 행 편집”처럼 대상이 들어가야 합니다.

관리자형 화면을 공개 서비스에 붙일 때는 접근성과 정보 노출을 함께 봐야 합니다. 사용자가 볼 필요 없는 내부 상태 이름이나 작업자용 문구가 UI에 보이면 접근성 이전에 신뢰 문제가 됩니다. VIBE 코딩에서는 카드와 테이블을 빠르게 만들수록 레이블, 설명, 상태 문구가 방문자 언어인지 함께 확인해야 합니다.

실수와 주의점

aria를 많이 쓰는 것이 좋은 접근성은 아니다

초보자가 자주 하는 실수는 모든 요소에 role과 aria-label을 덧붙이는 것입니다. 하지만 올바른 button, a, label, input, heading을 쓰면 많은 접근성 정보가 기본으로 제공됩니다. 잘못된 aria는 없는 것보다 나쁠 수 있습니다. 예를 들어 클릭 가능한 div에 role을 붙이는 것보다 실제 button을 쓰는 편이 안전합니다. 링크처럼 이동하는 요소는 a가 맞고, 화면 안에서 동작을 수행하는 요소는 button이 맞습니다.

AI에게도 “aria를 많이 추가하라”가 아니라 “시맨틱 HTML을 먼저 사용하고, 시각 텍스트만으로 이름이 부족한 컨트롤에만 aria-label을 보완하라”고 지시해야 합니다. 구현 리뷰에서는 aria 속성이 실제 상태와 동기화되는지 확인합니다. 열림 상태, 선택 상태, 오류 설명이 화면 상태와 달라지면 사용자에게 거짓 정보를 주게 됩니다.

색 대비와 포커스 표시를 디자인 취향으로 취급하지 않는다

색 대비와 focus-visible 스타일은 디자인 취향이 아니라 사용 가능성입니다. AI가 브랜드 색을 적용하면서 텍스트 대비를 낮추거나, 예쁜 화면을 위해 포커스 outline을 제거하는 경우가 많습니다. 포커스 표시가 없으면 키보드 사용자는 현재 위치를 알 수 없습니다. 저시력 사용자는 낮은 대비의 안내 문구를 읽기 어렵습니다.

디자인 시스템이 있다면 색 대비 기준과 포커스 스타일을 토큰에 넣어 두는 것이 좋습니다. 시스템이 없다면 최소한 핵심 CTA, 본문 텍스트, 오류 메시지, 비활성 버튼, 배지의 대비를 배포 스모크에서 확인합니다. AI가 “outline: none”을 넣었다면 반드시 대체 포커스 스타일이 있는지 봅니다.

자동 검사 통과를 최종 합격으로 착각하지 않는다

axe 같은 자동 검사는 중요한 안전망이지만 모든 문제를 잡지 못합니다. 자동 검사는 버튼 이름이 있는지 알 수 있지만, 그 이름이 제품 맥락에서 충분한지는 사람이 봐야 합니다. 색 대비 수치를 잡을 수 있지만, 오류 회복 경로가 사용자를 안심시키는지 판단하지 못합니다. 포커스 가능한 요소가 있는지 볼 수 있지만, 실제 탐색 순서가 자연스러운지는 사람이 걸어 봐야 합니다.

따라서 접근성 스모크는 자동 검사와 수동 확인의 조합입니다. 자동 검사를 먼저 돌려 명백한 결함을 줄이고, 수동 스모크로 핵심 흐름의 사용성을 확인합니다. 배포 전 시간이 부족해도 키보드 탐색, 주요 CTA 이름, 오류 상태, 모달 닫기만큼은 빼지 않는 것이 좋습니다.

접근성 이슈를 모두 한 PR에 몰아넣지 않는다

접근성 개선을 대형 리팩터링으로 만들면 리뷰가 어려워지고 rollback 범위가 커집니다. 버튼 이름 보강, label 연결, 포커스 회복, 색 대비 개선, heading 정리, 모달 트랩 보강은 관련 흐름별로 나눌 수 있습니다. AI에게는 한 번에 “사이트 전체 접근성 개선”을 맡기지 말고, “검색 모달의 키보드 탐색과 스크린 리더 이름만 개선”처럼 좁은 범위를 줘야 합니다.

작은 범위는 검증도 쉽습니다. 변경한 흐름의 acceptance criteria, 접근성 회귀 테스트, 배포 스모크 결과를 함께 남기면 리뷰어가 안전하게 승인할 수 있습니다. 문제가 생기면 해당 흐름만 rollback하거나 hotfix할 수 있습니다.

검증 체크리스트

작업 전 체크

• 기능의 핵심 사용자 흐름을 한 문장으로 적었는가.
• 접근성 acceptance criteria가 포커스 순서, 키보드 탐색, 스크린 리더 이름, 오류 전달, 색 대비, 모달 포커스 트랩 중 필요한 항목을 포함하는가.
• AI 작업 지시서에 시맨틱 HTML 우선, 클릭 가능한 div 금지, label 연결, aria-label 보완, 색만으로 상태 전달 금지 같은 제약이 들어갔는가.
• 기존 화면의 접근성 회귀 테스트나 스모크 기준을 확인했는가.

구현 후 자동 체크

• axe 또는 동등한 자동 검사에서 이름 없는 버튼, label 없는 입력, 잘못된 aria 속성, 명백한 색 대비 문제가 없는가.
• 제목 구조가 H1 하나와 논리적 H2, H3 흐름으로 읽히는가.
• 이미지와 아이콘에 필요한 대체 텍스트 또는 숨김 처리가 적용되었는가.
• 오류 메시지가 입력 필드와 연결되고 텍스트로 설명되는가.

배포 스모크 체크

• 마우스 없이 Tab, Shift+Tab, Enter, Space, Escape로 핵심 흐름을 완료할 수 있는가.
• 포커스 표시가 항상 보이고 포커스 순서가 시각적 흐름과 크게 어긋나지 않는가.
• 스크린 리더에서 주요 CTA, 카드 링크, 아이콘 버튼의 목적이 구분되는가.
• 모달, 드롭다운, 모바일 메뉴에서 포커스가 갇히거나 사라지지 않는가.
• 배포 후 대표 페이지와 상세 페이지에서 같은 검증이 다시 통과하는가.

rollback 판단

• 가입, 결제, 저장, 제출 같은 핵심 흐름이 키보드로 불가능하면 배포를 멈추거나 rollback한다.
• 주요 CTA가 스크린 리더에서 목적 없이 읽히면 hotfix 전까지 공개 확대를 보류한다.
• 모달 포커스 트랩이 깨져 사용자가 닫을 수 없으면 즉시 수정하거나 rollback한다.
• 색 대비 문제로 본문이나 오류 메시지를 읽기 어렵다면 최소한 해당 스타일을 이전 안전값으로 되돌린다.

다음 단계

접근성 스모크 루프를 팀에 정착시키려면 처음부터 거창한 감사 체계를 만들 필요는 없습니다. 먼저 자주 배포되는 한 페이지를 고릅니다. 그 페이지의 핵심 흐름을 기준으로 키보드 탐색, 스크린 리더 이름, 오류 상태, 모달 또는 메뉴, 색 대비를 10분 안에 확인하는 체크리스트를 만듭니다. 다음 AI 작업부터 그 체크리스트를 작업 지시서와 리뷰 템플릿에 넣습니다.

그다음 자동화할 수 있는 부분을 하나씩 테스트로 옮깁니다. label 누락, 중복 H1, 접근성 이름 없는 버튼, 명백한 색 대비, 닫힌 메뉴 안의 포커스 가능 요소처럼 반복되는 결함부터 회귀 테스트로 잠급니다. 모든 것을 자동화하려고 하지 말고, 반복해서 깨지는 것부터 자동화합니다.

마지막으로 배포 스모크 결과를 기록합니다. 어떤 경로를 키보드로 걸었는지, 어떤 스크린 리더 이름을 확인했는지, 어떤 결함을 보류했는지, 어떤 조건이면 rollback할지 남겨야 다음 사람이 이어받을 수 있습니다. VIBE 코딩에서 좋은 운영은 AI가 빠르게 만든 화면을 사람이 느리게 다시 만드는 것이 아니라, AI가 빠르게 만들수록 사람의 검증 루프도 작고 반복 가능하게 만드는 것입니다.