Retool 로 한달만에 어드민 페이지 만든 후기 02
2회차 글을 가져왔습니다. 그런데 이제 분석 대신 회고를 곁들인.
글에 들어가기 앞서....
머리 박고 시작하겠습니다... 리툴 프로덕트를 이용해서 어드민 툴을 만든 후기를 분석하려고 했으나... 벌써 3년이나 지나버려서 기억이 안 납니다. 죄송하지만 급하게 피봇하여 '개발 능력 0'의 사람이 어떻게 페이지를 기획하고 만들 수 있었는지에 대해서 작성드리고자 합니다. 프로덕트 분석을 원하셨던 분들은 저를 매우 치세요.
그럼 오랜만에 글 작성해보겠습니다.
저는 운영을 할 테니, 님은 개발을 하세요
Retool(이하, 리툴)은 노코드(no code)가 아닌, 로우코드(low code) 서비스이기 때문에 코딩을 전혀 하지 못하면 쓸 수가 없다. 로우코드는 제공되는 솔루션을 유연하게 사용할 수 있어서 좋다지만... 자바와 자바스크립트가 똑같은 건줄 알던 내게 이 유연함은 오히려 독이었다.
그래서 페이지 제작을 위해 첫 번째로 내가 떠올린 방법은 개발을 배우는 것이었다. 실제로 리툴 계정을 만들면서 개발자분께서 간단한 개발을 가르쳐주셨다. SDK와 API가 어떻게 다른지, Static Data와 Dynamic Data의 차이 등 아주 기본적인 개발 지식이었다. 하지만 인턴이 한달 남은 이 시점에 개발 공부를 시작하는건 아무리 봐도 시간 낭비였고, 내가 아무리 열심히 배워도 혼자서 페이지를 만들 수는 없을거 같았다. 개발자분께서 업무 시간을 나에게 온전히 할애하는 것도 어려운 상황이기도 했다.
그래서 나는 내가 가진 비교 우위에 집중하기로 했다. (지금 와서 보면 그때의 경험이 지금 나의 업무 습관을 만들었다고 생각한다.) 내가 우리 팀에서 상대적으로 가졌던 우위는 바로 '운영 경험'이었다. 기획도 잘 모르고, 개발은 전혀 모르지만 각 입점사별 담당자와 지지고 볶으며 얘기한 내용은 누구보다 내가 잘 알고 있다고 생각했다. 그때 나는 기획자 이은림과 개발자 이은림을 철저하게 분리했던 것 같다. 정확히 말하자면 기획자와 개발자 사이에 개발 리더가 있던 느낌이랄까. 기획안을 검토하고, 개발 실무자에게 일을 분배하는 리더 말이다. 그래서 나는 개발 리더와의 대화를 위해, 개발이 불필요한 영역은 모조리 다 준비해가기로 했다.
본격적으로 페이지를 기획하고 만들자
페이지 제작은 크게 세 단계로 이뤄졌다.
1. 입점사에서 자주 요청이 오는 기능 파악하기
2. 현재 요청을 어떻게 처리하고 있는지 확인하기
3. 이를 대체할 기능 만들기
1. 입점사에서 자주 요청하는 기능 파악하기
내가 만들기로 한 첫 번째 기능은 입점사의 프로필 수정 기능이었다. 그 당시 우리팀은 입점사가 요청할 경우에만 입점사의 프로필을 수정하고 있었다. 서비스 이름, 로고, 소개글, 소개 이미지까지 전부 다 우리 팀 개발자가 변경을 해야 했기에 꽤 요청이 많은 상황이었다. 심지어 담당 개발자가 1명이었으며, 프로필 정보 중 일부는 하드 코딩으로 수정을 진행하고 있었기 때문이다.
2. 현재 요청을 어떻게 처리하고 있는지 확인하기
우리에게 있는 것과 없는 것을 파악하는 것이 가장 어려우면서도 중요했던 것 같다. 우리의 MongoDB에 저장 중인 데이터를 파악하고, 이 데이터를 수정하기 위한 GraphQL의 API를 분석했다. 같은 데이터인데 다른 이름으로 적혀 있는 케이스도 보고, API가 어떤 테이블로 연결되는지를 가장 중시했던 것 같다.
예를 들어, 프로필 정보 중 서비스 이름과 로고, 한줄 소개글은 데이터가 있었으나, 자세한 소개글은 하드코딩으로 되어 있었다. 이럴 경우 개발자와의 회의를 통해 상세 소개글을 입력할 수 있는 DB를 구축할 것인지, DB에는 어떠한 정보를 넣어야 하는지를 논의한다. 그리고 서비스 이름, 로고, 한줄 소개글은 리툴에서 수정할 수 있도록 만들기를 결정한다.
3. 이를 대체할 기능 만들기
이제 다시 리툴로 돌아가 보자. 리툴을 이용하기 위해서는 데이터에 대한 이해가 필수적이다. 페이지에 들어가는 템플릿은 그에 연결된 데이터와 기능이 없다면 무용지물이다. 이용자가 블록 템플릿의 세세한 부분까지 모두 정의해야 한다. 페이지에 어떤 형태의 템플릿을 추가할지 선택하고, 블록별 데이터를 연결한다. 그리고 기능을 붙이기 위한 기본적인 개념을 알아야 한다. 데이터의 확장자나 각 데이터별 언어 정도는 알아야 수정 방식을 논의할 수 있다. 그리고 이에 따라 블록에 버튼을 추가하고, 이 버튼에 쿼리를 입력한 뒤 퍼블리시하면 페이지는 완성된다.
이 부분이 제일 어려웠고, 개발자분의 도움을 많이 요청한 파트이다. 실제로 내가 연결한 데이터가 맞는지 확인했고, 이걸 어떻게 바꾸고 싶은지를 논의했다. 유저에게 직접 보이는 데이터를 수정하기 위한 기능이었기에 부담도 컸던것 같다. 하지만 그만큼 잘하고 싶어서 많이 고민했고 아무리 기능이 사소해도 실제로 동작하는 기능을 만들도록 노력했다.
그 당시 작성한 쿼리. 무슨 내용인지는 이제 모르는게 함정.만들고 끝이 아니라 실제로 사용되도록
당시 만들었던 페이지는 프로필 관리와 후기 관리 페이지 밖에 없었다. 운영에 필요한 기능은 한가득이었지만 한달 동안은 그 정도가 최선이었던것 같다. 그래도 많은 사람의 도움을 받아 만든 페이지니까 내가 퇴사한 이후에도 팀원들이 썼으면 좋겠어서 인수인계에 집중했다.
인수인계서에는 각 기능별로 어떻게 서비스에 연결되는지를 정말 자세하게 작성했다. 쿼리는 나보다 팀원들이 더 잘 알테니 내가 어떤 의도를 갖고 기능을 넣었는지를 설명하려고 애썼던 것 같다. 그리고 특히 우리에게 없는 데이터나 기능을 모두 기록해서 추후 개선할 때 따로 찾아볼 필요가 없도록 정리했다. (지금도 이 페이지가 쓰이는지는 알 수 없다.)
이제 와서 보면 오히려 내가 일을 잘 못했기 때문에 이 일을 준거 같다는 생각이 든다. 어떻게든 스스로를 증명해보이겠다고 아등바등이었기 때문에 이런 해도 그만, 안해도 그만인 일을 아무런 기대 없이 준 거 같다는 생각말이다. 그래서 지금까지도 이 프로젝트가 내 자부심인건 조금 부끄러우면서도 재미있다. 얼마나 일을 못했으면 기획자한테 이걸 맡겼을까 싶으면서도, 결국 해냈으니 얼마나 다르게 보였을까 싶다. 나를 못 믿던 사람들을 생각하면 조금 통쾌하기도 하다.
강조되고 반복되는 고용 불안정은 저를 불안하게 만듭니다.마지막 주에는 이 일을 내게 맡기신 팀원분과 점심을 먹었다. 팀원분은 내게 스스로 문제를 정의하고 해결할 줄 안다고 했다. 그 분은 기억 못할지도 모르지만 난 아직도 내게 어려운 일이 주어질 때마다 그 한 문장을 생각하며 일을 한다. 그럼 여기까지, 내게 책임감과 오너십을 가르쳐 준 나의 소중한 프로젝트에 대한 기록을 마친다.
