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

datadog·2024년 3월 26일원문

엔지니어링 스포트라이트: 마리로르 바르도네 (새 탭에서 열림)

데이터독(Datadog)의 시니어 엔지니어링 매니저 마리 로르 바르도네(Marie-Laure Bardonnet)는 인턴으로 시작해 대규모 로그 관리 팀을 이끄는 리더로 성장하며, 기술적 호기심과 자기 주도적인 커리어 설계의 중요성을 강조합니다. 그녀는 제품 로드맵과 시스템 신뢰성 사이의 균형을 맞추는 엔지니어링 중심의 의사결정 체계를 구축하고, 조직의 성장에 맞춘 유연한 팀 구조 재편을 통해 구성원과 제품이 함께 성공할 수 있는 환경을 조성하고 있습니다. 이러한 여정은 기술적 전문성을 바탕으로 리더십 역량을 확장하려는 엔지니어들에게 실무적인 통찰과 커리어 확장의 방향성을 제시합니다. ### 프론트엔드에서 대규모 백엔드로의 기술적 전환 * **제품 기여:** 인턴 시절부터 노트북(Notebooks) 제품 개발에 참여했으며, 정규직 전환 후 대시보드 팀에서 모든 화면 크기에 대응하는 반응형 그리드 시스템의 백엔드 레이아웃을 구현했습니다. * **도전 과제 확장:** 분산 백엔드 시스템에 대한 호기심을 바탕으로 로그(Logs) 백엔드 팀으로 이동하여, 매일 수백만 건의 페이로드를 실시간으로 수집(Ingestion), 처리, 농축(Enrichment), 저장 및 쿼리하는 대규모 시스템을 경험했습니다. * **플랫폼 협업:** 로그 제품의 기술적 요구사항이 복잡해짐에 따라, 공통 기능을 대규모로 제공하는 플랫폼 팀과 긴밀히 협력하여 로그 서비스의 성능을 강화했습니다. ### 시니어 엔지니어링 매니저의 역할과 의사결정 * **로드맵 균형:** 분기별로 OKR(Objectives and Key Results)을 설정할 때, 제품 팀의 요구사항과 시스템 신뢰성, 확장성, 기술 부채 해결과 같은 기술적 로드맵 사이의 정교한 균형을 유지합니다. * **기술 문서 리뷰:** 팀의 의사결정을 지원하기 위해 RFC(Request for Comments)와 장애 사후 분석 보고서(Postmortems)를 검토하며 팀 간의 의존성을 식별하고 노력을 정렬합니다. * **채용 위원회 활동:** 매주 채용 위원회에 참여하여 최종 채용 권고를 내리고, 조직 전체의 엔지니어 레벨링(Leveling)이 일관되게 유지되도록 관리합니다. ### 효율적인 실행을 위한 조직 구조 재편 * **미래 예측 기반 구조화:** '1년 후 우리가 해결해야 할 문제는 무엇인가?'라는 질문을 바탕으로, 제품과 구성원이 모두 성공할 수 있는 방향으로 팀 구조를 재설계합니다. * **3-Horizon Plan:** 제품 관리 팀과 협력하여 3단계 지평 계획을 수립하고, 고객의 니즈에 맞춰 미래 투자를 합리화하며 조직의 목표를 정렬합니다. * **성장 기회 창출:** 각 구성원의 레벨과 트랙(IC 또는 매니지먼트)에 적합한 업무 범위와 도전 과제를 할당하고, 적절한 멘토링이 제공될 수 있도록 환경을 조성합니다. ### 자기 주도적 커리어 성장 전략 * **성찰과 분리:** 현재 하고 있는 일과 미래에 하고 싶은 일을 분리하여 생각하고, 자신이 업무에서 얻는 즐거움과 남기고 싶은 유산(Legacy)이 무엇인지 파악해야 합니다. * **다각적 균형:** 자신이 좋아하고 잘하는 일, 새로운 학습을 돕는 일, 그리고 조직의 우선순위에 부합하는 일 사이에서 균형점을 찾는 것이 중요합니다. * **불확실성 수용:** 성장은 익숙한 환경에서 벗어나 모르는 것을 받아들이고 도전할 때 발생하며, 동료들의 피드백을 성장의 검증 도구로 활용해야 합니다. **실용적인 제언** 엔지니어로서 커리어를 확장하고 싶다면 현재의 직무에 안주하지 말고 기술적 호기심을 따라 팀 이동이나 직군 전환을 적극적으로 타진해 보세요. 특히 매니지먼트 트랙을 고민한다면 기술적 문서를 리뷰하는 역량과 더불어, 조직의 비즈니스 목표와 기술적 건전성 사이의 우선순위를 조율하는 연습이 필수적입니다.

datadog로그 관리okrsbackend-systems+4

figma·2024년 3월 19일·3분 읽기큐레이션 요약

AI + 디자인: 피

생성형 AI의 성패는 기술 자체보다 사용자가 이해하고 실제로 활용할 수 있도록 설계하는 데 달려 있다. Figma 설문에서 대부분은 AI가 기업 제품에 영향을 줄 것으로 예상했지만, 실제 제품에서 AI의 역할은 아직 제한적이며 성과와 만족도도 낮았다. 따라서 단순히 AI 기능을 추가하기보다 기존 경험과 자연스럽게 통합하고 명확한 사용자 문제를 해결하는 디자인이 중요하다는 결론이다. ## 조사 대상과 AI의 현재 위치 - Figma는 2024년 2월 26일~3월 3일, 미국·캐나다·호주·영국·일본·프랑스·독일의 사용자 1,800명 이상을 조사했다. - 응답자는 디자이너, 개발자, 임원으로 구성됐다. - 생성형 AI는 텍스트·이미지·기타 데이터를 생성 모델과 프롬프트를 통해 만들어내는 기술로 정의됐다. - AI는 인터넷, 전기, 스마트폰처럼 범용 기술로 발전할 가능성이 있지만, 초기에는 기술을 일상에서 직관적이고 유용하게 만드는 디자인 작업이 필요하다. ## 높은 기대와 실제 성과의 격차 - 응답자의 89%는 향후 12개월 안에 AI가 자사 제품이나 서비스에 어느 정도 영향을 줄 것이라고 예상했다. - 37%는 그 영향이 “상당하거나 변혁적일 것”이라고 답했다. - 특히 의사결정을 담당하는 임원층이 AI를 회사 목표에 중요하다고 보는 경향이 더 강했다. - 그러나 AI를 제품에 도입한 사람 중 72%는 AI가 제품에서 “부수적이거나 필수적이지 않은 역할”을 한다고 평가했다. - AI 도입으로 매출, 비용, 시장점유율 등의 지표가 개선됐다고 답한 사람은 약 3분의 1에 불과했다. - 출시한 AI 기능을 자랑스럽게 생각한다는 응답도 3분의 1보다 적었다. ## AI 기능 피로와 사용자 문제의 부재 - Figma 연구진은 사용자 인터뷰와 장기간 분석을 통해 “또 하나의 AI 기능”에 대한 무관심이 나타나고 있다고 설명한다. - 이를 “AI feature fatigue”, 즉 AI 기능 피로라고 부를 수 있다. - AI 제품이나 기능을 만드는 사람 중 20% 이상은 “사용자 요구나 문제를 해결하지 못하는 것”을 주요 과제로 꼽았다. - 이 문제는 특히 해당 제품을 설계하는 디자이너에게 두드러졌다. - AI 제품을 개발 중인 응답자 가운데 실제로 기능을 출시한 사람은 절반에도 못 미쳤다. - 앞으로 AI 기능이 대량으로 출시되면, 시장이 실질적 가치 없는 AI 기능에 피로감을 느낄 가능성이 있다. ## 기존 제품에 AI를 자연스럽게 통합하기 - 응답자의 3분의 1은 11개 과제 중 “AI 기능을 기존 제품에 일관성 있게 통합하는 일”을 가장 중요한 우려로 선택했다. - 새로운 기능을 추가하는 것만으로는 AI 도입의 가치가 만들어지지 않는다. - AI가 제품의 기존 사용 흐름을 방해하지 않으면서 실제 경험을 개선해야 한다. - 사용자가 현재 어떤 도구를 이용할 수 있는지, AI가 어떤 상황에서 도움이 되는지 이해하도록 안내하는 설계가 필요하다. - AI의 성능보다 사용자가 기능을 발견하고, 이해하고, 신뢰하며, 반복해서 사용할 수 있는 인터페이스가 중요하다. ## ChatGPT 사례가 보여주는 디자인의 영향 - ChatGPT가 널리 사용되기 시작한 2022년 11월 당시 기반 모델의 기능은 이미 일정 기간 제공되고 있었다. - OpenAI는 모델 자체를 새롭게 만든 것뿐 아니라, 사용자가 쉽게 접근할 수 있는 대화형 채팅 인터페이스를 제공했다. - 대화 방식, 접근성, 도움을 주려는 상호작용 구조가 기술을 인간의 목적에 더 잘 맞도록 만들었다. - 이는 강력한 기술이라도 사용자가 이해하고 활용할 수 있는 경험으로 설계되지 않으면 대중적 채택으로 이어지기 어렵다는 점을 보여준다. ## 실용적인 시사점 - AI 기능을 추가하기 전에 해결하려는 사용자 문제와 기대 효과를 먼저 정의해야 한다. - “AI를 넣는 것”보다 기존 제품 흐름에서 AI가 어떤 행동을 개선하는지 검증해야 한다. - 사용자가 기능의 한계와 활용 방법을 이해할 수 있도록 명확한 안내와 피드백을 제공해야 한다. - 기술팀과 디자인팀이 협력해 AI의 가능성을 실제 사용 사례와 유용한 경험으로 변환해야 하며, 단순한 유행성 기능은 피하는 것이 좋다.

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

