AI가 40분 만에 기능을 '배송'하는 시대
dev.to에 올라온 바이브 코딩 분석 글에 따르면, 한 시리즈 B 스타트업 개발자가 CSV 임포트 파이프라인—파싱, 밸리데이션, 에러 리포팅, DB 쓰기, 프로그레스 바 UI까지—을 AI 에이전트로 40분 만에 완성했다고 합니다. 이전이라면 이틀은 잡았을 작업입니다. Stack Overflow 2025 서베이 기준, 매일 AI를 쓰는 개발자가 73%에 달하고, 프로토타이핑 속도는 4배 빨라졌다고 보고됩니다. 솔직히 놀랍지 않아요. 저도 Cursor에서 Composer 모드 켜놓으면 컴포넌트 뼈대가 순식간에 나오는 걸 매일 경험하고 있으니까요.
그런데 말입니다. 그 40분짜리 프로그레스 바, height가 정확히 4px인지 누가 확인했을까요?
문제는 '생성'이 아니라 '검증'에 있다
바이브 코딩의 핵심은 명확합니다. Andrej Karpathy가 2025년 초 정의한 대로, 개발자는 자연어로 의도를 기술하고 AI 에이전트가 코드를 반복 생성·테스트·수정하는 루프를 돌리는 방식이죠. RAG로 코드베이스 컨텍스트를 유지하고, 100만 토큰 넘는 롱컨텍스트 윈도우가 이걸 뒷받침합니다. 개발자는 사실상 프로덕트 매니저 역할로 전환되는 셈입니다.
그런데 프론트엔드 실무에서 이 워크플로우를 돌려보면, 사용자 입장에서는 꽤 아슬아슬한 지점이 드러납니다. AI가 생성한 React 컴포넌트가 useState로 상태를 잘 관리하고, useEffect의 의존성 배열도 빈 배열로 깔끔하게 처리하고, 조건부 렌더링도 삼항 연산자로 무난하게 짜줍니다—velog의 리액트 필수 매뉴얼에 나오는 그 교과서적인 패턴 그대로요. 문법적으로는 완벽합니다. 하지만 그 컴포넌트가 디자인 시스템의 spacing scale을 지키는지, gap: 12px이 아니라 gap: var(--space-3)을 쓰는지, 버튼의 focus ring이 WCAG 2.1 AA 기준 3:1 대비를 충족하는지는 전혀 다른 차원의 문제입니다.
Flexbox 한 줄이 UX를 결정하는 순간
velog에 올라온 Flexbox Defense 해설 글을 보면, justify-content: space-between과 space-around의 차이가 단순한 CSS 퀴즈가 아니라 실제 레이아웃의 시각적 균형을 좌우한다는 걸 알 수 있습니다. align-self: flex-end로 특정 요소만 하단 정렬하고, order 속성으로 시각적 순서를 재배치하는 건—게임에서야 재밌지만—프로덕션에서는 스크린리더의 읽기 순서와 시각적 순서의 괴리를 만들 수 있는 위험한 선택이기도 합니다.
AI에게 "카드 3개를 가로로 균등 배치해줘"라고 프롬프트를 던지면, 높은 확률로 display: flex; justify-content: space-between;을 뱉어냅니다. 사실 이건 flexbox로 해결되지만… 컨테이너 너비가 좁아질 때 카드가 찌그러지는 건 고려하지 않아요. flex-wrap: wrap을 넣을지, 아니면 grid의 auto-fill/minmax()가 더 적절한지는 브레이크포인트별로 Figma 시안을 px 단위로 뜯어본 사람만 판단할 수 있습니다.
디자인-개발 갭은 AI가 좁혀주지 않는다
포트폴리오 리뉴얼 사례를 다룬 dev.to 글이 흥미로운 대목을 보여줍니다. 다크 모드에서 폼 입력 필드와 레이블의 가독성을 확보하기 위해 "color inheritance에 세심한 주의를 기울였다"는 부분이요. 그리고 <Button /> 컴포넌트에 'white' variant를 추가해서 라이트/다크 모드 모두에서 CTA가 제대로 보이게 한 부분도요.
Figma에서 볼 때는 괜찮았는데, 실제로 구현하면 다크 모드에서 border-color가 배경에 묻혀버리는 일이 비일비재합니다. AI는 이 컨텍스트를 모릅니다. Design Token이 --color-border-subtle-dark: #2a2a2a로 정의되어 있고 배경이 #1a1a1a일 때, 명도 차이가 6%밖에 안 되니 사실상 보이지 않는다는 판단—이건 Lighthouse 점수에도 안 잡히고, 자동화 테스트로도 커버하기 어렵습니다. 사람의 눈이 스크린에서 직접 확인해야 하는 영역입니다.
시사점: '시니어'의 정의가 바뀐다
바이브 코딩 시대에 프론트엔드 시니어의 가치는 코드를 빠르게 치는 손가락이 아니라, AI가 생성한 결과물에서 "이거 왜 이렇게 했을까?"를 의심하는 눈에 있습니다. 구체적으로 세 가지 역량이 남습니다:
- 디자인 시스템 리터러시: AI 출력이 토큰 기반 spacing·color·typography 규칙을 따르는지 검증하는 능력. 여기서 로딩 스켈레톤 넣으면 어떨까요? 같은 제안은 AI가 못 합니다.
- 레이아웃 기초 체력: flexbox와 grid의 동작 원리를 체화하고, Container Queries나
:has()같은 새로운 CSS 기능이 어떤 문제를 해결하는지 판단하는 감각. - 접근성·반응형 감수성:
order속성이 키보드 탐색 순서를 깨뜨리지 않는지, 터치 타겟이 48px 이상인지, Core Web Vitals의 CLS를 0.1 이하로 유지하는 구조인지를 프롬프트로 지시하는 건 쉽지만 검증하는 건 어렵습니다.
전망: 프롬프트는 새 키보드, 눈은 여전히 구형 모니터
카파시의 말대로, 병목은 이제 문법이 아니라 사고의 명확성으로 이동했습니다. 하지만 프론트엔드에서는 한 발 더 나아가야 합니다. 사고의 명확성만으로는 부족하고, 시각적 판단의 정밀성이 추가되어야 합니다. AI가 이 라이브러리 도입하면 bundle size가 42KB 늘어난다고 알려줄 수는 있어도, 그 42KB짜리 애니메이션 라이브러리가 만들어내는 ease-out 커브가 브랜드 톤에 맞는지는 판단하지 못합니다.
바이브 코딩은 분명 "지루한 60%"를 자동화해줍니다. 그 덕분에 우리는 나머지 40%—미묘한 UX 결정, 분산 시스템 설계, 그리고 1px의 차이가 신뢰를 만드는 디테일—에 더 집중할 시간을 벌었습니다. 문제는 그 시간을 실제로 디테일에 쓸 역량이 있느냐는 것이고, 그건 결국 flexbox 게임이 아니라 실제 프로덕션에서 깨져본 경험의 두께에 달려 있습니다.
코드는 AI가 씁니다. 하지만 그 코드가 화면에서 제대로 보이는지는 여전히 사람이 확인합니다. 그리고 솔직히, 그게 가장 재밌는 부분이기도 하고요.