13장. Brilliant와 Datadog의 실제 사례

숫자가 말해 주는 순간이 있다

AI 도구를 소개할 때 가장 흔한 문장은 늘 비슷합니다. "더 빠릅니다." "더 쉽게 됩니다." "협업이 개선됩니다." 문제는 이런 말이 너무 자주 쓰여서, 듣는 사람 입장에서는 어느 순간부터 광고 배경음처럼 들린다는 데 있습니다. 좋다는 건 알겠는데, 그래서 얼마나 좋아졌다는 걸까? 그리고 무엇이 달라졌길래 그렇게 빨라진 걸까?

Claude Design의 초반 사례에서 눈에 띄는 이유가 바로 여기에 있습니다. Brilliant는 경쟁 도구에서 20개가 넘는 프롬프트가 필요하던 복잡한 페이지를 Claude Design에서는 2개의 프롬프트로 재현했다고 말했습니다. Datadog은 예전에는 브리프, 목업, 리뷰 라운드를 오가며 일주일쯤 걸리던 흐름이 이제는 하나의 대화 안에서 이뤄진다고 설명했습니다.¹²

이 숫자만 보면 마치 마술 같습니다. 하지만 실제로는 마술이라기보다, 중간 단계가 줄어든 결과에 가깝습니다. 이번 장에서는 그 중간 단계가 정확히 무엇이었는지, 그리고 왜 두 회사가 이 변화를 체감했는지 차근차근 살펴보겠습니다.

Brilliant 사례: 20번 넘게 말하던 일을 2번으로 줄이다

Brilliant는 복잡한 인터랙티브 학습 경험으로 잘 알려진 팀입니다. 이 회사의 화면은 단순히 예쁜 카드와 버튼 몇 개로 끝나지 않습니다. 사용자가 눌렀을 때 반응이 살아 있어야 하고, 교육용 콘텐츠 특유의 단계적 흐름과 애니메이션 감각도 중요합니다. 쉽게 말해, "정적인 예쁜 시안"만으로는 부족한 제품입니다.

Anthropic이 공개한 사례에 따르면 Brilliant의 시니어 프로덕트 디자이너는 가장 복잡한 페이지를 다른 도구로 재현하려면 20개 이상의 프롬프트가 필요했지만, Claude Design에서는 2개면 충분했다고 말했습니다.¹² 이건 단순히 프롬프트를 덜 쳤다는 뜻이 아닙니다. 그동안 사용자는 도구에게 계속 이렇게 말하고 있었던 셈입니다.

첫째, 내가 원하는 레이아웃은 이런 식이야. 둘째, 아니, 좀 더 우리 제품 같아야 해. 셋째, 이건 정적이라 부족하니 상호작용을 넣어야 해. 넷째, 색감과 간격을 다시 맞춰야 해. 다섯째, 이 상태에 대한 의도도 따로 설명해야 해.

즉, 프롬프트 수가 많았다는 것은 도구가 한 번에 이해하지 못한 맥락이 많았다는 뜻입니다. 사용자는 결과를 조금씩 고치면서, 빠진 정보를 뒤늦게 계속 보충해야 했습니다. 마치 길을 물어봤는데 상대가 매번 "아, 그건 말 안 하셨어요"라고 답하는 상황과 비슷합니다. 틀린 말은 아닌데, 꽤 피곤하죠.

Claude Design이 여기서 달랐던 이유는 화면을 단순 이미지처럼 다루지 않았기 때문입니다. Anthropic은 Claude Design이 대화로 첫 버전을 만들고, 인라인 코멘트와 직접 편집, 조정 슬라이더로 세밀하게 다듬게 해 주며, 완성 후에는 정적 목업을 인터랙티브 프로토타입으로 바꿔 사용자 테스트까지 이어지게 한다고 설명합니다.² Brilliant가 특히 높게 평가한 지점도 바로 여기였습니다. 정적인 시안을 곧바로 공유 가능한 인터랙티브 프로토타입으로 바꿀 수 있었고, 그 상태에서 디자인 의도까지 Claude Code 핸드오프에 포함할 수 있었다는 점입니다.¹²

중요한 것은 "2개의 프롬프트"라는 숫자 뒤에 숨어 있는 구조입니다. 이 숫자가 가능한 이유는 Claude Design이 한 번에 더 많은 맥락을 먹기 때문입니다. 팀의 디자인 시스템, 기존 코드베이스, 원하는 상호작용, 실제 제품과 비슷한 시각 언어가 한 흐름 안에 들어갑니다. 그래서 예전 같으면 따로따로 설명해야 했던 내용이 한 덩어리로 전달됩니다.