FigmaAI사용자 경험생성형 AI+2

figma·2024년 3월 18일·3분 읽기큐레이션 요약

지금 바로 북마크해야 할

프로토타이핑은 제품 개발 막바지의 보조 수단이 아니라, 아이디어 검증·사용자 조사·이해관계자 피드백·프레젠테이션 등 전 과정에서 팀의 공통 비전을 만드는 핵심 도구다. 이 글은 Figma 프로토타이핑 학습을 위해 기초 강의부터 발표, 모션과 플로우, 변수, 오피스 아워까지 23개의 영상·커뮤니티 파일·콘텐츠를 단계별로 큐레이션한다. 학습자는 자신의 수준과 목적에 맞는 자료를 골라 인터랙션 구현 능력을 높이고 더 나은 제품을 설계할 수 있다. ## 프로토타이핑의 역할 - 프로토타입은 제품의 동작과 사용자 경험을 시각화해 팀이 아이디어를 공유하도록 돕는다. - 사용자 테스트와 이해관계자 피드백을 통해 문제를 조기에 발견하고 반복적으로 개선할 수 있다. - 발표 자료에도 인터랙션을 추가해 정적인 화면보다 설득력 있게 제품의 흐름과 기능을 전달할 수 있다. - Figma는 모바일·태블릿·워치 등 다양한 디바이스 화면을 고려한 프로토타이핑 기능을 강화하고 있다. ## 기초 기능 익히기 - **「Build prototypes」(8분)** - 인터랙티브 프로토타입 제작의 기본 흐름을 소개한다. - 애니메이션을 적용하고 테스트 사용자에게서 피드백을 반영하는 방법을 다룬다. - **「Prototyping playlist」(50분)** - easing curve, transition, Smart Animate, 스크롤, 디바이스 프레임 등 핵심 기능을 짧은 영상들로 학습할 수 있다. - **「Prototyping 101」(63분)** - 프레임 간 기본 내비게이션부터 인터랙티브 컴포넌트 같은 고급 기능까지 설명한다. - **제품 담당자를 위한 Figma 학습 시리즈** - 디자이너가 아닌 제품 담당자도 가벼운 프로토타입을 직접 만들 수 있도록 안내한다. - 두 번째 영상에서는 transition, Smart Animate, 스크롤 동작 등을 활용해 화면을 더 실제처럼 만드는 방법을 다룬다. - **접근 가능한 프로토타입 커뮤니티 파일** - Figma의 접근성 모드를 활용해 프로토타이핑 화면의 정보를 스크린 리더로 읽을 수 있다. - macOS의 VoiceOver와 Windows의 JAWS 같은 도구를 통한 접근성 테스트에 활용할 수 있다. ## 발표 자료를 인터랙티브하게 만들기 - **「Presenting with Figma」(70분)** - Figma 프로토타이핑 기능을 활용해 역동적인 슬라이드 프레젠테이션을 구성하는 방법을 소개한다. - **발표 팁 영상** - 슬라이드 안에 프로토타입을 중첩해 실제로 스크롤되는 모바일 화면 등 인터랙티브 요소를 넣을 수 있다. - 이 방식은 이사회 보고, 수업, 제품 소개처럼 메시지 전달이 중요한 상황에 유용하다. - **Figma 앱으로 발표하기** - 모바일 앱에서 슬라이드를 직접 클릭하며 발표하는 방법을 보여준다. ## 영상·모션·사용자 플로우 학습 - 프로토타입의 완성도를 높이려면 단순한 화면 연결뿐 아니라 전환 효과, 애니메이션, 스크롤 동작을 함께 설계해야 한다. - Smart Animate와 easing curve를 사용하면 화면 변화가 더 자연스럽고 제품의 실제 동작에 가까워진다. - 모션과 플로우를 활용하면 사용자가 어떤 순서로 기능을 경험하는지 명확하게 검증할 수 있다. ## 변수와 고급 프로토타이핑 - 변수 기능을 활용하면 하나의 프로토타입에서 상태, 값, 조건에 따른 다양한 동작을 관리할 수 있다. - 반복되는 상태나 화면을 개별 프레임으로 복제하는 대신 변수와 인터랙티브 컴포넌트로 구성해 유지보수성을 높일 수 있다. - 복잡한 사용자 플로우와 여러 상태를 표현할 때 변수 기반 설계가 특히 유용하다. ## 오피스 아워와 실습 자료 - Figma의 오피스 아워 콘텐츠는 프로토타이핑 기능과 실제 활용 사례를 보충 학습할 수 있는 자료로 제공된다. - 영상뿐 아니라 Figma 커뮤니티 파일을 직접 열어 결과물을 확인하고 따라 해볼 수 있다. - 학습 방식에 따라 짧은 영상, 장시간 강의, 실습 파일, 소셜 콘텐츠 중 적합한 자료를 선택할 수 있다. 처음 시작한다면 기초 프로토타입 제작과 프레임 간 내비게이션부터 익힌 뒤, Smart Animate·스크롤·인터랙티브 컴포넌트로 확장하는 순서가 좋다. 이후 접근성 테스트, 변수, 발표용 프로토타입을 적용하면 실무에서 검증과 커뮤니케이션을 동시에 강화할 수 있다.

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

Figma프로토타이핑접근성user-research+3

figma·2024년 3월 13일·4분 읽기큐레이션 요약

Figma 데이터베이스 팀이 대

