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

figma3분 읽기큐레이션 요약

피그마에서 브랜드

브랜드 템플릿은 완성된 디자인을 그대로 복제하는 것이 아니라, 마케터가 다양한 콘텐츠와 형식에 맞게 안전하게 수정할 수 있도록 설계해야 한다. Figma Buzz에서는 자동 레이아웃, 모듈화된 텍스트 레이어, 비율 고정, 명확한 레이어 이름 등을 활용해 브랜드 일관성을 지키면서도 유연한 셀프서비스 템플릿을 만들 수 있다. 이를 통해 브랜드 디자이너의 검수 부담을 줄이고 마케팅 팀의 제작 속도를 높일 수 있다. ## Figma Design에서 작업 시작 - 익숙한 **Figma Design**에서 먼저 프레임을 만든 뒤 Figma Buzz로 복사한다. - Figma Design의 컴포넌트 기능을 활용해 템플릿 구조를 설계할 수 있다. - Figma Draw의 브러시, 동적 스트로크, 프로그레시브 블러 등 표현 도구를 사용해 시각적 완성도를 높인 뒤 Buzz에서 템플릿으로 다듬는다. - 디자인 표현과 템플릿 편집 기능을 분리해, 디자이너는 창의적인 작업에 집중하고 마케터는 Buzz에서 콘텐츠를 수정할 수 있다. ## Auto Layout으로 레이아웃 유연성 확보 - Auto Layout은 반응형 템플릿의 기반이다. - 버튼, 텍스트 상자, 이미지 컨테이너 사이의 간격과 정렬을 자동으로 유지한다. - 긴 제목이나 본문이 입력되어도 주변 요소가 어긋나거나 겹치는 문제를 줄일 수 있다. - 콘텐츠 길이가 달라지는 템플릿일수록 고정 좌표보다 Auto Layout을 우선 적용하는 것이 좋다. ## 텍스트 레이어를 입력 단위별로 분리 - 서로 다른 입력값은 각각 별도의 텍스트 레이어로 만든다. - 글꼴, 크기, 스타일이 다른 내용을 하나의 레이어에 섞지 않아야 한다. - Figma Buzz의 **Bulk create** 기능은 CSV 또는 XLSX의 각 데이터 필드를 디자인 레이어에 매핑하므로, 텍스트 레이어가 모듈화되어 있어야 한다. - 여러 스타일이나 입력 필드를 하나의 레이어에 결합하면 대량 생성 시 서식이 깨지거나 수정이 어려워질 수 있다. ## 이미지와 벡터의 가로세로 비율 고정 - 이미지나 벡터를 선택한 뒤 레이아웃의 너비·높이 입력란 옆에 있는 정사각형 아이콘을 눌러 비율을 고정한다. - 정사각형 소셜 게시물을 세로형 스토리나 웹 배너로 확장할 때도 로고, 인물 사진, 일러스트가 찌그러지지 않는다. - 비율을 고정하지 않으면 이미지가 늘어나거나 눌리는 문제가 발생할 수 있다. - 다양한 출력 규격을 고려하는 템플릿에서는 이미지와 벡터의 비율 설정이 특히 중요하다. ## 레이어 이름을 명확하게 지정 - 기본적으로 텍스트 레이어 이름은 캔버스에 입력된 실제 문구로 지정된다. - Command + R 단축키나 레이어 직접 편집으로 이름을 바꿀 수 있다. - 레이어가 많다면 Figma AI를 활용해 이름을 일괄적으로 정리할 수 있다. - 템플릿 게시 후 팀원은 잠금 해제된 텍스트·이미지 레이어를 Edit Content 패널에서 폼처럼 수정하므로, 레이어 이름이 입력 목적을 명확히 설명해야 한다. - 예를 들어 `제목`, `작성자명`, `제품 이미지`, `CTA 문구`처럼 실제 입력 항목을 나타내는 이름이 적합하다. - 명확한 이름은 마케터의 편집 실수를 줄이고 템플릿 사용성을 높인다. ## 템플릿을 ‘편집 경험’ 중심으로 설계 - 일반 디자인과 템플릿 디자인의 차이는 사용자가 콘텐츠를 바꿀 것을 전제로 한다는 점이다. - 긴 문구, 다양한 이미지 비율, 여러 캠페인 데이터를 입력해도 레이아웃이 유지되어야 한다. - 디자이너가 모든 결과물을 사전 검수하기 어렵기 때문에, 템플릿 자체에 브랜드 가이드와 편집상의 안전장치를 반영해야 한다. - 잠금 설정, 자동 정렬, 명확한 레이어 구조를 조합하면 마케터가 빠르게 제작하면서도 브랜드 일관성을 유지할 수 있다. 실무에서는 먼저 Figma Design에서 구조를 만들고, Auto Layout과 레이어 분리를 적용한 뒤 Figma Buzz로 옮기는 방식이 효율적이다. 이후 실제로 긴 문구와 다른 이미지 비율을 입력해 테스트하면서 레이아웃이 깨지지 않는지 확인하는 것이 좋다.

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

3년 차 앱 개발자가 일하는 순서를 공유합니다 (새 탭에서 열림)

효율적인 협업과 코드 리뷰를 위해 개발 프로세스를 세분화하고 작업 단위를 최소화하는 것이 핵심입니다. 기획 시뮬레이션부터 PoC(Proof of Concept), 그리고 리뷰어를 배려한 PR(Pull Request) 작성까지 이어지는 체계적인 워크플로우를 통해 작업의 예측 가능성을 높이고 팀 내 신뢰를 구축할 수 있습니다. 궁극적으로 작고 명확한 단위로 일하는 습관은 본인의 히스토리 관리와 팀의 전체 생산성 향상에 기여합니다. ### 기획 리뷰와 동작 시뮬레이션 * 기획서의 목적과 작동 방식을 명확히 이해하고, 실제 코드를 작성하듯 데이터 흐름과 화면 전환, 예외 상황(Edge Case)을 머릿속으로 시뮬레이션합니다. * 이 과정에서 사용자 경험을 위한 개선 아이디어나 의문점이 생기면 기획자와 즉시 소통하여 요구 사항을 확정합니다. * 복잡한 기능은 다이어그램이나 화살표를 활용해 전체적인 구조와 데이터 흐름을 시각화하여 큰 그림을 먼저 그립니다. ### 협업 효율을 높이는 작업 가시화 * 그려둔 작업 흐름을 바탕으로 Jira 에픽(Epic)과 하위 이슈들을 생성하여 전체 작업을 눈에 보이게 쪼갭니다. * 중요도가 높거나 여러 명이 관여하는 작업의 경우, 티켓을 확정하기 전 동료들에게 개발 방향 콘셉트를 공유하여 피드백을 받습니다. * 사전 공유 단계를 거치면 추후 리뷰 단계에서 발생할 수 있는 대규모 수정을 미연에 방지하고 불필요한 논쟁을 줄일 수 있습니다. ### PoC를 통한 규모 검토와 셀프 피드백 * 본격적인 개발 전 프로토타이핑(PoC)을 진행하며 예상치 못한 문제나 누락된 시나리오가 없는지 점검합니다. * PoC 단계의 코드 양을 확인하여(저자 기준 400줄), 변경 사항이 너무 많다면 주제별로 티켓을 분리하거나 하위 작업(Sub-task)으로 세분화합니다. * "내가 이 PR을 리뷰한다면 부담스럽지 않을까?"라는 질문을 스스로 던지며 리뷰어가 이해하기 쉬운 적정 규모로 작업을 조정합니다. ### 리뷰어 중심의 구현 및 PR 작성 * 의미 있는 단위로 커밋을 쪼개고, 인터페이스 정의 후 구현체를 작성하는 등 논리적인 순서로 코드를 쌓아 올립니다. * PR 작성 시에는 목적, 원인, 영향 범위, 테스트 방법 등을 상세히 기록하며, 필요시 동작 영상을 첨부하여 리뷰어의 이해를 돕습니다. * 작고 명확한 PR은 문제가 발생했을 때 원복(Revert)이 쉽고, 리뷰어에게 '읽기 편한 코드'라는 신뢰를 주는 효과가 있습니다. 이러한 워크플로우를 정착시키면 개발 기간 산정의 정확도를 높일 수 있습니다. 특히 Jira의 시간 기록 기능을 활용해 '최초 추정 시간'과 '실제 소요 시간'을 비교하고 기록하는 습관을 들이면, 본인의 개발 속도를 객관적으로 파악하고 더욱 정교한 일정 관리가 가능해집니다. 환경에 맞춰 이 프로세스를 유연하게 적용해 보시길 권장합니다.

