좀비 UI 처방 넷 중 둘만 가져가겠습니다

좀비 UI는 프롬프트가 아니라 디자인 시스템과 편집자가 막는다

Stripe 디자인 총괄 케이티 딜이 털어놓은 시행착오 하나가 이 강연의 전부보다 실용적입니다. 디자인 문서를 읽는 MCP를 AI에 붙였더니 기대에 못 미쳤다는 것. 충분히 구체적이지 않았고, 세 사람이 같은 프롬프트를 넣으면 세 가지 다른 결과가 나왔답니다. 그래서 지금 Stripe는 디자인 시스템 위에 CLI를 만들어 씁니다.

딜은 Lenny and Friends Summit 2026에서 AI로 누구나 화면을 빨리 만드는 지금을 2차대전 뒤 미국의 건축 붐에 빗댔습니다. 모더니즘 양식이 이유 없이 복제되며 무엇과도 구별되지 않는 '좀비 건물'이 도시를 채웠듯, 지금은 맥락도 브랜드도 없는 좀비 UI가 쏟아진다는 거죠. 처방은 넷입니다. 기준을 먼저 세운다, 기준을 디자인 시스템에 심는다, '다 만들었다'와 '좋다'를 가르는 편집자를 둔다, AI로 아낀 비용을 이상한 시도에 쓴다. 저는 이 중 둘은 내일 바로 가져가고, 하나는 조건을 붙이고, 하나는 흔한 얘기로 넘기겠습니다.

가져갈 하나 — 시스템을 읽히지 말고 쓰게 만든다

좀비 UI가 나오는 첫 경로를 딜은 '가장 흔한 답'으로 설명합니다. LLM은 확률이 가장 높은 답을 잘 내니, 유행했거나 잘 먹혔던 걸 내놓고 내 브랜드에만 맞는 답에는 약하다는 거예요. 강연에서 보여 준 예가 소프트웨어 회사처럼 생긴 한식 바비큐 식당 사이트입니다.

소프트웨어 회사처럼 보이는 한식 바비큐 식당 사이트

멀쩡하지만 식당다운 구석이 하나도 없습니다. 이걸 막으려고 많은 팀이 하는 일이 디자인 가이드를 문서로 정리해 AI에 먹이는 겁니다. MCP든 컨텍스트 파일이든 방식은 다르지만 결국 '읽게' 하는 접근이죠. Stripe의 실패담은 이 접근의 한계를 정확히 보여 줍니다. 문서는 해석의 여지를 남기고, 해석은 사람마다 달라지고, 대화가 길어질수록 AI는 앞에서 읽은 내용을 흐리게 다룹니다.

처음엔 MCP, 지금은 디자인 시스템 위의 CLI

CLI는 이 문제를 다르게 풉니다. 만드는 사람이 일하는 바로 그 자리에서, 필요한 문서를 필요한 때에만 넣어 주고, AI가 훨씬 말을 잘 듣게 만드는 틀 역할을 한다는 설명이에요. 제가 보기에 핵심은 '도구를 통해서만 시스템에 손대게 한다'는 데 있습니다. 개발자에게 익숙한 비유로 바꾸면, 코딩 컨벤션 문서를 위키에 올려 두는 것과 린터·포매터를 CI에 거는 것의 차이입니다. 앞의 것은 읽은 사람의 성실함에 기대고, 뒤의 것은 규칙을 어길 길 자체를 줄입니다.

Stripe가 시스템에 부품만이 아니라 화면 템플릿과 사용 흐름까지 넣었다는 대목도 같은 맥락입니다. 예전 디자인 시스템은 다 적어 두지 않아도 빈칸을 늘 그 자리에 있던 디자이너가 채웠는데, 이제는 여러 사람과 에이전트가 흩어져 만드니 결정을 훨씬 분명하게 정의해야 한다는 거죠. 딜의 표현대로 디자인의 대상이 화면이 아니라 시스템 자체가 된 겁니다. 딜이 든 구텐베르크 이야기가 이 감각을 잘 보여 줍니다. 구텐베르크는 대소문자 52자만 만든 게 아니라 폭이 다른 글자와 약자, 이음자까지 290종의 활자를 만들어, 양쪽 정렬로 찍어도 단어 사이가 어색하게 벌어지지 않게 했습니다. 기계로 찍어도 손으로 쓴 것처럼 보이도록 시스템을 충분히 넓고 단단하게 만든 거죠. 옛 시스템이 일관성을 퍼뜨렸다면 새 시스템은 의도를 퍼뜨려야 한다는 딜의 말은 여기서 나옵니다. 이걸 우리 팀에 옮기려면 비용을 봐야 합니다. CLI를 만들고 유지하는 건 디자이너 혼자 할 일이 아니라 엔지니어가 붙어야 하는 일이고, 디자인 시스템 팀이 사실상 내부 플랫폼 팀이 된다는 뜻이에요. 그 각오가 없는 조직이라면 최소한 "AI에게 주는 디자인 맥락을 누가 관리하나"를 정하는 데서 시작하면 됩니다.

가져갈 둘 — 편집자를 만든 뒤가 아니라 고르는 자리에

