스포카 한 산스2.0에 관한 몇 가지 단편적 사실들

안녕하세요. BX디자이너 김동휘입니다.

스포카에서 했던 프로젝트 중 가장 애착이 가는 프로젝트를 꼽으라면, 스포카 한 산스 프로젝트를 첫째로 꼽을 것입니다. 몇번 이와 관련된 글을 남기려고 했지만, 2.0버전이 나오고서야 글을 쓰게 되었네요.

이 글에선 스포카 한 산스 새 버전 공개를 앞두고 스포카 한 산스 공식 웹에 다 담을 수 없었던 자잘한 업데이트 이야기, 스포카 한 산스에 관한 몇 가지 흥미로운 사실, 그리고 작업자의 소회 등을 단편적으로 기록해보려고 합니다.

1) 영문 대문자 롤백

애초에 스포카 한 산스의 영문 대문자를 커스텀 한 이유는 한글과 영문을 함께 썼을 때 영문의 자간과 자폭이 유독 좁아 보이는걸 보완하고자 함이였습니다.

하지만 실제로 스포카 한 산스로 영문을 타이핑했을 때, 대문자만 쓰면 자간이 너무 벙벙해졌고 소문자와 함께 쓰면 자간이 부조화스러웠습니다. 또한 강제로 넓힌 자폭 및 자간을 다듬는 것은 아마추어가 건들기엔 더 전문적인 지식과 많은 시간을 필요로 하는일이었음을 깨닫고 원래 상태로 돌리기로 했습니다.

2) 대문자 Q의 모양

모든 대문자를 원래 상태로 돌린 건 아니였습니다. 대문자 Q는 디자인에 큰 변화를 겪었습니다.

소문자 y의 꼬리 또한 마찬가지 이유로 커브를 쫙 펴주는 작업을 해주었습니다. 노토산스 CJK KR에 심긴 영문은 한글과의 어울림을 고려하여 디자인된 게 아니고 기존에 있던 오픈산스를 그대로 가져와 옮겨심은 것이기 때문에 완벽하게 매칭된 상태는 아닙니다. 그래서인지 개인적으로도 한글은 다소 딱딱한 느낌인데 반해 영문은 비교적 둥글둥글하다는 첫인상이였습니다. 또한 라토 서체에서 커스텀해 옮겨온 숫자 글리프도 쭉쭉 뻗은 모양새입니다. 이전 스포카 한 산스 작업당시 소문자 l의 꼬리 끝을 과감히 잘라낸 이유 중 하나도 한글 및 숫자 글리프와는 어울리지 않는다 판단했기 때문입니다.

스포카 한 산스 2.0 작업을 하면서 스포카 한 산스의 기존 커스텀 방향을 좀 더 충실히 따르기로 했고 Q와 y도 대세를 따라 둥근 꼬리를 버리고 단호한 꼬리를 달게 되었습니다.

숫자와 함께 쓰인 영문 예시 도판을 보시면 의도가 더 설득될지도 모르겠습니다.

4) “,”와 “?”

, ? 모양도 마찬가지로 대세를 따릅니다. 참고로 쉼표 모양을 변경하면서 참고했던 Apple 산돌고딕 Neo의 경우 , . ? “ ” ‘ ’ 모두 획의 끝을 각진 스타일을 맞춰줬으나 스한스는 그렇게까지는 안 하기로 했습니다.

내가 만약 서체 디자이너라면 각진 스타일을 모두 맞춰주었겠지만, 스포카 한 산스 프로젝트의 최종 목표는 완벽한 서체를 만드는 것이 아니라 우리 서비스에 최적화된 서체를 (빨리) 커스텀하는것이였으므로 타협을 하기로 했습니다. 아래 Apple산돌고딕 Neo 소문자 i와 j의 점 모양을 보시면 타협한 이유가 보이실 텐데요, 이걸 고치기 시작하면 고칠 게 너무 많아지기 때문입니다.

5) 소문자 a

물론 이 모든 변화는 디자이너와 리뷰어들의 취향 또한 반영합니다. 이 변화의 경우 다른 이유보다 취향 탓이 더 큰 듯합니다. 오픈산스의 a는 사발(bowl) 부분이 다소 처진 느낌입니다. 이 사발 윗면의 경사 또한 부드러운 인상에 한몫한다고 판단, 경사를 완만하게 만들었습니다.

