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

figma3분 읽기큐레이션 요약

디자이너가 정치적 변화

디자이너는 시각적 결과물을 만드는 데 그치지 않고, 정치·사회적 변화를 촉진하는 실질적인 역할을 할 수 있다. 2016년 미국 대선 이후 여러 디자이너가 무상 디자인, 캠페인, 작품 판매, 풍자 작업 등을 통해 소수자와 시민단체를 지원했다. 글은 좋은 디자인이 조직의 신뢰도와 영향력을 높이며, 디자이너 개인도 자신의 직업과 창작물을 정치적 참여의 수단으로 활용할 수 있다고 말한다. ## 선거 이후 행동으로 전환한 디자이너들 - 트럼프 당선 다음 날, 포틀랜드의 디자인 에이전시 **The Beauty Shop**은 여성, 유색인종, 히스패닉계, 무슬림, 이민자, LGBTQ 커뮤니티를 대표하는 단체에 무료 디자인을 제공하겠다고 발표했다. - 게시물 공개 후 이틀 만에 팔로워가 네 배로 늘었고, 약 300명의 디자이너와 스튜디오가 참여 의사를 밝혔다. - 이들은 디자이너와 풀뿌리 조직을 연결하는 연합체 **Visible**을 만들었다. - 초기 협력 단체에는 낙태 접근권을 지원하는 Iowa Abortion Access Fund, 의료 문제를 다루는 Nightingale, 예멘과 미국의 관계를 연구하는 Yemen Peace Project 등이 포함됐다. - 해킹 공격을 받은 Yemen Peace Project처럼, 디자인은 미적 개선뿐 아니라 조직의 복구와 활동 지속에도 직접 기여할 수 있었다. ## 디자인이 사회운동의 신뢰도를 높이는 방식 - 좋은 로고와 시각 체계는 단체를 더 합법적이고 신뢰할 만한 조직처럼 보이게 한다. - 디자인은 사회운동의 구조와 메시지를 정리해 사람들이 단체의 목적을 이해하고 참여하도록 돕는다. - 따라서 디자이너의 기여는 단순히 “예쁜 결과물”을 만드는 일이 아니라, 시민단체가 목표를 달성할 수 있는 기반을 구축하는 일이다. - 글은 디자이너가 사회를 직접 구한다는 식의 낙관을 경계하면서도, 전문 기술이 운동의 성공 가능성을 높일 수 있다고 설명한다. ## 긍정적 가치와 공통 기반을 보여주는 캠페인 - **Creative Action Network(CAN)**은 National Parks Conservation Association, New York Public Library 등과 협력해 사회적 목적의 디자인 캠페인을 진행한다. - 트럼프 행정부 출범 이후에는 “미국을 위대하게 만드는 것”을 주제로 포스터를 제작했다. - 목표는 새 행정부의 첫 100일 동안 하루에 한 장씩 포스터를 공개하는 것이었다. - 포스터는 재즈, 종교의 자유 등 미국 사회가 지켜야 할 다양한 가치를 다뤘다. - 저항과 protest뿐 아니라, 사람들이 더 많이 보고 싶어 하는 가치를 축하하고 공통점을 만드는 것 역시 정치적 행동이라는 관점을 제시한다. ## 예술 작품을 통한 직접적인 모금 - 일러스트레이터 **Hallie Bateman**은 정치적 현실이 바뀐 뒤 자신의 작품이 새로운 시대를 충분히 반영하고 있는지 고민했다. - 그는 전쟁 시기의 예술가와 예술의 역할을 다룬 책을 읽으며 자신의 창작 방향을 재검토했다. - 이후 어두운 숲길을 달리는 장면을 그린 작품을 한정 판매하고, 인쇄비를 제외한 수익을 Planned Parenthood에 기부했다. - 모금 목표였던 2,000달러를 달성했으며, 이후 Sierra Club을 위한 작품 판매도 진행했다. - 명확한 정치 포스터가 아니더라도 작품 판매와 기부를 결합하면 예술 자체가 사회운동의 재원이 될 수 있음을 보여준다. ## 풍자와 대중매체를 활용한 정치적 메시지 - 전 Facebook 디자이너 **Ben Barry**는 The New York Times의 의뢰로 트럼프를 풍자하는 가짜 구인 지원서를 디자인했다. - 그는 초등학교 현장학습 안내문처럼 보이게 하거나 러시아 내부 문서처럼 보이게 하는 등 여러 시각적 형식을 제안했다. - 최종안은 트럼프의 이미지와 연상되는 크고 화려한 금색 스타일로 제작됐다. - 이 사례는 디자이너가 신문, 소셜미디어 등 대중적인 매체의 영향력을 활용해 정치적 비판을 효과적으로 전달할 수 있음을 보여준다. 디자이너는 자신의 전문성을 무상 지원, 캠페인 제작, 기부 상품, 풍자 콘텐츠 등 다양한 방식으로 사회적 목적에 연결할 수 있다. 중요한 것은 모든 작업이 거대한 정치 프로젝트일 필요는 없으며, 자신이 가진 기술과 창작 방식을 현실적인 범위에서 지속적으로 활용하는 것이다.

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

Figma의 팀 라이

Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다. ## 기존 디자인 도구의 한계 - 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다. - 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다. - 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다. - 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다. - Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다. ## Figma가 제시한 기반 - Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다. - 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다. - 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다. ## 엔지니어링 원칙을 반영한 디자인 시스템 - React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다. - 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다. - 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다. ## 게시(Publish): 단일 진실 공급원 만들기 - 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다. - 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다. - 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다. - 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다. - 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다. - 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다. ## 삽입(Insert): 여러 파일에서 컴포넌트 재사용 - 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다. - 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다. - 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다. - 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다. - 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다. ## 업데이트(Update): 변경 사항의 동기화 - 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다. - 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다. - 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다. - 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다. - 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다. ## 실용적인 결론 Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.

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

마운트의 문제점 (새 탭에서 열림)

데이터독(Datadog) 에이전트가 특정 환경에서 응답을 멈추고 종료조차 되지 않는 문제는 NFS(Network File System)의 '하드 마운트' 속성과 시스템 콜의 작동 방식 때문에 발생했습니다. 하드 마운트된 NFS 서버와의 연결이 끊기면 디스크 정보를 확인하는 `statvfs` 시스템 콜이 무한 대기에 빠지며, 이는 결과적으로 에이전트 전체의 중단으로 이어졌습니다. 이를 해결하기 위해 데이터독은 디스크 체크 로직을 별도 스레드로 분리하고 타임아웃을 적용함으로써, 고객사의 시스템 설정에 관계없이 에이전트의 가용성을 확보하는 설계를 도입했습니다. **에이전트 정지 현상과 원인 분석** * 일부 시스템에서 모든 메트릭 수집이 중단되고 에이전트가 '종료 불가능한(unkillable)' 상태로 멈추는 버그가 보고되었습니다. * 조사 결과, 에이전트는 항상 디스크 체크 과정에서 멈췄으며 구체적으로 파이썬의 `os.statvfs` 함수 호출 시점에서 병목이 발생했습니다. * `os.statvfs`는 내부적으로 glibc의 `statvfs` 시스템 콜을 호출하는데, 이는 리눅스 환경에서 파일 시스템의 상태 정보를 가져오는 표준적인 방법입니다. **NFS 하드 마운트와 시스템 콜의 무한 대기** * NFS를 '하드 마운트(hard mount)' 옵션으로 연결하면, 서버가 응답하지 않을 때 시스템 콜이 타임아웃 없이 성공할 때까지 영구적으로 재시도합니다. * 하드 마운트는 데이터의 일관성을 보장하지만 네트워크 불안정 시 해당 마운트 지점에 접근하는 프로세스를 '좀비' 상태로 만들 수 있으며, 이는 NFS의 기본 설정이기도 합니다. * 특히 glibc의 `statvfs` 구현체는 정보를 찾기 위해 `/proc/mounts`에 나열된 모든 디렉토리를 순회하므로, 현재 조사하려는 대상이 아닌 다른 NFS 마운트에 문제가 생겨도 시스템 전체가 멈추는 현상이 발생합니다. **별도 스레드 및 타임아웃 도입을 통한 해결** * 데이터독 에이전트는 고객이 설정한 마운트 옵션을 강제로 변경할 수 없으므로, 어떤 환경에서도 정상 동작할 수 있는 방어적인 코드가 필요했습니다. * 문제를 해결하기 위해 `statvfs` 호출을 별도의 스레드에서 실행하도록 구조를 변경하고, 메인 스레드에는 타임아웃 로직을 추가했습니다. * 만약 특정 마운트 지점에서 시스템 콜이 응답하지 않더라도, 메인 스레드는 지정된 시간 이후 작업을 포기하고 다음 메트릭 수집으로 넘어감으로써 에이전트의 전체 성능을 보존합니다. * 이 방식은 하드 마운트가 활성화된 시스템에서 약간의 메모리 사용량 증가를 야기하지만, 다양한 이질적 환경에서 모니터링 연속성을 보장하기 위한 필수적인 트레이드오프(Trade-off)로 채택되었습니다. 서버 환경에서 NFS를 운용할 때는 `soft` 마운트 옵션이나 `intr(interruptible)` 옵션을 검토하여 시스템 콜이 무한 대기에 빠지는 상황을 예방해야 합니다. 또한, 모니터링 도구와 같이 외부 환경에 민감한 애플리케이션을 개발할 때는 외부 시스템 콜(I/O) 작업을 반드시 별도 스레드로 격리하고 엄격한 타임아웃을 적용하는 설계가 중요합니다.

datadog1분 읽기큐레이션 요약

마운팅의 문제점 |

제공된 내용에는 기술 블로그 본문이 포함되어 있지 않고, Datadog의 제품 메뉴와 Gartner 홍보 링크만 표시되어 있습니다. 따라서 글의 주장, 기술적 세부사항, 섹션별 내용을 정확히 요약할 수 없습니다. 링크의 실제 본문이나 원문 텍스트를 보내주시면 요청하신 형식으로 요약하겠습니다. ### 현재 확인 가능한 내용 - 링크 경로는 `Datadog Engineering`의 **“The Trouble with Mounting”** 글을 가리킵니다. - 제공된 텍스트 대부분은 다음과 같은 Datadog 사이트 내비게이션입니다. - 인프라·애플리케이션 모니터링 - 로그·보안·RUM·CI/CD - AI 및 플랫폼 기능 - 본문에 해당하는 문제 제기, 구현 방식, 코드, 성능 비교, 결론은 포함되어 있지 않습니다. 원문 본문을 붙여 넣거나 정상적으로 추출된 페이지 내용을 제공해 주세요.

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

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

Datadog의 새로운 기능인 'Notebooks'는 숙련된 시니어 엔지니어가 아닌, 7개월간의 인턴십을 거친 인턴의 주도로 개발되었습니다. 인턴 Marie-Laure Bardonnet는 사소한 버그 수정부터 시작해 점진적으로 업무 범위를 넓히며, 결국 최신 프론트엔드 기술을 활용해 제품의 핵심 기능을 성공적으로 구축했습니다. 이는 주니어 개발자에게 도전적인 과제와 적절한 멘토링이 주어졌을 때 얼마나 큰 성과를 낼 수 있는지를 보여주는 사례입니다. ### Notebooks 기능의 역할과 가치 * 특정 시점의 데이터 그래프를 텍스트 및 기타 정보와 함께 저장하고 공유할 수 있는 도구입니다. * 조직 내에서 장애 대응이나 분석 시 깊은 맥락(Context)을 제공하여 팀원들이 더 빠르게 상황을 파악하고 협업할 수 있도록 돕습니다. ### 단계적인 업무 확장을 통한 코드베이스 적응 * 초기에는 대시보드의 즐겨찾기 별표 표시 수정과 같은 사소한 UI 버그부터 시작하여 애플리케이션 구조에 익숙해졌습니다. * 점차 난이도가 높은 과제를 수행하며 코드베이스에 연착륙(Smooth entry)했고, 이는 단순한 '잡무(Grunt work)'를 넘어 실제 제품에 영향을 미치는 프로젝트로 이어졌습니다. ### 최신 프론트엔드 기술 스택의 실무 적용 * 단순한 기능 구현을 넘어 React, Redux(상태 관리), Redux Saga(사이드 이펙트 관리)와 같은 최신 기술을 깊이 있게 학습하고 적용했습니다. * 인턴 과정임에도 불구하고 기능 구현에 필요한 아키텍처 리팩토링 아이디어를 제안하고 이를 실무에 반영하는 등 심도 있는 엔지니어링 과정을 거쳤습니다. ### 자율성과 가이드의 균형을 맞춘 멘토링 * 팀 리드는 인턴이 스스로 해결책을 찾도록 지켜보는 것과 기술적으로 까다로운 부분에서 함께 논의하는 것 사이에서 적절한 균형을 유지했습니다. * 이러한 멘토링 덕분에 인턴은 이론적인 지식과 실무 역량의 차이를 이해하고, 개발자로서 독립적인 의사결정을 내리는 법을 체득했습니다. 기업이 우수한 엔지니어를 확보하기 위해서는 인턴을 단순 보조 인력으로 활용하기보다, 실질적인 제품 개발에 참여시키고 최신 기술을 탐구할 환경을 제공해야 합니다. 적절한 자율성과 책임감이 부여될 때 주니어 개발자는 기업의 핵심 인재로 성장하며 장기적인 기여를 할 수 있게 됩니다.

