Techlist.io - 한국 테크 블로그 큐레이터

figma3분 읽기큐레이션 요약

비하인드 스토리: 국제 키

Figma는 미국 키보드 기준으로 설계된 단축키가 국제 키보드 사용자에게 작동하지 않는 문제를 해결하기 위해 1년간 단축키 시스템을 개선했다. 문제는 단순히 키 조합을 추가하는 것이 아니라, 브라우저의 키보드 이벤트 처리, 문자 정규화, 키보드 레이아웃 감지 등 여러 계층에 걸쳐 있었다. 특히 독일어 `ß`처럼 대소문자 변환만으로는 안전하게 처리할 수 없는 문자와 수천 가지 키보드 레이아웃이 복잡성을 높였다. ### 국제 키보드에서 발생한 단축키 문제 - Figma의 기존 단축키는 미국 키보드를 기준으로 설계되었다. - 일부 사용자는 키보드에 존재하지 않는 키를 요구받았다. - `⌘ + \`로 UI를 전환해야 하지만 `\` 키가 없는 경우 - `/` 키를 누를 수 없어 Cursor Chat을 시작할 수 없는 경우 - 단축키는 작업 효율성과 접근성에 중요한 기능이므로, 모든 지역의 사용자가 동일한 기능을 이용할 수 있어야 했다. - 이를 해결하기 위해 에디터 사용성 팀을 중심으로 여러 직군이 참여한 프로젝트가 시작되었다. ### Figma의 단축키 처리 구조 - 사용자가 키를 누르면 브라우저가 `KeyboardEvent`를 Figma에 전달한다. - Figma는 이벤트를 에디터가 해석할 수 있는 내부 표현으로 변환한다. - 가능한 단축키와 실행할 동작은 JSON 파일에 정의되어 있다. - 단축키 활성화 여부는 다음과 같은 상태에 따라 달라진다. - 사용자 설정 - 현재 사용 중인 Figma 제품 - 운영체제 - 기타 제품 상태 - 입력된 키 조합을 정의된 단축키 목록과 비교해 일치하면 해당 동작을 실행한다. ### 단순한 단축키 추가로 해결되지 않은 이유 - 처음에는 키보드별 대체 조합을 JSON에 추가하면 될 것처럼 보였다. - 스웨덴어 키보드: `⌘ + ]` 대신 `Meta + Ä` - 한국어 키보드: `⌘ + \` 대신 `₩` - 그러나 단축키를 정규화하는 과정에서 언어별 문자의 특수성이 드러났다. - 독일어 키보드의 `Meta + Alt + ß`를 처리할 때 JavaScript의 `"ß".toUpperCase()`가 `SS`로 변환되었다. - 하나의 키 문자가 두 글자로 늘어나면서 단일 키 단축키라는 전제가 깨졌다. - 더 나아가 `"ß".toUpperCase().toLowerCase()`도 원래의 `ß`로 되돌아가지 않았다. - Figma는 대문자 에스체트인 `ẞ`를 사용해 우회했다. - `ẞ`는 대문자로 변환해도 동일하게 유지된다. - 이 문자는 2017년 독일 철자위원회에서 공식 채택되었지만, 프로그래밍 언어와 도구의 지원은 아직 완전하지 않았다. ### 키보드 레이아웃 감지의 어려움 - 전 세계에는 매우 많은 키보드 레이아웃이 있어, 처음부터 모두 지원하기는 어려웠다. - Figma는 사용자가 많이 사용하는 레이아웃부터 지원하기로 했다. - 데스크톱 앱에서는 운영체제의 키보드 설정을 직접 감지할 수 있었다. - 브라우저에서는 운영체제 정보를 충분히 얻기 어려워 실험적인 Keyboard API와 휴리스틱을 사용했다. - API가 제공하는 키 위치별 문자를 알려진 레이아웃과 비교해 사용자의 레이아웃을 추정했다. - 예를 들어 `Quote` 키 위치에 `ä`가 입력되는지 확인하고 다른 키 정보와 조합해 스웨덴어 키보드인지 추론한다. - 실제 사용 데이터를 수집한 결과, 30일 동안 Figma에서 2,500개가 넘는 서로 다른 키보드 레이아웃이 관찰되었다. - 이는 키보드 레이아웃의 다양성이 예상보다 훨씬 크며, 국제 단축키 지원이 단순한 지역별 매핑 이상의 문제임을 보여준다. 국제 키보드 단축키를 설계할 때는 특정 국가의 키 조합을 추가하는 데 그치지 말고, 문자 정규화의 언어적 예외, 브라우저와 데스크톱 환경의 감지 차이, 레이아웃의 폭넓은 다양성을 함께 고려해야 한다. 특히 키 이름이나 문자를 문자열로만 처리하면 `ß` 사례처럼 예기치 않은 변환이 발생할 수 있으므로, 키 위치와 입력 문자를 구분하는 견고한 설계가 필요하다.

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

디자인이 일을 제대로 작동

변화와 불확실성이 커진 업무 환경에서 관리자는 기존의 업무 방식을 그대로 유지하기보다 자신의 역할과 시간을 다시 설계해야 한다. 이 글은 회의와 피드백 중심의 업무를 비동기 협업과 시각화로 전환하면, 관리자는 더 중요한 리더십과 팀 성장에 집중할 수 있다고 주장한다. 핵심은 회의를 줄이고, 초기부터 작업을 공유하며, 팀이 자율적으로 의견을 남길 수 있는 구조를 만드는 것이다. ## 변화하는 환경에서 관리자의 역할 재설계 - 하이브리드 근무, 기술 발전, 업무 방식의 변화로 관리자의 역할이 과거보다 복잡해졌다. - ‘정상적인 업무 방식’이 사라진 상황은 기존 관행을 재검토하고 새로운 방식을 실험할 기회이기도 하다. - 관리자는 현재 자신이 시간을 어디에 쓰는지 점검하고, 조직이 기대하는 역할과 실제 업무 사이의 차이를 파악해야 한다. - 단순한 일정 조율이나 회의 운영보다 조직 변화, 구성원의 성장, 팀의 생산성 향상에 시간을 써야 한다. ## 반복 회의를 줄이고 비동기 협업 확대 - Shopify는 2023년 초 3명 초과의 모든 반복 회의를 폐지한 뒤, 꼭 필요한 회의만 점진적으로 다시 추가했다. - 회의를 줄이면 구성원이 중단 없이 독립적으로 집중할 시간이 늘어난다. - 여러 시간대에 분산된 원격 팀에서는 실시간 회의보다 Figma·FigJam 파일을 활용한 상시 협업이 효과적이다. - 프로젝트 계획을 FigJam에 공유하면 구성원이 실시간으로 참여하는 동시에, 나중에 비동기적으로 아이디어와 피드백을 남길 수 있다. - 회의가 필요하더라도 의사결정만을 위한 시간이 아니라 관계 형성, 업무에 대한 태도와 철학을 공유하는 시간으로 활용할 수 있다. - 브레인스토밍이나 시각화 도구를 사용하면 회의 없이도 아이디어를 수집하고 작업을 진전시킬 수 있다. ## 피드백을 초기부터 공개해 재작업 줄이기 - 모든 사람을 만족시키려다 피드백이 뒤늦게 몰리면 업무가 반복적으로 뒤집히는 ‘swoop and poop’ 현상이 발생한다. - 완성된 결과물을 한 번에 보여주기보다, 초안이나 작업 중인 화면을 FigJam에 스크린샷으로 공유하는 방식이 효과적이다. - 동료와 이해관계자는 주석, 스티커, 이모지 등을 활용해 의견을 남길 수 있다. - 모든 사소한 의견에 즉시 대응하지 않아도 되므로 팀의 작업 흐름을 유지하면서 다양한 관점을 수집할 수 있다. - 시각적 브레인스토밍은 협업 과정뿐 아니라 결정 사항과 논의 맥락을 기록하는 역할도 한다. ## 반복 가능한 프로세스와 개선 문화 - 구성원이 매번 같은 문제를 새로 해결하지 않도록 표준화된 프로세스를 마련하면 본업에 집중할 수 있다. - 동시에 프로세스가 잘 작동하지 않는 부분을 말할 수 있는 안전한 공간도 필요하다. - 주거 건물 유지보수 자동화 스타트업 Super는 월간 회고에서 익명으로 운영 개선 의견을 받았다. - 이 과정에서 버그 보고 시스템이 개선되고, 신규 기능을 팀 전체가 시험하는 주 1회 15분 회의가 만들어졌다. - 리더십은 팀에 일방적으로 절차를 강요하기보다 “어떻게 더 나아질 수 있을까?”를 함께 묻는 역할을 해야 한다. 실무에서는 모든 회의를 없애는 것보다 반복 회의의 목적을 점검하고, 문서·화이트보드·댓글 기반의 비동기 협업으로 대체할 수 있는 업무부터 전환하는 것이 현실적이다. 또한 완성도를 높인 뒤 공개하기보다 초기 초안을 자주 공유해 피드백 비용과 늦은 방향 전환을 줄이는 것이 좋다.

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

