핵심 요약

  • 레딧은 저장소와 브랜치 관리의 복잡함을 감춘 내부 도구 Reddit Proto로 디자이너와 제품 관리자가 실제 제품에 가까운 시제품을 만들게 했다.
  • 실제 계정 데이터와 제품용 컴포넌트를 연결하자 검토자가 구현 방식을 추측하는 대신 사용 경험을 평가할 수 있었다.
  • 클레어 보는 Claude Duet의 설계와 연결 기능을 높이 평가했지만 느린 응답과 부족한 알림 때문에 계속 쓰지 못했다.
  • 두 사례의 쟁점은 AI가 무엇을 만들 수 있느냐와 함께 기존 업무의 맥락과 협업 방식에 얼마나 잘 들어오느냐였다.

AI 도구가 일상 업무에 자리 잡는 조건

ChatPRD 창업자 클레어 보가 진행하는 How I AI의 두 회차는 AI 도구의 업무 정착을 서로 다른 각도에서 다뤘다. 레딧 수석 UX 엔지니어이자 Reddit Proto 개발자인 블레어 멧캐프와의 대담에서는 내부 시제품 제작 도구를 소개했고 보의 단독 방송에서는 앤트로픽의 개인 에이전트 Claude Duet 사용 경험을 다뤘다.

레딧에서는 시제품이 약 700개 쌓였고 멧캐프는 UX와 제품 조직의 도입률이 100%에 이르렀다고 밝혔다. 반면 보는 Duet의 완성도에 감탄하고도 사용을 잊었다. 두 사례에서 다루는 문제는 AI 도구가 실제 업무에서 계속 쓰이려면 무엇이 필요한가다.

복잡한 개발 절차를 감추고 실제 경험을 만든 레딧

Reddit Proto는 디자이너와 제품 관리자가 GitHub를 직접 다루지 않고도 시제품을 만드는 내부 플랫폼이다. 데스크톱 앱이 코드 저장소, 작업을 나누는 브랜치, 기본 뼈대 설정을 뒤에서 처리한다. 사용자는 개발 절차보다 구현할 아이디어에 집중할 수 있다.

시제품에는 가상의 예시 데이터 대신 실제 레딧 데이터를 넣는다. 사용자가 자신의 계정으로 로그인하면 피드와 검색 결과, 커뮤니티에 익숙한 콘텐츠가 나타난다. 검토자는 빈자리를 상상으로 채우지 않고 실제 사용 경험을 살펴볼 수 있다.

멧캐프는 이 과정에서 속도가 개선된다고 강조했다. 실제 컴포넌트와 계정 데이터로 만든 시제품을 공유하면 구현 방식의 불확실성이 줄어 의사결정이 빨라진다고 말했다.

짧은 수정 요청에도 코드 맥락을 붙인다

Reddit Proto는 화면에 남긴 주석을 그대로 AI 코딩 도구 Cursor에 보내지 않는다. 해당 화면 요소와 관련된 컴포넌트, 디자인 시스템 지침, 사용자의 의도를 함께 전달한다. 짧은 요청만 보고 AI가 수정 방향을 추측하는 일을 줄이기 위해서다.

이를 뒷받침하는 장치가 자체 디자인 시스템 MCP다. MCP는 여기서 AI에 디자인 체계와 코드 정보를 연결하는 통로로 쓰인다. 레딧 팀은 색상·간격 같은 디자인 값과 재사용 컴포넌트, 작업 절차를 실제 제품 코드에 연결했다. Cursor가 어떤 요소를 쓰고 어디에 코드를 배치할지 판단할 근거를 마련했다.

멧캐프는 뛰어난 활용자가 반드시 개발 경험이 많은 사람은 아니었다고 소개했다. 엔지니어링 배경이 없는 시각 디자이너와 애니메이터도 두각을 보였다. 이들은 제품을 이해하고 구상이 분명했으며 실험하려는 태도를 갖췄다.

제작 이후에는 인계와 검색이 중요해진다

레딧의 ‘기능 캡슐’은 디자인을 개발팀에 넘기는 과정도 다룬다. 디자이너가 Figma 링크를 제출하면 시스템이 화면 요소를 실제 제품 컴포넌트에 대응시키고 이전 엔지니어링 피드백을 반영한다. 이어 기능의 완료 여부를 판단할 수용 기준을 포함한 제품 요구사항 문서(PRD)를 생성한다.

시제품이 약 700개로 늘자 기존 실험을 찾는 일도 중요해졌다. 레딧은 태그와 팀별·플랫폼별 필터로 검색하는 콘솔을 개발하고 있다. 시제품을 사내에 공개해 두면 흩어진 Figma 폴더보다 다른 팀의 실험을 파악하기 쉽다고 봤다.

Duet의 정교한 설계와 엇갈린 작업 결과

보는 Duet이 초기 안내부터 접근 가능한 정보와 수행할 일을 명확하게 설명한다고 평가했다. 기존 Claude 플러그인과 외부 앱 연결 기능을 활용하고 사용자와 에이전트의 할 일을 구분하며 기존 작업 산출물도 가져온다. Slack과 비슷한 채널로 영업처럼 특정 업무의 대화를 분리할 수도 있다.

실제 결과는 고르지 않았다. 연결된 앱을 이용한 영업 파이프라인 분석은 빠르게 처리했지만 이메일과 Slack 분류에서는 일부 우선순위와 중요한 맥락을 놓쳤다. 발표 자료는 쓸 만했으나 브랜드에 맞지 않았고 티켓 검색도 전체 절차를 마무리하지는 못했다.

작업 맥락을 옮기는 데도 제약이 있었다. Duet이 로컬 Claude 스킬에 접근하지 못해 보는 출시 영상 제작에 쓰던 스킬을 플러그인으로 변환해야 했다.

느린 응답과 개인용 모바일 경험의 한계

보의 사용 경험에서 Opus 5.5는 괜찮은 결과를 냈지만 병렬 작업은 별다른 진행 표시 없이 10분 넘게 걸리는 일이 잦았다. 보는 결과가 조금 덜 뛰어나더라도 빠르게 반응하는 에이전트가 더 유용하게 느껴질 수 있다고 봤다.

다시 사용할 계기도 부족했다. 초기 설정과 몇 가지 작업 뒤에는 적극적인 알림이 끊겼고 짧은 아침 브리핑만으로는 일상에 자리 잡지 못했다. 조용한 알림 방식이 세련돼 보여도 사용 자체를 잊게 됐다.

데스크톱과 공동 작업 지원의 부재도 컸다. 보는 주로 컴퓨터와 Slack 같은 팀 도구에서 일하며 다섯 명 규모의 사업에도 함께 쓸 수 있는 에이전트가 필요하다고 말했다. Duet의 모델과 연결 기능은 좋은 기반이었지만 자신의 업무 도구로 정착하려면 속도와 능동성, 데스크톱 접근, 팀 공유가 더 필요하다고 평가했다.

레딧은 실제 데이터와 제품 체계를 연결해 제작과 검토의 불확실성을 줄였다. Duet은 정교한 설계를 갖추고도 보의 작업 속도와 협업 환경에 충분히 맞지 않았다. 두 사례에서 지속적인 사용을 가른 것은 개별 작업의 결과와 더불어 그 결과를 만드는 과정이 기존 업무와 얼마나 이어지는지였다.