datadog2분 읽기큐레이션 요약

엔지니어링 스포

Datadog이 Gartner의 ‘Observability Platforms’ 매직 쿼드런트에서 리더로 선정되었다는 내용을 홍보하는 페이지입니다. 제공된 내용에는 평가 근거, 비교 대상, 제품별 분석 등 본문이 포함되어 있지 않아 선정의 구체적인 이유와 결론까지는 확인할 수 없습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 관측성 플랫폼 분야에서 Gartner가 선정한 리더로 소개됩니다. - 링크 제목상 2026년 Gartner Magic Quadrant for Observability Platforms 평가와 관련된 자료입니다. - 다만 제공된 텍스트에는 Gartner의 평가 기준이나 Datadog의 강점에 대한 설명이 없습니다. ### Datadog의 제품 영역 제공된 페이지 메뉴를 통해 Datadog이 다음과 같은 폭넓은 기능을 제공한다는 점은 확인할 수 있습니다. - **인프라 모니터링** - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스, GPU 모니터링 - 클라우드 비용 및 스토리지 관리 - **애플리케이션 관측성** - APM, 서비스 모니터링, 연속 프로파일링, 동적 계측 - AI 에이전트 관측성 - **로그·데이터 관리** - 로그 관리, 데이터베이스 모니터링, 데이터 스트림 및 작업 모니터링 - 민감 데이터 탐지와 관측성 파이프라인 - **보안** - 코드 보안, SAST·IAST, 클라우드 보안, SIEM - 취약점 관리, 워크로드 보호, 애플리케이션·API 보호 - **디지털 경험** - 브라우저·모바일 RUM, 세션 리플레이, 합성 모니터링 - 오류 추적, 제품 분석, 모바일 앱 테스트 - **소프트웨어 제공 및 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 - **AI 기능** - Bits AI 에이전트, 조사·보안 분석, AI 통합, MCP 서버 - GPU 모니터링 및 AI 에이전트 디렉터리 ### 확인할 수 없는 내용 - Gartner가 Datadog을 리더로 평가한 구체적인 근거 - 실행 능력(Ability to Execute)과 비전 완성도(Completeness of Vision) 점수 - 경쟁 제품과의 비교 결과 - Datadog의 약점이나 Gartner의 개선 권고 - 실제 고객 사례와 비용·구축 관련 평가 원문 보고서나 본문 전체가 제공되어야 Gartner의 평가 기준과 Datadog의 리더 선정 이유를 정확히 요약할 수 있습니다.

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

피그마 컴포넌트

Figma의 컴포넌트는 소프트웨어 개발의 composition, inheritance, override 개념을 디자인에 적용해 복잡한 UI를 일관되고 효율적으로 설계하도록 돕는다. 원본 컴포넌트를 수정하면 모든 인스턴스에 변경 사항이 반영되지만, 각 인스턴스는 필요한 속성을 독립적으로 재정의할 수 있다. 이를 통해 반복 작업을 줄이면서도 디자인 시스템의 일관성과 창의적인 변형을 동시에 확보할 수 있다. ## 디자인에 컴포넌트를 적용하는 이유 - 복잡한 화면을 더 작은 재사용 단위로 나누어 이해하고 구성할 수 있다. - 주소록의 연락처 행처럼 반복되는 UI를 한 번만 설계한 뒤 여러 곳에서 재사용할 수 있다. - 동일한 컴포넌트를 사용하면 글자 크기, 간격, 아이콘, 그래픽 등의 시각적 일관성을 유지하기 쉽다. - 컴포넌트는 단순한 복사본이 아니라 동일한 원본을 참조하는 인스턴스이므로, 원본 변경 사항이 관련 디자인에 자동으로 반영된다. ## Figma가 지향한 컴포넌트 설계 - 초보자도 쉽게 배울 수 있어야 한다. - 고급 사용자에게 충분히 강력해야 한다. - 디자인 과정 전반에서 유연하게 활용할 수 있어야 한다. - 체계적으로 디자인하더라도 창의적인 작업을 방해하거나 불필요한 작업 절차를 늘리지 않아야 한다. - 디자인 시스템 구축이 속도와 일관성을 높이는 수단이 되어야 하며, 새로운 문제를 해결하는 데 제약이 되어서는 안 된다. ## 컴포넌트와 인스턴스의 동작 방식 - 선택한 프레임이나 객체에 “Create Component”를 적용하면 컴포넌트가 생성된다. - 컴포넌트를 복제하거나 Alt 키로 드래그하거나 복사·붙여넣기하면 일반 복사본이 아니라 인스턴스가 만들어진다. - 인스턴스는 캔버스에서 위치를 독립적으로 가질 수 있지만, 기본적으로 원본 컴포넌트의 구조와 속성을 공유한다. - 원본 컴포넌트의 변경 사항은 모든 인스턴스에 즉시 반영된다. - 인스턴스 내부의 일부 속성은 관리와 유지보수를 위해 제한될 수 있으며, 특히 내부 객체의 위치와 크기 같은 속성이 대표적이다. ## 스타일 및 속성 오버라이드 - 인스턴스에서 변경한 값은 원본을 대체하는 것이 아니라 해당 인스턴스에만 적용되는 오버라이드로 취급된다. - 예를 들어 특정 인스턴스의 채우기 색상을 진회색으로 바꾸거나, 다른 인스턴스의 선 색상과 두께를 빨간색·6px로 설정할 수 있다. - 원본 컴포넌트를 수정해도 인스턴스에서 직접 재정의한 속성은 유지된다. - 재정의하지 않은 속성은 원본 컴포넌트의 최신 상태를 계속 반영한다. - 인스턴스 내부의 하위 레이어와 그 속성도 오버라이드할 수 있어 다양한 변형을 만들 수 있다. - 변경 사항을 제거하려면 “Reset Instance”를 사용해 원본 컴포넌트의 상태로 되돌릴 수 있다. ## 중첩 컴포넌트로 복잡한 UI 구성 - 컴포넌트 안에 다른 컴포넌트의 인스턴스를 포함할 수 있다. - 여러 인스턴스를 조합해 더 복잡한 동작과 UI 구조를 만들 수 있다. - 기존 인스턴스를 포함한 객체를 다시 컴포넌트로 만들 수도 있다. - 작은 단위의 컴포넌트를 계층적으로 조합하면 대규모 디자인 시스템을 관리하기 쉬워진다. ## 제약 조건과의 결합 - 컴포넌트는 Figma의 다른 기능과 함께 사용할 때 더 큰 표현력을 갖는다. - 제약 조건을 적용하면 화면 크기나 객체 위치가 바뀔 때 내부 요소가 어떻게 반응할지 정의할 수 있다. - 따라서 단순히 같은 UI를 복제하는 것을 넘어, 다양한 크기와 상황에 대응하는 반응형 디자인을 구성할 수 있다. 실무에서는 반복되는 UI를 먼저 컴포넌트로 만들고, 인스턴스별 차이는 오버라이드로 최소한만 적용하는 방식이 적합하다. 공통 구조와 스타일은 원본에서 관리하고, 개별 화면의 예외적인 요구만 인스턴스에서 변경하면 유지보수성과 디자인 일관성을 함께 확보할 수 있다.

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

