10. 기획 과정에서 배운 것들 ① (feat. 안정화 기능)
22년 12월부터 테이블 오더 서비스의 PO를 맡고 약 2달간 여러 기능들을 기획하게 된다. 회사에서 앱 서비스 기획을 실제로 해보는 것은 처음이었던 나에겐 모든 게 새로웠던 것 같다. (물론 사이드 프로젝트로 앱/웹 기획을 해본 적은 있었지만)
실제 유저의 VOC를 듣고, 이를 바탕으로 기능을 기획/개발하고, 개발된 기능을 실제 출시 후 운영을 하면서 피드백을 받는 일련의 과정에서 배운 것이 참 많았던 것 같다. 특히 사용자들이 돈을 내고 쓰는 서비스였기 때문에 더 달랐던 점이 많았던 것 같다.
이번 글에선 특히 안정화 관련 기능 기획과정에서 느꼈던 내용들 중 일부에 대해 적어보고자 한다.
1. 사장님에게 중요한 건 매장운영
식당 사장님들이 매장에서 어떤 서비스를 쓴다면, 그것은 대부분 2가지 이유중에 하나로 귀결될 것이다.
1. 매출을 높여주거나
2. 비용을 낮춰주거나(매장 운영 효율화)
결국에 내가 맡았던 테이블 오더라는 서비스도, 식당에서 일어나는 "주문/결제"에 투입되는 인력을 감소시켜 인건비를 낮추고 더 효율적으로 매장운영을 하게 만든다! 를 목표로 하고 있다.
이런 점에서 "2번: 비용낮추기(매장 운영 효율화)"에 매우 포커싱 된 서비스였다고 볼 수 있다.
(물론 부가적으로 매장회전율을 높이거나, 추가주문율을 높여주는 효과 등도 있어 1번에도 일부 해당된다.)
이러한 니즈를 가지고있는 사용자의 특성 때문에 타 서비스(ex. 일반적인 앱, 웹)와 다른 특수성들이 존재했다.
1) 매우 중요한 "실시간성"
매장 운영을 효율적으로 하고 싶어하는 사장님 입장에서, 테이블 오더를 쓸 때 정말 중요했던 것 중에 하나가 "실시간성"이라는 포인트였다.
예를 들어, 사장님이 테이블오더의 특정 세팅을 바꿨다고 해보자. (ex. 메뉴 가격 변경, 특정 메뉴 품절, 신규 상품 추가)
매장에는 보통 테이블 마다 테이블 오더 태블릿이 비치되어 있다. 작은 식당의 경우 10개 정도의 테이블이 있고, 대형매장의 경우 20~30개가 넘는 경우도 있다. 따라서 거의 20~30개의 태블릿을 보유하고 있는 것이다.
=> 세팅값을 바꿨을때 전체 태블릿에 정보가 실시간 반영이 되지 않는다면 어떻게 될까?
=> 예를들어 각 태블릿의 테이블 오더 앱을 껐다 켜어야지만, 변경사항이 반영된다면?
- 이렇게 되면 어떤 태블릿엔 변경된 가격의 상품이 나타날것이고, 어떤 태블릿엔 예전 가격의 상품이 나올 것이다.
- 사장님이 품절시킨 상품인데 고객의 주문이 들어갈 수도 있을것 이다.
- 또한 태블릿에 깔린 테이블 오더앱을 하나하나씩 껐다 켜야한다면 하나당 30초씩만 소요된다 해도 30초 x 30개 =900초 (15분) 가 소요된다.
이렇게 되면 인건비를 아끼고 매장 효율화를 하려고 설치했다가 오히려 불편해지는 상황이 발생할 수도 있는 것이다. 결국 매장 매출에 영향이 갈 수도 있고, 손님 Claim으로 이어져 매장이미지를 떨어뜨릴 수도 있는 부분이다.
일반적인 앱/웹이라면 아래와 같이 편하게 처리할 수도 있었겠지만....
- 웹사이트: 바로 실시간 반영은 안 되고, 유저가 새로고침 버튼 누르게 하기 (ex. 크롬 새로고침 버튼)
- 기기 1대로(ex. 스마트폰 1대)로 이뤄지는 앱 :새로고침 버튼을 유저가 누르게 유도하거나, 유저가 앱 자체를 껐다 키게 하기
테이블 오더 서비스는 20~30대의 태블릿을 한 번에 컨트롤해야 하고, 각 태블릿에서의 액션이 결국 주문/결제라는 "매장의 매출"과 연결되어 있다. 그래서 다른 서비스에선 덜 민감할 수도 있는 "실시간성"이라는 이슈가 테이블오더에선 더욱 크게 작용할 수 밖에 없었다.
2) 더 나은 실시간성을 위한 고민
이렇게 "실시간성" 이라는 요소가 테이블 오더에 중요했기에 내가 해당 서비스의 PO를 맡고 나서도 해당 부분에 대한 우선순위가 높을 수밖에 없었다. 특히 내가 서비스를 처음 맡았을 때는 극 서비스 초기단계였기 때문에, 매장에서 일어날 수 있는 다양한 실시간성 관련 이슈에 대해 완전히 대응이 되어있진 않았다. 그렇기 때문에 여러 상황에서 발생할 수 있는 실시간성 이슈 들에 대해 기술적으로 안정화를 시켜나가는 과정이 초반에 Product 팀 분들과 가장 노력했던 부분 중에 하나였던 것 같다.
1. 푸셔 VS 폴링, 과연 어떤 기술을 쓰는게 좋을까?
실시간성 이슈에 대한 해결을 위해 기술적으로 푸셔와 폴링이라는 방식을 이용하게 된다.
이에 대한 이해를 돕기 위해 개념을 간단히 서술해보면 다음과 같다.
(개발자가 아니기 때문에 엄밀한 개념은 아닐 수 있는 것 양해 부탁)
a. 푸셔
- 개념: 유저가 "특정 세팅을 변경했을때"에 나머지 20~30개의 테이블 오더 태블릿에 "세팅이 변경됐어! 너네도 어서 세팅값을 바꿔"라는 신호를 보내서 해당 20~30개 태블릿의 세팅을 변경시키는 것
- 장점: 유저가 세팅을 변경했을때만 신호를 보내면 되므로 훨씬 효율적
- 단점: 신호를 받는 20~30개의 태블릿 중 와이파이가 불안정하거나, 앱이 백그라운드로 가있는 태블릿은 신호를 못 받을 수 있음.
b. 폴링
- 개념: 20~30개 태블릿에 있는 각각의 테이블 오더 앱에서 주기적으로 (ex. 30초 간격, 60초 간격) 으로, 서버 DB 상에 저장되어 있는 최신 정보를 당겨오는 방법
- 장점: 주기적으로 최신정보를 동기화 하므로, 정확성/안정성 측면에서 장점
- 단점: 잦은 호출로 인한 서버비용 문제, 너무 많은 정보를 당겨올 경우 해당 떙겨오는 화면에서 앱이 느려질 수 있음.
이에 대해서 "어 그럼 '푸셔' 라는건 딱 그 세팅값 바꿔줄 때만 신호를 쏘니까 개발적으로 더 효율적이고, 저거 쓰면 되는 것 아니에요?"라고 물을 수 있다.
=> 일반적인 상황에서는 그럴 수 있지만, 우리 앱을 쓰는 장소인 식당의 경우 와이파이가 매우 불안정...한 상황이 많다.
(와이파이 한개에 몇십대의 태블릿이 연결되어 있고, 여러 태블릿에서 동시에 액션을 할 경우 일시적으로 불안정해질 수 있다.)
그래서 해당 와이파이 불안정으로 인해 몇개의 태블릿만 신호가 중간에 누락될 가능성도 있다. (세팅값이 몇 개 태블릿만 안 바뀔 수도 있는 것)
반대로, "폴링이 그럼 안정성 측면에서 더 탄탄할 거 같은데, 그럼 저걸로 앱의 모든 화면 다 가면 되지 않을까요?" 라고 물을 수 있다.
=> 위의 장단점에서 적은 서버비용의 발생은 차치하더라도, 앱이 너무 느려질 가능성이 있다. 손님입장에서 주문/결제를 편하게 할 수 있게 테이블 오더 앱을 쓰는 건데, 그 앱이 여러 화면에서 느리고, 잘 먹지도 않는다면...? 더 많은 불만이 생길 수도 있다.
2. 그러면 어떻게 기획하나..?
그래서 결국은 "액션에 따라" 기획을 다르게 하는게 중요했다.
1) 이 액션이 얼마나 중요한 액션인지 2)얼마나 자주 일어날 것 같은지 등에 따라서 동기화 주기/방법을 다르게 기획하는게 중요했다 (ex. 푸셔만 사용, 폴링만 사용, 둘 다 사용, 폴링의 동기화 주기는 몇 초로 할지 등)
예를 들어 매장 매출에 유의미한 영향을 줄 수 있고, 자주 발생할 수 있는 세팅값 변경의 경우,
세팅값을 변경했을 때 신호를 보내는 푸셔 뿐만 아니라, 주기적으로 n 초마다 폴링(서버 정보 동기화)을 하는 식으로 개발하는 것이다. 이를 통해 혹시나 푸셔 신호가 누락되더라도, n초마다 있는 폴링으로 인해 최대 n초 안에는 최신정보로 동기화될 수 있어 안전장치를 마련할 수 있다.
반대로 매장 매출에 영향이 크지도 않고, 엄청 가끔(ex. 몇달에 한번) 하는 세팅값 변경의 경우 푸셔만 넣는 식으로 처리하는 것이다. 매출에 큰 영향은 없는 세팅값이기에 혹시나 몇 개의 태블릿에 누락되더라도 감안할 수 있을 것이다. 또한 해당 태블릿의 앱을 껐다 켜면 최신정보는 반영되기 때문에 운영적으로 처리가 가능하다. 폴링을 추가하는 것도 결국 다 개발 공수가 드는 것이기에, 해당 부분에 대한 불편이 주기적으로 자주 인입되면 그때 폴링기능을 추가하는 식인 것이다.
이렇게 나름의 방편을 마련했다싶겠지만, 더 악조건의 상황까지 고려해서 기획하는게 필요했다.
예를 들면 아래와 같다.
=> 악조건 예시: 30초 주기로 세팅값을 폴링(동기화) 한다 치자. 만약 사장님이 세팅값은 변경(품절로 변경) 했고, 이게 반영되기까지 30초가 걸린다. 29초 째라 아직은 상품이 테이블 오더 앱 UI에서 품절처리가 안되어서 고객이 주문을 넣어버버릴 수 있다면?
바쁜 매장의 상황에선 이런 상황이 안 발생하리란 것은 없으므로 이를 고려해 2차 보완책을 마련하는 기획이 필요했다.
예를 들어 중요액션인 주문 같은 경우에는, 고객이 앱에서 주문 버튼을 눌렀을때 클라이언트(테이블 오더 앱)에서 서버에 고객이 주문을 시도했다는 신호를 보낼 것이다. 이때 서버 DB 내 데이터와 교차 검증을 통해서 정말 맞는 세팅값으로 요청을 보낸 게 맞는지 검증하는 것이다.
(ex. 품절된 상품인데 테이블 오더 앱 UI상 품절처리가 안되어서 고객이 주문 넣었다. 이때는 서버에 있는 데이터에는 품절로 되어있으므로, 품절이라 주문 불가하다고 메시지를 앱에 내려주고, 그에 따라 앱 UI 도 품절상태로 바꿔버리기)
초반엔 이런 기술들에 대해서 잘 알지 못했다. 푸셔가 뭔지 폴링이 뭔지 들어본 적도 없어서, 나름대로 이리저리 찾아보고 여쭤봤던 것 같다. 같은 팀에 계시는 프론트, 백엔드 개발자님과 CPO 님께서 기술들에 대해 알려주시고 기획적인 부분에 대해서도 더 좋은 방향에 대해서 많이 제안들을 해주셨다. 그래서 하나하나 이런 실시간성 관련 이슈들을 함께 해결하다 보니, 이 부분에 있어서는 꽤나 안정화가 됐었고 덕분에 좀 더 나은 서비스를 만들 수 있었던 것 같다.
또 이런 실시간성에 대한 디테일한 고민(ex. 여러 악조건 case 가정, 경험) 을 해볼 수 있었던 것은 꼭 테이블오더가 아니라, 다른 서비스를 기획할 때도 더 세세한 기획을 할 수 있는 능력을 직간접적으로 길러주었다고 생각해서 회사에 감사한다.
2. 사소해 보이지만 아니야
1) 효과음 파일의 음량이 중요하다고?
일반적인 앱이라면 효과음 파일의 음량 크기는 그렇게 중요한 요소가 아닐 수 있다.
하지만, 매장운영 효율화를 위한 테이블 오더앱에선 이런 효과음 파일의 음량 같은 사소해 보이는 부분이 정말 중요하게 작용했었다.
테이블 오더를 써본 분들은 알겠지만, 보통 테이블 오더 앱에는 직원을 호출하는 버튼이 있다. 해당 버튼을 손님이 누르면, 사장님의 POS기에서 호출 효과음이 나는 기능이다. 만약 이 소리가 잘 안 들린다면, 직원이 손님의 호출에 대응을 안 한 게 되므로 손님의 강한 Claim으로 이어질 수도 있다. 매장운영을 효율화하기 위해 쓴 서비스인데 오히려 방해가 될 수도 있는 것이다.
많은 분들이, 근데 음량 뭐 어느정도 작지 않은 이상 다 잘 들리지 않나요? 앱 코드에 삽입한 음성파일의 크기가 그렇게 중요한가요? 그냥 사장님 기기에서 음량 키우기 하면 되는 거 아니에요?라고 물음을 할 수도 있다.
1. 그러나 우리가 공급하는 서비스는 식당/술집에서 주로 쓰는 서비스다.
(매장의 음악소리, 손님들이 대화하는 소리가 크다면 효과음이 묻힐수도 있다. )
2. 매장마다 해당 음성을 출력하는 기기의 사양이 천지 차이다.
(어떤 사장님은 좋은 스피커를 연결해 쓸 수도, 또 어떤 사장님은 저가형 태블릿의 안 좋은 내장 스피커를 쓸 수도)
실제로 서비스 극초기 이런 효과음 파일 음량의 크기에 대해 아쉬움을 표출하는 VOC가 꽤 많았고, 빠른 우선순위로 관련 문제를 해결하기 위한 개발을 했던 것이 생각난다.
그 과정에서 느꼈던 것은 다음과 같다.
1. 서비스가 실제 사용되는 환경은 테스트하는 환경과 다르다
음성 파일의 음량에 대해 테스트를 하는 것은 회사 사무실이다. 사무실에선 웬만하면 소리가 잘 들리고 크게 들릴 수 있다.
하지만 노래가 틀어져 있고 시끄럽게 떠드는 술집이라면? 그리고 출력 사양이 안좋은 스피커라면 회사의 테스트 환경과는 상황이 다를 수 있는 것이다.
서비스가 실제 사용되는 환경은 테스트하는 환경(소음, 기기 사양) 과 또 다르다는 것을 이해, 인지하고 그런 지점들을 고려해서 기획하고 테스트 하는 것의 중요성을 느꼈던 순간이었다.
2. 기능 개발 우선순위란 상대적인 것
당연하게 들릴 수도 있지만, 기능 개발 우선순위는 정말 상대적이란 걸 느꼈다. 일반앱에선 그렇게 큰 고려를 하지 않아도 될 부분이 특정 서비스에선 정말 큰 우선순위일 수도 있다는 것을 많이 느꼈다.
마찬가지로, 멋들어진 새로운 기능들이 중요해 보일 수 있어도 어떤 서비스의 타겟에게는 그것보다 안정화 기능이 훨씬 시급하고 중요할 수 있다는 것도 알게 되었다. 특히 내가 맡은 이 테이블 오더에 있어서는 무엇보다 "매장 운영 효율화" 라는 관점이 정말 중요한 기준이라는 것을 다시 한번 느끼게 해 줬던 순간이었다.
이번 글에선 특히 서비스의 안정화를 위한 기능들을 기획했던 과정들 그리고 그 과정에서의 느낀 점 위주로 작성했다.
다음 글에선 사용자에게 새로운 가치를 제공하기 위한 기능을 기획하는 과정에서 배웠던 내용 들에 대해 적어보고자 한다.
Profile: