디자인 에이전트는 '어색해요'를 문장으로 바꾼 팀에서만 일한다

“뭔가 어색해요. 좀 더 자연스럽게 해주세요.” 디자인 리뷰에서 흔히 오가는 이 말을, 라이너 팀은 에이전트에게는 쓸 수 없는 문장으로 분류했습니다. 그대로 전달하면 에이전트가 같은 문제를 다시 만든다는 이유로요. 저는 Pencil이라는 디자인 하네스에서 이 판단이 가장 값지다고 봅니다. 디자인 에이전트를 들이려는 팀이 먼저 물어야 할 질문도 여기서 나오거든요. 우리 팀은 '어색하다'를 문장으로 바꿀 수 있는가.

토큰은 값을 알려 줄 뿐이다

Pencil의 출발점은 DESIGN.md의 한계입니다. 디자인 시스템을 에이전트가 읽을 수 있는 문서로 건네주면 색상·타이포그래피·간격 토큰은 정확히 지켜집니다. 그런데 토큰을 다 지킨 화면이 좋은 화면이라는 보장은 없죠. 라이너가 보여 준 비교가 그 차이를 정확히 짚습니다.

왼쪽은 모든 간격이 16, 오른쪽은 8·32·8·16·16·8·16. 두 화면 모두 디자인 시스템을 지켰고, 차이는 어떤 요소를 한 묶음으로 보느냐에서 생겼습니다. 개발자 말로 옮기면 디자인 시스템은 쓸 수 있는 값의 목록을 줬을 뿐, 값과 값 사이의 관계는 정의하지 않았다는 겁니다. 타입은 맞는데 로직이 틀린 코드와 비슷하죠. 컴파일은 통과하는데 동작이 이상한.

Pencil은 그 관계를 리뷰 지침으로 적었습니다. 형식이 특히 좋습니다.

'뭔가 어색하다'는 인상은 '로고부터 약관까지 모든 간격이 16px로 같다'는 관찰이 되고, '어떤 요소가 한 묶음인지 간격으로 드러나지 않는다'는 원인을 거쳐, '묶음 안은 작은 간격, 묶음 사이는 한 단 더 크게'라는 지침으로 내려갑니다. 지침 자체는 새롭지 않아요. 가까이 놓인 것을 한 무리로 읽는다는, 디자이너라면 다 아는 근접성 원칙이니까요. 진짜 성과는 원칙의 발견이 아니라 기록입니다. 모두가 알고 있어서 아무도 디자인 시스템 문서에 적지 않았던 지식이, 에이전트라는 글자 그대로 읽는 독자가 생기자 비로소 문장이 됐습니다.

팀은 시각적 리듬감·비례·무게감·밀도까지 이 형식으로 skill화했고, 수정된 화면을 반복해 확인하며 지침을 다듬었습니다. 저는 그 문서가 에이전트 없이도 쓸모 있다고 봐요. 신입 디자이너에게, 화면을 직접 짜는 프론트엔드 개발자에게 그대로 넘길 수 있는 문서니까요.

세 단계로 나눈 효과와 빈칸

하네스의 뼈대는 기획·디자인·리뷰의 분리입니다.

기획 skill이 화면의 목적과 사용자가 해야 할 일, 정보의 우선순위를 정해 동작 명세를 만들고, 디자인 skill이 그걸 컴포넌트와 토큰으로 Figma 시안에 옮기고, 리뷰 skill이 실제 결과를 보며 시선의 흐름과 위계, 간격의 리듬을 따져 어색하면 디자인 단계로 되돌립니다. 만드는 일과 평가하는 일을 다른 절차로 둔 건 맞는 설계라고 봐요. 한 프롬프트 안에서 만들고 스스로 괜찮다고 판정하게 두면 기준이 흐려지기 쉬우니까요. 리뷰가 생성 과정이 아니라 실제 결과물을 본다는 점도 좋습니다.

다만 Product Design 하네스라는 이름에 비해 입구가 좁습니다. 기획 skill의 이름이 prd-to-pencil이에요. 입력은 PRD고, 무엇을 왜 만들지는 여전히 하네스 바깥에서 들어옵니다. "Pencil만 사용해도 제품 개발이 마무리될 수 있게"라는 목표는 문제 정의가 이미 끝났다는 전제 위에서만 성립하는 셈이죠.

캐시에는 만료가 있다

비용 쪽 결정도 실무적입니다. Figma MCP의 get_design_context 같은 도구는 선택 영역의 구조와 레이아웃, 토큰을 풍부하게 넘겨주는데, 버튼 인스턴스 하나 만드는 데 그 맥락이 다 필요하지는 않습니다. 그래서 팀은 디자인 시스템의 명세와 의도를 컴포넌트 key 기준의 JSON 정적 파일로 정리해, 에이전트가 이미 아는 지식을 매번 Figma에 다시 묻지 않게 했습니다.

개발자 눈에는 익숙한 그림입니다. 정적 카탈로그는 Figma 라이브러리의 캐시거든요. 캐시는 빠르고 싸지만 만료 정책 없이는 조용히 틀려집니다. 라이브러리에 컴포넌트가 추가되거나 속성이 바뀌었을 때 카탈로그를 누가, 어떻게 다시 만드는지는 글에 나오지 않아요. 사람이 손으로 관리하는 카탈로그라면 몇 달 뒤 에이전트는 없는 속성을 자신 있게 쓰고 있을지도 모릅니다. 따라 할 팀이라면 카탈로그를 라이브러리 배포 과정에서 자동으로 생성하는 것부터 정해 두길 권합니다.

도입 전에 확인할 것

이 글에는 효과를 보여 주는 숫자가 하나도 없습니다. 리뷰 단계가 몇 번이나 되돌렸는지, 맥락 비용이 얼마나 줄었는지, 디자이너의 시간이 어떻게 바뀌었는지. 어제 해결했다고 생각한 문제가 오늘은 아니었다는 고백과 함께 읽어야 하는 제작기입니다. 그래서 저는 이 사례를 "따라 하면 된다"가 아니라 "이런 팀이라면 해볼 만하다"로 읽습니다.

조건은 이렇습니다. Figma에 컴포넌트 key가 안정적으로 관리되는 디자인 시스템이 있어야 하고, 에이전트를 돌릴 환경을 만들어 줄 사람이 있어야 합니다. 라이너에는 Hermes 에이전트를 GUI로 만들고 관리하는 환경을 구축한 데스옵스 리드가 있었죠. 그런데 가장 대체하기 어려운 조건은 따로 있어요. 리뷰 감각을 관찰·원인·지침으로 번역할 디자이너입니다. 그 사람이 없으면 하네스는 토큰만 성실하게 지키는 에이전트로 돌아갑니다.

시작점이 에이전트일 필요는 없습니다. 지난 디자인 리뷰에서 "어색해요", "좀 더 자연스럽게"로 끝난 코멘트를 몇 개 골라 관찰·원인·지침으로 다시 써 보면 됩니다. 술술 써지는 팀이라면 하네스를 만들 재료가 이미 있는 거고요. 써지지 않는다면, 그동안 우리 리뷰가 전달해 온 건 기준이었을까요, 기분이었을까요?