user-interface

9 개의 포스트

discord

소개합니다: You Bar (새 탭에서 열림)

Discord는 모바일 앱의 탐색을 단순화하고, 사용자 정체성을 강조하며, 데스크톱과 모바일 경험을 통합하기 위해 새로운 하단 UI인 ‘You Bar’를 도입했습니다. 서버와 채널 중심으로 사용하는 실제 이용 패턴과 오픈월드 게임의 탐험 구조에서 영감을 받아, You Bar를 사용자가 Discord 세계를 이동하는 중심 인터페이스로 설계했습니다. 향후 서버별 프로필, 서버 태그, 활동 표시, 모바일 음성 기능 등으로 확장될 예정입니다. ## 서버 중심의 단일 탐색 구조 - 기존 모바일 Discord에는 서버를 이동하는 방식과 서버 외 기능으로 이동하는 방식이 동시에 존재해 초보 사용자에게 복잡하게 느껴질 수 있었습니다. - 사용자들이 대부분의 시간을 서버와 채널 탐색, 채팅, 음성 채널 이용, 공지 확인에 사용한다는 점에 주목했습니다. - 오픈월드 게임에서 캐릭터가 넓은 세계를 이동하는 방식에 착안해: - 서버와 채널은 탐험하는 ‘세계’ - You Bar는 그 세계를 이동하는 ‘사용자’를 상징하도록 구성했습니다. - 이를 통해 기존의 이중 탐색 체계를 하나의 서버 중심 탐색 시스템으로 단순화했습니다. ## You Bar의 주요 조작 방식 - You Bar를 탭하면 프로필이 열립니다. - 프로필 편집 - 설정 - 퀘스트 - 상점 등 기존 기능은 그대로 유지됩니다. - 벨 아이콘을 탭하면 알림을 확인할 수 있습니다. - You Bar를 길게 누르면 계정 메뉴가 열리고 온라인 상태를 변경할 수 있습니다. - 아바타를 길게 누르면 설정으로 바로 이동합니다. - You Bar를 왼쪽에서 오른쪽으로 쓸어 넘기면 DM과 현재 서버 사이를 전환할 수 있습니다. - UI 구조를 단순화하면서 소폭의 메모리 및 CPU 절감 효과도 기대할 수 있습니다. ## 사용자 정체성을 강조하는 디자인 - You Bar는 사용자가 Discord 안에서 자신을 표현하는 전용 공간으로 설계됐습니다. - 기존보다 더 크고 표현력이 풍부한 아바타를 배치했습니다. - 표시 이름과 상태 정보를 보다 세련된 방식으로 보여줍니다. - 아바타 장식과 이름표가 새로운 레이아웃에서 더 잘 드러나도록 했습니다. - 사용자가 아바타, 장식, 이름표 등을 조합해 개성을 표현하는 것을 주요 경험으로 삼았습니다. ## 모바일과 데스크톱 경험의 통합 - 데스크톱과 모바일 앱이 서로 다른 속도로 발전하면서 디자인과 사용 경험이 점점 달라졌습니다. - You Bar는 데스크톱 UI를 모바일에 그대로 복제하려는 것이 아니라, 플랫폼별 장점을 유지하면서 Discord의 기본 경험을 더 일관되게 만드는 단계입니다. - 향후 모바일 사용성을 개선하기 위한 여러 변경 사항 중 하나로 추진되고 있습니다. ## 향후 추가될 기능 - **서버별 You Bar** - 현재 서버에 별도 프로필을 설정했다면 해당 프로필에 맞춰 You Bar가 변경됩니다. - **서버 태그** - 사용자가 좋아하는 서버의 태그를 You Bar에 표시할 수 있게 됩니다. - **활동 상태 표시** - 게임 플레이, 음악 감상 등 현재 활동을 You Bar에서 확인할 수 있습니다. - **애니메이션 설정** - 아바타 장식과 이름표의 애니메이션을 You Bar에서 언제 재생할지 사용자가 선택할 수 있습니다. - **확장된 프로필 공간** - 단순한 정적 프로필 페이지가 아니라, 사용자를 위한 독립적인 공간으로 프로필 화면을 재설계할 계획입니다. - **개선된 모바일 음성 경험** - 데스크톱에서 익숙한 음성 채널 입장 및 이탈 경험을 모바일에도 가져오는 작업이 예고됐습니다. You Bar는 단순히 새로운 하단 메뉴를 추가한 것이 아니라, Discord 모바일의 탐색 방식을 서버 중심으로 재구성하고 사용자의 정체성을 전면에 내세우려는 디자인 개편입니다. 모바일 Discord를 자주 사용한다면 새로운 제스처와 메뉴 위치를 익히는 것이 좋으며, 향후 서버별 프로필과 음성 기능 확장까지 고려하면 모바일 경험의 중심 인터페이스가 될 가능성이 큽니다.

kakao

카카오톡 예약하기에서 그려 본 캘린더 (새 탭에서 열림)

