[접근성연구·모바일] 우리 버튼은 손가락에 충분한가
앞 두 편에서 우리는 터치 타겟의 기준(015)과 그 기준이 무너졌을 때의 오작동(016)을 살펴봤습니다. 이번 편은 시선을 우리 화면으로 돌립니다. '우리 버튼은 손가락에 충분한가'를, 자가점검의 관점에서 직접 확인하는 방법입니다. 점검이라고 하면 흔히 '정확한 수치 측정'을 떠올립니다. 물론 픽셀 단위로 재는 것도 의
![[접근성연구·모바일] 우리 버튼은 손가락에 충분한가](https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/abexe1aj-99922.jpeg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC9hYmV4ZTFhai05OTkyMi5qcGVnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDQ2NTcyOSwiZXhwIjoyMDk5ODI1NzI5fQ.HwCxvLwCciC0m4CmWeLc7-olYnFnNfj7ZwyMa3V1IBc)
터치 타겟 점검 관점
〈디지털 접근성 연구 017〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.
들어가며 — 측정 전에 손가락으로
앞 두 편에서 우리는 터치 타겟의 기준(015)과 그 기준이 무너졌을 때의 오작동(016)을 살펴봤습니다. 이번 편은 시선을 우리 화면으로 돌립니다. '우리 버튼은 손가락에 충분한가'를, 자가점검의 관점에서 직접 확인하는 방법입니다.
점검이라고 하면 흔히 '정확한 수치 측정'을 떠올립니다. 물론 픽셀 단위로 재는 것도 의미가 있습니다. 그러나 우리는 측정보다 앞서야 할 점검이 있다고 봅니다. 바로 '실제로 손가락으로 눌러 보는' 것입니다. 자를 대기 전에, 흔들리는 버스를 상상하며 엄지로 눌러 보는 것. 이 단순한 동작이 수치 측정이 놓치는 많은 것을 드러냅니다.
이번 편은 특별한 도구 없이도 할 수 있는 점검에서 시작해, 조금 더 정밀한 확인으로 나아갑니다. 모든 점검의 바탕에는 하나의 질문이 있습니다. '이 버튼을, 손이 불편한 사람이 흔들리는 환경에서도 한 번에 누를 수 있는가.'
1. 점검 방법 ① — 엄지 하나로 끝까지
가장 먼저 권하는 점검은 '한 손, 엄지 하나로 전체 흐름을 끝까지 해 보기'입니다. 두 손으로 폰을 받치고 검지로 또박또박 누르는 것이 아니라, 한 손으로 폰을 쥐고 엄지만으로 신청·검색·로그인 같은 주요 흐름을 처음부터 끝까지 진행해 봅니다.
이 점검이 드러내는 것은 '실제 사용 자세'에서의 어려움입니다. 많은 사용자는 한 손으로 폰을 씁니다. 출퇴근길에, 짐을 든 채로, 아이를 안은 채로. 엄지는 검지만큼 정밀하지 않고, 화면의 모든 영역에 똑같이 닿지도 않습니다. 화면 위쪽이나 반대쪽 가장자리는 엄지가 닿기 어렵습니다.
엄지 하나로 흐름을 진행하다 멈칫하는 지점 — 누르기 위해 폰을 고쳐 쥐어야 하는 곳, 두세 번 시도해야 닿는 곳, 옆 버튼이 눌리는 곳 — 이 곧 점검해야 할 자리입니다. 이 점검은 도구가 필요 없고, 누구나 지금 당장 할 수 있습니다.
2. 점검 방법 ② — 흔들며 눌러 보기
두 번째 점검은 '흔들리는 환경을 흉내 내며 눌러 보기'입니다. 책상에 폰을 고정하고 누르면 대부분의 버튼이 멀쩡합니다. 그러나 실제 모바일 사용 환경은 흔들립니다.
걸으면서, 또는 일부러 손을 살짝 흔들며 주요 버튼을 눌러 봅니다. 가능하다면 실제로 버스나 지하철에서 그 화면을 써 봅니다. 흔들림 속에서 빗나가는 버튼이 있다면, 그것은 '간격이 부족한' 신호입니다. 안정된 손으로는 닿지만 흔들리는 손으로는 빗나가는 버튼은, 손이 불편한 사용자에게는 안정된 환경에서도 빗나가는 버튼일 가능성이 높습니다.
이 점검의 의미는, '평균적 사용자의 평균적 환경'이 아니라 '불리한 환경'을 기준으로 본다는 데 있습니다. 가장 불리한 조건에서 견디는 버튼은 모든 조건에서 견딥니다. 반대로 가장 좋은 조건에서만 멀쩡한 버튼은, 현실의 다양한 조건에서 사람을 걸러 냅니다.

