시그니파이어: 기능은 있는데, 왜 아무도 누르지 않을까

문 앞에서는 손잡이가 먼저 말합니다

처음 찾아간 공방의 유리문 앞에 섰다고 생각해 보세요. 길게 뻗은 손잡이를 보면, 안내문을 읽기 전에 손부터 뻗어 당겨 보고 싶을 수 있습니다.

이 문은 앞으로 밀어야 열린다고 가정해 봅시다. 손잡이를 잡아당기는 행동은 할 수 있지만, 그렇게 해서는 문이 열리지 않습니다. 길게 뻗은 손잡이 모양에서 예상한 ‘당겨서 열기’와 실제로 문을 여는 ‘밀기’가 어긋난 것입니다.

화면에서도 모양을 보고 예상한 행동과 실제 동작이 어긋날 수 있습니다. 다음 신청 목록에서는 어디를 눌러야 내용을 고칠 수 있을지 먼저 찾아보세요.

수정할 곳을 먼저 찾아보세요

아래는 교육 프로그램의 가상 신청 목록입니다. 이번 과제는 신청 메모 한 칸을 고치는 것입니다. 먼저 어느 부분을 선택하면 될지 예상하고 눌러 보세요. 그다음 ‘행동 이름 표시’를 켜서 같은 목록을 다시 읽어 보세요. 처음 고른 곳과 새 문구를 본 뒤 고른 곳이 같았는지 살펴봅니다.

어떤 모양이나 말 때문에 그곳을 골랐나요? ‘행동 이름 표시’를 켠 뒤에는 수정할 곳이 더 분명해졌나요? 편집 화면을 열었다면 메모를 바꾸고 ‘예시 메모 저장’을 눌러 결과도 확인해 보세요.

이 체험에서는 속도보다 무엇을 단서로 골랐는지 살펴봅니다. 한 번 눌러 보면 위치를 기억하므로 두 번째 시도가 빨라도 문구만의 효과로 볼 수는 없습니다. 키보드로 이동할 때 지금 조작할 곳을 보여 주는 초점 표시와 보조기술에 전달되는 이름은 두 상태 모두에 있으므로, 입력 방식에 따라 얻는 단서도 다릅니다.

제목과 배지는 무엇을 알려 주고 있었을까요

메모를 고치려면 ‘전시 기획 워크숍’이라는 제목 영역을 눌러야 했습니다. ‘접수됨’은 신청 상태를 짧게 보여 주는 배지입니다. 이 예시에서는 눌러도 동작하지 않았습니다. 배지를 먼저 고르고 싶었다면, 짙은 배경과 둥근 모양을 버튼의 단서로 읽었는지 돌아보세요.

‘신청 내용 수정’이라는 말이 나타나면 제목 영역을 눌러 편집할 수 있다는 설명이 더해집니다. 눌리는 위치와 영역, 열리는 편집 화면은 그대로입니다. 기능은 이미 있었고, 그 기능을 알아보게 하는 설명이 추가된 것입니다.

아래 도판에서 두 요소의 표현과 동작을 비교해 보세요. 제목에는 수정 기능이 있어도 이를 알리는 말이 부족했습니다. 배지는 눌러도 동작하지 않는데 버튼처럼 보일 수 있었습니다.

행동 이름을 보고 수정할 곳을 찾았어도 ‘접수됨’을 누르고 싶었다면, 배지의 표현은 여전히 오해를 만들고 있는 셈입니다. 다음 변경안에서는 상태를 읽는 곳과 수정을 시작하는 곳이 다르게 보이도록 바꿉니다.

이런 단서를 시그니파이어(signifier)라고 합니다. 문 앞의 ‘미세요’, 편집할 값 옆의 연필, 링크의 밑줄, 현재 선택된 항목의 표시처럼 행동이나 상태를 해석하게 해 줍니다. 중요한 것은 표시를 더하는 것 자체가 아니라, 사용자가 읽은 뜻이 실제 동작과 맞는지입니다.

변경 전과 변경안: 접수 상태는 읽고, 수정은 누릅니다

