문제의 근원을 해결 하기 위한 다양한 시도

배경

토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트는 테이블이에요. 테이블은 크게 두 가지를 고려해야 하는 복잡한 컴포넌트예요. 테이블을 구성하는 최소 단위인 셀, 그 셀들을 합쳐 만든 표. 각각을 사용하는 경우의 수를 고려하면 구현 난이도는 무한대로 높아져요.

우리가 흔히 표를 만들 때 쓰는 엑셀은 말 그대로 표를 만들기 위해 만들어진 에디터 솔루션이기 때문에, 셀과 표를 처음부터 고려해서 만들어졌어요. 하지만 우리가 사용하는 대개의 디자인 에디터 툴들은 테이블 만을 위해 만들어진 솔루션이 아니기 때문에 컴포넌트 기능과, 테이블 제작 사용성 두가지 모두를 한번에 고려하여 반영 하는데에 한계가 있습니다. 그래서 토스의 초기 테이블은 (이하 테이블 1.0) 최소 구성 단위인 셀 형태의 컴포넌트로 구성되어 있었어요.

문제

테이블 컴포넌트는 표를 구성하는 작은 단위의 셀을 의미 하기도 하고. 큰 덩어리인 표 단위를 의미하기도 해요.

TDS의 테이블 컴포넌트 역시 이를 모두 커버하기 위해 셀 단위의 기능과, 표 단위의 제작 사용성 솔루션이 필요로 했어요. 토스 팀에서는 제품에서 사용하는 형태에 따라 테이블 컴포넌트가 가지고 있어야 할 기능과 요구 되는 사항들은 천차만별로 달라서 여기에 다 쓸 수 없을 정도로 다양한 케이스를 다뤄야 했죠. 저희 팀은 그런 셀의 경험을 개선하는 것만으로도 정신이 없었어요.

이렇게 셀의 기능이 대부분 채워갈 무렵, 자연스럽게 표 제작에 대한 사용성 관련한 문제들이 수면 위로 드러나기 시작 했어요. 테이블을 구성하는 최소 구성단위인 셀 기능만 포함 된 컴포넌트로 패턴 단위의 표를 만드려면 이런 과정을 거쳐야 했어요.

우리는 이미 표를 만들기 위해 사용하는 엑셀과 같은 툴에 익숙해져있으니, 보기만 해도 너무 불편하다는 걸 느끼실 거예요. 실제로 PC 화면을 디자인하는 분들도 많은 피드백을 주셨고요.

• 👤 테이블을 내가 왜 이렇게 만들어야 하나…
• 👤 하나하나 쌓아 만드는거 너무 짜친다… 현타 온다
• 👤 다 모르겠고 누가 만들어 놓은거 복붙 해서 쓰는게 편해요

가설

하지만 앞에서 말씀 드렸듯이, 디자인 툴은 테이블을 만들기 위해 제작 된 에디터가 아니기 때문에 문제를 해결 하는데에는 기술적인 한계가 존재 했어요. 그래서 처음에는 지금 메이커들이 겪고 있는 문제 중 치명적인 비효율을 만드는 요소들을 제거 하는 것 부터 시작하자! 하고 반복되는 문제 패턴을 찾았죠. 예를 들면 이런 것들이 있었어요.

1. 간단한 표를 구성하기 위해 필요한 툴과 관련된 사전 지식들
   1. fixed ↔ fill ↔ fit-content
2. 표를 만들고 난 후에도 필요에 따라 잦은 데이터 수정이 필요한 컴포넌트의 특수성
   1. 각 셀 마다 가지고 있는 패널 설정을 찾아 수정하는 과정이 번거로움
   2. 열, 행 구성에 따라 제작 된 표는 추후 수정이 어려움

위와 같은 문제들을 테이블 베타라는 이름의 솔루션으로 개선하고 난 후, 단순한 리스트형 테이블을 쉽게 만들 수 있게 되었지만 아무리 이전보다 나아졌다고 해도, 툴에 종속되어 해결 된 솔루션이라 매우 제한적인 해결방법으로 도출 되어 제작 사용성을 완전히 해결했다고 보기 어려웠어요. 여전히 테이블 만을 위해 제작 된 솔루션들의 경험과 비교하여 생각한다면 불편하다고 생각할 수 밖에 없었죠.

