Skip to content →

접근성 지원, 개발자의 빠른 성장을 도와줍니다.

종종 “내가 개발자로서 올바른 방향으로 성장하고 있는 것인가?”, 또는 “내가 최선의 방법으로 앱을 만들고 있는 것인가?” 같은 의문이 생길 때가 있습니다. 이런 질문에 대답 하기란 쉽지 않죠. 개발자 평가 시험 같은 것이 있어서 내가 100점 만점에 몇 점 짜리 개발자인지 확인 할 수 있는 것이 아니니까요. 이럴 때 내가 만든 앱이 얼마나 접근성을 잘 지원하는지 확인 해보는 일이 도움이 될 수 있습니다. 만약 정도(正道)를 충실히 따라 개발했다면, 설령 접근성 지원을 별로 염두에 두지 않고 개발을 하셨더라도, 높은 확률로 최소한의 접근성 지원은 자동으로 이루어지고 있을 것이기 때문입니다. 그리고 접근성을 지원하다보면, 다음의 여러 이유들 때문에, 여러분은 거의 자동적으로 지금보다 훨씬 훌륭한 프로그래머가 될 수 있습니다.

접근성 지원은 애플이 의도한 대로 각종 API를 사용하도록 도와줍니다.

새 iOS버전이 나왔을 때 앱이 갑자기 이상하게 행동하게 되는 경우가 있습니다. 적지 않은 경우에, 이는 우리가 그 동안 애플의 개발자들이 예상치 못한 방식으로 각종 API들을 사용하고 있었다는 뜻일 수 있습니다. 그렇다면 우리는 어떻게 애플 개발자들의 “예상”을 추정 할 수 있을까요? 즉, 그들이 만든 API의 의도를 어떻게 해야 더 잘 이해 할 수 있을까요?

모든 애플의 UI Control들은 기본적으로 접근성을 아주 잘 지원하도록 설계되어 있습니다. 그러니 이 UI Control들을 응용(application)한 앱(application)이 접근성을 제대로 지원하지 못하고 있다면, 그 UI Control들을 만든 사람들의 의도와는 사뭇 거리가 있는 방식으로 응용이 이루어지고 있다고 추정 할 수 있지요. 거꾸로 말하면, 여러분의 앱이 접근성을 어느 정도 잘 지원하고 있다면, 애플 개발자들의 의도에 맞게 UIKit을 활용하고 있다는 신호 일 수 있습니다.
그리고 애플의 의도대로 API를 사용하게 되면, 새로운 iOS버전이 나왔다고 해서 앱이 비정상적으로 작동하는 일은 훨씬 줄어들게 됩니다. 만약 그런 일이 발생한다면, 애플의 앱들부터 문제가 발생할 것이기 때문입니다.

사실 이는 애플에 국한된 이야기가 아닙니다. 여러분이 Angular를 쓰든 React를 쓰든, Android를 만들든, 커다란 플랫폼 제공자들은 정도와 범위의 차이는 있을 지언정 접근성 지원을 위해 아주 많이 노력합니다. 단적인 예로, HTML에서 그냥 div로 뷰들을 만들지 않고 각 태그들의 의도를 최대한 살려서 페이지를 작성하면 별다른 노력 없이도 훌륭한 접근성 지원을 할 수 있습니다. 그리고 각 태그들의 의도를 잘 살리다보면, 전체적으로 훨씬 훌륭한 제품이 나오기 마련이지요.

접근성 지원은 가장 효율적으로 오토레이아웃을 사용하도록 도와줍니다.

어떤 레이아웃을 오토레이아웃을 사용해 구현하는 방법은 다양합니다. 그 중에 어떤 구현이 애플워치,iPhone5,iPhone6+,iPhoneXR ,iPad 등등 모든 기기에 걸쳐 예쁜 화면을 만들어 낼 수 있을까요? 어느 정도 직관이 쌓이면 이를 판단하는 일은 어렵지 않게 될 수도 있지만, 기본적으로 우리는 아주 다양한 기기에 걸쳐 이를 확인 해 보아야 합니다. 그리고 설령 이 확인 과정을 스토리보드에서 한다고 하더라도, 이 과정에는 생각보다 시간이 꽤 많이 소모 될 수 있습니다.

하지만 만약 여러분이 Dynamic Types를 지원한다면, 여러분의 오토레이아웃의 성능을 확인 할 수 있는 훨씬 빠르고 쉬운 방법이 있습니다. 바로 아주 작은 폰트사이즈부터, 아주 커다란 폰트사이즈 까지 모두 표현 할 수 있는지를 확인하는 것이지요. 이 테스트에 통과한다면, 여러분의 오토레이아웃은 높은 확률로 대단히 많은 기기에서 여러분이 원하는 화면을 만들어 낼 것입니다.

