/design 한 줄에 시안이 뜨는 40초 데모가 조회 90만을 넘겼습니다

"/design a few options for {기능}". 이 한 줄을 터미널에 치면 클로드 코드가 디자인 시안 여러 장을 아트보드로 띄웁니다. 클로드 코드 개발자 @nateparrott은 트윗으로 이 기능을 발표해 조회 907,756을 모았어요.

저는 숫자보다 반응의 비율을 눈여겨봤습니다. 사람들은 공감 표시 셋을 누를 때 저장을 둘 꼴로 눌렀어요. 발표를 감상하기보다 사용법으로 저장했다는 뜻이라고 저는 읽었어요.

이 글에서는 /design의 흐름과 비용, 현장에서 나온 한계를 차례로 정리했습니다.

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

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

@nateparrott은 발표 트윗에 40초짜리 데모 영상을 붙여 이 흐름을 그대로 보여줍니다. 별도의 블로그나 문서 링크 없이 트윗 하나와 영상 하나로만 발표했는데도 이만큼 반응을 얻었어요.

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

클로드 코드 데스크톱과 CLI 양쪽에서 쓸 수 있고, 앤트로픽은 얼리 프리뷰 딱지를 붙여 뒀습니다. 터미널 도구인 CLI에서 아트보드를 고른다는 게 특히 낯설죠.

발표 24시간이 안 된 2026년 8월 18일에는 @minchoi가 소개 트윗을 따로 올렸습니다. 사람들은 이 소개 트윗도 주로 저장했고, 눈길은 대부분 인용된 원본 발표에 줬어요. 파생 트윗까지 저장용으로 소비했다는 얘기입니다.

구현 전에 시안을 고르면 뭐가 달라지나요?

지금까지 에이전트로 UI를 만들 때는 예외 없이 만들고 나서 다듬었습니다. 일단 구현하고, 눈으로 보고, 마음에 안 들면 다시 시키고. 그 왕복에 토큰과 시간을 다 썼죠. 다시 시킬 때마다 비용을 또 냈으니까요.

/design은 구현 전에 고르게 합니다. 시안 단계에서 방향을 확정하면 한 번에 구현합니다. 버리는 왕복도 없어요.

시안 여러 장을 뽑아도 완성된 구현을 여러 번 갈아엎을 때보다 비용을 훨씬 덜 냅니다. 고르는 단계를 앞당기면 같은 선택으로 전체 비용을 크게 줄일 수 있죠.

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

디자인을 못 해도 시안만 잘 고르면 좋은 결과물을 만들 수 있어요. 이제는 고르는 안목만으로도 앞서갈 수 있습니다.

현장 반응은 어떤 한계를 짚었나요?

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

거대한 반응을 얻은 발표 밑에서 이 지적을 읽은 사람은 거의 없었습니다. 실무자라면 누구나 고개를 끄덕일 내용인데도요. 신기능 발표 밑에서 흔히 보는 풍경입니다.

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

앤트로픽은 기존 UI가 하나로 정리돼 있다고 치고 이 약속을 했어요. 그런 전제가 안 맞는 코드베이스에서 직접 돌려 봐야 이 기능을 제대로 평가할 수 있습니다.

또 하나, 격리된 에이전트나 워크트리 안에서 돌리면 깃 트리가 안 맞는다는 실사용 보고도 있었습니다. 에이전트 여러 개를 병렬로 굴리는 사람일수록 먼저 부딪히는 한계예요.

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

앤트로픽이 얼리 프리뷰 딱지를 붙인 것도 그래서라고 봐야죠. 사용자들이 발표 직후부터 데모의 매끈함과 실사용의 거친 면을 같이 보고한다는 건, 이 기능을 진지하게 쓰기 시작했다는 신호이기도 하고요.

남는 생각

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

사람은 이제 코드 리뷰보다 앞선 시안 단계에서 개입합니다. 코드 리뷰 단계에서 방향이 틀렸다는 걸 발견하면 구현 전체를 버려야 하지만, 시안 단계에서 같은 걸 발견하면 아트보드 한 장을 버리면 끝이에요. 같은 판단이라도 시안 단계에서 하면 비용을 훨씬 덜 냅니다.

물론 디자인 시스템 두 개가 엉킨 코드베이스와 워크트리 깃 불일치라는 숙제는 남아 있습니다. 앤트로픽이 완성도를 다듬으면 풀 수 있는 문제예요. 검토 지점을 앞으로 당기는 흐름 자체는 되돌리기 어려워 보입니다.

에이전트에게 실행을 넘길수록 사람은 고르는 일에 집중합니다. /design으로 사람은 한 단계 더 앞에서 고르게 됐어요.

---