결국 Brilliant 사례는 이렇게 읽는 것이 맞습니다. 프롬프트 수 감소 = 노동 감소가 아니라, 맥락 전달 비용 감소 = 반복 수정 감소입니다. 이 차이를 이해해야 "왜 20에서 2로 줄었는가"가 보입니다.

Brilliant 사례가 보여 주는 진짜 포인트

Brilliant 사례를 단순히 "Claude Design이 더 똑똑하다"로 정리하면 절반만 본 것입니다. 더 중요한 포인트는, 이 도구가 복잡한 인터랙티브 페이지를 만들 때 필요한 설명을 한곳에 모아 준다는 점입니다.

예전에는 복잡한 페이지 하나를 만들기 위해 적어도 세 가지가 따로 놀기 쉬웠습니다. 화면의 모양, 움직임의 규칙, 그리고 구현 시 전달해야 할 의도입니다. 모양은 목업에 있고, 움직임은 회의 때 말로 설명되고, 구현 의도는 슬랙에 남아 있는 식이죠. 그러면 팀은 결국 같은 페이지를 세 번 설명하게 됩니다.

Brilliant가 말한 속도 향상은 이 세 설명이 한 줄로 연결되었을 때 일어난 변화로 볼 수 있습니다. Claude Design에서 정적인 시안을 만들고, 그것을 인터랙티브 프로토타입으로 바꾸고, 그 안에 담긴 디자인 의도를 Claude Code로 넘기는 흐름이 생기면서 설명의 왕복이 줄어든 것입니다.¹²

여기서 독자가 꼭 기억할 점이 하나 있습니다. 속도의 핵심은 "생성"이 아닙니다. 재설명하지 않아도 되는 것이 핵심입니다. 디자인 작업에서 시간을 잡아먹는 건 처음 초안을 만드는 10분보다, 그다음 3일 동안 "제가 원한 건 그게 아니라요"를 반복하는 과정인 경우가 많기 때문입니다.

Datadog 사례: 일주일짜리 왕복을 한 대화로 압축하다

Datadog 사례는 Brilliant와 결이 조금 다릅니다. Brilliant가 복잡한 인터랙션을 빠르게 만들었다는 이야기라면, Datadog은 팀 협업 리듬 자체가 바뀌었다는 이야기입니다.

Anthropic이 공개한 문구에 따르면 Datadog 팀은 이제 회의 도중에 라이브로 디자인을 만들 수 있을 만큼 프로토타이핑이 빨라졌고, 예전에는 브리프 작성, 목업 제작, 리뷰 라운드를 거치며 일주일쯤 걸리던 흐름이 한 번의 대화 안에서 일어난다고 평가했습니다.² VentureBeat도 이 사례를 같은 맥락으로 전하며, Datadog의 제품 팀이 브리프-목업-리뷰의 주간 단위 사이클을 단일 대화로 압축했다고 소개했습니다.¹

이 장면을 상상해 봅시다. 예전 방식에서는 먼저 누군가가 요구사항을 문서로 정리합니다. 그다음 디자이너가 초안을 만들고, 다시 PM이 코멘트를 달고, 이해관계자가 수정 요청을 하고, 리뷰를 거쳐 다음 버전이 나옵니다. 다들 열심히 일하고 있지만, 실제로는 공이 계속 사람 사이를 오가고 있습니다. 한 사람이 틀렸다기보다, 전달 방식이 느린 겁니다.

Datadog 사례가 흥미로운 이유는 Claude Design이 이 공을 한가운데로 모았기 때문입니다. 대화 안에서 바로 시각화가 되고, 그 자리에서 수정이 이뤄지고, 브랜드와 디자인 가이드라인이 결과물에 유지되니, 회의가 끝났을 때 손에 남는 것이 단순 메모가 아니라 실제 프로토타입이 됩니다.²

회의가 끝났는데 남는 것이 "다음 주까지 시안 부탁드립니다"가 아니라 "지금 이 버전을 공유하고 테스트해 봅시다"라면, 팀의 시간 감각은 완전히 달라집니다. 이것이 Datadog 사례의 본질입니다.

Datadog은 왜 더 빨라졌을까

Datadog 사례를 뜯어 보면 속도를 만든 요인은 몇 가지로 정리됩니다.

첫 번째는 브리프와 결과물 사이의 간격이 짧아졌다는 점입니다. 원래 브리프는 말로 된 문서이고, 목업은 시각 결과물입니다. 둘 사이에는 늘 해석이 들어갑니다. 그런데 Claude Design에서는 브리프가 거의 바로 시각 초안으로 이어집니다. 해석 단계가 없어지는 건 아니지만, 훨씬 짧아집니다.