카카오톡 예약하기는 카드 목록만으로는 재고와 예약을 한눈에 파악하기 어렵다는 문제를 해결하기 위해 타임 블록형 캘린더를 구현했다. 예약을 시작 시간과 종료 시간에 따라 정렬하고, 겹치는 예약을 그래프로 모델링한 뒤 DFS로 배치 깊이와 확장 가능 범위를 계산했다. 이후 루트 노드 간의 길이 차이로 남는 공간이 생기는 예외까지 보정해 예약 블록을 최대한 빈틈없이 배치했다. ## 캘린더 제작 배경과 요구사항 - 파트너센터의 예약 관리 화면은 예약을 카드 목록으로 보여주고 있었다. - 카드 목록은 많은 예약과 재고를 한눈에 비교하기 어렵다는 불편이 있었다. - 이를 해결하기 위해 예약과 재고를 시간축 위에서 확인할 수 있는 타임 블록형 캘린더를 제작했다. - 주요 요구사항은 다음과 같다. - 하나의 시간대에 최대 10개의 예약이 존재할 수 있다. - 하나의 예약은 최대 6시간을 차지한다. - 예약 블록 사이에 빈 공간을 최소화하면서 최대한 잘 보이게 배치해야 한다. ## 예약 배치 순서 ### 이용 시간이 이른 예약부터 정렬 - 예약이 입력된 순서가 아니라 시작 시간이 빠른 순서대로 배치했다. - 판매자가 하루를 시작할 때 가장 먼저 확인할 가능성이 높은 예약을 왼쪽 위에 배치하기 위한 결정이다. - 사용자의 시선이 일반적으로 왼쪽 위에서 오른쪽 아래로 이동한다는 시각적 우선순위도 고려했다. - 첫 번째 배치 규칙은 **“이용 시간이 이른 순서로 정렬한다”**이다. ### 같은 시간에는 소요 시간이 긴 예약부터 정렬 - 같은 시간대에 여러 예약이 겹치면 소요 시간이 긴 예약을 앞에 배치했다. - 긴 예약이 뒤로 밀리면 앞쪽 예약이 차지한 공간 때문에 긴 블록의 확장이 제한될 수 있다. - 긴 예약을 먼저 배치하면 이후 예약들이 남은 공간을 기준으로 배치되고, 각 예약이 확보할 수 있는 영역을 예측하기 쉬워진다. - 두 번째 배치 규칙은 **“같은 시간 내에서는 소요 시간이 긴 순서로 정렬한다”**이다. ## 예약을 그래프로 모델링 - 단순히 DOM 요소의 위치를 조정하는 대신, 예약 간의 겹침 관계를 그래프로 표현했다. - 각 예약을 그래프의 노드로 만들고, 서로 영향을 주는 예약을 연결했다. - 노드에는 예약 정보와 함께 이전 예약(`prevBooking`), 다음 예약(`nextBooking`) 같은 연결 관계를 저장했다. - 이 구조를 이용하면 예약이 어떤 경로로 연결되어 있고, 어느 정도까지 확장될 수 있는지 계산할 수 있다. ## DFS를 이용한 위치와 확장 범위 계산 - 각 노드에서 DFS를 수행해 다음 정보를 계산했다. - 그래프에서의 깊이 또는 레벨 - 연결된 예약 중 가장 끝에 있는 예약까지의 최대 거리(`maxLength`) - 깊이는 예약 블록의 가로 방향 위치를 결정하는 데 사용된다. - 최대 거리는 해당 예약이 오른쪽으로 얼마나 확장될 수 있는지 판단하는 기준이 된다. - 계산된 값을 바탕으로 각 노드의 다음 UI 속성을 구한다. - `left`: 블록의 시작 위치 - `width`: 블록이 차지할 가로 너비 - 그래프의 가장 왼쪽에 있는 노드부터 기준을 잡아 예약 블록을 배치하고 확장했다. ## 루트 노드 간 길이 차이로 발생한 예외 - 초기 알고리즘은 모든 예약이 연결된 그래프에서도 공간이 남는 경우를 완전히 처리하지 못했다. - 위쪽 루트 노드의 `maxLength`가 더 길고, 아래쪽 루트 노드의 `maxLength`가 짧으면 하위 그래프가 끝까지 확장되지 않았다. - 그 결과 예약 간 연결은 유지되지만 일부 빈 공간이 남는 문제가 발생했다. - 이 문제를 해결하기 위해 다음과 같은 보정 과정을 추가했다. - 현재 노드의 `left + width`보다 다음 노드의 `left`가 크면 두 노드 사이에 확장 가능한 공간이 있다고 판단한다. - 해당 노드와 연결된 예약들을 확인한다. - 여러 개의 빈 공간이 있으면 가장 작은 공간을 기준으로 연결된 노드들의 너비를 확장한다. - 이 과정을 반복해 예약 블록이 가능한 한 빈틈없이 영역을 채우도록 했다. ## 구현 과정에서 얻은 교훈 - 겉보기에는 단순한 UI라도 다양한 입력 데이터와 최악의 배치 상황을 고려해야 한다. - 타임 블록 캘린더는 예약의 정렬, 겹침 처리, 가로 확장, 예외 보정이 결합된 알고리즘 문제에 가깝다. - 그래프와 DFS 같은 자료구조·알고리즘이 실제 프런트엔드 UI 배치 문제를 해결하는 데 직접 활용될 수 있다. - 프런트엔드 개발자는 데이터를 화면에 어떻게 보여줄지 결정하는 책임과 권한을 함께 가진다. - 실제 서비스에서는 초기 알고리즘을 완성형으로 보기보다, 운영 중 발견되는 버그와 새로운 입력 패턴에 맞춰 지속적으로 개선해야 한다. 타임 블록 캘린더를 구현할 때는 먼저 예약을 시작 시간과 지속 시간 기준으로 안정적으로 정렬하고, 겹침 관계를 그래프로 모델링하는 방식이 유용하다. 이후 DFS로 배치 깊이와 확장 범위를 계산하되, 루트별 길이 차이로 생기는 잔여 공간과 같은 예외 케이스를 별도로 검증하는 것이 중요하다.

discord

데스크톱 디스코드 화면 최적화: 눈이 편안해지는 디스플레이 설정 (새 탭에서 열림)

