코딩 에이전트의 디자인은 왜 비슷비슷한가 — 디자인 스택을 고르기까지의 조사와 결정#

2026-07-03

Claude Code 같은 코딩 에이전트에게 웹 서비스 디자인을 맡기면 웬만큼 괜찮은 결과물이 나옵니다. 그런데 뭔가 아쉽습니다. 어디서 본 듯 비슷비슷하고, 디테일이 다소 어설픕니다. 필자는 진행 중인 프로젝트의 디자인 시안을 뽑으면서 이 아쉬움을 해결할 방법을 찾아보았고, 스킬·MCP·하네스 지침을 하나씩 조사하여 최종 디자인 스택을 결정했습니다. 이 글은 그 조사와 결정의 과정을 정리한 것입니다.

근본 원인: 능력 문제가 아니라 기본값 문제#

조사하면서 가장 먼저 확인한 것은, 이 현상이 에이전트의 능력 부족 때문이 아니라는 점입니다. LLM(Large Language Model, 대규모 언어 모델)은 방향 지시가 없으면 가장 확률 높은 답을 냅니다. “괜찮은 버튼"의 최빈값은 Inter 폰트, 보라색 그라데이션, 카드 그리드, 흰 배경입니다. 모든 AI 생성 디자인이 닮아 보이는 이유가 여기에 있습니다.

“더 예쁘게 해줘” 같은 모호한 요청이 통하지 않는 이유도 같습니다. 모호한 프롬프트는 모호한 평균값을 다시 불러올 뿐입니다. 해결책은 능력을 더하는 것이 아니라 모델이 기본값에서 의도적으로 멀어지도록 조종하는 것입니다. 모델은 이미 CSS를 쓸 줄 압니다. 다만 이 프로젝트, 이 순간에 어떤 CSS를 써야 하는지 모를 뿐입니다.

이 관점에서 보면 도구들은 세 계층으로 나뉩니다.

스킬이 “어떻게 생각할지(how it thinks)“를 다룬다면, MCP(Model Context Protocol, 에이전트에 외부 도구를 연결하는 표준)는 “무엇을 할 수 있는지(what it can do)“를 다룹니다. 층위가 다르므로 원칙적으로는 경쟁이 아니라 상호보완 관계입니다. 다만 뒤에서 보듯, 예외가 있습니다.

조사한 도구들#

frontend-design — 안티 기본값 철학#

Anthropic 공식 스킬입니다. 놀랍게도 수십 줄에 불과한 짧은 문서인데, 컴포넌트나 코드 조각을 주는 것이 아니라 태도와 절차를 주입합니다.

핵심은 두 가지입니다. 첫째, AI 디자인이 쏠리는 클리셰를 이름으로 지목해 금지합니다. 크림색 배경 + 세리프 + 테라코타, 검은 배경 + 형광 강조색, 신문식 레이아웃 — 이 세 가지는 “선택이 아니라 기본값"이라고 못 박습니다. 둘째, 코드를 짜기 전에 2단계 절차를 강제합니다. 먼저 색 4~6개, 역할별 폰트, 레이아웃, 그리고 이 페이지를 기억하게 할 단 하나의 시그니처 요소로 이루어진 토큰 시스템을 만들고, 그 계획이 “비슷한 요청이면 나도 여기 도달했을까"라는 자기비평을 통과해야만 코드 작성을 시작합니다.

절제에 대한 지침도 인상적입니다. 대담함은 시그니처 한 곳에만 쓰고 나머지는 조용하게 유지하라며, “외출 전 거울을 보고 액세서리 하나를 빼라"는 샤넬의 조언을 인용합니다.

Superdesign — 좋은 개념, 그러나 외부 의존#

Superdesign은 스킬 형태로 설치되지만 실체는 외부 SaaS(Software as a Service, 클라우드 구독형 서비스)의 프론트엔드입니다. CLI 설치와 로그인이 필요하고, 저장소의 컴포넌트 소스를 자사 서비스로 전송하여 무한 캔버스에서 시안 변형을 만들어 줍니다. 무료 티어가 있고 유료는 월 20달러 정액입니다.