line원문

Nginx 설정 통합과 Loki 연동으로 설계한 유연한 멀티사이트 아키텍처 (새 탭에서 열림)

LINE NEXT는 빠르게 확장되는 글로벌 서비스 환경에 대응하기 위해 파편화된 웹 서버 인프라를 중앙 집중형 네이티브 Nginx 멀티사이트 구조로 전환했습니다. 기존의 수동 구성 방식과 Ingress Nginx의 제약을 극복하고자 Ansible 기반의 자동화와 설정 통합을 도입했으며, 이를 통해 서비스 론칭 리드 타임을 80% 이상 단축하고 고급 Nginx 기능을 유연하게 구현할 수 있는 환경을 마련했습니다. **Nginx 인프라 아키텍처의 3단계 진화** * **PMC 기반 초기 구조**: 사내 배포 도구인 PMC와 `rsync`를 이용해 서비스별로 독립된 Nginx 서버와 로드밸런서를 운영했습니다. 하지만 서버 발급부터 설정까지 최대 2주의 시간이 소요되었고, 보안망 내 SSH 포트 개방 리스크와 설정 파편화로 인한 유지보수 어려움이 있었습니다. * **Ingress Nginx 기반 구조**: 쿠버네티스 환경에서 헬름 차트를 통해 도메인과 설정을 추상화하여 배포 속도를 높였습니다. 그러나 로드밸런서 프락시 모드 사용 시 클라이언트의 실제 IP(Remote Address) 확인이 어렵고, GeoIP 등 Nginx 네이티브 모듈 활용에 제약이 발생하는 한계가 있었습니다. * **네이티브 Nginx 멀티사이트 구조(현재)**: Ingress Nginx의 설정 중심 방식과 네이티브 Nginx의 기능적 자유도를 결합한 하이브리드 모델입니다. 별도의 Ansible 배포 서버를 구축하여 공통 설정은 유지하되 서비스별로 유연한 기능을 탑재할 수 있도록 개선했습니다. **효율적인 관리와 확장성을 위한 설정 통합** * **마스터 설정과 서버 블록 분리**: Apache의 구성 방식에서 영감을 얻어 `events` 및 `http` 블록의 공통 설정(timeout, log format 등)을 마스터 설정으로 추출하고, 서비스별 가상 호스트 설정은 `sites-available` 디렉터리 내 개별 파일로 관리합니다. * **멀티사이트 아키텍처**: 단일 Nginx 인스턴스에서 다수의 도메인과 서비스를 동시에 서빙할 수 있도록 구조화하여, 신규 서비스 추가 시 설정 파일만 배포하면 즉시 반영되는 환경을 구축했습니다. * **환경별 독립 관리**: 알파, 베타, RC, 프로덕션 등 각 배포 환경에 맞는 설정을 독립적인 리포지터리 구조로 관리하여 운영 안정성을 높였습니다. **Ansible 기반의 안정적인 배포 자동화** * **자동화 프로세스**: 사용자가 타깃 서버와 환경을 지정하면 Ansible이 최신 설정을 클론하여 배포하며, `Nginx Verify`를 통한 문법 검사와 프로세스 상태 체크를 자동으로 수행합니다. * **롤링 배포(Rolling Deployment)**: 서비스 중단을 방지하기 위해 순차적으로 배포를 진행하며, 특정 단계에서 오류가 발생하면 즉시 배포를 중단하여 서비스 영향을 최소화합니다. * **고급 기능 통합**: GeoIP 모듈을 통한 국가별 트래픽 처리, Loki 연동을 통한 실시간 로그 수집, SSL 인증서 자동화 등 복잡한 요구사항을 공통 템플릿 내에서 손쉽게 관리할 수 있게 되었습니다. 다수의 도메인을 운영하고 빠른 서비스 론칭이 필요한 환경이라면, 클라우드 네이티브의 편의성과 네이티브 소프트웨어의 제어권을 모두 챙길 수 있는 'Ansible+네이티브 Nginx' 조합의 멀티사이트 구조 도입을 적극 권장합니다. 이를 통해 인프라 리드 타임 감소는 물론, 보안과 로그 수집 같은 공통 요구사항을 표준화된 방식으로 해결할 수 있습니다.

line원문

자네, 해커가 되지 않겠나? Hack Day 2025에 다녀왔습니다! (새 탭에서 열림)

LY Corporation의 'Hack Day 2025'는 19년째 이어져 온 전통 있는 사내 해커톤으로, 직무와 국적에 상관없이 구성원들이 자유롭게 아이디어를 기술로 구현하는 혁신적인 개발 문화를 상징합니다. 참가자들은 24시간 동안 몰입하여 프로토타입을 제작하며, 'Perfect the Details' 정신을 바탕으로 기술적 검증과 협업의 가치를 실현합니다. 이번 행사는 단순한 개발을 넘어 글로벌 동료들과의 네트워크를 강화하고 창의적인 시도를 장려하는 LY Corporation만의 독보적인 기술 축제로 자리매김했습니다. **자유로운 협업과 글로벌 팀 빌딩** * 과거 야후 재팬 시절부터 시작되어 19회차를 맞이한 Hack Day는 기획자, 디자이너, HR 등 사내 구성원 누구나 참여할 수 있는 열린 행사입니다. * 온/오프라인 밋업과 Zoom, Miro 등의 툴을 활용해 한국, 일본, 대만, 베트남 등 다양한 국가의 멤버들이 'Global Mixed Team'을 구성하여 협업합니다. * 하이브리드 워크 환경에 맞춰 이동 시간 및 업무 집중 시간을 보장하는 'Travel Day' 제도를 통해 원격 근무자들이 오프라인에서 밀도 있게 협업할 수 있는 환경을 제공합니다. **몰입을 돕는 환경과 해커톤의 문화** * 행사 기간 동안 오피스의 한 층을 통째로 사용하며, 팀별 독립 공간과 화이트보드, 모니터 등 개발에 필요한 인프라를 전폭적으로 지원합니다. * 1일 차 오전 9시, 전 참가자가 모여 "Hack Time!"을 외치는 개회 선언을 통해 행사의 본격적인 시작을 알리는 전통이 있습니다. * 에너지 소모가 큰 해커톤 특성을 고려하여 시간대별로 도넛, 컵라면 등 다양한 간식과 전 세계 법인에서 가져온 이색 먹거리를 무제한 제공하여 개발에만 집중할 수 있게 돕습니다. **AI 모델을 활용한 기술적 실천과 유연한 피보팅** * 실제 프로젝트 사례로 Slack 커뮤니케이션 기록과 AI 모델을 결합해 개개인의 협업 성향을 분석하는 '전투력 측정' 프로그램을 개발했습니다. * 성격 심리학 모델인 'Big 5 Personality'를 도입하여 데이터의 신뢰성을 확보하고, 이를 게임 캐릭터 능력치처럼 시각화하여 재미 요소를 더했습니다. * 개발 마지막 단계에서 포토 프린터 하드웨어 장애라는 변수가 발생하자, 실물 카드 출력 대신 파일 다운로드 방식으로 기획을 신속하게 변경하며 해커톤 특유의 유연한 문제 해결 능력을 발휘했습니다. **성과 공유를 위한 90초 발표와 부스 운영** * 3일 차에는 각 팀이 결과물을 공유하며, 90초라는 엄격한 시간 제한 속에서 핵심 기능과 데모를 선보이는 '라이브 피칭'을 진행합니다. * 발표 후에는 별도의 부스 운영 시간을 통해 심사위원과 다른 참가자들이 직접 서비스를 체험해 보고 기술적인 디테일에 대해 심도 있는 질의응답을 나눕니다. * 창의성, 기술적 완성도, 발표 전달력을 종합적으로 평가하여 시상하며, 이를 통해 사내 기술 트렌드를 공유하고 성취감을 고취합니다. Hack Day와 같은 사내 해커톤은 일상적인 업무에서 벗어나 최신 기술(AI 등)을 실험하고 동료와의 유대감을 쌓을 수 있는 최고의 기회입니다. 기술적 성장에 목마른 조직이라면, 결과물의 완벽함보다는 24시간 동안의 몰입 경험과 그 과정에서 발생하는 유쾌한 시행착오를 장려하는 문화를 구축해 보길 추천합니다.

