터미널 한 줄이면 디자인 시안 여러 장이 아트보드로 뜹니다

"/design a few options for {기능}". 이 한 줄을 터미널에 치면 디자인 시안 여러 장이 아트보드로 뜹니다. 클로드 코드 개발자 @nateparrott이 올린 이 기능의 발표 트윗이 조회 907,756을 기록했어요.

숫자보다 눈에 띈 건 반응의 결이었습니다. 공감 표시 셋에 저장이 둘 꿀로 따라붙는 비율이었어요. 사람들이 이 발표를 감상이 아니라 사용법으로 저장했다는 뜻이라고 저는 읽었어요.

터미널에서 디자인 시안을 고르는 시대가 이렇게 열렸습니다.

/design은 어떤 흐름으로 동작하나요?

공식 설명은 간단합니다. 뭔가를 만들기 전에 "/design a few options for {기능}"을 치고, 마음에 드는 아트보드를 골라 고친 다음, 그대로 구현시키라는 거예요. 프롬프트, 아트보드, 편집, 구현. 네 단계가 전부입니다.

발표 트윗에 붙은 40초짜리 데모 영상이 이 흐름을 그대로 보여줍니다. 별도의 블로그나 문서 링크 없이 트윗 하나와 영상 하나가 발표의 전부였는데도 이만한 반응이 나왔어요.

핵심 약속은 두 가지입니다. 코드베이스를 읽는다는 것, 그리고 기존 UI에 맞춰준다는 것. 에이전트가 시안을 그리는 도구는 전에도 있었지만, 내 프로젝트의 코드를 읽고 내 UI에 맞춘 시안을 내놓는다는 게 이 기능의 차별점이에요.

클로드 코드 데스크톱과 CLI 양쪽에서 되고, 얼리 프리뷰 딱지가 붙어 있습니다. 터미널 도구인 CLI에서도 아트보드를 고르는 워크플로가 된다는 점이 특히 낯선 장면이죠.

발표 24시간이 안 된 2026년 8월 18일, @minchoi의 소개 트윗도 따로 돌았습니다. 이 소개 트윗도 저장 위주로 소비됐고, 눈길 자체는 인용된 원본 발표가 대부분 가져갔어요. 파생 트윗까지 저장용으로 소비됐다는 얘기입니다.

지금까지 에이전트로 UI를 만드는 흐름은 예외 없이 만들고 나서 다듬는 쪽이었습니다. 일단 구현하고, 눈으로 보고, 마음에 안 들면 다시 시키고. 그 왕복이 토큰과 시간을 다 먹었죠. 다시 시키는 횟수만큼 비용이 쌓이는 구조였으니까요.

/design은 구현 전에 고르게 합니다. 시안 단계에서 방향을 확정하면 구현은 한 번에 갑니다. 버리는 왕복이 사라지는 거예요.

시안 여러 장을 뽑는 비용은 완성된 구현을 여러 번 갈아엎는 비용보다 훨씬 쌉니다. 같은 선택을 하더라도 어느 단계에서 하느냐가 전체 비용을 가르는 거죠.

이건 검증된 컴포넌트를 조립해서 디자인 감각을 대체하는 접근을 공식 기능으로 끌어올린 것이기도 합니다. 프론트엔드 쪽에서 개인들이 각자 구축해 쓰던 우회로를, 하네스 제작사가 직접 슬래시 커맨드로 넣어버린 거죠.

디자인을 못 해도 시안을 고를 줄만 알면 디자인 좋은 결과물이 나오는 구조. 잘 만드는 능력보다 잘 고르는 능력이 결과물을 가르는 구간으로 들어왔습니다. 고르는 눈이 만드는 손을 대체하는 중이에요.

"기존 UI에 맞춰준다"는 약속을 정면으로 겨눈 답글이 있었습니다. 아무도 안 치운 디자인 시스템 두 개가 경쟁하는 코드베이스를 만나기 전까지만 유효한 말이라는 거예요.