벡터 네트워크의 삭제 및 복구 |

Figma의 “삭제 후 복구(Delete and Heal)”는 정점을 단순히 제거하는 기능이 아니라, 주변 선과 곡률을 최대한 보존하며 벡터 구조를 재구성하는 작업이다. 단순한 경로에서는 인접 정점을 연결하면 되지만, 곡선과 벡터 네트워크에서는 베지어 곡선 근사와 그래프 구조를 함께 고려해야 한다. Figma는 이 기능을 통해 복잡한 벡터 네트워크에서도 자연스러운 편집 결과를 제공한다. ## 삭제와 삭제 후 복구의 차이 - 일반적인 정점 삭제는 해당 정점에 연결된 모든 선분과 그 선분에 닿는 채우기 영역을 함께 제거한다. - “삭제 후 복구”는 삭제된 정점 양쪽의 구조를 새 선으로 연결해 기존 형태를 유지하려는 기능이다. - 한쪽에만 선이 연결된 정점은 연결할 대상이 없으므로 선을 제거한다. - 삼각형처럼 정점 수가 줄어드는 경우에도 결과가 항상 같지는 않다. - 어떤 경우에는 두 정점 사이의 단일 선으로 축소된다. - 다른 경우에는 두 개의 선이 유지될 수 있다. - Figma는 정점과 선의 연결 관계에 따라 결과를 다르게 처리한다. ## 곡선의 형태를 보존하는 복구 - 곡선 위의 정점을 삭제하면 단순히 양 끝점을 직선으로 연결할 경우 기존 곡률이 사라진다. - 다른 도구는 인접 정점의 곡률 핸들 위치를 그대로 유지하는 경우가 많다. - Figma는 원래 곡선을 최대한 근사하도록 인접 정점의 제어 핸들을 조정한다. - 각 곡선 선분은 cubic Bézier curve로 표현된다. - 복구 문제는 다음 두 개의 cubic Bézier 곡선을 하나의 곡선으로 근사하는 문제로 바뀐다. - 첫 번째 곡선: `(P0, P1, P2, P3)` - 두 번째 곡선: `(P3, P4, P5, P6)` - 새 곡선: `(P’0, P’1, P’2, P’3)` - 벡터 네트워크의 나머지 부분을 변경하지 않기 위해 새 곡선의 양 끝점은 고정한다. - `P’0 = P0` - `P’3 = P6` - 따라서 계산해야 하는 것은 새 곡선의 제어점 `P’1`, `P’2`다. ## 베지어 곡선 근사 알고리즘 - 먼저 두 기존 곡선을 따라 여러 샘플 점을 생성한다. - cubic Bézier의 매개변수 `t`에 값을 대입해 곡선 위의 점을 계산한다. - 두 곡선이 공유하는 끝점은 중복해서 세지 않는다. - 예를 들어 각 구간에 여러 `t` 값을 적용하면 전체 연결 곡선 위의 샘플 점 목록을 얻을 수 있다. - 생성된 점들을 하나의 cubic Bézier 곡선으로 피팅한다. - Figma는 Philip J. Schneider의 “An Algorithm for Automatically Fitting Digitized Curves” 알고리즘과 관련 구현을 활용한다. - 결과적으로 삭제 전의 곡률을 완벽히 복원하지는 않지만, 시각적으로 자연스러운 단일 곡선을 얻는다. ## 벡터 네트워크와 그래프 기반 삭제 - Figma의 벡터 객체는 일반적인 순차 경로가 아니라 무방향 그래프로 표현된다. - 더 정확히는 각 선 자체의 식별성을 가진 무방향 멀티그래프다. - 따라서 하나의 정점에 최대 두 개의 선만 연결된다는 경로 기반 도구의 가정을 사용할 수 없다. - 삭제 대상 정점에 세 개 이상의 선이 연결될 수 있으며, 이 경우 어떤 선끼리 연결할지 결정해야 한다. - 연결된 선의 개수가 홀수라면 모든 인접 선을 제거한다. - 남는 선을 자연스럽게 짝지을 방법이 없기 때문이다. - 연결된 선의 개수가 짝수라면 선들을 쌍으로 묶어 새 선을 만든다. - 이때 “서로 반대편에 있는 선”을 정의하기 위해 정점에서 뻗어나가는 선을 각도 기준으로 정렬한다. - 정렬된 방향을 바탕으로 서로 마주 보는 선끼리 연결해 네트워크 구조를 복구한다. ## 실용적인 결론 벡터 편집기의 삭제 기능은 단순한 데이터 제거가 아니라, 그래프 연결성·곡선 근사·사용자 기대를 함께 처리하는 기하학적 재구성 문제다. 특히 벡터 네트워크를 지원하려면 정점 차수가 2를 넘는 상황과 곡선 제어점까지 고려해야 하며, Bézier 샘플링과 곡선 피팅을 결합하는 방식이 실용적인 해결책이 된다.

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

Redux-Doghouse: 스코프 지정을 통한 재사용 가능한 React-Redux 컴포넌트 만들기 (새 탭에서 열림)

Redux-Doghouse는 단일 Redux 애플리케이션 내에서 동일한 컴포넌트를 여러 번 재사용할 때 발생하는 상태 충돌 문제를 해결하기 위해 개발된 라이브러리입니다. 각 컴포넌트 인스턴스에 고유한 '스코프(Scope)'를 부여함으로써 액션과 리듀서가 특정 인스턴스에만 독립적으로 작용하도록 격리합니다. 이를 통해 개발자는 기존의 Redux 로직을 대대적으로 수정하지 않고도 복잡한 UI 구성 요소를 모듈화하고 재사용할 수 있습니다. **재사용 가능한 컴포넌트와 Redux의 충돌** * Redux는 전역 상태 관리에는 탁월하지만, 동일한 로직을 가진 컴포넌트를 한 페이지에 여러 개 배치할 경우 문제가 발생합니다. * 특정 액션 타입(예: `MY_ACTION`)이 발행되면, 해당 타입을 구독하는 모든 리듀서가 동시에 반응하기 때문에 한 인스턴스의 버튼 클릭이 모든 인스턴스에 영향을 주게 됩니다. * 이를 해결하기 위해 기존 코드를 리팩토링하는 대신, 각 인스턴스를 독립된 영역(Doghouse)에 격리하는 방식이 필요해졌습니다. **스코프 기반의 액션과 리듀서 작동 방식** * Redux-Doghouse는 `actionCreators`와 `reducers`에 고유한 스코프(식별자)를 결합합니다. * 액션이 발행될 때 메타데이터로 스코프 정보를 포함하며, 래핑된 리듀서는 자신에게 할당된 스코프와 일치하는 액션만을 처리합니다. * 이 방식의 장점은 하위 컴포넌트가 자신이 거대한 애플리케이션의 일부라는 사실을 모른 채 독립적으로 작동할 수 있다는 점입니다. * 상위 레벨에서는 여전히 모든 인스턴스의 내부 상태에 접근하거나 특정 액션에 반응할 수 있어, 상호 연결된 Redux의 장점을 그대로 유지합니다. **데이터독(Datadog)의 실제 적용 사례: 쿼리 에디터** * 데이터독의 '익스프레션 에디터(Expression Editor)'는 여러 개의 '쿼리 에디터'를 포함하며, 각 쿼리는 A, B, C 등의 식별자를 가집니다. * 각 쿼리 에디터에서 발생하는 `SET_GROUP` 액션은 해당 쿼리 인스턴스에만 영향을 주어야 하지만, 동시에 상위 에디터는 모든 쿼리의 그룹 규칙이 일치하는지 검사해야 합니다. * Redux-Doghouse를 통해 각 쿼리 에디터는 부모의 존재를 모른 채 독립적으로 동작하고, 상위 에디터는 스코프가 부여된 액션을 통해 전체적인 비즈니스 로직을 조율합니다. **모듈화와 개발 생산성 측면의 이점** * UI 구성 요소(React)와 상태 로직(Redux)을 동일한 단위로 묶어 모듈화할 수 있어 코드 관리가 용이해집니다. * 뷰(View) 코드와 모델(Model) 코드가 서로 다른 방식으로 분리되는 혼란을 방지하고, 컴포넌트 중심으로 사고할 수 있게 돕습니다. * 기존에 독립적으로 작성된 Redux 컴포넌트를 더 큰 시스템에 통합할 때 코드 수정 기능을 최소화할 수 있습니다. 복잡한 대시보드나 도구 모음처럼 동일한 UI 패턴이 한 화면에 반복적으로 나타나면서도 각각 독립적인 상태를 유지해야 하는 프로젝트라면, Redux-Doghouse는 구조적인 일관성을 지키며 확장성을 확보할 수 있는 훌륭한 대안이 될 것입니다.

datadog1분 읽기큐레이션 요약

Redux-Doghouse: 스

제공된 내용에는 기술 블로그 본문이 포함되어 있지 않고, Datadog의 제품 메뉴와 Gartner Magic Quadrant 홍보 문구가 대부분입니다. 본문 링크의 제목으로 보아 글의 주제는 React·Redux 컴포넌트를 스코핑(scoping)해 재사용하는 방법으로 추정되지만, 구체적인 구현 방식이나 결론은 확인할 수 없습니다. ### 제공된 페이지의 성격 - Datadog의 제품·서비스 탐색 메뉴가 포함되어 있습니다. - 인프라 모니터링, APM, 로그, 보안, RUM, CI, AI 등 Datadog 제품군이 나열되어 있습니다. - “Gartner Magic Quadrant for Observability Platforms”에서 Leader로 선정되었다는 홍보 링크가 있습니다. - 해당 내용은 기술 블로그의 본문이라기보다 Datadog 웹사이트의 공통 내비게이션 및 광고 영역에 가깝습니다. ### 링크에서 확인되는 기술 주제 - 링크 경로에는 다음과 같은 주제가 나타납니다. - `redux-doghouse` - 재사용 가능한 React Redux 컴포넌트 - 컴포넌트 간 상태 스코핑 - 다만 다음과 같은 핵심 정보는 제공된 텍스트에 없습니다. - 기존 Redux 구조의 문제점 - “Doghouse”의 구체적인 설계 - 스코핑을 구현하는 코드 - 상태 격리 및 재사용 방식 - 성능·테스트·유지보수상의 장단점 정확한 섹션별 요약을 위해서는 링크의 실제 본문이나 원문 텍스트가 추가로 필요합니다.

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

Emscripten으로 데이터

