프론트엔드 개발을 에이전트에게 맡겨도 될까

디자이너가 Figma 링크를 하나 던진다. "이 화면 구현해주세요."
개발자는 링크를 열어 컴포넌트를 확인하고, 색상 코드를 복사하고, 크기를 재고, 코드를 쓴다. 이 과정이 변경이 생길 때마다 반복된다. 앞으로 프론트엔드 개발에서, 에이전트가 이것을 대신 수행할 수 있을까라는 질문에서 이 연구를 시작했다.

DESIGN.md라는 시도

구글이 DESIGN.md라는 포맷을 오픈소스로 공개했다. 세 가지 원칙이 핵심이다.

• self-contained — 이 파일 하나만 보면 모든 걸 파악할 수 있게.
• plain-text — 단순 텍스트로.
• across AI agents and tools — 어떤 에이전트든 동일하게 활용할 수 있게.

이 포맷이 나온 맥락이 있다. 디자이너는 Figma를 업데이트하고, 프론트 개발자는 코드를 업데이트하는데, 유지보수를 하며, 시간이 흐르면 둘이 멀어진다. 피그마 파일과 실제 코드의 디자인이 어느 순간부터 달라지는 것, 그래서 디자인 시스템이 어렵고, 프론트 개발자라면 누구나 겪어봤을 것이다. DESIGN.md는 그 사이의 단일 원천이 되겠다는 시도이다. 사람도 읽고, 에이전트도 읽는.

내용은 YAML과 Markdown의 혼합이다. 색상 토큰, 타이포그래피, 컴포넌트 명세가 담긴다. 형태는 백엔드의 AGENTS.md와 닮아있다. 개별 디자인 화면의 설명이 아니라 디자인 시스템을 담는다는 점이 중요하다. 특정 화면이 아닌, 버튼은 어떻게 생겼고, 색상은 어떤 토큰을 쓰고, 타이포그래피 스케일은 어떤지.

DESIGN.md 생성

Claude Code에 Figma MCP를 붙이는 것부터 시작했다. 준비물은 두 가지다. Claude Code 환경과, 피그마를 띄워놓은 상태. MCP는 피그마가 실행 중이어야 동작한다.

프롬프트는 단순했다. Google의 DESIGN.md 원칙에 따라 Figma 파일에서 DESIGN.md를 생성하라는 지시 하나. 회사 제품 키오스크의 디자인 시스템 파일과 컴포넌트 파일 링크를 함께 넘겼다.

결과는 기대 이상이었다. 에이전트는 Figma 노드를 순회하며 색상 토큰, 버튼 컴포넌트 명세, 타이포그래피 스케일을 뽑아냈다. 사람이 직접 작성해도 이 정도면 충분하다 싶은 수준의 문서가 나왔다. YAML 헤더에 토큰 값이 정리되고, Markdown 본문에 컴포넌트 사용 지침이 붙는 형태로.

Figma 화면을 HTML로

DESIGN.md가 생겼으니, 이걸 기반으로 실제 화면을 구현하게 했다. Figma에서 구현할 화면 영역을 지정하고, 에이전트에게 HTML로 만들어달라고 지시했다.

에이전트가 구현한 결과는 이렇다.

Figma 노드를 파싱해서 HTML로 변환했다. 에이전트는 지시한 대로만 구현한다. 페이지 사이즈가 어떻게 되는지, 우리 서비스가 반응형인지, Portrait과 Landscape를 모두 대응한다는 것은 모른 채, 결과는 초안으로 쓸 수 있는 수준이었다. 손코딩으로 다듬는 기반으로는 약간의 의미가 있었다.

반응형을 추가하면?

우리 제품은 고정 사이즈가 아닌 반응형이다. 하나의 리소스로 Portrait과 Landscape를 모두 대응한다. 이 내용을 추가로 지시했다.

반응형으로 이루어져야 한다. 고정된 스크린 사이즈가 아니다. portrait에서는 상단 이미지 영역이 없어져야 한다. landscape에서는 location-bar 하위만 보여야 한다. 아이콘 크기, 이미지 비율이 맞지 않다.

두 가지 방향을 하나의 프롬프트에 담으니 오히려 이상한 결과가 나왔다. 에이전트는 두 맥락 사이에서 절충하려 했고, 그 절충이 좋은 방향이 아니었다. 새 세션에서 처음부터 다시 지시하는 쪽이 낫겠다는 판단이 섰다.

Figma 없이 새 화면

방향을 바꿔서 완전히 새로운 화면을 지시해봤다. 이번에는 Figma 링크 세 개를 함께 넘겼다. 차량 조회 화면, 번호 입력 후 상태, 차량을 찾지 못한 상태.

그런데 Figma MCP에 rate limit이 걸렸다. Claude Code 토큰도 30% 넘게 소진된 상태였다. 에이전트는 Figma 디자인 컨텍스트를 가져오지 못하자, DESIGN.md 토큰만 가지고 직접 생성을 시작했다.

어쨌든 결과물은 나왔다. 그걸 보고 방향을 다시 생각했다. Figma 없이, DESIGN.md만으로 화면을 지시할 수 있지 않을까.

DESIGN.md만으로

이번에는 Figma 링크를 아예 넣지 않았다. DESIGN.md를 참조하게 하고, 화면 구조를 자연어로 설명했다. 상단 이미지 영역, 안내 문구, 4자리 입력 박스, 숫자 키패드, 하단 기능 버튼, 각 영역의 역할과 동작을 텍스트로 풀어서 넘겼다.

결과는 예상보다 나았다. Figma를 직접 파싱하는 것보다, 사람이 의도를 명확하게 전달하는 방식이 더 잘 됐다. Figma는 디자이너의 레이아웃 도구이지, 에이전트에게 맥락을 전달하는 도구가 아니기 때문이다.

"불가능"이 아닌, "아직"의 문제

지금 시점에서 결론을 내리면 "도입 불가능"이 된다. 구현해야 할 디자인이 Figma에 고정되어 있을 때, 에이전트가 충실하게 재현하려면 여전히 사람의 개입이 많이 필요하다. 디자이너가 거의 개입하지 않는 어드민 같은 케이스라면 부분 도입이 가능하고, 컴포넌트 레벨이라면 충분히 쓸 만하다.

그러나 코딩 에이전트도 그렇게 발전했다. Zero-shot 프롬프트에서 시작해서, 도구를 주고, MCP로 빈 공백을 채우고, 피드백 루프를 만들어 그 루프를 돌리는 방식으로 진화했다.

백엔드의 코딩 루프는 이미 작동한다. AGENTS.md라는 가이드라인 아래, 설계 문서로 스키마와 API를 정의하고, 에이전트가 개발하고, 테스트케이스로 검증하고, 결과를 확인한 뒤 다시 루프를 돈다.

프론트엔드에도 같은 구조를 적용할 수 있다. DESIGN.md가 AGENTS.md 역할을 한다. Figma 캡처 이미지와 반응형 조건 같은 세부 지침이 설계 산출물이 된다. 에이전트가 개발하고, headless browser로 실제 렌더링을 캡처해 사람이나 에이전트가 스코어링한다. 가장 잘된 결과에 가중치를 줘서 다시 루프를 돌린다면? 가능하지 않을까.

지금은 "에이전트에게 시켰더니 이 정도더라"의 단계이다. 루프가 생기면 "에이전트가 목표를 달성할 때까지 스스로 반복한다"가 된다.

좀 더 흐름을 지켜봐야겠다.