Discord 데스크톱 앱은 미디어 표시 방식, 색상 강도, HDR, 이름 스타일, UI 밀도와 글자 크기 등을 조정해 눈의 피로를 줄일 수 있다. 사용자는 이미지·영상·링크 미리보기를 필요할 때만 표시하거나, 색상과 밝기를 낮추고, 화면에 표시되는 정보량을 자신의 선호에 맞게 바꿀 수 있다. 이러한 설정은 데스크톱과 웹 앱을 중심으로 설명되지만 일부는 모바일에서도 유사하게 제공된다. ## 대화 속 미디어 표시 제어 - **이미지·영상 자동 표시 설정** - `사용자 설정 > 디스플레이 > 메시지`에서 미디어 표시 방식을 조정할 수 있다. - 링크로 게시된 이미지·영상과 Discord에 직접 업로드된 파일을 각각 필요할 때만 열도록 설정할 수 있다. - **링크 미리보기 끄기** - “임베드 및 링크 미리보기 표시”를 끄면 링크 아래에 자동으로 생성되는 미리보기를 숨길 수 있다. - **이미지 설명(Alt Text) 표시** - 작성자가 이미지 설명을 입력한 경우 Alt Text 버튼을 통해 내용을 확인할 수 있다. - 이미지 설명을 기본적으로 확인하도록 설정할 수 있다. - **스포일러 콘텐츠 표시** - 스포일러 처리된 이미지나 영상을 다음 방식으로 표시할 수 있다. - 클릭할 때만 표시 - 항상 표시 - 자신이 관리하는 서버에서만 표시 - **링크 항상 밑줄 표시** - 링크에 색상뿐 아니라 밑줄도 적용해 링크임을 쉽게 구분할 수 있다. - 색상 채도를 낮췄을 때 파란색 링크가 잘 보이지 않는 문제를 보완하는 데 유용하다. ## Discord 색상과 밝기 낮추기 - **전체 인터페이스 채도 조절** - 채도를 낮추면 버튼, 상태 표시, 클릭 가능한 링크 등 Discord UI의 색상 강도가 줄어든다. - “사용자 지정 색상에도 적용”을 활성화하면 역할 색상 등 다른 사용자가 지정한 인터페이스 색상에도 적용된다. - 아바타, 사용자 지정 이모지, 업로드된 사진·영상처럼 사용자가 만든 콘텐츠의 색상은 조정되지 않는다. - **역할 색상을 이름 옆 점으로 표시** - 역할 색상으로 전체 표시 이름을 칠하는 대신 이름 왼쪽의 작은 점으로 표시할 수 있다. - 배경색과 비슷한 역할 색상 때문에 이름이 잘 보이지 않는 문제를 줄일 수 있다. - **HDR 콘텐츠 밝기 낮추기** - HDR 모니터에서 지나치게 밝게 표시되는 이미지·영상의 강도를 낮출 수 있다. - `접근성 > 하이 다이내믹 레인지`에서 전체 동적 범위와 표준 범위 사이를 선택한다. - **표시 이름 스타일 숨기기** - Nitro 사용자가 적용한 특수 글꼴이나 색상 효과가 산만하다면 `접근성 > 텍스트 가독성`에서 “표시 이름 스타일”을 끌 수 있다. - 이 설정은 본인 화면에만 적용되며 다른 사용자에게는 영향을 주지 않는다. ## UI 밀도와 글자 크기 조정 - Discord의 UI 밀도를 조절해 한 화면에 더 많은 정보를 표시하거나, 요소 사이 간격을 넓혀 구분하기 쉽게 만들 수 있다. - 글자 크기와 화면 요소의 크기를 자신의 시력과 사용 환경에 맞게 확대·축소할 수 있다. - 데스크톱, 노트북, 웹 앱 등 사용하는 화면 크기와 목적에 따라 밀도와 텍스트 크기를 다르게 설정하면 읽기 편의성을 높일 수 있다. 눈의 피로가 크다면 먼저 이미지·영상 자동 표시와 링크 미리보기를 끄고, 채도와 HDR 범위를 낮추는 것이 효과적이다. 이후 링크 밑줄, 역할 색상 표시 방식, 이름 스타일 숨기기, UI 밀도와 글자 크기를 조합해 자신에게 가장 편안한 Discord 환경을 구성하면 된다.

discord

디스코드 업데이트: 2026년 3월 24일 변경 사항 (새 탭에서 열림)

