에이전트에게 디자인을 맡겨봤다, 그런데 왜 마지막엔 늘 내가 고르고 있나

요즘 “에이전트가 디자인을 한다”는 말이 흔하다. 그래서 한 달 동안 오픈소스 도구들을 직접 모아 깔아봤다. 결론부터 말하면, 도구는 놀랍게 빨라졌는데 정작 “이게 우리답나”를 정하는 일은 매번 내 몫으로 돌아왔다. 왜 그런지, 성격이 또렷한 핵심 도구 네 개를 뜯어보며 알게 됐다.

먼저, 핵심 네 개를 골랐다

수십 개 중 디자인을 다루는 방식이 서로 다른 넷만 남겼다.

design.md, 에이전트가 읽는 규칙서. 구글랩스가 만든 형식이다. 색과 글꼴, 간격 같은 디자인 규칙을 사람이 아니라 기계가 읽도록 마크다운 한 장에 적어둔다. 재미있는 건 lint라는 검사 명령이 붙어 있다는 점이다. 글자 대비가 너무 약하면 경고를 띄운다. 맞춤법 검사기가 오타를 잡듯, 디자인 규칙의 기본을 자동으로 점검해 준다.

dembrandt, 남의 사이트를 숫자로 가져오는 도구. 마음에 드는 웹사이트 주소를 넣으면 그 사이트의 색, 글꼴, 간격을 숫자 목록으로 뽑아준다. 이 숫자 목록을 디자인 토큰이라고 부른다. 한 번 기준을 정해두면, 다음에 뽑은 결과가 그 기준에서 얼마나 벗어났는지 점수로 비교까지 해준다.

Figma-Context-MCP, 에이전트에게 내 피그마를 보여주는 다리. 내가 피그마에서 그린 디자인을 에이전트가 직접 읽게 해주는 다리다. 여기서 MCP는 에이전트와 외부 도구를 잇는 표준 연결구다. 규칙을 글로 적는 대신, 내가 그린 화면 자체가 규칙이 된다.

design-jarvis, 비평가가 딸린 디자인 팀. 혼자 일하지 않고 여러 에이전트가 역할을 나눈다. UX 담당, UI 담당이 따로 있고, 그 위에 디자인 리뷰어가 따로 있어 결과를 검수하는 단계를 일부러 떼어놓았다. 만드는 에이전트와 보는 에이전트를 나눈 셈이다.

네 도구가 똑같이 하는 것

성격은 제각각인데 일하는 순서는 약속이라도 한 듯 같았다. 다섯 단계다. 규칙을 정해주고, 만들고, 시안을 보고, 검수하고, 내보낸다. 상용 서비스도 다르지 않았다. v0나 Lovable 같은 유료 도구를 열어봐도 이름만 예쁠 뿐 같은 다섯 단계였다.

도구가 바닥을 가져갈수록, 사람의 일은 사라지지 않는다. 오히려 천장으로 더 또렷하게 모인다.

그런데 마지막 한 단계는 늘 비어 있었다

여기서 알맹이가 나온다. 자동화가 앞의 네 단계를 거의 다 먹었는데, “시안을 고르는” 단계만은 어디서도 사람에게 남겨두고 있었다. 이유는 단순하다. 코드에는 “테스트 통과”라는 객관적 합격선이 있다. 디자인에는 그게 없다. 천장을 재는 자가 없으니, 그 판단은 결국 사람 눈으로 돌아온다.

그래서 에이전트에게 디자인을 맡긴다는 건 사람이 손을 떼는 일이 아니었다. 좋은 도구를 고르는 기준은 얼마나 자동화됐느냐가 아니라, 나를 어디에 앉혀주느냐였다.