cross-platform-development

3 개의 포스트

slack3분 읽기큐레이션 요약

슬랙이 알림 기능을 어떻게 다시 만들었나 📣

Slack은 알림이 많아서가 아니라 사용자가 알림 설정을 이해하고 통제하기 어려워서 “소음”을 느낀다고 진단했다. 이에 데스크톱과 모바일의 서로 다른 설정 체계를 하나의 모델로 통합하고, 활동 알림과 푸시 알림을 분리했다. 레거시 호환성과 롤백 가능성을 고려한 읽기 시점 마이그레이션, 자동 저장, 클라이언트 간 상태 동기화를 통해 더 예측 가능하고 차분한 알림 경험을 구축했다. ## 알림 소음의 근본 원인 - Slack에서 알림 과부하는 고객 불만의 주요 원인이며, 고객 경험 관련 문의의 상위 3개 요인에 포함됐다. - 참여한 채널 수가 많을수록 사용자는 알림 동작을 더 혼란스럽고 압도적으로 느꼈다. - 문제는 단순히 알림의 양이 아니라, 여러 해에 걸쳐 누적된 레거시 아키텍처에도 있었다. - 데스크톱과 모바일이 서로 다른 선호도 모델을 사용했다. - 모바일의 `nothing`과 데스크톱의 `Off`가 같은 의미가 아니었다. - 설정을 바꿔도 실제 결과를 예측하기 어려웠다. - 알림 대상과 전달 방식이 강하게 결합되어 있었다. - 푸시 알림을 줄이면 인앱 활동 확인까지 포기해야 했다. - 클라이언트 간 설정 동기화가 불안정해 데스크톱과 모바일에서 서로 다른 알림이 발생하거나 설정을 반복해야 했다. - 고급 기능이 여러 메뉴에 흩어져 있어 파워 유저도 전체 설정 구조를 파악하기 어려웠다. ## 하나의 알림 모델로 통합 Slack은 UI만 개편하지 않고 알림의 동작 방식 자체를 재설계했다. - 채널 알림을 세 가지 선택지로 단순화했다. - 모든 새 게시물 - 멘션 - 음소거 - 데스크톱과 모바일의 푸시 알림을 독립적인 켜기/끄기 옵션으로 통합했다. - 모바일에도 “모든 읽지 않은 항목 배지 표시” 같은 고급 제어 기능을 제공했다. - 데스크톱과 모바일의 전역 설정 구조와 문구를 일관되게 정비했다. - 단순화된 선호도 로직을 사용해 여러 클라이언트에서 동일한 상태를 유지하도록 개선했다. ## 선호도 데이터 마이그레이션 기존에는 데스크톱과 모바일 설정이 각각 알림 대상과 푸시 전달을 함께 결정했다. ```text 기존 desktop: everything | mentions | nothing mobile: everything | mentions | nothing ``` 새 모델에서는 활동과 푸시를 분리했다. ```text 변경 후 desktop: everything | mentions desktop_push_enabled: true | false mobile: everything | mentions | nothing ``` - 데스크톱의 `desktop_push_enabled`를 새로 도입해 푸시 알림만 별도로 제어했다. - 기존 사용자의 데이터베이스 값을 일괄적으로 직접 변경하지 않았다. - 잘못된 마이그레이션이나 롤백 문제를 피하기 위한 선택이다. - 새 설정을 기존 값에 기반해 백필했다. - 읽기 시점에 레거시 `Off`를 새로운 의미의 `Mentions + 푸시 비활성화`로 해석했다. - 사용자는 기존과 동일한 경험을 유지하면서도 새로운 분리형 알림 구조를 사용할 수 있었다. - 결과적으로 인앱 배지와 활동 알림은 계속 확인할 수 있고, 실제 방해가 되는 푸시만 별도로 끌 수 있게 됐다. ## 자동 저장과 “무엇을 받을지”와 “어떻게 받을지”의 분리 기존 알림 모달은 변경할 때마다 사용자가 `Save` 버튼을 눌러야 했다. - 저장을 잊으면 설정이 적용되지 않아 사용자가 알림 시스템이 고장 났다고 오해할 수 있었다. - 새 모달은 자동 저장을 적용해 변경 즉시 설정이 반영된다. - 알림 설정을 다음 두 축으로 분리했다. - 어떤 활동을 받을 것인가 - 어떤 방식으로 전달받을 것인가 - 예를 들어 모든 활동을 인앱에서 확인하되, 푸시는 멘션에 대해서만 받는 구성이 가능해졌다. - 데스크톱과 모바일 UI에는 재사용 가능한 React 컴포넌트를 활용해 일관성을 높였다. - 기존 모바일 전용 레거시 UI 코드도 대체해 플랫폼별 동작 차이를 줄였다. ## 크로스플랫폼 일관성 - 프로젝트는 수백 개의 댓글이 달린 기술 논의와 제품·디자인·프론트엔드·백엔드·모바일 팀 간 조율을 필요로 했다. - 핵심 목표는 단순히 같은 화면을 만드는 것이 아니라, 어떤 클라이언트에서 설정해도 동일한 상태와 의미를 갖게 하는 것이었다. - 이 구조를 통해 사용자는 데스크톱에서 바꾼 설정이 모바일에서 다르게 동작하는 문제를 덜 겪게 됐다. Slack의 접근 방식은 알림을 무조건 줄이는 대신, 활동 알림과 푸시 알림을 분리하고 설정 의미를 명확히 하는 데 초점을 둔다. 비슷한 시스템을 설계할 때도 레거시 값을 즉시 덮어쓰기보다 읽기 시점 호환성, 점진적 백필, 독립적인 설정 축, 자동 저장을 활용하는 것이 안전하고 사용자 혼란도 줄일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Forrester가 분석한 Dev Mode의

