2025. 7. 10.

내가 먼저 느껴야 하는 UX

VienceDeveloper

"또 성장"

UX가 왜 중요해요?

회사일을 하다가, CTO님과 이런 이야기를 나눈 적이 있다.

나 : UX는 따로 디자이너가 있고, 프론트는 그냥 그거 그대로 적용하면 되지 않나요?

CTO : 아뇨, 무조건 중요합니다. 윤찬님이 말씀하시는 건 지금 UI이고, 개발자에게는 UX가 필수에요.

사실 그전까지 나는 UX를 디자이너의 영역이라고만 생각했다. 그리고 프론트엔드의 핵심은 최적화나 상태 관리 같은 기술적인 부분이라고만 생각했다.

그래서 이 버튼은 이쪽에 두는 게 더 사용자 경험에 좋아요 같은 말은 단순히 부수적인 요소라고 여겼다. 심지어 그런 이야기를 하는 게 왠지 에겐남이 되어가는것 같았다. 코더라면 코드로만 말하고, 기술적인 완성도로 인정받는 게 멋진 거라고 생각하고 있었기 때문이다.

하지만 CTO님은 그런 내 시각을 바로잡아주셨다. 사용자 경험을 고민하는 것 역시 개발자의 중요한 역할이며, 아직 내가 더 배워야 할 부분이라고 하셨다. UX의 정의가 뭘까?

사용자가 제품을 처음 접하고, 이해하고, 사용하는 전 과정에서 느끼는 총체적인 경험

클릭했을 때 얼마나 빠르게 반응하는지
오류가 발생했을 때 얼마나 이해하기 쉽게 알려주는지
사용자가 원하는 정보를 얼마나 자연스럽게 찾을 수 있는지

이 모든 것들이 UX에 포함된다.

사실 위와 같은 내용은 기획 회의를 할 때, 의견을 많이 내긴 했었다. 근데 난 이게 UX라고 생각을 하지 않고 그냥, 기획적인 부분이라고만 생각을 했다. 내가 개발을 할 때, 이 것을 갖추고 들어가고 아니고를 중간에 고민하냐?의 차이가 컷던거 같은데 만약 이것을 갖추었을때, 아닐때를 한번 생각해보자

case 1 사용자가 오른쪽에 있는 작은 버튼을 누르면 사이드 패널이 펼쳐진다.

case 2 사용자가 오른쪽의 작은 버튼을 누르면 사이드 패널이 펼쳐진다. 그런데 거기에 더해, 사용자가 키보드에서 Tab 키를 눌러도 사이드 패널이 자연스럽게 열리도록 설계한다.

두 경우 모두 사이드 패널이 열린다는 기능은 동일하다. 하지만 사용자가 패널에 도달하는 방식은 완전히 다르다.

첫 번째 경우는 버튼 클릭이라는 단일 경로만 제공한다.

두 번째 경우는 키보드 접근성까지 고려해, 사용자가 더 다양한 상황에서 불편함 없이 패널을 열 수 있다.

그리고 이 차이는 단순히 기능의 유무가 아니라 구현 방식에서도 크게 드러난다.

첫 번째 경우는 간단히 지역 상태만 관리하면 충분하다.
두 번째 경우는 키 이벤트를 처리해야 하고, 화면의 다른 input에 focus가 잡혀있지 않을 때만 Tab이 동작하도록 해야 한다. 또, Tab으로 패널을 열었을 때 패널 안에 input이 있다면 focus 흐름을 잠시 멈추게 하고, focus가 사라졌을 때 다시 키 이벤트가 동작하도록 제어해야 한다.

즉, 기능적으로는 비슷해 보이지만 UX를 고려한 설계는 코드의 구조와 복잡도까지 달라진다는 점이다.

결국 서비스는, 사용자가 편하게 쓰게 한다는 것이며 내가 중간에 UX를 고려하지 않는다면, 코드가 또 추가되거나 구조가 바뀔수 있다는 것이다. 이것을 UX디자이너가 있다 하더라도, 프론트엔드 개발자도 항상 고려해야하는 이유는 어떤 UI 설계도 실제 코드로 옮기는 과정에서 디테일이 달라질 수밖에 없으며, 결국 개발의 지연으로 이어질 수 있기 때문이다.

UX를 가슴 한쪽에 항상 간직하고 개발

그렇다면, 내가 개발을 하면서, UX를 고려하며 개발했을때 어땠을까? Workspace의 노드중 dataset Congifuation이라는 노드가 있다.

앞의 여러 노드에서 출력되는 값을 하나로 묶어주는 역할을 하는 노드가 있었다. 처음 받은 요구사항은,

input으로 들어오는 노드가 몇 개인지 선으로는 구분하기 어렵기 때문에, 노드 위에 숫자를 표시

하지만 시각화를 중요하게 생각하는 우리 회사에서는 단순히 텍스트로 숫자를 표시하는 방식이 최선은 아니라고 판단했다. 숫자보다 모양 자체로 직관적으로 표현하는 방식이 더 이해하기 쉽고, 디자인적으로도 일관성을 유지할 수 있기 때문이다.

그래서 실제로 들어온 input의 개수만큼 포트가 동적으로 보이도록 구현하는 방법을 선택했다.

입력으로 연결된 노드의 수를 기준으로, dataset configuration 노드가 해당 input 개수를 감지한다. 그리고 이 값에 따라 포트가 자동으로 생성/표시되도록 커스텀 했다. 결국 코드적으로도 변화를 주게 되며 전달되는 데이터 양식도 많이 달라지게 되었다. 사용자의 입장에서는, 이 방식의 노드가 더 직관적이었으며, 해당 노드의 기능을 명확하게 말할 수 있었다.

결국 개발의 지연을 막는다.

또 다른 예시로는 Workspace의 전체 사용 경험이 있다. 이 부분은 벤치마킹을 통해 얻은 아이디어였는데, 현재 editor의 키 조작 방식은 사용자에게 익숙한 경험을 주지 못하고 있었다.

화면 이동은 왼쪽 마우스를 클릭한 뒤 드래그해야 하고,
여러 노드를 삭제하려면 Ctrl 키를 누른 상태에서 일일이 선택 후 삭제해야 한다.

하지만 이는 시장에서 많이 사용되는 에디터와는 다른 방식이었다. 내가 말하는 ‘익숙한 에디터’란 Photoshop, Figma, PowerPoint 등, 많은 사용자가 이미 손에 익은 조작 경험을 말한다. 그래서 Figma와 동일한 조작 방식을 적용하기로 했다.

오른쪽 마우스는 드래그를 통해 여러 노드를 선택하게 함
가운데 스크롤을 통해, 화면을 이동할 수 있음
마우스별, 가운데 스크롤 버튼이 없는 경우가 있기 때문에, 화면에 스위칭 버튼을 추가

결국 이것도, 익숙함을 제공하면서, 초반에 확실한 데이터 구조와 상태 관리를 잡을 수 있었다.

마지막 예시로는, 회사 서비스는 아니지만 칸반을 예전 구현할 때 필요했던 것이다.

이렇게 칸반에 각각의 데이터들이 있다고 할때, 하나의 element를 선택하게 된다면, 오른쪽에 패널이 나오게 된다.

이 경우에는, 내가 선택한 요소가 해당 패널에 가려지게 된다. 그렇기 때문에 잘못 선택을 해버린 경우, 어떤 element에 대한 패널인지 구분이 가지 않을 수 있다. 따라서, 화면의 절반을 기준으로 해서,

오른쪽 부분(초록)을 선택했을때, 그만큼, 펼쳐지는 패널의 width만큼, 칸반의 오른쪽에는 가상의 공간을 만들어 밀리도록해, 선택한 element와 패널을 동시에 볼 수 있도록 하였다.

다시 패널을 닫을때는 당연하게, 가상 공간이 없어져, 다시 원래 배치로 복구가 된다.

이렇듯, UX 디자이너가 있다고 해도, 프론트엔드 개발자가 UX를 따로 고려하지 않으면 개발 과정에서 불필요한 지연이 발생하거나, 구현 도중 구조를 변경해야 하는 상황이 생길 수 있다.

사용자 경험은 단순히 화면을 보는 사람만 느끼는 것이 아니다. 개발자인 나조차 그 경험을 충분히 체감해야 한다. 초반에 잠깐 경험만 하고 결과물 없이 넘어간다면, 실제 사용자가 느낄 경험과 개발자가 구현한 코드 사이에 큰 간극이 생기게 된다.

그래서 개발 과정에서도 내가 직접 경험하며 느낀 UX를 코드에 반영하는 것이 중요하다. 버튼의 위치, 반응 속도, 인터랙션 하나까지도 직접 체감하며 조정하면, 사용자 입장에서 보다 자연스럽고 편리한 경험을 만들어낼 수 있다.

결국, 모두가 결과물을 보기 전까지는 완벽한 UX를 만들어낼 수 없기 때문에, 중간 과정에서 지속적으로 수정하고 의견을 내는 것이 진정한 UX 완성으로 이어진다고 생각한다.