Figma에서는 맞는데, 브라우저에서는 틀립니다
프론트엔드 개발자라면 매일 겪는 장면이 있습니다. Figma 시안에서 gap: 16px로 지정된 간격이, 실제 브라우저에서는 부모의 padding과 겹치면서 24px처럼 보이는 순간. Tailwind 클래스 gap-4를 정직하게 적었는데 레이아웃이 1px 어긋나는 그 순간. dev.to에 올라온 「AI Coding Tools and the Runtime Context Gap」이라는 글은 바로 이 지점을 정확히 찔러줍니다. AI 코딩 도구는 소스 파일을 읽을 뿐, 브라우저가 계산한 최종 스타일(computed styles)이나 렌더링된 DOM 트리, 서버 미들웨어의 실행 순서 같은 '런타임 컨텍스트'는 보지 못한다는 것입니다.
런타임 갭, 정확히 어디서 벌어지나
사실 이건 디자인-개발 갭의 확장판입니다. 소스 코드와 실행 결과 사이에는 두 겹의 벽이 있습니다.
클라이언트 쪽 벽: CSS 변수, @container 쿼리, 캐스케이드 순서, 상속이 뒤섞여 최종 스타일이 결정됩니다. JSX가 곧 DOM이 아니고, 포탈·조건부 렌더링·프래그먼트를 거치면 실제 트리는 소스와 상당히 달라집니다. AI는 클래스명을 읽을 수 있지만, getComputedStyle()의 결과값은 읽지 못합니다.
서버 쪽 벽: Next.js의 파일 기반 라우팅은 런타임에서야 라우트 테이블이 확정됩니다. Astro의 아일랜드 하이드레이션은 어떤 컴포넌트가 실제로 hydrate됐는지 서버 로그를 봐야 알 수 있고, Vite의 HMR 모듈 그래프는 소스 코드만으로는 재현이 불가능합니다. 원문의 표현을 빌리면, "소스 코드는 실행 중인 애플리케이션의 완전한 그림이었던 적이 없다"는 겁니다.
CSS 변수 시스템이 증명하는 '소스 ≠ 런타임'
이 런타임 갭이 왜 실무에서 치명적인지, DateSpark 프로젝트의 CSS 변수 아키텍처를 보면 바로 체감됩니다. dev.to에 공유된 이 프로젝트는 --color-brand-600, --space-4, --shadow-auth-card 같은 디자인 토큰을 :root에 선언하고, --shadow-plan-card: var(--shadow-feature-card)처럼 시맨틱 앨리어스로 연결하는 구조를 씁니다.
사용자 입장에서는 이 시스템이 아름답습니다. 브랜드 컬러 하나 바꾸면 전체 페이지가 따라오니까요. 그런데 AI 코딩 도구 입장에서는? var(--overlay-brand-500-12)라는 토큰이 실제로 rgba(244, 63, 94, 0.12)로 풀린다는 걸 런타임에서 계산하기 전까지는 알 수 없습니다. 라디얼 그래디언트가 겹치면서 만들어내는 시각적 깊이감, cream 배경 위에서 rose-25 카드가 만드는 미묘한 대비 — 이건 px 단위로 DevTools에서 찍어봐야 알 수 있는 영역입니다. 접근성 측면에서도, aria-labelledby로 연결된 카드 제목이 스크린리더에서 제대로 읽히는지는 실제 브라우저에서 탭을 눌러봐야 확인됩니다.
크로스플랫폼으로 가면 갭은 두 배가 됩니다
Velog에 올라온 React-Electron 확장기를 읽으면 이 갭이 더 선명해집니다. 기존 BrowserRouter가 Electron의 file:// 프로토콜에서 깨지는 문제, contextIsolation: true로 렌더러-메인 프로세스 간 보안 경계를 설정하는 문제, isElectron() 분기가 코드 전체에 퍼지는 것을 platformService 패턴으로 한 곳에 모으는 설계 — 이 모든 판단은 "실제로 데스크탑에서 돌려보고 깨져봐야" 나오는 인사이트입니다.
AI 도구에게 "Electron에서 HashRouter로 바꿔줘"라고 요청할 수는 있습니다. 하지만 file:// 환경에서 preload 스크립트가 contextBridge를 통해 노출한 API만 렌더러에서 접근 가능한지, 빌드된 정적 파일을 Electron이 제대로 로드하는지 — 이건 런타임을 직접 확인해야 하는 영역입니다. CRA가 외부 디렉토리 import를 제한해서 shared/를 webapp/ 안에 둘 수밖에 없었다는 현실적 제약도, AI가 프로젝트 설정 파일의 런타임 동작까지 파악하지 못하면 제안할 수 없는 판단입니다.
런타임을 읽는 도구들, 그리고 솔직한 한계
원문은 이 갭을 메우려는 도구들도 소개합니다. Frontman처럼 프레임워크 미들웨어에 직접 끼어드는 방식, Stagewise처럼 브라우저 프록시로 DOM 컨텍스트를 잡는 방식, Chrome DevTools MCP처럼 런타임 상태를 LLM이 호출할 수 있게 노출하는 방식. MCP(Model Context Protocol)를 통해 computed style, 라우트 테이블, 컴파일된 모듈 그래프를 AI 에이전트에게 넘겨주겠다는 구상입니다.
솔직히 말하면, 원문 저자의 표현이 가장 정확합니다: "디버거 훅에 추가 단계를 더한 것이지만, 의미 있는 개선이기도 하다." React DevTools + Chrome DevTools + 소스맵으로 이미 볼 수 있는 정보를, LLM이 프로그래밍적으로 소비할 수 있게 포장한 것이니까요. 하지만 describe → edit → 브라우저 확인 → IDE 복귀 → 재설명 루프가 클릭 → 설명 → 핫 리로드로 줄어든다면, 그건 Lighthouse 점수를 1점 올리는 것보다 DX(Developer Experience)에 더 큰 영향을 줄 수 있습니다.
그래서 프론트엔드 개발자가 사수해야 할 것
원문에서 가장 날카로운 문장은 이겁니다: "코드가 런타임 동작과 너무 동떨어져서 사람도 AI도 예측할 수 없다면, 그건 도구가 아니라 아키텍처 문제다." 5개 파일에 걸쳐 퍼진 조건부 렌더링, 3단계 추상화를 타고 캐스케이딩되는 CSS 오버라이드, 아무도 전체를 이해하지 못하는 미들웨어 체인 — AI에 런타임 접근권을 줘도 이건 고쳐지지 않습니다.
토스 테크 블로그의 AST 기반 퍼널 시각화 사례도 같은 맥락입니다. router.push() 호출만 추출해서 Mermaid 다이어그램을 자동 생성하는 건, 결국 "코드의 의미 구조를 사람이 읽을 수 있는 형태로 환원"하는 작업입니다. AI가 코드를 짜주는 속도가 빨라질수록, 그 코드가 만드는 런타임 결과물을 검증하고 구조화하는 인간의 역할은 오히려 더 중요해집니다.
결국 AI 시대 프론트엔드 개발자의 진짜 전장은 소스 에디터가 아닙니다. DevTools의 Computed 탭, Elements 패널의 실제 DOM 트리, Network 탭의 미들웨어 응답 순서, 그리고 키보드 탭 한 번으로 드러나는 접근성의 빈틈 — 이 런타임의 1px을 사수하는 사람이 AI 시대에도 대체 불가능한 프론트엔드 개발자입니다. AI가 코드를 짜는 속도는 계속 빨라지겠지만, "Figma에서는 맞는데 브라우저에서는 틀린" 그 갭을 메우는 건 당분간 사람의 눈과 손가락이 해야 할 일입니다.