디스코드의 2026년 3월 업데이트는 사용자들이 데스크톱 앱에서 보다 직관적이고 빠르게 소통할 수 있도록 내비게이션 성능과 게임 관련 편의 기능을 대폭 강화하는 데 초점을 맞췄습니다. 화면 공유 시의 조작성 향상과 브라우저 방식의 앞/뒤 이동 버튼 도입 등 사용자 피드백을 반영한 실질적인 기능 개선이 이루어졌으며, 전반적인 앱 반응 속도 또한 최적화되었습니다. 이번 업데이트를 통해 사용자들은 대규모 서버 관리부터 개인적인 게임 스트리밍까지 더욱 쾌적한 환경에서 경험할 수 있게 되었습니다. ### 게임 몰입감을 높이는 스트리밍 및 소셜 기능 - **화면 공유 줌 및 팬 기능:** 이제 화면 공유(Screenshare) 시 마우스 휠이나 트랙패드를 이용해 화면을 확대(Zoom)하거나 특정 위치로 이동(Pan)할 수 있어, 복잡한 게임 UI나 작은 텍스트도 선명하게 확인할 수 있습니다. - **간편한 음성 채널 초대:** 음성 채팅 중 '음성 채널 초대' 옵션을 통해 서버 내 친구뿐만 아니라 서버 외부에 있는 가까운 친구에게도 빠르게 참가를 권유할 수 있는 추천 시스템이 도입되었습니다. - **게임 스탯 위젯 확장:** 프로필 위젯에서 지원하는 게임이 추가되었습니다. '명조: 워더링 웨이브(Wuthering Waves)' 계정을 연동해 업적 수나 선호 캐릭터 등 세부 스탯을 프로필에 전시할 수 있습니다. - **마블 라이벌즈 아이템 선물:** 서버 디스커버리를 통해 '마블 라이벌즈' 서버의 게임 샵에 방문하면 위시리스트 아이템을 친구에게 선물하거나 자신에게 직접 구매해 줄 수 있습니다. ### 빠르고 효율적인 앱 내비게이션 최적화 - **성능 및 지연 시간 개선:** 데스크톱 앱 내부 구조를 업그레이드하여 앱 내 메뉴를 이동할 때 발생하는 랙(Lag)을 크게 줄였으며, 전반적인 반응 속도가 눈에 띄게 빨라졌습니다. - **앞으로/뒤로 가기 버튼 추가:** 웹 브라우저처럼 앱 왼쪽 상단에 내비게이션 버튼이 생겼습니다. 마우스의 측면 버튼을 이용한 이동 기능도 지원하여 이전에 방문했던 채널이나 설정 페이지로 빠르게 돌아갈 수 있습니다. - **역할(Role) 구성원 확인:** 채팅창에 언급된 @역할(Role) 태그를 클릭하면 해당 역할을 가진 사용자를 최대 100명까지 즉시 리스트로 보여주어 관리 효율성을 높였습니다. ### 설정 인터페이스 및 개발자 지원 업데이트 - **데스크톱 설정 디자인 개편:** 알림, 음성 및 비디오, 클립, 스트리머 모드 등의 설정 페이지 레이아웃이 정리되었습니다. 더 명확한 문구와 정돈된 스타일을 통해 원하는 옵션을 쉽게 찾을 수 있습니다. - **GDC 2026 발표 내용 공유:** 게임 개발자 컨퍼런스(GDC)에서 발표된 게임 성장 지원 도구들에 대한 정보를 블로그를 통해 공개하며, 개발자들이 디스코드 생태계를 활용할 수 있는 새로운 방법들을 제시했습니다. 데스크톱 앱을 최신 버전으로 업데이트하여 더욱 빨라진 내비게이션과 편리해진 화면 공유 기능을 직접 체험해 보시기 바랍니다. 특히 마우스 측면 버튼을 활용한 앞/뒤 이동 기능은 다수의 서버를 관리하는 사용자들에게 매우 유용한 도구가 될 것입니다.

figma

프레스 스타트: 컨트롤러 (새 탭에서 열림)

게임 인터페이스는 사용자가 어떤 입력 장치를 쓰는지에 따라 형성된다. 초기 게임의 단순한 시작 화면부터 현대 AAA 게임의 복잡한 메뉴·탭·인벤토리 구조까지 발전했지만, 방향키와 버튼을 중심으로 한 컨트롤러는 일관된 탐색 경험과 근육 기억을 유지해 왔다. 앞으로 AR·VR 같은 기술은 입력 장치와 인터페이스의 경계를 물리적 공간까지 확장할 것으로 보인다. ## 게임 인터페이스의 발전 - 1958년의 **Tennis for Two**부터 초기 아케이드 게임까지는 인터페이스가 매우 단순했다. - *Pong*, *PAC-MAN*, *Super Mario Bros.* 같은 게임은 사실상 단일 화면과 시작 버튼만으로 플레이가 가능했다. - 현대 AAA 게임은 다음과 같은 다양한 기능을 제공한다. - 여러 게임 모드 - 캐릭터 및 코스튬 커스터마이징 - 게임 내 상점 - 월드 맵과 인벤토리 - 퀘스트와 설정 메뉴 - 이에 따라 게임 UI는 단일 타이틀 화면에서 메뉴, 탭, 화면 간 연결로 구성된 복합적인 허브 구조로 확장됐다. ## 컨트롤러가 만든 일관된 탐색 원칙 - Atari 2600부터 PlayStation 5까지 컨트롤러는 방향 입력과 버튼을 핵심 구조로 유지했다. - 세대가 바뀌어도 기본적인 조작 방식이 크게 변하지 않아 플레이어는 기존의 근육 기억을 활용할 수 있었다. - 컨트롤러의 공통 규칙은 게임 UI 설계의 기반이 됐다. - 플랫폼마다 완전히 새로운 탐색 방식을 만들 필요가 줄어들어 디자인·개발 비용도 절감된다. - 게임이 거대한 문화 산업으로 성장하고 스트리밍, e스포츠 등으로 확장됐지만, 플레이어와 게임을 연결하는 핵심 장치는 여전히 컨트롤러다. ## 입력 장치가 인터페이스를 결정한다 - 디지털 인터페이스는 사용하는 표면과 입력 방식에 맞춰 설계된다. - 데스크톱: 마우스 - 모바일: 손가락 터치 - TV: 리모컨 - 마우스는 빠르고 정밀하며 여러 버튼을 제공한다. - 화면을 한 번에 가로질러 이동할 수 있다. - 몇 픽셀 크기의 작은 컨트롤도 조작할 수 있다. - 가운데 버튼, 오른쪽 클릭처럼 추가 기능을 제공한다. - 따라서 데스크톱 UI는 작고 밀도 높은 컨트롤과 많은 정보를 한 화면에 배치할 수 있다. - 손가락은 마우스 커서보다 크고 정밀도가 낮기 때문에 모바일 UI는 다음과 같은 특성을 갖는다. - 크고 둥근 버튼 - 충분한 버튼 간격 - 오작동을 줄이는 넓은 터치 영역 - 모바일은 탭, 스와이프, 핀치 같은 제스처도 적극적으로 활용한다. - 마우스와 손가락은 모두 화면의 특정 위치를 가리키는 “포인터”라는 공통점을 가지지만, 정밀도와 조작 방식의 차이가 UI 형태를 바꾼다. ## 2D 메뉴에서 3D 공간으로 - 기존 게임에서는 플레이어가 컨트롤러로 2D 인터페이스를 탐색하고, 게임 속 3D 세계를 조작했다. - 최신 기술에서는 플레이어의 신체와 주변 환경 자체가 입력 영역이 되기 시작했다. - AR·VR 컨트롤러는 기존의 버튼과 방향 입력을 넘어 공간 이동, 손동작, 시선 등 새로운 상호작용을 가능하게 한다. - 입력과 경험의 관계를 분석하면 게임뿐 아니라 차세대 디지털 인터페이스가 어떻게 이동하고 반응해야 하는지도 이해할 수 있다. ## 실용적인 시사점 새로운 인터페이스를 설계할 때는 화면 구성보다 먼저 입력 장치의 특성을 파악해야 한다. 정밀한 마우스에는 높은 정보 밀도를, 손가락에는 큰 터치 영역을, 컨트롤러에는 명확한 방향 이동과 일관된 포커스 규칙을 적용하는 방식이 효과적이다. AR·VR에서는 화면 안의 UI뿐 아니라 사용자의 몸과 주변 공간까지 인터페이스로 고려해야 한다.

figma

“Chat, 우리 망했 (새 탭에서 열림)

소셜 미디어 알고리즘은 유행어를 퍼뜨리는 데 그치지 않고, 사람들이 자신을 표현하고 타인을 이해하는 방식까지 바꾼다. 알고리즘은 특정 커뮤니티의 언어를 맥락에서 분리해 대중화하며, 단어의 의미와 문화적 배경을 재구성한다. 따라서 새로운 표현 자체를 문제 삼기보다, 어떤 플랫폼 구조와 문화적 경로가 그 언어를 유행시켰는지 비판적으로 살펴봐야 한다. ## 인터페이스가 사고와 관계를 바꾸는 방식 - Tinder의 ‘스와이프’는 단순한 조작법을 넘어 호감과 선택을 표현하는 언어가 됐다. - 오른쪽을 긍정적으로, 왼쪽을 부정적으로 인식하는 서구 문화의 상징 체계도 인터페이스에 반영된다. - Marshall McLuhan의 “미디어가 메시지다”라는 개념처럼, 플랫폼의 형식과 기능 자체가 사용자의 행동과 의미 해석을 만든다. - Hinge의 프로필 질문은 사용자를 특정한 서사 방식으로 자기소개하게 한다. - Grindr의 ‘bear’, ‘twink’ 같은 분류 체계는 사용자가 자신의 정체성을 특정 부족이나 유형으로 표현하도록 유도한다. - 즉, 플랫폼은 사용자의 외적 표현뿐 아니라 자기 자신을 이해하는 방식에도 영향을 준다. ## 알고리즘과 ‘맥락 붕괴’ - 인터넷은 특정 커뮤니티에서 만들어진 언어를 더 넓은 대중에게 빠르게 확산시킨다. - 알고리즘은 해시태그뿐 아니라 게시물과 영상에서 사용된 단어 자체를 메타데이터처럼 활용한다. - 특정 집단에서만 통용되던 표현이 ‘For You’ 피드에 등장하면, 이용자는 그 말이 자신의 문화권을 위한 것이라고 오해할 수 있다. - 원래의 역사·공동체·정치적 맥락이 사라진 채 표현만 확산되는 현상을 ‘맥락 붕괴’라고 볼 수 있다. - 예를 들어 ‘slay’는 뉴욕의 흑인·라틴계 게이 남성들이 중심이었던 볼룸 문화에서 출발했지만, 소셜 미디어를 거치며 훨씬 넓은 대중어가 됐다. ## 커뮤니티 언어의 대중화와 의미 변화 - ‘slay’, ‘serve’, ‘queen’, ‘cooked’, ‘ate’, ‘bussin’’, ‘it’s giving’ 등은 볼룸 문화와 AAVE에서 유래한 표현의 사례로 제시된다. - 인터뷰이는 유행어의 상당수가 AAVE 또는 4chan에서 비롯된다는 경험적 견해를 말한다. - 대중화 과정에서 단어는 더 많은 사람에게 사용되지만, 원래의 문화적 의미와 정서적 뉘앙스는 약해질 수 있다. - 인플루언서가 유행어를 사용하고, 알고리즘이 이를 확산시키면서 단어의 인지도와 바이럴성이 서로 강화된다. - 언어 변화는 자연스러운 현상이지만, 어떤 공동체의 표현이 누구에 의해 소비되고 재해석되는지는 살펴볼 필요가 있다. ## 밈을 통한 이념과 문화의 확산 - 밈은 단순한 농담이나 유행어가 아니라 특정 생각과 가치관을 전달하는 매개체가 될 수 있다. - ‘looksmaxxing’이나 ‘-pilled’처럼 인셀 문화에서 사용되던 표현도 밈의 형태로 주류에 진입할 수 있다. - 밈은 거부감이 큰 사상이나 온라인 하위문화의 관점을 재미있는 표현 속에 숨겨 전달하는 ‘트로이 목마’처럼 작동할 수 있다. - 다만 새로운 단어를 사용하는 것 자체가 곧 해롭다는 뜻은 아니며, 그 표현이 어디서 왔고 어떤 관점을 포함하는지 인식하는 태도가 중요하다. ## 언어가 바이럴리티의 지표가 되는 과정 - 오늘날 언어는 콘텐츠의 설명 수단을 넘어 알고리즘이 포착하는 핵심 신호가 된다. - 특정 단어를 사용하면 콘텐츠가 유행 흐름에 편입될 가능성이 높아지고, 다시 더 많은 사람이 그 단어를 접하게 된다. - 플랫폼은 이런 순환을 통해 어떤 표현을 ‘바이럴한 언어’로 만들고, 사용자는 유행에 참여하기 위해 그 표현을 모방한다. - 결과적으로 알고리즘은 사람들이 무엇을 말하는지뿐 아니라, 어떤 단어를 가치 있고 영향력 있다고 느끼는지도 결정한다. 플랫폼에서 유행어를 사용할 때는 뜻만 따라 하기보다 그 표현의 기원, 원래 사용하던 공동체, 현재의 의미 변화를 함께 확인하는 것이 좋다. 서비스를 설계하거나 운영한다면 특정 언어가 어떤 맥락에서 확산되는지와 인터페이스가 정체성 표현에 미치는 영향까지 고려해야 한다.