Husky: 대규모 환경에서의 정확히 한 번 데이터 수집과 멀티테넌시 (새 탭에서 열림)

Datadog의 3세대 이벤트 저장소인 Husky는 대규모 멀티테넌트 환경에서 데이터 중복 없는 '정확히 한 번(Exactly-once)'의 인입을 보장하기 위해 데이터 지역성(Locality) 기반의 라우팅 아키텍처를 도입했습니다. 스캔과 집계에 최적화된 Husky의 특성상 고성능 포인트 조회가 어렵다는 점을 극복하기 위해, 결정론적 샤딩을 통해 중복 제거의 범위를 샤드 단위로 한정하여 시스템 복잡도를 낮췄습니다. 이를 통해 테넌트별 데이터 격리 비용을 최소화하고, 가변적인 트래픽 상황에서도 효율적으로 스토리지와 컴퓨팅 자원을 확장할 수 있는 기반을 마련했습니다. ## 샤드 라우터를 통한 데이터 지역성 확보 * **결정론적 매핑**: 업스트림 서비스인 'Shard Router'를 사용하여 이벤트의 ID와 타임스탬프를 기반으로 특정 샤드(파티션 그룹)에 이벤트를 할당합니다. * **샤드 할당 전략**: 각 테넌트에게 고정된 리스트의 샤드를 할당하고, 해당 리스트 내에서 이벤트 ID를 해싱하여 샤드를 선택함으로써 무작위 라우팅을 방지합니다. * **테넌트 격리**: 개별 워커 노드가 노출되는 테넌트와 인덱스의 수를 최소화하여, 시스템 전체의 복잡도를 관리 가능한 수준으로 유지합니다. ## 데이터 지역성 도입의 기술적 이점 * **중복 제거(Deduplication) 효율화**: 동일한 ID를 가진 이벤트는 항상 같은 샤드로 라우팅되므로, 전체 시스템이 아닌 샤드 내부에서만 중복 여부를 확인하면 됩니다. 이벤트 ID 세트가 메모리에 수용 가능한 크기로 유지되어 처리 속도가 비약적으로 향상됩니다. * **스토리지 비용 절감**: Husky는 테넌트별로 데이터를 전용 테이블에 격리하며 파일 단위로 저장합니다. 지역성을 통해 워커당 처리하는 테넌트 수를 제한하면 생성되는 파일 수가 줄어들어, 클라우드 스토리지 비용과 후속 컴팩션(Compaction) 작업의 부하를 동시에 낮출 수 있습니다. * **성능 최적화**: 워커 노드가 처리해야 할 논리적 네임스페이스의 카디널리티(Cardinality)가 낮아짐에 따라 쓰기 성능이 개선되고 리소스 효율성이 높아집니다. ## 동적 환경에서의 라우팅 도전 과제 * **할당 변경 관리**: 특정 테넌트의 트래픽이 갑자기 수십 배 증가하거나 전체 샤드 수가 변경될 때, 기존의 결정론적 규칙을 유지하면서도 유연하게 샤드 배정을 변경해야 합니다. * **분산 노드 간 합의**: 모든 샤드 라우터 노드가 동일한 라우팅 규칙을 공유해야 중복 데이터 유입을 방지할 수 있으며, 이를 위해 노드 간의 일관성 있는 결정 메커니즘이 필수적입니다. * **부하 분산(Load Balancing)**: 모든 샤드에 인입 트래픽이 균등하게 배분되도록 설계하여 특정 워커 노드에 부하가 집중되는 '핫스팟' 현상을 방지해야 합니다. 대규모 분산 시스템에서 데이터 일관성을 유지하며 비용을 최적화하려면, 무상태(Stateless) 라우팅보다는 데이터의 특성에 맞춘 지역성 설계를 우선 고려해야 합니다. 특히 테넌트 수가 많은 SaaS 환경에서는 워커가 처리하는 테넌트의 카디널리티를 물리적으로 제한하는 것이 스토리지 관리 비용을 결정짓는 핵심 요소가 됩니다.

datadog2분 읽기큐레이션 요약

Husky: 대규모에서의

제공된 내용에는 기술 블로그 본문이 아니라 Datadog의 제품 메뉴와 “Gartner® Observability Platforms Magic Quadrant™에서 Leader로 선정됐다”는 홍보 문구가 대부분 포함되어 있습니다. 따라서 Datadog이 인프라·애플리케이션·로그·보안·RUM·CI/CD·AI를 아우르는 통합 관측성 플랫폼을 제공한다는 점은 확인할 수 있지만, 구체적인 기술적 주장이나 결론은 파악하기 어렵습니다. 링크 경로상 원문은 `husky-deep-dive`에 관한 엔지니어링 글로 보이나, 본문 내용은 제공되지 않았습니다. ## Gartner 관측성 플랫폼 리더 선정 - Datadog이 Gartner의 Observability Platforms Magic Quadrant에서 Leader로 평가받았다는 내용이 제목과 배너에 제시되어 있습니다. - 다만 평가 기준, 경쟁사 대비 강점, Gartner의 구체적인 분석 내용은 제공된 텍스트에 포함되어 있지 않습니다. - 따라서 이 선정만으로 제품 성능이나 시장 우위를 구체적으로 판단하기는 어렵습니다. ## Datadog의 통합 모니터링 범위 - **인프라** - 호스트·컨테이너·Kubernetes 모니터링 - 메트릭, 네트워크, 서버리스, GPU 및 클라우드 비용 관리 - **애플리케이션** - APM, 지속적 프로파일링, 동적 계측 - 서비스 간 성능 분석과 에이전트 관측성 - **로그·데이터** - 로그 관리 및 민감 데이터 탐지 - 데이터베이스, 데이터 스트림, 데이터 품질과 작업 모니터링 - **디지털 경험** - 브라우저·모바일 RUM - 세션 리플레이, 합성 모니터링, 오류 추적, 제품 분석 - **소프트웨어 개발** - CI 가시성, 테스트 최적화, 코드 커버리지 - 내부 개발자 포털, 기능 플래그, IDE 플러그인 - **보안** - 코드·클라우드·런타임 보안 - SAST, SCA, CSPM, SIEM, 취약점 및 워크로드 보호 - **서비스 관리와 AI** - 장애 대응, SLO, 이벤트 관리, 워크플로 자동화 - Bits AI Agents, AI 기반 조사, GPU 모니터링, MCP 서버 등 ## 제공된 자료의 한계 - `husky-deep-dive` 글의 본문, 코드, 아키텍처 설명, 성능 수치가 누락되어 있습니다. - Husky가 무엇인지, 어떤 문제를 해결하는지, 내부 구현이 어떻게 구성되는지 확인할 수 없습니다. - 정확한 기술 요약을 위해서는 해당 링크의 본문이나 원문 전체가 추가로 필요합니다. 원문 본문을 제공하면 Husky의 아키텍처, 데이터 처리 방식, 성능 최적화, 설계상의 트레이드오프까지 섹션별로 구체적으로 요약할 수 있습니다.

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

핀터레스트 디자인

