[우테코] 스탬프크러쉬의 실제 사용자(카페 사장)와 함께한 일주일

 

 

 

 

안녕! 

우아한테크코스 5기 [스탬프크러쉬]팀 깃짱이라고 합니다. 

 

스탬프크러쉬 서비스의 소스 코드 바로가기

사장모드: stampcrush.site/admin

고객모드: stampcrush.site

 

 

이번 포스팅 제목은 약간 모리와 함께한 화요일 느낌으로다가 해봤는데... 눈치 챈 사람 있나..? 풉킼

 

💋 드디어 실제 사용자(카페 사장)가 스탬프크러쉬를 사용하기 시작했다!

✔️ [23.10.06] 성수동 개인카페 ‘파일론 성수’에서 스탬프크러쉬 첫 사용

바로 전날, 라잇과 나는 파일론 성수에 가서, 마지막으로 동작 확인 등등을 하고 돌아왔다.

그리고 하루 뒤인 10월 6일, 드디어 파일론 카페에서 우리 서비스를 쓰기 시작했다!!!

진짜로 이렇게 슬랙으로 적립 알림이 막 오기 시작하니 와쿠와쿠

 

 

일주일 동안 계속해서 적립이 쌓이기 시작했고, 팀원들 모두 신이 났다.

 

✔️ [23.10.06] 우테코 공식 카페 ‘글렌카페’에서 스탬프크러쉬 첫 사용

글렌은 하루에 약 2번 정도 우테코 내 공식 카페 글렌카페를 운영한다. 크루들에게 늘 커피를 타주는 것을 많이 봤기 때문에, 직접 영업을 해서 글렌도 이제 스탬프크러쉬를 사용하기 시작했다 ㅎㅎㅎㅎ

 

 

💋 개발자가 준비해야 할 것들

✔️ 꼼꼼한 예외처리가 필요하다!

어떻게 구한 실제 카페인데, 절대로 첫 일주일부터 장애를 내서는 안된다는 마음이 커졌고, 어떤 기능에 문제가 있는 것 같다는 이야기가 나올 때마다 가슴이 덜컹하게 되었다.

 

그러던 중에, 주말 동안 우테코 크루가 장난으로 우리 실제 운영 서버에 10만 건의 스탬프를 적립하는 일이 일어났다.

프론트엔드 측에서는 UI로 사용하면 분명히 최대 10개까지만 적립되도록 해 놓았는데, 알고보니 백엔드 측에서 별다른 조치를 취하지 않은 것이다.

 

 

10만 개의 스탬프에 대해서 10만 개의 스탬프에 대한 기록이 데이터베이스에 저장되었고, 거의 1만 개 가까운 쿠폰도 생성되었으며 리워드도 1만 개 생성되었다….

이 일로 인해서 서버가 버티지 못하고 죽었더라면…? 장난친 사람에게 책임을 물을 수 있을까?

우테코 내에서 이런 장난을 치는 것에 대해서 정말 화가 나긴 했지만, 먼저 백엔드에서 해당 요청은 거를 수 있도록 했어야만 했다. 이전에 대규모 시스템 설계에 대한 책에서 API를 얼마 이상 이용할 수 없도록 각 사용자를 제한해야 한다고 했는데 이도 유사한 상황이었다. 하나의 악성 요청으로 인해 전체 시스템이 흔들릴 수 있던 상황이었다.

 

✔️ 적립한 고객들에게 SMS 발송 기능이 필요하다!

 

일단, 적립이 제대로 발생하는지 매번 데이터베이스로 모니터링할 수 없는 법이다.

우리 팀은 적립 발생에 대해 이벤트를 발행해서 슬랙에 알림이 오도록 연동해 놓았다.

 

또, 적립한 사람들은 적립 때마다 일일이 알림을 보내주고 있다. 물론 자동화하면 최고겠지만, 현재로는 문자 보내는 API나 카카오톡 메세지를 보내는 API 사용에 대해서 알아볼 시간이 없어서, 수동으로 진행중이다.

 

 

위와 같은 내용을 프론트 크루 윤생이 직접 보내주고 있다…ㅋㅋ 가짜 Web 발신..

 

 

하지만 이렇게 적립은 하루에도 수십번씩 일어나고 있어서 윤생이 이제 한계에 다다른 듯 하다..ㅋㅋㅌㅌ

찾아보니, 네이버 SMS API 연동과 같은 방법들이 있을 것 같으니.. 취업이 비교적 급하지 않은 내가 좀 더 알아봐야 겠다.

 

 

💋 파일론 카페 사장님의 피드백

✔️ 사장모드를 아이디, 비밀번호를 사용한 로그인으로 변경해달라고 요청했다.

우리 팀은 마냥 OAuth를 사용한 소셜 로그인을 사용하면 더 편리할 것이라고 생각했는데, 아니었다.

카페 사장 측에서는 항상 같은 사람이 이용하는 것이 아니라 알바생, 대타 등등 여러 사람이 이용해야 하므로 아이디 비밀번호를 사용한 방식으로 변경해달라고 요청했다.

스탬프크러쉬는 초창기에는 login_id, encrypted_password를 데이터베이스에 저장하는 식으로 구상했었다. 하지만, 이후에 로그인을 만드는 과정에서 OAuth 방식이 더 편리할 것이라고 생각해 해당 두 칼럼은 비워둔 채로 OAuth와 관련된 칼럼을 추가하는 식으로 변경했었다.

 

결과적으로 아래와 같이 일반 아이디, 비밀번호 방식의 로그인과 OAuth 방식을 위한 칼럼이 공존했었다.

 