두 번째는 브랜드 정합성 비용이 줄었다는 점입니다. Anthropic은 Claude Design이 팀의 디자인 시스템을 읽고 이후 프로젝트에 자동 적용할 수 있다고 설명합니다.² 이 말은 Datadog 같은 팀이 매번 "우리 톤은 이렇고, 컴포넌트는 저렇고, 이 화면은 회사 제품 느낌을 유지해야 합니다"를 길게 반복할 필요가 줄어든다는 뜻입니다. 초안이 처음부터 팀 문법을 어느 정도 알고 시작하니, 리뷰는 미세 조정에 더 가까워집니다.

세 번째는 수정이 회의 후반 작업이 아니라 회의 중 행동이 되었다는 점입니다. 예전에는 회의에서 의견을 모으고, 작업은 그다음에 시작하는 경우가 많았습니다. 이제는 의견을 말하는 순간 수정이 일어납니다. 말하자면 회의가 "요청서 작성 시간"에서 "실제 제작 시간"으로 바뀐 셈입니다.

이 변화는 생각보다 큽니다. 왜냐하면 많은 조직에서 느림은 능력 부족보다도 대기 시간 때문에 생기기 때문입니다. 누가 일을 못해서가 아니라, 누군가의 차례를 기다리느라 느린 것이죠. Datadog 사례는 그 대기 시간을 강하게 줄인 예로 볼 수 있습니다.

두 사례의 공통점: 속도는 생성 모델보다 흐름에서 나온다

Brilliant와 Datadog은 서로 다른 종류의 팀처럼 보입니다. 하나는 복잡한 인터랙티브 학습 경험이 중요한 제품 팀이고, 다른 하나는 빠른 제품 협업과 명확한 전달이 중요한 조직 사례로 읽힙니다. 그런데 두 사례는 아주 비슷한 결론으로 모입니다.

둘 다 "디자인을 더 빨리 그렸다"는 이야기만 하고 있지 않습니다. 둘 다 설명, 수정, 공유, 구현 연결이 더 짧아졌다고 말하고 있습니다.¹²

이 공통점은 중요합니다. Claude Design의 가치가 단순한 시각 생성에만 있다면, 팀마다 체감 차이는 꽤 달라졌을 것입니다. 어떤 팀은 만족하고, 어떤 팀은 "그림은 빨리 나오는데 그래서 뭐?"라고 말했겠죠. 그런데 Brilliant는 복잡한 페이지의 재현 비용이 줄었다고 말하고, Datadog은 협업 사이클이 줄었다고 말합니다. 즉, 서로 다른 문제를 가진 팀이 같은 도구에서 같은 종류의 이익을 본 것입니다. 바로 마찰 감소입니다.

Brilliant에게 마찰은 많은 프롬프트와 복잡한 프로토타이핑 과정이었습니다. Datadog에게 마찰은 브리프와 목업, 리뷰 라운드 사이의 왕복이었습니다. Claude Design은 둘 다를 줄였습니다. 그래서 이 두 사례는 단순한 고객 추천사가 아니라, 제품 포지셔닝의 증거에 가깝습니다.

이것이 홍보 문구가 아닌 이유

물론 냉정하게 볼 필요도 있습니다. 공개 사례는 어디까지나 성공한 장면을 보여 줍니다. 모든 팀이 첫 주부터 똑같은 속도를 얻는다고 기대하면 곤란합니다. 프롬프트를 어떻게 쓰는지, 팀의 디자인 시스템이 얼마나 정리되어 있는지, 기존 코드베이스가 얼마나 일관된지에 따라 결과는 달라질 수 있습니다.

그럼에도 이 사례들이 의미 있는 이유는, 개선 폭이 너무 애매하지 않기 때문입니다. "조금 더 편해졌어요"가 아니라 "20개 이상의 프롬프트가 2개가 됐다", "일주일 걸리던 흐름이 단일 대화가 됐다" 같은 표현은 팀이 체감한 변화의 크기를 보여 줍니다.¹² 이 정도면 단순한 감상보다, 워크플로의 구조 변화에 가깝습니다.

특히 두 사례 모두 Claude Design 단독의 예쁜 결과물보다, 다음 단계로 이어지는 능력을 강조합니다. Brilliant는 인터랙티브 프로토타입과 Claude Code 핸드오프를 언급했고, Datadog은 라이브 디자인과 브랜드 일관성을 말했습니다.¹² 다시 말해, 이 도구의 평가 기준이 "보기 좋다"에 머무르지 않았다는 뜻입니다. 실무 팀은 늘 그렇습니다. 멋진 화면보다, 바로 다음 행동으로 이어지는 결과물을 더 높게 평가합니다.

