Sentry: 오류 그룹화로 원시 예외를 처리 가능한 이슈로 바꾸는 방법

배경과 문제 정의

운영 환경의 코드가 실패하면 개발자는 네 가지 질문에 답해야 합니다. 오류가 어느 줄에서 났는지, 몇 명의 사용자가 영향을 받았는지, 어느 릴리스에서 시작됐는지, 어떻게 재현할지입니다. 일반 로그는 실패를 모두 기록하지만, 비슷한 기록 수천 건을 하나의 처리 가능한 문제로 묶지는 못합니다. Sentry는 이 간격을 메우기 위한 오픈소스 오류 모니터링 및 성능 추적 플랫폼입니다. 원시 이벤트를 조치 가능한 이슈로 바꾸는 것이 목표입니다.

어려운 부분은 그룹화입니다. 같은 결함이라도 기기, 로케일, 입력에 따라 메시지, 변수 값, 스택 경로가 달라집니다. 원문 텍스트로 중복을 제거하면 버그 하나가 수백 개의 이슈로 쪼개집니다. 예외 타입만으로 묶으면 관련 없는 장애가 섞입니다. Sentry는 이 두 극단 사이에서 안정적인 경계를 찾아야 합니다.

저장소의 스타는 약 4.5만 개이고 주 언어는 Python입니다. 라이선스 파일 LICENSE.md는 FSL-1.1-Apache-2.0, 즉 Functional Source License를 명시합니다. 토픽의 fair-source 태그와도 일치합니다. 팀은 코드를 읽고, 직접 호스팅하고, 내부용으로 수정할 수 있습니다. 다만 이 코드로 경쟁하는 상용 호스팅 서비스를 제공할 수는 없습니다.

핵심 아키텍처와 기술 원리

저장소는 대형 Python 모놀리스입니다. src/sentry 아래와 저장소 전체를 합치면 Python 파일이 8,000개를 넘고, 정적 프런트엔드에는 TSX 파일이 약 8,700개 있습니다. 웹 화면, 공개 API, 백그라운드 워커, 그룹화 엔진, 수집 경로가 이 하나의 코드 트리 안에 있습니다. 이벤트 흐름은 세 단계입니다. 첫 단계는 이벤트 스트림입니다. src/sentry/eventstream/snuba.py의 85번째 줄에 있는 SnubaProtocolEventStream이 삽입, 병합, 분리, 삭제를 위한 공통 프로토콜을 정의합니다. src/sentry/eventstream/kafka/backend.py의 63번째 줄 KafkaEventStream은 이 프로토콜을 상속해 메시지를 Kafka로 보냅니다. 호출하는 쪽을 바꾸지 않고 전송 방식을 교체할 수 있는 구조입니다. 둘째 단계는 그룹화입니다. src/sentry/grouping/variants.py에서 BaseVariant(26행)가 기반 타입입니다. ComponentVariant(113행)는 그룹화 구성 요소로 해시를 계산합니다. CustomFingerprintVariant(191행)는 사용자가 지문을 직접 지정하게 합니다. FallbackVariant(106행)는 다른 변형이 해시를 만들지 못한 이벤트를 맡습니다. 구성 요소는 src/sentry/grouping/component.py에 있으며 오류 타입, 오류 메시지, 파일명, 함수명을 포함합니다(240행부터 252행). 각 그룹화 설정에는 식별자가 있고, src/sentry/grouping/strategies/configurations.py의 8번째 줄 레지스트리에 등록됩니다. WINTER_2023_GROUPING_CONFIG나 FALL_2025_GROUPING_CONFIG 같은 이름 있는 설정은 src/sentry/conf/server.py에 있습니다. 버전이 있는 설정 덕분에 이전 설정을 남긴 채 알고리즘을 발전시킬 수 있습니다.

