프론트엔드 개발자 없이 어디까지 가능할까?
사내에서 이 주제로 리서치를 해보고 발표도 해보았습니다.
바이브 코딩 대회니 뭐니 챔피언십도 열리는 마당에 너무 보수적인거 아니야? 라는 말도 있었지만
돈을 받고 파는 물건에는 결국 꾸준한 책임이 따릅니다. 나중에 핸들링이 안 돼서 새로 만드는 게 낫다는 소리를 하기 싫었거든요.
물론 내부적으로 이 주제에 대해 말씀드릴 때는 온도를 조금 더 낮춰 친절하게 말씀드린 부분도 있지만 강조하고 싶은 부분은 명확했습니다. 결국 어떤 포지션이던 전문성 없이 그 분야에 대해서 일괄적으로 맡기는 것은 현재 불가능하고, 그건 크던 작던 상용 프로젝트에서는 아직까지는 금기시되어야한다고요.
데모는 인상적이다. 근데 그 다음은?
v0, Claude Artifacts, Generative UI 같은 서비스들을 보면 프롬프트 한 줄로 완성된 UI가 뚝딱 나옵니다. "프론트엔드 개발자 없이도 되겠는데?"
네 됩니다.
AI가 프론트엔드를 못 만든다고 생각하진 않아요. 만들 수 있습니다. 문제는 거기서부터입니다.
만드는 건 된다. 유지하는 건?
첫 버전은 그럴싸하게 나옵니다. 진짜 문제는 그 코드 위에 계속 쌓아올릴 때 생깁니다.
단발성으로 계속 쌓으면 부채가 쌓입니다. AI는 지금 이 요청에 최적화된 코드를 만들지, "6개월 뒤에 이 위에 뭘 얹어야 할 때"를 고려하지 않아요. 매번 새로 만들 듯이 코드를 생성하니까, 비슷한 로직이 여기저기 흩어지고, 상태 관리 구조가 일관되지 않고, 컴포넌트 간 의존성이 꼬입니다.
알아차리지 못한 미스매치가 쌓입니다. 디자인 시스템의 토큰을 안 쓰고 하드코딩된 값이 슬금슬금 들어오고, 에러 바운더리가 빠져있고, 접근성이 누락되고. 하나하나는 작지만 모이면 "왜 이 서비스 어딘가 어설프지?" 가 됩니다.
이걸 꾸준히 잡아가면서 퀄리티를 유지하려면 — 코드베이스에 대한 이해가 필요합니다. 여기는 왜 이렇게 돼있고, 저기를 건드리면 어디가 영향받는지를 아는 사람. AI한테 매번 컨텍스트를 처음부터 설명하는 것과, 프로젝트를 계속 들여다보는 사람이 판단하는 것은 다릅니다.
프론트엔드 개발자가 직접 손대야 할 일은 분명 많이 줄어들 겁니다. 하지만 전문성이 있는 사람이 단 한 명도 없이 상용 프로젝트를 유지하는 건 불가능하다고 생각합니다. 상용 프로젝트는 결국 돈을 받고 파는 제품이니까요. 그 품질 기준을 누가 정하고, 누가 지키는지의 문제입니다.
가능은 하죠. 지금도 바이브 코딩으로 수천개씩 쏟아지는 것들이 있잖아요.
어디에 쓰느냐입니다.
백오피스나 어드민을 보면 대부분 비슷한 구조예요. 테이블 + 필터 + 상세 모달. 이런 반복 작업에는 AI가 확실히 빠릅니다. 엣지케이스 허용 범위도 넓고, 디자인 정합성 기준도 낮아서 AI 결과물을 바로 쓸 수 있는 여지가 큽니다.
가능한 것:
- 프로토타입, 데모, 내부 발표용 UI
- 일회성 이벤트/랜딩 페이지
- 데이터 조회 + 단순 폼 저장 수준의 대시보드
어려운 것:
- 6개월 뒤에 수정해야 할 코드
- API 스펙 변경 시 영향 범위 파악
- 배포 후 모니터링, 성능 이슈 추적
- 왜 이렇게 짰는지에 대한 맥락 유지
현실적인 방향
AI로 처음부터 전부 만든다가 아니라, AI로 반복을 줄이고 사람은 판단에 집중한다가 현실적인 목표입니다.
실제로 효과를 본 방식:
-
AI 코딩 도구에 프로젝트 규칙을 주입 — 컴포넌트 네이밍, 패턴, 금지사항을 명시하면 기존 코드와 일관된 결과가 나옴. 규칙 없이 쓰는 것과 품질 차이가 확연함.
-
API 스키마 + 디자인 문서 → 코드 초안 — "이 데이터로 목록 + 상세 + 생성 폼 만들어"는 잘 동작함. 개발자는 비즈니스 로직 추가하고 리뷰하면 끝.
-
기획 단계에서 AI로 초안 빠르게 뽑기 — 완성이 아니라 출발점으로 쓰기. 거기서부터 사람이 다듬는 게 빈 화면에서 시작하는 것보다 빠름.
결론
AI가 프론트엔드 작업의 하한선을 올려주는 건 맞습니다. 누구나 그럴싸한 첫 버전을 만들 수 있게 됐지만, 상용 품질로 끌어올리는 건 여전히 사람의 몫이고, 당분간은 그럴 겁니다.