3. 점검 방법 ③ — 크기와 간격을 함께 재기
세 번째는 조금 더 정밀한 점검입니다. 주요 버튼의 크기와 간격을 함께 확인합니다. 크기만 보고 간격을 빠뜨리지 않는 것이 핵심입니다.
크기는 '버튼의 실제 누름 영역'이 손가락이 무난히 닿을 정도인지를 봅니다. 앞서(015) 다룬 '44' 계열의 권장 크기를 참고하되, 정확한 수치·단위는 적용하려는 기준의 원문을 확인합니다. 간격은 '이 버튼과 가장 가까운 다른 컨트롤 사이의 거리'를 봅니다. 두 컨트롤이 손가락 하나 거리 안에 들어온다면, 크기가 충분해도 오작동 위험이 있습니다.
브라우저의 개발자 도구나 디자인 도구를 쓸 수 있다면, 요소의 실제 크기와 여백을 수치로 확인할 수 있습니다. 다만 수치만으로 끝내지 않는 편이 좋습니다. 수치상 기준을 만족해도 손가락으로 눌러 빗나간다면, 그 손가락의 경험이 우선입니다. 수치는 손가락 점검을 보완하는 도구이지, 대체하는 것이 아닙니다.
4. 점검 방법 ④ — 누름 영역의 실제 경계 확인
네 번째 점검은 '보이는 크기'와 '실제 누름 영역'의 차이를 확인하는 것입니다. 앞서 강조했듯, 둘은 다를 수 있습니다.
작은 아이콘 버튼을 골라, 그 아이콘의 가장자리 바깥쪽을 눌러 봅니다. 아이콘에서 조금 떨어진 곳을 눌렀는데도 반응한다면, 누름 영역이 시각적 크기보다 넓게 설정된 것입니다. 좋은 신호입니다. 반대로 아이콘의 정확한 중심만 반응한다면, 실제 누름 영역이 좁다는 뜻입니다.
체크박스라면, 옆의 글자(라벨)를 눌러 봅니다. 글자를 눌러도 체크가 된다면 누름 영역이 글자까지 확장된 것이고, 작은 네모만 반응한다면 그렇지 않은 것입니다. 이 점검은 '작아 보이지만 실은 충분한' 버튼과 '커 보이지만 실은 좁은' 버튼을 가려 냅니다. 시각적 크기로 안심하지 않고, 실제 닿는 범위를 확인하는 일입니다.

