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

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

요점만 말하자면:

Figma의 「Building better」는 개발자 경험(DX)이 특정 팀이나 도구만의 문제가 아니라, 조직 전체의 문화·원칙·프로세스에서 결정된다고 주장한다. 글은 VS Code, Atlassian, Linear 등의 사례를 통해 개발자의 몰입을 보호하고, 개발자 만족을 측정하며, 명확한 제품 철학과 디자인·개발 협업 체계를 구축하는 방법을 소개한다. 결론적으로 더 나은 개발 환경은 도구 도입보다 조직 차원의 일관된 운영 방식에서 출발한다. ## 개발자의 몰입을 지키는 ‘이너 루프’ VS Code는 개발자가 코드 작성에 집중하는 시간을 “이너 루프”, 버그 관리·티켓 응답·회의 같은 협업 활동을 “아우터 루프”로 구분한다. - 생산성을 가장 크게 떨어뜨리는 요인은 작업 자체보다 잦은 컨텍스트 스위칭이다. - 코드 편집과 디버깅처럼 집중력이 필요한 작업을 보호해야 한다. - 협업 활동을 완전히 제거하기보다, 이너 루프와 아우터 루프 사이의 전환 횟수를 줄이는 것이 핵심이다. - 개발 도구는 개발자가 여러 업무 시스템을 오가며 흐름을 잃지 않도록 지원해야 한다. ## 개발자 경험을 넘어선 ‘개발자 기쁨’ Atlassian은 개발자 경험을 넘어 “developer joy”를 조직의 중요한 기준으로 삼는다. - 개발자 기쁨은 단순한 편의성이나 만족도보다, 좋은 소프트웨어를 만드는 과정의 완성도와 장인정신에 초점을 둔다. - 이를 추상적인 구호로 남기지 않고 조직의 가치와 업무 방식에 반영한다. - 개발자 경험 개선이 생산성, 업무 만족도, 비즈니스 성과에 어떤 영향을 주는지 측정하려 한다. - 특정 팀의 활동에 그치지 않고 조직 전체로 확장하려면 공통된 원칙과 운영 체계가 필요하다. ## 강한 의견을 반영한 소프트웨어 Linear는 모든 사용자의 요구를 수용하기보다, 제품이 지향하는 명확한 관점을 바탕으로 기본적인 업무 흐름을 설계한다. - 좋은 도구는 기능을 무작정 늘리기보다 사용자가 따라갈 수 있는 강한 기본값을 제공한다. - 제품의 철학은 인터페이스뿐 아니라 우선순위 설정, 협업 방식, 내부 프로세스에도 반영된다. - 일반적인 관행과 다르더라도 일관된 원칙이 사용자 경험을 단순하고 예측 가능하게 만들 수 있다. - 다만 독단적인 설계가 아니라, 어떤 문제를 해결하려는지에 대한 분명한 판단이 전제되어야 한다. ## Dev Mode 도입에서 얻은 10가지 교훈 Decathlon의 엔지니어링 매니저는 1년간 Dev Mode를 디자인 시스템과 개발 workflow에 적용한 경험을 공유한다. - 처음부터 조직 전체에 도입하기보다 작은 범위에서 시작하는 것이 좋다. - 빠르게 효과를 확인할 수 있는 작은 개선부터 추진한다. - 디자인과 개발 사이의 전달 과정에서 반복되는 혼선을 찾아 해결한다. - Dev Mode를 단순한 기능 도입이 아니라 디자인 시스템 운영 방식의 일부로 활용한다. - 실제 사용 경험을 바탕으로 팀에 맞는 규칙과 협업 방식을 점진적으로 정립한다. ## 대규모 제품의 복잡성 관리 Crunchyroll은 웹, 모바일, 게임 콘솔 등 15개 플랫폼과 12개 언어를 지원하기 위해 Universal Design System을 활용한다. - 플랫폼과 언어가 늘어날수록 디자인 일관성과 개발 전달 과정이 복잡해진다. - 공통 컴포넌트와 디자인 시스템을 통해 여러 접점에서 동일한 사용자 경험을 유지한다. - Dev Mode는 디자인 사양을 확인하고 개발에 필요한 정보를 전달하는 과정을 간소화한다. - 디자인 시스템의 채택률을 높이려면 문서화뿐 아니라 실제 workflow 안에서 쉽게 사용할 수 있어야 한다. - 복잡성을 줄이는 핵심은 개별 화면을 관리하는 것이 아니라 재사용 가능한 시스템을 구축하는 데 있다. ## 디자인과 코드 사이의 연결 글의 ‘Rabbit hole’에서는 Figma의 Code Connect와 Simple Design System 사례를 통해 디자인과 실제 코드의 연결을 다룬다. - Simple Design System은 실제 코드 기반을 갖춘 UI 키트로, 디자인 결과물과 구현 결과 사이의 간극을 줄이는 것을 목표로 한다. - 디자인 시스템은 시각적 컴포넌트 모음에 그치지 않고 코드에서 어떻게 사용되는지까지 연결되어야 한다. - Code Connect 같은 접근은 디자인 컴포넌트와 실제 코드 컴포넌트의 관계를 명확히 하는 데 도움을 준다. - 디자인과 개발의 연결은 단순히 협업 편의성을 높이는 것뿐 아니라 구현 품질과 일관성을 관리하는 수단이기도 하다. 조직은 새로운 도구를 도입하는 데 그치지 말고, 집중 업무 보호, 명확한 제품 원칙, 측정 가능한 개발자 만족도, 디자인 시스템과 코드의 연결을 함께 설계해야 한다. 작은 workflow 개선부터 시작해 실제 효과를 검증하고, 검증된 방식을 조직 전체의 문화와 프로세스로 확장하는 접근이 현실적이다.

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

Figma디자인 시스템dev-modecode-connect+2

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

피그마 AI 검색의

Figma의 AI 검색은 텍스트·이미지·레이어 선택을 동일한 임베딩 공간에서 비교해 디자인과 컴포넌트를 의미적으로 찾도록 구축됐다. 핵심 기반은 CLIP 멀티모달 임베딩 모델과 벡터 검색 인덱스이며, 수십억 개의 임베딩을 생성·관리하면서도 비용과 처리량을 고려한 인프라 설계가 필요했다. 특히 파일 내부의 검색 가능한 프레임을 식별하고 썸네일과 임베딩을 비동기적으로 생성하는 과정이 주요 기술 과제였다. ## AI 검색이 해결하는 문제 - **디자인 검색** - 조직이나 팀 전체의 Figma 파일에 포함된 프레임을 검색한다. - 파일명이나 레이어 이름이 없어도 프레임의 시각적 내용으로 찾을 수 있다. - 텍스트 설명, 스크린샷, 선택한 Figma 레이어를 검색 입력으로 사용할 수 있다. - 선택 영역은 새 스크린샷으로 렌더링한 뒤 이미지 검색과 같은 경로로 처리한다. - **컴포넌트 검색** - 기존 Assets 검색의 엄격한 텍스트 일치 방식을 의미 기반 검색으로 확장했다. - 예를 들어 이름이 😀인 컴포넌트를 “smiley”, “happy”, “face”, “grin” 같은 표현으로도 찾을 수 있다. - 컴포넌트 이름과 설명에 검색 키워드를 일일이 추가하는 SEO 작업이 필요 없다. - 컴포넌트 역시 스크린샷이나 레이어 선택을 이용해 시각적으로 검색할 수 있다. ## CLIP 기반 멀티모달 임베딩 - 임베딩 모델은 텍스트나 이미지를 의미를 보존한 숫자 배열로 변환한다. - Figma는 현재 오픈소스 **CLIP** 모델을 사용한다. - CLIP은 이미지와 텍스트를 같은 벡터 공간에 표현한다. - 고양이 이미지의 임베딩과 `"cat"`이라는 텍스트의 임베딩이 서로 가까운 위치에 놓인다. - 따라서 이미지와 텍스트를 서로 다른 입력 방식으로 검색해도 의미적으로 비교할 수 있다. - 모델은 고객의 비공개 Figma 파일이나 고객 데이터를 학습에 사용하지 않았다. - 공개된 무료 Community 파일의 UI 이미지로 미세 조정했다. - 초기에는 선택 영역을 JSON 같은 텍스트 표현으로 변환해 임베딩하는 방식도 검토했다. - 그러나 이미지로 임베딩을 생성하는 방식이 더 나은 검색 결과를 제공했다. - 스크린샷 검색과 동일한 처리 경로를 사용할 수 있다는 장점도 있었다. ## 벡터 검색 처리 방식 - 검색 대상 콘텐츠마다 임베딩을 생성해 벡터 검색 인덱스에 저장한다. - 예: 디자인 시스템의 모든 컴포넌트와 각 컴포넌트의 임베딩 - 사용자가 검색하면 입력을 먼저 임베딩으로 변환한다. - 텍스트 검색은 입력 문장을 임베딩 모델에 전달한다. - 스크린샷 검색은 이미지에서 임베딩을 생성한다. - 레이어 선택 검색은 선택 영역을 스크린샷으로 만든 뒤 임베딩한다. - 생성된 쿼리 임베딩과 인덱스의 임베딩 사이 거리를 계산해 가장 가까운 항목을 반환한다. - 전통적인 문자열 검색처럼 검색어와 색인 항목을 직접 비교하는 것이 아니라, 고차원 벡터 공간에서 최근접 이웃을 찾는다. ## 검색 가능한 프레임 식별 - Figma 파일 깊숙한 곳에 있는 모든 검색 대상 프레임을 찾아야 한다. - 각 프레임에 대해 다음 작업을 수행한다. - Figma 레이어를 렌더링해 썸네일을 생성한다. - 썸네일에서 임베딩을 생성한다. - 메타데이터와 임베딩을 검색 인덱스에 기록한다. - 게시되지 않은 프레임은 일반적인 방식으로 쉽게 열거할 수 없다는 문제가 있다. - 이를 해결하기 위해 비동기 작업에서 서버 측 C++ Figma 에디터를 헤드리스 방식으로 실행한다. - 서버에서 C++ 에디터를 실행하기 위해 별도의 샌드박싱 기술을 사용한다. ## 저장소와 인프라 선택 - Figma는 자체 RDS 클러스터도 운영하지만, AI 검색에는 DynamoDB를 사용한다. - AI 검색의 저장 요구사항이 복잡한 관계형 트랜잭션보다 단순한 키-값 저장에 가깝기 때문이다. - 주요 요구사항은 다음과 같다. - 임베딩과 관련 메타데이터의 대량 저장 - 높은 쓰기 처리량 - 검색 시 빠른 읽기 - 대규모 인덱스 생성 및 갱신 처리 - 전체 시스템은 수십억 개의 임베딩을 생성하고 색인해야 하므로 검색 품질뿐 아니라 생성 비용과 운영 비용도 중요한 설계 기준이 된다. Figma의 접근 방식은 이미지와 텍스트를 하나의 의미 공간에 매핑하고, 프레임·컴포넌트별 임베딩을 사전에 구축하는 것이다. 유사한 기능을 구현한다면 먼저 검색 대상을 안정적으로 열거하고, 렌더링·임베딩 생성·색인 갱신을 비동기 파이프라인으로 분리하며, 모델 학습 데이터와 고객 데이터의 경계를 명확히 관리하는 것이 중요하다.

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

