0. 결심
당시 한꺼번에 장애를 겪으며 '어떻게 대응해야 효율적으로 할 수 있지? 이걸 어떻게 모두에게 전파할 수 있지? 그리고 이해관계자들에게는 어떻게 전파해야하지?' 라는 생각을 했었다.
하이브리드앱이라는 새로운 플랫폼이 생기면서 얽히게 되는 이해관계자들은 더 많아질 수밖에 없었다. 애초에 '이 에러가 나도 확인해야하는 에러였어?' 라며 자신이 이해관계자인지도 불분명한 경우도 있었다. 앱에서 디버깅이 불가하여 웹 개발자에게 요청해야하는 순간들도 있었으며 '이게 왜 앱에서 에러가 나는거야?'라며 이해도가 서로 일치하지 않는 경우가 있었다. 그리고 이렇게 취합된 문제정의와 해결 과정들을 운영팀과 소통하면서 전달하는 과정도 순탄치 않았다.
커뮤니케이션 코스트를 줄이면서도 운영팀은 문제 정의를 빠르게하여 서비스대응을 하고 개발팀은 정상화될 수 있게 문제 해결에 집중할 수 있는 과정이 필요하다고 느꼈다. 전사적으로 공유하거나 또는 이러한 과정이 필요함을 인지 시킬 필요가 있다고 생각이 들었고, LINE이나 우아한형제 블로그 글들을 읽으며 이 작은 조직 내에서도 프로세스를 수립하고 프로덕트팀에게 제안해보고 싶었다.
시스템 관점에서 장애에 어떻게 잘 대응할 수 있까라는 부분을 생각해봤을 때 아래와 같은 카테고리들이 나올 수 있겠다.
- 어떻게 하면 더 빨리 감지할 수 있을까
- 장애가 발생하더라도 그 영향 범위를 최소화하려면 어떻게 해야 할까
- 앞으로 어떻게 하면 같은 장애가 또 발생하지 않게 할까
- 시스템이 자동으로 복구되게 만들 수 없을까
1. Recognize Before Customer!
고객보다 먼저 장애를 인지하는 게 중요하다. 하지만 프로덕트팀은 보통 CS채널이나 업무요청 채널로부터 접수된 이후 인지하게 되는 것이 일반적인 프로세스였다.
CS팀으로부터 접수받기전에 프로덕트팀에서 먼저 알 수 있지않았을까? 그렇다면 고객보다 먼저 장애를 인지하려면 모니터링이 중요하겠다라는 생각을 했다. 우리 서비스가 문제없이 잘 돌아가고 있는지 서비스에 영향을 주는 모든 걸 확인하는 것이다. 보통은 해당 서비스의 개발자나 운영 담당자가 모니터링 알람을 직접 받는 것 같았다.
1편에서 겪었던 에러들 중 CS건으로 직접적으로 전달받고, 문제가 많이 진행된 상태에서 인지한게 조금 아쉬웠던 상황들이 있었다. 예를 들어 채널톡 SDK 라이브버리 충돌문제나 FCM 알림 같은경우 '비정상적인 종료활동에 대한 알람을 미리 받고 더 빠르게 대응할 수 있었을텐데'라는 생각을 했었다. 그래서 이상수치에 대한 알람을 준다는 점 그리고 에러 로그를 볼 수 있고 무료로 사용할 수 있다는 점에서 앱에 최적화된 CrashAnalaytics 라는 Firebase 모니터링 툴을 선택하게 되었다.
Meta tag 에러 이후 심은 CrashAnalyatics 덕에 채널톡에서 발생하는 에러를 이상 수치에 대한 알람으로 프로덕트팀 전사적으로 알람이 전파되었고 이는 고객접수보다 빠르게 먼저 확인할 수 있는 계기가 되었다. Tool을 이용한 에러 메시지와 수치 모니터링으로 장애를 빠르게 인식하는 것으로 개선한 것이다.
또한 API 통신이 오가는 Interceptor 부분에서 발생하는 서버 에러를 캐치해 에러 발생시 Slack으로 알리게 연동시켰다.
'주문장이 올라가지 않습니다!' 라는 CS가 접수됐다면 담당 운영자는 해당 시간의 에러 메세지만 보고도 원인을 바로 파악할 수 있는 것이다. '주문장을 이미 올리셨네요!'
이처럼 개발팀에게 직접 요청하여 원인을 알아내지 않고도 알림툴을 확인할 수 있음으로써 커뮤니케이션 코스트를 줄이고 더 신속히 대응할 수 있었던 경우다.
둘의 차이가 있다면, CrashAnalytics 를 설치한 플랫폼은 프로덕트팀 모든 구성원들이 알람을 받도록 설정했고, 네이티브 앱으로 개발되고 에러를 캐치할 경우 알람을 주게 연동시킨 슬랙같은 경우는 개발팀은 네이티브 개발자만 알람을 받도록 했다. CrashAnalytics 경우에는 이상 수치 이상에 대한 알람이므로 모두가 인지하는 게 맞다 생각했고, 슬랙연동 같은 경우는 모든 에러 로그를 찍어 확인하게 해놨기때문에 네이티브 개발자와 운영팀만 확인할 수 있게 이해관계자들을 나누어 더욱 집중할 수 있게 했다.
2. 영향범위 최소화하기
장애가 발생하더라고 영향범위를 조금이라도 최소화할 수 있는 장치가 필요할 수도 있다. 에러가 발생했을 때 안내 팝업처럼 미리 장치를 심는 것이다. 그리고 프로덕트에러가 아니여도 모든 에러에 해당할 수 있으며 시스템 내에서 해결할 수 있으면 미리 예방 방지턱을 만들어두는 것이 좋겠다.
예를 들어, 서비스 특성상 동대문 도매 상가를 기반으로 두고 해당 유저들이 이용을 했었는데 특정 상가들에선 네트워크 통신이 느리거나 끊기는 경우가 있었다. 이 경우 서비스내 로딩창이 돌고, 유저들은 서비스 내 문제인 줄 알게 되고 경험이 좋지 못하게 될 것이다. 이 같은 경우 안드로이드 경우는 NetworkManager를 통해 연결이 되었는지, 불안정한지 감지할 수 있었으므로 따로 네트워크 불안정 뷰를 보여주고 다시 refresh 해 새 페이지를 불러오게 바꾸었다.
3. 장애 회고와 개선
그리고 장애건들을 list up 하면서 거창한 건 아니지만 장애대응 매뉴얼이나 장애 리포트 같은게 있으면 어떨까라는 생각을 했다.
그래서 당시 2주마다 스프린트가 끝나면 회고를 했었는데, 네이티브의 장애 회고도 같이하면서 당시 아래의 카테고리를 적용하여 리스트업한 것을 회고했었다.
- 장애 현상
- 장애 원인
- 장애 영향도
- 장애 조치사항
- 장애 재발 대비책
- 그 외 추가 정보 등
시작은 앱 파트에서 시작을 했지만 이것을 개발팀의 프로세스로 적용하면 어떨까라는 의견도 제시해보았다. '프로세스도 문화가 뒷받침되어야한다'라는 말처럼 내가 몸담고 있던 조직의 규모는 작았고 문서화나 리포트를 작성하는 것보다 다른 더 중요한 것들이 많았다. 앱 파트 또한 안드로이드개발자 1명, iOS 개발자 1명씩이라 이런 프로세스를 정립해 나가는 과정들이 더욱 소모적일 수 있겠다라는 판단을 했다. 하지만 모두가 공감하는 이슈였고 모두가 '인지'할 수 있게 되었다는 점에서 의미있는 회고였던 것 같다.
그리고 이러한 장애들을 지표화한 후 반복되는 장애들 중 시스템화할 수 있는 것들을 또다시 추려볼 수 있다. 예를 들어 '주문장이 열리지 않는다'라는 빈도수가 높았던 에러는 일일이 개발팀에서 주문장 링크를 전달해주는 형식에서 관리자 페이지 시스템내 주문장 링크를 복사하는 기능 개발로 이어진 좋은 케이스였다. 운영단에서 개발팀에게 업무요청하고 기다리지 않아도 직접 시스템내 해결할 수 있게 함으로써 고객이 기다리는 시간을 최소화할 수 있게 된 것이다. 에러 해결과정에서 자동화까지 된 경우였다.
3. Set My Priority!
에러 대응 과정을 겪으며내가 앱 개발을 하는데 있어서 우선순위도 확실하게 정해진 것 같다.
앱은 웹에 비해 아주 폐쇠적인 플랫폼이다. 웹의 배포는 개발자가 직접 배포하고 서비스로 바로 출시할 수 있지만 앱은 스토어라는 검수자가 있고 그 업데이트되는 시간도 아무도 알 수없게 된다. 따라서 더욱 신중에 신중을 더하여 개발과 배포를 해야겠다고 생각했다.
일단 앱을 구동하는데 있어서는 앱이 뻗지않게 하는 것, 그리고 서비스적인 면에서는 '주문을 꼭 확인해야하는 사장님'들이 쓰는 서비스에서는 '주문 확인 기능'은 배포 전 꼭 확인해야할 것을 최우선으로 두는 것이다. 유저에게 직접적으로 닿아있는 서비스가 주문 확인이었고, 주문 확인이 되지 않으면 우리 서비스를 이용하는 유저는 일을 할 수 없게 되니 서비스를 이용하는 의미가 없어진 것이다. 주문장이 안보이면 안되고, 주문 푸쉬 알림을 눌렀는데 앱이 죽어버린다면 그 사용자경험이 더욱 더 안좋아지는 것이다. 그래서 이 두 가지를 최우선적으로 안정화해나가는 작업을 계속해야겠다는 생각을 했다.
또한 앱의 배포주기도 정하게 되었다. 기존의 앱 파트의 배포주기와 전략은 존재하지 않았다. 다른 앱 서비스들은 어떻게 배포 주기를 갖는지 물어보며 다녔었는데 타 서비스의 앱같은 경우는 최소 1주, 보통은 2주단위나 한달단위로 정기적인 주기를 갖는 것 같았다. 이 기회에 우리 회사의 앱 파트도 배포전략을 조금 다르게 가야겠다는 생각을 했다. 1편의 에러들로 인해 앱 배포를 에러 대응으로 일주일간 4번을 했었다. 물론 크리티컬한 이슈때문에 어쩔수없이 바로 배포를 할 수밖에 없었던 상황이었지만 배포가 바로 필요하지 않는 경우도 있다. 주문이 들어온 걸 알려주는 FCM 푸쉬 알림에서 에러가 났지만 이는 부가적인 서비스이고 또한 유저분들은 거의 다 카카오톡 알림으로 확인하는 경우가 많으니(2개의 알람 서비스를 제공하고 있었다) 이런 건은 후일로 다른 배포건과 함께 배포하는 것으로 그 배포 시기를 우선순위에 따라 미룰 수 있다. 그래서 다른 파트와도 함께 배포를 해야하는경우, 기존에는 모든 파트의 테스크가 다 끝난 시점이 네이티브 배포 날짜였다면, 네이티브가 정해놓은 배포날에 맞춰서 배포하는 방식을 제안하기도 했었다.
4. QA 프로세스 구축
이후 나는 QA 프로세스도 개선하고자 했다. 첫 번째는 시스템적으로 QA 환경을 마련해주었다.
기존에는 앱 QA와 내부 고객을 위한 테스트 환경이 미흡했었다. 수동으로 테스트환경에 연결된 파일을 기계에 빌드해서 QA를 전달하는 방식이었다. 내부 테스트를 위한 Firebase의 App Distribution에 파일을 빌드해서 올렸고 더이상 기획팀과 '다시 빌드해주세요' 라는 불필요한 소통 과정도 줄일 수 있었다. 그리고 더 나아가 기존 apk 파일이나 aab 파일을 수동으로 스토어에 올리던 비효율적인 배포 프로세스도 fastlane을 도입하여 자동화시켰다.
두 번째는 서비스적으로 앱 배포가 되기전 비즈니스적으로 제일 중요한 서비스가 담긴 기능들은 필수 확인 기능으로 리스트업을 했었다. 나는 서비스의 정책도 잘 꿰고 있었고 무엇이 비즈니스 임팩트가 큰 지도 판단할 수 있는 사람이라고 생각했기에 운영팀과 함께 리스트업을 한 기억이 있다. 예를 들어 새 기능 개발이 있더라도, 연관이 없어보이는 기능이어도 앱 파트의 QA 단계에서는 필수로 검증하고 넘어가는 리스트들이었다.
무엇보다도 개발자의 입장에서 정책 구멍없이, 작동되지 않는 기능들이 없이, 엣지 케이스가 없이 '잘 만든 프로덕트'를 전달하는 것이 중요하겠다. 이 부분은 QA 에 대한 글을 다시 작성할 때 또 다시 작성해보도록 하겠다.
5. 마치며
1년차 주니어에게 큰 에러들이 한꺼번에 발생하면서 당시에는 정말 난관들을 헤쳐 나가기가 벅찼었다. 하지만 하나씩 헤쳐 나가면서 남는 것은 제품의 완성도인 것 같다. 점차 제품의 완성도를 높여 나가고 에러가 발생해도 빠르게 대응할 수 있는 툴을 구축했다. 순간의 대응에 그치지 않고 팀 내에 장애를 인식할 필요성을 제고하며 '프로덕트'의 완성도를 위해 여러 방면으로 해결하고 했던 것이 이 에러들을 겪으며 나에게 남는 교훈이자 뿌듯함이다.
참고자료
'💬 회고' 카테고리의 다른 글
| 2023년 회고. (1) | 2024.01.31 |
|---|---|
| 나는 어떻게 장애를 전파하였는가 (1) (1) | 2023.10.07 |