Pinterest의 Gestalt 디자인 시스템은 코드 사용량만으로는 전체 채택 현황을 파악하기 어렵다고 보고, Figma 안에서 디자이너들이 컴포넌트를 얼마나 사용하는지 측정하는 ‘디자인 채택률’을 도입했다. 코드 지표는 웹 플랫폼에 한정되고 실제 디자인 단계보다 늦게 나타나는 반면, Figma 지표는 웹·iOS·Android를 아우르며 초기 사용 신호를 제공한다. 이를 위해 Figma REST API 기반의 대시보드 FigStats를 만들어 컴포넌트 사용량을 전체 디자인 요소 대비 상대적으로 분석했다. ## 코드 채택률만으로는 부족한 이유 - Gestalt은 웹뿐 아니라 iOS와 Android용 디자인 컴포넌트도 제공하지만, 기존 코드 채택률은 웹 컴포넌트만 측정했다. - 새 컴포넌트가 실제 제품 코드에 도입되기까지 시간이 걸리므로, 코드 지표에는 채택 지연이 발생한다. - 디자이너가 컴포넌트를 사용하지 않으면 개발자도 해당 컴포넌트의 존재나 필요성을 알기 어렵다. - 따라서 디자인 시스템 채택은 제품 코드 단계가 아니라 디자인 단계부터 시작된다는 관점이 필요하다. ## Figma에서 디자인 채택을 측정하는 이유 - Pinterest 디자이너들의 작업은 Figma에서 이루어지므로, 디자인 시스템 사용 현황을 가장 이른 단계에서 확인할 수 있다. - Figma에서 Gestalt 컴포넌트가 사용되면 웹·iOS·Android 전반에서 향후 코드 컴포넌트를 구축할 근거로 활용할 수 있다. - 디자이너가 실제로 컴포넌트를 사용하는지 확인하면 디자인 시스템 투자 효과와 플랫폼별 개발 우선순위를 설명하기 쉬워진다. ## 단순한 인스턴스·삽입 횟수의 한계 - Figma 기본 라이브러리 분석은 팀별 컴포넌트 인스턴스 수와 삽입 횟수를 제공한다. - 예를 들어 버튼이 수십만 번 사용됐다는 사실은 알 수 있지만, 그 수치가 건강한 채택 수준인지는 판단하기 어렵다. - 대형 파일에 노드가 1,000개 있고 Gestalt 컴포넌트가 10개뿐이라면, 사용량은 존재하지만 전체 디자인의 1%에 불과하다. - 따라서 절대적인 사용 횟수보다 전체 디자인 요소 중 디자인 시스템 컴포넌트가 차지하는 비율이 더 유용한 지표가 된다. ## FigStats와 상대적 채택률 - Gestalt 팀은 Figma REST API를 사용해 FigStats라는 내부 대시보드를 구축했다. - 대시보드는 Figma 파일을 분석해 어떤 Gestalt 컴포넌트가 어느 팀과 파일에서 사용되는지 시각화한다. - 핵심은 컴포넌트 인스턴스 수 자체가 아니라, 전체 노드 또는 디자인 요소 중 Gestalt 컴포넌트가 차지하는 비중을 계산하는 것이다. - 이를 통해 파일 규모가 서로 달라도 디자인 시스템이 실제 작업에 얼마나 깊이 적용됐는지 비교할 수 있다. - 컴포넌트별 사용 현황을 보면 널리 사용되는 컴포넌트와 거의 사용되지 않는 컴포넌트를 구분할 수 있으며, 개선이나 교육이 필요한 영역도 찾을 수 있다. ## 채택 데이터의 활용 - 채택률은 디자인 시스템 팀이 제공하는 가치와 투자 대비 효과를 리더십에 설명하는 공통 언어가 된다. - 사용률이 낮은 컴포넌트는 문서화 부족, 발견성 문제, API나 시각적 설계의 불편함 때문일 수 있다. - 디자인 단계에서 사용이 확인된 컴포넌트는 향후 코드 컴포넌트로 구현할 때 우선순위를 정하는 근거가 된다. - 코드 채택률과 디자인 채택률을 함께 보면 디자인에서 제품 출시까지의 채택 흐름과 지연 구간을 파악할 수 있다. ## Figma 분석 기능의 확장 - 글 작성 당시 Figma 기본 분석은 주로 컴포넌트 인스턴스와 삽입 데이터를 제공했다. - 이후 Figma Library Analytics는 스타일과 변수 데이터까지 포함하도록 확장되었고, Enterprise 고객은 Library Analytics API를 활용할 수 있게 됐다. - 따라서 현재는 컴포넌트뿐 아니라 스타일·변수까지 포함해 조직 전체의 디자인 시스템 채택을 분석할 수 있다. 디자인 시스템의 성공을 평가할 때 단순한 사용 횟수만 보지 말고, 전체 디자인 대비 사용 비율과 플랫폼별 채택 흐름을 함께 측정하는 것이 좋다. 특히 Figma의 디자인 채택률과 코드 채택률을 연결하면 어떤 컴포넌트가 실제 제품으로 이어지는지 더 정확하게 판단할 수 있다.

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

Datadog 에이 (새 탭에서 열림)

Datadog은 에이전트가 더 적은 CPU를 사용하면서도 더 많은 데이터를 빠르게 처리할 수 있도록 메트릭 식별 키(Metric Context) 생성 알고리즘을 최적화했습니다. Go 언어의 프로파일링 도구를 활용해 병목 지점인 태그 정렬 과정을 찾아냈으며, 특수화된 알고리즘과 해시 전략 수정을 통해 처리량을 대폭 개선했습니다. 결과적으로 동일한 리소스 내에서 더 많은 DogStatsD 메트릭을 수집하고 처리할 수 있는 성능 효율성을 달성했습니다. ## CPU 프로파일링을 통한 병목 지점 파악 * Go 언어의 런타임 도구와 플레임그래프(Flamegraph)를 사용하여 고부하 상황에서의 CPU 사용량을 분석했습니다. * 분석 결과, DogStatsD 서버가 샘플을 수신할 때 호출되는 `addSample`과 `trackContext` 함수가 가장 많은 CPU를 점유하고 있음을 확인했습니다. * 구체적으로 메트릭의 고유성을 보장하기 위해 수행하는 태그 정렬 알고리즘(`util.SortUniqInPlace`)이 전체 성능의 주요 병목 원인으로 지목되었습니다. ## 기존 메트릭 컨텍스트 생성 방식의 한계 * 메트릭 컨텍스트는 메트릭 이름과 태그 조합을 해시화하여 RAM 내 저장소의 키로 사용하며, 동일한 메트릭은 항상 같은 키를 생성해야 합니다. * 일관된 해시 생성을 위해 모든 태그를 정렬하고 중복을 제거하는 과정을 거치는데, 이 정렬 작업의 비용이 메트릭 양에 비례해 급격히 증가합니다. * 해시 충돌을 방지하면서도 수천 개의 메트릭을 초당 처리할 수 있을 만큼 알고리즘의 원시 성능이 매우 중요한 구조였습니다. ## 성능 향상을 위한 단계적 최적화 전략 * **코드 특수화(Specialization):** 태그의 개수에 따라 서로 다른 정렬 알고리즘을 적용하도록 최적화하여, 가장 빈번하게 발생하는 케이스에 대해 최상의 성능을 내도록 개선했습니다. * **해시 알고리즘 교체:** 마이크로 벤치마크를 통해 속도와 고유성이 뛰어난 **Murmur3** 알고리즘을 채택했습니다. * **Go 런타임 최적화 활용:** 기존 128비트 해시 대신 64비트 메트릭 컨텍스트를 사용하도록 변경했습니다. 이를 통해 Go 런타임의 최적화된 맵 접근 함수(`mapassign_fast64`, `mapaccess2_fast64`)가 작동하게 되어 맵 조작 속도를 높였습니다. * **근본적인 디자인 재설계:** 정렬이 성능의 가장 큰 장애물임을 인지하고, 정렬과 중복 제거에 의존하던 기존 알고리즘을 완전히 대체하는 새로운 설계 방식을 도입했습니다. 성능 최적화를 위해서는 단순히 하드웨어 사양을 높이는 대신, Go의 `pprof`와 같은 도구로 핫 패스(Hot path)를 정확히 진단하는 것이 우선입니다. 특히 대규모 데이터를 처리하는 시스템이라면 언어 런타임이 제공하는 하위 수준의 최적화(예: 특정 비트 수에 따른 맵 최적화)를 적극적으로 활용하고, 당연하게 여겨지던 정렬과 같은 알고리즘을 의심하여 재설계하는 과정이 필요합니다.

datadog원문

Datadog Agent 메트릭 파이프라인의 성능 개선 (새 탭에서 열림)

Datadog Agent는 동일한 CPU 리소스로 더 많은 메트릭을 빠르게 처리하기 위해 메트릭 고유 키(Context) 생성 로직을 최적화했습니다. Go 언어의 프로파일링 도구를 통해 태그 정렬 및 해싱 과정이 시스템의 주요 병목 지점임을 확인했으며, 이를 해결하기 위해 상황별 특수화 알고리즘과 64비트 해시 최적화 기법을 도입했습니다. 이러한 개선을 통해 에이전트의 데이터 처리 성능을 한 단계 높이고 리소스 효율성을 극대화하는 결과를 얻었습니다. ### 병목 지점 식별 및 분석 * Go 언어(Golang)의 CPU 프로파일링과 플레임그래프(Flamegraph) 도구를 활용하여 메트릭 파이프라인 내 리소스 소모가 큰 지점을 추적했습니다. * 분석 결과, 메트릭을 수신하고 고유 키를 생성하는 `addSample` 및 `trackContext` 함수가 가장 많은 CPU를 점유하고 있음을 확인했습니다. * 특히 태그 중복을 제거하고 동일한 해시 값을 보장하기 위해 수행하는 태그 정렬 로직(`util.SortUniqInPlace`)이 전체 성능의 주요 장애물로 작용하고 있었습니다. ### 메트릭 컨텍스트 생성의 기술적 문제 * 고유 식별을 위해 메트릭 이름, DogStatsD 태그, 컨테이너 태그를 모두 조합하여 해시 키를 생성해야 합니다. * 해시 충돌을 방지하면서도 빠른 생성 속도를 유지해야 하며, 동일한 메트릭에 대해 항상 일관된 키를 생성하기 위해 태그 리스트를 정렬하는 과정이 필수적이었습니다. * 태그 리스트 정렬은 데이터 양이 많아질수록 비용이 급격히 증가하는 특성이 있어, 매번 메트릭이 들어올 때마다 이를 수행하는 것은 비효율적이었습니다. ### 성능 최적화를 위한 다각도 접근 * **코드 특수화(Specialization):** 모든 경우에 일반적인 정렬 알고리즘을 사용하는 대신, 태그의 개수에 따라 가장 빠른 성능을 낼 수 있는 정렬 방식을 선택적으로 적용하도록 로직을 개선했습니다. * **해시 알고리즘 및 구조 개선:** 벤치마크를 통해 속도와 고유성이 검증된 Murmur3 알고리즘을 도입했습니다. * **Go 런타임 최적화 활용:** 기존 128비트 해시를 충돌 방지에 충분한 64비트로 전환하여, Go 런타임의 최적화된 맵 접근 함수(`mapassign_fast64`, `mapaccess2_fast64`)가 동작하도록 유도함으로써 처리 속도를 가속화했습니다. 데이터 집약적인 시스템에서는 런타임 프로파일링을 통해 '핫 패스(Hot path)'를 정확히 찾아내는 것이 중요합니다. 특히 태그 정렬이나 해싱과 같은 빈번한 기본 연산에서 발생하는 미세한 오버헤드를 줄이는 것만으로도 대규모 환경에서의 전체 처리량(Throughput)을 크게 향상시킬 수 있습니다.

figma3분 읽기큐레이션 요약

디자인 시스템의 미래는 복잡

디자인 시스템은 제품과 사용자 요구가 복잡해질수록 단순한 시각 규칙 모음이 아니라, 여러 팀과 시스템을 조율하는 운영 구조가 되어야 한다. 브랜치·머지, 로컬 시스템, 오픈소스 같은 코드의 방식을 활용하면 확장성과 협업을 높일 수 있지만, 지나친 규제는 창의성과 실험을 막는다. 따라서 미래의 디자인 시스템은 구조와 유연성 사이의 균형을 지속적으로 조정해야 한다. ## 디지털 제품의 복잡성과 디자인 시스템의 변화 - 초기 디자인 시스템은 사용자가 디지털 인터페이스를 이해하도록 돕는 시각적 은유에 크게 의존했다. - Google Material Design은 종이를 쌓은 듯한 표면, 가장자리, 그림자를 사용해 조작 가능한 요소를 설명했다. - 당시에는 완전한 스큐어모피즘 없이도 사용자가 인터페이스를 직관적으로 이해하도록 만드는 것이 주요 과제였다. - 그러나 다양한 디바이스와 폼팩터가 등장하면서 단일 은유만으로는 충분하지 않게 됐다. - 접근성 기준 - 새로운 입력 방식과 상호작용 - 성능 요구사항 - 여러 화면과 플랫폼에 대응하는 반응형 경험 - Instagram처럼 하나의 핵심 기능만 제공하던 앱도 검색, 광고, 파트너십, 쇼핑 등으로 확장됐다. - 이에 따라 디자인 시스템은 더 많은 기능과 사용자 유형, 서로 연결된 제품 경험을 지원해야 한다. ## 구조로 혼란 다루기 - 디자인팀은 소프트웨어 개발에서 사용하던 프로세스와 프레임워크를 디자인 시스템에 적용하고 있다. - 대표적인 방식이 브랜치와 머지다. - 기여자가 별도의 브랜치에서 새로운 컴포넌트나 수정안을 작업한다. - 기존의 메인 시스템에 영향을 주지 않고 실험할 수 있다. - 디자인 시스템 관리자가 변경 사항을 검토한 뒤 공식 시스템에 반영한다. - 이 방식은 디자인 시스템을 중앙 팀만 관리하는 자산이 아니라, 커뮤니티와 함께 발전시키는 구조로 만든다. - Spotify의 Encore는 하위 팀이 시스템을 포크해 각자의 “로컬 시스템”을 만들도록 허용했다. - 광고 팀의 비디오 플레이어처럼 특정 도메인에 특화된 컴포넌트가 발전했다. - 이러한 결과물이 다시 전체 디자인 시스템의 방향과 적용 범위를 넓혔다. - 오픈 디자인 시스템은 외부 기여와 피드백을 받을 수 있다는 장점이 있다. - 다양한 사용자의 요구를 파악할 수 있다. - 제품과 조직의 작업 방식을 공개해 신뢰와 인지도를 높인다. - 디자인 지식을 업계와 공유할 수 있다. ## 지나치게 엄격한 시스템의 문제 - 구조를 규모 있게 적용하면 일관성은 높아지지만, 시스템이 지나치게 제한적으로 변할 수 있다. - 디자이너는 다음과 같은 문제를 경험할 수 있다. - 새로운 아이디어를 실험하기 어려움 - 제품 특성에 맞는 예외를 만들기 어려움 - 기존 컴포넌트에 억지로 맞추느라 디자인 품질이 떨어짐 - 디자인 시스템의 목적은 창의적 표현의 진입장벽을 낮추는 것이지, 창작 자체를 어렵게 만드는 것이 아니다. - 모든 상황을 사전에 정의하려는 접근은 복잡한 제품과 예상하지 못한 사용자 요구에 제대로 대응하지 못한다. ## 건축보다 정원에 가까운 운영 - Shopify의 José Torre는 디자인 시스템을 완성 후 고정하는 건축물보다 계속 돌보고 변화하는 정원에 비유한다. - 건축적 접근: - 세부 사항을 미리 결정한다. - 설계와 구축이 끝나면 결과물을 완성된 상태로 간주한다. - 정원식 접근: - 기본적인 씨앗과 구조를 심되, 최종 형태는 성장 과정에서 발견한다. - 실제 사용 중 나타나는 문제와 새로운 요구에 따라 개입한다. - 불필요한 요소는 제거하고 유용한 패턴은 발전시킨다. - 계획된 디자인 시스템 안에서도 새로운 버튼이나 메뉴 변형이 자연스럽게 등장할 수 있다. - 이런 변형을 무조건 제거하기보다, 실제 제품 요구에서 비롯된 것인지 평가하고 필요하다면 시스템에 흡수하는 유연성이 중요하다. 디자인 시스템은 엄격한 규칙집이 아니라 제품과 조직의 변화에 맞춰 계속 진화하는 기반으로 운영하는 것이 바람직하다. 공통 구조와 검토 절차는 유지하되, 브랜치·로컬 시스템·실험 공간을 허용해 팀의 자율성과 창의성을 보장해야 한다.

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

