이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

요즘 디자이너들 사이에서 묘한 불안감이 퍼지고 있어요.

엔지니어들이 Claude Code로 에이전트 7개를 동시에 돌리며 기능을 쏟아내는데, 디자이너는 아직 목업을 만들고 있거든요. "디자인 프로세스를 믿어라"라고 배웠던 그 프로세스가, 엔지니어링의 속도 앞에서 무력해지고 있습니다.

Jenny Wen은 이 변화의 한복판에 있는 사람이에요.

Figma에서 FigJam과 Slides의 디자인 팀을 이끌다가 Anthropic으로 건너와 Claude Co-work의 디자인을 맡고 있죠.

그녀가 베를린 컨퍼런스에서 "디자인 프로세스를 믿지 마라"라는 제목으로 강연한 지 불과 3~4개월 만에, 본인이 그 강연이 이미 구식처럼 느껴진다고 말할 정도로 변화의 속도가 빠릅니다.

디자인 프로세스의 종말

Q. AI 시대에 디자인 프로세스가 어떻게 바뀌고 있나요?

많이 바뀌고 있어요. 그리고 아직 갈 길이 멀다고 생각해요.

솔직히 말하면, 지난 몇 달간 엔지니어링 쪽이 디자인보다 훨씬 더 많이 바뀌었어요. 그런데 엔지니어링이 바뀌면 디자인도 어쩔 수 없이 따라 바뀌게 되거든요.

작년 9월에 베를린 컨퍼런스에서 강연을 하나 했는데, 제목이 "디자인 프로세스를 믿지 마라"였어요. 디자이너들이 배워온 그 프로세스 있잖아요. 리서치하고, 디스커버리(발견 단계)하고, 발산하고 수렴하고, 또 발산하고 수렴하고.

우리가 거의 복음처럼 따르던 프로세스인데, 이게 이제 사실상 끝났다는 얘기를 했어요. AI 시대 이전에도 서서히 죽어가고 있었는데, 이제 엔지니어들이 자기들의 Claude 에이전트를 7개씩 돌릴 수 있게 되면서, 디자이너로서 그 프로세스를 정말로 놓아야 할 때가 왔다고 봐요.

그런데 그 강연을 한 지 3~4개월밖에 안 됐는데, 벌써 그 강연이 좀 구식처럼 느껴져요. 솔직히 약간 민망하기도 하고요.

특히 Opus 4.6이 나오고, 연말 연휴 동안 정말 많은 사람들이 Claude Code를 발견하고 쓰기 시작하면서, 프로세스를 바꿔야 한다는 압력이 훨씬 더 강해졌어요.

Q. 그러면 지금 디자인 업무는 구체적으로 어떤 모습인가요?

지금 디자인 업무는 크게 두 종류로 나뉘고 있어요. 상당히 뚜렷하게 층이 갈리고 있죠.

첫 번째는 실행과 구현을 지원하는 일이에요.

엔지니어들이 자기들의 Claude 에이전트 7개로 기능을 계속 만들어내고, 누구든 아이디어를 내면 — 보통은 엔지니어가, 아직은 우리보다 구현을 더 잘하니까 — 바로 대충이라도 만들어서 써볼 수 있거든요. 이런 환경에서 디자이너가 예쁜 목업을 만들 시간이 없어요. 예전처럼 디자이너가 리드하는 방식이 어려워진 거예요.

두 번째는 비전이나 방향을 제시하는 일이에요.

이건 여전히 정말 중요한데, 형태가 많이 바뀌었어요. 예전에는 2년, 5년, 심지어 10년짜리 비전을 만들곤 했거든요. 그런데 지금은 기술이 너무 빠르게 바뀌어서, 2년 뒤에 뭐가 될지 아무도 몰라요. 그래서 비전이라는 게 3~6개월 앞을 내다보는 정도가 되었고, 아름답게 스토리텔링된 덱을 만드는 게 아니라 그냥 사람들이 올바른 방향으로 가도록 가리키는 프로토타입을 만드는 거예요.

이 두 번째 종류의 일이 지금 세상에서 특히 중요한 이유가 있어요.

사람들이 각자 에이전트를 7개씩 돌리면서 아무 방향으로나 기능을 만들 수 있잖아요. 그러면 누군가는 방향을 가리켜야 해요. 우리 모두가 하나의 큰 목표를 향해 만들어야 효율적이니까요. 각자 랜덤한 걸 만드는 것보다 훨씬 낫죠.

Q. 그러니까 디자인 분야 스스로 "우리 바뀌어야 해"라고 한 게 아니라, 엔지니어링 속도가 강제로 바꿔놓은 건가요?

