운영 포털에서 Pendo를 테스트하며 본 것들

내부 사용자와 파트너가 함께 쓰는 운영 포털은 외부 고객용 메인 서비스보다 사용자 수가 적을 수 있다. 그래서 종종 Product Analytics 도구를 따로 붙일 필요가 없다고 생각하기 쉽다. 하지만 실제 운영에서는 반대인 경우가 많다. 사용자 수는 적어도, 그 사용자가 매일 수행하는 작업은 비즈니스 운영과 직접 연결되기 때문이다.

이 글은 React 기반 운영 포털에 Pendo를 실제로 붙여보며 확인한 점을 정리한다. 완전히 전환한 것은 아니고, 사용자 pain point를 더 잘 보기 위해 검토하고 테스트한 경험에 가깝다. 핵심은 “어떤 기능이 얼마나 쓰이는가”를 보는 데 그치지 않는다. 사용자가 어디서 막히는지, 기존 방식으로는 왜 그 맥락이 잘 안 보였는지, Pendo를 붙여보니 무엇이 더 보였는지를 중심으로 본다.

사용자는 어디서 막히고 있었을까

운영 포털은 보통 피드백이 빠르게 들어온다. Slack 메시지, 회의, Jira 티켓으로 불편 사항을 금방 들을 수 있기 때문이다. 문제는 이런 피드백이 대부분 정성적이라는 점이다. “여기 불편하다”, “이 기능을 잘 못 찾겠다”, “어디선가 자꾸 막힌다”는 이야기는 들리는데, 실제로 어느 화면에서 어떤 흐름이 끊기는지는 잘 보이지 않았다.

예를 들어 아래 질문은 정성 피드백만으로 답하기 어렵다.

• 어떤 화면이 실제로 가장 자주 열리는가
• 새 기능이 배포된 뒤 adoption이 늘었는가
• 특정 작업 흐름에서 사용자가 자주 중단되는 지점은 어디인가
• 많이 요청받는 기능과 실제로 많이 쓰이는 기능이 같은가

이런 질문에 답하려면 운영 포털도 행동 데이터를 가져야 한다. 외부 고객 서비스만큼 정교한 퍼널 분석이 아니어도 괜찮다. 다만 최소한 무엇이 자주 쓰이고, 무엇이 거의 안 쓰이며, 어디서 멈추는가는 보여야 개선 우선순위를 잡을 수 있다. 이번에 Pendo를 검토한 것도 결국 이 pain point 때문이었다.

그래서 Pendo를 테스트해 봤다

Pendo를 본 이유는 단순히 분석 도구를 하나 더 늘리기 위해서가 아니었다. 사용 흐름 안에서 사용자가 실제로 어디서 막히는지, 어떤 기능이 채택되는지, 새 기능을 화면 안에서 직접 안내할 수 있는지까지 한 번에 확인해 보고 싶었기 때문이다.

즉, 이 테스트의 목적은 “전면 전환”보다 아래 질문에 답해 보는 것이었다.

• 이 도구가 운영 포털의 사용 흐름을 더 잘 보여 주는가
• 인증 이후 초기화와 사용자 식별을 안정적으로 붙일 수 있는가
• 이벤트 추적을 제품 관점으로 더 정리하기 쉬운가
• Guide, NPS, Replay가 실제 pain point를 보는 데 도움이 되는가

Pendo를 붙여보니 기존 방식과 무엇이 달랐나

운영 포털에는 이미 다른 방식의 관측과 분석이 존재할 수 있다. 성능과 오류는 잘 보이는데, 사용자가 실제로 어떤 기능을 어떻게 쓰는지는 덜 보이는 경우가 많다. 반대로 이벤트는 쌓이는데, 그 이벤트가 제품 사용 맥락 안에서 어떤 의미를 갖는지 해석하기 어려울 때도 있다.

Pendo를 붙여보며 느낀 차이는 대체로 세 가지였다.

즉, Pendo의 차별점은 단순히 이벤트를 하나 더 수집하는 데 있지 않았다. 운영 포털 안에서 사용 흐름을 보고, 안내하고, 다시 반응을 보는 일을 한 도구 안에서 더 가깝게 묶어 준다는 점에 가까웠다.

Pendo 초기화에서 가장 중요한 것은 시점이다