두 번째로 가져갈 건 편집자입니다. 예전에는 품질을 거르는 일이 개발 과정 곳곳에 박혀 있었습니다. 아이디어가 20개여도 사람을 붙일 수 있는 건 하나뿐이었으니, 고르는 순간 이미 걸러진 거죠. 지금은 20개를 일주일 만에 만들어 볼 수 있고, 거르는 일이 만든 뒤로 밀렸습니다. 딜이 짚은 진짜 문제는 그다음입니다. 이미 만든 것에 아니라고 말하기는 훨씬 어렵다는 것.

저는 이게 이 강연에서 가장 날카로운 관찰이라고 봅니다. 매몰 비용은 사람 마음을 생각보다 강하게 붙잡습니다. 동작하는 프로토타입이 회의실 화면에 떠 있으면 "이거 그냥 내보내면 안 돼요?"라는 말이 나오고, 그걸 막을 근거는 대개 감각 말고는 없어요. 그래서 편집자는 '만들어진 걸 평가하는 사람'이 아니라 '만들기 전에 무엇을 만들지 고르는 사람'이어야 합니다. 딜이 편집 실력을 키우는 방법으로 사용자처럼 처음부터 끝까지 써 보라고 권한 것도, 화면 하나는 괜찮아도 사용자 여정으로 이어 붙이면 어긋나는 경우가 많기 때문이죠.

애니메이션 하나를 56번 다시 만든 과정 중 두 장면

다만 이 사례는 양날입니다. 딜은 애니메이션 하나를 56번 다시 만든 끝에 더 사실적인 장면을 얻었고, AI가 없었다면 그렇게 많은 시점을 시도하지 못했을 거라고 말합니다. 맞는 얘기지만, 뒤집어 보면 AI가 시도 횟수를 늘린 만큼 편집자가 봐야 할 양도 늘었다는 뜻입니다. 광고 시안 리뷰에서 고칠 점 17개를 뽑아낸 이야기도 마찬가지예요. 편집자의 시간은 늘지 않으니, 어디에 그 시간을 쓸지부터 정해야 합니다. 편집자가 한 명뿐인 팀이라면 그 사람이 곧 병목이 되고, 병목 앞에서는 결국 '일단 내보내자'가 이깁니다.

조건을 붙일 하나 — '이상한 것을 지켜라'

딜이 가장 아낀다는 네 번째 처방은 Protect the strange입니다. AI로 만드는 비용이 낮아졌으니 그 절약분 일부를 정말 특별한 걸 만드는 데 쓰자는 것, 이미 만들던 걸 더 빨리 만드는 데만 쓰면 가장 흥미로운 부분을 놓친다는 것. 채팅창·차트·명령줄이 이 시대 인터페이스의 완성형일 리 없다는 말에도 동의합니다.

그런데 저는 이 처방이 대부분의 조직에서 구호로 끝날 거라고 봅니다. 절약분은 그냥 두면 처리량이나 인원 계획으로 회수되기 때문입니다. 30명이 하던 일을 3명이 한다는 숫자를 본 경영진이 남은 27명의 시간을 '이상한 시도'에 쓰라고 내줄까요? 딜이 팀 리더에게 AI를 쓰라고만 하지 말고 탐색의 여지를 주라고 권한 건 맞지만, 그 여지는 분기 계획에 이름과 예산이 붙어야 생깁니다. 프리미엄 브랜드가 경쟁력인 Stripe에서는 자연스러운 투자가, 납기에 쫓기는 에이전시나 초기 스타트업에서는 사치가 될 수 있어요.

그리고 모든 화면이 특별할 필요도 없습니다. 설정 화면, 관리자 화면, 결제 실패 안내 같은 곳에서는 '가장 흔한 답'이 오히려 정답입니다. 사용자는 거기서 예측 가능성을 원하지 개성을 원하지 않거든요. 좀비 UI가 진짜 문제인 곳은 브랜드가 드러나야 하는 접점, 사용자가 '이 회사는 다르다'고 느껴야 하는 화면입니다. 딜이 반대 사례로 든 것들도 그렇습니다. 브라우저 탭에 오늘 날짜를 띄운 캘린더, 결제를 대신하는 에이전트가 겪을 문제를 내다보고 넣어 둔 안내. 이런 디테일은 아무 화면에나 뿌리는 장식이 아니라 사용자가 가장 오래 머무는 자리에 놓인 배려입니다.

첫 번째 처방인 '기준을 먼저 세운다'는 흔한 얘기라 짧게만 짚고 넘깁니다. 만든 방식은 사용자에게 중요하지 않고 결과물이 좋은지가 중요하다는 원칙은 AI 이전에도 옳았습니다. 다만 Stripe가 낙관이라는 가치를 색과 문장과 제품에까지 옮겨 둔 회사라는 점은 기억해 둘 만합니다. 기준은 그렇게 구체적일 때만 리뷰에서 쓸모가 있습니다.

정리하면 이렇습니다. 좀비 UI의 처방은 모든 화면을 특별하게 만드는 게 아니라, 어디가 좀비여도 되는지를 먼저 정하는 겁니다. 예측 가능하면 되는 화면은 시스템과 CLI에 맡겨 AI가 찍어 내게 하고, 편집자의 희소한 시간과 '이상한 시도'의 예산은 브랜드가 드러나는 접점에만 몰아주세요. 그 구분 없이 네 처방을 다 하려는 팀은 결국 어느 것도 제대로 못 하고, 그 사이 좀비는 조용히 늘어날 겁니다.