[개발일지] 05. UX와 사용성에 대한 나의 고민 (feat. 개발자 시점)

개발자가 UI/UX와 사용성을 생각할 필요 있을까?

네! 저는 이 질문에 대한 답이 정말정말정말정말정말 확고합니다. 반드시 필요하다고 생각해요. "개발자는 개발만 잘하면 되는거 아니야?", "UI/UX는 디자이너랑 QA 팀이 해주겠지!" 이 말들을 간혹 들었던 것 같아요. 처음에는 저도 그렇게 생각했던 적이 있었어요. "요구사항대로 기능을 구현하기도 바쁜데.. 내가 그것까지 생각해야하나?" 하는 나쁘고 안일한 생각이었죠. 

 

하지만 실제 사용자가 있는 팀 프로젝트와 협업을 경험해보니 생각이 완전히 바뀌었어요. 기능은 '동작'하는 것만으로는 충분하지 않더라고요. 사용자가 이해할 수 있어야 하고, 자연스럽게 사용할 수 있어야 하고, 헷갈리지 않아야 합니다.

 

예를 들어,

- 버튼은 분명히 있는데 사용자가 못 찾는다면?

- 기능은 완벽하게 구현했는데 사용 흐름이 어색하다면?

- 텍스트 입력 시 불편하다면? 

- 당연히 동작할 것 같은데, 동작하지 않는다면?

 

그건 과연 "잘 만든 기능"일까요? 저는 아니라고 생각합니다. 개발자는 결국 사용자가 실제로 만지는 화면을 만드는 사람입니다. UI를 코드로 구현하는 것도 개발자이고, 사용 흐름을 연결하는 것도 개발자이고, 로딩 속도와 반응성을 책임지는 것도 개발자라고 생각해요.

 

탭탭을 만들면서 저는 이런 질문을 계속 던졌습니다.

- 이 버튼 위치가 정말 최선일까?

- 한 번 더 터치해야 하는 이 과정은 줄일 수 없을까?

- 이 메세지는 사용자에게 친절한가?

- 액션에 대해 사용자에게 충분한 인터랙션이 제공 되었는가?

- 설명하지 않아도 사용할 수 있는가?

 

이 고민들은 디자이너만의 몫이 아니었고, 저희 개발 팀도 적극적으로 의견을 내고, 개선 방향을 제안했습니다.

 

서론이 조금 길었네요! 그럼 지금부터, 제가 탭탭을 개발하면서 UX와 사용성에 대해 어떤 고민을 했고, 어떤 방식으로 사용성을 개선해 나갔는지 이야기해보려고 합니다.

---

QA는 중요하다.

012

자랑스러운(?) QA의 흔적들

 

저희 탭탭 팀은 디자인이 수정되거나, 기능이 변경될 때마다 내부 QA를 꾸준히 진행했습니다. 제가 직접 QA를 진행하면서 몇 가지 느낀점이 있는데요!

 

1. 개발할 땐 전혀 인지하지 못했던 것들이 보인다.

당연하지만 개발할 때는 기능이 정상적으로 동작하는지에 집중하게 됩니다. 하지만 직접 사용자의 흐름으로 따라가 보니, 그동안 보지 못했던 작은 어색함들이 눈에 들어오기 시작하더라고요.

 

2. 사용자의 입장에서 바라보면 사소한 것도 바로 체감된다.

한 번 더 눌러야 하는 버튼, 애매한 안내 문구 등 개발자에겐 사소할 수 있지만, 사용자 입장에서는 그게 '불편함'이 되더라고요. 직접 써보니 그 차이를 명확하게 느낄 수 있던 것 같아요.

---

과도한 배려는 오히려 독?

탭탭은 사파리 익스텐션 기반 서비스입니다. 사파리 익스텐션 특성상 초기 설정이 제대로 되어야 기능을 정상적으로 사용할 수 있습니다. 그래서 저희 팀은 온보딩에 많은 공을 들였습니다.

 

- 사파리 익스텐션을 활성화하는 방법

- 설정에서 권한을 허용하는 방법

- 실제 사용 흐름과 예시

 

게다가 사용자가 중간에 놓치지 않도록, 모든 단계를 스킵 없이 완료해야만 앱을 사용할 수 있게 설계했습니다. (최악의 선택이었죠 ..)

 

당시 저희 팀의 생각은 단순했어요. "기능을 제대로 쓰려면, 제대로 알아야 한다.", "설정을 안 하면 결국 못 쓸 텐데, 미리 친절하게 아주 자세히 알려주자." 저희는 이것이 사용자에 대한 배려라고 생각했습니다. 

 