google원문

고정밀 레이블을 통한 (새 탭에서 열림)

구글 애즈(Google Ads) 연구팀은 대규모 언어 모델(LLM) 파인튜닝에 필요한 학습 데이터의 양을 획기적으로 줄이면서도 모델의 정확도를 높일 수 있는 새로운 능동 학습(Active Learning) 기반의 큐레이션 프로세스를 개발했습니다. 이 방법론은 수천억 개의 예시 중 전문가의 주석이 가장 가치 있는 데이터를 반복적으로 식별하여, 기존 10만 개 이상의 데이터가 필요했던 작업을 500개 미만의 데이터만으로 수행하면서 전문가와의 정렬도를 최대 65% 향상시켰습니다. 이를 통해 안전 정책 변화나 새로운 유형의 부적절한 콘텐츠에 대응하는 비용을 크게 절감하고 모델의 신뢰성을 확보할 수 있게 되었습니다. **능동 학습 기반의 데이터 큐레이션 프로세스** * **초기 라벨링 및 클러스터링**: 먼저 퓨샷(Few-shot) 프롬프트가 적용된 LLM-0 모델을 사용하여 대규모 데이터셋을 '정책 위반' 또는 '정상'으로 분류합니다. 이때 발생하는 데이터 불균형과 모델의 낮은 정답률을 해결하기 위해, 각 라벨별로 데이터를 클러스터링합니다. * **경계 영역 샘플링**: 서로 다른 라벨을 가졌음에도 클러스터가 겹치는 구간, 즉 모델이 혼동을 느끼는 결정 경계(Decision Boundary) 부근에서 서로 가장 가까운 데이터 쌍을 찾아냅니다. * **정보성 및 다양성 확보**: 추출된 데이터 쌍 중에서도 전체 탐색 공간을 가장 잘 대변하는 샘플을 우선적으로 선별하여 전문가에게 전달함으로써, 적은 수의 샘플로도 높은 정보성과 다양성을 동시에 확보합니다. * **반복적 파인튜닝**: 전문가가 라벨링한 데이터를 평가용과 학습용으로 나누어 모델을 파인튜닝하며, 모델과 전문가 사이의 정렬도가 전문가들 사이의 합의 수준에 도달하거나 성능이 정체될 때까지 이 과정을 반복합니다. **객관적 성능 평가를 위한 코헨 카파(Cohen’s Kappa) 지표 활용** * 광고 안전성 검토와 같은 영역은 정답(Ground Truth)이 모호한 경우가 많아 정밀도나 재현율 같은 기존 지표 대신 '코헨 카파' 지표를 사용합니다. * 코헨 카파는 두 명의 평가자가 우연히 일치할 확률을 제외하고 얼마나 일관되게 동의하는지를 측정하며, 0.8 이상은 매우 우수한 수준, 0.4 이상은 수용 가능한 수준으로 간주합니다. * 이 지표는 데이터셋의 품질을 모니터링하는 지표인 동시에, 모델이 전문가의 판단 기준에 얼마나 근접했는지를 나타내는 핵심 성능 지표로 활용됩니다. **Gemini Nano 모델을 통한 실험 및 성능 검증** * 연구팀은 1.8B 파라미터의 Gemini Nano-1과 3.25B의 Nano-2 모델을 대상으로 복잡도가 다른 두 가지 과제에 대해 성능을 테스트했습니다. * **데이터 효율성**: 기존에 크라우드소싱을 통해 수집한 10만 개의 데이터를 학습시킨 모델보다, 단 250~400개의 전문가 큐레이션 데이터를 학습시킨 모델이 훨씬 뛰어난 성능을 보였습니다. * **성능 향상**: 복잡도가 높은 과제에서 크라우드소싱 데이터 기반 모델의 카파 지수는 0.41에 불과했으나, 큐레이션 프로세스를 거친 모델은 전문가 합의 수준인 0.78에 근접하는 성과를 거두었습니다. * 결과적으로 대규모 모델을 사용하는 실제 프로덕션 시스템에서는 데이터 규모를 최대 10,000배까지 줄이면서도 품질을 유지하거나 개선할 수 있음을 입증했습니다. 이 연구는 데이터의 '양'보다 '질'과 '선택 방식'이 LLM 성능 향상에 더 결정적임을 보여줍니다. 특히 전문가의 개입이 필요한 모호한 분류 작업에서 비용 효율적으로 고성능 모델을 구축하고자 하는 조직에게 이 능동 학습 기반 큐레이션은 매우 실용적인 가이드라인이 될 것입니다.

figma3분 읽기큐레이션 요약

리듬을 타고: 음악이 Figma

Figma는 Figma Draw에 점묘와 음영 표현에 적합한 산란 브러시(scatter brush) 10종을 추가했다. 이 브러시들은 반복되는 획의 패턴이 음악의 비트와 닮았다는 발상에서 출발해, Doo-wop·Vaporwave·Screamo 등 음악 장르의 분위기를 시각적 질감으로 구현했다. 디자이너 Rogie King은 99개의 시안을 제작한 뒤 팀 투표를 거쳐 가장 유연하고 표현력 있는 브러시를 선정했다. ## 음악을 브러시의 출발점으로 삼은 이유 - 산란 브러시는 작은 형태가 반복적으로 흩뿌려지는 방식으로 선을 만든다. - 획의 간격(gap), 흔들림(wiggle), 무작위성(jitter)을 조절할 수 있어 음악의 템포·질감·볼륨을 조정하는 과정과 비슷하다. - UX Writer Molly Rosen Marriner는 `Every Noise At Once`와 Figma 직원들의 추천을 참고해 시각적으로 연상하기 쉬운 장르를 수집했다. - Electroclash, Drone, Witch house처럼 전자음악의 반복적이고 깨진 듯한 분위기를 브러시 디자인에 적용하기 좋았고, Nu metal·Italo disco·Samba 등 다양한 장르도 후보에 포함됐다. ## 장르의 분위기를 시각적 질감으로 변환 - 먼저 점묘(stippling)처럼 사용자가 바로 활용할 만한 기본적인 산란 표현부터 설계했다. - 이후 특정 장르의 대표 음악을 듣고, 해당 장르의 패션·문화·시각적 특징을 조사하며 브러시의 성격을 구체화했다. - Screamo 브러시는 AFI의 곡과 2000년대 초반의 검은 후드티, 진한 아이라이너, 모시 핏에서 영감을 받아 거칠고 혼란스러운 느낌으로 제작됐다. - Shoegaze처럼 디자이너가 직접 이해하기 어려운 장르는 해당 음악을 잘 아는 가족이나 주변 사람에게 추천을 받아 시각적 방향을 잡았다. ## 99개 시안에서 10개 브러시로 - Rogie King은 다양한 장르를 탐색하며 총 99개의 산란 브러시 디자인을 만들었다. - 팀원들은 각 시안을 검토하고 캔버스에서의 활용도와 표현력을 기준으로 선호하는 디자인에 투표했다. - 최종 브러시는 다음 10개 장르의 이름을 갖게 됐다. - Bubblegum - Witch house - Shoegaze - Honky-tonk - Screamo - Drone - Doo-wop - Spoken word - Vaporwave - Oi! - 일부 디자인은 장르와 직관적으로 연결됐지만, 어떤 브러시는 결과물에 맞춰 새로운 장르 이름을 찾아야 할 정도로 해석의 여지가 컸다. ## 전문 지식 없이도 예술 표현을 확장 - 산란 브러시는 점묘와 음영뿐 아니라 안개, 얼룩, 반복되는 기호 등 다양한 감정과 스타일을 표현할 수 있다. - Figma Draw의 기존 스트레치 브러시가 캘리그래피나 목탄처럼 선의 형태를 강조했다면, 산란 브러시는 작업에 질감·깊이·움직임을 더한다. - 브러시 이름을 `플랫 브러시`, `과슈 브러시` 같은 전통적인 미술 용어 대신 음악 장르로 정한 것은 미술 교육을 받지 않은 사람도 부담 없이 접근하도록 하기 위한 선택이다. - 이름 자체가 브러시의 분위기를 상상하게 하며, 정식 미술 교육이나 물리적 도구 경험이 없어도 예술가처럼 창작할 수 있다는 메시지를 전달한다. Figma Draw의 새 산란 브러시는 단순한 장식 도구라기보다 반복·무작위성·질감을 조합해 작업의 분위기를 빠르게 바꾸는 표현 도구다. 점묘, 음영, 배경 질감, 감정적 효과가 필요한 작업에서 브러시 이름의 음악적 이미지를 참고해 다양한 스타일을 실험해볼 수 있다.

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

웨어러블 기기 및 일상 (새 탭에서 열림)

구글 리서치(Google Research)는 웨어러블 기기 데이터와 일반적인 혈액 검사 지표를 결합해 제2형 당뇨병의 전조 증상인 인슐린 저항성(IR)을 높은 정확도로 예측하는 머신러닝 모델을 개발했습니다. 이 연구는 침습적이고 비용이 많이 드는 기존 검사 방식을 대체할 수 있는 확장 가능한 조기 선별 도구를 제시하며, 고위험군을 대상으로 한 예방적 치료의 가능성을 열었습니다. 특히 Gemini 모델 기반의 AI 에이전트를 도입하여 사용자가 자신의 상태를 쉽게 이해하고 맞춤형 건강 관리를 실천할 수 있도록 지원하는 통합적인 접근 방식을 제안합니다. **디지털 바이오마커와 혈액 지표의 결합 (WEAR-ME 연구)** * 미국 전역의 1,165명의 참가자를 대상으로 웨어러블 기기(Fitbit, Google Pixel Watch)와 퀘스트 다이아노스틱스(Quest Diagnostics)의 혈액 검사 데이터를 수집하는 WEAR-ME 연구를 진행했습니다. * 데이터는 안정 시 심박수, 걸음 수, 수면 패턴과 같은 웨어러블 지표와 공복 혈당, 지질 패널(Lipid panel) 등 루틴한 혈액 검사 결과, 인구통계학적 정보를 포함합니다. * 심층 신경망(Deep Neural Network)을 활용해 인슐린 저항성의 표준 지표인 HOMA-IR 점수를 예측하도록 모델을 학습시켰습니다. **모델 성능 및 데이터 소스별 기여도** * 단일 데이터 소스보다 여러 스트림을 결합했을 때 예측 정확도(auROC)가 유의미하게 향상되는 결과를 보였습니다. * 웨어러블 데이터와 인구통계 정보만 사용했을 때 0.70이었던 auROC는 공복 혈당 데이터를 추가하자 0.78로 상승했습니다. * 웨어러블, 인구통계, 공복 혈당에 지질 패널을 포함한 전체 혈액 검사 데이터를 모두 결합했을 때 가장 높은 성능인 0.82(독립 검증 코호트에서 0.81)를 달성했습니다. **고위험군 대상의 효용성 및 검증** * 이 모델은 특히 비만이거나 신체 활동량이 적은 정적인 생활 방식을 가진 고위험군에서 강력한 예측 성능을 보였습니다. * 72명의 독립적인 검증 코호트에서도 일관되게 높은 성능을 유지함으로써 모델의 일반화 가능성을 입증했습니다. * 이는 고비용의 특수 인슐린 검사 없이도 일상적인 데이터와 정기 검진 결과만으로 당뇨 위험을 조기에 포착할 수 있음을 의미합니다. **Gemini 기반 인슐린 저항성 교육 에이전트** * 단순한 수치 예측을 넘어, 최신 거대언어모델(LLM)인 Gemini를 활용한 '인슐린 저항성 이해 및 교육 에이전트(IR Agent)' 프로토타입을 구축했습니다. * 이 에이전트는 사용자가 모델의 예측 결과를 쉽게 해석할 수 있도록 돕고, 인슐린 저항성에 대한 문해력을 높여줍니다. * 분석된 데이터를 바탕으로 안전하고 개인화된 건강 관리 권장 사항을 제공하여 실질적인 생활 습관 개선을 유도합니다. 이 기술은 증상이 나타나기 전 단계에서 인슐린 저항성을 발견함으로써 제2형 당뇨병으로의 진행을 늦추거나 예방할 수 있는 강력한 도구가 될 수 있습니다. 현재는 연구 및 정보 제공 목적으로 개발되었으나, 향후 의료 현장에서 데이터 기반의 정밀한 조기 진단 보조 도구로 활용될 것으로 기대됩니다.

figma4분 읽기큐레이션 요약

디자인 시스템과 AI: MCP 서버

디자인 시스템은 AI가 브랜드와 팀의 표준에 맞는 코드를 생성하도록 만드는 핵심 맥락이며, MCP 서버는 이 맥락을 디자인 도구와 개발 환경 사이에서 전달하는 연결 고리다. Figma MCP 서버는 컴포넌트, 스타일, 변수, Code Connect 정보 등을 AI 에이전트에 제공해 생성 코드의 정확도와 일관성을 높인다. 결과적으로 디자인 시스템과 AI는 서로를 강화하는 선순환을 만들며, 더 빠르면서도 품질 높은 제품 개발을 가능하게 한다. ## 디자인 시스템과 AI의 선순환 - 디자인 시스템은 디자인과 엔지니어링 팀이 확장된 환경에서도 일관된 결정을 내리도록 돕는 기반이다. - 성공적인 디자인 시스템의 요소인 문서화, 공통 언어, 재사용 패턴, 브랜드 가이드는 AI 활용에도 필수적인 맥락이 된다. - AI가 디자인 시스템을 이해하면 단순히 “작동하는 결과물”이 아니라 팀의 표준과 의도에 맞는 결과물을 생성할 수 있다. - AI가 디자인 시스템을 활용해 더 나은 코드를 만들면, 디자인 시스템의 활용도와 품질도 다시 향상되는 선순환이 형성된다. ## MCP 서버가 제공하는 역할 - Figma MCP 서버는 Figma의 디자인 정보를 IDE와 AI 에이전트에 전달한다. - AI가 활용할 수 있는 정보에는 다음이 포함된다. - 컴포넌트와 스타일 - 디자인 변수와 변수의 코드 문법 - Code Connect를 통해 연결된 실제 코드 리소스 - 디자인 요소가 코드와 연결되어 있을수록 AI는 기존 컴포넌트와 구현을 재사용할 수 있어 더욱 정확한 코드를 생성한다. - 디자인 시스템이 아직 충분히 구축되지 않은 조직에서도 토큰과 컴포넌트 구현을 시작하는 데 MCP 서버를 활용할 수 있다. ## 디자인 시스템은 디자인과 AI의 공통 언어 - LLM을 통해 아이디어를 실행으로 옮기기 쉬워질수록, 기능뿐 아니라 시각적 완성도와 브랜드 정체성이 차별화 요소가 된다. - 디자인 시스템은 다음과 같은 기반을 제공한다. - **확장 가능한 기반:** 색상, 간격, 타이포그래피 등의 토큰을 정의해 플랫폼 전반의 일관성을 유지 - **재사용 가능한 컴포넌트:** 다양한 사용 사례에 대응하면서도 단일한 기준점 유지 - **내장된 접근성:** 처음부터 포용적이고 사용 가능한 인터페이스 설계 - 디자인 시스템이 없으면 AI가 생성한 결과가 비슷하고 일반적인 UI의 조합으로 수렴할 수 있다. - 디자인 시스템은 AI를 조직의 브랜드, 품질 기준, 개발 관행에 연결하는 매개체가 된다. ## 속도와 정확도를 높이는 디자인 맥락 - 글에서 인용한 Figma AI 보고서에 따르면 개발자의 68%가 코드 작성에 AI를 사용하지만, 생성 결과를 신뢰하는 디자이너와 개발자는 32%에 그친다. - AI가 디자인 시스템 없이 코드를 생성하는 것은 팀의 온보딩을 거치지 않은 신입 개발자에게 바로 코드를 배포하게 하는 것과 비슷하다. - 디자인 시스템 맥락이 제공되면 AI는 다음을 수행할 수 있다. - 기존 컴포넌트와 패턴을 재사용해 중복과 불일치 감소 - 디자인 토큰을 자동 적용해 브랜드 및 접근성 기준 준수 - 개발자가 바로 개선할 수 있는 품질 높은 초기 코드 제공 - 디자인과 개발 사이의 오해 및 QA 시간을 줄여 피드백 주기 단축 ## Figma MCP 서버의 코드 생성 방식 - Figma 프레임을 검사하면 MCP 서버가 해당 화면의 컴포넌트, 스타일, 변수 등의 맥락을 AI 에이전트에 전달한다. - Code Connect와 변수 코드 문법이 설정되어 있으면 AI는 실제 코드베이스의 컴포넌트와 리소스를 직접 활용할 수 있다. - 연결 정보가 없더라도 MCP 서버는 색상, 스타일, 레이아웃 등 디자인 정보를 제공해 AI가 디자인에 맞는 코드를 새로 작성하도록 돕는다. - 자동 디자인 시스템 규칙 생성 기능은 코드베이스를 분석해 다음 내용을 포함한 구조화된 규칙 파일을 만들 수 있다. - 토큰 정의 - 컴포넌트 라이브러리 - 스타일 계층 구조 - 명명 규칙 - 이 규칙 파일은 AI 에이전트의 시스템 수준 지침으로 작동해, 개발자가 매번 간격·토큰·이름 규칙을 상세히 프롬프트하지 않아도 팀의 기본값을 적용하게 한다. - 주석(annotations)을 사용하면 접근성 요구사항, 상호작용 방식, 콘텐츠 관련 추가 맥락도 AI에 전달할 수 있다. ## 실용적인 적용 방향 - AI 코드 생성 전에 디자인 토큰, 컴포넌트, 변수의 이름과 구조를 정리한다. - Figma 컴포넌트와 실제 코드 컴포넌트를 Code Connect로 연결한다. - 코드베이스의 규칙과 명명 체계를 AI가 참조할 수 있는 규칙 파일로 관리한다. - 접근성, 상호작용 동작, 콘텐츠 제약은 주석으로 명시한다. - MCP 서버는 AI를 대체하는 도구라기보다, 조직의 디자인 시스템을 AI가 활용할 수 있도록 변환하는 인프라로 보는 것이 적절하다.

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