이제는 컴포넌트의 경험을 개선하는 것을 넘어서, 디자이너분들이 실제로 어떻게 사용하는지 과정 전체에 대한 이야기를 듣고, 본질적인 사용 방식을 개선해야 겠다는 생각이 들었어요. 그래서 작업 방향을 잡기 위해 디자이너분들을 찾아가 심층 인터뷰를 하면서 테이블을 사용하시는 행태를 꼼꼼하게 조사했어요.

이를 위해 가용 가능한 개발 리소스를 확보하고 설문+UT를 통해 3가지 방향성을 도출 했어요.

1. 제로 베이스의 제작을 하지 않아도 되게 만든다
2. 표 자체를 완성하는 환경을 쉽게 한다
3. 잦은 수정이 일어나는 상태를 쉽게 수정하게 한다

UT, POC를 통해 차츰 방향성을 잡아 가면서 메이커들과 이격을 줄이는 작업들이 병행 되었어요.

이렇게 정밀 진단을 통해 꼭 해결해야하는 큰 맥락을 설정해보니, 툴의 한계를 벗어나 빌더 수준의 완전히 새로운 형태의 제작이 필요하다는 판단을 하게 되었어요. 문제 해결의 한계를 만들고 있는 툴의 환경을 벗어나 사고 하고 해결책을 찾아야겠다 생각 했죠. 하지만 툴을 벗어나 해결책을 찾더라도 결국 툴 내부에 솔루션을 심어야 했기 때문에 완전히 환경을 벗어나긴 어려웠고 이에 우리는 크롬 플러그인을 활용하여 프레이머라는 툴 내에 붙여 활용 할 수 있는 방법을 찾아 활용해 보게 되었어요.

해결책

컴포넌트 단위의 솔루션이 아닌 에디터를 만드는 수준의 솔루션을 설계해야 하는 상황이었지만 완전히 바닥부터 시작하기엔 우리에게 주어진 시간이 많지 않았기 때문에 리소스를 효율적으로 쓰는 것이 가장 중요했어요.

메이커 리소스 및 물리적인 작업 환경 확보하기

한명의 개발자로 문의 대응과 테이블 혁신까지 이뤄내야 했기 때문에 응급 상황 제외 문의 최대한 손 떼고, UXE Assistant + Platform designer 조합으로 개발 구조체를 변경하지 않는 선의 간단한 대응을 모두 위임하는 등 한명의 개발자로 테이블 2.0을 만들어야 하는 상황에 필요한 물리적인 환경을 구축 하는데 신경 썼어요.

빠르게 도달 할 수 있는 방법 시도 하기

문제를 해결 하기 위해 방향성이 설정 되었다면 이제 달려나가야겠죠? 제로 베이스에서 시작하기에 리소스 및 시간이 턱 없이 부족 하다면 기반이 되어줄 타 제품을 찾아보고 무료 소스를 적극 차용하는 것도 좋은 방법이 될 수 있어요. 테이블만을 고민하고 솔루션을 구축해온 AG grid 라는 제품을 차용해 유료 기능을 제외한 무료 기능들을 가져와 뼈대를 만들고, 이후 필요한 기능들을 직접 개발 하면서 2.0의 모습을 갖춰나갔어요. 토스에서 필요한 기능들과 프레이머라는 환경을 고려해야 했기에 거의 새로 만드는 수준 이었지만 AG grid를 통한 뼈대를 구축하는 과정이 문제 해결 속도를 높이는데 큰 도움이 되었어요.

빠르게 검증하기

테이블 베타를 통해 성공적인 임팩트를 도모하지 못했던 것은 제작 과정에서의 검증을 놓쳤기 때문이라 생각했기 때문에 주어진 기간이 매우 짧아 검증할 시간이 충분하지 않더라도 실패를 줄이기 위해서는 무조건 진행하기로 했어요. 주 단위로 스프린트를 구성하여 스펙 구현 과 메이커 UT를 동시에 진행 하면서 제품을 실시간으로 깎아 나갔어요. 이 과정에는 한몸이 된 것처럼 밀도 있는 커뮤니케이션이 필수적이에요. 이 과정들을 통해 해결 해야하는 문제가 클 수록 투자 해야할 시간이 길어져 자칫 늘어질 수 있는 호흡을 잡아주는 역할도 할 수 있어요.

결과

그렇게 충분하지 않았던 리소스로 엄청난 효율을 추구하며 만들어낸 결과, 테이블 1.0과 비교했을 때 완전히 다른 방법으로 개선된 2.0이 나왔죠. 테이블2.0은 표 제작 및 생성 하는데 필요한 사용성을 개선 대부분 개선 할 수 있었어요. 특히 잦은 벨류 수정이 필요했던 케이스를 대응 할 수 있어 큰 반응이 있었어요.