멀티모달 AIvector-dbc++embeddings+2

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

Figma에서의 속도 탐

Figma는 검색 지연의 원인을 OpenSearch 자체의 검색 속도보다 쿼리 전후 처리와 잘못된 모니터링 지표에서 발견했다. OpenSearch가 보고한 평균 8ms는 전체 검색 시간이 아니라 개별 샤드 쿼리 시간에 불과했으며, 실제 애플리케이션 호출은 평균 150ms에 달했다. 조사 결과 권한 필터를 만드는 사전 처리와 검색 결과를 검증하는 사후 처리가 전체 시간의 대부분을 차지했고, 이를 개선하는 것이 확장 가능한 검색 기반을 마련하는 핵심이었다. ## OpenSearch 마이그레이션과 검색 성능 문제 - Figma는 2023년 말까지 오래된 Elasticsearch 버전을 사용하다가 AWS 관리형 OpenSearch로 이전하기 시작했다. - OpenSearch는 Elasticsearch의 라이선스 변경 이후 분기된 프로젝트로, 기본적으로 호환되지만 3년간 세부적인 차이가 누적되어 마이그레이션이 예상보다 어려웠다. - 사용자와 데이터가 증가하면서 검색 시스템이 원하는 콘텐츠를 안정적으로 찾기 어려워졌고, 장기적인 확장을 위한 검색 인프라 재정비가 필요해졌다. ## 잘못 해석한 8ms 지표 - Datadog의 OpenSearch 연동에서는 평균 검색 시간이 약 8ms로 나타났다. - 하지만 Figma 검색 API의 p99 지연 시간은 거의 1초였고, 애플리케이션에서 OpenSearch API를 호출하는 데 걸린 시간은 다음과 같았다. - 평균 약 150ms - p99 약 200~400ms - 최소 지연 시간도 40ms 이상 - OpenSearch와 애플리케이션이 같은 AWS 가용 영역에서 실행되고 있었기 때문에 네트워크 지연만으로는 이 차이를 설명할 수 없었다. - 원인은 8ms가 전체 검색 시간이 아니라 **각 샤드에서 실행된 개별 쿼리의 평균 시간**이었기 때문이다. ## OpenSearch의 쿼리 및 fetch 단계 - 검색 요청은 먼저 coordinator 노드에 전달된다. - coordinator 노드는 인덱스의 각 샤드가 있는 worker 노드에 쿼리를 보낸다. - 이 과정이 OpenSearch의 **query 단계**다. - coordinator는 각 샤드의 결과를 수집하고 정렬한 뒤, 상위 결과에 대한 상세 정보를 다시 요청한다. - 이 후속 과정이 **fetch 단계**이며, 최종 결과가 클라이언트에 반환된다. - Figma의 초기 구성에서는 사용자 검색 하나가 최대 500개의 샤드 쿼리를 발생시킬 수 있었다. - 샤드 쿼리 대부분은 병렬 실행되지만 모두 동시에 처리되는 것은 아니므로, 개별 샤드 시간과 전체 검색 시간 사이에 큰 차이가 발생했다. ## 전체 검색 시간을 측정하도록 계측 개선 - Figma는 검색 코드의 주요 구간에 메트릭과 트레이스를 추가했다. - 조사 결과 OpenSearch가 보고하는 지표와 실제 API 호출 시간 사이에 큰 불일치가 있음을 확인했다. - OpenSearch의 기본 메트릭과 로그에는 coordinator 관점의 전체 쿼리 시간이 포함되지 않았다. - 전체 검색 시간은 검색 API 응답의 `took` 필드에만 제공됐다. - Figma는 모든 검색 응답에서 `took` 값을 추출해 모니터링 시스템에 추가했고, 이를 통해 실제 백엔드 검색 지연을 보다 정확하게 파악했다. ## 병목은 OpenSearch 검색 자체가 아니었다 - 실제로 OpenSearch에서 검색을 기다리는 시간은 전체 쿼리 API 시간의 30% 미만이었다. - 나머지 시간은 검색 전후의 애플리케이션 처리에 사용됐다. - **사전 처리** - 사용자가 접근할 수 있는 파일 관련 정보를 조회한다. - 접근 권한이 없는 파일을 대부분 제외하도록 OpenSearch 필터 절을 생성한다. - **사후 처리** - OpenSearch가 반환한 각 파일 결과에 대해 사용자의 실제 접근 권한을 다시 확인한다. - 권한 검증을 통해 사용자가 볼 수 없는 파일이 검색 결과에 포함되지 않도록 보장한다. - 특히 사후 처리가 매우 느렸으며, Figma는 권한 시스템과 협력해 이 부분을 개선하기 시작했다. 검색 성능을 개선하려면 검색 엔진이 표시하는 단일 지표만 믿지 말고, coordinator부터 애플리케이션의 사전·사후 처리까지 전체 요청 경로를 측정해야 한다. Figma 사례처럼 샤드별 지연 시간보다 실제 사용자 요청의 전체 지연 시간을 기준으로 병목을 찾아야 하며, 권한 필터 생성과 결과 검증도 검색 성능의 핵심 구성 요소로 다뤄야 한다.

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

옵저버빌리티AWSelasticsearchopensearch+2

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

Figma on Figma:

Figma UI3는 작업물을 화면의 중심에 두고 사용자의 작업 흐름을 방해하지 않는 것을 목표로 2년 넘게 설계·개선된 인터페이스다. 초기에는 탐색·속성 패널을 플로팅 방식으로 바꿨지만, 실제 사용 데이터와 피드백을 통해 캔버스 공간과 작업 속도를 해친다는 점을 확인하고 고정 패널로 되돌렸다. Figma는 명확한 미래 비전을 세우되, 사용자 피드백과 성능 지표에 따라 과감하게 설계를 수정하는 접근을 강조한다. ## 작업 중심 인터페이스를 위한 UI3 - UI3의 핵심 목표는 캔버스와 디자이너의 작업을 중심에 두고 불필요한 방해 요소를 줄이는 것이다. - 팀은 2년 이상 다양한 인터페이스를 반복적으로 실험했으며, 출시 이후에도 기존의 핵심 설계 결정을 되돌렸다. - “완성도와 작업 흐름”처럼 직접 측정하기 어려운 요소는 정량 지표만으로 판단하기 어렵기 때문에 사용자 의견을 수집하고 신중하게 해석했다. - UI3는 2024년 10월 10일 모든 사용자에게 제공될 예정이었다. ## 도킹 패널과 플로팅 패널 실험 - 탐색 패널과 속성 패널은 Figma 인터페이스의 핵심 요소였기 때문에 다양한 실험이 진행됐다. - 마우스를 올릴 때만 나타나는 패널 - 캔버스 위에 떠 있는 패널 - 제품 전반에 일관되게 적용되는 플로팅 UI - 최종적으로 초기 UI3에서는 패널을 플로팅 방식으로 제공했다. - 플로팅 패널의 장점은 단순하고 친근한 인터페이스를 만들며, 제품 생태계 전체에 일관된 경험을 제공할 수 있다는 점이었다. - 그러나 오픈 베타 이후 실제 사용 데이터를 분석한 결과 다음 문제가 드러났다. - 작은 화면에서 캔버스 공간을 과도하게 차지함 - 디자인이 패널 뒤에서 일부 가려져 시각적으로 산만함 - 눈금자가 디자인에서 멀어져 활용성이 떨어짐 - 장시간 Figma를 사용하는 사용자들의 작업 속도를 저하시킴 - Figma는 “속도는 기능”이라는 판단 아래, 정식 출시에서는 탐색·속성 패널을 다시 고정했다. - 다만 패널 크기는 조절할 수 있도록 해 사용자가 작업 환경에 맞게 유연하게 배치할 수 있게 했다. - 플로팅 UI 자체가 완전히 사라지는 것은 아니다. - Figma Design의 Minimize UI 상태 - Figma Slides의 그리드 보기 - FigJam의 기본 인터페이스 - 모든 Figma 제품의 하단 툴바 에서는 플로팅 요소가 유지된다. ## Minimize UI와 작업 집중 - 기존의 Hide UI 기능은 작업물을 전면에 보여주지만, UI를 숨기거나 다시 표시하는 방식이 다소 극단적이고 제한적이었다. - UI3의 Minimize UI는 측면 패널을 접어 캔버스를 넓히면서도 필요할 때 도구에 쉽게 접근할 수 있도록 설계됐다. - 특히 다음 환경에서 유용하도록 개선됐다. - 작은 화면 - 분할 화면 - 원격·하이브리드 근무 환경 - Figma는 UI가 항상 많이 표시되어야 한다는 전제 대신, “작업이 캔버스의 중심이어야 한다”는 원칙을 장기적인 기준으로 삼았다. ## 확장성을 고려한 정보 구조 - UI3에서는 기능을 단순히 재배치하는 데 그치지 않고, 앞으로 추가될 기능을 수용할 수 있는 구조를 만들려 했다. - 기존 인터페이스는 새로운 기능을 넣을 때마다 화면에 요소를 억지로 끼워 넣는 방식에 가까웠다. - 새 탐색 패널은 다음과 같은 논리적 순서로 정보를 배치한다. - 파일 이름 - 브랜치 이름 - 프로젝트 이름 - 페이지 - 레이어 - 향후 파일 이동이나 탐색 방식이 추가되더라도 기존 구조를 크게 훼손하지 않고 확장할 수 있도록 설계했다. - 이는 현재의 편의성뿐 아니라 아직 구현되지 않은 미래의 기능까지 고려한 정보 구조다. ## 변화하는 인터페이스 관습과 블렌드 모드 - Figma는 UI3에서 과거 인터페이스의 일부 관습을 그대로 유지하기보다, 현재 사용자가 익숙하게 받아들이는 패턴을 재검토했다. - 예를 들어 다음과 같은 방식은 기술적으로는 다소 비직관적일 수 있지만 널리 정착됐다. - Shift 키를 사용하는 명령 단축키 - 화면에 거의 드러나지 않는 스크롤바 - 블렌드 모드 역시 과거의 사용 방식과 새로운 인터페이스 관습 사이의 균형을 맞추는 대상으로 다뤄졌다. - 제공된 글 내용은 블렌드 모드 섹션 초반에서 끝나므로, 구체적인 변경 사항은 확인할 수 없다. UI3의 가장 실용적인 교훈은 큰 폭의 redesign도 가설로 시작하되 실제 사용성 검증을 거쳐 수정해야 한다는 점이다. 새로운 UI를 도입할 때는 시각적 새로움보다 캔버스 공간, 작업 속도, 화면 크기별 사용성, 장시간 사용자의 효율을 우선적으로 측정하는 것이 바람직하다.

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

Figma디자인 시스템사용자 경험사용자 인터페이스+2

microsoft·2024년 9월 25일원문

일반적인 주석이 달린 (새 탭에서 열림)

마이크로소프트는 보안 토큰의 탐지 효율을 높이고 오탐을 최소화하기 위해 '식별 가능한(Identifiable)' 키 형식인 CASK(Common Annotated Security Standard) 표준을 공개했습니다. 이 표준은 고정된 시그니처와 체크섬 기술을 활용하여 소스 코드 내 보안 키를 즉각적으로 식별하고 차단할 수 있도록 설계되었으며, 엔지니어의 생산성을 저해하지 않으면서도 시스템의 보안 태세를 강화하는 것을 목표로 합니다. 마이크로소프트는 이 표준을 오픈소스로 공개하여 서비스 제공자들이 공통된 규격의 보안 키를 생성하고 생태계 전반의 보안 수준을 높일 것을 권장하고 있습니다. ### CASK 표준의 기술적 특징 * **특수 문자 배제**: CASK 키는 오직 알파벳과 숫자로만 구성된 Base62 문자열을 사용합니다. 이를 통해 별도의 이스케이프(Escaping)나 인코딩 과정 없이 모든 프로그래밍 환경과 컨텍스트에서 안전하게 전송 및 처리가 가능합니다. * **강력한 엔트로피 제공**: 각 키는 약 310비트 수준의 엔트로피를 보유한 52자의 무작위 데이터를 포함합니다. 이는 현재의 컴퓨팅 환경은 물론, 향후 양자 컴퓨팅 시대의 무차별 대입 공격(Brute-forcing)에도 대응할 수 있는 충분한 보안 강도입니다. * **이중 시그니처 구조**: 표준 자체를 나타내는 공통 시그니처인 `JQQJ`와 서비스 제공자를 식별하는 고정 시그니처(예: Azure DevOps의 경우 `AZDO`)를 함께 사용합니다. 이를 통해 스캐닝 도구는 단 한 번의 규칙 검사만으로도 키의 존재 여부와 출처를 매우 빠르고 정확하게 판별할 수 있습니다. ### 보안 운영 및 관리 최적화 * **생성 타임스탬프 내장**: 모든 CASK 키에는 생성된 월과 연도 정보가 포함되어 있습니다. 이 정보는 보안 사고 발생 시 대응 우선순위를 정하거나, 조직의 정기적인 키 순환(Rotation) 정책을 자동으로 강제하는 데 유용하게 활용됩니다. * **전용 테스트 키 정의**: 실제 보안 키를 외부에 노출하지 않고도 시스템 기능을 테스트할 수 있도록 예약된 테스트용 키 세트를 제공합니다. 개발자는 이를 통해 보안 제어 장치가 제대로 작동하는지 안전하게 검증할 수 있습니다. * **플랫폼별 확장성**: 표준 규격 내에 서비스 제공자가 자체적인 메타데이터를 인코딩할 수 있는 예약 공간을 유지합니다. 마이크로소프트는 이를 활용해 Azure 서비스에 특화된 추가 정보를 포함하고 있으며, 다른 제공자들도 이를 유연하게 확장할 수 있습니다. 보안 사고의 주요 원인인 비밀번호 및 키 유출을 근본적으로 방지하기 위해 서비스 제공자들은 CASK 표준 도입을 적극적으로 검토해야 합니다. 식별 가능한 키 형식을 채택하면 보안 스캔 도구의 비용을 낮추고 개발 워크플로우 내에서 실시간 차단이 가능해져 전체 소프트웨어 공급망의 안전성을 크게 향상시킬 수 있습니다.

cybersecuritysecret-scanninggithub-advanced-securityazure-devops+4

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

디자이너를 위한 더 나은