기능은 흥미로웠지만 필자는 보류했습니다. 지금 단계에서 외부 서비스에 의존적인 상태를 만들고 싶지 않았기 때문입니다. 추후 서비스가 확장되면서 더 나은 디자인이 필요해지는 시점에 다시 고려해 볼 생각입니다. 다만 Superdesign이 밀고 있는 DESIGN.md라는 개념은 도구와 무관하게 채택할 가치가 있었습니다. 이에 대해서는 뒤에서 다시 다룹니다.

UI/UX Pro Max — 디자인 백과사전#

UI/UX Pro Max는 커뮤니티에서 가장 인기 있는 디자인 스킬(약 9.8만 스타)로, 한마디로 디자인 백과사전 + 검색·추천 엔진입니다. 67개 이상의 UI 스타일, 161개 색 팔레트, 57개 폰트 페어링, 161개 업종별 추론 규칙을 내장하고, “뷰티 스파 랜딩페이지"처럼 제품 유형을 말하면 스타일 + 색 + 폰트 + 피해야 할 안티패턴 + 배포 전 체크리스트를 한 세트로 추천합니다.

중요한 점은 이것이 로컬에서 동작하는 MIT 라이선스 오픈소스라는 것입니다. 계정도, 로그인도, 소스 외부 전송도 없습니다. Superdesign을 보류하게 만든 기준에 걸리지 않습니다.

frontend-design이 철학(정성적)이라면 UI/UX Pro Max는 데이터베이스(정량적)입니다. 두 스킬을 직접 비교한 글들의 보편적 결론은 “절대적 우열은 없고 업종에 따라 갈리니, 본인 케이스로 둘 다 돌려보고 고르라"였습니다. 한 비교 실험에서는 SaaS 랜딩페이지와 온천 료칸은 frontend-design이, 미슐랭 스시집은 “사진을 빼는 대담한 덜어내기"를 해낸 UI/UX Pro Max가 우세했습니다. 덧셈으로 성공하는 업종과 뺄셈으로 성공하는 업종이 다르다는 관찰입니다.

interface-design — 제품 UI 전용, 기억을 내장한 스킬#

interface-design은 앞의 둘과 타깃이 다릅니다. 대시보드·앱·관리자 패널 같은 제품 UI 전용이며, README에 “마케팅 사이트용이 아니다"라고 명시되어 있습니다. 슬로건은 Craft(완성도) · Memory(기억) · Consistency(일관성)입니다.

특히 주목할 부분은 Memory입니다. 디자인 결정(간격·색·버튼 높이 등)을 .interface-design/system.md 파일에 저장하고 다음 세션에 자동으로 다시 불러옵니다. 버튼 높이가 36px, 38px, 40px로 세션마다 흔들리는 문제를 도구 차원에서 막아주는 것입니다.

MCP 서버들 — 대부분 탈락#

MCP 쪽도 후보를 하나씩 검토했지만, 결론부터 말하면 필자의 상황에서는 전부 탈락했습니다.

• 21st.dev Magic MCP: 자연어로 UI 컴포넌트를 즉석 생성해 주는 “에디터 안의 v0"입니다. 그러나 API 키가 필요한 외부 SaaS이고, 큐레이션된 카탈로그에서 “무난하게 잘 만든” 컴포넌트를 뽑아주는 방향이라 frontend-design의 안티 기본값 철학과 정면으로 어긋납니다. 보편적 디자인을 원하는 것이 아니었으므로 탈락.
• Figma Dev Mode MCP: Figma에 이미 만들어둔 디자인을 코드로 옮겨주는 공식 “번역기"입니다. 취향을 만들지 않고 옮기기만 하므로 충돌은 없지만, 필자는 Figma를 사용하지 않아 번역할 원본 자체가 없습니다. 지금은 붙일 자리가 없어 보류.
• shadcn 스튜디오: 상용 shadcn/ui 키트 + 변환 도구입니다. shadcn 특유의 look으로 수렴하는 성격이라 Magic과 같은 이유로 탈락.