Figma의 Dev Mode는 디자인-개발 간 핸드오프와 반복적인 확인 작업을 줄여 개발자의 생산성과 출시 속도를 높인다는 내용이다. Forrester는 이를 바탕으로 3년간 개발자 생산성이 20~30% 향상되고, 개발자 1인당 매주 90분 이상을 절약할 수 있다고 분석했다. 복합 기업 모델에서는 약 1,000만 달러의 시간 절감 효과와 출시 기간 단축으로 인한 200만 달러의 추가 이익을 추정했다. ## Forrester의 분석 범위와 방법 - Figma는 Dev Mode 출시 2년 후 경제적 효과를 검증하기 위해 Forrester Consulting에 연구를 의뢰했다. - Forrester의 **Total Economic Impact(TEI)** 방법론을 활용했다. - Dev Mode를 사용하는 조직의 의사결정자 4명을 인터뷰했다. - 인터뷰 결과를 바탕으로 디자이너와 개발자 100~1,000명 규모의 복합 조직을 모델링했다. - 분석 대상의 핵심 문제는 다음과 같다. - 비효율적인 디자인-개발 핸드오프 - 디자인 의도 확인을 위한 반복적인 커뮤니케이션 - 중복 작업과 문서 탐색 - 개발 과정에서 발생하는 컨텍스트 전환 ## 개발자 생산성과 경제적 효과 - Dev Mode 사용으로 개발자 산출량이 **20~30% 증가**할 것으로 추정됐다. - 개발자 1인당 매주 **90분 이상**의 시간을 절약할 수 있는 것으로 나타났다. - 한 기업이 개발자 200명을 대상으로 조사한 결과, 평균 절감 시간은 **주 98분**이었다. - 복합 조직 모델에서는 3년 동안 개발자 효율성 향상으로 약 **1,000만 달러의 시간 절감 효과**를 추산했다. - 제품을 더 빠르게 출시함으로써 약 **200만 달러의 추가 이익**이 발생할 수 있다고 분석했다. - 효과는 단순히 코딩 속도 향상에만 있지 않고, 개발자가 실제 구현에 집중할 수 있도록 방해 요소를 줄이는 데서 비롯된다. ## 하나의 진실 공급원으로서의 Dev Mode - 디자이너와 개발자가 동일한 Figma 파일을 기준으로 작업하면서 디자인 정보가 분산되는 문제를 줄인다. - 개발자는 파일에서 다음 정보를 직접 확인할 수 있다. - 디자인 변수 - 정확한 치수와 사양 - 사용된 에셋 - 관련 문서 - 코드 스니펫 - Slack 메시지, 회의, 별도 문서 검색을 통해 디자인 의도를 확인할 필요가 줄어든다. - 시간대가 다른 글로벌 팀에서도 별도의 실시간 미팅 없이 필요한 정보를 스스로 확인할 수 있다. ## 핸드오프 방식에서 동시 협업 방식으로 - 기존 방식에서는 디자인이 완성된 뒤 개발로 넘기는 순차적인 핸드오프가 일반적이었다. - 이 과정은 디자인 의도 확인과 수정 요청이 반복되면서 출시까지 매우 오래 걸릴 수 있었다. - 한 피트니스 업계 기업은 Dev Mode를 통해 디자인과 개발이 진행 중인 상태에서 지속적으로 협업했다. - 그 결과 “코드가 전혀 없는 상태에서 출시까지” 걸리는 시간이 **2~3년에서 6~8개월**로 단축됐다고 보고했다. - 디자이너와 개발자가 작업 중간부터 피드백을 주고받으면 후반부의 대규모 재작업을 줄일 수 있다. ## 커뮤니케이션과 수작업 감소 - 개발자는 과거에 디자인 의도를 확인하기 위해 디자이너에게 질문하거나 별도 미팅을 요청해야 했다. - 디자이너 역시 수동으로 주석을 달고 사양을 설명하는 데 시간을 써야 했다. - Dev Mode는 필요한 정보를 디자인 파일 안에서 직접 제공해 이런 반복 작업을 줄인다. - 한 시스템 디자이너는 개발자가 변수, 사양, 코드 정보를 직접 확인할 수 있어 더 자율적으로 작업한다고 설명했다. - 결과적으로 다음과 같은 변화가 가능하다. - 불필요한 메시지와 회의 감소 - 수동 주석 작성 감소 - 디자인 확인을 위한 대기 시간 단축 - 개발자의 정신적 부담과 컨텍스트 전환 감소 - 구현과 제품 완성도에 더 많은 집중 ## 실용적인 시사점 Dev Mode 같은 협업 도구의 ROI는 기능 자체보다 핸드오프 과정에서 발생하는 대기·질문·중복 작업을 얼마나 줄이는지로 평가하는 것이 적절하다. 도입을 검토하는 팀이라면 개발자당 절감 시간, 디자인 확인에 소요되는 커뮤니케이션량, 재작업 횟수, 출시까지의 기간을 도입 전후로 측정하는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma원문