Figma는 디자이너가 아이디어를 실제 화면으로 옮기는 초기 단계를 돕기 위해 AI 기능인 **First Draft**를 재출시했다. 이 기능은 사용자의 프롬프트와 Figma 디자인 시스템을 바탕으로 여러 컴포넌트를 조합해 초안을 만들며, 완성품보다 탐색과 논의의 출발점을 제공하는 데 초점을 둔다. 기존 Make Designs는 다른 앱과 지나치게 유사한 결과가 생성되는 문제로 중단됐지만, 디자인 라이브러리와 생성 방식을 개선해 제한적 베타로 돌아왔다. ## 아이디어를 초안으로 옮기는 장벽 - 좋은 디자인 아이디어가 있어도 첫 화면을 만들기까지 반복적인 작업과 여러 장애물이 발생한다. - 초기 초안은 완성도 높은 결과물보다 다음 목적에 중요하다. - 아이디어를 빠르게 시각화 - 팀 논의 시작 - 다양한 디자인 방향 탐색 - 제품 아이디어를 실제 작업으로 발전 - Figma는 AI가 사용자의 머릿속 아이디어를 새로운 방식으로 표현하고, 초기 탐색 과정을 매끄럽게 만들 수 있다고 본다. ## First Draft의 작동 방식 - First Draft는 고객 콘텐츠를 학습 데이터로 사용하지 않는다. - OpenAI의 GPT-4, Amazon Titan과 같은 범용 AI 모델을 활용한다. - 생성 과정은 세 요소로 구성된다. - **모델**: 결과를 생성하는 AI 모델 - **컨텍스트**: Figma가 제공하는 모바일·데스크톱 디자인 시스템, 컴포넌트, 조합 사례 - **프롬프트**: 사용자가 입력하는 디자인 목표와 요구사항 - AI는 프롬프트를 해석한 뒤 적절한 디자인 시스템 컴포넌트를 선택하고 배치·수정해 초기 디자인을 만든다. - 따라서 빈 캔버스에서 시작하는 대신, 사용자가 편집하고 발전시킬 수 있는 출발점을 제공한다. ## Make Designs의 문제와 재출시 - Figma는 Config 2024에서 Make Designs를 포함한 10개 이상의 Figma AI 기능을 제한적 베타로 공개했다. - Make Designs는 간단한 프롬프트만으로 기본 디자인 초안을 생성하는 기능이었다. - 그러나 내부 디자인 시스템의 문제로 인해 생성 결과가 기존 앱과 지나치게 비슷해지는 문제가 발견됐다. - Figma는 기능을 일시적으로 비활성화하고 분석, 반복 개선, 테스트를 진행했다. - 재출시하면서 이름을 **First Draft**로 변경했다. - 완성된 디자인을 만드는 기능이 아니라 - 디자이너가 아이디어를 시작할 수 있는 “출발점”이라는 목적을 더 정확히 표현하기 위해서다. ## 네 가지 디자인 라이브러리 - 사용자는 필요에 따라 네 가지 라이브러리 중 하나를 선택할 수 있다. - 라이브러리는 낮은 충실도의 와이어프레임부터 시각적으로 구체적인 사이트·앱 디자인까지 범위가 다양하다. - 주요 활용 방식은 다음과 같다. - **로파이 와이어프레임**: 특정 스타일에 덜 구애받고 구조와 흐름을 탐색 - **하이파이 라이브러리**: 더 풍부한 시각 표현과 구체적인 UI 패턴 실험 - 이는 기존 파일이나 컴포넌트를 정확히 찾는 **Visual Search**와 구별된다. - Visual Search: 이미 존재하는 디자인 자산 검색 - First Draft: 아직 정해지지 않은 아이디어와 선택지 탐색 ## 향후 확장 방향 - Figma는 조직이 자체 디자인 라이브러리를 First Draft에 연결할 수 있도록 확장할 계획이다. - 향후 팀은 수백 개의 컴포넌트를 직접 찾지 않고도 회사 고유의 디자인 언어를 반영한 초안을 만들 수 있다. - Google Material 3 같은 표준 디자인 시스템을 활용한 개념 증명도 진행 중이다. - 코드와 연결된 강력한 컴포넌트를 사용하면 디자이너와 개발자가 동일한 디자인 시스템을 기반으로 더 긴밀하게 반복 작업을 할 수 있다. - 궁극적으로 First Draft는 기존 디자인 도구를 대체하기보다 다음을 지원하는 확장 도구로 제시된다. - 정확한 시작점 찾기 - 더 넓은 디자인 선택지 탐색 - 팀의 디자인 언어를 반영한 빠른 반복 ## 현재 상태 - 글의 편집자 주에 따르면 First Draft는 현재 독립 기능이 아니라 **Figma 디자인 에이전트**의 기능으로 통합됐다. - 디자인 에이전트는 기존 First Draft 기능에 다음 능력을 더한다. - 프롬프트 재입력 - 더 깊은 반복 작업 - 여러 요소의 일괄 수정 - 화면 흐름과 디자인에 대한 실시간 피드백 실무에서는 AI가 만든 초안을 최종 디자인으로 받아들이기보다, 빠른 구조 탐색과 팀 논의를 위한 출발점으로 활용하는 것이 적절하다. 특히 조직의 디자인 시스템을 연결할 수 있다면 브랜드 일관성을 유지하면서 초기 아이디어를 더 빠르게 검증할 수 있다.

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

디자인 시스템사용자 경험생성형 AIfigma-ai+2

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

비용, 품질, 안전성을 고려

Datadog은 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다고 홍보한다. 제공된 내용은 실제 기술 블로그 본문이 아니라 Datadog 제품 메뉴와 관련 링크가 대부분이므로, 포스트모템에서 LLM을 활용하는 구체적인 방법이나 기술적 결론은 확인할 수 없다. ### Gartner 매직 쿼드런트 선정 - Datadog이 관측성 플랫폼 분야의 리더로 평가받았다는 내용이다. - 관련 링크는 Gartner 보고서 다운로드 또는 안내 페이지로 연결된다. - 이는 Datadog의 시장 영향력과 제품 역량을 강조하기 위한 홍보성 메시지다. ### Datadog 관측성 제품 범위 제공된 메뉴는 Datadog이 단일 모니터링 도구를 넘어 여러 운영 영역을 통합하려는 플랫폼 전략을 보여준다. - **인프라 모니터링** - 호스트 맵, 메트릭, 컨테이너, Kubernetes 오토스케일링 - 네트워크, 서버리스, GPU, 스토리지, 클라우드 비용 관리 - **애플리케이션 성능 관리** - APM, 서비스 모니터링, 연속 프로파일링 - 동적 계측과 AI 에이전트 관측성 - **로그·데이터 관측성** - 로그 관리, 민감 데이터 탐지, 감사 추적 - 데이터베이스, 데이터 스트림, 데이터 품질 및 작업 모니터링 - **보안** - 코드 보안, SAST, IAST, IaC·클라우드 보안 - SIEM, 워크로드 보호, 취약점 및 비밀정보 탐지 - **디지털 경험** - 브라우저·모바일 RUM, 세션 리플레이 - 신세틱 모니터링, 오류 추적, 제품 분석 - **소프트웨어 제공 및 서비스 관리** - CI/CD 가시성, 테스트 최적화, 코드 커버리지 - 인시던트 대응, SLO, 이벤트 관리, 워크플로 자동화 - **AI 기능** - Bits AI 에이전트와 조사 기능 - AI 통합, MCP 서버, GPU 모니터링, AI 에이전트 관측성 ### 제공된 자료의 한계 - 링크의 제목으로 보아 원문은 LLM을 활용한 포스트모템 작성 또는 분석을 다루는 글로 보인다. - 그러나 본문, 구현 방식, 프롬프트, 데이터 처리 과정, 정확성 검증 방법은 제공되지 않았다. - 따라서 LLM 기반 포스트모템 자동화의 장단점이나 실제 적용 절차를 이 자료만으로 요약할 수는 없다. 실제 기술 블로그 본문을 요약하려면 링크의 본문 내용이나 전체 텍스트를 추가로 제공해야 한다.

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

AI 에이전트쿠버네티스옵저버빌리티애플리케이션 성능 모니터링+4

datadog·2024년 9월 23일원문

장애 회고 작성을 지원하기 위해 비용, 품질, 안전성 측면에서 LLM 활용을 최적화한 방법 (새 탭에서 열림)