mysql> describe owner;
+--------------------+-----------------------+------+-----+---------+----------------+
| Field			  | Type				  | Null | Key | Default | Extra		  |
+--------------------+-----------------------+------+-----+---------+----------------+
| created_at		 | datetime(6)		   | YES  |	 | NULL	|				|
| id				 | bigint				| NO   | PRI | NULL	| auto_increment |
| updated_at		 | datetime(6)		   | YES  |	 | NULL	|				|
| encrypted_password | varchar(255)		  | YES  |	 | NULL	|				|
| login_id		   | varchar(255)		  | YES  |	 | NULL	|				|
| name			   | varchar(255)		  | YES  |	 | NULL	|				|
| phone_number	   | varchar(255)		  | YES  |	 | NULL	|				|
| email			  | varchar(255)		  | YES  |	 | NULL	|				|
| oauth_provider	 | enum('KAKAO','NAVER') | YES  |	 | NULL	|				|
| oauth_id		   | bigint				| YES  |	 | NULL	|				|
+--------------------+-----------------------+------+-----+---------+----------------+
10 rows in set (0.00 sec)

 

백엔드 내부에서도 사용하지 않는 login_id, encrypted_password 를 지우는 것이 어떠냐는 의견이 있었는데, 나는 ‘만약에충’이라서 남겨두자고 했었다. 정말 다행ㅋㅋㅋ 또 스키마 변경할 생각 하니 아주 귀찮았을 것 같다. 서비스가 자리잡지 않은 초창기에는 성능을 너무 과도하게 생각하기보다는, 좀 비효율적이더라도 많은 가능성을 남겨두는 것도 좋을 것 같다는 생각이 들었다.

 

✔️ 고객모드에서 임시 회원도 리워드를 사용할 수 있도록 해달라고 요청했다.

스탬프크러쉬의 기존 정책은 아래와 같았다.

• 스탬프크러쉬 고객모드 임시 회원(미가입자)도 전화번호만을 입력해 손쉽게 적립 가능
• 스탬프크러쉬 고객모드에 접속해 자신의 쿠폰북을 확인하려면 가입 필요
• 발급된 리워드를 사용하려면 스탬프크러쉬 고객모드에 가입 필요 → 임시 회원은 8잔 모아도 회원가입 전에는 아메리카노를 마실 수 없다는 뜻.

 

하지만, 파일론에서는 임시 회원도 리워드를 사용할 수 있게 해달라고 요청했다.

이건 파일론과 스탬프크러쉬의 이익이 충돌하는 부분이었다.

• 파일론: 임시회원도 리워드를 사용할 수 있게 되면, 고객이 귀찮은 가입을 하지 않더라도 쿠폰북 확인을 제외한 모든 기능을 사용할 수 있음.
• 스탬프크러쉬: 쿠폰북 확인은 가장 강제성이 없는 부분인데, 임시회원도 리워드를 사용할 수 있게 되면 고객모드에 아무도 안 들어올 위험이 있음.

 

하지만 우리는 아직 슈퍼슈퍼 을이니깐!

곧바로 해당 요구사항을 반영했다. 요구사항 반영은 리워드 사용 시에 임시 회원이 아닌지에 대한 검증 로직만 제거하면 되기 때문에 매우 간단했다…. 하지만 슬펐다.

 

결과는 아래에서 이어진다.

 

 

💋 부진한 고객모드 회원가입

우리는 이 일은 예상하고는 있었다.

 

아무튼 일주일 간 사장모드는 카페에서 열심히 사용했지만, 고객모드에 가입하는 사람들은 정말 극히 드물었다.

파일론 카페 측에서는 카카오로그인이 문제일 것이라고 생각했는지, 로그인 방식을 바꾸는 것이 어떠냐고 제안했다.

 

 

하지만, 워낙 5%도 안되는 사람들이 고객모드에 가입할 것이라고 예상했기 때문에 나는 로그인 방식과 같은 사소한 것이 원인이 아니라, 우리 비즈니스 특성 상 고객모드 가입은 워낙 드문 일인 것이 당연하다고 주장했다. 팀원들도 이에 동의해 일단은 보류하기로 했다.

 

유사한 서비스인 도도포인트만 생각해보더라도, 그냥 적립이 잘 되었겠거니 믿고 넘어가지, 직접 들어가서 확인할 생각을 하지 않는다. 만약에 들어가서 가입을 할까 고민한다면, 오히려 소셜 로그인이 더 진입장벽이 낮고 내 아이디 비밀번호를 직접 입력하라고 하면 더 꺼려질 것이라고 나는 생각한다.

 

고객모드의 회원가입 전환에 대해서는 다음 주에 추가로 이야기하고 조치를 취하기로 했는데, 현재 나의 생각은 당연한 일인데 조치를 취할 필요가 있는가..? 이다.

 

내가 생각하기에는 6개월 이내로 회원가입하지 않으면 모든 데이터가 날아간다고 보내기 (일단 말만… 실제로 할 지는 이제 생각해봐야함..ㅋㅋ) 같은 방식이 있을 것 같다.

 

💋 파일론의 사용자를 늘려주자!

사장모드에서 적립하는 고객은 하루 10명~20명 정도. 파일론은 하지만, 구글맵에도 등록되어 있지 않았다. 그래서 내가 직접 등록해줌ㅋㅋㅌㅋㅋ

 

등록하면 아래와 같이 메일로 진행 상황도 보내준다. 구글 개발자들 힘들겠어.

 

 

이제 파일론 성수라고 검색하면 구글맵에서 찾아볼 수 있다.

 

 

💋 첫 피드백, 긍정적.

처음으로 긍정적인 피드백을 받았다. 약 일주일 사용 후에 편하다고들 하네요 라는 피드백에 우리 팀원 모두 감동의 눈물을 내적으로 흘렸다.

 

 

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