Razorpay가 개발자 워크플 (새 탭에서 열림)

인도 최대의 금융 서비스 기업인 Razorpay는 1,000만 개 이상의 비즈니스를 지원하기 위해 디자인 시스템 'Blade'를 구축하여 일관된 사용자 경험과 개발 효율성을 동시에 확보했습니다. 웹과 모바일을 아우르는 단일 API 구조를 통해 플랫폼 간 전환 비용을 최소화하고, 전용 플러그인과 Figma Dev Mode를 적극 활용해 디자이너와 개발자 간의 협업 마찰을 획기적으로 줄였습니다. 결과적으로 Blade는 단순한 가이드를 넘어 제품의 신뢰성을 높이고 시장 출시 속도를 앞당기는 핵심 동력으로 자리 잡았습니다. **크로스 플랫폼을 위한 단일 라이브러리 체계** * 웹, iOS, Android 등 다양한 플랫폼에서 동일한 API와 속성을 공유하는 단일 디자인 시스템을 운영하여 개발자가 플랫폼을 옮겨가더라도 기존 지식을 그대로 활용할 수 있게 했습니다. * 하드코딩으로 인해 발생할 수 있는 텍스트 필드의 에러 처리나 버튼 상태값 누락 등의 세부적인 오류를 방지하고, 모든 컴포넌트에 접근성(Accessibility)을 기본적으로 내장했습니다. * 디자이너와 개발자가 동일한 언어를 사용함으로써 커뮤니케이션 비용을 줄이고, 디자인에서 보는 결과물이 코드와 일치하도록 보장합니다. **지표 기반의 도입 전략과 조직 내 확산** * 새로운 기능을 개발할 때는 디자인의 70%, 기존 화면을 수정할 때는 50% 이상 Blade 컴포넌트를 사용하도록 KPI를 설정하여 디자인과 개발 팀이 공동의 목표를 추구하게 합니다. * 'Blade Coverage' 플러그인을 통해 디자이너가 시스템에서 얼마나 벗어나고 있는지 실시간으로 확인하게 함으로써, 핸드오프 단계 이전에 피드백을 주고받을 수 있는 환경을 조성했습니다. * 리더십의 지지를 바탕으로 전담 슬랙 채널 운영, 오피스 아워, 시연 영상 공유 등을 통해 내부 고객(직원)들의 채택률을 높이고 연간 NPS(순추천지수) 설문을 통해 만족도를 관리합니다. **RazorSharp와 Dev Mode를 통한 코드 자동화** * 개발자가 일일이 속성을 검사하던 비효율을 제거하기 위해 디자인을 코드로 자동 변환해주는 자체 플러그인 'RazorSharp'를 개발했습니다. * Figma의 Dev Mode를 도입하면서 기존 편집 권한이 필요했던 플러그인 제약을 극복했고, 개발자가 편집 권한 없이도 코드를 복사하고 Storybook 링크를 통해 바로 컴포넌트 환경으로 이동할 수 있게 했습니다. * VS Code 플러그인을 연동하여 개발 환경 내부에서 직접 디자인 사양을 확인하며 코드를 작성하는 워크플로우를 구축했습니다. **Variables를 활용한 토큰 관리 및 성능 최적화** * 기존의 복잡한 토큰 명명 규칙(surface/text/subtle)을 개발자 친화적인 구조(surface.text.subtle)로 변환하고, 간격(spacing) 토큰을 변수화하여 개발 편의성을 높였습니다. * 여러 테마와 라이트/다크 모드를 개별적으로 만들던 방식에서 변수(Variables) 기반 시스템으로 전환하여 메모리 소모를 대폭 줄이고 디자인 작업 속도를 개선했습니다. * 이를 통해 하나의 테마 안에서 다양한 모드를 유연하게 구현할 수 있게 되어 시스템의 복잡성을 낮추고 관리 효율을 극대화했습니다. **디자인 시스템 운영을 위한 실용적 제언** 디자인 시스템의 성공은 단순히 컴포넌트를 만드는 것에 그치지 않고, 개발자가 실제 작업 환경에서 얼마나 편리하게 코드를 추출하고 적용할 수 있느냐에 달려 있습니다. Razorpay처럼 자체 플러그인을 개발하거나 Dev Mode를 적극 활용하여 '디자인 검사'에 들어가는 시간을 줄이고, 정량적인 사용량 지표(Coverage)를 통해 팀의 성과를 객관화하는 접근 방식이 권장됩니다. 또한, 시스템의 복잡도가 커질수록 Variables 기능을 활용해 성능 저하를 방지하고 개발 생산성을 높이는 전략이 필수적입니다.