장애 해결 후 포스트모템(장애 회고록)을 작성하는 과정은 조직의 학습과 복구 능력 향상을 위해 필수적이지만, 엔지니어들에게는 상당한 시간과 노력이 드는 번거로운 작업입니다. 이를 해결하기 위해 Datadog은 Bits AI에 LLM을 도입하여 정형화된 장애 메타데이터와 슬랙의 비정형 대화 데이터를 결합해 포스트모템 초안을 자동 생성하는 기능을 구현했습니다. 이 프로젝트는 단순한 자동화를 넘어, 환각 현상을 억제하고 엔지니어가 직접 내용을 검토하며 학습하는 '인간 중심의 통제권'을 유지하는 데 초점을 맞추었습니다. ### LLM 기반 포스트모템 도입 시 직면한 과제 * **데이터 정확성 및 환각(Hallucinations):** LLM은 문법적으로는 완벽해 보이지만 사실이 아닌 내용을 그럴듯하게 생성하는 경향이 있습니다. 팩트가 생명인 장애 보고서에서 이러한 비결정론적 특성을 제어하는 것이 가장 큰 과제였습니다. * **비용, 속도, 품질의 트레이드오프:** GPT-4와 같은 고성능 모델은 정확도가 높지만 GPT-3.5에 비해 비용이 최대 50배 비싸고 생성 속도가 느려, 사용자 경험과 운영 비용 사이의 균형점이 필요했습니다. * **학습 과정의 훼손 방지:** AI가 완성된 결과물을 그대로 제공하면 엔지니어가 장애 원인을 깊이 파고드는 학습 기회를 놓칠 수 있습니다. 따라서 AI는 '작성 보조 도구'로서 초안을 제공하고 최종 판단은 인간이 하도록 설계해야 했습니다. * **보안 및 개인정보 보호:** 장애 데이터에는 민감한 정보나 비밀번호 등이 포함될 수 있으므로, LLM에 데이터를 전달하기 전 이를 사전에 필터링하는 보안 레이어가 필수적이었습니다. ### 정확도 향상을 위한 기술적 해결책 * **커스텀 API 및 데이터 정제 프레임워크:** 슬랙 대화와 장애 관리 앱에서 데이터를 추출한 뒤, 민감 정보를 제거하고 구조화하여 LLM이 처리하기 쉬운 형태로 변환하는 전용 API를 개발했습니다. * **정형·비정형 데이터의 결합:** 수동으로 입력된 장애 메타데이터(정형)뿐만 아니라, 장애 당시의 급박한 상황이 담긴 슬랙 대화 내용(비정형)을 함께 분석하여 문맥적으로 더 정확한 초안을 생성하도록 했습니다. * **프롬프트 엔지니어링 및 파라미터 튜닝:** 100시간 이상을 투입해 프롬프트 구조를 반복 수정했으며, 모델의 온도(Temperature) 설정을 낮추어 출력의 일관성을 높이고 무작위성을 줄였습니다. * **점진적 검증 프로세스:** 포스트모템 작성을 돕기 전, 먼저 짧은 '장애 요약 기능'을 구현하여 모델의 성능을 테스트하고 여기서 얻은 인사이트를 긴 문서 작성 기능에 피드백하는 방식을 취했습니다. ### 모델 출력 평가 및 피드백 루프 * **정성적/정량적 평가 병행:** 기존에 사람이 작성한 포스트모템과 AI가 생성한 초안을 정확성, 간결성, 유용성 등의 항목으로 비교하는 설문 조사를 실시하여 품질을 지속적으로 개선했습니다. * **사용자 피드백 반영:** 초안 생성 과정에서 엔지니어가 수정하는 내용을 추적하여, 어떤 부분이 부족하고 어떤 정보가 더 보강되어야 하는지 데이터 기반으로 파악하고 있습니다. LLM을 이용한 포스트모템 작성 지원은 엔지니어의 업무 부담을 줄여주는 동시에, 장애로부터 배우는 조직 문화를 더욱 공고히 하는 강력한 도구가 될 수 있습니다. 다만, AI의 결과물을 맹신하기보다는 엔지니어가 비판적으로 검토할 수 있는 '초안' 단계로 활용하는 것이 시스템의 신뢰성과 교육적 가치를 유지하는 핵심입니다.

대규모 언어 모델datadogslack데이터 사이언스+4

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

VS Code 방식: 개발자의 이너

개발자의 생산성을 높이려면 코드 작성 자체보다 코드와 디버깅에 몰입하는 ‘이너 루프(inner loop)’를 최대한 끊기지 않게 해야 한다. VS Code는 외부 도구로 이동하는 횟수를 줄이고, 협업·프로젝트 관리·AI 지원 기능을 편집기 안으로 통합해 몰입과 협업을 함께 달성하려 한다. 궁극적으로 도구를 오가는 마찰을 줄이는 것이 코드 품질뿐 아니라 개발자의 만족도와 에너지에도 영향을 준다는 주장이다. ## 이너 루프와 아우터 루프의 구분 - **이너 루프**는 코드 작성, 컴파일, 디버깅을 코드 에디터 안에서 반복하는 집중 작업 과정이다. - **아우터 루프**는 버그 트래커 확인, 티켓 업데이트, 동료와의 Slack·Teams 대화, 문서 검색, 프로젝트 관리 등 에디터 밖의 활동을 의미한다. - 여러 프로젝트를 동시에 진행하면 브라우저, API 문서, 터미널, 데스크톱을 계속 오가게 되며 집중력이 분산된다. - 몰입 상태가 유지되면 코드의 엣지 케이스와 향후 확장 계획 같은 맥락을 머릿속에 유지할 수 있다. - 반대로 컨텍스트 스위칭이 발생하면 이러한 맥락이 사라져 생산성과 코드 품질이 떨어진다. ## 편집기 안에서 집중력 유지하기 - VS Code의 **Zen Mode**는 사이드바 등 불필요한 UI를 숨겨 방해 요소를 줄인다. - 화면 구성이 바뀔 때마다 뇌가 새로운 UI에 적응해야 하므로, 작은 UI 변화도 누적되면 집중을 방해할 수 있다. - 개발자는 필요한 확장 기능을 선택해 자신의 작업 방식에 맞게 편집기를 구성할 수 있다. - 단일 도구의 사용성을 개선하는 것만으로는 충분하지 않으며, 도구 사이를 오가는 행위 자체를 줄여야 한다. ## 아우터 루프를 이너 루프로 가져오기 - GitHub에서 풀 리퀘스트를 확인한 뒤 다시 에디터로 돌아오는 과정처럼, 작업 중 도구를 전환하면 흐름이 끊긴다. - 가능한 경우 다음 기능을 코드 에디터에 직접 통합해야 한다. - 협업자와의 커뮤니케이션 - 코드 리뷰와 풀 리퀘스트 처리 - 프로젝트 관리와 티켓 확인 - 디자인 및 API 문서 참조 - Figma for VS Code 확장 기능을 사용하면 VS Code에서 디자인을 직접 확인하고 검사할 수 있다. - 필요한 협업이나 프로젝트 관리 작업을 현재 작업 공간에서 처리하면 불필요한 브라우저 전환을 줄일 수 있다. ## AI를 활용한 작업 흐름 보완 - 생성형 AI는 개발자가 작성 중인 코드를 분석해 다음에 필요할 가능성이 높은 코드를 미리 제안할 수 있다. - 제안이 작업 흐름을 방해하지 않는 방식으로 제공되면 코드 작성 속도와 집중력을 동시에 높일 수 있다. - 글에서는 GitHub Copilot 사용 시 코딩 속도가 55% 향상되었다는 GitHub의 보고와, AI 사용 개발자의 75%가 더 큰 성취감을 느꼈다는 조사 결과를 소개한다. - AI의 가치는 단순한 속도 향상뿐 아니라 개발자가 반복 작업에서 벗어나 더 만족스럽게 일하도록 돕는 데 있다. ## 협업도 몰입을 깨지 않는 방식으로 - 협업은 필수지만 회의와 실시간 채팅, 메시지 왕복은 개발자의 집중을 끊을 수 있다. - 이상적인 협업은 한 사람이 다른 사람의 작업을 중단시키는 방식이 아니라, 서로 각자의 이너 루프를 유지하며 진행하는 것이다. - VS Code는 GitHub 기능을 편집기에 통합해 다음 작업을 에디터를 떠나지 않고 수행하도록 지원한다. - 이슈 작업 - 코드 리뷰 - 풀 리퀘스트 작성 및 제출 - 모든 협업이 실시간이어야 하는 것은 아니며, 비동기 댓글과 리뷰를 활용하면 집중과 협업을 함께 유지할 수 있다. ## 개발자 행복으로 이어지는 선순환 - 도구 간 전환이 줄어들면 작업의 마찰과 반복적인 불편이 감소한다. - 몰입 상태가 길어질수록 생산성뿐 아니라 개발자의 에너지와 만족도도 높아진다. - 개발자 도구를 만드는 팀은 기능을 추가하는 것뿐 아니라, 개발자의 흐름을 방해하는 요소를 지속적으로 제거해야 한다. - 장기적으로는 코드 에디터가 개발에 필요한 모든 도구를 연결하는 통합 작업 공간이 되는 것이 이상적인 방향이다. 개발팀은 자주 발생하는 도구 전환 지점을 먼저 파악하고, GitHub·디자인 도구·문서·프로젝트 관리 기능을 에디터와 연동하는 것부터 시작하는 것이 좋다. 또한 알림을 줄이고 비동기 협업을 기본값으로 삼으면 집중력을 보존하면서도 협업 품질을 유지할 수 있다.

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

Figma생성형 AIgithubgithub-copilot+3

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

Figma on Figma: 최신

