이모지 복사

이모지는 그림이 아니라 문자다

이 페이지에서 복사하는 것은 텍스트입니다. 활짝 웃는 얼굴은 코드 포인트 U+1F600으로, 영문자 A와 같은 종류이며, 이미지 파일이 아니라 문자로서 클립보드를 거쳐 갑니다.

이모지가 다른 곳에 도착하면 모양이 달라지는 이유가 이것입니다. Apple, Google, Microsoft, Samsung, Twitter는 같은 코드 포인트에 대해 각자 그림을 제작하며, 읽는 기기는 자기 글꼴이 제공하는 버전을 그립니다. 문자는 같고 그림만 다릅니다. 이모지가 주변 텍스트와 함께 크기가 바뀌고, 검색할 수 있으며, 이미지는 못 들어가는 파일 이름이나 커밋 메시지에도 쓸 수 있는 이유이기도 합니다.

차이가 겉모습에 그치지 않을 때도 있습니다. 해석이 다른 곳과 너무 멀어지면 제조사들이 이모지를 다시 그려 왔으며, 모든 주요 플랫폼에서 권총이 물총으로 바뀐 것이 가장 유명한 사례입니다. 그래서 어느 해에 보낸 문자가 다른 해에 읽힐 때 다른 인상을 줄 수 있습니다.

일부 이모지가 보이지 않는 이유

유니코드는 거의 해마다 새 이모지를 추가하고, 기기는 설치된 글꼴이 아는 이모지만 그릴 수 있습니다. 글꼴보다 새로운 이모지는 '두부'라고 불리는 빈 사각형으로 표시되며, 안에 코드 포인트의 16진수가 들어 있기도 합니다.

보이지 않는 것을 복사하지 않도록, 이 페이지는 브라우저가 실제로 그릴 수 있는 이모지를 확인하고 나머지는 숨깁니다. 그래서 목록은 기기와 운영 체제를 최근에 언제 업데이트했는지에 따라 조금씩 다르며, 여기서 보이는 것은 당신에게 보이는 것입니다. 받는 사람에게도 보인다는 보장은 아닙니다. 상대가 오래된 기기를 쓴다면 아주 새로운 이모지는 그쪽에서 사각형으로 도착할 수 있습니다. 중요한 경우라면 오래되고 널리 지원되는 이모지일수록 안전합니다.

시퀀스, 결합 문자, 피부색

많은 이모지는 코드 포인트 하나가 아니라 여러 개로 이루어집니다. 가족, 커플, 직업, 국기는 보이지 않는 폭 없는 결합 문자 U+200D로 여러 문자를 이어 만듭니다. 그 시퀀스를 이해하는 기기는 하나로 합친 글리프를 그리고, 이해하지 못하는 기기는 부분들을 나란히 보여 줍니다. 가족 이모지가 가끔 따로따로인 사람들로 도착하는 이유입니다.

피부색도 같은 방식입니다. 유니코드는 다섯 가지 피부색 수식자를 정의하며, 기본 이모지 뒤에 오는 문자로 적용됩니다. 정의된 것은 일부 이모지뿐으로, 대체로 피부색이 의미 있는 손, 사람, 신체 부위입니다. 여기서는 모두 기본 형태로 복사되며, 피부색은 나중에 자신의 키보드나 휴대폰 이모지 패널에서 적용할 수 있습니다.

이 모든 것의 실무적 결과는 이모지가 코드에서 한 글자보다 긴 경우가 많다는 것입니다. 길이 제한, 데이터베이스 열, 텍스트 자르기 로직은 모두 보이는 글리프가 아니라 부분을 세므로, 가족 이모지 하나가 글자 수 예산의 일곱 단위 이상을 차지할 수 있고, 단순한 자르기 로직에 반으로 잘릴 수도 있습니다.

이모지가 깨지는 곳

대표적인 실패는 utf8로 선언한 MySQL 열입니다. 이것은 UTF-8이 아니라 U+FFFF 위의 문자를 표현할 수 없는 3바이트 부분 집합입니다. 여기에 넣은 이모지는 거부되거나 첫 이모지에서 조용히 잘립니다. 해결책은 utf8mb4이며, 설정이 아니라 스키마 변경입니다.

저장 외에도, 이모지는 의미 있는 순서가 아니라 코드 포인트 순서로 정렬되고, 따로 설정하지 않으면 텍스트 검색에서 대개 보이지 않으며, 이체 선택자를 달고 있어 눈으로는 똑같은 두 문자열이 다르다고 비교될 수 있습니다. 모두 이모지를 피할 이유는 아니지만, 필드가 이모지를 처리한다고 가정하기 전에 하나 넣어 시험해 볼 이유는 됩니다.

새 이모지가 만들어지기까지

이모지는 유니코드 컨소시엄이 운영하는 공식 제안 절차를 거쳐 유니코드에 추가됩니다. 누구나 제안서를 낼 수 있지만, 제안서는 근거를 들어 주장을 펴야 합니다. 예상 사용 빈도, 그 개념이 이미 기존 문자로 표현되는지, 지나치게 구체적이지는 않은지, 한때의 유행에 그치지는 않는지, 사실상 로고에 해당하지는 않는지 같은 것들입니다. 제출된 제안 대부분은 이 가운데 한 가지 이유로 거절됩니다.

채택된 문자는 해마다 한 번 나오는 릴리스로 공개되고, 그다음에는 각 벤더가 자체 디자인을 만들어 운영체제 업데이트로 배포합니다. 새 이모지가 발표되고도 1년 넘게 실제로는 쓸 수 없는 이유가 바로 이 시차입니다. 코드 포인트는 존재하지만 대부분의 기기에는 글리프가 없어 빈 네모 상자가 대신 표시됩니다.