리니어가 디도스 공격을

Linear는 2022년 10월 홈페이지가 DDoS 공격으로 마비되자, 단순히 서비스를 복구하는 데 그치지 않고 Figma 디자인 파일 자체를 임시 홈페이지로 활용했다. 이 즉흥적인 대응은 공격 중에도 사용자에게 브랜드와 리디자인을 보여주는 창구가 되었고, 결과적으로 위기를 창의적인 홍보와 커뮤니티 이벤트로 전환했다. 글은 빠른 장애 대응과 대담한 아이디어, 그리고 축적된 디자인 작업물이 위기 상황에서 새로운 가치를 만들 수 있음을 보여준다. ## 출시 직전까지 이어진 대규모 디자인 작업 - Linear 팀은 새 홈페이지를 준비하며 수개월 동안 다양한 디자인 방향을 탐색했다. - 하나의 Figma 파일에 수많은 프레임, 대형 이미지, 아이디어, 반복 작업 결과물이 축적됐다. - 파일이 너무 커져 브라우저 메모리의 약 64.3%를 사용한다는 경고가 표시될 정도였다. - 출시 직전까지도 작업이 이어졌지만, 최종 결과물은 온라인에서 좋은 반응을 얻으며 큰 관심을 끌었다. - Paco Coursey는 출시 며칠 전 이 거대한 Figma 파일을 공개할지 디자이너 Edgar Ambartsoumian에게 묻는 게시물을 올렸다. ## 홈페이지를 마비시킨 DDoS 공격 - DDoS는 대량의 인터넷 트래픽으로 서버나 네트워크를 압도해 정상적인 서비스를 방해하는 공격이다. - 홈페이지 리디자인 다음 날 Linear 사이트가 다운되자, 팀은 처음에는 새 배포나 디자인 변경에 문제가 생겼다고 추측했다. - 조사 결과 원인은 비교적 흔한 유형의 DDoS 공격으로 확인됐다. - 장애 대응의 최우선 목표는 사용자가 Linear 앱에 다시 접근하도록 만드는 것이었다. - 팀은 사이트의 하위 페이지 방문자를 로그인 페이지로 직접 보내 앱 접근을 우선 복구했다. - 그러나 소셜미디어에서 화제가 된 새 랜딩 페이지를 보러 온 방문자들은 홈페이지 대신 로그인 화면만 보게 됐다. ## Figma 파일을 임시 홈페이지로 활용한 발상 - Jori Lallo는 홈페이지 대신 Figma 디자인 파일을 공개하자는 아이디어를 제안했다. - Paco는 즉시 실행 가능하다고 판단했지만, Edgar와 일부 팀원은 처음에는 다소 주저했다. - Jori는 “그냥 믿어 달라”며 아이디어를 밀어붙였다. - 결과적으로 완성된 웹사이트가 아닌 제작 과정의 Figma 파일을 공개해, 공격으로 사라진 홈페이지를 대체했다. - 파일에는 최종 디자인뿐 아니라 수개월 동안의 탐색과 반복 과정도 담겨 있어 방문자에게 제작 비하인드까지 보여줄 수 있었다. ## 장애를 브랜드 경험으로 바꾼 대응 - 일반적인 장애 대응은 서비스 복구와 원인 차단에 집중하지만, Linear 팀은 사용자가 무엇을 보게 될지까지 고려했다. - 로그인 페이지로만 연결하면 기능 접근은 가능하지만, 새 홈페이지를 기대한 방문자 경험은 크게 떨어진다는 점을 인식했다. - Figma 파일 공개는 공격으로 인한 공백을 채우면서도 Linear의 디자인 문화와 작업 방식을 직접 보여주는 방법이 됐다. - 예상치 못한 상황에서 팀의 빠른 의사결정과 디자인 자산이 결합해 온라인에서 큰 화제를 만들었다. - 이 사건은 단순한 보안 사고가 아니라, 커뮤니티가 함께 참여하는 일종의 Figma 이벤트로 발전했다. ## 실용적인 시사점 - 장애 상황에서는 기술적 복구뿐 아니라 사용자가 마주할 대체 경험도 설계해야 한다. - 평소 축적해 둔 디자인 파일, 문서, 작업 기록은 위기 때 커뮤니케이션 자산으로 활용할 수 있다. - 완벽한 대안을 기다리기보다 안전하고 실행 가능한 임시 해결책을 빠르게 시도하는 것이 효과적일 수 있다. - 단, Figma 파일 공개와 같은 대응은 내부 정보나 민감한 자산이 포함되지 않았는지 먼저 검토해야 한다.

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

Figma Persona 20

Figma Persona 2022는 21개의 질문을 통해 자신의 창의적 협업 및 업무 방식을 돌아보게 하는 퀴즈다. 아이디어를 만들고 문제를 해결하는 방식, 작업 공간과 도구를 사용하는 방식, 다른 사람과 협업하는 방식을 분석해 8가지 페르소나 중 하나를 제시한다. 이 글의 결론은 자신의 성향을 이해하고, 그에 맞는 업무 환경과 협업 방식을 의식적으로 설계하자는 것이다. ## Figma Persona 퀴즈의 목적 - 연말에 자신의 업무 방식과 협업 습관을 되돌아보고 다음 해의 목표를 세우도록 돕는다. - 21개의 질문을 통해 개인의 창의적 특성을 분석한다. - 분석 기준은 다음 세 가지 축이다. - 아이디어를 생성하고 문제를 해결하는 방식 - 작업 공간을 구성하고 Figma 도구를 활용하는 방식 - 다른 사람과 소통하고 협업하는 방식 - 결과는 총 8개의 Figma Persona 중 하나로 나타난다. - 퀴즈 자체도 Figma 파일과 FigJam을 활용해 동료들과 함께 진행할 수 있도록 구성됐다. ## 정리된 개인주의자 정리된 개인주의자는 명확한 프로세스와 개인의 책임 범위를 선호하는 유형이다. - 혼자 집중할 수 있는 시간을 가진 뒤 팀과 다시 공유하는 방식을 좋아한다. - 실시간 회의보다 비동기 업데이트, 버그 검토, 명확한 마일스톤을 선호한다. - 정돈된 작업 환경과 분명한 산출물, 체계적인 프로세스에서 높은 생산성을 발휘한다. - 협업할 때는 충분히 생각할 시간을 주고, 사전 자료와 기대 결과를 명확하게 전달하는 것이 효과적이다. - 요청 사항을 모호하게 표현하기보다 구체적이고 정확하게 설명해야 한다. ## Type 1: Lone Ascender Lone Ascender는 체계적이고 분석적인 개인주의자다. - 복잡한 문제를 해결할 때 강점을 보인다. - 전술적이고 실용적이며 시스템 중심의 해결책을 선호한다. - 거의 모든 일에 자신만의 프로세스를 만들 정도로 구조화된 업무 방식을 갖고 있다. - 단축키, 색상 코드 등 도구 사용법을 빠르게 익히고 반복 작업을 효율화한다. - 이상적인 접근보다 현실적이고 확장 가능한 해결책을 중시한다. - 협업 자체를 거부하지는 않지만, 자신의 파일 구조와 작업 규칙이 흐트러지는 것을 불편해할 수 있다. - 적절한 도구로는 Figma의 단축키와 빠른 실행 기능, 다양한 FigJam 템플릿 등이 제시된다. ## 나머지 Figma Persona 유형 글은 Lone Ascender 외에도 다음 7가지 협업 성향을 제시한다. - **Canvas Captain**: 캔버스와 작업 공간을 주도적으로 구성하고 관리하는 유형 - **Direct Mobilizer**: 명확하고 직접적인 소통으로 사람들을 움직이는 유형 - **Artful Detacher**: 작업과 감정을 적절히 분리하고 필요할 때 한발 물러나는 유형 - **Bounding Boxer**: 작업 범위와 구조를 명확히 설정하는 유형 - **Branch Merger**: 여러 아이디어나 작업 흐름을 하나로 통합하는 유형 - **Vector Networker**: 다양한 사람과 연결하며 협업 네트워크를 확장하는 유형 - **Bézier Curve Baller**: Figma의 세부적인 디자인 기능과 조형적 표현을 능숙하게 다루는 유형 이 유형들은 우열을 가리는 분류가 아니라, 각자가 아이디어를 만들고 파일을 다루며 협업하는 방식을 재미있게 이해하기 위한 자기 진단 도구다. ## 자신의 Persona를 협업에 활용하는 방법 - 자신의 강점뿐 아니라 협업 과정에서 생길 수 있는 불편함도 파악한다. - 혼자 생각할 시간이 필요한 사람에게는 회의 전에 비동기 사전 작업을 제공한다. - 업무 요청 시 목표, 산출물, 마감일, 의사결정 기준을 구체적으로 제시한다. - 정리와 구조화를 중시하는 사람에게는 자유로운 브레인스토밍만 요구하기보다 명확한 범위와 기대치를 함께 전달한다. - 팀원마다 작업 방식이 다르다는 점을 인정하면 불필요한 충돌을 줄이고 협업 효율을 높일 수 있다. 자신의 Persona를 고정된 성격 유형으로 받아들이기보다, 현재의 업무 습관을 점검하는 출발점으로 활용하는 것이 좋다. 특히 팀 전체가 함께 퀴즈를 진행하면 서로에게 필요한 소통 방식과 협업 조건을 더 쉽게 이해할 수 있다.

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

