“쓰레기를 넣으면 보물을 얻는다”: 앤트로픽(Anthropic)의 수석 디자이너가 말하는 코워크(Cowork)의 제품 철학과 10일 만에 출시된 진실
정리 & 번역: TechFlow
게스트: 제니 웬(Jenny Wen), Cowork 디자인 책임자
진행자: 피터 양(Peter Yang)
팟캐스트 출처: Peter Yang
원제목: Claude Cowork 튜토리얼 – Cowork 디자인 책임자 인터뷰 (40분) | 제니 웬
방송일: 2026년 3월 29일
핵심 요약
제니는 Cowork의 디자인 책임자다. 그녀는 내게 Anthropic 내부의 운영 방식을 깊이 있게 소개해 주었고, Cowork를 활용해 제품을 설계하고 개발하는 방법, 그리고 Cowork 탄생 뒤에 숨은 진짜 이야기도 들려주었다. Anthropic은 거의 매일 새로운 기능을 출시하는데, 그들의 업무 방식을 보고 나는 정말 큰 충격을 받았다.
주요 통찰 요약
일상적인 업무 방식에 관하여
- 내가 시간을 가장 많이 쓰는 일은 바로 제품을 출시하는 것이다. 하지만 이 일이 1~2년 전과는 분명 달라졌다고 느낀다. 그중 상당 부분은 엔지니어나 제품 담당자 등과 비공식적인 방식으로 함께 ‘jam’하는 것이다(즉, 즉흥적 협업). 일반적으로 우리는 프로토타입을 함께 살펴보며, 그것이 어떻게 진화할 수 있을지 지적하고 고민한다.
“쓰레기 입력, 보물 출력”이라는 철학에 관하여
- Cowork가 나를 가장 놀라게 만든 점은 정보 정리 능력이다. 나는 이를 “쓰레기 입력, 보물 출력”이라고 부른다. Cowork는 다양한 출처에서 정보를 수집한 후, 핵심 포인트를 빠르게 식별하고 가치 있는 콘텐츠를 추출하며, 이를 실제 생산성으로 이어지는 결과물로 전환한다.
Cowork와 Claude Code의 차이점에 관하여
- 매우 세밀한 프로덕션 코드 작업 외에는, 지금은 거의 모든 일을 Cowork로 처리한다. 특정 코드 세부 사항에 집중해야 할 때는 여전히 Claude Code를 사용한다. 그러나 일상적인 의사소통 및 협업에서는 이제 완전히 Cowork에 의존한다.
Cowork의 탄생 스토리에 관하여
- “그들이 10일 만에 만들었다”는 말은 어느 인터뷰나 언론 보도에서 발췌된 문장이다. 하지만 실제 상황은 이렇다. 내가 1년 전 Anthropic에 입사했을 때부터 이미 Cowork라는 방향성에 대해 구상하기 시작했으며, 우리는 전통적인 지식 근로자 모두를 위한 ‘사고 파트너(thinking partner)’를 어떻게 만들어야 할지를 계속 고민해 왔다.
- Claude Code가 이미 코드 관련 작업을 훌륭하게 수행할 수 있긴 하지만, 우리의 목표는 모든 지식 근로 시나리오를 아우르는 것이다. 진정한 도전은 다음과 같다: 우리가 이 아이디어를 실제로 어떻게 실행할 것인가? 어떤 아키텍처가 가장 적합한가? 어떤 사용자 경험(UX)이 올바른가?
디자인 프로세스의 진화에 관하여
- 나는 여전히 Figma를 사용한다. 그러나 이제는 자주 사양 문서(specification document)를 작성하지 않으며, 작성하더라도 매우 상세하지 않다. 우선순위 설정은 여전히 진행되며, 문서 형태로 존재하지만, 일반적으로 과도하게 설계된 화려한 표가 아니라 단지 몇 개의 불릿 포인트(bullet points) 수준이다.
계획 및 비전에 관하여
- 우리가 속한 기술 분야는 변화가 극도로 빠르며, 새로운 모델이 끊임없이 등장하고 업데이트 속도 역시 점점 더 빨라지고 있다. 따라서 우리에게는 1년 단위의 비전을 수립하는 것조차 현실적이지 않으며, 2~5년 단위의 장기 비전은 더욱 그렇다. 너무 많은 불확실성이 존재하기 때문이다.
디자이너의 미래에 관하여
- 당신이 발밑의 땅이 움직이고 있다고 느낀다면, 그것은 실제로 그렇게 변하고 있다는 뜻이다. 우리는 이를 인정하고 적응해야 하며, 동시에 기존 업무 방식을 열린 마음으로 재검토해야 한다.
- 내 직업이 위협받고 있다고 느낄 때마다, 나는 항상 내 엔지니어 동료들을 떠올린다. 그들의 업무는 이미 오래전부터 거대한 변화를 겪어 왔다. 그러나 그들은 이러한 변화에 단순히 적응한 것이 아니라, 놀라운 용기와 겸손함으로 도전을 맞이했고, 결국 더 효율적이고 탁월한 업무 성과를 달성했다. 그들은 바로 나의 영감의 원천이다—나는 스스로에게 이렇게 말한다: “이렇게 존경하는 동료들이 해낼 수 있다면, 나도 반드시 해낼 수 있다.” 그들은 나의 변화 적응 롤모델이다.
오프닝
피터 양: 안녕하세요. 오늘은 Anthropic의 디자인 책임자 제니를 특별히 초대했습니다. 제니는 클로드 코워크(Claude Cowork)와 클로드 코드(Claude Code)를 어떻게 활용해 제품을 설계하고 출시하는지, 그리고 코워크의 내부 스토리를 공유해 주실 예정입니다. 아마도 제품의 다음 단계에 대해서도 이야기해 주실지도 모르겠네요.
제니, 당신의 하루는 보통 어떻게 보내시나요? 어떤 업무가 대부분의 시간을 차지하나요?
제니:
‘보통의 하루’가 정확히 무엇인지 잘 모르겠지만, 제가 시간을 가장 많이 쓰는 일은 바로 제품을 출시하는 것이다. 하지만 이 일이 1~2년 전과는 분명 달라졌다고 느낀다. 그중 상당 부분은 엔지니어나 제품 담당자 등과 비공식적인 방식으로 함께 ‘jam’하는 것이다(즉, 즉흥적 협업). 일반적으로 우리는 프로토타입을 함께 살펴보며, 그것이 어떻게 진화할 수 있을지 지적하고 고민한다. 때로는 기능의 표현 방식에 대해 논의하기도 하고, 때로는 내가 직접 일부를 구현하기도 한다. 여전히 많은 시간을 디자인하거나 프로토타입 제작 등에 쓰고 있지만, 지금의 디자인 업무 방식은 매우 유연하고 느슨하다고 느껴진다.
피터 양: 기본적으로 당신은 클로드 같은 도구를 이용해 여러 프로토타입을 생성한 후, 엔지니어들과 함께 jam하며 피드백을 주고받고, 프롬프트를 통해 AI가 그것을 개선하도록 하는 방식으로 일하시죠?
제니:
사실 그것들이 프로토타입이라기보다는, 이미 우리 내부에서 구축되어 클로드 또는 코워크 인스턴스에서 작동 중인 실용적인 프로토타입인 경우가 많다. 나는 일반적으로 이 기능을 직접 사용해보고, 이를 밀어붙이며, 그 능력을 확인하고 의견을 형성한 후, 다음 반복 단계에서 엔지니어와 앉아서 이렇게 말한다: “이렇게 생각해봤는데, 여기를 바꾸는 게 좋을 것 같아요.” 그래도 여전히 디자인 도구 안에서 반복하고 다듬고 정교화하는 시간이 매우 중요하다고 느끼기 때문에, 그 부분은 사라지지 않았다. 다만 내가 동시에 더 많은 프로젝트를 처리하면서, 보다 자유롭고 비공식적인 방식으로 작업하는 것이 더 효율적이라고 느껴질 뿐이다.
피터 양: 사실 그게 바로 내가 제품 매니저나 디자이너로서 가장 즐기는 부분인데요, 디자이너와 엔지니어를 한데 모아 제품을 함께 반복적으로 개선해 가는 과정이죠. 그렇다면 이제는 사양 문서나 Figma 파일 같은 계획 문서를 거의 만들지 않으시나요? 아니면 그냥 코드 안에서 바로 프로토타입을 반복하시나요?
제니:
나는 여전히 Figma를 사용한다. 그러나 이제는 자주 사양 문서를 작성하지 않으며, 작성하더라도 매우 상세하지 않다. 그렇습니다. 우선순위 설정은 여전히 진행되며, 문서 형태로 존재한다. 사실 이것은 보안팀이나 법무팀에 전달할 때 특히 유용한데, 그들이 출시될 내용을 명확히 이해할 수 있도록 해주기 때문이다. 그러나 일반적으로는 과도하게 설계된 화려한 표가 아니라 단지 몇 개의 불릿 포인트 수준이다. 우리 Figma 파일도 마찬가지라고 생각한다.
Cowork 실무 데모
피터 양: 각 제품을 어떻게 사용하시는지, 혹은 각각 어떤 용도로 활용하시는지 보여주실 수 있으신가요?
제니:
물론입니다. 제가 Cowork를 어떻게 사용하는지 설명드리겠습니다. 사실 제게는 작은 비밀이 있는데, 매우 세밀한 프로덕션 코드 작업 외에는 지금은 거의 모든 일을 Cowork로 처리합니다. 특정 코드 세부 사항에 집중해야 할 때는 여전히 Claude Code를 사용합니다. 그러나 일상적인 의사소통 및 협업에서는 이제 완전히 Cowork에 의존합니다.
제가 Cowork에서 가장 놀라운 점으로 꼽는 것은 바로 정보 정리 능력입니다. 저는 이를 “쓰레기 입력, 보물 출력”이라고 부릅니다. Cowork는 다양한 출처에서 정보를 수집한 후, 핵심 포인트를 빠르게 식별하고 가치 있는 콘텐츠를 추출하며, 이를 실제 생산성으로 이어지는 결과물로 전환합니다.
예를 들어, 현재 저는 사용자 인터뷰 기록이 저장된 폴더를 연결해 두었습니다. Cowork 팀은 사용자와의 긴밀한 연계를 매우 중시하며, 이것이 우리가 어느 정도 성공을 거둔 핵심 요인 중 하나이기도 합니다. 우리는 전통적인 사용자 경험 연구(UXR)를 통해 사용자와 직접 대화하고, 동시에 내부에서 직접 사용하는 방식도 병행합니다. 예를 들어, 피드백을 수집하기 위한 전용 Slack 채널을 운영하고 있습니다. 또한 소셜미디어에서의 논의를 주의 깊게 살펴보고, 열정적인 사용자들의 의견을 경청합니다. 바로 이런 사용자와의 긴밀한 연계와 빠른 제품 반복이 가능했기에, 우리는 지속적으로 개선해 왔고 오늘의 성과를 이룰 수 있었습니다.
그래서 제가 지금 하는 일은, 클로드에게 이렇게 말하는 것입니다: “이 인터뷰 폴더가 있어요. 그런데 클로드는 소셜미디어, 레딧(Reddit), 기타 Cowork 고객 평가 사이트도 살펴보고, 가장 큰 통찰을 알려줘요.” 이 작업은 다소 시간이 걸릴 수 있습니다. 클로드가 실제로 엄청난 양의 데이터를 처리하고 가공해야 하기 때문입니다. 하지만 클로드는 때때로 서브 에이전트(sub-agent)를 파견해 병렬 처리를 수행하기도 하고, 인터넷 검색을 위해 시간을 투자하기도 합니다.
피터 양: 실제 업무에서, 여러분은 매주 통찰 보고서 같은 것을 자동으로 생성해 팀원들과 공유하는 방식을 사용하시나요?
제니:
사실 지금 당장 Cowork를 통해 바로 만들 수 있습니다. 연구원 중 한 명이 그런 보고서를 정기적으로 발송하고 있으며, 또 다른 버전은 Slack에서 우리를 @mention해 줍니다. 또한 우리는 내부 Slack 채널을 직접 듣고 있으며, 내부 구성원과 가장 강력한 사용자들로부터 선구적인 피드백을 얻는 데 매우 의존하고 있습니다. 왜냐하면 내부 구성원은 정말 솔직하게 말해 주며, 기능을 최대한까지 밀어붙이고, 따라가기도 가장 쉽기 때문입니다.
피터 양: 바로 이런 방식이야말로 진정으로 이루어져야 할 일이라고 생각합니다. 그리고 대부분의 기업에서는 팀 간에 너무나도 단절되어 있지만, Anthropic은 전혀 그렇지 않은 것 같습니다.
제니:
저도 그렇게 생각합니다. 바로 이 점이 Claude Code의 성공을 이끈 중요한 요소 중 하나인데요—현장 사용자의 목소리를 경청하는 것입니다. 또한 우리는 Figma 시절에도 이를 매우 적극적으로 실천했습니다. 내부 dogfooding(자체 제품 사용)을 대량으로 진행했는데요. 특히 인터랙션 디자인과 세부 조정과 같은 영역에서는 내부 구성원들이 정말 미세한 디테일까지 직접 탐색하기 때문입니다. 반면 외부 사용자는 보통 “이 기능이 자신의 사용자 프로세스에 맞는가?”라는 수준의 피드백만 제공하기 때문에, 완전히 다른 차원의 피드백을 얻을 수 있습니다.
Cowork vs Claude Code의 사용자 경계
피터 양: Anthropic의 마케팅팀과 제품 매니저들은 현재 거의 모두 클로드 코드를 사용하고 있고, 특히 코워크가 내부에서 사용 가능해진 이후부터는 더욱 그렇습니다. 그럼 각각 어떤 사용 사례가 있는지, 혹은 사람들이 코워크와 클로드 코드를 어떻게 다르게 활용하는지 말씀해 주실 수 있나요?
제니:
우리는 코워크의 전체 적용 범위가 점차 확대되고 있으며, 이제는 이전에 클로드 코드를 선도적으로 사용하던 사용자들이 시도했던 것과 유사한 선구적 시나리오에서도 활용되기 시작했다는 점을 눈여겨보았습니다. 코워크 개발 초기에, 내부 영업팀은 우리에게 주요 정보 출처였습니다. 그들 중 몇 명은 클로드 코드의 심층 사용자였으며, 잠재 고객 리스트를 생성하거나 전화 대본을 작성하는 데 이를 활용했습니다. 제가 처음 이러한 사용 사례를 접했을 때는 정말 놀랐습니다. 당시 저는 클로드 코드가 이런 작업까지 수행할 수 있을 것이라고는 전혀 상상하지 못했기 때문입니다. 그런데 지금은 이 사용자들이 거의 전부 코워크로 전환했고, 심지어 그들의 동료들도 코워크를 자주 사용하게 되었습니다.
이유는 지금 코워크에 멋진 UI가 있기 때문입니다. 그래서 이것이야말로 진정으로 필요한 것이었습니다. 또 하나의 이유는, 코워크가 그들이 이미 하고 있던 다른 업무와 매우 가까운 위치에 있기 때문입니다—그들은 원래 채팅 기능을 사용하고 있었고, 이 데스크톱 애플리케이션 안에서도 계속해서 클로드 코드를 사용할 수 있으므로, 명령줄(command line)을 여는 것보다 훨씬 그들의 기존 워크플로우에 부합한다고 느꼈습니다.
통찰에서 실행 가능한 산출물(Artifact)까지의 전체 프로세스
제니:
여기에는 일곱 가지 서로 다른 주제가 있으며, 매주 그 내용이 달라집니다. 저는 기본적으로 클로드에게 이렇게 말할 수 있습니다: “이 문서 X를 만들어줘. 그리고 이미 내 컴퓨터의 특정 폴더에 자동으로 저장돼 있어.” 또 두 개의 병렬 작업을 동시에 시작할 수도 있습니다. 예를 들어 이렇게 말할 수 있습니다: “이 통찰들은 정말 훌륭한데, 이를 바탕으로 실제로 어떤 제품 기능을 구축해야 할까?” 그리고 동시에 또 다른 작업을 병렬로 수행할 수도 있습니다—방금 클로드가 만들어 준 통찰 문서를 바탕으로, 이번 주 킥오프 미팅에서 팀과 공유할 수 있는 프레젠테이션을 만들어줘.
그러면 저는 바로 여기서부터 디자인 프로세스를 시작할 수 있습니다—클로드가 다양한 기능 옵션을 제시해 줄 것입니다. 여기서 더 나아가, 클로드가 이 기능들을 위한 와이어프레임(wireframe)도 만들어 줄 수 있습니다. 클로드는 여러 가지 다른 옵션을 제시해 줄 테고, 저는 이를 Figma로 가져가서 실제로 세부 조정을 하거나, 클로드 코드로 가져가서 우리 진짜 디자인 시스템 컴포넌트를 활용해 실제 제품으로 구현할 수 있습니다.
또한 저는 이 모든 작업을 정기 작업으로 설정할 수도 있습니다. 예를 들어, 매주 월요일 오전 10시에 자동으로 실행되도록 이 작업을 스케줄링해 달라고 요청할 수 있습니다. 그러면 저는 매주 월요일 오전 10시에 프레젠테이션과 세 네 가지의 제품 아이디어를 손에 쥔 채, 일주일을 시작할 수 있습니다. 이 방식은 피드백에서 구체적인 산출물(tangible thing) 또는 팀이 볼 수 있는 아이디어까지의 반복 주기를 극도로 짧게 압축해 주며, 제품을 빠르게 반복 개선하고 더 나은 제품으로 만드는 데 도움을 줍니다.
피터 양: 모든 것이 반복에 관한 것이고, 모든 것이 반복에 관한 것이죠. 저도 이제는 게을러졌습니다. 항상 AI에게 먼저 1차 버전을 만들어 달라고 한 후, 제가 그 위에서 반응하고 수정하죠.
제니:
네, 그렇습니다. 그래서 만약 제가 정말로 이 통찰들을 처음부터 기능 우선순위로 정리해 달라고 요청한다면, 지금은 예전보다 훨씬 더 오랜 시간이 걸릴 것입니다.
저도 그렇게 하고 있습니다. 예를 들어, 당신이 저에게 보낸 이 팟캐스트 노트를 보면, 저는 개인 노트 폴더를 가지고 있는데, 여기에는 1:1 미팅 내용, 잡다한 아이디어 등이 들어 있습니다. 그러면 저는 바로 이렇게 말합니다: “내 개인 노트를 읽고, 이 팟캐스트 발표의 핵심 포인트를 정리해줘. 그리고 여기서 내가 말하고 싶은 것도 함께 생각해줘.” 물론 저는 단어 하나하나를 그대로 읽지는 않지만, 클로드는 분명히 제 사고를 열어 주고, 제 생각을 진화시키는 데 도움을 주며, 막혀 있는 상태를 벗어나게 해줍니다.
Skills 및 개인 지식베이스
피터 양: 당신은 어떤 skills를 사용하시나요? 아니면 문서 및 프레젠테이션을 만들기 위해 개인 전용 skills를 따로 보유하고 계신가요?
제니:
우리는 내부적으로 문서 및 프레젠테이션 제작을 위해 전용으로 설계된 여러 개의 skill을 보유하고 있습니다. 이는 브랜드 일관성을 유지하는 데 도움이 됩니다. 저는 개인 전용 skill 라이브러리는 따로 보유하지 않으며, 대부분의 경우는 내부에서 이미 제공되는 skill을 빌려와 다양한 목적에 맞게 활용합니다.
피터 양: 예를 들어, 저는 writing skill을 하나 보유하고 있는데, 이 skill은 AI가 ‘AI slop’ 용어를 사용하지 않도록 지시합니다.
제니:
하지만 사실 저는 지금 Cowork의 폴더 기능—즉, 제가 모든 개인 노트 등을 저장하는 폴더—를 사용하면서, 클로드가 이 폴더들을 통해 저를 이해하는 방식이 이미 매우 유용하다고 느낍니다. 오히려 저는 memory와 skills가 점점 더 필요 없어지고 있다고 느낍니다. 왜냐하면 클로드가 이미 제 대한 지식베이스를 갖추고 있기 때문입니다. 물론 저는 skills가 특정 상황에서는 여전히 유효하다고 생각하지만, 제가 현재 사용하는 사례에서는 그 수요가 그리 크지 않다고 느낍니다.
피터 양: 매일 당신의 대화를 기반으로 자동으로 메모리를 업데이트해 주기 때문인가요?
제니:
네, 기본적으로 그것은 제가 직접 관리하는 메모리입니다. 왜냐하면 제가 계속해서 여기에 노트를 기록하고 있기 때문입니다.
팀 협업 시점
피터 양: 그렇다면 당신은 전체 프로세스에서 언제 팀을 끌어들이시나요? 즉, AI와 반복 작업을 한 후, 다시 팀과 반복 작업을 교차로 진행하시나요, 아니면 다른 방식으로 진행하시나요?
제니:
실제 UXR 인터뷰 같은 일은 제가 직접 하지 않습니다—그것은 제품 매니저나 팀 내 리서처, 또는 다른 팀원이 담당합니다. 그런 후, 바로 산출물을 공유하고 팀을 끌어들입니다. 그러면 이것이 바로 팀의 운영 근거가 됩니다.
우리 팀은 적어도 상당히 바텀업(bottom-up)이고 민주적인 편입니다. 따라서 우리의 운영 방식은, 통찰과 목표를 팀 전체에 공유한 후, 각자가 프로토타입을 만들고 시도해 보는 식입니다. 아이디어는 사방에서 나옵니다. 디자이너로서 제가 모든 해결책을 생각해 내는 것이 아니라, “이런 통찰이 있어요. 이것이 우리가 이번 달에 달성하고자 하는 목표예요. 우리가 어떻게 함께 이 목표를 달성할 수 있을까요?”라고 묻는 것입니다.
저는 이 방식을 통해 여전히 모든 것을 클로드에게 맡기지 않습니다. 우리는 여전히 많은 판단을 스스로 내리고, 진정으로 구축하고 실행할 것들을 관리하고 결정하는 능력에 의존합니다.
피터 양: 사람들이 온라인에서 ‘취향’과 ‘판단력’에 대해 이야기할 때, 저는 이 능력이 어떻게 배양되는지에 대해 생각해 봅니다. 바로 내부와 외부에서 지속적으로 많은 제품 피드백을 받아들이는 과정을 통해, 점차 문제를 감지하고 수정해야 할 부분을 직관적으로 파악하는 능력이 생깁니다. 매일 피드백을 듣고 처리하면서, 자연스럽게 문제에 대한 민첩한 판단력을 갖추게 되는 것이죠.
제니:
디자인 측면에서 클로드의 기능 중 하나는 와이어프레임(wireframe)과 유사한 스케치를 생성하고, 여러 디자인 옵션을 제시하는 것입니다. 저는 디자이너로서 이 방식을 매우 좋아합니다. 비록 이 스케치들이 세밀하지는 않지만, 다양한 가능성들을 직관적으로 볼 수 있게 해주며, 제 상상력에만 의존하지 않아도 된다는 점에서 큰 장점입니다. 이를 통해 저는 다음 디자인 방향을 더 빨리 결정할 수 있습니다.
따라서 클로드가 이러한 초기 옵션을 직접 생성해 주는 것으로, 제가 수작업으로 스케치를 만드는 데 드는 시간과 노력을 절약할 수 있습니다. 그런 후, 저는 이 옵션들 중 하나의 방향을 선택해 소규모 반복 작업을 시작합니다. 다음 단계에서는 이 방향을 코드로 구현해 초기 프로토타입을 만들고, 이를 기반으로 디자인을 계속 최적화하고 완성해 나갑니다.
Cowork 탄생의 진짜 이야기
피터 양: 이제 Cowork가 어떻게 탄생했는지 이야기해 주세요. 외부에서는 ‘10일 만에 만들었다’는 이야기가 많이 돌지만, 사실 그 이전에도 많은 반복이 있었을 텐데요?
제니:
“그들이 10일 만에 만들었다”는 말은 어느 인터뷰나 언론 보도에서 발췌된 문장입니다. 사람들은 이 점을 중심으로 계속 이야기를 나누고 있습니다. 하지만 실제 상황은 이렇습니다. 내가 1년 전 Anthropic에 입사했을 때부터 이미 Cowork라는 방향성에 대해 구상하기 시작했으며, 우리는 전통적인 지식 근로자 모두를 위한 ‘사고 파트너(thinking partner)’를 어떻게 만들어야 할지를 계속 고민해 왔습니다. 클로드 코드가 이미 코드 관련 작업을 훌륭하게 수행할 수 있긴 하지만, 우리의 목표는 모든 지식 근로 시나리오를 아우르는 것이다. 진정한 도전은 다음과 같다: 우리가 이 아이디어를 실제로 어떻게 실행할 것인가? 어떤 아키텍처가 가장 적합한가? 어떤 사용자 경험(UX)이 올바른가?
지난 1년간 우리는 다양한 프로토타입을 시도해 왔고, 그중 일부 아이디어는 현재의 목표보다 훨씬 더 야심 찬 것이었습니다. 또한 여러 AI 에이전트 프레임워크를 실험해 보았지만, 그중 일부는 실패했습니다. 결국 우리는 현재의 방향을 점차 확정지었습니다. 우리는 실험실 팀이 개발한 프로토타입뿐 아니라, 제품 팀 자체가 구축한 프로토타입도 참고했습니다. 결국, 시기와 실행력이 핵심이 되었고, 마치 번개가 정확히 목표를 맞춘 것처럼 되었습니다.
우리가 이 제품을 출시하기로 결정했을 때, 전체 과정은 매우 신속했습니다—“출시해야 한다”는 결정에서 “제품이 실제로 라이브되었다”는 순간까지 단 10일이 걸렸습니다. 이는 주로 클로드 코드 휴가 기간 동안 그 잠재력을 발견했기 때문입니다. 휴가 기간 동안, 많은 사람들이 마침내 클로드 코드를 시도할 시간을 가졌고, 기술 전문가가 아닌 사용자들까지도 그것을 사용하기 시작했습니다. 예를 들어, 팟캐스트 전사본(transcript)을 분석하거나 복잡한 데이터 분석을 수행하는 데 사용했습니다. 우리는 클로드 코드의 에이전트 프레임워크가 비기술 사용자들 사이에서도 초기 제품-시장 적합성(product-market fit)을 보이고 있음을 발견했습니다. 사실 당시 우리 내부에는 이미 작동 가능한 프로토타입이 있었고, 원래는 조금 더 늦게 출시할 계획이었지만, 이러한 피드백을 통해 “지금이 바로 최적의 시기”임을 깨달았습니다. 그래서 우리는 이 기회를 잡기로 결심했고, 결국 그 ‘광란의 10일’이 탄생했습니다.
피터 양: 제가 잘못 이해한 게 아니라면, 지난 1년간 여러분은 내부 Slack에서 많은 프로토타입을 공유했고, 광범위한 피드백을 수집해 결국 실행 가능한 프로토타입을 확정지었습니다. 그런 후 시장의 수요를 보고, 빠르게 집중된 개발을 통해 제품을 출시한 것이죠?
제니:
맞습니다. 우리가 원래는 몇 주 후에 출시할 계획이었지만, 당시 “지금이 바로 최적의 시기”라고 느꼈습니다. 이 인식은 시간이 촉박한 상황에서도 제품 범위를 더 현실적이고 실행 가능한 수준으로 좁히는 데 도움을 주었고, 전력으로 모든 자원과 노력을 투입해 결국 출시를 성공적으로 마쳤습니다.
초기 디자인 반복: 워크플로우 도구에서 극도로 단순한 채팅 인터페이스로
피터 양: 초기 반복 과정에서의 경험을 공유해주실 수 있으신가요? 혹은 개발 중인 콘텐츠를 보여주실 수 있으신가요?
제니:
물론입니다. 제가 특별히 초기 스크린샷을 정리해 왔습니다. 이를 통해 당시의 디자인 사고방식과 반복 과정을 보여드릴 수 있습니다.
올해 초, 우리는 초기 프로토타입을 만들었습니다. 이는 저와 또 다른 디자이너가 공동으로 완성한 것입니다. 당시 우리는 이 도구를 더 ‘태스크 중심(task-oriented)’ 또는 ‘워크플로우 중심(workflow-oriented)’으로 설계하려고 노력했습니다. 우리는 사용자가 Cowork와 같은 제품을 사용할 때, 구체적인 태스크를 완수하거나 명확한 결과(outcome)를 달성할 수 있을지에 대해 걱정했습니다. 예를 들어, 대시보드(dashboard)를 만들거나, 여러 출처에서 온 데이터를 통합하는 것 등입니다. 따라서 당시 사용자 인터페이스는 매우 구조화되어 있었고, 거의 워크플로우 도구처럼 보였습니다—예를 들어 “이 내용을 추가하세요. 이것은 입력(inputs)이고, 이것은 출력(outputs)입니다.”—반면 채팅 기능은 부차적인 위치에 있었습니다.
하지만 2025년의 지금, 왜 굳이 이렇게 많은 단계를 거쳐야 할까요? 그냥 클로드에게 맡기면 되지 않습니까?
이는 초기 디자인 방향 중 하나였지만, 이후 우리는 이를 더 단순하게 만들기로 결정했습니다. 즉, 단순한 채팅 박스(chat box)처럼 보이도록 했습니다. 우리는 이를 통해 사용자가 분석이나 문서 생성과 같은 더 구체적인 목표를 달성하도록 유도하려고 했습니다. 또한 기능적인 프로토타입을 설계했는데, 사용자가 클릭하면 다양한 옵션이 나타나고, 각 옵션에는 문서 길이를 조정하거나 메모 또는 프레젠테이션과 같은 문서 유형을 선택할 수 있는 버튼이 있었습니다. 그러나 이 디자인은 사용자에게 지나치게 복잡하고 압박감을 주는 느낌을 주었습니다.
따라서 여러 차례 탐색과 시도를 거치며, 우리는 명확한 사용 사례를 정의하는 것과 채팅 박스처럼 자유로운 형식을 유지하는 것 사이에서 균형점을 찾으려고 계속 노력했습니다.
결국, 우리가 몇 주 전에 출시한 버전이 지금의 모습입니다. 우리는 이전에 ‘마법사 모드(wizard-like)’의 사용자 경험을 시도하기도 했는데, 사용자가 클릭하면 “3~5페이지 분량의 문서를 생성하세요” 같은 안내가 나타났습니다.
당시 우리는 인터페이스에 많은 요소를 추가해, 일반적인 채팅 박스와는 다르게 보이도록 하려고 했습니다. 그러나 이후 이 디자인이 인터페이스를 지나치게 복잡하게 만들고, 시각적 요소들 간의 경쟁이 너무 치열하다는 점을 발견했습니다. 그래서 우리는 디자인을 단순화하기로 결정했고, 불필요한 요소들을 대부분 제거했습니다.
현재 보시는 사용자 인터페이스는 크게 단순화되었습니다. 우리는 무거운 사이드바(sidebars)를 제거해, 전통적인 채팅 박스에 더 가깝게 만들었습니다. 다만 홈 페이지에는 일부 변경을 가해, 이 인터페이스가 클로드와 제가 함께 공유하는 ‘할 일 목록(to-do list)’처럼 보이도록 했습니다. 복잡한 제안과 안내로 가득 찬 채팅 도구가 아니라 말입니다.
피터 양: 아마 미래에는 여러 에이전트(agent)를 지원하고, 작업을 드래그 앤 드롭하여 워크플로우를 관리할 수 있게 될지도 모르겠네요.
제니:
그럴 가능성도 있습니다. 하지만 강조하고 싶은 점은, UI 디자인이 약 4~5주 전만 해도 완전히 달랐다는 것입니다. 우리는 계속해서 무엇이 가장 효과적인 디자인인지, 무엇이 덜 효과적인지 배우고 있으며, 동시에 이 기술을 사용자에게 최적으로 제시하는 최선의 방식을 찾기 위해 노력하고 있습니다.
Cowork와 Claude Code의 차별화된 포지셔닝
피터 양: 클로드 코드를 사용하면서 저는 종종 트위터에 피드백을 공유합니다. 클로드 코드는 내장된 슬래시 명령어(slash commands)가 많아, 사용자가 하나씩 배워가야 합니다. 이 경험은 코스트코(Costco)에서 ‘보물찾기(treasure hunt)’를 하는 것과 비슷합니다. 언제 어떤 새 기능을 발견할지 아무도 모릅니다.
하지만 초보자에게는 이 방식이 그리 친절하지 않습니다. 이건 마치 게임처럼, 사용 시간이 늘어날수록 점차 익숙해지고 숙련도가 높아지는 방식입니다. 저는 코워크가 일반적인 채팅 도구와 클로드 코드 사이의 중간 지점을 탐색하려는 시도를 하고 있다고 느낍니다. 모든 기능을 숨기지 않으면서도, 사용자가 이를 더 잘 활용할 수 있도록 안내하는 방식을 추구하는 것이죠.
제니:
네, Cowork에서도 여전히 슬래시 명령어(slash commands)를 지원하지만, 그것들이 주된 상호작용 방식은 아닙니다. 개인적으로는 Cowork가 적어도 전문가를 대상으로 한 도구라고 생각합니다. 우리는 많은 사용자들이 이미 고도화된 사용자 방식으로 Cowork를 사용하고 있음을 관찰했습니다. 또한 커뮤니티 내에서는 이미 고도화된 사용자들이 등장하고 있습니다. 이 사용자들은 자신만의 스킬(skill)을 만들거나, 팀과 공유하거나, 약어 명령어(shorthand commands)를 사용하는 것과 같은 더 복잡한 기능을 배우는 데 시간을 투자할 준비가 되어 있습니다.
하지만 우리의 목표는 이러한 기능을 부차적인 상호작용 방식으로 두고, 필수적인 학습 내용으로 강제하지 않는 것입니다. 즉, 사용자가 모든 명령어를 알지 못하더라도 Cowork를 쉽게 사용할 수 있어야 한다는 것입니다. 우리는 사용자가 클로드와의 상호작용이 자연스럽고 직관적이기를 바라며, 일련의 명령어를 기억해야만 작업을 완료할 수 있도록 하지 않기를 원합니다.
계획 프로세스 및 비전
피터 양: Anthropic의 계획 프로세스는 어떻게 운영되나요? 연간 계획 및 목표 설정을 수행하나요? 아니면 프로토타입 개발과 지속적인 시도에 더 의존하나요?
제니:
우리의 계획 방식은 매번 다릅니다. 제가 속한 팀에서는 월간 계획을 수립합니다. 우리는 전자 스프레드시트를 사용하며, 적어도 Cowork 부분에서는 최대 약 12개의 작업을 P0(최우선)로 나열합니다. 각 작업에는 직접 책임자(DRI)가 지정되어 있으며, 우리는 매주 점검합니다: “우리는 여전히 올바른 방향으로 가고 있는가?” 또한 분기 또는 반기 계획도 수립하는데, 일반적으로 담당자가 이렇게 제안합니다: “우리는 이 방향으로 나아가야 하며, 이 사항들을 주의 깊게 살펴봐야 합니다.” 그러나 이러한 계획은 특정 프로젝트를 반드시 실행해야 한다는 엄격한 규정이 아닙니다. 더 많은 경우는 팀 전체에 방향성을 제공하는 데 초점을 맞추며, 따라서 비교적 유연합니다.
피터 양: 비교적 유연하군요. 흥미로운 점은, 가장 혁신적인 기업일수록 연간 계획을 덜 하고, 대신 지속적인 반복과 사용자로부터의 학습에 더 의존한다는 점입니다. 당신의 경력에서 North Star 비전 데크 같은 것을 만들어 본 적이 있나요? 그런 것이 유용하다고 생각하나요?
제니:
네, 실제로 만들어 본 적이 있습니다. 작년에 저는 North Star 비전 데크를 만들었습니다. 저는 비전이 분명한 가치가 있다고 생각합니다. 비전은 팀에게 방향을 제시해주고, 앞으로 진행될 작업에 대해 명확한 인식을 갖도록 도와줍니다. 하지만 우리가 속한 기술 분야는 변화가 극도로 빠르며, 새로운 모델이 끊임없이 등장하고 업데이트 속도 역시 점점 더 빨라지고 있습니다. 따라서 우리에게는 1년 단위의 비전을 수립하는 것조차 현실적이지 않으며, 2~5년 단위의 장기 비전은 더욱 그렇습니다. 너무 많은 불확실성이 존재하기 때문입니다.
그러나 비전의 진정한 역할은, 특히 모든 사람이 자유롭게 다양한 프로젝트를 구축할 수 있는 환경에서, 모두가 같은 방향을 향해 나아가도록 이끄는 데 있습니다. 그래서 저는 현재 비전의 시간 범위는 최대 3~6개월이 적절하다고 생각하며, 문서 형태로도 충분히 표현할 수 있다고 봅니다. 저는 비전이 시각화되었을 때 더 큰 영향력을 발휘한다고 생각합니다. 바로 이것이 디자인의 거대한 가치 중 하나입니다—다양한 요소를 하나로 통합해, 특정 기간 동안 일관된 이야기를 전달하는 것입니다. 물론 비전은 정적인 데크가 아니라 프로토타입일 수도 있습니다. 이는 특히 다섯 개의 팀이 매우 유사하거나 충돌할 수 있는 프로젝트를 다루는 상황에서 팀 간 협업을 조율하는 데 도움을 줄 수 있습니다. 디자인은 이러한 아이디어들을 큐레이션(curation)함으로써 일관된 방향을 제시하고, 이상적인 사용자 경험을 향한 길을 보여주는 데 기여할 수 있습니다. 분산된 경험 대신 말입니다.
피터 양: 그렇다면 제품 매니저 리뷰나 관련 인원 대상 리뷰는 어떻게 진행되나요? 이러한 리뷰는 공식적인가요? 아니면 그들도 프로토타입 설계에 직접 참여하나요?
제니:
우리는 실제로 리뷰를 진행하지만, 제가 이전에 근무했던 일부 기업처럼 모든 기능에 대해 리뷰를 요구하지는 않습니다. 우리의 리뷰는 주로 규모가 크고 우선순위가 높은 프로젝트에 초점을 맞춥니다. 리뷰의 목적은 시간을 많이 들여 준비하는 것이 아니라, 프로젝트의 가시성을 높이고 피드백을 얻는 데 있습니다. 만약 팀을 넘나드는, 회사 전체에 영향을 미치는 중요한 프로젝트라면, 우리는 그러한 리뷰를 진행합니다.
AI 시대에 디자이너가 자신의 위치를 찾는 법: 제안
피터 양: 그렇다면 자신의 직업 환경이 급속도로 변화하고 있다고 느끼는 디자이너들에게 어떤 조언을 해주실 수 있나요? 그들은 이제 코드 PR(풀 리퀘스트)을 제출하는 법을 배우기 시작해야 할까요? 아니면 디자이너가 변화에 적응하기 위해 다른 방식을 취해야 할까요?
제니:
당신이 발밑의 땅이 움직이고 있다고 느낀다면, 그것은 실제로 그렇게 변하고 있다는 뜻입니다. 우리는 이를 인정하고 적응해야 하며, 동시에 기존 업무 방식을 열린 마음으로 재검토해야 합니다. 저는 현재의 변화가 디자이너에게 특히 큰 영향을 미친다고 생각합니다. 왜냐하면 우리는 바로 이 물결의 두 번째 파도를 맞고 있기 때문입니다. 다른 직업군은 이미 유사한 전환을 겪어 왔고, 이제는 우리 차례입니다. 동시에, 우리의 디자인 도구 역시 끊임없이 진화하고 있습니다.
매번 제 직업이 위협받고 있다고 느낄 때, 저는 약간의 불안을 느낍니다. “천만에, 제 일이 극도로 변하고 있어요. 사람들이 제 일을 예전만큼 중요하게 여기지 않을지도 몰라요.” 하지만 그런 순간, 저는 항상 제 엔지니어 동료들을 떠올립니다. 그들의 업무는 이미 오래전부터 거대한 변화를 겪어 왔습니다. 그러나 그들은 이러한 변화에 단순히 적응한 것이 아니라, 놀라운 용기와 겸손함으로 도전을 맞이했고, 결국 더 효율적이고 탁월한 업무 성과를 달성했습니다. 그들은 바로 나의 영감의 원천입니다—나는 스스로에게 이렇게 말합니다: “이렇게 존경하는 동료들이 해낼 수 있다면, 나도 반드시 해낼 수 있다.” 그들은 나의 변화 적응 롤모델입니다.
피터 양: 어느 정도는 이러한 변화가 디자이너를 많은 번거로운 반복 작업에서 해방시켜 주는 것이죠. 예를 들어, 이제는 다양한 박스들을 조정하는 데 시간을 쓰지 않아도 되니까요. 그렇게 하면, 더 높은 수준의 사고와 창의적 작업에 더 많은 에너지를 집중할 수 있습니다.
제니:
맞습니다. 혹은 이러한 변화가 우리에게 더 많은 일을 해낼 수 있는 가능성을 열어준다고도 말할 수 있습니다. 예를 들어, 제 엔지니어 동료들이 이제는 며칠 만에 완전한 기능을 완성할 수 있다는 것을 보면, 예전에는 몇 주가 걸렸던 것과 비교해 정말 놀랍습니다. 따라서, 그렇습니다. 이러한 변화는 더 많은 가능성을 가져다줍니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
深潮TechFlow