셋째 단계는 심볼화와 질의입니다. C, C++, Swift, Rust의 네이티브 크래시는 원시 메모리 주소로 들어옵니다. 디버그 심볼이 있어야 함수 이름으로 바꿀 수 있습니다. src/sentry/lang/native/symbolicator.py의 44번째 줄 SymbolicatorFunction 열거형은 별도 프로젝트인 외부 Symbolicator 서비스를 호출하는 접점입니다. 질의 쪽에서는 src/sentry/conf/server.py의 1749번째 줄이 Snuba 주소의 기본값을 http://127.0.0.1:1218로 둡니다. Snuba는 ClickHouse 위의 질의 계층으로, 검색, 추세, 성능 통계를 담당합니다. SDK와 맞닿는 입구에는 Relay라는 별도 Rust 구성 요소가 있습니다. 프로토콜 페이로드를 검증하고, 속도 제한을 걸고, 민감 정보를 제거한 뒤 이벤트를 Python 코드로 넘깁니다. 이 저장소에는 구현이 없습니다. 실행 요구 사항은 pyproject.toml의 requires-python = ">=3.13"에 나와 있습니다.

실용성 평가와 적용

그룹화는 가장 주의 깊게 살펴볼 기능입니다. 새 이벤트가 들어오면 엔진은 우선순위 순서로 변형을 시도합니다. 일치하는 사용자 지정 지문이 우선합니다. 해당하는 것이 없으면 구성 요소 해시가 결정하고, 폴백 변형이 나머지를 맡습니다. 사용자가 화면에서 그룹화 규칙을 바꾸면 이 우선순위 체인이 바뀝니다. 따라서 규칙 변경은 기존 이슈를 나누거나 합칠 수 있습니다. 평가할 때는 세 가지를 봐야 합니다. 첫째, 연동 범위입니다. README에는 공식 SDK 21종이 나옵니다. JavaScript, Python, Go, Rust, Java와 Kotlin, Swift, C#, C와 C++, Dart, Unity와 Godot 같은 게임 엔진을 포함합니다. 팀은 SDK 하나로 시작해 나중에 늘릴 수 있습니다. 둘째, 운영 부담입니다. 자체 호스팅 저장소 getsentry/self-hosted에는 docker-compose.yml, install.sh, clickhouse 디렉터리, nginx.conf가 있습니다. 이 구성은 관계형 데이터베이스, 메시지 큐, 열 지향 저장소, 질의 서비스, 역방향 프록시가 함께 돌아가는 완전한 배포를 보여 줍니다. 충돌 보고만 필요한 팀에게는 과할 수 있습니다. 데이터를 직접 통제하려는 팀은 이 비용을 감수합니다.

셋째, 라이선스의 경계입니다. FSL-1.1-Apache-2.0은 내부 사용, 수정, 자체 호스팅을 허용합니다. 이 코드로 경쟁하는 상용 서비스를 제공하는 것은 금지합니다. 사내 플랫폼 팀은 대부분 이 제한에 걸리지 않습니다. 호스팅 제품을 계획한 기업은 걸립니다. 실무에서는 그룹화 규칙 변경을 먼저 스테이징 프로젝트에서 시험하세요. 변경 전후의 이슈 수를 비교한 다음에 운영 규칙을 바꾸는 순서가 안전합니다.

업계 영향과 전망

Sentry는 업계가 오류를 바라보는 방식에 영향을 주었습니다. 그룹화를 숨은 휴리스틱이 아니라 버전, 식별자, 테스트를 갖춘 엔지니어링 대상으로 다룹니다. 이 관점은 다른 모니터링 도구가 이슈 집계를 보여 주는 방식에도 영향을 미쳤습니다.

라이선스 역시 다른 인프라 프로젝트도 택한 타협을 보여 줍니다. 소스 코드는 공개되어 읽을 수 있습니다. 내부 사용은 허용됩니다. 직접적인 재판매는 제한되고, 일정 기간 뒤 코드는 Apache 2.0이 됩니다. 이 방식을 오픈소스로 볼 수 있는지는 개발자들 사이에서 의견이 갈립니다.

저장소에서 읽히는 신호는 세 가지입니다. 첫째, 이름 있는 그룹화 설정이 늘고 있어 알고리즘이 버전 단위로 진화합니다. 둘째, 처리량이 중요한 수집과 심볼화는 이미 Rust 구성 요소에서 돌아갑니다. 셋째는 필자의 전망이며, 이 코드베이스에서 확인된 사실이 아닙니다. 관측 데이터를 하나의 플랫폼에 모으는 팀이 늘어날 가능성이 큽니다.