며칠 전 UX와 관련된 글을 하나 올렸었죠. 그동안 UX와 사용성을 공부해왔고, 탭탭 프로젝트를 통해 경험한 고민과 배움을 기록으로 남기고 싶어서 작성한 글이었습니다.
그동안 블로그에는 UX에 대한 이야기를 따로 정리하지 않았는데, 이제는 그 생각과 과정을 기록해보려고 합니다. 앞으로 UX에 대한 글도 꾸준히 작성하며, 배움과 고민의 기록을 남겨보고자 합니다.
갑자기 UX 공부?, "개발자는 개발만 잘하면 되는 거 아닌가요?" 물론 개발 공부도 열심히 하고 있습니다! 다만, 여러 경험을 통해 최근에 한 가지 뼈저리게 느낀게 있습니다. 개발을 잘하는 것과, 사람들이 쓰고 싶어 하는 서비스를 만드는 것은 전혀 다른 문제라는 것을!
솔직히 처음에는 UX를 크게 중요하게 생각하지 않았습니다. 디자이너와 기획자가 정리해준 시안을 그대로 구현하면 개발자의 역할은 끝이라고 생각했습니다. 화면이 명세대로 나오고, 기능이 오류 없이 동작하면 "잘 만든 앱/서비스"라고 생각했었거든요.
하지만 실제 사용자가 있는 서비스를 직접 기획하고, 개발하고, 운영까지 해보면서 생각이 완전히 바뀌었습니다.
기능은 문제없이 동작했지만, 사용자는 생각보다 쉽게 질려하고, 쉽게 이탈했습니다.
왜 그럴까 고민해보니, 문제는 코드가 아니라 사용 경험에 있었습니다.
사용자가 어디에서 멈추는지, 무엇을 헷갈려하는지, 어떤 순간에 불편함을 느끼는지에 대한 것을 이해하지 못하면 아무리 공들여 개발한 기능도 의미가 없다는 걸 깨달았습니다.
개발자가 몇 달을 들여 서비스를 출시해도, 아무도 사용하지 않는다면 그건 기술적으로는 성공일지 몰라도, 서비스로서는 실패입니다.
그래서 저는 UX와 사용성을 공부하기 시작했습니다.
그렇다면 실제로 어떤 경험이 저를 이렇게 바꾸었을까요?
앞에서 이야기했듯이, 저는 실제 사용자가 있는 프로젝트를 운영해본 뒤에 생각이 바뀌었습니다. 직접 사용자 반응을 마주하는 것은 완전히 다른 경험이었습니다.
몇 가지 경험을 이야기해보려고 합니다.
물론 제가 개발한 앱과 서비스가 메이저한 서비스는 아닙니다. 수천, 수만 명의 사용자를 보유한 서비스도 아니었고, 대부분의 피드백은 지인, 멘토, 러너, 주변 사용자들에게서 받은 것이었습니다. 실제 유저 데이터의 표본 수가 정말 많다고 말하기는 어렵습니다. (그래도 최근 탭탭의 유저 수는 증가하고 있습니다. 하하 깨알 자랑)
하지만 오히려 그렇기 때문에 더 직접적이었고, 이러한 경험들이 저의 관점을 바꾸기 시작했습니다.
첫 번째 경험 - "있으면 좋겠는데?"가 "사용성이 좋아졌다"로 바뀐 경험
UX에 대해 본격적으로 고민하기 시작한 계기는 아카데미에서 진행했던 YAP 프로젝트였습니다.
YAP는 사용자의 신체 정보를 세팅하고, 식단을 입력하면 이를 기반으로 식단을 관리해주고 운동을 추천해주는 다이어트 보조 앱이었습니다. 핵심 기능 중 하나는 '식단 입력'이었고, 사용자는 음식을 검색해서 기록해야 했습니다.
기획 단계에서 팀원 '홍'과 이런 이야기를 나눈 적이 있습니다.
"검색할 때 손으로 치는 것 말고, 그냥 사진 찍으면 자동으로 음식 인식해서 검색 해주면 좋지 않을까요?"
처음에는 단순히 "있으면 편하겠다" 정도의 아이디어였습니다. 사실 이미지 검색 기능은 요즘 많은 앱에서 제공하고 있는 기능이기도 했고요. 그래서 그 당시에는 UX적인 깊은 고민이라기보다는, 트렌디한 기능 하나를 추가하는 느낌에 가까웠습니다.
팀원들과 논의 끝에 이미지 검색 기능을 도입했고, 구현까지 마쳤습니다. 그런데 갤러리 워크와 외부 사용자 테스트에서 예상과는 다른 반응이 나왔습니다.
"이미지 검색 기능 진짜 편하다"
이때 저는 느꼈습니다. 제가 생각한 건 단순히 '기능 추가'였는데, 사용자에게는 '입력 과정을 줄여주는 경험 개선'이었다는 것입니다. 사용자가 앱을 사용하는 과정에서 가장 번거로운 지점을 줄여주는 것, 그 작은 차이가 서비스에 대한 인상을 바꿀 수 있다는 걸 그때 처음 체감했습니다.
이 경험을 계기로 UX에 대해 더 깊이 고민하기 시작했습니다. '어떤 기능을 넣을까?'가 아니라, '사용자는 어디에서 불편을 느낄까?'를 생각하게 되는 경험이었습니다.
+ 지금 보니까 이미지 검색 플로팅 버튼이 조금 아쉽네요..! 저 버튼이 화면의 정보를 가리는 것이 살짝 불편하네요.
두 번째 경험 - 고민 했던 UX가 실제로 좋은 피드백을 받은 경험
YAP 프로젝트를 통해 UX의 중요성을 체감한 이후, 저는 기능을 설계할 때 UX에 대한 고민을 많이 했습니다. 이후 기획하고 개발했던 포비라는 서비스에서는 몇 가지 UX적인 고민을 적용해보았습니다.
포비는 전면 카메라를 통해 사용자의 집중 상태를 실시간으로 감지하고, 시간에 따른 집중력 변화를 시각적으로 기록해주는 앱입니다.
기획 의도는 명확했습니다. "사용자의 집중 상태를 향상시키는 것"
중요했던 건, 앱이 존재하되 '방해되지 않는 상태'를 만드는 것이었습니다.
그래서 저는 "이 앱이 오히려 사용자의 집중을 방해하고 있지는 않을까?"에 포커스를 맞추고 UX를 의도적으로 고민했습니다.
1. 화면이 시선을 빼앗으면 안 된다.
집중 측정이 시작된 상태에서 화면이 계속 밝게 켜져 있다면, 사용자는 무의식적으로 화면을 바라보게 됩니다.
"화면은 필요할 때만 보이고, 기본적으로는 존재감을 줄여야 하지 않을까?"
집중력 체크가 시작되면 3초 뒤 화면 밝기가 낮아지도록 설계했습니다. 사용자가 화면을 다시 터치하면 밝아지고, 다시 3초 후 어두워지는 자동 밝기 전환 모드를 구현했습니다.
하지만 여기서 또 하나의 고민이 생겼습니다. "누군가는 화면을 계속 보고 싶어할 수도 있지 않을까?"
그래서 자동 전환 모드와 계속 보기 모드를 토글로 선택할 수 있도록 설계했습니다. 기본값은 자동 전환이지만, 사용자가 원하면 제어할 수 있도록 한 것 입니다.
+ 화면 전체를 다 어둡게 했으면 더 좋을 것 같네요. 물론 학습시간을 체크하고 싶다는 이유로 남겨두었던 것 같은데, 타이머의 숫자 변화나 집중력 수치의 변화가 생각보다 신경쓰일 것 같다는 생각이 드네요.
2. 거치 이후의 조작은 불편하지 않을까?
포비는 특성상 휴대폰을 거치해야 했습니다. 사용자는 카메라 각도를 맞추고, 자세를 정돈하고, 집중할 준비를 해야합니다. 그런데 그 상태에서 다시 휴대폰을 만져서 '측정 시작' 버튼을 눌러야 한다면 어떨까요? 기기가 움직이거나 넘어질 수도 있고, 다시 자세를 잡아야 할 수도 있고, 막 집중하려던 마인드셋이 깨질 수도 있습니다.
"측정을 시작하기 위해 굳이 터치를 해야 할까?"
그래서 제스처 기반으로 측정을 시작할 수 있도록 구현했습니다. 휴대폰을 다시 조작하지 않아도, 자연스러운 동작만으로 시작되도록 설계했습니다. 다만, 제스처 인식이 항상 완벽할 수는 없기에 예외 상황도 함께 고려했습니다. 인식이 실패하거나 사용자가 제스처 방식을 선호하지 않을 경우를 대비해, 기존의 '측정 시작' 버튼 역시 그대로 유지했습니다.
포비 역시 갤러리 워크와 외부 사용자 테스트를 통해 피드백을 받았습니다. 가장 인상 깊었던 것은, 제가 의도를 설명하지 않았음에도 불구하고 사용자들이 먼저 그 의도를 정확히 짚어냈을 때였습니다.
"만약 화면이 밝았으면 집중력이 깨졌을 것 같아요. 자동 밝기 기능은 좋은 기능인 것 같아요.",
"주먹만 쥐면 자동으로 측정 시작하는 거 너무 재밌었어요. 그리고 핸드폰을 다시 안만져도 된다는게 정말 좋은 것 같아요."
제가 고민했던 UX의 의도가 사용자에게 설명 없이 전달되었다는 것. 내가 고민했던 지점이 실제 사용자 경험 개선으로 이어졌다는 경험은 UX를 더 깊게 공부하고 싶다는 동기로 이어졌습니다.
세 번째 경험 - 내부 QA와 UT 경험
탭탭 프로젝트를 진행하면서 저는 처음으로 내부 QA 프로세스를 경험하게 되었습니다. 탭탭 팀은 디자인이 수정되거나 기능이 변경될 때마다 내부 QA를 꾸준히 진행했습니다. 단순히 "동작 확인"이 아니라, 실제 사용자 흐름을 따라가며 사용자 관점으로 점검하는 방식이었습니다.
직접 QA를 진행하면서 몇 가지 느낀게 있습니다.
1. 개발할 때는 보이지 않던 것들이 보이기 시작한다.
개발 단계에서는 자연스럽게 기능의 정상 동작 여부에 집중하게 됩니다. 상태값은 제대로 변경되는지, 예외 처리는 빠짐없이 되는지, 데이터베이스에 잘 저장 되는지 등.
하지만 QA 단계에서 '사용자 흐름'으로 다시 따라가보니 다른 것들이 보이기 시작했습니다.
- 버튼의 위치가 미묘하게 어색한 부분
- 굳이 한 번 더 눌러야 하는 불필요한 뎁스
- 입력 시 키보드가 텍스트 필드를 가려, 내용을 확인하기 위해 화면을 다시 조정해야 하는 불편함
기능적으로는 아무 문제가 없었지만, 경험적으로는 어색한 지점들이 분명히 존재했습니다.
2. 사소한 차이가 '불편함'이 된다.
한 번 더 눌러야 하는 버튼, 애매한 안내 문구 등 개발자 입장에서는 크게 문제되지 않는 요소들입니다. 하지만 사용자 입장에서는 그 작은 차이가 곧 '불편함'이 됩니다.
직접 사용자 관점으로 써보니, 그 미묘한 차이가 체감되었습니다. 그동안은 기능 구현이 완료되면 끝이라고 생각했지만, QA를 통해 앱의 완성은 기능 구현으로 끝나는 것이 아니라, 다시 바라보고 다듬는 것이라는 것을 배웠습니다.
3. 사용자는 생각보다 냉정하다.
아카데미에서 여러 UT를 진행하면서 크게 느낀 점이 있습니다.
사용자는 생각보다 냉정하다는 것이었습니다.
기능 하나를 만들기 위해 꽤 많은 시간을 들였습니다. 디테일을 다듬고, 흐름을 고민하고, 사용자의 편의를 고민하고, 나름대로 최선을 다했다고 생각했습니다.
하지만 사용자에게 그것은 하나의 화면일 뿐이었습니다. 길면 넘겼고, 복잡하면 멈췄고, 조금이라도 막히면 다른 걸 눌렀습니다. 우리가 중요하다고 생각했던 포인트나 기획 의도는, 사용자에게는 특별한 의미가 아니었습니다. 그저 빠르게 소비되는 인터페이스 중 하나였습니다.
UT를 진행하면서 특히 인상 깊었던 점은, "사용자는 우리가 설계한 '맥락' 안에서 움직이지 않는다"는 것이었습니다. 우리는 기능 A를 이해하면 자연스럽게 기능 B로 이어질 것이라고 생각합니다. 하지만 실제 사용자는 그렇지 않았습니다.
눈에 먼저 띄는 것을 눌러보고, 직관적으로 이해되지 않으면 넘아가고, 한 번 막히면 그대로 멈췄습니다. 우리가 의도한 사용자 흐름은 존재하지만, 사용자는 그 흐름을 따라와 줄 의무가 없었습니다.
그리고, UT는 사실 비교적 친절한 환경입니다. "한 번 써보세요"라는 요청을 받고 시간을 내서 참여해주는 자리니까요. 조금 막혀도 한 번 더 시도해보고, 이상한 점이 있으면 "이건 이런 건가요?"라고 물어봐 줍니다. 그럼에도 불구하고 흐름은 쉽게 끊겼습니다. 그렇다면 UT가 아닌 실제 환경에서는 어떨까요? 아마 더 빠르게 판단하고, 더 빠르게 이탈하고, 더 빠르게 다른 앱으로 이동할 것입니다.
네 번째 경험 - 실제 사용자 피드백
아카데미 쇼케이스에서 정말 많은 외부 사용자 분들이 탭탭을 직접 사용해주셨습니다. 그 자리는 내부 인원도, 멘토도, 팀원도 아닌 저희 서비스를 처음 접하는 완전한 외부 사용자들이었습니다.
그 자리에서 바로 피드백을 받을 수 있었는데, 그 경험은 이전의 어떤 QA나 UT보다도 더 직관적이고 날것에 가까웠습니다.
내부 테스트에서는 어느 정도 맥락을 알고 있었습니다. UT 환경에서는 참여자도 "테스트"라는 걸 인지하고 있습니다. 하지만 쇼케이스의 사용자들은 다릅니다. 설명은 최소한으로 듣고, 관심이 생기면 써보고, 아니면 바로 넘어갑니다. 그 반응은 정말정말 솔직했습니다.
"이건 뭐하는 앱이에요?", "지금 뭘 눌러야 하죠?", "생각보다 어려운데요", "그래서 이제 뭘 해야하죠?"
기능은 동작하고 있었지만, '한눈에 이해되는가?'라는 질문 앞에서는 부족한 부분이 분명히 보였습니다.
앱스토어 출시 이후 받은 피드백도 크게 다르지 않았습니다.
1. "온보딩 스킵하게 해주세요."
온보딩은 탭탭 팀이 기획 단계에서 가장 많이 고민했던 지점이었습니다.
탭탭은 사파리 익스텐션 기반 서비스입니다. 사파리 익스텐션이 제대로 활성화되지 않으면 앱의 핵심 기능이 정상적으로 동작하지 않습니다. 그래서 저희는 "기능을 제대로 쓰려면, 사파리 익스텐션을 제대로 알아야한다.", "설정을 안 하면 결국 못 쓸 텐데, 미리 아주 친절하게 알려주자."
그 결과, 온보딩에 정말 많은 공을 들였습니다.
- 사파리 익스텐션을 활성화하는 방법
- 설정에서 권한을 허용하는 방법
- 실제 사용 가이딩과 예시 화면
사용자가 중간에 놓치지 않도록, 모든 단계를 스킵 없이 완료해야만 앱을 사용할 수 있도록 설계했습니다.
기획 단계에서는 이것이 사용자에 대한 배려라고 믿었습니다. 사용자가 실패하지 않도록 완벽하게 가이딩하는 것이 좋은 UX라고 생각했습니다. 하지만 실제 유저들의 반응은 전혀 다른 반응이었습니다.
"온보딩 스킵하게 해주세요."
저희는 기능을 '잘 쓰게'하려고 했습니다. 하지만 사용자는 먼저 '가볍게 써보고'싶어 했습니다. 이 차이는 생각보다 훨씬 컸습니다. 탭탭은 사용자가 실패하지 않도록 설계된 구조였습니다.
- 스킵 불가
- 모든 단계 완료 필수
- 긴 설명, 상세한 가이드
문제는 이것이 우리의 의도와 달리 '친절함'이 아니라, 사용자에게는 '의무'처럼 느꼈다는 점입니다. 생각해보면 당연한 일입니다. 사용자는 탭탭 서비스에 대한 애착도, 신뢰도 없습니다. 그런 상태에서 긴 설명과 필수 절차를 요구받는다면, 그건 배려가 아니라 진입 장벽이 됩니다.
이 피드백은 정말 많은 것을 느끼게 된 피드백이었던 것 같습니다. 사용자는 실패하지 않게 해주는 것보다 지금 당장 써볼 수 있는 것을 더 중요하게 생각할 수도 있다는 것. UX는 사용자를 통제하는 설계가 아니라, 선택권을 남겨두는 설계라는 것을 느끼게 되었습니다.
2. "앱을 처음 켜면 뭘 해야 하는거죠?"
탭탭은 사파리 익스텐션을 통해 웹에서 문장을 스크랩하고, 그 데이터를 앱으로 공유받아 사용하는 구조입니다. 사용자는 사파리에서 문장을 선택해 저장하고, 앱에서는 그 스크랩 데이터를 다시 살펴보거나 수정하고 정리하는 경험을 하게 됩니다.
문제는, 막상 사용자가 앱을 처음 실행하면, 초기에는 아무런 데이터가 없는 '빈 화면'만 보이도록 되어 있었습니다. 기능적으로는 문제가 없었습니다. 하지만 사용자 입장에서는 전혀 달랐습니다.
"앱을 처음 켜면 뭘 해야 하는 거죠?", "지금 이 화면에서 제가 할 수 있는 게 뭐죠?"
사실 저희도 이 부분을 전혀 고려하지 않은 것은 아니였습니다. "이 앱을 다운받는 사람이라면, 사파리 익스텐션 기반 스크랩 앱이라는 걸 알고 의도에 맞게 잘 사용하지 않을까?", "어떻게 사용하는지 이미 이해하고 설치한 거 아닐까?"
탭탭 팀은 사용자가 우리와 같은 맥락을 공유하고 있을 거라고 가정했습니다. 사용자는 앱을 실행한 순간, 지금 당장 무엇을 해야 하는지를 알고 싶어 했습니다. 기능 구조를 이해하는 것은 그 다음 문제였습니다.
3. "문장 단위 선택은 좋은데... 내가 원하는 대로는 안 되네요."
탭탭의 기획 의도는 명확했습니다. "한 손으로 원하는 부분을 편하게 스크랩하자."
더블 탭 제스처, 즉 '탭탭'이라는 제스처는 저희 서비스의 아이덴티티였습니다. 이름에도 담겨 있고, 핵심 경험이기도 했습니다. 그래서 사파리 화면에서 문장을 더블 탭하면 자동으로 '문장 단위'로 선택되도록 설계했습니다.
이 기능은 꽤 많은 고민과 구현 공수가 들어간 부분이었습니다. 사용자가 정확한 문장 단위로 깔끔하게 스크랩할 수 있도록 하기 위함이었습니다. 저희 탭탭 팀은 이것이 명확하고, 세련된 경험이라고 생각했습니다.
실제로 이 기능에 대해서는 긍정적인 피드백도 있었습니다. "문장 단위로 자동 선택되는 건 좋네요" 하지만 그 다음 피드백이 더 중요했습니다. "근데 제가 원하는 부분만 선택해서 저장할 수는 없나요?"
저희는 '정확한 문장 단위 선택'이 더 좋은 경험이라고 생각했습니다. 하지만 사용자는 '자유롭게 선택할 수 있는 경험'을 더 중요하게 여기는 것이었습니다. 저희의 설계는 사용자를 돕기 위한 것이었습니다. 하지만 동시에 선택의 폭을 제한하고 있었습니다.
- 문장 전체가 아닌 일부만 저장하고 싶은 경우
- 두 문장을 이어서 저장하고 싶은 경우
- 특정 단어만 따로 남기고 싶은 경우
저희는 사용자를 돕는다고 생각했지만, 어쩌면 사용자의 선택권을 줄이고 있었던 건 아닐까 하는 고민이 들었습니다. 서비스의 아이덴티티를 지키는 것도 중요하지만, 그 아이덴티티가 사용자의 자유를 제한하는 순간 UX의 설계는 잘못된 것이라는 걸 배웠습니다.
4. "맥이나 아이패드에서도 연동되면 좋겠어요."
쇼케이스와 앱스토어 피드백에서 반복적으로 나왔던 다른 이야기 중 하나는 맥과 아이패드 연동에 관한 이야기였습니다. 처음 이 피드백을 들었을 때는 약간 의외였습니다. 저희는 모바일 기반 사용 경험에 집중하고 있었고, 사파리 익스텐션을 통한 '빠른 스크랩'을 초점을 맞추고 있었기 때문입니다.
하지만 사용자는 다르게 생각하고 있었습니다. 사용자는 특정 디바이스 안에서 기능을 보는 것이 아니라, 자신의 '작업 흐름' 안에서 서비스를 바라보고 있었습니다. 아이폰으로 스크랩하고, 아이패드에서 정리하고, 맥에서 다시 꺼내보는 흐름. 사용자가 생각하는 또 다른 중요한 것은 일관된 경험의 연결성이었습니다.
저희는 "한 손으로 빠르게 스크랩한다"는 문제를 해결하려고 했지만, 사용자는 그 이후의 흐름까지 자연스럽게 이어지기를 기대하고 있었습니다. 그래서 연동에 대한 요구는 단순한 플랫폼 확장이 아니라, 경험의 확장에 대한 요청이었습니다. 이 경험을 통해 배운 점은 명확했습니다. 우리는 하나의 기능을 만들고 있었지만, 사용자는 하나의 흐름을 기대하고 있었다는 것입니다.
+ 실제로 탭탭 팀은 이 피드백을 계기로 내부적으로 방향을 다시 검토했습니다. 기존 기획과 타겟을 재정의했고, macOS로의 확장과 아이클라우드 기반 동기화를 포함한 일관된 UX 설계를 준비하고 있습니다.
기능은 잘 동작하는데, 왜 사용자는 떠나는가
돌이켜보면 탭탭도, YAP도, 포비도 기능은 정상적으로 동작했습니다. 버그가 있었던 것도 아니고, 아예 못 쓰는 앱도 아니었습니다. 그런데 사용자는 쉽게 멈췄고, 쉽게 떠났습니다. 생각해보면 그 이유는 단순했습니다
1. 무엇을 해야 할지 명확하지 않았고
2. 이해하기까지 에너지가 들었고
3. 자유롭게 쓸 수 없었고
4. 흐름이 끊겼기 때문입니다.
사용자는 조금이라도 귀찮으면 넘기고, 조금이라도 복잡하면 멈추고, 조금이라도 이해가 안 되면 떠납니다.
즉, 사용자는 우리의 노력을 봐주지 않습니다. 오직 경험만을 판단합니다.
개발자가 UX를 이해하면 달라지는 점
UX를 고민하기 시작하고, 실제 사용자 피드백을 받아보면서 몇 가지 분명한 변화가 있었습니다
1. 타 도메인 직군과의 협업이 훨씬 수월해졌다.
이전에는 디자인과 기획을 "구현해야 할 결과물"로 바라봤습니다. 주어진 시안을 정확히 구현하는 것이 개발자의 역할이라고 생각했습니다. 하지만 UX를 고민하기 시작하면서, 디자인과 기획의 의도를 이해하려고 질문하기 시작했습니다.
- 왜 이 버튼은 이 위치에 있어야 할까?
- 왜 이 단계는 반드시 필요할까? 뎁스를 더 줄일 수는 없을까?
- 이 문구는 어떤 맥락에서 작성되었을까?
이러한 질문들이 쌓이면서, 기획 단계에서부터 의견을 나눌 수 있게 되었고, 디자이너와도 화면이 아니라 경험에 대해 이야기할 수 있게 되었습니다. 개발자가 UX를 고민한다는 건 디자이너나 기획자의 영역을 침범하는 게 아니라, 사용자 경험에 대한 책임을 함께 지는 태도라고 생각합니다.
2. 기능을 추가하는 대신, 덜어내는 고민을 하게 되었다.
이전에는 기획이나 수정하는 과정에서 새로운 기능을 추가하는 것이 곧 발전이라고 생각했습니다. 하지만 UX를 고민하기 시작하면서 생각이 달라졌습니다. 서비스는 기능이 많아질수록 좋아지는 것이 아니라, 핵심 경험이 더 또렷해질수록 좋아진다는 걸 배웠기 때문입니다.
마무리
물론 개발자는 구현을 잘해야 합니다. 좋은 코드를 작성하기 위해 고민해야 하고, 유지보수를 고려해 구조를 설계해야 하고, 성능과 안정성도 책임져야 합니다. 그건 기본이라고 생각합니다.
하지만 저는 이렇게 생각합니다. 실력 있는 개발자는 구현을 잘하는 개발자이고, 좋은 개발자는 기획 단계에서부터 사용자 경험을 고민하는 개발자라고 생각합니다.
그래서 저는 '실력있는' '좋은' 개발자가 되고 싶습니다. 그래서 UX를 공부하고 있습니다. 단순히 디자인을 이해하기 위해서가 아니라 더 좋은 서비스를 만들기 위해서입니다.