Figma는 데이터베이스 규모가 2020년 이후 약 100배 성장하면서 단일 Postgres와 수직 분할만으로는 한계에 도달했다. 먼저 캐시, 읽기 복제본, 수직 파티셔닝으로 확장 여유를 확보했지만, 수 테라바이트 규모의 테이블과 급격히 증가하는 쓰기량 때문에 수평 샤딩이 필요해졌다. Figma는 새로운 데이터베이스로 전면 이전하기보다 기존 RDS Postgres 전문성과 데이터 일관성을 유지하는 점진적 수평 샤딩을 선택해 약 9개월 만에 확장 기반을 마련했다. ## 급격한 성장과 수직 파티셔닝의 한계 - Figma는 2020년 AWS의 가장 큰 물리 인스턴스에서 단일 Postgres를 운영했다. - 2022년 말에는 다음과 같은 분산 구조로 발전했다. - 캐시 - 읽기 복제본 - 약 12개의 수직 분할 데이터베이스 - “Figma 파일”, “조직”처럼 연관된 테이블 그룹을 별도 데이터베이스로 분리해 점진적으로 확장했다. - 수직 파티셔닝은 CPU 사용량을 낮추고 빠르게 확장 여유를 확보하는 데 효과적이었다. - 그러나 수직 분할의 최소 단위는 테이블 하나이므로, 하나의 테이블 자체가 지나치게 커지는 문제는 해결하지 못했다. ## 데이터베이스 병목을 정량적으로 측정 - Figma는 CPU뿐 아니라 다음 지표를 함께 모니터링했다. - 디스크 I/O - 테이블 크기 - 기록되는 행 수 - 데이터베이스별 처리 한계 - 과거 운영 데이터와 부하 테스트를 조합해 각 데이터베이스와 샤드의 “남은 확장 여유”를 예측했다. - 수 테라바이트와 수십억 개의 행을 가진 테이블에서는 Postgres의 `VACUUM` 작업이 안정성에 영향을 주기 시작했다. - `VACUUM`은 트랜잭션 ID 고갈을 방지하는 필수 백그라운드 작업이지만, 대형 테이블에서는 처리 부담이 커진다. - 쓰기량이 가장 많은 테이블은 AWS RDS가 제공하는 최대 IOPS에 곧 도달할 상황이었다. - 이 문제는 테이블을 다른 데이터베이스로 옮기는 수직 분할만으로는 해결할 수 없어 수평 샤딩이 요구됐다. ## 확장 설계의 목표 Figma는 단순히 데이터를 여러 데이터베이스에 나누는 것보다, 운영과 애플리케이션 변경 위험을 최소화하는 것을 중요하게 봤다. - **개발자 영향 최소화** - 기존의 복잡한 관계형 데이터 모델을 최대한 유지한다. - 애플리케이션 개발자가 대규모 데이터 접근 코드를 전면 수정하지 않도록 한다. - **투명한 확장** - 최초에 샤딩 호환성을 확보한 뒤에는, 향후 샤드를 추가할 때 애플리케이션 변경을 최소화한다. - **대규모 백필 회피** - 수개월이 걸릴 수 있는 전체 테이블 백필이나 전체 데이터 마이그레이션을 피한다. - **점진적 적용** - 빠르게 증가하는 테이블부터 단계적으로 적용한다. - 각 단계에서 위험을 검증해 대규모 장애 가능성을 낮춘다. - **롤백 가능성 확보** - 물리적 샤딩 이후에도 문제가 생기면 이전 상태로 되돌릴 수 있어야 한다. - **강한 일관성 유지** - 다운타임과 일관성 위험을 유발할 수 있는 이중 쓰기 방식을 피한다. - 거의 무중단에 가까운 확장을 목표로 한다. - **기존 역량 활용** - 이미 축적한 RDS Postgres 운영 경험과 도구를 활용해 새로운 저장소의 불확실성을 줄인다. ## 대체 데이터베이스 검토 - Figma는 수평 확장을 지원하는 여러 기술을 검토했다. - CockroachDB - TiDB - Spanner - Vitess - 그러나 새 데이터베이스로 전환하려면 기존 Postgres와 새 저장소 사이의 복잡한 데이터 마이그레이션이 필요했다. - 데이터 일관성과 안정성을 확보하면서 핵심 기능을 모두 이전하려면 상당한 시간이 필요했다. - Figma는 이미 RDS Postgres를 안정적이고 성능 좋게 운영하는 전문성을 갖고 있었으므로, 새로운 데이터베이스로 바꾸면 이 역량을 다시 구축해야 했다. - 성장 속도가 매우 빨라 남은 확장 여유가 수개월뿐이었기 때문에, 새로운 저장소를 도입하는 것은 기술적으로 가능하더라도 일정과 위험 측면에서 적합하지 않았다. ## NoSQL을 선택하지 않은 이유 - NoSQL은 기본적으로 수평 확장을 제공하지만, Figma의 데이터 모델과는 잘 맞지 않았다. - Figma는 복잡한 관계형 데이터와 여러 테이블 간 관계를 Postgres 위에서 활용하고 있었다. - NoSQL API만으로는 이러한 관계형 질의와 데이터 모델의 유연성을 동일하게 제공하기 어려웠다. - 따라서 애플리케이션 구조를 대규모로 재설계하는 대신, 기존 관계형 모델을 유지하면서 Postgres를 수평 확장하는 방향을 택했다. ## 실용적인 결론 데이터베이스 확장은 처음부터 수평 샤딩으로 시작하기보다, 캐시·읽기 복제본·수직 파티셔닝으로 단기 여유를 확보한 뒤 실제 병목을 측정하며 단계적으로 진행하는 것이 현실적이다. 특히 기존 데이터베이스에 대한 운영 역량과 강한 일관성이 중요하다면, 새로운 저장소로 전면 이전하기보다 현재 시스템을 유지한 채 점진적으로 샤딩하는 전략이 위험과 개발 비용을 줄일 수 있다.

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

PostgreSQL분산 시스템database-shardingdatabase-replication+2

figma·2024년 3월 12일·3분 읽기큐레이션 요약

Figma에서 커스텀 권한

Figma는 기존 Ruby 모놀리스의 `has_access?` 메서드에 모든 권한 로직을 집중시킨 결과, 복잡성·디버깅 난이도·계층형 권한의 한계·데이터베이스 부하 문제에 직면했다. 이를 해결하기 위해 자체 권한 도메인 특화 언어(DSL), 크로스플랫폼 권한 로직 엔진을 구축하고 핵심 권한 규칙을 새 시스템으로 이전했다. 목표는 권한 정확성과 성능을 높이는 동시에 개발자가 안전하게 권한 규칙을 변경할 수 있도록 만드는 것이었다. ## Figma의 권한 모델 - Figma의 협업 기능은 파일과 폴더, 팀, 조직 단위의 복잡한 권한 구조를 필요로 한다. - 파일 접근 방식은 크게 두 가지다. - **역할 기반 접근**: 상위 폴더·팀·조직에서 상속된 역할에 따라 접근한다. - **링크 기반 접근**: 링크를 가진 사용자의 접근 수준, 만료 기간, 비밀번호, 조직 정책 등을 조합해 결정한다. - 파일 삭제 여부, 계층 구조, 조직 제한, 결제 상태 등도 접근 가능 여부에 영향을 준다. - 기존에는 각 ActiveRecord 모델의 `has_access?` 메서드가 사용자와 리소스를 받아 접근 가능 여부를 boolean으로 반환했다. ## 기존 `has_access?` 방식의 한계 - 권한 판단에 필요한 모든 비즈니스 로직이 하나의 긴 메서드에 들어갔다. - 제품 엔지니어가 컨트롤러에서 이 메서드를 적절한 시점에 직접 호출해야 했다. - 작은 변경도 전체 권한 체계에 영향을 줄 수 있어 개발자들이 메서드 수정 자체를 꺼리게 됐다. - 권한 버그는 Figma의 모든 파일에 대한 접근 허용으로 이어질 수 있어 위험성이 컸다. - 디버깅 시 특정 규칙만 분리해 확인하기 어려웠고, 수십 개의 로그를 코드 곳곳에 추가해야 했다. ## 계층형 권한과 boolean 플래그의 문제 - 권한 수준을 정수로 표현했지만, 실제 동작은 여러 boolean 플래그에 의해 달라졌다. - 예시 메서드는 다음과 같은 선택적 인자를 포함했다. - `ignore_link_access` - `org_candidate` - `ignore_archived_branch` - 같은 권한 수준이라도 플래그 조합에 따라 결과가 달라져 개발자가 이해해야 할 경우의 수가 많았다. - 리소스마다 플래그의 의미와 동작이 달라 일관된 권한 모델을 만들기 어려웠다. - 예를 들어 `300` 수준의 편집 권한은 있어도, 특정 조건을 무시한 `100` 수준의 보기 권한 검사는 통과하지 못할 수 있었다. - 따라서 기존 계층 구조만으로는 표현하기 어려운, 서로 독립적인 세밀한 권한이 필요했다. - 새로운 시스템은 기존 계층형 권한을 지원하면서도 비계층적이고 독립적인 권한 체계를 추가할 수 있어야 했다. ## 권한 검사로 인한 데이터베이스 부하 - Figma의 사용자와 리소스 규모가 빠르게 증가하면서 권한 검사가 데이터베이스에 큰 부담을 줬다. - 전체 데이터베이스 부하 중 약 **20%**가 권한 검사에서 발생했다. - 데이터베이스를 수직·수평 확장하는 것만으로는 물리적 한계가 있었기 때문에, 권한 로직 자체가 데이터 계층에 가하는 부하를 줄여야 했다. - 새로운 권한 시스템에는 권한 데이터를 어떻게 조회하고 처리할지에 대한 더 세밀한 제어가 필요했다. ## 자체 권한 DSL과 로직 엔진 - Figma는 외부 솔루션을 우선 검토하는 일반적인 방침과 달리, 권한 문제에는 자체 시스템을 선택했다. - 구축한 구성 요소는 다음과 같다. - 권한 규칙을 명확하게 표현하는 **도메인 특화 언어(DSL)** - 여러 환경에서 동작하는 **크로스플랫폼 권한 로직 엔진** - 기존의 핵심 권한 규칙을 새 시스템으로 이전하는 마이그레이션 체계 - 이를 통해 권한 규칙을 하나의 거대한 조건문으로 관리하지 않고, 독립적이고 조합 가능한 규칙으로 다룰 수 있게 하는 것이 목표였다. - 결과적으로 권한 로직을 제품 기능과 분리하고, 규칙 추가·수정·삭제 시 기존 권한 체계를 모두 다시 이해해야 하는 부담을 줄이려 했다. ## 실용적인 결론 복잡한 권한 시스템에서는 단순한 `if/else` 함수와 호출 규약만으로 규모 확장을 감당하기 어렵다. 권한을 독립적인 규칙으로 모델링하고, 선언적인 DSL과 공통 실행 엔진을 사용하면 정확성·성능·개발자 경험을 함께 개선할 수 있다.

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