우리 팀은 이 사례를 어떻게 읽어야 할까

이 장을 읽고 가장 먼저 던져야 할 질문은 "우리도 20에서 2로 줄일 수 있을까?"가 아닙니다. 그 질문은 너무 결과 중심입니다. 더 좋은 질문은 이것입니다. 우리 팀에서 가장 많이 새는 시간이 어디인가?

어떤 팀은 초안 만들기가 느립니다. 어떤 팀은 수정 라운드가 너무 많습니다. 어떤 팀은 디자이너와 엔지니어 사이의 핸드오프에서 자꾸 의도가 깨집니다. 또 어떤 팀은 회의는 길게 했는데 남는 결과물이 없습니다.

Brilliant와 Datadog 사례는 바로 이 질문에 답하는 힌트를 줍니다. Claude Design은 만능 지우개처럼 모든 문제를 없애 주기보다, 중간에 반복되는 설명과 대기 시간을 줄이는 데 강합니다. 따라서 도입 검토도 이렇게 해야 합니다.

우리 팀이 복잡한 인터랙션을 설명하느라 계속 프롬프트와 수정 요청을 반복한다면, Brilliant 유형의 개선을 기대할 수 있습니다. 반대로 회의와 브리프, 목업, 리뷰 사이클이 길어서 의사결정이 늦다면, Datadog 유형의 개선이 더 현실적인 목표입니다.

즉, 사례를 복사하려 하지 말고 우리 병목과 같은 모양의 장면을 찾아야 합니다.

속도는 비용 절감이 아니라 의사결정 능력의 확장이다

마지막으로 하나만 더 짚고 넘어가겠습니다. 많은 사람이 속도 향상을 들으면 곧바로 "사람을 덜 써도 되겠네"라고 해석합니다. 하지만 이 장의 두 사례를 보면 더 중요한 효과는 인건비 절감이 아니라 탐색 범위 확대에 있습니다.

Brilliant는 같은 복잡도를 더 적은 왕복으로 다룰 수 있게 되었고, Datadog은 회의 안에서 실제 프로토타입을 만들 수 있게 되었습니다.¹² 이것은 단순히 일을 빨리 끝낸다는 의미만이 아닙니다. 같은 시간 안에 더 많은 방향을 시험해 보고, 더 빨리 검증하고, 더 일찍 구현 단계로 넘어갈 수 있다는 뜻입니다.

제품 개발에서 이 차이는 큽니다. 느린 팀은 좋은 아이디어가 없어서 지는 경우보다, 아이디어를 시험할 시간이 부족해서 지는 경우가 많기 때문입니다. 속도는 단지 달리기 기록이 아닙니다. 더 많은 시도를 할 수 있는 권리입니다.

Claude Design의 초기 사례가 흥미로운 이유도 바로 여기 있습니다. 이 도구가 약속하는 것은 예쁜 화면 한 장이 아니라, 팀이 생각을 더 빨리 외부화하고 더 적은 손실로 구현까지 가져가는 능력입니다. Brilliant와 Datadog은 그 약속이 적어도 일부 팀에게는 실제로 작동했다는 첫 증거입니다.

이 장의 핵심 정리

Brilliant 사례는 Claude Design이 복잡한 인터랙티브 페이지에서 맥락 전달 비용을 크게 줄일 수 있음을 보여 줍니다. 경쟁 도구에서 20개 이상의 프롬프트가 필요하던 작업이 2개로 줄었다는 말은, 생성 품질만이 아니라 반복 수정의 구조가 바뀌었다는 뜻입니다.¹²

Datadog 사례는 협업 속도가 어떻게 바뀌는지를 보여 줍니다. 브리프, 목업, 리뷰를 주간 단위로 주고받던 흐름이 단일 대화로 압축되었다는 말은, 회의가 논의의 장소를 넘어 실제 제작의 장소가 되었음을 의미합니다.¹²

두 사례를 함께 보면 결론은 분명합니다. Claude Design의 강점은 단순히 시안을 빨리 만드는 데 있지 않습니다. 디자인, 프로토타이핑, 공유, 핸드오프 사이의 마찰을 줄여 팀의 결정 속도를 높이는 데 있습니다. 그래서 이 속도 향상은 홍보 문구가 아니라, 잘 맞는 팀에게는 실제 운영 방식의 변화가 될 수 있습니다.

참고

¹Anthropic just launched Claude Design, an AI tool that turns prompts into prototypes and challenges Figma

²Introducing Claude Design by Anthropic Labs