서비스 초심자를 위해 글을 적어보면서

프로덕트 만드는거에 집중하다보면 기존사용자, 기존기능, 신규기능에 신경쓰게 되면서 '첫 가입자' 온보딩 흐름을 놓치는 경우가 생기는 것 같다.

주기적으로 테스트 과정을 거치면서 첫 가입, 첫 프로젝트(팀) 생성, 첫 데이터 연결, 첫 화면 구성등을 해보는데 그때마다 아쉽고 불편한 것들이 튀어 나온다.

"쓸 사람은 어떻게든 쓴다"

사실 처음에는 이런(위험한) 생각도 했었다. 불편하지만- 그럼에도 불구하고 이걸 쓰고 가치를 느낀다면 좋은게 아닐까?

하지만 조금 더 나아가 생각해보면 (요즘 가입자가 늘고, 안착 사용자도 계속 늘고 있지만) 앞으로 들어오시는 더 많은 주변 사람들에게 난감한 순간을 선물하는건 아닌가 하는 씁쓸한 생각이 들었다.

더 잘 했으면 더 좋았을텐데 라는 아쉬움이 한가득 생겨서 기록으로 남겨본다. 메이커로서 미안함도 느껴지고 더 좋은 제품을 전달하지 못한 팀 구성원으로서의 아쉬움있고 앞으로 더 잘해야겠다. (청소를 잘하자! 주제로 글을 써봐야겠다.)

오랜만에 이번에는 초심자-튜토리얼 글을 적으면서 깨닫는게 있을 듯하여 첫 사용자 관점에서 글을 먼저 적어보았다. 좋기도, 어렵기도, 싱숭생숭한 구석들이 여전히 많아 보이고 놓쳤던 부분도 조금씩 보이게 되니까 좋았다. (남에게 설명하고 알려주다보면 깨닫는게 있는 듯)

부담없이 간단한 어드민 만들기 - Serverless

안녕하세요. 셀렉트 팀의 이진혁입니다. 제 주변에도, 커뮤니티를 지켜보아도 세상에 많은 분들이 멋진 프로덕트를 만들고 계신데요. 직접 개발하거나 여러가지 노코드툴을 활용하여 웹이나 앱 형태의 프로덕트를 빠르게 만드는 모습이 너무나 대단하게 느껴집니다. 모든 프로덕트와 서비스는 .. 처음에는 간단하게 시작하지만 사용자가 늘어나고 기능이 늘어나며 관리할 포인트가 점점 늘어나게 된다고 이야기를 종종 듣습니다. 조회나 수정

https://blog.selectfromuser.com/serverless-admin/

원래 해결하고자 했던 문제에서는

"깊은 고민없이 (한숨 쉬지 않고) 누구나 어드민/운영툴 만들기"

첫 요구사항 (2021년 12월) 기준으로는 대부분 충족했다. (1년 넘게 시간을 썼다는게 믿기지 않는다)

• 이제 더 이상 신규어드민 니즈가 회의때 나와도 기획, 개발 담당자가 눈알 굴리는 상황은 없을 것이며
• CS팀, 영업팀, 마케팅팀이 매주 자료 요청하거나 급하게 화면 고쳐달라는 이슈를 개발자 통하지 않고도 (통하더라도 서로 편하게) 해결할 수 있다!

이래저래 비슷한 서비스도 나오는 것 같고, 해외 서비스도 꽤 있는데 앞으로 어떻게 될지 기대된다. 아직까지 우리는 진짜 어드민을 만드는 거의 유일한 회사고, 어드민 자체는 본업(고객/매출/영업/운영)에 집중하기 위해 만든다는 사실이 너무나 중요하다. 왜 이 일을 처음 시작했고 수년간 해오는지 오랜만에 다시 생각이 났다. (첫 사용자 관점에서 튜토리얼 글을 적다가 갑자기 생각이 들었다)

지난 18개월 정도의 기간 동안 수 많은 인터뷰와 피드백, 쓰고 계신 분들, 문제있다고 달려오신 분들에게 너무나 고맙고 잘해야겠다. 셀렉트는 두번째 요구사항 (2023년)과 함께 2025년까지 계속 갑니다!

너무나 오랜만에 올린 메이커로그 끝

지금 꼭 로그를 쌓아야할까?

로그란

과거에 나에겐 로그란 디버깅 도구? 방법 정도였다.

토이프로젝트를 하면서 로그는 잘돌아가나? 지켜보는 도구이자

사용자들이 잘 쓰고 있나 지켜보는 용도였다.