여기서 한 가지 정리된 인식이 있습니다. MCP와 스킬은 원칙적으로 상호보완이지만, 컴포넌트 생성형 MCP는 취향 층에서 스킬과 경합할 수 있습니다. 레퍼런스·실행 계열 MCP(브라우저 자동화 등)는 순수 보완이고, 생성 계열은 그렇지 않습니다. 결국 디자인 능력 강화를 위해 새로 추가할 MCP는 없다는 결론에 도달했습니다. 필요한 실행·검증 도구(chrome-devtools MCP)는 이미 갖추고 있었기 때문입니다.

개념 정리: 발산과 수렴, 그리고 하네스#

조사 과정에서 가장 값진 수확은 도구 목록이 아니라 개념 프레임이었습니다.

DESIGN.md는 시안 생성기와 경쟁하는 도구가 아닙니다. 색·타이포·간격·컴포넌트 규칙·금지 목록을 마크다운 한 파일에 고정해 두는 컨벤션인데, 그 역할은 시안들 중 하나를 채택한 뒤 이어지는 디자인 작업들이 엇나가지 않게 잡아주는 하네스입니다. 정리하면 이렇습니다.

• 생성기(frontend-design, UI/UX Pro Max)는 발산 도구입니다. 방향을 만들어냅니다. 그러나 상태가 없어서(stateless), 매번 새로 굴리면 결과가 조금씩 달라지고, “우리가 이걸로 결정했다"는 사실을 기억하지 못합니다.
• 하네스(DESIGN.md, system.md)는 수렴 도구입니다. 채택된 방향을 동결하고, 5번째, 20번째 페이지에서도 흐트러지지 않게 강제합니다.

비유하자면 생성기는 브랜드의 아트 디렉션을 정하는 디렉터이고, DESIGN.md는 그 디렉터가 서명한 브랜드 가이드라인 문서입니다. 이후 합류하는 모든 작업자(다음 세션의 에이전트)는 그 문서를 보고 같은 방향으로 그립니다.

하나 주의할 함정도 발견했습니다. interface-design의 system.md는 그 스킬 전용 메커니즘이라 다른 스킬은 그 파일의 존재를 모릅니다. 일관성 지침을 한 파일에 몰아넣고 “일임"하려면, 모든 스킬이 실제로 읽는 위치(예: 항상 컨텍스트에 로드되는 CLAUDE.md가 참조하는 루트의 DESIGN.md)에 두어야 합니다. 브랜드 공통 층은 DESIGN.md에, 제품 UI 전용 디테일은 system.md에 두는 2층 구조가 안전합니다.

최종 결정: 페이지 성격별 라우팅#

시안을 직접 뽑아 비교한 끝에 내린 결정은 다음과 같습니다.

두 생성기를 화면 성격별로 나눠 쓰는 방식은, 두 스킬이 같은 화면에서 부딪히지 않게 하여 취향 충돌을 애초에 회피합니다. 대신 새로운 위험이 생깁니다. 콘솔 화면과 랜딩 페이지가 서로 다른 제품처럼 보일 위험입니다. 그래서 생성기를 두 개로 나눈 순간 DESIGN.md는 선택이 아니라 필수가 되었습니다. 두 생성기의 산출물이 하나의 제품으로 느껴지게 하는 유일한 통일 지점이기 때문입니다.

맺으며: 도구 추가보다 하네스 설계#

이번 조사에서 얻은 결론을 한 문장으로 줄이면 이렇습니다. 코딩 에이전트의 디자인 품질은 도구를 더 얹어서가 아니라, 기본값에서 멀어지게 하는 지침과 결정을 기억하게 하는 하네스로 올라간다.

그리고 마지막으로 하나 더. 도구가 설치되어 있는 것과 그 도구가 루프에 물려 있는 것은 다릅니다. chrome-devtools MCP가 설정되어 있어도, “화면을 만든 뒤 스크린샷을 찍어 자기 결과를 보고 DESIGN.md 기준으로 고쳐라"는 지침이 없으면 에이전트는 여전히 눈을 감고 만듭니다. frontend-design 스킬의 표현을 빌리면, “그림 한 장이 토큰 1000개의 값어치"입니다. 배선까지 마쳐야 어설픔이 잡힙니다.