이번에는 접수 상태와 수정 행동을 서로 다르게 표현해 보겠습니다. 두 그림에서 접수가 끝났는지 읽는 곳과 내용을 고치기 위해 누를 곳을 찾아보세요. 같은 신청서를 수정하는 과제로 만든 가상 변경안입니다.

변경 전에는 둥근 ‘접수됨’ 배지가 짙은 배경과 여백 때문에 버튼처럼 보일 수 있습니다. 실제로 수정 화면을 여는 제목은 일반 글자처럼 보입니다. 사용자는 눌러도 반응이 없는 배지와 눌러야 하는 제목을 거꾸로 해석할 수 있습니다.

변경안은 ‘접수 상태: 접수됨’을 읽는 정보로 두고, ‘신청 내용 수정’을 별도의 버튼으로 만듭니다. 이렇게 하면 상태를 확인하는 일과 내용을 바꾸는 일을 다른 표현으로 구별할 수 있습니다. 제목을 눌러 상세 내용을 여는 기능도 필요하다면, 그 역할을 알려 주는 단서도 따로 마련해야 합니다.

핵심은 ‘접수됐는지는 문장에서 읽고, 고치려면 수정 버튼을 누른다’고 설명할 수 있는 화면입니다. 처음 보는 사람도 같은 뜻으로 읽고 행동하는지 확인해 보세요.

촘촘한 목록을 반복해서 쓰는 도구라면 모든 행의 긴 버튼이 부담스러울 수 있습니다. 짧은 ‘수정’ 링크를 쓰거나 선택한 행의 동작을 늘 같은 위치에 보여 주는 안도 있습니다. 그 화면을 쓰는 사람이 상태와 행동을 구별할 만큼의 단서를 남기세요.

행동할 수 있다는 사실과 그것을 알아보는 일

방금 체험의 수정 기능은 문구를 감췄을 때도 동작했습니다. 다만 어디를 눌러야 하는지 알아보기 어려웠습니다. Norman은 이렇게 가능한 행동과 그 행동을 알아보게 하는 단서를 구별해 설명합니다.

Don Norman은 2008년 글에서 시그니파이어를 사람이 감지하고 의미를 읽을 수 있는 단서로 설명했습니다. 안내문처럼 의도적으로 만든 표시뿐 아니라 사람들이 남긴 흔적처럼 우연히 생긴 단서도 포함합니다. 어포던스(affordance)는 어떤 사람과 환경의 관계에서 실제로 어떤 행동이 가능한지를 말합니다. 문을 열 수 있는가와 여는 방법을 알아볼 수 있는가는 서로 다른 질문입니다. Norman, 2008

어포던스를 살필 때는 물건과 그 물건을 쓰는 사람을 함께 봅니다. 같은 손잡이도 손이 닿고 잡아서 힘을 줄 수 있는 사람에게 가능한 행동과, 그러기 어려운 사람에게 가능한 행동은 다를 수 있습니다. ‘손잡이가 있다’는 물건의 속성만으로 모든 사람이 같은 행동을 할 수 있다고 판단하기 어려운 이유입니다. Norman, 1999, Perceived Affordance

같은 물건도 할 수 있는 행동은 다릅니다

같은 머그여도 지금 자세에서 누구나 집을 수 있나요?

머그가 보이는가와, 지금 자세에서 실제로 집을 수 있는가는 다른 질문입니다. 물건이 보인다는 사실 자체를 시그니파이어라고 부르는 예시는 아닙니다.

반면 손잡이 모양을 보고 ‘당기면 열리겠다’고 생각했다면 그 모양을 시그니파이어로 읽은 것입니다. 실제로 손잡이를 잡아당길 수 있어도 문은 밀어야 열릴 수 있습니다. 같은 손잡이를 두고 가능한 행동과 그 행동에 대한 예상을 따로 살펴보는 이유입니다.

가상 신청 화면으로 돌아가 보세요. 제목을 눌러 수정할 수 있는 동작은 이미 있습니다. 제목에 붙인 ‘신청 내용 수정’이라는 문구는 그 동작을 알리는 단서가 될 수 있습니다. 문구만 붙였는데 동작하지 않는다면, 단서를 추가한 것이지 기능을 만든 것은 아닙니다. 반대로 동작이 있어도 알아볼 단서가 없으면 사용자가 우연히 눌러 보기 전까지 발견하지 못할 수 있습니다.

이 구분을 쓰면 고칠 곳이 분명해집니다. 필요한 동작이 없다면 기능을 구현해야 합니다. 동작은 있지만 발견하기 어렵다면 그것을 알리는 단서를 고칩니다. 동작하지 않는 표시가 버튼처럼 보인다면, 실제 기능을 붙일지 버튼 같은 인상을 없앨지 결정합니다.

같은 연필도 모두에게 같은 뜻은 아닙니다

연필 아이콘이 보이면 우리는 흔히 수정을 떠올립니다. 하지만 처음 보는 서비스에서는 무엇을 수정하는지까지 분명하지 않을 수 있습니다. 신청 제목일까요, 신청서 전체일까요? 아이콘을 알아보는 일과 그 화면에서의 쓰임을 이해하는 일은 따로 살펴볼 필요가 있습니다.

연필을 보고 수정을 떠올리는 데에는 배운 경험도 작용합니다. Norman은 1999년 글에서 커서 모양과 스크롤바의 작동 방식을 학습된 관습으로 설명합니다. 관습은 여러 화면을 쓰며 익힌 표현과 사용 방식입니다. 그래서 서로 다른 기기와 서비스를 써 온 사람은 같은 단서도 다르게 읽을 수 있습니다. Norman, 1999, Constraints and Conventions

연필을 ‘수정’으로 알아보았어도, 옆에 무엇이 놓였는지에 따라 수정할 대상은 달라집니다. 프로필 사진 옆에서는 사진을, 신청 제목 옆에서는 제목을 바꾸는 것으로 읽힐 수 있습니다. 그래서 ‘이 아이콘은 다 알아요’에서 검토를 끝내지 않습니다. 처음 방문하는 사람이 신청서 전체를 고치는 화면이라면 ‘신청 내용 수정’처럼 대상을 함께 적는 안을 비교해 볼 만합니다. 자주 쓰는 도구에서는 더 짧은 표현이 충분할 수도 있습니다.

큰 표시가 행동의 뜻까지 알려 주는 것은 아닙니다. Google Translate 팀은 2018년 설계 회고에서 기능을 여는 영역을 크고 눈에 띄게 만든 첫 시도 뒤 오히려 카메라·대화 기능의 사용이 줄었다고 설명합니다. 이후 익숙한 화면을 바탕으로 아이콘, 행동 이름, 기능별 역할을 함께 다듬었습니다. 여러 요소를 함께 바꾼 사례이므로 문구 하나의 효과로 볼 수는 없습니다. 여기서 가져올 질문은 두 가지입니다. 사용자가 표시를 발견했나요? 그곳에서 무슨 일을 할 수 있는지도 알았나요?

라벨이 무엇을 약속하는지 읽어 보기

누르기 전의 안내와 누른 뒤의 응답

수정할 곳을 찾았다고 모든 안내가 끝나지는 않습니다. 메모를 바꾸고 저장했는데 목록도 그대로이고 응답도 없다면, 저장된 것인지 다시 눌러야 하는지 망설이게 됩니다. 여기서 필요한 정보가 앞의 행동 이름과 어떻게 다른지 살펴보겠습니다.

‘신청 내용 수정’은 어디에서 무엇을 할지 알려 줍니다. 저장 뒤에 바뀐 메모와 완료 문구는 방금 한 행동이 반영됐는지 알려 줍니다. Norman과 Wadia는 입력을 시스템이 감지하고 이해했는지 알려 주는 역할을 피드백으로 설명합니다. 이 설명은 기능을 발견하는 문제와 조작 결과를 확인하는 문제를 구별할 때 도움이 됩니다. Norman·Wadia, 2013, Feedback

‘저장됐습니다’를 읽으면 두 가지를 알 수 있습니다. 방금 한 저장이 반영됐다는 응답은 피드백이고, 지금 저장된 상태라는 단서는 시그니파이어입니다. 한 문구가 두 역할을 할 수 있으므로 표시가 나온 시점만으로 이름을 나누기보다, 어떤 질문에 답하는지 살펴보세요. 어디서 수정하는지, 입력이 받아들여졌는지, 현재 어떤 상태인지를 각각 확인하면 됩니다.