Magician이 Figma의 텍스트

Figma의 텍스트 리뷰 API는 플러그인이 별도 창을 띄우지 않고 Figma 편집기 안에서 텍스트를 감지하고 대체 문구를 제안하도록 한다. Diagram은 이를 맞춤법 검사 대신 AI 카피라이팅 기능인 Magician의 “Magic Copy”에 활용해, 사용자가 입력하는 헤드라인·본문·CTA의 대안을 실시간으로 제시한다. 이 사례는 디자인 도구와 AI를 결합할 때 작게 시작해 반복적으로 실험하고, 상황에 맞는 출력 품질을 다듬는 것이 중요하다는 점을 보여준다. ## Figma 텍스트 리뷰 API의 역할 - 텍스트 리뷰 API는 Figma Plugin API의 새로운 기능이다. - 사용자가 캔버스에서 입력하는 텍스트를 자동으로 실행 중인 기본 텍스트 리뷰 플러그인이 분석할 수 있다. - 플러그인은 텍스트의 특정 범위를 강조하고, 수정 또는 대체를 위한 제안 목록을 제공한다. - 맞춤법과 문법 교정뿐 아니라 다음과 같은 기능에도 활용할 수 있다. - 더 나은 카피 제안 - 기업 스타일 가이드 준수 - 문장 표현 개선 - 특정 문구의 대체안 생성 - 일반적인 플러그인 창과 달리 백그라운드에서 동작하며 Figma 편집기 UI에 자연스럽게 통합된다. ## Magician과 Magic Copy - Magician은 Diagram이 만든 Figma용 AI 디자인 도구다. - 디자인 작업 중 아이디어를 확장하고 창의적 작업을 돕는 것을 목표로 한다. - 주요 기능은 “매직 스펠”이라는 형태로 제공된다. - **Magic Icon**: 새로운 아이콘 생성 - **Magic Image**: 디자인에 사용할 이미지 생성 - **Magic Copy**: 문구 작성과 대안 제안 - Magic Copy는 텍스트 레이어를 편집할 때 기존 문구를 바탕으로 여러 대안을 제시한다. - 헤드라인, 본문, 행동 유도 문구(CTA) 등 다양한 디자인 문구에 사용할 수 있다. ## 텍스트 리뷰 API를 활용한 AI 카피라이팅 - Magic Copy는 사용자가 입력하는 텍스트를 텍스트 리뷰 API를 통해 감지한다. - 사용자가 별도의 플러그인 창을 조작하지 않아도 편집 흐름 안에서 제안이 나타난다. - 글이 잘 떠오르지 않는 상황에서 기존 문구를 개선하거나 새로운 표현을 탐색하는 데 유용하다. - AI가 작성한 대안을 비교하면서 디자이너가 더 빠르게 문구를 결정할 수 있다. - 텍스트 리뷰 API의 본래 용도인 맞춤법 검사를 넘어, 글쓰기 보조 도구로 확장한 사례다. ## 하나의 확장 가능한 플러그인으로 통합 - Magician은 처음에는 Magic Copy와 Magic Icon 등이 각각 별도의 플러그인으로 계획됐다. - 이후 여러 AI 기능을 하나의 플러그인에 모으는 방향으로 전환했다. - 이를 통해: - 여러 “매직 스펠”을 하나의 경험으로 제공할 수 있고 - 새로운 기능을 일관된 방식으로 추가할 수 있으며 - 아이디어를 빠르게 실험하고 검증할 수 있게 됐다. - 핵심은 개별 기능을 독립적으로 만드는 대신, 새로운 AI 기능을 계속 수용할 수 있는 기반과 플랫폼을 먼저 마련한 것이다. ## AI 기능을 반복적으로 개선하는 방식 - Diagram은 Magician의 각 기능이 다양한 상황에서도 일관되고 유용한 결과를 내도록 출력 품질을 조정했다. - 이를 위해 많은 입력과 결과를 시험하고, 효과적인 방식이 무엇인지 반복적으로 확인했다. - Stable Diffusion과 OpenAI 같은 생성형 AI 모델의 발전은 이러한 실험을 빠르게 수행할 수 있게 했다. - AI 도구를 처음부터 완성된 제품으로 만들기보다 작은 기능으로 시작해 사용자 경험과 출력 결과를 계속 개선하는 접근을 강조한다. 실용적으로는 텍스트 리뷰 API를 단순한 맞춤법 검사에만 한정하지 말고, 제품 문구·브랜드 가이드·콘텐츠 생성 등 편집 흐름에 직접 연결되는 기능에 활용할 수 있다. 다만 AI 제안은 반복적인 품질 검증과 세밀한 출력 조정이 필요하므로, 작은 사용 사례부터 시작해 점진적으로 확장하는 것이 적절하다.

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

WIP에 오신 것을 환영

