🪄 TL;DR
- 레거시 화면을 리뉴얼하면서 테이블 구현 방식을 두고 디자이너와 개발 팀의 의견이 갈렸다.
- 디자이너는 사내 디자인 시스템 테이블을 사용하길 원했다. 이미 다른 화면에서 사용하며 사용성과 일관성이 검증된 컴포넌트였기 때문이다.
- 개발 팀은 라이선스를 보유한 AG Grid를 커스텀하여 사용하길 원했다. 셀 복사, 컬럼 너비 조절, 컬럼 고정 등 요구 기능이 AG Grid에는 기본으로 있었지만, 디자인 시스템 테이블에서는 전부 직접 구현해야 했기 때문이다.
- 디자이너의 우려가 시안 재현 가능성과 검증되지 않은 인터랙션의 QA 리스크라는 걸 파악했다.
- 말로 설득하는 대신 하루 만에 디자인 시스템 테이블과 똑같이 커스텀한 프로토타입을 만들어 직접 조작해보게 했고, 인터랙션까지 붙여 5일 만에 공통 그리드를 완성해 AG Grid 채택이 확정됐다.
AG Grid 커스텀 시리즈로 AG Grid 커스터마이징과 상태 오버레이 구현 관련 글을 작성했다. 그보다 더 이전에 있었던 디자이너 설득하기!가 꽤 중요한 과정이었다는 생각이 들어서, 해당 과정을 정리해보려고 한다.
배경
리뉴얼 작업을 진행하는 레포에는 기존에 사용하던 디자인 시스템 테이블 컴포넌트가 있었고, 새롭게 만드는 화면에도 그리드가 필요했기에 디자이너는 기존에 사용하던 컴포넌트를 사용하길 원했다. 하지만 기존 디자인 시스템 테이블은 단순한 형태의 조회 화면용으로 만들어져 있어서, 새롭게 만드는 화면에서 사용하기에는 제약이 있었다.
새롭게 만드는 화면은 AG Grid를 활용한 레거시 화면을 대체하는 화면이라, 레거시에서 사용하던 기능이 그대로 요구되었다. 요구사항이 정말 많았는데, 대표적인 것만 정리해보면 아래와 같았다.
이 기능들을 디자인 시스템 테이블에 추가하려면 하나하나 스크립트로 직접 구현해야 했다. 반면 AG Grid는 이미 기본으로 제공하는 기능이라 간단한 설정으로 붙일 수 있었다. 코드 작성 편의성과 유지보수 측면에서도 기능을 직접 구현하고 검증하는 것보다 이미 검증된 라이브러리를 활용하는 게 낫다는 생각이었다.
개발 팀은 라이선스 활용과 개발 편의성을 근거로 AG Grid 커스텀 사용을 제안했지만, 디자이너는 우려를 표했다. 기획과 QA는 특별한 반대 없이 디자이너 의견을 따르는 중립적인 입장이었다.
그러자 개발 팀 동료들이 디자이너 출신인 나에게 물어봤다. "AG Grid를 쓰면 기능도 안정적으로 구현되고 좋은데, 디자이너 입장에서는 왜 거절하는 거예요?"
디자이너 의견
AG Grid 사용을 반대하는 디자이너의 입장에서 생각해보았다.
디자이너가 원하는 건 이미 다른 페이지에서 사용되고 있고, 사용성이 검증되어 문제가 없는 컴포넌트를 그대로 쓰는 것이었다. 새로운 방식을 도입하면 사용성을 다시 검증해야 하고 QA도 새로 진행해야 한다. 특히 디자이너가 봐온 AG Grid는 레거시 화면의 커스텀되지 않은 구형 테이블뿐이었다. "이걸 디자인 시스템 테이블처럼 커스텀하겠다"는 말이 잘 상상되지 않았을 것이다.
정리하면 디자이너의 우려는 두 가지였다.
- 시안 재현 가능성: 커스텀한 AG Grid가 정말 디자인 시스템 테이블과 똑같이 보이는가
- QA 리스크: 검증되지 않은 인터랙션이 QA 단계에서 문제를 일으키지 않는가
개발자 의견
개발 팀은 이미 라이선스를 구매해 사용 중인 AG Grid를 쓰길 원했다. 레거시 AG Grid 테이블의 기능을 다시 스크립트로 일일이 구현하는 것보다 AG Grid가 제공하는 기능을 그대로 쓰는 게 낫다는 판단이었다.
사실은 개발자 사이에서도 의견이 갈렸다
디자이너 의견대로 기존 디자인 시스템 테이블을 쓰고, 기획에서 요구한 기능들은 스크립트로 직접 구현하자는 의견도 있었다. 요청받은 대로 맞춰주고 빠르게 진행하자는 입장이었다.
하지만 기존 코드에서 스크립트로 직접 구현된 부분들을 보면 유지보수가 매우 어려웠다. 요구사항이 추가될 때마다 스크립트가 덧붙여지면서 코드가 점점 복잡해졌고, 나중에는 수정하기도 조심스러운 상태가 되어 있었다. 이번 화면은 요구 기능이 훨씬 많았기 때문에, 같은 방식으로 가면 같은 문제가 더 크게 반복될 거라고 생각했다.
다른 포지션의 의견은 당연히 존중하고 고려해야 한다. 다만 그 방향이 "원래 그렇게 해왔으니까" 같은 관성 때문이고, 코드 품질이나 유지보수 측면에서 더 나은 방법이 분명히 있다면 의견을 내는 것도 개발자의 역할이라고 생각했다. 그래서 요구사항을 그대로 받아 구현하기보다, 검증된 기능을 쓰는 쪽으로 디자이너를 설득해보자고 제안했고, 결국 팀의 의견도 그쪽으로 모였다.
두 쪽이 다른 언어를 쓰고 있었다
양쪽 입장을 놓고 보니, 서로 다른 것을 이야기하고 있었다.
- 디자이너: 일관성, 검증된 사용성
- 개발자: 직접 구현 비용, 유지보수, 라이선스 활용, 이후 개발 편의성
개발 팀이 아무리 유지보수와 라이선스 이야기를 해도, 디자이너의 우려인 "똑같이 재현되는가"와 "QA에서 문제없는가"에 대한 답은 되지 않았다. 그래서 디자이너를 어떻게 설득할지 고민하다가, 우리도 직접 해보기 전까지는 100% 구현 가능한지 확인할 수 없으니 내가 먼저 프로토타입을 빠르게 만들어보겠다고 했다.
증명해보자!
디자이너가 우려하는 부분이 '시안 재현 가능성'과 'QA 부담'이라면, 그 부분을 빠르게 눈으로 확인시켜주자는 생각이었다. 텍스트로 기능 설명을 줄줄 늘어놓는 것보다 프로토타입으로 직접 보여주는 게 낫다고 봤다.
프로토타입으로 증명하기
구현 가능하다고 설명하는 대신, 하루 만에 디자인 시스템 테이블과 동일하게 스타일을 맞춘 프로토타입을 만들었다. 폰트, 호버, 구분선, 말줄임, 배경색, 패딩, 텍스트 간격과 크기, 컬러까지 전부 맞췄다. 이 커스터마이징 과정은 1편에 정리해두었다.
단순히 이미지만 보여주는 게 아니라 직접 사용 가능하게 테이블을 구성하여 조작까지 할 수 있도록 했다. 디자인 시스템 테이블에 구현된 동작을 모두 동일하게 적용하고, 레거시에서 쓰던 동작까지 붙여서 사용성에 문제가 없다는 걸 디자이너가 직접 만져보며 확인하게 했다.
반응은 긍정적이었다. "오, 이런 것도 되나요?" 하면서 세부 인터랙션에 대해서도 구현 가능한지 물어보았다. 처음에는 커스텀 가능 여부만 보여줄 계획이었는데, 이 질문을 보고 더 확실한 신뢰를 주려면 우려가 남은 인터랙션까지 전부 구현해서 보여주는 게 맞다고 판단했다.
그렇게 필요한 인터랙션까지 모두 붙여서 5일 만에 공통으로 사용 가능한 AG Grid 컴포넌트를 완성해 공유했고, 디자이너도 이견 없이 확정하면서 AG Grid 채택이 결정됐다.
함께 결정한 것들
설득만 한 건 아니었다. AG Grid의 기본 기능 중 레거시에는 있었지만 신규 디자인에 필요한지 아닌지 판단이 안 서는 것들은 따로 정리해서 기획자와 디자이너에게 의견을 물어보고 결정을 받았다. 행 순서 변경 기능, 컬럼 헤더를 드래그해 컬럼을 숨기는 기능 등 정의가 없었던 기능들은 함께 의견을 나누고 협의해가며 그리드 기능을 정의했다.
결과
개발 1주에 QA 2주를 거쳐, 총 3주 만에 실제 사용자 배포까지 나갔다. QA에서 디자이너가 우려했던 항목들은 모두 이슈 없이 통과했다.
이후 이 공통 그리드는 레거시 리뉴얼 화면 4개의 메인 그리드로 사용되고 있고, 팀원 전원이 쓰는 공용 컴포넌트로 정착했다. 2편에서 정리한 로딩 · 빈 데이터 · 에러 오버레이도 이 공통 그리드의 일부다.
정리
이번 일에서 배운 건 단순하다.
- 다른 포지션의 의견은 존중하되, 관성으로 유지되는 방식보다 더 나은 방향이 있다면 근거를 가지고 의견을 내야 한다.
- 말로 의견을 주고받는 것보다 결과물로 보여주는 게 빠르다. 디자이너의 우려는 장황하게 설명하는 말이 아닌 직접 만져본 프로토타입으로 풀 수 있었다.
- 나도 확신할 수 없을 때는 빠르게 검증하며 증명하는 과정을 거치는 게 좋다. 개발 팀도 해보기 전까지는 100% 된다고 말할 수 없었다. 하루를 투자한 프로토타입이 양쪽의 불확실함을 동시에 없애줬다.
- 상대가 우려하는 게 정확히 무엇인지 먼저 파악해야 한다. 유지보수와 라이선스는 개발자의 언어였고, 디자이너에게 필요한 답은 재현 가능성과 QA 리스크였다.
다음 편에서는 공통 그리드 폴더에 관성적으로 남아 있던 CellModel을 정리한 과정을 다뤄보려고 한다.