React 앱에 Pendo를 붙일 때 가장 먼저 신경 써야 하는 것은 SDK 설치보다 초기화 시점이다. 인증이 끝나기 전에 initialize를 호출하면, 익명 사용자나 불완전한 식별 정보로 세션이 기록될 수 있다. 그러면 분석 데이터가 빠르게 섞인다.

실무적으로는 보통 아래 조건이 만족된 뒤 초기화하는 편이 안정적이다.

1. 로그인 여부가 확정되었을 것
2. 사용자 식별자와 계정 정보가 준비되었을 것
3. 앱이 최소한의 렌더를 마친 상태일 것

즉 “앱이 마운트되면 바로 initialize”보다, 인증과 사용자 컨텍스트가 준비된 뒤 한 번만 initialize하는 패턴이 낫다.

아래는 구조 이해를 위한 개념 예시다.

import { useEffect } from "react";
 
type AuthState = {
  isAuthenticated: boolean;
  user?: { id: string; email: string; team: string };
};
 
export function usePendoBootstrap(auth: AuthState) {
  useEffect(() => {
    if (!auth.isAuthenticated || !auth.user) return;
 
    window.pendo?.initialize({
      visitor: {
        id: auth.user.id,
        email: auth.user.email,
      },
      account: {
        id: auth.user.team,
      },
    });
  }, [auth.isAuthenticated, auth.user]);
}

핵심은 Pendo가 “누가 어떤 맥락에서 이 앱을 쓰고 있는가”를 올바르게 아는 상태에서 세션을 시작하게 만드는 것이다.

자동 수집만으로는 부족하고 커스텀 이벤트가 필요하다

Pendo는 기본적으로 페이지 뷰나 클릭 같은 정보를 어느 정도 자동 수집한다. 하지만 운영 포털에서 정말 중요한 것은 비즈니스 의미가 있는 행동이다. 예를 들면:

• 사용자 생성 완료
• 권한 변경 요청 제출
• 내보내기 실행
• 특정 승인 흐름 완료

이런 이벤트는 단순한 클릭 로그와 다르다. “버튼을 눌렀다”보다 “실제 작업이 완료되었다”가 더 중요하다. 그래서 커스텀 이벤트를 별도로 설계해야 한다.

이벤트 이름을 설계할 때는 “행동이 끝난 상태”를 기준으로 잡는 편이 좋다. 그래야 나중에 funnel이나 adoption을 볼 때 의미가 선명해진다.

Hook으로 감싸 두면 추적 코드가 덜 번진다

Pendo SDK를 각 컴포넌트에서 직접 호출하기 시작하면 이벤트 이름과 속성 규칙이 빠르게 흩어진다. 그래서 추적 로직은 Hook이나 helper로 한 번 감싸 두는 편이 낫다.

아래는 구조를 단순화한 개념 예시다.

type EventPayload = Record<string, string | number | boolean>;
 
export function usePendo() {
  function track(name: string, payload: EventPayload = {}) {
    window.pendo?.track(name, payload);
  }
 
  return {
    trackUserCreated(userType: string) {
      track("user_created", { userType });
    },
    trackExportRequested(exportType: string) {
      track("export_requested", { exportType });
    },
  };
}

이렇게 두면 컴포넌트는 추적 도구 세부사항보다 “어떤 비즈니스 행동을 기록할 것인가”에 집중할 수 있다. 나중에 도구를 바꾸더라도 호출 지점을 전부 뒤집지 않아도 된다.

Guide와 NPS는 언제 유용할까

Pendo를 붙이면 흔히 분석 대시보드만 떠올리지만, 실제로는 Guide와 NPS도 꽤 유용하다.

• Guide
  • 새 기능이나 변경된 워크플로우를 인앱에서 바로 안내할 수 있다
  • 문서 링크만 던지는 것보다 실제 화면 맥락 안에서 설명하기 쉽다
• NPS
  • 운영 포털도 “추천 의향”과 자유 응답을 통해 만족도를 볼 수 있다
  • 다만 점수 자체보다 어떤 맥락에서 불만이 나왔는지 함께 봐야 의미가 있다

내부 사용자와 파트너가 함께 쓰는 운영 포털에서는 특히 Guide가 강했다. 릴리스 노트를 따로 찾지 않아도, 사용자가 실제로 기능을 접하는 순간 짧은 설명을 보여줄 수 있기 때문이다.

Session Replay는 왜 같이 보게 되었나

사용자가 어디서 막히는지 보고 싶다는 문제의식에서 출발했기 때문에, Session Replay는 자연스럽게 눈에 들어왔다. 숫자만 보면 “이 화면에서 이탈이 많다”는 것까지는 알 수 있어도, 사용자가 어떤 맥락에서 멈췄는지는 보이지 않는 경우가 많기 때문이다.

Pendo를 테스트하면서 특히 흥미로웠던 점은 Analytics, Guide, Replay가 서로 완전히 분리된 경험이 아니라는 점이었다. 기능 사용 흐름을 보고, 특정 지점에서 실제 사용 맥락을 다시 확인하는 식의 접근이 가능해 보였다.

물론 이것만으로 바로 전환 결정을 내릴 수 있는 것은 아니었다. privacy 설정, 마스킹, 실제 운영 비용, 기존 분석 체계와의 역할 분담은 별도로 더 봐야 했다. 하지만 “사용자가 막히는 장면을 더 직접적으로 볼 수 있겠다”는 감각은 충분히 확인할 수 있었다.

디버깅할 때는 데이터보다 식별 맥락부터 확인해야 한다

분석 도구가 제대로 붙었는지 볼 때 가장 먼저 확인할 것은 차트가 아니라 식별 정보다. visitor와 account가 기대한 값으로 들어가지 않으면, 그 뒤 데이터는 전부 흔들린다.

실무적으로는 아래 순서가 편하다.

1. 브라우저에서 현재 visitor/account가 기대한 값으로 잡혔는지 확인한다
2. 네트워크 탭에서 SDK 호출이 정상 전송되는지 본다
3. 스테이징 환경에서 이벤트 이름과 속성이 의도대로 들어가는지 확인한다
4. 마지막으로 대시보드에서 실제 집계가 맞는지 본다

이 순서를 거꾸로 가면 대시보드 숫자만 붙잡고 원인을 찾느라 시간이 오래 걸린다.

전환까지 가지 않았어도 확인할 수 있었던 것

이번 작업은 Pendo로 완전히 전환한 사례는 아니다. 다만 직접 붙여 보며 아래 정도는 판단할 수 있었다.

• 운영 포털에서도 제품 사용 흐름을 더 세밀하게 볼 수 있다
• 초기화 타이밍과 식별 정보 설계가 데이터 품질에 큰 영향을 준다
• 커스텀 이벤트를 제품 언어로 정리해야 의미 있는 분석이 된다
• Guide, NPS, Replay는 “사용자가 어디서 막히는가”를 보는 데 분명한 후보가 될 수 있다

즉, 이번 테스트는 도구 도입 완료보다 무엇을 더 보고 싶었는지와, 그 목적에 Pendo가 얼마나 맞는지 확인하는 과정에 가까웠다.

운영 포털에서도 결국 중요한 것은 행동의 의미다

Pendo 같은 도구를 붙인다고 해서 제품 분석이 자동으로 완성되지는 않는다. 정말 중요한 것은 어떤 행동을 중요한 신호로 볼지 정의하는 일이다.

운영 포털에서 Product Analytics가 유효한 이유는 단순하다. 자주 쓰이는 기능과 거의 쓰이지 않는 기능, 사용자가 자주 머뭇거리는 지점, 새 기능이 실제로 채택되는 속도를 숫자로 볼 수 있기 때문이다.

그래서 React 앱에 Pendo를 붙일 때도 핵심은 SDK 설치 자체가 아니다.

• 언제 initialize할 것인가
• 어떤 행동을 커스텀 이벤트로 볼 것인가
• 어떤 흐름을 Guide나 NPS로 보완할 것인가

이 세 가지가 선명하면, 운영 포털도 더 이상 감에 의존해서 개선하지 않게 된다. 이번에 Pendo를 테스트해 본 경험도 결국 같은 결론으로 이어졌다. 중요한 것은 도구 이름보다, 우리가 정말 보고 싶은 pain point가 무엇인지 먼저 분명히 하는 일이었다.

참고 자료

• Validate your Pendo installation 
• Choose IDs and metadata 
• Conditionally initialize Pendo 
• Guides overview 
• Overview of Session Replay 
• Activate Session Replay