Figma의 저장 파일이 간헐적으로 손상되는 문제는 재현이 어려운 비결정적 이벤트와 C++의 메모리 안전성 문제 때문에 장기간 해결되지 않았다. 일반적인 메모리 디버깅 도구로 원인을 찾지 못한 뒤, 키보드·마우스 입력을 생성하는 퍼저로 이벤트를 반복 실행해 문제를 재현하는 데 성공했다. 최종 수정은 FlatBuffers의 잘못된 메모리 접근을 고치는 세 줄짜리 커밋이었지만, 원인을 추적하는 과정에서 Emscripten과 브라우저의 메모리 모델까지 분석해야 했다. ## 간헐적으로 발생한 저장 파일 손상 - Figma는 때때로 다시 읽을 수 없는 잘못된 저장 파일을 생성했다. - 당시 저장 형식은 다음 구조였다. - ZIP 파일 - 내부에 Google FlatBuffers로 인코딩된 문서 - 파일의 전체 바이트 구조는 대체로 정상처럼 보였지만, 뒤쪽 데이터를 가리키는 일부 오프셋이 0으로 변해 있었다. - 데이터가 원래 위치가 아닌 곳에 기록된 현상은 다음과 같은 메모리 안전성 위반을 의심하게 했다. - 초기화되지 않은 메모리 사용 - 해제된 메모리 접근(use-after-free) - 배열 범위를 벗어난 읽기·쓰기 ## C++ 메모리 오류의 추적 난이도 - Figma 에디터는 C++로 작성되어 있었다. - C++는 다음과 같은 장점 때문에 그래픽 소프트웨어에 적합하다. - FreeType, HarfBuzz, Skia 같은 저수준 라이브러리 활용 - 하드웨어와 직접 연결되는 언어 기능 - 성숙한 디버깅 및 최적화 도구 - 높은 성능과 세밀한 메모리 제어 - 반면 C++는 언어 자체가 메모리 안전성을 보장하지 않는다. - 복잡한 언어 설계, 오류가 발생하기 쉬운 표준 라이브러리 API, C에서 물려받은 레거시가 결합되어 대규모 프로젝트에서 메모리 오류를 완전히 피하기 어렵다. ## 일반적인 디버깅 방법의 한계 개발팀은 다음과 같은 방법을 시도했지만 문제를 발견하지 못했다. - 메모리를 해제하지 않아 use-after-free 가능성 제거 - macOS의 malloc 디버깅 옵션 활성화 - Valgrind가 보고한 모든 문제 수정 - 컴파일러 업그레이드 - Clang 정적 분석기가 발견한 문제 수정 이런 도구들은 많은 오류를 찾아내지만, 실행 조건에 따라 드물게 발생하거나 특정 메모리 배치에서만 나타나는 문제까지 항상 잡아내지는 못한다. ## 이벤트 기록과 퍼징으로 재현성 확보 - 문제의 핵심은 비동기 타이머와 네트워크 이벤트 등 웹 앱의 비결정성이었다. - 해결 전략은 다음과 같았다. - 사용자 이벤트를 기록한다. - 동일한 이벤트를 순서대로 재생한다. - 문제가 발생할 때까지 세션을 반복 실행한다. - 이벤트를 무작위로 제거하면서도 문제가 유지되는 최소 테스트 케이스를 만든다. - 실제 사용자 세션에는 너무 다양한 이벤트가 포함되므로, 범위를 키보드와 마우스 이벤트로 제한했다. - 실제 세션을 수집하는 대신 퍼저가 무작위 키보드·마우스 입력을 생성하도록 했다. - 며칠 동안 실행한 결과 여러 건의 저장 실패를 재현할 수 있었고, 이후 반복 가능한 입력 시퀀스를 기반으로 본격적인 디버깅이 가능해졌다. ## Emscripten이 C++를 브라우저에서 실행하는 방식 - Figma는 플러그인 없이 브라우저에서 실행되는 웹 앱이다. - C++ 코드는 Emscripten을 통해 JavaScript로 컴파일된다. - JavaScript는 기본적으로 메모리 안전성과 가비지 컬렉션을 제공하지만, WebGL과 Typed Arrays 덕분에 C의 메모리 모델을 흉내 낼 수 있다. - Typed Array의 특징은 다음과 같다. - 고정된 크기를 가진다. - 모든 원소가 같은 타입이다. - 여러 Typed Array가 하나의 ArrayBuffer를 공유할 수 있다. - 같은 메모리를 `Float32Array`와 `Uint8Array` 등 서로 다른 타입으로 해석할 수 있기 때문에 C/C++의 포인터 캐스팅과 유사한 동작을 구현할 수 있다. ## Emscripten의 포인터와 메모리 변환 Emscripten은 C++의 주요 요소를 JavaScript 구조로 변환한다. - 포인터 읽기: Typed Array 읽기 - 포인터 쓰기: Typed Array 쓰기 - 레지스터: JavaScript 지역 변수 - 스택: `STACKTOP`이라는 스택 포인터로 관리 - 타입 변환: 동일한 ArrayBuffer를 공유하는 Typed Array를 통해 구현 - 생성된 코드는 asm.js라는 제한적인 JavaScript 부분집합을 사용해 JIT 컴파일러가 타입을 추론하고 빠르게 최적화하도록 한다. - 예를 들어 `+$value`는 값을 double로 취급하도록 JIT에 힌트를 주며, 비트 연산은 정수 연산으로 최적화될 가능성을 높인다. ## 실용적인 결론 재현이 어려운 데이터 손상 문제는 도구를 하나씩 추가하는 것만으로 해결되지 않을 수 있다. 비결정적 입력을 통제하고, 퍼징과 이벤트 재생으로 실패 조건을 반복 가능하게 만드는 것이 핵심이며, 컴파일된 실행 환경에서는 원본 언어뿐 아니라 Emscripten의 메모리 모델과 런타임 동작까지 함께 이해해야 한다.

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

동료들을 응원하기: Datadog 대시보드로 조직 문화 만들기 (새 탭에서 열림)

6일 동안 850km를 달리는 동료의 도전을 응원하기 위해, 실시간 레이스 데이터를 수집하고 Datadog 대시보드로 시각화한 프로젝트 사례를 소개합니다. 파이썬을 활용한 웹 스크래핑과 Datadog의 메트릭 전송 기능을 결합하여, 멀리 떨어진 사무실에서도 실시간으로 선수의 순위와 주행 거리를 확인할 수 있는 모니터링 환경을 구축했습니다. ### 웹 스크래핑을 통한 데이터 추출 * 레이스 이벤트 웹사이트에서 일반 HTML 형태로 제공되는 주자들의 통계 데이터를 소스로 활용했습니다. * Python의 **Requests** 라이브러리를 사용하여 웹페이지의 HTML 코드를 가져오는 크롤러를 구현했습니다. * 가져온 HTML 데이터에서 실시간 순위, 총 주행 거리 등의 핵심 정보를 추출하기 위해 **BeautifulSoup** 라이브러리를 사용해 파싱 작업을 수행했습니다. ### StatsD를 활용한 메트릭 전송 * 추출한 데이터를 Datadog 에이전트와 **StatsD**를 통해 시스템으로 전송했습니다. * 선수의 주행 거리(`runner.distance`), 현재 순위(`runner.ranking`), 경과 시간(`runner.elapsed_time`)을 각각 **Gauge** 타입의 메트릭으로 정의했습니다. * 각 메트릭에 주자의 이름을 태그(`tags=["name:%s"]`)로 추가하여, 대시보드에서 특정 주자의 데이터를 쉽게 필터링하고 구분할 수 있도록 구성했습니다. ### 대시보드 시각화 및 결과 * 수집된 메트릭을 기반으로 실시간 영상 스트리밍과 재미를 위한 GIF 파일, 그리고 주요 지표들이 포함된 종합 대시보드를 제작했습니다. * 뉴욕과 파리 사무실 곳곳에 이 대시보드를 공유하여, 전 직원이 실시간으로 레이스 상황을 지켜보며 동료를 원격으로 응원할 수 있는 환경을 만들었습니다. 이 사례는 IT 인프라뿐만 아니라 외부의 실시간 데이터를 Datadog과 연결하여 조직 내 이벤트를 흥미롭게 공유하고 구성원들의 참여를 끌어낼 수 있음을 잘 보여줍니다. 데이터 수집부터 시각화까지의 과정이 비교적 간단하므로, 조직 내 다양한 온/오프라인 이벤트를 추적하는 데 응용해 볼 것을 추천합니다.

