AI가 코드를 쓰는 속도는 이미 사람의 손을 앞질렀다. 한 오후에 20개 파일이 담긴 PR이 날아오는 건 이제 낯선 풍경이 아니다. 그런데 리뷰어의 눈은 그 속도를 따라가지 못한다. 더 정확히 말하면, 예전 방식 그대로 따라가려는 시도 자체가 잘못된 접근이다. 병목은 생성에서 검증으로 이동했고, 품질 기준도 그에 맞게 재설계되어야 한다.
리뷰의 목적을 다시 묻다
dev.to에 올라온 "Review the code that does not exist yet"은 이 전환점을 가장 날카롭게 포착한 글이다. 저자는 수년간 PR을 열면 매 줄을 훑고, 들여쓰기와 네이밍과 패턴 위반을 찾아내는 것이 리뷰라고 믿었다. 그러다 CSS 변경 PR 하나에 댓글 17개를 달고 나서야 깨달았다. 자신이 '코드'를 리뷰했지, '작업'을 리뷰하지 않았다는 것을. 기능은 동작했고, 요구사항은 충족됐고, UI는 명확했다. 그는 포맷을 수호하느라 정작 중요한 걸 놓쳤다.
AI 코드 생성 시대에 이 문제는 배수로 증폭된다. 줄 단위 리뷰에 집중하다 보면 가장 예리한 판단력을 가장 사소한 곳에 먼저 소진하게 된다. 반면 진짜 위험은 파일과 파일 사이, 가정과 가정이 교차하는 경계 지점에 숨어 있다. 저자는 45개 파일짜리 PR을 대충 훑어 승인했다가, 6개월 뒤 프로덕션에서 중복 트랜잭션 버그를 마주했다. 개별 파일은 모두 맞았지만, 전체가 틀렸던 것이다.
의도 중심 리뷰로의 전환
저자가 제안하는 대안은 간단하지만 근본적이다. 코드를 열기 전에 먼저 의도를 읽는다. 이 변경이 무엇을 하려는가 → 어떻게 해결했는가, 내가 다르게 풀었을 것인가 → 어떤 트레이드오프가 보이는가 → 이게 정말 시스템을 개선하는가, 아니면 미래의 시한폭탄인가 → 정말 확신하는가. 이 흐름을 다 통과한 뒤에야 비로소 줄 단위 정밀 검사가 시작된다. 엄격함의 위치가 달라졌을 뿐, 엄격함 자체가 사라진 게 아니다.
이 프레임을 프론트엔드 컴포넌트 설계에 그대로 대입하면 시사점이 선명해진다. AI가 생성한 컴포넌트를 리뷰할 때 먼저 물어야 할 건 "이 컴포넌트가 시스템의 어떤 문제를 해결하는가"이고, 그다음이 "이 구조가 6개월 뒤에도 이해 가능한가"다. Prop 네이밍이나 파일 구조 같은 줄 단위 이슈는 그 이후에 다뤄야 할 질문이다.
접근성은 의도 리뷰의 가장 좋은 테스트 케이스다
의도 중심 리뷰가 실제로 무엇을 뜻하는지, 접근성 구현이 구체적으로 보여준다. dev.to의 "The Ins and Outs of Closings"는 React로 완전한 접근성 네비게이션 컴포넌트를 구축하는 시리즈의 일부로, 이번 편에서는 서브내비게이션 닫기 동작을 다섯 가지 수용 기준으로 쪼개 구현한다. 부모 리스트가 닫힐 때 중첩된 자식도 함께 닫히는 캐스케이드 동작, 상단 행 포커스 이동 시 열린 서브리스트 자동 닫기, 컴포넌트 바깥으로 포커스가 이탈할 때의 처리까지—ARIA Authoring Practices Guide가 명문화하지 않은 동작까지 사용자 기대치를 역산해서 설계한다.
이 수준의 디테일은 AI가 자동으로 생성하지 않는다. AI는 onClick으로 드롭다운을 토글하는 코드는 금방 만들어낸다. 하지만 Escape 키가 눌렸을 때 포커스가 최상위 부모로 돌아가야 한다는 규칙, onFocus 이벤트가 링크와 버튼 모두에서 동등하게 처리돼야 한다는 패리티 요구사항은 명세가 없으면 생성도 없다. 의도 중심 리뷰가 중요한 이유가 바로 여기에 있다. AI가 만든 컴포넌트를 리뷰할 때 "키보드 사용자가 이 컴포넌트를 어떻게 경험하는가"라는 질문이 없으면, 코드가 아무리 깔끔해도 실제로 배제된 사용자가 생긴다.
React 19 컴포넌트 설계: 구조가 품질이다
세 번째 소재인 SupaForm Builder는 또 다른 각도를 제공한다. React 19, TypeScript, Zod, Firebase를 조합한 오픈소스 폼 빌더로, 개발자가 SaaS 폼 빌더에 월 수십만 원을 내는 대신 드래그앤드롭으로 설계하고 JSON 출력을 자신의 백엔드에서 처리할 수 있도록 만들어졌다. 이 프로젝트가 흥미로운 이유는 기능 목록이 아니라 설계 결정이다. 라우트 기반 코드 스플리팅, 컴포넌트 지연 로딩, 150KB 이하의 번들—이 선택들은 폼 빌더라는 도메인 특성과 맞닿아 있다. 폼은 사용자 전환율에 직결되기 때문에 로딩 지연이 곧 이탈이다.
AI로 프로토타입을 빠르게 올릴 수 있는 지금, 이 프로젝트가 던지는 질문은 이것이다. AI가 초안을 만들어준다고 해서 설계 결정도 자동화되는가? 답은 명백히 아니다. Form.io를 빌더 엔진으로 채택할지, Zod를 검증 레이어로 두고 Firebase를 스토리지로 분리할지—이 아키텍처 결정은 사용자 문제와 비즈니스 제약을 읽는 사람이 내린다. AI는 그 결정을 코드로 구현하는 속도를 높여줄 뿐이다.
AI 시대 프론트엔드 품질의 새로운 정의
세 소재를 교차하면 하나의 원칙이 남는다. AI가 코드 생성을 민주화하면, 품질 기준은 더 높아져야 한다. 역설적으로 들리지만 논리는 단순하다. 생성 비용이 0에 수렴할수록, 무엇을 만들지와 왜 만드는지에 대한 판단이 유일한 희소 자원이 된다.
프론트엔드 개발자가 지금 재설계해야 할 것은 세 가지다. 첫째, 리뷰 프로세스—줄 단위 체크리스트에서 의도와 구조를 먼저 검증하는 순서로. 둘째, 접근성 명세—AI에게 프롬프트를 주기 전에 키보드 흐름과 ARIA 요구사항을 수용 기준으로 문서화하는 습관으로. 셋째, 컴포넌트 아키텍처 결정 기준—React 19의 새 기능을 채택할 때 '가능한가'가 아닌 '이 도메인에서 옳은가'를 먼저 묻는 것으로.
AI가 PR에 20개 파일을 쏟아내는 속도는 앞으로 더 빨라진다. 리뷰어가 그 속도에 압도되지 않으려면, 더 빨리 읽는 방법이 아니라 무엇을 먼저 읽을지 알고 있어야 한다. 코드가 존재하기 전에, 그 코드가 만들어낼 경험을 먼저 리뷰하는 것—그게 지금 시대의 프론트엔드 품질 기준이다.