DeepPolisher를 이용한 고 (새 탭에서 열림)

구글 리서치와 UC 산타크루즈 게놈 연구소가 공동 개발한 DeepPolisher는 게놈 조립 과정에서 발생하는 염기 서열 오류를 정밀하게 수정하여 유전체 연구의 정확도를 획기적으로 높이는 딥러닝 도구입니다. 트랜스포머(Transformer) 아키텍처를 기반으로 설계된 이 기술은 기존 방식 대비 전체 오류의 50%, 특히 유전자 식별에 치명적인 삽입 및 삭제(indel) 오류를 70%까지 줄이는 성과를 거두었습니다. 이를 통해 연구자들은 질병 진단과 유전적 변이 분석의 신뢰성을 확보하고 보다 완벽에 가까운 참조 게놈(Reference Genome)을 구축할 수 있게 되었습니다. ## 게놈 조립의 과제와 인델 오류의 영향 * 유전체는 약 30억 개의 염기(A, T, G, C)로 구성되어 있어, 아주 낮은 오류율이라도 전체 게놈에서는 방대한 수의 데이터 결함으로 이어집니다. * 특히 염기가 추가되거나 빠지는 삽입 및 삭제(indel) 오류는 단백질 코딩 서열을 왜곡하여 유전자를 정확히 식별하거나 질병의 원인이 되는 변이를 찾는 과정을 방해합니다. * 유전체 지도를 완성하기 위해서는 동일한 게놈을 여러 번 시퀀싱하여 반복적으로 오류를 수정하는 과정이 필요하지만, 기존의 보정 기술로는 완벽한 정확도에 도달하는 데 한계가 있었습니다. ## 시퀀싱 기술의 발전과 DeepPolisher의 등장 배경 * 과거 Illumina의 숏리드(Short-read) 방식은 정확도는 높으나 길이가 짧아 복잡한 게놈 구조를 파악하기 어려웠고, PacBio의 롱리드(Long-read) 방식은 초기 오류율이 높다는 단점이 있었습니다. * 구글과 PacBio는 협력을 통해 오류율을 0.1% 미만으로 낮춘 DeepConsensus 기술을 개발했으나, 참조 게놈급의 고정밀 지도를 만들기 위해서는 여러 DNA 분자 정보를 통합해 남은 오류를 잡아낼 추가 도구가 필요했습니다. * DeepPolisher는 이러한 배경에서 탄생했으며, 다수의 시퀀싱 리드(reads)를 동시에 분석하여 조립된 게놈의 미세한 결함을 찾아내고 수정하는 최종 폴리싱 역할을 수행합니다. ## 트랜스포머 아키텍처와 학습 데이터 * DeepPolisher는 언어 모델에서 성능이 검증된 트랜스포머 신경망 아키텍처를 채택하여 서열 데이터 내의 복잡한 패턴을 학습합니다. * 모델 학습에는 NIST(미국 국립표준기술연구소)와 NHGRI가 정밀하게 분석하여 정확도가 99.99999%에 달하는 인간 세포주 게놈 데이터를 사용했습니다. * 입력 데이터로 시퀀싱된 염기 정보, 데이터의 품질 점수(Quality score), 그리고 각 리드가 조립된 게놈에 정렬된 형태를 활용하여 실제 유전적 변이와 기계적 노이즈를 정확히 구분해냅니다. DeepPolisher는 현재 오픈 소스로 공개되어 있으며, 휴먼 판게놈 참조 게놈(Human Pangenome Reference) 구축과 같은 최첨단 유전체 프로젝트에서 핵심적인 역할을 수행하고 있습니다. 정밀한 유전체 분석이 필요한 연구팀은 이 도구를 통해 데이터의 신뢰성을 극대화할 수 있을 것입니다.

datadog2분 읽기큐레이션 요약

실시간 시계열 스토리지

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 내용이 제시되어 있습니다. 다만 제공된 본문에는 선정 근거와 평가 세부사항보다 Datadog 제품 메뉴와 링크 목록이 대부분 포함되어 있어, 기술 블로그의 구체적인 주장이나 결론을 충분히 확인하기는 어렵습니다. ## Gartner 매직 쿼드런트에서의 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 리더로 소개됩니다. - 연결된 리소스는 Datadog의 관측성 플랫폼 역량을 강조하기 위한 홍보 자료로 보입니다. - 제공된 내용만으로는 평가 기준, 경쟁사 비교, 실행 능력(Ability to Execute), 비전 완성도(Completeness of Vision) 점수는 확인할 수 없습니다. ## Datadog의 통합 관측성 범위 제공된 제품 목록은 Datadog이 단일 모니터링 도구를 넘어 여러 운영 영역을 통합하는 플랫폼임을 보여줍니다. - **인프라 관측성** - 인프라·메트릭·컨테이너·Kubernetes 모니터링 - 네트워크, 서버리스, GPU, 스토리지 및 클라우드 비용 관리 - **애플리케이션 성능 관리** - APM, 분산 추적, Continuous Profiler - 동적 계측(Dynamic Instrumentation), 서비스 모니터링, AI 에이전트 관측성 - **로그 및 데이터 관측성** - 로그 관리, 민감 데이터 탐지, 감사 추적 - 데이터베이스, 데이터 스트림, 데이터 품질 및 작업 모니터링 - **보안** - 코드 보안, SAST, IAST, 소프트웨어 구성 분석 - 클라우드 보안, SIEM, 워크로드 보호, 애플리케이션·API 보호 - **디지털 경험** - 브라우저·모바일 RUM - 세션 리플레이, 신시틱 모니터링, 오류 추적, 제품 분석 - **소프트웨어 제공 및 서비스 관리** - CI 가시성, 테스트 최적화, 코드 커버리지, 기능 플래그 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 ## AI와 자동화 기능 - AI 에이전트 관측성, GPU 모니터링, AI 통합 기능을 제공하는 것으로 나열되어 있습니다. - Bits 계열 기능을 통해 조사, 채팅, 보안 분석, 코드 작업을 지원합니다. - MCP 서버와 에이전트 디렉터리 등 외부 도구 및 AI 에이전트와의 연계를 지원합니다. - Watchdog과 자동화 기능은 이상 탐지와 운영 대응을 자동화하는 방향을 보여줍니다. ## 제공된 글의 한계 - 실제 본문이 Datadog의 사이트 내비게이션 목록에서 중간에 잘린 형태로 제공되었습니다. - Gartner의 평가 이유, 제품별 강점과 약점, 고객 사례, 수치와 결론은 포함되어 있지 않습니다. - 따라서 현재 내용만으로는 “Datadog이 관측성 전 영역을 포괄하는 통합 플랫폼으로 평가받았다”는 수준까지만 요약할 수 있습니다. 실제 기술적 평가와 Gartner 선정 근거를 정확히 요약하려면 글 본문 전체나 원문 링크의 내용을 추가로 제공해야 합니다.

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

대규모 성능을 위해 Rust로 구축한 실시간 시계열 저장소를 다시 발전시키다 (새 탭에서 열림)

데이터독(Datadog)은 급증하는 데이터 볼륨과 고카디널리티(high-cardinality) 워크로드를 처리하기 위해 Rust 기반의 6세대 실시간 시계열 데이터베이스 엔진을 새롭게 설계했습니다. 기존 시스템의 한계를 극복하기 위해 인제스션(Ingestion), 저장, 쿼리 실행 구조를 근본적으로 재구성함으로써 수집 성능은 60배, 쿼리 속도는 최대 5배까지 향상시키는 성과를 거두었습니다. 이 글은 지난 15년간 데이터독이 카산드라에서 시작해 Rust 기반의 전용 엔진에 이르기까지 거쳐온 기술적 진화 과정과 그 과정에서 얻은 교훈을 다룹니다. ### 데이터독 시계열 저장소의 아키텍처 데이터독의 메트릭 플랫폼은 데이터의 효율적인 처리를 위해 실시간 저장소와 인덱스 데이터베이스를 분리하여 운영합니다. * **RTDB (Real-time DB):** `<timeseries_id, timestamp, value>` 형태의 원시 메트릭 데이터를 저장하고 집계하며, 최신 데이터를 실시간으로 서빙합니다. * **인덱스 데이터베이스:** 메트릭 식별자와 태그 정보를 `<timeseries_id, tags>` 형태로 관리합니다. * **데이터 흐름:** 쿼리가 발생하면 상위 서비스가 RTDB와 인덱스 노드에 각각 접속하여 결과를 가져오고, RTDB 노드 내부는 인테이크(Intake), 스토리지 엔진, 스냅샷 모듈, gRPC 쿼리 실행 계층 등으로 구성되어 유기적으로 동작합니다. ### 1세대부터 3세대: 확장성과 운영 효율의 탐색 초기 데이터독은 기성 솔루션을 활용하며 실시간 쿼리 성능과 운영 편의성을 확보하는 데 집중했습니다. * **Gen 1 (Cassandra):** 뛰어난 쓰기 확장성을 제공했으나, 알람 및 분석에 필요한 복잡한 실시간 쿼리를 지원하기 어렵고 대규모 데이터셋 반환 시 효율이 떨어지는 한계가 있었습니다. * **Gen 2 (Redis):** 빠른 읽기 속도와 운영 가시성을 제공했지만, 싱글 스레드 특성상 라이브 트래픽 처리 중 스냅샷 작업이 어려웠고 데이터 직렬화/역직렬화에 따른 CPU 및 메모리 비용이 증가했습니다. * **Gen 3 (MDBM):** `mmap`을 통해 OS 페이지 캐시를 활용하는 메모리 맵 방식의 키-값 저장소를 도입했으나, 대규모 워크로드에서 성능과 정확성 이슈가 발생하며 명시적인 I/O 관리의 필요성을 체감했습니다. ### 4세대와 5세대: 커스텀 엔진과 기능 확장 성능 한계를 돌파하기 위해 범용 DB를 벗어나 전용 스토리지 엔진을 직접 구현하기 시작했습니다. * **Gen 4 (Go 기반 B+ Tree):** Go 언어로 구현된 커스텀 B+ 트리 엔진을 도입하여 '코어당 스레드(thread-per-core)' 모델의 기초를 닦았으며, 처리량과 지연 시간 면에서 큰 진전을 이루었습니다. * **Gen 5 (RocksDB 통합):** 분포 메트릭(distribution metrics)과 DDSketch 타입을 지원하기 위해 RocksDB를 병행 도입했습니다. 하지만 기존 Go 엔진과 RocksDB가 공존하는 구조는 관리가 복잡하고 효율성이 분산되는 결과를 낳았습니다. ### 6세대: Rust 기반의 통합 엔진으로의 전환 파편화된 엔진을 통합하고 성능을 극대화하기 위해 Rust를 선택하여 차세대 시스템을 구축했습니다. * **통합 및 최적화:** 스칼라 값과 스케치 데이터를 모두 처리할 수 있는 단일 엔진을 Rust로 구축하여 언어 차원의 안정성과 고성능 I/O 제어권을 확보했습니다. * **성능 성과:** 이 구조적 변화를 통해 데이터 수집 성능을 60배 높였으며, 피크 시간대 쿼리 속도를 5배 향상시켜 전례 없는 규모의 트래픽을 효율적으로 수용하게 되었습니다. **결론 및 추천** 시스템 규모가 커짐에 따라 범용 데이터베이스나 `mmap`과 같은 추상화 계층은 오히려 성능 병목이 될 수 있습니다. 데이터독의 사례처럼 워크로드의 특성에 맞춰 I/O와 메모리 레이아웃을 직접 제어할 수 있는 전용 엔진을 구축하는 것이 기술적 부채를 해결하고 폭발적인 성장을 뒷받침하는 핵심 전략이 될 수 있습니다. 특히 Rust와 같은 시스템 프로그래밍 언어는 고성능 실시간 시스템을 재설계할 때 강력한 도구가 됩니다.

discord4분 읽기큐레이션 요약

디스코드 패치 노트: 2025년 8월 4

