후원 받은 커피는 더 많은 자료를 만드는 원동력이 됩니다.
목차
1. 문제의 ‘원인’을 알지 못하겠어요
버블 커뮤니티를 보면, 뉴비 분들이 앱을 만들면서 발생하는 버그 및 이슈를 공유하며 조언을 종종 구합니다. 문제가 발생했을 때, 먼저 해야할 일은 “왜 문제가 발생했는가?”를 알아내는 것입니다. 즉, 문제의 원인을 명확히 파악해야 합니다. 사실 원인만 파악하면, 문제를 해결하는 건 그리 어렵지 않습니다. 다만, 뉴비라면 원인을 파악하는 법을 모르기에 답답할 수 밖에 없습니다. 이번 글에서는 버블에서 발생한 문제의 원인을 어떻게 파악하는지 알아보는 법을 다뤄보겠습니다.
디버깅은 2가지 방법을 활용해 원인을 파악하면 됩니다.
1.
디버그 모드로 파악하기 → 프론트 워크플로우에 적합
2.
서버 로그에서 파악하기 → 백엔드 워크플로우에 적합
2. 디버그 모드 활용하기
버블 에디터에서 [Preview] 버튼을 클릭해 Dev 앱을 실행할 경우, URL에 debug_mode=true 라는 파라미터가 존재합니다. 이는 현재 Dev 앱을 디버그 모드로 실행하겠다는 의미입니다. 만약 해당 파라미터 자체를 지우거나 False 값으로 설정한다면, 디버그 모드로 실행되지 않습니다. 디버그 모드 실행 시, 브라우저 하단에 [Debugger]가 보이게 됩니다.
좌측 : 디버그 모드 실행 O / 우측 : 디버그 모드 실행 X
[Debugger]에는 크게 3가지 선택 값이 있습니다. 여기서 무엇을 선택하느냐에 따라 디버그의 깊이가 달라집니다. 즉, 문제 원인을 파악할 수 있는 수준이 달라집니다. 기본 값은 [Normal]로 설정됩니다.
[Normal]을 선택 시, 디버깅 없이 데브 앱을 사용합니다.
반면 [Slow]를 선택하면, 동작하는 워크플로우가 하나하나 보여지면서 앱이 작동합니다. 어떤 트리거 및 액션이 동작하는지 보여주면서 앱이 동작합니다. 앞선 [Normal] 설정에 비해 어떤 워크플로우가 관여하는지 알 수 있는 장점이 있습니다.
마지막으로 [step-by-step]을 선택하면, 워크플로우의 트리거와 액션을 내가 차근차근 확인하면서 앱을 동작시킬 수 있습니다. 앞선 [Slow]는 워크플로우만 보여줄 뿐, 트리거와 액션이 멈추지 않고 계속 동작합니다. 반면, [step-by-step]은 워크플로우를 보여줌과 동시에 트리거와 액션을 내가 하나하나 클릭해서 넘어갑니다. [Debugger]에 있는 [Run Next] 버튼을 클릭해야 다음 액션으로 넘어갑니다.
추가적으로 각 액션에 사용한 dynamic value나 conditional 등의 값도 확인할 수 있습니다. 아래 이미지의 좌측을 보면, 액션의 조건이 “current user is looged out and current page name contains mycourse”인 걸 볼 수 있습니다. 보면 [only when]이 빨간 색으로 표시됐는지 이는 해당 조건이 충족되지 못했음을 의미합니다. 또한, 우측에서 현재 사용된 “Current User”의 값이 무엇인지도 확인할 수 있습니다.
이처럼 워크플로우에서 이슈가 있을 때, 디버그 모드의 [step-by-step]으로 확인하면 어디서 문제가 발생했는지 알 수 있습니다. 액션에서 조건이 동작하지 않았는지 아니면, 값이 잘못 전달 됐는지 등을 확인할 수 있습니다. 만약 디버거 모드를 사용하지 않는다면, 뇌피셜로 하나하나 뜯어봐야 합니다…
디버거를 사용합시다. (출처 : velog - @wupajw)
3. 서버 로그 체크하기
앞선 디버거는 프론트엔드 워크플로우를 파악하는 데 좋습니다. 하지만, 백엔드 워크플로우에서 발생한 문제는 어떨까요? 이런 경우에 에디터에서 [setting] - [Sever logs]를 들어가 앱의 작동 로그를 확인하면 됩니다. 모든 워크플로우의 트리거와 액션을 확인할 수 있습니다. 여기서 백엔드 워크플로우를 확인하면 됩니다. 참고로 로그는 Dev 앱과 Live 앱이 독립적으로 저장됩니다. 우측의 [switch to] 버튼을 클릭해 각 버전의 로그를 확인할 수 있습니다.
참고로 서버 로그로 프론트 워크플로우의 문제도 파악할 수 있습니다. 애초에 해당 탭에서는 앱의 모든 로그를 저장하기 때문입니다. 다만, 보여주는 정보가 적고 불편하기에, 프론트 워크플로우에 발생한 버그 체크는 디버거를 사용합시다.
4. 전문가에게 에디터 공유하기
짬을 무시할 수 없습니다. 버블을 오랫동안 사용한 사람이라면, 버그 및 이슈의 원인을 뉴비보다 훨씬 빠르게 찾아냅니다. 왜냐면 고수들도 처음 버블을 시작할 때, 비슷한 경험을 해봤기 때문입니다. 저 또한, 버블을 갓 시작한 분들에게 질문을 받을 때, “어 이거 내가 이전에 겪은 문제인데?”하면서 바로 답을 알려준 적이 몇 번 있습니다. 그렇기에 버블 고수에게 도움을 요청하는 게 가장 빠른 방법일 수 있습니다.
짬은 무시할 수 없다. (출처 : 쇼미더머니)
다만, 버블 고수에게 문제를 공유할 때, 글과 이미지만으로 온전한 정보 파악이 어려울 수 있습니다. 프론트, 백엔드, 데이터베이스, 보안 등 다양한 부분이 얽혀있기에 공유한 정보는 단편적일 수 밖에 없습니다. 버블 고수들도 현생이 있는데, 이렇게 단편적인 정보만 받으면 원인을 더 빠르게 파악할 수 없어서 고통 받습니다.
이런 경우에 그냥 에디터를 공유하는 게 깔끔합니다. 놀랍게도 버블에선 에디터를 누구나 접근하도록 설정하는 기능이 있습니다. 설령 에디터에 초대 받은 계정이 아니여도 URL만 입력해 접근할 수 있습니다.
에디터의 [setting] > [General]에 들어간 후, [Privacy & Security] 영역의 [Define who can see and modify the app]에서 [Everyon can view]를 선택하면 됩니다. 그러면, 이제 에디터 URL을 누구나 접근할 수 있습니다. 참고로 [Everyone can edit]을 선택하면 앱 수정도 가능하니 주의합시다. 이제 에디터 URL을 복사해 고수분에게 공유해 도움을 요청할 수 있습니다.
+ 마지막 챕터를 다룰 때, 살짝 걱정이 있었습니다. 오히려 이 기능을 알고 URL을 복사해 고수분들에 무작정 공유해 도움을 요청하는 분들이 간혹 있지 않을까 합니다… 노파심에 말하면, 많은 고수분들이 금전적 이익이 아니라 그저 선의의 목적으로 도움을 드리고 있습니다. 이 부분을 고려하며 도움을 요청드리면, 더 좋은 버블 커뮤니티가 생길 것 같습니다
버블박스가 버블을 주제로 책을 발행할 예정입니다. 출간 알림을 등록하면 추후에 안내 드릴게요!
+ 알림 신청자 중 일부에게 책을 무료로 드릴 예정입니다.
버블박스를 운영하는 페임리가 궁금하다면?
If you're curious about Family?
버블박스 l BubbleBox
