프론트엔드 개발의 속도를 결정하는 변수는 두 가지로 수렴되고 있다. 하나는 빌드 인프라의 성능이고, 다른 하나는 AI 에이전트와의 협업 품질이다. 최근 이 두 축에서 동시에 의미 있는 변화가 일어났다. Oxc가 React Compiler를 Babel AST 없이 직접 통합하는 방식을 공개했고, 한 개발자는 10개월간 AI 에이전트와 함께 실제 프로젝트를 운영하며 체계적인 협업 방법론을 정리해 공유했다. 두 소식은 별개처럼 보이지만, '빠른 프로토타이핑 → 검증 → 고도화'라는 흐름 안에서 강하게 맞물린다.
중간 변환 단계를 없앤다는 것의 의미
React Compiler는 컴포넌트와 Hook을 빌드 시점에 분석해 자동으로 memoization을 적용한다. 좋은 개념이지만, 기존 빌드 파이프라인에 끼워 넣으려면 컴파일러 자체가 또 하나의 비용이 된다. Velog에 정리된 Oxc의 접근 방식은 이 구조적 문제를 정면으로 파고들었다.
핵심은 AST 변환 단계를 줄이는 것이다. 기존 흐름에서 React Compiler의 Rust 포트는 자체적인 Babel 형태의 AST를 유지하고 있었다. 그 결과 Oxc에서 사용하려면 소스 → Oxc AST → Babel 형태 AST로 변환 → React Compiler → 다시 Oxc AST로 변환이라는 왕복 여정이 불가피했다. 메모리 할당과 변환 비용이 언어를 Rust로 바꿔도 그대로 남는 구조였다.
Oxc 팀은 방향을 틀어 React Compiler를 Oxc 내부에 vendor하고, 컴파일러가 Oxc AST를 직접 처리하도록 수정했다. 결과는 소스 → Oxc AST → React Compiler → Oxc Transform으로 단순해진다. 성능 개선의 핵심이 언어를 바꾼 것이 아니라, 컴파일 단계 사이의 표현 변환을 없앤 데 있다는 점이 인상적이다. 공개된 초기 벤치마크에서 oxc-transform-react는 babel-plugin-react-compiler 대비 10배 이상 빠른 수치를 보였고, 파일 하나 처리 시간이 약 100ms에서 10ms 수준으로 줄었다고 설명한다.
다만 이 수치를 곧이곧대로 받아들일 필요는 없다. React Compiler는 전체 Vite 빌드 파이프라인의 한 단계일 뿐이다. 프로젝트의 병목이 번들링이나 minification에 있다면 전체 빌드 시간 단축 효과는 훨씬 작아진다. Oxc 팀 스스로도 이 수치가 preliminary/local 벤치마크임을 명시하고 있다.
숫자보다 중요한 구조적 변화
10배라는 숫자보다 주목해야 할 것은 아키텍처의 변화다. 이번 통합에서 Oxlint도 React Compiler의 validation 로직을 활용하게 됐다. Oxlint에는 React Compiler 기반 규칙 22개가 추가됐는데, immutability, purity, refs, set-state-in-render, static-components 같이 컴파일러가 최적화 가능성을 판단할 때 검사하는 조건들을 lint 단계에서 미리 확인할 수 있다.
이것은 개발 흐름을 바꾸는 변화다. 기존에는 빌드 후에야 컴파일러가 어떤 컴포넌트의 최적화를 건너뛰었는지 알 수 있었다. 이제는 코드를 작성하는 순간 lint 단계에서 원인을 확인할 수 있다. React Compiler가 Rules of React를 위반하거나 안전하게 분석할 수 없는 코드는 해당 컴포넌트의 최적화를 포기한다는 점을 감안하면, 이 피드백 루프의 단축이 실제 개발 경험에서 가지는 의미는 크다.
Vite와의 연결 방식도 눈여겨볼 부분이다. React Compiler integration을 Vite나 Rolldown 코어에 넣지 않고 @vitejs/plugin-react에 위치시킨 선택은, 빌드 도구의 framework-neutral 원칙을 지키면서 React 고유의 기능을 분리하려는 의도다. 설정은 react({ compiler: true }) 한 줄로 끝난다. 다만 현재는 experimental 상태이며, 복잡한 JSX transform이나 MobX observer() 같은 mutation 기반 라이브러리를 사용하는 기존 프로젝트에는 제약이 있다.
AI 에이전트와 10개월, 찾아낸 하나의 구조
dev.to에 공유된 글은 다른 종류의 인프라 이야기다. 한 개발자가 10개월간 복잡한 신규 프로젝트를 처음부터 구축하고, 여러 상용·오픈소스 코드베이스를 유지하면서 AI 에이전트와 협업하는 방법을 실전으로 검증한 결과물이다. 그는 팀원 대부분이 직접 손으로 쓰는 코드가 15% 이하이고, 자신의 경우 2% 수준이라고 밝혔다. 이 비율이 높아질수록, 에이전트가 만들어내는 코드의 품질이 곧 리뷰 비용과 출시 속도를 결정한다.
그가 진단한 에이전트 생성 코드의 근본 문제는 기술적인 것이 아니었다. 에이전트와의 새 채팅은 신입 개발자의 첫 출근과 같다. 어떤 헬퍼가 이미 존재하는지, 어떤 문제가 이미 해결됐는지, 어떤 인터페이스가 쓰이는지 모른다. 그리고 사람과 달리 에이전트는 거의 반박하지 않는다. 태스크를 던지면 질문 없이 구현을 시작하고, 자신이 이해한 가장 가까운 해법으로 방향을 잡는다.
두 번째 문제는 태스크 자체의 이해다. 개발자가 관리자가 상상한 대로 정확히 구현하는 경우는 드물다. 요구사항은 변하고, 전체를 이해하는 사람은 처음부터 아무도 없다. 태스크에 대한 완전한 이해는 종종 만들면서야 생긴다. 에이전트도 마찬가지다. 세 번째는 컨텍스트 전달이고, 네 번째는 변경 범위의 통제다. 에이전트는 100개 파일을 쉽게 수정해버리고, 그 diff를 제대로 리뷰하는 것은 사실상 불가능에 가깝다.
Grill: 구현 전에 결정을 끝낸다
이 문제들을 해결하기 위해 그가 정착한 핵심 메서드는 /grill이다. Matt Pocock의 아이디어에서 출발한 이 방식은, 구현 전에 에이전트가 태스크를 실제로 이해하고 있음을 증명하게 한다. 에이전트는 태스크를 재서술하고, 이미 내포된 결정과 가정을 찾아내고, 결과에 실질적인 영향을 줄 수 있는 모든 것을 사용자에게 물어본다.
Grill은 태스크를 결정 트리로 모델링한다. 에이전트는 다른 미결 결정에 의존하지 않는 질문부터 시작하고, 각 질문에 권장 답변과 대안을 함께 제시한다. 초기 3개의 질문이 14개로 이어질 수도 있다. 중요한 역할 분리가 있다. 사실을 찾는 것은 에이전트의 일이고, 결정을 내리는 것은 사용자의 일이다. 어떤 헬퍼나 컴포넌트가 이미 있는지는 에이전트 스스로 코드와 문서를 뒤져 찾아야 한다. 에이전트는 그 조사를 마친 후 진짜로 제품이나 아키텍처 결정이 필요한 질문만 가져온다.
Grill이 끝나면 에이전트는 구현을 시작할 충분한 컨텍스트를 갖추고, 사용자는 에이전트가 무엇을 만들려는지 안다. 이 질문들은 절반이 이미 만들어진 뒤에야 발견할 문제를 미리 드러낸다. 경험 많은 시니어 개발자가 "이 시나리오는 어떻게 동작해야 해요?"라고 바로 묻는 것과 비슷한 느낌이라고 그는 표현했다.
Spec이 아닌 흐름으로
그가 명시적으로 버린 것도 있다. OpenSpec 같은 spec-driven 프레임워크는 요구사항과 설계를 먼저 정의한 뒤 코드를 작성하는 방향으로 무게 중심을 옮긴다. 개념은 합리적이지만 두 가지 문제가 뒤따른다. 명세가 항상 최신 상태를 유지해야 하고, 모든 태스크에 작성과 검토라는 의식이 붙는다. 실제로 그의 팀에서 spec 디렉토리는 아무도 책임질 수 없을 만큼 커졌고, 결국 삭제했다.
대신 AgentFlow라는 이름으로 패키지화한 방법론의 흐름은 이렇다. 에이전트가 변경할 시스템 부분을 먼저 조사한다. 관련 모듈, 파일, 문서를 찾고 현재 아키텍처를 스케치한다. 그 위에서 Grill로 결정을 끝낸다. 이후 변경을 작은 단계로 나눠 각각 검증하며 진행한다. 컨텍스트는 채팅 히스토리가 아닌 구조화된 방식으로 이어진다. 이 흐름은 UI 한 곳의 변경부터 여러 저장소에 걸친 에픽까지 동일하게 적용된다고 한다.
두 흐름이 만나는 지점
이 두 이야기는 같은 방향을 가리킨다. Oxc의 React Compiler 통합은 빌드 인프라 차원에서 불필요한 변환 비용을 없애고, lint와 컴파일의 피드백 루프를 하나로 묶는다. AgentFlow의 Grill은 에이전트 협업에서 컨텍스트 손실과 무분별한 구현을 막고, 결정을 미리 끝낸다. 둘 다 '처음부터 올바르게'라는 원칙을 각자의 영역에서 실현하려는 시도다.
프로토타이핑 단계에서 에이전트가 코드를 빠르게 생성할 때, 빌드 피드백이 느리면 검증 루프도 느려진다. Oxc의 구조적 단순화는 이 루프를 조여주는 인프라가 된다. 반대로 빌드가 아무리 빨라도 에이전트가 잘못된 방향으로 100개 파일을 수정해버린다면 속도는 오히려 독이 된다. 구현 전에 결정을 끝내는 Grill이 그 방어선이다.
현재 Oxc의 React Compiler 지원은 experimental이고, AgentFlow의 방법론은 특정 팀과 프로젝트에서 검증된 것이다. 두 가지 모두 실험과 맥락이 필요한 도구다. 하지만 프론트엔드 개발의 속도와 품질을 동시에 높이려는 사람이라면, 이 두 흐름이 교차하는 지점을 주목할 이유는 충분하다.