누구에게 보이는 단서인가

같은 화면을 쓰는 사람 중에는 색을 구별하기 어려운 사람도, 스크린리더라는 보조기술로 내용을 듣는 사람도, 버튼 이름을 말해 조작하는 사람도 있습니다. 화면에서 보이는 단서가 이들에게도 전달되는지 살펴봅시다. 웹 콘텐츠 접근성 지침인 WCAG의 관련 기준이 점검에 도움이 됩니다.

먼저 색을 빼고도 뜻이 남는지 봅니다. 이 예시의 배지는 색뿐 아니라 ‘접수됨’이라는 말로 상태를 전달합니다. 선택된 항목을 노란색으로만 표시한다면 색을 구별하기 어려운 사람에게는 선택 여부가 전달되지 않을 수 있습니다. WCAG 2.2의 1.4.1은 정보를 전하거나 행동을 표시하는 유일한 시각적 수단으로 색만 사용하지 않도록 요구합니다. 색과 함께 체크 표시나 텍스트 등으로도 뜻을 전달하세요. W3C 해설 1.4.1

다음은 이름과 역할입니다. 화면에 ‘신청 내용 수정’이 보여도 스크린리더에는 이름 없는 버튼으로 전달될 수 있습니다. 여기서 이름은 ‘신청 내용 수정’, 역할은 ‘버튼’처럼 무엇을 어떻게 조작하는지 알려 주는 정보입니다. 4.1.2는 버튼이나 입력칸 같은 컨트롤의 이름·역할을 프로그램이 알아낼 수 있어야 한다는 요구 등을 다룹니다. 보이는 글자와 보조기술에 전달되는 정보를 함께 확인해야 합니다. W3C 해설 4.1.2

마우스를 올리지 못하면 어떤 단서가 남나요?

숨긴 설명이 다른 입력 방식에서도 전달되나요?

수정 행동 이름을 마우스를 올릴 때만 보여 주는 가상의 도구를 생각해 보세요. 이 가정에서는 터치로 누르거나 키보드로 초점을 옮겨도 그 이름이 나타나지 않습니다. 같은 행동 이름을 기본 화면에 남기면 무엇을 할 수 있는지 먼저 읽고 조작할 수 있습니다.

문제 도구의 포인터 상태

—

포인터를 올린 동안만 신청 내용 수정이라는 이름이 나타나는 가정입니다.

같은 도구를 터치로 사용

—

문제 가정: 터치로 눌러도 숨긴 이름이 나타나지 않습니다.

신청 내용 수정

변경안: 누르기 전에 행동 이름을 기본 화면에서 읽습니다.

같은 도구를 키보드로 사용

—

문제 가정: 초점 테두리는 보여도 행동 이름은 나타나지 않습니다.

신청 내용 수정

변경안: 행동 이름과 현재 초점을 따로 제공합니다.

보이는 행동 이름: ‘신청 내용 수정’. 보조기술에 전달할 이름도 따로 확인합니다. 실제 구현에서 보이는 이름이 자동으로 적절히 전달되는지 검수해야 합니다. 초점에서도 열리는 설명은 가능하며, 여기서는 의도적으로 포인터에만 연결된 가정을 비교했습니다.

화면에서 읽은 말로 조작할 수도 있어야 합니다. ‘수정’ 버튼을 보고 음성으로 ‘수정’을 말했는데, 보조기술에 전달된 이름이 전혀 다르면 찾기 어려울 수 있습니다. 이때 쓰는 접근 가능한 이름은 보조기술이 요소를 식별할 때 읽는 이름입니다. 2.5.3은 텍스트 라벨이 있는 컨트롤에서 이 이름에 보이는 텍스트를 포함하도록 요구합니다. 이 조항은 보이는 텍스트가 없는 아이콘 전용 버튼과 구분해 적용합니다. W3C 해설 2.5.3

