<div id="readability-page-1" class="page"><div id="gh-main">
    <article>
        <header>
                <span>
                    By <a href="/author/jiwon/">Jiwon Park</a>
                        in
                        <a href="https://www.jiwon.me/tag/ux/">UX</a>
                    —
                    <time datetime="2021-11-03">2021년 11월 3일</time>
                </span>

            <h2>토스뱅크의 에러메시지에 동의하지 않습니다 - 에러메시지는 어떠해야 하는가</h2>


        </header>

        <div>
            <p>최근 토스뱅크 출범 후 빠르게 대기 신청을 하고 순서가 되어 약 한 달간 사용해 본 결과, 여러가지 UX 문제점이 눈에 띄었지만 그 중 <strong>에러메시지</strong>에 대해서 다루어 보고자 한다. 토스가 UX writing에 특히 심혈을 기울이는 회사라는 점과, 토스뱅크는 금융 서비스를 제공하는 어플리케이션이라는 특수성이 있어 다루는 것이며, 토스가 더 발전하기를 바라며 포스트를 작성해본다.</p><h2 id="%EC%97%90%EB%9F%AC%EB%A9%94%EC%8B%9C%EC%A7%80%EC%9D%98-%EC%97%AD%ED%95%A0">에러메시지의 역할</h2><p>서비스 사용 중 에러가 발생하게 되면 사용자는 기본적으로 당황하게 된다. 에러메시지가 해야할 역할은 <strong>(1)사용자에게 에러의 내용을 충분히 설명하고, (2) 해결방안을 제시하는 것</strong>이 되어야한다.</p><p>그런 면에서 토스 뱅크의 에러메시지는 좋은 UX가 아니다. 한 달간 사용 중 발생했던 에러 두가지를 예시로, 좋은 에러메시지는 어떠해야 하는지 살펴보자.</p><h2 id="%EC%B5%9C%EC%95%85%EC%9D%98-%EC%97%90%EB%9F%AC-%EB%A9%94%EC%8B%9C%EC%A7%80-could-not-execute-statement-sql-na">최악의 에러 메시지: could not execute statement; SQL [n/a];</h2><p>최악의 에러메시지는 <strong>프로그램에서 발생한 에러메시지 그 자체를 그대로 사용자에게 보여주는 것</strong>이다.</p><figure><img src="https://www.jiwon.me/content/images/2021/11/IMG_4503.png" alt="" loading="lazy" width="946" height="1181" sizes="(min-width: 720px) 720px"></figure><p>물론 에러의 내용은 명확하게 보여주고 있다. 그러나 비어있느니만 못하다. 비어있는 에러창은 사용자를 황당하게 만들 뿐이지만, <strong>프로그램의 에러를 그대로 보여준 에러창은 사용자를 당황하게 만든다</strong>. 당연히 서비스 전체에 대한 이미지에 악영향을 미친다.</p><p>시작할 때 말했던 <strong>'사용자에게 에러의 내용을 충분히 설명한다'</strong>에서 이 경우는 <strong>'사용자에게' </strong>설명하는데 실패했다. 저 에러 내용을 이해할 수 있는 사람은 토스 내부의 시스템 개발자 뿐이다. 개발자는 저 에러를 보자마자 "아 여기서 에러가 발생했네" 하면서 코드를 고치러 가겠지만, 디자이너는 저걸 보면 바로 경악하면서 메시지 수정을 요청해야한다.</p><p>제품 개발시 프로그램 에러메시지는 개발자 도구 혹은 <strong>개발 모드일 때에만 노출되도록</strong> 하고, 프로덕션에서는 프로그램 에러메시지가 사용자에게 <strong>그대로 노출되는 로직 자체를 차단</strong>해야한다.</p><p>또 누군가는 스크린샷으로 에러 리포트가 들어왔을 때 에러코드라도 적혀있어야 한다고 주장할 수 있다. 그러나 <strong>사용자가 알아먹을 수 없는 정보는 아무런 의미가 없이 혼란만 야기할 뿐</strong>이다. 에러가 발생했을 때 해당 에러를 보고할 때에도 직접 에러 코드나 메시지를 드러내야할 필요는 없다. 이걸 해결할 수 있는 UX는 널리고 널렸다. 우리가 네이버 접속할 때 네이버 서버 IP를 직접 입력하지는 않는다. <strong>뒤로 숨겨져 있어야 할 데이터는 뒤에만 있어야한다.</strong></p><h2 id="%EC%97%90%EB%9F%AC%EB%A9%94%EC%8B%9C%EC%A7%80%EB%8A%94-%EA%B2%A9%EC%8B%9D%EC%B2%B4%EB%A1%9C-%EB%8F%88%EC%9D%84-%EC%98%AE%EA%B8%B0%EB%8A%94-%EC%A4%91-%EC%98%A4%EB%A5%98%EA%B0%80-%EB%B0%9C%EC%83%9D%ED%96%88%EC%96%B4%EC%9A%94">에러메시지는 격식체로: 돈을 옮기는 중 오류가 발생했어요.</h2><figure><img src="https://www.jiwon.me/images/toss_error.jpg" alt="" loading="lazy"></figure><figure><img src="https://www.jiwon.me/content/images/2021/11/IMG_4899.png" alt="" loading="lazy" width="444" height="486"></figure><h3 id="%EC%9E%98%EB%AA%BB%ED%96%88%EC%9C%BC%EB%A9%B4-%EA%B2%A9%EC%8B%9D%EC%9D%84-%EC%B0%A8%EB%A0%A4%EC%95%BC">잘못했으면 격식을 차려야</h3><p>에러메시지는 제품의 문제로 인해 <strong>사용자에게 양해를 구하는 메시지</strong>가 되어야한다. 그렇다고 '죄송합니다'와 같은 단어를 집어넣을 필요는 없지만(오히려 넣으면 안된다고 생각한다).</p><p>'~해요'와 같은 <strong>해요체</strong>와 '~습니다' 같은 <strong>하십시오체</strong>는 미묘한 차이가 있다.</p><p>국어에서 해요체는 <strong>비격식체</strong>로 분류가 되고, 하십시오체는 <strong>격식체</strong>로 분류가 된다. 즉 사용자에게 격식을 차려 내용을 전달해야하는 에러메시지에는 격식체인 하십시오체를 사용해야한다.</p><p>해요체는 자신을 낮추는 동시에 <strong>수동적인 태도</strong>를 드러낸다. "제가 이걸 하다가 문제가 발생했어요" 뒤에는 "죄송해요" 보다 "어떡하죠?"가 더 자연스럽다. "죄송해요"라고 해도 얘가 뭔가 스스로 해결책을 가져올거 같지는 않다. 토스 전체적으로 해요체를 톤앤매너로 삼아 사용자와의 거리를 좁히려고 하는 것은 이해하겠지만, <strong>난 굳이 잘못을 고백하는 은행원과 친밀해지고 싶지는 않다</strong>. 적어도 잘못했을 때는 격식을 차려달라.</p><p>사용자는 제품을 스스로 고칠 능력이 없다. 사용자 스스로도 알고 있기 때문에 서비스의 톤은 언제나 '믿음직한' 이미지를 제공하여 <strong>사용자의 문제를 서비스가 언제나 해결해 줄 수 있다고 생각하게</strong> 만들어야한다. 금융관련 서비스라면 특히나 그렇다. 따라서 <strong>하십시오체를 사용하여 책임감과 믿음직함을 느낄 수 있도록 </strong>해야한다.</p><h3 id="%EC%96%B4-%EB%82%98%EB%A5%BC-%EB%AC%B4%EC%8B%9C%ED%95%98%EB%82%98">어? 나를 무시하나?</h3><p><strong>"돈을 옮기는 중"</strong>과<strong> "송금 중"</strong> 둘 중에 어떤 언어를 선택하느냐도 앞선 제품의 신뢰도 문제와 직결되어있다. 우리는 금융 서비스를 사용할 때 친구가 내 돈을 다뤄준다고 생각하지 않고, <strong>금융 전문가</strong>가 내 돈을 조심히 다뤄주기를 기대한다. 수십년간의 금융 관련 계약서에서는 <strong>'돈을 옮기다'</strong>라는 표현보다 전문 용어인 <strong>'송금'</strong>이 더 많이 등장해왔다. (송금은 그렇게 전문적인 용어도 아니다.)</p><p><em>"송금의뢰 이체금 전송 거래 요청 수리 실패" </em>따위의 언어가 아니라면, 사용자가 이해할 수 있는 단어를 굳이 풀어서 설명할 필요가 없다. 이해할 수 있는 단어를 두고 더 쉬운 용어를 택하는 건 오히려 사용자로 하여금 자신을 <strong>무시한다는 불쾌함</strong>을 유발시킬 수 있다.</p><h2 id="%EA%B7%B8%EB%9E%98%EB%8F%84-%EC%9D%B4%EA%B1%B0%EB%8A%94-%EC%9E%98%ED%96%88%EB%8B%A4">그래도 이거는 잘했다</h2><p>토스의 에러메시지에는 다른 어플리케이션에서 툭하면 볼 수 있었던 <strong>느낌표나 붉은색 경고 표시</strong>가 등장하지 않았다. 매우 좋은 선택이다. 느낌표와 붉은색 경고 표시는 사용자가 위험한 상황이거나 긴급하게 정보를 인지해야할 때 사용한다. 그러나 대부분의 에러메시지는 긴급할 필요가 없다. 에러메시지가 뜨면 모든 작업이 멈추고 사용자는 에러메시지만 읽게 되므로 급하지 않아도 된다. 오히려 <strong>사용자의 판단 시간을 짧게 만드는 행위는 긴장과 당황을 유발</strong>한다. 이미 내가 의도하지 않은 에러메시지가 뜬 상황에서 한 번 당황하고, 붉은색 메시지와 느낌표를 보며 두 번 당황하고, 마지막으로 알아먹을 수 없는 에러메시지로 세 번 당황하게 만들었다면 나는 그 어플리케이션을 당장 꺼버렸을 것이다. 긴급함을 나타내지 않는 정보 전달 톤의 에러창을 채택함으로서 <strong>사용자가 에러를 받아들일 수 있는 심리적 시간을 늘려준 점</strong>은 칭찬한다.</p><h2 id="%EA%B2%B0%EB%A1%A0">결론</h2><p>지금까지 토스뱅크를 사용하며 발생한 에러메시지로 좋은 에러메시지는 무엇인가에 대해 살펴봤다. 지적할 점도 많았지만 전반적인 사용자 경험에 있어서는 신기함과 편리함의 연속이였고, 나는 토스뱅크가 더 발전할 수 있을 것이라 기대해본다.</p><hr><p>글을 쓰기 위한 원동력을 얻기 위해 자발적인 후원을 받고 있습니다.<br>구독 및 후원해 주신 분들께는 뉴스레터로 전용 컨텐츠가 추가 발송될 예정입니다.</p><a href="https://toss.me/panic/3000"><svg width="205" height="48" viewBox="0 0 205 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<rect width="204.706" height="48" rx="11.2941" fill="#2962F6"></rect>
<path d="M60.7219 28.0687H54.6569V25.1887H59.1802V23.7995H50.3539V21.8005H58.7059V20.4282H50.3539V18.5816H59.0447V17.1586H48.5751V25.1887H52.8951V28.0687H46.864V29.5087H60.7219V28.0687ZM74.9511 24.9176L75.7135 23.4776C72.698 22.9355 70.2415 20.5807 70.2415 18.1412V16.9892H68.3949V18.1412C68.3949 20.5299 65.9384 22.9355 62.9229 23.4776L63.6683 24.9176C66.1587 24.4264 68.3102 22.8 69.3097 20.7162C70.3093 22.8 72.4608 24.4264 74.9511 24.9176ZM76.3064 27.8993H62.4486V29.3393H76.3064V27.8993ZM91.891 28.0687H85.8091V25.4598H90.5865V24.0536H81.4214V21.9191H90.2477V17.0739H79.6764V18.48H88.5197V20.5299H79.7103V25.4598H84.0642V28.0687H78.0331V29.5087H91.891V28.0687ZM110.468 19.0729V17.6838H105.182V15.9558H103.437V17.6838H98.0839V19.0729H110.468ZM99.219 22.4104C99.219 24.0536 101.133 25.0024 104.318 25.0024C107.503 25.0024 109.418 24.0536 109.418 22.4104C109.418 20.7332 107.503 19.8184 104.318 19.8184C101.133 19.8184 99.219 20.7332 99.219 22.4104ZM107.588 22.4104C107.588 23.2744 106.504 23.6979 104.318 23.6979C102.133 23.6979 101.032 23.2744 101.032 22.4104C101.032 21.5633 102.133 21.1398 104.318 21.1398C106.504 21.1398 107.588 21.5633 107.588 22.4104ZM111.264 27.3233V25.9172H97.3893V27.3233H103.437V31.3214H105.182V27.3233H111.264ZM123.918 24.9854H120.919V26.2052H123.918V27.6282H125.663V15.9896H123.918V24.9854ZM117.87 21.9699C120.106 21.9699 121.648 20.9026 121.648 19.2762C121.648 17.6499 120.106 16.5826 117.87 16.5826C115.634 16.5826 114.075 17.6499 114.075 19.2762C114.075 20.9026 115.634 21.9699 117.87 21.9699ZM117.87 17.8701C119.157 17.8701 119.988 18.4122 119.988 19.2762C119.988 20.1402 119.157 20.6824 117.87 20.6824C116.582 20.6824 115.735 20.1402 115.735 19.2762C115.735 18.4122 116.582 17.8701 117.87 17.8701ZM117.175 24.2908V27.1369H118.92V24.1892C120.225 24.1214 121.563 23.9689 122.851 23.7487L122.715 22.4951C119.462 22.9016 115.718 22.9525 112.906 22.9525L113.126 24.3755C114.346 24.3755 115.684 24.3586 117.175 24.2908ZM126.019 29.5934H116.718V26.4932H114.973V31.0165H126.019V29.5934ZM142.806 23.6132V22.1562H140.451V16.0066H138.689V31.3214H140.451V23.6132H142.806ZM133.878 18.3614V16.2268H132.133V18.3614H128.491V19.7845H137.453V18.3614H133.878ZM133.031 20.8687C130.812 20.8687 129.236 22.3426 129.236 24.4433C129.236 26.544 130.812 28.0179 133.031 28.0179C135.199 28.0179 136.826 26.544 136.826 24.4433C136.826 22.3426 135.199 20.8687 133.031 20.8687ZM133.031 26.5779C131.794 26.5779 130.896 25.7308 130.896 24.4433C130.896 23.1558 131.794 22.3087 133.031 22.3087C134.268 22.3087 135.166 23.1558 135.166 24.4433C135.166 25.7308 134.268 26.5779 133.031 26.5779ZM156.781 16.0066H155.036V31.3045H156.781V16.0066ZM152.275 17.616H145.024V19.0391H150.479C150.191 22.5628 148.277 25.2395 144.262 27.1878L145.193 28.5769C150.445 26.0358 152.275 22.1732 152.275 17.616Z" fill="white"></path>
</svg>