Figma는 디자이너 중심 도구에서 개발자·PM·제품팀 전체가 사용하는 생태계로 확장한 현실을 반영해 브랜드의 시각 언어를 재정비했다. 정적인 커서와 굵은 검은 윤곽선 중심의 기존 표현 대신, 공동 창작과 다양한 역할을 상징하는 프리미티브·색상·타이포그래피·모션을 도입했다. 새 브랜드는 누구나 아이디어를 현실로 만들 수 있는 협업 공간으로서의 Figma를 표현한다. ### 디자이너 도구에서 제품 개발 생태계로 - 지난 10년 동안 Figma는 순수한 디자인 도구에서 개발자, 제품 관리자, 전체 제품팀을 지원하는 플랫폼으로 성장했다. - 기존 브랜드는 벡터 그래픽의 문법에 가까웠다. - 정적인 마우스 커서 - 굵은 검은 외곽선 - 디자인 작업 자체에 초점을 둔 시각 표현 - 새로운 정체성은 아이디어 구상부터 개발, 협업, 완성까지 여러 사람이 참여하는 제품 제작 과정을 담는 데 초점을 맞췄다. ### 새 시각 언어를 구성하는 네 가지 기반 - **다목적 프리미티브** - 공동 창작에 참여하는 다양한 사람과 역할을 상징한다. - 특정 직군이나 작업 단계에 종속되지 않는 기본 형태로 활용된다. - **동적인 구성** - 만들고, 조정하고, 협업하는 다양한 작업 방식을 표현한다. - 정적인 결과물보다 제작 과정의 움직임과 상호작용을 강조한다. - **확장된 색상 팔레트** - 더 생생하고 폭넓은 색을 사용한다. - 색상 변수를 활용해 다양한 매체와 상황에 쉽게 적용할 수 있도록 설계했다. - **통합된 모션 원칙** - 창작 과정에서 발생하는 행동과 흐름을 애니메이션으로 표현한다. - 브랜드의 움직임이 단순 장식이 아니라 작업 과정과 연결되도록 했다. ### Figma 전용 서체 체계 - Figma는 Grilli Type과 협업해 독자적인 그로테스크 서체인 **Figma Sans**를 제작했다. - 브랜드에는 다음 네 가지 서체가 포함된다. - **Figma Sans**: 일반적인 브랜드 커뮤니케이션과 본문 - **Figma Sans Condensed**: 더 압축된 인상과 공간 효율이 필요한 표현 - **Figma Mono**: 개발, 코드, 정밀한 제작 작업을 연상시키는 표현 - **Figma Hand**: 브레인스토밍과 팀 협업처럼 인간적인 분위기를 전달 - 서로 다른 서체를 조합해 디자인, 엔지니어링, 협업 등 다양한 역할과 작업 방식을 표현한다. ### 샌드박스에서 시작한 탐색 - Figma Brand Studio는 사람들이 Figma를 사용하는 전 과정을 살펴보며 탐색을 시작했다. - 브레인스토밍 - 초기 아이디어 구상 - 요소 검사 - 최종 결과물의 세부 조정 - 팀은 여러 활동이 하나의 공유 공간에서 동시에 이루어지는 모습에 주목했다. - 이 개념은 사람들이 같은 공간에서 각자 놀고 만들며 상호작용하는 **parallel play**와 연결됐다. - Figma 캔버스를 사람들이 함께 만들고 실험하는 장소로 보고, 놀이터에서 시각적 영감을 얻었다. - Isamu Noguchi의 놀이터와 조경 작품 - Mitsuru Senda의 다채로운 패널형 놀이터 - 정교한 타일 작업과 인프라 구조 - 초기에는 놀이터의 형태를 직접적으로 차용했지만, 최종적으로는 이를 단순한 모방이 아니라 공동 창작과 실험을 상징하는 추상적 시각 언어로 발전시켰다. ### 실용적인 시사점 브랜드 리뉴얼은 로고나 색상만 바꾸는 작업이 아니라, 사용자의 역할과 제품이 지원하는 행동 범위를 다시 정의하는 과정이다. 특히 제품이 여러 직군의 협업 도구로 성장했다면, 시각 체계도 결과물뿐 아니라 아이디어 구상·소통·개발·수정 같은 전체 제작 흐름을 표현하도록 확장하는 것이 효과적이다.

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

Figma디자인 시스템디자인 토큰typography+2

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

우리만의 서체: Figma Sans 제작

Figma는 제품과 사용자층이 확장되면서 기존 브랜드와 서체를 함께 재정비했고, 그 결과 Grilli Type과 협업해 맞춤 서체인 Figma Sans를 만들었다. Figma Sans는 디스플레이와 본문 모두에서 잘 작동하고, 디자이너뿐 아니라 개발자·제품 관리자·초보 사용자까지 아우르는 유연성과 가독성을 목표로 했다. 제작 과정에서는 유행을 따르기보다 Figma만의 “주관 있는(opinionated)” 성격을 서체에 담는 데 집중했다. ## 브랜드 확장에 맞춘 서체 재설계 - 기존 서체인 **Whyte**는 2019년부터 Figma의 브랜드를 대표했으며, 특유의 인트랩(inktrap) 스타일을 갖고 있었다. - Figma가 다양한 제품 제작 도구를 제공하고 커뮤니티도 확장되면서, 기존 서체만으로는 새로운 브랜드 방향을 충분히 표현하기 어려워졌다. - 색상 팔레트, 일러스트레이션, 패턴, 모션 등 시각 아이덴티티 전반을 바꾸는 과정에서 서체도 핵심 요소로 재검토됐다. - 새로운 브랜드는 강렬한 색상과 더 복잡하고 추상화된 형태를 사용했기 때문에, 이를 보완하면서도 과도하게 튀지 않는 서체가 필요했다. ## 현대적 그로테스크 서체를 선택한 이유 - Figma 팀은 여러 스타일을 검토한 끝에 **현대적인 그로테스크 계열 산세리프**를 적합한 방향으로 판단했다. - 그로테스크는 19세기 초부터 등장한 산세리프 서체 양식으로, 장식이 적고 구조가 명확한 것이 특징이다. - Figma Sans에는 다음과 같은 조건이 요구됐다. - 다양한 굵기와 옵티컬 사이즈 지원 - 마케팅용 대형 제목과 본문 텍스트 모두에서 높은 성능 - Help Center 같은 긴 글을 읽는 화면에서도 가독성 확보 - 디자이너뿐 아니라 개발자, 제품 관리자, 신규 사용자도 편하게 사용할 수 있는 폭넓은 인상 - 단순히 개성적인 서체가 아니라, 여러 제품과 사용 환경에 적용할 수 있는 실용성이 중요했다. ## 기성 서체 대신 맞춤 서체를 선택 - Figma 팀은 Commercial Type의 **Marr Sans**, RP Digital Type Foundry의 **Agipo** 등 다양한 기성 서체를 검토했다. - 그러나 브랜드의 개성과 기능적 요구를 동시에 충족하는 서체를 찾기 어려웠다. - 이에 따라 Figma는 외부 서체를 선택하는 대신, 요구사항을 함께 정리하고 브랜드에 맞게 설계할 수 있는 맞춤 서체 제작을 결정했다. - 협업 파트너로는 그래픽 디자인과 서체 제작에서 강한 개성을 보여온 스위스·미국 기반의 **Grilli Type**을 선택했다. - Grilli Type은 일반적인 유행이나 역사적 서체의 복제보다, 흥미로운 개념적 틀을 바탕으로 독자적인 서체를 만드는 접근을 중시했다. ## “주관 있는” 서체라는 방향 설정 - Grilli Type은 Figma의 요구사항을 정리하기 위해 무드보드를 만들고, 다양한 시각적 아이디어가 어떻게 연결되는지 탐색했다. - 프로젝트의 중심 질문은 브랜드 설명에서 말하는 핵심 긴장감이 무엇인지 찾는 것이었다. - 그 과정에서 **“opinionated”**, 즉 자신이 누구인지와 무엇을 원하는지 분명히 아는 태도가 중요한 키워드로 자리 잡았다. - Figma Sans는 장식이나 불필요한 요소를 덧붙이기보다, 단순하고 명확하지만 확실한 인상을 주는 방향으로 발전했다. ## 두 가지 초기 방향을 결합한 설계 - Grilli Type은 초기 단계에서 서로 다른 두 가지 디자인 방향을 제시했다. - 하나는 보다 직관적이고 단순한 방향 - 다른 하나는 훨씬 실험적이고 과감한 방향 - 두 안 중 하나를 그대로 선택하기보다, 각각이 어떤 가능성을 열어주는지 논의하는 데 초점을 맞췄다. - 최종적으로는 첫 번째 방향의 단순화된 형태를 기본으로 삼고, 두 번째 방향의 독특한 특징을 일부 결합했다. - 참고 자료로는 다음과 같은 역사적 사례가 활용됐다. - 1925년 『Typographische Mitteilungen』의 타이포그래피 - 1960년대 Karl Gerstner의 프로그램적 디자인 - 전화번호부용으로 설계된 Matthew Carter의 **Bell Centennial** - 이를 통해 Figma Sans는 읽기 쉬운 구조와 브랜드 고유의 개성을 동시에 추구했다. ## 실용적인 결론 Figma Sans의 제작 과정은 브랜드용 서체가 단순히 새로운 글꼴을 만드는 작업이 아니라, 브랜드의 사용자·제품·시각 언어를 하나의 시스템으로 정리하는 과정임을 보여준다. 특히 여러 화면과 사용자층을 고려해야 한다면, 개성만 강조하기보다 본문 가독성, 다양한 굵기, 적용 범위까지 함께 설계하는 것이 중요하다.

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

Figmatypographybrandingtypeface-design+2

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

입문하기: 첫 프로덕트

