UX writing의 3원칙이라는 것이 딱히 정해지지는 않았지만, 일반적으로는 정확성·일관성·간결성+직관성을 뽑곤 합니다. ‘그중 제일은 사랑이라’ 같은 느낌으로, 가장 중요한 원칙은 정확성이라고 생각합니다. Writer를 뽑는 면접을 볼 때에도 정확성에 대해 어떤 생각을 갖고 있는지 깊게 묻곤 합니다. 물론 제가 인터뷰이가 되어 답할 때도 정확성에 대한 제 신념(?)을 밝히곤 했습니다.
아니 이보시오, 톤 앤 보이스가 다 무슨 소용이란 말이오. 정확성이 와따요. 거짓말하는 것들은 혀를 뽑…
(취업을 위해 여기까지 하는 것이 좋습니다)
UX/UI의 표지판 – UI text
내비게이션 없는 차를 타고 고속도로를 달릴 때, 우리가 의지할 것은 오로지 도로 표지판입니다. 마찬가지로 UX/UI에서 표지판이라고 하면 당연 Label, UI 텍스트죠. 당신이 상형 문자를 쓰는 고대 이집트인을 대상으로 서비스를 기획하고 있는 것이 아니라면, 텍스트만큼 사용자의 방향을 안내하고 다음 행동을 지시할 정도로 효율적인 UI 요소는 없습니다.
여담으로 가끔 텍스트 요소를 극단적으로 줄인 UI를 보게 됩니다. 디자이너는 본인의 훌륭한 그래픽 역량을 사용해서 아이콘과 GUI 디자인, 인터랙션만으로 사용자를 원하는 방향으로 인도할 수 있다고 생각했는지 모르겠지만… 음… 개인적으로는 답답하게 느껴지는 경우가 많았습니다.
마치 이집트 상형문자를 해석하는 느낌? <가족 오락관>의 ‘몸으로 말해요’를 보는 느낌? 디자이너가 갖고 있는 기의·개념·표현 방식이 나의 그것과는 맞지 않아 명탐정 코난이라도 된 듯 화면을 어렵게 탐색해야 할 때… 나도 모르게 그런 생각이 떠오르곤 했습니다.
이럴 거면 그냥 말로 해…
어찌 되었든 간에, UX/UI의 표지판인 레이블의 가장 중요한 역할은 정보 전달입니다. 크게는 앱이나 서비스·프로덕트의 공식 명칭이, 작게는 메뉴·콘텐츠·화면∼버튼 등의 컴포넌트 이름과 설명이 모두 소중한 정보가 되어 표지석이자 표지판의 역할을 합니다.
그뿐만이 아닙니다. 눈에 보이는 것들의 이름뿐만 아니라 눈에 보이지 않는 액션·과정·시간의 이름·설명 등도 너무나 귀중한 정보죠. 두 번 빠르게 클릭해야 나오는지, 끌어당겨야 하는지, 밀어야 하는지 사용자의 액션을 정확하게 지정하고 묘사해줘야 합니다. 행위의 선후 중계, 눈에는 보이지 않았지만 사용자 모르는 사이에 생긴 오류의 상황 등 UI를 여행하는 사용자에게 텍스트화될 수 있는 정보는 무궁무진합니다. 이처럼 광범위한 정보를 표현할 때 가장 중요한 가치는 다시 말하지만 정확성입니다.
물론 그 외의 요소도 상당히 중요한 영향을 미칩니다. 잠깐 이야기하고 넘어가자면, 정보가 제공되는 위치가 그중 하나죠. 어떤 UI를 보면 화면의 코어 영역에 쓸데없는 정보를 때려 넣어 놓았습니다. 그러면 저절로 어흥! 소리가 나오죠.
아니, 여기가 땅값이 얼만데 이 공간을 이렇게 낭비하냐!
(물론 실제로는 ‘아… 이 자리가 참 귀중한 자리인데 말이죠, 이 내용을 넣기에는 참으로 아깝네요…’ 라고 말합니다)
정보 출현 시점 역시 중요합니다. 세상 친절한 디자이너가 생뚱맞은 시점과 배경 위에 팝업이나 토스트를 제공하려고 할 때, 조용히 다가가 입술 위에 손가락을 올리고 ‘쉿! 우리 지금은 아무 말도 하지 말기로 해’라고 은근하게 말리는 것이 UX writer의 일이기도 합니다.
아무튼 간에 표지판은 1) 정확한 정보를 담고2 ) 핵심 요지에 3) 나와야 할 시점에 등장해야 합니다. 이번 글에서는 그중 1번, 정확한 정보를 담는다는 것에 대해 집중적으로 설명해 보려고 합니다.
여담이지만 경부 고속도로를 타고 서울에서 분당으로 가다 보면 정말 생뚱맞은 위치에 아시안 하이웨이 표지판을 보게 됩니다. 혹시 보신 분 있으실까요? 빨간 버스에서 저 표지판을 볼 때마다 도대체 저것의 존재 의의는 뭐지 싶었습니다. 아시아 교통망 통합이라는 취지는 그렇다 치고, 정보의 질·제공 위치·나와야 하는 시점 모두에서 뭐 하나 빠지지 않고 생뚱맞은 표지판이라고 생각했어요.
이 아시안 하이웨이 표지판 같은 레이블이 UI를 망치지 못하게 하는 것. 그것이 이 UX writing 시리즈를 쓰는 이유입니다.
틀린 정보를 제공하지 않는다
정확하다는 것은 무엇일까요? 어떻게 쓰면 정확하게 쓰는 것일까요? 개인적으로 저는 다음 4가지 원칙에 충실하다면 정확하게 쓴 레이블이라고 생각합니다. 하나하나 설명해 보죠.
우선, 틀린 정보를 제공하지 않는다는 것입니다. 말 그대로 A를 A라고 말해야지 B나 C로 말하지 않는다는 것이죠. 사실을 사실 그대로 설명하는 일은 무척 쉬워 보입니다만, 막상 해보면 쉽지 않습니다. 대부분의 디자이너와 기획자는 명민하시기 때문에 대놓고 거짓말을 하거나 틀린 정보를 끼워 넣는 일은 거의 없습니다. 말을 안 하는 경우나, 표현력이 부족한 경우가 많지 나쁜 의도를 가지고 사용자를 교란하려는 사람은 분명 거의 없습니다.
대신 상황이 그들을 거짓말쟁이로 만드는 일이 더 많죠. 규모가 큰 앱의 경우 그 앱에 관련된 사람이 너무 많고, 관련된 텍스트도 수도 없이 많기 때문에 잠깐 정신을 놓으면 저도 모르는 사이에 스펙은 변했는데 텍스트는 그대로인 상황이 발생하게 됩니다. 분명히 내가 그 텍스트를 작성해서 넣었을 때에는 진실이었지만, 앱 업데이트를 통해 스펙이나 화면 구성이 미묘하게 변하면 나도 모르는 사이에 정확하지 않은 텍스트가 사용자에게 제공되는 것입니다.
가장 찾기 쉬운 사례는 스펙 변화(디자인, IA 변경)에 따라가지 못 하고 레이블에 담긴 위치 경로가 잘못된 상태로 혼자 남겨지는 케이스입니다. 아시다시피 화면 내 위치 경로를 하나하나 써주고 거기서 뭔가를 해보라는 가이드를 제공하는 것은 상당히 구질구질합니다. 마음 같아서는 링크 걸어서 누르면 바로 랜딩 화면으로 보내주고 싶지만, 여러 가지 문제로 링크를 사용해 원하는 화면에 바로 떨어뜨리는 것이 쉽지 않죠. 그럴 경우에는 팝업이나 화면 디스크립션으로 사용자의 기억력에 의지하는 텍스트를 제공할 수밖에 없습니다. 이렇게 말이죠.
이 기능을 사용하려면 설정> 권한> 카메라 사용 기능을 켜주세요.
특히 3rd party 앱에서 기기 설정에 들어가 옵션을 켜야 할 경우에는, 기기의 설정으로 바로 보내기 어려운 경우가 많습니다. 그러니 이런 류의 텍스트는 불가피하게 존재하게 됩니다.
잦은 화면 변경으로 인해 랜딩 위치가 변경된 경우, 또는 어떤 이슈가 있어서 화면 내 기능이 사라진 경우, 아예 메뉴명에 변경이 생긴 경우 텍스트를 똑바로 변경해 주지 않는다면 정확하지 않은 레이블을 의도치 않게 후생산(?)할 수 있습니다. 부정확한 레이블을 본 착한 사용자가 레이블이 시키는 대로, 기억력을 총동원해서 경로를 잘 외워서 찾아갔더니 “뭐야… 아무것도 없잖아ㅠㅠ” 같은 미안한 상황이 되는 것이죠.
단순히 실망에서 끝나면 다행입니다. “이 서비스, 고객에게 거짓말하는군?” 또는 “뭐야, 허술하잖아? 이런 서비스를 믿을 수 있겠어?” 이렇게 서비스에 대한 신뢰도가 떨어지는 게 정말 최악이겠죠. 내 화면뿐만 아니라 내화면을 refer하고 있는 화면, 내가 refer하고 있는 기능들을 주의 깊게 보아야 할 필요가 있겠습니다.
필요한 정보를 반드시 밝힌다
정확하게 쓴다는 것은, 필요한 정보를 모두 밝힌다는 것이기도 합니다. 지금 이 시점에 알아야 할 것들을 사용자에게 알리지 않는다면 정확하게 쓴다고 말하기 어렵겠죠. 제공하는 내용의 정확도만 문제가 되는 것이 아닙니다. 제공해야 할 것을 하지 않아서 상황이 불명확하게 되는 것도 정확성을 해치는 일입니다.
쉽게 접할 수 있는 예로 오류 메시지를 살펴봅시다. 서버에 문제가 생겼거나, 네트워크 오류가 났거나, 사용자가 데이터를 꺼놨거나 등등 오류 메시지는 항상 든든하고 풍성하게 준비되어 있어야 하고, 가능하면 세분화해서 준비해 두는 것이 좋습니다.
다음 메시지들을 보면서 어떤 차이가 있는지 살펴봅시다. 어느 날 제게 사용자가 비밀번호를 5번 잘못 쳐서 로그인이 24시간 동안 막히는 상황에 화면에 띄울 팝업이 의뢰되었습니다.
로그인 오류가 발생했습니다. or 로그인에 실패했습니다.
이런 메시지를 팝업도 아니고 토스트로 써달라는 요청을 받을 때 약한 현기증이 올라오곤 합니다. 우리가 뭔가 말을 해줘야 사용자가 힘을 내서 전진을 해볼까 말까 이런 상황인데, 덜렁 ‘오류가 발생했어’ 또는 ‘너 실패했어’만 알려준다면 과연 정확한 정보를 제공했다고 할 수 있을까요? 정말 우리가 서비스 제공자의 의무를 다했다고 할 수 있을까요?
단언컨대 이렇게 알맹이가 없는 데다가 부정적이기까지 한 실패 선언은 사용자와 서비스 제공자 모두에게 도움이 되지 않습니다. 그럼 이런 케이스에서 정확한 정보를 제공한다고 말할 수 있으려면 어떤 레이블을 써야 할까요?
스펙, 개발 제약 등을 고려해 케이스마다 조금씩 정보량을 조절해서 작성해야 하지만, 보통은 이런 방식으로 구성하도록 제안드립니다.
비밀번호가 5회 연속 일치하지 않아 24시간 동안 로그인할 수 없습니다. 나중에 다시 시도해 주세요.
1) 오류의 상황 및 원인 2) 앞으로 일어나게 될 일 3) 재시도 가능 여부 4) 재시도 가능 시점 등을 모두 밝혔습니다. 왜 이런 내용까지 밝혀야 하는지, 추가 정보는 어디까지 알려줘야 하는지는 에러 텍스트 작성 원칙에 대해서 논의하는 글에서 조금 더 자세하게 설명하도록 하겠습니다.
중요한 것은 초안과 같은 단정적인 실패 선언 대비 UX writing으로 작성한 팝업 문구에서는 현재의 상황과 향후 대안을 핍진하게, 정확하게 설명하려 했다는 것입니다.
누군가 이 레이블을 보고 설명충이라고 놀려도 상관없습니다. 간결성이 떨어진다고 말할 수도 있겠지만, 역시 상관없습니다. 누가 이걸 다 읽고 앉아있냐고 빈정대는 것 역시 상관없습니다.
UX writing을 할 때, 아니 UX/UI 작업을 할 때에도 우리는 핵심 가치들이 서로 상충하는 상황과 매우 자주 맞닥뜨리게 됩니다. 이때 저는 단호하게 우선하는 가치의 손을 들어야 한다고 생각합니다. 이 시점에 사용자에게 필요한 정보라면, 한 발자국 사용자를 나아가게 할 수 있다면, 우리 서비스를 신뢰하게 할 수 있다면 길더라도 다소 장황하게 느껴질 수 있더라도 그 문장은 반드시 써야 합니다. 말해야 할 때 침묵하는 것. 그것도 거짓말이기 때문입니다.
1차 세줄 요약
- Label, UI text는 UX/UI의 표지판입니다. 표지판은 1) 정확한 정보를 담고 2) 핵심 요지에 3) 나와야 할 시점에 등장해야 합니다.
- 정확하게 쓴다는 것은 틀린 정보를 제공하지 않는다는 것입니다. 처음부터 거짓말하는 사람은 잘 없지만, 스펙·디자인 변경으로 인해 원치 않게 부정확한 정보를 제공하게 되는 일 등이 빈번하게 발생합니다. 잘 챙깁시다.
- 정확하게 쓴다는 것은 알려줘야 할 정보를 모두 알려준다는 것을 의미합니다. 간결성, 전달 효율성 등을 핑계 삼아 필요한 정보를 빼먹지 맙시다. 우선하는 가치는 언제나 정확성입니다.
포괄적으로 쓰지 않는다
‘아이디 또는 비밀번호를 잘못 입력하셨습니다’는 하루에서 수만, 어쩌면 수십만의 사람을 힘들게 하는 에러 메시지일 수 있습니다. 딥빡을 불러오는 이 해묵은 메시지에 대해서는 저도 쓴 사람에게 물어보지를 못해서, 추측만 해볼 뿐입니다.
아마도 보안 때문이겠죠. 아이디, 비밀번호 중에 어떤 것이 틀렸는지 명확하게 밝힌다면 그만큼 외부의 해킹이나 공격에 취약해질 수 있기 때문이 아닐까 짬밥에 의거하여 막연하게 생각해 봅니다.
위 에러 메시지는 어쩐지 이유가 있을 것 같아서 그렇다고 쳐도, 이유 없이 모호하게 제공되는 메시지는 꽤나 많습니다. UX writer로 일하면서 제가 가장 많이 듣는 코멘트 중엔 이런 게 있습니다.
나중을 생각해서 포괄적으로 사용할 수 있게 써주세요. ‘에러가 발생했습니다.’ 이거 어때요?
디자이너나 개발자의 입장에서 에러 메시지는 적으면 적을수록 좋겠죠. 관리 차원에서 하나의 메시지를 아무 때나 불러다 쓸 수 있으면 편하기야 할 겁니다. 그렇지만 과연 오류 상황에 사용자도 그렇게 생각할까요?
필수 항목 입력이 빠졌을 때, 이메일을 입력해야 하는데 형식에 @가 빠졌을 때, 서버가 다운되어서 당장 뭔가 할 수 없을 때에도 모두 동일하게 ‘에러가 발생했습니다’를 뿌린다면 사용자가 그 문제를 해결하기는 쉽지 않을 겁니다. 결국 만드는 사람만 편하고, 쓰는 사람은 불편한 서비스가 탄생하게 되는 거죠.
뿐만이 아닙니다. 앵무새처럼 무슨 문제만 생기면 ‘에러가 발생했습니다’만 보여주는 서비스를 보며 사용자가 이 서비스가 제대로 돌아가고 있다고 생각하기도 어렵겠죠. “와 이 서비스 참 정성 없다… 대충 만들었네…” 이런 인상을 받을 확률이 높습니다. 저는 일하면서 이런 말도 자주 듣곤 했습니다.
나중에 스펙이 확장될 수 있으니까 그거 고려해서 써주세요. 일단 기능명 밝히지 않고 다 커버할 수 있게 ‘기능이 실행되었습니다’ 같은 걸로?
이런 말을 들을 때에는 ‘백 년도 못 사는 중생들이 천년을 걱정하는구나, 허허허…’ 같은 말을 남기고 흰 수염을 흩날리며 구름을 타고 멀리 사라지고 싶은 욕망이 솟구쳐 오릅니다.
우리가 이 서비스의 이 기능을 내년 이맘때에도 담당하고 있을지는 아무도 모릅니다. 사실 이 기능을 디자인하는 디자이너, 개발자, 더해서 저까지 이 회사를 내년에 다니고 있을지 없을지도 모르는 상황이죠(물론 저는 회사 오래 다니고 싶습니다만… 굽신굽신)
그런데 앞으로 스펙이 확장될 수 있으니까, 또는 변경될 수 있으니까 그 상황도 커버해줄 수 있는 그런 메시지를 적어달라고 요청하는 건 좀 아니다 싶습니다. 해당 서비스 개선 방향이 확정된 것도 아닌데, 벌써부터 미래를 고려해서 메시지를 써야 할까요? 현재의 사용성을 포기하면서까지? 성장기 어린이 겨울 점퍼 사듯 미리부터 큰 옷, 그러니까 미리부터 크게 포괄할 수 있는 메시지를 작성할 이유가 없습니다. 아시다시피 아이 옷은 딱 맞춰서 입혀야 예쁘다고요.
이런 식의 모호하고 포괄적인 형태로 작성해달라는 요청이 왜 디자인이나 개발이 아닌 writer에게만 유독 몰릴까요? 한번 생각해 본 적이 있습니다. 아마도 디자인이나 개발은 원하는 방식으로 움직이게 하기 위해서 타깃과 직접적인 연계성을 가지고 설계되어야 하지만, 텍스트는 굳이 그렇지 않아도 되지 않으니까? 라고 잘못 생각하고 있기 때문이 아닐까요? 일단 이게 지금까지의 제 추측입니다.
또 처음부터 설계 시에 해당 케이스들이 분리될 거라는 것을 생각 못 하고 기획·개발·디자인까지 다 나왔는데 알고 보니 케이스를 분기 쳐야 하는 것이 나중에 밝혀질 수가 있습니다. 세상 당황스럽고 귀찮은 상황인데 릴리즈는 또 얼마 안 남았어요. 바로 그때 디자이너 입에서 ‘일단 에러 상황을 다 포괄할 수 있는 메시지로 써주세요. 다음 phase 때 고칠게요.’와 같은 코멘트가 나오게 되는 것 같기도 해요. (그런 말 들을 때 제 표정은 이미 돌덩이)
이런 포괄적이고 모호한 메시지를 작성하지 않기 위해 제가 추천드리는 방법은 다음 두 가지입니다.
- 주어는 정확한 기능명을 사용하고, 서술어는 실질적인 의미를 가진 동사로 씁니다.
- ‘또는’, ‘혹은’, ‘거나’와 같이 상황을 2개 이상 제시하는 접속사를 사용하지 않습니다.
이 두 개만 잘해도 나도 모르게 포괄적이거나 모호한 표현을 쓰는 일을 방지할 수 있습니다.
명확한 표현으로 정보를 설명한다
이것에 대해서는 너무나 말하기 어렵지만, 말을 아니 할 수 없습니다. 일하다 보면 생각보다 표준어를 구사하지 못하는 사람, 그러니까 맞춤법을 틀리는 사람, 파워 당당하게 비문을 쓰는 사람을 많이 만납니다. 센스도 있고, 감각도 있고, 커뮤니케이션 스킬도 좋고 디자인도 잘하는데 아아아… 글을 못 쓰는 디자이너를 볼 때마다 마음이 무너집니다. 아이고 이 사람아…
내 마음은 그것이 아닌데, 내가 하고 싶은 말은 그것이 아닌데 그냥 그렇게 쓰게 되는 상황, 항상 일정에 쫓겨서 텍스트를 가장 마지막에 쓰게 되는 상황이 참 많이 발생하겠지요. 개발에서 ‘QA 하다가 이거 이런 에러 상황이 있으니까 팝업 문구 빨리 하나 만들어 주세요!’라고 하면 머리가 하얘지면서 일단 뭐라도 써서 주느라 아무 말 대잔치는 했는데 이게 맞는 건지 모르겠고…
일단 다음 두 가지 예시를 살펴보며, 자주 발생하는 불명확한 표현 사용에 대해 알아봅시다.
- A. Wifi 연결이 해지되었습니다.
- B. Wi-Fi 연결이 해제되었습니다.
A와 B 중에서 어떤 것이 정확한 레이블인지 다들 아시리라 믿지만, 굳이 정답을 말하자면 B가 정확한 쪽입니다. Wi-Fi가 바른 표기이고, ‘해지’는 서비스를 영구적으로 사용하지 않는다는 용어인 반면 ‘해제’는 기능을 일시적으로 사용하지 않음을 의미하는 용어이므로 당연히 후자를 사용해야 합니다.
외국어 표기, 해지와 해제, 정지와 중지 등의 헷갈리는 용어 등은 신문이든, 표준국어대사전(=네이버 사전)이든 검색해보면 바로 알 수 있습니다. 시간에 쫓긴다고 넘어가지 마시고 한 번만, 그니까 정말 한 번만! 네이버 맞춤법 검사기와 브런치 맞춤법 검사기를 돌려보고 개발에 메시지를 넘겨주세요.
- A. % s가 응답하지 않습니다. 통화는 이 기기에서 이어집니다.
- B. % s 기기에 파일을 보낼 수 없습니다. 현재 통화는 계속해서 진행할 수 있습니다.
조금 더 까다로운 문제입니다. 분명히 둘 다 비문이거나 틀린 이야기를 하고 있는 것인 아닌데, 어느 쪽을 써야 할지 선택이 어려울 수 있습니다.
A는 전통적인 개발 용어를 한국어로 번역한 번역투 문장이고 불필요한 지시사 ‘이’를 사용하고 있습니다. 내용상 파일은 못 보내고 통화는 계속할 수 있다는 의미인 것 같은데 굳이 지시사 ‘이’를 쓸 필요가 없죠(이 휴대폰 말고 다른 휴대폰을 쓸건 아니니까요).
B는 사용자를 주어로 고정하고(문장 내에서는 생략되었지만 맥락상 주어를 파악할 수 있습니다), 사용자 중심으로 서술했습니다. ‘대상이 응답을 하다’라는 표현보다는 사용자가 시도한 행위가 실패했라는 방향으로 기술하고, 실패했음에도 불구하고 사용자가 계속할 수 있는 행위는 무엇인지도 알려주었습니다. 주어가 다른 두 문장이 연이어 있는 A보다는 B가 흐름상 이해하기 쉽습니다.
좋은 문장을 쓰기 위해서는 꽤 오랜 시간의 훈련을 해야 합니다. 다양한 케이스를 접해보고, 각 상황마다 사용자가 어떻게 판단할지, 어떤 표현을 쓰면 사용자가 빠르고 오해 없이 이해할 수 있을지 고민해야 합니다. 끊임없이 사용자의 언어 습관에 대해 관심을 갖고 발견해낸 패턴과 용어들을 연습해야 합니다.
해야 할 일이 많은 디자이너 입장에서는 이런 훈련을 꾸준히 해나간다는 것이 쉬운 일은 아닐 것입니다. 정확한 표현으로 텍스트를 작성하기 위해 제가 추천드리는 방법은 다음 세 가지입니다.
- 확정 전에 네이버, 브런치 맞춤법 검사기를 한 번이라도 돌려보세요.
- 어떤 표현이 더 사용자 친화적인지, 더 보편적인지 구분이 어려울 때에는 주요 일간지 신문 기사에서 해당 용어들을 검색해 보세요. 사용 빈도수가 높은 용어를 쓰시는 것을 권해드립니다.
- 내가 무슨 말을 하고 있는지 정신이 혼미할 때에는 30분이나 1시간쯤 정도 써놓은 문장을 보지 않고 있다가, 머리 털털 털어내고 다시 읽어보길 바랍니다. 잠깐 쉬면 유체이탈이 되고 과거의 나를 냉정하게 깔 수(?) 있습니다. 자기 객관화가 뭐 별건가요.
2차 세줄 요약
- 정확하게 쓴다는 것은 모호하거나 포괄적으로 쓰지 않는다는 의미입니다. 먼 미래를 생각하지 말고 현재에 충실하게, 각 케이스에 딱 맞는 메시지를 따로 준비해 주세요. 귀찮다고 모호한 말로 퉁치기 없기로 해요, 우리.
- 정확하게 쓴다는 것은 상황을 가장 핍진하게 설명해 줄 수 있는 명확한 표현을 사용한다는 의미입니다. 어문 규정에 맞는 표준어 사용·비문 지양은 물론이고, 사용자가 읽고 이해하기 쉬운 문형으로 서술하도록 합시다.
- 모르면 사전·검색 포털·맞춤법 검사기를 돌립시다. 당장 맞춤법 모르는 거 하나도 부끄럽지 않아요. 노력 안 해서 틀린 그대로 서비스 릴리즈되는 게 더 부끄러운 일입니다. 서비스 이미지가 진짜 구려진다고요.
이 필자의 다른 글 보기