컨소시엄은 문자와 함께 CLDR 데이터도 공개합니다. 이모지마다의 짧은 이름과 검색 키워드를 로케일별로 번역해 둔 자료입니다. 두 개 이상의 언어에서 작동하는 이모지 검색은 이 페이지의 검색을 포함해 모두 이 데이터에 기대고 있으며, 같은 그림을 어디에 있느냐에 따라 서로 다른 단어로 찾게 되는 것도 그 때문입니다.

스크린 리더는 무엇을 읽어 주는가

이모지는 접근성 트리에 이름을 가지고 있고, 스크린 리더는 그 이름을 소리 내어 읽습니다. 이모지가 의미를 담고 있을 때는 유용하지만 그렇지 않을 때는 성가실 뿐입니다. 폭죽 이모지 다섯 개로 끝나는 줄은 다섯 개의 설명으로 따로따로 읽히고, 항목마다 장식용 기호로 시작하는 목록에서는 그 기호가 줄마다 반복됩니다.

쓸모 있는 지침은 이렇습니다. 이모지는 문장 중간이 아니라 끝에 두어, 하나하나 소리 내어 읽히더라도 문장이 매끄럽게 읽히도록 합니다. 컨트롤의 유일한 레이블로 이모지를 쓰지 않습니다. 읽히는 이름이 의도한 뜻과 다를 수 있기 때문입니다. 그리고 장식을 위한 반복은 본문에서 빼 둡니다.

이름이나 핸들 속 이모지는 특히 문제가 됩니다. 그 이름이 나올 때마다 매번 읽히기 때문입니다. 인터페이스가 이를 허용한다면 일반 텍스트로 된 표시 이름도 함께 허용해야 합니다.

데이터베이스에 이모지를 저장하고 검색하기

전형적인 실패는 MySQL 컬럼을 utf8로 선언하는 것입니다. utf8은 3바이트 부분집합이라 U+FFFF 위쪽의 문자를 전혀 표현하지 못합니다. 여기에 넣은 이모지는 거부되거나 첫 이모지 자리에서 잘려 나갑니다. 해결책은 utf8mb4이며, 스키마 변경은 물론 커넥션 문자셋, 그리고 예전 버전에서 애초에 utf8을 고르게 만들었던 인덱스 길이 제한까지 함께 손봐야 합니다.

그다음 놀라움은 검색입니다. 이모지는 코드 포인트 순으로 정렬되는데 이는 읽는 사람에게 아무런 의미가 없고, 전문 검색 인덱스는 따로 설정하지 않으면 보통 이모지를 구두점으로 보고 걸러 냅니다. 사용자가 이모지로 검색할 수 있게 하려면, 현실적인 방법은 문자와 함께 CLDR 이름을 인덱싱하는 것입니다.

비교에는 또 다른 함정이 있습니다. 변이 선택자와 제로 폭 결합자 때문에 똑같아 보이는 두 문자열이 바이트 단위로는 다를 수 있습니다. 비교 전에 정규화하거나, 원시 바이트가 아니라 렌더링된 결과를 비교해야 중복 제거가 제대로 동작합니다.

같은 문자, 다른 그림

벤더마다 그림을 직접 그리기 때문에, 이모지에는 보내는 사람이 통제할 수 없는 어조가 실립니다. 이에 대한 연구 결과는 한결같습니다. 사람들은 같은 이모지를 플랫폼에 따라 다르게, 때로는 정반대의 감정으로 해석합니다. 따뜻한 마음으로 보낸 메시지가 비꼼으로 도착하는 이유가 여기에 있습니다.

벤더들이 서로 수렴하면서 시간이 지나 뜻이 바뀐 문자도 있습니다. 권총은 2016년부터 2018년 사이에 모든 주요 플랫폼에서 물총으로 다시 그려졌고, 몇몇 손동작 이모지는 처음 그림이 특정 지역에서 의도하지 않은 뜻으로 읽히는 바람에 다시 디자인되었습니다.

제품 인터페이스, 고객 응대 메시지, 문서처럼 중요한 자리에서의 실용적인 원칙은 이렇습니다. 오래전부터 쓰여 어디서나 렌더링이 안정적인 이모지를 고르고, 최소한 Apple 기기 하나와 Android 기기 하나에서 확인하며, 텍스트가 담고 있지 않은 의미를 특정 그림에 맡기지 않는 것입니다.

코드와 파일 이름, 식별자 속의 이모지

이모지는 평범한 문자여서 사람들이 예상하지 못한 자리에서도 대부분의 시스템이 받아들입니다. 커밋 메시지, 브랜치 이름, 파일 이름, JSON 키, 일부 언어에서는 식별자까지 가능합니다. 거기에 써도 되는지는 또 다른 문제입니다.

흔한 사례는 커밋 메시지이고, 이 관례에는 gitmoji라는 이름까지 있습니다. 맨 앞의 문자 하나로 변경의 종류를 분류하는 방식입니다. 팀이 그 대응 관계에 합의했다면 잘 굴러가지만, 커밋 메시지를 파싱하는 도구와는 잘 맞지 않습니다. 그림으로 인코딩된 분류는 fix:나 feat: 같은 접두사보다 매칭하기가 훨씬 까다롭기 때문입니다.

파일 이름은 보기보다 위험합니다. 요즘 파일 시스템에서는 살아남지만, 오래된 빌드 도구나 아카이브 형식, 그리고 문자열을 이어 붙여 셸 명령을 만드는 모든 것을 망가뜨릴 수 있습니다. 시스템 경계를 넘나드는 파일이라면 이름은 ASCII로 두고 이모지는 이름이 아니라 메타데이터에 넣는 쪽이 계속 잘 동작하는 방식입니다.