제품 디자인의 첫 직무를 얻으려면 포트폴리오를 통해 실력뿐 아니라 문제 해결 과정과 제품 사고를 보여줘야 한다. 특히 결과물 자체보다 “왜 그렇게 결정했는가”를 설명하고, 제약·트레이드오프·배운 점까지 설득력 있게 전달하는 것이 중요하다. Figma는 인턴과 신입 디자이너에게 관찰자가 아닌 제품에 기여하는 구성원으로서의 창의성과 새로운 관점을 기대한다. ## Figma의 초기 커리어 기회 - Figma는 매년 인턴과 신입 졸업생을 제품 디자인 팀에 영입한다. - 초기 경력 디자이너도 단순히 업무를 관찰하는 데 그치지 않고 제품에 새로운 아이디어와 에너지를 더한다. - 글은 Figma의 채용 기준과 초기 커리어 지원 방법, 인터뷰 과정 등을 안내한다. - 인터뷰에는 Figma 제품 디자이너인 Chia Amisola, Julia Han, Keeyen Yeo, Kelly Hu, Tammy Taabassum의 경험과 조언이 담겼다. ## 포트폴리오의 기본 원칙 - 포트폴리오는 첫인상을 결정하므로 자신의 역량, 창의성, 디자인 프로세스, 결과의 영향력을 가장 잘 보여주는 작업을 앞에 배치해야 한다. - 사이트 제작 도구, 프로젝트 개수, 시각적 스타일보다 다음 요소가 더 중요하다. - 최고의 작업을 선별했는가 - 프로젝트를 이해하기 쉬운 이야기로 구성했는가 - 방문자가 콘텐츠를 쉽게 탐색할 수 있는가 - 포트폴리오가 자신의 관점과 개성을 드러내는가 - 포트폴리오의 형식은 개인적일 수 있으며, 정해진 템플릿을 따르기보다 자신과 작업을 잘 표현하는 방식을 선택하면 된다. ## 가장 강한 프로젝트를 앞에 배치하기 - 첫 번째 프로젝트는 전체 포트폴리오의 기준을 설정하므로 가장 종합적으로 자신의 능력을 보여주는 작업을 선택해야 한다. - 어떤 프로젝트를 앞에 둘지 고민된다면, 가장 자연스럽게 설명할 수 있고 설득력 있는 이야기를 들려줄 수 있는 작업을 고르는 것이 좋다. - 좋은 프로젝트 사례에는 다음 내용이 포함된다. - 명확한 문제 정의 - 프로젝트의 주요 단계와 마일스톤 - 결과에 대한 해석과 결론 - 성과를 측정한 지표 - 진행 과정에서 얻은 교훈 - 다시 한다면 바꾸고 싶은 점 - 프로젝트가 큰 성공을 거두지 못했더라도 실패 원인과 배운 점을 설명할 수 있다면 충분히 강력한 사례가 될 수 있다. ## 결과보다 디자인 의사결정이 중요한 이유 - 제품 디자인 포트폴리오에서는 최종 화면보다 각 선택의 이유를 설명하는 능력이 중요하다. - 색상, 컴포넌트, 스타일, 문구 등 모든 요소는 의도적인 결정으로 다뤄야 한다. - 설명할 때 다음 내용을 구체적으로 제시해야 한다. - 어떤 문제를 해결하려 했는가 - 고려한 대안은 무엇이었는가 - 각 대안의 장단점은 무엇이었는가 - 시간·기술·비즈니스 등 어떤 제약이 있었는가 - 최종 선택으로 인해 발생한 트레이드오프는 무엇인가 - 이러한 설명은 단순히 화면을 제작하는 능력을 넘어, 제품의 맥락과 다양한 선택의 영향을 이해하고 있음을 보여준다. ## 포트폴리오 제작에 활용할 수 있는 자료 - Figma는 포트폴리오 발표 구성과 제작을 돕는 커뮤니티 템플릿을 제공한다. - 활용 가능한 자료에는 다음이 포함된다. - 제품 디자이너 포트폴리오 발표 가이드 및 템플릿 - 여러 기기 화면을 보여주는 디바이스 목업 - 15페이지 분량의 제품 디자인 포트폴리오 발표 템플릿 - HTML 포트폴리오 템플릿 - UI·UX 디자이너용 개인 포트폴리오 템플릿 - 템플릿은 완성된 정답이라기보다 작업의 구조를 잡고 빠르게 시작하기 위한 도구로 활용하는 것이 적절하다. 프로젝트를 많이 넣기보다 가장 잘 설명할 수 있는 작업을 선별하고, 화면보다 문제 정의·과정·의사결정·성과·배움을 중심으로 구성하는 것이 효과적이다. 포트폴리오를 완성한 뒤에는 각 선택의 “왜”를 말로 설명하는 연습을 해보는 것이 좋다.

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

Figma사용자 경험생성형 AI프로덕트 디자인+3

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

개발 모드와 함께한

Figma Dev Mode를 1년간 도입한 Decathlon의 경험에 따르면, 이 도구는 디자인과 개발 사이의 협업을 크게 개선할 수 있다. 특히 Code Connect를 활용하면 Figma 컴포넌트와 실제 코드 간의 속성, 명명 규칙, 상태를 직접 연결할 수 있어 디자인 시스템 운영이 정교해진다. 다만 기존 업무 방식을 한 번에 바꾸기보다 작은 성공 사례부터 시작하고, 명확한 문서화와 완료 기준을 마련하는 것이 중요하다. ## 디자인과 코드의 연결: Code Connect - Dev Mode의 가장 큰 효과는 Figma 컴포넌트를 실제 컴포넌트 코드와 연결하는 **Code Connect**에서 나타났다. - 디자인과 코드에서 컴포넌트 구조가 다르더라도 다음 문제를 조정하는 데 도움이 된다. - 속성 및 프로퍼티 정렬 - 컴포넌트 이름 규칙 통일 - 상태 관리 방식 일치 - 디자인 토큰을 Figma에서 명확히 표현하면 개발자가 시각적 의사결정을 코드 수준에서 이해하기 쉬워진다. - 색상 값과 토큰 이름을 연결하면 디자인 토큰 변경 사항이 대응하는 코드 변경으로 즉시 이어진다. ## 작게 시작하고 확장하기 - 개발자에게 새로운 도구는 기존 업무 흐름을 방해할 수 있으므로, Dev Mode를 전면 도입하기보다 작은 범위에서 시작했다. - 초기에는 Figma Variables를 활용한 디자인 토큰 관리처럼 빠르게 효과를 확인할 수 있는 영역에 집중했다. - **변수 별칭(variable aliasing)**을 사용하면 원시 토큰과 의미론적 토큰 사이에 계층을 만들 수 있다. - 테마 구현이 쉬워진다. - 팀원이 토큰 체계를 이해하고 적용하기 쉬워진다. - 변수 스코핑을 설정하면 특정 변수가 적용될 수 있는 속성을 제한할 수 있다. - 배경색을 텍스트 색상에 사용하는 실수 방지 - 간격 값을 테두리 반경에 사용하는 잘못된 적용 방지 - 변수의 코드 표기법을 플랫폼별 개발자 명명 규칙에 맞게 사용자 지정할 수 있다. ## 고급 검사 기능으로 레이아웃 확인 - Dev Mode는 복잡한 UI 레이아웃과 Flexbox 기반 구조를 검사하고 구현 가능한 코드로 확인하는 데 유용하다. - 개발자는 다음 플랫폼의 구현 속성을 직접 살펴볼 수 있다. - 웹 CSS - iOS의 SwiftUI와 UIKit - Android의 XML과 Compose - 디자이너와 디자인 시스템 담당자는 컴포넌트가 요구사항에 맞게 구현될 수 있는지 구체적으로 검증할 수 있다. - Figma VS Code 확장을 이용하면 CSS, Compose, SwiftUI 코드 탐색과 자동완성을 IDE 안에서 처리할 수 있다. - 결과적으로 디자인 파일을 별도로 해석해 코드를 작성하는 부담이 줄어든다. ## 완료 기준과 문서화 통일 - 디자인 시스템 문서는 지속적으로 최신 상태를 유지하기 어렵고, 디자인 의도나 세부 요구사항이 개발 과정에서 누락되기 쉽다. - Dev Mode의 문서화 및 주석 기능을 사용하면 디자인 파일 안에 필요한 정보를 직접 남길 수 있다. - 주석에는 다음 내용을 포함할 수 있다. - 자유로운 설명 문장 - 정렬 및 크기 같은 명시적 값 - 간격과 치수를 보여주는 측정 정보 - 디자이너는 개발자에게 특정 주석을 직접 연결해 의도와 구현 조건을 명확히 전달할 수 있다. - 팀에서는 각 컴포넌트에 다음 자료를 함께 연결하는 문서화 체계를 구축했다. - GitHub 소스 코드 - README - 관련 플레이그라운드 - 이를 통해 “디자인 완료”와 “개발 완료”의 기준을 팀 전체가 같은 방식으로 이해할 수 있다. ## 적용 시 권장 방식 - Dev Mode를 도입할 때는 기존 개발 프로세스를 즉시 대체하기보다 디자인 토큰이나 변수처럼 효과가 명확한 영역부터 시작하는 것이 좋다. - 토큰 계층, 변수 스코핑, 코드 명명 규칙을 먼저 정리하면 이후 Code Connect와 컴포넌트 문서화의 효과가 커진다. - 검사 기능만 사용하는 데 그치지 말고, 주석·소스 코드·README·플레이그라운드를 연결해 디자인 시스템의 단일한 참고 지점을 만들어야 한다.

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