다양한 크기의 기계에서 오토레이아웃을 테스트 할 수도 있지만, 한 기계에서 글자의 크기를 바꿈으로써 오토레이아웃을 테스트 할 수도 있습니다.

접근성 지원은 여러분의 앱을 다양한 방식으로 바라보도록 도와줍니다.

여러분은 아마 꽤 오랜 기간동안 앱을 개발하고 또 사용해 오셨을 겁니다. 그렇기 때문에 여러분의 앱을 방금 막 다운받은 신규 유저의 입장이 되는 일은 생각보다 어려운 일이 될 수 있습니다. 여러분에게는 어떤 버튼을 눌렀을 때 어떤 일이 벌어질지가 너무나 당연해보이지만, 신규유저 입장에서는 어떤 버튼이 어디에 있는지 조차도 헷갈릴 수 있는 노릇이지요.

보이스오버등을 활용해서, 여러분이 여태까지 사용하지 않았던 방식으로 여러분의 앱을 둘러보는 일은, 여러분의 앱을 좀 더 새로운 시각으로 바라 볼 수 있게 도와줍니다. 혹시 모르죠. VoiceOver로 둘러보면, 여러분의 앱이 생각보다도 훨씬 복잡해 졌다는 사실을 알게 될 지도 모릅니다. [관련 영상: VoiceOver: App Testing Beyond The Visuals]

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/299d9f6f-e1d6-4134-b9c0-67354c5e8cc5/2019-12-16_15.01.01.gif
보이스오버를 활용해 앱을 사용하다보면, 좀 더 새로운 시선으로 앱을 바라 볼 수 있게 됩니다.

접근성 지원은 퍼포먼스에 신경을 쓰도록 만듭니다.

버벅임은 당연히 나쁘지만, 저시력자나 노인들, 터치 디바이스가 익숙하지 않은 사람들에게는 사용을 거의 불가능하게 만드는 요소가 될 수도 있습니다. 이런 부분에 신경을 쓰다 보면, 평소에는 그냥 지나칠 법한 작은 버벅임에도 한 번 더 눈길이 가게 됩니다. 이런 사소함에 신경을 쓰느냐 안 쓰느냐가 훌륭한 개발자가 되느냐를 가르는 갈림길이 되는 것 같아요.

접근성 지원은 테스트 작성을 아주 쉽게 만들어줍니다.

UI테스트는 작성하기 아주 까다롭게 느껴질 수 있습니다. 하지만 이는 오해입니다. 접근성을 제대로 지원한 앱에서는 UI테스트 작성이 매우 손쉬울 수 있습니다.

XCUITest는 VoiceOver API를 활용하여 여러분의 앱에서 버튼을 찾고 그것을 누르는 방식으로 동작합니다. 당연히 VoiceOver가 제대로 지원되지 않는 앱에서는 UI테스트가 제대로 돌아갈 수 없죠. 거꾸로 말해, 접근성 지원이 제대로 이루어진 앱에서는 UI테스트를 작성하기가 아주 쉽습니다.

실제로 플리토에서는 로그인 및 회원가입 화면들에 대해 VoiceOver 상호작용을 지원하게 되었고, 이 부분들에 대해서는 코드베이스의 90% 이상을 커버하는 UI테스트를 며칠 안에 손쉽게 작성 할 수 있었습니다.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/067c44f9-ecd6-4828-8b8a-2d6728b3674c/2019-12-16_15.17.40.gif

마치며

접근성을 지원하려고 하다보면, 자연스럽게 소프트웨어 개발의 정도(正道)를 걷게 된다고 생각합니다. 만약 여러분이 Best-practices들을 따르고 있는지가 의심된다면, Accessibility Inspector를 켜보세요. 그리고 여러분의 앱에 대해 Accessibility Audit을 실행해 보세요. 높은 확률로, 여러분이 나아가야 할 방향에 대한 힌트 정도는 얻을 수 있을 것입니다.


Accessibility Inspector를 켜서 Run Audit을 실행하면, 앱의 어느 화면 어느 부분에 어떤 문제가 있는지 상세하게 알려줍니다. 플리토 앱도 아직 갈 길이 머네요 ^^

관련자료

혹시 이 글을 읽고 접근성 지원에 관심이 생기셨나요? 접근성 지원을 처음 시작하려 하신다면, 다음의 자료들이 도움이 될 것 같습니다.

Published in 회고, 또는 의견