figma

슬랙래시부터 토글 (새 탭에서 열림)

2023년의 디지털·하이브리드 업무 환경은 새로운 행동과 감정을 만들어냈고, 이를 표현할 새로운 업무 용어도 낳았다. 이 글은 Slack, Zoom, 협업 도구, 멀티태스킹과 관련된 현상을 유머러스한 신조어로 정리하며, 변화한 업무 문화를 이해하고 적응하는 언어를 제시한다. 결국 바쁜 업무 환경을 완전히 없애기보다, 그 안의 불합리함과 재미를 인식하고 더 현명하게 일하자는 메시지다. ### 업무 완성도와 반복 개선 - **Fidelity Fluency** - 프로젝트에 필요한 완성도 수준을 판단하는 능력이다. - 초기 아이디어 스케치에 과도한 시간을 쓰지 않고, 실제 영향력에 맞춰 디테일을 조절한다. - 불필요한 픽셀 단위 수정과 낭비를 줄이는 실무적 감각을 의미한다. - **WIP Waltz** - 진행 중인 작업을 끊임없이 수정하고 반복하는 과정을 춤에 비유한 표현이다. - 매 단계마다 새로운 관점과 개선 사항이 생기지만, 동시에 또 다른 수정 라운드가 시작된다. ### 원격 협업에서 발생하는 순간들 - **Icebroken** - 온라인 회의의 아이스브레이킹에서 지나치게 개인적인 이야기를 꺼내 어색해지는 상황이다. - 친밀감을 만들려던 시도가 오히려 ‘TMI’로 이어지는 순간을 풍자한다. - **Screenshare Scramble** - 화면 공유 직전이나 도중에 민감하거나 부끄러운 브라우저 탭을 급히 숨기는 행동이다. - Zoom 화면에 무엇이 나타날지 모르는 긴장감과 허둥거림을 표현한다. - **Zoombie** - Zoom 회의에 접속해 있지만 실제로는 거의 참여하지 않는 사람을 뜻한다. - 카메라 앞에는 존재하지만 정신적으로는 여러 회의와 화면 공유에 지친 상태다. - **Zoom Zen** - 명확한 안건, 원활한 음소거·해제, 시간 내 종료가 모두 이루어진 이상적인 화상회의 상태다. - 드물지만 회의가 효율적이고 만족스럽게 끝났을 때의 평온함을 의미한다. ### 메시지와 알림의 과부하 - **Keyboard Cardio** - 이메일과 Slack 메시지를 빠르게 입력하고 처리하는 일을 격렬한 유산소 운동처럼 표현한 말이다. - 실제 운동 효과보다는 메시지 작성이 유발하는 긴장과 스트레스를 농담처럼 강조한다. - **Slack-lash** - Slack 알림과 메시지가 한꺼번에 쏟아져 놀라고 압도되는 순간이다. - 디지털 메시지의 폭발적인 유입을 갑작스러운 반동이나 ‘채찍질’에 비유한다. - **Workplace Whack-a-Mole** - 업무, 알림, 이메일이 끊임없이 나타나 이를 계속 처리해야 하는 상황이다. - 하나를 끝내면 곧바로 다른 일이 튀어나오는 업무 환경의 피로와 혼란을 묘사한다. ### 멀티태스킹과 디지털 산만함 - **Toggle Tax** - 여러 업무 사이를 전환할 때 발생하는 인지적 비용이다. - 작업을 바꿀 때마다 집중력을 다시 끌어올려야 하므로, 멀티태스킹이 생산성을 떨어뜨릴 수 있음을 암시한다. - **Tab Tsunami** - 브라우저 탭이 지나치게 많이 열려 화면과 집중력을 모두 압도하는 상태다. - 수많은 정보와 작업을 동시에 붙잡으려는 디지털 업무 습관을 거대한 파도에 비유한다. ### 디자인 시스템과 협업 문화 - **Style Guide Safari** - 스타일 가이드 안에서 색상, 서체, 컴포넌트 등을 탐색하는 과정을 정글 탐험처럼 표현한 말이다. - 디자인 시스템이 풍부하고 복잡할수록 원하는 규칙을 찾아다니는 경험이 모험처럼 느껴질 수 있다. - **Sudden Heavy Stamping** - 협업 중 자신의 아이디어에 갑자기 여러 개의 +1, 하트, 스탬프가 몰리는 순간이다. - 실시간 협업 도구에서 사회적 인정과 즉각적인 피드백을 받는 기쁨을 뜻한다. - **UI Lock Ness Monster** - 다음 업데이트에 포함될 것이라는 소문만 무성하고 실제로는 계속 등장하지 않는 UI 기능이다. - 오랫동안 기대되지만 실현되지 않는 기능을 전설 속 괴물에 빗댄 표현이다. ### 글이 제시하는 업무 문화의 풍경 - 이 용어들은 새로운 기술 자체보다, 기술을 사용하는 과정에서 생긴 감정과 습관을 포착한다. - Zoom 피로, Slack 알림, 화면 공유 불안, 멀티태스킹 비용처럼 디지털 업무의 문제를 유머로 표현한다. - 동시에 비동기 업무, 팬데믹 이후의 업무 전환, 몰입 중심의 업무 방식 등 변화한 일하는 방식을 반영한다. - 이러한 표현은 업무의 혼란을 개인의 실패로만 보지 않고, 많은 사람이 공유하는 문화적 경험으로 바라보게 한다. 업무 효율을 높이려면 `Toggle Tax`를 줄이도록 작업 전환을 최소화하고, `Zoom Zen`을 위해 회의 안건과 종료 시간을 명확히 정하는 것이 좋다. 또한 `Fidelity Fluency`처럼 업무 목적에 맞는 완성도만 추구하면 불필요한 수정과 디지털 과부하를 줄일 수 있다.