Discord의 2025년 8월 4일 패치 노트는 성능, 검색, 키보드·입력 처리, 미디어 다운로드, 플랫폼 연동과 다양한 UI 버그 수정을 다룬다. 특히 Android 키보드 동작, Tumblr 임베드, 스레드 검색, 대용량 계정의 성능, Mac Spotlight·Apple Handoff 지원이 주요 변경 사항이다. 일부 수정 사항은 플랫폼별로 순차 배포 중일 수 있다. ## 주요 기능 개선 - 채널별 고정 메시지 최대 개수가 **50개에서 250개**로 증가했다. - 통화 중 Desktop의 User Settings 버튼을 누르면 바로 **Voice & Video 설정**으로 이동한다. - Tumblr 콘텐츠 전반에 대한 임베드가 지원된다. - 일반 Tumblr 링크뿐 아니라 Tumblr 외부 도메인에 호스팅된 사이트도 지원한다. - 스레드 검색 기능이 추가됐다. - 스레드 내부 메시지를 검색할 수 있다. - 검색어의 `in:` 필터로 스레드 이름을 자동완성할 수 있다. ## Android 키보드 및 미디어 처리 - Android에서 이모지 키보드, 갤러리, 시스템 키보드 간 상호작용을 개선했다. - 앱을 다시 foreground로 전환할 때 키보드가 메시지를 가리던 문제를 수정했다. - 멀티태스킹 및 폴더블 기기에서 키보드가 화면을 과도하게 가리던 문제를 해결했다. - 다른 플랫폼의 임베드 이미지와 동영상 다운로드 안정성을 높였다. - 다운로드 실패가 줄어든다. - `@jpeg.bin.jpg`처럼 잘못된 확장자를 가진 파일이 생성되는 문제를 수정했다. ## 대규모 사용 계정의 성능 개선 - 극도로 많은 데이터를 사용하는 계정에서 발생하던 앱 실행 지연과 성능 저하를 개선했다. - 다음 영역을 중심으로 최적화했다. - GDM 검색 - DM 정리 - 대량의 친구·관계 작업 처리 - 일반 사용자보다 관계 수와 메시지가 매우 많은 파워 유저에게 효과가 클 것으로 보인다. ## macOS 및 Apple 플랫폼 연동 - macOS Spotlight에서 Discord 서버나 채널 이름을 검색해 해당 채널로 바로 이동할 수 있다. - Apple 기기 간 Handoff를 지원한다. - 한 기기에서 보던 채널을 다른 Mac, iPad, iPhone의 Dock이나 앱 전환기에서 이어서 열 수 있다. ## 검색 및 탐색 관련 수정 - iOS 검색 필터 제안이 선택한 필터와 무관한 결과를 표시하던 문제를 수정했다. - 예를 들어 사용자 검색 중 채널 이름이 표시되는 문제가 해결됐다. - Desktop 검색 자동완성에서 카테고리 이름 정렬이 어긋나던 문제를 수정했다. - 사용자명 자동완성이 첫 번째 일치 항목만 과도하게 고정하던 동작을 완화했다. - Desktop 알림을 클릭해도 앱으로 제대로 이동하지 않던 문제를 해결했다. - 채널 설정에서 뒤로 가기 제스처가 채팅 화면까지 지나치게 이동하던 문제를 수정했다. ## 서버·역할·권한 기능 - Role Settings의 역할 우클릭 메뉴에 **Delete Role** 기능을 추가했다. - 모바일 Role Settings에서 역할 정렬이 다시 작동한다. - 권한 없이 초대 링크를 만들려고 할 때 표시되는 안내 문구를 더 구체적으로 변경했다. - 초대 수락 버튼에 다시 초대를 수락할 사용자명이 표시된다. - 조건에 맞지 않는 짧은 서버 템플릿 이름을 입력하면 오류가 표시된다. - Server Onboarding을 닫은 뒤 다른 화면으로 이동했다 돌아와도 해제 상태가 유지된다. - Student Hubs의 생략 부호 메뉴가 다시 작동한다. - Desktop에서 대기 중인 친구 요청이 사용자 프로필에 다시 표시된다. ## UI 및 시각적 버그 수정 - Invite permission required 모달의 “Got It” 버튼 정렬을 수정했다. - Server Tag 미리보기에서 아바타 뒤에 표시되던 blurple 배경을 제거했다. - Clips 팝업, 사용자 프로필, User Settings 등의 여백과 패딩 문제를 해결했다. - Desktop 시스템 트레이 아이콘이 업데이트 후 숨겨지던 문제를 수정했다. - 채널 사이드바 구분선을 클릭하면 폭이 미세하게 늘어나던 문제를 해결했다. - 모바일 Server Onboarding의 배경 그라데이션 색상 문제를 수정했다. - 모바일의 공식 계정 `OFFICIAL` 배지와 부스트 아이콘 정렬을 조정했다. - iOS에서 이모지 상세 화면과 메시지 미리보기의 이모지가 잘리던 문제를 해결했다. - PiP 설정이 PiP 창 뒤에서 열리던 문제를 수정했다. - 서버 검색 아이콘, 서버 발견 아이콘, 역할 간격 등 다양한 정렬 문제를 보완했다. ## 메시지·언어·날짜 표시 수정 - 일본어가 채널 이름에서 올바르게 표시되지 않던 문제를 수정했다. - Burmese Unicode 텍스트가 전송 중 변형되거나 삭제되던 문제를 해결했다. - 이벤트 설명의 마스킹 링크가 모바일에서 제대로 렌더링되지 않던 문제를 수정했다. - Mod View의 날짜가 설정과 관계없이 `MM/DD/YYYY` 형식으로 표시되던 문제를 해결했다. - 일부 리액션 이모지가 빈칸으로 표시되던 일시적 문제를 수정했다. - Android와 iOS의 커스텀 상태 입력창 정렬을 개선했다. - 음성 메시지의 볼륨 슬라이더가 사라지지 않던 문제를 해결했다. 이번 업데이트는 새로운 대형 기능보다는 검색·입력·탐색 경험과 플랫폼별 안정성 개선에 초점을 맞춘 릴리스다. 특히 스레드를 자주 사용하는 사용자는 `in:` 검색을 활용하고, 대규모 서버나 많은 DM을 관리하는 사용자는 성능 개선 여부를 확인해볼 만하다.

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

디자인에 마우스가 필요

Figma는 마우스 없이도 디자인 작업을 수행할 수 있도록 키보드 접근성 기능을 대폭 강화했다. 이제 키보드만으로 캔버스 이동, 객체 삽입, 정밀한 선택이 가능하며, 스크린 리더가 작업 내용을 읽어줘 사용자가 현재 위치와 상태를 파악하기 쉬워졌다. 이는 키보드나 스크린 리더를 주로 사용하는 디자이너도 디자인 프로세스에 온전히 참여할 수 있도록 장벽을 낮추려는 업데이트다. ## 키보드만으로 이어지는 디자인 작업 - 기존에는 키보드만 사용할 경우 프레임 간 이동, 컴포넌트 선택, 새 요소 추가가 어려웠다. - 캔버스 상단에 갇히거나 잘못된 영역으로 확대·축소되는 등 작업 흐름이 끊기는 문제가 있었다. - 이번 업데이트는 기존 단축키에 더해 패닝, 삽입, 선택 기능을 보완해 디자인 스프린트, 공동 작업, 디자인 리뷰까지 마우스 없이 수행할 수 있게 한다. - 기능 개발 과정에서 키보드와 스크린 리더를 사용하는 디자이너 및 알파 사용자들의 피드백을 반영했다. ## 방향키 기반 캔버스 이동 - 방향키로 캔버스를 상하좌우로 이동할 수 있다. - `Shift` 키를 함께 사용하면 더 빠르게 이동하거나 스크롤할 수 있다. - 새 키보드 단축키를 통해 확대·축소를 세밀하게 조정할 수 있다. - 이동 도구와 손 도구에도 키보드로 접근할 수 있어 캔버스 탐색의 유연성이 높아졌다. ## 키보드로 객체 삽입과 배치 - 도형, 텍스트 등 대부분의 객체 유형을 키보드만으로 캔버스에 추가할 수 있다. - 프레임은 키보드 단축키와 십자선 형태의 안내 화면을 이용해 원하는 위치에 삽입할 수 있다. - `Enter` 키를 사용하면 화면 중앙에 텍스트를 배치할 수 있다. - 마우스 포인터 없이도 삽입 위치를 확인하고 객체를 생성할 수 있다. ## 키보드 기반 객체 선택 - 새로운 키보드 박스 선택 도구로 캔버스의 객체를 선택할 수 있다. - 방향키로 분홍색 커서를 이동해 객체 위에 놓은 뒤 `Enter`를 누르면 해당 객체를 선택한다. - 객체를 하나씩 선택하거나 선택 상자를 이용해 여러 객체를 동시에 선택할 수 있다. - 선택한 객체의 위치 조정 역시 키보드 중심으로 처리할 수 있다. ## 스크린 리더와 포용적인 디자인 - 사용자가 수행하는 작업을 스크린 리더가 읽어주므로 현재 상태와 위치를 파악하기 쉬워졌다. - 이번 기능은 단순히 Figma 사용성을 개선하는 것을 넘어, 더 많은 사람이 창작 과정에 참여하도록 하는 데 목적이 있다. - Figma는 색상 선택기의 대비 검사기를 통해 텍스트와 그래픽이 WCAG 기준을 충족하는지 확인할 수 있도록 지원한다. - 디자인에서 의미 있는 HTML 시맨틱 태그를 지정할 수 있어 스크린 리더를 지원하는 제품 설계에도 활용할 수 있다. - 접근성을 일회성 점검 항목이 아니라 지속적으로 개선해야 할 제품 개발 원칙으로 보고 있다. 마우스 사용이 어렵거나 키보드·스크린 리더를 선호하는 사용자는 Figma의 키보드 단축키와 스크린 리더 지원을 활성화해 작업 흐름을 점검해볼 만하다. 팀 차원에서도 이러한 기능을 활용하면 접근성을 고려한 디자인 협업 환경을 더 쉽게 구축할 수 있다.

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

일 평균 30억 건을 처리하는 결제 시스템의 DB를 Vitess로 교체하기 - 2. 개발 및 운영기 (새 탭에서 열림)