access-controlrubydatabase-shardingauthorization+3

figma·2024년 3월 5일·3분 읽기큐레이션 요약

기능 비하인드: 멀

Figma의 **멀티 편집(multi-edit)**은 여러 프레임이나 컴포넌트 세트에 속한 객체를 한 번에 선택하고 수정할 수 있게 해 반복 작업을 줄이는 기능이다. 이 아이디어는 2019년 variants 기능을 설계하던 중 시작됐지만, 선택 방식과 편집 동작을 새롭게 정의해야 해 오랜 기간 다듬어졌다. Figma는 멀티 편집처럼 사용자가 별도 학습 없이 자연스럽게 쓰는 기능을 만드는 일을 제품 개발의 중요한 목표로 본다. ## 멀티 편집의 출발점: variants의 반복 작업 - 2019년 variants 기능을 설계하던 중, 여러 변형에 같은 수정 작업을 반복해야 하는 문제가 드러났다. - Figma 팀은 이 문제를 해결하기 위해 이틀간 디자인 서밋을 열고 다양한 접근법을 논의했다. - 핵심 아이디어는 특정 모드에 들어가면 한 객체에 한 수정이 모든 variants에 동시에 적용되도록 하는 것이었다. - 이후 이 방식은 variants뿐 아니라 여러 디자인 객체를 한꺼번에 편집해야 하는 다양한 상황에도 유용하다고 판단됐다. - 팀은 화이트보드에 아이디어를 그린 뒤 이를 “multi-edit”라고 이름 붙였다. ## 기존 다중 선택 방식의 한계 - Figma는 이미 여러 객체를 선택해 일부 속성을 동시에 수정할 수 있었지만, 실용성에는 한계가 있었다. - 사용자가 실제로 수정하려는 객체만 정확히 선택하기 어려웠다. - 여러 객체를 선택한 뒤에도 편집 종류에 따라 결과가 제대로 작동하지 않았다. - 여러 객체의 색상 변경은 비교적 쉬웠지만, 크기 조정은 어려웠다. - 여러 텍스트 노드의 글꼴이나 글자 크기는 바꿀 수 있지만, 텍스트 내용 자체를 동시에 수정하기는 어려웠다. - 따라서 단순히 “여러 개를 선택하는 기능”이 아니라, 선택과 편집 동작 전체를 재설계해야 했다. ## 아이디어의 긴 숙성 기간 - 초기에는 멀티 편집을 고급 텍스트 편집기의 다중 커서처럼 강력한 별도 편집 모드로 구상했다. - 그러나 실제 구현을 검토하면서 Figma의 기존 선택 모델과 어떻게 결합할지 해결해야 했다. - 어떤 객체를 같은 대상으로 간주할지, 선택된 객체에 어떤 편집을 허용할지 등 핵심 원칙이 명확하지 않았다. - 이러한 문제를 정리하는 데 시간이 필요해 아이디어는 곧바로 개발되지 못하고 오랫동안 “동면” 상태에 머물렀다. - 글은 멀티 편집이 처음부터 완성된 기능이 아니라, 반복적인 시행착오와 세부 조정을 거쳐 출시됐음을 강조한다. ## 현재 제공되는 멀티 편집 사용법 - `⌘ Command + ⌥ Option + A`: 조건에 맞는 동일한 객체를 모두 선택한다. - `Shift`를 누른 채 드래그: 원하는 동일 객체만 직접 선택한다. - 여러 텍스트 객체를 선택한 뒤 `Enter`: 텍스트 멀티 편집 모드로 들어간다. - 컴포넌트 세트를 선택한 뒤 `Q`: variants 멀티 편집 모드로 전환한다. - 멀티 편집을 사용하면 여러 프레임과 컴포넌트 세트에 걸친 객체를 몇 번의 동작만으로 동시에 수정할 수 있다. ## 실용적인 결론 반복적으로 여러 화면이나 variants를 수정해야 한다면 멀티 편집을 우선 활용하는 것이 좋다. 특히 동일한 텍스트를 수정하거나 여러 컴포넌트의 공통 속성을 변경할 때 기존 객체를 하나씩 편집하는 것보다 훨씬 효율적이다.

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

Figmadesign-toolsuser-interface-designcomponent-variants+1

figma·2024년 2월 28일·3분 읽기큐레이션 요약

Figma에서 Eng Crits

Figma의 엔지니어링 크리트(eng crit)는 완성된 설계를 승인하는 절차가 아니라, 기술적 아이디어를 초기에 공유하고 다양한 관점의 피드백을 받아 팀의 진행을 돕는 협업 방식이다. 늦은 기술 리뷰에서 발생하는 방향 전환이나 출시 차단 문제를 줄이기 위해, 디자인 크리의 개방성과 브레인스토밍 방식을 엔지니어링에 적용했다. Figma는 이를 FigJam의 열린 캔버스에서 운영하며, 참여자가 많아도 누구나 의견을 보태는 구조를 만들었다. ## 늦은 기술 리뷰의 한계 - 일반적인 기술 리뷰는 프로젝트 후반부에 상세한 엔지니어링 스펙을 검토하고 승인받는 절차로 진행된다. - 리뷰 시점이 너무 늦으면 주요 방향이나 설계가 이미 구현된 뒤라서, 피드백이 출시를 막는 문제로 이어질 수 있다. - 승인 여부가 “찬성/반대”로 나뉘는 이진적 구조에서는 새로운 아이디어를 탐색하거나 함께 개선하기 어렵다. - 초기 단계의 미완성 아이디어를 공유하려면 실수를 비난하지 않고 열린 대화를 장려하는 문화가 필요하다. ## 엔지니어링 크리의 목적 - 기술적 문제에 대한 새로운 접근법을 함께 브레인스토밍한다. - 진행 중인 작업과 기술 설계를 일찍, 자주 공유한다. - 전문성을 가진 동료에게 조언을 구하고 팀의 작업을 막고 있는 문제를 해결한다. - 승인이나 통과 여부를 결정하는 공식 게이트가 아니라, 프로젝트를 앞으로 나아가게 하는 지원 포럼으로 운영한다. - Figma CTO Kris Rasmussen은 이를 “아이디어를 함께 키우는 장소”로 설명하며, 정원에 비유해 다른 사람이 아이디어를 발전시키는 과정에 참여해야 한다고 강조한다. ## 디자인 크리에서 얻은 영감 - Figma의 디자인 크리는 결과물을 승인하는 자리가 아니라, 탐색과 피드백을 위한 안전한 공간으로 운영된다. - 엔지니어링 크리는 디자인 크리와 기술 리뷰의 중간 형태로 설계됐다. - 디자인 크리처럼 초기 작업을 공유하되, 기술 리뷰처럼 기술적 설계에 대한 전문적인 피드백을 받을 수 있도록 했다. - 핵심은 완성된 결과를 평가하는 것이 아니라, 작업자가 다음 단계로 나아가는 데 필요한 도움을 제공하는 것이다. ## 기존 리뷰 방식의 문제점과 협업형 포맷 - 동기식 기술 리뷰에서는 소수의 팀 리드가 대화를 주도하고, 다른 참가자는 충분히 의견을 내기 어려웠다. - 비동기식 리뷰에서는 각자가 댓글을 남기는 데 그쳐, 서로 연결되지 않은 피드백이 긴 댓글 스레드로 쌓였다. - Figma는 FigJam을 사용해 이 문제를 해결했다. - 여러 사람이 짧은 시간에 동시에 의견을 남길 수 있다. - 한 사람이 발표하고 나머지가 순서대로 응답하는 방식이 아니다. - 초기 아이디어, 참고 자료, 진행 중인 화면, 스크린샷, 질문과 맥락을 한 캔버스에 함께 배치할 수 있다. - 단순한 피드백 목록이 아니라 공동 브레인스토밍과 대화가 가능하다. ## 참여 규모를 확장한 과정 - 처음에는 8~10명 규모의 가까운 팀에서 파일럿을 진행했다. - 반복 가능한 진행 형식을 정립한 뒤 캘린더 초대를 개방했다. - 참여자는 점차 늘어 200명 이상이 참석하는 조직 단위 프로세스로 발전했다. - 현재는 Figma 에디터를 개발하는 모든 엔지니어에게 초대장을 보내며, 참석자는 “선택 사항”으로 표시한다. - 다른 조직이나 직군도 자유롭게 참여할 수 있고, 자신의 전문성과 관련된 주제일 때 주로 참석한다. ## 실용적인 적용 방법 - 리뷰를 승인 절차로 정의하지 말고, 초기 피드백과 문제 해결을 위한 자리로 명확히 규정한다. - 완성된 문서만 요구하지 말고, 미완성 설계·스크린샷·참고 자료도 공유하도록 허용한다. - 특정 리더 몇 명에게 발언이 집중되지 않도록 여러 사람이 동시에 참여할 수 있는 도구와 형식을 사용한다. - 참석을 의무화하기보다 선택적으로 운영해 관심과 전문성에 기반한 참여를 유도한다. - 중요한 것은 회의 자체보다, 아이디어를 일찍 공개하고 함께 발전시킬 수 있는 심리적 안전감과 협업 문화를 만드는 것이다.

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