5. 점검 방법 ⑤ — 위험한 버튼의 이웃 보기
다섯 번째 점검은 '위험한 버튼 곁에 무엇이 있는가'를 보는 것입니다. 같은 빗나감도 위험한 버튼에서 일어나면 손실이 됩니다.
화면에서 '되돌리기 어려운 동작'을 하는 버튼들을 먼저 찾습니다. 삭제, 제출, 결제, 취소, 탈퇴 같은 것들입니다. 그리고 그 버튼 바로 곁에 무엇이 붙어 있는지 봅니다. 만약 '저장' 옆에 '삭제'가, '이전' 옆에 '취소'가 바짝 붙어 있다면, 빗나감 한 번이 손실로 이어질 수 있는 자리입니다.
이런 자리는 우선적으로 손봐야 합니다. 두 버튼 사이 간격을 넉넉히 두거나, 위험한 버튼을 시각적으로 분리하거나, 위험한 동작에 한 단계 확인을 두는 방식이 있습니다. 점검의 핵심은 '빗나갔을 때의 결과'를 함께 보는 것입니다. 자주 빗나가는 곳보다, 빗나갔을 때 크게 잃는 곳을 먼저 보는 시선이 필요합니다.
5-1. 다섯 점검을 한 장으로 — 무엇을 드러내나
다섯 방법은 드러내는 문제가 서로 다릅니다. 무엇을 의심하느냐에 따라 골라 쓰도록 한 표로 정리합니다.
| 점검 방법 | 주로 드러내는 문제 | 필요한 도구 | 혼자 가능? |
|---|---|---|---|
| ① 엄지 하나로 끝까지 | 도달 어려운 영역·자세 부담 | 없음 | 가능 |
| ② 흔들며 눌러 보기 | 간격 부족(흔들림에 빗나감) | 없음 | 가능 |
| ③ 크기·간격 재기 | 수치상 미달 | 개발자 도구(선택) | 가능 |
| ④ 누름 영역 경계 | 보임≠닿음 차이 | 없음 | 가능 |
| ⑤ 위험 버튼 이웃 | 빗나감의 손실 크기 | 없음 | 가능 |
표가 보여 주듯, 다섯 방법은 대부분 도구 없이 가능하며 ①②④⑤는 '손가락으로 직접', ③만 '수치로'입니다. 우리는 ①②(자세·환경)로 먼저 큰 문제를 걸러 내고, ③(수치)으로 확인하며, ④⑤(영역·이웃)로 놓치기 쉬운 빈틈을 메우는 순서를 권합니다.
6. 자주 빠지는 함정
터치 타겟 점검을 하다 보면 몇 가지 함정에 빠지기 쉽습니다. 미리 짚어 둡니다.
첫째, 개발자의 손가락으로만 점검하는 함정입니다. 화면을 만든 사람은 버튼의 위치를 정확히 압니다. 어디를 눌러야 하는지 알고 누르면 빗나가지 않습니다. 그러나 처음 온 사용자, 손이 불편한 사용자는 그렇지 않습니다. 점검은 '위치를 모르는 사람'의 입장에서 해야 합니다.
둘째, 최신 고급 기기로만 점검하는 함정입니다. 큰 화면, 빠른 반응의 최신 폰에서는 작은 버튼도 그럭저럭 눌립니다. 그러나 작은 화면의 보급형 기기, 반응이 느린 구형 기기에서는 같은 버튼이 훨씬 어렵습니다. 가능하면 다양한 기기에서 확인하는 편이 좋습니다.
셋째, '평균'에 안심하는 함정입니다. 대부분의 버튼이 충분하다고 해서 안심하면, 정작 가장 중요한 한두 개 버튼의 문제를 놓칩니다. 점검은 평균이 아니라, 가장 중요하고 가장 위험한 버튼에 집중해야 합니다.
| 함정 | 어떤 모습으로 | 왜 위험한가 | 빠져나오는 길 |
|---|---|---|---|
| 개발자 손가락으로만 | 위치 알고 누름 | 처음 온 손의 어려움 안 보임 | 위치 모르는 사람 입장에서 |
| 최신 고급 기기로만 | 큰 화면·빠른 반응 | 보급형·구형서 더 어려움 | 다양한 기기에서 확인 |
| '평균'에 안심 | 대부분 OK라 안심 | 결정적 한두 개 놓침 | 중요·위험 버튼에 집중 |

7. 점검의 우선순위
모든 버튼을 똑같은 비중으로 점검하기는 어렵습니다. 우리는 다음 순서를 제안합니다.
먼저 과업의 결정적 버튼입니다. 신청·제출·로그인·결제처럼 누르지 못하면 일이 멈추는 버튼을 가장 먼저 확인합니다. 다음은 빠져나가는 통로 — 닫기·취소·뒤로입니다. 이것이 막히면 사용자는 갇힙니다. 그다음은 위험한 동작 버튼과 그 이웃입니다. 빗나감이 손실이 되는 자리입니다. 그다음은 동의·선택 컨트롤 — 작고 붙어 있기 쉬운 체크박스·라디오 버튼입니다. 마지막으로 촘촘한 목록과 툴바를 봅니다.
기준은 한결같습니다. '여기서 손가락이 빗나가면, 사용자가 일을 완수하지 못하거나 크게 잃는가.' 그 답이 '그렇다'인 곳일수록 먼저 점검하는 편이 좋습니다.
| 순위 | 점검 대상 | 막히면 무엇을 잃나 |
|---|---|---|
| 1 | 과업 결정적 버튼(신청·제출·결제) | 일 전체가 멈춤 |
| 2 | 빠져나가는 통로(닫기·취소·뒤로) | 화면에 갇힘 |
| 3 | 위험 버튼과 그 이웃 | 빗나감이 손실로 |
| 4 | 동의·선택 컨트롤(체크박스·라디오) | 동의·선택 못 함 |
| 5 | 촘촘한 목록·툴바 | 오작동 누적 |
8. 점검을 기록으로 남기기
점검은 한 번 하고 끝나면 효과가 옅어집니다. 같은 점검을 반복할 수 있고, 다른 사람과 공유할 수 있도록 기록으로 남기는 편이 좋습니다.
기록의 형식은 거창할 필요가 없습니다. '어느 화면의 어느 버튼이, 어떤 조건에서, 어떻게 빗나갔는가'를 적으면 충분합니다. 예를 들어 '○○ 신청 동의 화면 — 체크박스들 간격 좁음 — 흔들며 누를 때 인접 항목 체크됨'처럼 적습니다. 이렇게 적어 두면, 나중에 손본 뒤 같은 조건으로 다시 점검해 개선을 확인할 수 있습니다.
기록은 또한 '주관'을 '근거'로 바꿉니다. "버튼이 좀 작은 것 같다"는 느낌은 흘러가지만, "이 버튼이 이 조건에서 세 번 중 두 번 빗나갔다"는 기록은 고칠 근거가 됩니다. 우리는 점검의 마지막 단계로 기록을 권합니다. 보이지 않던 패턴이 기록을 통해 드러나기 때문입니다.
| 기록 항목 | 무엇을 적나 | 예시 |
|---|---|---|
| 어느 화면·버튼 | 위치 | ○○ 신청 동의 화면 / 약관 체크박스 |
| 어떤 조건 | 자세·환경·기기 | 한 손 엄지 / 걸으며 / 보급형 |
| 어떻게 빗나갔나 | 증상 | 인접 항목이 체크됨 |
| 빈도 | 몇 번 중 몇 번 | 3번 중 2번 |
| 빗나감의 결과 | 손실 | 잘못 동의(되돌림 필요) |
표의 '빈도'와 '결과' 칸이 "좀 작은 것 같다"는 인상을 고칠 수 있는 한 줄의 일감으로 바꿉니다. 빈도는 손본 뒤 같은 조건으로 재점검해 개선을 확인하는 기준이 되고, 결과는 한정된 시간을 어디에 먼저 쓸지 정해 줍니다.
8-1. 손가락 점검과 자동 점검의 역할 분담
이 글이 권하는 다섯 점검은 대부분 '손가락으로 직접'입니다. 그러나 ③(크기·간격 재기)처럼 수치가 필요한 부분은 사람 눈보다 기계가 정확합니다. ViewCheck 같은 자동 점검은 화면 안 모든 컨트롤의 실제 크기와 인접 간격을 전수로 측정해, '권장 크기 미달 38곳', '간격 8px 이하 12곳'처럼 사람이 일일이 잴 수 없는 양을 한 번에 표로 냅니다. 다만 '이 버튼이 위험한가', '흔들리는 환경에서 어떨까', '한 손 엄지로 닿나'는 손가락과 맥락의 영역입니다.
| 점검 항목 | 자동 점검이 잘하는 일 | 손가락 점검이 잘하는 일 |
|---|---|---|
| 크기·간격 수치 | 전수 측정·미달 목록화 | — |
| 자세·도달 범위 | — | 한 손 엄지로 직접 확인 |
| 흔들림 견딤 | — | 이동 중 실제 사용 |
| 위험도 판단 | 인접 컨트롤 나열 | 위험/안전 의미 구분 |
우리는 이 둘을 경쟁이 아니라 분업으로 봅니다 — 자동 점검이 '얼마나 많은 버튼이 수치상 위험한가'를 한눈에 보여 주면, 사람은 그 목록에서 '무엇부터 손가락으로 확인하고 고칠까'를 정합니다.

