바이브코딩 디자인 시스템, 프론트엔드 하네스 엔지니어링
AI 프론트엔드 하네스 - 일관성을 잡는 세 가지 방법
AI로 기능은 금방 만드는데, ui가 매번 바뀌는 문제를 어떻게 해결할 수 있을까요.
저의 의견 : 컴포넌트 재사용에 집착하는 순간, '본질'에서 멀어진다. 디자인 토큰으로 스타일만 통일하자.
저는 찐 미대 출신이고, UIUX 및 브랜드 경험 디자인을 15년 동안 해왔어요. 2025년 2월부터 바이브코딩을 시작했는데, 꽤 일찍 시작한 편이에요. 지금의 바이브코딩 씬과 작년은 판도가 정말 많이 달랐어요. 개발을 공부하지 않으면 코드 에러가 나서 빌드가 안 됐었죠. 반강제적으로 에러가 날 때마다, 혹은 ai에게 적절한 지시를 내리기 위해 필요한 지식 위주로 개발을 공부했어요. (GPT와 제미나이 선생님) 생각보다 적성에 맞고, 생각보다 너무 재밌었습니다. 실제로 개발자로 전향을 했다고 봐야죠. 디자이너도 개발을 할 수 있나? 프로토타이핑 수준을 넘어서서? 저는 충분히 가능하다고 생각해요. AI가 코딩을 대신해주는 시대잖아요. "막혔을 때 어떻게든 풀어내려는 끈기"가 있다면 개발자가 될 수 있는 자질이 있다고 봅니다. ㅎㅎ 저도 초기에는 3일 동안 같은 에러랑 싸웠는데, 결국 풀고 나니까 그게 곧 제 자산이 되더라고요.여하튼, 일찍 시작했기 때문에 AI를 이렇게도 다뤄보고 저렇게도 다뤄봤어요. 프롬프트 엔지니어링 스킬셋을 정말 많이 실험해 봤고, 2026년 멀티 에이전트가 등장하면서 바이브코딩으로 프론트엔드를 어떻게 제어해야 하는지 어느 정도 답을 찾아낸 것 같아요.
AI 시대에 프론트엔드가 병목인 이유
AI가 코딩을 해주는 시대가 됐어요. 근데 지금 우리가 만나는 문제가 뭔가요.
사람과 가장 닿아 있는 프론트엔드가 AI 시대에 가장 큰 병목이에요. 크게 두 가지 문제가 있는데요. 하나는 디자인을 일관되게 하지 못한다는 것. 또 하나는 AI가 뽑아준 디자인이 좋은지 아닌지 잘 모르겠다는 것.
이 글에서는 전자에 대해서만 이야기할게요. 디자인의 의미가 생각보다 훨씬 넓고 기획적인 영역도 포함하거든요. 주제를 좁혀서, 일관된 디자인을 뽑아내는 법을 정리해 볼게요.
AI 프론트엔드 일관성을 잡는 세 가지 방법
크게 세 가지 방법이 있어요.
1. AI에게 맡기기 2. 인간 하네스 3. 멀티 에이전트 활용
하네스가 뭔지 모르시는 분들을 위해 간단히 설명하면, AI에게 제약을 줘서 일관된 품질의 코드를 생성하게 하는 방법이에요.
방법 1. AI에게 맡기기 — 랜딩페이지, 가벼운 웹사이트
랜딩페이지나 가벼운 웹사이트를 만들 때는 AI가 주도적으로 일을 할 수 있게 시켜요. 최대한 제약을 없애는 게 포인트예요. 요즘 유행하는 디자인.md 파일을 제공하고, CSS 코드를 추출하게 해서 이 두 가지만 가지고 일관되게 만드는 방법이에요.
방법 2. 인간 하네스 — 반복 개선이 필요한 앱
제가 똑같은 앱을 40번 개선하면서 배포할 수 있었던 건, 아주 구체적으로 스타일과 컴포넌트를 지시하고 재사용했기 때문이에요. 이 방법은 컴포넌트와 개발 아키텍처에 대한 이해도가 있어야 해서, MVP를 세 번 정도는 협업하면서 만들어봤다 하는 분들만 가능한 방법일 거예요.
방법 3. 에이전트 활용 — 멀티 에이전트 시대의 접근법
2026년부터 판도가 완전히 바뀌었어요. 멀티 에이전트 시대가 됐죠. 에이전트들을 내 직원처럼 만들어서, 디자인팀과 개발팀이 협력해서 일하는 구조를 세팅하는 방법이에요.
이 방법에 대해서는 아래에서 더 자세하게 다룰게요.
디자인 시스템을 제대로 이해하기 스타일 vs 컴포넌트
디자인 라이브러리라고도 하는 디자인 시스템은 크게 디자인 스타일과 컴포넌트 두 가지로 나눌 수 있어요.
디자인 스타일은 폰트, 컬러, 간격, 곡률 등 시각적으로 꾸며주는 값들을 말해요. 여기서 정의된 값들이 CSS 코드로 생성돼요.
컴포넌트는 버튼, 인풋창, 리스트, 아이콘 버튼 등 화면 안에서 유저의 액션이 필요한 쪼개진 조각들이에요. 피그마가 딱 이런 용도의 툴이고요.
이 두 가지를 굳이 분리해서 생각해야 하는 이유가 있어요.
AI는 스타일은 재사용을 꽤 잘하지만, 컴포넌트는 재사용하지 않아요.
AI는 컴포넌트를 재사용하지 않는다그리고 그게 사실은 맞다
이게 이 글의 핵심이에요.
AI는 컴포넌트를 재사용하지 않는 방식이 더 자연스러워요. 기존 컴포넌트 코드를 탐색하지 않아도 되니까 토큰이 절약되고, 독립적인 컴포넌트를 너무 빨리 그려버리기 때문에 오히려 더 빠른 실험을 할 수 있어요. 리팩토링은 단계별로 진행해도 크게 문제 될 게 없어요.
사람 개발 방식은 마스터 컴포넌트를 미리 만들어두고 복제해서 사용하는데요. shadcn/ui가 이 마스터 컴포넌트 라이브러리예요. 사람이 할 때는 이렇게 할 수밖에 없었죠. 마스터 하나만 바꿔주면 인스턴스들이 자동으로 수정되니까요. (tmi. 제가 개발을 시작하게 된 이유가 내가 디자인한 컴포넌트 시스템이 코드로는 어떻게 동작하나. 이게 미치도록 궁금해서였네요 ㅎㅎㅎ)
여하튼 AI에게는 이 컴포넌트 재사용 방식이 상당히 병목이에요. 매번 모든 컴포넌트를 새로 그리는데, 이게 엄청 빠르거든요. "마스터 컴포넌트를 찾아서 이걸 사용해줘"라고 하는 게 오히려 더 피곤한 일인 거예요. 참고로 mvp 단계에서는 집착하지 않아도 된다는 이야기고, 본격적으로 팀 단위로 스케일업 할 때는 전통적인 개발 방식으로 레이어를 쌓아 나가야 합니다! 그리고 다른 mvp로 빠르게 찍어내고 싶을 때도 컴포넌트 재사용 개발 방식은 여전히 유용해요.
디자인 토큰 CSS비디자이너도 바로 쓸 수 있는 스타일 세팅
디자인 스타일은 최대한 간결하게 정의하는 게 핵심이에요. 선택지가 많을수록 AI가 선택을 못하거든요.
컬러
프라이머리 컬러 딱 하나만 지정하세요. 디자이너가 아니라면 보조색은 만들지 마세요. 그레이스케일, 호버 색깔 지정, 다 불필요해요. 프라이머리 기준만 주어지면 나머지는 AI가 알아서 해줘요.
폰트
프리텐다드를 쓰라고 하세요. 볼드, 미디움, 라이트 3개 볼륨만 사용해요. 폰트 볼륨을 너무 많이 쓰면 SEO에도 좋지 않은 영향을 미쳐요.
아이콘
Lucide를 쓰라고 하세요. 가장 무난하고 촌스럽지 않아요.
라디우스
박스나 버튼에 사용될 라디우스 값을 지정하세요. 귀여운 느낌은 32px 이상, 일반적으로 24~16px을 추천해요.
AI 냄새 제거
"그라디언트를 최소화 해줘"라거나 "플랫한 미니멀 디자인으로 해줘"라고 명령해 보세요. 아니면 심플한 레퍼런스 사이트를 지정해서 "이 스타일의 디자인 md 파일 만들어줘, CSS 파일도 같이 만들어줘"라고 해보세요.
라이트 모드 vs 다크 모드
라이트 모드보다는 다크 모드 기준으로 작업하세요. 다크 모드는 밀도가 이미 채워져 있어서 퀄리티가 조금 더 높아 보여요.
디자인.md보다 전역 CSS가 중요하다
디자인.md로 만들어달라고 요청해도 되는데, 문서화에 너무 얽매이지 않는 게 좋아요. 전역 CSS 파일이 훨씬 중요해요. CSS 파일은 참고 자료가 아니라 코드 파일이기 때문에, md 파일보다 생성된 코드를 훨씬 더 잘 따라요.
MVP를 많이 만들어본 철학으로 정리하면:
컴포넌트를 재사용하려고 너무 노력하지 마세요. 구조 짜느라 매몰 비용 낭비하지 마세요.
그럼에도 더 통일됐으면 한다면, "버튼 컴포넌트를 재사용할 수 있게 해줘"라고 명령해 보세요. 같은 버튼이 다른 페이지 3곳에 들어갈 때 정리해 보는 걸 추천해요.
컴포넌트 등록도 간단해요. "이 버튼은 컴포넌트로 등록해줘"라고 명령하고, 다음부터는 이 버튼을 재사용하라고 에이전트에게 명확히 전달하면 돼요. 이렇게 대충 말해도 ai가 알아들으니 참 신기하죠 ㅎㅎ.
UI 디자인 에이전트와개발 에이전트의 역할 분리
마지막으로 에이전트를 활용한 컴포넌트 재사용 방식을 공유할게요.
결론만 말하면, 코드를 생성하기 전에 이미 만들어진 코드가 있는지 검색하게 하라는 것이에요.
"컴포넌트를 재사용해줘"라는 방식은 통하지 않아요. 그래서 생각한 아이디어가 검색 의무화 방식이에요. 컴포넌트를 그리기 전에, 비슷한 컴포넌트가 있는지 반드시 검색하게 한 후, 사용자의 허락을 받고 나서 UI를 그리게 하는 거예요.
UI 디자인 에이전트 프로세스
이건 제가 지정한 프로세스가 아니에요. 클로드가 제안해 준 방식이에요.
디자인 에이전트 vs 개발 에이전트 — 명확한 경계
디자인 에이전트가 UI를 그리면 이어받아서 개발 에이전트가 나머지를 담당해요. 파이프라인에서 경계가 명확하게 분리되어 있어요.
핵심 원칙은 간단해요. Design은 "뷰만 작업, API/데이터/훅 건드리지 않음". Developer는 "UI 코드 작성, 컴포넌트 .tsx 직접 수정 X".
마지막으로, QA 에이전트를 만들어줍니다.
작업하다보면 프라이머리 컬러로 적용해줘.. 라고 해도 어느 순간 하드 코딩이 박혀있어요. (부글부글)
최종 커밋하기 전, 큐에이 에이전트를 한 번 돌려줘요. 코드 리뷰 에이전트라고 해도 좋구요. 생각보다 잘 찾아주는데요, 이건 직접 사용을 해보셔야 얼마나 기똥찬지 아실 수 있을거에요.
마무리
요즘 Claude 디자인도 나오고, 디자인 md 파일도 나오고. AI로 디자인을 잘 뽑는 것에 대한 관심이 매우 높아진 것 같아요. 이 시대에는 개발자들도 디자인에 관심을 가지는 시대고, 반대로 디자이너나 기획자도 개발을 할 수 있는 재밌는 시대예요. 그런데 이게 조금 더 긍정적인 방향으로 흘러가면 좋겠다는 생각이 있어요.
우리가 AI를 위해 일하고 있는가. 사람을 위한 제품을 만들고 있는가.
기획이나 디자인, 개발처럼 파편화된 업무 베이스로 일을 하는 게 아니라, 문제 기반으로 일을 하게 되고, 그 문제를 해결해 나간다는 효용감을 함께 느낄 수 있는 시대가 됐다고 믿어요.
이 글이 도움이 됐다면, 어떤 방법을 쓰고 계신지 댓글로 나눠주세요. 더 다양한 실험 결과가 쌓일수록 모두에게 도움이 될 것 같아요 :)