맞아요. 디자이너들 사이에서 "우리 지금 당장 바뀌어야 한다"는 하나의 통일된 목소리가 있는 건 아니에요. 엔지니어링 도구가 바뀌면서 생긴 후속 효과에 가까워요. 디자인 도구도 아마 올해 안에 많이 바뀔 거라고 생각하는데, 지금은 아직 뒤처져 있는 상태예요.

동시에 디자이너에게도 힘을 실어주는 부분이 있어요. 우리도 이제 이 코딩 도구들에 접근할 수 있거든요. 엔지니어에게 의존하지 않고 직접 코드로 프로토타입을 만들 수 있게 됐고, 라스트 마일(마지막 마무리 작업) — 폴리시(디테일 다듬기)를 직접 구현하면서 엔지니어와 아주 가까이 협업하고 있어요.

Q. 이런 변화가 Anthropic 같은 AI 최전선 기업에서만 일어나는 건가요? 다른 회사에서도 비슷한가요?

제가 작년에 한 강연이 의외로 제가 해본 강연 중에서 가장 공감을 많이 받았어요. 업계 전반에서 사람들이 느끼기 시작한 것 같아요. "아, 예전 디자인 프로세스로는 더 이상 안 되겠다"고요. Claude Code나 v0 같은 도구로 프로토타입을 만들기 시작한 사람들이 있고, PM들도 프로토타입을 직접 만들기 시작했고요.

그런데 흥미로운 점은, 반발도 꽤 있었어요. 자기 커리어 전체를 이 안정적인 디자인 프로세스를 배우고 가르치고 사용하는 데 투자한 사람들이 있잖아요. "디스커버리 없이는 안 돼", "이 프로세스의 이 부분은 빠뜨릴 수 없어" 같은 반박이 꽤 있었어요. 그래서 업계의 일부는 아직 이 일하는 방식에 도달하지 못한 상태예요.

Q. 그러면 빠르게 출시하고 반복하는 방식이 실제로 더 나은 제품을 만드나요? 아니면 그냥 다들 그렇게 하니까 따라가는 건가요?

상황에 따라 판단해야 한다고 생각해요. 하지만 빠르게 실행해서 실제 데이터로, 실제 사용자 관점으로 제품 안에서 뭔가를 시도해보는 능력, 이게 더 나은 제품으로 이어진다고 봐요.

특히 지금 우리 모두가 비결정적(non-deterministic, 같은 입력에 매번 다른 결과가 나오는)인 AI 모델을 다루고 있잖아요. 모든 상태를 목업으로 만들 수가 없어요. 이론화할 수도 없고, 클릭 가능한 프로토타입조차 만들기 어려워요.

실제 모델을 깔고 사람들이 자기 유스 케이스(사용 사례)로 써보게 해야 해요. 이런 모델은 특정 유스 케이스를 위해 디자인할 수 있지만, 사람들이 실제로 쓰는 걸 보면서 새로운 유스 케이스를 발견해야 하거든요.

Anthropic 디자이너의 하루

Q. Anthropic에서 디자이너로 일하는 건 어떤 느낌인가요? 하루 일과가 궁금합니다.

Anthropic에서 상당한 시간을 회사 안에서 무슨 일이 벌어지고 있는지 파악하는 데 쓰고 있어요. 이 규모의 회사에서 몇 군데 일해봤는데, 여기는 정보의 양도 많고 진행되는 일도 많지만, 따라가고 싶다는 의지가 정말 강하게 들어요.

리서치 팀에서 모델 개발 관련 일이 있고, 어느 순간이든 정말 다양한 팀이 서로 다른 아이디어를 프로토타입하고 시도하고 있어요. 코드 네임도 잔뜩 있고요. 저는 그 프로젝트들이 뭔지 파악하려고 돌아다녀요. "앞으로 나한테 뭐가 올까"를 미리 감지하려는 거죠. 리서치 팀뿐 아니라 리서치에 더 가까운 랩스(Labs) 팀에서 프로토타입하고 시도하는 것도 있고요.

그리고 그냥 직접 써보고 싶은 것들이 있어요. 내부에 사용할 수 있는 프로토타입과 제품이 여러 개 있는데, 그냥 궁금해서 써보는 거예요.

또 사내에서 업계 방향에 대한 인사이트와 의견을 많이 가진 분들이 계시는데, 그 글들이 정말 흥미로워요. 철학적 논쟁이나 회사 방향에 관한 것들이라서요. 보통 회사에서는 "이건 내 손이 닿지 않는 일이니까 신경 안 써도 돼"라고 생각할 텐데, 여기서는 양도 양이지만 일어나는 일의 종류 자체가 너무 흥미로워서 계속 따라가고 싶어져요.

