<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-17">2021년 11월 17일</time>
                </span>

            <h2>그 특수문자는 사용할 수 없습니다</h2>


        </header>

        <div>
            <blockquote>모바일에서 비밀번호 입력 규칙 제공하기<br>TL;DR: 사용자가 실수하게 만들지 마라, 필요없는 내용은 모두 제거하라.</blockquote><p>온라인 서비스를 이용하기 위해 비밀번호를 설정하려고 보면 대부분 일정 규칙을 만족하도록 비밀번호를 설정해달라고 요구한다. 예를 들어 생년월일은 비밀번호에 사용할 수 없다던가, 10자 이상 16자 미만의 길이 제한을 두는 등의 방식이다. 그 중 오늘 다뤄볼 내용은 <strong>'특수문자'에 대한 요구사항</strong>이다.</p><p>모바일에서의 비밀번호 설정 과정은 크게 다음 요소들로 나눌 수 있다.</p><ol><li>입력 키보드</li><li>비밀번호 유효성 체크</li><li>피드백</li></ol><h2 id="%EC%9E%85%EB%A0%A5-%ED%82%A4%EB%B3%B4%EB%93%9C">입력 키보드</h2><p>PC에서와 달리 모바일 환경에서는 어플리케이션마다 입력받는 키보드를 변경할 수 있다. 특히 보안이 중요시되는 금융 관련 어플리케이션이나 인증서 사용 시에는 그림과 같은 커스텀 키보드가 사용된다.</p><p>가장 좋은 방법은 일반 키보드로 입력해도 문제가 없는 시스템을 만들어 두는 것이지만, 부득이한 경우에는 커스텀 키보드를 사용할 수 있다. 단, 커스텀 키보드는 다음의 몇 가지 규칙을 지켜야한다.</p><h3 id="%ED%82%A4%EB%8A%94-%EB%AA%85%ED%99%95%ED%9E%88-%EA%B5%AC%EB%B6%84%EB%90%98%EC%96%B4%EC%95%BC-%ED%95%9C%EB%8B%A4">키는 명확히 구분되어야 한다.</h3><figure><img src="https://www.jiwon.me/content/images/2021/11/image.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>가장 기본적인 내용이다. 커스텀 키보드는 시스템 기본 키보드와 최대한 비슷한 경험을 제공할 수 있도록 노력해야하며, 과도하게 많은 문자를 키보드에 담아 하나의 버튼을 누를 때 의도하지 않은 오타가 발생하는 경우가 없도록 해야 한다.</p><h3 id="%ED%82%A4%EA%B0%80-%EB%88%8C%EB%A6%AC%EB%A9%B4-%EC%A0%81%EC%A0%88%ED%95%9C-%ED%94%BC%EB%93%9C%EB%B0%B1%EC%9D%84-%EC%A0%9C%EA%B3%B5%ED%95%B4%EC%95%BC%ED%95%9C%EB%8B%A4">키가 눌리면 적절한 피드백을 제공해야한다.</h3><figure><img src="https://www.jiwon.me/content/images/2021/11/image-1.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>키보드의 모든 키에는 눌렀을 때 <strong>시각적/촉각적/청각적 피드백</strong>을 제공하여야 한다. 만약 키를 눌러도 아무런 시각적 변화가 없고 진동이나 소리 또한 울리지 않으며 오직 문자만 입력된다면 사용자는 자신이 키를 누르는 행동이 문자 입력으로 이어지지 않는다고 생각하게되어 사용자 경험상 단절이나 원하는 입력이 되지 않았다고 판단하여 다시 키를 누르는 오입력이 발생할 수 있다.</p><h3 id="%EB%B6%88%ED%95%84%EC%9A%94%ED%95%9C-%ED%82%A4%EB%8A%94-%ED%91%9C%EC%8B%9C%ED%95%98%EC%A7%80-%EC%95%8A%EB%8A%94%EB%8B%A4">불필요한 키는 표시하지 않는다.</h3><figure><img src="https://www.jiwon.me/content/images/2021/11/image-2.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>굉장히 많은 곳에서 지키지 않는 규칙 중 하나다. 특수문자를 자유롭게 입력할 수 있도록 하는 곳은 그다지 많지 않다. 그러나 모든 은행앱의 특수문자 입력 커스텀 키보드 창을 보면 하나 같이 키보드의 모든 특수문자를 단순 나열해 두었다.</p><figure><img src="https://www.jiwon.me/content/images/2021/11/image-3.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>하지만 실제로 유효하게 사용할 수 있는 특수문자는 그 중 일부이므로, 비밀번호로 설정할 수 없는 키는 보이지 않거나 사용하지 못한다는 것을 알 수 있게끔 조치해야한다.</p><h2 id="%EC%9C%A0%ED%9A%A8%EC%84%B1-%EC%B2%B4%ED%81%AC-%ED%83%80%EC%9D%B4%EB%B0%8D">유효성 체크 타이밍</h2><p>비밀번호를 입력받으면 그 비밀번호가 요구하는 규칙에 만족하는지 체크해야한다. 체크하는 시점을 어떻게 지정하느냐에 따라 사용자 경험이 달라진다.</p><p>예를 들어 임의의 비밀번호 <code>@23-F4g+</code>를 입력받는다고 가정하면 다음과 같은 시나리오를 생각해볼 수 있다.</p><ol><li>첫번째 문자 <code>@</code>부터 마지막 문자 <code>+</code>까지 한 번에 입력받는다.</li><li><strong>제출 버튼을 누르면</strong> 입력받은 문자열 <code>@23-F4g+</code>에 대한 유효성을 검사한다.</li><li><code>+</code>는 사용할 수 없는 문자이므로 사용자에게 재입력을 요청한다.</li></ol><p>이런 시나리오는 은행 어플리케이션과 같이 사용성에 크게 관심을 기울이지 않는 서비스에서 자주 발견할 수 있다. 이 시나리오는 어떤 문제점이 있을까? 가장 큰 문제점은 제출 버튼을 누르기 전까지는 <strong>내가 규칙에 맞는 비밀번호를 입력하고 있는지 알 수 없다</strong>는 것이다. 기껏 열심히 요구하는 특수문자를 사용해서 비밀번호를 새롭게 만들어냈더니 다시 입력해달라고 한다면 사용자는 큰 피로를 느낀다. 어떤 특수문자를 사용해야 하는지도 나중에 알려준다면 금상첨화다.</p><figure><img src="https://www.jiwon.me/content/images/2021/11/image-5.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>여기에서 조금의 개선을 이뤄내면 다음과 같은 시나리오가 된다. 매 문자가 입력될 때마다 유효성을 판단하는 방식이다.</p><ol><li>첫번째 문자 <code>@</code>를 입력받는다.</li><li>입력받은 전체 문자열 <code>@</code>은 규칙에 부합하지 않으므로 계속 입력을 받는다.</li><li>다음 문자 <code>2</code>를 입력 받는다.</li><li>입력받은 전체 문자열 <code>@2</code>는 규칙에 부합하지 않으므로 계속 입력을 받는다.</li><li>다른 문자들에 대해서도 동일한 과정을 거친다.</li><li>입력이 올바르게 끝나면 제출 버튼을 활성화한다.</li></ol><p>PC 환경에서는 이정도면 꽤나 괜찮은 UX라고 할 수 있다. (적어도 사용에 큰 문제는 발생하지 않는다.</p><p>그러나 모바일에서는 아직 개선할 점이 남아있다.</p><h2 id="%ED%94%BC%EB%93%9C%EB%B0%B1">피드백</h2><p>모바일에서는 문자 입력시 키보드가 화면의 절반을 차지하게 된다. 비밀번호 규칙은 대개 3~4개의 규칙으로 구성되는데, 비밀번호 입력 필드 아래 해당 규칙을 나열해두면 몇 개는 필연적으로 가려지게 된다.</p><figure><img src="https://www.jiwon.me/content/images/2021/11/image-4.png" alt="" loading="lazy" width="2000" height="830" sizes="(min-width: 720px) 720px"></figure><p>토스가 이 문제를 잘 풀어냈다. 여러개의 비밀번호 규칙 중 이미 만족하는 규칙은 하단으로 내리고, 아직 만족하지 못한 규칙은 상단으로 올려 키보드가 화면 하단을 가려도 만족하지 못한 규칙이 무엇인지 확인할 수 있도록 했다.</p><h2 id="%EC%A0%95%EB%A6%AC">정리</h2><p>지금까지 모바일 환경에서 비밀번호 설정 시 입력 규칙을 사용자에게 제공하는 방법에 대해서 살펴봤다. 스스로 확신이 서지 않아 적지 못한 부분이 있는데, 입력한 비밀번호를 다시 한 번 적게끔 만드는 것이 좋은 UX인지에 대한 의문이다. 회원가입 UX 설계에서의 기본 원칙은 1) 사용자가 실수하지 않는 환경을 마련할 것 2) 사용자가 귀찮아하지 않도록 할 것인데, 둘 중 무엇을 우선시 하느냐에 따라 달라지지 않을까 싶다. 귀찮아지는 순간 사용자는 서비스를 이탈할테니.</p><p>이 글 이후에도 회원가입 과정 UX에 대한 이야기를 조금 더 써볼 생각이다. 다루면 좋겠다 싶은 내용이 있으면 언제든 환영이다.</p><hr><p>글을 쓰기 위한 원동력을 얻기 위해 자발적인 후원을 받고 있습니다.<br>후원해 주신 분들께는 뉴스레터를 통해 일부 컨텐츠가 선공개될 예정입니다.<br>(구독자 이름과 후원자 이름이 동일해야 발송이 가능합니다)</p><a href="https://toss.me/panic"><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

모바일에서 비밀번호 입력 규칙 제공하기
TL;DR: 사용자가 실수하게 만들지 마라, 필요없는 내용은 모두 제거하라.
온라인 서비스를 이용하기 위해 비밀번호를 설정하려고 보면 대부분 일정 규칙을 만족하도록 비밀번호를 설정해달라고 요구한다. 예를 들어 생년월일은 비밀번호에 사용할 수 없다던가, 10자 이상 16자 미만의 길이 제한을 두는 등의 방식이다. 그 중 오늘 다뤄볼 내용은 '특수문자'에 대한 요구사항이다.
모바일에서의 비밀번호 설정 과정은 크게 다음 요소들로 나눌 수 있다.
입력 키보드
비밀번호 유효성 체크
피드백
입력 키보드
PC에서와 달리 모바일 환경에서는 어플리케이션마다 입력받는 키보드를 변경할 수 있다. 특히 보안이 중요시되는 금융 관련 어플리케이션이나 인증서 사용 시에는 그림과 같은 커스텀 키보드가 사용된다.
가장 좋은 방법은 일반 키보드로 입력해도 문제가 없는 시스템을 만들어 두는 것이지만, 부득이한 경우에는 커스텀 키보드를 사용할 수 있다. 단, 커스텀 키보드는 다음의 몇 가지 규칙을 지켜야한다.
키는 명확히 구분되어야 한다.
가장 기본적인 내용이다. 커스텀 키보드는 시스템 기본 키보드와 최대한 비슷한 경험을 제공할 수 있도록 노력해야하며, 과도하게 많은 문자를 키보드에 담아 하나의 버튼을 누를 때 의도하지 않은 오타가 발생하는 경우가 없도록 해야 한다.
키가 눌리면 적절한 피드백을 제공해야한다.
키보드의 모든 키에는 눌렀을 때 시각적/촉각적/청각적 피드백을 제공하여야 한다. 만약 키를 눌러도 아무런 시각적 변화가 없고 진동이나 소리 또한 울리지 않으며 오직 문자만 입력된다면 사용자는 자신이 키를 누르는 행동이 문자 입력으로 이어지지 않는다고 생각하게되어 사용자 경험상 단절이나 원하는 입력이 되지 않았다고 판단하여 다시 키를 누르는 오입력이 발생할 수 있다.
불필요한 키는 표시하지 않는다.
굉장히 많은 곳에서 지키지 않는 규칙 중 하나다. 특수문자를 자유롭게 입력할 수 있도록 하는 곳은 그다지 많지 않다. 그러나 모든 은행앱의 특수문자 입력 커스텀 키보드 창을 보면 하나 같이 키보드의 모든 특수문자를 단순 나열해 두었다.
하지만 실제로 유효하게 사용할 수 있는 특수문자는 그 중 일부이므로, 비밀번호로 설정할 수 없는 키는 보이지 않거나 사용하지 못한다는 것을 알 수 있게끔 조치해야한다.
유효성 체크 타이밍
비밀번호를 입력받으면 그 비밀번호가 요구하는 규칙에 만족하는지 체크해야한다. 체크하는 시점을 어떻게 지정하느냐에 따라 사용자 경험이 달라진다.
예를 들어 임의의 비밀번호 @23-F4g+를 입력받는다고 가정하면 다음과 같은 시나리오를 생각해볼 수 있다.
첫번째 문자 @부터 마지막 문자 +까지 한 번에 입력받는다.
제출 버튼을 누르면 입력받은 문자열 @23-F4g+에 대한 유효성을 검사한다.
+는 사용할 수 없는 문자이므로 사용자에게 재입력을 요청한다.
이런 시나리오는 은행 어플리케이션과 같이 사용성에 크게 관심을 기울이지 않는 서비스에서 자주 발견할 수 있다. 이 시나리오는 어떤 문제점이 있을까? 가장 큰 문제점은 제출 버튼을 누르기 전까지는 내가 규칙에 맞는 비밀번호를 입력하고 있는지 알 수 없다는 것이다. 기껏 열심히 요구하는 특수문자를 사용해서 비밀번호를 새롭게 만들어냈더니 다시 입력해달라고 한다면 사용자는 큰 피로를 느낀다. 어떤 특수문자를 사용해야 하는지도 나중에 알려준다면 금상첨화다.
여기에서 조금의 개선을 이뤄내면 다음과 같은 시나리오가 된다. 매 문자가 입력될 때마다 유효성을 판단하는 방식이다.
첫번째 문자 @를 입력받는다.
입력받은 전체 문자열 @은 규칙에 부합하지 않으므로 계속 입력을 받는다.
다음 문자 2를 입력 받는다.
입력받은 전체 문자열 @2는 규칙에 부합하지 않으므로 계속 입력을 받는다.
다른 문자들에 대해서도 동일한 과정을 거친다.
입력이 올바르게 끝나면 제출 버튼을 활성화한다.
PC 환경에서는 이정도면 꽤나 괜찮은 UX라고 할 수 있다. (적어도 사용에 큰 문제는 발생하지 않는다.
그러나 모바일에서는 아직 개선할 점이 남아있다.
피드백
모바일에서는 문자 입력시 키보드가 화면의 절반을 차지하게 된다. 비밀번호 규칙은 대개 3~4개의 규칙으로 구성되는데, 비밀번호 입력 필드 아래 해당 규칙을 나열해두면 몇 개는 필연적으로 가려지게 된다.
토스가 이 문제를 잘 풀어냈다. 여러개의 비밀번호 규칙 중 이미 만족하는 규칙은 하단으로 내리고, 아직 만족하지 못한 규칙은 상단으로 올려 키보드가 화면 하단을 가려도 만족하지 못한 규칙이 무엇인지 확인할 수 있도록 했다.
정리
지금까지 모바일 환경에서 비밀번호 설정 시 입력 규칙을 사용자에게 제공하는 방법에 대해서 살펴봤다. 스스로 확신이 서지 않아 적지 못한 부분이 있는데, 입력한 비밀번호를 다시 한 번 적게끔 만드는 것이 좋은 UX인지에 대한 의문이다. 회원가입 UX 설계에서의 기본 원칙은 1) 사용자가 실수하지 않는 환경을 마련할 것 2) 사용자가 귀찮아하지 않도록 할 것인데, 둘 중 무엇을 우선시 하느냐에 따라 달라지지 않을까 싶다. 귀찮아지는 순간 사용자는 서비스를 이탈할테니.
이 글 이후에도 회원가입 과정 UX에 대한 이야기를 조금 더 써볼 생각이다. 다루면 좋겠다 싶은 내용이 있으면 언제든 환영이다.
글을 쓰기 위한 원동력을 얻기 위해 자발적인 후원을 받고 있습니다.
후원해 주신 분들께는 뉴스레터를 통해 일부 컨텐츠가 선공개될 예정입니다.
(구독자 이름과 후원자 이름이 동일해야 발송이 가능합니다)

그 특수문자는 사용할 수 없습니다

댓글