9. 한 장 요약 — 손가락으로 먼저, 자로 나중에
길었던 점검 이야기를 한자리에 모읍니다. 다섯 줄로 줄이면 이렇습니다.
첫째, 한 손 엄지로 끝까지 해 본다. 실제 사용 자세에서 멈칫하는 지점이 점검할 자리다. 둘째, 흔들며 눌러 본다. 불리한 환경에서 견디는 버튼이 모든 환경에서 견딘다. 셋째, 크기와 간격을 함께 잰다. 크기만 보고 간격을 빠뜨리지 않는다. 넷째, 보이는 크기가 아니라 실제 누름 영역을 확인한다. 작아 보여도 충분할 수 있고, 커 보여도 좁을 수 있다. 다섯째, 위험한 버튼의 이웃을 본다. 빗나갔을 때 크게 잃는 곳을 먼저 본다.
| 핵심 명제 | 한 줄 정리 | 도구·방법 |
|---|---|---|
| 한 손 엄지로 끝까지 | 실제 자세의 멈칫이 점검 자리 | §1 |
| 흔들며 눌러 본다 | 불리한 환경 견디면 다 견딤 | §2 |
| 크기+간격 함께 잰다 | 크기만 보면 놓침 | §3 |
| 보임이 아니라 닿음 | 실제 누름 영역 확인 | §4 |
| 위험 버튼 이웃을 본다 | 크게 잃는 곳 먼저 | §5 |
이 다섯 줄의 바탕에는 하나의 순서가 있습니다 — 손가락으로 먼저, 자로 나중에. 수치는 손가락 점검을 보완하는 도구일 뿐, 손가락이 빗나가는 것을 수치가 덮을 수는 없습니다.
이 점검법의 한계도 분명히 합니다. 첫째, '손가락으로 눌러 빗나간다'는 관찰은 점검자 자신의 손과 환경에 좌우되므로, 가능하면 여러 사람·여러 기기로 확인하는 편이 안전합니다. 둘째, 적정 크기·간격의 정확한 수치는 단위·등급·사용자층에 따라 달라지므로 이 글은 수치를 단정하지 않습니다. 셋째, 자가점검은 사용성 테스트나 실사용 로그를 대체하지 못합니다 — 진짜 사용자가 어디서 빗나가는지는 그들의 시도로만 확정됩니다.
맺으며 — 점검은 손가락의 편에 서는 일
터치 타겟 점검은 결국 '손가락의 편에 서는 일'입니다. 화면을 만든 사람의 정확한 손가락이 아니라, 처음 온 사람의 손가락, 흔들리는 환경의 손가락, 떨리는 손가락의 편에 서서 화면을 다시 누르는 것입니다.
그 편에 서서 누르면, 책상 위에서는 보이지 않던 어려움이 드러납니다. 그 어려움을 기록하고, 크기를 키우고, 간격을 벌리고, 누름 영역을 넓히고, 위험한 버튼을 떼어 놓는 것 — 이 점검과 손질이, '한 번에 안 눌리는 버튼'을 '한 번에 눌리는 버튼'으로 바꿉니다. 다음 편에서는 시야를 넓혀, 데스크탑·태블릿·모바일 세 화면에서 같은 페이지가 일관되게 동작하는지를 기준연구의 관점에서 다루겠습니다.
다음 편 예고 (018): [접근성연구·모바일] 데스크탑·태블릿·모바일 — 같은 페이지가 세 화면에서 어떻게 달라지는지, 3뷰포트 일관성을 기준연구의 관점에서 다룹니다.
참고한 공개 자료(출처):
- WCAG 2.1 성공 기준 2.5.5 Target Size (Enhanced) / WCAG 2.2 성공 기준 2.5.8 Target Size (Minimum) (W3C WAI) — 정확한 수치·단위는 원문 확인 권장
- 한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2) — 컨트롤 크기·간격 관련 항목
- 디지털 정부서비스 UI/UX 가이드라인(KRDS) 버튼·터치 영역 관련 권장
- 한 손 조작·도달 범위(thumb zone) 등 모바일 인터랙션 설계 원리(통설)
관련 글
[접근성연구·디지털포용] 한 사람이 여러 벽을 동시에
앞 편(081)에서 디지털 포용이 여러 갈래의 사용자를 하나의 목표로 묶는다고 봤다. 그리고 끝에서 한 가지를 남겼다 — 현실의 한 사람은 여러 조건을 동시에 가질 수 있다고. 이 시리즈를 닫는 이번 편은 그 '겹침'을 정면으로 본다. 영역의 경계를 가로질러, 조건이 겹칠 때 접근성이 어떻게 더 가팔라지는지를 관찰한다.
[접근성연구·디지털포용] 디지털포용법이 말하는 '포용'
앞 편(080)에서 초고령사회라는 인구구조의 신호를 봤다. 그리고 끝에서 한 가지를 분명히 했다 — 디지털 격차는 고령에만 있는 것이 아니라고. 이번 편은 그 여러 갈래의 격차를 '디지털 포용(digital inclusion)'이라는 하나의 정책 틀에서 함께 본다. 이 시리즈는 그동안 사용자를 영역별로 나눠 다뤘다. 고령
[접근성연구·디지털포용] 초고령사회, 공공웹은 준비됐나
공공앱 세 편(077~079)으로 매체의 확장을 닫았다. 이제 시선을 한 번 더 넓힌다. 지금까지 이 시리즈는 주로 '한 사람이 화면 앞에서 겪는 어려움'을 다뤘다. 고령(001~014), 저시력(029~043), 키보드(047~049)처럼, 개별 사용자의 자리에서 벽을 봤다. 이번 묶음(080~082)은 그 시선을 거시