4 Comments

  1. yun yun

    안녕하세요 류성두님. 개발자의 성장에 대한 포스팅을 접하고 확장된(?) 질문이 있어 댓글을 남기게 되었습니다. 우문이겠지만 혹시 가능하시다면 현답을 들려주실 수 있으신지요?

    어떤 기능을 구현하기 위해 애플의 공식 문서를 보게 되면, 제가 느낀 바로는 정보가 파편화 된 것 같았습니다. 예를 들어 문서1의 코드 A와 문서 2의 코드 B를 합치면 원하는 기능을 만들 수 있다고 한다면, 이 코드들을 통합해서 보여주는 형태의 예시는 없는 것 같았습니다.

    혹시 공식문서의 정보들을 활용하는데 있어서 조언을 주실 수 있을까요?

    뎃글을 작성하고 나니 더더욱 우문이 되었는데, 읽어주셔서 감사합니다.

    • 안녕하세요 yun님!
      글 재밌게 읽어주셔서 감사합니다.

      yun님의 질문은 전혀 우문이 아니고, 아주 적절하면서도 모두가 공감하는 궁금증이라고 생각합니다.

      먼저, 저라고 해서 애플의 API가 만들어진 모든 배경과 의도를 알진 못한다는 점을 말씀드리고 싶어요. 다만 이 글 같은 경우, 어디까지나 API저자의 의도를 추정 할 수 있는 방법의 일환으로 접근성 지원을 제시한 것 뿐이지요.

      그리고 실제로 애플의 개발자들도 모든 UIKit의 의도와 맥락을 철저히 잘 알고 있는 것 같지 않습니다. 샘플코드에 버그를 올려놓아 후회하면서도, 박제된 샘플코드를 수정 할 수 없어 한탄하는 내용을 담은 발표도 있었고, https://youtu.be/JFtn5wK-1iI
      또, Swift By Sundell의 한 에피소드 https://podcasts.apple.com/kr/podcast/swift-by-sundell/id1267161825?i=1000433713240 를 들어보면, 애플의 개발자들이 어떻게 UIKit의 적절한 기능을 몰라 삽질을 했는지 같은 내용도 알 수 있죠.

      애플 개발자들도 저렇게 삽질을 하니, 일반 개발자인 저희들이 우왕자왕 삽질을 하는 것은 어찌보면 당연한 일인 것 같습니다.

      그럼에도 불구하고, 제가 공식문서의 내용들을 최대한 이해하기 위해 들이는 노력 몇 가지는 다음과 같습니다.

      1. 궁금한게 생겼을 때, 구글에 검색하고 싶은 유혹을 견디고, 언제나 Command+Shift+0을 사용해 공식문서를 검색합니다. 더 자주 공식문서에 들어 갈 수록, “어떤 지식이 어디에 있는지” 같은 것들의 지도가 머리 속에 생기게 되고, 지식들이 더 유기적으로 얽히게 됩니다.
      2. 출퇴근 길에 WWDC 비디오를 봅니다. WWDC 의 여러 발표들 중에서, 명시적으로 특정 API의 의도와 맥락을 잘 설명해주는 부분들이 꽤 있습니다. 만약 WWDC 비디오를 보는데 시간이 너무 많이 걸린다고 생각되신다면, WWDC 각 세션의 발표 슬라이드를 텍스트 불렛포인트로 정리한 이런 저장소 https://github.com/erenkabakci/WWDC-Recap 를 활용하는 것도 방법입니다.
      3. 아카이브된, “더 이상 업데이트 되지 않는” 문서들도 API의 맥락과 의도를 파악하는 데는 큰 도움이 됩니다. https://developer.apple.com/library/archive/navigation/ 에 “Programming Guide”라고 검색하면, 여러 문서들이 나올겁니다. Concurrency Programming Guide, Accessibility Programming Guide, View Programming Guide, Text Programming Guide 등 기초가 되는 녀석들이 여기서 검색이 잘 되더라고요. 이런 녀석들은 여러 API의 내용들을 종합적으로 전달해주기 때문에 yun님의 궁금증에 많은 도움이 될 것 같습니다.
      4. API의 이름에는 의미가 있다고 가정합니다. 예컨대 ViewController는 View를 Control해야 한다던가, TableViewDataSource는 TableView를 위한 Data의 Source역할을 해야 한다던가 하는 식이죠. 이렇게 생각하면 ViewController가 tableView의 dataSource가 꼭 되지 않을 수 있다는 것을 좀 더 빨리 눈치 챌 수 있는 것 같아요

      제 나름의 노하우들을 정리해 보기는 했습니다만, 역시 결국에는 수많은 시행착오를 겪어보는 수밖에 없는 것 같습니다. yun님께서도 많은 시행착오를 겪어보시고, 노하우가 생기시면 많이 공유해 주세요!

      좋인 질문 던져주셔서 정말 감사드립니다!

      • yun yun

        안녕하세요. 세상에나, 좋은 답변 정말 감사드립니다.
        질문을 남기고 이상한 질문인 것 같아 삭제하려 했는데, 삭제 버튼이 없더라구요 (..) 그래서 삭제를 못 했는데, 삭제 했으면 정말 후회했을 것 같습니다.
        좋은 답변 다시 한번 감사드립니다!

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: