"이 사이트 React로 옮겨줘." 프론트엔드 개발자라면 한 번쯤 받아봤을 요청이다. DevTools를 열고, 스타일을 하나씩 복사하고, 패딩을 눈으로 가늠하며 사흘을 보내고 나면—원본과 96% 닮은, 하지만 왜인지 히어로 섹션 간격이 살짝 어긋난 결과물이 나온다. 이 고통이 반복되자 누군가는 그 80%를 자동화하는 도구를 만들기 시작했다.
dev.to에 공개된 url2code 프로젝트의 아키텍처 분석은, 이 문제가 왜 단순한 HTML 스크래핑으로 해결되지 않는지를 명쾌하게 짚는다. 핵심은 이것이다: 현대 웹사이트는 HTML 문서가 아니라 실행 중인 애플리케이션이다. 스타일은 CSSOM이 cascade를 전부 해소한 뒤에야 의미를 갖고, 콘텐츠의 상당수는 자바스크립트가 실행된 이후에야 존재하며, 뷰포트 아래 모든 것은 사용자가 스크롤하기 전까지 DOM에 없다. curl로 가져온 HTML은 껍데기일 뿐이다.
그래서 이 자동화 파이프라인의 첫 번째 선택지는 헤드리스 브라우저다. 페이지를 실제 브라우저처럼 렌더링하고, 네트워크와 프레임워크가 완전히 안정된 시점을 기다린 뒤, 뷰포트를 아래로 스크롤하며 지연 로딩 콘텐츠까지 모두 트리거한다. 이 단계를 건너뛰면 폴드 아래 콘텐츠가 통째로 사라지는 변환 결과가 나온다—그리고 대부분의 "웹사이트를 코드로" 도구들이 조용히 실패하는 지점이 바로 여기다.
두 번째 핵심 결정은 소스 CSS 대신 컴퓨티드 스타일을 읽는 것이다. 원본 스타일시트를 다운받아 파싱하는 대신, 브라우저가 이미 cascade를 전부 해소해놓은 최종 스타일 값을 DOM에서 직접 읽어낸다. 문제는 단일 엘리먼트의 computed style에 수백 개 프로퍼티가 딸려온다는 점이다. 대부분은 상속 기본값—설계 의도와 무관한 노이즈다. 의미 있는 레이아웃 값(박스 모델, flex/grid, 타이포그래피, 색상, 간격)만 필터링해 Tailwind 유틸리티 클래스로 매핑하는 것이 이 단계의 전부다. 이 필터링의 정밀도가 "개발자가 수용할 수 있는 출력"과 "버려지는 출력"의 차이를 만든다.
세 번째, 그리고 가장 어려운 단계가 래퍼 지옥을 컴포넌트 구조로 변환하는 것이다. 렌더링된 DOM은 수천 개의 중첩 노드로 이루어져 있지만, 실제로 유지보수 가능한 React 트리는 수십 개의 의미 단위로 구성된다. 반복 패턴(카드, 리스트 아이템, 내비게이션 링크)을 재사용 가능한 컴포넌트로 묶고, 불필요한 래퍼를 평탄화하고, 자연스러운 섹션 경계를 찾아내는 것—이것이 자동화 도구가 아직 완전히 정복하지 못한 영역이다. 제작자 스스로 솔직하게 인정한다: "좋은 시작 구조를 만들어줄 뿐, 당신이 직접 선택했을 컴포넌트 분리와 항상 일치하지는 않는다."
이 자동화 파이프라인이 흥미로운 이유는 단순히 노동을 줄여주기 때문만이 아니다. 이것은 '빠른 프로토타이핑 → 검증 → 고도화' 흐름을 마이그레이션 시나리오에 그대로 적용한 사례다. 80%를 자동으로 만들어놓고, 사람이 나머지 20%의 판단이 필요한 지점—컴포넌트 경계, 인터랙션 로직, 브랜드 디테일—에만 집중하게 만드는 구조다. 전환 작업의 가장 지루한 부분을 걷어내고, 개발자의 판단이 진짜로 필요한 영역에 에너지를 집중시킨다.
같은 맥락에서, AI-Native 개발 스택을 다룬 또 다른 dev.to 글은 이 자동화 흐름을 에이전트 워크플로우로 확장하는 실마리를 제공한다. Claude Code, Codex 같은 AI 에이전트를 실제 프로덕션 코드베이스에 연결할 때 핵심 교훈은 역설적이게도 '덜 주는 것'이다. AGENTS.md 파일은 작게 유지할수록 에이전트 성능이 올라가고, 스킬(MCP 서버, 컨텍스트 문서)은 필요한 대화에만 임시로 활성화한 뒤 제거해야 한다. 컨텍스트 창을 오염시키지 않는 것이 에이전트 품질 관리의 핵심 변수라는 통찰이다.
프론트엔드 스택 선택에서도 이 철학은 이어진다. Next.js App Router + MUI(또는 shadcn/ui)의 조합은 AI 에이전트가 코드를 생성하기 좋은 구조다—컴포넌트 경계가 명확하고, 서버/클라이언트 역할 분리가 파일 시스템 레벨에서 강제되기 때문이다. 에이전트가 "어떤 파일을 건드려야 하는가"를 스스로 추론하기 쉬운 구조, 그리고 과도한 추상화 없이 단순하게 유지된 코드베이스가 AI-Native 개발 속도를 실제로 결정한다는 것이다.
두 글이 수렴하는 지점은 결국 하나다: 자동화 80%의 실질적 가치는 나머지 20%를 위한 공간을 만드는 데 있다. 마이그레이션 자동화든 에이전트 기반 개발이든, 도구가 잘 처리하는 영역과 인간의 판단이 필수인 영역을 명확하게 구분하는 것이 워크플로우 설계의 출발점이다. 헤드리스 브라우저가 설계 의도를 읽어내고, 에이전트가 코드로 재조립하는 동안—개발자는 컴포넌트 경계를 어디에 그을 것인지, 어떤 인터랙션이 진짜 사용자 가치를 만드는지를 고민하는 데 시간을 써야 한다. 그것이 AI 도구 시대에 프론트엔드 개발자가 가져야 할 레버리지 포인트다.