18. 2번의 롤백(Roll back)을 통해 배운 것
0. 롤백(Roll back) 이란?
롤백(Roll back)이란 영어 단어 그대로 "되돌리다"라는 의미를 가지고 있다. 앱에 심각한 버그가 발생한 경우, 버그가 발생하기 이전 버전으로 앱 버전을 되돌리는 것을 말한다.
보통은 해당 버그를 수정하지 않으면, 유저가 앱을 사용하는 main flow에 심한 영향이 갈 정도의 버그일 때 롤백이라는 수단을 고려한다.
물론 그 정도로 심각한 버그라면 빠르게 수정 후 재 배포를 하는게 best겠지만,
1) 빠르게 수정하기에는 시간이 오래 걸리거나
2) 버그 수정과정에서 서비스 중요 기능에 영향을 미칠 수 있어, 충분한 QA(테스트) 없이 나가기엔 risk가 큰 경우
3) 버그 수정에 있어 1분 1초가 급한 경우
(ex. 몇 초/분만 지나도 버그로 인해 심각한 피해를 보는 사람이 기하급수적으로 늘어날 경우)
등 과 같을 땐 일단 롤백을 통해 빠르게 이전 버전으로 되돌려서 서비스를 정상화를 먼저 시킨 뒤, 이후 충분한 시간을 가지고 버그를 수정해 재배포를 한다.
10개월간 일을 하면서, 내가 직접적으로 맡았던 기능에서 롤백이 발생했던 적은 그렇게 많진 않았다. 하지만 정신없이 대응했던 2번의 경험이 나에게 많은 것을 느끼게 해 줬다. 이번 글에선 롤백을 하는 과정에서 배웠던 점에 대해 [1. 문제 발생 전 2. 문제 발생 이후]로 나눠서 적어보려 한다.
1. 문제 발생 전
먼저 문제 발생 전, PM으로서 이런 부분을 더 챙겼다면 좋았지 않았을까 하는 부분을 적어본다.
1) 기술적인 부분을 고려하고 소통하자
개발자 분과 기술 관련 소통을 미리 했다면 발생 안 할 버그를 겪으면서, 기술적 부분에 대한 고려의 중요성을 느꼈다.
Naive 하게 생각하면, "기술적인 부분들은 개발자 분들이 알아서 해주겠지. 개발자 분들이 그쪽으론 더 전문 가니까!"라고 생각할 수 있다. 하지만 기능에 문제가 발생하는 것을 예방하기 위해선, PM이 기술적 부분도 고려를 하고 이를 개발자 분들과 깊이 있게 소통하는게 필요하다.
간단한 예시를 통해 PM에게 기술적 부분을 고려하는 것이 왜 중요한지 설명해보려 한다.
PM인 내가 이번에 기획한 기능의 구동을 위해선, 기능 동작 전 앱에서 "특정 data"를 불러와야 한다고 쳐보자.
단순하게 기획한다면, "앱의 홈화면에서 00 데이터, 이미지들을 불러와주세요"라고만 기획서를 만들고 개발자 분들께 전달할 수 있다. 하지만 실제로는 조금 더 세심하게 다음과 같은 부분까지 생각해야 한다.
1. 정보를 불러오는 시점
: 앱에 처음 진입할 때 정보를 불러올 것인가? 혹은 유저가 특정 버튼을 눌렀을 때?
기획적인 입장에선 어느 시점에서 불러오더라도 큰 상관이 없을 수 있다. 하지만 기술적인 측면에선, 시점을 언제로 결정하는지에 따라 뒷단에서의 처리 속도, 부하가 엄청나게 달라질 수 있다.
예를 들어, 기존 우리 앱은 처음 진입 시에 불러오는 정보의 양이 "이미 많았다." 유저가 처음 진입하자마자 보여줘야 할 정보가 많으니까. 이런 앱의 기존 상황에 대한 고려 없이, 이번 신규 기능 때문에 앱 초기 진입화면에서 불러오는 정보를 더 추가한다면 "유저가 앱을 처음 로딩할 때" 굉장히 큰 delay가 발생할 수 있다.
따라서 이런 상황에선, 정말로 앱에 진입하자마자 즉시 필요한 정보가 아니라면
1) 유저가 뭔가의 액션을 앱에서 했을 때(특정 버튼을 터치했을 때) 정보를 불러오기
2) 정보를 한꺼번에 다 불러오는 게 아니라, 유저가 앱을 스크롤할 때마다 30개씩만 추가적으로 불러오기
3) 정보를 카테고리별로 순차적으로 불러오기
등과 같이 한번에 너무 많은 정보를 불러오는 걸 막아, 앱 delay에 대한 나름의 방어책을 만드는 게 필요할 수 있다.
(확실하진 않지만... 많은 은행 앱, 금융앱들이 첫 로딩이 오래 걸리는 것도 이런 이유 아닐까? 물론 보안인증 같은 추가적인 처리 때문도 있겠지만, 처음부터 불러와야 할 데이터가 너무 많게 설계 되어서 그런 것도 있지 않을 까 싶다.)
2. 어떤 주기로 정보를 불러올까?
: 주기적으로 update 되어야 하는 정보라면, 몇 초에 한 번씩 정보를 update 할지
30초에 한번, 60초에 한번? 혹은 1시간에 한번? 기획자에겐 별거 아니어 보일 수 있다. 하지만 이 주기에 따라서도 기술적 이슈가 발생할지 아닐지가 결정되기도 한다.
- 너무 많은 정보를 잦은 주기로 요청하면 앱 구동 자체가 느려져 유저가 앱을 이용하는데 불편이 발생할 수도 있다.
- 혹은 중요한 정보인데 update주기가 너무 느리면, update 되지 않은 잘못된 정보(예전 정보)를 유저들이 최근 정보인 것으로 인식해 앱 사용에 큰 혼란을 초래할 수도 있다.
=> 실제로 나도 처음엔 기존의 앱 로직상, 각 화면에서 얼마나 많은 정보를 불러오고 있는지에 대한 이해가 부족했었다. 그래서 특정 기능을 만들었을 때 별생각 없이, 앱 첫 화면에서 data를 추가로 불러왔다가 앱 로딩에 있어서 문제가 생겼던 적이 있었다. 기술에 대해 완벽히 이해할 필요는 없지만, 기술적인 이슈가 발생할 부분은 없을지에 대해 개발자 분과 같이 소통하고 질문하는 등 지속적인 노력이 더 나은 서비스를 만드는 길이라고 생각한다.
2) 실제 현장에 가까운 + 극단을 가정한 개발 및 QA
개발부터 QA까지 일련의 과정에서, best 뿐만 아닌 worst 케이스에 대한 고려가 필요한 것을 배웠다.
실제 유저 case로 예를 들어 설명해 보도록 하자.
보통 식당들은 테이블 오더 앱 내에 몇십 개 정도의 메뉴만 만들어 놓는 게 일반적이다. 근데 xx 식당 사장님은 술도 워낙 종류별로 파시고, 각종 사이드 메뉴들이 워낙 많아 몇백~몇천 개의 메뉴를 만들어놓았다고 해보자.
회사에서 개발을 할 때는 그 정도의 메뉴 수 까진 가정을 안 하고 일반적인 숫자인 몇십 개 정도의 메뉴만 만들어 놓은 채 코드 개발을 했다. 그리고 큰 이상이 없었다. QA테스트를 할 때도 마찬가지로 비슷한 수의 메뉴를 만들고 해 봤을 때 문제가 없었다.
-> 그런데 알고 보니 개발 로직상, 몇십 개 정도의 메뉴 수에선 문제가 없지만, 몇 천 개 대로 메뉴 수가 늘어나게 될 경우 앱 로딩 속도가 너무 길어지게 설계되어있다면?
혹은 실제 유저 중엔 엄청나게 구형의 태블릿이나 저성능 기기를 가지고 앱을 이용하는 분이 있을 수 있다.
-> 회사에 있는 일반적인 기기나 성능 좋은 기기에선 문제가 없는데, 저성능 기기에선 로딩이 너무 느려질 수 있게 설계된 기능이라면? 그리고 회사에선 일반적인 기기로만 QA 테스트를 진행했다면?
이렇게 실제 현장에선, 회사 내부에서 생각하는 일반적인 상황이 아닌 극단적인 환경에서 서비스를 이용하는 유저들이 있을 수 있다. 그렇기 때문에 항상 과연 이 기능을 쓰는 극단적인 상황은 뭔지 생각해 보고, 이런 상황에서도 괜찮을지를 고려해서 개발하고 QA 하는 것이 필요하다.
위의 사례에 적용해본다면,
1) (선논의) 구현 방식 상 "메뉴 수에 따라 로딩 속도 등에 영향은 없는지" 개발자 분과 로직에 대한 논의
2) (데이터 파악) 만약 메뉴 수에 따라 영향을 받는다면, 실제 유저 데이터 상 극단의 유저는 어느 정도의 메뉴를 갖고 있고 앱 내에 해당 유저의 수/비중은 얼마나 되는지
3) (QA) 극단의 유저의 상황과 비슷한 환경을 만들어 놓고 QA를 했을 때도 문제가 발생하지 않는지
와 같은 식으로 기능을 개발한다면 조금 더 안전하게 기능을 개발할 수 있을 것이다.
3) 서비스가 복잡해질수록 서비스/기능 간 연관성 고려하기
회사의 서비스가 복잡해지고 커질수록 회사 내 타 서비스, 타 팀에서 개발한 기능에 대한 고려가 필요하다는 걸 배웠다.
회사 초반엔 서비스가 그렇게까지 복잡하지 않았고, 팀 간/기능 간 경계도 명확한 편이었다. 하지만 점점 서비스가 복잡해질수록 회사 내 타 서비스/기능과 우리 팀에서 개발한 기능 간에 충돌이 발생하곤 했고 이 때문에 꽤나 고생했던 기억이 있다. 우리 팀에선 건드린 게 없는데, 타 팀에서 개발한 내용이 우리 서비스에 영향이 가기도 하고, 우리 서비스의 기존 정책이 타 서비스의 정책과 충돌하기도 하는 등...
이런 상황을 겪으면서 팀 내적, 외적으로 기획자가 해야 할 역할에 대해 다시 한번 새기게 됐다.
- 팀 내적:
이 기능이 타 서비스 혹은 전체 서비스의 main 기능에 영향이 갈 요인은 없을지에 대해 개발자 분들과 미리 개발 전 선 논의하는 게 필요하다
- 팀 외적:
타 팀에서 배포하는 기능들에 대한 주기적 트래킹을 통해 혹시나 우리 서비스에 영향 갈 부분은 없는지 파악해야 한다.
또 타 팀 분들께 우리 서비스의 일정에 대해 잘 공지해 드리고, 우리 서비스의 정책/기능에 대해 잘 설명해 드림으로써 서로 간의 충돌이 일어나지 않도록 사전 예방하는 게 필요하다.
몇 번의 충돌을 경험하고 나서야, 이런 부분들이 조금씩 매끄러워지기 시작했었다.
2. 문제 발생 후
문제 발생 후 이를 대처 하는데 있어서, PM에게 중요한 것들에 대해 적어본다.
1) 중요한 건 대응
버그 자체를 안 만드는 게 best겠지만, 어쩔 수 없이 나온 버그라면 버그 이후의 의사결정과 대처가 당연히 정말 중요하다. 특히 심각한 버그의 경우, 매우 빠른 의사결정을 필요로 한다. 마치 의사 선생님이 응급상황에서 환자를 어떻게 해야 할지 결정해야 하는 상황처럼. 몇 초, 몇 분이 지날수록 버그로 인해 피해를 보는 사람이 기하급수 적으로 늘어날 수 있고, 지금 문제를 겪고 있는 사람입장에서는 그 상황을 겪는 시간이 늘어나는 거니까(ex. 식당에서 결제가 안돼, 주문이 안 들어가 등)
이때 롤백을 할지, 빠른 수정배포를 할지, 안내 문자를 내보내는 게 오히려 나을지, 내보낸다면 어떤 형식으로 누구에게까지 보낼지 등 여러 사항에 대해 빠른 고민 후 의사결정을 내리는 것이 필요하다.
처음에 이런 상황을 겪었을 땐 정말 어버버버 하면서 지나갔던 거 같다. 하지만 비슷한 상황을 2번 3번 겪으면서, 그 뒤에는 조금 더 이성적으로, 빠른 결정을 위해 필요한 게 뭔지가 더 잘 떠오를 수 있었던 것 같다.
더 큰 서비스를 맡게 될수록, 더 높은 직급에 올라가게 될 수록 순간적인 의사결정이 중요해지는 순간들이 올 텐데 이 경험들이 꽤 큰 자산이 될 것이라 생각한다.
2) 때로는 같이 있어드리는 것만으로도
한 번은 버그가 터져서 이에 대한 수정을 개발자 분이 해주셔야 했던 적이 있었다. 저녁 늦은 시간에 버그가 발견되어서, 개발자 분이 어쩔 수 없이 야근을 하면서 수정을 해야 하는 상황이었다. 그 당시 내가 직접적으로 도와드릴 수 있는 작업은 없었지만, 수정이 완료될 때까지 옆에서 같이 남아 시간을 보냈던 적이 있다.
기술적인 버그라고 하더라도 온전히 개발자 분들의 책임이라고 생각하지 않는다. Product에 관련한 전반을 관리하는 게 PM이니까. 또한 평소에 기획자들이 상상속에서 기획한 것들을 묵묵히 실제 현실로 만들어 주신 분들이다. 결국 내가 생각해 낸 것들 때문에 고생하시는 분들인데, 그 과정에서 노력하다 생긴 버그 때문에 늦게까지 고생을 하신다면 아무리 그게 기술적인 부분에서 나온 버그라도 같이 조금이라도 함께 있어 드리는 게 도리라고 생각했다. (이건 네 일, 이건 내 일 딱 선 긋고 나누는 것이 아니라)
이때 같이 남아드렸던 것에 대해 개발자 분께서 고마워하셨던 게 생각이 난다. "밤늦게까지 해야 해서 힘들고, 속상하고 그랬는데 같이 있어주신 것만으로 힘이 났다고". 또 CPO님께서 나중에 따로 말씀해 주시기를 "그렇게 같이 남아준 행동 잘한 거라고. PM으로서 그런 부분들도 중요하다"고 해주셨던게 기억이 난다.
결국은 어쩔 수 없이 이것도 사람끼리, 사람들 간에 하는 일이다. 물론 비즈니스 적으로, 이성적으로 하는 일처리도 필요하지만 이런 식의 감정적 지지가 필요할 때도 있다는 걸 느끼게 됐다. 그리고 이런 기회를 통해서라도 같이 일해 주시는 개발자 분들에게 항상 고생해 주셔서 감사하다는 마음을 표현할 수 있어서 나에게도 소중했던 시간이었다.
3. 마치며
실제로 여러 버그들을 겪고, 롤백을 겪으면서 기술적인 부분에 대한 이해도를 포함하여 지식적인 부분에서 많이 성장할 수 있었다. 또 급박한 상황을 대처해 나가는 경험을 통해 위기 대처 능력도 많이 올라갔다고 생각한다.
그런데 무엇보다 가장 크게 배웠던 건 같이 일하시는 분들의 소중함, 그분들에 대한 감사함이 아닐까 싶다. 솔직히 문제가 터지는 걸 좋아하는 사람은 아무도 없다. 그런데도 회사의 직원분들은 네 탓이네 내 탓이네 하기보다, 문제가 터졌을 때마다 항상 각자의 위치에서 묵묵히 대처해 주셨다. 오히려 서로 응원해 주시고, 서로가 실수한 부분을 감싸주시는 직원분들을 보면서 더 큰 위로를 많이 느꼈던 거 같다.
어쩌면 이런 사람 간의 유대라는 요소 때문에, 여러 부서와 부대끼면서 일을 할 수밖에 없는 PM이라는 직무를 고생 고생하면서도 나는 계속 꿈꾸고 있는 거 아닐까 라는 생각을 한다.
Profile: