Engineering
맨땅에 UX 헤딩하기
여기어때 UX Center여기어때
2023년 8월 11일
원문에서 보기 ↗글. 이재선(Woojoo) / UX Designer
여기어때는 21년부터 22년까지 많은 서비스를 오픈했었는데요. MVP로 빠르게 여러 서비스를 오픈하다 보니 보완해야 할 부분들이 꽤 있었어요. 오픈 후 일반 사용자 분들이 사용하는 서비스를 개선하는 작업도 필요했지만, 앞과 뒤가 잘 호환이 되어야 내부 운영 효율을 극대화시킬 수 있기 때문에 파트너분들을 위한 개선도 꼭 필요했습니다.
여기어때 파트너분들이 사용하는 어드민은 기존엔 2개 이상이었어요. 그래서 관리 측면에서도 어려움이 있었죠. 현실적으로 한 번에 많은 걸 개선할 순 없었지만 운영 툴을 하나라도 줄여야 장기적으로는 업무 리소스를 줄이는데도 효과적이라 판단했어요. 그렇게 시작된 프로젝트가 여기어때 통합 파트너센터입니다.
통합이라고 시작했기 때문에 UX적으로 호텔, 모텔, 펜션 등 도메인마다의 차이를 구분해야 했어요. 같은 도메인이어도 파트너분들 개개인마다의 사용성에도 차이가 있었기 때문에 이 모든 걸 공통의 고리로 잡아야 해서 개선 범위가 상당히 컸죠. 또, 테크에서도 각 도메인마다의 뒷단이 나누어져 관리가 되었기 때문에 한데 모으는 작업양도 방대했습니다**.**
그래서 이번 글을 통해 파트너센터 UX 개선을 진행하면서 알게 된 반응형과 적응형 디자인의 장단점 그리고 이를 적용한 디자인 시스템에 대해 이야기해보려고 해요.
반응형과 적응형 기초 쌓기
먼저 반응형과 적응형의 차이에 대해 알아볼게요. 반응형은 하나의 템플릿으로 요소들의 크기나 화면 구성이 자연스럽게 변화하면서 어떤 화면과 기기에서든 일관된 경험을 제공해요.
반면, 적응형은 반응형과 달리 디바이스 별로 구분되어 각각의 독립적인 템플릿을 만들어 제공한다고 볼 수 있어요. 그로 인해 반응형의 장단점과 적응형의 장단점은 극명한 차이를 가지고 있어요.
반응형 장단점
반응형 디자인
반응형의 장점은 어떤 디바이스로든 접근이 가능해서 접근성이 좋다는 점이에요. 초반 작업 시 명확한 규칙으로 그리드 시스템과 브레이크 포인트를 잘 잡고 진행한다면 추후 화면이 추가될 때마다 웹과 모바일 버전을 별도로 만들지 않아도 된다는 장점이 있어요 따라서 유지 보수에 대한 리소스가 줄어드는 거죠.
반면, 웹과 모바일에서 일관된 경험을 제공해야 하기 때문에 브라우저의 크기를 조절할 때마다 자연스럽게 레이아웃이 변경되는 부분까지 감안하고 디자인을 해야 하는 단점이 있죠. 또 초기에 잡아둔 그리드 시스템과 브레이크 포인트의 규칙이 있기 때문에 그 부분을 계속 염두에 두고 작업해야 합니다. 그래서 오히려 초기 리소스가 상당히 많이 들어가게 돼요. 또, 개발적으로는 한 번에 모든 콘텐츠를 불러와야 하기 때문에 로딩이 조금 더 걸릴 수 있어요.
적응형 장단점
적응형 디자인
이에 반해 적응형의 장점으로는 각 디바이스에 맞춰 최적화된 화면을 제공하기 때문에 사용성이 좀 더 매끄럽다고 느낄 수 있어요. 덕분에 디자인의 자율성도 조금 더 올라가고요. 개발적으로는 필요한 콘텐츠만 불러와도 되기 때문에 로딩은 반응형에 비해 좀 더 빠르죠.
하지만 몇 가지 뷰포트(viewport)를 정해두고 그 화면에만 대응을 하다 보니 좀 더 다양한 기기에서 서비스를 제공받을 수 없다는 제한이 있어요. 또, 정해진 뷰포트에 따라 최적화된 디자인 화면을 모두 필요로 하기 때문에 초기뿐만 아니라 추후 화면이 추가될 경우에도 많은 리소스가 투입돼요.
이처럼 반응형과 적응형은 너무나 명확하게 다른 특징을 가지고 있기 때문에 반응형은 다양한 디바이스에서 접속해야 할 일이 많거나 일반 커머스나 회사 소개, 사업 소개와 같이 균일화된 레이아웃을 제공할 수 있는 사이트에 적합한 것 같아요.
반면, 적응형은 다양한 디바이스에서의 활용보다는 많은 콘텐츠를 제공해야 하거나 어드민과 같이 복잡도가 높은 사이트에 적합할 수 있을 것 같아요. 물론 제가 생각한 웹 디자인의 사용 정의가 꼭 정답은 아니기 때문에 참고로만 생각해 주시면 좋을 것 같아요.
확장성과 효율성을 위한 선택, 반응형
그렇다면, 이번 파트너센터 개선 작업에선 어떤 방식으로 구현하게 됐을까요?
결론만 빠르게 말씀드리면, 반응형으로 작업하게 되었어요. 처음엔 ‘어쩌면 복잡도도 높고 초점에 따라 많은 콘텐츠를 제공해야 하니 적응형이 맞지 않을까?’라고 생각했었어요. 하지만 파트너센터 특성상 여러 숙소 카테고리의 파트너분들이 사용하셔야 하고, 파트너분들마다 활용도 또한 다양했기 때문에 여러 가지 확장성을 고려함과 동시에 추후 운영 리소스를 줄이고자 하는 방향도 함께 고려되어 반응형으로 작업하게 되었습니다.
반응형과 디자인 시스템의 만남
사실 반응형으로 작업하는 것까진 큰 어려움은 없었어요. 하지만 이 반응형에 디자인 시스템을 더하게 되었습니다. 사실 두 가지 작업을 함께 병행하는 경우는 흔하진 않는데요. 그래서 개인적으로 난이도가 높았지만, 돌아보면 그 과정에서 얻은 게 많았던 프로젝트였던 것 같아요.
여기어때에는 YDS(디자인 시스템)이 있습니다. 여기어때 디자인 시스템의 약자인데요. 이 시스템은 웹이 아닌 앱을 기반으로 구축한 시스템이라 웹에서 그대로 사용하기 어려웠어요. 대신 우리에겐 YDS라는 뿌리가 있으니 그 뿌리로부터 틀을 갖춰나가면 되겠다 생각했어요.
폰트나 컬러, 컴포넌트들의 형태는 YDS의 기조를 따라가되 웹에 최적화된 컴포넌트로 변형시킬 계획이었죠. 처음엔 반응형이어도 어느 정도 뷰포트 크기에 따라 버튼의 크기도 조절해서 시스템에 적용하고자 욕심을 냈었어요.
하지만 한 번에 많은 콘텐츠를 불러오는 반응형에 뷰포트에 따라 버튼 크기를 달리하는 건 디자이너에게도 개발자에게도 상당한 부담이 있었죠. 관리의 범위도 커질뿐더러 화면의 버벅거림이 심할 경우 사용자에게도 원활한 경험을 주지 못할 수 있으니까요. 그래서 결국 모든 디바이스의 컴포넌트 크기를 하나로 맞추게 되었어요.
일관된 규칙 만들기
반응형에 디자인 시스템을 덧붙여 적용하게 되면 기존 반응형에 비해 생각보다 고려해야 할 부분들이 많았습니다. 데스크톱과 태블릿, 모바일 화면마다의 케이스는 모두 고려해야 함은 물론이고요.
예시를 들어보자면 디자이너는 팝업과 다이얼로그는 각기 다른 컴포넌트인데, 개발자는 팝업도 다이얼로그도 사실 다를 게 없는 똑같은 모달인 거죠. 또, 디자이너는 테이블은 병합 형태의 가로형과 세로형이 있고, 단순 리스트는 별도의 컴포넌트라고 생각하지만 개발자는 리스트 또한 또 다른 형태의 테이블인 거예요.
이렇게 각기 이해도가 다른 상황에서 일관된 규칙을 만드는 것이 가장 중요했습니다.
규칙에 맞게 반응하는 시스템이 되어야 했고, 이 시스템은 앞으로 디자이너와 개발자가 함께 사용하는 것이니까요.
이처럼 단기간에 시스템 디자이너와 함께 디자인 시스템 1.0 한 벌을 빠르게 만들어 개발에 전달해야 했던 상황이었어요. 동시에 통합 파트너센터 UX 개선은 계속 진행 중이었기 때문에 PO와의 싱크도, 각 페이지별 담당 디자이너들과 화면별 규칙을 맞춰가는 과정도 진행되어야 해서 마냥 쉽지만은 않았어요.
한 사이트를 여러 명이 작업하더라도 단 한 명이 작업한 듯 결을 맞춰가는 것은 당연한 일이지만, 시스템을 적용하기로 한 이상 이 공통의 규칙은 그 어느 때보다 우선순위가 높아졌던 거죠. 결국 시스템은 혼자 하는 것이 아니기 때문에 어쩌면 사소하다고 느껴질 수 있는 버튼과 버튼 사이 간격이라거나, 콘텐츠와 콘텐츠 사이 간격까지 함께 논의를 거쳐 정하게 되었어요. 페이지마다 특성이 다르기 때문에 다른 기능을 가진 버튼을 무조건 같은 위치에 제공한다는 규칙을 가져가게 되면 사용자 관점에서 불편할 수 있기 때문이죠.
이런 규칙은 UX Writing도 동일했어요. 예로 팝업을 닫는 경우 ‘닫기’와 ‘취소’를 혼용해서 쓰고 있다는 걸 작업 중에 발견할 수 있었죠. 이런 부분들은 페이지별 담당 디자이너와 시스템 디자이너 그리고 UX 라이터까지 함께 데일리 싱크 미팅을 통해 맞추어 나갔습니다.
당연해서 놓치기 쉬운 것
어쩌면 ‘너무나 당연히 맞춰야 하는 부분 아닌가?’라고 생각하실 수 있어요. 사실 맞습니다. 하지만 이 프로젝트를 시작하게 되면서 회사 내부적으로도 처음 시도하는 부분들이 많아 의사 결정의 범위도 넓고 앞에서 정리해야 되는 부분들도 많다 보니 초기 단계에 쓰인 시간이 많았어요.
게다가 빡빡한 작업 일정 속에서 각자 빠르게 진도를 내야 했기 때문에 처음부터 세부적인 규칙을 먼저 잡고 갈 수 없었어요. 그래서 프로젝트 중간 이후부터는 담당 디자이너들 간의 싱크를 더 잦게 가져갔던 것 같아요. 돌아보면 꼭 필요한 과정이었고 그 시기는 좀 더 빠르게 되었다면 좋았겠지만 그 당시 상황에서는 최선의 선택이었다고 생각합니다.
앞서 말씀드린 내용들 외에도 수많은 과정들이 있었고 그 속에 우여곡절이 참 많았어요.
그렇지만 반응형과 디자인 시스템, 서비스 통합의 과정을 함께 진행하면서 저 스스로에게 큰 성장을 가져다주었죠. 스킬에 있어서도, 업무를 진행하는 과정에 있어서도요! 또 여러 가지 프로젝트를 동시에 진행하게 되면 각 영역들을 넓게 바라볼 줄 아는 시야를 가지는 게 매우 중요하단 깨달음까지도 얻을 수 있었습니다.
돌아보면 이게 제일 중요하더라고요
첫 번째, 가장 중요한 디자이너들과의 내부 싱크
워낙 큰 프로젝트고 처음 시도하는 부분들이 많았기 때문에 4명의 UX 디자이너, 1명의 시스템 디자이너 그리고 UX 라이터까지 투입되어 각개전투를 하고 있었어요. 디자인 시스템이 있어 어느 정도 스타일은 맞춰졌어도 상세한 규칙은 서로 상이하게 사용하는 경우가 생각보다 꽤 발생했고 이 간극을 좁히기 위해선 지속적인 싱크만이 답이었죠. UX 싱크 미팅은 매일 진행되었고, 시스템 디자인 싱크 또한 별도로 주 4회씩 진행하며 일관성에 대한 디테일을 놓치지 않으려고 했어요.
두 번째, 내부 디자이너들과의 싱크 못지않게 중요한 개발팀과의 싱크
정말 너무나 많이 중요합니다. ‘이런 거까지 물어보는 게 맞나’라는 생각이 들어도, 가끔은 자괴감이 든다 싶을 정도로 디테일하게 많이 물어봐야 해요.
위에 말씀드린 사례처럼 용어 하나에도 사람마다 각자 이해의 범위가 다르기도 하고 생각보다 많은 차이가 있을 수 있기 때문에 그 간극을 줄이는 게 가장 중요하고 그 간극을 줄이려면 결국엔 많은 대화가 핵심인 것 같아요.
세 번째, 디자인 시스템에 대한 이해도 쌓기
작업자마다 시스템에 대한 이해도가 모두가 상이했기 때문에 이 부분을 맞추는 것도 중요했어요. 정말 중요한 부분이 한 둘이 아니죠? 디자인 시스템에 대해 생각하는 범위가 모두 달랐기 때문이에요.
누군가는 ‘완전한’ 시스템 그 자체로 생각하기도 하고, 누군가는 ‘적당히’ 적절하게 맞춰지는 시스템 정도로 생각하는 거죠. 이 부분에선 디자이너들끼리도 서로가 생각하는 시스템의 범위가 달랐고, 디자이너와 개발자 사이에서도 물론 달랐습니다.
단순히 규칙만 정해서 해결되는 문제는 아니었어요. 서로의 이해도가 같은 선상에 위치되어야 규칙이 주어져도 각자 상황에 맞게 잘 활용할 수 있으니까요. 또, 협업하는 PO와 UX 라이터에게도 디자인 시스템에 대한 이해도를 높이고 중요도를 느낄 수 있도록 노력했어요.
저를 포함한 프로젝트 구성원들 모두 다양한 아이디어를 발산해 내도 시스템 안에 녹아드는 게 가능한 범위여야 했고 한 화면에서만 사용되는 UX여도 추후에 다른 화면에서 사용됐을 때 생겨날 다른 문제는 없을지, 다양한 상황을 고려해야 했기 때문에 이해도를 맞춰야 함은 너무 자연스러운 일이었던 것 같아요. 그래야 일의 진척이 생기기도 하지만, 미래의 내가 과거의 나를 원망하는 일도 만들지 않을 수 있겠죠?
결국 프로젝트 팀원들 모두가 사용자에게 수월하고 일관된 경험을 제공하기 위해 힘쓰는 공동체 운명이기에, 업무의 롤이 달라도 이해도를 높여 함께하는 건 그 프로덕트의 완성도를 높일 수 있는 방법 중 하나일 거란 생각이 들어요.
내가 아는 것을 이해도가 부족한 누군가에게 이해시키는 방법과 또 역으로 이해도가 부족한 내가 누군가가 아는 것을 이해하는 과정, 이 과정들이 꽤 지난하다고 느껴질 수 있어도 한 발 나아가는 과정이라 생각하면 즐거웠습니다.
UX엔 정말 정답이 없다
사실 서비스에 따라서 적응형이 좋을 수도 있고, 반응형이 더 좋을 수도 있어요.그래서 속한 회사와 서비스의 성격에 따라 알맞다고 생각하는 선택지를 고르는 게 가장 현명한 방법 아닐까 싶어요.
앞으로 저는 어떤 프로젝트를 하더라도 통합, 반응형, 디자인 시스템 이 3가지를 염두에 둔 프로젝트를 경험할 기회는 많지 않을 것 같아요.
통합을 위한 사업부, 운영, 각 부서별 리더와의 조율도 중요했고, 디자인 시스템과 반응형을 위해 개발과의 원활한 커뮤니케이션도 중요했고요. 프로젝트를 함께 진행하는 디자이너들끼리의 싱크업도, 협업하는 PO, UX 라이터와의 싱크업도 중요했죠. 어느하나 중요하지 않은 부분이 없었던, 모든 부분을 살피고 바라봐야 했던 프로젝트였습니다.
부족한 부분도 많아 스스로 한계를 느끼기도 하고 허덕거리던 때도 있었지만 이 프로젝트를 통해 프로젝트 팀원들과 더 잘 소통하는 방법, 개발자분들과 한 발짝 더 가까워지는 방법 그리고 이해관계자들을 잘 설득시키는 방법까지 가장 깊게 고민하고 생각할 수 있었던 기회였어요.
그리고 모든 일이 그렇듯이 ‘나’ 혼자 할 수 있는 일은 없는 것 같습니다. 이 자리를 빌려 모든 여정을 함께해 준 프로젝트 팀원분들에게 한 번 더 감사하다고 꼭 전하고 싶어요!
✔️ 글쓴이를 더 알고 싶다면? 링크드인
구성 및 편집: 이소연(Jetty) UX Writer
*해당 글과 이미지를 인용 또는 재가공 시 출처를 꼭 밝혀주세요.
관련 글