첫 배포 이후에도 필요로한 추가 기능들을 지속적으로 배포 하면서 테이블을 제작하는데 필요로한 기능들을 대응 했어요.

PD분들의 반응도 열광적이었어요.

적용해보기

문제의 근원을 해결하기 위해 시도했던 다양한 시도들을 통해 우리는 아래와 같은 러닝을 얻게 되었어요.

1. Question every assumption : 근본적인 해결을 위해 다시 사고하는 과정이 느려보여도 가장 빠른 해결책이 될 수 있어요

   특히 시스템 관련해서 컴포넌트와 관련한 문제를 마주 하다보면 당장 산재한 문제들을 빠르게 해결하기 위해 정신 없이 1:1 대응 형태로 문제 해결을 하게 되는데요. 느리더라도 문제를 해결 하기 위해 근원적인 물음들을 제기 하면서 근본적인 문제를 해결을 위한 사고 과정에 시간을 투자 해보세요. 이 문제가 진짜 문제인지, 이 해결 방법으로 해결 할 수 있는 문제는 무엇인지 등 당연 했다고 생각한 것들에 질문하고 처음부터 다시 사고 하는 과정을 거치다 보면 근본의 가정까지 파고들어가 사고 할 수 있어요. 이렇게 느리지만 가장 빠른 해결책을 찾는 과정을 통해 여러 문제를 혁신적으로 해결 할 수 있을거에요. 한번의 시도에 완벽한 해결을 만들 수 없기 때문에 이 과정을 반복하는 것을 추천 드려요.

2. Ask for feedback : 성장하는 시스템은 주요 원동력은 피드백이다

   잘 만들어진 시스템은 잘 사용 되는 시스템이에요. 그렇기 때문에 메이커들의 솔직하고 주기적인 피드백이 중요해요. 시스템은 이를 사용하는 메이커들의 피드백을 통해 성장하고 고도화 되는 성장형 솔루션이어야 합니다. 때문에 우리는 시스템을 제작 하는 과정도 중요 하지만 의도 한대로 잘 작동 하고 있는지 지속적인 트래킹 하는 과정을 필수로 진행하고 있어요.

   사용자가 늘 적극적으로 피드백을 주지 않을 때에는 시스템이 의도대로 잘 작동하고 있구나 안심하지 말고 직접 찾아 다니면서 집착적으로 피드백 받고 문제를 발굴 하는 것도 중요해요. 시스템을 만드는 과정이 벅차서 이 부분을 놓치게 되면 언젠가 눈덩이처럼 커져버린 문제를 마주하게 될지도 몰라요.

3. Focus on Impact : 혁신적인 임팩트를 생산 하기 위한 집중과 물리적인 확보는 반드시 필요하다

   해야할 일은 사라지지 않고 문제는 늘 많은데 어떻게 혁신적인 임팩트를 생산 할 수 있을까요? 모든 문제를 해결 할 수 없다는 것을 인지하고 해결 하고자 하는 문제에 집중하여 몰입하는 과감한 투자가 필요해요. PC 시스템 팀에서는 PC TDS가 해결해야 하는 문제들 중 테이블과 관련한 문제가 가장 큰 이슈이자 풀기 어려운 숙제라고 판단했고, 2.0 이라는 솔루션을 만들어내기 위해서 매일 대응 하고 있는 시스템 운영 및 대응, 신규 컴포넌트 생산과 같은 업무를 줄여 리소스를 물리적으로 확보 하고자 했어요.

   완전히 끊어내고 몰입할수 있는 환경이라면 가장 좋겠지만, 시스템 팀은 토스 전 조직 대상으로 움직이는 팀이기 때문에 완전히 업무를 중단하기 어려웠어요. 하지만 테이블2.0을 만들어 내려면 리소스 확보가 꼭 필요했습니다 개발자가 1명 이었으니까요. 어려운 환경에 있더라도 방법은 어떤 형태로든 찾을 수 있습니다. 많은 일을 한꺼번에 처리하긴 어려워요. 집중 할 수 있는 환경과 기간을 설정하고 과감한 시도를 통해 문제를 해결 해보세요!

눈 앞의 문제들을 해결했음에도 여전히 불편함이 남아있다면, 본질적인 문제를 다룰 수 없을지 확인해보세요. 너무 당연했던 전제를 바꿀 수 있다고 상상해보면 완전히 다른 해결책이 떠오를 거예요.