마지막으로 저장 결과도 전달해야 합니다. 화면에 ‘저장됐습니다’가 나타나도 스크린리더 사용자는 변화를 놓칠 수 있습니다. 4.1.3은 사용자가 그 메시지로 초점을 옮기지 않아도 보조기술이 상태 메시지를 알려 줄 수 있도록 구현할 것을 요구합니다. 이 예시에서는 저장 완료가 전달되는지 확인하되, 모든 화면 변화를 경고처럼 읽게 하지는 않습니다. W3C 해설 4.1.3

이 기준들은 서로 다른 문제를 다룹니다. 색, 이름, 역할, 결과 전달을 확인한 뒤 나머지 접근성 요구도 살펴야 합니다. 위 링크는 이해를 돕는 해설이며, 지켜야 할 성공기준과 적합성 조건은 WCAG 2.2 본문에 있습니다.

‘찾았다’ 이후에도 확인할 것

이제 사용자에게 가상 목록을 보여 주고 수정 과제를 부탁한다고 생각해 보세요. 먼저 어디를 누르는지 관찰한 뒤, 무엇을 단서로 골랐고 어떤 동작을 예상했는지 물어봅니다. 실행 전에 예상을 말하게 할 수도 있지만, 질문이 단서에 주의를 돌릴 수 있으므로 관찰 절차를 구분해 기록합니다. 단서를 발견하지 못했는지, 발견했지만 뜻을 달리 읽었는지도 나누어 봅니다.

반복 사용자는 화면 위치를 외워 문제없이 동작할 수 있습니다. 그래서 숙련자의 성공만으로 처음 온 사람도 쉽게 발견한다고 판단하지 않습니다. 반대로 처음 온 사람이 잠깐 머뭇거렸다는 이유로 전문 도구의 모든 관례를 버릴 필요도 없습니다. 누구의 어떤 과제를 돕는지 정한 뒤 비교해야 합니다.

단서가 많아질 때 생기는 비용도 살핍니다. 모든 곳에 테두리, 화살표, 툴팁(짧게 나타나는 도움말), 설명을 붙이면 무엇을 우선해야 할지 다시 판단해야 합니다. 핵심 기능을 발견하는 데 필요한 단서부터 추가하고, 같은 정보를 반복하는 표현은 덜어 보세요.

특히 광고, 유료 전환, 구독 해지처럼 이해관계가 갈리는 화면에서는 단서의 정확성을 더 엄격하게 물어보세요. 닫기처럼 보이는 표시가 다른 페이지로 이동하거나, 건너뛰기처럼 보이는 문구가 동의를 실행한다면 클릭을 잘 유도했어도 사용자의 기대와 어긋납니다. 단서는 사용자가 하려는 행동을 돕는 약속이어야 합니다.

확인해볼 질문

• 처음 보는 사람은 과제를 받았을 때 어디를 눌러 보려 하나요?
• 눌러도 될 것처럼 보이지만 동작하지 않는 요소는 없나요?
• 행동을 시작하는 곳의 이름과 실제로 일어나는 일이 맞나요?
• 색을 제외해도 상태와 행동이 구별되나요? 보조기술에도 이름과 역할이 전달되나요?
• 수정안에서 기능을 쉽게 찾을 수 있나요? 오해한 행동과 불필요한 조작도 함께 확인했나요?

시그니파이어를 점검할 때는 화면이 암시하는 행동을 적고 실제 동작과 나란히 놓아 보세요. 기능이 있는데 찾지 못하는 곳에는 단서를 보충하고, 눌러도 동작하지 않는 곳은 버튼처럼 보이지 않게 구분합니다. 마지막으로 처음 보는 사람도 같은 뜻으로 읽는지 확인하세요.

근거의 범위

개념 설명은 Norman의 글, 버튼 문구는 GOV.UK의 공식 지침, 접근성은 W3C의 기준과 해설을 근거로 삼았습니다. 신청 화면과 문·공원 장면은 이를 이해하기 위한 가상 예시입니다. Google Translate는 2018년 제품팀의 설계 회고로 읽었습니다. 이 자료들은 본문의 변경안이 얼마나 빨라지거나 더 성공적으로 쓰일지를 입증하지 않습니다.