원인 파악 : 이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다. 하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.
그니까 이상황에서
이 상황이 된거다.
엑스 쳐진 부분에 문제가 생긴 상황 -> 서버 스택의 여러곳에 순간적으로 장애가 발생한 상황
근데 어떻게 알아냈는가? : 로그를 통해서 서비스에 장애에 대한 원인을 추적했기 때문이다.
->로그는 서비스에서 문제가 생겼을 시에 문제 해결을 하는데 큰 역할을 한다는 이야기를 위한 아티클. 헷갈리면 블랙박스 떠올리기.
2. 사용자 행동 분석
로그는 단순한 기술 기록이 아니다. 사용자가 서비스를 어떻게 사용하는지, 어디서 머무르고, 어디서 이탈하는지, 그 모든 행동의 흔적을 남긴다.
즉, 로그는사용자 경험(UX)을 분석하고 개선하기 위한 1차 데이터다.
예를 들어,
어떤 버튼을 눌렀는가
어느 페이지에서 오래 머물렀는가
어느 시점에서 앱을 종료했는가
이런 기록은사용자 여정을 추적하게 해주고, UX의 병목 구간이나이탈 포인트를 정확히 찾아낼 수 있게 해준다.
다시 말해, 로그는 ‘지표’가 아니라 ‘행동’ 그 자체다. 행동을 보면 니즈가 보이고, 니즈를 보면 개선점이 보인다.
**배달앱 예시. 상황 : 배달앱에서 사용자가 음식을 주문을 완료하지 않고 앱을 떠나는 경우를 추적한다 가정. 해결 : 로그에 기록된 사용자 셋션 정보를 분석해서, 사용자가 어떤 페이지에서 이탈했는지, 혹은 어떤 버튼을 클릭했는지 알아내기. 실행 : 이를 통해 사용자가 장바구니에서 결제 페이지로 넘어가는 중에 이탈한 경우 결제 과정에서 문제가 있었음을 알 수 있고 때문에 결제 프로세스 개선을 위한 인사이트를 얻는 후, 해결위한 움직임.
3. 비지니스 전략 수립.
로그는 단순한 에러 추적이나 사용기록 수집을 넘어, 비즈니스 전략을 세우는 데 필요한 핵심 데이터를 제공한다.
예를 들어,
하루 동안 특정 상품 페이지에 몇 명이 들어왔는지
주문까지 연결된 비율은 얼마나 되는지
결제가 완료된 시간대는 언제 집중되는지
이 모든 건로그를 기반으로 추적할 수 있다.
“어? 이거 데이터 분석이잖아요?” 맞아요. 바로 그 ‘데이터’를 제공하는 게 로그의 본질적인 역할입니다.
결국 로그는 ✔서비스 이용 패턴을 이해하게 만들고 ✔매출 추이를 관찰하게 해주며 ✔주문량 증감의 원인을 분석하게 해주는 도구다.
그리고 이 모든 정보는 📈더 나은 비즈니스 전략을 세우기 위한 설계도가 된다.
**배달앱 예시. 상황 : 배달앱에서 특정 지역의 주문량이나 주문 평균 금액등을 추적하고자 한다. 해결 : 로그에 기록된 주문 정보 분석해서 진행 -> 특정 프로모션 기간동안 해당 지역의 주문량이 급증한 데이터를 확인하면, 프로모션의 효과를 평가할 수 있다. 이 데이터를 통해 향후 비슷한 프로모션을 더 효과적으로 계획하고, 비지니스 성장 전략을 세울 수 있다.
4. 로그의 종류
Q. 로그의 종류는 어떤 것들이 있나요?
로그의 종류는 다양하게 있고 다 알면 좋으나, PM으로써 확실하게 알아야할 것은 클라이언트 로그 라는 것만 알아도 1차적으로 충분하다.
✅ 클라이언트 로그란?
사용자의 장치, 예를 들어 **웹 브라우저, 모바일 앱 등에서 발생하는 ‘행동 이벤트’**를 기록하는 로그다.
**예시_내일 배움 캠프 웹페이지
가정해보자. 우리가내일배움캠프 담당자 PM이라면, 이런 게 궁금할 수 있다.
“우리 페이지, 얼마나 많은 사람들이 보고 있을까?” “‘내일배움캠프’ 탭, 사람들이 클릭은 하고 있는 걸까?”
이때 필요한 게 바로클릭 로그, 즉,유저가 어느 버튼을 누르고 어디를 이동했는지를 추적하는 데이터다.
👉 이 클릭 로그를심는 것 자체가 로그 작업이며, 👉 이 데이터를 기록하는 방식이클라이언트 로그인 것이다.
정리하자면,
✔ “내가 궁금한 데이터가 있다 → 그 데이터를 심는다 → 그게 로그다” ✔ 그리고 사용자가 보는 화면에서 일어나는 건 대부분클라이언트 로그다.
로그 설계 순서(기초 이론편)
더 세부적인 건 이후 포스팅에서 다룰 예정
로그 설계 순서 1_ 로그 설계 목표정의
로그 설계는 단순히 "무엇을 기록할지"가 아니라 "왜 기록할지" "어떻게 기록할지"에 대한 전략적 접근이 필요하다. PM은 이 설계를 통해 개발 팀이 실제로 필요한 데이터를 수집하고, 이 데이터를 기반으로 문제를 빠르게 파악하거나 서비스를 개선할 수 있도록 해야한다.
이전 단락에서 스파르타 내일 배움 캠프 예시를 설명란것이 기억나는가?
내가 내일 배움 캠프의 담당자라 가정했을때
스파르타 코딩 클럽의 웹페이지에서 "내일배움캠프 를 신청 항목 클릭해 들어온 유저들이 얼마나 되는지를 보고싶다"는 궁금증을 갖고있을거라고 했다. 때문에 로그 역시 내일배움캠프 신청 항목 GNB에 클릭로그를 심길 원할거라고.
그런 내일 배움 캠프 pm의 로그 항목 정의는 이렇다.
로그 항목 정의 : 내일 배움 캠프 탭 클릭한 걸 클라이언트 로그로 넣겠다!
이렇듯, 로그를 설계할때는 PM이 로그의 목적성과 필요성을 정의 한뒤, 그것에 맞게 로그를 설계해야한다.
로그 설계 순서 2_ 로그 항목 정의 및 설계
이렇게 로그 항목을 PM이 정의한 이후 개발쪽에 넘긴다. 그 이후엔
> 개발에서 로그 전송 작업진행
> 전송 잘되는지 테스트 진행
> 잘 쌓이는 것 확인
> 데이터들이 쌓여서 데이터 확인 가능한 순서.
순으로 진행된다.
앞에서는내일배움캠프만 담당한다고 가정했지만, 이번엔 내가스파르타 코딩클럽 전체 서비스의 PM이라고 생각해보자.
그럼 이제 궁금한 건 한두 가지가 아니다.
내일배움캠프뿐 아니라
기업교육페이지는 얼마나 클릭되는지,
인텔리픽은 유입이 어떤지,
고객센터는 자주 찾는지,
마이페이지는 얼마나 사용되는지 등…
모든 메뉴의 클릭, 유입, 전환 데이터가 다 궁금해진다.
이럴 땐?
👉모든 주요 아이콘과 버튼에 클릭 로그를 심어야 한다.
이건 단순히 “로그 심기”를 넘어서 서비스 전반에 대한행동 데이터 구조를 설계하는 일이다.
📌 그래서 PM은?
서비스 담당자들은 보통자신이 맡은 서비스에 필요한 로그를 전부 설계하고 수집한다고 보면 된다.
내가 무엇을 알고 싶은지 → 어떤 행동을 추적해야 하는지 → 어떤 로그를 어디에 심을 것인지