Q. 그 Slack 정보가 그렇게 가치 있는 건가요?

Anthropic Slack은 금광이에요. 사람들이 뭘 만들고 있는지, 뭘 생각하는지 읽는 게 정말 재미있어요. 아마 최고의 AI 뉴스는 이런 AI 회사 내부 Slack에 있을 거예요. 바깥에서 AI 뉴스를 따라가는 것도 힘든데, 실제로 랩 안에서 벌어지고 있는 걸 보는 건 완전히 다른 차원의 피드죠.

Q. 내부 파악 말고 나머지 시간은 어떻게 쓰나요?

전통적인 디자인 작업도 여전히 해요.

예를 들어 이번 주에는 시간을 따로 잡아서 "앞으로 3개월은 어떻게 될까, 시장 상황과 모델 수준을 감안하면 어디까지 갈 수 있을까"를 생각하는 시간을 가졌어요. 이걸 시각화해서 팀에게 보여주고 같은 방향을 가리키는 건 여전히 중요하거든요.

그리고 하루의 상당 부분을 엔지니어와 함께 잼(jam, 자유롭게 아이디어를 주고받는 것)하면서 보내요. 대화하거나, 화이트보드 하거나, 엔지니어가 만든 걸 보면서 피드백을 주는 식의 컨설팅이에요.

또 하루 중 일부는 직접 코드를 써요. 폴리시 작업이나 구현을 하는 거죠. 엔지니어와 같이 뭔가를 작업하면, 엔지니어가 1차 버전을 만들고 제가 들어가서 같이 다듬어요. 이 부분이 몇 달 전만 해도 없던 일인데, 제 업무 중에서 정말 재미있는 파트가 됐어요.

Q. 전통적인 디자인 프로세스 — 프로토타이핑, 사용자 리서치, 패널 조사 같은 건 아예 안 하나요?

다 하고 있어요. 어느 정도는요.

팀에 사용자 리서치 담당자가 있고 전통적인 연구도 하고 서베이(설문조사)도 하고 있어요. 프로토타이핑도 하고, 목업도 여전히 만들어요. 다만 이제 도구가 더 다양해졌고, 각 활동에 쓰는 시간의 비율이 달라진 거예요.

Q. 예전과 지금의 시간 배분이 구체적으로 어떻게 달라졌나요?

몇 년 전 디자이너로서 시간 배분을 보면, 60~70%가 목업과 프로토타이핑이었어요. 그다음 20% 정도가 엔지니어와 잼하고 컨설팅하는 거고, 나머지 10% 정도가 미팅 같은 조율 업무였죠.

지금은 목업이 30~40%로 줄었어요. 그리고 또 다른 30~40%가 엔지니어와 직접 페어링하고 잼하는 거예요. 거기에 더해서 — 남은 비율이 얼마인지 모르겠지만 — 직접 구현하는 일, 빌드하고 실제로 배포하는 일이 새로 생겼어요.

디자이너의 AI 스택

Q. 디자이너로서 어떤 AI 도구를 쓰고 있나요?

Claude 스택을 깊이 파고들고 있어요. Claude Chat을 쓰고 있고, 점점 더 많이 Claude Co-work으로 옮기고 있어요. 사실상 채팅으로 하던 유스 케이스를 전부 Co-work으로 전환했어요. 제가 Claude에 물어보던 것들이 대부분 오래 걸리는 작업이었는데, Co-work이 그런 작업에 더 잘 맞거든요.

그리고 Claude Code도 쓰는데, 주로 VS Code IDE 안에서 써요. 보통 프런트엔드 코드를 수정하는 일이라 코드를 직접 보면서 Claude와 대화할 수 있는 게 편하거든요.

최근에는 Claude Code를 모바일이나 Slack에서 원격으로 쓰는 것도 시도하고 있어요. 누군가 "이 아이콘 하나 어긋나 있어"라고 하면, Slack에서 Claude를 멘션하면 Claude가 고쳐주고, PR을 열어두면 그냥 승인하면 끝이에요. 이게 정말 재미있어요.

Q. 디자이너로서 Figma는 아직 쓰고 있나요? 요즘 "코드가 디자인의 미래다, Figma는 필요 없다"는 논쟁이 있잖아요.

Figma 여전히 쓰고 있어요. 전 Figma 출신이라 편향이 있을 수 있지만, Figma를 쓸 때 "맞아, 이걸 써야 해"라는 느낌이 아직 확실히 있어요. 여전히 좋은 빈자리를 채워주거든요.

가장 큰 이유는 다양한 옵션을 탐색하는 거예요. 하나의 문제에 대해 8~10가지 다른 방법을 생각해보는 게 디자인에서 정말 중요한 부분이거든요. 가장 좋은 디자인은 아이디어를 잔뜩 벽에 던지고, 큐레이션하고, 스스로를 밀어붙여서 다양한 방향을 내놓을 때 나와요.

지금 코딩 도구로는 이게 잘 안 돼요. 너무 선형적이에요. 하나의 방향에 깊이 투자해서 Claude와 계속 반복하는 식이거든요. 그래서 Figma는 여전히 다양한 옵션을 탐색하는 데 정말 좋아요. 그리고 세밀한 시각적, 인터랙션 디테일도 마찬가지예요. 다양한 타이포그래피나 스타일을 캔버스에서 탐색할 수 있는 게 여전히 유용하고, 항상 바로 코드로 가고 싶지는 않거든요.

Q. 엔지니어링에서는 IDE보다 커맨드라인과 에이전트 쪽으로 가고 있는데, 디자이너로서 아직 IDE를 쓰는 게 흥미롭네요.

프런트엔드 코드를 수정할 때는 CSS 값 하나, 색상 하나 바꾸는 거잖아요. 에이전트한테 "이 클래스를 저 클래스로 바꿔줘"라고 말하는 것보다 그냥 직접 들어가서 바꾸는 게 훨씬 빠르거든요. 어쩌면 IDE가 이제 디자이너와 PM에게 유용한 도구가 되고, 엔지니어는 이미 그걸 넘어선 건지도 모르겠어요.

엔지니어와 협업하는 법

Q. 엔지니어들이 쏟아내는 결과물을 따라잡으면서 디자인 퀄리티를 유지하는 방법이 있나요?

엔지니어와 프로젝트를 같이 할 때, 컨설팅 형태로 일하면서 제가 왜 이렇게 생각하는지를 설명하려고 해요. 그냥 "이건 여기 있으면 안 돼"라고 하는 게 아니라, "여기에 버튼이 있어야 하는 이유는, 모든 사람이 여기서 프롬프트를 입력할 수 있다는 걸 알아채는 게 아니거든요. 리서치에서 나온 예시가 이런 거예요"라는 식으로요. 원칙을 추출할 수 있게 도와주는 거죠.

그리고 디자인 시스템 같은 것을 엔지니어에게 적극적으로 알려줘요. 지금 Claude가 코드를 많이 쓰고 있는데, 항상 디자인 시스템에 있는 컴포넌트를 가져다 쓰는 건 아니거든요. 제가 나중에 없어도 쓸 수 있는 것들을 최대한 갖춰주는 거예요.

따라잡는 게 힘든 건 사실이에요. 엔지니어뿐 아니라 디자이너 모두가 느끼는 거예요. 이제 우리가 할 수 있는 게 많아지니까 더 많이 하고 싶어지거든요.

디자이너만 엔지니어를 따라잡으려는 게 아니에요. 엔지니어도 "우리가 우리 자신을 어떻게 따라잡지?"라고 말하고 있어요. "우리 에이전트 7개가 계속 돌아가는데 어떻게 따라가지?"라는 거죠.

속도로 신뢰를 쌓는 법

Q. 제품이 하루에 수천 번 배포되는 상황에서 크래프트(장인 정신)와 퀄리티, 신뢰는 어떻게 유지하나요?

디자이너가 안 끼는 건 아니에요. 디자이너 한 명이 감당하기엔 너무 많은 거죠.

저는 기능이나 제품이 채택 사이클(도입 주기)에서 어디에 있는지를 생각해요. 초기 프리뷰 단계인지, 이미 안정된 제품인지에 따라 다르게 접근하는 거예요.

예를 들어 Claude Co-work을 출시할 때 '리서치 프리뷰(초기 연구 단계)'라는 라벨을 붙였어요. "이건 초기 단계이고 결함이 있을 거다"라고 충분히 설명했죠. 우리 모델과 비슷해요. "이게 역대 최악의 버전이지만, 내부에서 써본 결과 정말 강력한 뭔가가 있어서, 혜택이 단점을 넘는다고 판단해서 내놓는 거다"라고요. 가장 쓰기 쉽지 않을 수 있고, 퀄리티가 최상이 아닐 수 있지만요.

단, 사용자에게 반드시 해야 하는 약속이 있어요. "우리가 피드백을 받을 거고, 반복해서 개선할 거고, 더 나아지게 만들겠다"는 거예요. 그 약속을 지켜야 해요. 피드백에 응답하고, 계속 배포하고 개선하는 모습을 보여줘야 해요.

초기에 내놓고 나서 아무 일도 안 일어나면, 그때 브랜드가 진짜 훼손되는 거예요. 하지만 초기에 내놓더라도 계속 개선하는 걸 보여주면 브랜드를 유지할 수 있어요.

Q. '속도로 신뢰를 쌓는다'는 표현을 쓰셨는데, 구체적으로 어떻게요?

속도로 신뢰를 쌓는 것도 있지만, 사람들이 자기 목소리가 들렸다고 느끼게 하는 거예요. 우리가 피드백을 기반으로 고치고 있고, 그들의 피드백이 실제로 감사히 여겨지고 활용되고 있다고요.

Anthropic 팀이 뭔가를 출시하면, 팀원 모두가 트위터에서 직접 응답하고 댓글을 달고, "어제 이거 고쳤습니다, 이건 곧 됩니다"라고 알려주거든요. 그러면 사용자 입장에서 "아, 이건 오늘의 문제일 뿐이고 금방 고쳐질 거야"라는 확신이 생겨요. Claude Code가 코드를 빨리 쓸 수 있으니까, 수정도 정말 빠르게 나오고요.

AI가 디자이너를 대체할까

Q. AI가 점점 똑똑해지는 상황에서, 인간의 뇌가 계속 가치 있을 영역은 어디라고 보나요? AI가 취향과 판단, 디자인도 잘하게 될까요?

AI가 취향과 판단, 디자인에서 더 나아질 거라고 생각해요. 우리가 "디자이너나 누군가가 항상 최고의 결과를 알 거야"라고 너무 붙잡고 있는 것 같아요.

하지만 결국 누군가는 실제로 뭘 만들 건지, 뭐가 중요한지를 결정해야 해요.

"AI가 소프트웨어를 만들어줄 거야"라고 말하는 사람들이 있는데, 소프트웨어를 만드는 데서 진짜 어려운 부분은 만드는 것 자체가 아니거든요. 직장에서 가장 힘들었던 때를 생각해보면, 아마 누군가와 "이 기능에 뭘 넣어야 하냐"를 놓고 의견이 갈렸던 때일 거예요. 이런 건 AI가 의견을 낼 수 있지만, 두 사람 사이의 분쟁을 해결해주진 못해요.

우리가 만드는 것에 뭘 넣을지를 결정하는 일 — 그게 어떤 의미에서는 취향이지만, 미학적 취향이라기보다는 "다음에 뭘 해야 하는가"에 대한 판단이에요.

Q. AI가 코딩을 장악하는 속도를 보면, 1~2년 전에 "AI가 이렇게 잘할 리 없다"고 했던 가정이 다 틀렸잖아요. 디자인 판단도 결국 AI가 해내지 않을까요?

맞아요. 세계 최고의 엔지니어들이 코드를 더 이상 직접 보지도 않을 만큼 AI를 신뢰하는 수준까지 왔잖아요. 그걸 보면 저도 "AI가 정말 좋은 PM이나 디자이너만큼 판단하고 결정하는 데 절대 못 미칠 거야"라는 가정을 재평가하게 돼요. AI가 거기까지 갈 것 같아요.

AI가 의견이 갈리는 두 사람에게 "여기 결정에 필요한 모든 데이터가 있고, 이게 정답인 이유는 이거예요. 1번을 누르면 제가 바로 만들겠습니다"라고 할 수 있는 날이 올 거예요.

Q. 그래도 디자이너, PM, 엔지니어는 여전히 필요하다고 보시나요?

네, 누군가는 여전히 결정을 내려야 하고, 그 결정에 책임(accountability)을 져야 하거든요.

Claude가 코드를 다 써줘도 그 코드가 실제로 작동하는지, 제품에서 말이 되는지는 여전히 엔지니어가 책임지잖아요. 그런 의사결정과 판단의 레이어가 있어요. 언젠가는 우리가 안 해도 될 수 있지만, 아직은 우리 몫이에요.

방사선과 의사 비유가 떠올라요. AI가 방사선과 분야를 대체할 거라는 말이 계속 있었잖아요. 하지만 인간이 주로 유용한 이유는 결정에 서명하는 거예요. 누군가가 틀렸을 때 책임을 져야 하니까요. 최고의 직업은 아니지만, 건강 분야와 코드 분야는 판돈이 다르긴 하죠.

챗봇은 사라지지 않는다

Q. 챗봇과 터미널이 AI의 최종 인터페이스라고 생각하나요? 다음 단계가 있을까요?