Figmafigjamengineering-critiquestechnical-design+1

figma·2024년 2월 26일·3분 읽기큐레이션 요약

니콜 뵈쳐의 피그

니콜 부에처는 전직 UX·제품 디자이너로서 Figma를 활용해 퀼트를 설계하고, 디지털 디자인의 반복·측정·최적화 방식을 수공예에 적용한다. 그녀는 천을 자르기 전에 퀼트의 약 80%를 Figma에서 완성하며, 색상 조합과 패턴을 빠르게 실험하고 필요한 원단 수량과 재단 순서까지 계획한다. Figma는 창의적인 퀼트 작업을 체계화하면서도, 재료와 시간을 절약하게 해주는 설계 도구가 된다. ## 손으로 만드는 취미와 디지털 설계의 결합 - 니콜은 2021년 팬데믹으로 업무 방식이 바뀌면서 손을 사용하는 새로운 공예를 찾기 시작했다. - Artsy에서 2년 반 동안 제품 디자이너로 일한 경험이 있으며, 이전에도 간단한 봉제 작업은 했지만 퀼트 제작은 미뤄두고 있었다. - 온라인 튜토리얼과 초보자용 패턴을 따라 하며 독학했고, 실력이 늘면서 더 큰 퀼트를 만들게 됐다. - 직접 패턴을 설계할 단계가 되자 익숙한 도구인 Figma를 사용하기 시작했다. ## UX 경험을 바탕으로 한 계획적 제작 - 니콜은 천을 자르기 전에 퀼트 디자인의 약 80%를 Figma에서 완성한다. - UX 디자인과 엔지니어링용 에셋 준비 경험 때문에 즉흥적으로 만들기보다 먼저 구조와 치수를 계획하는 편이다. - 퀼트 제작은 각 조각을 1/4인치 단위로 측정해야 하므로, 정확한 크기 조정이 가능한 Figma가 적합하다. - 스케치나 종이 조각을 직접 옮기는 방식보다 도형의 비율과 배치를 빠르게 수정할 수 있다. ## 색상 라이브러리와 패턴 실험 - 영감은 퀼트 관련 서적과 Instagram에서 얻으며, 전통적인 퀼트 블록을 새로운 패턴으로 변형하는 방식으로 작업을 시작한다. - 이미 가지고 있는 원단을 우선 활용하기 위해 원단 제조사의 색상 견본을 Figma에 모아 색상 라이브러리를 구축했다. - 디자인 파일에서 특정 영역을 선택해 색상이나 패턴을 한꺼번에 바꿀 수 있다. - `Random Colors Fill` 같은 Figma 플러그인을 활용하면 다양한 색상 조합을 빠르게 시험할 수 있다. - 제품 디자인처럼 하나의 퀼트에 대해 수십 가지 버전을 만든 뒤 최종안을 선택한다. ## Figma에서 퀼트 구조 설계하기 - Grid Quilt처럼 격자 구조의 디자인을 Figma에서 먼저 구성한다. - 각 행을 개별적으로 수정하는 대신 Auto Layout을 사용해 여러 행의 배치를 동시에 조정할 수 있다. - 완성된 전체 디자인을 재단과 봉제에 필요한 작은 단위 조각으로 분해한다. - 조각을 어떤 순서로 연결할지까지 시각적으로 확인해 제작 과정을 단순화한다. ## 치수 계산과 원단 낭비 줄이기 - 최종 디자인을 복제한 뒤 사각형과 직사각형 등 원자 단위의 조각으로 나눈다. - `Count Things` 플러그인으로 필요한 조각의 개수를 계산한다. - 예: 청록색 직사각형 189개, 황갈색 정사각형 378개 등 - Figma의 픽셀 크기를 실제 인치 단위와 대응시켜 재단에 필요한 치수를 산출한다. - 봉제선 여유분을 고려해 각 조각의 양쪽에 1/4인치를 추가한다. - 필요한 원단의 총 길이를 계산하고, 조각을 최대한 효율적으로 배치해 불필요한 자투리 원단을 줄인다. - 어떤 조각을 먼저 봉제할지 다시 조정해 전체 작업 단계를 최소화한다. ## 디지털 도구가 공예에 주는 의미 - Figma는 단순한 화면 디자인 도구가 아니라 실제 재료를 다루는 제작 과정의 계획 도구로 활용된다. - 반복적인 시안 제작, 정확한 치수 계산, 색상 관리, 재단 최적화를 하나의 파일 안에서 처리할 수 있다. - 디지털 설계의 효율성이 수작업의 섬세함을 대체하는 것이 아니라, 수작업에 더 많은 시간과 집중력을 투입하도록 돕는다. - 니콜의 사례는 특정 산업을 위해 만들어진 도구도 사용자의 창의적인 방식에 따라 전혀 다른 제작 분야로 확장될 수 있음을 보여준다. 실용적으로는 퀼트처럼 규격과 반복이 중요한 작업을 시작할 때 Figma에서 색상 견본, 실제 치수, 조각 수량, 조립 순서를 먼저 관리하면 시행착오와 재료 낭비를 크게 줄일 수 있다.

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

Figma사용자 경험프로덕트 디자인auto-layout+2

figma·2024년 2월 26일·3분 읽기큐레이션 요약

기능 비하인드:

Figma는 프로토타입을 실제 기기에서 사용하는 경험에 가깝게 만들기 위해 모바일·태블릿·워치용 **인라인 디바이스 프레임**을 에디터 안에 도입했다. 사용자는 프레젠테이션 화면으로 이동하지 않고도 디자인 옆에서 기기 프레임을 배치·이동·크기 조절하며 프로토타입을 확인할 수 있다. 이 기능은 다양한 기기 형태를 반영하면서도 자연스러운 상호작용과 협업 중심의 디자인 프로세스를 유지하는 것을 목표로 개발됐다. ## 프로토타이핑을 현실에 가깝게 만드는 이유 - 실제 기기를 손에 들고 화면과 플로우를 확인하면 제품이 실제로 어떻게 작동하는지 더 잘 이해할 수 있다. - 프로토타입은 개발 전에 사용성 문제, 설계의 빈틈, 개선 기회를 발견하게 해준다. - Figma는 2023년 Config에서 실시간으로 프로토타입을 확인하는 **인라인 프리뷰**를 선보였고, 이후 기기 프레임까지 에디터 내부로 확장했다. - 프레젠테이션 뷰로 이동하지 않아도 디자인 작업과 실제 기기 맥락 확인을 동시에 할 수 있게 된 것이 핵심이다. ## 협업을 기반으로 한 기능 설계 - Figma는 기존 프레젠테이션 뷰에서 제공하던 다양한 기기 프리셋이 인기가 높다는 점에 주목했다. - 이를 에디터 안으로 가져와 디자인 옆에서 휴대폰, 태블릿, 워치 프레임을 사용할 수 있도록 했다. - 제품 디자이너, 엔지니어, 제품 관리자, 마케팅 담당자와 사용자 커뮤니티의 의견을 함께 반영했다. - 개발 과정에서 세운 핵심 원칙은 다음과 같다. - 디자인 작업 흐름에 자연스럽게 통합할 것 - 다양한 실제 기기를 현실적으로 표현할 것 - 기기의 상호작용 영역을 직관적으로 설계할 것 - 목표는 단순한 정적 이미지가 아니라, 사용자가 잡고 이동하고 크기를 조절할 수 있는 반응형 기기를 에디터 안에 구현하는 것이었다. ## 다양한 기기 형태의 표현 - 인라인 프리뷰 공간의 제약 때문에 초기 대상은 개인용 컴퓨터보다 상대적으로 작은 모바일, 태블릿, 워치로 한정했다. - 기기마다 화면 비율과 외형이 다르므로 하나의 고정된 프레임으로는 다양한 사용 환경을 표현하기 어렵다. - 스마트폰의 카메라와 센서를 수용하기 위해 화면 일부가 파인 **노치(notch)** 같은 요소도 고려해야 했다. - 화면뿐 아니라 기기 외곽, 모서리, 센서 영역 등 실제 사용 경험을 구성하는 시각적 요소를 함께 재현해야 했다. ## 자연스러운 크기 조절과 상호작용 - 인라인 디바이스 프레임은 디자인 요소처럼 에디터 안에서 이동하고 크기를 조절할 수 있어야 했다. - 특히 워치처럼 외형이 작고 복잡한 기기는 어느 영역을 드래그하거나 조작할 수 있게 할지 결정하기 어려웠다. - 프레임의 상호작용 가능한 영역, 즉 **히트 타깃**을 명확하고 직관적으로 설계하는 것이 중요한 과제였다. - 기기마다 형태가 다르더라도 사용자가 별도의 학습 없이 동일한 방식으로 조작할 수 있도록 상호작용 규칙을 정리해야 했다. ## 프로토타이핑 기능 전반의 개선 - 인라인 디바이스 프레임과 함께 여러 프로토타이핑 개선 사항도 제공됐다. - 연결선을 복사·붙여넣기해 인터랙션을 빠르게 복제할 수 있다. - 플로우를 빠르게 삭제하는 기능이 추가됐다. - 로컬 변수가 포함된 요소를 새 파일로 쉽게 가져올 수 있는 고급 기능도 제공됐다. - 주요 사용 사례에서 로딩 스피너가 나타나는 시간이 22% 줄어 성능도 개선됐다. 실무에서는 모바일·태블릿·워치 화면을 설계할 때 인라인 디바이스 프레임을 활용해 디자인과 실제 사용 맥락을 동시에 검토하는 것이 유용하다. 특히 기기별 화면 비율, 노치, 워치의 작은 터치 영역처럼 실제 환경에서 발생하는 문제를 개발 전에 확인하는 데 적합하다.

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

Figma프로토타이핑반응형 디자인user-interface-design+2

figma·2024년 2월 25일·3분 읽기큐레이션 요약

AI가 어떻게 디자인과 개발을 통합

AI는 디자인과 개발을 পৃথ개의 영역으로 두기보다 하나의 긴밀한 창작·제작 과정으로 통합할 가능성이 크다. David Hoang은 AI가 정해진 화면을 설계하는 방식을 넘어, 사용자와 맥락에 따라 변화하는 동적·멀티모달 인터페이스를 만들 것이라고 전망한다. Replit은 범용 인공지능(AGI)보다 개발자의 자율성과 생산성을 높이는 ‘인공 개발자 지능(ADI)’에 집중하며, 아이디어를 코드로 구현하고 실제 출시까지 이어지도록 돕는 것을 목표로 한다. ## AI가 바꾸는 인터페이스와 디자인 - 모바일 혁명 당시 기존 전문가들이 새로운 환경에서 다시 초보자가 되었듯, AI도 디자인과 상호작용의 기준을 재설정하고 있다. - 디자이너가 사용자가 보게 될 모든 인터페이스를 미리 고정하는 방식에서 벗어나, 상황에 따라 형태와 표현이 바뀌는 **동적 인터페이스**로 이동한다. - AI, 멀티모달 기술, 다양한 폼팩터, 공간 컴퓨팅(예: Apple Vision Pro)은 서로 독립적인 흐름이 아니라 하나로 수렴하는 변화로 설명된다. - 디자이너는 화면의 모든 요소를 직접 통제하기보다, 시스템이 변화할 수 있는 여지를 설계해야 한다. ## 디자인과 개발의 통합 - AI는 엔지니어에게는 설계와 코드 작성을, 디자이너에게는 기술 구현과 프로토타이핑을 보조할 수 있다. - 그 결과 디자인과 엔지니어링은 점점 더 긴밀하게 결합된 하나의 분야가 될 가능성이 있다. - AI 도구는 특정 직군을 대체하기보다 각자가 자신의 전문성을 확장하고 다른 영역의 작업까지 수행하도록 돕는 **증강 기술**로 제시된다. - 협업과 AI는 Replit이 개발자 생산성을 바라보는 핵심 축이다. ## Replit의 ‘인공 개발자 지능(ADI)’ - Replit은 인간 수준의 범용 지능인 AGI보다, 소프트웨어 개발에 특화된 **Artificial Developer Intelligence(ADI)** 구축에 초점을 맞춘다. - ADI의 목표는 사용자의 자율성을 높이고 더 적은 장벽으로 소프트웨어를 만들 수 있도록 지원하는 것이다. - 장기적으로는 복잡한 소프트웨어 아키텍처를 생성하고, Replit에 배포된 고급 개발 도구를 조율하는 에이전트가 등장할 수 있다. - 단순한 코드 생성뿐 아니라 팀의 작업 방식과 협업 맥락을 이해하는 조직 지능으로 확장될 수 있다. ## ‘코드 학습’에서 ‘제품 출시’까지 - ADI는 코드 자동완성, 코드 생성, 개발 과정 안내 등 다양한 형태로 활용될 수 있다. - Replit은 사용자가 코딩을 배우는 데서 멈추지 않고, 실제 제품을 만들고 출시하며 사업으로 발전시키는 과정을 가속하는 것을 지향한다. - Hoang은 Replit을 사용자가 필요로 하는 ‘기술 공동창업자’처럼 바라본다. - AI를 활용하면 비기술 직군의 기획자도 프롬프트와 제품 이해를 바탕으로, 기존 엔지니어 팀에 못지않은 수준의 결과물을 만들 수 있다. - 따라서 앞으로는 코딩 능력뿐 아니라 문제를 정의하고 AI에 정확한 지시를 내리는 능력도 중요한 역량이 된다. AI 시대의 창작 도구는 완성된 화면이나 코드 조각을 제공하는 수준을 넘어, 사용자의 의도와 팀의 맥락을 이해하고 실행 가능한 결과물까지 함께 만들어야 한다. 디자이너와 개발자는 모든 것을 직접 통제하려 하기보다 AI와 협업하는 방식, 명확한 문제 정의, 효과적인 프롬프트 작성 능력을 함께 발전시키는 것이 바람직하다.

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

AI프롬프트 엔지니어링code-generationmobile-apps+4

datadog·2024년 2월 14일원문

Vale을 사용하여 문서 편집 프로세스를 개선 (새 탭에서 열림)

데이터독(Datadog)은 대규모 오픈 소스 기여자와 수많은 제품군을 보유한 환경에서 문서의 일관성과 품질을 유지하기 위해 'Vale'이라는 오픈 소스 산문 린터(Linter)를 도입했습니다. 이를 통해 수동 편집에 드는 리소스를 대폭 줄이고, 스타일 가이드를 코드로 관리함으로써 문서 검토 과정을 자동화하는 성과를 거두었습니다. 결과적으로 작성자가 코드를 제출하기 전 단계에서부터 스스로 문서를 수정할 수 있는 '시프트 레프트(Shift-left)' 문화를 정착시켜 전체적인 문서화 효율을 높였습니다. ### 대규모 문서 기여 관리의 한계 * 데이터독 문서팀은 약 14명의 작가가 1,400명 이상의 기여자(내부 개발자 및 외부 기여자)가 생성하는 문서를 관리하며, 작가 1인당 개발자 비율은 200대 1에 달합니다. * 2023년 한 해에만 35개 이상의 제품과 수백 개의 API, 통합 서비스에 대해 20,000개 이상의 풀 리퀘스트(PR)를 처리했습니다. * 당번 작가는 하루 평균 40개 이상의 PR을 검토해야 하므로, 수동으로 모든 문법, 어조, 스타일 가이드를 확인하는 것은 물리적으로 불가능한 상황이었습니다. ### Vale를 활용한 문서 스타일 린팅 자동화 * 오픈 소스 CLI 도구인 Vale를 작성 환경과 CI(지속적 통합) 워크플로우에 통합했습니다. * GitHub Actions를 통해 PR이 생성될 때마다 Vale이 HTML 및 마크다운 파일을 스캔하여 스타일 규칙 위반 사항을 자동으로 댓글로 남깁니다. * 너무 긴 문장, 불필요한 수식어 사용, 오래된 타자기 습관(이중 공백 등)을 자동으로 감지하여 작가가 검토하기 전에 기여자가 스스로 수정할 수 있게 합니다. ### 스타일 가이드의 코드화 (Codifying Style Guide) * 과거에는 컨플루언스(Confluence)나 위키 등에 흩어져 있던 편집 가이드라인을 `datadog-vale`이라는 오픈 소스 프로젝트를 통해 코드 형태로 변환했습니다. * YAML 형식을 사용하여 검증하고자 하는 스타일 규칙을 정의하며, 정규 표현식(RegEx)을 통해 특정 패턴(예: 옥스퍼드 콤마 누락)을 감지합니다. * 특정 단어(simply, easily 등)를 지양하게 하는 `words.yml`, 라틴어 약어 대신 쉬운 영어를 쓰게 하는 `abbreviations.yml` 등의 규칙을 통해 일관된 어조를 유지합니다. * 휴고(Hugo) 숏코드와 같이 스타일 검사에서 제외해야 할 영역은 정규 표현식으로 필터링하여 오탐지를 방지합니다. ### 실용적인 제언 대규모 팀이나 프로젝트를 운영하고 있다면 스타일 가이드를 단순히 문서로만 남기지 말고, Vale와 같은 도구를 사용해 자동화된 규칙으로 변환하는 것이 좋습니다. 데이터독이 공개한 `datadog-vale` 규칙을 참고하면 옥스퍼드 콤마 사용이나 전문 용어 관리 등을 손쉽게 자신의 프로젝트에 적용해 볼 수 있습니다.