이 지적은 거대한 반응을 얻은 발표 밑에서 거의 아무도 안 읽고 지나갔습니다. 실무자라면 누구나 고개를 끄덕일 내용인데도요. 환호는 크게 돌고 한계는 조용히 묻히는 게 신기능 발표의 전형적인 풍경입니다.

깨끗한 코드베이스라면 기존 UI를 읽고 맞추는 게 어렵지 않습니다. 그런데 현실의 오래된 프로젝트는 버튼 스타일이 두 벌, 색 정의가 세 벌인 경우가 흔하죠. 그때 /design이 어느 쪽을 기준으로 삼을지는 아직 답이 없습니다.

기존 UI에 맞춘다는 기능은 기존 UI가 하나로 정리돼 있다고 치고 하는 말이에요. 그 전제가 무너진 코드베이스에서 이 기능이 어떻게 동작하는지가 데모 영상 바깥의 진짜 시험대입니다.

또 하나, 격리된 에이전트나 워크트리 안에서 돌리면 깃 트리가 안 맞는다는 실사용 보고도 나왔습니다. 에이전트 여러 개를 병렬로 굴리는 워크플로일수록 먼저 부딪히는 한계예요. 헤비 유저의 작업 방식과 새 기능이 아직 아귀가 안 맞는 셈입니다.

역설적인 지점이에요. 에이전트를 가장 적극적으로 쓰는 사람일수록 워크트리로 작업을 격리하는데, 바로 그 사람들이 새 기능의 구멍을 먼저 밟게 되니까요.

얼리 프리뷰 딱지가 붙은 이유가 여기 있다고 봐야죠. 데모의 매끈함과 실사용의 거친 면이 발표 직후부터 같이 보고되고 있다는 것 자체가, 이 기능이 진지하게 쓰이기 시작했다는 신호이기도 하고요.

저는 이 기능의 진짜 의미가 검토 지점의 이동이라고 봅니다.

사람의 개입이 코드 리뷰에서 시안 선택으로 앞당겨졌어요. 코드 리뷰 단계에서 방향이 틀렸다는 걸 발견하면 구현 전체를 버려야 하지만, 시안 단계에서 같은 걸 발견하면 아트보드 한 장을 버리면 끝이에요. 같은 판단인데 비용이 다릅니다.

물론 디자인 시스템 두 개가 엉킨 코드베이스와 워크트리 깃 불일치라는 숙제는 남아 있습니다. 그런데 그건 기능의 완성도 문제지, 방향의 문제가 아니에요. 검토 지점을 앞으로 당기는 흐름 자체는 되돌리기 어려워 보입니다.

에이전트가 실행을 가져갈수록 사람에게 남는 건 선택 지점들입니다. 에이전트 시대의 사람 역할은 실행이 아니라 선택 지점마다 서 있는 것이고, /design으로 그 지점이 하나 더 앞으로 왔습니다.

FAQ

/design은 어떤 흐름으로 동작하나요?: 뭔가를 만들기 전에 "/design a few options for {기능}"을 치고, 마음에 드는 아트보드를 골라 고친 다음 그대로 구현시키는 순서입니다. 코드베이스를 읽고 기존 UI에 맞춘 시안을 내놓는다는 게 차별점이고, 데스크톱과 CLI 양쪽에서 됩니다.
구현 전에 시안을 고르면 뭐가 달라지나요?: 지금까지는 일단 구현하고 마음에 안 들면 다시 시키는 왕복이 토큰과 시간을 다 먹었습니다. 시안 단계에서 방향을 확정하면 구현은 한 번에 가고, 버리는 왕복이 사라집니다.
현장 반응은 어떤 한계를 짚었나요?: 디자인 시스템 두 개가 경쟁하는 코드베이스에서는 기존 UI에 맞춘다는 약속이 흔들린다는 지적이 나왔습니다. 격리된 에이전트나 워크트리 안에서 돌리면 깃 트리가 안 맞는다는 실사용 보고도 있었습니다.