둘 다 공존할 거예요. 클릭하고 만지는 UI와, 대화하는 인터페이스 둘 다요.

Claude 안에서도 이미 이걸 실험하고 있어요. 최근에 위젯을 여러 개 출시했는데, Claude가 질문을 던지거나 날씨, 주식 같은 걸 인터랙티브하게 보여주는 거예요. 반응이 정말 좋았어요. 사람들은 여전히 UI를 보고 터치하고 클릭하고 싶어하고, 그게 타이핑보다 훨씬 효율적인 경우가 있으니까요.

동시에 챗봇 패러다임에 정말 기대했을 때, 이전에 고정된 UI로는 불가능했던 무한한 유연성의 세계가 열렸어요. 그래서 제 판단은 이래요. 채팅은 절대 사라지지 않을 거예요. 컴퓨터와 대화하는 이 새로운 방식이 전에는 없었으니까요. 하지만 아주 구체적인 특정 기능에 대해서는 여전히 UI가 가장 직접적이에요. 그리고 그런 UI들이 점점 더 모델이 직접 생성하게 될 거라고 봐요. 우리가 하나하나 직접 코딩하는 게 아니라요.

재미있는 건, OpenAI든 Claude든 MBot이든 최근 큰 혁신 중 하나가 WhatsApp이나 Telegram, SMS로 채팅할 수 있게 된 거예요. 또 다른 형태의 챗봇이지만, "아, 그냥 WhatsApp으로 물어볼 수 있구나"가 큰 경험이 된 거예요. 사람은 원래 대화하는 존재잖아요. 이제 그 대화 상대에 컴퓨터가 추가된 거죠.

매니저와 IC 사이에서

Q. Figma 디자인 디렉터에서 Anthropic IC(개인 기여자)로 돌아간 이유가 뭔가요?

Anthropic에 처음에는 IC로 합류했어요. 여기서 IC로 할 수 있는 일이 정말 흥미로웠고, 일에 가까이 붙어 있고 싶었거든요. 또 미들 매니지먼트(중간 관리직)가 미래에 안전한가에 대한 의문도 있었어요. "이 일하는 방식이 앞으로도 계속 존재할 직업일까, 아니면 다른 걸 시도해보고 직접 실무에 뛰어들어야 할까"라는 생각이 있었죠.

솔직히 매니징과 IC 양쪽 다 좋아해요. 팀을 세팅하고 사람들을 관리하는 것도 좋고, IC로 직접 만드는 것도 좋아요. 원래 좀 마지못해 매니저를 시작한 타입이었거든요.

그런데 이 1년간 IC를 하면서 깨달은 게, 매니징만 했으면 절대 얻지 못했을 하드 스킬(실무 기술)을 엄청나게 쌓았다는 거예요. 디자인 프로세스가 이 1년 동안 정말 많이 바뀌었는데, 직접 겪었으니까 이해하는 거예요. 나중에 다시 팀을 이끄게 되면, 이 경험이 공감대와 이해를 줄 거예요. 이 환경에서 직접 일하지 않았으면 뭘 해야 하는지, 팀을 어떻게 가이드해야 하는지 몰랐을 거예요.

Q. Figma에서 팀이 얼마나 컸나요?

최대 12~15명 정도의 디자이너가 있었고, 매니저 몇 명도 두고 있었어요.

Q. 디자인 매니지먼트라는 직업은 장기적으로 살아남을까요?

사람들로 이루어진 팀이 있는 한, 매니징하는 사람이 있는 건 도움이 돼요. 다만 매니저의 형태가 바뀌고 있다고 생각해요. 순수한 피플 매니지먼트 — 1 on 1 하고, 커리어 관리하고, 기분 확인하는 것 — 이것만으로는 더 이상 충분하지 않아요.

지금 매니저에게 필요한 건, 팀에 방향을 제시하면서 동시에 피플 매니지먼트도 하는 거예요. 이 두 가지가 결합된 형태가 적어도 현재로서는 매니지먼트의 미래라고 봐요. 팀의 업무에 실질적으로 관여하면서 방향을 제시하고, 동시에 팀이 최선의 결과를 낼 수 있는 환경을 만드는 사람이요.

Q. 디자인 매니저들을 위한 조언이 있다면요?

IC로 돌아가는 걸 진지하게 고려해보라고 말하고 싶어요.

엔지니어링에서는 원래 EM(엔지니어링 매니저)이나 디렉터를 채용할 때, 몇 달 동안 직접 태스크를 수행하면서 기술이 어떻게 돌아가는지 파악하는 로테이션을 시키는 곳이 있거든요. 디자인도 비슷한 걸 해야 한다고 봐요. 지금까지 디자인은 피플 매니지먼트에 좀 더 치우쳐 있었는데요.