datadogCI/CDGitHub Actionsmarkdown+4

datadog·2024년 2월 14일원문

Vale를 사용하여 문서 편집 프로세스를 개선하는 방법 (새 탭에서 열림)

데이터독(Datadog) 문서화 팀은 수많은 기여자 사이에서 일관된 문서 품질을 유지하기 위해 오픈 소스 산문 린터(Prose Linter)인 'Vale'을 도입하여 스타일 가이드 적용을 자동화했습니다. 개발자들이 코드 린터를 사용하듯 문서에도 자동화된 검사 도구를 통합함으로써, 1,400명이 넘는 기여자가 생성하는 방대한 양의 문서를 효율적으로 관리하고 기술 작가의 리뷰 부담을 획기적으로 줄였습니다. 결과적으로 이 시스템은 고품질의 문서를 더 빠르게 배포할 수 있는 '시프트 레프트(Shift-left)' 전략을 실현했습니다. **대규모 문서 관리의 한계와 자동화의 필요성** * 데이터독은 약 1,400명의 내부 및 외부 기여자가 생성하는 35개 이상의 제품 문서를 관리하며, 연간 20,000개 이상의 풀 리퀘스트(PR)를 처리합니다. * 기술 작가 한 명당 개발자 비율이 1:200에 달하는 상황에서, 모든 문서의 문법, 전문 용어, 시제, 성별 중립적 언어 등을 수동으로 검토하는 것은 불가능에 가깝습니다. * LLM(대형 언어 모델)을 사용하더라도 데이터독 특유의 스타일 가이드(예: 옥스퍼드 콤마 사용, 'currently' 같은 시간 표현 지양 등)를 완벽히 준수하기 어렵기 때문에 자동화된 검증 도구가 필수적입니다. **Vale를 활용한 문서 스타일 린팅** * 오픈 소스 도구인 Vale를 GitHub Actions와 통합하여 CI(지속적 통합) 워크플로우 내에서 문서 스타일을 자동으로 검사합니다. * 기여자가 PR을 생성하면 Vale가 `vale.ini` 설정 파일을 바탕으로 HTML 및 마크다운 파일을 스캔하고, 수정이 필요한 부분에 직접 자동 댓글을 남깁니다. * 이를 통해 기여자는 기술 작가가 리뷰를 시작하기 전에 스스로 문장을 수정할 수 있으며, 작가들은 반복적인 스타일 수정 작업에서 벗어나 콘텐츠의 기술적 정확성에 더 집중할 수 있습니다. **스타일 가이드의 코드화와 규칙 적용** * 기존에 Confluence나 위키에 흩어져 있던 복잡한 편집 지침을 YAML 형식의 린트 규칙으로 변환하여 관리합니다. * **불필요한 단어 제거**: `words.yml` 규칙을 통해 'easily', 'simply'와 같이 객관성이 떨어지는 수식어나 불필요한 전문 용어를 감지하여 경고를 보냅니다. * **구두점 및 문법 강제**: `oxfordcomma.yml`과 같은 규칙에 정규 표현식(Regex)을 사용하여 나열된 항목들 사이에 옥스퍼드 콤마가 누락된 경우를 찾아냅니다. * **약어 대체**: 라틴어 약어(e.g., i.e. 등)를 쉬운 영어 표현(for example, that is 등)으로 대체하도록 유도하는 `abbreviations.yml` 규칙을 적용하여 가독성을 높입니다. **실용적인 제언** 규모가 커지는 조직에서 문서의 일관성을 유지하고 싶다면, 스타일 가이드를 단순한 문서로 남겨두지 말고 Vale와 같은 도구를 통해 '코드로서의 문서(Docs-as-code)' 환경에 통합하는 것이 좋습니다. 처음에는 옥스퍼드 콤마나 금지어 목록 같은 간단한 규칙부터 시작하여 점진적으로 자동화 범위를 넓히면 리뷰 효율을 극대화할 수 있습니다.

datadogCI/CDGitHub Actionsmarkdown+4

figma·2024년 2월 13일·3분 읽기큐레이션 요약

원활한 핸드오프를

핸드오프는 디자인이 끝나는 한순간의 전달이 아니라, 작업 중인 디자인과 맥락·커뮤니케이션이 지속적으로 오가는 과정이다. 원활한 협업을 위해서는 개발자가 필요한 정보를 명확히 확인할 수 있도록 주석을 정리하고, 디자인·개발 간 공통 언어를 만들며, 파일 구조를 체계적으로 정리해야 한다. 특히 “Ready for dev”가 실제 구현 가능한 상태를 의미하도록 팀의 기준과 작업 방식을 맞추는 것이 중요하다. ## 주석과 콜아웃을 간결하고 명확하게 정리하기 - 주석은 디자인 결정의 의도와 개발자가 놓치기 쉬운 세부 사항을 전달하는 수단이다. - 모든 간격이나 색상을 반복해서 설명하기보다, 이미 변수나 스타일로 정의된 정보는 생략하고 다음과 같은 내용을 우선적으로 표시한다. - 새로 사용하는 컴포넌트 - 프로토타입만으로는 명확하지 않은 인터랙션 - 플랫폼별로 다르게 보여야 하는 요소 - 특정 레이어의 속성, 크기, 동작 방식 - 개발자와 먼저 어떤 정보가 유용한지 합의하면 불필요한 주석을 줄일 수 있다. - Figma의 annotations와 Dev Mode를 활용하면 스펙, 측정값, 설명을 최종 디자인에 직접 고정할 수 있다. - 주석은 디자이너와 개발자 간 대화를 대체하는 것이 아니라, 대화가 필요한 지점을 명확하게 해 커뮤니케이션을 개선한다. ## 디자인과 개발의 공통 언어 만들기 - 디자인과 개발은 서로 다른 분야이므로 같은 용어가 다른 의미로 해석될 수 있다. - 예를 들어 디자이너가 “toggle”이라고 했을 때 개발자가 “switch”를 떠올릴 수 있다. - 프로젝트 초기에 컴포넌트와 속성의 명칭을 합의하면 이후 구현 논의에서 불필요한 혼선을 줄일 수 있다. - 색상, 폰트, 간격처럼 기초적인 디자인 요소는 변수와 스타일로 관리해 디자인과 코드가 동일한 기준을 사용하도록 한다. - 개발팀에 이미 네이밍 규칙이 있다면 디자인 시스템에도 이를 반영하는 것이 좋다. - 예를 들어 `bg-primary-active`, `body text`처럼 공유된 명칭을 사용하면 특정 색상의 헥스 코드나 폰트 세부 정보를 매번 설명하지 않아도 된다. - 디자인 시스템의 색상 휠과 같은 도구를 활용하면 색조와 명도를 일관되게 선택하고 적용할 수 있다. ## 파일과 캔버스를 라벨로 정리하기 - Figma의 무한 캔버스는 아이디어를 자유롭게 펼치기 좋지만, 개발자가 처음 파일을 열었을 때 필요한 화면을 찾기 어렵게 만들 수 있다. - 브레인스토밍과 반복 작업 단계에서는 파일이 다소 복잡해도 괜찮지만, 개발에 넘길 시점에는 구조를 정리해야 한다. - 관련 디자인을 섹션으로 묶어 캔버스 내 탐색 범위를 좁힌다. - 구현이 준비된 섹션이나 프레임에는 “Ready for dev” 상태를 표시해 개발자가 우선 확인할 대상을 알 수 있게 한다. - 팀 차원에서 동일한 파일 템플릿을 사용하면 매번 구조를 새로 파악해야 하는 부담과 컨텍스트 전환을 줄일 수 있다. 실무에서는 주석을 많이 다는 것보다 필요한 정보만 남기고, 변수·스타일·공통 명칭을 디자인 시스템에 정착시키는 것이 효과적이다. 또한 개발 전달 전에는 파일을 정리하고 구현 범위를 명확히 표시해 “Ready for dev”가 팀 내에서 실제로 신뢰할 수 있는 상태가 되도록 관리하는 것이 좋다.

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