디자인 시스템디자인 토큰swiftuiflexbox+4

figma·2024년 8월 19일원문

크런치롤이 개발자 (새 탭에서 열림)

글로벌 애니메이션 스트리밍 서비스인 크런치롤(Crunchyroll)은 15개의 플랫폼과 12개의 언어를 지원하는 복잡한 환경 속에서 디자인 일관성을 유지하기 위해 '유니버설 디자인 시스템(Universal Design System)'과 피그마의 '개발 모드(Dev Mode)'를 적극 도입했습니다. 과거 인수합병 과정에서 쌓인 파편화된 워크플로우와 기술 부채를 정리함으로써, 디자이너와 엔지니어 간의 협업 효율을 극대화하고 사용자에게 통일된 브랜드 경험을 제공하게 되었습니다. 이번 전환은 단순히 도구를 바꾼 것을 넘어, 복잡한 다중 플랫폼 환경에서 제품의 출시 속도와 품질을 동시에 잡는 전략적 선택이었습니다. **다중 플랫폼 환경에서의 복잡성과 레거시 문제** * 크런치롤은 웹, 모바일뿐만 아니라 게임 콘솔, 스마트 TV 등 9개의 거실용 기기를 포함해 총 15개의 플랫폼을 지원하며, 1,500만 명 이상의 글로벌 팬들에게 서비스를 제공합니다. * 과거에는 각 플랫폼별로 개별적인 디자인 시스템(iOS, Android, tvOS 등)을 운영했으며, 이는 협업 과정에서 심각한 불일치와 혼선을 초래했습니다. * 기존 워크플로우는 Jira 트리거와 Zeplin에 의존했으나, 아트보드 로딩에만 4~5분이 소요되거나 시차 문제로 인해 최신 디자인 사양을 실시간으로 공유하기 어려운 구조였습니다. **디자인 시스템을 통한 효율성 극대화: "식재료 준비(Meal Prepping)"** * 디자인 시스템을 '식재료 미리 준비하기'에 비유하여, 매번 새로운 기능을 만들 때마다 처음부터 설계하는 것이 아니라 준비된 컴포넌트를 재사용하여 리소스를 절약합니다. * 엔지니어링의 DRY(Don't Repeat Yourself) 원칙을 디자인에도 적용하여 중복 컴포넌트를 제거하고 일관된 타이포그래피, 그리드, 간격 시스템을 구축했습니다. * 이러한 표준화는 사용자의 인지 부하를 줄여 구독 전환율을 높이는 동시에, 제품 관리자가 아이디어를 빠르게 검증할 수 있는 속도 경쟁력을 제공합니다. **개발 모드(Dev Mode)를 활용한 협업 프로세스의 혁신** * 개발자가 피그마 링크를 통해 '개발 준비 완료(Ready for development)' 페이지에 접속하면, 수많은 아이데이션 과정은 생략하고 오직 구현에 필요한 최신 스펙과 코드 값만 바로 확인할 수 있습니다. * 기존에 5분씩 걸리던 데이터 파싱 속도가 획기적으로 개선되어, 엔지니어가 특정 결제 플로우나 컴포넌트의 상세 정보를 찾는 데 드는 시간을 대폭 단축했습니다. * 코드 커넥트(Code Connect) 베타 버전을 통합하여 디자인 시스템의 컴포넌트와 실제 코드를 더 밀접하게 연결함으로써 디자인과 코드 간의 괴리를 좁히고 있습니다. **디자인 시스템 운영의 철학과 변화 관리** * 디자인 시스템은 팀을 지원하기 위한 도구일 뿐, 프로세스의 포로가 되어서는 안 된다는 철학 아래 지속적인 교육과 온보딩 워크숍을 진행했습니다. * 과거의 복잡한 QA 단계나 불필요한 태그 시스템을 과감히 삭제하고, 개발자가 필요한 정보에 직접 접근할 수 있는 자율적인 환경을 조성했습니다. * 전문화된 디자인 원칙(계층 구조, 그리드 등)을 준수하는 '좋아 보이는 디자인'과 엣지 케이스까지 고려한 '잘 작동하는 디자인'을 디자인 성공의 핵심 지표로 삼고 있습니다. 디자인 시스템은 한 번 구축하고 끝나는 것이 아니라 팀의 성장에 맞춰 계속 진화해야 합니다. 크런치롤의 사례처럼 도구의 기능을 활용해 불필요한 단계를 제거하고, 개발자와 디자이너가 동일한 언어로 소통할 수 있는 환경을 만드는 것이 복잡한 글로벌 서비스를 운영하는 핵심 전략입니다.

Figma디자인 시스템사용자 경험design-to-code+4

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

Figma의 3C:

Figma 입문자는 개별 기능을 순서대로 외우기보다 **생성(Creation), 사용자화(Customization), 협업(Collaboration)**이라는 세 가지 관점으로 학습하는 것이 효과적이다. 기본 요소를 만들고, 다양한 상황에 맞게 유연하게 개선한 뒤, 팀원들이 재사용할 수 있도록 공유하는 단계적 접근이 Figma 활용 능력과 협업 역량을 함께 높여준다. 명확한 목표와 일정, 그리고 직접 시도하고 질문하는 학습 태도도 중요하다. ## 목표·일정·학습 태도 설정 - 학습을 시작하기 전에 무엇을 배우고 어떻게 활용할지 목표를 적어 둔다. - 예시 목표: - Figma와 자신의 디자인 프로세스에 필요한 기본 도구 익히기 - 효율적으로 협업하는 팀원 되기 - 예시 일정: - **30일:** 기본 도구, 협업 방식, 파일 정리와 관리 습관 이해 - **60일:** 몇 가지 프로젝트에 적용해 부족한 부분 파악 - **90일:** 고급 기능을 실제 업무 흐름에 도입 - 권장 학습 태도: - 직접 만들고, 망가뜨리고, 다시 만들며 기능을 실험한다. - 작업물을 공유하고 Slack, 소셜 미디어, Figma Community Forum 등에서 질문한다. - 새로운 도구와 프로세스에 익숙해지는 데 시간이 걸리므로 필요할 때 휴식한다. ## 세 가지 C로 배우는 Figma - **Creation(생성)** - 기본적인 디자인 요소를 직접 만든다. - 에디터의 핵심 조작과 기본 도구 사용법을 익히는 단계다. - **Customization(사용자화)** - 만든 요소를 더 유연하고 재사용 가능하게 만든다. - 다양한 사용 사례에 대응하도록 고급 기능을 적용한다. - **Collaboration(협업)** - 완성한 디자인을 팀원과 공유한다. - 다른 사람이 자신의 파일에서 사용할 수 있도록 컴포넌트와 문서를 제공한다. - 세 단계는 사다리의 각 발판처럼 연결된다. 먼저 요소를 만들고, 이를 확장·정리한 뒤, 팀의 공동 자산으로 공유해야 효과적인 협업이 가능하다. ## 버튼 제작으로 이해하는 학습 과정 - 글은 버튼을 만드는 과정을 세 가지 C의 사례로 제시한다. - 버튼을 직접 만든다: **생성** - 버튼을 컴포넌트로 전환한다: **사용자화** - 다른 사람이 사용할 수 있도록 게시한다: **협업** - 최종적으로는 하나의 버튼이 아니라 여러 상황에서 재사용할 수 있는 버튼 세트를 구축하는 방향으로 발전한다. - 이 과정을 통해 Figma 기능 자체보다 실제 업무 흐름에 기능이 어떻게 연결되는지 이해할 수 있다. ## 학습에 활용할 자료 - Figma Help Center에서 기능별 상세 설명을 확인할 수 있다. - Figma YouTube 채널에서는 튜토리얼, 라이브 방송 녹화본, 기능 출시 영상을 제공한다. - 정기적인 온라인 이벤트와 Figma Community의 플레이그라운드 파일을 통해 실습할 수 있다. - 특히 기능을 따로 암기하기보다 하나의 디자인 요소를 완성해 가며 세 가지 C를 순서대로 적용하는 방식이 효과적이다. 처음부터 모든 기능을 익히려 하기보다 작은 요소 하나를 만들고, 재사용 가능한 컴포넌트로 발전시킨 뒤, 팀과 공유하는 실습부터 시작하는 것이 좋다.

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

Figma디자인 시스템프로토타이핑사용자 인터페이스+2