운영 중인 서비스에서 “특정 사용자만 결제가 안 된다”, “업체 계정에서는 화면이 멈춘다”는 문의가 들어오면, 오류 메시지만으로는 원인을 좁히기 어렵습니다. 반대로 이메일, 전화번호, 요청 전문, 화면 입력값까지 관측 도구에 넣으면 조사 속도는 빨라질 수 있지만 비용, 개인정보, 노이즈가 함께 늘어납니다.
Sentry와 Grafana를 함께 쓰는 팀의 목표는 모든 행동을 기록하는 데 있지 않습니다. 누가 어떤 환경에서 어떤 기능을 쓰다가, 어떤 유형의 실패를 만났는지 판단할 수 있는 최소 데이터 집합을 정하는 일이 먼저입니다. Sentry는 예외와 실패 흐름을 추적하는 데, Grafana와 Faro 같은 관측 도구는 요청량, 성공률, 브라우저 오류, 세션 흐름을 보는 데 쓸 수 있습니다. 두 도구에 같은 개인정보를 넓게 복제할 이유는 없습니다.
이 글은 CTO, 개발 리드, 운영 담당자가 관측 요구사항을 정하고 구현한 뒤, 데이터 품질과 비용을 계속 관리하는 순서로 구성했습니다.
1. 도구를 고르기 전에 장애 질문을 먼저 적는다
관측 설계는 SDK 설치로 시작하면 범위가 쉽게 커집니다. 먼저 운영팀과 개발팀이 실제로 답해야 하는 질문을 적어야 합니다. 이 질문이 수집 항목의 상한선이 됩니다.
예를 들어 B2B와 일반 사용자 기능이 함께 있는 서비스라면 다음 질문이 의미 있을 수 있습니다.
- 업체 사용자와 일반 사용자 중 어느 집단에서 오류가 더 많이 발생하는가
- 오류가 운영 환경에서만 발생하는가, 특정 배포 버전부터 늘어났는가
- 오류가 브라우저, 운영체제, 화면 경로, API 응답 상태와 관계가 있는가
- 로그인 실패, 권한 거부, 결제 실패, 파일 업로드 실패 중 어떤 실패가 사용자 이탈로 이어지는가
- 특정 API의 실패가 잘못된 호출 위치 때문인지, 서버 장애 때문인지 구분할 수 있는가
여기서 중요한 것은 “사용자를 식별할 수 있는가”와 “사용자군을 구분할 수 있는가”를 분리하는 일입니다. 많은 운영 질문은 개인의 실명이나 이메일 없이도 답할 수 있습니다. business_user, consumer_user, admin처럼 권한 또는 사용자 유형을 나타내는 값, web, mobile_web 같은 클라이언트 구분, production, staging 같은 환경 정보가 더 직접적인 단서가 되기도 합니다.
이 단계의 산출물은 관측 질문 목록과 데이터 사전 초안입니다. 데이터 사전에는 각 항목마다 다음을 적습니다.
| 항목 | 운영 질문 | 수집 위치 | 보존 필요성 | 제외 또는 변환 방식 |
|---|---|---|---|---|
| 사용자 유형 | 어떤 사용자군이 실패했는가 | Sentry 태그, Grafana 속성 | 높음 | 역할명만 전송 |
| 배포 버전 | 어느 배포부터 오류가 증가했는가 | Sentry 릴리스, 로그 레이블 | 높음 | 공개 가능한 버전 식별자 사용 |
| 내부 사용자 키 | 동일 사용자의 반복 오류인가 | 제한된 오류 컨텍스트 | 조건부 | 원문 ID 대신 비가역 또는 별도 매핑 키 검토 |
| 이메일·전화번호 | 대개 오류 원인 분석과 무관 | 수집 금지 | 낮음 | 전송 전 제거 |
| 요청 본문·응답 본문 | 실패 원인에 따라 다름 | 서버 로그 또는 오류 컨텍스트 | 조건부 | 허용 필드만 추출, 민감 필드 제거 |
이 표에서 “조건부”가 많은 항목은 설계 검토가 필요한 항목입니다. 편하다는 이유만으로 기본 수집값에 넣지 않는 편이 낫습니다.
2. 사용자 정보는 세 층으로 나눠 전송한다
사용자 정보는 한 덩어리로 취급하면 안 됩니다. Sentry의 사용자 컨텍스트, 태그, 추가 컨텍스트와 Grafana의 로그 레이블 또는 이벤트 속성은 검색성과 비용 영향이 다를 수 있기 때문입니다. 제품별 세부 제한과 과금 기준은 사용 중인 플랜 및 설정에서 확인해야 합니다.
운영 설계에서는 다음 세 층으로 나누면 결정하기 편합니다.
공통 분류값: 대부분의 이벤트에 남긴다
환경, 서비스명, 배포 버전, 사용자 유형, 클라이언트 종류, 기능 영역처럼 집계와 필터링에 계속 쓰는 값입니다. 이 값은 오류를 묶고 대시보드에서 비교하는 기준이 됩니다.
다만 값의 종류가 지나치게 많아지면 검색과 집계가 어려워집니다. 예를 들어 URL 전체, 사용자별 고유 식별자, 주문번호처럼 거의 매번 달라지는 값을 태그나 레이블로 쓰면 고유값 수가 급격히 늘어날 수 있습니다. 이런 현상은 흔히 카디널리티 증가라고 부르며, 쿼리 성능, 저장 비용, 대시보드 해석에 부담을 줄 수 있습니다.
조사용 연결키: 필요한 오류에만 제한한다
반복 문의, 권한 문제, 특정 계정의 데이터 상태를 조사해야 할 때는 내부 사용자 키나 요청 추적 키가 도움이 됩니다. 다만 이 키가 다른 시스템의 데이터와 쉽게 연결돼 개인을 식별할 수 있다면 개인정보 취급 범위를 넓힐 수 있습니다.
따라서 다음 중 하나를 선택해야 합니다.
- 운영자가 동일 사용자의 반복 오류만 구분하면 되는 경우: 관측 목적의 별도 식별자 또는 변환된 키를 사용한다.
- 고객 지원 과정에서 원래 계정과 연결해야 하는 경우: 매핑 테이블의 접근 권한, 보존 기간, 열람 절차를 별도로 정한다.
- 이 연결이 없어도 오류를 해결할 수 있는 경우: 사용자 키 자체를 보내지 않는다.
비가역 변환을 했다고 해서 모든 위험이 사라지는 것은 아닙니다. 다른 데이터와 결합해 다시 연결할 수 있는지, 조직 내부에서 누가 원래 값을 알고 있는지까지 검토해야 합니다. 법적 판단이 필요한 서비스라면 개인정보 및 보안 담당자와 수집 목적, 처리 근거, 보유 기간을 함께 확인하는 편이 안전합니다.
원인 재현용 상세값: 허용 목록 방식으로 남긴다
오류의 원인을 재현하려면 API 경로, HTTP 상태 코드, 기능 플래그, 결제수단 유형, 파일 크기 구간처럼 상세 정보가 필요할 수 있습니다. 이때는 “제외할 민감정보 목록”보다 “보내도 되는 필드 목록”을 먼저 정하는 편이 낫습니다.
예를 들어 요청 본문 전체를 전송하지 않고, 오류 판단에 필요한 operation_type, validation_error_code, file_size_bucket 같은 값만 추출합니다. 주소, 연락처, 인증 토큰, 쿠키, 비밀번호, 결제 정보, 원문 입력 텍스트처럼 민감할 가능성이 높은 값은 기본적으로 전송하지 않는 쪽에서 시작합니다.
이 단계의 산출물은 이벤트 스키마와 필드 허용 목록입니다. 프론트엔드, 백엔드, 데이터, 보안 담당자가 같은 문서를 봐야 SDK마다 다른 값이 들어가는 일을 줄일 수 있습니다.
3. 구현은 환경 분리와 필터링을 먼저 적용한다
관측 SDK를 붙일 때 가장 흔한 실패는 개발 환경의 오류, 브라우저 확장 프로그램 오류, 알려진 경고, 테스트 트래픽이 운영 이슈와 한 대시보드에 섞이는 경우입니다. 운영자가 알림을 신뢰하지 않게 되면 도구를 설치한 의미가 줄어듭니다.
구현 순서는 다음과 같이 잡을 수 있습니다.
-
환경을 분리한다. 로컬과 개발 환경의 이벤트를 외부 관측 서비스로 보내지 않거나, 운영 환경과 명확히 다른 프로젝트·데이터 소스로 분리합니다. 스테이징은 배포 검증에 필요할 수 있으므로, 운영 데이터와 섞지 않는 전제에서 별도 수집 여부를 결정합니다.
-
릴리스와 서비스 버전을 연결한다. 오류가 코드 변경 이후 늘었는지 판단하려면 배포 버전이 이벤트에 연결돼야 합니다. 버전 규칙, 배포 시점, 롤백 여부를 운영 문서에 남겨야 대시보드의 오류 증가와 배포 이력을 맞춰 볼 수 있습니다.
-
PII 기본 전송을 끈다. Sentry 등 도구가 제공하는 기본 개인정보 전송 옵션을 확인하고, 서비스 정책에 맞지 않는 기본 수집은 비활성화합니다. 이후 프론트엔드와 백엔드 전송 직전에 URL 파라미터, 헤더, 요청 본문, 오류 메시지를 다시 검사하는 필터를 둡니다.
-
알려진 노이즈를 분류한다. 하이드레이션 경고처럼 프레임워크나 브라우저 조건에서 반복되는 오류는 무조건 삭제하기보다 먼저 표본을 검토합니다. 사용자 기능 장애와 관계없는 것으로 판단한 뒤에는 제외 규칙, 발생 조건, 재검토 시점을 기록합니다. 같은 이름의 오류라도 배포 후 양상이 바뀌면 필터가 진짜 장애를 가릴 수 있습니다.
-
샘플링 규칙을 분리한다. 모든 오류를 항상 같은 비율로 수집할 필요는 없습니다. 결제, 로그인, 권한, 데이터 저장처럼 실패 비용이 큰 흐름은 더 많이 남기고, 성능 추적이나 정상 세션 데이터는 서비스 규모와 예산에 맞춰 표본을 조정할 수 있습니다. 오류 이벤트, 트랜잭션, 세션 재현, 로그는 저장 단위와 비용 구조가 다를 수 있으므로 한 숫자로 결정하지 않습니다.
이 단계의 산출물은 SDK 설정값, 필터 규칙 목록, 환경별 수집 정책, 배포 점검 항목입니다. 필터 코드는 애플리케이션 코드와 함께 버전 관리하고, 왜 제외했는지 주석이나 운영 문서로 남겨야 담당자가 바뀌어도 판단 근거를 잃지 않습니다.
4. Sentry와 Grafana에는 서로 다른 질문을 맡긴다
두 도구에 동일한 이벤트를 대량으로 보내면 비용만 이중으로 늘어날 수 있습니다. 도구별로 조사 역할을 나누면 수집 기준도 명확해집니다.
Sentry에는 예외, 처리되지 않은 오류, 사용자 영향이 큰 실패, 오류 발생 전후의 제한된 컨텍스트를 우선 보냅니다. 운영자는 이슈 단위로 오류 빈도, 영향을 받은 릴리스, 사용자 유형, 브라우저 조건을 확인하고 재현 가능한 결함부터 수정합니다.
Grafana에는 시간 흐름과 분포를 보는 데이터를 둡니다. API별 요청 수와 성공·실패 비율, 사용자 유형별 요청 결과, 브라우저 콘솔 오류의 추세, 플랫폼별 세션 비율처럼 “장애가 얼마나 넓게 퍼졌는가”를 확인하는 질문에 맞습니다. Loki를 쓴다면 로그 검색을 위한 LogQL 설계도 필요하지만, AI 도구나 MCP로 쿼리 초안을 만들더라도 사람이 데이터 소스, 시간 범위, 레이블, 집계 단위를 검토해야 합니다. 잘못된 쿼리는 그럴듯한 그래프를 만들 수 있습니다.
대시보드는 처음부터 많이 만들지 않는 편이 좋습니다. 운영 화면에는 다음 네 가지면 출발할 수 있습니다.
- 핵심 사용자 여정의 성공률과 실패 유형
- API 또는 기능 영역별 오류 추세
- 사용자 유형과 클라이언트 환경별 실패 차이
- 새 릴리스 이후 증가한 오류와 알림 상태
이 단계의 산출물은 대시보드 명세와 알림 정책입니다. 각 패널에는 담당자, 확인 주기, 이상 징후가 보였을 때의 다음 행동을 적습니다. 그래프를 보는 사람이 아무도 없거나, 알림을 받은 뒤 무엇을 확인할지 정해지지 않았다면 그 지표는 아직 운영 지표가 아닙니다.
5. 배포 전에 데이터 누출과 노이즈를 시험한다
관측 시스템은 운영 배포 후에야 문제를 찾는 도구이지만, 관측 설정 자체는 배포 전에 시험해야 합니다. 테스트 계정과 의도적으로 만든 오류를 사용해 다음을 검증합니다.
- 사용자 유형, 환경, 릴리스 버전이 기대한 위치에 표시되는가
- 이메일 주소, 토큰, 인증 헤더, 입력값 등 제외 대상이 이벤트에 남지 않는가
- 권한 없는 사용자가 호출한 API와 서버 내부 장애가 구분되는가
- 필터가 알려진 노이즈를 줄이면서도 신규 오류를 가리지 않는가
- Grafana의 성공률 계산에서 취소된 요청, 예상된 권한 거부, 재시도 요청을 어떻게 다루는가
- 오류 알림이 담당 채널로 전달되고, 같은 사건의 중복 알림이 과도하지 않은가
특히 성공률은 분모 정의가 핵심입니다. 권한이 없는 사용자가 호출하면 안 되는 API를 프론트엔드가 호출해 서버가 거절한 경우, 서버 상태만 보면 실패율 문제로 보일 수 있습니다. 하지만 제품 흐름 관점에서는 잘못된 화면 조건 또는 권한 분기 문제일 수 있습니다. API별 대시보드에는 상태 코드만 놓지 말고 호출 주체, 기능 경로, 기대된 실패인지 여부를 함께 해석할 수 있는 조건을 남겨야 합니다.
운영에 들어간 뒤에는 월별 또는 릴리스 단위로 데이터 사전을 다시 봅니다. 더 이상 쓰지 않는 태그, 의미가 불분명한 오류 이름, 너무 넓은 URL 값, 조사에 한 번도 쓰이지 않은 컨텍스트는 줄일 후보입니다. 반대로 VOC 조사에서 반복해 부족했던 정보는 목적과 보존 범위를 정한 뒤 추가합니다.
처음 회의에서 결정할 일은 “사용자 정보를 어디까지 넣을까”가 아닙니다. 다음 장애가 발생했을 때 팀이 어떤 화면을 열고, 어떤 조건으로 사용자를 구분하며, 어떤 데이터 없이도 원인을 찾을 수 있는지를 한 장의 데이터 사전으로 합의하는 일입니다. 그 문서가 있어야 Sentry의 이슈와 Grafana의 그래프가 기록 저장소가 아니라 운영 판단 도구가 됩니다.