Figma디자인 시스템디자인 토큰dev-mode+3

datadog·2024년 2월 13일·2분 읽기큐레이션 요약

.NET 지속적 프로파일

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 내용입니다. 제공된 본문에는 선정 이유나 평가 기준에 대한 상세 설명은 없고, Datadog이 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 제공·AI 등을 아우르는 통합 플랫폼을 제공한다는 정보가 주로 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner의 **Observability Platforms 2026** 평가에서 Leader로 소개되었습니다. - 다만 제공된 내용만으로는 다음 세부 사항을 확인할 수 없습니다. - 평가된 구체적인 강점과 약점 - 다른 경쟁 제품과의 비교 - Gartner의 실행 능력 및 비전 평가 근거 - Datadog의 매직 쿼드런트 내 정확한 위치 ### 통합 옵저버빌리티 플랫폼 Datadog은 여러 운영 데이터를 하나의 플랫폼에서 수집·분석하는 제품군을 제공합니다. - **인프라 모니터링** - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스 모니터링 - 클라우드 비용, 스토리지, GPU 모니터링 - **애플리케이션 성능 관리** - APM, 서비스 모니터링, 지속적 프로파일링 - 동적 계측과 AI 에이전트 관측성 - **로그 및 데이터 관측성** - 로그 관리와 민감 데이터 탐지 - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 모니터링 - **보안** - 코드 보안, SAST, IAST, IaC 보안 - 클라우드 보안, SIEM, 워크로드 보호, 애플리케이션·API 보호 - **디지털 사용자 경험** - 브라우저·모바일 RUM - 세션 리플레이, 합성 모니터링, 오류 추적, 제품 분석 - **소프트웨어 제공 및 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 - **AI 기능** - Bits AI 에이전트, 조사·채팅 기능, 보안 분석가 - MCP 서버, GPU 모니터링, AI 통합 기능 ### 제공된 자료의 한계 - 본문에는 Gartner 보고서의 분석 내용보다 Datadog 사이트의 제품 메뉴와 링크가 대부분 포함되어 있습니다. - 따라서 “Leader” 선정 자체는 확인할 수 있지만, 그 의미를 기술적으로 평가하거나 선정 배경을 검증하기에는 정보가 부족합니다. - 정확한 판단을 위해서는 Gartner 보고서 원문이나 Datadog의 공식 발표문에서 평가 기준과 세부 근거를 추가로 확인해야 합니다. 실무적으로는 Datadog이 다양한 관측성·보안·개발 운영 기능을 단일 플랫폼으로 통합하려는 제품 전략을 보여준다는 점에 의미가 있습니다. 다만 도입 여부는 Gartner의 등급만으로 결정하기보다 비용, 데이터 보존 정책, 기존 도구와의 연동성, 조직의 운영 규모를 함께 비교하는 것이 좋습니다.

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

옵저버빌리티애플리케이션 성능 모니터링인프라 모니터링dotnet+1

datadog·2024년 2월 13일원문

.NET 연속 프로파일러: CPU 및 월 타임 프로파일링 (새 탭에서 열림)

Datadog의 .NET 컨티뉴어스 프로파일러는 CPU 사용량과 Wall Time(실행 시간)을 효과적으로 수집하기 위해 저수준 스레드 샘플링 방식을 채택하고 있습니다. 운영 환경의 부하를 최소화하면서도 정확한 데이터를 확보하기 위해 관리되는 스레드(Managed Threads)를 정밀하게 추적하며, 가비지 컬렉션(GC)과 같은 네이티브 스레드의 영향까지 함께 분석합니다. 이를 통해 개발자는 연산 집약적인 코드뿐만 아니라 I/O 대기 등으로 인한 지연 원인까지 심층적으로 파악할 수 있습니다. ### CPU와 Wall Time 프로파일링의 개념적 차이 * **CPU 프로파일링**: 스레드가 CPU 코어에서 실제로 실행되는 동안 소모한 사이클을 측정하여 연산량이 많은 코드 블록을 찾는 데 집중합니다. * **Wall Time 프로파일링**: I/O 대기나 락(Lock) 경합 등 스레드가 중단된 시간까지 포함하여 메서드 실행에 걸린 전체 시간을 측정하며, 요청 지연의 근본 원인을 파악하는 데 유용합니다. * **샘플링 방식 채택**: ETW(Windows)나 perf(Linux) 같은 도구는 높은 권한과 시스템 부하 문제로 운영 환경에 부적합하므로, 특정 주기로 스레드 스택을 관찰하는 샘플링 방식을 사용하여 성능 영향을 최소화합니다. ### 효율적인 스레드 모니터링 구조 * **관리되는 스레드 추적**: `ICorProfilerCallback`의 메서드들을 활용해 .NET 런타임이 관리하는 스레드의 생성 및 파괴를 실시간으로 모니터링하고 `ManagedThreadList`에 보관합니다. * **네이티브 스레드 오탐 방지**: 초기 구현에서는 C#을 사용했으나, 네이티브 스레드가 관리되는 메서드를 호출할 때 발생하는 예외적인 상황을 방지하기 위해 전체 구조를 C++로 작성하여 프로파일러 자체 스레드가 샘플링되는 문제를 해결했습니다. * **공용 익스포터 활용**: 수집된 샘플 데이터는 Rust로 작성된 고성능 익스포터를 통해 Datadog 백엔드로 전송되며, 이 모듈은 PHP, Ruby 등 다른 언어 프로파일러와 공유되어 안정성을 확보했습니다. ### OS 수준의 CPU 프로파일링 최적화 * **상태 확인 메커니즘**: 10ms마다 실행 가능한 스레드를 검사하며, Windows는 `NtQueryInformationThread`를, Linux는 `/proc/self/task/<tid>/stat` 파일을 파싱하여 CPU 소비량을 확인합니다. * **저수준 C 구현을 통한 성능 개선**: Linux 환경에서 `std::ifstream` 등 고수준 C++ 클래스를 사용할 때 발생하는 메모리 할당 오버헤드를 줄이기 위해, 할당이 없는 저수준 C API로 교체하여 전체 메모리 할당량의 8%와 CPU 사용량의 2%를 절감했습니다. * **GC 스레드 가시화**: .NET 5 이상의 환경에서는 프로파일링 API가 감지하지 못하는 서버 GC 및 배경 GC 스레드의 CPU 소비량을 별도로 계산하여 플레임 그래프에 표시함으로써 성능 간섭 현상을 명확히 보여줍니다. ### 분산 추적과 연동된 Wall Time 분석 * **Code Hotspots 기능**: 분산 트레이서와 연동하여 특정 요청(Span)을 처리 중인 스레드를 우선적으로 샘플링하며, 이를 통해 느린 요청의 원인이 되는 코드 경로를 정확히 짚어냅니다. * **P/Invoke 비용 최소화**: 트레이서가 프로파일러를 호출할 때 발생하는 오버헤드를 줄이기 위해, 스팬 ID가 기록되는 메모리 위치를 직접 공유하여 추가적인 API 호출 없이 데이터를 실시간으로 읽어옵니다. * **동적 샘플링**: 실행 중인 스레드가 많아질수록 샘플링 간격을 조절하여 데이터의 정확도와 시스템 부하 사이의 균형을 유지합니다. 이 프로파일러는 고성능 환경에서 안정적으로 동작하기 위해 C++와 Rust를 기반으로 저수준 OS API를 직접 제어하도록 설계되었습니다. 특히 Linux 환경에서의 파일 파싱 최적화나 트레이서와의 메모리 공유 방식은 대규모 트래픽을 처리하는 서비스에서 프로파일러 자체의 오버헤드를 극단적으로 줄여야 하는 개발자들에게 유용한 참고 사례가 됩니다.

datadogRustLinuxwindows+4