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