figma

기능 비하인드 (새 탭에서 열림)

Figma는 Community 파일에서 사용자와 제작자가 더 깊이 소통할 수 있도록 일반 댓글과 캔버스 위치에 연결되는 컨텍스트 댓글을 도입했다. 기존 에디터 댓글 기능을 그대로 재사용하는 작업으로 시작했지만, 읽기 전용 파일 뷰어를 양방향 커뮤니케이션 공간으로 바꾸면서 UI·성능·공간 설계 문제가 발생했다. 최종적으로는 사용자가 캔버스를 클릭하면 전체 화면 댓글 보기로 전환하는 방향을 택했다. ## 커뮤니티에 댓글이 필요했던 이유 - Figma Community는 파일과 플러그인을 공유하고 발견하는 공간이었지만, 초기에는 제작자와 사용자 간 직접적인 소통 수단이 부족했다. - 글쓴이는 파일의 프로토타입 시작 프레임 오류를 발견했지만, 제작자에게 연락하기 위해 개인 웹사이트와 트위터를 거쳐 이메일을 찾아야 했다. - 이러한 경험을 개선하려면 단순한 리소스 공유를 넘어 질문, 의견, 피드백을 쉽게 주고받을 수 있어야 했다. - 이를 위해 두 가지 댓글 방식을 구상했다. - **일반 댓글**: 파일 아래 피드 형태로 표시 - **컨텍스트 댓글**: 에디터의 댓글처럼 파일 속 특정 위치에 연결 ## 기존 댓글 기능을 커뮤니티에 적용하며 생긴 문제 - 처음에는 기존 에디터 댓글 UI와 코드를 파일 미리보기에 그대로 덧붙이면 될 것으로 예상했다. - 하지만 다음과 같은 기술적 수정이 필요했다. - 뷰포트 정보를 주고받을 수 있도록 기존 iframe 기반 파일 미리보기 구조를 교체 - 댓글 수가 많아질 때 발생할 수 있는 성능 문제 검토 - 더 큰 어려움은 코드보다 상호작용 설계였다. - 에디터 내부 댓글과 비슷해 보이려면, 읽기 전용 커뮤니티 뷰어에서는 오히려 다른 상호작용을 설계해야 했다. - 기존 Community는 제작자가 콘텐츠를 공개하고 사용자가 이를 소비하는 일방향 구조였지만, 댓글은 사용자에서 제작자로 향하는 새로운 소통 경로를 만들었다. - 특히 컨텍스트 댓글은 일반적인 세로형 댓글 피드와 달리 다음 문제를 해결해야 했다. - 댓글을 디자인의 특정 지점에 고정하는 방법 - 댓글을 보면서 캔버스를 이동하고 탐색하는 방법 - 댓글 기능이 기존의 편안한 읽기 전용 경험을 방해하지 않도록 하는 방법 ## 초기 디자인 탐색과 협업 - 엔지니어링, 디자인, 제품 팀은 개발 과정 내내 긴밀한 피드백 루프를 유지했다. - 정적인 와이어프레임보다 댓글 생성과 캔버스 이동을 보여주는 GIF와 인터랙션 프로토타입을 적극 활용했다. - 여러 시안을 통해 다음과 같은 방향을 탐색했다. - 댓글 피드를 배치할 위치 - 캔버스 미리보기에서 댓글을 확인하는 방식 - 댓글 위치를 이해하기 위한 미니 뷰어와 전체 화면 뷰어 - 구체적인 프로토타입 덕분에 기술적 실현 가능성, UI 예외 상황, 출시 일정에 따라 기능 범위를 빠르게 좁힐 수 있었다. ## 초기 출시를 위한 세 가지 목표 - 사용자가 최대한 빠르고 쉽게 댓글 기능에 진입하도록 해 참여를 유도한다. - 컨텍스트 댓글이 달린 파일 위치를 충분히 크게 보여주어 사용자가 댓글의 의미와 디자인 맥락을 이해하도록 한다. - 출시 일정 안에서 구현 가능하고 지나치게 복잡하지 않은 해결책을 선택한다. ## 전체 화면 기반 컨텍스트 댓글 - 위 목표와 제약을 바탕으로 컨텍스트 댓글은 **전체 화면 보기에서만** 표시하도록 결정했다. - 전체 화면은 댓글이 연결된 디자인 영역을 충분히 확인할 수 있는 공간을 제공한다. - 사용자가 축소된 캔버스를 클릭하면 전체 화면 뷰어로 확장되도록 설계했다. - 반대로 축소된 캔버스에서는 클릭과 패닝을 비활성화해, 일반적인 파일 탐색 경험과 댓글 상호작용이 충돌하지 않도록 했다. - 결과적으로 댓글 기능을 기존 파일 뷰어에 무리하게 끼워 넣기보다, 댓글을 확인하고 위치를 탐색하는 별도의 집중된 경험으로 분리했다. ## 실용적인 시사점 기존 기능을 다른 제품 영역에 재사용할 때는 코드 복사보다 사용 맥락의 차이를 먼저 검토해야 한다. 특히 읽기 전용 화면에 편집기용 상호작용을 도입한다면, 기능 자체보다 진입 방식·공간 배치·탐색 흐름·성능과 같은 전체 사용자 경험을 함께 재설계하는 것이 중요하다.

figma

Figma UI 개편: (새 탭에서 열림)

Figma는 기능 구조를 크게 바꾸기보다 타이포그래피, 레이아웃, 색상, 아이콘 등 UI 표면을 다듬는 방식으로 시각적 리프레시를 진행했다. 기존 UI가 제품 성장에 따라 일관성을 잃고 한계에 부딪혔기 때문에, 전사적 브레인스토밍과 이슈 통합, 정성·정량 조사를 거쳐 변경 범위를 결정했다. 핵심은 모든 사용자를 만족시키려 하기보다 문제를 체계적으로 수집하고, 중요한 개선점에 집중하는 것이었다. ## 리디자인이 필요해진 배경 - Figma의 UI는 제품과 기능이 성장하면서 점점 일관성을 잃었다. - 기존 컴포넌트로 새로운 기능을 표현하기 어려워질 때마다 팀이 임시 컴포넌트와 맞춤형 해결책을 만들었다. - 그 결과 다음과 같은 문제가 누적됐다. - 서로 다른 형태의 테이블, 버튼, 입력 컨트롤 - UI 곳곳에 흩어진 여러 색조의 회색·빨강·파랑 - 기능마다 다른 알림과 대화상자 처리 방식 - 가독성, 여백, 아이콘 체계의 불일치 - 마지막으로 UI 전체를 검토했을 때는 아직 Multiplayer나 Components 같은 핵심 기능이 없었다. - 즉, 기존 UI의 기반이 현재의 Figma를 충분히 반영하지 못하게 된 것이 리프레시의 주요 배경이었다. ## 표면적 변화에 집중한 전략 - 목표는 사용자가 큰 혼란 없이 새 UI를 받아들이도록 만드는 것이었다. - 정보 구조나 제품의 기본 동작을 재설계하기보다는 다음과 같은 시각적 요소를 중심으로 개선했다. - 타이포그래피 - 레이아웃 - 색상 - 아이콘 - 컴포넌트의 시각적 일관성 - 출시 전 수개월 동안 정성적·정량적 조사를 진행했다. - 세부 변경 사항마다 여러 팀이 깊이 논의해 최종 결과에 동의하도록 했다. - 특히 디자이너는 시각적 변화에 민감하므로, 리디자인이 모든 사람에게 동일하게 환영받을 수 없다는 점도 고려했다. ## 1단계: 제한 없이 문제 수집하기 - 전체 디자인 팀이 참여하는 2시간 브레인스토밍 세션을 열었다. - 팀원들은 실제로 Figma를 사용하면서 제품의 구석구석을 살펴봤다. - 발견한 내용을 다음 방식으로 기록했다. - UI의 문제점과 불편한 점 - 마음에 드는 부분 - 관련 스크린샷 - 특정 문제가 미치는 영향에 대한 메모 - 모든 결과물을 Figma 파일에 모아 공동으로 검토했다. - 팀원들이 강하게 반응한 문제, 즉 모두가 “이건 심각하다”고 느낀 항목을 별도로 표시했다. - 이 반응은 어떤 문제가 사용자 경험에 큰 영향을 줄 가능성이 있는지 판단하는 초기 신호로 활용됐다. - 브레인스토밍 직후 결론을 내리지 않고 며칠간 거리를 둔 것도 중요했다. 시간이 지나면서 문제의 우선순위와 구성원들의 의견이 자연스럽게 바뀌었기 때문이다. ## 2단계: 문제를 통합하고 범주화하기 - 후속 회의에서 각 문제를 다시 검토하며 처음의 판단을 재평가했다. - 일부 문제는 생각보다 중요하지 않다고 판단했고, 다른 문제는 해결 필요성을 더 강하게 주장할 수 있도록 논거를 보완했다. - 긴 문제 목록을 팀원들에게 나누어 전달하고, 각자가 이를 포스트잇 형태의 짧은 항목으로 재작성했다. - 이 과정에서는 개별적인 증상을 그대로 옮기기보다 공통된 근본 문제로 추상화했다. - 예: “특정 화면의 알림 모양이 다르다” - 통합된 표현: “제품 전체의 알림 처리 시스템이 필요하다” - 비슷한 포스트잇을 함께 묶어 반복적으로 나타나는 주제를 확인했다. - 그 결과 다음과 같은 범주가 도출됐다. - 아이콘, 타이포그래피, 가독성, 색상 - 대화상자, 툴바, 말투 - 에디터와 파일 브라우저 - 모드, 팀 페이지, 속성 사이드바 - 컴포넌트, 레이어, 히스토리 - 공유, 퍼블리싱, 내보내기 - 포스트잇의 반복은 단순한 중복이 아니라 중요한 문제가 여러 방식으로 나타나고 있다는 신호가 되었다. - 다만 범주를 다시 “시각적 문제에서 기초 구조적 문제까지”라는 축으로 정렬하려 한 것은 지나치게 복잡한 접근이었다. ## 범주화 과정에서 얻은 교훈 - 문제를 조직화할 때 지나치게 추상적인 기준을 만들면 오히려 판단이 어려워진다. - “제품의 개성”처럼 거의 모든 문제를 포함할 수 있는 범주는 유용하지 않다. - 반대로 특정 대화상자 하나처럼 지나치게 좁은 범주도 전체적인 개선 방향을 잡는 데 적합하지 않다. - 가장 좋은 범주는 서로 비슷한 문제를 묶으면서도, 실제 개선 작업으로 이어질 수 있을 만큼 구체적이어야 한다. - 완벽한 분류 체계를 만드는 것보다 중요한 문제의 신호를 잡음에서 분리하는 것이 우선이다. ## 실무에 적용할 때의 추천 - 리디자인을 시작할 때 바로 해결책을 만들기보다, 먼저 팀 전체가 제품을 직접 사용하며 문제를 폭넓게 수집한다. - 각 문제를 개별 사례가 아닌 반복되는 시스템적 문제로 재정의한다. - 브레인스토밍 직후 결론을 확정하지 말고 일정한 숙고 시간을 둔다. - 범주화는 단순하고 이해하기 쉽게 유지하며, 지나치게 추상적이거나 복잡한 분류 축은 피하는 것이 좋다.