제가 IC로 돌아가서 가장 녹슬었다고 느낀 건 크릿(crit, 디자인 비평 세션)이었어요. 비판을 받는 거요. 작업을 팀 앞에서 공유하고 비판적 피드백을 계속 받는 게 꽤 취약한 경험이거든요. 매니저로 있다가 다시 그걸 하니까 "아, 맞다" 싶었어요.

Co-work은 어떻게 태어났나

Q. Co-work의 최종 형태에 도달하기까지의 과정을 들려주실 수 있나요? Boris가 팟캐스트에서 "결국 터미널을 제품 안에 넣자"고 결론이 났다고 했는데요.

Co-work은 내부에서 정말 다양한 프로토타입을 거쳤어요. 많은 걸 시도했는데, 실제로 언제 출시할 준비가 되는지가 확실하지 않았어요. 그러다가 한 번에 모든 게 맞아떨어졌죠. "좋아, 곧 출시하자"가 된 거예요.

"10일 만에 만들었다"는 말이 바이럴이 됐는데, 정확히 말하면 내부에 있던 것을 외부 출시 가능한 수준으로 올리는 데 10일이 걸린 거예요. 그 전에 오랫동안 만들고 있었지만 정확한 형태가 정해지지 않았었죠.

다양한 에이전트 하네스(agent harness, AI 에이전트를 구동하는 기반 프레임워크) 위에 여러 탐색을 했고, Co-work에 들어간 인터랙션들의 작은 부분들을 각각 프로토타입했었어요. Claude가 할 일 목록을 보여주는 형태, 객관식 질문을 제시하는 형태, 유스 케이스를 알려주는 방법 등등 다양한 폼 팩터(형태)를 시도했어요.

최고의 폼 팩터를 찾았다고 확신하지는 않지만, 내부에서 사람들이 좋아했던 것들을 그냥 내보내자는 거였어요. 외부에서 더 많은 신호를 얻기 위해서요. 그 10일 동안에는 있는 걸 최대한 꺼내서 거기서부터 반복하자는 마인드였어요. 그리고 실제로 그렇게 하고 있고요.

사실 Co-work이라는 아이디어 자체가 한 번에 나온 건 아니에요. 계속 반복해서 올라왔는데, 한 번도 맞는 타이밍이 아니었거나 조금씩 다른 변형이었다가, 갑자기 맞는 순간이 온 거예요.

다 되고 나면 처음부터 당연했던 것처럼 느껴지지만, 거기까지 오는 여정은 정말 길었고 많은 사람이 관여했어요. 출시하자마자 인터넷에서 폭발적인 반응이 왔으니까 결과적으로 잘된 거죠.

Q. Co-work에서 가장 자랑스럽거나 빨리 고치고 싶은 기능이 있나요?

솔직히 가장 자랑스러운 건 출시 자체예요. 그냥 세상에 내놓은 것 자체가요. 디자이너로서 오래 작업하면 결함만 보이거든요. "이게 좋아"라고 딱 말하기 어려운데, 출시한 것 자체는 자랑스러워요.

기대되는 건, 홈페이지를 계속 개선하고 있는데, 점점 더 "이건 Claude에게 줄 수 있는 할 일들이고, Claude가 작업 중인 태스크들"이라는 느낌을 주려고 하고 있어요. Claude와 사용자 사이의 공유 할 일 목록 같은 거요. "이건 Claude가 작업 중, 이건 사용자의 확인이 필요함" 같은 형태요.

그리고 Co-work의 진짜 폼 팩터에 대해서도 더 생각해보고 싶어요. 항상 화면에 고정되어 있는 건지, 작업하는 다른 화면들로 자연스럽게 뻗어나가는 건지요.

디자인 채용의 새로운 기준

Q. 이렇게 역할이 바뀌는 상황에서, 디자이너 채용 시 새롭게 중요해진 것은 뭔가요?

우선 이런 환경에서 일하려면 회복탄력성(resilience)과 유연함이 필요해요. 주변이 계속 바뀌니까 새로운 방법과 도구를 기꺼이 시도하고 배우려는 자세가 중요하죠.

그 다음, 지금 제 눈에 특별히 흥미로운 세 가지 유형의 사람이 있어요. 예전에도 흥미로웠지만 이 시대에 특히 중요해졌어요.

첫 번째는 강한 제너럴리스트(strong generalist)예요.