</a>

        </div>

            
    </article>
</div></div>

jiwon.me

최근 토스뱅크 출범 후 빠르게 대기 신청을 하고 순서가 되어 약 한 달간 사용해 본 결과, 여러가지 UX 문제점이 눈에 띄었지만 그 중 에러메시지에 대해서 다루어 보고자 한다. 토스가 UX writing에 특히 심혈을 기울이는 회사라는 점과, 토스뱅크는 금융 서비스를 제공하는 어플리케이션이라는 특수성이 있어 다루는 것이며, 토스가 더 발전하기를 바라며 포스트를 작성해본다.
에러메시지의 역할
서비스 사용 중 에러가 발생하게 되면 사용자는 기본적으로 당황하게 된다. 에러메시지가 해야할 역할은 (1)사용자에게 에러의 내용을 충분히 설명하고, (2) 해결방안을 제시하는 것이 되어야한다.
그런 면에서 토스 뱅크의 에러메시지는 좋은 UX가 아니다. 한 달간 사용 중 발생했던 에러 두가지를 예시로, 좋은 에러메시지는 어떠해야 하는지 살펴보자.
최악의 에러 메시지: could not execute statement; SQL [n/a];
최악의 에러메시지는 프로그램에서 발생한 에러메시지 그 자체를 그대로 사용자에게 보여주는 것이다.
물론 에러의 내용은 명확하게 보여주고 있다. 그러나 비어있느니만 못하다. 비어있는 에러창은 사용자를 황당하게 만들 뿐이지만, 프로그램의 에러를 그대로 보여준 에러창은 사용자를 당황하게 만든다. 당연히 서비스 전체에 대한 이미지에 악영향을 미친다.
시작할 때 말했던 '사용자에게 에러의 내용을 충분히 설명한다'에서 이 경우는 '사용자에게' 설명하는데 실패했다. 저 에러 내용을 이해할 수 있는 사람은 토스 내부의 시스템 개발자 뿐이다. 개발자는 저 에러를 보자마자 "아 여기서 에러가 발생했네" 하면서 코드를 고치러 가겠지만, 디자이너는 저걸 보면 바로 경악하면서 메시지 수정을 요청해야한다.
제품 개발시 프로그램 에러메시지는 개발자 도구 혹은 개발 모드일 때에만 노출되도록 하고, 프로덕션에서는 프로그램 에러메시지가 사용자에게 그대로 노출되는 로직 자체를 차단해야한다.
또 누군가는 스크린샷으로 에러 리포트가 들어왔을 때 에러코드라도 적혀있어야 한다고 주장할 수 있다. 그러나 사용자가 알아먹을 수 없는 정보는 아무런 의미가 없이 혼란만 야기할 뿐이다. 에러가 발생했을 때 해당 에러를 보고할 때에도 직접 에러 코드나 메시지를 드러내야할 필요는 없다. 이걸 해결할 수 있는 UX는 널리고 널렸다. 우리가 네이버 접속할 때 네이버 서버 IP를 직접 입력하지는 않는다. 뒤로 숨겨져 있어야 할 데이터는 뒤에만 있어야한다.
에러메시지는 격식체로: 돈을 옮기는 중 오류가 발생했어요.
잘못했으면 격식을 차려야
에러메시지는 제품의 문제로 인해 사용자에게 양해를 구하는 메시지가 되어야한다. 그렇다고 '죄송합니다'와 같은 단어를 집어넣을 필요는 없지만(오히려 넣으면 안된다고 생각한다).
'~해요'와 같은 해요체와 '~습니다' 같은 하십시오체는 미묘한 차이가 있다.
국어에서 해요체는 비격식체로 분류가 되고, 하십시오체는 격식체로 분류가 된다. 즉 사용자에게 격식을 차려 내용을 전달해야하는 에러메시지에는 격식체인 하십시오체를 사용해야한다.
해요체는 자신을 낮추는 동시에 수동적인 태도를 드러낸다. "제가 이걸 하다가 문제가 발생했어요" 뒤에는 "죄송해요" 보다 "어떡하죠?"가 더 자연스럽다. "죄송해요"라고 해도 얘가 뭔가 스스로 해결책을 가져올거 같지는 않다. 토스 전체적으로 해요체를 톤앤매너로 삼아 사용자와의 거리를 좁히려고 하는 것은 이해하겠지만, 난 굳이 잘못을 고백하는 은행원과 친밀해지고 싶지는 않다. 적어도 잘못했을 때는 격식을 차려달라.
사용자는 제품을 스스로 고칠 능력이 없다. 사용자 스스로도 알고 있기 때문에 서비스의 톤은 언제나 '믿음직한' 이미지를 제공하여 사용자의 문제를 서비스가 언제나 해결해 줄 수 있다고 생각하게 만들어야한다. 금융관련 서비스라면 특히나 그렇다. 따라서 하십시오체를 사용하여 책임감과 믿음직함을 느낄 수 있도록 해야한다.
어? 나를 무시하나?
"돈을 옮기는 중"과 "송금 중" 둘 중에 어떤 언어를 선택하느냐도 앞선 제품의 신뢰도 문제와 직결되어있다. 우리는 금융 서비스를 사용할 때 친구가 내 돈을 다뤄준다고 생각하지 않고, 금융 전문가가 내 돈을 조심히 다뤄주기를 기대한다. 수십년간의 금융 관련 계약서에서는 '돈을 옮기다'라는 표현보다 전문 용어인 '송금'이 더 많이 등장해왔다. (송금은 그렇게 전문적인 용어도 아니다.)
"송금의뢰 이체금 전송 거래 요청 수리 실패" 따위의 언어가 아니라면, 사용자가 이해할 수 있는 단어를 굳이 풀어서 설명할 필요가 없다. 이해할 수 있는 단어를 두고 더 쉬운 용어를 택하는 건 오히려 사용자로 하여금 자신을 무시한다는 불쾌함을 유발시킬 수 있다.
그래도 이거는 잘했다
토스의 에러메시지에는 다른 어플리케이션에서 툭하면 볼 수 있었던 느낌표나 붉은색 경고 표시가 등장하지 않았다. 매우 좋은 선택이다. 느낌표와 붉은색 경고 표시는 사용자가 위험한 상황이거나 긴급하게 정보를 인지해야할 때 사용한다. 그러나 대부분의 에러메시지는 긴급할 필요가 없다. 에러메시지가 뜨면 모든 작업이 멈추고 사용자는 에러메시지만 읽게 되므로 급하지 않아도 된다. 오히려 사용자의 판단 시간을 짧게 만드는 행위는 긴장과 당황을 유발한다. 이미 내가 의도하지 않은 에러메시지가 뜬 상황에서 한 번 당황하고, 붉은색 메시지와 느낌표를 보며 두 번 당황하고, 마지막으로 알아먹을 수 없는 에러메시지로 세 번 당황하게 만들었다면 나는 그 어플리케이션을 당장 꺼버렸을 것이다. 긴급함을 나타내지 않는 정보 전달 톤의 에러창을 채택함으로서 사용자가 에러를 받아들일 수 있는 심리적 시간을 늘려준 점은 칭찬한다.
결론
지금까지 토스뱅크를 사용하며 발생한 에러메시지로 좋은 에러메시지는 무엇인가에 대해 살펴봤다. 지적할 점도 많았지만 전반적인 사용자 경험에 있어서는 신기함과 편리함의 연속이였고, 나는 토스뱅크가 더 발전할 수 있을 것이라 기대해본다.
글을 쓰기 위한 원동력을 얻기 위해 자발적인 후원을 받고 있습니다.
구독 및 후원해 주신 분들께는 뉴스레터로 전용 컨텐츠가 추가 발송될 예정입니다.

토스뱅크의 에러메시지에 동의하지 않습니다 - 에러메시지는 어떠해야 하는가

댓글