디지털 제품 개발은 연구→아이디어→설계→테스트→출시로 끝나는 선형 과정이 아니라, 계속 수정·공유·협업하는 “진행 중인 작업(WIP)”에 가깝다. 이 변화는 초기 공유와 빠른 피드백을 가능하게 하지만, 피드백의 유효성이 쉽게 사라지고 최종 상태를 판단하기 어려워지는 혼란도 만든다. 따라서 완벽한 검토 시점을 기다리기보다 예측 가능한 주기로 작업을 검토하고, WIP 상태에 맞는 협업 방식을 설계해야 한다. ## 선형적 제품 개발 모델의 한계 - 전통적인 제품 개발은 다음과 같은 이상적인 순서를 전제로 한다. - 리서치 - 브레인스토밍 - 스케치 - 테스트 - 출시 - 물리적 제품은 제작과 변경에 비용이 많이 들었기 때문에 단계별로 신중하게 진행하는 선형 프로세스가 중요했다. - 하지만 디지털 제품은 몇 분 만에도 업데이트할 수 있어, 문제 정의·해결책·제품이 명확히 고정된 순간을 찾기 어렵다. - 실제 프로젝트는 이전 단계로 되돌아가거나 여러 단계가 동시에 진행되는 등 훨씬 비선형적이고 복잡하다. ## 디지털 제품은 항상 진행 중이다 - 브라우저 기반 협업 도구에서는 파일이 이메일로 전달되는 정적 문서가 아니라, 누구나 URL을 통해 동시에 확인하고 수정하는 공동 작업 공간이 된다. - 실시간으로 수정할 수 있기 때문에 팀은 완성될 때까지 기다리지 않고 초기 결과물을 더 일찍 공유한다. - 파일 제목에 `[WIP]` 또는 `Work in Progress`를 표시하면 결과물이 미완성임을 알리고, 피드백을 주는 사람의 부담과 기대치를 낮출 수 있다. - 디자이너는 초기 방향을 제품 관리자와 공유하고, 작가는 초고를 편집자에게 보여주는 방식으로 작업 초기에 협업할 수 있다. ## WIP 협업이 만드는 새로운 문제 - 작업이 계속 바뀌면 과거에 남긴 댓글이나 피드백이 더 이상 현재 결과물에 적용되지 않을 수 있다. - 전날 합의하거나 승인한 내용이 다음 날에는 이미 변경되어, “무엇이 확정되었는가”를 추적하기 어려워진다. - 파일이 실제로 최종 상태가 되는 명확한 순간이 없으며, 제품 출시 후에도 WIP 표시를 삭제하지 않는 경우가 생긴다. - 따라서 팀 구성원이 변화와 피드백을 놓치지 않도록 지속적인 알림과 소통 체계가 필요하다. - Figma는 이러한 문제를 보완하기 위해 알림과 모바일 댓글 기능을 제공하고, Google Calendar·Microsoft Teams·Zoom 등 외부 도구와의 연동도 확장하고 있다. ## 완벽한 검토 시점보다 예측 가능한 검토 주기 - 항상 변화하는 환경에서는 다음 중 언제 리뷰해야 할지 판단하기 어렵다. - 문제를 정의할 때 - 해결책을 정렬할 때 - 출시 직전 - 이상적인 방식은 작업이 각 단계를 자연스럽게 통과하며 팀의 확신이 점점 높아지는 것이지만, 실제로는 작업 상태가 계속 움직인다. - 특정 단계가 “완벽해질 때”까지 기다리기보다, 정해진 주기에 따라 정기적으로 리뷰하면 이해관계자와 팀이 지속적으로 방향을 확인할 수 있다. - 예측 가능한 리뷰 cadence는 피드백을 한 번에 몰아서 받는 대신, 작업의 변화에 맞춰 반복적으로 조정할 수 있게 한다. - 결과적으로 중요한 것은 최종 승인 순간을 찾는 것이 아니라, 반복적인 검토를 통해 제품 방향에 대한 신뢰를 점진적으로 높이는 것이다. ## 실용적인 적용 방법 - 초기 산출물에는 WIP 상태를 명확히 표시해 피드백의 기대 수준을 조정한다. - 피드백이 특정 버전이나 상태를 기준으로 한다는 점을 댓글과 리뷰 기록에 남긴다. - 완벽한 결과물을 기다리지 말고 정기적인 리뷰 일정을 운영한다. - 알림, 모바일 댓글, 협업 도구 연동을 활용해 작업 변화와 의사결정을 공유한다. - “완료”를 단 한 번의 최종 승인으로 정의하기보다, 반복적인 검토와 업데이트의 과정으로 바라보는 것이 적합하다.

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

피그마 접근성 팀과의 대화 | 피그마 블로그

Figma의 접근성 팀은 스크린 리더 지원을 개발 초기부터 다양한 사용자와 함께 검증해야 한다고 강조한다. 프로토타입 스크린 리더 베타를 통해 VoiceOver와 JAWS의 차이, 저시력 사용자의 시각·음성 병행 사용, 키보드 포커스의 중요성을 확인했다. Figma는 앞으로도 접근성 파트너와 협력해 지원 범위를 넓히고, 디자이너가 생성 HTML과 접근성 품질을 더 직접적으로 관리할 수 있는 도구를 제공할 계획이다. ## 오픈 베타를 통해 확인한 실제 사용자 요구 - 내부 테스트만으로는 실제 사용 환경과 보조공학 사용자의 요구를 충분히 파악하기 어렵다. - Mac VoiceOver에서는 잘 작동하던 기능도 JAWS 등 다른 스크린 리더에서는 추가 조정이 필요했다. - 스크린 리더 사용자는 시각 정보를 전혀 사용하지 않는 경우만 있는 것이 아니다. - 저시력 사용자는 화면의 시각 정보와 음성 정보를 함께 활용할 수 있다. - 다양한 상호작용 방식을 제공하면 더 넓은 사용자에게 도움이 된다. - 이에 따라 Figma는 주요 스크린 리더 기술을 개발 후반이 아니라 초기 단계부터 테스트하기로 했다. ## 시각 경험과 스크린 리더 경험의 연결 베타 테스트 결과, 스크린 리더 사용 경험은 시각적 UI와 분리된 별도 기능이 아니라 두 경험이 서로 보완되어야 한다는 점이 드러났다. - 접근성 트리에 요소의 위치 정보를 제공해, 시각 정보를 일부 활용하는 사용자가 스크린 리더 커서의 화면상 위치를 파악할 수 있게 했다. - 클릭 가능한 요소에 키보드 포커스가 있을 때도 “On hover” 상호작용을 실행하도록 조정했다. - 스크린 리더 커서가 이동하면 스크롤 영역도 함께 이동하도록 구현했다. - 프로토타입 도구 모음이 자동으로 숨겨질 때 키보드 포커스를 고려했다. - 화면을 탐색할 때 도구 모음이 방해되지 않아야 한다. - 동시에 현재 포커스된 컨트롤은 계속 화면에 보여야 한다. - 개발 과정에서 접근성 사용자를 단순히 “시각 사용자”와 “음성 사용자”로 나누는 기존 가정을 수정하게 됐다. ## 접근 가능한 프로토타입 진입 경로 프로토타입 자체가 스크린 리더로 접근 가능하더라도, Figma 디자인에서 해당 프로토타입으로 이동할 방법이 없으면 전체 경험은 접근 가능하지 않다. - 실제 출시 과정에서 프로토타이핑 모드로 바로 이동하는 단축키를 추가했다. - Mac: `Option + Command + Return` - PC: `Alt + Ctrl + Enter` - 스크린 리더 지원을 지속적으로 켤 수 있는 토글을 제공했다. - Figma Community를 통해 접근성 기능 사용법을 더 적극적으로 안내했다. - 기능 단위가 아니라 사용자가 처음부터 끝까지 수행하는 전체 흐름을 검증해야 한다는 교훈을 얻었다. ## 접근성 파트너와의 공동 테스트 Figma는 보조공학 사용자와 기업을 연결하는 Fable과 협력해 기능을 검증하고 있다. - Fable은 특정 사용자 흐름 테스트부터 심층 사용자 인터뷰까지 지원한다. - 사용자 피드백을 반영해 접근성 관련 컨트롤과 키보드 단축키를 더 쉽게 찾도록 개선하고 있다. - 접근성 탐색용 키보드 단축키를 키보드 단축키 패널에 포함하는 작업을 진행했다. - 키보드 단축키 패널 자체도 스크린 리더와 키보드로 접근 가능하도록 개선 중이다. - FigJam에서는 화면 구성의 정보 계층을 명확히 전달하기 위해 다음 정보를 스크린 리더에 제공한다. - 각 항목의 자식 수 - 형제 항목 수 - 캔버스 내 요소의 맥락을 파악하는 데 필요한 구조 정보 - 다양한 스크린 리더 소프트웨어와 숙련도 차이를 고려하면서 기능을 조정할 수 있었다. ## 앞으로의 접근성 방향 Figma 팀은 현재의 프로토타입 스크린 리더 지원이 완성된 상태가 아니라고 설명한다. - 콘텐츠가 기본적으로 스크린 리더 사용자에게 항상 제공되도록 하는 것을 우선순위로 삼고 있다. - 디자이너가 Figma가 생성하는 HTML을 더 세밀하게 제어할 수 있도록 할 계획이다. - 스크린 리더에 익숙하지 않은 디자이너도 자신의 디자인 접근성을 평가할 수 있는 도구를 개발하려 한다. - 접근성을 출시 직전의 점검 항목이 아니라 제품 설계와 개발 전반에 포함되는 기준으로 정착시키려 한다. 접근성 기능을 만들 때는 특정 스크린 리더 하나만 기준으로 삼지 말고, 실제 보조공학 사용자와 함께 초기 단계부터 테스트하는 것이 중요하다. 또한 개별 기능의 접근성뿐 아니라 사용자가 해당 기능에 도달하고, 탐색하고, 조작하는 전체 경로를 검증해야 한다.

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