그러다가 회사 일을 할때나 조금 더 묵직한 서비스를 만들때

점점 로그는 신규기능과 동시에 챙겨야하는 중요한 부분이 되었다.

하지만 새 프로젝트를 하면 기능 추가와 유지보수로 바쁘기 때문에

로그 기반이나 로그 방식, 표준화된 에러 리포트를 놓치기 쉽다.

그럼에도 로그는 정말 중요하다. 노력대비 얻는 것이 크기 때문인데.

신규기능의 이용활성도, 응답속도,

사용자의 오묘한 이용패턴과 변수 파악, 이럴리가 없는데 에러 포착,

기능개선, 추후 유지보수등등 매우 쓸모가 있기 때문이다.

서버나 웹이나 모바일 환경등등 로그의 형태가 다르고

종류가 많기 때문에 단정짓기는 어렵지만 ..

최소한 서버 단 로그는 반드시 남기는게 필요하다고 본다.

이제 그러면 얼마나/자주/자세히 로그를 남기는지가 고민될 것이다.

로그 걱정 하나

일반적으로 로그 시스템을 구축하려고 하지만

서비스 초반에는 로그가 양이 별로 많지 않다.

따라서 ELK, Datadog 이런거 아니더라도

RDBMS에 쌓아도 무리가 없다. 로그가 월 100만건 넘지 않는다면

일상적인 조회, 통계에 전혀 문제가 없다.

디비는 생각보다 강력해서 시간순서로 쌓인 데이터에 대한 쿼리는 빠르고

SQL을 할줄 안다면 누구나 현재/과거 지표를 뽑기 편하다.

요즘은 MySQL, PostgreSQL도 JSON 지원이 잘되어서

로그 전용 디비를 따로 둘 필요도 없다.

다소 데이터 공간 낭비가 있지만 업데이트 내역(before/after, prev/next)까지

남긴다면 사용자의 시간순 경험을 replay 할 수 있고

버그 파악이나 고객 장애 파악에 도움이 된다.

로그 형식

서비스 형태, 지원기기, 이벤트 단위에 따라 다르겠지만

초기엔 '거의 모든 사용자의 행동'을 로그남기는 걸 추천한다.

이벤트 단위라면 mixpanel, amplitude등 서비스도 있고

마케팅용 써드파티도 많지만 결국엔 디비 조회를 찾게된다. (큰회사나 작은회사 모두)

모바일이나 게임쪽은 상당한 로그를 남기는 것으로 유명한데

웹서비스나 SaaS쪽은 아직 로그 사례가 많이 없는듯 하다.

결론

• 귀찮아도 로그 잘 쌓아야한다.
• 로그도 계획하고 개선해야한다.
• 디비에 쌓아도 서비스 초창기에는 괜찮다. (백만건 이하)
• (통계 용도가 아니더라도) 어차피 서비스가 성장하면 사용자의 모든 내역을 기록해야한다.

데이터팀(이름 미정) 리펙토링 거의 끝나간다.

요즘은 주로 셀렉트 어드민만 집중하고있지만

처음 시작할땐 '디비계정 공유없이 쿼리만 입력하고 구글시트로 짠' 나오는걸

주력으로 밀고나갔었다. 결과적으론 쿼리툴 대신 이걸쓰는 사람은 없었다.

나 조차도 그냥 디비클라이언트 쓰거나 어드민에 녹인다. 근데 여전히 가끔 쿼리로 엑셀뽑거나 임베딩하는게 필요하고, 목마른 갈증이 남아있어서 ... 데이터팀을 다시 재작성했다. 몇년째 궁시렁대던걸 드디어 해결해보고자 칼을 뽑은것이다.

목표

- 원래 쓰던, 연결해놓은 어드민에서 바로 시작가능할것

- 모든 쿼리가 검색 잘될것 (쿼리 보관도 일.. 뒤적거리는게 일상..)

- 단축키로 즉시 실행하고 에러가 잘나올것 (Cmd+Enter/R, Cmd+S 지원)

- 쿼리 결과는 물론이고 SQL도 공유하기 편할것

난 메모장 같은걸 원한건데. 디비접근제어나 디비툴 SaaS등 막상 써보니 투머치해서 내가 불만족스러웠던거 같다. 우리 회사의 주요 먹거리는 이 프로젝트가 아니지만, 어쨋거나 개발자가 더 이상 운영업무에 치이지 않도록 한줌 모래성을 쌓아본다.

(사진은 노션에 쿼리 결과 넣은 모습)

요즘 국내 SaaS는 다들 해외로 나가는 것 같다.