디자인 시스템 없이 AI Agent로 프론트엔드 개발하기 — 실패와 해결의 기록
팀에 프론트엔드 경험자가 없는 상황에서, 공식 디자인 시스템조차 없는 환경에 AI Agent 기반 개발 워크플로우를 직접 설계하며 겪은 문제와 해결책을 기록합니다. Figma MCP, 퍼블리셔 HTML/CSS, Playwright를 엮은 4-Source 컨텍스트 전략과 QA 자동화 파이프라인까지.
참고: 이 글은 2025년 11월부터 2026년 5월까지 실제 프로젝트에서 겪은 경험을 바탕으로 작성되었습니다. 일부 내용은 회사 내부 정보를 제외하고 개념적으로 재구성했습니다.
시작 전에
2025년 11월, AIDC(Ali International Digital Center)와의 통합 광고센터 프로젝트가 시작됐다. 나는 백엔드 엔지니어였고, 갑자기 프론트엔드 설계와 AI 개발 체계 구축까지 맡게 됐다.
팀 상황은 간단했다. 프론트엔드를 경험해본 사람이 거의 없었다. Next.js와 React를 처음 보는 팀원들이 대부분이었다. 그리고 마감은 정해져 있었다.
"AI로 하면 되지 않나요?" 라는 말이 나오기 시작했다. 맞는 말이었다. 문제는 AI를 '어떻게' 쓸 것인가였다.
AI Agent 개발의 전제 조건 — 디자인 시스템
AI Agent로 프론트엔드를 개발하려면 가장 먼저 필요한 것이 있다. 명확한 기준점.
AI에게 "로그인 폼을 만들어줘"라고 하면 만들어주긴 한다. 그런데 그게 우리 서비스의 스타일인가? 버튼 색상은? 폰트 크기는? 스페이싱은?
이 모든 기준을 제공해주는 게 디자인 시스템이다. 컴포넌트 토큰, 색상 팔레트, 타이포그래피 규칙이 명문화되어 있으면, AI는 그걸 기준으로 일관된 UI를 생성할 수 있다.
우리에겐 그게 없었다.
상황
이 프로젝트는 셀러 대면 어드민이었다. 공식 디자인 시스템이 정의된 B2C 서비스가 아니었다. UX 디자이너가 Figma에서 직접 작업하며 화면을 잡아가는 방식으로 진행됐고, 우리가 참고할 컴포넌트 토큰이나 스타일 가이드는 없었다.
처음에는 단순하게 생각했다. Figma를 줬더니 AI가 그냥 못 만들었다.
// 이런 식으로 시도했다
프롬프트: "이 Figma 화면을 Next.js로 구현해줘"
결과: 매번 다른 스타일의 컴포넌트, 불일치하는 spacing, 다른 색상
AI는 기준이 없으면 매번 제멋대로 생성한다. 일관성이 사라진다.
해결책 — 퍼블리셔 HTML/CSS를 비공식 Design Token으로
생각을 바꿨다.
디자인 시스템이 없다면, 대신 퍼블리셔와 디자이너가 합의해서 만들어낸 HTML/CSS 산출물이 있었다. 퍼블리셔들이 디자이너 Figma를 보고 직접 마크업한 결과물이다. 이미 디자인과 합의된, 실제 화면에 가장 가까운 산출물.
이걸 비공식 Design Token으로 쓰기로 했다.
AI에게 "이 HTML/CSS를 Next.js 컴포넌트로 포팅해줘"라고 하면, 기준점이 생기는 것이다.
4-Source 멀티모달 컨텍스트
단순히 HTML/CSS만 주는 것도 부족했다. AI가 의미를 제대로 이해하도록 4가지 소스를 조합했다.
Source 1: Figma MCP 메타데이터
Figma MCP를 통해 화면의 레이아웃 구조와 컴포넌트 의미를 AI에게 전달했다. 스크린샷만으로는 놓치는 **컴포넌트의 의도(semantic)**를 전달하는 역할이다.
예를 들어, 시각적으로는 똑같아 보이는 두 박스가 하나는 Card, 하나는 Modal이라면, Figma 메타데이터가 그걸 구분해준다.
Source 2: 퍼블리셔 HTML/CSS 산출물
핵심 소스. 디자이너 Figma → 퍼블리셔가 마크업한 실제 HTML/CSS 코드다.
AI가 이걸 기준으로 Next.js 컴포넌트를 생성하면, 스타일과 레이아웃이 이미 정해진 기준을 따르게 된다. 임의로 스타일을 만들지 않는다.
<!-- 퍼블리셔 산출물 예시 -->
<div class="ad-card">
<div class="ad-card__header">
<span class="ad-card__title">광고 제목</span>
<span class="ad-card__status status--active">활성</span>
</div>
<div class="ad-card__body">
...
</div>
</div>
// AI가 생성한 Next.js 컴포넌트 (개념)
export function AdCard({ title, status, children }: AdCardProps) {
return (
<div className={styles.adCard}>
<div className={styles.header}>
<span className={styles.title}>{title}</span>
<span className={cn(styles.status, styles[status])}>{statusLabel}</span>
</div>
<div className={styles.body}>{children}</div>
</div>
);
}
Source 3: 퍼블리셔 산출물 스크린샷
HTML/CSS 코드만으로는 AI가 공간적 레이아웃을 완전히 이해하기 어렵다. 실제 렌더링된 스크린샷을 함께 제공해서 시각적 컨텍스트를 보완했다.
멀티모달 AI의 이미지 이해 능력을 활용하는 부분이다.
Source 4: 정제된 기획 문서
UI만 있고 동작이 없으면 반쪽이다. 버튼 클릭 시 무슨 일이 일어나야 하는지, 어떤 데이터를 표시해야 하는지는 기획 문서에서 가져왔다.
단, 원본 기획 문서를 그대로 넣지 않았다. AI에게 불필요한 내용이 많으면 노이즈가 된다. 해당 작업 페이지에 필요한 내용만 정제해서 제공했다.
이 방식의 핵심 통찰
디자인 시스템이 없어도, 합의된 산출물이 있으면 AI는 그것을 기준으로 동작한다.
공식 Design System이냐 아니냐가 중요한 게 아니었다. AI에게 필요한 건 "이게 기준이다"라고 할 수 있는 레퍼런스였고, 퍼블리셔 HTML/CSS가 그 역할을 했다.
실제로 이 방식으로 진행했을 때, 컴포넌트 스타일 불일치 문제가 극적으로 줄었다. AI가 HTML/CSS라는 명확한 기준을 갖게 된 것이다.
다음 문제 — QA를 어떻게 할 것인가
개발 체계를 잡았더니 다음 문제가 왔다. QA다.
이슈가 수십 건씩 쌓인다. 각 이슈마다 재현 조건을 확인하고, 수정하고, 검증하는 사이클이 반복된다. 사람이 하나씩 검증하면 병목이 생긴다.
이것도 자동화하기로 했다.
QA 자동화 파이프라인
Step 1-2: Jira 티켓 파싱 및 이슈 분석
AI가 Jira 티켓의 Description, Comments, 첨부 파일을 읽고 이슈를 분석한다.
중요한 것은 Comments까지 읽는다는 점이다. QA 담당자가 코멘트로 남긴 재현 조건, 추가 발견 이슈, 스크린샷 등이 실제로 중요한 컨텍스트를 담고 있는 경우가 많다.
Step 3: 태스크 분해
이슈 하나가 실제로는 여러 작업으로 나뉠 수 있다. AI가 "이 이슈를 해결하려면 무엇을 해야 하는가"를 분석해서 구체적인 태스크 단위로 분해한다.
Step 4: Evidence 매핑 — 가장 중요한 레이어
이 단계가 핵심이다.
AI가 만들어낸 태스크가 실제로 유효한지 검증하는 과정이다. Jira 티켓에 연결된 Confluence 문서, GitHub 이슈·PR, 관련 코드를 매핑해서 "이 작업을 해야 한다는 근거"를 확인한다.
왜 이게 필요한가?
AI는 이슈를 분석하다 보면 종종 작업 범위를 임의로 넓히거나, 관련 없는 것까지 건드리려 한다. 근거 없는 태스크를 걸러내는 그라운딩(Grounding) 레이어가 없으면, AI가 해야 하는 일과 실제 작업 범위 사이에 괴리가 생긴다.
Evidence가 매핑되지 않는 태스크는 작업 대상에서 제외한다.
Step 5-6: 작업 및 Playwright E2E 자동화
검증된 태스크만 실제 작업으로 들어간다. 수정 완료 후 Playwright로 E2E 테스트를 실행하는데, 단순 테스트 통과 여부뿐 아니라 스크린샷과 Video Recording까지 수행한다.
// Playwright 테스트 예시 (개념 코드)
test('광고 그룹 상태 변경 후 반영 확인', async ({ page }) => {
await page.goto('/ad-groups');
await page.screenshot({ path: 'screenshots/ad-groups-before.png' });
await page.click('[data-testid="status-toggle"]');
await page.waitForResponse('/api/ad-groups/*');
await page.screenshot({ path: 'screenshots/ad-groups-after.png' });
await expect(page.locator('[data-testid="status-badge"]')).toHaveText('일시정지');
});
Step 7-8: 대시보드 1차 + PR Review 2차
50건의 이슈가 있으면, 대시보드에서 50건의 완료 스크린샷과 영상을 한 번에 확인한다. 사람이 50건을 하나씩 재현하는 게 아니라, 결과물만 확인하는 방식이다.
이후 PR Review 단계에서 사람이 2차 검증을 수행한다.
겪은 문제들
문제 1: 퍼블리셔 산출물이 바뀌면?
HTML/CSS 산출물을 기준점으로 쓰면, 퍼블리셔가 수정할 때마다 AI가 참조하는 기준이 달라진다. 이걸 AI가 자동으로 감지하지 못하면, 오래된 마크업 기준으로 계속 작업하게 된다.
현재는 수동으로 산출물을 교체하는 방식을 쓰고 있다. 이상적으로는 변경 감지 훅이나 버전 관리가 있으면 좋겠다.
문제 2: AI가 생성한 E2E 테스트의 품질
AI가 Playwright 테스트를 생성할 때, "중요한 유저 플로우를 실제로 커버하는가"를 검증하기 어렵다. 테스트 코드가 많아 보여도 핵심 플로우를 빠뜨릴 수 있다.
Coverage Report 연동이 있으면 이걸 측정할 수 있는데, 아직 적용하지 못했다.
문제 3: 대시보드 검증의 한계
현재 대시보드는 "이슈가 완료됐는가"를 확인하는 수준이다. 스크린샷을 Expected 결과와 픽셀 단위로 비교하는 Visual Regression이 없어서, 완료 여부는 확인하지만 "올바르게 완료됐는가"는 사람이 판단해야 한다.
돌아보며
이 워크플로우를 설계하고 6개월간 사용하면서 가장 크게 배운 것은 두 가지다.
첫째, AI에게 필요한 건 "기준"이다.
디자인 시스템이 없어서 AI를 못 쓰는 게 아니다. 합의된 레퍼런스가 있으면, 그것이 어떤 형태든 AI의 기준점이 된다. 퍼블리셔 HTML/CSS가 그 역할을 충분히 했다.
둘째, AI의 환각을 막는 건 "그라운딩"이다.
Evidence 매핑 레이어 없이 AI에게 이슈를 해결하라고 하면, 관련 없는 것까지 건드리거나 임의로 범위를 넓힌다. Jira·Confluence·GitHub에 실제 근거가 있는 태스크만 작업하도록 제한하는 것이 AI 자동화의 신뢰도를 결정했다.
아직 완성된 시스템은 아니다. Visual Regression, 산출물 변경 동기화, 테스트 커버리지 측정 — 개선해야 할 것들이 남아 있다. 이 과정을 계속 기록해 나갈 생각이다.