오락실 이용 현황과 수집 목적

오락실 상세를 본 사람과 실제 방문한 사람을 같은 숫자로 설명할 수는 없다. 예를 들어 여행 중 갈 곳을 비교하며 여러 문서를 열어 본 이용자는 모두 방문하지 않을 수 있다. 상세 조회는 관심, 길찾기는 이동 의도, 방문 인증은 현장에서 남긴 결과를 각각 보여 준다.

flowchart TD
    accTitle: 목적별 지표와 방문 도메인의 분리
    accDescr: 조회와 길찾기 이벤트는 개인 식별 없이 집계하고 방문 인증은 별도 도메인 기록에서 집계한다.
    E[조회와 길찾기] --> A[목적별 분석 이벤트]
    A --> S[서버 집계]
    V[방문 인증 기록] --> T[방문 지표 집계]
    S --> R[권한별 결과]
    T --> R

서비스 개선에는 이런 차이를 볼 지표가 필요하지만, 한 사람의 이동을 따라가는 이력까지 모을 필요는 없다고 봤다. 목적별 분석 이벤트에는 IP·사용자 에이전트·사용자 식별자를 저장하지 않고, 결과를 공개 기본 지표와 운영용 상세 지표로 나누었다.

분석 이벤트와 방문 통계

상세 조회와 길찾기는 정해진 종류의 추가형 이벤트로 저장해 서버에서 집계한다. 이벤트 종류와 관련 오락실을 API에서 제한하고 내부 컬렉션을 직접 열지 않아, 브라우저가 임의의 분석 항목을 만들지 못하게 한다.

sequenceDiagram
    accTitle: 상세 읽기와 지표 기록
    accDescr: 상세 API는 공개 오락실 데이터를 읽고 조회 이벤트 기록을 시도한 뒤 상세 결과를 반환한다.
    participant W as 이용자 요청
    participant A as 상세 API
    participant D as 저장소
    W->>A: 오락실 상세 읽기
    A->>D: 공개 오락실 조회
    D-->>A: 상세 데이터
    A->>D: 조회 이벤트 기록 시도
    A-->>W: 상세 결과

방문 횟수와 서로 다른 방문자 수에는 방문 인증 기능의 자료를 사용한다. 익명 조회 이벤트에 사용자 ID를 추가해 계산하지 않는다. 방문 기능 자체에는 계정이 필요하지만, 그 사실이 목적이 다른 조회 이벤트에도 식별 정보를 저장해야 한다는 뜻은 아니기 때문이다.

공개 통계와 운영자 지표

기본 지표는 공개하고, 길찾기·방문 인증·서로 다른 방문자 수 등 상세 운영 지표는 담당 오락실 계정과 허용된 운영진에게 제공한다. 화면에서 숫자를 가리는 것으로 끝내지 않고 조회 API에서 현재 계정이 해당 오락실을 관리할 자격이 있는지 검사한다.

flowchart TD
    accTitle: 지표 응답의 접근 경계
    accDescr: 현재 공개 가능한 장소인지 확인한 뒤 기본 지표와 권한이 필요한 운영 지표를 구분해 반환한다.
    Q[지표 조회] --> P[장소의 공개 정책 검사]
    P --> B[공개 기본 지표]
    P --> O[대상 운영 권한 검사]
    O --> D[보호된 상세 지표]

집계할 때도 장소의 공개 조건을 적용한다. 상세 문서에서 볼 수 없는 장소가 통계로 드러나지 않게 하기 위해서다. 방문과 순위는 별도 저장소를 사용하더라도 공개 가능한 대상을 정하는 기준은 함께 따른다.

지표의 해석과 집계 실패

목적별로 집계하면 개인 추적 이력 없이 정보의 이용 현황을 살펴볼 수 있다. 분석 저장에 실패해도 정상적인 상세 조회는 반환한다. 지표를 남기는 과정 때문에 이용자가 보려던 문서까지 열지 못하게 해서는 안 되기 때문이다.

조회수는 고유 이용자 수가 아니며 반복 요청과 기록 실패의 영향을 받는다. 방문 인증 횟수도 그 기능의 확인 조건 안에서 해석해야 한다. 숫자를 볼 때 수집한 행동과 집계 범위를 함께 이해할 수 있도록 제공하는 이유다.

관련 글과 자료: 엔지니어링 기록