datadog원문

동료 응원하기: Dat (새 탭에서 열림)

데이터독(Datadog)의 엔지니어들은 6일 동안 약 850km를 달리는 초장거리 레이스에 출전한 동료를 응원하기 위해 실시간 레이스 모니터링 대시보드를 구축했습니다. 이 프로젝트는 웹 스크래핑 기술과 데이터독의 지표 수집 기능을 결합하여 외부 데이터를 대시보드에 시각화하는 과정을 보여줍니다. 이를 통해 기술적인 도구가 단순한 시스템 관제를 넘어 커뮤니티의 결속과 응원을 위한 도구로 어떻게 활용될 수 있는지 증명했습니다. ### 데이터 추출 및 파싱 대시보드 구축의 첫 단계는 대회 공식 웹사이트에서 선수의 실시간 데이터를 가져오는 것이었습니다. - 파이썬(Python)의 인기 라이브러리인 **Requests**를 사용하여 웹페이지의 HTML 코드를 수집하는 간단한 크롤러를 구현했습니다. - 수집된 HTML 데이터는 **BeautifulSoup** 라이브러리를 통해 파싱되어 현재 순위, 총 주행 거리 등 필요한 수치 데이터로 변환되었습니다. - 대회 사이트가 일반 텍스트 형태의 HTML로 데이터를 제공했기에 복잡한 API 없이도 손쉽게 데이터를 확보할 수 있었습니다. ### StatsD를 활용한 지표 전송 확보된 데이터는 데이터독 에이전트와 StatsD를 통해 실시간 지표(Metrics)로 변환되었습니다. - **dog.gauge** 메서드를 사용하여 세 가지 핵심 지표를 생성했습니다: 주행 거리(`runner.distance`), 현재 순위(`runner.ranking`), 경과 시간(`runner.elapsed_time`). - 각 지표에는 `name` 태그를 부여하여 여러 러너의 데이터를 구분하고 개별적으로 필터링할 수 있도록 설계했습니다. - 파이썬 스크립트를 통해 주기적으로 데이터를 갱신함으로써 실시간에 가까운 데이터 흐름을 유지했습니다. ### 대시보드 구성 및 시각화 수집된 지표들은 뉴욕과 파리 사무실에서 누구나 볼 수 있는 인터랙티브 대시보드로 구성되었습니다. - 단순히 숫자만 나열하는 것이 아니라 실시간 비디오 스트리밍과 재미를 위한 GIF 이미지를 포함하여 시각적 즐거움을 더했습니다. - 거리 차이(Lead)와 남은 시간 등 레이스 상황을 한눈에 파악할 수 있는 유의미한 지표들을 배치했습니다. - 이를 통해 전 세계 사무실의 동료들이 원격으로 레이스 상황을 공유하며 선수를 응원할 수 있는 환경을 조성했습니다. 만약 특정 이벤트나 실시간 경주 데이터를 모니터링하고 싶다면, 이 사례와 같이 파이썬의 웹 스크래핑 라이브러리와 데이터독의 Gauge 지표 기능을 결합해 보시기 바랍니다. 데이터가 HTML 형태로 존재하기만 한다면, 어떤 외부 활동이라도 전문적인 인프라 모니터링 도구를 통해 실시간 대시보드로 구현할 수 있습니다.

figma4분 읽기큐레이션 요약

Figma의 멀티플레이어 편집

