Retool for Startups

왜 이 업종에 맞나고객 문의가 오면 운영 담당자가 개발자에게 '이 회원 상태 좀 봐 달라'고 부탁하는 구조가 가장 비쌉니다.

고객이 '결제했는데 이용이 안 된다'고 문의하면 운영 담당자는 데이터를 볼 권한도 화면도 없어 개발자를 부릅니다. 개발자는 하던 일을 멈추고 데이터베이스를 직접 열어 봅니다. 하루에 몇 번씩 반복됩니다.

서비스 데이터베이스를 읽기 전용으로 연결합니다. 첫 화면은 '이메일이나 회원번호로 검색하면 가입일·결제 상태·최근 이용 기록이 표로 보이는' 조회 화면 하나만 만듭니다. 검색창 하나, 표 하나면 됩니다.

조회가 안정되면 '결제 상태 재확인' 버튼처럼 운영팀이 자주 부탁하는 동작을 하나씩 버튼으로 붙입니다. 쓰기 권한이 있는 동작은 확인 창을 한 번 거치게 하고 누가 언제 눌렀는지 기록이 남게 합니다.

운영 담당자가 문의를 받은 자리에서 확인하고 답하니 답변 시간이 줄고 개발자를 부르는 횟수가 줄어듭니다.

처음부터 쓰기 권한을 주지 마세요. 조회로 한 달을 돌려 어떤 동작이 정말 필요한지 본 뒤에 붙이는 것이 사고가 적습니다.

왜 이 업종에 맞나앱 운영은 공지 등록, 잘못 들어간 데이터 수정, 신고 처리처럼 '작지만 매일 있는 일'이 대부분입니다.

앱을 내고 나면 콘텐츠 등록·신고 처리·잘못된 데이터 정정 같은 운영 업무가 매일 생깁니다. 이런 화면을 앱 안에 만들면 앱 배포를 다시 해야 하고 안 만들면 개발자가 직접 데이터를 고칩니다.

운영 항목을 세 가지로 추립니다. 예를 들어 '공지 등록', '신고된 게시물 처리', '회원 상태 변경'입니다. 각각 표 하나와 입력 폼? 하나로 화면을 만들고 저장 버튼이 API? 를 호출하게 연결합니다.

운영 담당자별로 볼 수 있는 화면과 누를 수 있는 버튼을 나눕니다. 신고 처리 담당은 게시물만, 회원 관리 담당은 회원 화면만 보게 하면 실수가 줄어듭니다.

앱을 다시 배포하지 않고도 운영 화면을 고칠 수 있으니, 운영 규칙이 바뀌어도 앱 출시 일정과 상관없이 대응합니다.

화면이 늘어나면 어느 화면이 어느 데이터를 만지는지 목록을 따로 관리하세요. 나중에 데이터 구조를 바꿀 때 어디가 깨지는지 바로 압니다.

왜 이 업종에 맞나판매자와 구매자가 모두 있는 플랫폼은 관리자 화면이 고객 화면보다 먼저 필요할 때가 많습니다.

입점사 승인, 상품 검수, 월 정산처럼 플랫폼 운영에는 사람이 판단하는 단계가 많습니다. 이걸 엑셀로 하다 보면 입점사가 몇십 곳만 넘어도 누락이 생깁니다.

입점 신청 데이터를 연결해 '대기 중 입점사 목록 → 서류 확인 → 승인·반려 버튼' 흐름을 화면 하나로 만듭니다. 반려 사유 입력 칸을 두고 버튼을 누르면 입점사에게 자동 메일이 가도록 API 를 겁니다.

정산은 주문 데이터를 월별로 묶어 입점사별 매출·수수료·지급액을 표로 보여 주는 화면을 만듭니다. 계산은 화면에서 하지 말고 서버? 쪽에서 계산한 값을 보여 주기만 하게 해야 숫자가 어긋나지 않습니다.

입점 처리와 정산이 화면에 남으니 담당자가 바뀌어도 이력이 있고 입점사가 '언제 승인되나' 물으면 바로 답합니다.

정산 금액처럼 돈이 걸린 화면은 개발자가 한 번 검토한 뒤 열어 두세요. 편해 보이는 만큼 실수도 빠르게 퍼집니다.