6) 숫자폭과 숫자 1, 4 글리프

서비스 특성상 숫자가 잘 읽혀야 하며 숫자의 단위를 가급적 빨리 인지할 수 있게 해야 했습니다. 특히 여러 수치를 리포트 형식으로 보여주는 페이지가 많으며 각각의 데이터값을 쉽게 비교해야 하는 서비스 특성을 반영해 개선했습니다.

노토산스의 숫자를 보면 한글이나 영문 속에서 섞여 있을 땐 글줄이 매끈하게 썩 잘 어울리지만 숫자만 쓰였을 땐 그 장점이 단점으로 작용합니다.

기존 스포카 한 산스는 형태에 대한 커스텀은 라토를 가져옴으로 해결했지만 자폭에 대한 고려는 하지 못했습니다. 왜냐하면 각 숫자 글리프의 형태가 단순한 1부터 양옆으로 빵빵한 8에 이르기까지 다양했기 때문에 각 숫자의 공간을 동일하게 주기 어려웠기 때문입니다. 특히 1의 공간을 해결하기 너무나 어려웠는데요, 이번엔 라토 1의 모양대로 밑에 받침을 넣어주고 상단의 삐침을 길게 빼줘서 고정폭이 되더라도 어색해 보이지 않게 개선했습니다.

라토 4 획의 끝을 각지게 바꾸면서 다소 생뚱맞은 특징이 하나 생겼는데, 이를 반듯하게 다듬어주었습니다. 위의 숫자 1의 변화와 함께 놓고 보면 훨씬 안정적으로 바뀌었음을 느낄 수 있습니다.

8) ☃ 글리프 교체

단순히 귀여움을 위해 눈사람 글리프도 스포카 캐릭터로 심어주었습니다.

9)_, - 수정.

한글, 일본어 및 숫자를 주로 사용하는 서비스 특성에 맞춰, 숫자와 관련된 기호를 영문 소문자 디센더를 상대적으로 덜 고려한 위치로 옮겼습니다.

수학 공식의 마이너스 부호는 너비를 늘리고 커스텀한 숫자에 맞춰 높이를 약간 낮췄습니다. 고객이 태블릿 입력창에 기입한 휴대폰 번호의 가독성이 높아야만 했기 때문에 너비를 충분히 넓혀주어 앞뒤 숫자들이 명확히 구분되게끔 했습니다.

이런 변화는 숫자의 변화와 마찬가지로 인쇄를 위한 매끈한 글줄을 조판하고자 할 땐 거슬릴 수 있습니다. 키보드에 있는 마이너스 부호는 수학 공식에 쓰이기도 하지만 하이픈이나 구간을 나타내는 엔대시와도 혼용하고 있기 때문입니다. 엔대시가 포함된 글 한 단락을 조판한다고 가정했을 땐, 이런 변화는 글줄이 다소 끊겨 보일 테니 말입니다.

10) <, >

키보드에 ‘<’, ‘>’는 사실 수식의 부등호란 사실 알고 계셨나요?(…) 나 또한 스포카 한 산스 커스텀 하면서 알게 된 사실입니다. 허나 이미 수많은 사람이 이를 괄호처럼 사용하고 있으므로, 이게 괄호처럼 쓰여도 과히 이상해 보이지 않았으면 했고 이를 반영한 결과가 다음과 같습니다. 물론 수학 부등호와 괄호를 분명히 구분해주는 것이 맞지만, 많은 사람들이 귀찮고 특수문자를 찾아 넣기 힘들다는 이유로 혼용하고 있기 때문에 이를 무시할 수 없다고 생각했습니다.¹

참고로 과거의 나와 많은 사람이 <, >와 혼용하는 이 부호의 명칭은 꺾쇠괄호 혹은 홑화살괄호 〈 〉라고 합니다.

11) |, \, /, (, ), {, }, [, ] 위치 및 길이 수정

노토산스CJK KR의 경우 영문의 어센더 디센더를 모두 고려한 길이와 위치로 설정되어있었습니다. 그래서 한글이나 숫자, 그리고 디센더가 없는 영문 글리프와는 좀 어색한 모양새입니다. 모두 고려해주면 좋겠지만, 당장은 한글과 숫자 사용이 월등히 많으므로 한글과 숫자에 어울리는 길이와 위치로 변경해주었습니다. 단 완벽하게 한글과 숫자에 최적화를 한 건 아니며, 어쩌다 영문 소문자와 함께 쓰여도 이상하지 않을 정도로 타협을 보았습니다.

참고로 산돌 네오고딕의 경우, 노토산스 CJK KR과 달리 영문서체도 모두 산돌에서 제작을 했음을 생각하면 영문의 디센더와 어센더의 높이를 한글에 맞게 길들인 것으로 짐작이 됩니다. 따라서 버티컬 라인의 위치와 길이가 별다른 조정 없이도 한글, 영문, 대소문자 숫자 모두 잘 어울립니다.

(, ), {, }, [, ]도 디폴트값이 영문을 기준으로 되어있던 위치를 한글과 숫자 위주로 조절해주었습니다.

12) ※, 〶, ‹, ›, «, », 『, 』, 「, 」, 『, 』, 「, 」, 《, 》, 〈, 〉

각종 글리프 중 자주 쓸만한 글리프들의 굵기를 웨이트에 맞아 보이게 조절습니다.

『, 』, 《, 》, 「, 」, 〈, 〉의 경우 사실 유니코드 표준상으로는 전각이 맞습니다.² 하지만 한글 조판 방식의 특성이 고려가 안 된 표준이라 글자 사이를 엄청나게 띄워놓아 가독성을 해치고 글줄에 구멍을 만듭니다. 물론 어도비 프로그램에서는 몇 가지 설정으로 쉽게 미세조정이 가능하나 디자인 툴이 갖춰져 있지 않거나 웹앱 등에서는 미세조정이 불가능하므로 강제로 반각으로 고쳤습니다.³ 그러고 보니 스포카 한 산스의 커스텀 내용 중 많은 수가 디자인툴에서만 수정 가능한, 하지만 범용 애플리케이션에서도 니즈가 있던 부분들을 적용해주는 작업이네요.

13) ¥ $ ₩ %

숫자 글리프를 전면 수정하면서, 숫자와 주로 함께 쓰이는 통화기호도 숫자 외형 변화에 발맞춰야 했습니다.

퍼센트 기호의 경우, 스한스 버전 1 때는 단독으로 예뻐 보이는 방향으로 취향껏 고치는 바람에 똥글똥글한 모양에 세로획이 다소 두꺼운 모양이었으나, 숫자 0과 영문 Oo과 잘 어울리지 않는다고 판단, 기존 모양으로 돌아가 획 굵기만 재수정하였습니다.

14) 각종 글리프 패스 정리

다소 부끄러운 고백이나, 폰트랩이 익숙지 않아서 처음 스포카 한 산스 작업할 땐 수정하고픈 글리프를 모두 일러스트레이터로 그려서 폰트랩에 옮겨오는 식으로 작업했습니다. 이 과정에서 패스가 일그러지는 부분들이 다수 생겼고, 2.0작업하면서 거의 모두 폰트랩으로 다시 그리거나 패스를 정리하였습니다. 웹에서 보면 그리 티 나지 않지만 디자인툴인 일러스트레이터나 인디자인으로 써놓고 크게 확대해보면 일그러진 패스들이 보입니다.

15)

“스포카”를 검색하면 가장 먼저 뜨는 연관검색어는 스포카의 서비스인 “도도 포인트”가 아니고 “스포카 한 산스”입니다. 스포카에서 진행한 오픈소스 프로젝트 중 가장 흥한 프로젝트는 스포카 한 산스 프로젝트라고 내부적으로 평가하기도 합니다.

16)

처음 스포카 한 산스를 공개했을 땐 피드백과 문제를 받기 위한 메일주소를 공개했었습니다. 덕분에 유익한 피드백을 받기도 했었지만 한편으론 우리도 끝내 해결 못 한 문제나 노토산스 자체 버그를 해결해달라는 문의도 많이 들어왔습니다. 현재는 해결 못하는 문제들을 기록하는 채널을 통일하고, 다른 분들도 모두 이슈를 확인하실 수 있도록 github 이슈로만 제보 받고 있습니다. 직접 해결해드리고 싶지만 본업이 서체 디자이너나 서체 개발자는 아닌지라 안타까운 마음일 뿐…

17)

