어포던스 대신 기능, 신호, 기대

UI/UX 디자이너, 또는 프론트엔드 개발자라면 어포던스(Affordance)라는 용어를 들어보셨을텐데요. 저는 원래 이 용어를 '행위유발성'으로 이해했었고, 프론트엔드 개발자 입장에서 대략 이런 심상을 가졌었어요.

• 버튼처럼 생겼으면 클릭 가능해야 한다
• 클릭 가능하다면 클릭 가능할 것처럼 생겨야 한다 (링크를 푸른색 또는 밑줄로 표시, 버튼은 버튼처럼 표시 등)

대화방에서 다시 배운 어포던스

그런데 우연히 그룹대화방에서 어포던스 이야기라는 강규영님의 훌륭한 글을 접해, 어포던스라는 용어 및 개념이 오용된 역사에 대해 잘 알게 됐습니다. 재미있는 역사 이야기는 원글을 참조하시고, 결론부를 좀 길게 인용하면 이렇습니다.

아무튼 노먼은 어포던스는 원래 깁슨의 뜻대로 돌려놓고 디자이너들은 기표라는 개념에 더 집중하길 바랐으니 이 바람에 따라 짧게 정리를 해보려고 한다.

어포던스란?
- 행위자와 환경 사이에 존재하는 행동 가능성possibility of action. 굳이 번역하자면 행동유발성 보다는 행동가능성. 행위자란 동물, 사람 등을 이른다. 환경에는 다른 행위자도 포함되며, 이들이야 말로 가장 중요한 지각의 대상이다. 노먼이 후기에 제안한 “사회적 기표” 개념과 연결될 수 있는 지점이다.
- 환경에 내재된 속성이 아니라, 행위자와 환경 사이의 관계에 존재. 예를 들어 “앉을 수 있음”이라는 어포던스는 의자의 본질적 속성이 아니라, 의자의 모양과 크기가 행위자의 몸집이나 골격과 적절히 일치하는 경우에만 존재한다. 어른과 의자 사이에 존재하는 어포던스가 아이와 의자 사이에는 존재하지 않을 수 있다. 개미과 벽 사이에는 “기어오를 수 있음”이라는 어포던스가 존재하지만, 인간과 벽 사이에는 존재하지 않는다.
- 행위자가 어포던스를 지각하건 지각하지 않건 행위자가 원하건 원하지 않건, 어포던스는 존재. 예를 들어 행위자가 의자에 앉을 수 있다는 사실을 지각하지 못했더라도, 그 행위자와 의자 사이에는 “앉을 수 있음”이라는 어포던스가 항상 존재한다. 또는 행위자가 앉기를 원하지 않더라도 어포던스는 존재한다.
- 어포던스를 넣었다? 없던 행동 가능성이 새로 추가된 경우에만 ‘어포던스를 넣었다’고 표현하면 될텐데, 보통은 그냥 ‘기능을 추가했다’고 말하면 되니까 굳이 ‘어포던스를 넣었다’고 말할 필요는 없어 보인다. 아주 특별한 경우가 아니라면 쓰지 않아도 될 것 같다.

기표란?
- 기표는 무언가를 발신하는 역할을 한다. 특히 어떤 동작을 어떻게 수행할 수 있는지를 알려준다. 기표는 반드시 지각할 수 있어야 하며, 그렇지 않다면 기표가 제대로 작동하지 않는 것이다.
- 기표는 의도적으로 설계될 수도 있고, 따론 우연하게 만들어질 수도 있다. 예를 들어 사람들이 많이 다니는 산길에는 자연스럽게 지각할 수 있는 ‘길’이 만들어지는데 이것 또한 기표다.
- 사용자에게 드러내야할 어포던스가 잘 드러나지 않는다면 기표를 잘 디자인하여 추가한다. 평소 ‘어포던스를 넣었다’고 말해 왔지만 사실 우리는 그동안 기표를 넣었던 것이다.

기표가 있다면 기의도 있어야 하지 않을까?

그런데 이걸 읽고 나니 '기표'라는 단어에서 호기심이 생겼어요. 본래 기표와 기의는 신호학에서 나온 개념이고 항상 짝을 이뤄 등장하는데, 기표가 있다면 기의도 있어야 하지 않을까? 하는 생각이죠.

특히 프론트엔드 개발자로서 UI 디자인에서 이 개념을 어떻게 활용할 수 있을지 궁금해졌습니다. 그래서 Google AI Studio에서 Gemini 2.5 Pro에게 질문을 던졌죠.

https://wiki.g15e.com/pages/A%20story%20of%20affordance

먼저 이 글을 주의깊게 읽어줘.

'기표(signifier)'라는 단어가 글 후반부에 주요하게 사용됐는데, 나는 기표 라고 하니까 기호학에서 말하는 '기의'도 같이 떠올라. UX/UI 관점에서 '기표'라는 단어를 affordance와 다르게 활용한다면 여기서 '기의'는 어떻게 의미를 가지면 좋을까?

참고로 나는 프론트엔드 개발자로서 꽤 긴 경력을 가지고 있어. 내가 생각을 더 확장할 만한 질문들도 자유롭게 던져줘.

그랬더니 아래와 같이 답변해줬습니다.

'기의'를 크게 기능, 상태와 결과에 대한 기대, 감정적/추상적 가치로 생각할 수 있겠다는 제안이었죠. 그 뒤에 해준 질문들, 특히 사회적 맥락에 대한 질문도 좋았어요.

원래 이쯤에서 만족하려고 했는데...

다시 대화방에서 학습

이렇게 Gemini와 대화 나눈 이야기를 대화방에 올렸더니, 다른 분이 호기심이 생기셨는지 제 이야기를 다른 LLM에 먹여 또다시 대화를 이어나갔습니다. 핵심은 '애초에 어포던스, 기표, 기의라는 헷갈리고 생소한 용어를 써야 하는가?' 에 있었어요. 그분이 올려주시는 걸 읽다 보니 저도 공감됐고, 이런 용어를 써서 설명하는 것 자체가 불리한 포지션을 자처하는 거라는 생각도 들었습니다.

저는 LLM이 마지막에 준 이 이야기가 깔끔하고 좋더군요.

실무(UI/FE)에서는 ‘어포던스·기표·기의’ 같은 학술 용어를 최소화하고, 아래 3가지만 쓰는 게 제일 안전합니다.
1. Signal(신호) = 사용자가 감지하는 단서(텍스트/아이콘/모션/오디오/ARIA 등)
2. Capability(능력) = 시스템이 실제로 해낼 수 있는 작동(권한·상태·핸들러·가역성 포함)
3. Expectation(기대) = 사용자가 그 신호를 보고 무슨 일이 일어날지 예측한 내용

이걸 보니 제 스스로 이렇게 정리가 됐습니다.

• 좋은 UI는 적절한 signal을 뿜어, 시스템상의 특정 요소에 대한 capability를 사용자가 expect할 수 있게 해줘야 한다. (시스템, UI, 사용자: 가장 중요한 3가지 stakeholder)
• Signal: 이 페이지에는/이 컴포넌트에는 이런 signal이 존재해야 한다 → 자동화 테스트 대상
• Capability: 이 signal에 대해 행동(클릭, 스크롤 등)하면 요렇게 동작해야 한다 → 자동화 테스트 대상
• Expectation: 이런 사용자는 이 signal을 요런 capability로 expect할 것이다 → 유저 테스트 대상. 온보딩 퍼널 통과율 분석, 온보딩 플로우에 대한 녹화 관찰 등

다만 '신호, 능력, 기대'라는 용어가 최선일지 확신이 없어 다시 AI Studio로 돌아가 이렇게 질문해봤어요.

다른 분들과 대화를 나눠보면서 '어포던스', '기표', '기의'라는 단어들 자체가 혼란을 줄 수 있겠다는 판단을 내렸어. 그래서 그 대신 이렇게 용어 정리를 해봤는데 어떻게 생각해?
- (시스템의) Capability
- (UI의) Signal
- (사용자의) Expectation

괜찮아 보인다면, 적절한 한글 용어도 제안해줘.

여느때처럼 '완벽하다' 같은 말을 하며 아부를 하긴 했지만 좋은 답변을 받았습니다. 제가 생각했던 바와도 아주 잘 공명했고요.

특히 이부분이 좋았어요.

사용자가 혼란을 겪는다면, 이 세 단계 중 어디에서 문제가 발생했는지 추적할 수 있습니다.
- Capability 자체가 없는가? (기능 미구현)
- Signal이 부정확하거나 없는가? (잘못된 UI 디자인/구현)
- 사용자의 Expectation이 일반적인 관습과 다른가? (새로운 인터랙션에 대한 온보딩 부족)

그리고 Capability를 '능력' 대신 '기능'으로 표현하는 게 더 낫겠다는 결론을 얻었습니다.

맺으며

적어도 본인의 전문 도메인 내에서는 엄밀한 개념 정의를 머릿속에 들고다니는 게 문제 분석 및 의사소통에 큰 도움이 됩니다. '엄밀해지기 위해 호기심을 가지고 찾아보는' 습관이 이번에도 즐거운 학습을 만들어줬네요.

저는 앞으로 (UI/UX 디자인 또는 프론트엔드 분야에서) '어포던스'라는 단어를 웬만하면 쓰지 않으려고 합니다. 그리고 조직 내에서 이 단어를 쓰는 분이 있다면 조심스럽게 그 의미를 분해해서 기능/신호/기대로 소통하는 시도를 하려고 해요. 여러분도 동참해보시면 어떨까요? 😄

그리고 여담이지만, 저는 요즘 이런 흐름으로 좋은 학습을 하는 일이 많아서 무척 만족스럽습니다. 최근 제 글을 읽으신 분들은 이미 눈치채셨을 것 같아요.

• 흥미로운 주제 또는 자료(영상, 글)에 대한 이야기
• 그걸 직접 읽어보고, LLM과 함께 읽어보며 추가 대화
• 본인의 감상 또는 LLM이 해준 이야기를 가지고 옴
• 그 이야기를 다시 각자 LLM에게 가져가서 추가 대화
• 반복

이게 가능한 이유는 대화방의 멤버들이 모두 호기심이 많고, AI 리터러시가 높으며, 공유하는 컨텍스트는 많지만 관심사와 전문 영역은 살짝 다르니 다양성이 생기고, 서로를 존중하는 분위기이며, 사람 수가 너무 많지 않다... 등의 귀한 조건이 죄다 맞아떨어져서인 것 같아요. 여러분에게도 이런 모임이 있다면 학습 기회를 잘 살려보시는 것도 좋겠습니다.