그냥 이것저것 좀 하는 일반적인 제너럴리스트가 아니라, T자형 프레임워크에서 거의 블록 모양에 가까운 사람이에요. 핵심 스킬 몇 가지에서 상위 80% 수준으로 뛰어난 사람이요. 상당히 드물고 채용하기 어려워요. 하지만 디자인 역할이 이미 PM 방향으로, 엔지니어링 방향으로 뻗어나가고 있잖아요. 여러 버킷에서 이미 강한 스킬이 있으면 역할을 유연하게 확장하기가 정말 쉬워요.

두 번째는 깊은 스페셜리스트(deep specialist)예요.

T자형에서 T의 아랫부분이 다른 사람보다 훨씬 깊이 내려가는 사람이요. 업계 상위 10% 정도. 예를 들어 소프트웨어 엔지니어의 50%쯤 되는 수준으로 기술적인 디자이너가 있어요. 지금 우리는 모델과 직접 작업하니까, 깊은 엔지니어링 전문성이 있으면 정말 도움이 돼요. 또는 비주얼 디자인이나 아이콘 디자인 같은 데서 정말 깊은 스페셜리스트도 있죠. 누구나 뭐든 만들 수 있는 시대에, 그런 깊은 전문성이 우리가 만드는 것을 차별화하는 데 도움이 되거든요.

세 번째는 제가 유능한 신입(craft new grad)이라고 부르는 유형이에요.

이걸 많은 사람이 간과하고 있다고 생각해요. 커리어 초기인데 경험치 이상으로 현명하고, 겸손하면서 배우려는 열의가 강한 사람이에요. 대부분의 회사가 시니어만 찾고 있는데, 역할과 기대치가 이렇게 바뀌는 상황에서 거의 백지 상태에서 정말 빠르게 배우는 사람, 기존 프로세스와 관습이 머릿속에 굳어 있지 않은 사람이 정말 가치 있어요.

Q. 현직 시니어 디자이너도 기술을 배우고 코딩을 해야 할까요?

밑바닥부터 코딩을 배울 필요까지는 없지만, 디자이너의 어휘에 구현이 점점 더 들어오고 있는 건 사실이에요. 모델과 제품이 더 좋아지면 추상화 레이어가 계속 올라가서 코드 한 줄 한 줄을 알 필요는 없어지겠지만, 지금 당장은 코딩 도구를 자기 툴킷에 넣는 게 맞아요.

React를 따로 공부하러 가는 것보다는, 코딩 도구들이 뭐가 있고 어떻게 쓰는지를 잘 아는 게 더 중요해요.

Q. 신입 디자이너가 Anthropic 같은 곳에 들어가려면 어떻게 해야 할까요?

그냥 많이 만들어보세요. 다양한 것을 시도하고, 실제로 작동하는 것을 만드세요.

디자인 교육이 어떤 상태인지 잘 모르겠지만, 제가 학교 다닐 때는 다 이론적이었거든요. 접근법을 가르쳐주고. 그런데 제가 본 최고의 유능한 신입들은 그냥 기술을 쓰고, 실제로 만들고, 경험이 부족하다는 사실에 위축되지 않는 사람들이에요. 오히려 그게 짐이 없는 거예요. 우리는 업계에 오래 있으면서 스스로에 대한 기대치가 생기는데, 이 사람들은 그게 없어서 뭐든 가능하다고 느끼거든요.

제 모교에서 Socratica라는 걸 시작했는데, 기본적으로 뭔가를 만들고 과학 프로젝트처럼 보여주는 거예요. 누군가는 Claude로 돌아가는 로봇을 조립했고, 누군가는 보스턴 버스에 눈알 스티커를 붙이는 프로젝트를 했어요. 만들고, 하고, 공유하는 에이전시(주체성)와 커뮤니티가 있는 거예요. 어떤 형태든 그런 걸 하고 공유하면 눈에 띌 수밖에 없어요.

Q. Claude를 디자이너로 채용한다면 어떨까요? 만족할 만한가요?

아직 채용할 수준은 아니에요. 강한 제너럴리스트도, 깊은 스페셜리스트도, 유능한 신입도 아니에요. 첫 번째 패스(초안)에서는 꽤 괜찮고 다양한 아이디어를 보여주는데, 아직 특별하고 채용하고 싶은 수준은 아니에요.

디자이너들에게 당장은 좋은 소식이죠, 아직 여기서는 못한다는 거니까.

하지만 지난 1년 동안에도 많이 나아졌으니까, 얼마나 더 좋아질 수 있는지는 큰 열린 질문이에요. 정말 놀랍고 독창적이고 창의적인 경험을 뽑아낼 수 있게 될까, 아니면 인간 디자이너만큼은 절대 안 될까. 아직 모르지만 궁금해요.