Figma는 파일을 내려받아 로컬에서 편집한 뒤 전체 문서를 저장하는 방식이 협업 환경과 근본적으로 맞지 않는다는 문제를 해결하기 위해 실시간 멀티플레이어 편집을 도입했다. 사용자의 변경 사항을 서버에 전송하고 실시간으로 다른 사용자에게 브로드캐스트함으로써 최신 버전 보장, 덮어쓰기 방지, 원격 협업과 리뷰 개선을实现했다. 구현 과정에서는 실행 취소·다시 실행, 충돌 해결, 성능과 파일 형식 개선 등 복잡한 기술적 과제를 해결해야 했다. ## 기존 저장 방식의 한계 - 초기 Figma는 문서를 브라우저로 내려받아 로컬에서 편집하고, 일정 주기마다 전체 문서를 다시 업로드했다. - 개인 사용자에게는 구현과 이해가 쉬웠고, Dropbox 같은 동기화 서비스와도 유사해 익숙한 방식이었다. - 하지만 팀 기능이 추가되면서 다음 문제가 발생했다. - 여러 사용자가 서로의 작업을 모르고 저장해 변경 사항을 덮어씀 - 저장이 완료되기 전에 공유한 링크를 열면 이전 버전이 표시됨 - 버전 기록에는 모든 저장이 남았지만, 협업 중 발생하는 혼란 자체를 막지는 못함 - 한 명씩 편집권을 넘기는 ‘baton-passing’ 방식도 검토했지만, 동시 편집만큼 단순하고 자연스럽지는 않았다. ## 실시간 멀티플레이어 모델 - 각 사용자의 변경 사항을 서버로 보내고, 서버가 이를 다른 사용자에게 실시간으로 전달한다. - 서로 다른 객체나 속성에 대한 변경은 독립적으로 처리한다. - 동일 객체의 동일 속성을 동시에 수정하면 최신 변경을 적용하는 방식으로 충돌을 해결한다. - 이 구조를 통해 사용자는 항상 최신 문서를 보고, 편집 중인 파일 버전을 따로 확인하거나 충돌을 조정할 필요가 줄어든다. - Figma는 이 기능이 협동 멀티플레이어 게임과 비슷하다는 점에서 “multiplayer”라는 이름을 붙였다. ## 멀티플레이어 실행 취소와 다시 실행 - 단일 사용자 환경에서는 실행 취소가 “내가 방금 한 작업을 되돌리는 것”으로 정의되지만, 여러 사용자가 같은 객체를 수정하면 의미가 복잡해진다. - 다른 사용자의 변경 이후 실행 취소를 수행할 때 자신의 과거 변경을 다시 덮어써서는 안 된다. - Figma는 다음 원칙을 기준으로 동작을 설계했다. - 사용자가 여러 작업을 실행 취소한다. - 중간 상태에서 무언가를 복사한다. - 다시 실행해 현재 상태로 돌아온다. - 이 과정만으로 문서 내용이 달라져서는 안 된다. - 단순히 과거 상태를 복원하는 방식이 아니라, 다른 사용자의 후속 변경을 보존하는 방향으로 redo를 설계해야 했다. ## 충돌 해결의 복잡성 - 한 객체의 여러 속성이 함께 변경되어야 하는 경우, 특정 속성 하나의 변경만으로 전체 상태를 덮어쓰지 않도록 세밀한 병합이 필요했다. - 겉보기에는 한 객체만 수정하는 작업이 실제로는 다른 객체에도 영향을 줄 수 있었다. - 이 때문에 서로 무관해 보이는 객체를 두 사용자가 동시에 편집해도 충돌이 발생할 수 있었다. - 일부 레이아웃 기능은 이러한 협업 상황에 맞게 동작 방식을 수정해야 했다. - 단순한 “최신 변경 우선”만으로는 충분하지 않고, 작업 간 의존성과 여러 객체에 걸친 부수 효과까지 고려해야 했다. ## 성능과 파일 형식 개선 - 전문 디자인 도구 수준의 실시간 협업을 위해 지속적인 측정과 성능 튜닝이 필요했다. - 기존 파일 형식은 작은 변경 사항을 효율적으로 표현하기에 적합하지 않아 파일 포맷 자체를 개편했다. - 전체 문서를 반복해서 전송하는 대신, 작은 변경 메시지를 빠르게 전달하고 처리하는 것이 중요했다. - 멀티플레이어 기능은 에디터의 핵심 구조에 영향을 주는 대규모 기술 투자였지만, 향후 협업 기능을 위한 기반이 되었다. ## 협업 경험을 단순하게 만든 UI - 멀티플레이어는 기능을 추가했지만, 기존에 사용자들이 협업을 위해 사용하던 복잡한 우회 절차를 없애 UX를 오히려 단순하게 만들었다. - 현재 문서에 참여 중인 사용자의 마우스 커서와 선택 영역을 표시한다. - 누가 문서에 있는지 확인할 수 있다. - 다른 사람이 어느 부분을 작업 중인지 알 수 있다. - 커서를 특정 객체 옆에 두어 다른 사람의 주의를 끌거나 대상을 가리킬 수 있다. - 모든 사용자는 화면 오른쪽 위에 아바타로 표시된다. - 아바타는 참여자 확인뿐 아니라 프레젠테이션에도 활용된다. - Figma는 한 명의 발표자를 강제하고 모두가 그 사람을 따라가게 하는 방식을 시험했지만, 사용자의 선택권을 제한한다고 판단했다. - 대신 다른 사용자의 아바타를 클릭해 발표를 따라가는 선택적 방식이 더 자연스럽다고 보았다. ## 실용적인 결론 실시간 협업 기능은 단순히 변경 사항을 동기화하는 문제가 아니라, 실행 취소·충돌 병합·파일 포맷·레이아웃 모델·사용자 인터페이스까지 함께 설계해야 하는 시스템 문제다. 협업 제품을 만들 때는 기존의 개인용 저장 모델에 기능을 덧붙이기보다, 처음부터 동시 편집과 사용자 간 맥락 공유를 핵심 구조로 고려하는 것이 바람직하다.

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

화장실 꿀팁 (새 탭에서 열림)

데이터독(Datadog)은 사무실 인원 증가로 인해 발생하는 화장실 대기 문제를 해결하고자 IoT 기술을 활용한 실시간 화장실 점유 모니터링 시스템을 구축했습니다. 이들은 프라이버시 보호를 위해 카메라 대신 도어락 상태를 감지하는 센서를 사용했으며, 수집된 데이터를 사내 대시보드와 연동하여 실무적인 편의성을 높였습니다. 이 프로젝트는 라즈베리 파이와 표준 유닉스 도구, 간단한 센서의 조합만으로도 일상의 물리적인 문제를 효율적으로 해결할 수 있음을 보여줍니다. **하드웨어 구성 및 현장 맞춤형 센서 적용** * 두뇌 역할을 하는 기기로 라즈베리 파이 2 모델 B를 채택하여 리눅스 환경에서 SSH와 WiFi를 통해 기기를 쉽게 관리할 수 있도록 했습니다. * 문의 형태에 따라 서로 다른 센서를 적용했습니다. 일반적인 버튼식 잠금장치에는 자석 리드 스위치(Magnetic reed switch)를, 슬라이드 방식의 칸막이 문에는 자동차 도어용 핀 스위치를 활용했습니다. * 전원 콘센트가 없는 위치나 WiFi 신호가 약한 콘크리트 벽 등 열악한 환경 조건에 맞춰 배선을 몰딩 처리하고 출력 박스 안에 기기를 매립하여 전문적인 외관을 유지했습니다. **소프트웨어 구현 및 시스템 통합** * 라즈베리 파이의 GPIO 핀을 `/sys/class/gpio/` 경로의 파일 시스템으로 제어하여 센서 상태를 읽어오는 파이썬 스크립트를 작성했습니다. * 작성된 스크립트는 `daemontools`와 `tcpserver`를 통해 안정적으로 실행되며 네트워크를 통해 상태 정보를 제공합니다. * 모든 소프트웨어 설정과 코드는 오픈소스로 공개되어 누구나 유사한 시스템을 구축할 수 있도록 지원합니다. **데이터 시각화 및 실제 활용** * 직원들은 터미널에서 `netcat(nc)` 명령어를 사용하여 즉시 화장실 가용 여부를 확인할 수 있습니다. * 맥 OS의 TextBar나 사무실 곳곳에 배치된 데이터독 대시보드 위젯에 실시간 상태를 표시하여 접근성을 극대화했습니다. * 복잡한 코드 작성보다는 적절한 센서 선정과 깔끔한 물리적 설치, 안정적인 네트워크 확보에 집중하여 실용적인 MVP(최소 기능 제품)를 완성했습니다. **결론** 임베디드 하드웨어와 유닉스 도구를 적절히 조합하면 최소한의 개발 비용으로 강력한 효과를 낼 수 있습니다. 하드웨어 프로젝트에서는 코드 작성 그 자체보다 물리적인 설치 환경에 대한 고려와 적합한 센서 선택이 성공의 핵심입니다. 이를 위해 사내의 '메이커' 문화를 장려하고 일상의 작은 불편함을 기술로 해결해보는 시도가 조직의 창의성을 높이는 데 큰 도움이 될 것입니다.