피그마의 피드백 선물

피드백은 단순한 지적이 아니라 상황과 관계에 맞게 전달해야 하는 ‘선물’이다. 효과적인 피드백을 위해서는 프로젝트 단계, 팀의 협업 문화, 상대방의 시간대와 업무 방식 등을 고려해야 하며, 의도와 전달 방식이 어긋나면 관계가 악화되고 프로젝트가 불필요한 반복 논의에 빠질 수 있다. 특히 디자인의 완성도에 맞춰 피드백의 범위와 깊이를 조절하는 것이 중요하다. ## 피드백을 전달할 적절한 시점 - 좋은 피드백은 내용뿐 아니라 **언제 전달하느냐**에 따라 효과가 달라진다. - 회사, 팀, 프로젝트, 개인마다 일정과 제약이 다르므로 가장 건설적으로 받아들여질 시점을 선택해야 한다. - 프로젝트 단계에 따라 피드백의 목적을 명확히 해야 한다. - **브레인스토밍**: 다양한 가능성을 확장하는 단계이므로 너무 일찍 범위를 좁히는 피드백은 피한다. - **초기 콘셉트**: 리서치와 데이터를 활용해 선택지를 합리적으로 좁힌다. - **제품 리뷰**: 결과물이 제품 및 비즈니스 목표와 일치하는지 확인한다. - **디자인 크리틱**: 구체적인 UX·비주얼 개선 의견과 제품 간 일관성을 논의한다. - **프로토타입**: 사용성 및 애니메이션에 초점을 맞춘다. - **고해상도 디자인**: 세부 요소를 꼼꼼히 검토해 디자이너가 놓친 부분을 보완한다. - **최종 디자인**: 모든 주요 플로우와 사용 사례가 다뤄졌는지 확인한다. - 피드백을 요청할 때 어떤 종류의 의견이 필요한지 미리 설명하면 참여자들이 논의의 초점을 맞출 수 있다. ## 팀의 피드백 문화에 맞추기 - 협업 중심의 문화는 하루아침에 만들어지지 않으며, 조직의 변화에는 수년이 걸릴 수 있다. - 팀이 피드백 문화를 구축하는 초기 단계라면: - 피드백의 목적과 프로젝트 맥락을 충분히 설명한다. - 중요한 논의를 초기에, 그리고 자주 진행한다. - 피드백을 주고받는 방식은 실제 협업 과정에서 조정될 수 있으며 처음부터 완벽하지 않아도 된다. - 이미 피드백 문화가 정착된 팀이라면: - 검증된 채널과 절차를 활용해 보다 직접적으로 의견을 전달한다. - 팀원들이 익숙한 협업 방식과 커뮤니케이션 규칙을 존중한다. - 팀의 문화 수준에 맞지 않는 방식으로 피드백하면 좋은 의도라도 부담이나 저항으로 받아들여질 수 있다. ## 시간대와 업무 리듬 존중하기 - 다른 시간대에서 일하는 동료에게 이른 아침이나 늦은 밤에 갑작스럽게 메시지를 보내는 일을 피한다. - 팀원마다 근무 시간과 집중이 잘되는 시간이 다르므로 일정과 개인 선호를 파악해야 한다. - 상대방의 시간과 에너지를 존중하고, 자신의 업무 방식과 응답 가능 시간도 명확히 공유한다. - 작은 일정 조율과 기대치 설정만으로도 협업 과정의 마찰을 크게 줄일 수 있다. ## 실용적인 적용 방법 - 피드백 전에 “지금 이 단계에서 어떤 결정을 내려야 하는가?”를 먼저 확인한다. - 의견을 전달할 때 원하는 피드백의 범위와 우선순위를 구체적으로 제시한다. - 초기 단계에서는 가능성을 열어 두고, 후반 단계로 갈수록 실행 가능성·세부 품질·누락된 사용 사례를 집중적으로 검토한다. - 팀의 협업 성숙도와 상대방의 일정에 맞춰 채널, 표현, 전달 시점을 조정한다.

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

코드에서 영감 얻기 | Figma

디자인 시스템이 복잡성과 규모를 감당하려면 코드의 설계 원칙에서 배울 필요가 있다. 특히 고정된 컴포넌트와 과도한 변형 조합 대신 구성(composition), 구조와 표현의 분리, 체계적인 변경 관리가 중요하다. 궁극적으로 디자인 시스템은 창의성을 제한하는 규칙 모음이 아니라, 유연성과 일관성을 함께 제공하는 제품처럼 운영되어야 한다. ### 디자인의 복잡성과 코드에서 얻는 교훈 - 과거에는 디자인 파일이 개인 컴퓨터에 저장되어 협업이나 파일 간 의존성을 크게 신경 쓰지 않아도 됐다. - 오늘날에는 여러 팀과 기여자가 서로 연결된 시스템을 동시에 다루므로 일관성, 품질, 확장성을 관리해야 한다. - 디자인 시스템은 복잡성을 줄이는 데 도움을 주지만, 구조가 지나치게 강해지면 자유로운 탐색과 표현을 방해할 수 있다. - Figma는 이러한 문제에 대응하기 위해 디자인이 코드의 엔지니어링 프레임워크를 차용하고 있다고 설명한다. ### 중첩 컴포넌트로 유연한 레이아웃 구성 - 단순한 시스템에서는 하나의 컴포넌트에 몇 가지 변형(variant)만 정의하면 된다. - 카드처럼 가로형·세로형 등 레이아웃이 다양해지면 모든 경우를 variant로 만드는 방식은 유지보수가 어려워진다. - 컴포넌트 속성으로 이미지, 인용문 등 선택적 요소를 제어할 수 있지만, 구조 자체가 크게 다른 레이아웃에는 한계가 있다. - 작은 하위 컴포넌트를 만든 뒤 이를 큰 컴포넌트 안에 중첩하는 **구성(composition)** 방식을 사용할 수 있다. - 이미지, 제목, 가격, 버튼 같은 하위 컴포넌트를 다양한 방식으로 조합하면 시스템 관리자가 미리 예상하지 못한 레이아웃도 유연하게 만들 수 있다. - 이는 코드에서 재사용 가능한 모듈을 조합해 여러 기능을 구현하는 방식과 유사하다. ### 구조와 표현의 분리 - 초기 디자인 시스템은 컴포넌트에 특정 색상을 직접 지정하는 단순한 형태로 시작하는 경우가 많다. - 이후 다크 모드가 필요해지고, 제품·브랜드별 색상까지 추가되면서 테마 관리가 복잡해진다. - 제품과 하위 브랜드가 늘어날수록 각 컴포넌트에 색상과 스타일을 직접 넣는 방식은 조직의 관리 부담을 키운다. - 이러한 문제를 해결하려면 컴포넌트의 구조와 시각적 표현을 분리하는 새로운 아키텍처가 필요하다. - 글에서는 그 대안으로 **헤드리스 디자인 시스템(headless design system)**을 소개하려 하지만, 제공된 본문은 해당 설명 중간에서 끝난다. ### 실용적인 결론 컴포넌트의 모든 경우를 미리 variant로 만들기보다, 재사용 가능한 하위 컴포넌트를 조합하는 구조를 우선 고려하는 것이 좋다. 또한 색상·테마 같은 표현 요소를 구조와 분리하면 다크 모드, 멀티브랜드, 하위 제품 확장에 더 효과적으로 대응할 수 있다.

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