한번은 스포카 한 산스 적용 중에 생긴 문제 해결을 위해 자사에서 사용 중인 개발 디테일을 알려달라는 메일이 오기도 했었습니다. 이에 개발 디테일은 공개할 수 없다고 답변드리자 스포카 한 산스 프로젝트 전체를 총체적으로 폄하하는 메일을 받기도 했었습니다. 당시엔 황당했지만 지금은 오픈소스 프로젝트에 대한 견해나 이해도 차이가 낳은 헤프닝이라고 생각합니다.

18)

사용문의 메일이 (아직도) 심심찮게 옵니다. 주로 기업에서의 사용문의인데, 여러분 그냥 묻지 말고 쓰셔도 됩니다.

19)

경쟁사에서 본인들 웹사이트에 해당 서체를 사용하는 걸 발견하고 모두가 어이없어했는데, 그로부터 몇 개월 후 스포카는 그 경쟁사를 인수하게 되었습니다. ⁴

20)

2017년 2월부터 산돌커뮤니케이션의 서체 관리 프로그램인 ‘구름다리’를 통해 스포카 한 산스 2.0 버전을 제공하게 되었습니다. 산돌커뮤니케이션은 바로 노토산스CJK KR의 한글을 제작했던 서체 회사입니다.

21)

스포카 한 산스 프로젝트를 하고 난 후, 이따금 내가 처음부터 만들지도 않은 서체를 우리 회사 이름을 붙이고 적극적으로 홍보하는 것에 대해 가끔은 떳떳하지 않은 기분을 느꼈습니다. 나는 서체 디자이너가 아니며, 그렇기때문에 아무리 우리가 쓰기 좋게 만들었다 한들 서체만을 전문으로 디자인하는 전문가 입장과는 상충할 수밖에 없다고 생각했습니다. 커스텀 퀄리티에 대해 자신이 없기도 했고요.

하지만 최근에 한글타이포그래피학교에서 진행하는 안삼열 님의 섞어짜기 특강을 들을 기회가 생겼고 우리의 방향성은 틀리지 않음을 확인했습니다.⁵ 한글과 영문을 함께 쓴다는것은 두 문명의 충돌이기에 모든 조건에 100% 만족하게끔 섞어 쓰는 건 어려운 일이고, 어떻게 서로를 “길들”일지는 디자이너의 선택에 따라 방향이 달라질 수 있는 것이지요. 어떤 의도로, 무엇에 초점을 맞춰 서로를 길들일지 판단하는 것은 디자이너의 몫인 것입니다.

스포카 한 산스가 어디에 주로 쓰일 것인지 명확했고, 철저히 그 조건에 부합하려고 노력했습니다. 노토산스CJK KR은 한글을 디자인한 디자이너가 영문이나 기타 글리프를 직접 디자인한 게 아니고 오픈산스를 가져와 붙인 것입니다. 물론 한글과 영문을 함께 쓰기에 부족함이 없도록 노력한 흔적들이 많고, 디자이너라면 이를 잘 찾아 적용할 수 있을 겁니다. 하지만 일반인들이 이런 방법을 알기는 힘들며, 앞서 말했듯 범용 애플리케이션에서 적용하기엔 어려운 점이 있습니다. 그럼에도 불구하고 노토산스CJK KR은 장점이 압도적인 서체이고, 감사하게도 오픈소스로 풀리는 바람에 우리 같은 아마추어도 서체를 새로 만드는 수고에 비해 아주 적은 노력만을 들여 개조할 수 있었습니다. 우리가 개발자 문화에 친숙했고, 오픈소스란 개념이 낯설지 않았던 덕택에 이런 문명의 혜택(?)을 입을 수 있었던 것입니다.

이제는 이 프로젝트가 일종의 “리메이크”에 가깝다고 느낍니다. 상황에 맞게 기성 음악을 믹싱해서 틀거나 원하는 의도대로 리메이크 하듯, 우리도 서체를 리메이크한 것이지요.

현재, 다른 웹사이트에서 심심찮게 스포카 한 산스를 발견할 수 있습니다. 숫자를 많이 쓰는 기업의 웹사이트에서 스한스를 많이 적용한 걸 보면 장점이 명확한 걸로 보입니다. 물론 우리 제품에서도 잘 쓰고 있고요. 이 정도면 꽤 성공한 프로젝트 아닐까요?

22)

Contributor : 김동휘, 강영화

Reviewer : 김예지, 박지선, 정희연

Technical assistance : 양천웅, 홍민희, 문성원, 유은총, 김재석, 박준규, 최종찬, 강성용

Inspection of English contents : 옥지혜