LINE Billing Platform 팀은 일 평균 30억 건의 요청을 처리하는 대규모 결제 시스템을 운영하기 위해 기존 Nbase-T에서 Vitess로 성공적인 데이터베이스 마이그레이션을 수행했습니다. 이 글에서는 성능 문제와 개발 편의성을 고려해 gRPC 대신 MySQL 프로토콜을 선택한 과정과 효율적인 데이터 처리를 위한 샤딩 전략을 상세히 다룹니다. 또한 VTOrc와 Prometheus를 활용한 자동 복구 및 모니터링 체계를 구축하여 분산 데이터베이스 환경에서도 높은 안정성을 확보한 실무 노하우를 공유합니다. ### 프로토콜 선정 및 개발 환경 구축 * VTGate는 gRPC와 MySQL 프로토콜을 모두 지원하지만, gRPC 사용 시 `http2: frame too large` 에러와 CPU 오버헤드가 발생하여 최종적으로 MySQL 프로토콜을 채택했습니다. * Java 클라이언트 사용 시 gRPC 프로토콜은 쿼리 결과를 객체로 변환하는 과정이 번거롭고 Vitess 측에서도 현재 MySQL 프로토콜 사용을 권장하고 있습니다. * 익숙한 MySQL 프로토콜을 사용함으로써 기존 개발 경험을 유지하면서도 Vitess의 샤딩 기능을 안정적으로 활용할 수 있게 되었습니다. ### 키스페이스 설계 및 데이터 처리 방식 * 시스템은 크게 두 개의 키스페이스로 분리되어 있습니다. '글로벌 키스페이스'는 단일 샤드로 구성되어 자동 증가(Auto-increment)하는 샤딩 키를 관리합니다. * 실제 데이터가 저장되는 '서비스 키스페이스'는 N개의 샤드로 분산되어 있으며, 코인 잔액 및 충전/사용 내역 등의 데이터를 저장합니다. * 서비스 키스페이스는 'Hash Vindex'를 사용하여 데이터를 균등하게 분산하며, 애플리케이션이 쿼리에 샤딩 키를 포함하면 VTGate가 해당 샤드를 자동으로 특정해 효율적인 요청 처리가 가능합니다. ### MySQL 호환성 및 주요 기능 활용 * 트랜잭션 격리 수준은 단일 샤드일 경우 `REPEATABLE READ`, 다중 샤드일 경우 `READ COMMITTED`가 적용됩니다. * Vitess는 MySQL 프로토콜을 지원하지만 일부 쿼리 제약 사항이 존재하므로, `unsupported_cases.json`을 통해 사전에 호환성을 확인해야 합니다. * 분산 샤드 간 트랜잭션을 지원하는 'Two-Phase Commit(2PC)' 기능과 쿼리 실행 계획을 분석하는 'VEXPLAIN/VTEXPLAIN' 등을 통해 분산 환경의 제약을 보완하고 있습니다. ### 안정적인 운영을 위한 모니터링 및 장애 복구 * 자동 복구 도구인 'VTOrc'를 도입하여 토폴로지 서버와 VTTablet의 데이터를 기반으로 문제를 자동 감지하고 복구합니다. * Prometheus를 통해 VTOrc의 지표(Metrics)를 수집하며, 장애 발생 시 이메일과 Slack으로 알람이 전달되도록 구성했습니다. * VTAdmin 웹 UI를 활용해 복구 내역을 시각적으로 확인하고, `tablet_alias`를 통해 문제가 발생한 MySQL 노드를 즉각적으로 식별하여 운영 효율성을 높였습니다. 대규모 분산 환경에서 Vitess를 도입할 때는 성능과 유지보수를 위해 gRPC보다는 MySQL 프로토콜 사용을 우선적으로 고려하는 것이 좋습니다. 또한 단일 샤드와 다중 샤드 간의 트랜잭션 격리 수준 차이 및 쿼리 제약 사항을 면밀히 검토하여 애플리케이션 로직을 설계해야 하며, VTOrc와 같은 도구를 적극 활용하여 고가용성 운영 체계를 구축하는 것이 중요합니다.

figma3분 읽기큐레이션 요약

듀오링고 메소드:

Duolingo Math 팀은 디자인과 엔지니어링을 분리해 순차적으로 넘기는 전통적인 핸드오프 대신, 처음부터 함께 아이디어를 만들고 프로토타입을 반복 검증하는 방식을 택한다. 디자이너·엔지니어·PM이 실시간으로 협업하며 실제 작동하는 경험을 바탕으로 결정하기 때문에, 새로운 제품에서도 빠르게 방향을 찾고 완성도를 높일 수 있다. 핵심은 완벽한 설계를 먼저 확정하는 것이 아니라, 만들고 보여주고 수정하는 과정을 팀 전체의 공동 작업으로 만드는 데 있다. ## 선형적인 핸드오프의 한계 - 디자인에서 엔지니어링으로 작업을 한 번에 넘기는 방식은 제품 개발이 실제로 진행되는 방식과 맞지 않는다. - 특히 Duolingo Math처럼 새로운 학습 모듈과 게임을 처음부터 만들어야 하는 팀은 기존 템플릿이나 검증된 청사진을 활용하기 어렵다. - 상호작용과 애니메이션이 많은 기능은 문서나 정적인 화면만으로 구현 난이도와 사용자 경험을 정확히 판단하기 어렵다. - 따라서 디자인과 엔지니어링이 초기 단계부터 지속적으로 연결되어야 한다. ## 초기 단계부터 함께 아이디어 구상 - 디자이너가 혼자 작업을 시작하지 않고, 디자이너·엔지니어·제품 관리자가 공유된 FigJam 파일에서 함께 아이디어를 낸다. - 방향이 정해지면 디자이너가 Figma에서 화면과 동작, 모션을 구체화한다. - 엔지니어도 이 단계에 적극 참여해 복잡한 상호작용과 애니메이션을 미리 검토한다. - 구현하기 어려운 부분은 Figma 댓글 등으로 조기에 지적해 불필요한 설계 수정을 줄인다. - Jira를 Figma와 직접 연결해 도구 간 맥락 전환을 줄이고, 디자인과 개발 작업의 흐름을 유지한다. ## 빠른 프로토타이핑과 반복 실험 - 디자인 시안에 합의한 뒤 엔지니어가 Duolingo 디자인 시스템의 컴포넌트를 활용해 초기 프로토타입을 빠르게 만든다. - 디자이너와 엔지니어가 작동하는 프로토타입을 만든 후 팀 회의에서 직접 테스트하고 피드백을 받는다. - Slack 채널에서 디자이너는 Figma 파일을, 엔지니어는 구현된 프로토타입을 공유하며 질문과 의견을 주고받는다. - 각 기능마다 다음 순환을 반복한다. - 프로토타입 제작 - 팀 테스트 - 피드백 수집 - 수정 및 재검증 - Duolingo의 “말로 설명하기보다 직접 보여준다(show don’t tell)”는 원칙에 따라, 아이디어의 타당성을 논의만 하지 않고 실제 경험으로 확인한다. - 프로토타입은 설계를 미리 완성하기 위한 결과물이 아니라, 제품이 실제로 어떻게 느껴지는지 확인하고 핵심 결정을 내리기 위한 도구다. ## 함께 다듬고 출시하기 - 지속적인 협업을 통해 개발 중에도 빠르게 의사결정을 내리고 기능을 다듬을 수 있다. - 속도가 중요할 때는 애니메이션을 단순화하는 등 기능을 핵심 경험 위주로 축소한다. - 교육용 게임의 시장 적합성을 확인할 때도 처음부터 완성도 높은 게임 두 개를 만드는 대신, 단순한 디자인과 최소한의 메커니즘을 가진 게임부터 빠르게 제작했다. - 어떤 기능을 우선할지 미리 정한 뒤, 일곱 가지 프로토타입을 반복적으로 제작하며 사용자에게 어떤 경험이 반응을 얻는지 확인했다. - 이 방식은 대규모 기능을 장기간 개발한 뒤 실패하는 위험을 낮추고, 초기 학습을 제품 방향에 빠르게 반영하게 한다. ## 실무에 적용할 때의 시사점 - 디자인 완료 후 개발을 시작하기보다, 초기 기획부터 디자이너와 엔지니어를 함께 참여시킨다. - 정적 시안보다 작동하는 작은 프로토타입을 우선 제작한다. - 기능별로 짧은 제작·테스트·수정 주기를 운영한다. - 속도와 학습이 중요한 초기 단계에서는 부가 기능보다 핵심 사용자 경험에 집중한다. - 협업 도구를 연결하고 공유 채널을 마련해 작업 맥락과 피드백을 실시간으로 유지한다.

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