하지만 유저 테스트를 진행한 결과, 저희 예상과는 다른.. 피드백이 들어왔습니다. 저희는 기능을 '잘 쓰게' 하려 했지만, 사용자는 먼저 '가볍게 써보고' 싶어 했습니다. 이 차이는 생각보다 컸습니다. 

---

탭탭은 사용자가 실패하지 않도록 완벽한 가이딩을 설계했습니다. 하지만 그 과정에서 사용자의 선택권을 거의 남겨두지 않았습니다.

 

1. 스킵 불가

2. 모든 단계 완료 필수

3. 긴 설명

4. 상세한 가이드

 

문제는 이것이 "친절함"이 아니라 사용자에게는 "의무"처럼 느껴졌다는 것입니다. 생각해 보면 사용자는 아직 이 서비스에 애착도, 신뢰도 없습니다. 그런 상태에서 긴 설명과 필수 과정을 요구받으면, 그건 배려가 아니라 진입 장벽이 된다는 것을 깨닫게 된 정말정말정말 소중한 경험이었습니다.

---

사용자는 생각보다 냉정하구나

유저 테스트를 직접 해보면서 느낀 건 사용자는 생각보다 냉정하다는 것을 느꼈어요.

 

기능을 꽤 공들여 만들었고, 여러 디테일도 신경 썼고, 나름대로 많이 고민하고 개발했다고 생각했습니다. 하지만 사용자는 생각보다 냉정했어요. 길면 넘기고, 복잡하면 멈추고, 조금이라도 막히면 다른 걸 합니다. 우리가 중요하다고 생각한 포인트, 기획 의도들은 사용자에겐 그냥 하나의 화면일 뿐이었습니다.

 

특히 UT를 진행하면서 가장 인상 깊었던 건, 사용자들은 우리가 생각한 '맥락' 안에서 움직이지 않는다는 점이었습니다. 기능 A를 이해하고 나면 자연스럽게 기능 B를 써볼 거라고 생각했습니다. 하지만 실제로는 눈에 띄는 것부터 눌러보고, 바로 이해되지 않으면 넘기고, 한 번 막히면 그냥 멈췄습니다. 

 

UT는 그래도 비교적 친절한 환경이라고 생각해요. "써보세요"라는 요청을 받고, 시간을 내서 참여해주는 자리니까요. 조금 막혀도 한 번 더 시도해보고, 뭔가 이상해도 "이게 이런 건가요?"라고 물어봐 줍니다. 그런데도 흐름은 쉽게 끊겼습니다.

 

그렇다면 UT가 아닌 실제 환경에서는 어떨까요? 아마 더 빨리 판단하고, 더 빨리 포기할 것이라고 생각해요.

---

그래서 개발자는 무엇을 해야 할까?

1. 최소한 한 번은 사용자처럼 써봐야 한다.

- 직접 사용해 보면, 개발하면서 발견하지 못했던 불편함들이 눈에 들어오더라고요. 단순히 써보는 것만으로 끝나지 않고, 어떤 과정에서 막혔는지, 어디서 멈췄는지, 어떤 부분이 불편했는지 꼼꼼히 기록하는 것도 중요하다고 생각해요. 저는 실제로 이 기록을 바탕으로 회의에서 공유하고, 몇 가지가 실제 탭탭에 반영되기도 했습니다!

 

2. 디자이너에게 맡기지 말고, 같이 고민하자

- UX는 직군의 영역이 아니라, 팀 전체의 영역이라고 생각해요. 개발자는 기술적 제약을 알고 있고, 디자이너는 시각적 흐름을 알고 있고, 기획자는 서비스 맥락을 알고 있고, QA는 문제를 가장 먼저 발견합니다. 이 네 가지가 모여야 비로소 좋은 UX가 만들어지는 것 같아요.

---

결국 저는 이렇게 생각합니다

1. 개발자가 UX를 고민한다는 건 디자이너나 기획자의 영역을 침범하는 게 아니라, 사용자 경험에 대한 책임을 함께 지는 태도라고 생각해요.

 

2. 사용자가 처음 서비스를 접했을 때 느끼는 불편함은 개발자가 만든 코드와 직접 연결되어 있습니다. 개발자가 이러한 경험을 직접 체감하고 개선하려고 할 때, 서비스는 점점 더 직관적으로 변화할 것이라고 생각해요.

 

3. 협업에 있어서 이런 태도는 큰 힘을 발휘한다고 생각해요. 문제를 발견하고 개선안을 제안하는 과정에서 디자이너, 기획자와 자연스럽게 소통하게 되고, 서로 다른 관점이 모여 더 탄탄한 사용자 경험이 만들어진다고 생각해요.