Figma 이모지 출시의

Figma는 사용자 요청이 많았던 이모지 지원을 추가하면서, 운영체제마다 다르게 표시되는 이모지 문제를 해결하고자 했다. 브라우저나 OS의 이모지 렌더링에 의존하지 않고, 개별 이모지를 64×64 컬러 PNG로 제공한 뒤 캐싱하는 방식을 선택했다. 이를 통해 플랫폼 간 일관성과 디자이너가 요구하는 시각적 품질을 모두 확보했다.

이모지가 제품에 필요한 이유

• 이모지는 감정, 말투, 뉘앙스를 전달하는 디지털 커뮤니케이션의 시각 언어로 자리 잡았다.
• Figma에서 실제 서비스 화면을 디자인하려면 광고 문구, 메시지, 트윗 등에 사용되는 이모지도 정확히 표현할 수 있어야 했다.
• 이모지 지원 부족으로 일부 팀이 Figma를 이탈할 정도로 사용자 요구가 컸다.
• Mac에서는 Control + Command + Space, Windows에서는 터치 키보드의 이모지 아이콘으로 입력할 수 있다.

이모지 표준과 플랫폼별 차이

• 이모지는 1999년 일본 휴대전화 사업자가 텍스트만으로 감정을 표현하기 어렵다는 문제를 해결하기 위해 처음 만들었다.
• 통신사마다 자체 이모지 세트를 사용하면서 플랫폼 간 호환 문제가 발생했다.
• 2009년 Unicode Consortium이 이모지를 문자 체계에 포함하고, 각 이모지에 고유 코드 포인트를 부여했다.
• 예를 들어 U+1F355는 피자 이모지를 의미한다.
• Unicode는 코드와 기본 지침을 정의할 뿐, 구체적인 그림의 디자인은 플랫폼에 맡긴다.
• 따라서 같은 이모지도 Apple, Google, Facebook, Twitter, Samsung 등에서 서로 다르게 보일 수 있으며, 감정이나 의미가 왜곡될 위험이 있다.

Figma에서 OS 렌더링을 사용할 수 없었던 이유

• Figma는 Mac, Windows 등 여러 플랫폼에서 협업하므로 모든 사용자가 동일한 디자인을 봐야 한다.
• 브라우저가 운영체제의 이모지 라이브러리를 사용하면 같은 코드가 플랫폼마다 다른 이미지로 렌더링된다.
• 이는 협업 디자인 도구에서 시각적 일관성을 훼손하고, 사용자가 의도한 이모지의 의미를 바꿀 수 있다.

Slack 방식과 한계

• Slack은 Apple 이모지를 표준으로 정하고, 모든 이모지를 하나의 대형 PNG 파일에 담아 자체 호스팅했다.
• 사용자가 이모지를 선택하면 대형 이미지의 해당 영역만 표시하므로 삽입 속도가 빠르다.
• 그러나 PNG 기반 방식은 확대 시 화질이 떨어지고, 저해상도 이미지가 된다.
• 채팅 화면에서는 문제가 크지 않지만, 시각 품질에 민감한 디자이너가 사용하는 Figma에는 적합하지 않았다.

Figma의 개별 PNG와 캐싱 방식

• Figma는 각 이모지를 별도의 64×64 풀컬러 PNG로 제공했다.
• 처음 특정 이모지를 삽입할 때는 이미지를 불러오느라 약간의 지연이 발생한다.
• 이후에는 해당 이미지를 캐시해 재사용하므로 반복 사용 시 빠르게 표시된다.
• 하나의 거대한 PNG를 내려받는 대신 필요한 이모지만 관리해 메모리 효율도 높였다.
• 결과적으로 Slack 방식보다 높은 해상도를 유지하면서도 플랫폼에 관계없이 동일한 이모지를 표시할 수 있었다.

사용자 요구가 제품 이탈과 직결될 수 있는 기능이라면 우선순위를 재평가해야 한다. 특히 협업·디자인 도구에서는 운영체제에 따른 렌더링 차이를 그대로 허용하기보다, 일관된 리소스 제공과 캐싱을 조합해 품질과 성능을 함께 관리하는 것이 효과적이다.